Support for the Roles of the Physical Model
Support for the Roles of the Physical Model
Support is provided for both roles of a physical model:
■Generating the physical database
■Documenting physical design against the business requirements
For example, in a logical/physical model, you can create a physical model from an ERD, key-based, or fully attributed model simply by changing the view of the model from Logical Model to Physical Model. Each option in the logical model has a corresponding option in the physical model. Therefore, each entity becomes a relational table, attributes become columns, and keys become indices.
Once the physical model is created, you can generate all model objects in the correct syntax for the selected target server directly to the catalog of the target server, or indirectly as a schema DDL script file.
Summary of Logical and Physical Model Components
The following table summarizes the relationship between objects in a logical and a physical model:
Logical Model |
Physical Model |
|
|
Entity |
Table |
|
|
Dependent entity |
Foreign Key is part of the child table's |
|
Primary Key |
|
|
Independent entity |
Parent table or, if it is a child table, |
|
Foreign Key is NOT part of the child table's |
|
Primary Key |
|
|
Attribute |
Column |
|
|
Logical datatype (text, number, datetime, |
Physical datatype (valid example varies |
blob) |
depending on the target server selected) |
|
|
Domain (logical) |
Domain (physical) |
|
|
Primary key |
Primary key, Primary Key Index |
|
|
Foreign key |
Foreign key, Foreign Key Index |
|
|
Alternate key (AK) |
Alternate Key Index-a unique, non-primary |
|
index |
|
|
86 Methods Guide