Subclasses, Keys, Weak Entity Sets Design Issues - Database Systems I | CS 610, Study notes of Deductive Database Systems

Download Subclasses, Keys, Weak Entity Sets Design Issues - Database Systems I | CS 610 and more Study notes Deductive Database Systems in PDF only on Docsity!

More Design Issues

1. Sub classes.
2. Keys.
3. Weak entity sets.

Sub classes

Sub class = sp ecial case = fewer entities = more prop erties.

 Example: Ales are a kind of b eer. In addition to the properties (= attributes and relationships) of b eers, there is a \color" attribute for ales.

E/R Sub classes

 isa triangles indicate the sub class relation.

isa

Beers

Ales

name manf

color

Multiple Inheritance

Theoreticall y, an E.S. could b e a sub class of several other entity sets.

isa isa

name manf name manf

Beers (^) Wines

Grap e Beers

Problems

How should con icts b e resolved?

 Example: manf means grower for wines, b ottler for b eers. What do es manf mean for \grap e b eers"?

 Need ad-ho c notation to resolve meanings.

 In practice, we shall assume a tree of entity sets connected by isa, with all \isas" p ointing from child to parent.

Example

Supp ose name is key for Beers.

isa

Beers

Ales

manf

color

name

 Beer name is also key for ales.

F In general, key at ro ot is key for all.

Example: A Multiattribute Key

Courses

dept numb er hours

ro om

 Possibly, hours + ro om also forms a key, but we have not designated it as such.

Example: Logins (Email Addresses)

Login name = user name + host name, e.g., ullman@shalmaneser .stan ford. edu.

 A \login" entity corresp onds to a user name on a particular host, but the passwd table do esn't record the host, just the user name, e.g. ullman.

 Key for a login = the user name at the host (which is unique for that host only) + the IP address of the host (which is unique globally).

Logins @ Hosts

name name

 Design issue: Under what circumstances could we simply make login-name and host-name b e attributes of logins, and disp ense with the weak E.S.?

Example: Chain of \Weakness" Consider IP addresses consisting of a primary domain (e.g., edu) sub domain (e.g., stanford), and host (e.g. shalmaneser).

name name name

Primary Hosts In2 Domains In1 Domains

2ndary

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

Design Principles

Setting: client has (p ossibly vague) idea of what he/she wants. You must design a database that represents these thoughts and only these thoughts.

 Avoid redundancy.

F Wastes space and encourages inconsistency. F Intuition: something is redundant if it could b e hidden from view, and you could still gure out what it is from the other data.

 KISS = keep it simple, students.

F Avoid intermediate concepts.

 Faithfulness to requirements.

F Rememb er the design schema should enforce as many constraints as p ossible. Don't rely on future data to follow assumptions. F Example: If registrar wants to asso ciate only one instructor with a course, don't allow sets of instructors and count on departments to enter only one instructor p er course.

Bad (needless intermediate):

name

Beers ManfBy Manfs

name

 Question: Why is it OK to have Beers with just its key as attribute? Why not make set of b eers an attribute of manufacturers?