Contents

Data Architect Professional database modeling

---

Chapter 10

Logical Model

About this chapter

This chapter describes and explains the Logical Model.

Purpose

The LM is an important vehicle used within the System Development Life Cycle (SDLC) to understand, document, and communicate key business elements of the system. A critical feature of the LM is that it is created without the encumbrances of any particular physical implementation.

Who

The LM is created by those who have business knowledge and technical knowledge. The person is usually senior and highly experienced. The LM is created by involving people, with experience within the system, to discuss and review the LM - ensuring that it accurately reflects the needs of the organization.

Examples of people who may be responsible for the creation of a LM;

• Business Analyst
• Database Analyst
• Database Designer
• Data Architect

When

The LM is created without regard to any potential physical implementation. This allows the LM to be started in the Study Phase of the SDLC with modifications continuing into the Design Phase. However; the LM should not be completed before the Database Managament System (DBMS) is determined. The LM is then used as input to the Physical Model.

Using The Logical Model

A Logical Model (LM) is a document object which extends Diagram.

The LM has the features of a Diagram and new features such as additional shapes. Refer to Diagram elsewhere in this manual to gain an understanding of a Diagram.

The primary element in a LM is the Entity shape. The Entity shape is used to represent any logical grouping of data in the system. The relationships between the various Entities are then depicted by connecting them with a special line called a Relationship. In this manner all data for the system, and their relationships become easy to; navigate, document, communicate, and analize.

The following is an example of a simple Logical Model;

Menu Options

The LM has its own popup menu which can be accessed by <right-clicking> on it in the browser. This menu can be used to load the document and bring the editor into view. This menu can also be used to Save the document and request that it be validated.

Editing Properties

Of particular interest are the; Domains, Data Items, and the Rules tabs. These tabs each contain a list of LM child objects which are not shapes - that is they are not drawn on the document. These child objects can be added and removed as desired using this properties dialog.

Unlike Diagram - a LM can have child objects which are not drawn on the document. These child objects are not shapes and are only shown in the browser and the LM properties dialog

Adding Shapes And Other Child Objects

Shapes are added in the exact same manner as detailed in the Diagram documentation. Other child objects are added using the LM properties dialog.

The following child objects are introduced in the LM;

Icon	Name	Shape
	Entity
	Relationship
	Association
	Association Link
	Inheritance Link
	Business Rule
	Domain
	Data Item

Manipulating Shapes And Other Child Objects

Shapes are manipulated in the same manner described in the Diagram documentation. Other child objects are manipulated by editing their properties and this can be done, for example, by invoking thier properties dialog from their popup menu in the browser.

Finding Shapes And Other Objects

Shapes can be found using the same technique detailed in the Diagram documentation. Other child objects will be searched along with the shapes and all results are listed in the Find tab of the output dock-window.

Business Rule

A Business Rule can be a company policy, an externally mandated regulation, etc which affects objects in the system. The rule is stated in text and is then associated with any number of relevant objects such as; entities, relationships, and attributes. Business Rules are an important mechanism to pass important information through the analysis, design and into the development phases of the SDLC.

A Business Rule is a LM child object but is not a shape so it is not represented on the document but, instead, can be found in the browser and in the LM properties dialog. The following is an example of a Business Rule properties dialog;

Domain

Domains are reusable data definitions. Domains should be considered whenever a specific data definition is frequently used. For example; it may be common to create data items with a VARCHAR(50) data definition. In this case a Domain could be created as a VARCHAR(50) and then the Domain could be used as the data definition for the data items. This not only makes specifying the data definition easier but it also makes changing it later easier as it only has to be changed in the one Domain and is automatically applied to all data items using the Domain.

A Domain is a LM child object but is not a shape so it is not represented on the document but, instead, can be found in the browser and in the LM properties dialog. The following is an example of a Domain properties dialog;

Data Item

A Data Item is a fundemental data element. Data Items will typically be used as entity attributes but exist outside of an entity to allow fundemental data elements to be documented without regard to the entity they may be used in. Later; when more is known about the system being modeled, the Data Item can be used by an entity attribute.

A Data Item is a LM child object but is not a shape so it is not represented on the document but, instead, can be found in the browser and in the LM properties dialog. The following is an example of a Data Item properties dialog;

Attribute

The Attribute is a data item contained within an Entity. The Attribute may be drawn within the Entity on the diagram. The Attribute has a name and a data type definition. The data type definition must accomodate all possible values during the life of the system.

Identifier:
An Attribute may be an identifier. Most Entities require some kind of primary identifier to uniquely identify each instance of an Entity. This may be one or more Attributes which are flagged as identifiers. One should think hard before leaving an Entity with no identifier. One may want to create an Attribute specificaly to be an identifier for an Entity which would otherwise lack one.
The best way to decide which Attributes (if any) are indentifier is to ask the following questions;
What are the minimum Attributes required to uniquely identify an instance of this Entity? Are these Attributes availible for all instances of the Entity?
One does not want to involve more Attributes then required and one should always consider all possible instances to ensure that the identifiers will always uniquely identify an instance.
Mandatory:
An Attribute value may be mandatory. It is important to communicate this into the Development Phase.

Entity

The Entity is a; person, place, thing or concept which is considered relevant to the system and about which data is stored. It is represented in a diagram by a simple box containing the entity name and, usually, a list of Entity Attributes. An Entity is used to represent a logical grouping of data. The following is an example of an Entity;


An Entity can have one or more attributes. Attributes are listed on the Entity shape and can be managed within the Entity properties dialog. The following is an example of the attributes tab of an Entity properties dialog;

Relationship

The Relationship indicates which entities share an important relationship to each other and contains details about that relationship. It is represented in a diagram by a line connecting the entities in question. The following is an example of a Relationship;

Important information about the Relationship is indicated on the line-ends of the Relationship. These indicators may seem to complicate the LM at first but it is important that the person creating the LM understand these indicators as they communicate critical information to be used in the Development Phase of the SDLC. The following table describes each; 

line-end	contribution	meaning	description
	1	mandatory	This entity contributes exactly 1 instance to the relationship.
	1-n*	many + mandatory	This entity may contribute at most, n, instances to this relationship. The entity will contribute at least 1 instance to the relationship.
	0-n	many + optional	This entity may contribute at most, n, instances to this relationship. This entity may contribute nothing to the relationship.
	0-1	optional	This entity may, or may not, contribute to this relationship but never more than 1 instance.

The following shows the Options tab of a Relationship properties dialog;

...

Association

An Association is a special type of entity which may be used to show a relationship between two other entities when the relationship itself contains data. The following is an example of an Association (TitleAuthor);
In the above example; a simple relationship would normally be made between Author and Title but because each instance of this relationship requires additional data (TitleAuthorOrder, TitleAuthorPercent ) a new entity is needed. But instead of just creating a new entity - an Association entity can be created. This is more accurate and will help the LM validate your model.

Inheritance

In the above example; Title is an existing entity but we have found that a Title can be a Periodical or a Nonperiodical. This would normally call for a flag of some sort in the entity to indicate this. But the complicating factor is that new attributes are need depending upon whether the Title is a Periodical or not. All of the new attributes could be added to the existing entity but this does not accurately reflect the system. The solution is to derive two new entities from Title and call them Nonperiodical and Periodical.

Creating a LM using Inheritance complicates the model but is probably more accurate. Also; if the target database  supports Inheritance any Physical Model generated from the LM will, optionally, contain inheritance.

Validation

The Validation strictness can be adjusted by specifiying the Level (Low, Medium, High) or by customizing the Value column of the table.

Working With Results

Validation results are sent to the Validation tab of the output dock-window. Each line will start with an icon indicating the severity level followed by some text indicating the problem. Like many output lines these are intelligent. <single-click> and <double-click> these lines to go to the source of the message.

---

Logical Model To Physical Model

The DBMS vendor and product are recommended at the end of the Study Phase of the SDLC and a recommendation is approved before the Development Phase starts. The Physical Model (PM) is created either as part of the recommendation or, more likely, during the start of the Development Phase. The important thing is that the PM can not be created until the LM is completed and a DBMS has been decided upon.

Data Architect can create a new PM from the LM. The PM can then be further edited to take into consideration any special DBMS features and optimizations.

Keeping the Logical Model and Physical Models seperate is important because;

• different people are responsible for them
• different skill sets go into them
• the original LM remains, unaltered, as the specification for the PM
  

---