## 3 Cellular Network Modeling
### The Temporal Aspects  
A temporal database is a database that integrates support for handling data involving time. The temporal aspects of interest are the so-called valid time and transaction time: the first represents the time interval during which a fact is true in the real world, and it is a user-defined representation of time; the second represents the time interval during which a fact is current in the database, and it is a system-defined representation of time, namely, managed by the DBMS. A temporal database is physically implemented by augmenting the primary key of each table one wants to temporalize. Specifically, the key is extended with a pair of values for each temporal dimension, representing the extremes of the respective interval. A database that implements both valid and transaction time is referred to as a bi-temporal database. The schema in Figure 6 reports the temporal aspects that have been associated with the entities, by means of the letters that are located on the bottom right corners of the corresponding boxes. Each entity of the cellular network has a transaction time interval (letter T). This allows us to easily retrace the database evolution, showing its content as it was at any previous moment in time. One could argue about the decision to maintain the observation's _time_observation_ attribute despite the presence of the transaction time; however, such values may be different, for example, due to a delay in the insertion of one instance into the database with respect to its moment of capture. Moreover, if updates are carried out on such database records (e.g., to correct errors), they might not have an impact on the _time_observation_, while certainly generating a new version of the record, tracked through the transaction time. In addition, considering that renaming may affect the cell, administrative area, and radio access network (as explained in Section 2.2), for each of the entities involved we also provide a valid time interval (identified by LS) that allows us to specify the moments in reality in which they existed. For example, this can be the case when we want to keep track of a cell that has been renamed and therefore no longer exists, but existed in a certain past time interval. Finally, to make the distinction between transaction and valid time clearer, and to justify the presence of both of them, consider the following two scenarios (for the ease of reading, we adopt a simplified version of the tuples, not referring to the actual conceptual schema). _Scenario 1_. On 2022-09-01, a new observation is added to the database, which, for the first time, reports the presence of a cell, say \(cell_{x}\), which has never seen before. Thus, a tuple that describes the cell is inserted with both transaction and valid time intervals starting from 2022-09-01:  
\[\{\;(cell_{x},T:[2022-09-01,\infty],LS:[2022-09-01,\infty])\;\}\;.\]  
The day after, a delayed observation, originally recorded on 2022-08-25, gets finally processed and inserted into the database. This observation also reports the presence of \(cell_{x}\). As a result, the tuples that describe the event now are:  
\[\{\;(cell_{x},T:[2022-09-01,2022-09-02],LS:[2022-09-01,\infty]),\] \[(cell_{x},T:[2022-09-02,\infty],LS:[2022-08-25,\infty])\;\}\;.\]  
Note how, in this way, the cell's history is kept by means of the logically deleted tuple, while the current information is encoded by the newly added one. _Scenario 2_. Valid and transaction times play a central role also in the management of a cell renaming or relocation. To reliably identify such an event, often multiple observations witnessing the change of parameters are needed, collected over an extended time frame (ingeneral, the fewer the measurements related to a given area, the longer the period). Let us assume that a cell, named \(cell_{x}\), first detected and inserted in the database on 2017-07-12, changes part of its global identifier on 2022-09-01, thereby being detected from that moment on as a new cell, say \(cell_{y}\).