Physical Models

Physical Models

There are also two levels of physical models for an implementation project: the Transformation Model and the DBMS Model. The physical models capture all of the information that systems developers need to understand and implement a logical model as a database system. The Transformation Model is also a “project data model” that describes a portion of an overall data structure intended for support by a single automation effort. ERwin supports individual projects within a business area, allowing the modeler to separate a larger area model into submodels, called subject areas. Subject areas can be developed, reported on, and generated to the database in isolation from the area model and other subject areas in the model.

The Transformation Model

The objectives of the transformation model are to provide the Database Administrator (DBA) with sufficient information to create an efficient physical database, to provide a context for the definition and recording of the data elements and records that form the database in the data dictionary, and to help the application team choose a physical structure for the programs that will access the data.

When deemed appropriate for the development effort, the model can also provide the basis for comparing the physical database design against the original business information requirements to:

■Demonstrate that the physical database design adequately supports those requirements.

■Document physical design choices and their implications, such as what is satisfied, and what is not.

■Identify database extensibility capabilities and constraints.

The DBMS Model

The Transformation Model directly translates into a DBMS model, which captures the physical database object definitions in the RDBMS schema or database catalog. ERwin directly supports this model with its schema generation function. Primary keys become unique indices. Alternate keys and inversion entries also may become indices. Cardinality can be enforced either through the referential integrity capabilities of the DBMS, application logic, or “after the fact” detection and repair of violations.

Information Systems, Databases, and Models 2–7