| December 2001 | ||
|
NPDM
|
||
| version 4.10 |
The NATO Product Data Model (NPDM) Version 4.10 defines at the conceptual level an information architecture for life cycle defense system support. For a consistent implementation of the conceptual model across NATO, a relational model was deemed necessary. These Implementation Guidelines (IGs) describe the relational model developed from the conceptual model (NPDM) and illustrate how specific application functionality is supported by the data elements defined in the physical model.
The IGs
have been developed by the NATO CALS Office (NCO) under the guidance of
the NATO CALS Management Board (NCMB) with contributions from Association
GOSET, France and Eurostep Limited, United Kingdom. Intellectual Property
Rights (IPR) for this document are owned by NATO. The NATO CALS Office
grants permission to print or otherwise reproduce this material for internal
use only and under the conditions that it will remain unchanged and that
ownership by the NCO is recognised. This document may not be copied for
sale or profit.
This document provides
a guideline for the implementation of the NATO Product Data Model in a
relational database. There is no single ideal
solution to the problem of how
to translate the Express Conceptual Data Model to the Relational Model.
In general, a pragmatic approach has been followed, and consistency has
sometimes been sacrificed in favour of finding the most practical solution
in individual cases. It should be noted that while a consistent approach
could lend itself to the automated generation of relational structures
from EXPRESS models, a consistent approach does not necessarily generate
the optimum solution for each particular situation.
With respect to keys, a consistent approach has been followed throughout the implementation guidelines. The keys labelled as "primary keys" ("PKs") in the IDEF1X diagrams are arbitrary long integers used throughout the relational implementation for linking tables. These keys are indexed, unique, and the bearers of referential integrity in the relational implementation. Even tables that are not referenced by other tables included within the scope of the current implementation guidelines are provided with linking keys for the sake of consistency. All foreign keys labelled as "foreign keys" ("FKs") in the IDEF1X diagrams are therefore also implemented as long integers. The keys labelled as alternate keys ("AKs") in the IDEF1X diagrams provide the logical keys for each table. Where a single logical key exists for an entity, this key is indexed and unique in the relational implementation. Where more than one logical key exists for a table, the collection of keys for that table is indexed and unique. The essential issue is that there is one set of unique (logical) keys which are the true identifiers for each record and one set of unique (arbitrary) keys used for linking within a particular implementation.
There is no ideal solution to the problem of how to best implement EXPRESS subtype / supertype trees in a relational structure. None of the trees in the NPDM exhibit multiple parenthood, but some exhibit ANDOR subtyping. There are four general approaches to the inheritance problem:
i) upward migration of attributes to a table with fields corresponding to all the attributes of the supertypes and all the attributes of the various subtypes.
ii) downward migration of attributes from any supertypes to all the classes specified by the various subtypes and the creation of tables corresponding to those classes - plus (if necessary) the creation of tables corresponding to any non-abstract supertypes.
iii) no migration of attributes, the creation of tables for each of the relevant classes (as in "ii"), and the creation of additional FKs (for each table corresponding to the subtype classes) that refer to the linking key of the supertype.
iv) hybrid solution using any of the above.
In some cases, entities in a subtype / supertype tree can simply be abolished without affecting the integrity or the data handling properties of the model - although, strictly speaking, the semantics of the model are affected in such cases.
There are advantages and disadvantages embodied in each of these general approaches and a mixture of approaches has been used in these guidelines.
For instance, the partial "collapsing" of the product_definition_relationship tree has resulted in the creation of a table corresponding to product_definition_relationship; a table corresponding to assembly_component_usage that inherits all the attributes of product_definition_relationship; a table corresponding to specified_higher_usage_occurrence that references its assembly_component_usage parent with an additional FK and provides an intersection between two instances of its parent; no table corresponding to the product_definition_usage entity; and no table corresponding to the next_assembly_usage_occurrence entity (the last two entities in this list having no attributes of their own).
In the same tree, no table is created that corresponds to the subtype represented by the quantified_assembly_component_usage entity, and, instead, this entity serves as the basis of an intersection table between assembly_component_usage and measure_with_unit. Similarly, in the product_category tree, the product_related_product_category entity serves as the basis of an intersection table between product_category and product. The product_definition entity is abolished and its entities migrated down to its two product_design_definition and breakdown subtypes. Similarly, the element_relationship is abolished, and its attributes migrated down to the sub_element_relationship subtype.
Wherever these occur in the original EXPRESS - in the form of aggregate relationships between entities - intersection entities have been generated. This has resulted in the creation, for example, of publication_issue_to_organization_link and breakdown_to_element_link entities - and corresponding tables - that normalize the relationships between publication_issue and organization, and breakdown and element respectively.
Two general approaches have been used to implement select types:
i) The Express Select Types are implemented as tables. Where select types reference simple data types, these have been implemented as non-mandatory fields within the select table. Where select types reference other entities, these references have been implemented as non-mandatory fields within the select table holding FKs for the relevant tables. The EXPRESS requirement that one and only one choice be permitted shall always be enforced in the relational implementation.
ii) One intersection table is created for each element in the select type.
Some EXPRESS constructs - such as the constellation of selects, enumerations and entity data types that record element and breakdown types within the NPDM - have been simplified. Distinctions between "standard" and "non-standard" breakdowns have therefore been lost. Similarly for "standard" and "non-standard" elements. The justification here is that the distinctions concerned were arbitrary and artificial and that the revised structure enables users to record all the data anticipated by the EXPRESS modellers (for breakdown and element) in a simpler relational model. This approach does, however, represent a departure from the original EXPRESS.
Examples
click on the file name to download the zip file
|
FILE
|
SIZE
|
APPLICATION
|
DESCRIPTION
|
| bom.zip | 27KB | Power Point 97 | This PPT presentation compares Part 21 and the Relational Database solution for product structure. The example is based on a very simple assembly and explains how product_definition_relationship, assembly_component_usage, next_assembly_usage_occurrence and specified_higher_usage_occurrence entities are implemented in the Relational Database. View the presentation in 'slide view' mode to see the animations. |
| nsn.zip | 22KB | Power Point 97 |
This example explains how the Relational Database supports the NATO Codification System (NCS) classification structure (e.g. Group, Classes, Item Names) and which relational tables are used to assign NSNs to products. View the presentation in 'slide view' mode to see the animations. |
| text_select.zip | 641KB | MS Access 97 | This is an MS Access database showing how the EXPRESS select type 'text_select' is implemented in a relational table. Three tables, one query and one form are used for this very simple example. Open the form and click on the record navigator the see the results. |
Document Description - The Physical Model
The document that is opened by Selecting an Express Entity in the Physical Model window is structured in sections A through G.
Section A contains the definition of the entity and the attributes as defined in the conceptual model:
Section B contains the Express syntax as defined in the conceptual model:
:
Section C displays the relational diagram (IDEF-1X) and the table implemented from the Express sintax:
Section D contains the description of the relational implementation in terms of tables and provides the applicable business rules:
Section E lists the entites that have a relationship with the entity in focus:
Section F presents alternatively a MS Access relational diagram or an example of data population:
Section G provides data type, data size and applicable rules for each attribute in the table:
Document Description - The Functional Viewpoint
Each identified functionality is documented in a single HTML file with sections A through C.
Section A contains a generic description of the functionality:
Section B provides the business rules for the functionality:
In Section C the function in focus is decomposed in elementary sub-functions and links are provided for nested functions and for the supporting data elements:
|
Implementation Guidelines Custodian |
|
Boye
Tranum |