Artifact: Data Model
|
| The data model describes the logical and physical representations of persistent data used by the application. In cases where the application will utilize a relational database management system (RDBMS), the data model may also include model elements for stored procedures, triggers, constraints, etc. that define the interaction of the application components with the RDBMS. | |
| Role: | Database Designer | |
|---|---|---|
| Optionality/Occurrence: | Optional.Inception and Elaboration phases. | |
| Templates and Reports: |
| |
| Examples: |
| |
| UML Representation: | A package stereotyped as <<model>>. | |
| More Information: |
| |
|
| ||
| Input to Activities:
| Output from Activities:
|
Purpose
The Data Model is used to describe the logical and physical structure of the persistent information managed by the system. The data model may be initially created through reverse engineering of existing persistent data stores (databases) or may be initially created from a set of persistent Design Classes in the Design Model.
The data model is needed whenever the persistent storage mechanism is based upon some non-object-oriented technology. The data model is specifically needed where the persistent data structure cannot be automatically and mechanically derived from the structure of persistent classes in the design model. It is used to define the mapping between persistent design classes and persistent data structures, and to define the persistent data structures themselves.
The properties table below describes the elements of the data model. The definitions of the model properties included in this table are consistent with the Data Modeling profile for version 1.3 of Unified Modeling Language (UML) specification. The data modeling profile elements for UML version 1.4 have not yet been defined.
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. | Classes, stereotyped as <<Table>>. |
| Relationship | Simple association between tables in the model. | Association, stereotyped as <<Non-Identifying>> |
| Strong Relationship | Composite Aggregation relationship between tables in the model. | Association, stereotyped as <<Identifying>> |
| Dependency (View to Table) | Dependency between Tables, Views and other model elements | Dependency, stereotyped as <<Derive>> for dependency relationships between Table and View |
| Column | The data values of the tables. | Attribute, stereotyped as <<Column>>. |
| Domain | A user-defined data type. | Class, stereotyped as <<Domain>>. |
| View | A virtual table, composed of columns from one or more tables. | Class, stereotyped as <<View>>. |
| Diagrams | The diagrams in the model, owned by the packages. | Class Diagrams that depict Tables and their relationships and Component Diagrams that depict the realization of the Tables in the model to Tablespaces components and Database components. |
| Index | Data access structures used to speed access along specified paths. | Operation, stereotyped as <<Index>>. |
| Trigger | Event-activated behavior associated with tables. | Operation, stereotyped as <<Trigger>>. |
| Check constraint | A validation rule on a column or table. It can consist of a range of valid values or calculations. | Operation, stereotyped as <<Check>>. |
| Unique constraint | Designates that the data in a column or set of columns must be unique. | Operation, stereotyped as <<Unique>>. |
| Stored Procedure Package | A Class that is used as a "container" for Stored Procedure operations | Class, stereotyped as <<SP_Container>> |
| Stored Procedure | Explicitly invoked behavior, associated with tables or with the model as a whole. | Operation, stereotyped as <<SP>>. |
| Schema | Container for elements of the data model that represents the overall structure of the database. Used for managing security and ownership of tables. | Package stereotyped as <<Schema>>. |
| Database | Model element that represents the physical database | Component, stereotyped as <<Database>> |
| Tablespace | Units of physical storage in a database | Component, stereotyped as <<Tablespace>> |
Timing
The data model may be started in the Inception Phase, as part of architectural prototyping, to understand existing reusable assets, or to get a jump-start on the design. In the Elaboration Phase, a data model is developed to the extent needed to mitigate key risks and support the architecturally significant use cases. In particular, it is generally important in elaboration have a solid mechanism for accessing persistent data storage (in most cases a database) from the rest of the application.
Responsibility
A 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
For projects which have little persistent data, or have a straightforward transformation from design classes to the persistency mechanism, a separate data model may not be needed. For projects utilizing a RDBMS for persistence, the data model will need to be tailored to the specifics semantics of the underlying database, which may vary slightly between RDMBSes.
