Figure As.04d – Association Meta-Model Physical Database

<font color="#29313b">In the section on meta-modeling subclasses and attributes, an important point was made for SID implementer’s who choose to take this approach. It is no longer necessary to use the repeated applications of the Characteristic pattern in the existing SID model or directly relating existing SID entities to characteristic “use” entities. This is demonstrated in Figure As.04d – Full Meta-Model Including Characteristics. For example, the Base Station Controller instance of CompoundResourceSpecification can be stored as an instance of RootEntityType; instances of CharacteristicSpecifications can be related to it by creating instances of RootEntityTypeCharUse.</font><br/><font color="#29313b">Figure As.04d – Association Meta-Model Physical Database shows the database.</font><br/><font color="#29313b">The transformation from the information model to the data model rolled down the two association specification entities. Therefore they are not included in the data model, but their attributes are. An additional database consideration is that an index could be added on the “name” attribute. This would provide a way to search for association specifications for an instance of a RootEntityType. If necessary, an index on “name” could also be added to the AssociationRole table, if the “name” column from the AssocationRoleSpecification table is added to it.</font><br/><font color="#29313b">A non-unique index on the “name” attribute of RootEntityType could be added. By doing this, instances of RootEntityType can be easily accessed when adding new attributes and/or associations to it.</font><br/><font color="#29313b">An attribute most likely also should be added to RootEntityType, and possibly RootEntity, and would indicate if an instance is a “true” dynamic entity.  These entities are not contained in the database generated from SID entities or that contains implied subclasses in the database. The attribute(s) could be added to the information model, rather than the data model. The addition would make finding instances of these dynamically added entities easier, particularly when dealing with (adding/updating/deleting/retrieving) instances of RootEntity.</font><br/><font color="#29313b">The keys of the Root entities should be stored in instances of SID entities. This would provide an indication that the entities have been extended. The keys of both RootEntityType and RootEntity should be stored in instances of SID implied subclasses. This is done because both the implied subclass and its superclass may have both been dynamically extended. For example, the ProductSpecification entity itself may have been dynamically extended, from which the implied subclasses of it inherit.</font><br/><font color="#29313b">The meta-model database can be deployed by application or domain to avoid any possible performance issues. However, dynamically added cross domain associations need to be considered when doing this.</font><br/><font color="#29313b">One final point about implementing a meta-model is that dynamically added entities and their subtypes, associations, and attributes should be considered for explicit modeling at some point in time. Their stability should be a consideration for determining when this should be done.</font><br/>