Scribd
Upload
48 views

Database Chapter02-02

The document discusses the process of transforming an entity-relationship (E-R) diagram into relational database tables. It describes the steps to map different E-R constructs, such as entities, relationships, and attributes, into normalized relational structures. These steps include mapping regular entities and their attributes, weak entities, binary and unary relationships, associative entities, and superclass/subclass relationships. The goal is to breakdown the E-R diagram into well-structured relations without anomalies or violations of first normal form.

Uploaded by

rockers91
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
48 views

Database Chapter02-02

The document discusses the process of transforming an entity-relationship (E-R) diagram into relational database tables. It describes the steps to map different E-R constructs, such as entities, relationships, and attributes, into normalized relational structures. These steps include mapping regular entities and their attributes, weak entities, binary and unary relationships, associative entities, and superclass/subclass relationships. The goal is to breakdown the E-R diagram into well-structured relations without anomalies or violations of first normal form.

Uploaded by

rockers91
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 42

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 (cant 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

4/11/02

5 Pencils, 3 Erasers, 6 Rulers

23

6/11/02

1 Scissor

15

7/11/02

2 Pen, 2 Notebook

7/11/02

15 5" Magazine File

23

7/11/02

1 Stapler

8/11/02

5 Kingston USB Flash Drive 8GB

Is this a relation?
5

OrderID

CustID

Date

Quantity

Items

4/11/02

Pencils

4/11/02

Erasers

4/11/02

Rulers

23

6/11/02

Scissor

15

7/11/02

Pen

15

7/11/02

Notebook

7/11/02

15

5" Magazine File

23

7/11/02

Stapler

8/11/02

Kingston USB Flash Drive 8GB

Example
6

DEPT_NO

MANAGER_NO

EMP_NO

EMP_NAME

D101

12345

20000
20001
20002

Carl Sagan
Magic Johnson
Larry Bird

D102

13456

30000
30001

Jimmy Carter
Paul Simon

and now, is this a relation?


7

Dept_N
o

Manager_N
o

Emp_N
o

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.

2.

3.

Simple attributes: E-R attributes map directly onto


the relation
Composite attributes: Use only their simple,
component attributes
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

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 keythis 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
relation

Foreign key
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
It

Assigned

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

Game

rates

by

Developer

Name
Ability
Gameplay

Platform

Exercise (7)
42

You might also like