ER & EER to Relational Mapping. Chapter 9 1



Similar documents
Relational Schema. CS 4700/6700 A Sample of Small Database Design Using Microsoft Access

CSC 443 Data Base Management Systems. Basic SQL

Lab Assignment Creating a Relational Database Schema from ER Diagram, Populating the Database and Querying over the database with SQL

Relational Schema Design

Figure 14.1 Simplified version of the

Part A: Data Definition Language (DDL) Schema and Catalog CREAT TABLE. Referential Triggered Actions. CSC 742 Database Management Systems

Part 4: Database Language - SQL

Chapter 3. Data Modeling Using the Entity-Relationship (ER) Model

2. Conceptual Modeling using the Entity-Relationship Model

Chapter 8. SQL-99: SchemaDefinition, Constraints, and Queries and Views

SQL-99: Schema Definition, Basic Constraints, and Queries

Lab Manual. Database Systems COT-313 & Database Management Systems Lab IT-216

{ PreviousEducation ( CollegeName, StartDate, EndDate, { Degree (DegreeName, Month, Year) }, { Transcript (CourseName, Semester, Year, Grade) } ) }

New York University Computer Science Department Courant Institute of Mathematical Sciences

Chapter 2: Entity-Relationship Model. Entity Sets. " Example: specific person, company, event, plant

Introduction to SQL: Data Retrieving

Summary on Chapter 4 Basic SQL

Advanced Database Models

THE ENTITY- RELATIONSHIP (ER) MODEL CHAPTER 7 (6/E) CHAPTER 3 (5/E)

10CS54: DATABASE MANAGEMENT SYSTEM

Fundamentals of Database Systems. Laboratory Manual 1. Rajshekhar Sunderraman. Georgia State University. August 2010

Entity-Relationship Model

b. Examine the following histories. Draw their serialization graph and identify which of them is serializable given reasons.

The Relational Algebra

CHAPTER 8: SQL-99: SCHEMA DEFINITION, BASIC CONSTRAINTS, AND QUERIES

How To Use The Database In Jdbc.Com On A Microsoft Gdbdns.Com (Amd64) On A Pcode (Amd32) On An Ubuntu (Amd66) On Microsoft

Chapter 7 Data Modeling Using the Entity- Relationship (ER) Model

CSC 742 Database Management Systems

SQL Nested & Complex Queries. CS 377: Database Systems

three Entity-Relationship Modeling chapter OVERVIEW CHAPTER

CS 338 Join, Aggregate and Group SQL Queries

Relational Normalization: Contents. Relational Database Design: Rationale. Relational Database Design. Motivation

Chapter 2: Entity-Relationship Model. E-R R Diagrams

Part 7: Object Oriented Databases

Functional Dependency and Normalization for Relational Databases

Review: Participation Constraints

featuring data privacy Andres Avelino Campos Sainz A Project submitted in partial fulfillment of the requirements for the degree of

Chapter 2: Entity-Relationship Model

Database Design. Database Design I: The Entity-Relationship Model. Entity Type (con t) Chapter 4. Entity: an object that is involved in the enterprise

COMP 378 Database Systems Notes for Chapter 7 of Database System Concepts Database Design and the Entity-Relationship Model

COURSE CODE: CIT 844 COURSE TITLE: ADVANCED DATABASE MANAGEMENT SYSTEM

The Entity-Relationship Model

More SQL: Assertions, Views, and Programming Techniques

Database Systems. Session 3 Main Theme. Enterprise Data Modeling Using The Entity/Relationship (ER) Model. Dr. Jean-Claude Franchitti

Entity - Relationship Modelling

ER modelling, Weak Entities, Class Hierarchies, Aggregation

Database Management Systems

not necessarily strictly sequential feedback loops exist, i.e. may need to revisit earlier stages during a later stage

VIEWS virtual relation data duplication consistency problems

CHAPTER 3. Relational Database Management System: Oracle. 3.1 COMPANY Database

Chapter 8 The Enhanced Entity- Relationship (EER) Model

IV. The (Extended) Entity-Relationship Model

Chapter 10. Functional Dependencies and Normalization for Relational Databases

How To Create A Table In Sql (Ahem)

Chapter 10 Functional Dependencies and Normalization for Relational Databases

XV. The Entity-Relationship Model

A Technique for Teaching Difficult Concepts in an Undergraduate Business Database Management Systems Course

Theory of Relational Database Design and Normalization

DATABASE DESIGN. - Developing database and information systems is performed using a development lifecycle, which consists of a series of steps.

Bridge from Entity Relationship modeling to creating SQL databases, tables, & relations

Database Design Overview. Conceptual Design ER Model. Entities and Entity Sets. Entity Set Representation. Keys

Database Design Methodologies

Theory of Relational Database Design and Normalization

Exercise 1: Relational Model

Designing a Database Schema

Enhanced-ER Data Model

Lecture 6. SQL, Logical DB Design

Data Modeling. Database Systems: The Complete Book Ch ,

Converting E-R Diagrams to Relational Model. Winter Lecture 17

The Relational Model. Why Study the Relational Model? Relational Database: Definitions. Chapter 3

A Tool for Generating Relational Database Schema from EER Diagram

Foundations of Information Management

Conceptual Design Using the Entity-Relationship (ER) Model

The Entity-Relationship Model

Databases and BigData

Lesson 8: Introduction to Databases E-R Data Modeling

Chapter 5: FUNCTIONAL DEPENDENCIES AND NORMALIZATION FOR RELATIONAL DATABASES

Lecture 12: Entity Relationship Modelling

Relational Database Design Theory

The Relational Model. Ramakrishnan&Gehrke, Chapter 3 CS4320 1

Chapter 10. Functional Dependencies and Normalization for Relational Databases. Copyright 2007 Ramez Elmasri and Shamkant B.

New York University Computer Science Department Courant Institute of Mathematical Sciences

Normalization in OODB Design

Use a high-level conceptual data model (ER Model). Identify objects of interest (entities) and relationships between these objects

LiTH, Tekniska högskolan vid Linköpings universitet 1(7) IDA, Institutionen för datavetenskap Juha Takkinen

7.1 The Information system

Chapter 9, More SQL: Assertions, Views, and Programming Techniques

COSC344 Database Theory and Applications. Lecture 9 Normalisation. COSC344 Lecture 9 1

Information Systems SQL. Nikolaj Popov

Database Design Methodology

Database Management Systems

CSCI315 Database Design and Implementation

CHAPTER 3: DATA MODELING USING THE ENTITY-RELATIONSHIP MODEL

Database Design Methodology

DataBase Management Systems Lecture Notes

Database Design and the E-R Model

Introduction to normalization. Introduction to normalization

Umbrello UML Modeller Handbook

Transcription:

ER & EER to Relational Mapping Chapter 9 1

Figure 3.2 ER schema diagram for the company database. Fname Minit Lname Number Name Address N 1 WORKS_FOR Name Locations Sex Salary Ssn Bdate EMPLOYEE NumberOfEmployees StartDate 1 1 MANAGES DEPARTMENT 1 CONTROLS N Hours supervisor supervisee WORKS_ON N PROJECT 1 SUPERVISION N 1 Name Location DEPENDENTS_OF Number N DEPENDENT Name Sex BirthDate Relationship Addison Wesley Longman, Inc. 2000, Elmasri/Navathe, Fundamentals of Database Systems, Third Edition

Step 1: For each regular entity type E Create a relation R that includes all the simple attributes of E. Include all the simple component attributes of composite attributes. Choose one of the key attributes of E as primary key for R. If the chosen key of E is composite, the set of simple attributes that form it will together form the primary key of R. Chapter 9 2

Figure 7.5 Schema diagram for the COMPANY relational database schema; the primary keys are underlined. EMPLOYEE FNAME MINIT LNAME SSN BDATE ADDRESS SEX SALARY SUPERSSN DNO DEPARTMENT DNAME DNUMBER MGRSSN MGRSTARTDATE DEPT_LOCATIONS DNUMBER DLOCATION PROJECT PNAME PNUMBER PLOCATION DNUM WORKS_ON ESSN PNO HOURS DEPENDENT ESSN DEPENDENT_NAME SEX BDATE RELATIONSHIP Addison Wesley Longman, Inc. 2000, Elmasri/Navathe, Fundamentals of Database Systems, Third Edition

Step 2: For each weak entity type W with owner entity type E Create a relation R, and include all simple attributes and simple components of composite attributes of W as attributes of R. In addition, include as foreign key attributes of R the primary key attribute(s) of the relation(s) that correspond to the owner entity type(s). Chapter 9 3

Figure 7.5 Schema diagram for the COMPANY relational database schema; the primary keys are underlined. EMPLOYEE FNAME MINIT LNAME SSN BDATE ADDRESS SEX SALARY SUPERSSN DNO DEPARTMENT DNAME DNUMBER MGRSSN MGRSTARTDATE DEPT_LOCATIONS DNUMBER DLOCATION PROJECT PNAME PNUMBER PLOCATION DNUM WORKS_ON ESSN PNO HOURS DEPENDENT ESSN DEPENDENT_NAME SEX BDATE RELATIONSHIP Addison Wesley Longman, Inc. 2000, Elmasri/Navathe, Fundamentals of Database Systems, Third Edition

Step 3: For each binary 1:1 relationship type R Identify the relations S and T that correspond to the entity types participating in R. Choose one of the relations, say S, and include as foreign key in S the primary key of T. It is better to choose an entity type with total participation in R in the role of S. Include the simple attributes of the 1:1 relationship type R as attributes of S. If both participations are total, we may merge the two entity types and the relationship into a single relation. Chapter 9 4

Figure 7.5 Schema diagram for the COMPANY relational database schema; the primary keys are underlined. EMPLOYEE FNAME MINIT LNAME SSN BDATE ADDRESS SEX SALARY SUPERSSN DNO DEPARTMENT DNAME DNUMBER MGRSSN MGRSTARTDATE DEPT_LOCATIONS DNUMBER DLOCATION PROJECT PNAME PNUMBER PLOCATION DNUM WORKS_ON ESSN PNO HOURS DEPENDENT ESSN DEPENDENT_NAME SEX BDATE RELATIONSHIP Addison Wesley Longman, Inc. 2000, Elmasri/Navathe, Fundamentals of Database Systems, Third Edition

Step 4: For each regular binary 1:N relationship type R Identify the relation S that represents the participating entity type at the N-side of the relationship type. Include as foreign key in S the primary key of the relations T that represents the other entity type participating in R. Include any simple attributes of the 1:N relationship type as attributes of S. Chapter 9 5

Figure 7.5 Schema diagram for the COMPANY relational database schema; the primary keys are underlined. EMPLOYEE FNAME MINIT LNAME SSN BDATE ADDRESS SEX SALARY SUPERSSN DNO DEPARTMENT DNAME DNUMBER MGRSSN MGRSTARTDATE DEPT_LOCATIONS DNUMBER DLOCATION PROJECT PNAME PNUMBER PLOCATION DNUM WORKS_ON ESSN PNO HOURS DEPENDENT ESSN DEPENDENT_NAME SEX BDATE RELATIONSHIP Addison Wesley Longman, Inc. 2000, Elmasri/Navathe, Fundamentals of Database Systems, Third Edition

Step 5: For each binary M:N relationship type R Create a new relation S to represent R. Include as foreign key attributes in S the primary keys of the relations that represent the participating entity types; their combination will form the primary key of S. Also, include any simple attributes of the M:N relationship type as attributes of S. Chapter 9 6

Figure 7.5 Schema diagram for the COMPANY relational database schema; the primary keys are underlined. EMPLOYEE FNAME MINIT LNAME SSN BDATE ADDRESS SEX SALARY SUPERSSN DNO DEPARTMENT DNAME DNUMBER MGRSSN MGRSTARTDATE DEPT_LOCATIONS DNUMBER DLOCATION PROJECT PNAME PNUMBER PLOCATION DNUM WORKS_ON ESSN PNO HOURS DEPENDENT ESSN DEPENDENT_NAME SEX BDATE RELATIONSHIP Addison Wesley Longman, Inc. 2000, Elmasri/Navathe, Fundamentals of Database Systems, Third Edition

Step 6: For each multi-valued attribute A Create a new relation R that includes an attribute corresponding to A plus the primary key attribute K (as a foreign key in R) of the relation that represents the entity type or relationship type that has A as an attribute. The primary key of R is the combination of A and K. If a multi-valued attribute is composite, we include its components. Chapter 9 7

Figure 7.5 Schema diagram for the COMPANY relational database schema; the primary keys are underlined. EMPLOYEE FNAME MINIT LNAME SSN BDATE ADDRESS SEX SALARY SUPERSSN DNO DEPARTMENT DNAME DNUMBER MGRSSN MGRSTARTDATE DEPT_LOCATIONS DNUMBER DLOCATION PROJECT PNAME PNUMBER PLOCATION DNUM WORKS_ON ESSN PNO HOURS DEPENDENT ESSN DEPENDENT_NAME SEX BDATE RELATIONSHIP Addison Wesley Longman, Inc. 2000, Elmasri/Navathe, Fundamentals of Database Systems, Third Edition

Step 7: For each n-ary relationship type R, n>2 Create a new relation S to represent R. Include as foreign key attributes in the S the primary keys of the relations that represent the participating entity types. Also include any simple attributes of the n- ary relationship types as attributes of S. The primary key for S is usually a combination of all the foreign keys that reference the relations representing the participating entity types. Chapter 9 8

TERNARY RELATIONSHIPS

Figure 9.1 Mapping the n-ary relationship type SUPPLY from Figure 4.13(a). SUPPLIER SNAME PROJECT PROJNAME PART PARTNO SUPPLY SNAME PROJNAME PARTNO QUANTITY Addison Wesley Longman, Inc. 2000, Elmasri/Navathe, Fundamentals of Database Systems, Third Edition

However, if the participation constraint (min,max) of one of the entity types E participating in the R has max =1, then the primary key of S can be the single foreign key attribute that references the relation E corresponding to E This is because, in this case, each entity e in E will participate in at most one relationship instance of R and hence can uniquely identify that relationship instance. Chapter 9 9

Step 8: To convert each super-class/subclass relationship into a relational schema you must use one of the four options available. Let C be the super-class, K its primary key and A 1, A 2,, A n its remaining attributes and let S 1, S 2,, S m be the sub-classes. Chapter 9 10

Option 8A (multiple relation option): Create a relation L for C with attributes Attrs(L) = {K, A 1, A 2,, A n } and PK(L) = K. Create a relation L i for each subclass S i, 1 < i < m, with the attributes ATTRS(L i ) = {K} U {attributes of S i } and PK(L i ) = K. This option works for any constraints: disjoint or overlapping; total or partial. Chapter 9 11

Option 8B (multiple relation option): Create a relation L i for each subclass S i, 1 < i < m, with ATTRS(L i ) = {attributes of S i } U {K, A 1, A 2,, A n } PK(L i ) = K This option works well only for disjoint and total constraints. If not disjoint, redundant values for inherited attributes. If not total, entity not belonging to any sub-class is lost. Chapter 9 12

Figure 9.2 Options for mapping specializations (or generalizations) to relations. (a) Mapping the EER schema of Figure 4.4 to relations by using Option A. (b) Mapping the EER schema of Figure 4.3(b) into relations by using Option B. (c) Mapping the EER schema of Figure 4.4 by using Option C, with JobType playing the role of type attribute. (d) Mapping the EER schema of Figure 4.5 by using Option D, with two Boolean type fields Mflag and Pflag. (a) EMPLOYEE SSN FName MInit LName BirthDate Address JobType SECRETARY SSN TypingSpeed TECHNICIAN SSN TGrade ENGINEER SSN EngType (b) CAR VehicleId LicensePlateNo Price MaxSpeed NoOfPassengers TRUCK VehicleId LicensePlateNo Price NoOfAxles Tonnage (c) EMPLOYEE SSN FName MInit LName BirthDate Address JobType TypingSpeed TGrade EngType (d) PART PartNo Description MFlag DrawingNo ManufactureDate BatchNo PFlag SupplierName ListPrice Addison Wesley Longman, Inc. 2000, Elmasri/Navathe, Fundamentals of Database Systems, Third Edition

Figure 9.2 Options for mapping specializations (or generalizations) to relations. (a) Mapping the EER schema of Figure 4.4 to relations by using Option A. (b) Mapping the EER schema of Figure 4.3(b) into relations by using Option B. (c) Mapping the EER schema of Figure 4.4 by using Option C, with JobType playing the role of type attribute. (d) Mapping the EER schema of Figure 4.5 by using Option D, with two Boolean type fields Mflag and Pflag. (a) EMPLOYEE SSN FName MInit LName BirthDate Address JobType SECRETARY SSN TypingSpeed TECHNICIAN SSN TGrade ENGINEER SSN EngType (b) CAR VehicleId LicensePlateNo Price MaxSpeed NoOfPassengers TRUCK VehicleId LicensePlateNo Price NoOfAxles Tonnage (c) EMPLOYEE SSN FName MInit LName BirthDate Address JobType TypingSpeed TGrade EngType (d) PART PartNo Description MFlag DrawingNo ManufactureDate BatchNo PFlag SupplierName ListPrice Addison Wesley Longman, Inc. 2000, Elmasri/Navathe, Fundamentals of Database Systems, Third Edition

Option 8c (Single Relation Option) Create a single relation L with attributes Attrs(L) = {K, A 1,, A n } U and PK(L)=K {attributes of S 1 } U U {attributes of S m } U {T} This option is for specialization whose subclasses are DISJOINT, and T is a type attribute that indicates the subclass to which each tuple belongs, if any. This option may generate a large number of null values. Not recommended if many specific attributes are defined in subclasses (will result in many null values!) Chapter 9 13

Figure 9.2 Options for mapping specializations (or generalizations) to relations. (a) Mapping the EER schema of Figure 4.4 to relations by using Option A. (b) Mapping the EER schema of Figure 4.3(b) into relations by using Option B. (c) Mapping the EER schema of Figure 4.4 by using Option C, with JobType playing the role of type attribute. (d) Mapping the EER schema of Figure 4.5 by using Option D, with two Boolean type fields Mflag and Pflag. (a) EMPLOYEE SSN FName MInit LName BirthDate Address JobType SECRETARY SSN TypingSpeed TECHNICIAN SSN TGrade ENGINEER SSN EngType (b) CAR VehicleId LicensePlateNo Price MaxSpeed NoOfPassengers TRUCK VehicleId LicensePlateNo Price NoOfAxles Tonnage (c) EMPLOYEE SSN FName MInit LName BirthDate Address JobType TypingSpeed TGrade EngType (d) PART PartNo Description MFlag DrawingNo ManufactureDate BatchNo PFlag SupplierName ListPrice Addison Wesley Longman, Inc. 2000, Elmasri/Navathe, Fundamentals of Database Systems, Third Edition

Option 8d (Single Relation Option) Create a single relation schema L with attributes Attrs(L) = {K, A 1,, A n } U and PK(L)=K {attributes of S 1 } U U {attributes of S m } U {T 1,, T n } This option is for specialization whose subclasses are overlapping, and each T i, 1 < i < m, is a Boolean attribute indicating whether a tuple belongs to subclass S i. This option could be used for disjoint subclasses too. Chapter 9 14

Figure 9.2 Options for mapping specializations (or generalizations) to relations. (a) Mapping the EER schema of Figure 4.4 to relations by using Option A. (b) Mapping the EER schema of Figure 4.3(b) into relations by using Option B. (c) Mapping the EER schema of Figure 4.4 by using Option C, with JobType playing the role of type attribute. (d) Mapping the EER schema of Figure 4.5 by using Option D, with two Boolean type fields Mflag and Pflag. (a) EMPLOYEE SSN FName MInit LName BirthDate Address JobType SECRETARY SSN TypingSpeed TECHNICIAN SSN TGrade ENGINEER SSN EngType (b) CAR VehicleId LicensePlateNo Price MaxSpeed NoOfPassengers TRUCK VehicleId LicensePlateNo Price NoOfAxles Tonnage (c) EMPLOYEE SSN FName MInit LName BirthDate Address JobType TypingSpeed TGrade EngType (d) PART PartNo Description MFlag DrawingNo ManufactureDate BatchNo PFlag SupplierName ListPrice Addison Wesley Longman, Inc. 2000, Elmasri/Navathe, Fundamentals of Database Systems, Third Edition

Figure 9.3 Mapping the EER specialization lattice shown in Figure 4.7 using multiple options. PERSON SSN Name BirthDate Sex Address EMPLOYEE SSN Salary EmployeeType Position Rank PercentTime RAFlag TAFlag Project Course ALUMNUS SSN ALUMNUS_DEGREES SSN Year Degree Major STUDENT SSN MajorDept GradFlag UndergradFlag DegreeProgram Class StudAssistFlag Addison Wesley Longman, Inc. 2000, Elmasri/Navathe, Fundamentals of Database Systems, Third Edition

Option 8A for PERSON/{EMPLOYEE,ALUMNUS,STUDENT} Option 8C for EMPLOYEE/{STAFF,FACULTY,STUDENT_ASSISTANT} Option 8D for STUDENT_ASSISTANT/{RESEARCH_ASSISTANT, TEACHING_ASSISTANT} STUDENT/{STUDENT_ASSISTANT} STUDENT/{GRADUATE_ASSISTANT, UNDERGRADUATE_STUDENT}