COSC 304 Introduction to Database Systems Enhanced Entity-Relationship (EER) Modeling

Similar documents
COSC 304 Introduction to Database Systems. Entity-Relationship Modeling

COSC 304 Introduction to Database Systems SQL. Dr. Ramon Lawrence University of British Columbia Okanagan

Conceptual Database Design. COSC 304 Introduction to Database Systems. Entity-Relationship Modeling. Entity-Relationship Modeling

COSC 122 Computer Fluency. Databases. Dr. Ramon Lawrence University of British Columbia Okanagan

COSC 304 Introduction to Database Systems. Views and Security. Dr. Ramon Lawrence University of British Columbia Okanagan

Key Points. COSC 122 Computer Fluency. Databases. What is a database? Databases in the Real-World DBMS. Database System Approach

Relational Model History. COSC 416 NoSQL Databases. Relational Model (Review) Relation Example. Relational Model Definitions. Relational Integrity

Views. COSC 304 Introduction to Database Systems. Views and Security. Creating Views. Views Example. Removing Views.

Database Design Process

Entity Relationship Data Model. Slides by: Shree Jaswal

SQL Queries. COSC 304 Introduction to Database Systems SQL. Example Relations. SQL and Relational Algebra. Example Relation Instances

Chapter 9: Relational DB Design byer/eer to Relational Mapping Relational Database Design Using ER-to- Relational Mapping Mapping EER Model

COIS Databases

Data Modeling Using the Entity-Relationship (ER) Model

Why Relational Databases? Relational databases allow for the storage and analysis of large amounts of data.

Conceptual Data Models for Database Design

Chapter 4. Enhanced Entity- Relationship Modeling. Enhanced-ER (EER) Model Concepts. Subclasses and Superclasses (1)

COSC 304 Introduction to Database Systems SQL DDL. Dr. Ramon Lawrence University of British Columbia Okanagan

COSC Dr. Ramon Lawrence. Emp Relation

Overview of Database Design Process. Data Modeling Using the Entity- Relationship (ER) Model. Two main activities:

Chapter Outline. Note 1. Overview of Database Design Process Example Database Application (COMPANY) ER Model Concepts

Overview of Database Design Process Example Database Application (COMPANY) ER Model Concepts

Copyright 2016 Ramez Elmasr and Shamkant B. Navathei

Relational Model History. COSC 304 Introduction to Database Systems. Relational Model and Algebra. Relational Model Definitions.

Copyright 2016 Ramez Elmasri and Shamkant B. Navathe

Data Modeling with the Entity Relationship Model. CS157A Chris Pollett Sept. 7, 2005.

COSC 404 Database System Implementation. Query Processing. Dr. Ramon Lawrence University of British Columbia Okanagan

CS 2451 Database Systems: Database and Schema Design

Chapter 8: Enhanced ER Model

Chapter (4) Enhanced Entity-Relationship and Object Modeling

Chapter 8 The Enhanced Entity- Relationship (EER) Model

Database Design Process. Requirements Collection & Analysis

Relational DB Design by ER- and EER-to-Relational Mapping Design & Analysis of Database Systems

Enhanced Entity- Relationship Models (EER)

XML. COSC Dr. Ramon Lawrence. An attribute is a name-value pair declared inside an element. Comments. Page 3. COSC Dr.

Chapter 2: Entity-Relationship Model

Lecture3: Data Modeling Using the Entity-Relationship Model.

LECTURE 3: ENTITY-RELATIONSHIP MODELING


High Level Database Models

LELCTURE 4: ENHANCED ENTITY-RELATIONSHIP MODELING (EER)

Database Systems. A Practical Approach to Design, Implementation, and Management. Database Systems. Thomas Connolly Carolyn Begg

Enhanced Entity-Relationship (EER) Modeling

Chapter 6: Entity-Relationship Model

Chapter 6: Entity-Relationship Model

Database Systems ER Model. A.R. Hurson 323 CS Building

Intro to DB CHAPTER 6

DATABASE DESIGN I - 1DL300

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

Entity-Relationship Model

Querying XML. COSC 304 Introduction to Database Systems. XML Querying. Example DTD. Example XML Document. Path Descriptions in XPath

Chapter 6: Entity-Relationship Model

Data Modeling Using the Entity-Relationship Model

Entity-Relationship Models

Data Modeling Using the Entity- Relationship Model Design & Analysis of Database Systems

DATABASE DESIGN I - 1DL300

Entity-Relationship Modelling. Entities Attributes Relationships Mapping Cardinality Keys Reduction of an E-R Diagram to Tables

COMP102: Introduction to Databases, 13

Copyright 2007 Ramez Elmasri and Shamkant B. Navathe Slide 4-1

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

MIS Database Systems Entity-Relationship Model.

OVERVIEW OF DATABASE DEVELOPMENT

Note that it works well to answer questions on computer instead of on the board.

CS 338 The Enhanced Entity-Relationship (EER) Model

CSE 530A. ER Model. Washington University Fall 2013

Chapter 7 Relational Database Design by ER- and EERR-to-Relational Mapping

1/24/2012. Chapter 7 Outline. Chapter 7 Outline (cont d.) CS 440: Database Management Systems

Database Principles: Fundamentals of Design, Implementation, and Management Tenth Edition. Chapter 7 Data Modeling with Entity Relationship Diagrams

Contents. Database. Information Policy. C03. Entity Relationship Model WKU-IP-C03 Database / Entity Relationship Model

Entity-Relationship Model. Dr. Samaresh Mishra, School of Computer Engineering, KIIT University, Bhubaneswar

CS 2451 Database Systems: SQL

Chapter 7: Entity-Relationship Model

COSC 304 Introduction to Database Systems. Database Introduction. Dr. Ramon Lawrence University of British Columbia Okanagan

The Next Step: Designing DB Schema. Chapter 6: Entity-Relationship Model. The E-R Model. Identifying Entities and their Attributes.

Overview of db design Requirement analysis Data to be stored Applications to be built Operations (most frequent) subject to performance requirement

Outline. Note 1. CSIE30600 Database Systems ER/EER to Relational Mapping 2

CS 2451 Database Systems: Entity-Relationship (ER) Model Algebra

Conceptual Design. The Entity-Relationship (ER) Model

CMP-3440 Database Systems

Overview. Introduction to Database Design. ER Model. Database Design

Relational Database Systems Part 01. Karine Reis Ferreira

Chapter 7: Entity-Relationship Model

Chapter 7: Entity-Relationship Model

Database Management

DATABASDESIGN FÖR INGENJÖRER F

Chapter 2 ENTITY RELATIONSHIP MODEL

Lecture 10. Spring 2018 Borough of Manhattan Community College

COSC 304 Introduction to Database Systems. Advanced SQL. Dr. Ramon Lawrence University of British Columbia Okanagan

CS 4604: Introduction to Database Management Systems. B. Aditya Prakash Lecture #5: Entity/Relational Models---Part 1

Database Management System (15ECSC208) UNIT I: Chapter 2: Relational Data Model and Relational Algebra

course 3 Levels of Database Design CSCI 403 Database Management Mines Courses ERD Attributes Entities title 9/26/2018

Bottom line: A database is the data stored and a database system is the software that manages the data. COSC Dr.

Chapter 6: Entity-Relationship Model. The Next Step: Designing DB Schema. Identifying Entities and their Attributes. The E-R Model.

Relational Model. CS 377: Database Systems

Conceptual Database Design

Identifying entities. Another relationship. Continue exploring our first model for databases: Entity-relationship (ER) model. Identifying entities

Unified Modeling Language (UML)

Advance Database Management System

High-Level Database Models (ii)

The Entity-Relationship Model. Steps in Database Design

Transcription:

COSC 304 Introduction to Database Systems Enhanced Entity-Relationship (EER) Modeling Dr. Ramon Lawrence University of British Columbia Okanagan ramon.lawrence@ubc.ca

Enhanced Entity-Relationship Modeling Enhanced Entity-Relationship (EER) modeling is an extension of ER modeling to include object-oriented concepts such as: superclasses and subclasses specialization and generalization aggregation and composition These modeling constructs may allow more precise modeling of systems that are object-oriented in nature such as: CAD/CAM systems (Computer-Aided Design/Manufacturing) GIS (Geographical Information Systems) Page 2

Review: Superclasses and Subclasses The object-oriented ideas of inheritance and superclasses and subclasses are taught during programming in an OO language such as Java. A superclass is a general class that is extended by one or more subclasses. A subclass is a more specific class that extends a superclass by inheriting its methods and attributes and then adding its own methods and attributes. Inheritance is the process of a subclass inheriting all the methods and attributes of a superclass. Page 3

Superclasses and Subclasses Example Java code: public class SavingsAccount extends BankAccount UML class diagram: BankAccount number balance Triangle points to superclass SavingsAccount interestrate Page 4

Superclasses and Subclasses Question Question: How many of the following statements are true? W B X Y A Z C 1) D is a superclass. 2) D has 1 attribute. 3) B and C are subclasses of A. 4) B inherits V from D. 5) D inherits attribute X. V D A) 0 B) 1 C) 2 D) 3 E) 4 Page 5

When to use EER Modeling? It is important to emphasize that many database projects do not need the object-oriented modeling features of EER modeling. Remember the goal of conceptual modeling is to produce a model that is simple and easy to understand. Do not introduce complicated subclass/superclass relationships if they are not needed. Only use the EER modeling constructs if they offer a significant advantage over regular ER modeling. Page 6

When to use EER Modeling? (2) EER modeling is especially useful when the domain being modeled is object-oriented in nature and the use of inheritance reduces the complexity of the design. There are two common cases where EER modeling is useful instead of basic ER modeling: 1) When using attribute inheritance can reduce the use of nulls in a single entity relation (that contains multiple subclasses). 2) Subclasses can be used to explicitly model and subsets of entity types that participate in their own relationships. Page 7

When to use EER Modeling? Using Attribute Inheritance COSC 304 - Dr. Ramon Lawrence Emp Relation eno e bdate title salary supereno dno E1 J. Doe 01-05-75 EE 30000 E2 null E2 M. Smith 06-04-66 SA 50000 E5 D3 E3 A. Lee 07-05-66 ME 40000 E7 D2 E4 J. Miller 09-01-50 PR 20000 E6 D3 E5 B. Casey 12-25-71 SA 50000 E8 D3 E6 L. Chu 11-30-65 EE 30000 E7 D2 E7 R. Davis 09-08-77 ME 40000 E8 D1 E8 J. Jones 10-11-72 SA 50000 null D1 Note that the title attribute indicates what job the employee does at the company. Consider if each job title had its own unique information that we would want to record such as: EE, PR - programming language used (lang), DB used (db) SA, ME - MBA? (MBA), bonus Page 8

When to use EER Modeling? Using Attribute Inheritance (2) COSC 304 - Dr. Ramon Lawrence We could represent all these attributes in a single relation: eno e bdate title salary supereno dno lang db MBA bonus E1 J. Doe 01-05-75 EE 30000 E2 C++ MySQL E2 M. Smith 06-04-66 SA 50000 E5 D3 N 2000 E3 A. Lee 07-05-66 ME 40000 E7 D2 N 3000 E4 J. Miller 09-01-50 PR 20000 E6 D3 Java Oracle E5 B. Casey 12-25-71 SA 50000 E8 D3 Y 4000 E6 L. Chu 11-30-65 EE 30000 E7 D2 C++ DB2 E7 R. Davis 09-08-77 ME 40000 E8 D1 N 3000 E8 J. Jones 10-11-72 SA 50000 D1 Y 6000 Note the wasted space as attributes that do not apply to a particular subclass are NULL. Page 9

When to use EER Modeling? Using Attribute Inheritance (3) COSC 304 - Dr. Ramon Lawrence A better solution would be to make two subclasses of Employee called Developer and Manager: Employee eno {PK} bdate title salary supereno dno lang db Developer MBA bonus Manager Page 10

When to use EER Modeling? Using Attribute Inheritance (4) COSC 304 - Dr. Ramon Lawrence Resulting relations: Employee Relation eno e bdate title salary supereno dno E1 J. Doe 01-05-75 EE 30000 E2 null E2 M. Smith 06-04-66 SA 50000 E5 D3 E3 A. Lee 07-05-66 ME 40000 E7 D2 E4 J. Miller 09-01-50 PR 20000 E6 D3 E5 B. Casey 12-25-71 SA 50000 E8 D3 E6 L. Chu 11-30-65 EE 30000 E7 D2 E7 R. Davis 09-08-77 ME 40000 E8 D1 E8 J. Jones 10-11-72 SA 50000 null D1 Developer Relation eno lang db E1 C++ MySQL E4 Java Oracle E6 C++ DB2 Manager Relation eno MBA bonus E2 N 2000 E3 N 3000 E5 Y 4000 E7 N 3000 E8 Y 6000 Page 11

Generalization and Specialization Subclasses and superclasses are created by using either generalization or specialization. Specialization is the process of creating more specialized subclasses of an existing superclass. Top-down process: Start with a general class and then subdivide it into more specialized classes. The specialized classes may contain their own attributes. Attributes common to all subclasses remain in the superclass. Generalization is the process of creating a more general superclass from existing subclasses. Bottom-up process: Start with specialized classes and try to determine a general class that contains the attributes common to all of them. Page 12

Specialization Example Employee superclass Employee eno {PK} bdate title salary supereno dno lang db MBA bonus General class - specialize into subclasses eno {PK} bdate title salary supereno dno Indicates specialization/ generalization lang db Developer MBA bonus Manager subclasses Page 13

Generalization Example Developer number {PK} developername birthdate title salary supereno dno lang db Manager eno {PK} birthdate title salary supereno dno MBA bonus Specific classes - generalize to create superclass lang db Developer Employee eno {PK} bdate title salary supereno dno subclasses MBA bonus Indicates specialization/ generalization Manager superclass Page 14

Constraints on Generalization and Specialization There are two types of constraints associated with generalization and specialization: COSC 304 - Dr. Ramon Lawrence Participation constraint - determines if every member in a superclass must participate as a member of one of its subclasses. It may be optional for a superclass member to be a member of one of its subclasses, or it may be mandatory that a superclass member be a member of one of its subclasses. Disjoint constraint - determines if a member of a superclass can be a member of one or more than one of its subclasses. If a superclass object may be a member of only one of its subclasses this is denoted by OR (subclasses are disjoint). Otherwise, AND is used to indicate that it may be in more than one of its subclasses. Page 15

Constraints Example An employee must be either a developer or a manager, but cannot be both. Employee eno {PK} bdate title salary supereno dno {Mandatory, OR} Participation constraint (must be developer or manager) Disjoint constraint (cannot be both a developer and a manager) lang db Developer MBA bonus Manager Page 16

Constraints Example (2) An employee may specialize as a developer or manager. An employee may be both a manager and developer. Employee eno {PK} bdate title salary supereno dno {Optional, AND} Participation constraint (may be developer or manager) Disjoint constraint (can be both a developer and a manager) lang db Developer MBA bonus Manager Page 17

General Predicate Constraints Predicate-defined constraints specify when an object participates in a subclass using a certain rule. For example, a subclass called RichEmployees can be defined with a membership predicate such as salary >100000. Attribute-defined subclasses are a particular type of predicate-defined constraint where the value of an attribute(s) determines if an object is a member of a subclass. For example, the title field could be used as a defining attribute for the Developer and Manager subclasses. Emp is in Developer if title = 'EE' or 'PR' Emp is in Manager if title = 'ME' or 'SA' Page 18

Constraints Question Employee E1 E2 E3 E4 E5 E6 E7 E2 E5 E6 E7 E8 E5 E7 Manager Supervisor E8 E8 Note: What is the participation and the disjoint constraints for superclass Employee (with subclasses Manager and Supervisor) given these instances? Page 19

Relationship Constraints vs. Inheritance Constraints COSC 304 - Dr. Ramon Lawrence There is a parallel between relationship constraints on associations/relationships and inheritance constraints on superclasses and subclasses. Minimum # of occurrences called participation constraint in both cases Maximum # of occurrences called cardinality constraint for relationships and disjoint constraint for subclasses Possible combinations: Subclass Constraints Optional, AND 0..* Optional, OR 0..1 Mandatory, AND 1..* Mandatory, OR 1..1 Relationship Constraints Page 20

EER Question Question: How many of the following statements are true? 1) Generalization is a bottom-up process. 2) In an UML diagram, the inheritance arrow points towards the superclass. 3) OPTIONAL and MANDATORY are possible choices for the participation constraint. 4) If the disjoint constraint is AND, a given object can be a member of multiple subclasses. 5) If the participation constraint is OPTIONAL, the disjoint constraint must be AND. A) 0 B) 1 C) 2 D) 3 E) 4 Page 21

Multiple Inheritance If each class only has one superclass, then the class diagram is said to be a specialization or type hierarchy. If a class may have more than one superclass, then the class diagram is said to be a specialization or type lattice. Although multiple inheritance is powerful, it should be avoided if possible. Page 22

Multiple Inheritance Example Employee eno {PK}. {Optional, OR} lang db Developer MBA bonus Manager {Optional} DeveloperManager project projectduedate Page 23

Aggregation Aggregation represents a 'HAS-A' or 'IS-PART-OF' relationship between entity types. One entity type is the whole, the other is the part. Example: Employee eno {PK} bdate title salary supereno dno 0..* Has 0..1 Department number {PK} Diamond on the side of the whole entity. Department has employees. 'whole' entity 'part' entity Page 24

Composition Composition is a stronger form of aggregation where the part cannot exist without its containing whole entity type and the part can only be part of one entity type. Example: Project number {PK} budget location [1..3] /totalemp 'part' entity 0..* Has 1..1 Department number {PK} 'whole' entity Filled diamond on the side of the whole entity to indicate composition. Project must have only one department. Note: The min-max constraint on the whole side of the relationship (in this case department) must always be 1..1 when modeling composition. Why? Page 25

Original ER Model Example Supervises Supervisee 0..* 0..1 Supervisor Employee number {PK} address state city street title salary Manages 0..1 0..* Has 0..* WorksOn 0..1 0..* 0..* responsibility hours Department number {PK} 0..1 0..* Project Has number {PK} budget location [1..3] /totalemp Page 26

EER Model Example Supervisor 0..1 {Optional, AND} 0..* Supervises Employee number {PK} address state city street title salary Manager 0..* 0..1 Has WorksOn 0..1 0..* 0..* responsibility hours Manages Department number {PK} 0..1 0..* Project 0..* Has number {PK} budget location [1..3] /totalemp Page 27

Conclusion The Enhanced Entity-Relationship model (EER) model allows for object-oriented design features to be captured. Generalization and specialization are two complementary processes for constructing superclasses and subclasses. Participation and disjoint constraints apply to subclasses. Participation of a superclass may be mandatory or optional in a subclass. A superclass may only be a member of one subclass (disjoint constraint indicated by OR) or multiple (indicated by AND). Aggregation and composition are used to model HAS-A or PART-OF relationships. The features of EER modeling are rarely needed in most database design projects. Page 28

Objectives Given an EER diagram, recognize the subclasses, superclasses, and constraints using the notation. Explain the difference between the participation constraint and the disjoint constraint. Explain the difference between aggregation and composition. Given an EER diagram, list the attributes of each class including attributes inherited from superclasses. Page 29