Weak Entity Sets. A weak entity is an entity that cannot exist in a database unless another type of entity also exists in that database.

Similar documents
Entity-Relationship Model

Conceptual Data Models for Database Design

Enhanced Entity- Relationship Models (EER)

Chapter 7: Entity-Relationship Model

LELCTURE 4: ENHANCED ENTITY-RELATIONSHIP MODELING (EER)

Roadmap of This Lecture. Weak Entity Sets Extended E-R Features Reduction to Relation Schemas Database Design UML*

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

Chapter 7: Entity-Relationship Model

Chapter 7: Entity-Relationship Model

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

Chapter 7: Entity-Relationship Model

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

Unit1: Introduction. Database System Concepts, 6 th Ed. Silberschatz, Korth and Sudarshan See for conditions on re-use

Module 2 : Entity-Relationship Model 15

COMP Instructor: Dimitris Papadias WWW page:

Chapter 2: Entity-Relationship Model

More on the Chen Notation

CS 338 The Enhanced Entity-Relationship (EER) Model

COMP 244. ER-Diagram Notations. Entity-Relationship Diagrams DATABASE CONCEPTS & APPLICATIONS. Database Concepts & Applications 1.


Data Modeling and the Entity-Relationship Model

Chapter (4) Enhanced Entity-Relationship and Object Modeling

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

COMP 244 DATABASE CONCEPTS & APPLICATIONS

The En'ty Rela'onship Model

Chapter 2 ENTITY RELATIONSHIP MODEL

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

The Entity-Relationship Model. Steps in Database Design

Chapter 7: Entity-Relationship Model. Chapter 7: Entity-Relationship Model

COIS Databases

CSIT5300: Advanced Database Systems

Relational Database Design Part I. Announcement. Relational model: review. CPS 116 Introduction to Database Systems

MTAT Introduction to Databases

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

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

Database Design Using E/R Model

Chapter 6: Entity-Relationship Model

THE ENHANCED ER (EER) MODEL CHAPTER 8 (6/E) CHAPTER 4 (5/E)

Unit I. By Prof.Sushila Aghav MIT

Chapter 6: Entity-Relationship Model

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

MIS Database Systems Entity-Relationship Model.

Relational Database Design Part I. Announcements (September 5) Relational model: review. CPS 116 Introduction to Database Systems

Intro to DB CHAPTER 6

6.1 RELATIONSHIP CONCEPTS

Entity Relationship Data Model. Slides by: Shree Jaswal

Ch 9: Mapping EER to Relational. Follow a seven-step algorithm to convert the basic ER model constructs into relations steps 1-7

Lecture 10 - Chapter 7 Entity Relationship Model

Conceptual Modeling in ER and UML

Databases Tutorial. January 19,2012 Jing Chen Mcmaster University

Database Design Process

LECTURE 3: ENTITY-RELATIONSHIP MODELING

Chapter 3 Database Modeling and Design II. Database Modeling

Chapter 4. In this chapter, you will learn:

2. E-R Model. Entity Sets Relationship Sets Attributes

ER to Relational Mapping

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

Database Applications (15-415)

Unit 3 Research Project. Eddie S. Jackson. Kaplan University. IT525: Database Design and Data Modeling

Notes. These slides are based on a slide set provided by Prof. M. Tamer Öszu. CS 640 E-R Model Winter / 23. Notes

Lecture3: Data Modeling Using the Entity-Relationship Model.

XV. The Entity-Relationship Model

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

CMPT 354 Database Systems I

Chapter 6: Entity-Relationship Model

CS 146 Database Systems

Database Systems: Design, Implementation, and Management Tenth Edition. Chapter 4 Entity Relationship (ER) Modeling

2004 John Mylopoulos. The Entity-Relationship Model John Mylopoulos. The Entity-Relationship Model John Mylopoulos

Database Systems CSE Comprehensive Exam Spring 2005

3. Advanced E/R Concepts

Enhanced Entity-Relationship (EER) Modeling

Other Relational Languages

UNIT - 1 INTRODUCTION TO DATA BASE

Database Management System (15ECSC208) UNIT I: Chapter 1: Introduction to DBMS and ER-Model

ER modeling. Lecture 4

Databases Model the Real World. The Entity- Relationship Model. Conceptual Design. Steps in Database Design. ER Model Basics. ER Model Basics (Contd.

3. Advanced E/R Concepts

Assignment 3 Translation from ER to Relational & Table Creation By Alexander Joel Heriford

CS425 Fall 2013 Boris Glavic Chapter 7: Entity-Relationship Model!

Essentials of Database Management (Hoffer et al.) Chapter 2 Modeling Data in the Organization

Announcement. Relational Database Design Part I. Keys. Relational model: review. Schema vs. data. More examples of keys

Conceptual Data Modeling and the Entity- Relationship Model. Department of Computer Science Northern Illinois University September 2014

Database Design Process. Requirements Collection & Analysis

Chapter 2. Database Design. Database Systems p. 25/540

Object Modeling. Entity-Relationship (ER) diagrams (1976) Object Modelling Technique (OMT) diagrams (1991)

Lecture 10. Spring 2018 Borough of Manhattan Community College

DATABASE SYSTEMS. Chapter 5 Entity Relationship (ER) Modelling DESIGN IMPLEMENTATION AND MANAGEMENT INTERNATIONAL EDITION ROB CORONEL CROCKETT

Copyright 2016 Ramez Elmasri and Shamkant B. Navathe

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

Database Principles: Fundamentals of Design, Implementation, and Management Tenth Edition. Chapter 8 Data Modeling Advanced Concepts

CS3DB3/SE4DB3/SE6M03 TUTORIAL

E-R Model. Hi! Here in this lecture we are going to discuss about the E-R Model.

Database Design and the E-R Model (7.4, )

26. Object-Oriented Design. Java. Summer 2008 Instructor: Dr. Masoud Yaghini

Database Management Systems

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

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

Database Design with Entity Relationship Model

Entity-Relationship Model &

OO System Models Static Views

Transcription:

Weak Entity Sets A weak entity is an entity that cannot exist in a database unless another type of entity also exists in that database. Weak entity meets two conditions Existence-dependent Cannot exist Implementation, without entity with which it has a and relationship Has primary key that is partially or totally derived from parent entity in relationshipmanagement Weak entities cannot exist without the identifying relationship. Weak entities do not have primary key attribute(s) of their own. They may have partial key. Partial Key: Database Principles: Fundamentals of Design, Tenth Edition Chapter 7 Data Modeling with Entity Relationship Diagrams (Cont.) Portion of the key that comes from the weak entity. The rest of the key comes from the other entity in the relationship.

Objectives In this chapter, students will learn: The main characteristics of weak entities and strong entities How to relate weak entity to its strong entity Rules about identifying relationships The main characteristics of inheritance modelling Constraints of inheritance relationship

Weak Entity Sets A weak entity is an entity that cannot exist in a database unless another type of entity also exists in that database. Weak entity meets two conditions Existence-dependent Cannot exist without entity with which it has a relationship Has primary key that is partially or totally derived from parent entity in relationship Weak entities cannot exist without the identifying relationship. Weak entities do not have primary key attribute(s) of their own. They may have partial key. Partial Key: Portion of the key that comes from the weak entity. The rest of the key comes from the other entity in the relationship.

Weak Entity Sets (cont.) Weak Entity is represented by double rectangle Weak Relationship is represented by double diamonds Many-one (or one-one) relationship sets are required

Weak Entity Sets (cont.) Example: Transactions of different accounts could have the same trans#, so trans# cannot be a key By borrowing attribute number from account, we have a key for transaction. Transaction is a weak entity set related to accounts via log relationship. number balance trans# account log transaction

Weak Entity Sets (cont.) Key of weak entity set = key of strong entity set(s) + partial key number balance trans# amount account log transaction

Chain of Weak Entity Sets governor street Located in city Located in state #ofhome s stname population cityname statename State name forms a key. City names are unique only within a state (e.g., 24 Springfield s within the 50 states). Street names are unique within a city. Multiple cities could have streets with the same name (e.g., Main ). A weak entity set might itself participate as owner in an identifying relationship with another weak entity set.

EXAMPLE Weak entity set examples! Seats in rooms in buildings number capacity name year Rooms In Buildings In number Seats

CASE STUDY Design a database representing cities, counties, and states For states, record name and capital (city) For counties, record name, area, and location (state) For cities, record name, population, and location (county and state) Assume the following: Names of states are unique Names of counties are only unique within a state Names of cities are only unique within a county A city is always located in a single county A county is always located in a single state

DESIGN 1

DESIGN 2

Practice 1 The company organizes many different types of parties for its customers. For all parties, the company assigns a unique id, a party date, start time, finish time and duration. Duration is calculated as the number of hours between start-time and finish-time. Each party is hosted (owned) by exactly one customer. A customer may host many parties. Each customer has a name, an address, a phone number and a unique id. There are many employees working at the company. Each employee has a name, salary and a unique id. A number of meetings are arranged for each party during the organization. Each meeting belongs to exactly one party. For each meeting a meeting date, a comment and a meeting number is recorded. Each meeting is identified by using the meeting number and party id together. Each meeting may contain one or more employees. An employee may be included in zero or more meetings.

Practice 2 A college course is taught by many instructors, and an instructor may teach many courses. A course may have one or more scheduled sections, or may not have a scheduled section. Attributes of COURSE include courseid, coursename, and credits. Courses are identified by courseid. Attribute of a SECTION of a course include courseid, sectionid, semesternumber, year, and instructorid. A Section is belong to only one course. Sections are identified by courseid and sectionid together. Only one instructor is responsible for a given section of a course. An INSTRUCTOR is identified by an instructorid. Additional information we want to store about an instructor includes the lastname, firstname, email address and officenumber.

INHERITANCE MODELLING ISA relationship METHOD I In some problems, we see entities that are types of or specializations/generalized of other entities. For these situations we use inheritance relationship. (Also known as ISA relationship). Nationality name natid Person address Superclass (generalzied) ISA SubClasses (Specialized) cgpa Student Employee salary

EXAMPLE birthday address id What are the keys of: Movie Person name 1. Movie Person 2. Actor IS A 3. Director picture Actor Director

INHERITANCE MODELLING ISA relationsip METHOD II We might have Constraints for the inheritances such as Disjoint or Overlap. CONSTRAINTS WILL BE INDICATED HERE!!!! Nationality natid Person name address Superclass (generalized) SubClasses (Specialized) stdid Student Employee cgpa empno salary

Specialization & Generalization Specialization process of taking an entity and creating several specialized subclasses Generalization process of taking several related entities and creating a general superclass

Specialization constraints Disjointness constraint specialization is disjoint or overlapping Completeness constraint specialization is total or partial

Disjointness constraint Specifies that an entity can be a member of at most one subclass There can be no overlap between the subclasses We use the notation of a d in a circle to symbolize that the subclasses are disjoint

Disjoint constraint

Overlap Entities are able to belong to more than one subclass Notation is an o inside of a circle

Overlap constraint

Completeness Constraint May be total or partial For total, every entity in the superclass must belong to a subclass For partial, entities in the superclass do not need to be part of any subclass Notation for total and partial are the same as in a regular E-R diagram single and double lines

Partial

Total

Examples Account d Saving Account Checking Account An Entity can be either a savings account or a checking account, but cannot be both.

Examples Person o Employee Customer A Person can be both an Employee and a Customer.

Examples Computer o Server Laptop Is it Partial? If yes why? Yes it is Partial. Because, there are some computers that they are neither Server nor Palmtop.

Examples Vehicle d Truck Bus It is Partial, because we can have cars, bike and etc.

Examples Student d Parttime Fulltime It s Total, because we have either part time or full time students. No other options!!!!

Examples Person o partial There can be a Person who is both Student and Employee. (overlap) (A Person may belong to more than one of its subclasses) **partial** Student d total Employee d partial An Employee can t be a Secretary and an Instructor. (disjoint) (Can be Clerk or Doctor or etc ) **partial** Parttime Fulltime Secretary Driver Instructor The Student has to be Parttime or Fulltime. Not BOTH!!! (disjoint) (A Student has to belong to any of its subclasses) **total**

Case Study Design a database consistent with the following: A station has a unique name and an address, and is either an express station or a local station A train has a unique number and an engineer, and is either an express train or a local train A local train can stop at any station An express train only stops at express stations A train can stop at a station for any number of times during a day Train schedules are the same everyday

DESIGN 1

DESIGN 2

Practice 1: There are many students at the university. Students are subdivided into graduate and undergraduate students. Students take a course in a particular semester and receive a grade for their performances. Sometimes students take the same course again in a different semester. There are no limits on how many courses a student can take. Each graduate student has exactly one advisor, who must be a professor, whereas each professor is allowed to be the advisor of at the most 20 students. Courses have a unique course number and a course title. Students and professors have a name and a unique identification no (assume that both professor and student are subclasses of Person Class); students additionally have a gpa, and undergraduate students have many majors. Professors can be students and take courses, but graduate students cannot be undergraduate students. Clearly indicate the Primary Keys.