Introduction to Databases Chapter 4: Designing a Database.

Introduction to Databases

Chapter 4: Designing a Database

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

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

Example: Converting 1-1 Binary Relationship

Example: Converting 1-1 Binary Relationship

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

• 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

• Solution 1:– Combine two entities into one table

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

• Solution 3:– Two separate tables– Salesperson Number as foreign key in

Office table

Example: Converting 1-M Binary Relationship

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

Example: Converting M-M Binary Relationship

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

Example: Converting M-M Binary Relationship

Example: Converting 1-1 Unary Relationship

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

Example: Converting 1-M Unary Relationship

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

Example: Converting M-M Unary Relationship

Example: Good Reading Bookstores

Example: Good Reading Bookstores

Example: Good Reading Bookstores

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

• Two types of input needed for data normalization process

1. List of all attributes to be incorporated in database, including intersection data attributes

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

Salesperson Entity Functional Dependencies

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

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

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

First Normal Form

Second Normal Form

Third Normal Form

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

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.

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