Denormalization
Logical Model |
Physical Model |
|
|
Referential Integrity |
INSERT, UPDATE, and DELETE |
(cascade, restrict, set |
Triggers |
null, set default) |
|
|
|
Cardinality |
INSERT, UPDATE, and DELETE |
|
Triggers |
|
|
N/A |
View or view relationship |
|
|
N/A |
Prescript and postscript |
|
|
Note: Referential integrity is a part of the logical model, because the decision of how you want a relationship to be maintained is a business decision. Referential integrity 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 models.
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 supports 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 8–3
Appendix
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 |
Description |
Example |
Entity 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 |
Associative and |
|
Designative |
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. |
|
|
|
|
Dependent Entity Types A–1
Classification of Dependent Entities
Dependent |
Description |
Example |
Entity Type |
|
|
|
|
|
Subtype |
Subtype entities are the |
|
|
dependent entities in a |
|
|
subtype relationship. In |
|
|
the example, CHECKING- |
|
|
ACCOUNT, SAVINGS- |
|
|
ACCOUNT, and LOAN- |
|
|
ACCOUNT are subtype |
|
|
entities. |
|
|
|
|
A–2 ERwin Methods Guide