Artifact: Data Model










var backPath = './../../';
var imgPath = './../../images/';
var nodeInfo=[{view: "view:_LVCagP5WEdmAzesbYywanQ", path: ["_LVCagP5WEdmAzesbYywanQ", "_zRigkAILEdq-_NKqZM1EhA", "_qwxC8N7YEdmjRZts2c4ZjQ", "{87EE3BF5-17CA-4211-BD3D-32F361E58550}", "{9DCF1723-1A21-4F48-BEDE-DBC543489682}"]}, {view: "view:_LVCagP5WEdmAzesbYywanQ", path: ["_LVCagP5WEdmAzesbYywanQ", "_zRigkAILEdq-_NKqZM1EhA", "_QV4x0AISEdqTna4sZVFRow", "_kjFBYN7HEdm8G6yT7-Wdqw", "{9DCF1723-1A21-4F48-BEDE-DBC543489682}"]}, {view: "view:_FCx1oN7CEdmsEI4YDGX2ag", path: ["_FCx1oN7CEdmsEI4YDGX2ag", "_f6_YwN7DEdmsEI4YDGX2ag", "_qwxC8N7YEdmjRZts2c4ZjQ", "{87EE3BF5-17CA-4211-BD3D-32F361E58550}", "{9DCF1723-1A21-4F48-BEDE-DBC543489682}"]}, {view: "view:_FCx1oN7CEdmsEI4YDGX2ag", path: ["_FCx1oN7CEdmsEI4YDGX2ag", "_Jvt1cAIaEdqEutyfYo0quQ", "_EOvXUN7HEdm8G6yT7-Wdqw", "_kjFBYN7HEdm8G6yT7-Wdqw", "{9DCF1723-1A21-4F48-BEDE-DBC543489682}"]}, {view: "view:_FCx1oN7CEdmsEI4YDGX2ag", path: ["_FCx1oN7CEdmsEI4YDGX2ag", "_Jvt1cAIaEdqEutyfYo0quQ", "_jijhYAIaEdqEutyfYo0quQ", "_mTMIkN7REdmjRZts2c4ZjQ", "{9DCF1723-1A21-4F48-BEDE-DBC543489682}"]}];
contentPage.preload(imgPath, backPath, nodeInfo, '', false, false, false);










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






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.



Relationships



RolesResponsible:



Database Designer


Modified By:



Database Designer





TasksInput To:



Database Design


Identify Test Ideas


Implement Design Elements


Review the Design


Output From:



Database Design





Process Usage


Analysis & Design
 > 
Design the Database
 > 
Data Model


Analysis & Design
 > 
Analyze Behavior
 > 
Data Model


Analysis & Design
 > 
Design Components
 > 
Data Model


Implementation
 > 
Implement Components
 > 
Data Model


Test
 > 
Improve Test Assets
 > 
Data Model


Test
 > 
Define Evaluation Mission
 > 
Data Model


Test
 > 
Test and Evaluate
 > 
Data Model






Tailoring



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



Checklists


Data Model





Guidelines


Data Model


Forward-Engineering Relational Databases


Reverse-engineering Relational Databases








©  Copyright IBM Corp. 1987, 2006.  All Rights Reserved.







contentPage.onload();