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 an 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 in the data dictionary of the data elements and records that form the database, and to assist the application team in choosing 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, to document physical design choices and their implications (e.g., what is satisfied, and what is not), and to 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 ∙ 17