## 6 Implementation and Application of the PORTAL-DOORS System
### Implementation of Current Version 0.6  
When providing registrar services for separate PORTAL and DOORS nodes, NEXUS registrars operate in a manner consistent with the original separate design. However, when providing registrar services for a combined PORTAL-DOORS node, NEXUS registrars can also operate in a manner that enables integrated storage of both PORTAL and DOORS record data on the same server as currently implemented in version 0.6 and reported here. Figure 5  
displays a diagram depicting the relational database model for the current 0.6 draft version of the PDS schemas available at www.portaldoors.org. This data structure model shows the primary and foreign keys that provide referential integrity constraints for the relational database tables of a NEXUS server node in the network system. Figure 6 displays the main table in relation to the auxiliary and administrative support tables for managing agent access to the system. All PDS tables in the database are named with the prefix **pds_** to distinguish them from the tables of other administrative providers such as Microsoft's ASP.net authentication and authorization services and their database tables named with the prefix **aspnet_**. Further, in order to simulate management of PORTAL, DOORS, and NEXUS network nodes at the same site in the same database, the tables for each of these servers are named respectively with the prefixes **pds_P_**, **pds_D**, and **pds_N** while tables common to all three server types are named with the prefix **pds_A**. In the following discussion, the prefix **pds_** appears in the figures but not in the text where it should be assumed. Figure 5: Relational database model for NEXUS combined design server with integrated storage of both PORTAL and DOORS data record fields as a NEXUS data record. See Figure 6 for the administrative content of a NEXUS record. Figure 6: Relational database model for the auxiliary and administrative support tables for system and agent management in relation to the main table for the NEXUS combined design server. See Figure 5 for the non-administrative content of a NEXUS record. With a conventional master-detail relationship, the table **NResource** serves as the main table for NEXUS resource records with primary key **ResourcelidKey** (an integer identifier) for the related records connected in a one-to-many relationship via foreign keys **ResourcelidRef** in each of the dependent tables **NTagAndLabel**, **NLocation**, **NCrossReference**, **NSupportingTag**, **NSupportingLabel**, **NSecondaryRegistry**, and **NSecondaryDirectory**. With the column ordering for the main table **NResource** as displayed in Figure 5, note that the fields displayed above the primary key **ResourcelidKey** are entity metadata fields whereas those displayed below the primary key are first the record metadata fields and then the infoset metadata fields. Because of the conceptual distinctions between the different kinds of metadata and the different ways that the metadata can be used, providing distinct keys for the different subsets of metadata offers greater convenience for various usage interface and programming contexts. The primary key **ResourcelidKey** is intended mostly for internal use with the foreign keys **ResourcelidRef** by the database to maintain the master-detail relationships between the main and dependent tables for the virtual record created for each resource. All other keys visible as explicit fields in the main table **NResource** of Figure 5 are considered optional: **EntityHidKey** is a T-SQL hierarchical identifier for the entity, **RecordHandle** is a character string identifier for the record, and **InfosetGuidKey** is a T-SQL globally unique identifier for the infoset. Technically, the PDS design specification requires only the resource label as the globally unique identifier for the resource metadata record. Although not visible as an explicit field, it is available as the **EntityCanonicalLabel** from a T-SQL view on the related tables **NResource** and **NTagAndLabel**.