Scribd
Upload
30 views3 pages

Announcements: Vote On Meeting Time in This Lecture

The document discusses relational database design and translating entity-relationship (E/R) models to relational schemas. It reviews key concepts like entity sets, relationship sets, and weak entity sets. It then covers three approaches to translating subclasses and "is-a" relationships: representing an entity in all superclass tables, only its most specific class, or a single combined table. The document also provides a train database example and discusses simplifying designs to reduce redundancy.

Uploaded by

Aml Makarem
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
30 views3 pages

Announcements: Vote On Meeting Time in This Lecture

The document discusses relational database design and translating entity-relationship (E/R) models to relational schemas. It reviews key concepts like entity sets, relationship sets, and weak entity sets. It then covers three approaches to translating subclasses and "is-a" relationships: representing an entity in all superclass tables, only its most specific class, or a single combined table. The document also provides a train database example and discusses simplifying designs to reduce redundancy.

Uploaded by

Aml Makarem
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 3

Announcements Relational Database Design Part II

CPS 116 Introduction to Database Systems


Homework

#1 due in 7 days (Thursday, Sept. 9) Details of the course project and presentations will be available next Tuesday Discussion session next week: Homework #1 Q&A
Vote on meeting time in this lecture

E/R model: review


Entity

Database design steps: review


Understand Specify

sets the real-world domain being modeled it using a database design model (e.g., E/R) Translate specification to the data model of DBMS (e.g., relational) Create DBMS schema
Next:

Keys Weak entity sets


Relationship

sets

Attributes on relationships Multiplicity Roles Binary versus N-ary relationships


Modeling N-ary relationships with weak entity sets and binary relationships

ISA relationships

translating an E/R design to a relational schema

Translating entity sets


An

Translating weak entity sets


Remember

entity set translates directly to a table

Attributes columns Key attributes key columns


SID name CID title

the borrowed key attributes Watch out for attribute name conflicts
number capacity Rooms In number L/R? Seats In Buildings name year

Students

Enroll grade

Courses

Student (SID, name)

Course (CID, title)

Building (building_name, year) Rooms (building_name, room_number, capacity) Seats (building_name, room_number, seat_number, left_or_right)

Translating relationship sets


A

More examples
SID name Students TID name Enroll TAs Courses CID title

relationship set translates to a table

Keys of connected entity sets columns Attributes of the relationship set (if any) columns Multiplicity of the relationship set determines the key of the table
SID name Students Enroll grade Enroll (SID, CID, grade) Courses CID title

Enroll (SID, CID, TID)

husband SSN Persons wife Marry

Marry (husband_SSN, wife_SSN) Marry (husband_SSN, wife_SSN)

Translating double diamonds


Recall that a double-diamond relationship set connects a weak entity set to another entity set No need to translate because the relationship is implicit in the weak entity sets translation

Translating subclasses & ISA (approach 1)


10

Entity-in-all-superclasses approach (E/R style)


An entity is represented in the table for each subclass to which it belongs A table include only the attributes attached to the corresponding entity set, plus the inherited key SID name office Students ISA GradStudents Enroll Courses CID title

number capacity

Rooms In

In

Buildings

name year

number L/R?

Seats

RoomInBuilding (room_building_name, room_number, building_name) is subsumed by Rooms (building_name, room_number, capacity)

h 444, Apui Student (SID, name) h 142, Barti

Course (CID, title)

Enroll (SID, CID)

h 444, D444i GradStudent (SID, office)

Translating subclasses & ISA (approach 2)


11

Translating subclasses & ISA (approach 3)


12

Entity-in-most-specific-class approach (OO style)


An entity is only represented in one table (corresponding to the most specific entity set to which the entity belongs) A table includes the attributes attached to the corresponding entity set, plus all inherited attributes SID name office Students ISA Enroll Courses CID title

All-entities-in-one-table approach (NULL style)


One relation for the root entity set, with all attributes found anywhere in the network of subclasses Use a special NULL value in columns that are not relevant for a particular entity SID name office Students ISA Enroll Courses CID title

Course (CID, title) GradStudents h 142, Barti Student (SID, name) Enroll (SID, CID) h 444, Apu, D444i GradStudent (SID, name, office)

Course (CID, title) h 444, Apu, D444i GradStudents h 142, Bart, NULLi Student (SID, name, office) Enroll (SID, CID)

Comparison of three approaches


13

A complete example
number engineer time Trains ISA LocalTrains ExpressTrains
Train (number, engineer) LocalTrain (number) ExpressTrain (number) Station (name, address) LocalStation (name) ExpressStation (name)

14

Entity-in-all-superclasses
Student (SID, name), GradStudent (SID, office) Pro: All students are found in one table Con: Attributes of grad students are scattered in different tables

LocalTrainStops

Stations ISA LocalStations

name address

Entity-in-most-specific-class
Student (SID, name), GradStudent (SID, name, office) Pro: All attributes of grad students are found in one table Con: Students are scattered in different tables

time

ExpressStations

All-entities-in-one-table
Student (SID, name, office) Pro: Everything is in one table Con: Too many NULLs; complicated if class hierarchy is complex

ExpressTrainStops
LocalTrainStop (local_train_number, station_name, time) ExpressTrainStop (express_train_number, express_station_name, time) Note that keys for Local/ExpressTrainStop come from assumptions not encoded in the E/R design

Simplifications and refinements


Train (number, engineer), LocalTrain (number), ExpressTrain (number) Station (name, address), LocalStation (name), ExpressStation (name) LocalTrainStop (local_train_number, station_name, time) ExpressTrainStop (express_train_number, express_station_name, time)

15

An alternative design
Train (number, engineer, type) Station (name, address, type) TrainStop (train_number, station_name, time)

16

Eliminate

LocalTrain table

Encode

Can be computed as number (Train) ExpressTrain Slightly harder to check that local_train_number is indeed a local train number
Eliminate

the type of train/station as a column rather than creating subclasses Some constraints are no longer captured
Type must be either local or express Express trains only stop at express stations Fortunately, they can be expressed/declared explicitly as database constraints in SQL
Arguably

LocalStation table

It can be computed as number (Station) ExpressStation

a better design because it is simpler!

Design principles
KISS

17

Keep It Simple, Stupid!


Avoid

redundancy

Redundancy wastes space, complicates updates, and promotes inconsistency


Use

your common sense

Warning: Mechanical translation procedures given in this lecture are no substitute for your own judgment

You might also like