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

54
DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

Post on 19-Dec-2015

217 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

DATABASE APPLICATION DEVELOPMENTSAK 3408

Database Design II(week 3)

Page 2: DATABASE APPLICATION DEVELOPMENT SAK 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.

Page 3: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

SAK3408 by PSS (W3)

Answer :Simple

Customer VideoBorrow

Page 4: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

SAK3408 by PSS (W3)

Answer : Advance ?

Customer VideoBorrow

Cus_ID

Add

PhoneNo

Vid_ID

Title

Price

D_Borrow

1 N

Page 5: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

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.

Page 6: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

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.

Page 7: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

SAK3408 by PSS (W3)

Example: Good

Cars ManfsManfBy

name

This design gives the address of each manufacturer exactly once.

name addr

Page 8: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

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

Page 9: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

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

Page 10: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

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.

Page 11: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

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

Page 12: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

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

Page 13: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

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

Page 14: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

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.

Page 15: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

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.

Page 16: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

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.

Page 17: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

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.

Page 18: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

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 ???

Page 19: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

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

Page 20: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

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.

Page 21: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

SAK3408 by PSS (W3)

Example

Customer VideoBorrow

Cus_ID

Add

PhoneNoCus_ID Add PhoneNo

CUSTOMER

CUSTOMER(Cus_ID, Add, PhoneNo)Primary KeyPrimary Key

Page 22: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

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

Page 23: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

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)

Page 24: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

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

Page 25: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

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

Page 26: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

SAK3408 by PSS (W3)

(a) CUSTOMER entity type with simple attributes

Figure 2.12 Mapping a regular entity

(b) CUSTOMER relation

Page 27: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

SAK3408 by PSS (W3)

(a) CUSTOMER entity type with composite attribute

Figure 2.13 Mapping a composite attribute

(b) CUSTOMER relation with address detail

Page 28: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

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)

Page 29: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

SAK3408 by PSS (W3)

Figure 2.15 Mapping a weak entity

(a) Weak entity DEPENDENT

Page 30: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

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

Page 31: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

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

Page 32: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

SAK3408 by PSS (W3)

Figure 2.18 Mapping a binary 1:1 relationship

(a) Binary 1:1 relationship

Page 33: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

SAK3408 by PSS (W3)

(b) Resulting relations

Page 34: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

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

Page 35: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

SAK3408 by PSS (W3)

Figure 2.16 mapping a 1:M relationship

(a) Relationship between customers and orders

Page 36: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

SAK3408 by PSS (W3)

(b) Mapping the relationship

Foreign key

Page 37: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

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

Page 38: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

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

Page 39: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

SAK3408 by PSS (W3)

(b) Three resulting relations

New intersection

relationForeign key

Foreign key

Composite primary key

Page 40: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

SAK3408 by PSS (W3)

STEP 6 (Multivalued attributes)

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

Page 41: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

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)

Page 42: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

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

Page 43: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

SAK3408 by PSS (W3)

Figure 2.21 Mapping a ternary relationship

(a) Ternary relationship with associative entity

Page 44: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

SAK3408 by PSS (W3)

(b) Mapping the ternary relationship

Remember that the primary key MUST be

unique

Page 45: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

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

Page 46: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

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

Page 47: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

SAK3408 by PSS (W3)

Mapping a unary M:N relationship

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

(b) ITEM and COMPONENT relations

Page 48: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

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

Page 49: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

SAK3408 by PSS (W3)

Figure 2.19 Mapping an associative entity

(a) Associative entity

Page 50: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

SAK3408 by PSS (W3)

(b) Three resulting relations

Page 51: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

SAK3408 by PSS (W3)

Practice I

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

Page 52: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

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

Page 53: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

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

Page 54: DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

SAK3408 by PSS (W3)

Recalled : Teaching Plan W3

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

… to be continued…