1 relational model and translating er into relational

1

Relational Model and Translating ER into Relational

2

Lecture Outline

• Relational model

• Translating from ER to relational model

3

Motivations & comparison of ER with relational model ...

4

Database Modeling & Implementation

Database Model(E/R, ODL)

Database Model(E/R, ODL)

IdeasIdeas

Physicalstorage

Physicalstorage

Diagrams (E/R) Tables: column names: attributes rows: tuples

Complexfile organizationand index structures.

Relational Schema

Relational Schema

5

ER Model vs. Relational Model

• Both are used to model data

• ER model has many concepts– entities, relations, attributes, etc.– well-suited for capturing the app. requirements– not well-suited for computer implementation– (does not even have operations on its structures)

• Relational model– has just a single concept: relation– world is represented with a collection of tables– well-suited for efficient manipulations on computers

6

The basics of the relational model ...

7

An Example of a Relation

Name Price Category Manufacturer

gizmo $19.99 gadgets GizmoWorks

Power gizmo $29.99 gadgets GizmoWorks

SingleTouch $149.99 photography Canon

MultiTouch $203.99 household Hitachi

tuples

Attribute namesTable name

Products:

8

Domains• Each attribute has a type• Must be atomic type (why? see later)• Called domain • Examples:

– Integer– String– Real– …

9

Schemas vs. instances (very important, make sure you know

the difference)

10

SchemasThe Schema of a Relation:

– Relation name plus attribute names– E.g. Product(Name, Price, Category, Manufacturer)– In practice we add the domain for each attribute

The Schema of a Database– A set of relation schemas– E.g. Product(Name, Price, Category, Manufacturer),

Vendor(Name, Address, Phone), . . . . . . .

11

Instances• Relational schema = R(A1,…,Ak):

Instance = relation with k attributes (of “type” R)– values of corresponding domains

• Database schema = R1(…), R2(…), …, Rn(…)Instance = n relations, of types R1, R2, ..., Rn

12

Example

Name Price Category Manufacturer

gizmo $19.99 gadgets GizmoWorks

Power gizmo $29.99 gadgets GizmoWorks

SingleTouch $149.99 photography Canon

MultiTouch $203.99 household Hitachi

Relational schema:Product(Name, Price, Category, Manufacturer)Instance:

13

Annother Example

SSN Name Category 123-45-6789 Charles undergrad 234-56-7890 Dan grad … …

SSN CID 123-45-6789 CSE444 123-45-6789 CSE444 234-56-7890 CSE142 …

Students: Takes:

CID Name Quarter CSE444 Databases fall CSE541 Operating systems winter

Courses:

Three relational schemas here + three relational instances

One database schema + one database instance

14

Updates

The database maintains a current database state (that is, a database instance).

Updates to the data (that is, the database instance)

1) add a tuple 2) delete a tuple 3) modify an attribute in a tuple

Updates to the data happen very frequently.

Updates to the schema: relatively rare. Rather painful. Why?

15

Schemas and Instances

• Analogy with programming languages:– Schema = type– Instance = value

• Important distinction:– Database Schema = stable over long periods of time– Database Instance = changes constantly, as data is

inserted/updated/deleted

16

How should we talk about relations (that is, represent them)?

Will skip this in the classYou can read for fun

17

Two Mathematical Definitions of Relations

Relation as Cartesian product• Tuple = element of string x int x string x string• E.g. t = (gizmo, 19, gadgets, GizmoWorks)• Relation = subset of string x int x string x

string• Order in the tuple is important !

– (gizmo, 19, gadgets, GizmoWorks)

– (gizmo, 19 , GizmoWorks, gadgets)

• No attributes

18

Relation as a set of functions• Fix the set of attributes

– A={name , price, category, manufacturer}

• A tuple = function t:A Domains• Relation = set of tuples• E.g.

• Order in a tuple is not important• Attribute names are important

{name gizmo, price 19, category gadgets, manufacturer gizmoWorks}

{name gizmo, price 19, category gadgets, manufacturer gizmoWorks}

19

Two Definitions of Relations

• We will switch back and forth between these two:– Positional tuples, without attribute names– Relational schemas with attribute names

20

Now the fun part: translating from ER to relational model

21

Translating ER Diagram to Rel. Design

• Basic cases– entity set E = relation with attributes of E– relationship R = relation with attributes being keys of

related entity sets + attributes of R

• Special cases– combining two relations – translating weak entity sets– translating is-a relationships and subclasses

22

address name ssn

Person

buys

makes

employs

CompanyProduct

name category

Stock price

name

price

An Example

23

Basic cases ...

24

Entity Sets to Relations

Product

name category

price

Product:

Name Category Price

gizmo gadgets $19.99

25

Relationships to Relations

makes CompanyProduct

name category

Stock price

name

Relation Makes (watch out for attribute name conflicts) Product-name Product-Category Company-name Starting-year

gizmo gadgets gizmoWorks 1963

Start Year

price

26

Relationship to Relation: Another Example

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)

27

Special cases:1) many-one relations2) weak entity sets3) is-a cases

28

Combining Two Relations

makes CompanyProduct

name category

Stock price

name

No need for Makes. Just modify Product:

name category price StartYear companyName

gizmo gadgets 19.99 1963 gizmoWorks

Start Year

price

29

Combining Relations

• It is OK to combine the relation for an entity-set E with the relation R for a many-one relationship from E to another entity set.

• Example: Drinkers(name, addr) and Favorite(drinker, beer) combine to make Drinker1(name, addr, favoriteBeer).

30

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

31

Handling Weak Entity Sets

UniversityTeam affiliation

numbersport name

Relation Team:

Sport Number Affiliated University

mud wrestling 15 Montezuma State U.

- need all the attributes that contribute to the key of Team - don’t need a separate relation for Affiliation. (why ?)

32

Handling Weak Entity Sets

• Relation for a weak entity set must include attributes for its complete key (including those belonging to other entity sets), as well as its own, nonkey attributes.

• A supporting (double-diamond) relationship is redundant and yields no relation.

33

Another Example

Logins HostsAt

name name

Hosts(hostName)Logins(loginName, hostName, time)At(loginName, hostName, hostName2)

Must be the same

time

At becomes part ofLogins

34

Translating Subclass Entities

Product

Educational Product

SoftwareProduct

Educ-softwareProduct

ageGrouptopic

Platformsrequired memory

Educational-method

isa

isa

isa

isa

35

Option #1: the OO Approach

4 tables: each object can only belong to a single table Product(name, price, category, manufacturer)

EducationalProduct( name, price, category, manufacturer, ageGroup, topic)

SoftwareProduct( name, price, category, manufacturer, platforms, requiredMemory)

EducationalSoftwareProduct( name, price, category, manufacturer, ageGroup, topic, platforms, requiredMemory)All names are distinct

36

Option #2: the E/R Approach

Product(name, price, category, manufacturer)

EducationalProduct( name, ageGroup, topic)

SoftwareProduct( name, platforms, requiredMemory)

No need for a relation EducationalSoftwareProduct

Unless, it has a specialized attribute: EducationalSoftwareProduct(name, educational-method)

Same name may appear in several relations

37

Option #3: The Null Value Approach

Have one table:

Product ( name, price, manufacturer, age-group, topic, platforms, required-memory, educational-method)

Some values in the table will be NULL, meaning that the attribute not make sense for the specific product.

Too many meanings for NULL

38

Translating Subclass Entities: The RulesThree approaches:

1. Object-oriented : each entity belongs to exactly one class; create a relation for each class, with all its attributes.

2. E/R style : create one relation for each subclass, with only the key attribute(s) and attributes attached to that E.S.; entity represented in all relations to whose subclass/E.S. it belongs.

3. Use nulls : create one relation; entities have null in attributes that don’t belong to them.

39

Example

Beers

Ales

isa

name manf

color

40

Object-Oriented

name manfBud Anheuser-Busch

Beers

name manf colorSummerbrew Pete’s dark

Ales

41

E/R Style

name manfBud Anheuser-BuschSummerbrew Pete’s

Beers

name colorSummerbrew dark

Ales

42

Using Nulls

name manf colorBud Anheuser-Busch NULLSummerbrew Pete’s dark

Beers

43

Comparisons• O-O approach good for queries like “find the color of

ales made by Pete’s.”– Just look in Ales relation.

• E/R approach good for queries like “find all beers (including ales) made by Pete’s.”– Just look in Beers relation.

• Using nulls saves space unless there are lots of attributes that are usually null.

44

Translation Review

• Basic cases– entity to table, relation to table– selecting attributes based on keys

• Special cases– many-one relation can be merged– merging many-many is dangerous– translating weak entity sets– translating isa hierarchy

• 3 choices, with trade-offs