1 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Entity relationship...
-
Upload
randolf-harrison -
Category
Documents
-
view
217 -
download
0
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 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