Chapter 6 Modeling the Data: Conceptual and Logical Data Modeling
Dec 19, 2015
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