Switch off your Mobiles Phones or Change Profile to Silent Mode

Transforming an ER Model to a Relational Schema

Topics Introduction Transformation of Binary relationships Unary relationships Ternary Relationships Subclasses / Superclasses

Transforming ER Model into Relational Schema There are a set of guidelines to convert an ER model into a relational schema. They are not hard and fast rules and Database Designer must use them wisely. ER model consists of 3 major concepts which have to be transformed Entity types Attributes Relationships

Transformation of Entity Types Each entity type is usually represented by a relation (table) DOCTOR(…………..) DOCTOR

Transformation of Attributes Attributes of Entity become columns of relation (table). DOCTOR Doc-no Name Title Speciality Doc-noNameTitleSpeciality DOCTOR

Transformation of Relationships Different Relationship Types Unary, Binary, Ternary Degree of Relationship Types 1:1 1:M M:N Optionality of Relationship Types Mandatory Optional

Transformation of Binary Relationships One to Many and Mandatory DEPARTMENT (dno, dname, location) PROJECT (pno, dno*, title, sdate, edate) DEPARTMENT PROJECT runs

Transformation of Binary Relationships One to Many and Mandatory So why not post pno into DEPARTMENT? DEPARTMENT (dno, pno*, dname, location) PROJECT (pno, title, sdate, edate) DEPARTMENT PROJECT runs dnopnodnamelocation D1P5SalesLondon D1P6SalesLondon D2P7ClaimsCardiff

Transformation of Binary Relationships One to Many and Mandatory ORDER (orderno, date) ORDER-DETAIL (Product_No, orderno*, qty, subtotal) ORDER ORDER-DETAIL contains

Transformation of Binary Relationships One to Many and Optional BORROWER (borrower-no, name, address) BOOK (catalog-no, title, ISBN, publisher) LOANS (catalog-no*, borrower-no*, date- out, date-due) BORROWER BOOK loans

Transformation of Binary Relationships Many to Many and Mandatory EMPLOYEE (emp-no, name, address) PROJECT (p-no, ptype, duration) WORKS-ON (emp-no*, p-no*) EMPLOYEE PROJECT Works on

Transformation of Binary Relationships Many to Many and Mandatory So why not post emp-no or p-no into original entity? EMPLOYEE (emp-no, p-no*,name, address) PROJECT (p-no, emp-no*, ptype, duration) EMPLOYEE PROJECT Works on Emp-noP-nonameaddress E11P1SmithLondon E11P2SmithLondon P-noEmp-noptypeduration P1E11Custom12 P1E11Custom12

Transformation of Binary Relationships Many to Many and Optional SUPPLIER (supp-no, name, address) PRODUCT (pcode, pname, colour) SUPPLIES (supp-no*, pcode*, min-order) SUPPLIER PRODUCT supplies

Transformation of Binary Relationships One to One and Mandatory PERSON (person-no, pname, address, job) BIRTH-CERTIFICATE (person-no*, registered, date-reg) PERSON BIRTH- CERTIFICATE has

Transformation of Binary Relationships One to One and Optional EMPLOYEE (emp-no, name, job-type) VEHICLE (vno, emp-no*, make, model, colour) OR VEHICLE (vno, make, model, colour) EMPLOYEE (emp-no, vno*, name, job-type) EMPLOYEE VEHICAL assigned

Transformation of Unary Relationships One to One PERSON (person-id, pname, address) MARRY (person-id*, spouse-id*, date) PERSON marry

Transformation of Unary Relationships One to Many (for mostly mandatory) EMPLOYEE (emp-id, super-no*, ename, salary) EMPLOYEE supervises

Transformation of Unary Relationships One to Many (for mostly optional) EMPLOYEE (emp-id, ename, salary) SUPERVISES (emp-id*, super-no*) EMPLOYEE supervises

Transformation of Unary Relationships Many to Many PART (part-no, pname, description) COMPRISES (major-part-no*, minor-part- no*, qty) PART Comprises

Transformation of Ternary Relationships

Transformation of Superclasses/Subclasses Option A Create a new relation for each subclass and a relation for the superclass. Use the primary key of the superclass as the primary key for each relation.

Transformation of Superclasses/Subclasses EMPLOYEE (emp-no, emp-name, address, job-type) SECRETARY (emp-no*, typing-speed) TECHNICIAN (emp-no*, tgrade) ENGINEER (emp-no*, eng-type)

Transformation of Superclasses/Subclasses Problem with this option: In order to extract all super and sub class attributes we must JOIN the relations

Transformation of Superclasses/Subclasses Option B Create a new relation for each subclass and include in each one all the attributes of the superclass. Use the primary key of the superclass for each of the new relations.

Transformation of Superclasses/Subclasses CAR (Vehicle-no, License-no, Price, MaxSpeed, NoOfPassengers) TRUCK (Vehicle-no, License-no, Price, NoOfAxles, Tonnage)

Transformation of Superclasses/Subclasses Problems with this option: We have no good way of finding all VEHICLES which are not CARS or TRUCKS. We have to search through all relations to find a particular VEHICLE superclass. If an entity belongs to more than one subclass we have redundant information.

Any Questions?