Denormalization
Logical Model |
Physical Model |
|
|
Inversion entry (IE) |
Inversion entry 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 Foreign |
|
Keys |
|
|
Identifying relationship |
Foreign Key is part of the child table's |
|
Primary Key (above the line) |
|
|
Non-identifying relationship |
Foreign Key is NOT part of the child table's |
|
Primary Key (below the line) |
|
|
Subtype relationship |
Denormalized tables |
|
|
Many-to-many relationship |
Associative table |
|
|
Referential Integrity relationship (Cascade, |
INSERT, UPDATE, and DELETE Triggers |
Restrict, Set Null, Set Default) |
|
|
|
Cardinality relationship |
INSERT, UPDATE, and DELETE Triggers |
|
|
N/A |
View or view relationship |
|
|
N/A |
Prescript or postscript |
|
|
Referential integrity is a part of the logical model, since the decision about how to maintain a relationship is a business decision. Referential integrity is also a physical model component, since triggers or declarative statements appear in the schema. Referential integrity is supported as a part of both the logical and physical models.
Denormalization
You can also denormalize the structure of the logical model, or allow data redundancy in a table to improve query performance 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.
Chapter 8: Physical Models 87
Denormalization
■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 supports denormalization of the physical model since 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. Support for resolving many-to-many relationships is provided in both the logical and physical models. If you resolve the many-to-many relationship in the logical model, the associative entity is created 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. The link is maintained between the original logical design and the new physical design, so the origin of the associative table is documented in the model.
88 Methods Guide
Appendix A: Dependent Entity Types
This section contains the following topics:
Classification of Dependent Entities (see page 89)
Classification of Dependent Entities
The following table lists the types of dependent entities that may appear in an IDEF1X diagram:
Dependent Entity Type |
Description |
Example |
|
|
|
Characteristic |
A characteristic entity represents a group of |
|
|
attributes that occur multiple times for an |
|
|
entity, and is not directly identified by any |
|
|
other entity. In the example, HOBBY is a |
|
|
characteristic of PERSON. |
|
|
|
|
Associative or Designative |
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 an associative entity. In the example, |
|
|
ADDRESS-USAGE is an associative or |
|
|
designative entity. |
|
|
|
|
Subtype |
Subtype entities are the dependent entities |
|
|
in a subtype relationship. In the example, |
|
|
CHECKING-ACCOUNT, SAVINGS-ACCOUNT, |
|
|
and LOAN-ACCOUNT are subtype entities. |
|
|
|
|
Appendix A: Dependent Entity Types 89