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 might also include model elements for stored procedures, triggers, constraints, etc. that define the interaction of the application components with the RDBMS.
Domains: Architecture
Relationships
Description
Main Description

Data models are used to represent the information that is used and manipulated during the execution of business processes.  As is described in Concept: Data Model, organizations will use data models with differing levels of abstraction to satisfy different requirements:

  • Conceptual data models deal with "real world" concepts and are used to elicit data requirements from stakeholders;
  • Logical data models are used to understand the key elements of data, including data entities, their attributes, and their relationships; and
  • Physical data models are used to represent the physical data stores.  These models include concrete constructions, such as triggers, indexes, typed fields, etc.     

The physical data model might be initially created through reverse engineering of existing persistent data stores (databases).

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.

Tailoring
Impact of not havingChaos and a failed business generally result if an organization of any size does not maintain clear representations of the data that it uses.  Lack of understanding of common data makes it extremely difficult to construct, automate, and maintain business processes that span multiple functional areas of the enterprise.
Representation Options

Data models can be represented in numerous forms, including:

  • Natural-language text, most effectively used when created in tabular form
  • Data definition language (DDL) - used to define physical data models
  • Graphical -- effective for conceptual, logical, and physical data models.

Ambler summarizes four notations that commonly are used to graphically depict data models. 

The data model might have the following properties:                  

Property Name Brief Description
Introduction A textual description that serves as a brief introduction to the model.
Packages The packages used for organizational grouping purposes.
Tables The tables in the data model, owned by the packages.
Relationship Simple association between tables in the model.
Strong Relationship Composite Aggregation relationship between tables in the model.
Dependency (View to Table) Dependency between Tables, Views and other model elements
Column The data values of the tables.
Domain A user-defined data type
View A virtual table, composed of columns from one or more tables.
Diagrams The diagrams in the model, owned by the packages.
Index Data access structures used to speed access along specified paths.
Trigger Event-activated behavior associated with tables.
Check constraint A validation rule on a column or table. It can consist of a range of valid values or calculations.
Unique constraint Designates that the data in a column or set of columns must be unique.
Stored Procedure Package A Class that is used as a "container" for Stored Procedure operations
Stored Procedure Explicitly invoked behavior, associated with tables or with the model as a whole.
Schema Container for elements of the data model that represents the overall structure of the database. Used for managing security and ownership of tables.
Database Model element that represents the physical database
Tablespace Units of physical storage in a database


More Information
Concepts