database application development sak 3408 database design ii (week 3)

DATABASE APPLICATION DEVELOPMENTSAK 3408

Database Design II(week 3)

SAK3408 by PSS (W3)

Try

Construct an E-R diagram for a video rental store that has a set of customer that can borrows one or more cars.

SAK3408 by PSS (W3)

Answer :Simple

Customer VideoBorrow

SAK3408 by PSS (W3)

Answer : Advance ?

Customer VideoBorrow

Cus_ID

Add

PhoneNo

Vid_ID

Title

Price

D_Borrow

1 N

SAK3408 by PSS (W3)

Design Techniques

1. Avoid redundancy.2. Limit the use of weak entity sets.3. Don’t use an entity set when an

attribute will do.

SAK3408 by PSS (W3)

Avoiding Redundancy

Redundancy = saying the same thing in two (or more) different ways.

Wastes space and (more importantly) encourages inconsistency. Two representations of the same fact

become inconsistent if we change one and forget to change the other.

Recall anomalies due to FD’s.

SAK3408 by PSS (W3)

Example: Good

Cars ManfsManfBy

name

This design gives the address of each manufacturer exactly once.

name addr

SAK3408 by PSS (W3)

Example: Bad

Cars ManfsManfBy

name

This design states the manufacturer of a beer twice: as an attribute and as a related entity.

name

manf

addr

SAK3408 by PSS (W3)

Example: Bad

Cars

name

This design repeats the manufacturer’s address once for each beer and loses the address if there are temporarily no beers for a manufacturer.

manf manfAddr

SAK3408 by PSS (W3)

Entity Sets Versus Attributes

An entity set should satisfy at least one of the following conditions:

It is more than the name of something; it has at least one nonkey attribute.

or It is the “many” in a many-one or

many-many relationship.

SAK3408 by PSS (W3)

Example: Good

Cars ManfsManfBy

name

•Manfs deserves to be an entity set because of the nonkey attribute addr.•Cars deserves to be an entity set because it is the “many” of the many-one relationship ManfBy.

name addr

SAK3408 by PSS (W3)

Example: Good

Cars

name

There is no need to make the manufacturer an entity set, because we record nothing about manufacturers besides their name.

manf

SAK3408 by PSS (W3)

Example: Bad

Cars ManfsManfBy

name

Since the manufacturer is nothing but a name, and is not at the “many” end of any relationship, it should not be an entity set.

name

SAK3408 by PSS (W3)

Don’t Overuse Weak Entity Sets

Beginning database designers often doubt that anything could be a key by itself. They make all entity sets weak, supported

by all other entity sets to which they are linked.

In reality, we usually create unique ID’s for entity sets. Examples include social-security numbers,

automobile VIN’s etc.

SAK3408 by PSS (W3)

When Do We Need Weak Entity Sets?

The usual reason is that there is no global authority capable of creating unique ID’s.

Example: it is unlikely that there could be an agreement to assign unique player numbers across all football teams in the world.

SAK3408 by PSS (W3)

Practice I

Construct an ER diagram for a car-insurance company that has a set of customers, each of whom owns one or more cars. Each car has associated with it zero to any number of recorded accidents.

SAK3408 by PSS (W3)

Practice II

A database is being constructed to keep track of the teams and games of a football league. A team has a number of players, not all of whom participate in each game. It is desired to keep track of the players participating in each game for each team, the position they played in that game, and the result of the game. Design an ER schema for this application.

SAK3408 by PSS (W3)

What’s next ?

Converting our ER diagram into relational

Definition: A relation is a named, two-dimensional table of data Table is made up of rows (records), and

columns (attribute or field) However : Not all tables qualify as

relations ???

SAK3408 by PSS (W3)

Relation Requirement :

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

SAK3408 by PSS (W3)

How to map ER to Relation ?

Entity set -> relation. Attributes -> attributes.

Relationships -> relations whose attributes are only: The keys of the connected entity sets. Attributes of the relationship itself.

SAK3408 by PSS (W3)

Example

Customer VideoBorrow

Cus_ID

Add

PhoneNoCus_ID Add PhoneNo

CUSTOMER

CUSTOMER(Cus_ID, Add, PhoneNo)Primary KeyPrimary Key

SAK3408 by PSS (W3)

Key

Keys are special fields that serve two main purposes: Primary keys are unique identifiers of the relation.

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

SAK3408 by PSS (W3)

Primary Key

Foreign Key (implements 1:N relationship between customer and order)

Combined, these are a composite primary key (uniquely identifies the order line)…individually they are foreign keys (implement M:N relationship between order and product)

SAK3408 by PSS (W3)

ER-to Relational Mapping Algorithm

1. Mapping of regular entity types2. Mapping of weak entity types3. Mapping of Binary 1:1 relationship types4. Mapping of Binary 1:N relationship types5. Mapping of Binary M:N relationship types6. Mapping of Multivalued attributes 7. Associative Entities Mapping of N-ary

relationship types

SAK3408 by PSS (W3)

STEP 1(Regular entity types)

1. Simple attributes: E-R attributes map directly onto the relation

2. Composite attributes: Use only their simple, component attributes

SAK3408 by PSS (W3)

(a) CUSTOMER entity type with simple attributes

Figure 2.12 Mapping a regular entity

(b) CUSTOMER relation

SAK3408 by PSS (W3)

(a) CUSTOMER entity type with composite attribute

Figure 2.13 Mapping a composite attribute

(b) CUSTOMER relation with address detail

SAK3408 by PSS (W3)

STEP 2(Weak entity types)

Becomes a separate relation with a foreign key taken from the superior entity

Primary key composed of:Partial identifier of weak entityPrimary key of identifying relation

(strong entity)

SAK3408 by PSS (W3)

Figure 2.15 Mapping a weak entity

(a) Weak entity DEPENDENT

SAK3408 by PSS (W3)

(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

SAK3408 by PSS (W3)

STEP 3(Binary 1:1 Relationship Types)

One-to-One - Primary key on the mandatory side becomes a foreign key on the optional side

SAK3408 by PSS (W3)

Figure 2.18 Mapping a binary 1:1 relationship

(a) Binary 1:1 relationship

SAK3408 by PSS (W3)

(b) Resulting relations

SAK3408 by PSS (W3)

STEP 4(Binary 1:N Relationship Types)

One-to-Many - Primary key on the one side becomes a foreign key on the many side

SAK3408 by PSS (W3)

Figure 2.16 mapping a 1:M relationship

(a) Relationship between customers and orders

SAK3408 by PSS (W3)

(b) Mapping the relationship

Foreign key

SAK3408 by PSS (W3)

STEP 5(Binary M:N Relationship Types)

Many-to-Many - Create a new new relationrelation with the primary keys of the two entities as its primary key

SAK3408 by PSS (W3)

Figure 2.17 Mapping M:N relationship

(a) ER diagram (M:N)

The Supplies relationship will need to become a separate relation

SAK3408 by PSS (W3)

(b) Three resulting relations

New intersection

relationForeign key

Foreign key

Composite primary key

SAK3408 by PSS (W3)

STEP 6 (Multivalued attributes)

• Multi-valued Attribute - Becomes a separate relation with a foreign key taken from the superior entity

SAK3408 by PSS (W3)

Figure 2.14 Mapping a multivalued attribute

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

(a)

Multivalued attribute becomes a separate relation with foreign key

(b)

SAK3408 by PSS (W3)

STEP 7(N-aray Relationship Types)

One relation for each entity and one for the associative entity

Associative entity has foreign keys to each entity in the relationship

SAK3408 by PSS (W3)

Figure 2.21 Mapping a ternary relationship

(a) Ternary relationship with associative entity

SAK3408 by PSS (W3)

(b) Mapping the ternary relationship

Remember that the primary key MUST be

unique

SAK3408 by PSS (W3)

Additional step : Unary Relationship

One-to-Many - Recursive foreign key in the same relation

Many-to-Many - Two relations:One for the entity typeOne for an associative relation in

which the primary key has two attributes, both taken from the primary key of the entity

SAK3408 by PSS (W3)

Figure 2.20 Mapping a unary 1:N relationship

(a) EMPLOYEE entity with Manages relationship

(b) EMPLOYEE relation with recursive foreign key

SAK3408 by PSS (W3)

Mapping a unary M:N relationship

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

(b) ITEM and COMPONENT relations

SAK3408 by PSS (W3)

Addition step : 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

SAK3408 by PSS (W3)

Figure 2.19 Mapping an associative entity

(a) Associative entity

SAK3408 by PSS (W3)

(b) Three resulting relations

SAK3408 by PSS (W3)

Practice I

Use your previous ERD from the car insurance company and build the relation

SAK3408 by PSS (W3)

Practice II

BANK

CUSTOMER

LOANACCOUNT

BANK_BRANCH

CodeName

Amount

Type Loan_no

BalanceAcct_no

Branch_noAddrAddr

Phone

NameAddr

NoKP

Type

BRANCHES

L_CA_C

LOANSACCTS

SAK3408 by PSS (W3)

Correspondence between ER and Relational Model

ER Model Relational Model

Entity type “Entity” relation

1:1 or 1:N relationship type Foreign key or “Relationship” relation

M:N relationship type “Relationship” relation and two foreign keys

N-ary relationship type “Relationship” relation and two foreign keys

Simple attribute Attribute

Composite attribute Set of simple component attributes

Multivalued attribute Relation and foreign key

Key attribute Primary key

SAK3408 by PSS (W3)

Recalled : Teaching Plan W3

Transforming ERD into Relations Data normalization (1NF, 2NF, 3NF)

… to be continued…