Lecture 09. Spring 2018 Borough of Manhattan Community College

Similar documents
Entity Relationship Modeling

Chapter 12. Entity-Relationship Modeling

Lecture 10. Spring 2018 Borough of Manhattan Community College

Using High-Level Conceptual Data Models for Database Design A Sample Database Application Entity Types, Entity Sets, Attributes, and Keys

Conceptual Database Design

SOLUTIONS TO REVIEW QUESTIONS AND EXERCISES FOR PART 3 - DATABASE ANALYSIS AND DESIGN (CHAPTERS 10 15)

COMP102: Introduction to Databases, 9.1

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

LECTURE 3: ENTITY-RELATIONSHIP MODELING

Elements of the E-R Model

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

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

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

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

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

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

Lecture 03. Spring 2018 Borough of Manhattan Community College

A l Ain University Of Science and Technology

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

COSC 304 Introduction to Database Systems. Entity-Relationship Modeling

Agenda: Understanding Relationship Types Degree and Cardinality with Examples

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

A l Ain University Of Science and Technology

Chapter 6: Entity-Relationship Model

Lecture 03. Fall 2017 Borough of Manhattan Community College

Represent entities and relations with diagrams

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

Multiple Choice Questions

The Entity-Relationship Model. The Entity-Relationship model. The ER model. The Entity-Relationship model. E-R Model Constructs. E-R Model Constructs

Chapter 3 Database Modeling and Design II. Database Modeling

Lecture3: Data Modeling Using the Entity-Relationship Model.

Information Technology Audit & Cyber Security

Relational Model (cont d) & Entity Relational Model. Lecture 2

Chapter 4. In this chapter, you will learn:

Data Modeling Using the Entity-Relationship (ER) Model

Chapter 2: Entity-Relationship Model. Entity Sets. Entity Sets customer and loan. Attributes. Relationship Sets. A database can be modeled as:

Database Systems. Overview - important points. Lecture 5. Some introductory information ERD diagrams Normalization Other stuff 08/03/2015

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

Design Process Modeling Constraints E-R Diagram Design Issues Weak Entity Sets Extended E-R Features Design of the Bank Database Reduction to

Copyright 2016 Ramez Elmasr and Shamkant B. Navathei

Unit 2 - Data Modeling. Pratian Technologies (India) Pvt. Ltd.

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

Chapter # 4 Entity Relationship (ER) Modeling

Intro to DB CHAPTER 6

Chapter 2: Entity-Relationship Model

Objectives of logical design... Transforming the ERD diagram into relations. Relational database components. Mapping a composite attribute

Lecture 07. Spring 2018 Borough of Manhattan Community College

Chapter 7: Entity-Relationship Model

COMP102: Introduction to Databases, 13

Database Management System 5 ER Modeling

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

Conceptual Data Models for Database Design

Modern Systems Analysis and Design Seventh Edition

Chapter 2 Conceptual Modeling. Objectives

The Entity Relationship Model

Example: specific person, company, event, plant

Data Analysis 1. Chapter 2.1 V3.1. Napier University Dr Gordon Russell

A database can be modeled as: + a collection of entities, + a set of relationships among entities.

Entity Relationship Modelling

CMPT 354 Database Systems I

CS352 Lecture - The Entity-Relationship Model

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

Chapter 7: Entity-Relationship Model

Lecture 14 of 42. E-R Diagrams, UML Notes: PS3 Notes, E-R Design. Thursday, 15 Feb 2007

Chapter 6: Entity-Relationship Model

Chapter 7: Entity-Relationship Model

ER Model. Objectives (2/2) Electricite Du Laos (EDL) Dr. Kanda Runapongsa Saikaew, Computer Engineering, KKU 1

The En'ty Rela'onship Model

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

Chapter 7: Entity-Relationship Model

MIT Database Management Systems Lesson 03: Entity Relationship Diagrams

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

Related download: Instructor Manual for Modern Database Management 12th Edition by Hoffer Venkataraman Topi (Case studies included)

Chapter 17. Methodology Logical Database Design for the Relational Model


Entity-Relationship Model &

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

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

More on the Chen Notation

Entity-Relationship Model

CSIT5300: Advanced Database Systems

David M. Kroenke and David J. Auer Database Processing Fundamentals, Design, and Implementation

Full file at

Database Management System 6 ER Modeling...

Unified Modeling Language (UML) Class Diagram

Chapter 6: Entity-Relationship Model

Conceptual Modeling in ER and UML

DATA MODELING USING THE ENTITY-RELATIONSHIP MODEL. 1 Powered by POeT Solvers Limited

IS 263 Database Concepts

Other Relational Languages

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

CMP-3440 Database Systems

Chapter 2 ENTITY RELATIONSHIP MODEL

COIS Databases

SOFTWARE ENGINEERING Prof.N.L.Sarda Computer Science & Engineering IIT Bombay. Lecture #10 Process Modelling DFD, Function Decomp (Part 2)

OVERVIEW OF DATABASE DEVELOPMENT

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

COMP Instructor: Dimitris Papadias WWW page:

CS403- Database Management Systems Solved Objective Midterm Papers For Preparation of Midterm Exam

KDI EER: The Extended ER Model

Transcription:

Lecture 09 Spring 2018 Borough of Manhattan Community College 1

Entity Relationship Modeling The Entity Relationship (ER) is a nontechnical communication model that describes the nature of the data and how it is used by the enterprise. The Entity Relationship modeling begins by identifying the important data called entities and relationships between the data that must be represented in the model. We then add more details, such as the information we want to hold about the entities and relationships called attributes and any constraints on the entities, relationships, and attributes. 2

Entity Types Entity type: A group of objects with the same properties, which are identified by the enterprise as having an independent existence. The basic concept of the ER model is the entity type, which represents a group of objects in the real world with the same properties. An entity type has an independent existence and can be objects with physical existence or objects with conceptual existence. Examples of entities with physical and conceptual existences. 3

Entity Types A database normally contains many different entity types. We identify each entity type by a name and a list of properties. Diagrammatic representation of entity types: Each entity type is shown as a rectangle, labeled with the name of the entity. In UML (Unified Modeling Language), the first letter of each word in the entity name is uppercase (for example, Staff and PropertyForRent). Entity occurrence: A uniquely identifiable object of an entity type. 4

Relationship Types Relationship type: A set of meaningful associations among entity types. A relationship type is a set of associations between one or more participating entity types. Each relationship type is given a name that describes its function. Relationship occurrence: A uniquely identifiable association that includes one occurrence from each participating entity type. A relationship occurrence indicates the particular entity occurrences that are related. 5

Relationship Types Consider a relationship type called Has, which represents an association between Branch and Staff entities, that is Branch Has Staff. Each occurrence of the Has relationship associates one Branch entity occurrence with one Staff entity occurrence. We can examine examples of individual occurrences of the Has relationship using a semantic net. A semantic net is an object-level model, which uses the symbol to represent entities and the symbol to represent relationships. 6

Relationship Types Relationships are represented by lines that join each participating Branch occurrence with the associated Staff occurrence. 7

Relationship Types If we represented an enterprise using semantic nets, it would be difficult to understand, due to the level of details. We can more easily represent the relationships between entities in an enterprise using the concepts of the ER model. The ER model uses a higher level of abstraction than the semantic net by combining sets of entity occurrences into entity types and sets of relationship occurrences into relationship types. 8

Relationship Types Diagrammatic representation of relationship types: Each relationship type is shown as a line connecting the associated entity types and labeled with the name of the relationship. A relationship is named using a verb (for example, Supervises or Manages) or a short phrase including a verb (for example, LeasedBy). Again, the first letter of each word in the relationship name is shown in uppercase. A relationship name should be unique for a given ER model. 9

Relationship Types A relationship is only labeled in one direction, which normally means that the name of the relationship only makes sense in one direction (for example, Branch Has Staff makes more sense than Staff Has Branch). Once the relationship name is chosen, an arrow symbol is placed beside the name indicating the correct direction for a reader to interpret the relationship name (for example, Branch Has Staff). 10

Degree of Relationship Type The entities involved in a particular relationship type are referred to as participants in that relationship. The number of participants in a relationship type is called the degree of that relationship. A relationship of degree two is called binary. An example of a binary relationship is the Has relationship with two participating entity types; namely, Staff and Branch. 11

Representation of Complex Relationships A relationship of degree three is called ternary. An example of a ternary relationship is Registers with three participating entity types: Staff, Branch, and Client. The UML notation uses a diamond to represent complex relationships relationships with degrees higher than binary. The name of the relationship is displayed inside the diamond, and in this case, the directional arrow normally associated with the name is omitted. 12

Representation of Complex Relationships 13

Recursive Relationship Recursive relationship: A relationship type in which the same entity type participates more than once in different roles. Relationships may be given role names to indicate the purpose that each participating entity type plays in a relationship. Recursive relationships are called unary relationships. 14

Role names may also be used when two entities are associated through more than one relationship. For example, the Staff and Branch entity types are associated through two distinct relationships called Manages and Has. Role names are usually not required if the function of the participating entities in a relationship is unambiguous. 15

Attributes Attribute: A property of an entity or a relationship type. For example, a Staff entity type may be described by the staffno, name, position, and salary attributes. The attributes hold values that describe each entity occurrence and represent the main part of the data stored in the database. A relationship type that associates entities can also have attributes similar to those of an entity type. Each attribute is associated with a set of values called a domain. 16

Representation of Attributes If an entity type is to be displayed with its attributes, we divide the rectangle representing the entity in two. The upper part of the rectangle displays the name of the entity and the lower part lists the names of the attributes. The first attribute(s) to be listed is the primary key for the entity type. The name(s) of the primary key attribute(s) can be labeled with the tag {PK}. In UML, the name of an attribute is displayed with the first letter in lowercase and with the first letter of each subsequent word in uppercase if the name has more than one word (for example, address and telno). 17

Representation of Attributes 18

Representation of Attributes For some simpler database systems, it is possible to show all the attributes for each entity type in the ER diagram. However, for more complex database systems, we just display the attribute, or attributes, that form the primary key of each entity type. When only the primary key attributes are shown in the ER diagram, we can omit the {PK} tag. For composite attributes, we list the name of the composite attribute followed below and indented to the right by the names of its simple component attributes. For multivalued attributes, we label the attribute name with an indication of the range of values available for the attribute. For example, the telno attribute holds one to a maximum of three values, we can label the attribute with [1..3]. For derived attributes, we prefix the attribute name with a "/". 19

Attributes on Relationships Attributes can also be assigned to relationships. For example, consider the relationship Advertises, which associates the Newspaper and PropertyForRent entity types. To record the date the property was advertised and the cost, we associate this information with the Advertises relationship as attributes called dateadvert and cost, rather than with the Newspaper or the PropertyForRent entities. 20

Representation of Attributes on Relationships We represent attributes associated with a relationship type using the same symbol as an entity type. However, to distinguish between a relationship with an attribute and an entity, the rectangle representing the attribute(s) is associated with the relationship using a dashed line. 21

Structural Constraints We now examine the constraints that may be placed on entity types that participate in a relationship. Examples: - A property for rent must have an owner. - Each branch must have staff. - A staff may manage a branch. Multiplicity: The number (or range) of possible occurrences of an entity type that relate to a single occurrence of an associated entity type through a particular relationship. 22

Structural Constraints Binary relationships are generally referred to as being: one-to-one (1:1), one-to-many (1:*), or many-to-many (*:*). We examine these three types of relationships using the following integrity constraints: a member of staff manages a branch (1:1); a member of staff oversees properties for rent (1:*); newspapers advertise properties for rent (*:*). 23

One-to-One (1:1) Relationships Consider the relationship Manages, which relates the Staff and Branch entity types. A member of staff can manage zero or one branch and each branch is managed by one member of staff. 24

Representation of (1:1) Relationships As there is a maximum of one branch for each member of staff involved in this relationship and a maximum of one member of staff for each branch, we refer to this type of relationship as one-to-one, which we abbreviate as (1:1). 25

One-to-Many (1:*) Relationships Consider the relationship Oversees, which relates the Staff and PropertyForRent entity types. A member of staff can oversee zero or more properties for rent and a property for rent is overseen by zero or one member of staff. 26

Representation of (1:*) Relationships For members of staff there are many properties for rent, and for properties there is a maximum of one member of staff. We refer to this type of relationship as one-to-many, which we abbreviate as (1:*). If we know the actual minimum and maximum values for the multiplicity, we can display these instead. For example, we can replace the "0..* with "0..100". 27

Many-to-Many (*:*) Relationships Consider the relationship Advertises, which relates the Newspaper and PropertyForRent entity types. A newspaper advertises one or more properties for rent and one property for rent is advertised in zero or more newspapers. 28

Representation of (*:*) Relationships For newspapers there are many properties for rent, and for each property for rent there are many newspapers. We refer to this type of relationship as many-to-many, which we abbreviate as (*:*). 29

Structural Constraints A summary of the possible ways that multiplicity constraints can be represented along with a description of the meaning: 30

Exercise Create an ER model for the following descriptions: A large organization has several parking lots, which are used by staff. Each member of staff has a unique number, name, telephone extension number, and vehicle license number. Each parking lot has a unique name, location, capacity, and number of floors. Each parking lot has parking spaces, which are uniquely identified using a space number. Members of staff can request the sole use of a single parking space. 33