1. Database Design
DB Chapter 5
J.G. Zheng
June 29th 2005

2. Overview Entity Relationship Modeling Transforming ERD into tables
Data modeling using Entity Relationship Diagram (ERD)
Transforming ERD into tables

3. Introduction/Review Design is a process Analysis (Logical) design
Requirements (user view)
Conceptual modeling (ERD)
(Logical) design
Transforming ERD to tables and keys
Physical design and implementation
Using MS Access
Analysis: conceptual design
Transforming ERD: logical design

4. Entity-Relationship Model
A model to represent the real world
Elements
Entities
Attributes
Identifiers
Relationships
For ER Model, refer to the book on page

5. Entity Entity Entity class (entity set) Entity instance
Anything in the real world
Entity class (entity set)
A set of things of the same type
Entity instance
An exact instance of an entity class
ERD notation for entity
A rectangular box
Books

6. Attribute and Identifier
Properties of entity
Notation: an oval
Identifier
An attribute with unique value to identify each instance
Title
Books
ISBN
Price

7. Relationship Notation: a diamond Degree of relationship
Unary (recursive) – only 1 entity
Binary – 2 entities
Ternary – 3 entities
N-ary – more entities
Books
Publishers
publish

8. Types of Binary Relationship
One-to-One (1:1)
A single entity instance in one entity class is related to a single entity instance in another entity class
Examples:
Governors : States
Students : PantherCards
ER Notation (Crow’s foot)
Governors
States
govern

9. Types of Binary Relationship
One-to-Many (1:N)
A single entity instance in one entity class (parent) is related to multiple entity instances in another entity class (child)
Examples
Customers : Orders
Students : Degrees
ER Notation (Crow’s foot)
Books
Publishers
publish

10. Types of Binary Relationship
Many-to-Many (N:M)
Each entity instance in one entity class is related to multiple entity instances in another entity class; and vice versa
Examples
Books : Writers
Customers : Banking Accounts
ER Notation (Crow’s foot)
Books
Authors
write

11. Cardinality Cardinality Maximum cardinalities (types of relationships)
Describes participation in the relationship
Figure 5.43 on page 423
Maximum cardinalities (types of relationships)
Minimum cardinalities
Optional (zero) or Mandatory (one)
Certificates
Programmers
have

12. A Complete ER Example

13. ER Diagram Exercise Draw a ERD about movie data
Let’s only consider the following entities and their attributes
Perfomers: PerformerID, FirstName, LastName, Gender
Movies: MovieID, Title, Maker, Year
MovieMakers(companies): MakerID, Name
Assumptions
A movie has at least one actor/actress
An actor/actress does not have to be in any movie
A movie is made by only one company
Pick someone to draw his/her diagram;
Collect all drawings

14. Transforming ER to Tables
Guidelines to create tables
Each entity becomes a relation (table)
Attributes of the entity become fields of that table
Identifier becomes primary key
Rules to transform relationships
Based on the type of the relationship
One-to-One
One-to-Many
Many-to-Many

15. Transforming 1:1 Relationships
One-to-One
The key from one relation is placed in the other as a foreign key
LockerDesc
Location
LockerID
Locker
EmpName
EmpID
Employee
Foreign Key
Primary Key

16. Transforming 1:1 Relationships
Usually, it does not matter which table receives the foreign key
EmpID
LockerDesc
Location
LockerID
Locker
EmpName
Employee
Foreign Key
Primary Key
Generally there is no direction consideration; some times needs to consider minimum cardinality (foreign key is placed at the mandatory side)
In an One-to-One relationship, two tables may be collapsed into one table
Why?
Why not?

17. Transforming 1:N Relationships
One-to-Many
The primary key from the “One” side is placed in the “Many” side as a foreign key
The foreign key is always on the “Many” side
Instructor
InstructorID
FirstName
Office
Department
CourseSection
CRN
Semester
CourseID
Time
If not, there will be redundancy issues
TaughtBy

18. Transforming 1:N Relationships
Another example
Department
Employee
has
DeptName
Location
DeptID
Department
Dept
EmpName
EmpID
Employee
Foreign Key
Primary Key

19. Transforming N:M Relationships
Many-to-Many
There is no direct way to map many to many relationships
To represent an M:N relationship, a table is created (intersection table) for the relationship
Sometimes this intersection table is meaningful, sometimes it’s not.
Orders
Parts
OrderItems

20. Transforming N:M Example
Orders
OrderNum
OrderDate
CustomerNum
OrderItems
OrderNum
PartNum
NumOrdered
Parts
PartNum
Description
Class
Price
1:N
N:1
Many-to-Many is designed as two One-to-Many relationships
Create an intersection table with the primary key from each original table as foreign keys
The intersection table usually has a composite primary key

21. M:N Relationship Exercise
MovieId
PerformerId
Movies
Performers
Cast
FirstName
Title
Create tables based on this diagram
Character
LastName
Length
Gender

22. Database Design Language (DBDL)
Customers (CustomerID, FirstName, LastName, Address, SSN, …)
AK SSN
Orders (OrderNumber, OrderDate, Orderby, ShippingMethod, …)
FK Orderby  Customers
Data structure diagram notation
TABLE(PrimaryKey, Attribute1, Attribute2, ForeignKey, …)

23. IDEF1X
Understand Figure 5.2 on page 384

24. Review Question
Given the entities SUPPLIER and PRODUCT are one-to-many relationship, which of the following would represent the correct table design?
PRODUCT (ProductID, Description, Cost) SUPPLIER (SupplierID, ContactName, PhoneNumber) FK ProductID  PRODUCT
PRODUCT (ProductID, Description, Cost, SupplierID) FK SupplierID  SUPPLIER SUPPLIER (SupplierID, ContactName, PhoneNumber, ProductID) FK ProductID  PRODUCT
PRODUCT (ProductID, Description, Cost, ContactName) FK ContactName  SUPPLIER SUPPLIER (SupplierID, ContactName, PhoneNumber)
PRODUCT (ProductID, Description, Cost, SupplierID) FK SupplierID  SUPPLIER SUPPLIER (SupplierID, ContactName, PhoneNumber)

25. Summary E-R diagram is used widely for database design
Remember the rules to transform ERD to actual tables and relationships
One to one
One to many
Many to many