Logical data models capture the business definition of information assets by using the entity-relationship modeling approach. The logical data model consists of a set of related entities and their business associations.
Logical data models can be implemented by both physical data models and database schemas. You can use InfoSphere® Metadata Asset Manager to set implementation relationships between logical data models, physical data models, database schemas, and their contained assets.
You can use bridges to import logical data models from design tools such as InfoSphere Data Architect and CA ERwin Data Modeler.
If you import logical data models, you have an end-to-end view of the metadata assets that control data flow. You can trace a logical entity to the table that implements the logical entity, through the jobs that use the columns of the table, and on to the business intelligence (BI) report that is based on the table.
Asset type | Definition | Components of the identity of the asset | Contained asset types |
---|---|---|---|
Logical data model | A logical representation of the data objects that are related to a business domain and the rules or constraints that govern their associations in real-world applications. Logical data models consist of a set of entities and relationships. A logical data model can be implemented by a physical data model or a database schema. |
If a logical data model has a submodel, the identity components
of the submodel are the following:
|
Subject area, logical entity, logical relationship,
entity generalization hierarchy, and logical domain Note: Logical data
models can also contain submodels.
|
Subject area | A grouping of related logical entities that focus on a particular business area. A logical entity can be included in more than one subject area to better differentiate it from other logical entities in the logical data model. |
|
A subject area can include but does not contain logical entities, logical relationships, and entity generalization hierarchies. Deleting the subject area does not delete assets of these types. |
Logical entity | An asset that represents the data structure in the logical data model. A logical entity defines entity attributes, entity keys, and entity constraints. A logical entity can be implemented by a design table in a physical model or by a database table. |
|
Entity attribute, entity key, and entity constraint |
Entity attribute | A relevant property or characteristic of an entity that defines the meaning and purpose of a unit of data. An entity attribute can be implemented by a design column in a physical data model or by a database column. |
|
Validation constraint |
Validation constraint | A validation constraint is an abstract supertype that can be a validation rule, validation range, or validation list. | See validation rule, validation range, or validation list. | |
Validation rule | An expression that defines the valid values for an entity attribute or a logical domain. |
|
|
Validation range | A range of values that defines the valid values for an entity attribute or a logical domain. |
|
|
Validation list | A list of discrete values that defines the valid values for an entity attribute or a logical domain. |
|
Validation value |
Validation value | A discrete value in a validation list. |
|
|
Entity key | A semantic identifier that consists of one or more entity attributes. An entity key is an abstract supertype that can be a unique key, a reference key, or an inversion entry. | See unique key, reference key, or inversion key. | |
Unique key | A key that specifies the values of the entity attributes that uniquely identify the instances of the logical entity. A unique key can be implemented as a candidate key in a design table or a database table. |
|
|
Reference key | A key that specifies a referential integrity constraint that is associated with a relationship. A reference key can be implemented as a foreign key in a design table or a database table. |
|
|
Inversion key | A non-unique logical identifier that defines an inversion entry. An inversion key can be implemented by an index in a design table or a database table. |
|
|
Entity key component | An association between an entity key and one of its attributes. |
|
|
Entity constraint | A business rule in the form of a constraint that is attached to a logical entity. |
|
|
Logical relationship | An asset that represents the set of business rules that define the associations between two logical entities. A logical relationship can be implemented by a design foreign key or a foreign key for a database table. |
|
Relationship end |
Relationship end | A connection between the entity and the relationship that expresses how the logical entity participates in the relationship. |
|
|
Entity generalization hierarchy | An asset that represents the inheritance associations that classify logical entities into subtypes and supertypes. A hierarchy supertype is a logical entity that is the supertype or parent entity in the hierarchy. |
|
Hierarchy supertype and hierarchy subtype |
Hierarchy subtype | An asset that connects a logical entity as a subtype in an entity generalization hierarchy. An entity can be a subtype in more than one hierarchy. |
|
|
Logical domain | A user-defined data type or global attribute that can be reused in multiple logical entities. A logical domain can be implemented by a physical domain or a database domain. Logical domains can contain other logical domains. |
If a logical domain contains another logical domain, the identity
components of the contained logical domain are the following:
|
Logical domain |