Database Design Concepts Lecture 7 Introduction to E:R Modelling Identifying Entities

Objectives To introduce the notation used in E:R modelling To explain what is meant by an Entity Introduce a strategy for identifying entities in a given scenario Introduce the concept of a relationship Show how optionality and degree are shown using the notation

Entity Relationship Diagrams Entities and Relationships An entity is a set of objects of the same type I.e. they have the same properties and they behave in a similar way EG Student entity  Bob  Nazia  Jim

Entity An entity has attributes or properties associated with it Eg Name Age Address And have relationships with other entities (These are the associations between the entities) Eg A Student is associated with a Course A Course is associated with a number of Modules

Identifying Entities We need to identify the things of interest to the users of the system Things Tangible Things Airplane Book Vehicle Roles Played Employee Student Lecturer Organisational Units Warehouse Department Accounts Section Event, incidents or interactions Flight, Order, Contract, Invoice, Payment Service call

Identifying the Entities One method is to identify all nouns associated with the system 1. List all the nouns the users mention in their description of the system 2. Review all documentation including sample forms from the existing systems 3. Make a list of all these nouns

Identifying the Entities For each noun on the list for it to be included (stay on the list) 1. Is it a thing the system needs to know about? 2. Is it inside the scope of the system? 3. Is there more than one of these objects? If the answer is yes to all of these question it stays on the list. If not remove it

Remove a noun from the list if you can answer yes to any of these questions 1. Is it another name for something already on the list? 2. Is it an input or output from the system that can be produced from other information you have identified? 3. Could it be a property of some other thing you have identified? 4. Are you unsure of any of these answers? if so note it for further research

At the end of this exercise we have a list of entities After follow up research to clear up any we are not sure about. Do not worry about missing any, they will turn up.

Relationships between Entities An association between entities ( in simple terms) Customer places an order Student enrols on a course

Properties of Relationships/ Associations Often described by a verb Often bi-directional Customer places an order Order is placed by a customer Have multiplicity For each direction  Customer places many orders  Order is placed by exactly one customer Shown by a line

Enterprise rules When we draw an E:R model we need to identify all the relationships between that entity and other entities These are known as Enterprise rules- these describes the rules the business uses Eg a student can only ever enrol on one course However another college may allow students to enrol on more than one course. This information comes from systems investigation and we need to know, to be able to design a useful database

ER Diagram An ER Diagram is a pictorial representation of Entity (type) level enterprise rules within the boundary of what exists or is required Basic notation of ER Diagram: NB - the colours are not part of the syntax = Entity = Relationship EmployeeMachine works on Often hard to name the relationship.

Participation Condition Otherwise called Membership Class Type of participation of an entity in a relationship Obligatory  every occurrence of an entity must participate OR Non-Obligatory  occurrence(s) of an entity can exist without participating in the relationship.

Participation Condition is shown as a dot or blob Enterprise Rules Represented: “An employee must work on one or many machines” (dot inside) “A machine is worked on by zero, one or many employees” (dot outside) EmployeeMachine Works on MM  

Example E:R Diagram Student Module Registers on m m

Multiplicity Shown by the use of 1or m on the relationship 0 shown by circle outside entity box Circle inside box says there must be at least 1 From the example A (one,each) student must be registered on one or more modules Other way A module has 0, one or more students registered on it

A student enrols on exactly one course Reading the relationship the other way A course may have 0, one or more students enrolled on it More Examples of multiplicity Student Course enrols 1 m

An employee may have one car And A car must belong to exactly one employee only Employee Car Has 11

Project Works_on Works_in Based_in Dept Room Fill in the degree of association (0,1,m etc.) and participation conditions (dots) (You will need to make a few assumptions). Employee

Employees may work on several projects but some employees do not work on projects. New projects may have no employees assigned. Some projects have many employees involved. Each employee is in just one department. Some employees are assigned a single room, others are not assigned a room at all. Rooms are usually shared

Guidelines The dots on m:m relationships are usually outside (non-obligatory) The dot that goes with the m of a 1:m relationship is usually outside too (that’s the dot beside the 1) These are very good guidelines for beginners to apply You need to be very sure of any variation from these two guidelines The other useful rule to remember is that 1:1 relationships are quite rare If you have one it’s probably WRONG!

Notations Many notations are used for Entity- Relationship modelling We use the Chen notation, which is particularly good for beginners. It is not the same notation as in some of the text books. The meaning and concepts are the same whatever the notation It is important that you do not mix the notation in a model.

Summary You should now know what is meant by an entity Be able to ‘read’ an E:R model

References Satzinger, Burd and Jackson Systems analysis and design in a changing world Chapter