Scribd
Upload
98 views35 pages

ER To Relational Schema Translation

The document describes translating an entity-relationship schema into an equivalent relational schema. It lists the steps to specify foreign keys, translate regular and weak entity types, handle different relationship types, and account for special cases like inheritance and union types. Guidelines are provided for how to represent attributes, keys, relationships and special structures like weak entities in the relational design.

Uploaded by

Sarmad
Copyright
© © All Rights Reserved
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
98 views35 pages

ER To Relational Schema Translation

The document describes translating an entity-relationship schema into an equivalent relational schema. It lists the steps to specify foreign keys, translate regular and weak entity types, handle different relationship types, and account for special cases like inheritance and union types. Guidelines are provided for how to represent attributes, keys, relationships and special structures like weak entities in the relational design.

Uploaded by

Sarmad
Copyright
© © All Rights Reserved
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/ 35

ER

to Relational Schema Translation



● Specify all foreign keys for the following schema:

STUDENT(SID, Name, Major, BirthDate)





COURSE(CID, Name, Dept)



ENROLL(Student, Course, Semester, Grade)



BOOK_ADOPTION(Course, Semester, ISBN)



TEXTBOOK(ISBN, Title, Publisher, Author)
Reverse engineer
this relational
schema to find an
equivalent ER
schema.
● Regular entity types become relations
◾include all simple attributes
◾include only components of compound attributes
◾keys become primary keys
◾if multiple keys (candidates) select a primary key

CUSTOMER(Ssn, Name, Addr, Phone)


BANK(Code, Name, Addr)

ACCOUNT(Acct_no, Type, Balance)

LOAN(Loan_no, Type, Amount)


● Weak entity types become relations
◾include all simple attributes
◾include only components of compound attributes
◾create a primary key from partial key 

and key of owning entity type (through identifying relationship)
◾attributes acquired through identifying relationship 

become a foreign key*

* typically, deletions and insertions will be propagated



through this foreign key
● Weak entity types become relations

BANK_BRANCH(Bank_code, Branch_No, Addr)


FK

BANK(Code, Name, Addr)


● Approach 1: Foreign Key
◾Chose one of the related entity types to hold the relationship

(chose one with total participation, if possible)
◾add FK to other relation
◾move all relationship attributes to this relation
◾this approach is preferable, except as noted below
● Approach 2: Merged Relation
◾combine the relations for the related entities into a single
relation
◾use only when both participations are total
● Approach 3: Separate Relation
◾same as binary M:N relationship (see step 5)
◾not generally a good option
● Approach 1: Foreign Key

EMPLOYEE(Ssn, Name, …)

FK
DEPARTMENT(Name, Number, Mgr, Mgr_start_date)
● Approach 2: Merged Relation

AJB(x, y, p, q, r)

or

AJB(x, y, p, q, r)
● 1:N Relationships become foreign key at N side
◾any relationship attributes also go to N side

LOAN(Loan_no, Type, Amount, 



Bank, Branch)

BANK_BRANCH(Bank_code, Branch_No, 

Addr)
● 1:N Relationships become foreign key at N side
◾any relationship attributes also go to N side

ACCOUNT(Acct_no, Type, Balance, 



Bank, Branch)

BANK_BRANCH(Bank_code, Branch_No, 

Addr)
● M:N Relationships must become a new relation
◾contains FKs to both related entities
◾combined FKs become PK for new relations
◾relationship attributes go in new relation

CUSTOMER(Ssn, Name, Addr, 



Phone)

A_C(Acct, Cust)

ACCOUNT(Acct_no, Type, 

Balance, Bank, Branch)
● Multivalued attributes must become new relations
◾FK to associated entity type
◾PK is whole relation

DEPARTMENT(Name, Number, Mgr, Mgr_start_date)

DEPT_LOCATIONS(DName, Dno, Location)


● Non-Binary Relationships become new relations
◾FKs to all participating entity types
◾Combine FKs to make a PK 

(exclude entities with max participation of 1)
◾Include any relationship attributes

SUPPLIER(SName)

PROJECT(Proj_name)

PART(Part_no)
SUPPLY(SName, PName, Part, Quantity)
CUSTOMER(Ssn, Name, Addr, Phone)
BANK(Code, Name, Addr)
ACCOUNT(Acct_no, Type, Balance, Bank, Branch)
LOAN(Loan_no, Type, Amount, Bank, Branch)
BANK_BRANCH(Bank_code, Branch_No, Addr)
A_C(Acct, Cust)
L_C(Loan, Cust)

BANK_BRANCH(Bank_code) refers to BANK



LOAN(Bank,Branch) refers to BANK_BRANCH
ACCOUNT(Bank,Branch) refers to BANK_BRANCH
A_C(Acct) refers to ACCOUNT
A_C(Cust) refers to CUSTOMER
L_C(Loan) refers to LOAN
L_C(Cust) refers to CUSTOMER
● Option a: Each entity type becomes a relation
◾all have same PK (from superclass)
◾PKs in subclasses are FKs to superclass
◾most general solution
PERSON(ID, Name)
STUDENT(ID, Major, Class)
PROFESSOR(ID, Dept, Office)
Name PERSON ID

STUDENT(ID) refers to PERSON


PROFESSOR(ID) refers to PERSON
STUDENT PROFESSOR

Major Class Dept Office


● Option b: Each subclass becomes a relation
◾all have same PK (from superclass)
◾each relation gets all superclass attributes
◾restriction: only works for covering inheritance
◾problem: need to join tables to find all PERSONs

Name PERSON ID

STUDENT(ID, Name, Major, Class)


PROFESSOR(ID, Name, Dept, Office)
STUDENT PROFESSOR

Major Class Dept Office


● Option c: Single relation with a type discriminator
◾PK from superclass
◾all attributes from all classes
◾restriction: only works for disjoint inheritance
◾problem: lots of NULL values
PERSON(ID, Classifier, Name, 

Major, Class, Dept, Office)
Name PERSON ID

Classifier ϵ { ‘S’, ‘P’, ‘N’ }

STUDENT PROFESSOR

Major Class Dept Office


● Option d: Single relation with multiple discriminators
◾PK from superclass
◾all attributes from all classes
◾works for overlapping inheritance
◾problem: lots of NULL values
PERSON(ID, isStudent, isProfessor,

Name, Major, Class, Dept, Office)
Name PERSON ID

dom(isStudent) = Boolean
dom(isProfessor) = Boolean
STUDENT PROFESSOR

Major Class Dept Office


● Union types become a new relation of surrogate keys
◾surrogate keys are added to all defining classes
◾attributes of the union type go in the new relation

add surrogate key to OWNER


PERSON(Driver_license_no, Ssn, Name, 

Address, Owner_id)

BANK(Bname, Baddress , Owner_id)

COMPANY(Cname, Caddress , Owner_id)

OWNER(ID)



PERSON(Owner_id) refers to OWNER
BANK(Owner_id) refers to OWNER
COMPANY(Owner_id) refers to OWNER
add surrogate key to REGISTERED_VEHICLE
CAR(Vehicle_id, Cstyle, Cmake, 

Cyear, Cmodel)

TRUCK(Vehicle_id, Tonnage, Tmake, 

Tyear, Tmodel)

REGISTERED_VEHICLE(Vehicle_id, License_plate_no)




CAR(Vehicle_id) refers to REGISTERED_VEHICLE
TRUCK(Vehicle_id) refers to REGISTERED_VEHICLE

in this case, we don’t need to invent a surrogate key, since the domains
of CAR keys and TRUCK keys are the same (and non-overlapping)
OWNS relation uses the surrogate
keys

OWNS(Owner_id, Vehicle_id, 

Purchase_date, Lien_or_regular)



OWNS(Owner_id) refers to OWNER
OWNS(Vehicle_id) refers to REGISTERED_VEHICLE
● Create relational schema from the following:
● Which employee has no supervisor?
● Which employees are supervised by Franklin Wong?
● Which employees have dependents?
● Which employees have daughters?
● Which employees in department 5 

work more than 10 hours/week on ProductX?
● Which department has the highest paid manager?
● What is the average salary 

of all department managers?
● Which employees don’t have daughters?

You might also like