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

2. 2 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

3. 3 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

4. 4 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Components of ERD Entities Attributes Relationships

5. 5 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

6. 6 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

7. 7 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Entities AircraftWedding CustomerSale

8. 8 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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)

9. 9 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Entities Further described by attributes or data elements Smallest units of data that can be described in a meaningful manner Employee Employee # Surname Given name Date of birth Telephone # Department

10. 10 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

11. 11 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Types of Relationships One-to-One relationships One-to-Many relationships Many-to-Many relationships

12. 12 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

13. 13 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering One-to-One relationships Roof Building Covered by Covers

14. 14 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

15. 15 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering One-to-Many relationships Department Employee Works in has

16. 16 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

17. 17 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Many-to-Many relationships Equipment Project allocated

18. 18 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

19. 19 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Choosing the right relationship Likewise, over time an EMPLOYEE works in many DEPARTMENTS

20. 20 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

21. 21 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Tips on building ERDs “My address book contains addresses and telephone numbers for both friends and businesses”

22. 22 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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”

23. 23 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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