Creating a NIEM Data Model

One of the underlying principles behind NIEM is re-use of a common reference vocabulary - a predefined set of data elements and definitions used to define information exchanges. To this end, one of the core tasks in building a NIEM data model is creating a subset of the NIEM reference schema. The goal is to model as much of your data exchange as is practical, by re-using types and elements that are already defined in the NIEM reference model.

A NIEM data model usually consists of a number of packages with the <<InformationModel>> stereotype applied.

Typically, a model will have one package representing a Niem-core subset schema, some other packages representing subsets of particular Domain schemas, and one or more packages representing extension schemas. The extension schema packages provide those elements required by the model, that are not available from the NIEM Reference Model. Often, the root element of the exchange message is separated from more general elements, and modeled in an extension schema Package dedicated to the specific exchange.

Steps for Creating a NIEM 4.0 Data Model

Step	Detail	See also
Import the NIEM 4.0 Reference Model	Many of the activities involved in creating NIEM models, rely on using the NIEM Reference Model. If you haven't already done so, import the Reference Model into your Enterprise Architect project before proceeding further. For more information, see the help topic Download the NIEM Reference Model.	Download the NIEM Reference Model
Create a Subset of the Niem-core Reference Package	There are a number of reasons for creating subsets of the NIEM namespace schemas when creating NIEM IEPDs, but the two most important reasons are: The reference schemas are very large; subsetting produces much smaller schema files that, in turn, leads to faster validation of the schemas Elements within the reference schemas are very loosely constrained; the subsetting process allows modelers to impose much tighter constraints, such as restricting cardinality and allowed values, to more closely reflect actual business requirements In Enterprise Architect, the subsetting process is performed using the Schema Composer. The Schema Composer allows the modeler to select the subset of required classes from the source package and, for each of the selected classes, select a subset of required attributes. The selected classes with their reduced attribute sets are then copied to a target package. Most often the source package will be the Niem-core namespace package from the NIEM Reference Model. In this case, the target package will also be a namespace package named 'Niem-core', but it will be part of your NIEM IEPD model. Other namespace packages from the Reference Model, such as the Domain packages, can also be subsetted in the same way. Use Enterprise Architect's Schema Composer tool to copy a subset of the Niem-core reference package to the Niem-core subset package that is part of your IEPD model. The goal is to model as much of your data exchange as is practical, by re-using types and elements that are already defined in the Niem-core reference model. In cases where your model will also make use of NIEM Domain packages, this subsetting process should be repeated for each domain package that you use. For more information, see the Help topic Subsetting NIEM with the Schema Composer.	Subsetting NIEM with the Schema Composer
Create Extension Packages	When creating a NIEM data model, the aim is to model as much of your data exchange as possible using types and elements from the NIEM Reference Model. What cannot be modeled by re-using existing NIEM elements is then modeled in 'extension' namespace packages, by creating new types and elements using elements from the NIEM-UML profiles, with all types ultimately deriving from XML schema primitive types. Both the NIEM Starter Model (from the Model Wizard) and the MPD Starter Model Pattern (from the Diagram Toolbox) provide <<InformationModel>> Packages in which to model the various schemas. Using PIM diagrams within these packages, you can build models of your different schemas, by adding elements from the Diagram Toolbox. It is suggested that you use the diagram in the 'exchange' package, to assemble the high-level model of your exchange, using types and elements from other schema packages as required. Most IEPDs require extension schemas to define specific types and properties that are unique to the data exchange being defined. However, the NIEM model does not define specific message types or structures for assembling all of the objects in an exchange. It is therefore up to the creator of the IEPD to write an extension schema that declares the root element and the basic structure of the messages. The root element of the exchange brings together all of the objects and associations defined in the exchange. Whilst you are not required to create a separate schema to declare the root element and basic structure of the message, it can be beneficial to separate message-specific extensions into an 'exchange' schema and more generic extensions into 'extension' schemas. Exchange schemas contain definitions that are unique to a message type or group of message types. This generally includes only the root element and its type and possibly some structural elements that form the basic framework of the message. Organizing schema elements into 'exchange' and generic 'extension' groupings also offers the possibility of sharing the more generic schema across multiple IEPDs, whereas the 'exchange' schema is usually specific to one particular IEPD. You can also have multiple 'exchange' schemas in order to represent different message types or groups of different message types.

Step

Detail

See also

Import the NIEM 4.0 Reference Model

Many of the activities involved in creating NIEM models, rely on using the NIEM Reference Model. If you haven't already done so, import the Reference Model into your Enterprise Architect project before proceeding further.

For more information, see the help topic Download the NIEM Reference Model.

Download the NIEM Reference Model

Create a Subset of the Niem-core Reference Package

There are a number of reasons for creating subsets of the NIEM namespace schemas when creating NIEM IEPDs, but the two most important reasons are:

The reference schemas are very large; subsetting produces much smaller schema files that, in turn, leads to faster validation of the schemas
Elements within the reference schemas are very loosely constrained; the subsetting process allows modelers to impose much tighter constraints, such as restricting cardinality and allowed values, to more closely reflect actual business requirements

In Enterprise Architect, the subsetting process is performed using the Schema Composer.

The Schema Composer allows the modeler to select the subset of required classes from the source package and, for each of the selected classes, select a subset of required attributes. The selected classes with their reduced attribute sets are then copied to a target package. Most often the source package will be the Niem-core namespace package from the NIEM Reference Model. In this case, the target package will also be a namespace package named 'Niem-core', but it will be part of your NIEM IEPD model.

Other namespace packages from the Reference Model, such as the Domain packages, can also be subsetted in the same way.

Use Enterprise Architect's Schema Composer tool to copy a subset of the Niem-core reference package to the Niem-core subset package that is part of your IEPD model. The goal is to model as much of your data exchange as is practical, by re-using types and elements that are already defined in the Niem-core reference model.

In cases where your model will also make use of NIEM Domain packages, this subsetting process should be repeated for each domain package that you use.

For more information, see the Help topic Subsetting NIEM with the Schema Composer.

Subsetting NIEM with the Schema Composer

Create Extension Packages

When creating a NIEM data model, the aim is to model as much of your data exchange as possible using types and elements from the NIEM Reference Model. What cannot be modeled by re-using existing NIEM elements is then modeled in 'extension' namespace packages, by creating new types and elements using elements from the NIEM-UML profiles, with all types ultimately deriving from XML schema primitive types.

Both the NIEM Starter Model (from the Model Wizard) and the MPD Starter Model Pattern (from the Diagram Toolbox) provide <<InformationModel>> Packages in which to model the various schemas. Using PIM diagrams within these packages, you can build models of your different schemas, by adding elements from the Diagram Toolbox.

It is suggested that you use the diagram in the 'exchange' package, to assemble the high-level model of your exchange, using types and elements from other schema packages as required.

Most IEPDs require extension schemas to define specific types and properties that are unique to the data exchange being defined. However, the NIEM model does not define specific message types or structures for assembling all of the objects in an exchange. It is therefore up to the creator of the IEPD to write an extension schema that declares the root element and the basic structure of the messages. The root element of the exchange brings together all of the objects and associations defined in the exchange.

Whilst you are not required to create a separate schema to declare the root element and basic structure of the message, it can be beneficial to separate message-specific extensions into an 'exchange' schema and more generic extensions into 'extension' schemas. Exchange schemas contain definitions that are unique to a message type or group of message types. This generally includes only the root element and its type and possibly some structural elements that form the basic framework of the message.

Organizing schema elements into 'exchange' and generic 'extension' groupings also offers the possibility of sharing the more generic schema across multiple IEPDs, whereas the 'exchange' schema is usually specific to one particular IEPD. You can also have multiple 'exchange' schemas in order to represent different message types or groups of different message types.