CS 180: Database Systems - Lecture Notes (Weeks 2-3), Study notes of Database Management Systems (DBMS)

These lecture notes from cs 180 cover topics related to weak entity sets, entity-relationship design, and the relational model. The concept of weak entity sets, their representation, and when they are necessary. It also includes examples of weak entity sets and their relationships with other entities. Additionally, it discusses design principles for creating a database schema and the difference between entity sets and attributes.

Typology: Study notes

Pre 2010

Uploaded on 08/19/2009

koofers-user-xcj
koofers-user-xcj 🇺🇸

10 documents

1 / 16

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Winter 2002 Arthur Keller – CS 180 2–1
Schedule
Today: Jan. 8 (T)
Weak Entity Sets, Entity-Relationship Design.
Read Sections 2.3-2.4.
Jan. 10 (TH)
Relational Model, Functional Dependencies.
Read Sections 3.1-3.5.
Jan. 15 (T)
Normal Forms, Multivalued Dependencies.
Read Sections 3.6-3.7. Assignment 1 due.
Jan. 17 (TH)
Relational Algebra.
Read Chapter 5. Project Part 1 due.
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff

Partial preview of the text

Download CS 180: Database Systems - Lecture Notes (Weeks 2-3) and more Study notes Database Management Systems (DBMS) in PDF only on Docsity!

Winter 2002

Arthur Keller – CS 180

2–

Schedule

-^

Today: Jan. 8 (T)^ ◆

Weak Entity Sets, Entity-Relationship Design. ◆

Read Sections 2.3-2.4.

-^

Jan. 10 (TH)^ ◆

Relational Model, Functional Dependencies. ◆

Read Sections 3.1-3.5.

-^

Jan. 15 (T)^ ◆

Normal Forms, Multivalued Dependencies. ◆

Read Sections 3.6-3.7. Assignment 1 due.

-^

Jan. 17 (TH)^ ◆

Relational Algebra. ◆

Read Chapter 5. Project Part 1 due.

Winter 2002

Arthur Keller – CS 180

2–

Weak Entity Sets

Sometimes an E.S.

E

’s key comes not (completely) from its own

attributes, but from the keys of one or more E.S.’s to which

E

is

linked by a

supporting

many-one relationship.

•^

Called a

weak

E.S.

•^

Represented by putting double rectangle around

E

and a double

diamond around each supporting relationship.

-^

Many-one-ness of supporting relationship (includes 1-1)essential.^ ◆

With many-many, we wouldn't know which entity provided the key value.

-^

“Exactly one” also essential, or else we might not be able toextract key attributes by following the supporting relationship.

Winter 2002

Arthur Keller – CS 180

2–

Example: Chain of “Weakness”

Consider IP addresses consisting of a primary domain(e.g.,

edu

), subdomain (e.g.,

ucsc

), and host (e.g.,

soe

-^

Key for primary domain = its name.

-^

Key for secondary domain = its name + name of primarydomain.

-^

Key for host = its name + key of secondary domain = itsname + name of secondary domain + name of primarydomain.

2ndaryDomains

PrimaryDomains

@In

name

name

Hosts

@In

name

Winter 2002

Arthur Keller – CS 180

2–

All “Connecting”

Entity SetsAre Weak

  • In this special case, where bar and beer determine

a price, we can omit

price

from the key, and

remove the double diamond from

ThePrice

.

  • Better:

price

is attribute of

BBP

.

Bars

Beers

The-Bar

Beers

The-Beer

The-Price

BBPBBP

The-Bar

The-Beer

The-Price

name

manf

name

addr

price

Winter 2002

Arthur Keller – CS 180

2–

-^

Solution: make Ordered into a weak entity set.

-^

And then add Shipment.

Buyer

Product

Qty

Buyer

Product

Shipment

Name

UPC

Name

UPC

ID

Ordered

OBOB

OPOP

Qty Ordered

Ordered

OBOB

OPOP

Part of

Qty Shipped

Part-of ismany-many andnot a weakrelationship!

Winter 2002

Arthur Keller – CS 180

2–

Design Principles

Setting: client has (possibly vague) idea of what he/shewants. You must design a database that represents thesethoughts and only these thoughts.Avoid redundancy= saying the same thing more than once.•Wastes space and encourages inconsistency.ExampleGood:

Beers

Manfs

ManfBy

name

addr

name

Winter 2002

Arthur Keller – CS 180

2–

• The design

schema

should enforce as many

constraints as possible.^ ◆

Don't rely on future data to follow assumptions

Example• If registrar wants to associate only one

instructor with a course, don't allow sets ofinstructors and count on departments toenter only one instructor per course.

Use Schema to Enforce Constraints

Winter 2002

Arthur Keller – CS 180

2–

Entity Sets Vs. Attributes

You may be unsure which concepts are worthy of being entity

sets, and which are handled more simply as attributes.

-^

Especially tricky for the class design project, since there is atemptation to create needless entity sets to make project“larger.”

Wrong: Right:

Beers

Manfs

ManfBy

name

name

Beers name

manf

Winter 2002

Arthur Keller – CS 180

2–

Example

The following design illustrates both points:•^

Manfs

deserves to be an E.S. because we record

addr

, a

nonkey attribute.

-^

Beers

deserves to be an E.S. because it is at the “many” end.

◆^

If not, we would have to make “set of beers” an attribute of

Manfs

something we avoid doing, although some may tell you it is OK inE/R model.

Beers

Manfs

ManfBy

name

addr

name

Winter 2002

Arthur Keller – CS 180

2–

Don't Overuse Weak E.S.

•^

There is a tendency to feel that no E.S. has its entitiesuniquely determined without following somerelationships.

-^

However, in practice, we almost always create uniqueID's to compensate: social-security numbers, VIN's, etc.

-^

The only times weak E.S.'s seem necessary are when:a)^

We can't easily create such ID's; e.g., no one is going to accept a“species ID” as part of the standard nomenclature (species is aweak E.S. supported by membership in a genus). b)

There is no global authority to create them,

e.g

., crews and

studios.

Winter 2002

Arthur Keller – CS 180

2–

If There's Time…

Suppose we only need to have a vegetarian

choice for a given meal if there is at leastone vegetarian taking that meal. How wouldwe modify the database schema?