Introduction to Databases Copyright by John Wiley and Sons, 2006 Introduction to Databases Chapter 4: Designing a Database

Designing Relational Tables Copyright by John Wiley and Sons, 2006 Designing Relational Tables Typical process for converting E-R diagrams to relational tables: Each entity converts to table For many-to-many relationships, each associative entity converts to table Attributes become table columns Ensure foreign keys appear in proper places in tables To convert single entity, create table of same name with column for each attribute

Salesperson Entity and Table Copyright by John Wiley and Sons, 2006 Salesperson Entity and Table

Converting Binary Relationships Copyright by John Wiley and Sons, 2006 Converting Binary Relationships Greater importance in selecting identifier and primary key Identifier and primary key define foreign key that establishes relationships between tables Often more than one way to represent entity relationships as relational tables

Example: Converting 1-1 Binary Relationship Copyright by John Wiley and Sons, 2006 Example: Converting 1-1 Binary Relationship

Example: Converting 1-1 Binary Relationship Copyright by John Wiley and Sons, 2006 Example: Converting 1-1 Binary Relationship

Example: Converting 1-1 Binary Relationship Copyright by John Wiley and Sons, 2006 Example: Converting 1-1 Binary Relationship

Example: Converting 1-1 Binary Relationship Copyright by John Wiley and Sons, 2006 Example: Converting 1-1 Binary Relationship Converting one-to-one Salesperson/Office relationship Options: Convert relationship to single/combined table Convert relationship to two tables

Example: Converting 1-1 Binary Relationship Copyright by John Wiley and Sons, 2006 Example: Converting 1-1 Binary Relationship Considerations: Business environment considers Salesperson and Office as separate entities Modality of zero at Salesperson entity in E-R diagram (office may have no one assigned) Salesperson entity in E-R diagram has relationships with other entities

Example: Converting 1-1 Binary Relationship Copyright by John Wiley and Sons, 2006 Example: Converting 1-1 Binary Relationship Solution 1: Combine two entities into one table

Example: Converting 1-1 Binary Relationship Copyright by John Wiley and Sons, 2006 Example: Converting 1-1 Binary Relationship Solution 2: Two separate tables Office Number as foreign key in Salesperson table

Example: Converting 1-1 Binary Relationship Copyright by John Wiley and Sons, 2006 Example: Converting 1-1 Binary Relationship Solution 3: Two separate tables Salesperson Number as foreign key in Office table

Example: Converting 1-M Binary Relationship Copyright by John Wiley and Sons, 2006 Example: Converting 1-M Binary Relationship

Example: Converting 1-M Binary Relationship Copyright by John Wiley and Sons, 2006 Example: Converting 1-M Binary Relationship Each occurrence of Salesperson is related to zero or more occurrences of Customer Unique identifier of entity on “one” side is placed as foreign key in entity of “many” side

Example: Converting 1-M Binary Relationship Copyright by John Wiley and Sons, 2006 Example: Converting 1-M Binary Relationship

Example: Converting M-M Binary Relationship Copyright by John Wiley and Sons, 2006 Example: Converting M-M Binary Relationship

Example: Converting M-M Binary Relationship Copyright by John Wiley and Sons, 2006 Example: Converting M-M Binary Relationship Most relational DBMS systems do not directly support many-to-many relationships Solution: Include associative entity to establish relationship May use composite key as primary key in associative entity

Example: Converting M-M Binary Relationship Copyright by John Wiley and Sons, 2006 Example: Converting M-M Binary Relationship

Example: Converting M-M Binary Relationship Copyright by John Wiley and Sons, 2006 Example: Converting M-M Binary Relationship

Example: Converting 1-1 Unary Relationship Copyright by John Wiley and Sons, 2006 Example: Converting 1-1 Unary Relationship

Example: Converting 1-1 Unary Relationship Copyright by John Wiley and Sons, 2006 Example: Converting 1-1 Unary Relationship With: Only one entity type involved, and One-to-one relationship Conversion requires only one table

Example: Converting 1-M Unary Relationship Copyright by John Wiley and Sons, 2006 Example: Converting 1-M Unary Relationship

Example: Converting 1-M Unary Relationship Copyright by John Wiley and Sons, 2006 Example: Converting 1-M Unary Relationship

Example: Converting M-M Unary Relationship Copyright by John Wiley and Sons, 2006 Example: Converting M-M Unary Relationship Many-to-many unary relationship: For example: one product can be constructed out of set or subset of other products General rule in conversion: Number of tables equal to number of entity types plus one more table for many-to-many relationship M-M unary relationship - 2 tables M-M binary relationship - 3 tables M-M ternary relationship - 4 four tables

Example: Converting M-M Unary Relationship Copyright by John Wiley and Sons, 2006 Example: Converting M-M Unary Relationship

Example: Converting M-M Unary Relationship Copyright by John Wiley and Sons, 2006 Example: Converting M-M Unary Relationship

Example: Good Reading Bookstores Copyright by John Wiley and Sons, 2006 Example: Good Reading Bookstores

Example: Good Reading Bookstores Copyright by John Wiley and Sons, 2006 Example: Good Reading Bookstores

Example: Good Reading Bookstores Copyright by John Wiley and Sons, 2006 Example: Good Reading Bookstores

Copyright by John Wiley and Sons, 2006 Normalizing Data Data normalization: Methodology for organizing attributes into tables to eliminate redundancy among nonkey attributes Goals: Each resultant table describes single entity type or single many-to-many relationship Foreign keys appear exactly where needed Properly structured relational database

Normalization Techniques Copyright by John Wiley and Sons, 2006 Normalization Techniques Two types of input needed for data normalization process List of all attributes to be incorporated in database, including intersection data attributes List of functional dependencies: all defining associations between attributes In functional dependencies, one attribute (determinate attribute) defines value of another attribute Salesperson Number → Salesperson Name

Salesperson Entity Attributes Copyright by John Wiley and Sons, 2006 Salesperson Entity Attributes

Salesperson Entity Functional Dependencies Copyright by John Wiley and Sons, 2006 Salesperson Entity Functional Dependencies

Example: Defining Attributes and Functional Dependencies Copyright by John Wiley and Sons, 2006 Example: Defining Attributes and Functional Dependencies Quantity is defined by two combined attributes Manager is defined independently by two attributes Department Number and Salesperson Number Salesperson Number also defines Department Number

Copyright by John Wiley and Sons, 2006 Normalizing Data Normal forms: Rules for data normalization Three main normal forms First normal form Second normal form Third normal form Normalization: Uses normal forms to step through “decomposition process” that decomposes attributes into subgroups In third normal form, group of tables is well-structured relational database with no data redundancy

Copyright by John Wiley and Sons, 2006 Normalizing Data First normal form: Eliminates multiple values Second normal form: Eliminates partial functional dependencies (data dependent on part of primary key) Every nonkey attribute must be fully functionally dependent on entire key of table Third normal form: Eliminates transitive dependencies (one nonkey attribute is functionally dependent on another) Nonkey attributes are not allowed to define other nonkey attributes

Example: Unnormalized Data Copyright by John Wiley and Sons, 2006 Example: Unnormalized Data

Copyright by John Wiley and Sons, 2006 First Normal Form

Copyright by John Wiley and Sons, 2006 Second Normal Form

Copyright by John Wiley and Sons, 2006 Third Normal Form

Copyright by John Wiley and Sons, 2006 Denormalizing Data Denormalizing may be needed when: Normalization has been taken to extreme Too many small tables creating more work and storage space E.g. Using State table to be referenced instead of entering two-digit code) More efficient data retrieval is needed: Many queries requiring resource-intensive joining In denormalizing, you join two or more tables into one less normalized table

Copyright by John Wiley and Sons, 2006 Summary In converting E-R diagrams to relational tables, each entity typically converted into table, with attributes as table columns. Considerations in conversion: Business needs, cardinalities, modalities, and defining foreign keys to establish relationships. Normalization: Uses three main normal forms to step through “decomposing” attributes into subgroups that allow data redundancies to be eliminated. Denormalizing may be needed in cases where storage space and speed of data retrieval are important factors.

Copyright by John Wiley and Sons, 2006 Key Terms Composite key Data integrity Data normalization Decomposition process Defining association Determinant attribute Exception conditions First normal form Functional dependency Joining Non-loss decomposition Normal forms Null value Partial functional dependency Referential integrity Relational integrity Second normal form Third normal form (3NF) Transitive dependency

Copyright by John Wiley and Sons, 2006 Copyright Notice Copyright 2008 John Wiley & Sons, Inc. All rights reserved. Reproduction or translation of this work beyond that permitted in section 117 of the 1976 United States Copyright Act without express permission of the copyright owner is unlawful. Requests for further information should be addressed to the Permissions Department, John Wiley & Sons, Inc. The purchaser may make back-up copies for his/her own use only and not for distribution or resale. The Publisher assumes no responsibility for errors, omissions, or damages caused by the use of these programs or from the use of the information herein.