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. It’s used to describe how the information represented in the DIV-2 “Logical Data Model” is actually implemented.

Guide: DoDAF Architecture Framework Version 2.02 – Page 137

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.

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.

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.

	DoDAF Viewpoint Matrix
AV	1	2
CV	1	2	3	4	5	6	7
DIV	1	2	3
OV	1	2	3	4	5a	5b	6a	6b	6c
PV	1	2	3
SvcV	1	2	3a	3b	4	5	6	7	8	9	10a	10b	10c
StdV	1	2
SV	1	2	3	4	5a	5b	6	7	8	9	10a	10b	10c

AcqTips:  

• The DoDAF descriptions in this website are very generic and are mostly taken from the DoDAF Architecture Framework website. Make sure you visit the actual website for the most update information and a more thorough explanation of each viewpoint.
• DoDAF Version 1.0, although outdated, has some good examples on how to construct AV’s, OV’s, and SV’s.

AcqLinks and References:

• [1] DoDAF Architecture Framework Version 2.02
• DoD Architecture Framework Working Group Version 1.0, Volume 1: Definition and Guideline, 9 Feb 04 (Old Version)
• DoD Architecture Framework Version 1.0, Volume 2: Product Description, 9 Feb 04 (Old Version)
• Website: DoDAF Architecture Framework – DoD Deputy Chief Information Officer
• Website: DoDAF Version 2.02 Journal

Updated: 6/26/2018