OpenUP/OpenUP_baseline_EN/exported_HTML_0_9/openup_basic/guidances/guidelines/data_modeling.html - epf/org.eclipse.epf.nl-libraries - Git at Google

 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
 <!-- VERSION rmc:7.1.0 -->
 <html xmlns="http://www.w3.org/1999/xhtml">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
 <!-- START NON-TRANSLATABLE -->
 <title>\openup_basic\guidances\guidelines\data_modeling.xmi</title>
 </head>
 <!-- WARNING: do not modify the generated comments in this file below this line.  They are used as markers for the import process. -->
 <body>
 Element Name: data_modeling.xmi<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: presentationName<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:presentationName,_ienXEEyAEdu-df7p0PuRvQ CRC: 754925525 -->Physical Data Modeling<!-- END:presentationName,_ienXEEyAEdu-df7p0PuRvQ -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: briefDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:briefDescription,_ienXEEyAEdu-df7p0PuRvQ CRC: 828844106 -->A physical data model (PDM) captures the design of a persistent data store such as a relational database or data file. Data modeling is the act of creating such a model.<!-- END:briefDescription,_ienXEEyAEdu-df7p0PuRvQ -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: mainDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:mainDescription,-XMbxFU8M85cRlf3C4iwAGw CRC: 2725241037 --><h3>
     Overview
 </h3>
 Physical data models (PDMs) are used to design the structure of a persistent data store. Typically a PDM is created for a
 single data store, although sometimes a PDM will cover several related data stores (this is particularly true when the data
 storage mechanism is file based). The assumption in this guideline is that you are modeling the schema of a single
 relational database.
 <h3>
     The Data Model in OpenUP
 </h3>
 The PDM is part of the Work Product: Design. It’s described as different views or perspectives of a portion of the design.
 <h3>
     Data Model Types
 </h3>
 <p dir="ltr" style="MARGIN-RIGHT: 0px">
     Traditionally, there are three types of data models:
 </p>
 <ol>
     <li>
         <div style="MARGIN-RIGHT: 0px">
             Conceptual. A conceptual model, also referred to as a domain model, depicts the critical business entities and
             the relationships between them.
         </div>
     </li>
     <li>
         <div style="MARGIN-RIGHT: 0px">
             Logical. A logical data model (LDM) adds detail, in particular data attributes and more entities. LDMs will
             optionally indicate candidate keys (one or more attributes of an entity which uniquely identify it) of an
             entity. LDMs describe how the design of the system handles the data that will be actually maintained in the
             PDM.
         </div>
     </li>
     <li>
         <div style="MARGIN-RIGHT: 0px">
             <p>
                 Physical. A PDM depicts the table structure (in the case of a relational database design), the
                 relationships between the tables, and the primary and foreign keys implemented by the tables. PDMs
                 potentially indicate views, stored procedures, and other database elements.
             </p>
         </div>
     </li>
 </ol>
 <p>
     For systems built using object and/or component-based technology, the LDM is usually not created in favor of a class
     model.
 </p>
 <h4 style="MARGIN-RIGHT: 0px">
     Physical Data Modeling
 </h4>
 <p>
     The PDM consists of the detailed database table designs and their relationships. The tables in the PDM have
     well-defined columns, as well as keys and indexes as needed. The tables might also have triggers defined as necessary
     to support the database functionality and referential integrity of the system. In addition to the tables, stored
     procedures have been created, documented, and associated with the database in which the stored procedure will reside.
 </p>
 <p>
     The diagram below shows an example of some of the elements of a PDM. A UML-based notation is used, although other
     notations such as “crow's feet” or Information Engineering (IE) are also common. This example model is a part of the
     PDM of a fictional order entry system. It depicts three tables (Order, OrderItem, and Item), three stored procedures
     (GetOrders, GetTotalBusiness, and TestDatabase), and a trigger on Order named deleteOrderItems. The figure also depicts
     the columns of each table, the primary key for each table, and any foreign keys to other tables.
 </p>
 <p>
     <strong>Example Physical Data Model</strong>
 </p>
 <p>
     &nbsp;<img height="309" alt="" src="./resources/PDMSample.JPG" width="597" />
 </p>
 <p>
     An existing database can be reverse-engineered to populate the PDM if the team has access to a tool that can transform
     a database into a model.
 </p>
 <h3>
     How to Model Database Schemas
 </h3>
 <p>
     Perform the following in an iterative manner:
 </p>
 <ol>
     <li>
         Identify tables. A table is similar conceptually to object-orientation’s concept of a class – a table contains a
         collection of rows of data whereas a class defines a collection of objects. A table could contain rows representing
         people, places, things, events, or concepts. Examples of tables include Customer, Order, and OrderItem.
     </li>
     <li>
         Identify columns. Each table has one or more columns. A column stores a single data attribute for each row. For
         example, the Customer table may have columns such as First Name and Surname. A column has a single data type, such
         as INT, DATETIME, or VARCHAR.
     </li>
     <li>
         Follow accepted modeling conventions. Your organization should have standards and guidelines applicable to data
         modeling, in particular naming conventions,&nbsp;that you should follow.
     </li>
     <li>
         Identify relationships between tables. In the real world entities have relationships with other entities. For
         example, customers PLACE orders, customers LIVE AT addresses, and line items ARE PART OF orders. These
         relationships will exist between the rows of data stored in the corresponding tables.
     </li>
     <li>
         Assign keys. A key is one or more columns that uniquely identify a row in a table. A primary key is the preferred
         key for a table. For example, the Customer table may have two potential keys, CustomerID and SocialSecurityNumber.
         You could choose to use CustomerID as the primary key, thereby making SocialSecurityNumber a secondary key. Foreign
         keys are used to maintain relationships between rows.
     </li>
     <li>
         Normalize to reduce data redundancy. Data normalization is a process in which columns within a PDM are organized to
         increase the cohesion of tables. In other words, the goal of data normalization is to reduce and even eliminate
         data redundancy, an important consideration for application developers because it is incredibly difficult to store
         objects in a relational database that maintains the same information in several places.
     </li>
     <li>
         De-normalize to improve performance. Normalized data schemas, when put into production, often suffer from
         performance problems. An important part of data modeling is to de-normalize portions of&nbsp;the data schema, to
         increase data redundancy by storing the same information in several places or manners, to improve database access
         times.
     </li>
 </ol>
 <h3>
     Data Modeling Throughout the Lifecycle
 </h3>
 <h4>
     Inception Phase
 </h4>
 <p>
     During the Inception phase the goal is to identify high-level requirements for the system so that the scope may be
     identified and project funding obtained. Little, if any, data modeling is performed at this point although some
     conceptual modeling may occur. Detailed data models are usually not needed at this point.
 </p>
 <h4>
     Elaboration Phase
 </h4>
 <p>
     The goal of the Elaboration phase is to eliminate technical risk and to produce a stable (baselined) architecture for
     the system. One of several architectural issues that is likely to arise is data architecture. To support this effort,
     you will need to model the major database structures (tables, indexes, and primary and foreign key columns) and then
     create the database schema from the model (ideally it would be generated from a modeling tool).
 </p>
 <p>
     Additionally, representative data volumes may be loaded into the database to support performance testing. Based on the
     results of performance testing, the PDM might need to be adjusted with optimization techniques, including but not
     limited to de-normalizing, optimizing physical storage attributes, or distribution and indexing.
 </p>
 <h4>
     Construction Phase
 </h4>
 <p>
     During the Construction phase the goal is to build a working system that is ready to be released. During each
     iteration&nbsp;the&nbsp;design, implementation, and tests are fleshed out to implement that iteration's requirements.
     In other words development artifacts, including your data-oriented artifacts, evolve over time. To support data model
     changes you may discover the need to refactor your existing database schema.
 </p>
 <h4>
     Transition Phase
 </h4>
 <p>
     The PDM is maintained during the Transition phase in response to approved change requests. You should keep the PDM
     synchronized with the database as the application goes through final acceptance test and is deployed into production.
 </p>
 <h3>
     Round-trip Engineering Considerations
 </h3>
 <p>
     If a development team is using modern visual modeling tools that have the ability to convert classes to tables (and
     vice versa) or has the ability to reverse and forward engineer databases, then the team needs to establish guidelines
     for managing the transformation and engineering processes. The development team must define the points in the
     development of the application (build-and-release cycle) at which it will be appropriate to perform the class-to-table
     transformations and to forward-engineer the database. Once the initial database is created, the development team must
     define guidelines for the team to manage the synchronization of the PDM and database as the design and code of the
     system evolve throughout the project.
 </p><!-- END:mainDescription,-XMbxFU8M85cRlf3C4iwAGw -->
 </body>
 </html>
	<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
	<!-- VERSION rmc:7.1.0 -->
	<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
	<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
	<!-- START NON-TRANSLATABLE -->
	<title>\openup_basic\guidances\guidelines\data_modeling.xmi</title>
	</head>
	<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
	<body>
	Element Name: data_modeling.xmi<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: presentationName<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:presentationName,_ienXEEyAEdu-df7p0PuRvQ CRC: 754925525 -->Physical Data Modeling<!-- END:presentationName,_ienXEEyAEdu-df7p0PuRvQ -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: briefDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:briefDescription,_ienXEEyAEdu-df7p0PuRvQ CRC: 828844106 -->A physical data model (PDM) captures the design of a persistent data store such as a relational database or data file. Data modeling is the act of creating such a model.<!-- END:briefDescription,_ienXEEyAEdu-df7p0PuRvQ -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: mainDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:mainDescription,-XMbxFU8M85cRlf3C4iwAGw CRC: 2725241037 --><h3>
	Overview
	</h3>
	Physical data models (PDMs) are used to design the structure of a persistent data store. Typically a PDM is created for a
	single data store, although sometimes a PDM will cover several related data stores (this is particularly true when the data
	storage mechanism is file based). The assumption in this guideline is that you are modeling the schema of a single
	relational database.
	<h3>
	The Data Model in OpenUP
	</h3>
	The PDM is part of the Work Product: Design. It’s described as different views or perspectives of a portion of the design.
	<h3>
	Data Model Types
	</h3>
	<p dir="ltr" style="MARGIN-RIGHT: 0px">
	Traditionally, there are three types of data models:
	</p>
	<ol>
	<li>
	<div style="MARGIN-RIGHT: 0px">
	Conceptual. A conceptual model, also referred to as a domain model, depicts the critical business entities and
	the relationships between them.
	</div>
	</li>
	<li>
	<div style="MARGIN-RIGHT: 0px">
	Logical. A logical data model (LDM) adds detail, in particular data attributes and more entities. LDMs will
	optionally indicate candidate keys (one or more attributes of an entity which uniquely identify it) of an
	entity. LDMs describe how the design of the system handles the data that will be actually maintained in the
	PDM.
	</div>
	</li>
	<li>
	<div style="MARGIN-RIGHT: 0px">
	<p>
	Physical. A PDM depicts the table structure (in the case of a relational database design), the
	relationships between the tables, and the primary and foreign keys implemented by the tables. PDMs
	potentially indicate views, stored procedures, and other database elements.
	</p>
	</div>
	</li>
	</ol>
	<p>
	For systems built using object and/or component-based technology, the LDM is usually not created in favor of a class
	model.
	</p>
	<h4 style="MARGIN-RIGHT: 0px">
	Physical Data Modeling
	</h4>
	<p>
	The PDM consists of the detailed database table designs and their relationships. The tables in the PDM have
	well-defined columns, as well as keys and indexes as needed. The tables might also have triggers defined as necessary
	to support the database functionality and referential integrity of the system. In addition to the tables, stored
	procedures have been created, documented, and associated with the database in which the stored procedure will reside.
	</p>
	<p>
	The diagram below shows an example of some of the elements of a PDM. A UML-based notation is used, although other
	notations such as “crow's feet” or Information Engineering (IE) are also common. This example model is a part of the
	PDM of a fictional order entry system. It depicts three tables (Order, OrderItem, and Item), three stored procedures
	(GetOrders, GetTotalBusiness, and TestDatabase), and a trigger on Order named deleteOrderItems. The figure also depicts
	the columns of each table, the primary key for each table, and any foreign keys to other tables.
	</p>
	<p>
	<strong>Example Physical Data Model</strong>
	</p>
	<p>
	<img height="309" alt="" src="./resources/PDMSample.JPG" width="597" />
	</p>
	<p>
	An existing database can be reverse-engineered to populate the PDM if the team has access to a tool that can transform
	a database into a model.
	</p>
	<h3>
	How to Model Database Schemas
	</h3>
	<p>
	Perform the following in an iterative manner:
	</p>
	<ol>
	<li>
	Identify tables. A table is similar conceptually to object-orientation’s concept of a class – a table contains a
	collection of rows of data whereas a class defines a collection of objects. A table could contain rows representing
	people, places, things, events, or concepts. Examples of tables include Customer, Order, and OrderItem.
	</li>
	<li>
	Identify columns. Each table has one or more columns. A column stores a single data attribute for each row. For
	example, the Customer table may have columns such as First Name and Surname. A column has a single data type, such
	as INT, DATETIME, or VARCHAR.
	</li>
	<li>
	Follow accepted modeling conventions. Your organization should have standards and guidelines applicable to data
	modeling, in particular naming conventions, that you should follow.
	</li>
	<li>
	Identify relationships between tables. In the real world entities have relationships with other entities. For
	example, customers PLACE orders, customers LIVE AT addresses, and line items ARE PART OF orders. These
	relationships will exist between the rows of data stored in the corresponding tables.
	</li>
	<li>
	Assign keys. A key is one or more columns that uniquely identify a row in a table. A primary key is the preferred
	key for a table. For example, the Customer table may have two potential keys, CustomerID and SocialSecurityNumber.
	You could choose to use CustomerID as the primary key, thereby making SocialSecurityNumber a secondary key. Foreign
	keys are used to maintain relationships between rows.
	</li>
	<li>
	Normalize to reduce data redundancy. Data normalization is a process in which columns within a PDM are organized to
	increase the cohesion of tables. In other words, the goal of data normalization is to reduce and even eliminate
	data redundancy, an important consideration for application developers because it is incredibly difficult to store
	objects in a relational database that maintains the same information in several places.
	</li>
	<li>
	De-normalize to improve performance. Normalized data schemas, when put into production, often suffer from
	performance problems. An important part of data modeling is to de-normalize portions of the data schema, to
	increase data redundancy by storing the same information in several places or manners, to improve database access
	times.
	</li>
	</ol>
	<h3>
	Data Modeling Throughout the Lifecycle
	</h3>
	<h4>
	Inception Phase
	</h4>
	<p>
	During the Inception phase the goal is to identify high-level requirements for the system so that the scope may be
	identified and project funding obtained. Little, if any, data modeling is performed at this point although some
	conceptual modeling may occur. Detailed data models are usually not needed at this point.
	</p>
	<h4>
	Elaboration Phase
	</h4>
	<p>
	The goal of the Elaboration phase is to eliminate technical risk and to produce a stable (baselined) architecture for
	the system. One of several architectural issues that is likely to arise is data architecture. To support this effort,
	you will need to model the major database structures (tables, indexes, and primary and foreign key columns) and then
	create the database schema from the model (ideally it would be generated from a modeling tool).
	</p>
	<p>
	Additionally, representative data volumes may be loaded into the database to support performance testing. Based on the
	results of performance testing, the PDM might need to be adjusted with optimization techniques, including but not
	limited to de-normalizing, optimizing physical storage attributes, or distribution and indexing.
	</p>
	<h4>
	Construction Phase
	</h4>
	<p>
	During the Construction phase the goal is to build a working system that is ready to be released. During each
	iteration the design, implementation, and tests are fleshed out to implement that iteration's requirements.
	In other words development artifacts, including your data-oriented artifacts, evolve over time. To support data model
	changes you may discover the need to refactor your existing database schema.
	</p>
	<h4>
	Transition Phase
	</h4>
	<p>
	The PDM is maintained during the Transition phase in response to approved change requests. You should keep the PDM
	synchronized with the database as the application goes through final acceptance test and is deployed into production.
	</p>
	<h3>
	Round-trip Engineering Considerations
	</h3>
	<p>
	If a development team is using modern visual modeling tools that have the ability to convert classes to tables (and
	vice versa) or has the ability to reverse and forward engineer databases, then the team needs to establish guidelines
	for managing the transformation and engineering processes. The development team must define the points in the
	development of the application (build-and-release cycle) at which it will be appropriate to perform the class-to-table
	transformations and to forward-engineer the database. Once the initial database is created, the development team must
	define guidelines for the team to manage the synchronization of the PDM and database as the design and code of the
	system evolve throughout the project.
	</p><!-- END:mainDescription,-XMbxFU8M85cRlf3C4iwAGw -->
	</body>
	</html>