44220: Database Design & Implementation ER Diagramming

Slides:



Advertisements
Similar presentations
ER Modeling Case Studies
Advertisements

Chapter # 4 BIS Database Systems
Transformation of an ER Model into a Relational Database Schema Translating to Software.
the Entity-Relationship (ER) Model
ER Modeling Case Studies
44220: Database Design & Implementation Avoiding Database Anomalies Ian Perry Room: C49 Tel Ext.: 7287
44238: Dynamic Web-site Development Working with a Remote Database Ian Perry Room:C48 Extension:7287
Chapter 12 Enhanced Entity-Relationship Modeling Transparencies © Pearson Education Limited 1995, 2005.
ENTITY RELATIONSHIP MODELLING
Database Systems: Design, Implementation, and Management Eighth Edition Chapter 4 Entity Relationship (ER) Modeling.
Copyright © 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 7 Data Modeling Using the Entity- Relationship (ER) Model.
Lecture Fourteen Methodology - Conceptual Database Design
Lecture 3 :Database Analysis and Design (II)
Enhanced ER modeling techniques Transparencies
Chapter 4 Entity Relationship (ER) Modeling
Database Systems: Design, Implementation, and Management Tenth Edition
Chapter Five Data Modeling with the Entity-Relationship Model.
Entity/Relationship Modelling
ER Modeling Case Studies
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,
IT 244 Database Management System Data Modeling 1 Ref: A First Course in Database System Jeffrey D Ullman & Jennifer Widom.
CSE314 Database Systems Data Modeling Using the Entity- Relationship (ER) Model Doç. Dr. Mehmet Göktürk src: Elmasri & Navanthe 6E Pearson Ed Slide Set.
44220: Database Design & Implementation Review & Assignment 1
1 Lecture 8 The Data Model. Database Design Process 1) i.d. users views and requirements 2) all requirements are mapped into relational model which is.
Chapter 7 Data Modeling with Entity Relationship Diagrams Database Principles: Fundamentals of Design, Implementation, and Management Tenth Edition.
44220: Database Design & Implementation Logical Data Modelling Ian Perry Room: C48 Tel Ext.: 7287
CSE 441: Systems Analysis & Design
1 ER Modeling BUAD/American University Entity Relationship (ER) Modeling.
Entity Relationship Diagram (ERD) 22 February 2011.
Copyright © 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 7 Data Modeling Using the Entity- Relationship (ER) Model.
Introduction to Database Systems Mapping ER Models to Relational Schemas Irvanizam Zamanhuri, M.Sc Informatics (Computer Science) Study Program Syiah Kuala.
DATABASEMODELSDATABASEMODELS  A database model ◦ defines the logical design of data. ◦ Describes the relationships between different parts of data.
44220: Database Design & Implementation Review & Assignment 2 Ian Perry Room: C49 Tel Ext.: 7287
44220: Database Design & Implementation Implementing Physical Domains Ian Perry Room: C49 Tel Ext.: 7287
1.  An introduction to data modelling  The purpose of data modelling  Modelling data relationships 2.
Chapter 4 Entity Relationship (ER) Modeling.  ER model forms the basis of an ER diagram  ERD represents conceptual database as viewed by end user 
44220: Database Design & Implementation Modelling the ‘Real’ World Ian Perry Room: C41C Ext.: 7287
4 1 Database Systems: Design, Implementation, & Management, 7 th Edition, Rob & Coronel Relationship Degree Indicates number of entities or participants.
Database Systems Module Review
Database Systems: Design, Implementation, and Management Ninth Edition Chapter 4 Entity Relationship (ER) Modeling.
Copyright © 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 7 Data Modeling Using the Entity- Relationship (ER) Model.
AL-MAAREFA COLLEGE FOR SCIENCE AND TECHNOLOGY INFO 232: DATABASE SYSTEMS CHAPTER 4 ENTITY RELATIONSHIP (ER) MODELING Instructor Ms. Arwa Binsaleh 1.
44220: Database Design & Implementation Review & Assignment 2 Ian Perry Room: C41C Tel Ext.: 7287
44220: Database Design & Implementation Implementing Physical Domains Ian Perry Room: C41C Tel Ext.: 7287
Database Design – Lecture 4 Conceptual Data Modeling.
INTRODUCTION TO DATABASE DESIGN. Definitions Database Models: Conceptual, Logical, Physical Conceptual: “big picture” overview of data and relationships.
Database Systems ER Diagramming Tutor:Ian Perry Tel: Web:
44271: Database Design & Implementation Logical Data Modelling (Avoiding Database Anomalies) Ian Perry Room: C49 Tel Ext.: 7287
44220: Database Design & Implementation Conceptual Data Modelling Ian Perry Room: C49 Tel Ext.: 7287
Entity/Relationship Modelling. Entity Relationship Modelling In This Lecture Entity/Relationship models Entities and Attributes Relationships Attributes.
Database Systems Avoiding Database Anomalies Tutor:Ian Perry Tel: Web:
Copyright © 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 7 Data Modeling Using the Entity- Relationship (ER) Model.
Tutorial 2 Data Modelling. 3 Terminology & Notation(1) An entity is an object about which the system needs to hold information –Customer, Student, Course.
DBMS ER model-2 Week 6-7.
44271: Database Design & Implementation Physical Data Modelling Ian Perry Room: C49 Tel Ext.: 7287
Lecture 5 Entity Relationship Modeling
44220: Database Design & Implementation Review & Assignment 2 Ian Perry Room: C41C Tel Ext.: 7287
Data Modeling Using the Entity- Relationship (ER) Model
Entity- Relationship (ER) Model
Enhanced Entity-Relationship Modeling
Enhanced Entity-Relationship Modeling
Entity-Relationship Model
Tables and Their Characteristics
Enhanced ER Modeling Transparencies
Implementation of Entity Relationships
Enhanced Entity-Relationship Modeling
Relationships as Primary & Foreign Keys
Enhanced Entity-Relationship Modeling
Workshop Exercise (Week 6)
Workshop Exercise (Week 6)
Presentation transcript:

44220: Database Design & Implementation ER Diagramming Ian Perry Room: C41C Tel Ext.: 7287 E-mail: I.P.Perry@hull.ac.uk http://itsy.co.uk/ac/0809/sem2/44220_DDI/ 1 1 1 1

Conceptual Data Modelling Process Identify ALL of the relevant Entities. must play a necessary role in the business system. Identify those Attributes that adequately describe each Entity. remember to choose ‘key’ attribute(s). Identify the Relationships between Entities. determine the Degree of each Relationship: determine the Type of each Relationship. attempt to decompose any many-to-many Relationships that you have identified. 21 20 22

Hospital Example Let us suppose that you have been asked to build a Conceptual Data Model for a Hospital. The questions you must ask (and answer?) are as follows: What are the major objects of interest? Entities What details adequately describe each of these objects? Attributes What associations are valid between these objects? Relationships 21 20 22

What are the Entities? i.e. the major objects of interest. Doctor Nurse Ward Patient Medication Operation Clinic etc.

What are the Attributes? i.e. the details that adequately describe each of the Entities. Ward Name, Location, Number of Beds, … Patient Name, Address, Date-of-Birth, Gender, … Doctor Name, Room, Extension, Speciality, … Nurse NB. Perhaps ‘people’ who work in the Hospital could be described using ONE Entity, i.e. Staff?

Entity Definition Syntax: For Example: Always Remember: EntityName (key attribute(s), attribute, ...) For Example: Staff (FirstName, FamilyName, Role, Room, Extension, Speciality, …) Ward (WardName, Location, Number-of-Beds, …) Medication (DrugCode, Type, Dosage, …) Patient (FirstName, FamilyName, DOB, Gender, Street, Town, Post Code, Tel. No., …) Always Remember: to indicate the ‘key’ Attribute(s).

‘Type’ of Relationships? i.e. associations which are valid, in BOTH directions, between pairs of Entities. Patient has Operation. Operation performed on Patient Staff work in Ward Ward employs Staff Ward has beds for Patient Patient stays in Ward Patient attends Clinic Clinic treats Patient Etc.

‘Degree’ of Relationships? One-to-One (1:1) Very rare! One-to-Many (1:M) Quite rare as a ‘real world’ relationship; however, what we require for both Logical and Physical Modelling. Many-to-Many (M:M) Most common as a ‘real world’ relationship; however, impossible to implement Logically or Physically. MUST be decomposed into two One-to-Many relationships linked by an ‘artificial’ Entity. 13 11 13

Occurrence Diagrams? Staff Ward Use these (with values for Key Attributes) to discover how many occurrences of each Entity are actually on either side of a Relationship. Staff Fred Smith Jane Bloggs Arthur Jones Angela Oust Ward Ward 1 Ward 2 Ward 3 M M 1 1

Participation in a Relationship? Mandatory: compulsory attachment on both sides (very rare). Contingent: compulsion on one side only (most common). Optional: no compulsory attachment for either Entity (rare). Inclusive: attachment only occurs when another relationship exists (very rare). Exclusive: only one attachment from a set of possible relationships is permitted (quite rare).

Degree, Type & Participation - 1 One-to-Many, Contingent (compulsion one side) Ward Patient has beds for => 1 M <= stays in Clinic Patient treats => 1 M <= attends One-to-Many, Contingent (compulsion one side) NB. a Patient can NOT both be staying in a Ward AND attending the Clinic, so these two Relationships are also Exclusive. 21 19

Degree, Type & Participation - 2 Many-to-Many, Contingent (compulsion one side) Patient Operation has => M <= performed on Staff Ward work in => M <= employs Many-to-Many, Contingent (compulsion one side) 20 20 18

Decompose Complex Relationships Staff Ward work in => M <= employs Can’t have any Many-to-Many Relationships; for example this one: MUST be decomposed into 2 x One-to-Many Relationships, linked by an ‘artificial’ Entity, i.e.: Staff Ward Team M 1 <= employs work in => FirstName FamilyName WardName WardName FirstName FamilyName 20 18 20

Rules for Drawing ER Diagrams Need to look good: So, DON’T draw them by hand! Need to be well laid out, so that: Entities with several Relationships are in the centre of the diagram. AND related Entities are adjacent to each other. AND Relationship lines do not cross.

The final Degree, Type & Participation Diags. Ward Patient has beds for => 1 M <= stays in Clinic Patient treats => 1 M <= attends NB. the above Relationships are also Exclusive. Staff Ward Team M 1 <= employs work in => Patient Operation Pat/Op M 1 <= performed on has => i.e. having now ‘solved’ BOTH M:M Relationship ‘problems’.

Plan BEFORE you begin! ‘Patient’ has Relationships with THREE other Entities: so, place ‘Patient’ in centre of the Diagram. ‘Ward’, ‘Team’ & ‘Pat/Op’ have Relationships with TWO other Entities: so, place these a little further out. The other 3 Entities (i.e. ‘Staff’, ‘Operation’ & ‘Clinic’ only have ONE Relationship: so, they should be placed on the outside of the digaram, close to the Entity that they have a Relationship with. Join all of the Entities: indicating the Degree, Type and Participation of each Relationship.

ER Diagram for a Hospital Patient Clinic treats => 1 M <= attends Ward has beds for => <= stays in #==========# Operation Pat/Op <= performed on has => Staff Team <= work in

This Week’s Workshop The purpose of this week’s Workshop it to check that you can create good looking ER Diagrams, using a suitable software tool. If you haven’t already got a favourite drawing application I suggest you use PowerPoint. Your ER Diagrams MUST follow the diagram conventions given in this lecture. The same is true for Assignment 1. Part 1 - Draw Degree, Type & Participation diagrams, which: depict 4, relatively simple, ‘real-world’ situations. Part 2 - Begin working on Assignment 1, by: identifying the Entities from the Case Study. then, drawing Occurrence diagrams for each Pair of Entities.