Work Product Descriptor: Data 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.