1

Database Application
SAK 3408

CHAPTER 2
DATABASE DESIGN
 Learning Objectives (W3)
2

 Describe the database design phases.

 Explain on how to construct E-R diagram.
 Transform ERD into Relation.
 Use normalization to decompose a relation with
anomalies into well-structured relations.
 Relation
3

 Definition: A relation is a named, two-dimensional table of

data
 Table is made up of rows (records), and columns (attribute or field)
 Not all tables qualify as relations
 Requirements:
 Every relation has a unique name.
 Every attribute value is atomic (not multivalued, not composite)
 Every row is unique (can’t have two rows with exactly the same
values for all their fields)
 Attributes (columns) in tables have unique names
 The order of the columns is irrelevant
 The order of the rows is irrelevant
 What is atomic value?
4

 This mean that in your table, for every row-by-column

position (cell), there exists only one value - not an
array or list of values:

OrderID CustID Date Items

1 4 4/11/02 5 Pencils, 3 Erasers, 6 Rulers

2 23 6/11/02 1 Scissor

3 15 7/11/02 2 Pen, 2 Notebook

4 2 7/11/02 15 5" Magazine File

5 23 7/11/02 1 Stapler

6 2 8/11/02 5 Kingston USB Flash Drive 8GB

 Is this a relation?
5

OrderID CustID Date Quantity Items

1 4 4/11/02 5 Pencils

1 4 4/11/02 3 Erasers

1 4 4/11/02 6 Rulers

2 23 6/11/02 1 Scissor

3 15 7/11/02 2 Pen

3 15 7/11/02 2 Notebook

4 2 7/11/02 15 5" Magazine File

5 23 7/11/02 1 Stapler

6 2 8/11/02 5 Kingston USB Flash Drive 8GB

 Example
6

DEPT_NO MANAGER_NO EMP_NO EMP_NAME

D101 12345 20000 Carl Sagan

20001 Magic Johnson
20002 Larry Bird

D102 13456 30000 Jimmy Carter

30001 Paul Simon
 …and now, is this a relation?
7

Dept_No Manager_No Emp_No Emp_Name

D101 12345 2000 Carl Sagan

D101 12345 2001 Magic Johnson
D101 12345 2002 Larry Bird
D102 13456 3000 Jimmy Carter
D102 13456 30001 Paul Simon
 Correspondence with ER Model
8

 Relations (tables) correspond with entity types

and with many-to-many relationship types
 Rows correspond with entity instances and with
many-to-many relationship instances
 Columns correspond with attributes
 Key
9

 Keys are special fields that serve two main purposes:

 Primary keys are unique identifiers of the relation in
question. Examples include employee numbers, social
security numbers, etc. This is how we can guarantee that all
rows are unique
 Foreign keys are identifiers that enable a dependent relation
(on the many side of a relationship) to refer to its parent
relation (on the one side of the relationship)
 Keys can be simple (a single field) or composite
(more than one field)
 Keys usually are used as indexes to speed up the
response to user queries.
 Transforming E-R into Relations
10

Step 1: Mapping Regular Entities to Relations

1. Simple attributes: E-R attributes map directly onto the
relation
2. Composite attributes: Use only their simple,
component attributes
3. Multi-valued Attribute - Becomes a separate relation
with a foreign key taken from the superior entity
 Figure 2.12 Mapping a regular entity

(a) CUSTOMER entity

type with simple
attributes

(b) CUSTOMER relation

{Customer_ID, Customer_Name, Custome_Address}

 Figure 2.13 Mapping a composite attribute

(a) CUSTOMER entity

type with composite
attribute

(b) CUSTOMER relation with address detail

Figure 2.14 Mapping a multivalued attribute
(a)

Multivalued attribute becomes a separate relation with foreign key

(b)

1 – to – many relationship between original entity and new relation

 Transforming E-R into Relations
14

Step 2: Mapping Weak Entities

 Becomes a separate relation with a
foreign key taken from the superior entity
 Primary key composed of:
 Partial identifier of weak entity
 Primary key of identifying relation (strong
entity)
Figure 2.15 Mapping a weak entity

(a) Weak entity DEPENDENT

(b) Relations resulting from weak entity

NOTE: the domain

constraint for the foreign key
should NOT allow null value
if DEPENDENT is a weak
entity

Foreign key

Composite primary key

 Transforming E-R into Relations
17

Step 3: Mapping Binary Relationships

 One-to-Many - Primary key on the one side
becomes a foreign key on the many side
 Many-to-Many - Create a new relation with the
primary keys of the two entities as its primary key
 One-to-One - Primary key on the mandatory side
becomes a foreign key on the optional side
Figure 2.16 mapping a 1:M relationship

(a) Relationship between customers and orders

(b) Mapping the relationship

Again, no null value in the

foreign key…this is because
of the mandatory minimum
cardinality

Foreign key
 Figure 2.17 Mapping M:N relationship

(a) ER diagram (M:N)

The Supplies relationship will need to become a separate relation

(b) Three resulting relations

Composite primary key

New
intersection
Foreign key relation

Foreign key
Figure 2.18 Mapping a binary 1:1 relationship

(a) Binary 1:1 relationship

(b) Resulting relations
 Transforming E-R into Relations
24

Step 4: Mapping Associative Entities

 Identifier Not Assigned
 Default primary key for the association relation is
composed of the primary keys of the two entities (as in M:N
relationship)
 Identifier Assigned
 It is natural and familiar to end-users
 Default identifier may not be unique
 Figure 2.19 Mapping an associative entity

(a) Associative entity

(b) Three resulting relations
 Transforming E-R into Relations
27

Step 5: Mapping Unary Relationships

 One-to-Many - Recursive foreign key in the same
relation
 Many-to-Many - Two relations:
 One for the entity type
 One for an associative relation in which the
primary key has two attributes, both taken
from the primary key of the entity
 Figure 2.20 Mapping a unary 1:N relationship

(a) EMPLOYEE entity with

Manages relationship

(b) EMPLOYEE
relation with
recursive foreign
key
 Mapping a unary M:N relationship

29

(a) Bill-of-materials
relationships (M:N)

(b) ITEM and

COMPONENT
relations
 Transforming E-R into Relations
30

Step 6: Mapping Ternary (and n-ary)

Relationships
 One relation for each entity and one for the
associative entity
 Associative entity has foreign keys to each entity in
the relationship
Figure 2.21 Mapping a ternary relationship

(a) Ternary relationship with associative entity

(b) Mapping the ternary relationship

Remember that the primary key

MUST be unique
 Transforming E-R into Relations
33

Step 7: Mapping Supertype/Subtype

Relationships
 One relation for supertype and for each subtype
 Supertype attributes (including identifier and subtype
discriminator) go into supertype relation
 Subtype attributes go into each subtype; primary key of
supertype relation also becomes primary key of subtype
relation
 1:1 relationship established between supertype and each
subtype, with supertype as primary table
Figure 2.22 Supertype/subtype relationships

(a)
 (b) Mapping Supertype/subtype relationships to relations

35
 Exercise (1)
36

phone
 Exercise (2)
37
 Exercise (3)
38
 Exercise (4)
39
 Exercise (5)
40
 Exercise (6)
41

Name Graphics Sound

Name
Phone no

Rater rates Game by Developer

Name
Ability

Gameplay Platform
 Exercise (7)
42