Please note : This help page is not for the latest version of Enterprise Architect. The latest help can be found here.
Physical Data Models
A Physical Data Model visually represents the structure of data as implemented by a relational database schema. In addition to providing a visual abstraction of the database structure, an important benefit of defining a Physical Data Model is that you can automatically derive the database schema from the model. This is possible due to the richness of meta-data captured by a Physical Data Model and its close mapping to aspects of the database schema, such as database Tables, columns, Primary keys and Foreign keys.
Example Data Model
This example shows a Physical Data Model that could be used to automatically generate a database schema. Each Table is represented by a UML Class; Table columns, Primary Keys and Foreign Keys are modeled using UML attributes and operations.
The example model is defined using Enterprise Architect's UML Profile for Data Modeling; the relationship between the Tables uses the Information Engineering notation.
Information Engineering is one of three notations that Enterprise Architect supports to help Data Modelers identify cardinality in relationships.
Prior to creating a Physical Data Model it is advisable for you to set the default DBMS for the project. Setting a default DBMS ensures that all new database elements that are created on diagrams are automatically assigned the default DBMS.
If the default DBMS is not set, new Tables are created without a DBMS assigned, this restricts Enterprise Architect's ability to model the physical objects correctly. For example Enterprise Architect is unable to determine the correct list of datatypes for columns.
You can set the default DBMS type using:
- 'Start > Workspace > Preferences > Code Editors', or
- The Code Generation Toolbar
Note: When modeling via the Database Builder the default DBMS is defined at the model level (as a Tagged Value 'DBMS' against the <<Database>> Package) instead of at the project level, thereby allowing for greater flexibility when projects involve multiple DBMSs.