0% found this document useful (0 votes)
37 views44 pages

Chapter 04 Database Learning Skills

Database learning skills

Uploaded by

Don Seneca
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
37 views44 pages

Chapter 04 Database Learning Skills

Database learning skills

Uploaded by

Don Seneca
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 44

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

You might also like