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?