Introduction to Database Systems Mapping ER Models to Relational Schemas Irvanizam Zamanhuri, M.Sc Informatics (Computer Science) Study Program Syiah Kuala.

Slides:



Advertisements
Similar presentations
Relational Database Design Via ER Modelling
Advertisements

Normalisation. Informal guidelines  Semantics of the attributes  easy to explain relation  doesn’t mix concepts  Reducing the redundant values in.
Keys  SuperKey  a set of attributes whose values together uniquely identify a tuple in a relation  Candidate Key  a superkey for which no proper subset.
Conceptual Data Modeling: ER
Data Modeling (CB 12) CPSC 356 Database Ellen Walker Hiram College (Includes figures from Database Systems by Connolly & Begg, © Addison Wesley 2002)
Logical Database Design
ENTITY RELATIONSHIP MODELLING
Text-Book Chapters (7 and 8) Entity-Relationship Model
Mapping an ERD to a Relational Database To map an ERD to a relational database, five rules are defined to govern how tables are constructed. 1)Rule for.
Data Modeling and Relational Database Design ISYS 650.
Chapter 6 Methodology Logical Database Design for the Relational Model Transparencies © Pearson Education Limited 1995, 2005.
System Analysis - Data Modeling
Methodology Logical Database Design for the Relational Model
Slides adapted from A. Silberschatz et al. Database System Concepts, 5th Ed. Entity-Relationship Model Database Management Systems I Alex Coman, Winter.
Modeling & Designing the Database
CSCI 6442 Entity-Relation Data Modeling Copyright 2012, David C. Roberts, all rights reserved.
Entity/Relationship Modelling
Mapping ERM to relational database
Data Definition, Relational Manipulation and Data Control Using SQL.
CS 405G Introduction to Database Systems
Entity Relationship Model Chapter 6. Basic Elements of E-R Model Entity Object of the real world that stores data. Eg. Customer, State, Project, Supplier,
Dr. Mohamed Osman Hegaz1 Conceptual data base design: The conceptual models: The Entity Relationship Model.
Introduction to Database Systems Conceptual Modeling
Relational Query Languages. Languages of DBMS  Data Definition Language DDL  define the schema and storage stored in a Data Dictionary  Data Manipulation.
Chapter 5 Entity–Relationship Modeling
ER to Relational Translation COMSATS INSTITUTE OF INFORMATION TECHNOLOGY, VEHARI.
Keys  SuperKey  a set of attributes whose values together uniquely identify a tuple in a relation  Candidate Key  a superkey for which no proper subset.
Database Systems Lecture # 7 8 th Feb, Conceptual and Logical Design Person buys Product name pricenamessn Conceptual Model: Relational Model: (plus.
(Extended) Entity Relationship Modelling and Mappings to the Relational Data Model.
©Silberschatz, Korth and Sudarshan2.1Database System Concepts Chapter 2: Entity-Relationship Model Entity Sets Relationship Sets Design Issues Mapping.
1.  An introduction to data modelling  The purpose of data modelling  Modelling data relationships 2.
Entity-Relationship (ER) Modelling ER modelling - Identify entities - Identify relationships - Construct ER diagram - Collect attributes for entities &
CS 370 Database Systems Lecture 9 The Relational model.
Chapter 9: Logical Database Design and the Relational Model (ERD Mapping)
CS 405G: Introduction to Database Systems Lecture 2 : Database Design I.
1 A Demo of Logical Database Design. 2 Aim of the demo To develop an understanding of the logical view of data and the importance of the relational model.
1 © Prentice Hall, 2002 Chapter 5: Logical Database Design and the Relational Model Modern Database Management 6 th Edition Jeffrey A. Hoffer, Mary B.
3 & 4 1 Database Systems: Design, Implementation, & Management, 7 th Edition, Rob & Coronel Keys Consists of one or more attributes that determine other.
Databases Illuminated Chapter 3 The Entity Relationship Model.
Data Modeling Using the Entity-Relationship (ER) Data Model (Based on Chapter 3 in Fundamentals of Database Systems by Elmasri and Navathe, Ed. 3)
advanced data modeling
Database Design Slide 1 Database Design Lecture 7 part 2 Mapping ERD to Tables.
CSE 412/598 DATABASE MANAGEMENT COURSE NOTES 3. ENTITY-RELATIONSHIP CONCEPTUAL MODELING Department of Computer Science & Engineering Arizona State University.
©Silberschatz, Korth and Sudarshan2.1Database System Concepts Chapter 2: Entity-Relationship Model Entity Sets Relationship Sets Mapping Constraints Keys.
©Silberschatz, Korth and Sudarshan7.1Database System Concepts - 6 th Edition Chapter 7: Entity-Relationship Model.
Methodology - Logical Database Design. 2 Step 2 Build and Validate Local Logical Data Model To build a local logical data model from a local conceptual.
Data Modeling and Entity-Relationship Model I
Database Designsemester Slide 1 Database Design Lecture 7 Entity-relationship modeling Text , 7.1.
COP Introduction to Database Structures
Entity/Relationship Modelling
Simplified phases of Database Design
Entity-Relationship Model
Methodology Logical Database Design for the Relational Model
Entity-Relationship Model
Tables and Their Characteristics
Chapter -3- Data Modeling Using the Entity-Relationship Model
Chapter 7: Entity-Relationship Model
Entity-Relationship Modelling
Chapter 7 Entity-Relationship Model
Entity-Relationship Modeling
بسم الله الرحمن الرحيم.
Entity-Relationship Modelling
Database Modeling using Entity Relationship Model (E-R Model)
Practical Relevance Examples Class Laboratory
Chapter 7: Entity-Relationship Model
Mapping an ERD to a Relational Database
Entity Relation Model Tingting Zhang.
Database Management system
Database Management system
Presentation transcript:

Introduction to Database Systems Mapping ER Models to Relational Schemas Irvanizam Zamanhuri, M.Sc Informatics (Computer Science) Study Program Syiah Kuala University

Conceptual and Logical Design Person buys Product name pricenamessn Conceptual Model: Relational Model:

We cannot store date in an ER schema (There are no ER database management systems)  We have to translate our ER schema into a relational schema  What does “translation” mean? Mapping an E-R Diagram to a Relational Schema

Mapping Entity Types to Relations  For every entity type create a relation  Every atomic attribute of the entity type becomes a relation attribute  Composite attributes: include all the atomic attributes  Derived attributes are not included (but remember their derivation rules)  The relation is a subset of the cross product of the domains of the attributes  Omit derived attributes name given family STUDENT studno no. of students subject equip courseno COURSE

Mapping Entity Types to Relations (cntd.) STUDENT (studno, givenname, familyname) COURSE(courseno, subject, equip) name given family STUDENT studno no. of students subject equip courseno COURSE

Mapping Many:many Relationship Types to Relations Create a relation with the following set of attributes: N (degree of relationship) U primary_key(E i ) U {a 1 …a M } i=1 primary keys of each participating entity type in the relationship attributes on the relationship type (if any) exammark no. of students labmark name given family STUDENT studno subject equip courseno COURSE ENROL

Mapping Many:many Relationship Types to Relations (cntd.) ENROL(studno, courseno, labmark, exammark) exammark no. of students labmark name given family STUDENT studno subject equip courseno COURSE ENROL

Mapping One:many Relationship Types to Relations Idea: “Post the primary key”  Given E1 at ‘many’ end of relationship and E2 at ‘one’ end of relationship, add to the relation for E1  Make the primary key of the entity at the ‘one’ end (the determined entity) a foreign key in the entity at the ‘many’ end (the determining entity). Include any relationship attributes with the foreign key entity attributes on the relationship type (if any) E1 U primary_key(E2) U {a 1 …a n } relation for entity E1 primary key for E2, is now a foreign key to E2 STAFF slot TUTOR m 1 name given family STUDENT studno roomno name

Mapping One:many Relationship Types to Relations (cntd.) STAFF slot TUTOR m 1 name given family STUDENT studno roomno name The relation STUDENT (studno, givenname, familyname) is extended to STUDENT (studno, givenname, familyname, tutor, roomno,slot) and the constraint Foreign Key STUDENT(tutor,roomno) references STAFF(name,roomno)

Mapping one:many Relationship Types to Relations (cntd.)

Mapping One:many Relationship Types to Relations (cntd.) Another Idea:  If the relationship type is optional to both entity types,  and an instance of the relationship is rare,  and there are many attributes on the relationship then… Create a new relation with the set of attributes: attributes on the relationship type (if any) primary_key(E1) U primary_key(E2) U {a 1, …,a m } primary key for E2, is now a foreign key to E2 primary key for E1, is now a foreign key to E1; also the PK for this relation STAFF slot TUTOR m 1 name given family STUDENT studno roomno name

Mapping One:many Relationship Types to Relations (cntd.) TUTOR(studno, staffname, rommno, slot) and Foreign key TUTOR(studno) references STUDENT(studno) Foreign key TUTOR(staffname,roomno) references STAFF(name,roomno) STAFF slot TUTOR m 1 name given family STUDENT studno roomno name Compare with the mapping of many:many relationship types!

Mapping One:many Relationship Types to Relations (cntd.)

Optional Participation of the Determined Entity (‘one end’) SCHOOL(hons, faculty) STUDENT(studno, givenname, familyname, ??? ) studno name given family hons STUDENT SCHOOL REG faculty m 1 A student entity instance must participate in a relationship instance of REG A school entity instance does not have to participate in a relationship instance of REG

Optional Participation of the Determined Entity hons can’t be NULL because it is mandatory for a student to be registered for a school  “not null” constraint No student is registered for “mi”, so “mi” doesn’t occur as a foreign key value (but that’s no problem)

Optional Participation of the Determinant Entity (‘many end’) STAFF slot TUTOR m 1 name given family STUDENT studno roomno name A student entity instance does not have to participate in a relationship instance of TUTOR A staff entity instance must participate in a relationship instance of TUTOR

Optional Participation of the Determinant Entity (‘many end’) 1. STUDENT (studno, givenname, familyname, tutor, slot) STAFF(name, roomno) Integrity constraint:  name,roomno STAFF –  tutor,roomno STUDENT =  2. STUDENT(studno, givenname, familyname) STAFF(name, roomno) TUTOR(studno, tutor, roomno, slot) Do we also need an integrity constraint?

Optional Participation of the Determinant Entity (cntd.)

Mapping one:one Relationship Types to Relations Post the primary key of one of the entity types into the other entity type as a foreign key, including any relationship attributes with it or Merge the entity types together Which constraint holds in this case? YEAR YEARTUTOR STAFF year roomnoname

dateofbirth Multi-Valued Attributes (… if they are allowed) For each multi-valued attribute of E i, create a relation with the attributes primary_key(E i ) U multi-valued attribute The primary key comprises all attributes name given family STUDENT studno contact

Mapping Roles & Recursive Relationships How can the entity STAFF appear in both of its roles ? STAFF name appraiser appraisee APPRAISAL 1 m roomno STAFF(name, roomno, ) appraiser, approomno

Multiple Relationships between Entity Types STUDENT SUPERVISE STAFF EXAMINE 1 1 m m studno name given family name roomno STAFF(name,roomno) STUDENT(studno,given,family, ??? ) EXAMINER( ??? ) SUPERVISOR( ??? ) EXAMINER-SUPERVISOR( ??? ) 1. Treat each relationship type separately 2. Represent distinct relationships by different foreign keys drawing on the same relation

Non-binary Relationship STAFF p m TUTORS name given family STUDENT studno COURSE subject equip courseno STAFF name n roomno slot COURSE(courseno, subject, equip) STUDENT(studno, givenname, familyname) STAFF(staffname, roomno) TUTORS(???)

Weak Entities orderid CUSTOMER 1 date ORDER m 1 address c-name ORDER LINES ORDER_ LINE m part quantity CUST-ORDER ORDER-MAKEUP Weak entity Identifying entity for ORDER_LINES Weak entity Strong Entity Identifying entity for ORDER Identifying entity for ORDER_LINES

Mapping Weak Entities to Relations Create a relation with the attributes: CUSTOMER ORDER CUST-ORDER 1 m orderid date address customer n primary_key(E 0 ) U U discriminator(E i ) U {a 1,…,a n } i=1 Attributes of the weak entity type Discriminators of identifying weak entity type Primary key of identifying weak entity type How should we choose the primary key?

Association Entity Types An entity type that represents a relationship type: labmark exammark ENROL studno m name given family STUDENT 1 mm COURSE subject equip courseno 1 studno m name given family STUDENT 1 STUD_ENROLCOURSE_ENROL

Mapping Association Types to Relations labmark exammark ENROL studno m name given family STUDENT 1 mm COURSE subject equip courseno 1 studno m name given family STUDENT 1 STUD_ENROLCOURSE_ENROL Then:  ENROL(courseno, studno, labmark, exammark) We have:  COURSE(courseno, subject, equip)  STUDENT(studno, givenname, familyname)

Translation of the University Diagram studno name given family hons slot labmark exammark STUDENT SCHOOL YEAR ENROL YEARREG REG TUTOR YEARTUTOR STAFF COURSE courseno subject equip name year faculty appraiser appraisee APPRAISAL TEACH m n 1 m m n m m 1 m 1 roomno STUDENT (studno, givenname, familyname, hons, tutor, slot, year) ENROL(studno, courseno, labmark,exammark) COURSE(courseno, subject, equip) STAFF(lecturer, roomno, appraiser) TEACH(courseno, lecturer) YEAR(year, yeartutor) SCHOOL(hons, faculty)

Exercise: Supervision of PhD Students A database needs to be developed that keeps track of PhD students:  For each student store the name and matriculation number. Matriculation numbers are unique.  Each student has exactly one address. An address consists of street, town and post code, and is uniquely identified by this information.  For each lecturer store the name, staff ID and office number. Staff ID's are unique.  Each student has exactly one supervisor. A staff member may supervise a number of students.  The date when supervision began also needs to be stored.  For each research topic store the title and a short description. Titles are unique.  Each student can be supervised in only one research topic, though topics that are currently not assigned also need to be stored in the database.

Exercise: Supervision of PhD Students Tasks: a) Design an entity relationship diagram that covers the requirements above. Do not forget to include cardinality and participation constraints. b) Based on the ER-diagram from above, develop a relational database schema. List tables with their attributes. Identify keys and foreign keys.

References In preparing these slides I have used several sources. The main ones are the following: Books:  A First Course in Database Systems, by J. Ullman and J. Widom  Fundamentals of Database Systems, by R. Elmasri and S. Navathe Slides from Database courses held by the following people:  Warner Nutt (Free University of Bozen-Bolzano)  Enrico Franconi (Free University of Bozen-Bolzano)  Carol Goble and Ian Horrocks (University of Manchester)