Chapter 6

Modeling the Data: Conceptual and Logical

Data Modeling

SAD/CHAPTER 6 2

Learning Objectives Understand the basic objectives of

conceptual and logical data modeling

Become familiar with the components of the ERD

Understand relationships and the concepts of degree, cardinality, and optionality

SAD/CHAPTER 6 3

Learning Objectives Learn the basic characteristics of a

good data model Understand the process of data

normalization and the concept of functional dependency

Understand when the normalization process may negatively impact actual system performance

SAD/CHAPTER 6 4

Objectives of Data Modeling Conceptual Data Model

Shows how the business world sees information.

Suppresses non-critical details to emphasize business rules and user objects.

Logical Data Model Mathematics of data sciences Conform to relational theory

SAD/CHAPTER 6 5

Entity Relationship Diagram Represents data entities

associated with a system or business environment, the relationship among those entities, and the specific attributes of both the entities and their relationships

SAD/CHAPTER 6 6

Figure 6-2. Basic Symbols for Constructing ERD

SAD/CHAPTER 6 7

Entities Represented by a rectangle on the

ERD Represent data which could be

people, places, objects, event, concepts, or whatever else an organization wishes to maintain data about.

SAD/CHAPTER 6 8

Entities Characteristics

It can be distinguished from all of the other entities in the business environment by some set of identifying characteristics or attributes.

It represents a class of things that can occur more than once within the business environment.

SAD/CHAPTER 6 9

Entities Entity type

A collection of entities that all share one or more common properties or attributes.

Entity instance Represents a single, unique

occurrence of a member of an entity type.

SAD/CHAPTER 6 10

Attributes Represented by an oval or ellipse

on the ERD A characteristic of an entity or a

relationship Example: The entity STUDENT

could be described by attributes such as NAME, ADDRESS, ID NUMBER, MAJOR, etc.

SAD/CHAPTER 6 11

Key Attributes An unique identifier of an entity Can be a single attribute, or group

of attributes Example: The entity PRODUCT

might be uniquely identified by a key PRODUCT ID

SAD/CHAPTER 6 12

Key Attributes Concatenated or Combination Key

More than one attribute is used to create a key for an instance

Candidate Key A candidate to become the primary

identifier Example: The entity STUDENT could

be uniquely identified by SSN, STUDENT ID, or E-MAIL ADDRESS

SAD/CHAPTER 6 13

Criteria for Selection

Explanation

Stability

Choose a candidate key that will not likely change its value over time. EXAMPLE: UNSTABLE STABLE NAME+ADDRESS EMPLOYEE_ID

Non-Null

Choose a candidate key that is always guaranteed to have a non-null value. EXAMPLE: POSSIBLE NULL NON-NULL PHONE_NO SSN

Non-Informational

Do not create intelligent keys that attempt to convey information via their structure. EXAMPLE: INFORMATIONAL NON-INFORMATIONAL 99XXX99XX 123456789 Location Color Shelf Class Code Code Code Code

Simplicity

Wherever feasible, consider using a single attribute primary key instead of a multi-attribute primary key. EXAMPLE: SINGLE ATTRIBUTE MULTI-ATTRIBUTE ITEM_NO+COLOR ITEM_CODE

Table 6-1. Criteria for Selecting a Primary Key From a List of Candidate Keys

SAD/CHAPTER 6 14

Multivalued Attributes Multiple values for a single entity

instance Example: the attribute TRAINING of

the entity EMPLOYEE can have more than one value at any given time

All multi-valued attributes must be transformed in a special manner during data normalization.

SAD/CHAPTER 6 15

Relationships Association between one or more

entities Relationship between STUDENT

and COURSE entities A STUDENT may be enrolled in zero,

one, or more COURSES, and a COURSE may be taken by zero, one, or more STUDENTS

SAD/CHAPTER 6 16

Figure 6-3. Typical Business Relationships between Two Entities

SAD/CHAPTER 6 17

Relationships Three basic characteristics of

complexity Cardinality Optionality Degree

SAD/CHAPTER 6 18

Cardinality and Optionality Cardinality

The number of instances of one entity to an instance of another entity

Optionality The degree to which a particular

relationship is mandatory or optional

SAD/CHAPTER 6 19

Cardinality / Optionality

Minimum Instances

Maximum Instances

Notation

Exactly 1 / Mandatory

1

1

One or More / Mandatory

1

Many (to n)

Zero or One / Optional

0

1

Zero, One, or Many / Optional

0

Many (to n)

Table 6-2. Cardinality and Optionality of Relationships

SAD/CHAPTER 6 20

Cardinality and Optionality One-to-one relationship One-to-many relationship Many-to-many relationship

SAD/CHAPTER 6 21

Figure 6-4. Examples of Various Relationship Complexities

SAD/CHAPTER 6 22

Relationship Degree The number of entities

participating in the relationship Unary Binary Ternary

SAD/CHAPTER 6 23

Relationship Degree Unary or recursive relationship:

relationship between unique instance of a single entity and has a degree value equal to one (Figure 6-5)

Binary relationship: a relationship with a degree equal to 2 (Figure 6-6)

Ternary relationship: a relationship with a degree value equal to 3 (Figure 6-7)

SAD/CHAPTER 6 24

Figure 6-5. Example of Common Unary Relationships

SAD/CHAPTER 6 25

Figure 6-6. Examples of Common Binary Relationships

SAD/CHAPTER 6 26

Figure 6-7. Example of a Ternary Relationship

SAD/CHAPTER 6 27

Associative Entities The existence of a many-to-many

relationship results in several attributes of the two entity types being closely related (Figure 6-8a).

An associative entity is created for the above situation (Figure 6-8b).

SAD/CHAPTER 6 28

Figure 6-8. Example of an Associative Entity

SAD/CHAPTER 6 29

Interpreting the ERD A simple set of rules can be

applied to insure that all relationships on an ERD are easy to translate into verbal form (Figure 6-9).

SAD/CHAPTER 6 30

Figure 6-9. General Syntax for Reading Relationships

SAD/CHAPTER 6 31

General Procedure for Identifying Entities and their Relationships

Question Category Description Determine System Entities

Find out what types of people, business units, things, places, events, materials, or other organizations are associated with, or interact with, the system and about which data must be maintained.

Identify Entity Attributes

Identify the characteristics by which each entity is associated or identified with.

Determine Entity Keys

Identify the most appropriate characteristic for each entity that uniquely distinguishes an instance of that entity from all other instances of the same entity.

Determine Relationships and Degrees

Identify the various events, transactions, or other business activities that infer an association between entities.

Determine Cardinalities and Optionalities

Identify the circumstances under which each of the relationships can occur. This requires an investigation into the various business rules under which the organization operates and the constraints imposed on the events which occur within the business environment.

SAD/CHAPTER 6 32

Logical Data Modeling Formal structuring of the data into a

more stable and desirable form through a process called normalization

Development of a data model to accurately reflect the actual data needs

Development of a data model that allows for the construction of a physical database design

SAD/CHAPTER 6 33

Characteristics of a Good Data Model

Characteristic Explanation Pictorial A good data model should be an accurate graphical depiction

of the entities and their relationships

Rigorous and Specific

A good data model should be specific with regard to the identification of all entities and their relationships and rigorous in the identification and specification of the attributes associated with each entity.

Top-down Decomposable

A good data model should be decomposable in the sense that the level of detail for each entity and its associated attributes can be investigated at various levels of detail or aggregation.

Provide Focus A good data model should be focused on the data associated

with a single system and contained within a single system boundary.

Minimally Redundant A good data model will display minimal redundancy with regard to repeated entity types, data redundancy, and many-to-many relationships.

Transparent The actual data and the physical structure of the database

should be discernable from looking at the graphical data model.

Easily Navigated A good data model should be laid out in an organized fashion to allow for the relationships among the entities to be easily followed.

Predicts the Final System

A good data model should be an accurate prediction of the physical implementation of the system.

SAD/CHAPTER 6 34

The Relational Data Model Organize data using tables called

relations Relation: a two-dimensional table of

data Each table consists of named

columns and unnamed row

SAD/CHAPTER 6 35

Student_ID Student_Name Student_ Major

Student_FinAid

Student_ Status

279265487 Mark O’Broek Business Stafford Active

301658974 Sam Waterson Chemistry None Active

105455531 Margaret Delaney Music None Graduated

230987413 Susan Santana Anthropology Pell Active

726521324 Christine Lorenzo Business BAT fellowship Inactive

STUDENT(Student_ID, Student_Name,Student_Major,Student_FinAid,Student_Status)

Table 6-5. Example of a Relation for STUDENT

SAD/CHAPTER 6 36

Data Normalization Organize data attributes in the

logical data model so that they are grouped in a stable and flexible manner.

Based on the functional dependence concept.

SAD/CHAPTER 6 37

Functional Dependency Relationship between two

attributes For any relation R, attribute B is

functionally dependent on attribute A if, for every valid instance of A, that value of A uniquely determines the value of B.

SAD/CHAPTER 6 38

Normal Form Description

 First Normal Form (1NF) 

 A relation is in 1NF if it contains no repeating data elements.

 Second Normal Form (2NF) 

 A relation is in 2NF if it is in 1NF and contains no partial functional dependencies.

 Third Normal Form (3NF) 

 A relation is in 3NF if it is in 2NF and contains no transitive dependencies.

Table 6-6. The Three Common Normalized Forms

SAD/CHAPTER 6 39

First Normal Form (1NF) Contains no repeating elements

any entity that contains one or more multivalued attributes must be transformed

Figure 6-10

SAD/CHAPTER 6 40

Figure 6-10. The Three Common Normalized Forms

SAD/CHAPTER 6 41

Second Normal Form (2NF) A relation is in 1NF and it contains

no partial functional dependencies. Partial functional dependency

exists when one or more of the nonkey attributes can be defined by less than the full primary key.

SAD/CHAPTER 6 42

Figure 6-11. Second Normal Form

SAD/CHAPTER 6 43

Third Normal Form (3NF) A relation is in 2NF and no

transitive dependencies exist. Transitive Dependency: when one or

more nonkey attributes can be derived from one or more other nonkey attributes

SAD/CHAPTER 6 44

Figure 6-12. Third Normal Form

SAD/CHAPTER 6 45

The fully Normalized ERD Shows all the entities, their

attributes, and their relationships to all other entities.

From the logical data model, the physical model of the database can be easily constructed.

SAD/CHAPTER 6 46

Denormalization The normalized set of relations

may actually create certain potential inefficiencies in the final database.

Denormalization addresses performance problem associated with stable, normalized relations.

SAD/CHAPTER 6 47

Figure 6-13. Example of Denormalization

SAD/CHAPTER 6 - END - 48

Figure 6-14. Fully Normalized ERD

SAD/CHAPTER 6 49

Chapter Summary The relational model is already

evolving to include object technologies and features and should be quite capable of meeting the increased demands for object-oriented design approaches.

Chapter 6

End of Chapter