DoDAF Viewpoints and Models
Data and Information Viewpoint
DIV-3: Physical Data Model
The DIV-3 defines the structure of the various kinds of system or service data that are utilized by the systems or services in the Architectural Description. The Physical Schema is one of the models closest to actual system design in DoDAF. DIV-3 is used to describe how the information represented in the DIV-2 Logical Data Model is actually implemented.
While the mapping between the logical and physical data models is relatively straightforward, the relationship between the components of each model (e.g., entity types in the logical model versus relational tables in the physical model) is frequently one-to-many or many-to-many.
The intended usage of the DIV-3 includes:
- Specifying the system/service data elements exchanged between systems and/or services, thus reducing the risk of interoperability errors.
- Definition of physical data structure.
- Providing as much detail as possible on data elements exchanged between systems, thus reducing the risk of interoperability problems.
- Providing data structures for use in the system design process, if necessary.
- Providing a common dictionary of data implementation elements (e.g., tables and records in a relational database schema) to consistently express models wherever physical-level data elements are included in the descriptions.
- Providing as much detail as possible on the system or service data elements exchanged between systems, thus reducing the risk of interfacing errors.
- Providing system and service data structures for use in the system and service design process, if necessary.
Note that DoDAF talks about information in the Operational Viewpoint and data in the System Viewpoint or Services Viewpoint. The intention of this distinction is that DIV-2 Logical Data Model describes information of importance to the business, (e.g., information products that might be referred to in doctrine, SOPs etc.) whereas DIV-3 describes data relevant at the system or service-level.
Detailed Description:
The DIV-3 is an implementation-oriented model that is used in the Systems Viewpoint and Services Viewpoint to describe how the information requirements represented in DIV-2 Logical Data Model are actually implemented. Entities represent:
- System Resource flows in SV-4 Systems Functionality Description.
- System Resource elements specified in SV-6 Systems Resource Flow Matrix and SV-10c Systems Event-Trace Description.
- Service Resource flows in SvcV-4 Services Functionality Description.
- Service Resource elements specified in SvcV-6 Services Resource Flow Matrix and SvcV-10c Services Event-Trace Description.
- Triggering events in SV-10b Systems State Transition Description or SvcV-10b Services State Transition Description.
- Events in SV-10c Systems Event-Trace Description or SvcV-10c Services Event-Trace Description.
- Elements required due to Standards in the StdV-1 Standards Profile or StdV-2 Standards Forecast.
For some purposes, an Entity relationship style diagram of the physical database design is sufficient. References to message format standards may be sufficient for message-oriented implementations. Descriptions of file formats may be used when file passing is the model used to exchange information. Interoperating systems may use a variety of techniques to exchange system data and have several distinct partitions in their DIV-3 with each partition using a different form.
Standards associated with entities are also often identified in the development of the DIV-3; these should be recorded in the StdV-1 Standards Profile. Structural Assertions - these involve static aspects of business rules - are best captured in the DIV-3.
Possible Construction Methods: DoDAF does not endorse a specific data modeling methodology. The physical data schema model specifies how the logical data model will be instantiated. The most predominant are the relational database management systems and object repository products. In addition, this model may employ other technology mechanisms, such as messages or flat files. The essential elements of a physical data schema model (in the case of a relational database) are: tables, records and keys. In an object-oriented data model, all data elements are expressed as objects; whether they are classes, instances, attributes, relationships, or events.
The appropriate way to develop a physical data model depends on the product chosen to instantiate the logical data model (e.g., a relational database management system [RDBMS]). A physical data schema model seems best described using an entity-relationship diagramming technique. For Object-Oriented data modeling, a physical data schema seems best described using by Class and/or Object diagrams. For other implementation technologies, such as message orientation, a reference to a message format standard might be more appropriate.
DIV-1: Conceptual Data Model
DIV-2: Logical Data Model
DIV-3: Physical Data Model