ER to Tables

7/27/2019 ER to Tables

1/39

+

Database Design:

Conceptual Model to

Logical Model (ERdiagrams to tables)


2/39

+Database Design Process

IS 257Fall 2006

Conceptual

Model

Logical

Model

External

Model

Conceptual

requirements

Conceptual

requirements

Conceptual

requirements

Conceptual

requirements

Application 1

Application 1

Application 2 Application 3 Application 4

Application 2

Application 3

Application 4

External

Model

External

Model

External

Model

Internal

Model


3/39

+Developing a Conceptual Model

Overall view of the database that integrates allthe needed information discovered during therequirements analysis.

Elements of the Conceptual Model arerepresented by diagrams, Entity-Relationship orER Diagrams, that show the meanings andrelationships of those elements independent ofany particular database systems orimplementation details.

Can also be represented using other modelingtools (such as UML)


4/39

+Developing a Conceptual Model

We looked at the bus transportation system

We identified key scenarios

Limited our scope

Made our initial ER diagram Identified Entities

Indicated relevant attributes

Specified unique identifiers

Worked out relationships between entities (& cardinality)

Still to do:

Still needs to be integrated

May be full of flaws!

IS 257Fall 2006


5/39

+Normalization of ER Diagram

(expand repeating attributes)

DiveOrdsOrdersDiveCust

Customer No ship

ShipVia

Order No

Ship Via

DiveItemRepeating

attribute

Customer No


6/39

+Normalization

DiveCust Orders

Customer No

DiveOrds

Ship

ShipVia

Order No

Ship Via

DiveItemContains

Item No

QtyOrder No

Customer No

Rental/sale


7/3910/1/2013

Some ER

Diagram

Styles


8/3910/1/2013

Crow's Feet Notation is as follows:

Cardinality: maximum (1 or many)

Modality: minimum (0 or 1)


9/39

+

Notation used in the following slides http://www.philblock.info/hitkb/i/interpreting_entity-

relationship_diagrams.html

10/1/2013
http://www.philblock.info/hitkb/i/interpreting_entity-relationship_diagrams.htmlhttp://www.philblock.info/hitkb/i/interpreting_entity-relationship_diagrams.htmlhttp://www.philblock.info/hitkb/i/interpreting_entity-relationship_diagrams.htmlhttp://www.philblock.info/hitkb/i/interpreting_entity-relationship_diagrams.htmlhttp://www.philblock.info/hitkb/i/interpreting_entity-relationship_diagrams.html


10/39

+ Chapter 7Logical

DatabaseDesign

Fundamentals of Database

Management Systemsby

Mark L. Gillenson, Ph.D.

University of Memphis

John Wiley & Sons, Inc.


11/39

+7-11

Chapter Objectives

Describe the concept of logical database design.

Design relational databases by converting entity-relationshipdiagrams into relational tables.

Describe the data normalization process.


12/39

+7-12

Chapter Objectives

Perform the data normalization process.

Test tables for irregularities using the data normalizationprocess.


13/39

+7-13

Logical Database Design

The process of deciding how to arrange the attributes of theentities in the business environment into database structures,such as the tables of a relational database.

The goal is to create well structured tables that properly reflectthe companys business environment.


14/39

+7-14

Logical Design of Relational

Database Systems

(1) The conversion of E-R diagrams into relational tables.

(2) The data normalization technique.

(3) The use of the data normalization technique to test the

tables resulting from the E-R diagram conversions.


15/39

+7-15

Converting E-R Diagrams into

Relational Tables

Each entity will convert to a table.

Each many-to-many relationship or associative entity willconvert to a table.

During the conversion, certain rules must be followed to ensurethat foreign keys appear in their proper places in the tables.


16/39

7-16

Converting a Simple Entity

The table simply contains the attributes that were specified inthe entity box.

Salesperson Number is underlined to indicate that it is theunique identifier of the entity and the primary key of the table.

Salesperson

Number

Salesperson

Name

Commission

Percentage Year of Hire

SALESPERSON


17/39

7-17

Converting Entities in Binary

Relationships: One-to-One

There are three options for designing tables to

represent this data.


18/39

7-18

One-to-One: Option #1

Salesperson

Number

Salesperson

Name

Commission

Percentage

Year

of

Hire

Office

Number Telephone Size

SALESPERSON/OFFICE

The two entities are

combined into one

relational table.


19/39

7-19


Separate tables for theSALESPERSON andOFFICE entities, withOffice Number as a

foreign key in theSALESPERSON table.

Salesperson

Number

Salesperson

Name

Commission

Percentage

Year of

Hire

Office

Number

SALESPERSON

Office


OFFICE


20/39

7-20


Separate tables for theSALESPERSON andOFFICE entities, withSalesperson Number as a

foreign key in the OFFICEtable.

Salesperson

Number

Salesperson

Name

Commission

Percentage

Year of

Hire

SALESPERSON

Office

Number Telephone

Salesperson

Number Size

OFFICE


21/39

7-21


Relationships: One-to-Many

The unique identifier of the entity on the one side of theone-to-many relationship is placed as a foreign key in the tablerepresenting the entity on themany side.

So, the Salesperson Number attribute is placed in theCUSTOMER table as a foreign key.


22/39

7-22



Salesperson

Number

Salesperson

Name

Commission


SALESPERSON

Customer

Number

Customer

Name HQ City

Salesperson

Number

CUSTOMER


23/39

7-23


Relationships: Many-to-Many

E-R diagram with the many-to-many binary

relationship and the equivalent diagram using an

associative entity.


24/39

+7-24



An E-R diagram with two entities in a many-to-manyrelationship converts to three relational tables.

Each of the two entities converts to a table with itsown attributes but with no foreign keys (regardingthis relationship).

In addition, there must be a thirdmany-to-manytable for the many-to-many relationship.


25/39

7-25



Salesperson

Number

Salesperson

Name

Commission


SALESPERSON

Product

Number

Product

Name Unit Price

PRODUCT

Salesperson

Number

Product

Number QuantitySALE

The primary key of SALEis the combination of theunique identifiers of thetwo entities in the many-

to-many relationship.Additional attributes arethe intersection data.

Product

Number

Product

Name Unit PricePRODUCT


26/39

7-26

Converting Entities in Unary

Relationships: One-to-One

Salesperson

Number

Salesperson

Name

Commission


Backup

NumberSALESPERSON

With only one entity typeinvolved and with a one-to-one relationship, theconversion requires only onetable.


27/39

7-27



Very similar to the one-to-one unary case.

Salesperson

Number

Salesperson

Name

Commission

Percentage Year of Hire Manager

SALESPERSON


28/39

7-28



Product

Number

Product

Name Unit Price

PRODUCT

This relationship requires two tables in theconversion.

The PRODUCT table has no foreign keys.

Product

Number

Sub-Assembly

Number Quantity

COMPONENT


29/39

7-29



Product

Number

Product

Name Unit Price

PRODUCT

A second table is created since in the conversion of amany-to-many relationship of any degree unary,

binary, or ternary the number of tables will be equal tothe number of entity types (one, two, or three,respectively) plus one more table for the many-to-manyrelationship.

Product

Number

Sub-Assembly

Number Quantity

COMPONENT


30/39

7-30

Converting Entities in

Ternary Relationships

Salesperson

Number

Salesperson

Name

Commission


SALESPERSON

The primary key of the SALEtable is the combination of theunique identifiers of the threeentities involved, plus the Dateattribute.

Customer

Number

Customer

Name HQ City

CUSTOMER

Product

Number

Product

Name Unit Price

PRODUCT

Salesperson

Number

Customer

Number

Product

Number Date QuantitySALE


31/39

7-31

Designing the

General Hardware

Company Database


32/39

7-32

Designing the General Hardware

Company Database

Salesperson

Number

Salesperson

Name

Commission


Office

Number

SALESPERSON

Customer

Number

Customer

Name

Salesperson

Number HQ City

CUSTOMER

Customer

Number

Employee

Number

Employee

Name Title

CUSTOMER EMPLOYEE

Product

Number

Product

Name Unit Price

PRODUCT

Salesperson

Number

Product

Number Quantity

SALES

Office


OFFICE


33/39

7-33

Designing the Good Reading

Bookstores Database


34/39

7-34

Designing the Good Reading

Bookstores Database

Publisher

Name City Country Telephone

Year

Founded

PUBLISHER

Author

Number

Author

Name

Year

Born

Year

Died

AUTHOR

Book

Number

Book

Name

Publication

Year Pages

Publisher

Name

BOOK

CustomerNumber

CustomerName Street City State Country

CUSTOMER

BookNumber

AuthorNumber

WRITING

Book

Number

Customer

Number Date Price Quantity

SALE


35/39

7-35

Designing the World Music Association

Database


36/39

7-36

Designing the World Music Association

Database

Orchestra

Name City Country

Music

Director

ORCHESTRA

Musician

Number

Musician

Name Instrument

Annual

Salary

Orchestra

Name

MUSICIAN

Musician

Number Degree University Year

DEGREE

Composer

Name Country

Date Of

Birth

COMPOSER

Composition

Name

Composer

Name Year

COMPOSITION

Orchestra

Name

Composition

Name

Composer

Name Year Price

RECORDING


37/39

7-37

Designing the

Lucky

Rent-A-CarDatabase


38/39

7-38

Designing the Lucky

Rent-A-Car DatabaseManufacturerName

ManufacturerCountry

Sales RepName

Sales RepTelephone

MANUFACTURER

Car Serial

Number Model Year Class

Manufacturer

Name

CAR

Repair

Number

Car Serial

Number Date Procedure Mileage

Repair

Time

MAINTENANCE

Customer

Number

Customer

Name

Customer

Address

Customer

Telephone

CUSTOMER

Car Serial

Number

Customer

Number

Rental

Date

Return

Date

Total

Cost

RENTAL


39/39

Documents

ER to Tables