Artifact: Data Model
This artifact 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.
Domains: Analysis and Design
Work Product Kinds: Model

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.

Representation Options

UML Representation: A package stereotyped as <<model>>.

The data model may have the following 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»

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.

More Information