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

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 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

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 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

13. 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
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. 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
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
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. 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. 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

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

48. Figure 6-14. Fully Normalized ERD
SAD/CHAPTER 6 - END -

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.
SAD/CHAPTER 6

50. Chapter 6
End of Chapter