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

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 E-MAIL ADDRESS SAD/CHAPTER 6

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

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

Relationships Three basic characteristics of complexity Cardinality Optionality Degree SAD/CHAPTER 6

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

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

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

Figure 6-6. Examples of Common Binary Relationships SAD/CHAPTER 6

Figure 6-7. Example of a Ternary Relationship SAD/CHAPTER 6

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

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

General Procedure for Identifying Entities and their Relationships SAD/CHAPTER 6

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

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

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

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

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

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

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

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

Chapter 6 End of Chapter