1 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Entity relationship...

23
Version 1.0 02/05/2004 Requirements Engineering 1 Entity relationship diagrams

Transcript of 1 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Entity relationship...

Version 1.0 02/05/2004© 2004 Robert Oshana

Requirements Engineering 1

Entity relationship diagrams

Version 1.0 02/05/2004© 2004 Robert Oshana

Requirements Engineering 2

What is an ERD?

• Abstractions of the real world which simplify the problem to be solved while retaining its essential features

• Used to;– Identify the data that must be captured, stored,

and retrieved in order to support the business activities performed by the organization

– Identify the data required to derive and report on the performance measures that an organization should be monitoring

Version 1.0 02/05/2004© 2004 Robert Oshana

Requirements Engineering 3

What is an ERD?

• Must be clearly defined so that all understand exactly what is being represented

• Relationships are evaluated in both directions to determine what type of relationship exists– One friend may have many telephones– One telephone belongs to a single friend

Version 1.0 02/05/2004© 2004 Robert Oshana

Requirements Engineering 4

Components of ERD

• Entities• Attributes• Relationships

Version 1.0 02/05/2004© 2004 Robert Oshana

Requirements Engineering 5

What’s in an ERD?

• Entities are drawn in boxes• Entities should be expressed in plural• Relationship is a line connecting the

entities• Arrows represent different types of

relationships• List of attributes developed as you go• Verbs placed on relationship lines that

describe relationship

Version 1.0 02/05/2004© 2004 Robert Oshana

Requirements Engineering 6

Entities

• People, places, things, events, concepts of interest to an organization

• Anything the organization needs to store data about

• Represented by labeled boxes• Collections of things

Version 1.0 02/05/2004© 2004 Robert Oshana

Requirements Engineering 7

Entities

Aircraft Wedding

Customer Sale

Version 1.0 02/05/2004© 2004 Robert Oshana

Requirements Engineering 8

Entities

• EMPLOYEE; collection of employees that work at an organization

• Individual members (employees) of the collection are called occurrences of the EMPLOYEE entity

• Entities should have detailed descriptions (space limited inside the box)

Version 1.0 02/05/2004© 2004 Robert Oshana

Requirements Engineering 9

Entities

• Further described by attributes or data elements

• Smallest units of data that can be described in a meaningful manner

Employee

Employee #SurnameGiven nameDate of birthTelephone #Department

Version 1.0 02/05/2004© 2004 Robert Oshana

Requirements Engineering 10

Relationship

• Frequently, a meaningful relationship exists between two different types of entity– EMPLOYEE works in a DEPARTMENT– LAWYER advises CLIENTS– EQUIPMENT is allocated to PROJECTS– TRUCK is a type of VEHICLE

Version 1.0 02/05/2004© 2004 Robert Oshana

Requirements Engineering 11

Types of Relationships

• One-to-One relationships• One-to-Many relationships• Many-to-Many relationships

Version 1.0 02/05/2004© 2004 Robert Oshana

Requirements Engineering 12

One-to-One relationships

• Takes place when a single occurrence of an entity is related to just one occurrence of a second entity– A ROOF covers one BUILDING– A BUILDING is covered by one ROOF

Version 1.0 02/05/2004© 2004 Robert Oshana

Requirements Engineering 13

One-to-One relationships

Roof

Building

Covered by

Covers

Version 1.0 02/05/2004© 2004 Robert Oshana

Requirements Engineering 14

One-to-Many relationships

• Takes place when a single occurrence of an entity is related to many occurrences of a second entity– EMPLOYEE works in one DEPARTMENT– A DEPARTMENT has many EMPLOYEES

Version 1.0 02/05/2004© 2004 Robert Oshana

Requirements Engineering 15

One-to-Many relationships

Department

Employee

Works in

has

Version 1.0 02/05/2004© 2004 Robert Oshana

Requirements Engineering 16

Many-to-Many relationships

• Takes place when many occurrences of an entity are related to many occurrences of a second entity– EQUIPMENT is allocated to many PROJECTS– PROJECT is related to many items of

EQUIPMENT

Version 1.0 02/05/2004© 2004 Robert Oshana

Requirements Engineering 17

Many-to-Many relationships

Equipment

Project

allocated

Version 1.0 02/05/2004© 2004 Robert Oshana

Requirements Engineering 18

Choosing the right relationship

• Type of relationship can change– Purpose of the model– Length of time involved– Definition of the entities participating in the

relationship

• If the definition of a ROOF entity is an apex or flat surface covering a building, then a BUILDING is covered by many ROOFS

Version 1.0 02/05/2004© 2004 Robert Oshana

Requirements Engineering 19

Choosing the right relationship

• Likewise, over time an EMPLOYEE works in many DEPARTMENTS

Version 1.0 02/05/2004© 2004 Robert Oshana

Requirements Engineering 20

Tips on building ERDs

• Nouns are clues to the entities of a business

• Start by describing the work that is done in the project or department or area of interest– Pull put nouns in the sentences as potential

candidates for entities

Version 1.0 02/05/2004© 2004 Robert Oshana

Requirements Engineering 21

Tips on building ERDs

• “My address book contains addresses and telephone numbers for both friends and businesses”

Version 1.0 02/05/2004© 2004 Robert Oshana

Requirements Engineering 22

Tips on building ERDs

• Verbs and adjectives sometimes help to get at relationships between entities– Friends have addresses

• Many-to-many relationships will cause you lots of trouble!– Get rid of them by defining an intermediate third

entity—Friends/kids between “Kids” and “Friends”

Version 1.0 02/05/2004© 2004 Robert Oshana

Requirements Engineering 23

Tips on building ERDs

• Spend the time to accurately define your entities so that everyone clearly understands what they represent– You will save yourself a lot of time and

headaches later in the process

• A step by step worksheet can also be helpful