JC3IEDM Metamodel

Transcription

JC3IEDM Metamodel

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
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
ii
V3.1.4
CONTENTS
1.
1.1
2.
2.1
3.
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
4.
4.1
4.2
Introduction ........................................................................................................................1
Technical Specification of JC3IEDM Metamodel...............................................................1
JC3IEDM Metamodel Overview ......................................................................................2
Introduction ..........................................................................................................................2
JC3IEDM Metamodel .......................................................................................................3
Technical Descriptions of Entities in the metamodel ..........................................................3
ENTITY ...............................................................................................................................3
ATTRIBUTE .......................................................................................................................5
Unification of Foreign Key Attributes ...............................................................................15
Alternate Key View ...........................................................................................................15
Entity Relationships ...........................................................................................................18
DOMAIN ...........................................................................................................................25
Business Rules ...................................................................................................................29
CREATOR-UPDATE-IDENTIFICATION ......................................................................35
JC3IEDM CONCEPTS AND PHYSICAL SPECIFICATIONS FOR THE
JC3IEDM MODEL..........................................................................................................37
Metamodel CONCEPTS ....................................................................................................37
Physical Abbreviations ......................................................................................................39
Annexes
Annex A:
Annex B:
Annex C:
Annex D:
Annex E:
Annex F:
Annex G:
Annex H:
Annex I:
Annex J:
Annex K:
Annex L:
JC3IEDM Metamodel—Glossary
JC3IEDM Metamodel—Entity Definitions and Attributes
JC3IEDM Metamodel—Attribute Definitions
JC3IEDM Metamodel—Entity Relationships
JC3IEDM Metamodel—Specifications of Enumerated Domains
JC3IEDM Metamodel—Specification of Physical Domains
JC3IEDM Metamodel—Compendium of Business Rules
JC3IEDM Metamodel—Naming Conventions and Class Words
Summary of IDef1X Data Modelling Methodology and Notation
References
JC3IEDM Metamodel—IDef1X Logical Data Model Diagram
JC3IEDM Metamodel—IDef1X Physical Data Model Diagram
iii
V3.1.4
LIST OF FIGURES
Figure 1.
Figure 2.
Figure 3.
Figure 4.
Figure 5.
Figure 6.
Figure 7.
Attribute View..................................................................................................................8
Alternate Key View .......................................................................................................16
Category Relationship View ..........................................................................................18
Relationship View ..........................................................................................................20
Domain View .................................................................................................................25
Business Rule View .......................................................................................................30
Creator Update Identification View ...............................................................................35
iv
V3.1.4
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
v
V3.1.4
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
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.
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.
1
V3.1.4
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.
2
V3.1.4
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
3
V3.1.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
***-table-name***-dependency***-storage***-id
***-name-text
text
code
***-depth-count
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 ***-modellevel-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-todependent 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 entitydepth-count of 0.
2) Each subtype of an independent entity (PERSON-TYPE, ORGANISATIONTYPE, 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.
2
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
By definition, an independent entity cannot be the child of an identifying relationship.
4
V3.1.4
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-depthcount 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.
5
V3.1.4
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:
a.
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-KEYATTRIBUTE.
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-KEYATTRIBUTE.
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.
6
V3.1.4
Table 2. Instance Table for ATTRIBUTE
entity-id
***(FK)
index
***-name-text
10000013 100001 action-id
***-primary- ***-foreignkeykey******-sequenceindicatorindicator- standardisation***-column-name-text number-ordinal
code
code
level-code
act_id
1
PK
FK
MPCO
10000013 100002 action-resource-index act_res_ix
10000013 100003 action-resourceact_res_employ_ix
employment-index
cat_code
10000013 100004 action-resourceemployment-categorycode
azimuth_fire_angle
10000013 100005 action-resourceemployment-azimuthfire-angle
10000013 100006 action-resourcemethod_of_ctrl_code
employment-method-ofcontrol-code
trajectory_fire_code
10000013 100007 action-resourceemployment-trajectoryfire-code
10000013 100008 action-objective-index act_objve_ix
10000013 100009 physical model only
creator_id
10000013 100010 physical model only
10000013 100100 action-id
update_seqnr
act_id
2
3
PK
PK
FK
BA
MPCO
MPCO
4
NK
BA
MPCO
5
NK
BA
MPCO
6
NK
BA
MPCO
7
NK
BA
MPCO
8
9
NK
NK
FK
BA
MPCO
MPCO
10
1
NK
PK
BA
FK
MPCO
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-keyindicator-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.
7
V3.1.4
ATTRIBUTE
entity-id (FK) (IE1.1,IE2.1,IE3.1)
attribute-index
attribute-nam e-text (IE1.2)
attribute-colum n-name-text (IE2.2)
attribute-sequence-number-ordinal (IE3.2)
attribute-prim ary-key-indicator-code
attribute-foreign-key-indicator-code
attribute-standardisation-level-code
attribute-primary-key-indicator-code
BASE-ATTRIBUTE
entity-id (FK)
attribute-index (FK)
FOREIGN-KEY-ATTRIBUTE
host-entity-id (FK)
PRIMARY-KEY-ATTRIBUTE
entity-id (FK)
NON-KEY-ATTRIBUTE
is-source-for
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)
entity-id (FK)
base-attribute-definition-text
base-attribute-data-type-code
base-attribute-data-length-count
base-attribute-data-decimals-count
domain-id (FK)
is-originator-for
unifies
non-key-attribute-optionality-indicator-code
Figure 1. Attribute View
3.3.2 PRIMARY-KEY-ATTRIBUTE
3.3.2.1 PRIMARY-KEY-ATTRIBUTE is a subtype of ATTRIBUTE under the
PRIMARY-KEYcategory
discriminator
attribute-primary-key-indicator-code.
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-KEYATTRIBUTE 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-KEYATTRIBUTE from the category (subtype) relationship from ATTRIBUTE. The attributes
of PRIMARY-KEY-ATTRIBUTE are the following:
a.
b.
3.3.2.3 The table below is an example instance table for PRIMARY-KEYATTRIBUTE.
8
V3.1.4
Table 3. Instance Table for PRIMARY-KEY-ATTRIBUTE
entity-id (FK)
10000002(ABSOLUTE-POINT)
10000027(CONE-VOLUME)
10000227(RELATIVE-COORDINATESYSTEM)
10000214(CORRIDOR-AREA)
10000215(ELLIPSE)
10000048(FAN-AREA)
10000055(GEOMETRIC-VOLUME)
10000061(LINE)
10000062(LINE-POINT)
10000063(LOCATION)
10000228(OBJECT-REFERENCE)
100001(absolute-point-id)
100001(cone-volume-id)
100001(relative-coordinatesystem-id)
100001(corridor-area-id)
100001(ellipse-id)
100001(fan-area-id)
100001(geometric-volume-id)
100001(line-id)
100001(line-id)
100002(line-point-index
100001(location-id)
100001(orbit-area-id)
100001(point-id)
100001(polyarc-area-id)
100001(polygon-area-id)
100001(relative-point-id)
100001(sphere-volume-id)
100001(surface-id)
100001(surface-volume-id)
100001(track-area-id)
100001(vertical-distance-id)
10000216(ORBIT-AREA)
10000105(POINT)
10000229(POINT-REFERENCE)
10000217(POLYARC-AREA)
10000218(POLYGON-AREA)
10000111(RELATIVE-POINT)
10000219(SPHERE-VOLUME)
10000119(SURFACE)
10000220(SURFACE-VOLUME)
10000221(TRACK-AREA)
10000222(VERTICAL-DISTANCE)
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-KEYATTRIBUTE are the following:
a.
b.
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.
9
V3.1.4
Table 4. Instance Table for NON-KEY-ATTRIBUTE
entity-id (FK)
10000282(GEOGRAPHICPOINT)
10000227(RELATIVECOORDINATE-SYSTEM)
10000063(LOCATION)
10000105(POINT)
100002(geographic-point-latitude-coordinate)
non-key-attributeoptionality-indicator-code
MA
100003(geographic-point-longitude-coordinate)
MA
100004(geographic-point-latitude-precision-code)
OP
100002(relative-coordinate-system-referencecategory-code)
100003(line-point-sequence-ordinal)
100002(location-category-code)
100002(point-category-code)
100002(polyarc-area-begin-bearing-angle)
100003(polyarc-area-end-bearing-angle)
100004(polyarc-area-arc-radius-dimension)
100002(relative-point-x-coordinate-dimension)
100003(relative-point-y-coordinate-dimension)
100004(relative-point-z-coordinate-dimension)
100005(relative-point-x-precision-code)
100006(relative-point-y-precision-code)
MA
MA
MA
MA
MA
MA
MA
MA
MA
OP
OP
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 BASEATTRIBUTE 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:
a.
b.
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.
10
V3.1.4
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-allowedvalues-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
100002(geographic-point-latitude-coordinate)
***-definitiontext
The numeric...
***-datatype-code
NUMBER
100003(geographic-point-longitude-coordinate)
The numeric...
NUMBER
100004(geographic-point-latitude-precisioncode)
100002(relative-coordinate-system-referencecategory-code)
100002(line-point-index)
100003(line-point-sequence-ordinal)
100002(location-category-code)
100002(point-category-code)
100002(polyarc-area-begin-bearing-angle)
The specif...
CHAR
The specif...
CHAR
entity-id (FK)
10000227(RELATIVECOORDINATE-SYSTEM)
10000063(LOCATION)
10000105(POINT)
100003(polyarc-area-end-bearing-angle)
100004(polyarc-area-arc-radius-dimension)
100002(relative-point-x-coordinate-dimension)
100003(relative-point-y-coordinate-dimension)
100004(relative-point-z-coordinate-dimension)
100005(relative-point-x-precision-code)
100006(relative-point-y-precision-code)
Note: *** = “base-attribute”
***-data-length-count
9
10
6
6
20
6
6
6
7
7
12
12
12
12
6
6
***-data-decimal-count
6
6
4
4
3
3
3
3
The unique...
The positive...
The specif...
The specif...
The
rotational...
The
rotational...
The onedimensionalG
The one-di...
The one-di...
The one-di...
The specif...
The specif...
NUMBER
NUMBER
CHAR
CHAR
NUMBER
NUMBER
NUMBER
NUMBER
NUMBER
NUMBER
CHAR
CHAR
domain-id
100000401
100000402
100004218
100004121
100001000
100002200
100000138
100000200
100000000
100000000
100000600
100000600
100000600
100000600
100004218
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.
11
V3.1.4
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-KEYATTRIBUTE 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).
b.
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 FOREIGNKEY-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-KEYATTRIBUTE under the same relationship (“migrates-from-parent(source)-tochild(host)-entity” from RELATIONSHIP) intentionally unifies with the sourceentity-id (FK) that is already a descriptive, non-key attribute of FOREIGN-KEYATTRIBUTE.
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”
12
V3.1.4
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-KEYATTRIBUTE 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 FOREIGNKEY-ATTRIBUTE under the relationship “is-originator-for” from BASEATTRIBUTE.
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 attributeindex). 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-KEYATTRIBUTE.
13
V3.1.4
Table 6. Instance Table for FOREIGN-KEY-ATTRIBUTE
hostentity-id
(FK)
10000002
(ABSOLU
TEPOINT)
10000061
(LINE)
10000062
(LINEPOINT)
10000062
(LINEPOINT)
10000105
(POINT)
10000111
(RELATIV
E-POINT)
10000111
(RELATIV
E-POINT)
attributeindex
(FK)
100001
(absolutepoint-id)
***-roledefinitiontext
The pointG
100001
(line-id)
100001
(line-id)
The
locationG
The
locationG
100004
(line-pointpoint-id)
100001
(point-id)
100001
(relativepoint-id)
100008
(relativecoordinate
-systemid)
The pointG
The
locationG
The pointG
The unique
valueG
***rolenameindicatorcode
RN
sourceentity-id
(FK)
10000105
(POINT)
sourceattributeindex (FK)
100001
(point-id)
10000063
(LOCATION)
10000061
(LINE)
100001
(location-id)
100001
(line-id)
RN
10000105
(POINT)
100001
(point-id)
RN
10000063
(LOCATION)
10000105
(POINT)
100001
(location-id)
100001
(point-id)
RN
MN
RN
MN
10000227
100001
(RELATIVE(relativeCOORDINA
coordinateTEsystem-id)
SYSTEM)
Note: *** = “foreign-key-attribute”
migratingrelationshipindex (FK)
1
base-entityid
(FK)
10000063
(LOCATION)
baseattributeindex
(FK)
100001
(location-id)
10000063
(LOCATION)
10000063
(LOCATION)
100001
(location-id)
100001
(location-id)
1
10000063
(LOCATION)
100001
(location-id)
1
10000063
(LOCATION)
10000063
(LOCATION)
100001
(location-id)
100001
(location-id)
1
1
2
1
10000227
(RELATIVECOORDINA
TESYSTEM)
100001
(relativecoordinatesystem-id)
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 FOREIGNKEY-ATTRIBUTE, as explained in the next section.
14
V3.1.4
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.
4
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
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.
15
V3.1.4
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.
ATTRIBUTE
attribute-index
ALTERNATE-KEY
entity-id (FK) (AK1.2)
alternate-key-index
attribute-name-text (IE1.2)
attribute-column-name-text (IE2.2)
alternate-key-number-quantity (AK1.1)
alternate-key-uniqueness-indicator-code (AK1.3)
ALTERNATE-KEY-ATTRIBUTE
appears-in
entity-id (FK)
alternate-key-index (FK)
consists-of
P
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-numberquantity.”
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-alsoidentified-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:
a.
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.
16
V3.1.4
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)
10010011
[DOMAIN-VALUE]
10010011
[DOMAIN-VALUE]
10010012
[ENTITY]
10010012
[ENTITY]
alternate-key-index
alternate-key-numberquantity
1
1
2
1
1
1
2
2
alternate-key-uniquenessindicator-code
AU
[Alternate Key]
MU
[Inversion Entry]
AU
[Alternate Key]
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 ALTERNATEKEY-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:
a.
b.
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-KEYATTRIBUTE.
17
V3.1.4
Table 8. Instance Table for ALTERNATE-KEY-ATTRIBUTE
entity-id (FK)
10010011
[DOMAIN-VALUE]
10010011
[DOMAIN-VALUE]
10010011
[DOMAIN-VALUE]
10010011
[DOMAIN-VALUE]
10010011
[DOMAIN-VALUE]
10010012
[ENTITY]
10010012
[ENTITY]
10010012
[ENTITY]
10010012
[ENTITY]
3.6
100003
[domain-value-description-text (AK1.1)]
100001
[domain-id (AK1.2)]
100007
[domain-value-type-code (AK1.3)]
100004
[domain-value-name-text (IE1.1)]
100001
[domain-id (IE1.2)]
100002
[entity-name-text (AK1.1)]
100001
[entity-id (AK1.2)]
100003
[entity-table-name-text (AK2.1)]
100001
[entity-id (AK2.2)]
1
1
1
2
2
1
1
2
2
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
18
V3.1.4
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 CATEGORYRELATIONSHIP 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 CATEGORYRELATIONSHIP.
Table 9. Instance Table for CATEGORY-RELATIONSHIP
super-entity-id (FK)
10000043 (FACILITY)
10000049 (FEATURE)
10000063 (LOCATION)
10000070 (MATERIEL-TYPE)
10000076 (OBJECT-ITEM)
10000085 (ORGANISATION)
10000105 (POINT)
***-definitiondiscriminator-attribute***-index
text
index (FK)
1
—
100002
1
—
100002
1
—
100002
1
—
100002
1
—
100002
1
—
100002
1
—
100002
Note: *** = “category-relationship”
19
***-completenessindicator-code
IC
IC
CC
IC
IC
IC
CC
V3.1.4
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 relationshiptype-code: CARDINALITY-RELATIONSHIP and SUBTYPE-RELATIONSHIP. The
relationship structure is shown in the figure below.
Figure 4. Relationship View
20
V3.1.4
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-relationshipidentifying-indicator-code” (identifying, nonidentifying); a “cardinality-relationshipparent-cardinality-code” (one = mandatory, zero-or-one = optional); a “cardinalityrelationship-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 cardinalityrelationship-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: CARDINALITYRELATIONSHIP; 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)
10000063 (LOCATION)
10000063 (LOCATION)
10000063 (LOCATION)
10000063 (LOCATION)
10000203 (MILITARYORGANISATION-TYPE)
child-entity-id (FK)
10000055 (GEOMETRIC-VOLUME)
10000061 (LINE)
10000105 (POINT)
10000119 (SURFACE)
10000204 (MILITARY-POST-TYPE)
10000243 (OBJECT-ITEM-ASSOCIATION)
10000243 (OBJECT-ITEM-ASSOCIATION)
10000008 (ACTION-OBJECTIVE)
10000012 (ACTION-RESOURCE)
10000170 (ORGANISATION-ACTION-ASSOCIATION)
10000157 (REPORTING-DATA)
10000247 (ACTION-OBJECTIVE-ITEM-MARKING)
10000128 (UNIT)
21
relationshipindex
1
1
1
1
1
relationshiptype-code
SR
SR
SR
SR
SR
1
2
1
1
1
1
1
1
CR
CR
CR
CR
CR
CR
CR
SR
V3.1.4
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 relationshiptype-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
c.
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.
22
V3.1.4
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 CARDINALITYRELATIONSHIP.
Table 11. Instance Table for CARDINALITY-RELATIONSHIP
relation
-shipindex
(FK)
1
parent-entity-id
(FK)
10000063
(LOCATION)
child-entity-id
(FK)
10000050 (FEATURELOCATION)
10000085
(ORGANISATION)
10000008 (ACTIONOBJECTIVE)
1
10000085
(ORGANISATION)
10000012 (ACTIONRESOURCE)
1
is-authorityfor-the-use-of
10000076
(OBJECT-ITEM)
10000076
(OBJECT-ITEM)
10000076
(OBJECT-ITEM)
10000243 (OBJECT-ITEMASSOCIATION)
10000243 (OBJECT-ITEMASSOCIATION)
10000224 (OBJECT-ITEMLOCATION)
1
10000085
(ORGANISATION)
10000170 (ORGANISATIONACTION-ASSOCIATION)
1
10000085
(ORGANISATION)
10000157 (REPORTINGDATA)
1
10000085
(ORGANISATION)
is-the-subjectof
is-the-objectof
isgeometricallydefinedthrough
has-its-rolespecifiedthrough
is-thereportingagent-for
is-the-user-of
10000247 (ACTION1
OBJECTIVE-ITEM-MARKING)
Note: *** = “cardinality-relationship”
2
1
***-verbname-text
providesgeometricdefinition-for
is-authorityfor-the-use-of
***inverseverbnametext
***identifyin
gindicatorcode
ID
***parentcardinali
ty-code
MA
***-childcardinali
ty-code
ZM
is-usedasspecified
-by
is-usedasspecified
-by
NI
OP
ZM
NI
OP
ZM
ID
MA
ZM
ID
MA
ZM
ID
MA
ZM
ID
MA
ZM
NI
MA
ZM
NI
MA
ZM
isreportedby
is-usedby
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 SUBTYPERELATIONSHIP, 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).
23
V3.1.4
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-typecode). 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 SUBTYPERELATIONSHIP is given the role name sub-entity-id (FK). The attributes of SUBTYPERELATIONSHIP 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
c.
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 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 SUBTYPERELATIONSHIP.
Table 12. Instance Table for SUBTYPE-RELATIONSHIP
10000063 (LOCATION)
10000063 (LOCATION)
10000063 (LOCATION)
10000063 (LOCATION)
sub-entity-id (FK)
10000055 (GEOMETRICVOLUME)
10000061 (LINE)
10000105 (POINT)
10000119 (SURFACE)
10000128 (UNIT)
relationshipindex (FK)
1
categoryrelationshipindex (FK)
1
domain-id
10000138
domainvalue-index
1000004
1
1
1
1
1
1
1
1
10000138
10000138
10000138
10000149
1000002
1000001
1000003
1000004
24
V3.1.4
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).
25
V3.1.4
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.
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
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.
26
to
V3.1.4
Table 13. Instance Table for DOMAIN
domain-id
100000000
100000100
100000110
***class-nametext
angle
code
code
***restrictiontype-code
RA
EN
EN
parentdomain-id
(FK)
***standardis
ation-levelcode
MPCO
MPCO
MPCO
***-modellevel-code
APPL
APPL
APPL
***definitionsource-text
—
—
—
***-name-text
angle
code
action100000100
category-code
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-descriptiontext.
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-valuedescription-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.
27
V3.1.4
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 DOMAINVALUE are the following:
a.
b.
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 DOMAINVALUE. 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 standardisationlevel-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.
28
V3.1.4
Table 14. Instance Table for DOMAIN-VALUE
domain-id
(FK)
100000000
100000000
100000000
100000110
***-index
1000001
1000002
1000003
1000003
***description
-text
0
0
359.9999
ACTEV
100000110
1000004
ACTTA
100000601
100000602
100001312
100001400
1000002
1000002
1000002
1000002
***nametext
***-typecode
DFLT
MIN-IN
MAX-IN
ELEM
***standardisation
-level-code
MPCO
MPCO
MPCO
MPCO
ELEM
MPCO
0
MIN-IN
0
MIN-IN
0
MIN-IN
-273.75
MIN-IN
Note: Not shown in the instance table is the attribute ***-source-text.
Note: *** = “domain-value”
MPCO
MPCO
MPCO
MPCO
ACTIONEVENT
ACTIONTASK
***-definition-text
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.
An ACTION that is being or has
been planned and for which the
planning details are known.
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-ENTITYATTRIBUTE-COMPOSITE-DOMAIN-VALUE. An indicator code specifies whether a
value must be specified for the attribute. The entity BUSINESS-RULE-ENTITYATTRIBUTE-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.
29
V3.1.4
ENTITY
ATTRIBUTE
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
attribute-index
is-characterised-by
P
provides-the-attribute-reference
has
BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE
BUSINESS-RULE-ENTITY
business-rule-id (FK)
business-rule-entity-index
is-composed-of
entity-of-interest-id (FK)
business-rule-entity-index (FK)
business-rule-entity-attribute-composite-index
business-rule-entity-attribute-composite-null-indicator-code
entity-id (FK)
is-composed-of
BUSINESS-RULE
business-rule-id
is-composed-of
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-ATTRIBUTE-COMPOSITE-DOMAIN-VALUE
business-rule-entity-index (FK)
business-rule-entity-attribute-composite-index (FK)
business-rule-entity-attribute-composite-domain-value-index
domain-id (FK)
domain-value-index (FK)
DOMAIN
is-part-of
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
parent-domain-id (FK)
domain-standardisation-level-code
domain-model-level-code
domain-definition-source-text
contains
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
is-basis-for
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, businessrule-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.
30
V3.1.4
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 BUSINESSRULE.
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)
100000000026
**categorycode
RULE
**-sectioncrossreferencetext
G2.7.1
**-name-text
G2.7.1 General Association Rules The
permissible domain values for object-itemassociation-category-code for various
combinations of subject and object OBJECTITEM are listed in Table G2-42. The last
column indicates that the object-itemassociation-subcategory-code is to be used
only when instances of subject and object
OBJECT-ITEM are ORGANISATIONs.
Note: ** = “business-rule”
**-definitiontext
Business
Rules for
OBJECTITEMASSOCIATIO
N Category
and
Subcategory
Codes
**-tablecrossreferencetext
Table G2-42
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.
31
V3.1.4
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 BUSINESSRULE-ENTITY are the following:
a.
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-RULEENTITY. 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
100000000026
business-rule-entity-index (PK)
100000000020
10000243
3.8.2.4 The specification for the JC3IEDM Metamodel has to ensure that businessrule-entity-(indices) are not reused. If the semantic understanding of an existing businessrule-entity-index has changed, then a new key should be generated for the new businessrule-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-RULEENTITY.’ 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-RULEENTITY-ATTRIBUTE-COMPOSITE are the following:
a.
b.
BUSINESS-RULE.
c.
business-rule-entity-attribute-composite-index—The unique value, or set of
characters, assigned to represent a specific BUSINESS-RULE-ENTITYATTRIBUTE-COMPOSITE for a specific BUSINESS-RULE-ENTITY and to
32
V3.1.4
distinguish it from all other BUSINESS-RULE-ENTITY-ATTRIBUTECOMPOSITEs 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-ATTRIBUTECOMPOSITE is permitted to be unspecified within the specific BUSINESS-RULE.
The domain values are: No; Yes.
e.
f.
3.8.3.3 The table below is an example instance table for BUSINESS-RULEENTITY-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)
100000000026
100000000026
100000000026
100000000026
****-nullindicatorentity-id
***-index (FK)
****-index (PK)
code
(FK)
100000000020
100000000001
NO
10000076
100000000020
100000000002
NO
10000076
100000000020
100000000003
NO
10000243
100000000020
100000000004
YES
10000243
Note: *** = “business-rule-entity”
Note: **** = “business-rule-entity-attribute-composite”
attribute-index
(FK)
100002
100002
100004
100005
3.8.3.4 The specification for the JC3IEDM Metamodel has to ensure that businessrule-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-DOMAINVALUE 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-DOMAINVALUE is identified by the primary key attributes, business-rule-id (FK), business-ruleentity-index (FK), business-rule-entity-attribute-composite-index (FK) and business-ruleentity-attribute-composite-domain-value-index (PK). The attributes of BUSINESS-RULEENTITY-ATTRIBUTE-COMPOSITE-DOMAIN-VALUE are the following:
a.
b.
33
V3.1.4
BUSINESS-RULE.
c.
business-rule-entity-attribute-composite-index—The unique value, or set of
characters, assigned to represent a specific BUSINESS-RULE-ENTITYATTRIBUTE-COMPOSITE for a specific BUSINESS-RULE-ENTITY and to
distinguish it from all other BUSINESS-RULE-ENTITY-ATTRIBUTECOMPOSITEs 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-ENTITYATTRIBUTE-COMPOSITE-DOMAIN-VALUE for a specific BUSINESS-RULEENTITY-ATTRIBUTE-COMPOSITE and to distinguish it from all other
BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE-DOMAIN-VALUEs for
that BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE.
e.
f.
3.8.4.3 The table below is an example instance table for BUSINESS-RULEENTITY-ATTRIUBTE-COMPOSITE-DOMAIN-VALUE.
Table 18. Instance Table for BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE-DOMAINVALUE
business-rule-id
(FK)
100000000026
100000000026
100000000026
100000000026
100000000026
100000000026
100000000026
100000000026
100000000026
100000000026
******-index
*****-index (FK)
(PK)
domain-id (FK)
100000000001
100000000001
100000144
100000000002
100000000001
100000144
100000000003
100000000001
100004142
100000000004
100000000001
100000297
100000000004
100000000002
100000297
100000000004
100000000003
100000297
100000000004
100000000004
100000297
100000000004
100000000005
100000297
100000000004
100000000006
100000297
100000000004
100000000007
100000297
Note: **** = “business-rule-entity”
Note: ***** = “business-rule-entity-attribute-composite”
Note: ****** = “business-rule-entity-attribute-composite-domain-value”
****-index (FK)
100000000020
100000000020
100000000020
100000000020
100000000020
100000000020
100000000020
100000000020
100000000020
100000000020
domain-valueindex (FK)
1000004
1000004
1000007
1000012
1000047
1000001
1000002
1000004
1000003
1000005
3.8.4.4 The specification for the JC3IEDM Metamodel has to ensure that businessrule-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-attributecomposite-domain-value-index. It is expected that no new identifier with a value less than
the highest used identifier (+ 1) will ever be used.
34
V3.1.4
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-seqnrcolumns” 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-seqnrcolumn” from the entity ATTRIBUTE. The attributes of CREATOR-UPDATEIDENTIFICATION are the following:
a.
b.
creator-attribute-index—The attribute-index for a specific CREATOR-UPDATEIDENTIFICATION 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-UPDATEIDENTIFICATION that identifies the update-seqnr of a specific record (a role name
for attribute-index).
35
V3.1.4
3.9.3 The table below is an example instance table for CREATOR-UPDATEIDENTIFICATION.
Table 19. Instance Table for CREATOR-UPDATE-IDENTIFICATION
entity-id
(FK)
10000002
10000003
10000004
10000005
10000006
creatorattribute-index
(FK)
100004
100004
100010
100005
100007
36
update-attributeindex (FK)
100005
100005
100011
100006
100008
V3.1.4
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 “entitymodel-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.
5
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
This attribute occurs for the following: ENTITY, ATTRIBUTE, DOMAIN, and DOMAIN-VALUE.
37
V3.1.4
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 “organisationtype-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.entityid. 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-entityindex,
business-rule-entity-attribute-composite-index,
business-rule-entity-attributecomposite-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)
38
V3.1.4
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
angle
binary object
code
coordinate
count
datetime
dimension
duration
identifier / id
index
ordinal
quantity
rate
ratio
temperature
text
amt
angle
binobj
code
coord
cnt
dttm
dim
dur
id
ix
ord
qty
rate
rat
tmpr
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
ALTERNATE
alt
alternate-key-attribute
ak_attr
ATTRIBUTE
attr
BUSINESS-RULE
br
cardinality
card
child
composite
column
ch
comp
col
completeness
compl6
cross-reference
xref
datatype
daty
decimals
dec
definition
def
dependency
depen
document
domain
doc
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.
39
V3.1.4
Logical Term
domain-value
entity
foreign-key
hierarchy
identifying
dom_val
ent
fk
hier
ident
inverse
inv
length
len
measurement
meas
migrating
migr
model
non-key
optionality
mod
nk
opt
parent
primary-key
reference
pa
pk
ref
relationship
rel7
restriction
restr
rolename
rona
sequence-number
seqnr
source
src
standardisation
stdn
status
stat
storage-type-code
subtype-relationship
super
stg_type_code
subt_rel
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.
40
V3.1.4
Annex A: JC3IEDM Metamodel—
GLOSSARY
A-1
V3.1.4
1 R IRISH
AAP
AAP
AAP-6
ABCA
AC
ACE
ACK
ACO
ACP
ACS
ACSE
ACT
ACT DAO
AD
ADatP–3
ADM
ADMD
AEngrP
AFNORTH
AFS
AFV
AH
AI
AICM
AIntP-3
AIRCENT
AMLESB
AN
ANSI
AOI
AOR
APC
APDU
API
APP
APPL
APP-10
APP-6A
APP-9
AR
ARM
Armd
ARP
ARRC
Arty
ASAP
ASCA
ASCII
ASN.1
ASSOCMAN
ASUW
ASW
The Royal Irish Rangers
NATO Standardisation Agreements and Allied Publications
Allied Administrative Publication
Allied Administrative Publication N° 6 - NATO Glossary of Terms and Definitions
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
Active Status
Allied Command Europe
Acknowledgement
Airspace Control Order / Allied Command for Operations
Allied Communications Publication
Automated Channel Selection
Association Control Service Element
Allied Command Transformation
Allied Command Transformation, Data Administration Office
Air Defence
Allied Data Publication Message Formats
ATCCIS Data Model
Administration Management Domain
Allied Engineering Publication
Allied Forces Northern Region
ADatP-3 Formatting Staff
Armoured Fighting Vehicle
Attack Helicopter
Air Interdiction
Aeronautical Information Conceptual Model
Allied Intelligence Publication 3
Allied Air Forces Central Europe
Additional Military Layers - Environment Seabed and Beach
Access Node
American National Standards Institute
Area of Interest
Area of Responsibility
Armoured personnel carrier
Application Protocol Data Unit
Application Programming Interface
Allied Procedural Publication
Application
Allied Procedural Publication N° 10 - NATO Interoperability Document
Allied Procedural Publication N° 6A - Military symbols for Land Based Systems
Allied Procedural Publication N° 9 - Compendium of Allied Forces Messages
Armored – US designation / Army Regulation
ATCCIS Replication Mechanism
Armoured
Address Resolution Protocol
ACE Rapid Reaction Corps
Artillery
Application service access point
Artillery Systems Cooperation Activities
American Standard Code for Information Interchange
Abstract Syntax Notation 1
Association Manager
Anti Surface Warfare
Anti-submarine warfare
A-1
V3.1.4
ATacCS
ATCCIS
ATCCS
ATCP
ATP
ATP-35(B)
AUS
AUT
AUTOKO
AWG
BAI
Bde
BE
BEL
BFV
BG
BGR
BICES
BIGSTAF
BIP
BiSC
BL
BMHS
BMP
BMS
Bn, BN
BOA
BPD
Bty
C
C2
C2IEDM
C2IS
C2S
C3
C4I DTF
CAN
CAS
CASP
CAV
CBRN
CBT
CCEB
CCIR
CCIS
CCWG
CDC
CE
CEE
CEOI
CET
CFCS
CFE
cGY
CIS
Army Tactical Computer System
Army Tactical Command and Control Information System
Army Tactical Command and Control System (USA)
Air Traffic Control Procedures
Allied Technical Publication
Allied Tactical Publication 35(B) - Land Forces Tactical Doctrine
Australia
Austria
AUTOmatisiertes KOmmunikationsnetz
ATCCIS Working Group
Battlefield air interdiction
Brigade
Basic Encyclopedia - a target numbering scheme
Belgium
Bradley Fighting Vehicle
Battle Group (Equivalent to a US Battalion)
Bulgaria
Battlefield Intelligence Collection and Exploitation System
Breitbandiges Integriertes Gefechtsstandfernmeldenetz
Battlefield Interoperability Programme
Bi Strategic Commands (NATO)
Baseline
BIP Message Handling System
Russian fighting vehicle
Battlefield Management System
Battalion
Basic Object Adaptor
Boundary Protection Device
Battery
Conditional
Command and Control
Command and Control Information Exchange Data Model (formerly named LC2IEDM)
Command and Control Information Systems
Command and Control System
Command, Control and Communications / Consultation, Command, and Control [NATO
usage]
Object Management Group (OMG) C4I Domain Task Force
Canada or Canadian
Close Air Support
Coordinated Air Sea Procedure
Cavalry
Chemical, Biological, Radiological and Nuclear
Combat
Combined Communication Electronic Board
Commander's Critical Information Requirements
Command and Control Information System
Configuration Control Working Group
Center for Disease Control
Combined Endeavour
Common Engineering Environment
Communication and Electronic Operating Instruction
Combat Engineer Tractor
Command and Fire Control System
Conventional Forces Europe
Centigray
Communications and Information System
A-2
V3.1.4
CJTF
CM
CMBG
CMO
CMSR
CN
CNR
COD
COI
COLOC
COMMS
COMSEC
COP
CORBA
CoStEx
COTS
Coy, COY
CP
CP
CPX
CRC
CRLF
CRO
CSMA/CD
CWID
CZE
DAFIF
DB
DBA
DDDS
DDL
DEM
DEMS
DES
DEU
DIGEST
Div, DIV
DMSWG
DMWG
DNK
DoD
DOS
DP
DPC
DR
DSN
DSP
DTG
E.G.
ECCM
ECM
ED50
E-IARRCIS
EID
E-Mail
EMC
Combined & Joint Task Force
Configuration Management
Combat Brigade Group (CAN)
Civil/Military Operations
Configuration Management Status Report
Change Notice
Combat Net Radio
Concise Oxford Dictionary
Community of Interest
Change of Location of Command
Communications
Communication Security
Common Operational Picture
Common Object Request Broker Architecture
Command and Staff Exercise
Commercial Off The Shelf
Company
Change Proposal
Command Post
Command Post Exercise
Cyclic Redundancy Check
Carriage Return Line Feed
Crisis Response Operations
Carrier Sense Multiple Access / Collision Detection
Coalition Warrior Interoperability Demonstration
Czech Republic
Digital Aeronautical Flight Information File
Database
ADatP-3 Data Base Administrator
Defense Data Dictionary System (USA)
Database Definition Language / Data Definition Language
Data Exchange Mechanism
Data Exchange Mechanism Schema
Data Exchange Schema
Germany or German
Digital Geographic Exchange Standard
Division
Data Management Services Working Group (formerly NDAG)
Data Modelling Working Group
Denmark
Department of Defense (USA)
Day of supply
Data Provider
Defence Planning Committee (NATO)
Data Receiver
Delivery Status Notification
Digital signal processor
Day Time Group
Exempli Gratia – As Example
Electronic Counter – Counter Measures
Electronic Counter Measures
European Datum 50
Enhanced Interim ARRC Information System
Experimental Interoperability Database
Electronic Mail
Electro-Magnetic Compatibility
A-3
V3.1.4
EMCON
Engr
ENVID
EOD
EoS
EQPMT
ER
ERWIN
ERwin ™
ESMTP
ESP
ETA
EUROFOR
EW
EXCON
FA
FAA
FAAP/CG
FACC
FAFCISO
FBI
FD
FFIR
FFIRN
FUD
FH
FIBE
FIMU
FIN
FIPS
FK
F-Kill
FLET
FLIP
FLOT
FM
FORMETS
FRA
FS
FSCL
FTP
FUD
FUDN
FUI
GBR
GeFüSys
GEL
GEW
GH
GIE
GIS
GOIDG
GPOC
GRC
GW
HCDR
Emission Control
Engineer, Engineering
Envelope ID
Explosive Ordnance Disposal
Element of Service
Equipment
Entity Relationship
CaseTool ER=entity-relationship WIN=Windows-based
IDEF1X software tool from Computer Associates (Versions 3.5.2 and 4.1.4 SP3)
Extended Simple Mail Transfer Protocol
Spain
Estimated Time of Arrival
European Force
Electronic Warfare
Exercise Control
Field Artillery
Federal Aviation Administration
Federal Aviation Administration Pilot/Controller Glossary
Feature and Attribute Coding Catalog (Volume 4 of the DIGEST standard)
Federal Armed Forces CIS Organization
Federal Bureau of Investigation (USA)
Field Demonstration
Friendly Forces Information Requirements
Field Format Index Reference Number
Field Use Designator
Frequency Hopping
Field Initiated Basic Encyclopedia—a target numbering scheme
Fleet Information Management Unit (Royal Navy – GBR)
Finland
Federal Information Processing Standard (USA)
Foreign Key (a key inherited by a child entity from a parent entity)
Firepower Kill (criterion)
Forward line of enemy troops
Flight Information Publications
Forward Line Own Troops
Field Manual
NATO Message Text Formatting System
France or French
Fire Support
Fire Support Coordination Line
File Transfer Protocol
Field Use Designator
Field Use Designator Number
Field Use Identifier
United Kingdom of Great Britain and Northern Ireland
Gefechtsfeldführungssystem
Generic Event List
Global Early Warning
Generic Hub Data Model - ATCCIS
Global Information Environment
Geographic Information System
General Officers International Digitization Group
Gateway Point of Contact
Greece
Gateway
High Capacity Data Radio
A-4
V3.1.4
HDRS
HEROS
HF
HICON
HoD
HQ
HQ AFCENT
HQ AFSOUTH
HQ ARRC
HQ EUROCORPS
HRF/LRF
HTML
HTTP
HUMINT
HUN
HW
I.E.
I/O
IA5
IAD
IAW
ICAM
ICAO
ICE
Id
ID
IDEF
IDEF1X
IDEF1X
IDL
IED
IEEE
IEM
IER
IEW
IFF
IFR
IMC
IMINT
IMO
IMS
IN
Inf, INF
INFOSEC
INTSUM
IOB
IOF
IOT&E
IP
IPM
IPMS
IR
IRD
IRDS
IRRB
ISDN
Headers
Heeresführungsinformationssystem für rechnergestützte Operationsführung in Stäben
(GER)
High Frequency
Higher Controller
Head of Delegation
Headquarters
Headquarters Allied Forces Central Europe
Headquarters Allied Forces Southern Europe
Headquarters ACE Rapid Reaction Corps
Headquarters European Corps
High Readiness Forces / Low Readiness Forces
Hyper Text Markup Language
Hyper Text Transfer Protocol
Human Intelligence
Hungary
Hardware
Id Est - Such As
Input / Output
International Alphabet Number 5 (also known as ASCII)
Interface Adapter Device
In Accordance With
Integrated Computer-Aided Manufacturing
International Civil Aviation Organisation
Information Content Element
Identification; Identifier
Infantry division (e.g., 25ID)
Integrated Computer-Aided Manufacturing (CAM) Definition (Language)
IDEF for Data Modelling
ICAM Definition Language 1. Extension
Interface Definition Language
Improvised Explosive Device
Institute of Electrical and Electronic Engineers
Information Exchange Mechanism
Information Exchange Requirement
Intelligence Electronic Warfare
Identification Friend/Foe
Instrument Flight Rules
Information Management Cell
Imagery Intelligence
International Maritime Organisation
International Military Staff
Inactive (status)
Infantry
Information Security
Intelligence Summary
Inter-Operability Branch
Input/Output Facility
Initial Operational Test & Evaluation
Internet Protocol, ISO/OSI level 3
Interpersonal Messaging
Interpersonal Messaging System
Incident Report
Information Resource Dictionary
Information Resource Dictionary Standard
IR Review Board
Integrated Services Digital Network
A-5
V3.1.4
ISO
ISO/OSI/IEC
ISSC
ITA
ITR
ITU
JAG-T
JC3IEDM
JC3RCSC
JCS
JCS Pub
JSB
JSP
JTF
JWID
KBS
K-Kill
LAN
LARS
LASH
LC
LC2IEDM
LC2IS
LCIS
LFC2IS
LFCS
LFRIL
LG.1
LLAPI
LLC
LO
LOCON
LOWG
LTU
M01
M02
M03
MA
MAS
MBN
MBP
MBPT
MBT
MBxTP
MCCIS
MCDM
MCI
MCLiP
MCMP
MCS
MDP
MDWP
MEBxR
MEDP
International Organisation of Standardisation
International Standardisation Organisation/ Open Systems Interconnection/ International
Electrotechnical Commission
Information System Sub-Committee
Italy or Italian
Initial Technical Review (CP at AFS or DBA)
International Telecommunication Union
JC3IEDM Annex Generation Tool
Joint C3 (Consultation, Command, and Control) Information Exchange Data Model
(formerly named C2IEDM)
Joint C3 Requirements and Concepts Sub-Committee
Joint Chiefs of Staff
Joint Chiefs of Staff Publication (USA)
Joint Service Board
Joint Services Publication (GBR)
Joint Task Force
Joint Warrior Interoperability Demonstration (renamed to CWID in 2005)
Kilobits per second
Permanent Kill (“unserviceable” criterion)
Local Area Network
Multiple rocket launcher
Lighter Aboard Ship
Line of contact
Land Command and Control Information Exchange Data Model (formerly named Generic
Hub 4)
Land Command and Control Information System
Land Common Interoperability System
Land Forces Command and Control System
Land Forces Command System
Land Forces Reportable Item List (NATO)
Land Group 1 (of the NATO Army Armaments Group - NAAG)
Low Level Air Picture Interface
Logical Link Control
Liaison Officer
Lower Controller
Land Operational Working Group
Lithuania
DEM incremental update management data exchange PDU
DEM bulk management data exchange PDU
DEM catalogue bulk management data exchange PDU
1) Management and 2) Mandatory
NATO Military Agency for Standardisation
MIP Briefing Notes
MIP Block Plan
MIP Boiler Plate Text
Main Battle Tank
MIP Block x Test Plan (x is for the Block it’s written for)
Maritime Command and Control Information System
MIP Common Data Model
MIP Common Interface
MIP Communications and Liaison Plan
MIP Configuration Management Plan
Maneuver Control System (USA)
MIP Development Plan
Multi Disciplinary Working Party (MIP)
MIP End Of Block x Report (x is for the Block it’s written for)
MIP Exercise and Demonstration Plan
A-6
V3.1.4
MEI
MEL
MEM
MET
MFI
MG
MGA
MGS
MHS
MI
MIC
MIE
MIF
MIL-STD-2525B
MIME
MIP
MIP Baseline List
MIP CONOPS
MIP Doc Reg
MIP Glos
MIP IEDM
MIP POC
MIPS
MIPSYSMAN
MIR
MIRD
M-Kill
MLC
MLRS
MMHSWG
MNC
MND
MNMB
MOA
MOD
MOH
MOL
MOLT
MOOTW
MOP
MOPP
MOU
MPA
MPMP
MPR
MPRL
MPRRB
MPRT
MRMP
MRS
MS
MSB
Msg
MSG
MSISP
MSLT
Message Exchange Interface
Main Events List
Message Exchange Mechanism
Meteorology, Meteorological
Mandatory For Implementation
Multinational agreement
CP MG agreed
CP in MG Staffing process MTFWG
Message Handling System
Military intelligence
Multinational Interoperability Council
Military Information Environment
MIP Integrated Framework
US Mil Standard, Common Warfighting Symbology, version B dd 30 Jan 1999
Multipurpose Internet Mail Extensions
Multilateral Interoperability Programme
MIP Baseline Documents Status List
MIP Concept of Operations
MIP Document Register
MIP Glossary
MIP Information Exchange Data Model
MIP Point of Contact List
MIP Integrated Programme Schedule
MIP System Management (message)
MIP Implementation Rules
MIP Information Resource Dictionary
Mobility Kill (criterion)
Military Load Classification
Multiple Launch Rocket System
Military Message Handling Services Working Group
Multinational Corps
Multi-National Division
MIP – NATO Management Board
Memorandum of Agreement
Ministry of Defence
MIP Operational Handbook
MIP Official Library
MIP Operational Level Test Specification
Military Operations Other Than War
MIP Operating Procedures
Mission Oriented Protective Posture
Memorandum of Understanding
Military Patrol Aircraft
MIP Programme Management Plan
MIP Problem Report
MIP Program Risk List
MPR Review Board
MIP Problem Report Tool (aka MIPzilla, Bugzilla)
MIP Risk Management Plan
MIP Reference System
Message Store / MIP Solution
MIP Standard Briefing
Message
MIP Steering Group
MIP System Interconnections Security Policy
MIP System Level Test Specification
A-7
V3.1.4
MTA
MTBF
MTC
MTEMP
MTF
MTFWG
MTFWG CM Plan
MTIDP
MTIR
MTM
MTP
MTS
MTTP
MTTR
MTWP
MVS
MWAOP
MWTU
NAAG
NAD
Narr
NATO
NBAC
NBC
NC3A
NC3B
NC3O
ND
NDAG
NEGACK
NEO
NFFI
NGA
NGF
NHQC3S
NHQC3S/IOB
NI
NII
NIETWG
NIMP
NIPD
NLD
NOR
NOSWG
NPIS
NRT
NTDI
O/R
OBJ
OC
OCL
OED
OIG
OLT
OMG
OMT
Message Transfer Agent
Mean Time Between Failure
MIP Test Controller
MIP Test and Evaluation Master Plan
Message Text Format / Medical Treatment Facility
Message Text Format Working Group
Message Text Format Working Group Configuration Management Plan
MIP Technical Interface Design Plan
MIP Tactical C2IS Interoperability Requirement
Message Transfer Mechanism
MIP Test Plan
Message Transfer System
MIP Technical Test Plan
Mean Time To Repair
MIP Testing Working Party
MIP Vision and Scope
MIP WEB Site Administration and Operating Procedures
Mine Warfare Training Unit (Royal Navy - GBR)
NATO Army Armaments Group
Network Architecture Diagram
Narrative
North Atlantic Treaty Organisation
Narrow body civilian aircraft
Nuclear, Biological and Chemical
NATO Consultation, Command, and Control Agency
NATO Consultation, Command, and Control Board
NATO Consultation, Command, and Control Organization
National Division
NATO Data Administration Group (now DMSWG)
Negative Acknowledgement
Non-combatant Evacuation Operations
NATO Friendly Force Identifier
National Geospatial and Intelligence Agency
Naval gunfire
NATO Headquarters Consultation, Command, and Control Staff
NATO Headquarters Consultation, Command, and Control Staff / Interoperability Branch
Not Implemented
National Implementation Issue
NATO Interoperability Testing Working Group
NATO Interoperability Management Plan
NATO Interoperability Planning Document
The Netherlands
Norway
NATO Opens Systems Working Group
NATO Procedural Interoperability Standards
Nearly Real Time
NATO Target Data Inventory
Originator/Recipient
Objective
Operation Centre
Object Constraint Language
Oxford English Dictionary
Operational Information Groups
Operational Level Test
Object Management Group
Object Modelling Technique
A-8
V3.1.4
OO
OOB
OOTW
Op Eval
OPCOM
OPCON
OPFOR
OPLAN
OPORDER
ORB
ORBAT
Org
OSI
OT
OWG
P1
PDAU
PDU
PIR
PL
PM
PMG
POL
POL
POSACK
POW
PPP
PRMD
PRT
PSO
PUB
QACISG
QACISIG
QIOP
QIP
QMHS
QSTAG
QTIDP
RCPT
RDBMS
RDC
RDT
RDU
Recce
REF
REPMAN
RET
RFC
RFC 822
RFD
RFW
Rgt, REGT
Rh
RHA
RHQ
RIC
Object Oriented
Order of Battle
Operations Other Than War
Operational Evaluation
Operational Command
Operational Control
Opposing Forces
Operations Plan
Operations Order
Object Request Broker
Order of Battle
Organization
Open Systems Interconnection
Object Technology
Operational Working Group
A special X.400 protocol
Physical Delivery Access Unit
Protocol Data Unit
Prioritized Information Requirements
Phase Line
Project Manager
Program Management Group (MIP)
Petroleum, Oil, and Lubricant
Poland
Positive Acknowledgement
Prisoner of War
Point-to-Point-Protocol
Private Management Domain
Portugal
Peace Support Operations
Publication
Quadrilateral Army CIS Interoperability Group
Quadrilateral Army Communications and Information systems Interoperability Group
Quadrilateral Interface Operational Procedures (QIP Program)
Quadrilateral Interoperability Programme
QIP Message Handling System
Quadripartite Standardization Agreement
QIP Technical Interface Design Plan
Receipt to
Relational Data Base Management System
Replication Domain Composite
Replication Domain Type
Replication Domain Union
Reconnaissance
Reference
Replication Manager
Return
Request for Comments
Part of SMTP Message Text Format
Request For Deviation
Request For Waiver
Regiment
Rhesus factor in blood typing
Royal Horse Artillery (GBR)
Regional Headquarters
Reportable Item Code
A-9
V3.1.4
RIP
RITA
RLC
RMKS
ROE
ROU
RPC
RTR
RTSE
S&F
SA
SACEUR
SAN
SAP
SATCOM
SC/n
SCRA(T)
SEAWG
SEI
SHAPE
SHAPE DAO
SHORAD
SIACCON
SICF
SIGINT
SIMACET
SINCE
SIR
SLIERP
SLT
SME
SMTP
SNR (A)
SNR (C3)
SOHB
SOI
SOP
SOTRIN
SPN
SQL
Sqn
SRS
SSP
STANAG
Std
STGP
SUT
SVN
SW
SWE
SYS ACK
SYS MAN
SYS NAK
TAA
TACCIS
TASK ORG
Routing Information Protocol
Réseau Intégré de Transmissions Automatiques (FRA)
Royal Logistics Corp
Remarks
Rules of Engagement
Romania
Remote Procedure Call
The Royal Tank Regiment (GBR)
Reliable Transfer Service Element
Store and Forward
Situational Awareness
Supreme Allied Commander Europe
Secondary Access Node
Service Access Point
Satellite Communications
Subcommittee/number
Single Channel Radio Access (Terminal)
Systems Engineering & Architecture Working Group
Software Engineering Institute from Carnegie Mellon University
Supreme Headquarters Allied Powers Europe
Supreme Headquarters Allied Powers Europe, Data Administration Office
Short Range Air Defence
Sistema Automatizzato di Comando e Controllo (ITA)
Système d’Information pour le Commandement des Forces (FRA)
Signals Intelligence
SIstema de Mando y Control para el Ejército de Tierra (ESP)
Simulation and C2 Information System Connectivity Experiment
Système d’Information Régimentaire (FRA)
Senior Land Information Exchange Requirements Panel
System Level Test
Subject Matter Expert
Simple Mail Transfer Protocol
Senior National Representatives (Army)
Senior National Representatives (C3)
Staff Officers Handbook (GBR)
Statement of Intent
Standard Operating Procedures
Sottosistema di Trasmissioni Integrate
Self-Protecting Node
Structured Query Language (ISO)
Squadron
[Software or System] Requirements Specifications
System Security Policy
NATO STANdardisation AGreement
Standard
Shared Tactical Ground Picture
System Under Test
Slovenia
Software
Sweden
System Acknowledgement
(MIP) System Management (message)
System Negative Acknowledgement
Tactical Assembly Areas
Tactical Area Command and Control Information System
Task Organisation
A-10
V3.1.4
TBD
TCP
TCP/IP
TEL
TEWG
TFMAN
TFTP
Tgt
TIDP
TMHS
TOA
TOC
TOE
TOO
TOP WG
ToR
TP2K
TTP
TTSpec
TUR
TWG
UA
UDP
UK
UN
USA
USMTF
UTC
UTM
UTO
UTP
UXO
VFR
VHF
WAN
WBAC
WG(s)
WGS-84
WHO
WP
WP(s)
WTD 81
WWW
X01
X02
X03
X.400
X25
X400
XDR
XML
Y2K
To be Done / To be Decided / To be Determined
Transmission Control Protocol
Protocol used within TCP/IP (Transfer Control Protocol/Internet Protocol) wide area
networks
Transporter erector launcher
Test and Evaluation Working Group
Transfer Facility Manager
Trivial File Transfer Protocol
Target
Technical Interface Design Plan
Tactical Message Handling System
Transfer Of Authority
Tactical Operations Centre
Table of Equipment
Table of Organisation
Land Forces Tactical Doctrine and Operational Procedures Working Group
Terms of Reference
TACOM Post-2000
Tactics, Techniques and Procedures
Technical Test Specification
Turkey
Technical Working Group
User Agent
User Datagram Protocol
United Kingdom
United Nations
United States of America
United States Message Text Format
Coordinated Universal Time
Universal Transverse Mercator
Unit Task Organisation
Unshielded Twisted Pair
Unexploded Ordnance
Visual Flight Rules
Very High Frequency
Wide Area Network
Wide Body Civilian Aircraft
Working Group(s)
World Geodetic System 1984 (reference standard)
World Health Organisation
Working Paper
Working party(s)
Wehrtechnische Dienststelle 81
World Wide Web
DEM Incremental Update Data Exchange PDU
DEM Full Bulk Data Exchange PDU
DEM Aborted Update PDU
CCITT/ITU Recommendation for Message Handling Systems
Protocol used within ISO standard X25 based networks
Protocol used within ISO standard X400 based networks
External Data Representation
Extensible Markup Language
Year 2000
A-11
V3.1.4
Annex B: JC3IEDM Metamodel—
ENTITY DEFINITIONS AND ATTRIBUTES
B-1
V3.1.4
(This page intentionally left blank)
B-2
V3.1.4
Annex B. JC3IEDM Metamodel—
ENTITY DEFINITIONS AND ATTRIBUTES
Entity Name
ALTERNATE-KEY
ALTERNATE-KEYATTRIBUTE
ATTRIBUTE
Entity Definition
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.
The association of a specific ALTERNATE-KEY
with a specific ATTRIBUTE that identifies the
participation of the ATTRIBUTE as part of
ALTERNATE-KEY.
A record that specifies the metadata
characteristics of an attribute for an entity that is
described in a specific ENTITY.
BASE-ATTRIBUTE
An ATTRIBUTE that is native to the entity
referenced by the specific ENTITY.
BUSINESS-RULE
A grouping of operationally related business
restrictions.
An identification of a specific entity that is the
focus of a particular BUSINESS-RULE.
BUSINESS-RULE-ENTITYATTRIBUTE-COMPOSITE
An identification of a specific attribute that is the
focus of a particular BUSINESS-RULE-ENTITY.
BUSINESS-RULE-ENTITYATTRIBUTE-COMPOSITEDOMAIN-VALUE
An identification of the specific domain value that
is part of a particular BUSINESS-RULE-ENTITYATTRIBUTE-COMPOSITE.
CARDINALITYRELATIONSHIP
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.
B-3
Attribute Name
entity-id (PK) (FK)
alternate-key-index (PK)
alternate-key-number-quantity
alternate-key-uniqueness-indicator-code
entity-id (PK) (FK)
attribute-index (PK) (FK)
alternate-key-index (PK) (FK)
entity-id (PK) (FK)
attribute-index (PK)
attribute-name-text
attribute-column-name-text
attribute-sequence-number-ordinal
entity-id (PK) (FK)
domain-id (FK)
business-rule-id (PK)
business-rule-section-cross-reference-text
business-rule-table-cross-reference-text
business-rule-id (PK) (FK)
business-rule-entity-index (PK)
business-rule-entity-index (PK)(FK)
(PK)
business-rule-entity-attribute-composite-nullindicator-code
entity-id (FK)
business-rule-entity-index (PK)(FK)
(PK)(FK)
business-rule-entity-attribute-compositedomain-value-index (PK)
domain-id (FK)
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-indicatorcode
cardinality-relationship-parent-cardinality-code
cardinality-relationship-child-cardinality-code
cardinality-relationship-child-minimumcardinality-count
cardinality-relationship-child-maximumcardinality-count
V3.1.4
CATEGORY-RELATIONSHIP Representation of the information required to
define a subtype for a specific ENTITY.
CREATOR-UPDATEIDENTIFICATION
DOMAIN
DOMAIN-VALUE
ENTITY
NON-KEY-ATTRIBUTE
RELATIONSHIP
SUBTYPE-RELATIONSHIP
super-entity-id (PK) (FK)
category-relationship-index (PK)
category-relationship-definition-text
discriminator-attribute-index (FK)
category-relationship-completeness-indicatorcode
A relationship of an ENTITY and an ATTRIBUTE entity-id (PK) (FK)
to identify the physical attributes for JC3IEDM
creator-attribute-index (FK)
Management.
update-attribute-index (FK)
A record that specifies the collective metadata
domain-id (PK)
characteristics for a set of values to be
domain-name-text
associated with a specific data element.
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
A record that specifies the metadata
entity-id (PK)
characteristics of an entity from a data model for entity-name-text
which metadata is being recorded.
entity-table-name-text
entity-depth-count
An ATTRIBUTE that has been migrated under a host-entity-id (PK) (FK)
RELATIONSHIP from the primary key of the
"Parent" ENTITY of that RELATIONSHIP.
base-entity-id (FK)
base-attribute-index (FK)
An ATTRIBUTE used to provide a descriptive
entity-id (PK) (FK)
data element of instances of the ENTITY to
which the ATTRIBUTE belongs and that is not a non-key-attribute-optionality-indicator-code
member of the primary key of that ENTITY.
An ATTRIBUTE used to provide the unique
entity-id (PK) (FK)
identifier(s) of an instance of the ENTITY to
which the attributes belong.
The association of one instance of ENTITY (the parent-entity-id (PK) (FK)
"Parent” ENTITY) with another (the "Child"
child-entity-id (PK) (FK)
ENTITY) that describes the degree and nature of relationship-index (PK)
the association.
relationship-type-code
A RELATIONSHIP that identifies a child ENTITY super-entity-id (PK) (FK)
whose primary key is identical to the primary key sub-entity-id (PK) (FK)
of the parent ENTITY and which inherits all of
relationship-index (PK) (FK)
the properties of the parent ENTITY.
category-relationship-index (FK)
domain-id (FK)
B-4
V3.1.4
Annex C: JC3IEDM Metamodel—
ATTRIBUTE DEFINITIONS
C-1
V3.1.4
C-2
V3.1.4
Annex C. JC3IEDM Metamodel—
ATTRIBUTE DEFINITIONS8
Attribute Name
alternate-key-index
Opt
Entity Usage
MA ALTERNATE-KEY
alternate-key-numberquantity
alternate-key-uniquenessindicator-code
MA ALTERNATE-KEY
MA ALTERNATE-KEY
MA ATTRIBUTE
attribute-foreign-keyindicator-code
MA ATTRIBUTE
attribute-index
MA ALTERNATE-KEYATTRIBUTE
ATTRIBUTE
BASE-ATTRIBUTE
NON-KEY-ATTRIBUTE
MA ATTRIBUTE
attribute-name-text
attribute-primary-keyindicator-code
MA ATTRIBUTE
attribute-sequence-numberordinal
attribute-standardisationlevel-code
base-attribute-datadecimals-count
OP ATTRIBUTE
MA ATTRIBUTE
OP BASE-ATTRIBUTE
base-attribute-data-lengthcount
base-attribute-data-typecode
MA BASE-ATTRIBUTE
MA BASE-ATTRIBUTE
base-attribute-index
MA FOREIGN-KEY-ATTRIBUTE
base-entity-id
MA BASE-ATTRIBUTE
business-rule-category-code MA BUSINESS-RULE
OP BUSINESS-RULE
business-rule-entityattribute-composite-domainvalue-index
MA BUSINESS-RULE-ENTITYATTRIBUTE-COMPOSITEDOMAIN-VALUE
business-rule-entityattribute-composite-index
MA BUSINESS-RULE-ENTITYATTRIBUTE-COMPOSITE
8
Attribute Definition
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 ALTERNATEKEYs for that ENTITY.
The numeric value that represents the alternate key or
inversion key in the ENTITY.
The specific value that denotes whether the alternate key
or inversion key is unique.
The character string assigned to represent the
ATTRIBUTE as a specific physical column within a table.
The specific value that denotes whether the ATTRIBUTE
plays the role of a foreign key in the ENTITY and thereby
owned by another ENTITY.
represent a specific ATTRIBUTE for a specific ENTITY
and to distinguish it from all other ATTRIBUTEs for that
ENTITY.
The character string assigned to represent a specific
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.
The integer value that represents the specific physical
position of the attribute inside the entity.
The specific value that represents the level of common
agreement for the ATTRIBUTE.
The numeric value representing the number of positions
to the right of the decimal point for attributes that are
expressed as real numbers.
The numeric value representing the maximum number of
characters permitted for a value of the attribute.
The specific value that represents the technical form
(datatype or syntax) for the attribute.
The character string assigned to represent the definition
of a specific BASE-ATTRIBUTE.
The attribute-index that identifies the base attribute for
the foreign key (a role name for attribute-index).
The entity-id that identifies the base entity for the foreign
key (a role name for entity-id).
The specific value that represents the class of
BUSINESS-RULE as text or a formal rule.
The character string assigned to specify the BUSINESSRULE. The purpose of this attribute is to enable crossreferencing to an external document.
represent a specific BUSINESS-RULE-ENTITYATTRIBUTE-COMPOSITE-DOMAIN-VALUE for a
specific BUSINESS-RULE-ENTITY-ATTRIBUTECOMPOSITE and to distinguish it from all other
BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITEDOMAIN-VALUEs for that BUSINESS-RULE-ENTITYATTRIBUTE-COMPOSITE.
represent a specific BUSINESS-RULE-ENTITYATTRIBUTE-COMPOSITE for a specific BUSINESSRULE-ENTITY and to distinguish it from all other
BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITEs
for that BUSINESS-RULE-ENTITY.
The second column indicates the optionality of the attribute: MA for mandatory (non-null) and OP for
optional (null allowed).
C-3
V3.1.4
Attribute Name
business-rule-entityattribute-composite-nullindicator-code
Opt
Entity Usage
MA BUSINESS-RULE-ENTITYATTRIBUTE-COMPOSITE
MA BUSINESS-RULE-ENTITY
MA BUSINESS-RULE
MA BUSINESS-RULE
business-rule-id
The specific value that indicates whether the attribute
cited in BUSINESS-RULE-ENTITY-ATTRIBUTECOMPOSITE is permitted to be unspecified within the
specific BUSINESS-RULE.
represent a specific BUSINESS-RULE-ENTITY for a
specific BUSINESS-RULE and to distinguish it from all
other BUSINESS-RULE-ENTITYs for that BUSINESSRULE.
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.
business-rule-section-cross- MA BUSINESS-RULE
The character string assigned to identify the section of
reference-text
the document describing the BUSINESS-RULE. The
purpose of this attribute is to enable cross-referencing to
an external document.
business-rule-table-crossOP BUSINESS-RULE
The character string assigned to identify the table in the
reference-text
document that corresponds to the BUSINESS-RULE.
The purpose of this attribute is to enable crossreferencing to an external document.
cardinality-relationship-child- MA CARDINALITYThe specific value that represents the range in the
cardinality-code
RELATIONSHIP
number of occurrences associated with the child entity in
the CARDINALITY-RELATIONSHIP represented.
cardinality-relationship-child- OP CARDINALITYThe integer value that represents the number of the
maximum-cardinality-count
RELATIONSHIP
maximum exact cardinality associated with the child
entity in the CARDINALITY-RELATIONSHIP
represented.
cardinality-relationship-child- OP CARDINALITYThe integer value that represents the number of the
minimum-cardinality-count
RELATIONSHIP
minimum exact cardinality associated with the child entity
in the CARDINALITY-RELATIONSHIP represented.
cardinality-relationshipMA CARDINALITYThe specific value that represents the class of
identifying-indicator-code
RELATIONSHIP
CARDINALITY-RELATIONSHIP represented.
cardinality-relationshipOP CARDINALITYThe character string assigned to represent the action
inverse-verb-name-text
RELATIONSHIP
phrase describing the relationship from the child and to
the parent instances of ENTITY for a CARDINALITYRELATIONSHIP.
cardinality-relationshipMA CARDINALITYThe specific value that represents the optionality of the
parent-cardinality-code
RELATIONSHIP
CARDINALITY-RELATIONSHIP.
cardinality-relationship-verb- MA CARDINALITYThe character string assigned to represent the action
name-text
RELATIONSHIP
phrase describing the association from the parent to the
child instances of ENTITY for a CARDINALITYRELATIONSHIP.
category-relationshipMA CATEGORY-RELATIONSHIP The specific value that represents whether all the
completeness-indicatorpossible subtypes of the Super ENTITY explicitly occur in
code
the data model.
category-relationshipOP CATEGORY-RELATIONSHIP The character string assigned to represent the
definition-text
characterisation of a CATEGORY-RELATIONSHIP.
category-relationship-index
MA CATEGORY-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.
The entity-id that identifies the child entity in the
child-entity-id
MA CARDINALITYrelationship (a role name for entity-id).
RELATIONSHIP
RELATIONSHIP
creator-attribute-index
OP CREATOR-UPDATEThe attribute-index for a specific CREATOR-UPDATEIDENTIFICATION
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 attributeindex).
MA DOMAIN
The character string assigned to represent the category
to which the DOMAIN belongs.
domain-definition-sourceOP DOMAIN
The character string assigned to represent the source of
text
the domain definition.
MA DOMAIN
of a specific DOMAIN.
C-4
V3.1.4
Attribute Name
domain-id
domain-measurement-unitdescription-text
domain-name-text
Opt
Entity Usage
MA BASE-ATTRIBUTE
DOMAIN
DOMAIN-VALUE
OP DOMAIN
MA DOMAIN
MA DOMAIN
domain-restriction-type-code OP DOMAIN
domain-standardisationlevel-code
MA DOMAIN
domain-value-descriptiontext
domain-value-index
MA DOMAIN-VALUE
OP DOMAIN-VALUE
MA BUSINESS-RULE-ENTITYATTRIBUTE-COMPOSITEDOMAIN-VALUE
DOMAIN-VALUE
OP DOMAIN-VALUE
OP DOMAIN-VALUE
domain-valuestandardisation-level-code
MA DOMAIN-VALUE
MA DOMAIN-VALUE
MA ENTITY
MA ENTITY
entity-depth-count
MA ENTITY
entity-id
MA ALTERNATE-KEY
ATTRIBUTE
BASE-ATTRIBUTE
ENTITY
CREATOR-UPDATEIDENTIFICATION
NON-KEY-ATTRIBUTE
MA ENTITY
entity-name-text
MA ENTITY
entity-of-interest-id
MA BUSINESS-RULE-ENTITY
entity-standardisation-levelcode
MA ENTITY
MA ENTITY
MA ENTITY
foreign-key-attribute-roledefinition-text
OP FOREIGN-KEY-ATTRIBUTE
represent a specific DOMAIN and to distinguish it from all
other DOMAINs.
The character string assigned to represent the unit of
measure for DOMAINs that permit quantitative values.
The specific value that represents the data model source
of the DOMAIN.
DOMAIN.
The specific value that represents the type of constraint
imposed upon values for the DOMAIN.
agreement for the DOMAIN.
of a DOMAIN-VALUE.
description of a DOMAIN-VALUE.
represent a specific DOMAIN-VALUE for a specific
DOMAIN and to distinguish it from all other DOMAINVALUEs for that DOMAIN.
DOMAIN-VALUE.
The character string assigned to represent the source of
the domain value and the definition of that domain value.
agreement of the DOMAIN-VALUE.
The specific value that represents the class of a
DOMAIN-VALUE.
of what the entity is.
The specific value that represents whether the ENTITY is
independent for its meaning and instances from all other
instance of 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.
represent a specific ENTITY and to distinguish it from all
other ENTITYs.
The specific value that represents the data model source
of the ENTITY being represented.
ENTITY.
The entity-id of the entity that is of interest in a specific
BUSINESS-RULE-ENTITY (a role name for entity-id).
agreement for the ENTITY.
The specific value that represents whether the ENTITY
as standard (non-loggable) or loggable.
The character string assigned to represent the physical
table or other object of a physical schema that represents
data specified for a specific ENTITY.
The character string assigned to represent the way in
which a FOREIGN-KEY-ATTRIBUTE relates to the base
ENTITY.
C-5
V3.1.4
Attribute Name
foreign-key-attributerolename-indicator-code
Opt
Entity Usage
host-entity-id
migrating-relationship-index
non-key-attribute-optionality- MA NON-KEY-ATTRIBUTE
indicator-code
parent-domain-id
OP DOMAIN
parent-entity-id
relationship-index
source-attribute-index
source-entity-id
sub-entity-id
super-entity-id
unifying-attribute-index
update-attribute-index
MA CARDINALITYRELATIONSHIP
RELATIONSHIP
MA CARDINALITYRELATIONSHIP
RELATIONSHIP
The specific value that represents whether a surrogate
name is used for a migrating FOREIGN-KEYATTRIBUTE in the base ENTITY.
The entity-id that identifies the entity in which the foreign
key resides (a role name for entity-id).
The relationship-index that identifies the instance of the
migration of the foreign key (a role name for relationshipindex).
The specific value that represents whether non-null
domain value is required for a NON-KEY-ATTRIBUTE.
The domain-id of a specific parent DOMAIN (a role name
for domain-id).
The entity-id that identifies the parent entity in the
relationship (a role name for entity-id).
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.
MA RELATIONSHIP
The specific value that represents the class of
RELATIONSHIP being specified.
MA FOREIGN-KEY-ATTRIBUTE The attribute-index that identifies the source attribute for
the foreign key (a role name for attribute-index).
MA FOREIGN-KEY-ATTRIBUTE The entity-id that identifies the source entity for the
foreign key (a role name for entity-id).
MA SUBTYPE-RELATIONSHIP
The entity-id that identifies the sub-type entity for subtyping (a role name for entity-id).
MA CATEGORY-RELATIONSHIP The entity-id that identifies the super-type entity for subSUBTYPE-RELATIONSHIP
typing (a role name for entity-id).
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).
OP CREATOR-UPDATEThe attribute-index for a specific CREATOR-UPDATEIDENTIFICATION
IDENTIFICATION that identifies the update-seqnr of a
specific record (a role name for attribute-index).
C-6
V3.1.4
Annex D: JC3IEDM Metamodel—
ENTITY RELATIONSHIPS
D-1
V3.1.4
D-2
V3.1.4
Annex D. JC3IEDM Metamodel—ENTITY RELATIONSHIPS
Parent Entity
Verb Phrase
Child Entity
Relationship
Type
ALTERNATE-KEY
consists-of
Identifying
ATTRIBUTE
appears-in
Identifying
ATTRIBUTE
Is a
BASE-ATTRIBUTE
Subtype
ATTRIBUTE
provides-the-attributereference
Nonidentifying
ATTRIBUTE
is-discriminator-for
CATEGORY-RELATIONSHIP
Nonidentifying
ATTRIBUTE
ATTRIBUTE
identifies-creator-id-column CREATOR-UPDATEIDENTIFICATION
identifies-update-seqnrCREATOR-UPDATEcolumn
IDENTIFICATION
Is a
Nonidentifying
Nonidentifying
Subtype
ATTRIBUTE
Is a
NON-KEY-ATTRIBUTE
Subtype
ATTRIBUTE
Is a
Subtype
BASE-ATTRIBUTE
is-originator-for
Nonidentifying
BUSINESS-RULE
is-composed-of
Identifying
BUSINESS-RULEENTITY
is-composed-of
Identifying
BUSINESS-RULEENTITYATTRIBUTECOMPOSITE
is-composed-of
Identifying
CATEGORYRELATIONSHIP
holds
Nonidentifying
ATTRIBUTE
D-3
Logical Foreign Keys
entity-id
alternate-key-index
entity-id
attribute-index
entity-id
attribute-index
entity-id
attribute-index
super-entity-id
discriminator-attribute-index
host-entity-id
attribute-index
entity-id
attribute-index
entity-id
attribute-index
base-entity-id
business-rule-id
business-rule-id
business-rule-id
business-rule-entity-attribute-compositeindex
super-entity-id
Cardinality
Nulls
One-to-One-or-More
(P)
One-to-Zero-One-orMore
Is a
One-to-Zero-One-OrMore
No Nulls
No Nulls
Zero-or-One-to-ZeroOne-or-More
Is a
Is a
Is a
No Nulls
No Nulls
No Nulls
One-to-One-or-More
(P)
No Nulls
No Nulls
V3.1.4
Parent Entity
DOMAIN
Verb Phrase
Child Entity
BASE-ATTRIBUTE
Relationship
Type
Nonidentifying
Nonidentifying
Identifying
DOMAIN
describes-allowed-valuesfor
is-basis-for
DOMAIN
DOMAIN
contains
DOMAIN-VALUE
DOMAIN-VALUE
discriminates
Nonidentifying
DOMAIN-VALUE
Is-part-of
Nonidentifying
ENTITY
is-also-identified-by
ALTERNATE-KEY
domain-id
domain-value-index
domain-id
domain-value-index
Identifying
entity-id
ENTITY
is-characterised-by
ATTRIBUTE
Identifying
entity-id
ENTITY
has
ENTITY
is-subtyped-via
Nonidentifying
Identifying
super-entity-id
ENTITY
Identifying
entity-id
ENTITY
has-creator-id-and-update- CREATOR-UPDATEseqnr-columns
IDENTIFICATION
is-child-of
RELATIONSHIP
Identifying
child-entity-id
ENTITY
is-parent-of
RELATIONSHIP
Identifying
parent-entity-id
FOREIGN-KEYATTRIBUTE
unifies
Nonidentifying
PRIMARY-KEYATTRIBUTE
is-source-for
Nonidentifying
RELATIONSHIP
Is a
Subtype
RELATIONSHIP
migrates-fromparent(source)-tochild(host)-entity
Nonidentifying
host-entity-id
source-entity-id
parent-entity-id
child-entity-id
relationship-index
source-entity-id
host-entity-id
D-4
domain-id
parent-domain-id
domain-id
Cardinality
One-to-One-or-More
(P)
One-to-One-or-More
(P)
One-to-Zero-or-One
(Z)
Nulls
No Nulls
Nulls
Allowed
Nulls
Allowed
No Nulls
No Nulls
Nulls
Allowed
No Nulls
Is a
One-to-One-or-More
(P)
No Nulls
V3.1.4
Parent Entity
RELATIONSHIP
Verb Phrase
Is a
Child Entity
Relationship
Type
Subtype
D-5
super-entity-id
sub-entity-id
relationship-index
Cardinality
Is a
Nulls
V3.1.4
D-6
V3.1.4
Annex E: JC3IEDM Metamodel—
SPECIFICATIONS FOR ENUMERATED DOMAINS
E-1
V3.1.4
E-2
V3.1.4
Annex E. JC3IEDM Metamodel—
SPECIFICATIONS OF ENUMERATED DOMAINS
Domain Name
Definition
Definition Source
Value
Always unique
Mostly unique
ALTERNATE-KEY
The specific value that denotes whether the alternate key or inversion key is unique.
MIP
DOMAIN VALUES
Definition
Source
The alternate key is always unique.
MIP
The alternate key is mostly unique as in an Inversion entry.
MIP
USAGE
Entity
Attribute
Physical
Value
AU
MU
Identifier
1000001
1000002
Optionality
MA
Domain Name
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.
Definition Source MIP
DOMAIN VALUES
Physical Identifier
Value
Definition
Source
Value
MIP
BA
1000001
BASEThat subset of ATTRIBUTE owned by the ENTITY to which the members
ATTRIBUTE
belong; that is, they are not foreign key attributes migrating from another
ENTITY under some relationship.
FOREIGN-KEY- An ATTRIBUTE that has been migrated under a RELATIONSHIP from the MIP
FK
1000002
ATTRIBUTE
primary key of the "Parent" ENTITY of that RELATIONSHIP.
USAGE
Entity
Attribute
Optionality
ATTRIBUTE
MA
Domain Name
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
Physical Identifier
Value
Definition
Source
Value
NON-KEYAn ATTRIBUTE used to provide a descriptive data element of instances of MIP
NK
1000001
ATTRIBUTE
the ENTITY to which the ATTRIBUTE belongs and that is not a member of
the primary key of that ENTITY.
PRIMARY-KEY- An ATTRIBUTE used to provide the unique identifier(s) of an instance of
MIP
PK
1000002
ATTRIBUTE
the ENTITY to which the attributes belong.
USAGE
Entity
Attribute
Optionality
ATTRIBUTE
MA
Domain Name
Definition
The specific value that represents the technical form (datatype or syntax) for the attribute.
Definition Source MIP-NDAG
DOMAIN VALUES
Physical Identifier
Value
Definition
Source
Value
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
The datatype of the attribute is variable character not space padded.
MIP-NDAG
VARCHAR 1000004
character
USAGE
Entity
Attribute
Optionality
BASE-ATTRIBUTE
MA
E-3
V3.1.4
Domain Name
Definition
The specific value that represents the class of BUSINESS-RULE as text or a formal rule.
DOMAIN VALUES
Value
Definition
Source
Rule
The specific value that represents a BUSINESS-RULE that is formalized in
metadata content.
Text
The specific value that represents a BUSINESS-RULE that is in textual
form.
USAGE
Entity
Attribute
BUSINESS-RULE
MIPNDAG
MIPNDAG
Physical
Value
RULE
1000001
TEXT
1000002
Identifier
Optionality
MA
Domain Name
Definition
business-rule-entity-attribute-composite-null-indicator-code
The specific value that indicates whether the attribute cited in BUSINESS-RULE-ENTITY-ATTRIBUTECOMPOSITE is permitted to be unspecified within the specific BUSINESS-RULE.
DOMAIN VALUES
Physical Identifier
Value
Definition
Source
Value
NO
1000001
No
The attribute can take any of the values listed in its associated BUSINESS- MIPNDAG
RULE-ENTITY-ATTRIBUTE-COMPOSITEs but it cannot be left
unspecified.
Yes
The attribute can take any of the values listed in its associated BUSINESS- MIPYES
1000002
RULE-ENTITY-ATTRIBUTE-COMPOSITEs and can also be left
NDAG
unspecified.
USAGE
Entity
Attribute
Optionality
business-rule-entity-attribute-composite-null-indicatorMA
code
Domain Name
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
Physical Identifier
Value
Definition
Source
Value
Exactly
The child cardinality relationship is represented by exactly one expression. MIP
EX
1000001
Positive (one or The child cardinality relationship is represented by one or more
MIP
PO
1000002
more)
expressions.
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
The child cardinality relationship is represented by zero, one or more
MIP
ZM
1000005
more
expressions.
Zero or one
The child cardinality relationship is represented by zero or one expressions. MIP
ZO
1000006
USAGE
Entity
Attribute
Optionality
CARDINALITY-RELATIONSHIP
MA
Domain Name
cardinality-relationship-identifying-indicator-code
Definition
The specific value that represents the class of CARDINALITY-RELATIONSHIP represented.
DOMAIN VALUES
Physical Identifier
Value
Definition
Source
Value
Identifying
The cardinality relationship is identifying.
MIP
ID
1000001
Nonidentifying
The cardinality relationship is nonidentifying.
MIP
NI
1000002
USAGE
Entity
Attribute
Optionality
cardinality-relationship-identifying-indicator-code
MA
E-4
V3.1.4
Domain Name
Definition
The specific value that represents the optionality of the CARDINALITY-RELATIONSHIP.
DOMAIN VALUES
Value
Definition
Source
Mandatory
Optional
The parent cardinality relationship must occur at least one time.
The parent cardinality relationship may or may not occur (zero or one).
USAGE
Entity
MIP
MIP
Physical
Value
MA
OP
Attribute
Identifier
1000001
1000002
Optionality
MA
Domain Name
Definition
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.
Definition Source
MIP
DOMAIN VALUES
Physical Identifier
Value
Definition
Source
Value
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
Entity
Attribute
Optionality
MA
Domain Name
Definition
The specific value that represents the type of constraint imposed upon values for the DOMAIN.
DOMAIN VALUES
Physical Identifier
Value
Definition
Source
Value
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
Entity
Attribute
Optionality
DOMAIN
MA
Domain Name
Definition
The specific value that represents the class of a DOMAIN-VALUE.
DOMAIN VALUES
Enumerated domains are associated with a complete set of domain values.
The maximum value excluded from the range.
MIP
MIP
Physical
Value
ELEM
MAX-EX
The maximum value included in the range.
MIP
MAX-IN
1000005
The minimum value excluded from the range.
MIP
MIN-EX
1000006
The minimum value included in the range.
MIP
MIN-IN
1000007
Value
Element
Maximum
exclusive
Maximum
inclusive
Minimum
exclusive
Minimum
inclusive
Definition
Source
Identifier
1000002
1000004
USAGE
Entity
DOMAIN-VALUE
Attribute
Domain Name
Definition
Optionality
MA
The specific value that represents whether the ENTITY is independent for its meaning and instances from all
other instance of ENTITY.
DOMAIN VALUES
Physical Identifier
Value
Definition
Source
Value
Dependent entity The entity is dependent upon one or more parents for its identity.
MIP
DE
1000001
E-5
V3.1.4
Independent
entity
Subtype entity
ENTITY
The entity is independent for its meaning and instances from all other
instance of entity.
The entity is dependent upon one parent for its identity.
USAGE
Entity
Attribute
MIP
IE
1000002
MIP
SE
1000003
Optionality
MA
Domain Name
Definition
The specific value that represents whether the ENTITY as standard (non-loggable) or loggable.
DOMAIN VALUES
Physical Identifier
Value
Definition
Source
Value
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
Attribute
Optionality
ENTITY
MA
Domain Name
Definition
The specific value that represents whether a surrogate name is used for a migrating FOREIGN-KEYATTRIBUTE in the base ENTITY.
DOMAIN VALUES
Physical
Value
Definition
Source
Value
Migrated name
The migrating attribute has not been rolenamed.
MIP
MN
Role name
The migrating attribute has been rolenamed.
MIP
RN
USAGE
Entity
Attribute
Identifier
1000001
1000002
Optionality
MA
Domain Name
model-level-code
Definition
The specific value that represents the data model source of the object.
DOMAIN VALUES
Value
Definition
Application
Dictionary
Metamodel
Application level, denoting a part of a data model.
Dictionary level, denoting a part of a data model.
MIP JC3IEDM metamodel management.
Source
MIP
MIP
MIPNDAG
Physical
Value
APPL
DICT
META
Identifier
1000001
1000003
1000004
USAGE
Entity
DOMAIN
ENTITY
Attribute
Optionality
MA
Domain Name
Definition
The specific value that represents whether non-null domain value is required for a NON-KEY-ATTRIBUTE.
DOMAIN VALUES
Physical Identifier
Value
Definition
Source
Value
Mandatory
The non-key attribute is mandatory.
MIP
MA
1000001
Optional
The non-key attribute is optional.
MIP
OP
1000002
USAGE
Entity
Attribute
Optionality
NON-KEY-ATTRIBUTE
MA
E-6
V3.1.4
Domain Name
Definition
The specific value that represents the class of RELATIONSHIP being specified.
DOMAIN VALUES
Value
Definition
Source
SUBTYPERELATIONSHIP
RELATIONSHIP
Domain Name
A one-way RELATIONSHIP that identifies a specific “parent” ENTITY with a MIP
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.
A RELATIONSHIP that identifies a subset of instances of a Parent ENTITY MIP
as an entity itself, which has a set of primary key attributes that are identical
to those of the Parent ENTITY.
USAGE
ENTITY
Attribute
standardisation-level-code
The specific value that represents the level of common agreement for the object.
MIP
DOMAIN VALUES
Value
Definition
Source
Physical
Value
CR
1000001
SR
1000002
Identifier
Optionality
MA
Definition
Definition Source
International
Local
National
MIP core
Multilateral Interoperability
Programme
MIP-NATO Data Administration
Entity
ATTRIBUTE
DOMAIN
DOMAIN-VALUE
ENTITY
International extensions to the JC3IEDM data model.
Local extensions to the JC3IEDM data model.
National extensions to the JC3IEDM data model.
All common meta data distributed in support of the Generic
Hub data model.
MIP extensions to the JC3IEDM data model.
MIP
MIP
MIP
MIP
Physical
Value
INAT
LOC
NAT
MPCO
MIP
MIP
1000005
MIP-NDAG extensions to the JC3IEDM data model.
USAGE
MIP
MPND
1000006
Attribute
E-7
Identifier
1000002
1000003
1000004
1000001
Optionality
MA
V3.1.4
E-8
V3.1.4
Annex F: JC3IEDM Metamodel—
SPECIFICATION OF OTHER DOMAINS
F-1
V3.1.4
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
cardinality-relationship-child-maximum-cardinality-count
cardinality-relationship-child-minimum-cardinality-count
entity-depth-count
Ordinal
attribute-sequence-number-ordinal
Quantity
alternate-key-number-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
host-entity-id
parent-entity-id
source-entity-id
sub-entity-id
super-entity-id
domain-id
parent-domain-id
business-rule-id
F-2
V3.1.4
Index
alternate-key-index
attribute-index
discriminator-attribute-index
sub-entity-id
super-entity-id
business-rule-entity-attribute-composite-domain-value-index
domain-value-index
relationship-index
Text
attribute-name-text
business-rule-section-reference-text
business-rule-table-reference-text
domain-name-text
domain-value-description-text
entity-name-text
F-3
V3.1.4
Annex G: JC3IEDM Metamodel—
Compendium of Business Rules
G-1
V3.1.4
G-2
V3.1.4
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 “entitydepth-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
FishID
=
Fish_Assoc
FishChildID (FK)
FishFatherIID (FK)
FishFatherIndex
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).
No.
b.
Recursive Relations:
c.
Relations: ACTION-OBJECTIVE-ITEM-MARKING has two parent entities:
and ACTION-OBJECTIVE-ITEM
Parent entities: values of “entity-depth-count”:
ORGANISATION
d.
(1)
(2)
9
“entity-depth-count” of ORG:
If (OBJ_ITEM=0) then ORG=1.
“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
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 = CANDIDATETARGET-DETAIL; CTGTDET_ITEM = CANDIDATE-TARGET-DETAIL-ITEM; ACT = ACTION;
ACT_OBJVE; ACTION-OBJECTIVE; ACT_OBJVE_ITEM; ACTION-OBJECTIVE-ITEM.
G-3
V3.1.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
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.
e.
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.
G-4
V3.1.4
Annex H: JC3IEDM Metamodel—
NAMING CONVENTIONS AND CLASS WORDS
H-1
V3.1.4
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.
H-2
V3.1.4
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, OBJECTITEM 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
H-3
V3.1.4
integral part of a “Real World” entity name. For instance, “ADATP-3ELEMENT” 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:
H-4
V3.1.4
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-datarelative-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-ofmeasure”.
l. Articles (a, an, the) are not permitted within an attribute name.
m. Conjunctions (and, or, but) are not permitted within an attribute name.
H-5
V3.1.4
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
H5.1
Relationship Names
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.
H-6
V3.1.4
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
H7
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
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.
ISO/TS 15000-5:2005
NUMBER (Decimals allowed) The "decimal separator" must be a period
(.). The use of scientific notation is not allowed for exchange.
Unbounded
Unbounded
Source of Definition
Data Type
Low Value
High Value
Definition Prefix
“The monetary numeric value that represents…”
H-7
V3.1.4
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.
Data Type
Low Value
High Value
Definition Prefix
Domain Name
MIP-NDAG
0
Unbounded
“The rotational measurement…”
binary-object (binobj)
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.)
ISO/TS 15000-5:2005
Data Type
Binary Object. Type
Low Value
Not applicable
High Value
Not applicable
Definition Prefix “A binary object assigned to…”
Definition
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.
Adapted ISO/TS15000-5:2005
Data Type
Low Value
High Value
Definition Prefix
VARCHAR
Not applicable
Not applicable
“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.
Data Type
Low Value
High Value
Definition Prefix
MIP-NDAG
-180
180
“The numeric value that represents…”
H-8
V3.1.4
Domain Name
count (cnt)
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.
Adapted from quantity in ISO/TS15000-5:2005
NUMBER (Decimals not allowed)
Data Type
Low Value
Unbounded (may be negative)
High Value
Unbounded
Definition Prefix “The integer value representing…”
Definition
Domain Name
datetime (dttm)
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.
ISO/TS15000-5:2005
CHAR
Data Type
Low Value
Not applicable
High Value
Not applicable
Definition Prefix “The character string representing a point in time that designates…”
Definition
Domain Name
dimension (dim)
A one-dimensional linear distance measure. This will be expressed in
metres
MIP-NDAG
Data Type
Low Value
High Value
Unbounded
Definition Prefix “The one-dimensional linear distance representing…”
Definition
Domain Name
duration (dur)
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.
MIP derived ISO 31-1 and ISO-8601
NUMBER
Data Type
Low Value
High Value
Unbounded
Definition Prefix “The numeric value that represents a quantity of time in milliseconds ...”
Definition
H-9
V3.1.4
Domain Name
identifier (id)
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.
Adapted ISO/TS15000-5:2005
Data Type
Low Value
Determined by key management rules
High Value
Definition Prefix “The unique value, or set of characters, assigned to represent a specific
<entity> and to distinguish it from all other <entity>s.”
Definition
Domain Name
index (ix)
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).
MIP-NDAG
Data Type
Low Value
High Value
Definition Prefix “The unique value, or set of characters, assigned to represent a specific…”
Definition
Domain Name
ordinal (ord)
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.
MIP-NDAG
Data Type
Low Value
1
High Value
Unbounded
Definition Prefix “The integer value that indicates...”
Definition
Domain Name
quantity (qty)
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.
MIP-NDAG
NUMBER
(Decimals
allowed)
The "decimal separator" must be a period
Data Type
Low Value
High Value
Unbounded
Definition Prefix The numeric value that represents...”
Definition
H-10
V3.1.4
Domain Name
rate (rate)
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.
MIP-NDAG
Data Type
Low Value
High Value
Unbounded
Definition Prefix “The numeric value that denotes…expressed as <A> per <B>.”
Definition
Domain Name
ratio (rat)
A numeric value representing the quotient of two values that have the same
Definition
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.
MIP-NDAG
Data Type
Low Value
High Value
Unbounded
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.
Data Type
Low Value
High Value
Definition Prefix
MIP-NDAG
-273.15
Unbounded
“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.
ISO/TS 15000-5:2005
VARCHAR
Data Type
Low Value
Not applicable
High Value
Not applicable
Definition Prefix “The character string assigned to represent…”
H-11
V3.1.4
Annex I: SUMMARY OF IDEF1X DATA MODELLING
METHODOLOGY AND NOTATION
I-1
V3.1.4
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].
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.2
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
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.1
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 keyattributes and non-key-attributes, i.e. those used to uniquely identify the entity and those
properties of the entity not used for that purpose.
I.2.2
ENTITY-NAME
key-area
data-area
Independent entity
Depends on no other
for its identification
ENTITY-NAME
key-area
data-area
Dependent entity
Depends on other(s)
for its identification
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.
I-2
V3.1.4
Table I-1. IDEF1X Attribute Notation
attribute (FK)
Foreign Key
Primary key of another entity contributed by a relationship
Role Name
New name for a foreign key connoting its use.
Alternate Key
Alternate unique identifier of the entity
Inversion Entry
Non-unique access identifier of the entity
Group Attribute
Attribute is a group containing the listed constituents.
Unified Foreign Key
Listed foreign keys are unified to a single foreign key attribute
role.name.attribute (FK)
attribute (AKn)
attribute (IEn)
group.(c1,c2,c3)
attribute(fk1,fk2,fk3)(FK)
I.3
Category Notation
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.1
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
Incomplete
Not all categories
shown
category discriminator
CAT-1
CAT-2
Each category entity
represents a subset of the
instances of the generic parent
and inherits the atributes and
relationships of that parent.
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.)
I-3
V3.1.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.
I-4
V3.1.4
Figure I-4. IDEF1X Cardinality Notation
I-5
V3.1.4
Annex J: REFERENCES
J-1
V3.1.4
AAP-6 (V) 1998
AAP-6 (2008)
AC/322-D(2004)0021
AC/322-D(2004)0022
AC/322(SC/4)WP/054REV1 (INV) 15 Dec 2003
AC/322(SC/4)WP/054REV1 (INV) 15 Dec 2003
ACCS 1995a
ACCS 1995b
ACE Directive 80-50
AComP-01(A) 2000
ADatP-3 1999
ADatP-3 BL 12.2
ADatP-3 BL 13.1
AFATDS IRS 1992
AIntP-3 1994
AML
AML V 2.1 NOV 05
APP-6A 1997
APP-6B 2008
APP-9 1997
ATCCIS WP ADatP-32
2000
ATCCIS WP 3-1 2002
NATO Glossary of Terms and Definitions, AAP-6(V), NATO Military
Agency for Standardisation, September 1998, NATO UNCLASSIFIED
NATO Glossary of Terms and Definitions, AAP-6(2008), NATO Military
Agency for Standardisation, April 2008, NATO UNCLASSIFIED
AC/322-D(2004)0021 INFOSEC Technical and Implementation Guidance
for Electronic Labelling of NAO Information
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) 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) NATO C3 Board Technical and
Implementation Guidance for Consistent Marking of NATO Information in
C3 Systems, 15 Dec 2003 - Def C-M(2002)49
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.
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
Operational Information Exchange System – General Instructions, Volume
1, SHAPE, 30 November 1992, NATO UNCLASSIFIED
NATO Communications Glossary, Military Agency for Standardization
(MAS), October 2000, NATO UNCLASSIFIED
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 13.1
Interface Requirements Specification for the AFATDS Version 1, ACCSA2-204-010C, US Army Communications and Electronics Command, 18
December 1992, UNCLASSIFIED
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
Additional Military Layers (AML) Product Specification Environment
Seabed and Beach (ESB) Version 2.0
Additional Military Layers (AML) Product Specification Environment
Seabed and Beach (ESB) Version 2.1
Military Symbols for Land-Based Systems, APP-6A, Military Agency for
Standardisation (MAS), 1 September 1997, NATO UNCLASSIFIED
Military Symbols for Land-Based Systems, APP-6B, Military Agency for
Standardisation (MAS), June 2008, NATO UNCLASSIFIED
A Compendium of Allied Land Forces Messages (Change 1) (CD-ROM),
1997, NATO UNCLASSIFIED
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 AdatP32
ATCCIS WP 3-1, Data Naming Procedures for the ATCCIS Data Model,
Edition 5.0, ATCCIS PWG, 18 March 2002, NATO UNCLASSIFIED
J-2
V3.1.4
ATCCIS WP 3-5 1997
ATCCIS WP 3-6 2002
ATCCIS WP 4-1 2002
ATCCIS WP 4-2 1994
ATCCIS WP 5-5 2002
ATCCIS WP 7L, 1989
ATCCIS WP 7N 1990
ATCCIS WP 10 1990
ATCCIS WP 14, 1990
ATCCIS WP 25 1994
ATP-1(C) Vol II 1983
ATP-6(B) Vol I 1992
ATP-24(B) Vol I 1981
ATP-27(B) 1993
ATP-27(C) 1999
ATP-35A 1995
ATP - 45 (B)
ATP - 45 (C)
BI-MNC Reporting
Directive
Bi-SC CDM
Bruce 1992
ATCCIS Working Paper 3-5, ATCCIS Data Management, Draft Edition 1.0,
ATCCIS PWG, SHAPE, Belgium, 19 September 1997, NATO
UNCLASSIFIED
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, ATCCIS Information Resource Dictionary (AIRD)—
Definition of Structure and Contents, Edition 5.0, ATCCIS PWG, 18 March
ATCCIS WP 4-2, AIRD Management Procedures, Edition 2.0, ATCCIS
PWG, 2 June 1995, NATO UNCLASSIFIED
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, Operational and Procedural Requirements for Data
Management and Standardization, Edition 1, ATCCIS PWG, June 1989,
NATO UNCLASSIFIED
ATCCIS WP 7N, Standardization of Data for Interoperability, Edition 1,
ATCCIS PWG, September 1990, NATO UNCLASSIFIED
ATCCIS WP 10, Information Flow Requirements and Products for Each
Key Task, Edition 2, ATCCIS PWG, September 1990, NATO
UNCLASSIFIED
ATCCIS WP 14, Information Exchange Requirements Between
Headquarters, Edition 2, ATCCIS PWG, September 1990, NATO
UNCLASSIFIED
ATCCIS WP 25, Technical Standards for Command and Control
Information Systems (CCISs) and Information Technology, ATCCIS PWG,
February 1994, NATO UNCLASSIFIED
Allied Maritime Tactical Signal and Maneuvering Book— ATP-1(C) Vol II
(STANAG 1174), October 1983, NATO RESTRICTED,
Mine Warfare Principles—ATP-6(B) (STANAG 1242), April 1992, NATO
CONFIDENTIAL
Mine Countermeasures—Tactics and Execution—ATP-24(B) Vol I
(STANAG 1132), August 1981, NATO CONFIDENTIAL,
Offensive Air Operations – ATP-27(B) (STANAG 3736), 18 November
1993, NATO UNRESTRICTED
Air Interdiction and Close Air Support – ATP-27(C) (STANAG 3736), June
Land Force Tactical Doctrine, ATP-35(A) (STANAG 2868, Edition 4.0),
Military Agency for Standardization, December 1995, NATO
UNCLASSIFIED
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
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
Operations/Situations Reports, Volume III, SHAPE, 1 August 1997, NATO
UNCLASSIFIED/PfP Releasable
Bi-Strategic Command (SC) Conceptual Data Model (CDM)
Designing Quality Databases with IDEF1X Information Models, Thomas A.
Bruce, Dorset House Publishing, 1992, UNCLASSIFIED
J-3
V3.1.4
C-M(55) 15
DAFIF
DEFSTAN 01-5 Iss 13
2002
DIGEST 1994
DIS 10032 1991
FAA
FACC 1994
FIPS PUB 183 1993
FIPS PUB 184 1993
ISO/IEC 9075 1992
ISO 3166-1
JC3IEDM-GuideToCP
JC3IEDM-Overview
JC3IEDM-Processing of
Operational Requirements
Joint Pub 1-02 2001
JSP 101
MCCIS CDM Georef
MCCIS CDM Surface
Military Standard 6040
2001
Military Standard 2525B
MIP MIRD 2005
MIP MTIR
NATO Reference Model
FAA
C-M(55) 15 FINAL, Security within the North Atlantic Treaty Organisation,
Enclosure C, Section 2, 15 Oct 97 Issue 3 NATO UNCLASSIFIED
(DAFIF) Data Dictionary, Eighth Edition, May 2005, PS\1FDE\086
MOD(GBR) Defence Standard 01-5 Issue 13, Fuel, Lubricants, and
Associated Products, January 2002.
Digital Geographic Information Exchange Standard (DIGEST), Edition 1.2,
Volumes 1-4, January 1994, NATO UNCLASSIFIED. Also see STANAG
7074
DIS 10032, Information Technology - Reference Model on Data
Management, International Organisation for Standardization (ISO) and
International Electrotechnical Commission (IEC), 13 May 1991,
UNCLASSIFIED
FAA Pilot/Controller Glossary (P/CG)
Part 4 Feature and Attribute Coding Catalog (FACC), Digital Geographic
Information Exchange Standard (DIGEST), Edition 1.2, Defense Mapping
Agency, January 1994
Integration Definition for Function Modeling (IDEF0), FIPS Pub 183,
December 1993, National Institute of Standards and Technology
Integration Definition for Information Modeling (IDEF1X), FIPS Pub 184,
December 1993, National Institute of Standards and Technology
ISO/IEC 9075:1992, Database Language SQL
ISO 3166-1: 1997, Codes for the representation of Names of Countries and
their Subdivisions – Part1: Country codes
JC3IEDM-GuideToCP, Guide To Change Proposals For MIP Data
Specifications, Edition 3.1c, 24 April 2008, MIP PMG, NATO
UNCLASSIFIED
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, Processing of
Operational Requirements, Edition 3.0, 9 December 2005 MIP PMG,
NATO UNCLASSIFIED
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
Joint Service Publication 101 (GBR), Meteorological Glossary, 6th Edition,
London HMSO
MCCIS Conceptual Data Model (CDM) Geographical Reference segment
MCCIS CDM Surface Warfare segment
USMTF: U.S. Message Text Formatting Program, Military Standard 6040,
DISA/JIEO, 31 March 2001, RESTRICTED USE
Department of Defense Interface Standard, Common Warfighting
Symbology, 30 January 1999, UNCLASSIFIED
MIP MIRD, MIP Information Resource Dictionary, Edition 3.0, MIP PMG,
9 December 2005, NATO UNCLASSIFIED
MIP MTIR, MIP Tactical C2IS Interoperability Requirement, Draft, MIP
PMG, March 2005, NATO UNCLASSIFIED
NATO Reference Model, Version 4.0, NATO Data Administration Office
(NDAO), April 2004, NATO UNCLASSIFIED
AIM Official Guide to Basic Flight Information and ATC (Air Traffic
Control) Procedures
J-4
V3.1.4
Oxford English Dictionary Oxford English Dictionary, Second Edition, 1999 Oxford University Press,
1999
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- Operational Terms and Graphics, Headquarters Department of the Army
2a 1997
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 102, 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
J-5
V3.1.4
US FM 5-33 1990
US TB 55-46-1 1991
US Army Field Manual 5-33 Terrain analysis, Headquarters Department of
the Army, 11 July 1990
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
J-6
V3.1.4
Annex K: JC3IEDM Metamodel—
IDEF1X LOGICAL DATA MODEL DIAGRAM
K-1
V3.1.4
JC3IEDM-Metamodel-3.1.4
JC3IEDM Metamodel
V3.1.4
ENTITY
entity-id (AK1.2,AK2.2)
is-parent-of
is-child-of
CREATOR-UPDATE-IDENTIFICATION
has-creator-id-and-update-s eqnr-columns
entity-name-text (AK1.1)
entity-table-name-text (AK2.1)
entity-depth-count
entity-standardis ation-level-code
P
is -discriminator-for
is-subtyped-via
Z entity-id (FK)
creator-attribute-index (FK)
update-attribute-index (FK)
identifies-creator-id-column
identifies -update-s eqnr-column
ATTRIBUTE
is-characterised-by
attribute-index
ALTERNATE-KEY-ATTRIBUTE
entity-id (FK)
appears-in
ALTERNATE-KEY
entity-id (FK) (AK1.2)
consists-of alternate-key-index
P
alternate-key-number-quantity (AK1.1)
alternate-key-uniqueness-indicator-code (AK1.3)
P
is-als o-identified-by
RELATIONSHIP
relationship-index
category-relationship-definition-text
discriminator-attribute-index (FK)
holds
BASE-ATTRIBUTE
entity-id (FK)
hos t-entity-id (FK)
migrates-from-parent(source)to-child(host)-entity
relations hip-type-code
sub-entity-id (FK)
Z relationship-index (FK)
entity-id (FK)
NON-KEY-ATTRIBUTE
entity-id (FK)
category-relations hip-index (FK)
domain-id (FK)
is-source-for
P foreign-key-attribute-role-definition-text
bas e-entity-id (FK)
bas e-attribute-index (FK)
provides-the-attribute-reference
is-originator-for
unifies
des cribes-allowed-values-for
relations hip-index (FK)
has
DOMAIN-VALUE
Z cardinality-relationship-identifying-indicator-code
cardinality-relationship-child-minimum-cardinality-count
cardinality-relationship-child-maximum-cardinality-count
domain-id (FK) (AK1.2,IE1.2)
domain-value-index
domain-value-des cription-text (AK1.1)
domain-value-name-text (IE1.1)
domain-value-type-code (AK1.3)
dis criminates
BUSINESS-RULE
business -rule-id
business -rule-category-code
business -rule-s ection-cross-reference-text
business -rule-name-text
business -rule-definition-text
business -rule-table-cross -reference-text
base-attribute-data-decimals -count
domain-id (FK)
is -composed-of
busines s-rule-id (FK)
busines s-rule-entity-index
is-composed-of
BUSINESS-RULE-ENTITY-ATTRIBUTE-COMPOSITE-DOMAIN-VALUE
busines s-rule-id (FK)
busines s-rule-entity-index (FK)
busines s-rule-entity-attribute-composite-index
busines s-rule-entity-attribute-composite-null-indicator-code
entity-id (FK)
is-composed-of
bus iness-rule-id (FK)
bus iness-rule-entity-index (FK)
bus iness-rule-entity-attribute-composite-index (FK)
bus iness-rule-entity-attribute-composite-domain-value-index
domain-id (FK)
K-2
1, 1 / 1, 1 -- 8:08:06 AM , 5/12/2009
is-part-of
contains
DOMAIN
domain-id (AK1.2)
domain-name-text (AK1.1)
domain-s tandardisation-level-code
domain-definition-s ource-text
is-basis-for
V3.1.4
Annex L: JC3IEDM Metamodel—
IDEF1X PHYSICAL DATA MODEL DIAGRAM
L-1
V3.1.4
JC3IEDM-Metamodel-3.1.4
1
JC3IEDM Metamodel
V3.1.4
ENT
ent_id: NUMBER(8) NOT NULL (AK1.2,AK2.2)
is_child_of
is_parent_of
has_creator_id_and_update_seqn
name_txt: VARCHAR(80) NOT NULL (AK1.1)
tab_name_txt: VARCHAR(30) NOT NULL (AK2.1)
is_characterised_by ATTR
def_txt: VARCHAR(999) NOT NULL
ent_id: NUMBER(8) NOT NULL (FK) (IE1.1,IE2.1,IE3.1)
depen_code: VARCHAR(2) NOT NULL
attr_ix: NUMBER(6) NOT NULL
P
depth_cnt: NUMBER(3) NOT NULL
name_txt: VARCHAR(160) NOT NULL (IE1.2)
stg_type_code: VARCHAR(4) NOT NULL
col_name_txt: VARCHAR(30) NOT NULL (IE2.2)
stdn_lvl_code: VARCHAR(6) NOT NULL
attr_seqnr_ord: NUMBER(3) NOT NULL (IE3.2)
mod_lvl_code: VARCHAR(4) NOT NULL
pk_ind_code: VARCHAR(2) NOT NULL
fk_ind_code: VARCHAR(2) NOT NULL
CREATOR_UPDATE_IDENTIFIC
Z ent_id: NUMBER(8) NOT NULL (FK)
creator_attr_ix: NUMBER(6) NULL (FK)
update_attr_ix: NUMBER(6) NULL (FK)
identifies_creator_id_column
identifies_update_seqnr_column
appears_in
AK_ATTR
ALT_KEY
ent_id: NUMBER(8) NOT NULL (FK)
ent_id: NUMBER(8) NOT NULL (FK) (AK1.2)
attr_ix: NUMBER(6) NOT NULL (FK) consists_of99
ak_ix: NUMBER(2) NOT NULL
ak_ix: NUMBER(2) NOT NULL (FK)
ak_no_qty: NUMBER(3) NOT NULL (AK1.1)
P
uniq_ind_code: VARCHAR(2) NOT NULL (AK1.3)
P
is_also_identified_by
is_subtyped_via
CAT
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
sup_ent_id: NUMBER(8) NOT NULL (FK)
cat_ix: NUMBER(2) NOT NULL
is_discriminator_for
Is_An_ATTR2
def_txt: VARCHAR(255) NULL
discr_ix: NUMBER(6) NOT NULL (FK)
compl_ind_code: VARCHAR(2) NOT NULL
holds
migrates_from_parent_source___
Is_A_REL2
cat_ix: NUMBER(2) NOT NULL (FK)
dom_id: NUMBER(9) NOT NULL (FK)
dom_val_ix: NUMBER(12) NOT NULL (FK)
Is_A_REL1
Is_An_ATTR4
opt_ind_code: VARCHAR(2) NOT NULL
P 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)
is_source_for
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)
is_originator_for
unifies
provides_the_attribute_referen
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_nam e_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
PK_ATTR
attr_ix: NUMBER(6) NOT NULL (FK)
NK_ATTR
Z
BASE_ATTR
FK_ATTR
host_ent_id: NUMBER(8) NOT NULL (FK)
Is_An_ATTR3
SUBT_REL
sup_ent_id: NUMBER(8) NOT NULL (FK)
sub_ent_id: NUMBER(8) NOT NULL (FK)
Z rel_ix: NUMBER(2) NOT NULL (FK)
Is_An_ATTR1
data_type_code: VARCHAR(7) NOT NULL
data_len_cnt: NUMBER(4) NOT NULL
data_dec_cnt: NUMBER(2) NULL
describes_allowed_values_for
has
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)
nam e_txt: VARCHAR(80) NULL (IE1.1)
type_code: VARCHAR(6) NOT NULL (AK1.3)
src_txt: VARCHAR(100) NULL
discriminates
BR
br_id: NUMBER(12) NOT NULL
is_composed_of1
cat_code: VARCHAR(6) NOT NULL
BR_ENT
section_xref_txt: VARCHAR(15) NOT NULL
br_id: NUMBER(12) NOT NULL (FK)
name_txt: VARCHAR(999) NOT NULL
br_ent_ix: NUMBER(12) NOT NULL
ent_of_interest_id: NUMBER(8) NOT NULL (FK)
tab_xref_txt: VARCHAR(15) NULL
is_com posed_of2
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
is_composed_of3
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)
L-1
1, 1 / 1, 1 -- 8:03:13 AM , 5/12/2009
contains99
is_part_of99
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
is_basis_for
V3.1.4

JC3IEDM Metamodel

Transcription

Similar documents

jc3iedm overview - MIP Public Home

FHA Update for REALTORS

Malay Named Entity Recognition Based on Rule-Based

information exchange policy vocabulary (iepv)

Photo search by face positions and facial attributes on

1st Reading - Jersey City

slides in pdf

Federal and Provincial Income Tax Rates and Brackets

Persistence in Massively Multiplayer Online Games

JC3IEDM-Main-3.1.4

JC3IEDM-Annex O-XML-3.1.4.doc

HKAS 21, 18 and 23 Today`s Agenda

Phenomenon-Driven Process Design methodology