1

The Relational Data Model

TablesSchemas

Conversion from E/R to RelationsFunctional Dependencies

2

A Relation is a Table

name manfWinterbrew Pete’sBud Lite Anheuser-

BuschBeers

Attributes(columnheaders)

Tuples(rows)

3

Schemas

Relation schema = relation name and attribute list. Optionally: types of attributes. Example: Beers(name, manf) or

Beers(name: string, manf: string) Database = collection of relations. Database schema = set of all

relation schemas in the database.

4

Why Relations?

Very simple model. Often matches how we think about

data. Abstract model that underlies SQL,

the most important database language today.

5

From E/R Diagrams to Relations

Simplest approach (not always best): convert each E.S. to a relation and each relationship to a relation.

Entity Set RelationE.S. attributes become relational attributes.

Becomes:Beers(name, manf)

Beers

name manf

6

Keys in Relations

An attribute or set of attributes K is a key for a relation R if we expect that in no instance of R will two different tuples agree on all the attributes of K.

Indicate a key by underlining the key attributes.

Example: If name is a key for Beers:Beers(name, manf)

7

E/R Relationships Relations

Relation has attribute for key attributes of each E.S. that participates in the relationship.

Add any attributes that belong to the relationship itself.

Renaming attributes OK. Essential if multiple roles for an E.S.

8

Relationship -> Relation

Drinkers BeersLikes

Likes(drinker, beer)Favorite

Favorite(drinker, beer)

Married

husband

wife

Married(husband, wife)

name addr name manf

Buddies

1 2

Buddies(name1, name2)

For one-one relation Married, we can choose either husband or wife as key.

9

Combining Relations

OK to combine into one relation:1. The relation for an entity-set E 2. The relations for many-one

relationships of which E is the “many.” Example: Drinkers(name, addr) and

Favorite(drinker, beer) combine to make Drinker1(name, addr, favBeer).

10

Risk with Many-Many Relationships

Combining Drinkers with Likes would be a mistake. It leads to redundancy, as:

name addr beerSally 123 Maple BudSally 123 Maple Miller

Redundancy

11

Handling Weak Entity Sets

Relation for a weak E.S. must include its full key (i.e., attributes of related entity sets) as well as its own attributes.

A supporting (double-diamond) relationship yields a relation that is actually redundant and should be deleted from the database schema.

12

Example

Logins HostsAt

name name

Hosts(hostName, location)Logins(loginName, hostName, billTo)At(loginName, hostName, hostName2)

Must be the same

billTo

At becomes part ofLogins

location

13

Subclasses: Three Approaches

1. Object-oriented : One relation per subset of subclasses, with all relevant attributes.

2. Use nulls : One relation; entities have NULL in attributes that don’t belong to them.

3. E/R style : One relation for each subclass: Key attribute(s). Attributes of that subclass.

14

Example

Beers

Ales

isa

name manf

color

15

Object-Oriented

name manfBud Anheuser-Busch

Beers

name manf colorSummerbrew Pete’s dark

Ales

Good for queries like “find thecolor of ales made by Pete’s.”

16

E/R Stylename manfBud Anheuser-BuschSummerbrew Pete’s

Beers

name colorSummerbrew dark

Ales

Good for queries like“find all beers (includingales) made by Pete’s.”

17

Using Nulls

name manf colorBud Anheuser-Busch NULLSummerbrew Pete’s dark

Beers

Saves space unless there are lotsof attributes that are usually NULL.

18

Functional Dependencies

Meaning of FD’sKeys and Superkeys

Inferring FD’s

19

Functional Dependencies

X -> A is an assertion about a relation R that whenever two tuples of R agree on all the attributes of X, then they must also agree on the attribute A. Say “X -> A holds in R.” Convention: …, X, Y, Z represent sets of

attributes; A, B, C,… represent single attributes.

Convention: no set formers in sets of attributes, just ABC, rather than {A,B,C }.

20

Example

Drinkers(name, addr, beersLiked, manf, favBeer)

Reasonable FD’s to assert:1. name -> addr2. name -> favBeer3. beersLiked -> manf

21

Example Data

name addr beersLiked manf favBeerJaneway Voyager Bud A.B. WickedAleJaneway Voyager WickedAle Pete’s WickedAleSpock Enterprise Bud A.B. Bud

Because name -> addr Because name -> favBeer

Because beersLiked -> manf

22

FD’s With Multiple Attributes

No need for FD’s with > 1 attribute on right. But sometimes convenient to combine

FD’s as a shorthand. Example: name -> addr and

name -> favBeer become name -> addr favBeer

> 1 attribute on left may be essential. Example: bar beer -> price

23

Keys of Relations

K is a superkey for relation R if K functionally determines all of R.

K is a key for R if K is a superkey, but no proper subset of K is a superkey (Minimality)

24

Example

Drinkers(name, addr, beersLiked, manf, favBeer)

{name, beersLiked} is a superkey because together these attributes determine all the other attributes. name -> addr favBeer beersLiked -> manf

25

Example, Cont.

{name, beersLiked} is a key because neither {name} nor {beersLiked} is a superkey. name doesn’t -> manf; beersLiked

doesn’t -> addr. There are no other keys, but lots of

superkeys. Any superset of {name, beersLiked}.

26

E/R and Relational Keys

Keys in E/R concern entities. Keys in relations concern tuples. Usually, one tuple corresponds to

one entity, so the ideas are the same.

But --- in poor relational designs, one entity can become several tuples, so E/R keys and Relational keys are different.

27

Example Data

name addr beersLiked manf favBeerJaneway Voyager Bud A.B. WickedAleJaneway Voyager WickedAle Pete’s WickedAleSpock Enterprise Bud A.B. Bud

Relational key = {name beersLiked}But in E/R, name is a key for Drinkers, and beersLiked is a key

for Beers.Note: 2 tuples for Janeway entity and 2 tuples for Bud entity.

28

Where Do Keys Come From?

1. Just assert a key K. The only FD’s are K -> A for all

attributes A.

2. Assert FD’s and deduce the keys by systematic exploration.

E/R model gives us FD’s from entity-set keys and from many-one relationships.

29

More FD’s From “Physics” or Organization Policy

Example: “no two courses can meet in the same room at the same time” tells us: hour room -> course.

30

Inferring FD’s

We are given FD’s X1 -> A1, X2 -> A2,…, Xn -> An , and we want to know whether an FD Y -> B must hold in any relation that satisfies the given FD’s. Example: If A -> B and B -> C hold, surely

A -> C holds, even if we don’t say so. Important for design of good relation

schemas.

31

Inference Testthis is important because … When we talk about improving relational

designs, we often need to ask “does this FD hold in this relation?”

Given FD’s X1 A1, X2 A2,…, Xn An, does FD

Y B necessarily hold in the same relation?

Start by assuming two tuples agree in Y. Use given FD’s to infer other attributes on which they

must agree. If B is among them, then yes, else no.

32

Closure Test

An easier way to test is to compute the closure of Y, denoted Y +.

Basis: Y + = Y. Induction: Look for an FD’s left side

X that is a subset of the current Y +. If the FD is X -> A, add A to Y +.

33

Y+new Y+

X A

34

Closure Test -- Example

A B, BC D. A+ = AB. C+=C. (AC)+ = ABCD.

AC

B

D

35

Given Versus Implied FD’s

Typically, we state a few FD’s that are known to hold for a relation R.

Other FD’s may follow logically from the given FD’s; these are implied FD’s.

We are free to choose any basis for the FD’s of R – a set of FD’s that imply all the FD’s that hold for R.

36

Finding All Implied FD’s Motivation: “normalization,” the process

where we break a relation schema into two or more schemas.

Suppose we have a relation ABCD with some FD’s F. If we decide to decompose ABCD into ABC and AD, what are the FD’s for ABC, AD?

Example: F = AB C, C D, D A. It looks like just AB C holds in ABC, but in fact

C A follows from F and applies to relation ABC.

38

Basic Idea

1. Start with given FD’s and find all nontrivial FD’s that follow from the given FD’s.

trivial = right side member of left side.• A -> A or AB ->A

2. Restrict to those FD’s that involve only attributes of the projected schema.

39

Simple, Exponential Algorithm

1. For each set of attributes X, compute X +.

2. Add X ->A for all A in X + - X.3. However, drop XY ->A if X ->A holds.

Because XY ->A follows from X ->A .

4. Finally, use only FD’s involving projected attributes.

40

A Few Tricks

No need to compute the closure of the empty set or of the set of all attributes.

If we find X + = all attributes, so is the closure of any superset of X.

41

Example

ABC with FD’s A ->B and B ->C. Project onto AC. A +=ABC ; yields A ->B, A ->C.

• We do not need to compute AB + or AC +.

B +=BC ; yields B ->C. C +=C ; yields nothing. BC +=BC ; yields nothing.

42

Example --- Continued

Resulting FD’s: A ->B, A ->C, and B ->C.

Projection onto AC : A ->C. Only FD that involves a subset of {A,C

}.

43

ExampleRelation ABCD FDs: F = AB C, C D, D A. What

FD’s follow? A+ = A; B+=B (nothing). C+=ACD (add C A). D+=AD (nothing new). (AB)+=ABCD (add AB D; skip all supersets of AB). (BC)+=ABCD (nothing new; skip all supersets of BC). (BD)+=ABCD (add BD C; skip all supersets of BD). (AC)+=ACD; (AD)+=AD; (CD)+=ACD (nothing new). (ACD)+=ACD (nothing new). All other sets contain AB, BC, or BD, so skip. Thus, the only interesting FD’s that follow from F are:

C A, AB D, BD C.

44

Example 2

Set of FD’s in ABCGHI:

A BA CCG HCG IB H

Compute (CG)+, (BG)+, (AG)+

45

Example 3In ABC with FD’s A B, B C, project onto AC.1. A+ = ABC; yields A B, A C.2. B+ = BC; yields B C.3. AB+ = ABC; yields AB C; drop in favor of A

C.4. AC+ = ABC yields AC B; drop in favor of A

B.5. C+ = C and BC+ = BC; adds nothing. Resulting FD’s: A B, A C, B C. Projection onto AC: A C.