Artifact: Data Model
 |
The data model is a subset of the implementation model which describes the logical and physical representation of persistent data in the system. It also includes any behavior defined in the database, such as stored procedures, triggers, constraints, etc. |
| UML representation: | A top-level Package stereotyped as «data model», containing a set of Components which represent the physical storage of persistent data in the system. |
| Worker: | Database Designer |
| Optionality: | Optional if the system has no persistent data |
| Reports: | |
| More information: | |
Purpose 
The following people use the design model:
- The database designer, to map persistent classes to database structures, and to define the implementation of persistent class behavior.
- The architect, to understand the architectural issues of persistence.
- The designer, to understand how persistent classes are stored, retrieved, updated and deleted.
Properties
Property Name |
Brief Description |
UML Representation |
| Introduction | A textual description that serves as a brief introduction to the model. | Tagged value, of type "short text". |
| Packages | The packages used for organizational grouping purposes. | Owned via the association "represents", or recursively via the aggregation "owns". |
| Tables | The tables in the data model, owned by the packages. | Components, stereotyped as <<table>>. |
| Relationships | The relationships between tables in the model. | Associations, stereotyped as <<foreign key>>. |
| Columns | The data values of the tables. | Attributes, stereotyped as <<column>>. |
| Diagrams | The diagrams in the model, owned by the packages. | - " - |
| Indexes | Data access structures used to speed access along specified paths. | Components, stereotyped as <<index>>. |
| Triggers | Event-activated behavior associated with tables. | Operation, stereotyped as <<trigger>>. |
| Procedures | Explicitly invoked behavior, associated with tables or with the model as a whole. | Component, stereotyped as <<procedure>>. |
Timing
The data model determines the architecture of the database.
Responsibility
An database designer is responsible for the integrity of the data model, ensuring that the data model as a whole is correct, consistent, and understandable.
Tailoring
Needs to be adapted to the semantics of the database, which may vary slightly between RDBMS's. Object Database systems have quite different semantics and the model described above needs to be modified accordingly.
