THE JOINT C3 INFORMATION EXCHANGE DATA MODEL Metamodel ... Document... · THE JOINT C3 INFORMATION EXCHANGE DATA MODEL Metamodel (JC3IEDM Metamodel) 14 Feb 2012, Greding, Germany

JC3IEDM - Metamodel - IPT3

V3.1.4

MULTILATERAL INTEROPERABILITY PROGRAMME (MIP)

THE JOINT C3 INFORMATION EXCHANGE

DATA MODEL Metamodel

(JC3IEDM Metamodel)

14 Feb 2012, Greding, Germany This Multilateral Interoperability Programme (MIP) Technical Interface Design Plan has

been reviewed and is hereby approved by the Heads of Delegation of participating nations.

Release of this document to nations or agencies, who are not participants in the

Multilateral Interoperability Programme including the media and general public, require

the approval of the MIP Steering Group (MSG) in accordance with policy stated in the

MIP Communications and Liaison Plan (MCLiP). This document is the property of the

MIP participants and the information contained in this document shall not be

communicated, either directly or indirectly, to any person or agency not authorised to

receive it.


V3.1.4

ii

RECORD OF CHANGES PAGE

CP Number Date Entered Responsible

Individual Remarks

CP_MIP31_33001_Errors

in JC3IEDM_JC3IEDM-v2 8 March 2011 Mike Morris

Fix Editorial issues for

3.1.1


V3.1.4

iii

CONTENTS

1. Introduction ........................................................................................................................1

1.1 Technical Specification of JC3IEDM Metamodel ...............................................................1

2. JC3IEDM Metamodel Overview ......................................................................................2

2.1 Introduction ..........................................................................................................................2

3. JC3IEDM Metamodel .......................................................................................................3

3.1 Technical Descriptions of Entities in the metamodel ..........................................................3

3.2 ENTITY ...............................................................................................................................3

3.3 ATTRIBUTE .......................................................................................................................5

3.4 Unification of Foreign Key Attributes ...............................................................................15

3.5 Alternate Key View ...........................................................................................................15

3.6 Entity Relationships ...........................................................................................................18

3.7 DOMAIN ...........................................................................................................................25

3.8 Business Rules ...................................................................................................................29

3.9 CREATOR-UPDATE-IDENTIFICATION ......................................................................35

4. JC3IEDM CONCEPTS AND PHYSICAL SPECIFICATIONS FOR THE

JC3IEDM MODEL ..........................................................................................................37

4.1 Metamodel CONCEPTS ....................................................................................................37

4.2 Physical Abbreviations ......................................................................................................39

Annexes

Annex A: JC3IEDM Metamodel—Glossary

Annex B: JC3IEDM Metamodel—Entity Definitions and Attributes

Annex C: JC3IEDM Metamodel—Attribute Definitions

Annex D: JC3IEDM Metamodel—Entity Relationships

Annex E: JC3IEDM Metamodel—Specifications of Enumerated Domains

Annex F: JC3IEDM Metamodel—Specification of Physical Domains

Annex G: JC3IEDM Metamodel—Compendium of Business Rules

Annex H: JC3IEDM Metamodel—Naming Conventions and Class Words

Annex I: Summary of IDef1X Data Modelling Methodology and Notation

Annex J: References

Annex K: JC3IEDM Metamodel—IDef1X Logical Data Model Diagram

Annex L: JC3IEDM Metamodel—IDef1X Physical Data Model Diagram


V3.1.4

iv

LIST OF FIGURES

Figure 1. Attribute View .................................................................................................................. 8

Figure 2. Alternate Key View ....................................................................................................... 16

Figure 3. Category Relationship View .......................................................................................... 18

Figure 4. Relationship View .......................................................................................................... 20

Figure 5. Domain View ................................................................................................................. 25

Figure 6. Business Rule View ....................................................................................................... 30

Figure 7. Creator Update Identification View ............................................................................... 35


V3.1.4

v

LIST OF TABLES

Table 1. Instance Table for ENTITY............................................................................................... 4

Table 2. Instance Table for ATTRIBUTE ....................................................................................... 7

Table 3. Instance Table for PRIMARY-KEY-ATTRIBUTE .......................................................... 9

Table 4. Instance Table for NON-KEY-ATTRIBUTE ................................................................. 10

Table 5. Instance Table for BASE-ATTRIBUTE ......................................................................... 11

Table 6. Instance Table for FOREIGN-KEY-ATTRIBUTE ......................................................... 14

Table 7. Instance Table for ALTERNATE-KEY .......................................................................... 17

Table 8. Instance Table for ALTERNATE-KEY-ATTRIBUTE .................................................. 18

Table 9. Instance Table for CATEGORY-RELATIONSHIP ....................................................... 19

Table 10. Instance Table for RELATIONSHIP ............................................................................ 21

Table 11. Instance Table for CARDINALITY-RELATIONSHIP ................................................ 23

Table 12. Instance Table for SUBTYPE-RELATIONSHIP ......................................................... 24

Table 13. Instance Table for DOMAIN ......................................................................................... 27

Table 14. Instance Table for DOMAIN-VALUE .......................................................................... 29

Table 15. Instance Table for BUSINESS-RULE .......................................................................... 31

Table 16. Instance Table for BUSINESS-RULE-ENTITY ........................................................... 32

Table 17. Instance Table for BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE ........... 33

Table 18. Instance Table for BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE-DOMAIN-VALUE

.................................................................................................................................... 34

Table 19. Instance Table for CREATOR-UPDATE-IDENTIFICATION .................................... 36

Table 20. Class Word Abbreviations ............................................................................................. 39

Table 21. JC3IEDM Metamodel Logical Term Abbreviations ..................................................... 39


V3.1.4

1

1. Introduction

1.1 Technical Specification of JC3IEDM Metamodel

1.1.1 General

1.1.1.1 The purpose of this document is to define the concepts behind the

metamodel and their relationships and also to discuss in technical detail the models that

will form the context for stating the specification. The entire Joint Consultation, Command,

and Control Information Exchange Data Model (JC3IEDM) metamodel is shown in a

separately maintained specification.

1.1.1.2 This document contains material on both concepts and models that will

ultimately be national implementation issues. This apparent redundancy is necessary to put

the metamodel in perspective, to define the relationships, and to decide the exact

boundaries and interfaces between national and international issues. When required,

national functionality will be explicitly identified.

1.1.1.3 Papers developed by the NATO Data Management Services Working Group

(DMSWG), formerly the (Data Administration Group (NDAG)) and the Data Modelling

Working Group (DMWG) cover the operational interoperability requirements for data

content, that is, the agreements for specifying meaning and relationships of information

subject to multinational exchange. These papers form the basis for the specification of the

metamodel.

1.1.1.4 If there are differences between this document and the MIP Information

Resource Dictionary (MIRD), the MIRD takes precedence.

1.1.1.5 The rest of this paper covers the following:

a. Chapter 1 - Introduction.

b. Chapter 2 - Overview of the JC3IEDM metamodel and its concepts.

c. Chapter 3 - Technical specifications for the entities and attributes of the JC3IEDM

metamodel.

d. Chapter 4 - Physical specifications for the entities and attributes of the JC3IEDM

metamodel.

1.1.1.6 The following annexes provide detailed technical model documentation:

a. Annex A—Glossary.

b. Annex B/C/D/E—Entity definitions, entity relationships, attribute definitions,

definitions of logical and physical enumerated domains and Other domains.1

c. Annex G—Compendium of Business Rules.

d. Annex H/I/J—Class Words, IDef1X Methodology and References.

e. Annex K/L—Logical and Physical representations of the JC3IEDM Metamodel.

1 The specifications contained in these annexes correspond to those stored in the ERwin Version 4.1.4

SP3 ER1 file. Every attempt has been made to ensure that the specifications in the annexes reflected

accurately the specifications in the ER1 file. In case of a difference, the specifications in MIRD file take

precedence.


V3.1.4

2

2. JC3IEDM Metamodel Overview

2.1 Introduction

2.1.1 Any implementation of the JC3IEDM will depend on an underlying MIP

Information Resource Dictionary database. Information about the JC3IEDM and the

JC3IEDM metamodel entities, attributes, etc., are stored in this database and enable the

JC3IEDM processes to determine, under dynamic user-imposed constraints, what to

replicate and how. An entity-attribute-relationship view of the structure of this MIP

Information Resource Dictionary database is given in a JC3IEDM metamodel.

2.1.2 The MIP Information Resource Dictionary (MIRD) describes all relevant

metadata for MIP. Among other things, it contains information about the JC3IEDM and the

JC3IEDM metamodel. The JC3IEDM metamodel has only one main view that is the set of

logically related entities.

2.1.3 This model is representing the metadata information that underlies the

JC3IEDM model and its metamodel. This view includes data describing entities/tables,

attributes/columns, relationships and domain values.

2.1.4 The ERwin logical and physical views of the metamodel are shown in

Annex K and Annex L.


V3.1.4

3

3. JC3IEDM Metamodel

3.1 Technical Descriptions of Entities in the metamodel

This section provides the definitions and instance tables for the entities in the

JC3IEDM metamodel. The metamodel diagram is presented in Annex K.

3.2 ENTITY

3.2.1 ENTITY

3.2.1.1 An ENTITY is part of the data model that describes the structure of MIP

operational information. An ENTITY is defined as ‘A record that specifies the metadata

characteristics of an entity from a data model for which metadata is being recorded.’ In the

metamodel, ENTITY is fully defined through all of its associations with other elements of

the metamodel.

3.2.1.2 Every entity has a name (which must be unique) as well as a table name

(which again uniquely identifies the entity). The table name is a shortened entity name that

will be used when the data model is implemented into a database and each instance of

ENTITY becomes a physical database table. The “entity-dependency-code” indicates

whether it is a non-subtype dependent entity, a subtype entity, or an independent entity.

3.2.1.3 There exists a one-to-one relationship between JC3IEDM entities and

JC3IEDM tables. For that reason, all table properties are included in the ENTITY entity.

3.2.1.4 The attributes of ENTITY are the following:

a. entity-id—The unique value, or set of characters, assigned to represent a specific

ENTITY and to distinguish it from all other ENTITYs.

b. entity-name-text—The character string assigned to represent a specific ENTITY.

c. entity-table-name-text—The character string assigned to represent the physical table

or other object of a physical schema that represents data specified for a specific

ENTITY.

d. entity-definition-text—The character string assigned to represent the definition of

what the entity is.

e. entity-dependency-code—The specific value that represents whether the ENTITY is

independent for its meaning and instances from all other instance of ENTITY. The

domain values are: Dependent Entity; Independent Entity; Subtype Entity.

f. entity-depth-count—The integer value representing the specification of the level of

dependency of the entity or maximum number of parent entities "above" the entity

itself.

g. entity-storage-type-code—The specific value that represents whether the ENTITY is

standard (non-loggable) or loggable. The domain values are: Loggable; Standard.

h. entity-standardisation-level-code—The specific value that represents the level of

common agreement for the ENTITY. The domain values are: International; Local;

National; MIP Core; MIP-NATO Data Administration; Multilateral Interoperability


V3.1.4

4

Programme. The domain value set for this attribute is shared with one or more other

attributes and is defined in the set standardisation-level-code.

i. entity-model-level-code—The specific value that represents the data model source of

the ENTITY being represented. The domain values are: Application; Metamodel;

Dictionary. The domain value set for this attribute is shared with one or more other

attributes and is defined in the set model-level-code.

3.2.1.5 The entity-storage-type-code attribute indicates whether an instance has

been specified in the implementation guidance as “loggable.” All current entities in the

JC3IEDM are considered “loggable”.

3.2.1.6 The table below is an example instance table for ENTITY.

Table 1. Instance Table for ENTITY

***-id

***-name-text

***-table-name-text

***-dependency-code

***-depth-count

***-storage-type-code

10000003 ACTION ACT IE 0 LOG

10000063 LOCATION LOC IE 0 LOG

10000076 OBJECT-ITEM OBJ_TEM IE 0 LOG

10000080 OBJECT-ITEM-STATUS OBJ_ITEM_STAT DE 3 LOG

10000082 OBJECT-TYPE OBJ_TYPE IE 0 LOG

10000085 ORGANISATION ORG SE 1 LOG

10000104 PERSON-TYPE PERS_TYPE SE 1 LOG

10000128 UNIT UNIT SE 2 LOG

Note: Not shown in the instance table are the attributes ***-definition-text, ***-standardisation-level-code, and ***-model-level-code.

Note: *** = “entity” Note: The values in the ***-dependency-code, and ***-storage-type-code are defined in Annex E.

Note: The value in the ***-depth-count is explained in Annex G.

3.2.1.7 The attribute entity-depth-count defines the order in which parent-to-

dependent children are related. An example is found in Annex G.

a. The values of entity-depth-count are not unique; instead, they partially order the

JC3IEDM and metamodel entities. The lowest entity-depth-count identifies the

independent entities for which none is the child of a non-identifying relationship.2

The following examples illustrate the entity-depth-count:

1) Each independent entity that is not the child of any non-identifying relationship

(e.g., OBJECT-TYPE, OBJECT-ITEM, ACTION, LOCATION) has entity-

depth-count of 0.

2) Each subtype of an independent entity (PERSON-TYPE, ORGANISATION-

TYPE, ORGANISATION) that is not the child of any non-identifying

relationship has entity-depth-count of 1.

3) A subtype or child of an entity with entity-depth-count 1 (e.g., UNIT) is of

entity-depth-count 2 if that entity is not the child of another relationship with

another entity.

b. The sequence (lowest to highest) defines the order in which tables would have to be

produced to ensure that no referential integrity violations occurred. For example, all

instances of entities at the lowest value (e.g., “0”) of entity-depth-count would have

2 By definition, an independent entity cannot be the child of an identifying relationship.


V3.1.4

5

to be produced before creating instances of entities at the next lowest value (e.g.,

“1”).

c. The order would be reversed (highest to lowest) if deletions were to be performed.

For example, all instances of entities at the highest value (e.g., “5”) of entity-depth-

count would have to be deleted before deleting instances of entities at the next lowest

value (e.g., “4”).

3.2.1.8 The “model-level-code” is used to describe the type of entity being

represented. The domain values for the attribute entity-model-level-code are: “APPL” is

used to distinguish JC3 application (JC3IEDM) entities; “META” identifies a metamodel

entity and “DICT”3 distinguishes management entities.

3.2.1.9 The specification for JC3IEDM and the JC3IEDM Metamodel has to ensure

that entity keys are not reused. If the semantic understanding of an existing entity has

changed, then a new key should be generated for that entity. It is expected that no new

identifier with a value less than the highest used identifier (+ 1) will ever be used.

3.3 ATTRIBUTE

3.3.1 ATTRIBUTE

3.3.1.1 An ATTRIBUTE is a record that specifies the metadata characteristics of an

attribute for an entity that is described in a specific ENTITY. It is defined as ‘A record that

specifies the metadata characteristics of an attribute for an entity that is described in a

specific ENTITY.’ The attribute structure is shown in Figure 1.

3.3.1.2 An entity is described by one or more attributes, captured by ATTRIBUTE.

Because an attribute only exists within the context of its hosting entity, an attribute is

identified by both an “entity-id” and an “attribute-index.” The attribute index denotes an

index number that uniquely distinguishes the attribute from other attributes in the same

entity. The attribute-sequence-number-ordinal indicates the position of an attribute inside

the enclosing entity. The ordering of attributes is important for the exchange of information

using the JC3IEDM.

3.3.1.3 Attributes are described by a name, which is the name that appears in the

IDEF1X metamodel diagram (i.e., usually the complete attribute name, but when the

attribute is renamed its role name is stored here), a column name for implementation

purposes, an indicator that distinguishes between primary key and non-key attributes, and

another indicator that distinguishes between foreign key and base attributes.

3.3.1.4 As for the index, both the attribute name and the column name must be

unique within an entity. Unified attributes, which are not displayed in the diagram, are

stored as normal attributes. Since unification is based upon equality of attribute names, the

uniqueness of attribute (and column) names is violated only in this case. In addition, the

attribute-sequence-number-ordinal value of the unified attributes is set to the same value as

the attribute-sequence-number-ordinal value with which it unifies. An example of the

unification of attributes is shown in Table 2 below. The last attribute in the table unifies

with the first attribute in the table, therefore the attribute-sequence-number-ordinal value

(1) of the last attribute is set to the same value (1) as the first attribute.

3 The value “DICT” is not currently in use for the JC3IEDM model and the JC3IEDM Metamodel.


V3.1.4

6

3.3.1.5 An ATTRIBUTE is identified by an entity-id (FK – Foreign Key) and by an

attribute-index that distinguishes instances of ATTRIBUTE for the same ENTITY. The

attributes of ATTRIBUTE are the following:



b. attribute-index—The unique value, or set of characters, assigned to represent a

specific ATTRIBUTE for a specific ENTITY and to distinguish it from all other

ATTRIBUTEs for that ENTITY.

c. attribute-name-text—The character string assigned to represent a specific attribute.

d. attribute-column-name-text—The character string assigned to represent the

ATTRIBUTE as a specific physical column within a table.

e. attribute-sequence-number-ordinal—The integer value that represents the specific

physical position of the attribute inside the entity.

f. attribute-primary-key-indicator-code—The specific value that denotes whether an

ATTRIBUTE plays the role of part of the primary key in the ENTITY to which it

belongs. The domain values are: NON-KEY-ATTRIBUTE; PRIMARY-KEY-

ATTRIBUTE.

g. attribute-foreign-key-indicator-code—The specific value that denotes whether the

ATTRIBUTE plays the role of a foreign key in the ENTITY and thereby owned by

another ENTITY. The domain values are: BASE-ATTRIBUTE; FOREIGN-KEY-

ATTRIBUTE.

h. attribute-standardisation-level-code—The specific value that represents the level of

common agreement for the ATTRIBUTE. The domain values are: International;

Local; National; MIP Core; MIP-NATO Data Administration; Multilateral

Interoperability Programme. The domain value set for this attribute is shared with

one or more other attributes and is defined in the set standardisation-level-code.

3.3.1.6 The table below is an example instance table for ATTRIBUTE.


V3.1.4

7

Table 2. Instance Table for ATTRIBUTE

entity-id (FK)

***-index

***-name-text

***-column-name-text

***-sequence-number-ordinal

***-primary-key-

indicator-code

***-foreign-key-

indicator-code

***-

standardisation-level-code

10000013 100001 action-id act_id 1 PK FK MPCO

10000013 100002 action-resource-index act_res_ix 2 PK FK MPCO

10000013 100003 action-resource-employment-index

act_res_employ_ix 3 PK BA MPCO

10000013 100004 action-resource-employment-category-code

cat_code 4 NK BA MPCO

10000013 100005 action-resource-employment-azimuth-fire-angle

azimuth_fire_angle 5 NK BA MPCO

10000013 100006 action-resource-employment-method-of-control-code

method_of_ctrl_code 6 NK BA MPCO

10000013 100007 action-resource-employment-trajectory-fire-code

trajectory_fire_code 7 NK BA MPCO

10000013 100008 action-objective-index act_objve_ix 8 NK FK MPCO

10000013 100009 physical model only creator_id 9 NK BA MPCO

10000013 100010 physical model only update_seqnr 10 NK BA MPCO

10000013 100100 action-id act_id 1 PK FK MPCO

Note: *** = “attribute”

3.3.1.7 Two sets of subtypes of ATTRIBUTE are described below and shown in the

figure below. One set distinguishes primary key attributes from non-key attributes, where

the former are used to identify unique instances of the ENTITY to which they belong, and

where the latter are used to describe aspects of that ENTITY at the data element (single

concept) level. The category discriminator for that distinction is attribute-primary-key-

indicator-code.

3.3.1.8 The other set of subtypes distinguishes owned (“base”) attributes from

attributes that occur in the ENTITY to which they belong solely because of a relationship

with another entity. The owned attributes form the subtype BASE-ATTRIBUTE, and the

others form the subtype FOREIGN-KEY-ATTRIBUTE. The category discriminator for

that distinction is attribute-foreign-key-indicator-code.


that attribute keys are not reused. If the semantic understanding of an existing attribute has

changed, then a new key should be generated for that attribute. It is expected that no new

identifier with a value less than the highest used identifier (+ 1) for attributes within an

entity will ever be used.


V3.1.4

8

attribute-foreign-key-indicator-code

attribute-primary-key-indicator-code

is-originator-for

unifies

is-source-for

ATTRIBUTE

entity-id (FK) (IE1.1,IE2.1,IE3.1)

attribute-index

attribute-name-text (IE1.2)

attribute-column-name-text (IE2.2)

attribute-sequence-number-ordinal (IE3.2)



attribute-standardisation-level-code

BASE-ATTRIBUTE

entity-id (FK)

attribute-index (FK)

base-attribute-definition-text

base-attribute-data-type-code

base-attribute-data-length-count

base-attribute-data-decimals-count

domain-id (FK)

FOREIGN-KEY-ATTRIBUTE

host-entity-id (FK)


foreign-key-attribute-role-definition-text

foreign-key-attribute-rolename-indicator-code

source-entity-id (FK)

source-attribute-index (FK)

migrating-relationship-index (FK)

base-entity-id (FK)

base-attribute-index (FK)

unifying-attribute-index (FK)NON-KEY-ATTRIBUTE

entity-id (FK)


non-key-attribute-optionality-indicator-code

PRIMARY-KEY-ATTRIBUTE

entity-id (FK)


Figure 1. Attribute View

3.3.2 PRIMARY-KEY-ATTRIBUTE

3.3.2.1 PRIMARY-KEY-ATTRIBUTE is a subtype of ATTRIBUTE under the

category discriminator attribute-primary-key-indicator-code. PRIMARY-KEY-

ATTRIBUTE is defined as ‘An ATTRIBUTE used to provide the unique identifier(s) of an

instance of the ENTITY to which the attributes belong.’ The PRIMARY-KEY-

ATTRIBUTE structure in shown in the figure above.

3.3.2.2 A PRIMARY-KEY-ATTRIBUTE is identified by the primary key

attributes, entity-id (FK) and attribute-index (FK) that migrate to PRIMARY-KEY-

ATTRIBUTE from the category (subtype) relationship from ATTRIBUTE. The attributes

of PRIMARY-KEY-ATTRIBUTE are the following:






3.3.2.3 The table below is an example instance table for PRIMARY-KEY-

ATTRIBUTE.


V3.1.4

9

Table 3. Instance Table for PRIMARY-KEY-ATTRIBUTE

entity-id (FK) attribute-index (FK)

10000002(ABSOLUTE-POINT) 100001(absolute-point-id)

10000027(CONE-VOLUME) 100001(cone-volume-id)

10000227(RELATIVE-COORDINATE-SYSTEM)

100001(relative-coordinate-system-id)

10000214(CORRIDOR-AREA) 100001(corridor-area-id)

10000215(ELLIPSE) 100001(ellipse-id)

10000048(FAN-AREA) 100001(fan-area-id)

10000055(GEOMETRIC-VOLUME) 100001(geometric-volume-id)

10000061(LINE) 100001(line-id)

10000062(LINE-POINT) 100001(line-id)

10000062(LINE-POINT) 100002(line-point-index

10000063(LOCATION) 100001(location-id)

10000228(OBJECT-REFERENCE) 100001(relative-coordinate-system-id)

10000216(ORBIT-AREA) 100001(orbit-area-id)

10000105(POINT) 100001(point-id)

10000229(POINT-REFERENCE) 100001(relative-coordinate-system-id)

10000217(POLYARC-AREA) 100001(polyarc-area-id)

10000218(POLYGON-AREA) 100001(polygon-area-id)

10000111(RELATIVE-POINT) 100001(relative-point-id)

10000219(SPHERE-VOLUME) 100001(sphere-volume-id)

10000119(SURFACE) 100001(surface-id)

10000220(SURFACE-VOLUME) 100001(surface-volume-id)

10000221(TRACK-AREA) 100001(track-area-id)

10000222(VERTICAL-DISTANCE) 100001(vertical-distance-id)

3.3.3 NON-KEY-ATTRIBUTE

3.3.3.1 NON-KEY-ATTRIBUTE is a subtype of ATTRIBUTE under the category

discriminator attribute-primary-key-indicator-code. NON-KEY-ATTRIBUTE is defined as

‘An ATTRIBUTE used to provide a descriptive data element of instances of the ENTITY

to which the ATTRIBUTE belongs and that is not a member of the primary key of that

ENTITY.’ The NON-KEY-ATTRIBUTE structure in shown in Figure 1 above.

3.3.3.2 A NON-KEY-ATTRIBUTE is identified by the primary key attributes,

entity-id (FK) and attribute-index (FK) that migrate to NON-KEY-ATTRIBUTE from the

category (subtype) relationship from ATTRIBUTE. The attributes of NON-KEY-

ATTRIBUTE are the following:






c. non-key-attribute-optionality-indicator-code—The specific value that represents

whether non-null domain value is required for a NON-KEY-ATTRIBUTE. The

domain values are: Mandatory; Optional.

3.3.3.3 The table below is an example instance table for NON-KEY-ATTRIBUTE.


V3.1.4

10

Table 4. Instance Table for NON-KEY-ATTRIBUTE

entity-id (FK)


non-key-attribute- optionality-indicator-code

10000282(GEOGRAPHIC-POINT)

100002(geographic-point-latitude-coordinate) MA


100003(geographic-point-longitude-coordinate) MA


100004(geographic-point-latitude-precision-code) OP


100002(relative-coordinate-system-reference-category-code)

MA

10000062(LINE-POINT) 100003(line-point-sequence-ordinal) MA

10000063(LOCATION) 100002(location-category-code) MA

10000105(POINT) 100002(point-category-code) MA

10000217(POLYARC-AREA) 100002(polyarc-area-begin-bearing-angle) MA

10000217(POLYARC-AREA) 100003(polyarc-area-end-bearing-angle) MA

10000217(POLYARC-AREA) 100004(polyarc-area-arc-radius-dimension) MA

10000111(RELATIVE-POINT) 100002(relative-point-x-coordinate-dimension) MA

10000111(RELATIVE-POINT) 100003(relative-point-y-coordinate-dimension) MA

10000111(RELATIVE-POINT) 100004(relative-point-z-coordinate-dimension) OP

10000111(RELATIVE-POINT) 100005(relative-point-x-precision-code) OP

10000111(RELATIVE-POINT) 100006(relative-point-y-precision-code) OP

3.3.4 BASE-ATTRIBUTE

3.3.4.1 BASE-ATTRIBUTE is a subtype of ATTRIBUTE under the category

discriminator attribute-foreign-key-indicator-code. BASE-ATTRIBUTE is that subset of

ATTRIBUTE owned by the ENTITY to which the members belong; that is, they are not

foreign key attributes migrating from another ENTITY under some relationship. A BASE-

ATTRIBUTE is defined as ‘An ATTRIBUTE that is native to the entity referenced by the

specific ENTITY.’ The BASE-ATTRIBUTE structure in shown in Figure 1 above.

3.3.4.2 A BASE-ATTRIBUTE is identified by the primary key attributes, entity-id

(FK) and attribute-index (FK) that migrate to BASE-ATTRIBUTE from the category

(subtype) relationship from ATTRIBUTE. The attributes of BASE-ATTRIBUTE are the

following:






c. base-attribute-definition-text—The character string assigned to represent the

definition of a specific BASE-ATTRIBUTE.

d. base-attribute-data-type-code—The specific value that represents the technical form

(datatype or syntax) for the attribute. The domain values are: Blob; Character;

Numeric; Varying character.

e. base-attribute-data-length-count—The numeric value representing the maximum

number of characters permitted for a value of the attribute.

f. base-attribute-data-decimals-count—The numeric value representing the number of

positions to the right of the decimal point for attributes that are expressed as real

numbers.


V3.1.4

11

g. domain-id—The unique value, or set of characters, assigned to represent a specific

DOMAIN and to distinguish it from all other DOMAINs. The attribute domain-id

(FK) migrates to BASE-ATTRIBUTE under the relationship “describes-allowed-

values-for” from DOMAIN.

3.3.4.3 The table below is an example instance table for BASE-ATTRIBUTE.

Table 5. Instance Table for BASE-ATTRIBUTE

entity-id (FK)


***-definition-text

***-data-type-code


100002(geographic-point-latitude-coordinate) The numeric... NUMBER


100003(geographic-point-longitude-coordinate) The numeric... NUMBER


100004(geographic-point-latitude-precision-code)

The specif... CHAR


100002(relative-coordinate-system-reference-category-code)

The specif... CHAR

10000062(LINE-POINT) 100002(line-point-index) The unique... NUMBER

10000062(LINE-POINT) 100003(line-point-sequence-ordinal) The positive... NUMBER

10000063(LOCATION) 100002(location-category-code) The specif... CHAR

10000105(POINT) 100002(point-category-code) The specif... CHAR

10000217(POLYARC-AREA) 100002(polyarc-area-begin-bearing-angle) The rotational...

NUMBER

10000217(POLYARC-AREA) 100003(polyarc-area-end-bearing-angle) The rotational...

NUMBER

10000217(POLYARC-AREA) 100004(polyarc-area-arc-radius-dimension) The one-dimensionalG

NUMBER

10000111(RELATIVE-POINT) 100002(relative-point-x-coordinate-dimension) The one-di... NUMBER

10000111(RELATIVE-POINT) 100003(relative-point-y-coordinate-dimension) The one-di... NUMBER

10000111(RELATIVE-POINT) 100004(relative-point-z-coordinate-dimension) The one-di... NUMBER

10000111(RELATIVE-POINT) 100005(relative-point-x-precision-code) The specif... CHAR

10000111(RELATIVE-POINT) 100006(relative-point-y-precision-code) The specif... CHAR

Note: *** = “base-attribute”

***-data-length-count ***-data-decimal-count domain-id

9 6 100000401

10 6 100000402

6 100004218

6 100004121

20 100001000

6 100002200

6 100000138

6 100000200

7 4 100000000

7 4 100000000

12 3 100000600

12 3 100000600

12 3 100000600

12 3 100000600

6 100004218

6 100004218

3.3.5 FOREIGN-KEY-ATTRIBUTE

3.3.5.1 FOREIGN-KEY-ATTRIBUTE is an ATTRIBUTE that has been migrated

under a RELATIONSHIP from the primary key of the “Parent” ENTITY of that

RELATIONSHIP. FOREIGN-KEY-ATTRIBUTE is defined as ‘An ATTRIBUTE that has

been migrated under a RELATIONSHIP from the primary key of the "Parent" ENTITY of

that RELATIONSHIP.’ The FOREIGN-KEY-ATTRIBUTE structure in shown in Figure 1

above.


V3.1.4

12

3.3.5.2 A FOREIGN-KEY-ATTRIBUTE is identified by the primary key attributes,

entity-id (FK) and attribute-index (FK) that migrate to FOREIGN-KEY-ATTRIBUTE from

the category (subtype) relationship from ATTRIBUTE. The attributes of FOREIGN-KEY-

ATTRIBUTE are the following:

a. host-entity-id—The entity-id that identifies the entity in which the foreign key resides

(a role name for entity-id).




c. foreign-key-attribute-role-definition-text—The character string assigned to represent

the way in which a FOREIGN-KEY-ATTRIBUTE relates to the base ENTITY.

d. foreign-key-attribute-rolename-indicator-code—The specific value that represents

whether a surrogate name is used for a migrating FOREIGN-KEY-ATTRIBUTE in

the base ENTITY. The domain values are: Migrated name; Role name.

e. source-entity-id—The entity-id that identifies the source entity for the foreign key (a

role name for entity-id). The Source ENTITY is the one from which a FOREIGN-

KEY-ATTRIBUTE migrates. The attribute name source-entity-id (FK) is a role name

for the attribute for entity-id (FK) that migrates to FOREIGN-KEY-ATTRIBUTE

under the relationship “is-source-for” from PRIMARY-KEY-ATTRIBUTE.

f. source-attribute-index—The attribute-index that identifies the source attribute for the

foreign key (a role name for attribute-index). The attribute source-attribute-index

(FK) is a role name for the attribute for attribute-index (FK) that migrates to

FOREIGN-KEY-ATTRIBUTE under the relationship “is-source-for” from

PRIMARY-KEY-ATTRIBUTE.

g. migrating-relationship-index—The relationship-index that identifies the instance of

the migration of the foreign key (a role name for relationship-index). The identifier of

a RELATIONSHIP, for a specific “Child” ENTITY and a specific “Parent” ENTITY,

under which the instance of FOREIGN-KEY-ATTRIBUTE migrates from the

“Parent” ENTITY to the “Child” ENTITY.

1) The attribute migrating-relationship-index (FK) is a role name for the attribute

for relationship-index (FK) that migrates to FOREIGN-KEY-ATTRIBUTE

under the relationship “migrates-from-parent(source)-to-child(host)-entity” from

RELATIONSHIP.

2) The attribute parent-entity-id (FK) that migrates to FOREIGN-KEY-

ATTRIBUTE under the same relationship (“migrates-from-parent(source)-to-

child(host)-entity” from RELATIONSHIP) intentionally unifies with the source-

entity-id (FK) that is already a descriptive, non-key attribute of FOREIGN-KEY-

ATTRIBUTE.

3) The attribute child-entity-id (FK) that migrates to FOREIGN-KEY-ATTRIBUTE

under the same relationship (“migrates-from-parent(source)-to-child(host)-entity”


V3.1.4

13

from RELATIONSHIP) intentionally unifies with the host-entity-id (FK) that is

already a primary key attribute of FOREIGN-KEY-ATTRIBUTE.

h. base-entity-id—The entity-id that identifies the base entity for the foreign key (a role

name for entity-id). The Base ENTITY is the one to which a FOREIGN-KEY-

ATTRIBUTE migrates. The attribute base-entity-id (FK) is a role name for the

attribute for entity-id (FK) that migrates to FOREIGN-KEY-ATTRIBUTE under the

relationship “is-originator-for” from BASE-ATTRIBUTE.

i. base-attribute-index—The attribute-index that identifies the base attribute for the

foreign key (a role name for attribute-index). The attribute base-attribute-index (FK)

is a role name for the attribute for attribute-index (FK) that migrates to FOREIGN-

KEY-ATTRIBUTE under the relationship “is-originator-for” from BASE-

ATTRIBUTE.

j. unifying-attribute-index—The attribute-index that identifies the attribute that belongs

to the same ENTITY as the one with which it unifies (a role name for attribute-

index). The identifier of an instance of ATTRIBUTE for a specific instance of

ENTITY that, together with the source-entity-id (FK), identifies the attribute of the

Base ENTITY which is designated the same as the FOREIGN-KEY-ATTRIBUTE

migrating from the Source ENTITY.

1) The attribute unifying-attribute-index (FK) is a role name for the attribute for

attribute-index (FK) that migrates to FOREIGN-KEY-ATTRIBUTE under the

relationship “unifies” from FOREIGN-KEY-ATTRIBUTE itself.

2) The attribute entity-id (FK) that migrates to FOREIGN-KEY-ATTRIBUTE

under the same relationship (“unifies” from FOREIGN-KEY-ATTRIBUTE)

intentionally unifies with the host-entity-id (FK) that is already a primary key

attribute of FOREIGN-KEY-ATTRIBUTE. Thus, the unifying instance of

attribute-index (FK) belongs to the same ENTITY as the one with which it

unifies.

3.3.5.3 The table below is an example instance table for FOREIGN-KEY-

ATTRIBUTE.


V3.1.4

14

Table 6. Instance Table for FOREIGN-KEY-ATTRIBUTE

host-entity-id (FK)


***-role-definition-

text

***-rolename-indicator-code



migrating-relation-ship-

index (FK)

base-entity-

id (FK)


10000002 (ABSOLUTE-POINT)

100001 (absolute-point-id)

The point-G

RN 10000105 (POINT)

100001 (point-id)

1 10000063 (LOCATION)

100001 (location-id)

10000061 (LINE)

100001 (line-id)

The locationG

RN 10000063 (LOCATION)


1 10000063 (LOCATION)


10000062 (LINE-POINT)

100001 (line-id)

The locationG

MN 10000061 (LINE)

100001 (line-id)

1 10000063 (LOCATION)


10000062 (LINE-POINT)

100004 (line-point-point-id)

The point-G

RN 10000105 (POINT)

100001 (point-id)

1 10000063 (LOCATION)


10000105 (POINT)

100001 (point-id)

The locationG

RN 10000063 (LOCATION)


1 10000063 (LOCATION)


10000111 (RELATIVE-POINT)

100001 (relative-point-id)

The point-G

RN 10000105 (POINT)

100001 (point-id)

2 10000063 (LOCATION)


10000111 (RELATIVE-POINT)

100008 (relative-coordinate-system-id)

The unique valueG

MN 10000227 (RELATIVE-COORDINA

TE-SYSTEM)

100001 (relative-

coordinate-system-id)

1 10000227 (RELATIVE-COORDINA

TE-SYSTEM)

100001 (relative-coordinate-system-id)

Note: *** = “foreign-key-attribute”

3.3.5.4 A foreign key attribute is the result of a (base or foreign key) attribute that

migrated from a source entity to its current host entity through some relationship that exists

between those two entities. As non-specific relationships are not allowed, every

relationship migrates at least one foreign key attribute.

3.3.5.5 A foreign key attribute (as for every kind of attribute) is identified by the

entity in which it resides and by an index. Basic properties are an indicator whether the

attribute has been role-named or given its migrated name, the source entity and attribute

(always a key attribute, because base attributes do not migrate), and the relationship that is

responsible for the migration. Although the role name indicator is more or less redundant

(because the attribute name could be compared with the attribute name of the source

primary key attribute), it clarifies the foreign key use in the child entity and will simplify

implementation.

3.3.5.6 A foreign key attribute has a base attribute (in another or the same entity)

from which it originates. Despite the fact that this information can be derived from already

represented structures in the metamodel diagram, this link is still useful if, for instance, one

wants to know the domain of a foreign key that already migrated several times.

3.3.5.7 Finally, the unification aspect of IDEF1X is modelled inside FOREIGN-

KEY-ATTRIBUTE, as explained in the next section.


V3.1.4

15

3.4 Unification of Foreign Key Attributes

3.4.1 UNIFICATION

3.4.1.1 Unification means that two or more attributes within the same entity always

contain exactly the same values and have been given the same name for that reason.

IDEF1X makes superfluous attributes disappear in the diagrams, unifying them into one

single attribute with that common name. In practice, the remaining attribute is just one of

the original attributes that “absorbs” the others. This attribute, called the unifying attribute,

is chosen arbitrarily to represent all involved attributes (i.e., both itself and all the absorbed

or unified attributes). As noted, all unified attributes (which are not distinguished in the

IDEF1X diagram) are stored in the MIP Information Resource Dictionary database as well.

However, they should be marked in a way that can be distinguished from the rest. Since

only foreign key attributes may be unified, an extra “unifying-attribute-index” is added to

FOREIGN-KEY-ATTRIBUTE, in which a unifying foreign key attribute index (within the

same host entity) may be put. Normal foreign keys hold a “null” value in this attribute,

unified foreign keys an index number. A foreign key with a “unifying-attribute-index”

equal to 4 has been unified with Attribute 4 of the same entity.

3.4.1.2 In summary, unification is modelled in such a way that only one of the

participants remains a normal attribute (the unifying attribute), while the others (the unified

attributes) are tagged. They are populated in the MIP Information Resource Dictionary

database, but will disappear in a physical database implementation as they become

redundant. All foreign key attributes (unifying, unified, and others) are put in the MIP

Information Resource Dictionary database, although the unified ones should be considered

as “hidden.”

3.4.1.3 Within FOREIGN-KEY-ATTRIBUTE several attributes have been unified

as a result of multiple relationships that carry the identifier of the same instance of some

entity.

3.5 Alternate Key View

3.5.1 ALTERNATE-KEY

3.5.1.1 An ALTERNATE-KEY is defined as ‘A record that points to one or more

attributes that collectively serve as a unique identification for an entity that is cited in a

specific ENTITY and may be used instead of the PRIMARY-KEY for the same instance of

ENTITY’. An ALTERNATE-KEY may also be designated as part or all of an inversion

entry, that is nulls are permitted and values are not necessarily unique but, while not

capable of being used as the primary key of an entity, are deemed useful for indexing

implemented databases (for retrieval of instances). By definition, every alternate key can

serve as an inversion entry but not conversely.4 The Alternate key structure is shown in the

figure below.

a. If two (or more) attributes form an ALTERNATE-KEY for an entity, the label

“AK1” may be appended to their names in the metamodel diagram (e.g., as in

4 It has long been recognized that the name ALTERNATE-KEY is confusing when it is defined and used

to capture not only alternate keys but inversion entries. The concept has been retained in Baseline 3.0

due to its simplicity.


V3.1.4

16

IDEF1X). If an additional set of attributes, possibly overlapping with the first, form

an alternate key, the label “AK2” may be appended to their names.

b. Similarly, if two our more attributes are designated as an inversion entry, the label

“IE1” may be appended to their names in the metamodel diagram (e.g., as in

IDEF1X). If an additional set of attributes, possibly overlapping with the first, form

an alternate key, the label “IE2” may be appended to their names.

3.5.1.2 Besides the primary key, an entity may have zero or more sets of alternate

keys, identified by an alternate key index. An alternate key contains at least one attribute of

the entity. Further, attributes may appear in zero or more different alternate keys, acting as

a so-called “alternate key attribute.” Each set of alternate keys or inversion entries for an

entity is denoted with an integer. Examples are AK1, AK2, IE1, and IE2.

consists-of

P

appears-in

ALTERNATE-KEY

entity-id (FK) (AK1.2)

alternate-key-index

alternate-key-number-quantity (AK1.1)

alternate-key-uniqueness-indicator-code (AK1.3)

ALTERNATE-KEY-ATTRIBUTE

entity-id (FK)


alternate-key-index (FK)

ATTRIBUTE


attribute-index







Figure 2. Alternate Key View

3.5.1.3 Both real alternate keys and inversion entries are represented in

ALTERNATE-KEY. Values for “alternate-key-uniqueness-indicator-code” are AU (always

unique; i.e., an alternate key) and MU (mostly unique; i.e., an inversion entry). The integer

part of the “AK” or “IE” label (e.g., “AK1”) is captured by “alternate-key-number-

quantity.”

3.5.1.4 An ALTERNATE-KEY is identified by the primary key attribute, entity-id

(FK), that migrates to ALTERNATE-KEY under the identifying relationship “is-also-

identified-by” from ENTITY, together with the owned attribute alternate-key-index that

serves to distinguish instances of ALTERNATE-KEY for the same ENTITY. The

attributes of ALTERNATE-KEY are the following:



b. alternate-key-index—The unique value, or set of characters, assigned to represent a

specific ALTERNATE-KEY for a specific ENTITY and to distinguish it from all

other ALTERNATE-KEYs for that ENTITY.

c. alternate-key-number-quantity—The numeric value that represents the alternate key

or inversion key in the ENTITY.


V3.1.4

17

d. alternate-key-uniqueness-indicator-code—The specific value that denotes whether

the alternate key or inversion key is unique. The domain values are: Always unique

(e.g., Alternate Key); Mostly unique (e.g., Inversion Entry).

3.5.1.5 The table below is an example instance table for ALTERNATE-KEY.

Table 7. Instance Table for ALTERNATE-KEY

entity-id (FK)

alternate-key-index

alternate-key-number-quantity

alternate-key-uniqueness-indicator-code

10010011 [DOMAIN-VALUE]

1 1 AU

[Alternate Key]


2 1 MU

[Inversion Entry]

10010012 [ENTITY]

1 1 AU

[Alternate Key]

10010012 [ENTITY]

2 2 AU

[Alternate Key]

3.5.2 ALTERNATE-KEY-ATTRIBUTE

3.5.2.1 An ALTERNATE-KEY-ATTRIBUTE is defined as ‘The association of a

specific ALTERNATE-KEY with a specific ATTRIBUTE that identifies the participation

of the ATTRIBUTE as part of ALTERNATE-KEY.’ The ALTERNATE-KEY structure is

shown in Figure 2 above.

3.5.2.2 An ALTERNATE-KEY-ATTRIBUTE is identified by the primary key

attributes, entity-id (FK) and alternate-key-index (FK), that migrate to ALTERNATE-

KEY-ATTRIBUTE from the identifying relationship “consists-of”; and the entity-id (FK)

and attribute-index (FK), that migrate to ALTERNATE-KEY-ATTRIBUTE from the

identifying relationship “appears-in” from ATTRIBUTE. The entity-id (FK) from

ALTERNATE-KEY and the entity-id (FK) from ATTRIBUTE intentionally unify; that is,

they represent the same data element in ALTERNATE-KEY-ATTRIBUTE. The attributes

of ALTERNATE-KEY-ATTRIBUTE are the following:






c. alternate-key-index—The unique value, or set of characters, assigned to represent a

specific ALTERNATE-KEY for a specific ENTITY and to distinguish it from all

other ALTERNATE-KEYs for that ENTITY.

3.5.2.3 The table below is an example instance table for ALTERNATE-KEY-

ATTRIBUTE.


V3.1.4

18

Table 8. Instance Table for ALTERNATE-KEY-ATTRIBUTE

entity-id (FK) attribute-index (FK) alternate-key-index (FK)


100003 [domain-value-description-text (AK1.1)]

1


100001 [domain-id (AK1.2)]

1


100007 [domain-value-type-code (AK1.3)]

1


100004 [domain-value-name-text (IE1.1)]

2


100001 [domain-id (IE1.2)]

2

10010012 [ENTITY]

100002 [entity-name-text (AK1.1)]

1

10010012 [ENTITY]

100001 [entity-id (AK1.2)]

1

10010012 [ENTITY]

100003 [entity-table-name-text (AK2.1)]

2

10010012 [ENTITY]

100001 [entity-id (AK2.2)]

2

3.6 Entity Relationships

3.6.1 CATEGORY-RELATIONSHIP

3.6.1.1 A CATEGORY-RELATIONSHIP is defined as ‘Representation of the

information required to define a subtype for a specific ENTITY.’ Such an attribute divides

the instances of the ENTITY into disjoint (non-overlapping) subsets (the subtypes), each of

which is identified as an ENTITY. The structure is shown in the figure below.

Figure 3. Category Relationship View


V3.1.4

19

3.6.1.2 An entity acts as supertype for zero, one, or more category subtrees. A

category can be considered as being a cluster that groups a number of subtype entities (but

is not modelled in this way). Every category has a discriminator (i.e., an attribute of the

supertype entity) and an indicator that says whether the category is complete or incomplete.

As the model indicates, a category consists of one or more subtype relationships, with the

same supertype entity (unified within SUBTYPE-RELATIONSHIP).

3.6.1.3 A CATEGORY-RELATIONSHIP is identified by two attributes. Firstly the

primary key attribute, super-entity-id (FK) that migrates to CATEGORY-RELATIONSHIP

from the identifying relationship “is-subtyped-via” from ENTITY. Secondly the owned

attribute category-relationship-index, which serves to distinguish instances of

CATEGORY-RELATIONSHIP for the same ENTITY. The attributes of CATEGORY-

RELATIONSHIP are the following:

a. super-entity-id—The entity-id that identifies the super-type entity for sub-typing (a

role name for entity-id).

b. category-relationship-index—The unique value, or set of characters, assigned to

represent a specific CATEGORY-RELATIONSHIP for a specific ENTITY and to

distinguish it from all other CATEGORY-RELATIONSHIPs for that ENTITY.

c. category-relationship-definition-text—The character string assigned to represent the

characterisation of a CATEGORY-RELATIONSHIP.

d. discriminator-attribute-index—The attribute-index that identifies the attribute used as

a discriminator for sub-typing (a role name for attribute-index).

e. category-relationship-completeness-indicator-code—The specific value that

represents whether all the possible subtypes of the Super ENTITY explicitly occur in

the data model. The domain values are: Complete category; Incomplete category.

3.6.1.4 The table below is an example instance table for CATEGORY-

RELATIONSHIP.

Table 9. Instance Table for CATEGORY-RELATIONSHIP

super-entity-id (FK)

***-index

***-definition-text

discriminator-attribute-index (FK)

***-completeness-indicator-code

10000043 (FACILITY) 1 — 100002 IC

10000049 (FEATURE) 1 — 100002 IC

10000063 (LOCATION) 1 — 100002 CC

10000070 (MATERIEL-TYPE) 1 — 100002 IC

10000076 (OBJECT-ITEM) 1 — 100002 IC

10000085 (ORGANISATION) 1 — 100002 IC

10000105 (POINT) 1 — 100002 CC

Note: *** = “category-relationship”


V3.1.4

20

3.6.2 RELATIONSHIP

3.6.2.1 A RELATIONSHIP is defined as ‘The association of one instance of

ENTITY (the "Parent” ENTITY) with another (the "Child" ENTITY) that describes the

degree and nature of the association.’ The RELATIONSHIP is said to connect the Parent

ENTITY to the Child ENTITY. In some cases, the RELATIONSHIP associates a subset of

the ENTITY with that Parent ENTITY and this is termed a SUBTYPE-RELATIONSHIP.

In the other case (termed CARDINALITY-RELATIONSHIP), the RELATIONSHIP

associates the primary key of the Parent ENTITY with the attributes of the Child ENTITY

(the primary key attributes of the Parent ENTITY are thereby said to “migrate” to the Child

Entity). There are two and only two subtypes of RELATIONSHIP under the relationship-

type-code: CARDINALITY-RELATIONSHIP and SUBTYPE-RELATIONSHIP. The

relationship structure is shown in the figure below.

Figure 4. Relationship View


V3.1.4

21

3.6.2.2 The first type of relationship, the cardinality relationship, captures the one(-

or-zero)-to-more relationships. These are described by an “cardinality-relationship-

identifying-indicator-code” (identifying, nonidentifying); a “cardinality-relationship-

parent-cardinality-code” (one = mandatory, zero-or-one = optional); a “cardinality-

relationship-child-cardinality-code” (zero, one or more, positive (one or more), zero or one,

exactly, range, special); a cardinality-relationship-child-minimum-cardinality-count and

cardinality-relationship-child-maximum-cardinality-count in case of an exact or a range

cardinality type; a cardinality-relationship-verb-name-text (mandatory); and a cardinality-

relationship-inverse-verb-name-text (optional).

3.6.2.3 The second type of relationship, the subtype relationship, is used to store the

subtype relationships between two different entities, that is, one entity is a subtype of

another entity and the latter entity is called the supertype. Every subtype relationship is

associated with exactly one category relationship (see next item).

3.6.2.4 A RELATIONSHIP is identified by 3 attributes. Firstly the primary key

attributes, parent-entity-id (FK) and child-entity-id (FK), that migrate to RELATIONSHIP

under the identifying relationships “is-parent-of” and “is-child-of,” respectively, from

ENTITY. The 3rd identifing attribute is the owned attribute relationship-index, which

serves to distinguish instances of RELATIONSHIP for the same Parent ENTITY and the

same Child ENTITY. The attributes of RELATIONSHIP are the following:

a. parent-entity-id—The entity-id that identifies the parent entity in the relationship (a


b. child-entity-id—The entity-id that identifies the child entity in the relationship (a role

name for entity-id).

c. relationship-index—The unique value, or set of characters, assigned to represent a

RELATIONSHIP for a specific Parent ENTITY and a specific Child ENTITY and to

distinguish it from all other RELATIONSHIPs for that Parent ENTITY and that

Child ENTITY.

d. relationship-type-code—The specific value that represents the class of

RELATIONSHIP being specified. The domain values are: CARDINALITY-

RELATIONSHIP; SUBTYPE-RELATIONSHIP.

3.6.2.5 The table below is an example instance table for RELATIONSHIP.

Table 10. Instance Table for RELATIONSHIP

parent-entity-id (FK)

child-entity-id (FK)

relationship-index

relationship-type-code

10000063 (LOCATION) 10000055 (GEOMETRIC-VOLUME) 1 SR

10000063 (LOCATION) 10000061 (LINE) 1 SR

10000063 (LOCATION) 10000105 (POINT) 1 SR

10000063 (LOCATION) 10000119 (SURFACE) 1 SR

10000203 (MILITARY-ORGANISATION-TYPE)

10000204 (MILITARY-POST-TYPE) 1 SR

10000076 (OBJECT-ITEM) 10000243 (OBJECT-ITEM-ASSOCIATION) 1 CR

10000076 (OBJECT-ITEM) 10000243 (OBJECT-ITEM-ASSOCIATION) 2 CR

10000085 (ORGANISATION) 10000008 (ACTION-OBJECTIVE) 1 CR

10000085 (ORGANISATION) 10000012 (ACTION-RESOURCE) 1 CR

10000085 (ORGANISATION) 10000170 (ORGANISATION-ACTION-ASSOCIATION) 1 CR

10000085 (ORGANISATION) 10000157 (REPORTING-DATA) 1 CR

10000085 (ORGANISATION) 10000247 (ACTION-OBJECTIVE-ITEM-MARKING) 1 CR

10000085 (ORGANISATION) 10000128 (UNIT) 1 SR


V3.1.4

22

3.6.3 CARDINALITY-RELATIONSHIP

3.6.3.1 As noted, CARDINALITY-RELATIONSHIP is a subtype of

RELATIONSHIP. A CARDINALITY-RELATIONSHIP is defined as ‘A one-way

RELATIONSHIP that identifies a specific “parent” ENTITY with a specific “child”

ENTITY where the child is a dependent ENTITY whose set of key attributes may differ

from the set of key attributes of the parent.’ By definition, it implies nothing about how the

Child ENTITY relates back to the Parent Entity. Cardinality is expressed by attributes that

specify how many instances of the entity may or must be present in the Child ENTITY. It

is a RELATIONSHIP whose child entity is a dependent ENTITY that has a set of key

attributes that may differ from the set of keys of the Parent.

3.6.3.2 A CARDINALITY-RELATIONSHIP is identified by the primary key

attributes, parent-entity-id (FK), child-entity-id (FK), and relationship-index (FK), that

migrate to CARDINALITY-RELATIONSHIP from the category (subtype) relationship

from RELATIONSHIP (whose category discriminator in the metamodel is relationship-

type-code). The attributes of CARDINALITY-RELATIONSHIP are the following:

a. parent-entity-id—The entity-id that identifies the parent entity in the relationship (a


b. child-entity-id—The entity-id that identifies the child entity in the relationship (a role





Child ENTITY.

d. cardinality-relationship-verb-name-text—The character string assigned to represent

the action phrase describing the association from the parent to the child instances of

ENTITY for a CARDINALITY-RELATIONSHIP.

e. cardinality-relationship-inverse-verb-name-text—The character string assigned to

represent the action phrase describing the relationship from the child and to the

parent instances of ENTITY for a CARDINALITY-RELATIONSHIP.

f. cardinality-relationship-identifying-indicator-code—The specific value that

represents the class of CARDINALITY-RELATIONSHIP represented. The domain

values are: Identifying; Nonidentifying.

g. cardinality-relationship-parent-cardinality-code—The specific value that represents

the optionality of the CARDINALITY-RELATIONSHIP. The domain values are:

Mandatory (one); Optional (zero or one).

h. cardinality-relationship-child-cardinality-code—The specific value that represents the

range in the number of occurrences associated with the child entity in the

CARDINALITY-RELATIONSHIP represented. The domain values are: Exactly;

Positive (one or more); Range; Special; Zero, one, or more; Zero or one.


V3.1.4

23

i. cardinality-relationship-child-minimum-cardinality-count—The integer value that

represents the number of the minimum exact cardinality associated with the child

entity in the CARDINALITY-RELATIONSHIP represented.

j. cardinality-relationship-child-maximum-cardinality-count—The integer value that

represents the number of the maximum exact cardinality associated with the child

entity in the CARDINALITY-RELATIONSHIP represented.

3.6.3.3 The table below is an example instance table for CARDINALITY-

RELATIONSHIP.

Table 11. Instance Table for CARDINALITY-RELATIONSHIP



relation-ship-index (FK)

***-verb-name-text

***-inverse-verb-name-text

***-identifyin

g-indicator-code

***-

parent-cardinality-code

***-child-cardinality-code

10000063 (LOCATION)

10000050 (FEATURE-LOCATION)

1 provides-geometric-definition-for

ID MA ZM

10000085 (ORGANISATION)

10000008 (ACTION-OBJECTIVE)

1 is-authority-for-the-use-of

is-used-as-specified-by

NI OP ZM


10000012 (ACTION-RESOURCE)

1 is-authority-for-the-use-of

is-used-as-specified-by

NI OP ZM

10000076 (OBJECT-ITEM)

10000243 (OBJECT-ITEM-ASSOCIATION)

1 is-the-subject-of

ID MA ZM


10000243 (OBJECT-ITEM-ASSOCIATION)

2 is-the-object-of

ID MA ZM


10000224 (OBJECT-ITEM-LOCATION)

1 is-geometrically-defined-through

ID MA ZM


10000170 (ORGANISATION-ACTION-ASSOCIATION)

1 has-its-role-specified-through

ID MA ZM


10000157 (REPORTING-DATA)

1 is-the-reporting-agent-for

is-reported-by

NI MA ZM


10000247 (ACTION-OBJECTIVE-ITEM-MARKING)

1 is-the-user-of is-used-by

NI MA ZM

Note: *** = “cardinality-relationship”

3.6.4 SUBTYPE-RELATIONSHIP

3.6.4.1 As noted, SUBTYPE-RELATIONSHIP is a subtype of RELATIONSHIP.

SUBTYPE-RELATIONSHIP is defined as ‘A RELATIONSHIP that identifies a child

ENTITY whose primary key is identical to the primary key of the parent ENTITY and

which inherits all of the properties of the parent ENTITY.’ In a SUBTYPE-

RELATIONSHIP, the primary key of the Parent ENTITY is always identical to the

primary key of the Child ENTITY (sometimes the attributes of the Child Entity are given

specific context by renaming them with so-called “role names.”) The method of identifying

the subset or subtype that serves as the Child ENTITY, uses a common value for one and

only one of the attributes of the Parent Entity (such an attribute is called the category

discriminator).


V3.1.4

24

3.6.4.2 A SUBTYPE-RELATIONSHIP is identified by the primary key attributes,

parent-entity-id (FK), child-entity-id (FK), and relationship-index (FK), that migrate to

SUBTYPE-RELATIONSHIP from the category (subtype) relationship from

RELATIONSHIP (whose category discriminator in the metamodel is relationship-type-

code). The attribute parent-entity-id (FK) in SUBTYPE-RELATIONSHIP is given the role

name super-entity-id (FK), which intentionally unifies with the super-entity-id that

migrates to SUBTYPE-RELATIONSHIP under the relationship “holds” from

CATEGORY-RELATIONSHIP. Further, the attribute child-entity-id (FK) in SUBTYPE-

RELATIONSHIP is given the role name sub-entity-id (FK). The attributes of SUBTYPE-

RELATIONSHIP are the following:

a. super-entity-id—The entity-id that identifies the super-type entity for sub-typing (a


b. sub-entity-id—The entity-id that identifies the sub-type entity for sub-typing (a role





Child ENTITY.

d. category-relationship-index—The unique value, or set of characters, assigned to

represent a specific CATEGORY-RELATIONSHIP for a specific ENTITY and to

distinguish it from all other CATEGORY-RELATIONSHIPs for that ENTITY. The

attribute category-relationship-index (FK) migrates to SUBTYPE-RELATIONSHIP

under the relationship “holds” from CATEGORY-RELATIONSHIP.

e. domain-id—The unique value, or set of characters, assigned to represent a specific

DOMAIN and to distinguish it from all other DOMAINs.

f. domain-value-index—The unique value, or set of characters, assigned to represent a

specific DOMAIN-VALUE for a specific DOMAIN and to distinguish it from all

other DOMAIN-VALUEs for that DOMAIN.

3.6.4.3 The table below is an example instance table for SUBTYPE-

RELATIONSHIP.

Table 12. Instance Table for SUBTYPE-RELATIONSHIP


sub-entity-id (FK)

relationship-index (FK)

category-relationship-index (FK)

domain-id

domain-

value-index

10000063 (LOCATION) 10000055 (GEOMETRIC-VOLUME)

1 1 10000138 1000004

10000063 (LOCATION) 10000061 (LINE) 1 1 10000138 1000002

10000063 (LOCATION) 10000105 (POINT) 1 1 10000138 1000001

10000063 (LOCATION) 10000119 (SURFACE) 1 1 10000138 1000003

10000085 (ORGANISATION) 10000128 (UNIT) 1 1 10000149 1000004


V3.1.4

25

3.7 DOMAIN

3.7.1 DOMAIN

3.7.1.1 A DOMAIN is defined as ‘A record that specifies the collective metadata

characteristics for a set of values to be associated with a specific data element.’ In some

cases, the specification is to list valid values for a coded attribute (those values are

provided in DOMAIN-VALUE). In some cases, the specification is to identify maximum

and minimum values for a numeric attribute and, where applicable, provide the

measurement unit description (e.g., metres, seconds, kilometres per hour). The DOMAIN

structure is shown in the figure below.

Figure 5. Domain View

3.7.1.2 This set may be specified by a description only, but can also explicitly

contain the complete set of values. In DOMAIN, the domain identifier and name both

uniquely identify a domain. The (mandatory) definition text describes the domain in an

unstructured manner. It can also clarify the purpose of a domain, its use for the JC3IEDM,

who is responsible for maintaining a domain, etc. The class name indicates the class word

each attribute using this domain must have. Thus, a domain can only cover one class word.

3.7.1.3 Globally, two kinds of domains exist. Each type has a specific way to

restrict the total number of values inside the domain. A domain can be an enumeration

(explicit set of values) or a range (values between a minimum and maximum).


V3.1.4

26

3.7.1.4 The unit of measurement must be used in case of domains that contain

physical or monetary numbers.

3.7.1.5 One is able to specify domain hierarchies. This is done for the sake of data

management only. A domain may refer to another “parent” domain from which the

properties are inherited. The “child” domain differs in the sense that it is more restrictive

(e.g., has fewer values). This concept, though valid, is not currently utilised by the

JC3IEDM.

3.7.1.6 A DOMAIN is identified by the primary key attribute domain-id. The

attributes of DOMAIN are the following:

a. domain-id—The unique value, or set of characters, assigned to represent a specific


b. domain-name-text—The character string assigned to represent a specific DOMAIN.

c. domain-definition-text—The character string assigned to represent the definition of a

specific DOMAIN.

d. domain-class-name-text—The character string assigned to represent the category to

which the DOMAIN belongs.

e. domain-restriction-type-code—The specific value that represents the type of

constraint imposed upon values for the DOMAIN. The domain values are:

Enumerated domain; Range.

f. domain-measurement-unit-description-text—The character string assigned to

represent the unit of measure for DOMAINs that permit quantitative values.

g. parent-domain-id—The domain-id of a specific parent DOMAIN (a role name for

domain-id). The attribute parent-domain-id (FK) is a role name for the attribute for

domain-id (FK) that migrates to DOMAIN under the relationship “is-basis-for” from

DOMAIN itself.

h. domain-standardisation-level-code—The specific value that represents the level of

common agreement for the DOMAIN. Domain values are: International; Local;

National; MIP Core; MIP-NATO Data Administration; Multilateral Interoperability

Programme. The domain value set for this attribute is shared with one or more other

attributes and is defined in the set standardisation-level-code.

i. domain-model-level-code—The specific value that represents the data model source

of the DOMAIN. Domain values are: Application; Dictionary; Metamodel. The

domain value set for this attribute is shared with one or more other attributes and is

defined in the set model-level-code.

j. domain-definition-source-text—The character string assigned to represent the source

of the domain definition.

3.7.1.7 The table below is an example instance table for DOMAIN.


V3.1.4

27

Table 13. Instance Table for DOMAIN

domain-id

***-name-text

***-

class-name-text

***-

restriction-type-code

parent-domain-id (FK)

***- standardisation-level-

code

***-model-level-code

***-

definition-source-text

100000000 angle angle RA MPCO APPL —

100000100 code code EN MPCO APPL —

100000110 action-category-code

code EN 100000100 MPCO APPL —

100000600 dimension dimension RA MPCO APPL —

100000700 duration duration RA MPCO APPL —

100001300 rate rate RA MPCO APPL —

100001400 temperature temperature RA MPCO APPL —

100002000 datetime datetime MPCO APPL —

Note: Not shown in the instance table are the attributes ***-definition-text and ***-measurement-unit-description-text.

Note: *** = “domain”


that domain keys are not reused. If the semantic understanding of an existing domain has changed,

then a new key should be generated for the new domain. It is expected that no new identifier with a

value less than the highest used identifier (+ 1) will ever be used.

3.7.2 DOMAIN-VALUE

3.7.2.1 A DOMAIN-VALUE is defined as ‘A valid data instance cited for a specific

DOMAIN.’ Typically, these values are the codes, labels for codes, and meanings for codes

of enumerated domains.

3.7.2.2 Explicit domain values are stored in DOMAIN-VALUE. Every record in

that table denotes a single value that belongs to a specific domain. Therefore, a domain

value can never be used in two or more domains. This explains why a domain value is

identified by the combination of a domain identifier and a value index. Each domain in the

DOMAIN table has zero or more domain values in DOMAIN-VALUE. Within the domain,

the values are uniquely identified by the index.

3.7.2.3 The actual domain value is represented by the attribute “domain-value-

description-text.” A value consists of 32 characters at the most (which is assumed to be

enough, because longer values are not expected to be listed as an explicit domain value).

Besides the value, there is also room for an optional value domain-value-name-text, which

can have up to 80 characters. Names are often used when the value itself is a code. For

example, the country code value “NLD” is accompanied by the value name “Netherlands”.

As for the index, each value and name (in the present case) uniquely identifies the values

within a domain. An optional definition can be given to a domain value.

3.7.2.4 Finally, the value type denotes the main function that this explicitly stored

value has for the enclosing domain. Enumerated domains are associated with a complete

set of domain values. Therefore, all these values—elements of the set—are classified as

“ELEM”.

3.7.2.5 Range domains are specified by means of a minimum and/or a maximum

domain value, either included in or excluded from the range. Four types can be used here:

“MIN-IN”, “MIN-EX”, “MAX-IN”, and “MAX-EX”. These are, respectively, the

minimum inclusive, minimum exclusive, maximum inclusive and maximum exclusive

types.


V3.1.4

28

3.7.2.6 Other types of domain values can be imagined, but so far there is no need

for more than the ones introduced above.

3.7.2.7 A DOMAIN-VALUE is identified by the primary key attribute, domain-id

(FK) that migrates to DOMAIN-VALUE under the identifying relationship “contains”

from DOMAIN, together with the owned attribute domain-value-index, which distinguishes

instances of DOMAIN-VALUE for the same DOMAIN. The attributes of DOMAIN-

VALUE are the following:

a. domain-id—The unique value, or set of characters, assigned to represent a specific


b. domain-value-index—The unique value, or set of characters, assigned to represent a



c. domain-value-description-text—The character string assigned to represent the

description of a DOMAIN-VALUE. This field is stored in Upper Case. It is to be

exchanged in that format and only that format.

d. domain-value-name-text—The character string assigned to represent a specific

DOMAIN-VALUE.

e. domain-value-definition-text—The character string assigned to represent the

definition of a DOMAIN-VALUE.

f. domain-value-type-code—The specific value that represents the class of a DOMAIN-

VALUE. The domain values are: Element; Maximum Exclusive; Maximum

Inclusive; Minimum Exclusive; Minimum Inclusive.

g. domain-value-standardisation-level-code—The specific value that represents the

level of common agreement of the DOMAIN-VALUE. The domain values are:

International; Local; National; MIP-NATO Data Administration; MIP Core;

Multilateral Interoperability Programme. The domain value set for this attribute is

shared with one or more other attributes and is defined in the set standardisation-

level-code.

h. domain-value-source-text—The character string assigned to represent the source of

the domain value and the definition of that domain value.

3.7.2.8 The table below is an example instance table for DOMAIN-VALUE.


V3.1.4

29

Table 14. Instance Table for DOMAIN-VALUE

domain-id (FK)

***-index

***-description

-text

***-name-text

***-definition-text

***-type-code

***-standardisation-level-code

100000000 1000001 0 DFLT MPCO

100000000 1000002 0 MIN-IN MPCO

100000000 1000003 359.9999 MAX-IN MPCO

100000110 1000003 ACTEV ACTION-EVENT

An ACTION that is an incident, phenomenon, or occasion of military significance which has occurred or is occurring but for which planning is not known.

ELEM MPCO

100000110 1000004 ACTTA ACTION-TASK

An ACTION that is being or has been planned and for which the planning details are known.

ELEM MPCO

100000601 1000002 0 MIN-IN MPCO

100000602 1000002 0 MIN-IN MPCO

100001312 1000002 0 MIN-IN MPCO

100001400 1000002 -273.75 MIN-IN MPCO

Note: Not shown in the instance table is the attribute ***-source-text. Note: *** = “domain-value”


that domain value indices are not reused. If the semantic understanding of an existing

domain value has changed, then a new key should be generated for the new domain value.

It is expected that no new identifier with a value less than the highest used identifier (+ 1)

will ever be used.

3.8 Business Rules

The entity BUSINESS-RULE is designed to capture the category, identifier,

name and description of a business rule. This entity allows the domain value associations

forming a business rule to be grouped as well as providing a link to the business rule text.

This is a significant benefit as error messages for domain value association violations can

include the direct specification reference. The entity BUSINESS-RULE-ENTITY is

designed to specify an entity of interest to which a particular business rule is applicable and

to group BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITEs. The entity DOMAIN

BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE is designed to specify a

particular attribute that plays a role in specifying a particular BUSINESS-RULE-ENTITY-

ATTRIBUTE-COMPOSITE-DOMAIN-VALUE. An indicator code specifies whether a

value must be specified for the attribute. The entity BUSINESS-RULE-ENTITY-

ATTRIBUTE-COMPOSITE-DOMAIN-VALUE specifies allowable domain-values. An

integrated example will be included in increments in the various sub-paragraphs. The

BUSINESS-RULE structure is shown in the figure below.


V3.1.4

30

provides-the-attribute-reference

is-characterised-by

P

is-composed-of

is-composed-of

has

is-composed-of

is-part-of

contains

is-basis-for

ATTRIBUTE


attribute-index







BUSINESS-RULE

business-rule-id

business-rule-category-code

business-rule-section-cross-reference-text

business-rule-name-text

business-rule-definition-text

business-rule-table-cross-reference-text

BUSINESS-RULE-ENTITY

business-rule-id (FK)

business-rule-entity-index

entity-of-interest-id (FK)

BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE


business-rule-entity-index (FK)

business-rule-entity-attribute-composite-index

business-rule-entity-attribute-composite-null-indicator-code

entity-id (FK)


BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE-DOMAIN-VALUE



business-rule-entity-attribute-composite-index (FK)

business-rule-entity-attribute-composite-domain-value-index

domain-id (FK)

domain-value-index (FK)

DOMAIN

domain-id (AK1.2)

domain-name-text (AK1.1)

domain-definition-text

domain-class-name-text

domain-restriction-type-code

domain-measurement-unit-description-text


domain-standardisation-level-code

domain-model-level-code

domain-definition-source-text

ENTITY

entity-id (AK1.2,AK2.2)

entity-name-text (AK1.1)

entity-table-name-text (AK2.1)

entity-definition-text

entity-dependency-code

entity-depth-count

entity-storage-type-code

entity-standardisation-level-code

entity-model-level-code

DOMAIN-VALUE

domain-id (FK) (AK1.2,IE1.2)

domain-value-index

domain-value-description-text (AK1.1)

domain-value-name-text (IE1.1)

domain-value-definition-text

domain-value-type-code (AK1.3)

domain-value-standardisation-level-code

domain-value-source-text

Figure 6. Business Rule View

3.8.1 BUSINESS RULE

3.8.1.1 BUSINESS-RULE is defined as ‘A grouping of operationally related

business restrictions.’ The current MIRD subject area provides a means to determine the

specific sub-type by means of a discriminating value in the category code used to indicate

sub-type presence. For this reason sub-type specifications are not captured within this

construct. They are enforced by the IDef1X modelling specification.

3.8.1.2 A BUSINESS-RULE is identified by the primary key attribute, business-

rule-id (PK). The attributes of BUSINESS-RULE are the following:

a. business-rule-id—The unique value or set of characters, assigned to represent a

specific BUSINESS-RULE and to distinguish it from all other BUSINESS-RULEs.


V3.1.4

31

b. business-rule-category-code—The specific value that represents the class of

BUSINESS-RULE as text or a formal rule. The domain values are: Rule; Text.

c. business-rule-section-cross-reference-text—The character string assigned to identify

the section of the document describing the BUSINESS-RULE. The purpose of this

attribute is to enable cross-referencing to an external document.

d. business-rule-name-text—The character string assigned to represent the BUSINESS-

RULE.

e. business-rule-definition-text—The character string assigned to specify the

BUSINESS-RULE. The purpose of this attribute is to enable cross-referencing to an

external document.

f. business-rule-table-cross-reference-text—The character string assigned to identify

the table in the document that corresponds to the BUSINESS-RULE. The purpose of

this attribute is to enable cross-referencing to an external document.

3.8.1.3 The datafill in each of the tables will be based on the following example:

ORGANISATION ORGANISATION Command and control Has attached Has detached

Has full command of Has operational command of

Has operational control of Has tactical command of

Has tactical control of [NULL]

3.8.1.4 The table below is an example instance table for BUSINESS-RULE.

Table 15. Instance Table for BUSINESS-RULE

**-id (PK)

**-

category-code

**-section-cross-

reference-text

**-name-text

**-definition-text

**-table-cross-

reference-text

100000000026 RULE G2.7.1 G2.7.1 General Association Rules The permissible domain values for object-item-association-category-code for various combinations of subject and object OBJECT-ITEM are listed in Table G2-42. The last column indicates that the object-item-association-subcategory-code is to be used only when instances of subject and object OBJECT-ITEM are ORGANISATIONs.

Business Rules for OBJECT-ITEM-ASSOCIATION Category and Subcategory Codes

Table G2-42

Note: ** = “business-rule”

3.8.1.5 The specification for the JC3IEDM Metamodel has to ensure that business

rule keys are not reused. If the semantic understanding of an existing business rule has

changed, then a new key should be generated for the new business rule. It is expected that

no new identifier with a value less than the highest used identifier (+ 1) will ever be used.

3.8.2 BUSINESS RULE ENTITY

3.8.2.1 BUSINESS-RULE-ENTITY is defined as ‘An identification of a specific

entity that is the focus of a particular BUSINESS-RULE.’ It is designed to specify an entity

of interest to which a particular business rule is applicable.


V3.1.4

32

3.8.2.2 A BUSINESS-RULE-ENTITY is identified by the primary key attributes,

business-rule-id (FK)and business-rule-entity-index (PK). The attributes of BUSINESS-

RULE-ENTITY are the following:



b. business-rule-entity-index—The unique value, or set of characters, assigned to

represent a specific BUSINESS-RULE-ENTITY for a specific BUSINESS-RULE

and to distinguish it from all other BUSINESS-RULE-ENTITYs for that

BUSINESS-RULE.

c. entity-of-interest-id—The entity-id of the entity that is of interest in a specific

BUSINESS-RULE-ENTITY (a role name for entity-id).

3.8.2.3 The table below is an example instance table for BUSINESS-RULE-

ENTITY. The example contains one of potentially many entries that represent the rows in a

Business Rule table.

Table 16. Instance Table for BUSINESS-RULE-ENTITY

business-rule-id (FK) business-rule-entity-index (PK) entity-of-interest-id (FK)

100000000026 100000000020 10000243

3.8.2.4 The specification for the JC3IEDM Metamodel has to ensure that business-

rule-entity-(indices) are not reused. If the semantic understanding of an existing business-

rule-entity-index has changed, then a new key should be generated for the new business-

rule-entity-index. It is expected that no new identifier with a value less than the highest

used identifier (+ 1) will ever be used.

3.8.3 BUSINESS RULE ENTITY-ATTRIBUTE-COMPOSITE

3.8.3.1 BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE is defined as ‘An

identification of a specific attribute that is the focus of a particular BUSINESS-RULE-

ENTITY.’ It is designed to specify a particular attribute that plays a role in specifying a

particular business rule.

3.8.3.2 A BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE is identified by

the primary key attributes, business-rule-id (FK), business-rule-entity-index (FK) and

business-rule-entity-attribute-composite-index (PK). The attributes of BUSINESS-RULE-

ENTITY-ATTRIBUTE-COMPOSITE are the following:






BUSINESS-RULE.

c. business-rule-entity-attribute-composite-index—The unique value, or set of

characters, assigned to represent a specific BUSINESS-RULE-ENTITY-

ATTRIBUTE-COMPOSITE for a specific BUSINESS-RULE-ENTITY and to


V3.1.4

33

distinguish it from all other BUSINESS-RULE-ENTITY-ATTRIBUTE-

COMPOSITEs for that BUSINESS-RULE-ENTITY.

d. business-rule-entity-attribute-composite-null-indicator-code—The specific value that

indicates whether the attribute cited in BUSINESS-RULE-ENTITY-ATTRIBUTE-

COMPOSITE is permitted to be unspecified within the specific BUSINESS-RULE.

The domain values are: No; Yes.

e. entity-id—The unique value, or set of characters, assigned to represent a specific


f. attribute-index—The unique value, or set of characters, assigned to represent a




ENTITY-ATTRIBUTE-COMPOSITE. The example contains one of potentially many

entries that represent the rows in a Business Rule table.

Table 17. Instance Table for BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE

business-rule-id

(FK)

***-index (FK)

****-index (PK)

****-null-indicator-code

entity-id (FK)

attribute-index

(FK)

100000000026 100000000020 100000000001 NO 10000076 100002

100000000026 100000000020 100000000002 NO 10000076 100002

100000000026 100000000020 100000000003 NO 10000243 100004

100000000026 100000000020 100000000004 YES 10000243 100005

Note: *** = “business-rule-entity” Note: **** = “business-rule-entity-attribute-composite”


rule-entity-attribute-composite-(indices) are not reused. If the semantic understanding of an

business-rule-entity-attribute-composite-index has changed, then a new key should be

generated for the new business-rule-entity-attribute-composite-index. It is expected that no

new identifier with a value less than the highest used identifier (+ 1) will ever be used.

3.8.4 BUSINESS RULE ENTITY-ATTRIBUTE-COMPOSITE-DOMAIN-VALUE

3.8.4.1 BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE-DOMAIN-

VALUE is defined as ‘An identification of the specific domain value that is part of a

particular BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE.’ It is designed to

specify allowable domain-values that play a role in specifying a particular business rule.

3.8.4.2 A BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE-DOMAIN-

VALUE is identified by the primary key attributes, business-rule-id (FK), business-rule-

entity-index (FK), business-rule-entity-attribute-composite-index (FK) and business-rule-

entity-attribute-composite-domain-value-index (PK). The attributes of BUSINESS-RULE-

ENTITY-ATTRIBUTE-COMPOSITE-DOMAIN-VALUE are the following:






V3.1.4

34


BUSINESS-RULE.

c. business-rule-entity-attribute-composite-index—The unique value, or set of

characters, assigned to represent a specific BUSINESS-RULE-ENTITY-

ATTRIBUTE-COMPOSITE for a specific BUSINESS-RULE-ENTITY and to

distinguish it from all other BUSINESS-RULE-ENTITY-ATTRIBUTE-

COMPOSITEs for that BUSINESS-RULE-ENTITY.

d. business-rule-entity-attribute-composite-domain-value-index—The unique value, or

set of characters, assigned to represent a specific BUSINESS-RULE-ENTITY-

ATTRIBUTE-COMPOSITE-DOMAIN-VALUE for a specific BUSINESS-RULE-

ENTITY-ATTRIBUTE-COMPOSITE and to distinguish it from all other

BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE-DOMAIN-VALUEs for

that BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE.

e. domain-id—The unique value, or set of characters, assigned to represent a specific


f. domain-value-index—The unique value, or set of characters, assigned to represent a




ENTITY-ATTRIUBTE-COMPOSITE-DOMAIN-VALUE.

Table 18. Instance Table for BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE-DOMAIN-

VALUE


****-index (FK)

*****-index (FK)

******-index (PK)

domain-id (FK)


100000000026 100000000020 100000000001 100000000001 100000144 1000004

100000000026 100000000020 100000000002 100000000001 100000144 1000004

100000000026 100000000020 100000000003 100000000001 100004142 1000007

100000000026 100000000020 100000000004 100000000001 100000297 1000012

100000000026 100000000020 100000000004 100000000002 100000297 1000047

100000000026 100000000020 100000000004 100000000003 100000297 1000001

100000000026 100000000020 100000000004 100000000004 100000297 1000002

100000000026 100000000020 100000000004 100000000005 100000297 1000004

100000000026 100000000020 100000000004 100000000006 100000297 1000003

100000000026 100000000020 100000000004 100000000007 100000297 1000005

Note: **** = “business-rule-entity” Note: ***** = “business-rule-entity-attribute-composite”

Note: ****** = “business-rule-entity-attribute-composite-domain-value”


rule-entity-attribute-composite-domain-value-(indices) are not reused. If the semantic

understanding of an existing business-rule-entity-attribute-composite-domain-value-index

has changed, then a new key should be generated for the new business-rule-entity-attribute-

composite-domain-value-index. It is expected that no new identifier with a value less than

the highest used identifier (+ 1) will ever be used.


V3.1.4

35

3.9 CREATOR-UPDATE-IDENTIFICATION

3.9.1 CREATOR-UPDATE-IDENTIFICATION is defined as ‘A relationship of

an ENTITY and an ATTRIBUTE to identify the physical attributes for JC3IEDM

Management.’ The JC3IEDM specification allows nations to make generic

implementations. The CREATOR-UPDATE-IDENTIFICATION structure is shown in the

figure below.

Figure 7. Creator Update Identification View

3.9.2 A CREATOR-UPDATE-IDENTIFICATION is identified by the primary

key attribute, entity-id (FK) that migrates to CREATOR-UPDATE-IDENTIFICATION

under the identifying (one to many) relationship “has-creator-id-and-update-seqnr-

columns” from ENTITY. The attribute entity-id (FK) unifies with the primary key as a

result of the relationships “identifies-creator-id-column” and “identifies-update-seqnr-

column” from the entity ATTRIBUTE. The attributes of CREATOR-UPDATE-

IDENTIFICATION are the following:



b. creator-attribute-index—The attribute-index for a specific CREATOR-UPDATE-

IDENTIFICATION that identifies the creator-id of a specific record (a role name for

attribute-index).

c. update-attribute-index—The attribute-index for a specific CREATOR-UPDATE-

IDENTIFICATION that identifies the update-seqnr of a specific record (a role name

for attribute-index).


V3.1.4

36

3.9.3 The table below is an example instance table for CREATOR-UPDATE-

IDENTIFICATION.

Table 19. Instance Table for CREATOR-UPDATE-IDENTIFICATION

entity-id (FK)

creator-attribute-index

(FK)

update-attribute-

index (FK)

10000002 100004 100005

10000003 100004 100005

10000004 100010 100011

10000005 100005 100006

10000006 100007 100008


V3.1.4

37

4. JC3IEDM CONCEPTS AND PHYSICAL SPECIFICATIONS FOR

THE JC3IEDM MODEL

4.1 Metamodel CONCEPTS

4.1.1 General Properties

This section discusses general properties of the JC3IEDM metamodel.

4.1.2 Model Level

4.1.2.1 The MIRD stores the current JC3IEDM data model. However, it may hold

an additional meta data model which describes the structure of the MIRD itself. The

distinction between meta data and meta meta data is made by means of the attribute “entity-

model-level-code.” Possible values are APPL (application level, denoting a part of the

JC3IEDM), META (denoting a part of the JC3IEDM metamodel).

4.1.2.2 Only entities and domains have a model level code. The model level of

other objects, such as attributes and domain values, is determined by reference to either

entity or domain.

4.1.3 Standardization Level

4.1.3.1 Future national MIP-based command and control systems will probably also

require the exchange of non-MIP data. This can happen, for instance, when specific data

(e.g., additions to MIP “person” data) must be distributed on a national basis. Such systems

will replicate data according to an extended MIP Data Model. There will be extra entities,

attributes, etc., to cover non-MIP data. Notice that the original JC3IEDM is unaffected;

only national extensions are allowed, not modifications.

4.1.3.2 The metamodel takes into account this requirement by (optionally) making a

distinction between different standardization levels. Four basic objects in a data model—

entity, attribute, domain, and domain value—are defined at a certain level of

standardization. Two replication nodes, for example, may be able to interchange data only

down to a certain level of standardization. For instance, the nodes might specifically

support bilaterally agreed data or nationally standardized data, in addition to MIP-specified

data.

4.1.3.3 The upper level is MIP; that is, “most” standard objects are defined by MIP.

Other levels include internationally agreed (between a number of countries) data sets, and

national data sets. The lowest level of standardization is the local level, which includes data

that is only used locally at a replication node (and is never replicated to other nodes).

Values of the domain “standardisation-level-code” are: MPCO (MIP core or JC3IEDM),

INAT (international extension), NAT (national extension), LOC (local), MIP (Multilateral

Interoperability Programme) and MIPNDA (MIP-NATO Data Administration).5

4.1.3.4 The following remarks amplify standardization specifications:

a. The concept of “standardization level” enables nations to extend the JC3IEDM with

additional entities, domains, etc. (just as subfunctional areas are extensions to the

JC3IEDM). Among other developments, the Dutch system development activities

have already revealed that national extensions to the data model are highly desirable.

Although there is uncertainty as to whether the “standardization level” attribute

should be an MIP feature or a national implementation issue, the attribute has been

5 This attribute occurs for the following: ENTITY, ATTRIBUTE, DOMAIN, and DOMAIN-VALUE.


V3.1.4

38

adopted so that experience can be gained from it. Nations are free to use it or

implement similar functionality in a different way (or make no use of extensions at

all) for evaluation and experimentation.

b. Besides national extensions to the JC3IEDM, nations might decide to make additions

to the metamodel as well. For instance, nations could decide to store certain

properties (e.g., entity names and definitions) in a second language. How these

properties are maintained and integrated with the metadata coming from MIP is a

national problem.

4.1.3.5 The following provides an example. In the Netherlands (NLD), there is a

requirement to store more information about persons than is done in MIP; an example is

“blood group.” Subtypes of ORGANISATION-TYPE other than “unit” may be needed by some

nation, for example an “agency.” The Dutch MIP-based command and control systems will

be based upon an extended MIP Data Model. A new attribute “blood-group-code” is added

to PERSON. A new domain for this attribute is added as well. Furthermore, a new subtype

entity NL-AGENCY is connected to ORGANISATION-TYPE. The domain of “organisation-

type-category-code” is extended (e.g., to include “NL-AG”). The Dutch dictionary now

contains a mixture of pure MIP data model objects and additional NL-specific data model

objects. The distinction between MIP and NLD features is made by means of the

standardization level.

4.1.4 Key Management

4.1.4.1 The five base (primary) key attributes contained in the metamodel described

above must fulfil the rules of MIP key management (MIP Implementation Rules (MIR)

Annex D). This is necessary because the five concepts they represent—entity, attribute,

business rule, domain and domain value—will be managed by more than one organisation.

At the MIP level and at national levels, objects such as these will be created and

maintained. In order to avoid clashes in key values, special rules are applicable.

4.1.4.2 The following base attributes are subject to MIP key management rules to

ensure that they are unique world wide: entity-id, attribute-index, business-rule-id,

domain-id, and domain-value-index.

4.1.4.3 New identifier values are only created for base key attributes. For instance,

RELATIONSHIP.parent-entity-id always refers to an existing, already created ENTITY.entity-

id. Therefore, the foreign key attributes derived from these five base key attributes are not

part of the list.

4.1.4.4 The remaining base key attributes in the metamodel (business-rule-entity-

index, business-rule-entity-attribute-composite-index, business-rule-entity-attribute-

composite-domain-value-index, relationship-index, category-relationship-index, and

alternate-key-index) can be assigned any value but should never reuse an old index

number.

4.1.5 Physical Properties

4.1.5.1 Physically (i.e., in database terms), a data model is described by the

following properties spread over the metamodel:

a. Table name (ENTITY)

b. Column name (ATTRIBUTE)

c. Datatype (BASE-ATTRIBUTE)


V3.1.4

39

d. Optionality (NON-KEY-ATTRIBUTE).

4.1.5.2 The JC3IEDM makes use of these properties to handle replicated data.

4.2 Physical Abbreviations

4.2.1 The table below shows the class words available for use in the JC3IEDM

Metamodel and their physical abbreviations.

Table 20. Class Word Abbreviations

Class Word Physical Abbreviation

amount amt

angle angle

binary object binobj

code code

coordinate coord

count cnt

datetime dttm

dimension dim

duration dur

identifier / id id

index ix

ordinal ord

quantity qty

rate rate

ratio rat

temperature tmpr

text txt

4.2.2 The abbreviations in the table below are used in the JC3IEDM metamodel for

entity and attribute names:

Table 21. JC3IEDM Metamodel Logical Term Abbreviations

Logical Term Physical Abbreviation

ALTERNATE alt

alternate-key-attribute ak_attr

ATTRIBUTE attr

BUSINESS-RULE br

cardinality card

child ch

composite comp

column col

completeness compl6

cross-reference xref

datatype daty

decimals dec

definition def

dependency depen

document doc

domain dom

6 The abbreviation ‘compl’ is also used in the JC3IEDM Metamodel to represent the tem “completion”. It is

recommended to not change either abbreviation unless there is a conflict within one model, either JC3IEDM

or JC3IEDM Metamodel.


V3.1.4

40

Logical Term Physical Abbreviation

domain-value dom_val

entity ent

foreign-key fk

hierarchy hier

identifying ident

inverse inv

length len

measurement meas

migrating migr

model mod

non-key nk

optionality opt

parent pa

primary-key pk

reference ref

relationship rel7

restriction restr

rolename rona

sequence-number seqnr

source src

standardisation stdn

status stat

storage-type-code stg_type_code

subtype-relationship subt_rel

super sup

table tab

unifying unif

unique uniq

value val

4.2.3 While not included in the JC3IEDM metamodel, every entity of JC3IEDM

has the following two physical attributes:

a. creator identifier of the tuple (creator_id)—The unique value, assigned to represent a

specific proprietor of a certain data item (record) that is responsible for maintaining

that data item. At present, the grammar assumes the creator_id is <padded no. 20>.

b. update_sequence_number (formerly known as “timestamp”; update_seqnr)—An

absolute sequence number, assigned to represent the validity (in terms of seniority) of

a certain data item. It is a national implementation issue to define a strategy which

ensures, that the update_sequence_number is always set to a larger value than the last

one used, when updating a data item in the JC3IEDM. MIP suggests using the current

time for the update_sequence_number value using the format:

YYYYMMDDHHMMSS.

7 The abbreviation ‘rel’ is also used in the JC3IEDM Metamodel to represent the tem “relative”. Because this

term is critical and extensively used, it is recommended to not change either abbreviation unless there is a

conflict within one model, either JC3IEDM or JC3IEDM Metamodel.


V3.1.4

A-1

Annex A: JC3IEDM Metamodel—

GLOSSARY


V3.1.4

A-1

1 R IRISH The Royal Irish Rangers

AAP NATO Standardisation Agreements and Allied Publications

AAP Allied Administrative Publication

AAP-6 Allied Administrative Publication N° 6 - NATO Glossary of Terms and Definitions

ABCA The America, Britain, Canada, Australia (ABCA) Armies Program is an armies

interoperability forum the purpose of which is to optimize interoperability through

cooperation and collaboration in the continuous pursuit of standardization and mutual

understanding in order to integrate the capabilities of the ABCA Armies in coalition

operations

AC Active Status

ACE Allied Command Europe

ACK Acknowledgement

ACO Airspace Control Order / Allied Command for Operations

ACP Allied Communications Publication

ACS Automated Channel Selection

ACSE Association Control Service Element

ACT Allied Command Transformation

ACT DAO Allied Command Transformation, Data Administration Office

AD Air Defence

ADatP–3 Allied Data Publication Message Formats

ADM ATCCIS Data Model

ADMD Administration Management Domain

AEngrP Allied Engineering Publication

AFNORTH Allied Forces Northern Region

AFS ADatP-3 Formatting Staff

AFV Armoured Fighting Vehicle

AH Attack Helicopter

AI Air Interdiction

AICM Aeronautical Information Conceptual Model

AIntP-3 Allied Intelligence Publication 3

AIRCENT Allied Air Forces Central Europe

AMLESB Additional Military Layers - Environment Seabed and Beach

AN Access Node

ANSI American National Standards Institute

AOI Area of Interest

AOR Area of Responsibility

APC Armoured personnel carrier

APDU Application Protocol Data Unit

API Application Programming Interface

APP Allied Procedural Publication

APPL Application

APP-10 Allied Procedural Publication N° 10 - NATO Interoperability Document

APP-6A Allied Procedural Publication N° 6A - Military symbols for Land Based Systems

APP-9 Allied Procedural Publication N° 9 - Compendium of Allied Forces Messages

AR Armored – US designation / Army Regulation

ARM ATCCIS Replication Mechanism

Armd Armoured

ARP Address Resolution Protocol

ARRC ACE Rapid Reaction Corps

Arty Artillery

ASAP Application service access point

ASCA Artillery Systems Cooperation Activities

ASCII American Standard Code for Information Interchange

ASN.1 Abstract Syntax Notation 1

ASSOCMAN Association Manager

ASUW Anti Surface Warfare

ASW Anti-submarine warfare


V3.1.4

A-2

ATacCS Army Tactical Computer System

ATCCIS Army Tactical Command and Control Information System

ATCCS Army Tactical Command and Control System (USA)

ATCP Air Traffic Control Procedures

ATP Allied Technical Publication

ATP-35(B) Allied Tactical Publication 35(B) - Land Forces Tactical Doctrine

AUS Australia

AUT Austria

AUTOKO AUTOmatisiertes KOmmunikationsnetz

AWG ATCCIS Working Group

BAI Battlefield air interdiction

Bde Brigade

BE Basic Encyclopedia - a target numbering scheme

BEL Belgium

BFV Bradley Fighting Vehicle

BG Battle Group (Equivalent to a US Battalion)

BGR Bulgaria

BICES Battlefield Intelligence Collection and Exploitation System

BIGSTAF Breitbandiges Integriertes Gefechtsstandfernmeldenetz

BIP Battlefield Interoperability Programme

BiSC Bi Strategic Commands (NATO)

BL Baseline

BMHS BIP Message Handling System

BMP Russian fighting vehicle

BMS Battlefield Management System

Bn, BN Battalion

BOA Basic Object Adaptor

BPD Boundary Protection Device

Bty Battery

C Conditional

C2 Command and Control

C2IEDM Command and Control Information Exchange Data Model (formerly named LC2IEDM)

C2IS Command and Control Information Systems

C2S Command and Control System

C3 Command, Control and Communications / Consultation, Command, and Control [NATO

usage]

C4I DTF Object Management Group (OMG) C4I Domain Task Force

CAN Canada or Canadian

CAS Close Air Support

CASP Coordinated Air Sea Procedure

CAV Cavalry

CBRN Chemical, Biological, Radiological and Nuclear

CBT Combat

CCEB Combined Communication Electronic Board

CCIR Commander's Critical Information Requirements

CCIS Command and Control Information System

CCWG Configuration Control Working Group

CDC Center for Disease Control

CE Combined Endeavour

CEE Common Engineering Environment

CEOI Communication and Electronic Operating Instruction

CET Combat Engineer Tractor

CFCS Command and Fire Control System

CFE Conventional Forces Europe

cGY Centigray

CIS Communications and Information System


V3.1.4

A-3

CJTF Combined & Joint Task Force

CM Configuration Management

CMBG Combat Brigade Group (CAN)

CMO Civil/Military Operations

CMSR Configuration Management Status Report

CN Change Notice

CNR Combat Net Radio

COD Concise Oxford Dictionary

COI Community of Interest

COLOC Change of Location of Command

COMMS Communications

COMSEC Communication Security

COP Common Operational Picture

CORBA Common Object Request Broker Architecture

CoStEx Command and Staff Exercise

COTS Commercial Off The Shelf

Coy, COY Company

CP Change Proposal

CP Command Post

CPX Command Post Exercise

CRC Cyclic Redundancy Check

CRLF Carriage Return Line Feed

CRO Crisis Response Operations

CSMA/CD Carrier Sense Multiple Access / Collision Detection

CWID Coalition Warrior Interoperability Demonstration

CZE Czech Republic

DAFIF Digital Aeronautical Flight Information File

DB Database

DBA ADatP-3 Data Base Administrator

DDDS Defense Data Dictionary System (USA)

DDL Database Definition Language / Data Definition Language

DEM Data Exchange Mechanism

DEMS Data Exchange Mechanism Schema

DES Data Exchange Schema

DEU Germany or German

DIGEST Digital Geographic Exchange Standard

Div, DIV Division

DMSWG Data Management Services Working Group (formerly NDAG)

DMWG Data Modelling Working Group

DNK Denmark

DoD Department of Defense (USA)

DOS Day of supply

DP Data Provider

DPC Defence Planning Committee (NATO)

DR Data Receiver

DSN Delivery Status Notification

DSP Digital signal processor

DTG Day Time Group

E.G. Exempli Gratia – As Example

ECCM Electronic Counter – Counter Measures

ECM Electronic Counter Measures

ED50 European Datum 50

E-IARRCIS Enhanced Interim ARRC Information System

EID Experimental Interoperability Database

E-Mail Electronic Mail

EMC Electro-Magnetic Compatibility


V3.1.4

A-4

EMCON Emission Control

Engr Engineer, Engineering

ENVID Envelope ID

EOD Explosive Ordnance Disposal

EoS Element of Service

EQPMT Equipment

ER Entity Relationship

ERWIN CaseTool ER=entity-relationship WIN=Windows-based

ERwin ™ IDEF1X software tool from Computer Associates (Versions 3.5.2 and 4.1.4 SP3)

ESMTP Extended Simple Mail Transfer Protocol

ESP Spain

ETA Estimated Time of Arrival

EUROFOR European Force

EW Electronic Warfare

EXCON Exercise Control

FA Field Artillery

FAA Federal Aviation Administration

FAAP/CG Federal Aviation Administration Pilot/Controller Glossary

FACC Feature and Attribute Coding Catalog (Volume 4 of the DIGEST standard)

FAFCISO Federal Armed Forces CIS Organization

FBI Federal Bureau of Investigation (USA)

FD Field Demonstration

FFIR Friendly Forces Information Requirements

FFIRN Field Format Index Reference Number

FUD Field Use Designator

FH Frequency Hopping

FIBE Field Initiated Basic Encyclopedia—a target numbering scheme

FIMU Fleet Information Management Unit (Royal Navy – GBR)

FIN Finland

FIPS Federal Information Processing Standard (USA)

FK Foreign Key (a key inherited by a child entity from a parent entity)

F-Kill Firepower Kill (criterion)

FLET Forward line of enemy troops

FLIP Flight Information Publications

FLOT Forward Line Own Troops

FM Field Manual

FORMETS NATO Message Text Formatting System

FRA France or French

FS Fire Support

FSCL Fire Support Coordination Line

FTP File Transfer Protocol

FUD Field Use Designator

FUDN Field Use Designator Number

FUI Field Use Identifier

GBR United Kingdom of Great Britain and Northern Ireland

GeFüSys Gefechtsfeldführungssystem

GEL Generic Event List

GEW Global Early Warning

GH Generic Hub Data Model - ATCCIS

GIE Global Information Environment

GIS Geographic Information System

GOIDG General Officers International Digitization Group

GPOC Gateway Point of Contact

GRC Greece

GW Gateway

HCDR High Capacity Data Radio


V3.1.4

A-5

HDRS Headers

HEROS Heeresführungsinformationssystem für rechnergestützte Operationsführung in Stäben

(GER)

HF High Frequency

HICON Higher Controller

HoD Head of Delegation

HQ Headquarters

HQ AFCENT Headquarters Allied Forces Central Europe

HQ AFSOUTH Headquarters Allied Forces Southern Europe

HQ ARRC Headquarters ACE Rapid Reaction Corps

HQ EUROCORPS Headquarters European Corps

HRF/LRF High Readiness Forces / Low Readiness Forces

HTML Hyper Text Markup Language

HTTP Hyper Text Transfer Protocol

HUMINT Human Intelligence

HUN Hungary

HW Hardware

I.E. Id Est - Such As

I/O Input / Output

IA5 International Alphabet Number 5 (also known as ASCII)

IAD Interface Adapter Device

IAW In Accordance With

ICAM Integrated Computer-Aided Manufacturing

ICAO International Civil Aviation Organisation

ICE Information Content Element

Id Identification; Identifier

ID Infantry division (e.g., 25ID)

IDEF Integrated Computer-Aided Manufacturing (CAM) Definition (Language)

IDEF1X IDEF for Data Modelling

IDEF1X ICAM Definition Language 1. Extension

IDL Interface Definition Language

IED Improvised Explosive Device

IEEE Institute of Electrical and Electronic Engineers

IEM Information Exchange Mechanism

IER Information Exchange Requirement

IEW Intelligence Electronic Warfare

IFF Identification Friend/Foe

IFR Instrument Flight Rules

IMC Information Management Cell

IMINT Imagery Intelligence

IMO International Maritime Organisation

IMS International Military Staff

IN Inactive (status)

Inf, INF Infantry

INFOSEC Information Security

INTSUM Intelligence Summary

IOB Inter-Operability Branch

IOF Input/Output Facility

IOT&E Initial Operational Test & Evaluation

IP Internet Protocol, ISO/OSI level 3

IPM Interpersonal Messaging

IPMS Interpersonal Messaging System

IR Incident Report

IRD Information Resource Dictionary

IRDS Information Resource Dictionary Standard

IRRB IR Review Board

ISDN Integrated Services Digital Network


V3.1.4

A-6

ISO International Organisation of Standardisation

ISO/OSI/IEC International Standardisation Organisation/ Open Systems Interconnection/ International

Electrotechnical Commission

ISSC Information System Sub-Committee

ITA Italy or Italian

ITR Initial Technical Review (CP at AFS or DBA)

ITU International Telecommunication Union

JAG-T JC3IEDM Annex Generation Tool

JC3IEDM Joint C3 (Consultation, Command, and Control) Information Exchange Data Model

(formerly named C2IEDM)

JC3RCSC Joint C3 Requirements and Concepts Sub-Committee

JCS Joint Chiefs of Staff

JCS Pub Joint Chiefs of Staff Publication (USA)

JSB Joint Service Board

JSP Joint Services Publication (GBR)

JTF Joint Task Force

JWID Joint Warrior Interoperability Demonstration (renamed to CWID in 2005)

KBS Kilobits per second

K-Kill Permanent Kill (“unserviceable” criterion)

LAN Local Area Network

LARS Multiple rocket launcher

LASH Lighter Aboard Ship

LC Line of contact

LC2IEDM Land Command and Control Information Exchange Data Model (formerly named Generic

Hub 4)

LC2IS Land Command and Control Information System

LCIS Land Common Interoperability System

LFC2IS Land Forces Command and Control System

LFCS Land Forces Command System

LFRIL Land Forces Reportable Item List (NATO)

LG.1 Land Group 1 (of the NATO Army Armaments Group - NAAG)

LLAPI Low Level Air Picture Interface

LLC Logical Link Control

LO Liaison Officer

LOCON Lower Controller

LOWG Land Operational Working Group

LTU Lithuania

M01 DEM incremental update management data exchange PDU

M02 DEM bulk management data exchange PDU

M03 DEM catalogue bulk management data exchange PDU

MA 1) Management and 2) Mandatory

MAS NATO Military Agency for Standardisation

MBN MIP Briefing Notes

MBP MIP Block Plan

MBPT MIP Boiler Plate Text

MBT Main Battle Tank

MBxTP MIP Block x Test Plan (x is for the Block it’s written for)

MCCIS Maritime Command and Control Information System

MCDM MIP Common Data Model

MCI MIP Common Interface

MCLiP MIP Communications and Liaison Plan

MCMP MIP Configuration Management Plan

MCS Maneuver Control System (USA)

MDP MIP Development Plan

MDWP Multi Disciplinary Working Party (MIP)

MEBxR MIP End Of Block x Report (x is for the Block it’s written for)

MEDP MIP Exercise and Demonstration Plan


V3.1.4

A-7

MEI Message Exchange Interface

MEL Main Events List

MEM Message Exchange Mechanism

MET Meteorology, Meteorological

MFI Mandatory For Implementation

MG Multinational agreement

MGA CP MG agreed

MGS CP in MG Staffing process MTFWG

MHS Message Handling System

MI Military intelligence

MIC Multinational Interoperability Council

MIE Military Information Environment

MIF MIP Integrated Framework

MIL-STD-2525B US Mil Standard, Common Warfighting Symbology, version B dd 30 Jan 1999

MIME Multipurpose Internet Mail Extensions

MIP Multilateral Interoperability Programme

MIP Baseline List MIP Baseline Documents Status List

MIP CONOPS MIP Concept of Operations

MIP Doc Reg MIP Document Register

MIP Glos MIP Glossary

MIP IEDM MIP Information Exchange Data Model

MIP POC MIP Point of Contact List

MIPS MIP Integrated Programme Schedule

MIPSYSMAN MIP System Management (message)

MIR MIP Implementation Rules

MIRD MIP Information Resource Dictionary

M-Kill Mobility Kill (criterion)

MLC Military Load Classification

MLRS Multiple Launch Rocket System

MMHSWG Military Message Handling Services Working Group

MNC Multinational Corps

MND Multi-National Division

MNMB MIP – NATO Management Board

MOA Memorandum of Agreement

MOD Ministry of Defence

MOH MIP Operational Handbook

MOL MIP Official Library

MOLT MIP Operational Level Test Specification

MOOTW Military Operations Other Than War

MOP MIP Operating Procedures

MOPP Mission Oriented Protective Posture

MOU Memorandum of Understanding

MPA Military Patrol Aircraft

MPMP MIP Programme Management Plan

MPR MIP Problem Report

MPRL MIP Program Risk List

MPRRB MPR Review Board

MPRT MIP Problem Report Tool (aka MIPzilla, Bugzilla)

MRMP MIP Risk Management Plan

MRS MIP Reference System

MS Message Store / MIP Solution

MSB MIP Standard Briefing

Msg Message

MSG MIP Steering Group

MSISP MIP System Interconnections Security Policy

MSLT MIP System Level Test Specification


V3.1.4

A-8

MTA Message Transfer Agent

MTBF Mean Time Between Failure

MTC MIP Test Controller

MTEMP MIP Test and Evaluation Master Plan

MTF Message Text Format / Medical Treatment Facility

MTFWG Message Text Format Working Group

MTFWG CM Plan Message Text Format Working Group Configuration Management Plan

MTIDP MIP Technical Interface Design Plan

MTIR MIP Tactical C2IS Interoperability Requirement

MTM Message Transfer Mechanism

MTP MIP Test Plan

MTS Message Transfer System

MTTP MIP Technical Test Plan

MTTR Mean Time To Repair

MTWP MIP Testing Working Party

MVS MIP Vision and Scope

MWAOP MIP WEB Site Administration and Operating Procedures

MWTU Mine Warfare Training Unit (Royal Navy - GBR)

NAAG NATO Army Armaments Group

NAD Network Architecture Diagram

Narr Narrative

NATO North Atlantic Treaty Organisation

NBAC Narrow body civilian aircraft

NBC Nuclear, Biological and Chemical

NC3A NATO Consultation, Command, and Control Agency

NC3B NATO Consultation, Command, and Control Board

NC3O NATO Consultation, Command, and Control Organization

ND National Division

NDAG NATO Data Administration Group (now DMSWG)

NEGACK Negative Acknowledgement

NEO Non-combatant Evacuation Operations

NFFI NATO Friendly Force Identifier

NGA National Geospatial and Intelligence Agency

NGF Naval gunfire

NHQC3S NATO Headquarters Consultation, Command, and Control Staff

NHQC3S/IOB NATO Headquarters Consultation, Command, and Control Staff / Interoperability Branch

NI Not Implemented

NII National Implementation Issue

NIETWG NATO Interoperability Testing Working Group

NIMP NATO Interoperability Management Plan

NIPD NATO Interoperability Planning Document

NLD The Netherlands

NOR Norway

NOSWG NATO Opens Systems Working Group

NPIS NATO Procedural Interoperability Standards

NRT Nearly Real Time

NTDI NATO Target Data Inventory

O/R Originator/Recipient

OBJ Objective

OC Operation Centre

OCL Object Constraint Language

OED Oxford English Dictionary

OIG Operational Information Groups

OLT Operational Level Test

OMG Object Management Group

OMT Object Modelling Technique


V3.1.4

A-9

OO Object Oriented

OOB Order of Battle

OOTW Operations Other Than War

Op Eval Operational Evaluation

OPCOM Operational Command

OPCON Operational Control

OPFOR Opposing Forces

OPLAN Operations Plan

OPORDER Operations Order

ORB Object Request Broker

ORBAT Order of Battle

Org Organization

OSI Open Systems Interconnection

OT Object Technology

OWG Operational Working Group

P1 A special X.400 protocol

PDAU Physical Delivery Access Unit

PDU Protocol Data Unit

PIR Prioritized Information Requirements

PL Phase Line

PM Project Manager

PMG Program Management Group (MIP)

POL Petroleum, Oil, and Lubricant

POL Poland

POSACK Positive Acknowledgement

POW Prisoner of War

PPP Point-to-Point-Protocol

PRMD Private Management Domain

PRT Portugal

PSO Peace Support Operations

PUB Publication

QACISG Quadrilateral Army CIS Interoperability Group

QACISIG Quadrilateral Army Communications and Information systems Interoperability Group

QIOP Quadrilateral Interface Operational Procedures (QIP Program)

QIP Quadrilateral Interoperability Programme

QMHS QIP Message Handling System

QSTAG Quadripartite Standardization Agreement

QTIDP QIP Technical Interface Design Plan

RCPT Receipt to

RDBMS Relational Data Base Management System

RDC Replication Domain Composite

RDT Replication Domain Type

RDU Replication Domain Union

Recce Reconnaissance

REF Reference

REPMAN Replication Manager

RET Return

RFC Request for Comments

RFC 822 Part of SMTP Message Text Format

RFD Request For Deviation

RFW Request For Waiver

Rgt, REGT Regiment

Rh Rhesus factor in blood typing

RHA Royal Horse Artillery (GBR)

RHQ Regional Headquarters

RIC Reportable Item Code


V3.1.4

A-10

RIP Routing Information Protocol

RITA Réseau Intégré de Transmissions Automatiques (FRA)

RLC Royal Logistics Corp

RMKS Remarks

ROE Rules of Engagement

ROU Romania

RPC Remote Procedure Call

RTR The Royal Tank Regiment (GBR)

RTSE Reliable Transfer Service Element

S&F Store and Forward

SA Situational Awareness

SACEUR Supreme Allied Commander Europe

SAN Secondary Access Node

SAP Service Access Point

SATCOM Satellite Communications

SC/n Subcommittee/number

SCRA(T) Single Channel Radio Access (Terminal)

SEAWG Systems Engineering & Architecture Working Group

SEI Software Engineering Institute from Carnegie Mellon University

SHAPE Supreme Headquarters Allied Powers Europe

SHAPE DAO Supreme Headquarters Allied Powers Europe, Data Administration Office

SHORAD Short Range Air Defence

SIACCON Sistema Automatizzato di Comando e Controllo (ITA)

SICF Système d’Information pour le Commandement des Forces (FRA)

SIGINT Signals Intelligence

SIMACET SIstema de Mando y Control para el Ejército de Tierra (ESP)

SINCE Simulation and C2 Information System Connectivity Experiment

SIR Système d’Information Régimentaire (FRA)

SLIERP Senior Land Information Exchange Requirements Panel

SLT System Level Test

SME Subject Matter Expert

SMTP Simple Mail Transfer Protocol

SNR (A) Senior National Representatives (Army)

SNR (C3) Senior National Representatives (C3)

SOHB Staff Officers Handbook (GBR)

SOI Statement of Intent

SOP Standard Operating Procedures

SOTRIN Sottosistema di Trasmissioni Integrate

SPN Self-Protecting Node

SQL Structured Query Language (ISO)

Sqn Squadron

SRS [Software or System] Requirements Specifications

SSP System Security Policy

STANAG NATO STANdardisation AGreement

Std Standard

STGP Shared Tactical Ground Picture

SUT System Under Test

SVN Slovenia

SW Software

SWE Sweden

SYS ACK System Acknowledgement

SYS MAN (MIP) System Management (message)

SYS NAK System Negative Acknowledgement

TAA Tactical Assembly Areas

TACCIS Tactical Area Command and Control Information System

TASK ORG Task Organisation


V3.1.4

A-11

TBD To be Done / To be Decided / To be Determined

TCP Transmission Control Protocol

TCP/IP Protocol used within TCP/IP (Transfer Control Protocol/Internet Protocol) wide area

networks

TEL Transporter erector launcher

TEWG Test and Evaluation Working Group

TFMAN Transfer Facility Manager

TFTP Trivial File Transfer Protocol

Tgt Target

TIDP Technical Interface Design Plan

TMHS Tactical Message Handling System

TOA Transfer Of Authority

TOC Tactical Operations Centre

TOE Table of Equipment

TOO Table of Organisation

TOP WG Land Forces Tactical Doctrine and Operational Procedures Working Group

ToR Terms of Reference

TP2K TACOM Post-2000

TTP Tactics, Techniques and Procedures

TTSpec Technical Test Specification

TUR Turkey

TWG Technical Working Group

UA User Agent

UDP User Datagram Protocol

UK United Kingdom

UN United Nations

USA United States of America

USMTF United States Message Text Format

UTC Coordinated Universal Time

UTM Universal Transverse Mercator

UTO Unit Task Organisation

UTP Unshielded Twisted Pair

UXO Unexploded Ordnance

VFR Visual Flight Rules

VHF Very High Frequency

WAN Wide Area Network

WBAC Wide Body Civilian Aircraft

WG(s) Working Group(s)

WGS-84 World Geodetic System 1984 (reference standard)

WHO World Health Organisation

WP Working Paper

WP(s) Working party(s)

WTD 81 Wehrtechnische Dienststelle 81

WWW World Wide Web

X01 DEM Incremental Update Data Exchange PDU

X02 DEM Full Bulk Data Exchange PDU

X03 DEM Aborted Update PDU

X.400 CCITT/ITU Recommendation for Message Handling Systems

X25 Protocol used within ISO standard X25 based networks

X400 Protocol used within ISO standard X400 based networks

XDR External Data Representation

XML Extensible Markup Language

Y2K Year 2000


V3.1.4

B-1

Annex B: JC3IEDM Metamodel—

ENTITY DEFINITIONS AND ATTRIBUTES


V3.1.4

B-2

(This page intentionally left blank)


V3.1.4

B-3

Annex B. JC3IEDM Metamodel—

ENTITY DEFINITIONS AND ATTRIBUTES

Entity Name Entity Definition Attribute Name

ALTERNATE-KEY A record that points to one or more attributes that collectively serve as a unique identification for an entity that is cited in a specific ENTITY and may be used instead of the PRIMARY-KEY for the same instance of ENTITY.

entity-id (PK) (FK)

alternate-key-index (PK)




The association of a specific ALTERNATE-KEY with a specific ATTRIBUTE that identifies the participation of the ATTRIBUTE as part of ALTERNATE-KEY.

entity-id (PK) (FK)

attribute-index (PK) (FK)

alternate-key-index (PK) (FK)

ATTRIBUTE A record that specifies the metadata characteristics of an attribute for an entity that is described in a specific ENTITY.

entity-id (PK) (FK)

attribute-index (PK)

attribute-name-text

attribute-column-name-text

attribute-sequence-number-ordinal




BASE-ATTRIBUTE An ATTRIBUTE that is native to the entity referenced by the specific ENTITY.

entity-id (PK) (FK)






domain-id (FK)

BUSINESS-RULE A grouping of operationally related business restrictions.

business-rule-id (PK)






BUSINESS-RULE-ENTITY An identification of a specific entity that is the focus of a particular BUSINESS-RULE.

business-rule-id (PK) (FK)

business-rule-entity-index (PK)



An identification of a specific attribute that is the focus of a particular BUSINESS-RULE-ENTITY.


business-rule-entity-index (PK)(FK)

business-rule-entity-attribute-composite-index (PK)


entity-id (FK)



An identification of the specific domain value that is part of a particular BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE.


business-rule-entity-index (PK)(FK)

business-rule-entity-attribute-composite-index (PK)(FK)

business-rule-entity-attribute-composite-domain-value-index (PK) domain-id (FK) domain-value-index (FK)

CARDINALITY-RELATIONSHIP

A one-way RELATIONSHIP that identifies a specific “parent” ENTITY with a specific “child” ENTITY where the child is a dependent ENTITY whose set of key attributes may differ from the set of key attributes of the parent.

parent-entity-id (PK) (FK)

child-entity-id (PK) (FK)

relationship-index (PK) (FK)

cardinality-relationship-verb-name-text

cardinality-relationship-inverse-verb-name-text

cardinality-relationship-identifying-indicator-code

cardinality-relationship-parent-cardinality-code

cardinality-relationship-child-cardinality-code

cardinality-relationship-child-minimum-cardinality-count

cardinality-relationship-child-maximum-cardinality-count


V3.1.4

B-4

CATEGORY-RELATIONSHIP Representation of the information required to define a subtype for a specific ENTITY.

super-entity-id (PK) (FK)

category-relationship-index (PK)

category-relationship-definition-text


category-relationship-completeness-indicator-code

CREATOR-UPDATE-IDENTIFICATION

A relationship of an ENTITY and an ATTRIBUTE to identify the physical attributes for JC3IEDM Management.

entity-id (PK) (FK)

creator-attribute-index (FK)

update-attribute-index (FK)

DOMAIN A record that specifies the collective metadata characteristics for a set of values to be associated with a specific data element.

domain-id (PK)

domain-name-text









DOMAIN-VALUE A valid data instance cited for a specific DOMAIN.

domain-id (PK) (FK)

domain-value-index (PK)

domain-value-description-text

domain-value-name-text


domain-value-type-code



ENTITY A record that specifies the metadata characteristics of an entity from a data model for which metadata is being recorded.

entity-id (PK)

entity-name-text

entity-table-name-text



entity-depth-count




FOREIGN-KEY-ATTRIBUTE An ATTRIBUTE that has been migrated under a RELATIONSHIP from the primary key of the "Parent" ENTITY of that RELATIONSHIP.

host-entity-id (PK) (FK)







base-entity-id (FK)


unifying-attribute-index (FK)

NON-KEY-ATTRIBUTE An ATTRIBUTE used to provide a descriptive data element of instances of the ENTITY to which the ATTRIBUTE belongs and that is not a member of the primary key of that ENTITY.

entity-id (PK) (FK)



PRIMARY-KEY-ATTRIBUTE An ATTRIBUTE used to provide the unique identifier(s) of an instance of the ENTITY to which the attributes belong.

entity-id (PK) (FK)


RELATIONSHIP The association of one instance of ENTITY (the "Parent” ENTITY) with another (the "Child" ENTITY) that describes the degree and nature of the association.

parent-entity-id (PK) (FK)

child-entity-id (PK) (FK)

relationship-index (PK)


SUBTYPE-RELATIONSHIP A RELATIONSHIP that identifies a child ENTITY whose primary key is identical to the primary key of the parent ENTITY and which inherits all of the properties of the parent ENTITY.

super-entity-id (PK) (FK)

sub-entity-id (PK) (FK)

relationship-index (PK) (FK)


domain-id (FK)



V3.1.4

C-1

Annex C: JC3IEDM Metamodel—

ATTRIBUTE DEFINITIONS


V3.1.4

C-2



V3.1.4

C-3

Annex C. JC3IEDM Metamodel—

ATTRIBUTE DEFINITIONS8

Attribute Name Opt Entity Usage Attribute Definition

alternate-key-index MA ALTERNATE-KEY ALTERNATE-KEY-ATTRIBUTE

The unique value, or set of characters, assigned to represent a specific ALTERNATE-KEY for a specific ENTITY and to distinguish it from all other ALTERNATE-KEYs for that ENTITY.


MA ALTERNATE-KEY The numeric value that represents the alternate key or inversion key in the ENTITY.


MA ALTERNATE-KEY The specific value that denotes whether the alternate key or inversion key is unique.

attribute-column-name-text MA ATTRIBUTE The character string assigned to represent the ATTRIBUTE as a specific physical column within a table.


MA ATTRIBUTE The specific value that denotes whether the ATTRIBUTE plays the role of a foreign key in the ENTITY and thereby owned by another ENTITY.

attribute-index MA ALTERNATE-KEY-ATTRIBUTE ATTRIBUTE BASE-ATTRIBUTE BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE FOREIGN-KEY-ATTRIBUTE NON-KEY-ATTRIBUTE PRIMARY-KEY-ATTRIBUTE

The unique value, or set of characters, assigned to represent a specific ATTRIBUTE for a specific ENTITY and to distinguish it from all other ATTRIBUTEs for that ENTITY.

attribute-name-text MA ATTRIBUTE The character string assigned to represent a specific attribute.


MA ATTRIBUTE The specific value that denotes whether an ATTRIBUTE plays the role of part of the primary key in the ENTITY to which it belongs.


OP ATTRIBUTE The integer value that represents the specific physical position of the attribute inside the entity.


MA ATTRIBUTE The specific value that represents the level of common agreement for the ATTRIBUTE.


OP BASE-ATTRIBUTE The numeric value representing the number of positions to the right of the decimal point for attributes that are expressed as real numbers.


MA BASE-ATTRIBUTE The numeric value representing the maximum number of characters permitted for a value of the attribute.


MA BASE-ATTRIBUTE The specific value that represents the technical form (datatype or syntax) for the attribute.

base-attribute-definition-text MA BASE-ATTRIBUTE The character string assigned to represent the definition of a specific BASE-ATTRIBUTE.

base-attribute-index MA FOREIGN-KEY-ATTRIBUTE The attribute-index that identifies the base attribute for the foreign key (a role name for attribute-index).

base-entity-id MA FOREIGN-KEY-ATTRIBUTE The entity-id that identifies the base entity for the foreign key (a role name for entity-id).

business-rule-category-code MA BUSINESS-RULE The specific value that represents the class of BUSINESS-RULE as text or a formal rule.

business-rule-definition-text OP BUSINESS-RULE The character string assigned to specify the BUSINESS-RULE. The purpose of this attribute is to enable cross-referencing to an external document.


MA BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE-DOMAIN-VALUE

The unique value, or set of characters, assigned to represent a specific BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE-DOMAIN-VALUE for a specific BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE and to distinguish it from all other BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE-DOMAIN-VALUEs for that BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE.


MA BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE-DOMAIN-VALUE

The unique value, or set of characters, assigned to represent a specific BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE for a specific BUSINESS-RULE-ENTITY and to distinguish it from all other BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITEs for that BUSINESS-RULE-ENTITY.

8 The second column indicates the optionality of the attribute: MA for mandatory (non-null) and OP for

optional (null allowed).


V3.1.4

C-4



MA BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE

The specific value that indicates whether the attribute cited in BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE is permitted to be unspecified within the specific BUSINESS-RULE.

business-rule-entity-index MA BUSINESS-RULE-ENTITY BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE-DOMAIN-VALUE

The unique value, or set of characters, assigned to represent a specific BUSINESS-RULE-ENTITY for a specific BUSINESS-RULE and to distinguish it from all other BUSINESS-RULE-ENTITYs for that BUSINESS-RULE.

business-rule-id MA BUSINESS-RULE BUSINESS-RULE-ENTITY BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE-DOMAIN-VALUE

The unique value or set of characters, assigned to represent a specific BUSINESS-RULE and to distinguish it from all other BUSINESS-RULEs.

business-rule-name-text MA BUSINESS-RULE The character string assigned to represent the BUSINESS-RULE.


MA BUSINESS-RULE The character string assigned to identify the section of the document describing the BUSINESS-RULE. The purpose of this attribute is to enable cross-referencing to an external document.


OP BUSINESS-RULE The character string assigned to identify the table in the document that corresponds to the BUSINESS-RULE. The purpose of this attribute is to enable cross-referencing to an external document.


MA CARDINALITY-RELATIONSHIP

The specific value that represents the range in the number of occurrences associated with the child entity in the CARDINALITY-RELATIONSHIP represented.


OP CARDINALITY-RELATIONSHIP

The integer value that represents the number of the maximum exact cardinality associated with the child entity in the CARDINALITY-RELATIONSHIP represented.



The integer value that represents the number of the minimum exact cardinality associated with the child entity in the CARDINALITY-RELATIONSHIP represented.



The specific value that represents the class of CARDINALITY-RELATIONSHIP represented.



The character string assigned to represent the action phrase describing the relationship from the child and to the parent instances of ENTITY for a CARDINALITY-RELATIONSHIP.



The specific value that represents the optionality of the CARDINALITY-RELATIONSHIP.



The character string assigned to represent the action phrase describing the association from the parent to the child instances of ENTITY for a CARDINALITY-RELATIONSHIP.


MA CATEGORY-RELATIONSHIP The specific value that represents whether all the possible subtypes of the Super ENTITY explicitly occur in the data model.


OP CATEGORY-RELATIONSHIP The character string assigned to represent the characterisation of a CATEGORY-RELATIONSHIP.

category-relationship-index MA CATEGORY-RELATIONSHIP SUBTYPE-RELATIONSHIP

The unique value, or set of characters, assigned to represent a specific CATEGORY-RELATIONSHIP for a specific ENTITY and to distinguish it from all other CATEGORY-RELATIONSHIPs for that ENTITY.

child-entity-id MA CARDINALITY-RELATIONSHIP RELATIONSHIP

The entity-id that identifies the child entity in the relationship (a role name for entity-id).

creator-attribute-index OP CREATOR-UPDATE-IDENTIFICATION

The attribute-index for a specific CREATOR-UPDATE-IDENTIFICATION that identifies the creator-id of a specific record (a role name for attribute-index).

discriminator-attribute-index MA CATEGORY-RELATIONSHIP The attribute-index that identifies the attribute used as a discriminator for sub-typing (a role name for attribute-index).

domain-class-name-text MA DOMAIN The character string assigned to represent the category to which the DOMAIN belongs.


OP DOMAIN The character string assigned to represent the source of the domain definition.

domain-definition-text MA DOMAIN The character string assigned to represent the definition of a specific DOMAIN.


V3.1.4

C-5


domain-id MA BASE-ATTRIBUTE BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE-DOMAIN-VALUE DOMAIN DOMAIN-VALUE SUBTYPE-RELATIONSHIP

The unique value, or set of characters, assigned to represent a specific DOMAIN and to distinguish it from all other DOMAINs.


OP DOMAIN The character string assigned to represent the unit of measure for DOMAINs that permit quantitative values.

domain-model-level-code MA DOMAIN The specific value that represents the data model source of the DOMAIN.

domain-name-text MA DOMAIN The character string assigned to represent a specific DOMAIN.

domain-restriction-type-code OP DOMAIN The specific value that represents the type of constraint imposed upon values for the DOMAIN.


MA DOMAIN The specific value that represents the level of common agreement for the DOMAIN.

domain-value-definition-text OP DOMAIN-VALUE The character string assigned to represent the definition of a DOMAIN-VALUE.


MA DOMAIN-VALUE The character string assigned to represent the description of a DOMAIN-VALUE.

domain-value-index MA BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE-DOMAIN-VALUE DOMAIN-VALUE SUBTYPE-RELATIONSHIP

The unique value, or set of characters, assigned to represent a specific DOMAIN-VALUE for a specific DOMAIN and to distinguish it from all other DOMAIN-VALUEs for that DOMAIN.

domain-value-name-text OP DOMAIN-VALUE The character string assigned to represent a specific DOMAIN-VALUE.

domain-value-source-text OP DOMAIN-VALUE The character string assigned to represent the source of the domain value and the definition of that domain value.


MA DOMAIN-VALUE The specific value that represents the level of common agreement of the DOMAIN-VALUE.

domain-value-type-code MA DOMAIN-VALUE The specific value that represents the class of a DOMAIN-VALUE.

entity-definition-text MA ENTITY The character string assigned to represent the definition of what the entity is.

entity-dependency-code MA ENTITY The specific value that represents whether the ENTITY is independent for its meaning and instances from all other instance of ENTITY.

entity-depth-count MA ENTITY The integer value representing the specification of the level of dependency of the entity or maximum number of parent entities "above" the entity itself.

entity-id MA ALTERNATE-KEY ALTERNATE-KEY-ATTRIBUTE ATTRIBUTE BASE-ATTRIBUTE BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE ENTITY CREATOR-UPDATE-IDENTIFICATION NON-KEY-ATTRIBUTE PRIMARY-KEY-ATTRIBUTE

The unique value, or set of characters, assigned to represent a specific ENTITY and to distinguish it from all other ENTITYs.

entity-model-level-code MA ENTITY The specific value that represents the data model source of the ENTITY being represented.

entity-name-text MA ENTITY The character string assigned to represent a specific ENTITY.

entity-of-interest-id MA BUSINESS-RULE-ENTITY The entity-id of the entity that is of interest in a specific BUSINESS-RULE-ENTITY (a role name for entity-id).


MA ENTITY The specific value that represents the level of common agreement for the ENTITY.

entity-storage-type-code MA ENTITY The specific value that represents whether the ENTITY as standard (non-loggable) or loggable.

entity-table-name-text MA ENTITY The character string assigned to represent the physical table or other object of a physical schema that represents data specified for a specific ENTITY.


OP FOREIGN-KEY-ATTRIBUTE The character string assigned to represent the way in which a FOREIGN-KEY-ATTRIBUTE relates to the base ENTITY.


V3.1.4

C-6



MA FOREIGN-KEY-ATTRIBUTE The specific value that represents whether a surrogate name is used for a migrating FOREIGN-KEY-ATTRIBUTE in the base ENTITY.

host-entity-id MA FOREIGN-KEY-ATTRIBUTE The entity-id that identifies the entity in which the foreign key resides (a role name for entity-id).

migrating-relationship-index MA FOREIGN-KEY-ATTRIBUTE The relationship-index that identifies the instance of the migration of the foreign key (a role name for relationship-index).


MA NON-KEY-ATTRIBUTE The specific value that represents whether non-null domain value is required for a NON-KEY-ATTRIBUTE.

parent-domain-id OP DOMAIN The domain-id of a specific parent DOMAIN (a role name for domain-id).

parent-entity-id MA CARDINALITY-RELATIONSHIP RELATIONSHIP

The entity-id that identifies the parent entity in the relationship (a role name for entity-id).

relationship-index MA CARDINALITY-RELATIONSHIP RELATIONSHIP SUBTYPE-RELATIONSHIP

The unique value, or set of characters, assigned to represent a RELATIONSHIP for a specific Parent ENTITY and a specific Child ENTITY and to distinguish it from all other RELATIONSHIPs for that Parent ENTITY and that Child ENTITY.

relationship-type-code MA RELATIONSHIP The specific value that represents the class of RELATIONSHIP being specified.

source-attribute-index MA FOREIGN-KEY-ATTRIBUTE The attribute-index that identifies the source attribute for the foreign key (a role name for attribute-index).

source-entity-id MA FOREIGN-KEY-ATTRIBUTE The entity-id that identifies the source entity for the foreign key (a role name for entity-id).

sub-entity-id MA SUBTYPE-RELATIONSHIP The entity-id that identifies the sub-type entity for sub-typing (a role name for entity-id).

super-entity-id MA CATEGORY-RELATIONSHIP SUBTYPE-RELATIONSHIP

The entity-id that identifies the super-type entity for sub-typing (a role name for entity-id).

unifying-attribute-index OP FOREIGN-KEY-ATTRIBUTE The attribute-index that identifies the attribute that belongs to the same ENTITY as the one with which it unifies (a role name for attribute-index).

update-attribute-index OP CREATOR-UPDATE-IDENTIFICATION

The attribute-index for a specific CREATOR-UPDATE-IDENTIFICATION that identifies the update-seqnr of a specific record (a role name for attribute-index).



V3.1.4

D-1

Annex D: JC3IEDM Metamodel—

ENTITY RELATIONSHIPS


V3.1.4

D-2



V3.1.4

D-3

Annex D. JC3IEDM Metamodel—ENTITY RELATIONSHIPS

Parent Entity

Verb Phrase

Child Entity

Relationship Type

Logical Foreign Keys

Cardinality

Nulls

ALTERNATE-KEY consists-of ALTERNATE-KEY-ATTRIBUTE

Identifying entity-id

alternate-key-index

One-to-One-or-More (P)

ATTRIBUTE appears-in ALTERNATE-KEY-ATTRIBUTE

Identifying entity-id

attribute-index

One-to-Zero-One-or-More

ATTRIBUTE Is a BASE-ATTRIBUTE Subtype entity-id

attribute-index

Is a

ATTRIBUTE provides-the-attribute-reference


Non-identifying

entity-id

attribute-index

One-to-Zero-One-Or-More

No Nulls

ATTRIBUTE is-discriminator-for CATEGORY-RELATIONSHIP Non-identifying

super-entity-id

discriminator-attribute-index


No Nulls

ATTRIBUTE identifies-creator-id-column CREATOR-UPDATE-IDENTIFICATION

Non-identifying

creator-attribute-index Zero-or-One-to-Zero-One-or-More

ATTRIBUTE identifies-update-seqnr-column


Non-identifying

update-attribute-index Zero-or-One-to-Zero-One-or-More

ATTRIBUTE Is a FOREIGN-KEY-ATTRIBUTE Subtype host-entity-id

attribute-index

Is a

ATTRIBUTE Is a NON-KEY-ATTRIBUTE Subtype entity-id

attribute-index

Is a

ATTRIBUTE Is a PRIMARY-KEY-ATTRIBUTE Subtype entity-id

attribute-index

Is a

BASE-ATTRIBUTE is-originator-for FOREIGN-KEY-ATTRIBUTE Non-identifying

base-entity-id

base-attribute-index


No Nulls

BUSINESS-RULE is-composed-of BUSINESS-RULE-ENTITY Identifying business-rule-id One-to-Zero-One-Or-More

No Nulls


is-composed-of BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE

Identifying business-rule-id



No Nulls


is-composed-of BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE-DOMAIN-VALUE

Identifying business-rule-id




No Nulls

CATEGORY-RELATIONSHIP

holds SUBTYPE-RELATIONSHIP Non-identifying

super-entity-id

category-relationship-index


No Nulls


V3.1.4

D-4

Parent Entity

Verb Phrase

Child Entity

Relationship Type


Cardinality

Nulls

DOMAIN describes-allowed-values-for

BASE-ATTRIBUTE Non-identifying

domain-id One-to-Zero-One-or-More

No Nulls

DOMAIN is-basis-for DOMAIN Non-identifying

parent-domain-id Zero-or-One-to-Zero-One-or-More

Nulls Allowed

DOMAIN contains DOMAIN-VALUE Identifying domain-id One-to-Zero-One-or-More

DOMAIN-VALUE discriminates SUBTYPE-RELATIONSHIP Non-identifying

domain-id

domain-value-index

Zero-or-One-to-Zero-One-or-More

Nulls Allowed

DOMAIN-VALUE Is-part-of BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE-DOMAIN-VALUE

Non-identifying

domain-id

domain-value-index


No Nulls

ENTITY is-also-identified-by ALTERNATE-KEY Identifying entity-id One-to-One-or-More (P)

ENTITY is-characterised-by ATTRIBUTE Identifying entity-id One-to-One-or-More (P)

ENTITY has BUSINESS-RULE-ENTITY Non-identifying

entity-of-interest-id One-to-Zero-One-Or-More

No Nulls

ENTITY is-subtyped-via CATEGORY-RELATIONSHIP Identifying super-entity-id One-to-Zero-One-or-More

ENTITY has-creator-id-and-update-seqnr-columns


Identifying entity-id One-to-Zero-or-One (Z)

ENTITY is-child-of RELATIONSHIP Identifying child-entity-id One-to-Zero-One-or-More

ENTITY is-parent-of RELATIONSHIP Identifying parent-entity-id One-to-Zero-One-or-More


unifies FOREIGN-KEY-ATTRIBUTE Non-identifying

host-entity-id

unifying-attribute-index

Zero-or-One-to-Zero-One-or-More

Nulls Allowed


is-source-for FOREIGN-KEY-ATTRIBUTE Non-identifying

source-entity-id

source-attribute-index


No Nulls

RELATIONSHIP Is a CARDINALITY-RELATIONSHIP

Subtype parent-entity-id

child-entity-id

relationship-index

Is a

RELATIONSHIP migrates-from-parent(source)-to-child(host)-entity

FOREIGN-KEY-ATTRIBUTE Non-identifying

source-entity-id

host-entity-id

migrating-relationship-index


No Nulls


V3.1.4

D-5

Parent Entity

Verb Phrase

Child Entity

Relationship Type


Cardinality

Nulls

RELATIONSHIP Is a SUBTYPE-RELATIONSHIP Subtype super-entity-id

sub-entity-id

relationship-index

Is a


V3.1.4

D-6



V3.1.4

E-1

Annex E: JC3IEDM Metamodel—

SPECIFICATIONS FOR ENUMERATED DOMAINS


V3.1.4

E-2



V3.1.4

E-3

Annex E. JC3IEDM Metamodel—

SPECIFICATIONS OF ENUMERATED DOMAINS

Domain Name alternate-key-uniqueness-indicator-code

Definition The specific value that denotes whether the alternate key or inversion key is unique.

Definition Source MIP

DOMAIN VALUES

Value Definition Source Physical Value

Identifier

Always unique The alternate key is always unique. MIP AU 1000001

Mostly unique The alternate key is mostly unique as in an Inversion entry. MIP MU 1000002

USAGE

Entity Attribute Optionality

ALTERNATE-KEY alternate-key-uniqueness-indicator-code MA

Domain Name attribute-foreign-key-indicator-code

Definition The specific value that denotes whether the ATTRIBUTE plays the role of a foreign key in the ENTITY and thereby owned by another ENTITY.


DOMAIN VALUES


Identifier

BASE-ATTRIBUTE

That subset of ATTRIBUTE owned by the ENTITY to which the members belong; that is, they are not foreign key attributes migrating from another ENTITY under some relationship.

MIP BA 1000001


An ATTRIBUTE that has been migrated under a RELATIONSHIP from the primary key of the "Parent" ENTITY of that RELATIONSHIP.

MIP FK 1000002

USAGE


ATTRIBUTE attribute-foreign-key-indicator-code MA

Domain Name attribute-primary-key-indicator-code

Definition The specific value that denotes whether an ATTRIBUTE plays the role of part of the primary key in the ENTITY to which it belongs.


DOMAIN VALUES


Identifier

NON-KEY-ATTRIBUTE

An ATTRIBUTE used to provide a descriptive data element of instances of the ENTITY to which the ATTRIBUTE belongs and that is not a member of the primary key of that ENTITY.

MIP NK 1000001


An ATTRIBUTE used to provide the unique identifier(s) of an instance of the ENTITY to which the attributes belong.

MIP PK 1000002

USAGE


ATTRIBUTE attribute-primary-key-indicator-code MA

Domain Name base-attribute-data-type-code

Definition The specific value that represents the technical form (datatype or syntax) for the attribute.

Definition Source MIP-NDAG

DOMAIN VALUES


Identifier

Blob The datatype of the attribute is BLOB. SQL-99 BLOB 1000001

Character The datatype of the attribute is space padded character. MIP-NDAG CHAR 1000002

Numeric The datatype of the attribute is a number. SQL-99 NUMBER 1000003

Varying character

The datatype of the attribute is variable character not space padded. MIP-NDAG VARCHAR 1000004

USAGE


BASE-ATTRIBUTE base-attribute-data-type-code MA


V3.1.4

E-4

Domain Name business-rule-category-code

Definition The specific value that represents the class of BUSINESS-RULE as text or a formal rule.


DOMAIN VALUES


Identifier

Rule The specific value that represents a BUSINESS-RULE that is formalized in metadata content.

MIP-NDAG

RULE 1000001

Text The specific value that represents a BUSINESS-RULE that is in textual form.

MIP-NDAG

TEXT 1000002

USAGE


BUSINESS-RULE business-rule-category-code MA

Domain Name business-rule-entity-attribute-composite-null-indicator-code

Definition The specific value that indicates whether the attribute cited in BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE is permitted to be unspecified within the specific BUSINESS-RULE.


DOMAIN VALUES


Identifier

No The attribute can take any of the values listed in its associated BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITEs but it cannot be left unspecified.

MIP-NDAG

NO 1000001

Yes The attribute can take any of the values listed in its associated BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITEs and can also be left unspecified.

MIP-NDAG

YES 1000002

USAGE


BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE business-rule-entity-attribute-composite-null-indicator-code

MA

Domain Name cardinality-relationship-child-cardinality-code

Definition The specific value that represents the range in the number of occurrences associated with the child entity in the CARDINALITY-RELATIONSHIP represented.


DOMAIN VALUES


Identifier

Exactly The child cardinality relationship is represented by exactly one expression. MIP EX 1000001

Positive (one or more)

The child cardinality relationship is represented by one or more expressions.

MIP PO 1000002

Range The child cardinality relationship is represented as a range. MIP RA 1000003

Special The child cardinality relationship is represented as a special expression. MIP SP 1000004

Zero, one or more

The child cardinality relationship is represented by zero, one or more expressions.

MIP ZM 1000005

Zero or one The child cardinality relationship is represented by zero or one expressions. MIP ZO 1000006

USAGE


CARDINALITY-RELATIONSHIP cardinality-relationship-child-cardinality-code MA

Domain Name cardinality-relationship-identifying-indicator-code

Definition The specific value that represents the class of CARDINALITY-RELATIONSHIP represented.


DOMAIN VALUES


Identifier

Identifying The cardinality relationship is identifying. MIP ID 1000001

Nonidentifying The cardinality relationship is nonidentifying. MIP NI 1000002

USAGE


CARDINALITY-RELATIONSHIP cardinality-relationship-identifying-indicator-code MA


V3.1.4

E-5

Domain Name cardinality-relationship-parent-cardinality-code

Definition The specific value that represents the optionality of the CARDINALITY-RELATIONSHIP.


DOMAIN VALUES


Identifier

Mandatory The parent cardinality relationship must occur at least one time. MIP MA 1000001

Optional The parent cardinality relationship may or may not occur (zero or one). MIP OP 1000002

USAGE


CARDINALITY-RELATIONSHIP cardinality-relationship-parent-cardinality-code MA

Domain Name category-relationship-completeness-indicator-code

Definition The specific value that represents whether all the possible subtypes of the Super ENTITY explicitly occur in the data model.


DOMAIN VALUES


Identifier

Complete category The subtyping for this entity is complete. MIP CC 1000001

Incomplete category The subtyping for this entity is incomplete. MIP IC 1000002

USAGE


CATEGORY-RELATIONSHIP category-relationship-completeness-indicator-code MA

Domain Name domain-restriction-type-code

Definition The specific value that represents the type of constraint imposed upon values for the DOMAIN.


DOMAIN VALUES


Identifier

Enumerated domain The constraint imposed on this domain is an enumerated domain. MIP EN 1000001

Range The constraint imposed on this domain is a range. MIP RA 1000003

USAGE


DOMAIN domain-restriction-type-code MA

Domain Name domain-value-type-code

Definition The specific value that represents the class of a DOMAIN-VALUE.


DOMAIN VALUES


Identifier

Element Enumerated domains are associated with a complete set of domain values. MIP ELEM 1000002

Maximum exclusive

The maximum value excluded from the range. MIP MAX-EX 1000004

Maximum inclusive

The maximum value included in the range. MIP MAX-IN 1000005

Minimum exclusive

The minimum value excluded from the range. MIP MIN-EX 1000006

Minimum inclusive

The minimum value included in the range. MIP MIN-IN 1000007

USAGE


DOMAIN-VALUE domain-value-type-code MA

Domain Name entity-dependency-code

Definition The specific value that represents whether the ENTITY is independent for its meaning and instances from all other instance of ENTITY.


DOMAIN VALUES


Identifier

Dependent entity The entity is dependent upon one or more parents for its identity. MIP DE 1000001


V3.1.4

E-6

Independent entity

The entity is independent for its meaning and instances from all other instance of entity.

MIP IE 1000002

Subtype entity The entity is dependent upon one parent for its identity. MIP SE 1000003

USAGE


ENTITY entity-dependency-code MA

Domain Name entity-storage-type-code

Definition The specific value that represents whether the ENTITY as standard (non-loggable) or loggable.


DOMAIN VALUES


Identifier

Loggable The entity is to be treated as loggable. MIP LOG 1000001

Standard The entity is to be treated as standard (non-loggable). MIP STD 1000002

USAGE


ENTITY entity-storage-type-code MA

Domain Name foreign-key-attribute-rolename-indicator-code

Definition The specific value that represents whether a surrogate name is used for a migrating FOREIGN-KEY-ATTRIBUTE in the base ENTITY.


DOMAIN VALUES


Identifier

Migrated name The migrating attribute has not been rolenamed. MIP MN 1000001

Role name The migrating attribute has been rolenamed. MIP RN 1000002

USAGE


FOREIGN-KEY-ATTRIBUTE foreign-key-attribute-rolename-indicator-code MA

Domain Name model-level-code

Definition The specific value that represents the data model source of the object.


DOMAIN VALUES


Identifier

Application Application level, denoting a part of a data model. MIP APPL 1000001

Dictionary Dictionary level, denoting a part of a data model. MIP DICT 1000003

Metamodel MIP JC3IEDM metamodel management. MIP-NDAG

META 1000004

USAGE


DOMAIN ENTITY

domain-model-level-code entity-model-level-code

MA

Domain Name non-key-attribute-optionality-indicator-code

Definition The specific value that represents whether non-null domain value is required for a NON-KEY-ATTRIBUTE.


DOMAIN VALUES


Identifier

Mandatory The non-key attribute is mandatory. MIP MA 1000001

Optional The non-key attribute is optional. MIP OP 1000002

USAGE


NON-KEY-ATTRIBUTE non-key-attribute-optionality-indicator-code MA


V3.1.4

E-7

Domain Name relationship-type-code

Definition The specific value that represents the class of RELATIONSHIP being specified.


DOMAIN VALUES


Identifier


A one-way RELATIONSHIP that identifies a specific “parent” ENTITY with a specific “child” ENTITY where the child is a dependent ENTITY whose set of key attributes may differ from the set of key attributes of the parent.

MIP CR 1000001

SUBTYPE-RELATIONSHIP

A RELATIONSHIP that identifies a subset of instances of a Parent ENTITY as an entity itself, which has a set of primary key attributes that are identical to those of the Parent ENTITY.

MIP SR 1000002

USAGE

ENTITY Attribute Optionality

RELATIONSHIP relationship-type-code MA

Domain Name standardisation-level-code

Definition The specific value that represents the level of common agreement for the object.


DOMAIN VALUES


Identifier

International International extensions to the JC3IEDM data model. MIP INAT 1000002

Local Local extensions to the JC3IEDM data model. MIP LOC 1000003

National National extensions to the JC3IEDM data model. MIP NAT 1000004

MIP core All common meta data distributed in support of the Generic Hub data model.

MIP MPCO 1000001

Multilateral Interoperability Programme

MIP extensions to the JC3IEDM data model. MIP MIP 1000005

MIP-NATO Data Administration MIP-NDAG extensions to the JC3IEDM data model. MIP MPND 1000006

USAGE


ATTRIBUTE DOMAIN DOMAIN-VALUE ENTITY

attribute-standardisation-level-code domain-standardisation-level-code domain-value-standardisation-level-code entity-standardisation-level-code

MA


V3.1.4

E-8



V3.1.4

F-1

Annex F: JC3IEDM Metamodel—

SPECIFICATION OF OTHER DOMAINS


V3.1.4

F-2

F.1 INTRODUCTION

This annex defines the Class words associated with their attributes, other than

‘code’ for the JC3IEDM metamodel. Section F.2 contains a description of all the range

attributes. Section F.3 specifies the remaining attributes that do not fall into the previous

category.

F.2 Range attributes

This section lists the attributes that have numeric values. The attributes are

ordered by class word.

Count





entity-depth-count

Ordinal


Quantity


F.3 Other Attributes

This section covers domains for attributes having class words id, index, and

text. The attributes are identified below.

Id

Domain – identifier_8

entity-id

base-entity-id

child-entity-id

entity-of-interest-id

host-entity-id

parent-entity-id

source-entity-id

sub-entity-id

super-entity-id


domain-id

parent-domain-id


business-rule-id


V3.1.4

F-3

Index

alternate-key-index

attribute-index

base-attribute-index

creator-attribute-index

discriminator-attribute-index

source-attribute-index

unifying-attribute-index

update-attribute-index

sub-entity-id

super-entity-id




domain-value-index

relationship-index


migrating-relationship-index

Text

attribute-column-name-text

attribute-name-text




business-rule-section-reference-text

business-rule-table-reference-text







domain-name-text



domain-value-name-text



entity-name-text

entity-table-name-text



V3.1.4

G-1

Annex G: JC3IEDM Metamodel—

Compendium of Business Rules


V3.1.4

G-2



V3.1.4

G-3

ANNEX G. Compendium of Business Rules

G1 Introduction

G.1.1 Business rules specify constraints that either cannot be expressed in formal

IDEF1X notation or those that are not explicitly structured as a design choice. Business

rules must be observed in order to maintain a workable data exchange interface.

G.1.2 Many of the rules are re-stated from the main body. Other rules are found

only in this Annex.

G2 EXAMPLE “entity-depth-count”

G2.1 The “entity-depth-count” is the level of dependency of the entity. This is

the maximum number of parent entities “above” the entity itself or, in other words, the

longest path to a completely independent entity taking into account the foreign keys. The

“entity-depth-count” of a certain entity is equal to the highest value of all the father

entities “entity-depth-count” (MaxFather) plus one. As default value for MaxFather: = -1, “depth-count”: = Max(all the father entities “depth-count”) + 1.

G2.2 In the special case of an entity with a recursive relation, entity-depth-count

value should ignore this relation in its computation. In order to ensure that the “entity-

depth-count” can be used accordingly, the recursive relation should be transformed when

possible into a self-related table like represented in the figure below. Fish

FishID

FishName Specie FatherFish

Fish_Assoc

FishChildID (FK) FishFatherIID (FK) FishFatherIndex

Fish

FishID

FishName Specie FatherFish

=

Figure G-1. Recursive Relation Breakdown

G2.3 Example for entity-depth-count = 9

a. Entity: ACTION-OBJECTIVE-ITEM-MARKING (an entity in the

JC3IEDM).

b. Recursive Relations: No.

c. Relations: ACTION-OBJECTIVE-ITEM-MARKING has two parent entities:

ORGANISATION and ACTION-OBJECTIVE-ITEM

d. Parent entities: values of “entity-depth-count”:

(1) “entity-depth-count” of ORG:

If (OBJ_ITEM=0) then ORG=1.

(2) “entity-depth-count” of ACTION-OBJECTIVE-ITEM

If (ORG = 1 and REF = 0) then RPTD = 2

If (RPTD = 2) then CTGTLST = 3

If (CTGTLST = 3) then CTGTDET = 4

9 Physical (table) names from the JC3IEDM are used in this example. The logical names are as follows:

ORG = ORGANISATION; OBJ_ITEM = OBJECT-ITEM; REF = REFERENCE; RPTD =

REPORTING-DATA; CTGTLST = CANDIDATE-TARGET-LIST; CTGTDET = CANDIDATE-

TARGET-DETAIL; CTGTDET_ITEM = CANDIDATE-TARGET-DETAIL-ITEM; ACT = ACTION;

ACT_OBJVE; ACTION-OBJECTIVE; ACT_OBJVE_ITEM; ACTION-OBJECTIVE-ITEM.


V3.1.4

G-4

If (CTGTDET = 4 and OBJ_ITEM = 0) then CTGTDET_ITEM = 5

and

If (ORG =1 and ACT = 0) then ACT_OBJVE = 2

then

If (ACT_OBJVE = 2 and OBJ_ITEM = 0 and CTGTDET_ITEM = 5)

then ACT_OBJVE-ITEM = 6

e. Computed “entity-depth-count” of ACTION-OBJECTIVE-ITEM-MARKING: Using the same rule:

If (ACTION-OBJECTIVE-ITEM = 6 and ORG = 1) then ACTION-OBJECTIVE-ITEM -

MARKING = 7.

G.3 GENERAL BUSINESS RULES

G.3.1 Identifiers and indexes are meaningless primary key attributes. Once

created, they can never be changed. Both identifiers and indexes are numbers that meet

domain requirements, such as the data type and range into which their values must fit.

G.3.2 If a name is an “alternate key” (AK), it means that the name serves as a

unique identifier (globally unique and never null). If a name is an “inversion entry” (IE), it

acts as alternate key in most cases (an inversion entry need not be globally unique and

may be null for some instances; its primary use is in indexing portions of the database for

rapid access). Applications normally make use of an alternate key to identify records. In

case of an inversion entry, identical names can occur by coincidence, in which case the

primary key makes the difference. AK or IE names should not be changed, unless to

correct a misspelling or similar error.

G.3.3 Keys must be created according to the rules specified in MIR Annex D.


V3.1.4

H-1

Annex H: JC3IEDM Metamodel—

NAMING CONVENTIONS AND CLASS WORDS


V3.1.4

H-2

ANNEX H. NAMING CONVENTIONS AND CLASS WORDS

H1 Introduction

H1.1 Purpose

The purpose of a naming convention is to provide a structured method by which

standard names for data objects can be developed to support the construction of IDEF1X

data models. The naming convention assumes the use of the English language. The

procedures must cover the naming of the following IDEF1X conceptual objects:

a. entities (independent and dependent entities as well as entity subtypes)

b. attributes

c. relationships.

H1.2 Guiding Principles

Readability. The naming convention should provide names that are completely

comprehensible to the user. This means that even though a name conforms to a convention

and may suffer some awkwardness in word flow, it must be readable to the user. The user

must be able to derive the basic meaning of the data object by looking at the name. This is

particularly important to assist validation of the IDEF1X data models by subject matter

experts.

Brevity. Names should be as short as possible while still retaining meaning and

uniqueness within the data model. Conflicts between brevity and clarity should always be

resolved in favour of clarity.

Syntax. Each name must be constructed according to the syntax of the naming

convention.

Context. Data objects are named based on their context within the data model and

not according to any physical characteristics.

H2 Keywords Used to Construct the Syntax of a Name

The syntax of the naming convention is defined using three different types of

keyword. These are defined below:

a. Prime Word (PW). A Prime Word is a noun, which is used to represent the

data grouping (entity) to which the data object belongs.

b. Class Word (CW). A Class Word is used to specify the type of information

contained in a set of data values.

c. Modifier (M). A Modifier is used to refine, describe or render a name unique

if this cannot be achieved by a Class Word or Prime Word alone.

In the subsequent specification of syntax, < > is used to delimit keywords, and [ ] is used

to denote the optionality of a component word.


V3.1.4

H-3

H3 Entity Names

H3.1 Syntax for an Entity Name (Independent and Dependent Entities

A Prime Term, as defined below, is used to name independent and dependent

entities. A Prime Term consists of a Prime Word (PW) that may be further modified to

construct a name that is representative of the entity and its context within the data model.

The syntax of a Prime Term is:

Prime Term = <PW> [<M>] ... [<M>]

Example: <CANDIDATE-TARGET-LIST>-<ASSOCIATION>

It is recommended but not required that the Prime Word should be the first keyword

within the Prime Term for the following reasons:

a. Its position in the Prime Term is always known, providing ease of reference.

b. This approach is consistent with the way that the military traditionally classify

objects by placing the major concept first.

H3.2 Syntax for a Category Entity (Entity Subtype)

In the case of a Category Entity (Entity Subtype) the syntax is extended to allow

optional modifiers before the Prime Word. The syntax of the Category Entity Prime Term

is:

Entity Subtype Prime Term = [<M>]...[<M>]<PW>[<M>]...[<M>]

Example: <PRIVATE-SECTOR>-<ORGANISATION-TYPE>

This syntax may only be used when the Prime Word is the same as that at the Entity

Supertype level.

H3.3 Rules for Naming Entities

a. The sequence of words within the Prime Term will conform to the syntax

specified in Section H3.1. The Prime Word will always be the first word within

the name.

b. Prime Words can also be used as Modifiers within an Entity Name.

c. A Prime Word must be a noun or sequence of nouns. Where more than one

word is required to accurately name an independent entity, the combination of

these words may then be regarded as the Prime Word. For example, OBJECT-

ITEM and OBJECT-TYPE may be regarded as instances of Prime Words.

d. A Prime Word must not be contained in the list of reserved Class Words.

e. Plurals of Prime Words or Modifiers are not permitted.

f. The Prime Word will often be the name of an independent entity within the

Data Model. In some cases, the Prime Word may be the name of a subtype in a

category hierarchy (e.g., UNIT as a subtype of ORGANISATION; FEATURE

and ORGANISATION as subtypes of OBJECT-ITEM).

g. A Modifier is an adjective or noun that is used to further refine or describe a

Prime Word in order to name an entity.

h. The use of abbreviations or acronyms shall be avoided.

i. Only the International Reference Alphabet characters (A-Z) are permitted

within a Prime Word or Modifier. Numbers are not permitted unless they form an


V3.1.4

H-4

integral part of a “Real World” entity name. For instance, “ADATP-3-

ELEMENT” is permitted, while names such as “TEST3” are not. Special

characters are not permitted.

j. Each word of a Prime Term is separated by a hyphen ("-").

k. Prepositions (at, by, from, in, to, of) are not permitted within a Prime Term.

l. Articles (a, an, the) are not permitted within a Prime Term.

m. Conjunctions (and, or, but) are not permitted within a Prime Term.

n. Verbs are not permitted within a Prime Term.

o. Gerunds (words ending in "ing") are permitted to be used as Modifiers.

p. Sufficient modifiers will be used to adequately describe the concept.

q. The entity name should appear in capital letters on all IDEF1X diagrams.

r. In principle there is no limit on the length of the name provided that it is

consistent with the specified syntax. However, see the implementation

restrictions relating to the supporting IRD Dictionary in Section H6.

s. Where the Entity Name contains more than one Prime Word (Prime Words

being used as modifiers), the actual choice of Prime Word within the syntax

should be chosen such that the concept being modelled is clearly described. In

most instances, the Prime Word will describe the major concept represented by

the Entity.

t. When naming non-subtype-children, where possible, the Entity Name of a

child (other than a subtype) should contain the Prime Word (or entire Prime

Term) of the entity name(s) of its parent(s). See Rule H3.4(c).

H3.4 Additional Rules for Naming Categorisation Entities (Entity Subtypes)

a. The sequence of words within the Prime Term will conform to the syntax

specified in Section H3.2.

b. The modifiers before the Prime Word are only to be used when it is agreed by

that the concept being modelled cannot be adequately named using the normal

syntax for a Prime Term (Section H3.1).

c. It is not mandatory to migrate the Prime Word from the Generalisation Entity

(Entity Supertype) to the related Category Entities (Entity Subtypes).

d. Rules (b) to (t), as specified in Section H3.3, apply.

H4 Attribute Names

H4.1 Syntax for an Attribute Name

H4.1.1 The attribute name will consist of two distinct component terms; the prime

term and the generic term, in which the Prime Term occurs first and the Generic Term is

juxtaposed at (i.e., added to) the end of the Prime Term.

Attribute Name = Prime Term + Generic Term

H4.1.2 The Prime Term is the same as that defined for naming entities in Section

H3. It will be the name of the parent entity of the attribute being named. A key attribute,

which is migrated within an IDEF1X Data Model, may be named in one of two ways

depending upon whether IDEF1X role-naming is used. If role-naming is not employed,

then the attribute must maintain the full migrated name as it occurs in the parent:


V3.1.4

H-5

Attribute Name = Name of Parent Entity + Generic Term

Example: electronic-equipment-type- + category-code

H4.1.3 Where IDEF1X role-naming is used, the attribute name shall be constructed

according to the following structure:

Attribute Name = Name of Host Entity + Role-named Generic Term

where the role-named generic term conforms to the rules for the construction of a Generic

Term. It is desired (but not mandatory) that the role-named generic term end in the

identical generic term used by the attribute in the parent entity.Example: reporting-data-

relative-timing- + reference-action-task-id

In the example first part is the name of the host entity and the second is the foreign

key “action-task-id” with “reference” as a modifier to create the role-named Generic

Term.

H4.1.4 The Generic Term identifies the set of values that can be associated with

the Prime Term. The syntax of the Generic Term is:

Generic Term = [<M>]......[<M>]<CW>

Example: <category-><code>

H4.1.5 To distinguish attribute names from entity names, attribute names are

written in lower-case characters with their words separated by hyphens.

H4.2 Rules for Naming Attributes

a. The Prime Term will be constructed according to the rules and syntax defined

for naming entities specified in Section H3.

b. The Generic Term will be constructed according to the syntax defined above.

c. Class Words will be reserved; and will not be used as a Prime Word. Use of

Class Words as Prime Word modifiers should be avoided.

d. All Class Words used must be from the authorised Class Word vocabulary. A

list of Class Words that applies to the JC3IEDM is contained in Section H7.

e. A Class Word must be a noun.

f. Plurals of Class Words or Modifiers are not permitted.

g. A Modifier is an adjective or noun that is used to further refine or describe the

Generic Term.

h. Abbreviations or acronyms should not be used within the Generic Term. (See

rule x)

i. Only International Reference Alphabet characters (a-z) are permitted within a

Class Word or Modifier. Numbers and special characters are not permitted.

j. Each word of the attribute name is separated from the next by a hyphen ("-").

k. Prepositions (at, by, from, in, of, to) are not permitted within an attribute name

unless the attribute name is a recognised fixed term considered as one word e.g.

“type-of-coverage-code”, “time-of-arrival”, “method-of-control”, “unit-of-

measure”.

l. Articles (a, an, the) are not permitted within an attribute name.

m. Conjunctions (and, or, but) are not permitted within an attribute name.


V3.1.4

H-6

n. Verbs are not permitted within an attribute name.

o. Gerunds are permitted to be used as Modifiers.

p. Sufficient modifiers will be used to adequately describe the Generic Term and

make it readable.

q. Each attribute name will contain at least one and only one Class Word (use of

additional class words should be avoided).

r. Prime Words may be used as Modifiers within the Generic Term.

s. Plurals of Class Words or Modifiers are not permitted in the construction of

the generic term.

t. A unit of measure suffix will not be applied within the Generic Term. Unit of

measure should be defined within the definition of the attribute or its associated

domain and not as part of its name.

u. The use of JC3IEDM generic terms will be controlled to ensure consistency of

approach to naming.

v. Attribute names will be displayed on IDEF1X diagrams in lower case text.

w. Use of abbreviations is to assist in the formulation of shortened physical

names. Special dispensation has been given for the demonstration data modelling

to allow "id" to be used instead of "identifier".

H4.3 Rules for Defining Attributes

Data attributes are defined based on their origin. If an attribute migrates to a child

entity the definition will change based on the role the attribute plays in the receiving

entity.

H5 Relationship Names

H5.1 Syntax for Relationship Names

The syntax for describing relationships within an IDEF1X Data Model is:

<parent-child relationship> / <child-parent relationship>

Example: <identifies-the-source-for>/<is-referenced-to>

The IDEF1X diagram places the relationship in context with its parent and child entities.

A parent-child relationship identifies the relationship between the parent entity and the

child entity. The child-parent relationship identifies the relationship between the child

entity and the parent entity. The parent-child verb phrase is sometimes termed the

"relationship verb phrase." The child-parent verb phrase is referred to as the "inverse verb

phrase."

H5.2 Rules for Relationship Names

The following rules should be followed in constructing both the parent-child and

child-parent relationship names:

a. Both the parent-child and child-parent relationship will consist of a verb

phrase.

b. The verb phrases must be meaningful so that they represent business rules that

can be verified by the user community. For example, the use of words such as:

"has", "uses", "relates to" and "does" indicates a weak relationship, which should

be rationalised within the Data Model.


V3.1.4

H-7

c. Where a dependent entity is used purely to resolve a many-to-many

relationship (termed an associative entity) the production of a <parent-child

relationship>/<child-parent relationship> may not be meaningful. In this case a

single verb phrase is assigned to each side of the associative entity; and the

associative entity is read through.

d. The verb phrases will be expressed in lower case characters.

e. Hyphens will be used as the separator between words. Spaces are not

permitted.

f. The maximum length of the “verb phrase” and “inverse verb phrase”

including hyphens are both restricted to 60 characters.

H6 IRD Implementation Restrictions

In order to implement an IRD efficiently, it desirable to specify maximum lengths

for the various components of the naming convention. These have been chosen so as not to

be restrictive to the application of the naming convention. The maximum lengths are

shown in Table H-22.

Table H-22. Implementation Restrictions on Name Lengths

Component Maximum Length (Chars)

Class Word 16

Prime Word 80

Attribute Name 160

Generic Term 80

Entity Name 80

Verb Phrase Name 60

Inverse Verb Phrase Name 60

H7 List of Reserved Class Words

This section contains the specification of class words that are used in the data

model. The approved Class Word abbreviation is shown in parentheses after the Class

Word name

Domain Name amount (amt)

Definition A number of monetary units specified in a currency where the unit of

currency is explicit or implied.

Source of Definition ISO/TS 15000-5:2005

Data Type NUMBER (Decimals allowed) The "decimal separator" must be a period (.). The use of scientific notation is not allowed for exchange.

Low Value Unbounded

High Value Unbounded

Definition Prefix “The monetary numeric value that represents…”


V3.1.4

H-8

Domain Name angle (angle)

Definition The rotational measurement between two lines and/or planes

diverging from a common point and/or line. This measurement will

be expressed in units of degrees.

Source of Definition MIP-NDAG

Data Type NUMBER (Decimals allowed) The "decimal separator" must be a period

(.). The use of scientific notation is not allowed for exchange.

Low Value 0


Definition Prefix “The rotational measurement…”

Domain Name binary-object (binobj)

Definition A set of finite-length sequences of binary octets. (Note: This

Representation Term shall also be used for Data Types representing

graphics (i.e. diagram, graph, mathematical curves, or similar representation), pictures (i.e. visual representation of a person, object, or

scene), sound, video, etc.)


Data Type Binary Object. Type

Low Value Not applicable

High Value Not applicable

Definition Prefix “A binary object assigned to…”

Domain Name code (code)

Definition A character string (letters, figures or symbols) that for brevity and/or

language independence may be used to represent or replace a definitive

value or text of a property. This class word is used only when there is a

limited set of possible values.

Source of Definition Adapted ISO/TS15000-5:2005

Data Type VARCHAR



Definition Prefix “The specific value that represents…”

Domain Name coordinate (coord)

Definition The geodetic designation for the location of a point using a polar

coordinate system where the radius is defined through the geoid. This

will be expressed in degrees, with positive values measured eastward

from the zero meridian or northward from the equator.




Low Value -180

High Value 180

Definition Prefix “The numeric value that represents…”


V3.1.4

H-9

Domain Name count (cnt)

Definition A counted number of non-monetary units. Counts need to be specified with

a unit of the count. (Note: This Representation Term shall also be used for

counted coefficients.

Source of Definition Adapted from quantity in ISO/TS15000-5:2005

Data Type NUMBER (Decimals not allowed)

Low Value Unbounded (may be negative)


Definition Prefix “The integer value representing…”

Domain Name datetime (dttm)

Definition A designation of a specified chronological point measured using Coordinated Universal Time (UTC) ISO 8601:2000 as a standard of

reference, constrained to "zero meridian" i.e. ‘Zulu’ time zone only. This is

expressed as a composite field using a compacted ISO notation

YYYYMMDDhhmmss.sss where YYYY represents a year in values from

0000 to 9999, MM represents a month in values from 00 to 12, and DD

represents a day in values from 00 to 31, hh represents an hour in values

from 00 to 23, mm represents a minute in values from 00 to 59, and ss.sss represents the number of seconds and milliseconds in values from 00.000 to

59.999. Note: All character positions must be filled.

Source of Definition ISO/TS15000-5:2005

Data Type CHAR



Definition Prefix “The character string representing a point in time that designates…”

Domain Name dimension (dim)

Definition A one-dimensional linear distance measure. This will be expressed in

metres






Definition Prefix “The one-dimensional linear distance representing…”

Domain Name duration (dur)

Definition A numeric value that represents a quantity of time expressed as

milliseconds. An optional preceding minus sign ('-') is allowed, to indicate a

negative duration. If the sign is omitted a positive duration is indicated.

Source of Definition MIP derived ISO 31-1 and ISO-8601

Data Type NUMBER



Definition Prefix “The numeric value that represents a quantity of time in milliseconds ...”


V3.1.4

H-10

Domain Name identifier (id)

Definition A character string used to establish the identity of, and distinguish

uniquely, one instance of an object within an identification scheme from all

other objects within the same scheme.

Source of Definition Adapted ISO/TS15000-5:2005


Low Value Determined by key management rules

High Value Determined by key management rules

Definition Prefix “The unique value, or set of characters, assigned to represent a specific

<entity> and to distinguish it from all other <entity>s.”

Domain Name index (ix)

Definition A sequence of one or more numbers, alphabetic characters and/or special

characters that serve to uniquely identify some object but have no readily

definable meaning. (Index enables the distinction of instances in associative entities that would otherwise be identical because the values of the other

key attributes (which are all foreign-key attributes) are the same).



Low Value Determined by key management rules

High Value Determined by key management rules

Definition Prefix “The unique value, or set of characters, assigned to represent a specific…”

Domain Name ordinal (ord)

Definition A number designating the place (as first, second, third, etc.) occupied by an

item in an ordered sequence. Units are not applicable. Note: Class word

ordinal is not to be used where class word index applies.



Low Value 1


Definition Prefix “The integer value that indicates...”

Domain Name quantity (qty)

Definition A numeric value that denotes a measure of the physical property of an

object. Class word quantity has a fixed unit of measure that must be

specified on an attribute-by-attribute basis. Class word quantity is not to be

used where class words angle, coordinate, count, dimension, and rate apply.






Definition Prefix The numeric value that represents...”


V3.1.4

H-11

Domain Name rate (rate)

Definition A numeric value that denotes a physical property of an object expressed as

a proportion of a physical property with respect to a unit of time. The unit

of measure for class word rate must be specified on an attribute-by-attribute

basis.






Definition Prefix “The numeric value that denotes…expressed as <A> per <B>.”

Domain Name ratio (rat)

Definition A numeric value representing the quotient of two values that have the same

unit of measurement, i.e., ratio has no units of measure. May be used to

express a percentage. The allowable range must be specified on an

attribute-by-attribute basis.






Definition Prefix “The numeric quotient value that represents...”

Domain Name temperature (tmpr)

Definition A measure of degree of hotness or coldness in an object or in space.

This will be expressed in degrees Celsius.




Low Value -273.15


Definition Prefix “The numeric value that indicates...”

Domain Name text (txt)

Definition A character string (i.e. a finite set of characters) generally in the form of

words of a language. This embraces notions such as description, name,

comment etc.


Data Type VARCHAR



Definition Prefix “The character string assigned to represent…”


V3.1.4

I-1

Annex I: SUMMARY OF IDEF1X DATA MODELLING

METHODOLOGY AND NOTATION


V3.1.4

I-2

I.1 Introduction

I.1.1 Whenever data structures and business rules required to support a

business area need to be specified, it is convenient to build a data model in order to

capture that information. A data model is a description of the organisation of data in a

manner that reflects the information structure of an enterprise. It encompasses the entity

definitions, relationships, and the integrity constraints through which the information

created and used by the functional activity is managed, and from which standard data are

created. [DoD 8020.1 1992].

I.1.2 Having identified what a data model is, one still needs a structured

syntax to begin expressing the information structure of the business. IDEF1X, a

methodology created to help design data, provides such a structured environment, with

special focus on relational constructs.

I.1.3 The following sections provide a brief description of the IDEF1X

syntax as discussed in Thomas A. Bruce’s book Designing Quality Databases with

IDEF1X Information Models [Bruce 1992].

I.2 Entities and Attributes

I.2.1 An entity is anything about which information is stored in a database. In

a conceptual schema language, any concrete or abstract thing of interest, including

associations among things .

I.2.2 IDEF1X distinguishes between independent and dependent entities.

Figure I-1 shows the symbols associated with independent and dependent entities. The

kind of information stored in the data base is, loosely speaking, the attributes or properties

that describe the entity. For instance, if PERSON is an entity in a given data model, then

person-name, person-social-security-number, person-address, etc., may all be properties or

attributes of that entity for the purposes of that enterprise. Attributes are divided into key-

attributes and non-key-attributes, i.e. those used to uniquely identify the entity and those

properties of the entity not used for that purpose.

key-area ENTITY-NAME

key-area

data-area

ENTITY-NAME Independent entity Depends on no other for its identification

Dependent entity Depends on other(s) for its identification data-area

Note: The area above the line is reserved for the identifying keys.

Figure I-1. IDEF1X Symbols for Independent and Dependent Entities

I.2.3 The IDEF1X syntax further categorises attributes according to its

diverse uses in either the key-area or the data area of the entity. Table I-1 summarises

these different usages.


V3.1.4

I-3

Table I-1. IDEF1X Attribute Notation

attribute (FK) Foreign Key

Primary key of another entity contributed by a relationship

role.name.attribute (FK) Role Name

New name for a foreign key connoting its use.

attribute (AKn) Alternate Key

Alternate unique identifier of the entity

attribute (IEn) Inversion Entry

Non-unique access identifier of the entity

group.(c1,c2,c3) Group Attribute

Attribute is a group containing the listed constituents.

attribute(fk1,fk2,fk3)(FK) Unified Foreign Key

Listed foreign keys are unified to a single foreign key attribute

I.3 Category Notation

I.3.1 A data model may contain a series of entities that share one or more

attributes. IDEF1X provides a method for aggregating these common attributes into a base

entity, while retaining the subtypes with their unique properties. This avoids unnecessary

duplication of attributes and helps with the management of the model.

I.3.2 Figure I-2 shows the two types of category supported by IDEF1X. If the

listing of the subtypes is exhaustive, the category is complete and the double line is used to

indicate this fact. If the subtypes depicted are only a fraction of the complete set then the

category is incomplete and only one line is used in the symbol. The subtypes of the

generic parent inherit all the attributes of that parent, but are not limited to spawning their

own unique relationships and subtypes if necessary.

GENERIC PARENT

CAT-1 CAT-2

category discriminator

Each category entity

represents a subset of the instances of the generic parent and inherits the atributes and relationships of that parent.

Incomplete Not all categories shown

Complete All categories shown

Figure I-2. IDEF1X Syntax for Entity Categories

I.4 Relationship Notation

IDEF1X allows three main types of relationship, namely, identifying relationships,

non-identifying relationships and non-specific relationships. (See Figure I-3.)


V3.1.4

I-4

Figure I-3. IDEF1X Relationship Notation

I.5 Cardinality Notation

A further aspect of a relationship is its cardinality. The first two relationships

shown in Figure I-3 (above) were one-to-many, that is, where at least one parent entity has

zero or more child entities associated to it. There are, however, situations in which zero or

one parent entity may have zero or more child entities associated to it, or where it is

guaranteed that there is either at least one parent or one child present in the relationship in

combination with zero or more of the other kind. Figure I-4 depicts all these combinations

diagrammatically.


V3.1.4

I-5

Figure I-4. IDEF1X Cardinality Notation


V3.1.4

J-1

Annex J: REFERENCES


V3.1.4

J-2

AAP-6 (V) 1998 NATO Glossary of Terms and Definitions, AAP-6(V), NATO Military

Agency for Standardisation, September 1998, NATO UNCLASSIFIED

AAP-6 (2008) NATO Glossary of Terms and Definitions, AAP-6(2008), NATO Military

Agency for Standardisation, April 2008, NATO UNCLASSIFIED

AC/322-D(2004)0021 AC/322-D(2004)0021 INFOSEC Technical and Implementation Guidance

for Electronic Labelling of NAO Information

AC/322-D(2004)0022 AC/322-D(2004)0022 NATO C3 Board Technical and Implementation

Guidance for Consistent Marking of NATO Information in C3 Systems

AC/322(SC/4)WP/054-

REV1 (INV) 15 Dec 2003

AC/322(SC/4)WP/054-REV1 (INV) NATO C3 Board Technical and

Implementation Guidance for Consistent Marking of NATO Information in

C3 Systems, 15 Dec 2003

AC/322(SC/4)WP/054-

REV1 (INV) 15 Dec 2003

AC/322(SC/4)WP/054-REV1 (INV) NATO C3 Board Technical and

Implementation Guidance for Consistent Marking of NATO Information in

C3 Systems, 15 Dec 2003 - Def C-M(2002)49

ACCS 1995a NACMA Working Paper Volume 1 ACCS Conceptual Data Model, Version

1.8, SHAPE Technical Centre, The Hague, The Netherlands, 23 June 1994

(made available to ATCCIS on 21 March 1995) NATO UNCLASSIFIED.

ACCS 1995b NACMA Working Paper Volume 2 ACCS Conceptual Data Model Data

Dictionary, Version 1.6, SHAPE Technical Centre, The Hague, The

Netherlands, 23 June 1994 (made available to ATCCIS on 21 March 1995)

NATO UNCLASSIFIED

ACE Directive 80-50 Operational Information Exchange System – General Instructions, Volume

1, SHAPE, 30 November 1992, NATO UNCLASSIFIED

AComP-01(A) 2000 NATO Communications Glossary, Military Agency for Standardization

(MAS), October 2000, NATO UNCLASSIFIED

ADatP-3 1999 ADatP-3 Baseline 11.0.1 (CD-ROM), HQ NATO C3S-IOB, Brussels,

Belgium, 1 July 1999, NATO UNCLASSIFIED

ADatP-3 BL 12.2 ADatP-3 BL 12.2

ADatP-3 BL 13.1 ADatP-3 BL 13.1

AFATDS IRS 1992 Interface Requirements Specification for the AFATDS Version 1, ACCS-

A2-204-010C, US Army Communications and Electronics Command, 18

December 1992, UNCLASSIFIED

AIntP-3 1994 AIntP-3, Military Intelligence Data Management and Exchange Concept,

October 1994, NATO UNCLASSIFIED:

Volume 1, Military Intelligence Data Management and Exchange Concept

Volume 2, Data Dictionary

AML Additional Military Layers (AML) Product Specification Environment

Seabed and Beach (ESB) Version 2.0

AML V 2.1 NOV 05 Additional Military Layers (AML) Product Specification Environment

Seabed and Beach (ESB) Version 2.1

APP-6A 1997 Military Symbols for Land-Based Systems, APP-6A, Military Agency for

Standardisation (MAS), 1 September 1997, NATO UNCLASSIFIED

APP-6B 2008 Military Symbols for Land-Based Systems, APP-6B, Military Agency for

Standardisation (MAS), June 2008, NATO UNCLASSIFIED

APP-9 1997 A Compendium of Allied Land Forces Messages (Change 1) (CD-ROM),

1997, NATO UNCLASSIFIED

ATCCIS WP ADatP-32

2000

AdatP-32, The Land C2 Information Exchange Data Model, Edition 2.0,

ATCCIS WG, SHAPE, Belgium, 31 March 2000, NATO UNCLASSIFIED

NOTE: This paper was published with the intent of making it a draft AdatP-

32

ATCCIS WP 3-1 2002 ATCCIS WP 3-1, Data Naming Procedures for the ATCCIS Data Model,

Edition 5.0, ATCCIS PWG, 18 March 2002, NATO UNCLASSIFIED


V3.1.4

J-3

ATCCIS WP 3-5 1997 ATCCIS Working Paper 3-5, ATCCIS Data Management, Draft Edition 1.0,

ATCCIS PWG, SHAPE, Belgium, 19 September 1997, NATO

UNCLASSIFIED

ATCCIS WP 3-6 2002 ATCCIS Working Paper 3-6, ATCCIS Key Management – A Strategy for

the Generation of Unique Keys, Edition 5.0, ATCCIS PWG, SHAPE,

Belgium,18 March 2002, NATO UNCLASSIFIED

ATCCIS WP 4-1 2002 ATCCIS WP 4-1, ATCCIS Information Resource Dictionary (AIRD)—

Definition of Structure and Contents, Edition 5.0, ATCCIS PWG, 18 March


ATCCIS WP 4-2 1994 ATCCIS WP 4-2, AIRD Management Procedures, Edition 2.0, ATCCIS

PWG, 2 June 1995, NATO UNCLASSIFIED

ATCCIS WP 5-5 2002 ATCCIS Working Paper 5-5, THE LAND C2 INFORMATION

EXCHANGE DATA MODEL, Edition 5.0, ATCCIS WG, SHAPE,

Belgium, 18 March 2002, NATO UNCLASSIFIED

ATCCIS WP 7L, 1989 ATCCIS WP 7L, Operational and Procedural Requirements for Data

Management and Standardization, Edition 1, ATCCIS PWG, June 1989,

NATO UNCLASSIFIED

ATCCIS WP 7N 1990 ATCCIS WP 7N, Standardization of Data for Interoperability, Edition 1,

ATCCIS PWG, September 1990, NATO UNCLASSIFIED

ATCCIS WP 10 1990 ATCCIS WP 10, Information Flow Requirements and Products for Each

Key Task, Edition 2, ATCCIS PWG, September 1990, NATO

UNCLASSIFIED

ATCCIS WP 14, 1990 ATCCIS WP 14, Information Exchange Requirements Between

Headquarters, Edition 2, ATCCIS PWG, September 1990, NATO

UNCLASSIFIED

ATCCIS WP 25 1994 ATCCIS WP 25, Technical Standards for Command and Control

Information Systems (CCISs) and Information Technology, ATCCIS PWG,

February 1994, NATO UNCLASSIFIED

ATP-1(C) Vol II 1983 Allied Maritime Tactical Signal and Maneuvering Book— ATP-1(C) Vol II

(STANAG 1174), October 1983, NATO RESTRICTED,

ATP-6(B) Vol I 1992 Mine Warfare Principles—ATP-6(B) (STANAG 1242), April 1992, NATO

CONFIDENTIAL

ATP-24(B) Vol I 1981 Mine Countermeasures—Tactics and Execution—ATP-24(B) Vol I

(STANAG 1132), August 1981, NATO CONFIDENTIAL,

ATP-27(B) 1993 Offensive Air Operations – ATP-27(B) (STANAG 3736), 18 November

1993, NATO UNRESTRICTED

ATP-27(C) 1999 Air Interdiction and Close Air Support – ATP-27(C) (STANAG 3736), June


ATP-35A 1995 Land Force Tactical Doctrine, ATP-35(A) (STANAG 2868, Edition 4.0),

Military Agency for Standardization, December 1995, NATO

UNCLASSIFIED

ATP - 45 (B) Reporting Nuclear Detonations, Biological And Chemical Attacks, and

Predicting and Warning Of Associated Hazards And Hazard Areas

(Operators Manual), ATP-45(B) (STANAG 2103, Edition 8.0) NATO,

NATO UNCLASSIFIED

ATP - 45 (C) Reporting Nuclear Detonations, Biological And Chemical Attacks, and

Predicting and Warning Of Associated Hazards And Hazard Areas

(Operators Manual), ATP - 45 (C) (STANAG 2103, Edition 9) NATO/PfP

UNCLASSIFIED

BI-MNC Reporting

Directive

Operations/Situations Reports, Volume III, SHAPE, 1 August 1997, NATO

UNCLASSIFIED/PfP Releasable

Bi-SC CDM Bi-Strategic Command (SC) Conceptual Data Model (CDM)

Bruce 1992 Designing Quality Databases with IDEF1X Information Models, Thomas A.

Bruce, Dorset House Publishing, 1992, UNCLASSIFIED


V3.1.4

J-4

C-M(55) 15 C-M(55) 15 FINAL, Security within the North Atlantic Treaty Organisation,

Enclosure C, Section 2, 15 Oct 97 Issue 3 NATO UNCLASSIFIED

DAFIF (DAFIF) Data Dictionary, Eighth Edition, May 2005, PS\1FDE\086

DEFSTAN 01-5 Iss 13

2002

MOD(GBR) Defence Standard 01-5 Issue 13, Fuel, Lubricants, and

Associated Products, January 2002.

DIGEST 1994 Digital Geographic Information Exchange Standard (DIGEST), Edition 1.2,

Volumes 1-4, January 1994, NATO UNCLASSIFIED. Also see STANAG

7074

DIS 10032 1991 DIS 10032, Information Technology - Reference Model on Data

Management, International Organisation for Standardization (ISO) and

International Electrotechnical Commission (IEC), 13 May 1991,

UNCLASSIFIED

FAA FAA Pilot/Controller Glossary (P/CG)

FACC 1994 Part 4 Feature and Attribute Coding Catalog (FACC), Digital Geographic

Information Exchange Standard (DIGEST), Edition 1.2, Defense Mapping

Agency, January 1994

FIPS PUB 183 1993 Integration Definition for Function Modeling (IDEF0), FIPS Pub 183,

December 1993, National Institute of Standards and Technology

FIPS PUB 184 1993 Integration Definition for Information Modeling (IDEF1X), FIPS Pub 184,

December 1993, National Institute of Standards and Technology

ISO/IEC 9075 1992 ISO/IEC 9075:1992, Database Language SQL

ISO 3166-1 ISO 3166-1: 1997, Codes for the representation of Names of Countries and

their Subdivisions – Part1: Country codes

JC3IEDM-GuideToCP JC3IEDM-GuideToCP, Guide To Change Proposals For MIP Data

Specifications, Edition 3.1c, 24 April 2008, MIP PMG, NATO

UNCLASSIFIED

JC3IEDM-Overview JC3IEDM-Overview, THE JOINT C3 INFORMATION EXCHANGE

DATA MODEL( JC3IEDM), Edition 3.1c, 24 April 2008, MIP PMG,

NATO UNCLASSIFIED

JC3IEDM-Processing of

Operational Requirements

JC3IEDM-Processing of Operational Requirements, Processing of

Operational Requirements, Edition 3.0, 9 December 2005 MIP PMG,

NATO UNCLASSIFIED

Joint Pub 1-02 2001 Department of Defense Dictionary of Military and Associated Terms

(Includes US Acronyms and Abbreviations and NATO Terms (English

Only)), Joint Publication Number 1-02, Joint Chiefs of Staff, April 2001

Amended through 17 October 2007, UNCLASSIFIED. Formerly JCS Pub

1-02

JSP 101 Joint Service Publication 101 (GBR), Meteorological Glossary, 6th Edition,

London HMSO

MCCIS CDM Georef MCCIS Conceptual Data Model (CDM) Geographical Reference segment

MCCIS CDM Surface MCCIS CDM Surface Warfare segment

Military Standard 6040

2001

USMTF: U.S. Message Text Formatting Program, Military Standard 6040,

DISA/JIEO, 31 March 2001, RESTRICTED USE

Military Standard 2525B Department of Defense Interface Standard, Common Warfighting

Symbology, 30 January 1999, UNCLASSIFIED

MIP MIRD 2005 MIP MIRD, MIP Information Resource Dictionary, Edition 3.0, MIP PMG,

9 December 2005, NATO UNCLASSIFIED

MIP MTIR MIP MTIR, MIP Tactical C2IS Interoperability Requirement, Draft, MIP

PMG, March 2005, NATO UNCLASSIFIED

NATO Reference Model NATO Reference Model, Version 4.0, NATO Data Administration Office

(NDAO), April 2004, NATO UNCLASSIFIED

FAA AIM Official Guide to Basic Flight Information and ATC (Air Traffic

Control) Procedures


V3.1.4

J-5

Oxford English Dictionary

1999

Oxford English Dictionary, Second Edition, 1999 Oxford University Press,

1999

SQL-99 ANSI SQL-99 (ISO/IEC 9075:1999: Database Language SQL) Database

Language SQL, Sections 1 and 2, 1 January 1999

STANAG 1166 STANAG 1166: Standard Ship Designator System, Edition 6, 2 October


STANAG 1241 STANAG 1241: NATO Standard Identity Description Structure for Tactical

Use, 16 October 1996, NATO RESTRICTED

STANAG 2014 STANAG 2014: Warning Orders, Operation Orders and

Administrative/Service Support Orders, Edition 8, October 1997, NATO

UNCLASSIFIED

STANAG 2021 STANAG 2021: Military computation of Bridge, Ferry, Raft and Vehicle

Classifications, 18 August 1990, NATO UNRESTRICTED

STANAG 2116 STANAG 2116: NATO Codes for Grades of Military Personnel, 13 March


STANAG 2257 STANAG 2257: MGD—Railways, Edition 4, 23 February 1993, NATO

UNCLASSIFIED

STANAG 2356 STANAG 2356: Comparative Formation Unit Designations, 21 March


STANAG 2934 STANAG 2934: Artillery Procedures—AArtyP-1, 20 June 1989, NATO

UNCLASSIFIED

STANAG 2961 STANAG 2961: Classes of Supply of NATO Land Forces, Edition 2, 19

September 2001, NATO UNCLASSIFIED

STANAG 2984 STANAG 2984: Graduated Levels of NBC Threats and Associated

Protection, Edition 5, 19 March 2001, NATO UNCLASSIFIED

STANAG 5048 STANAG 5048: The Minimum Scale of Connectivity for Communications

and Information Systems for NATO Land Forces, Edition 5, 16 February


STANAG 5525 STANAG 5525: Joint Consultation, Command, and Control Information

Exchange Data Model, December 2008, NATO UNCLASSIFIED

STANAG 5620 ND STANAG 5620: Standards for the Interoperability of Fire Support ADP

Systems, Part II, Annex E, ADatP-3 Formats, 27 Mar 1987, NATO

UNCLASSIFIED

STANAG 6001 STANAG 6001: Language Proficiency Levels, Edition 2, 11 June 2003,

NATO UNCLASSIFIED

STANAG 7074 STANAG 7074: Digital Information Exchange Standards (DIGEST) ,

Edition 2.1, September 2000, NATO UNCLASSIFIED

US AR 310-25 1986 US Army Regulation 310-25, Dictionary of United States Army Terms,

Headquarters Department of the Army, 21 May 1986

US FM 101-5-1/MCRP 5-

2a 1997

Operational Terms and Graphics, Headquarters Department of the Army

and United States Marine Corps, 30 September 1997 UNCLASSIFIED

US FM 101-10-1/1 1987 US Army Field Manual 101-10-1/1, Staff Officers’ Field Manual Volume 1:

Organizational, Technical, and Logistical Data, Headquarters Department of

the Army, October 1987

US FM 101-10-1/2 1987 US Army Field Manual 101-10-1/2, Staff Officers’ Field Manual Volume 2:

Organizational, Technical, and Logistical Data Planning Factors,

Headquarters Department of the Army, October 1987

US FM 1-02 2004 Department of Defense Dictionary of Operational Terms and Graphics

(Includes US Army and Marine Corps Acronyms and Abbreviations and

NATO Terms (English Only)) referenced from Joint Publication Number 1-

02, Joint Chiefs of Staff, May 1998, UNCLASSIFIED. Formerly JCS Pub

1-02, September 2004

US FM 3-06 2003 US Army Field Manual 3-06, Urban Operations Headquarters Department

of the Army, June 2003


V3.1.4

J-6

US FM 5-33 1990 US Army Field Manual 5-33 Terrain analysis, Headquarters Department of

the Army, 11 July 1990

US TB 55-46-1 1991 US Army Technical Bulletin 55-46-1, Standard Characteristics

(Dimensions, Weight, and Cube) for Transportability of Military Vehicles

and Other Outsize/Overweight Equipment, Department of the Army, 1

January 1991

WPI Pub 150 World Port Index Publication 150, 18th Edition


V3.1.4

K-1

Annex K: JC3IEDM Metamodel—

IDEF1X LOGICAL DATA MODEL DIAGRAM


V3.1.4

K-2

JC3IEDM MetamodelV3.1.4




consists-of

P

is-also-identified-by P

appears-in

provides-the-attribute-reference

identifies-update-seqnr-column

identifies-creator-id-column

is-discriminator-for

is-characterised-by

P

is-originator-for

describes-allowed-values-for

is-composed-of

is-composed-of

has

is-composed-of

is-part-of

Z

Z

holds

is-subtyped-via

contains

is-basis-for

discriminates

has-creator-id-and-update-seqnr-columns

Z

is-parent-of

is-child-of

unifies

is-source-for

migrates-from-parent(source)-

to-child(host)-entityP

ALTERNATE-KEY

entity-id (FK) (AK1.2)

alternate-key-index

alternate-key-number-quantity (AK1.1)

alternate-key-uniqueness-indicator-code (AK1.3)


entity-id (FK)


alternate-key-index (FK)

ATTRIBUTE


attribute-index







BASE-ATTRIBUTE

entity-id (FK)






domain-id (FK)

BUSINESS-RULE

business-rule-id















entity-id (FK)





business-rule-entity-attribute-composite-index (FK)


domain-id (FK)













CATEGORY-RELATIONSHIP






DOMAIN

domain-id (AK1.2)

domain-name-text (AK1.1)









DOMAIN-VALUE

domain-id (FK) (AK1.2,IE1.2)

domain-value-index

domain-value-description-text (AK1.1)

domain-value-name-text (IE1.1)


domain-value-type-code (AK1.3)



ENTITY

entity-id (AK1.2,AK2.2)

entity-name-text (AK1.1)

entity-table-name-text (AK2.1)



entity-depth-count





host-entity-id (FK)







base-entity-id (FK)


unifying-attribute-index (FK)

NON-KEY-ATTRIBUTE

entity-id (FK)




entity-id (FK)

creator-attribute-index (FK)

update-attribute-index (FK)


entity-id (FK)


RELATIONSHIP



relationship-index


SUBTYPE-RELATIONSHIP


sub-entity-id (FK)



domain-id (FK)


JC3IEDM-Metamodel-3.1.4

1, 1 / 1, 1 -- 8:08:06 AM , 5/12/2009


V3.1.4

L-1

Annex L: JC3IEDM Metamodel—

IDEF1X PHYSICAL DATA MODEL DIAGRAM


V3.1.4

L-1

1JC3IEDM MetamodelV3.1.4

consists_of99

P

is_also_identified_by P

appears_in

provides_the_attribute_referen

identifies_update_seqnr_column

identifies_creator_id_column

is_discriminator_for

Is_An_ATTR1Is_An_ATTR2

Is_An_ATTR4

Is_An_ATTR3

is_characterised_by

P

is_originator_for

describes_allowed_values_for

is_composed_of1

is_composed_of2

has

is_composed_of3

is_part_of99

Is_A_REL1

Z

Is_A_REL2

Z

holds

is_subtyped_via

contains99

is_basis_for

discriminates

has_creator_id_and_update_seqn

Z

is_parent_of

is_child_of

unifies

is_source_for

migrates_from_parent_source___ P

ALT_KEY

ent_id: NUMBER(8) NOT NULL (FK) (AK1.2)

ak_ix: NUMBER(2) NOT NULL

ak_no_qty: NUMBER(3) NOT NULL (AK1.1)

uniq_ind_code: VARCHAR(2) NOT NULL (AK1.3)

AK_ATTR

ent_id: NUMBER(8) NOT NULL (FK)

attr_ix: NUMBER(6) NOT NULL (FK)

ak_ix: NUMBER(2) NOT NULL (FK)

ATTR

ent_id: NUMBER(8) NOT NULL (FK) (IE1.1,IE2.1,IE3.1)

attr_ix: NUMBER(6) NOT NULL

name_txt: VARCHAR(160) NOT NULL (IE1.2)

col_name_txt: VARCHAR(30) NOT NULL (IE2.2)

attr_seqnr_ord: NUMBER(3) NOT NULL (IE3.2)

pk_ind_code: VARCHAR(2) NOT NULL

fk_ind_code: VARCHAR(2) NOT NULL

stdn_lvl_code: VARCHAR(6) NOT NULL

BASE_ATTR



def_txt: VARCHAR(999) NOT NULL

data_type_code: VARCHAR(7) NOT NULL

data_len_cnt: NUMBER(4) NOT NULL

data_dec_cnt: NUMBER(2) NULL

dom_id: NUMBER(9) NOT NULL (FK)

BR

br_id: NUMBER(12) NOT NULL

cat_code: VARCHAR(6) NOT NULL

section_xref_txt: VARCHAR(15) NOT NULL

name_txt: VARCHAR(999) NOT NULL

def_txt: VARCHAR(999) NULL

tab_xref_txt: VARCHAR(15) NULL

BR_ENT

br_id: NUMBER(12) NOT NULL (FK)

br_ent_ix: NUMBER(12) NOT NULL

ent_of_interest_id: NUMBER(8) NOT NULL (FK)

BR_ENT_ATTR_COMP


br_ent_ix: NUMBER(12) NOT NULL (FK)

br_ent_attr_comp_ix: NUMBER(12) NOT NULL

null_ind_code: VARCHAR(6) NOT NULL



BR_ENT_ATTR_COMP_DOM_VAL


br_ent_ix: NUMBER(12) NOT NULL (FK)

br_ent_attr_comp_ix: NUMBER(12) NOT NULL (FK)

br_ent_attr_comp_dom_val_ix: NUMBER(12) NOT NULL


dom_val_ix: NUMBER(12) NOT NULL (FK)

CARD_REL

pa_ent_id: NUMBER(8) NOT NULL (FK)

ch_ent_id: NUMBER(8) NOT NULL (FK)

rel_ix: NUMBER(2) NOT NULL (FK)

verb_name_txt: VARCHAR(60) NOT NULL

inv_verb_name_txt: VARCHAR(60) NULL

ident_ind_code: VARCHAR(2) NOT NULL

pa_card_code: VARCHAR(2) NOT NULL

ch_card_code: VARCHAR(2) NOT NULL

ch_mnm_card_cnt: NUMBER(3) NULL

ch_max_card_cnt: NUMBER(3) NULL

CAT

sup_ent_id: NUMBER(8) NOT NULL (FK)

cat_ix: NUMBER(2) NOT NULL


discr_ix: NUMBER(6) NOT NULL (FK)

compl_ind_code: VARCHAR(2) NOT NULL

DOM

dom_id: NUMBER(9) NOT NULL (AK1.2)

name_txt: VARCHAR(160) NOT NULL (AK1.1)


class_name_txt: VARCHAR(16) NOT NULL

restr_type_code: VARCHAR(2) NULL

meas_unit_descr_txt: VARCHAR(32) NULL

pa_dom_id: NUMBER(9) NULL (FK)


mod_lvl_code: VARCHAR(4) NOT NULL

def_src_txt: VARCHAR(100) NULL

DOM_VAL

dom_id: NUMBER(9) NOT NULL (FK) (AK1.2,IE1.2)

dom_val_ix: NUMBER(12) NOT NULL

descr_txt: VARCHAR(32) NOT NULL (AK1.1)

name_txt: VARCHAR(80) NULL (IE1.1)


type_code: VARCHAR(6) NOT NULL (AK1.3)


src_txt: VARCHAR(100) NULL

ENT

ent_id: NUMBER(8) NOT NULL (AK1.2,AK2.2)

name_txt: VARCHAR(80) NOT NULL (AK1.1)

tab_name_txt: VARCHAR(30) NOT NULL (AK2.1)


depen_code: VARCHAR(2) NOT NULL

depth_cnt: NUMBER(3) NOT NULL

stg_type_code: VARCHAR(4) NOT NULL


mod_lvl_code: VARCHAR(4) NOT NULL

FK_ATTR

host_ent_id: NUMBER(8) NOT NULL (FK)


role_def_txt: VARCHAR(999) NULL

rona_ind_code: VARCHAR(2) NOT NULL

src_ent_id: NUMBER(8) NOT NULL (FK)

src_attr_ix: NUMBER(6) NOT NULL (FK)

migr_rel_ix: NUMBER(2) NOT NULL (FK)

base_ent_id: NUMBER(8) NOT NULL (FK)

base_attr_ix: NUMBER(6) NOT NULL (FK)

unif_attr_ix: NUMBER(6) NULL (FK)

NK_ATTR



opt_ind_code: VARCHAR(2) NOT NULL

CREATOR_UPDATE_IDENTIFIC


creator_attr_ix: NUMBER(6) NULL (FK)

update_attr_ix: NUMBER(6) NULL (FK)

PK_ATTR



REL

pa_ent_id: NUMBER(8) NOT NULL (FK)

ch_ent_id: NUMBER(8) NOT NULL (FK)

rel_ix: NUMBER(2) NOT NULL

type_code: VARCHAR(2) NOT NULL

SUBT_REL

sup_ent_id: NUMBER(8) NOT NULL (FK)

sub_ent_id: NUMBER(8) NOT NULL (FK)

rel_ix: NUMBER(2) NOT NULL (FK)

cat_ix: NUMBER(2) NOT NULL (FK)


dom_val_ix: NUMBER(12) NOT NULL (FK)

JC3IEDM-Metamodel-3.1.4

1, 1 / 1, 1 -- 8:03:13 AM , 5/12/2009


V3.1.4