Domain models

A domain model describes the domain types that an organization allows and their constraints. Using domain data types instead of base data types ensures that you maintain consistency across an organization, and allows reuse of common data type definitions for greater team efficiency.

A domain model consists of a collection of domain data types. A domain data type represents an abstract data type that can be restricted by adding constraints. Domain data types are based on base data types. For example, you can define domain data types for commonly used definitions such as social security number, sex, height, or marital status.

Constraint definitions follow XML schema constraint definitions. For example, you can use an enumeration constraint to limit the number of possible values. A domain called "priority" could have three possible values: "high"; "med"; or "low". You can use a pattern constraint to specify a constraint in a regular expression; for example, "ABC*" .

Enumeration domains are transformed into check constraints in a physical data model. However, other domain constraints are used for documentation only and there are no additional constructs generated for constraints during logical-to-physical data model transformation

Domain model objects can be stored in a domain model (*.ddm) file, or in a logical data model (*.ldm) file. You can create one domain model, and share it across multiple projects and users for maximum efficiency. Domain model objects are always contained in a package object. There is always one root package, but you can add additional packages under the root package to group similar domain objects together.

Using the workbench, you can create a domain model from a template, or you can import simple types from an XML schema definition file (.xsd) into a domain model as domain types. You can also export a domain model into an .xsd file. A domain model can be associated with a logical model so that each domain in the model can be used as an attribute data type.


Feedback