## 3 Cellular Network Modeling
### Relational Database Development
#### 3.7.1 Logical Schema  
To translate the conceptual schema of Figure 6 into the logical one, preliminary restructuring of the former is needed, especially concerning the specialization constructs. In this restructuring step, we removed/combined unnecessary attributes, simplified entities, and introduced surrogate keys to effectively support the temporal capabilities of the system. The resulting restructured schema is shown in Figure 7.  
First, the derived attributes are not reported in the restructured schema, as they will not be present in the tables of the database, given that it is possible to recover them through the definition of appropriate views. Specifically, the choice not to store _coverage_ as a proper attribute is strongly dependent on the temporal dimension of the database: explicitly tracking its changes over time would result in an unnecessary overhead for the system, since the evolution of the coverage over time can be easily retrieved by appropriate temporal queries involving observation (precisely due to the lack of this spatial attribute, the aggregations of Figure 6 have been replaced here with standard relations). Entities PCU and DEVICE have not been reported in the restructured schema, as they are of secondary importance, especially considering the purposes of the positioning system; to note their marginal roles, these entities have no attributes in Figure 6.  
Let us now describe how the specializations were translated, omitting, for now, the roles played by the new primary keys that have been defined:  
* Administrative area: two entities were introduced to deal with administrative areas: registration area and routing area. * The first entity focuses on the registration service (LA for GSM and UMTS, and TA for LTE); the attribute _code_reg_area_ represents _lac_ for 2G/3G and _lac_ for 4G. * The second entity deals with the routing service, where differently from the first one (only for RA in GSM and UMTS), the attribute _code_rout_area_ represents _nc_. * For all the following specializations, it was decided to keep just the parent entity:
* Network controller: the attribute _code_ctrl_ groups the partial identifiers of the (former) children and _type_ctrl_ denotes the type of controller (based on the considered cellular technology). * Base station: the attribute _code_base_ groups the partial identifiers of the (former) children and _type_base_ indicates the type of base station (based on the considered cellular technology). * SubPLMN: the optional attribute _ncc_ represents the homonymous value considered in GSM technology only. * Cell: all the physical-layer cell identifiers values of different technologies are now modeled as optional attributes in the parent entity. Moreover, without loss of generality, a single attribute _ci_ is used to represent both _ci_ and _eci_. * Observation: the attribute _id_device_ actually replaces the entity device. As for the primary keys depicted in the restructured schema, they were defined as follows. Since the children of base station specialization had, in the previous schema, identifying relationships with different entities (precisely, BTS and NodeB with the network controller, and eNodeB with SubPLMN), to keep the parent entity by eliminating the children, the artificial attribute _id_base_ was introduced as the new primary key. Note how the relations towards network controller and SubPLMN are now optional as a result of this choice. Finally, entities with a valid time interval are now strong entities identified by a serial key: registration area is identified by _id_reg_, routing area by _id_rout_, cell by _id_cell_, and network controller by _id_ctrl_. The reason for the introduction of such surrogate keys is twofold.