Structured Analysis Techniques

Entity Relationship Diagrams

Data models Most large software systems make use of a large database of information. An important part of system modelling is to define the logical form of the data processed by the system.

Entity Relationship Diagrams Entity-Relationship diagrams are a data modeling technique. E-R modelling uses three basic components: entities, attributes, relationships. Entities An entity may be defined as: An entity is a class of persons, places, objects, events or concepts about which we need to capture and store data. If a bank stores data about you, then to the bank you are an entity. If a business stores data relating to a piece of paper called an invoice, then this invoice is an entity.

Entity Relationship Diagrams Attributes An attribute is a data element associated with an entity. For example, the entity SUPPLIER is likely to have attributes such as supplier_name, supplier_address, supplier_phone_number and so forth. Relationships Entities are associated with each other via relationships. A relationship is a named association between two or more entity types. For example: the relationship PLAYS-FOR between the entity types PLAYER and TEAM. The relationship CITIZEN-OF between the entity types PERSON and COUNTRY.

Entity Relationship Diagrams Relationships (cont.) Degree of Relationship. The degree of a relationship may be: one-to-one (1:1) one-to-many (1:N) many-to-many (N:M) As an example, consider a company database which might contain the following relationships: The relationship HEAD-OF between entity types MANAGER and DEPARTMENT is 1:1. This means that a department has at most one head and that a manager is head of at most one department.

Entity Relationship Diagrams Relationships (cont.) Examples: The relationship SUPERVISES between the entity types MANAGER and EMPLOYEE is 1:N. This assumes that a manager may supervise any number of different employees but a given employee is supervised by at most one manager. The relationship ASSIGNED-TO between the entity types EMPLOYEE and PROJECT is N:M. Thus an employee may be assigned to many different projects and each project may have many employees assigned to it.

Notation Notation The graphical representations for E-R diagrams are very simple: A plain rectangle to represent the entity type Invoice A labeled line to represent the relationship

Degree of Relationship There are a number of different graphical conventions for representing the degree of each relationship. The following notation will be used within these notes: A B 1:1 A B 1:n

Example For Example: COURSE enrols STUDENT ONE course has enrolled on it ONE or MORE students. ONE student is enrolled on ONE course. ONE supplier is sent ONE or MORE orders. ONE order is sent to ONE supplier.

Example For Example: ONE loan refers to ONE book. ONE book is referred to on ONE loan.

Example College Database An Example: An ER model for a small college database comprising the entity types: DEPARTMENT, COURSE, STUDENT and LECTURER. Each department has many lecturers, one of whom is the head department. A lecturer belongs to only one department. Each department offers many different courses, each of which is taught by a single lecturer. A student may enrol for many courses offered by different departments.

Example College Database DEPARTMENT offers is_in head_of COURSE LECTURER teaches_on enrols STUDENT ER Diagram - Small College ( solution )

Example Local Education Authority Another Example: A local education authority (LEA) requires a system to hold details of the applicants who apply for courses run by local colleges. Each course is run at only one college, though more than one course is run at each college. An applicant may apply for several courses. Details are to be kept of the standard qualifications that the majority of applicants have.

Example Local Education Authority APPLICANT applies_for COURSE has is_run_by QUALIFICATIONS COLLEGE

Many to Many relationship Decomposing a Many-to-Many (N:M) Relationship Occasionally a many-to-many relationship will occur, relational databases cannot accommodate this relationship type, as such they must be removed. The situation is easily resolved because it is always possible to replace a many-to-many relationship type with two one-to-many types, by introducing an extra entity type into the diagram. This 'new' entity type may simply be the invention of the systems analyst, invented for the sole purpose of eliminating the many-to-many relationship type. In other cases, some actual, physical entity might exist which will provide the needed linkage.

Many to Many relationship Imagine a business which buys in a number of parts from its suppliers. Suppose investigation and analysis has shown that: any one supplier might supply more than one kind of part. any one kind of part might be bought in from a number of different suppliers. supplies SUPPLIER PART

Many to Many relationship The many-to-many relationship type is removed as follows: Thinking of an appropriate name for 'entity X' can be difficult. In such cases it is acceptable to form it from the names of the original two entities. Naming the two new relationships formed by the decomposition can pose a problem however, it is acceptable to leave the relationships blank providing this does not impair the clarity of the diagram. SUPPLIER PART X

Many to Many relationship Remember this? DEPARTMENT is_in offers head_of COURSE LECTURER teaches_on enrols STUDENT

Many to Many relationship The n:m relationship is now removed. DEPARTMENT is_in offers head_of teaches_on COURSE LECTURER receives ENROLMENT STUDENT performs

Guidelines Guidelines for Drawing an Entity-Relationship Diagram: Select likely entities. Select an identifier for each of the entities. Identify relationships between the selected entities. Sketch an E-R diagram, adding the degree of each relationship. Decompose any N:M relationships, allocating an identifier to any new entities formed.