# Modeling the Data: Conceptual and Logical Data Modeling

## Presentation on theme: "Modeling the Data: Conceptual and Logical Data Modeling"— Presentation transcript:

Modeling the Data: Conceptual and Logical Data Modeling
Chapter 6 Modeling the Data: Conceptual and Logical Data Modeling

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

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

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

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

Figure 6-2. Basic Symbols for Constructing ERD

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

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

Entities Entity type Entity instance
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

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

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

Key Attributes Concatenated or Combination Key Candidate 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 ADDRESS SAD/CHAPTER 6

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

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

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

Figure 6-3. Typical Business Relationships between Two Entities

Relationships Three basic characteristics of complexity Cardinality

Cardinality and Optionality
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

Table 6-2. Cardinality and Optionality of Relationships

Cardinality and Optionality
One-to-one relationship One-to-many relationship Many-to-many relationship SAD/CHAPTER 6

Figure 6-4. Examples of Various Relationship Complexities

Relationship Degree The number of entities participating in the relationship Unary Binary Ternary SAD/CHAPTER 6

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

Figure 6-5. Example of Common Unary Relationships

Figure 6-6. Examples of Common Binary Relationships

Figure 6-7. Example of a Ternary Relationship

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

Figure 6-8. Example of an Associative Entity

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

Figure 6-9. General Syntax for Reading Relationships

General Procedure for Identifying Entities and their Relationships

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

Characteristics of a Good Data Model

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

Table 6-5. Example of a Relation for STUDENT

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

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

A relation is in 1NF if it contains no repeating data elements.
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

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

Figure 6-10. The Three Common Normalized Forms

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

Figure 6-11. Second Normal Form

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

Figure 6-12. Third Normal Form

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

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

Figure 6-13. Example of Denormalization