7 |
ERwin Methods Guide |
|
|
Creating a Physical Model
The following table summarizes the relationship between objects in a logical and physical model.
Summary of Logical and Physical Model Components
Logical Model |
Physical Model |
Entity |
Table |
Dependent entity |
FK is part of child table’s PK |
Independent entity |
Parent table or, if child table, FK is NOT part of child |
|
table’s PK |
Attribute |
Column |
Logical datatype (text, number, |
Physical datatype (valid example varies depending on |
datetime, blob) |
the target server selected) |
Domain (logical) |
Domain (physical) |
Primary key |
Primary key, PK Index |
Foreign key |
Foreign key, FK Index |
Alternate key (AK) |
AK Index—a unique, non-primary index |
Inversion entry (IE) |
IE Index—a non-unique index created to search table |
|
information by a non-unique value, such as customer |
|
last name. |
Key group |
Index |
Business rule |
Trigger or stored procedure |
Validation rule |
Constraint |
Relationship |
Relationship implemented using FKs |
Identifying |
FK is part of child table’s PK (above the line) |
Non-Identifying |
FK is NOT part of child table’s PK (below the line) |
Subtype |
Denormalized tables |
Many-to-many |
Associative table |
Referential Integrity |
INSERT, UPDATE, and DELETE Triggers |
(cascade, restrict, set |
|
null, set default) |
|
Cardinality |
INSERT, UPDATE, and DELETE Triggers |
N/A |
View or view relationship |
N/A |
Preand post-script |
|
|
Note: Referential integrity is described as a part of the logical model, because the decision of how you want a relationship to be maintained is a business decision, but it is also a physical model component, because triggers or declarative statements appear in the schema. ERwin supports referential integrity as a part of both the logical and physical model.
92 ∙ Creating a Physical Model
ERwin Methods Guide |
7 |
|
|
Denormalization
ERwin also lets you denormalize the structure of the logical model so that you can build a related physical model that is designed effectively for the target RDBMS. Features supporting denormalization include:
♦“Logical only” properties for entities, attributes, key groups, and domains. You can mark any item in the logical model “logical only” so that it appears in the logical model, but does not appear in the physical model. For example, you can use the “logical only” settings to denormalize subtype relationships or support partial key migration in the physical model.
♦“Physical only” properties for tables, columns, indexes, and domains. You can mark any item in the physical model “physical only” so that it appears in the physical model only. This setting also support denormalization of the physical model because it enables the modeler to include tables, columns, and indexes in the physical model that directly support physical implementation requirements.
♦Resolution of many-to-many relationships in a physical model. ERwin provides support for resolving many-to-many relationships in both the logical and physical models. If you resolve the many-to-many relationship in the logical model, ERwin creates the associative entity and lets you add additional attributes. If you choose to keep the many-to-many relationship in the logical model, you can still resolve the relationship in the physical model. ERwin maintains the link between the original logical design and the new physical design, so the origin of the associative table is documented in the model.
Creating a Physical Model ∙ 93
7 |
ERwin Methods Guide |
|
|
94 ∙ Creating a Physical Model
ERwin Methods Guide |
A |
|
|
Dependent Entity Types
Classification of Dependent Entities
The following table lists the types of dependent entities that may appear in an IDEF1X diagram.
Dependent Entity |
Description |
Example |
Type |
|
|
Characteristic |
A characteristic entity represents a group |
|
|
of attributes which occurs multiple times |
|
|
for an entity, and which is not directly |
|
|
identified by any other entity. In the |
|
|
example, HOBBY is said to be a |
|
|
characteristic of PERSON. |
|
Associative or Designative
Subtype
Associative and designative entities record multiple relationships between two or more entities. If the entity carries only the relationship information, it is termed a designative entity. If it also carries attributes that further describe the relationship, it is called associative. In the example, ADDRESS-USAGE is an associative or designative entity.
Subtype entities are the dependent entities in a subtype relationship. In the example, CHECKING-ACCOUNT, SAVINGSACCOUNT, and LOAN-ACCOUNT are subtype entities.
Dependent Entity Types ∙ 95
A |
ERwin Methods Guide |
|
|
96 ∙ Dependent Entity Types