Module Title? Data Base Design 30/6/2007 Entity Relationship Diagrams (ERDs)

Module Title? Data Base Design 30/6/2007 WHY  Entity Relationship Diagrams are data-modeling tool.  organizes the data into entities.  defines the relationships between the entities.  shows how information is, or should be, stored and used within a business system.  Helpful to the analyst to produce a good database structure so that the data can be stored and retrieved in a most efficient manner.  The success of any organization relies on the efficient flow and processing of information.

Module Title? Data Base Design 30/6/2007 The Four Major Components of an Entity Relationship (E-R) Model l Entities (really entity sets) l Attributes l Relationships l Cardinality

Module Title? Data Base Design 30/6/2007 Entity represented by  A data entity is anything real or abstract about which we want to store data.  Entity types fall into five classes:  roles, events, locations, tangible things or concepts.  Banking system: Customer, Account, Loan.  Airline system: Aircraft, Passenger, Flight, Airport.  Registration system: student, module, classroom, instructor.

Module Title? Data Base Design 30/6/2007 An Entity Example

Module Title? Data Base Design 30/6/2007 Naming of Entities  Create a name that is unambiguous  Use the minimum number of words  Do not use abbreviations  Use singular form of the name.

Module Title? Data Base Design 30/6/2007 Attribute  It is a characteristic common to all or most instances of a particular entity.  It is also called as property, data element, and field.  E.g. Name, address, Employee Number, pay rate are all attributes of the entity employee.

Module Title? Data Base Design 30/6/2007  Attribute types:  Simple and composite attributes.  E.g. composite attribute: address  Single-valued and multi-valued attributes  E.g. multivalued attribute: phone-numbers  Derived attributes  Can be computed from other attributes  E.g. age, given date of birth

Module Title? Data Base Design 30/6/2007 Single-valued attributes  Attributes having a single value for a particular entity are known as Single valued attributes.  For example, the loan-number attribute for a specific loan entity refers to only one loan number.

Module Title? Data Base Design 30/6/2007 multi-valued attributes  Attributes that have a set of values for a specific entity are known as multivalued attributes.  Eg: Consider and employee entity set with the attribute phone- number.  An employee may have zero, one, or several phone numbers, and different employees may have different numbers of phones.

Module Title? Data Base Design 30/6/2007 Simple attributes  Attributes that can not be divided into subparts are known as Simple attributes.  For example student_id, position etc

Module Title? Data Base Design 30/6/2007 composite attributes  Composite attributes can be divided into subparts.  For example, an attribute name could be structured as a composite attribute consisting of first-name, middle-initial, and last name.  Composite attributes help us to group together related attributes making the modeling cleaner.  Suppose we were to substitute for the customer entity-set attributes customer-street and customer-city the composite attribute address with the attributes street, city, state, and zip- code.

Module Title? Data Base Design 30/6/2007 Composite Attributes

Module Title? Data Base Design 30/6/2007 Derived Attributes  A Derived Attribute does not physically exist within the database, but is derived (computed) by an algorithm or computation.  Example: A person's AGE attribute can be derived by subtracting the date of birth (DOB) from the current date.  Example: Total cost can be derived by multiplying quantity ordered by unit price.

Module Title? Data Base Design 30/6/2007 Primary Key  An attribute or combination of attributes that uniquely identifies one and only one instance of an entity is called a primary key or identifier.  E.g. Employee Number is a primary key for Employee.

Module Title? Data Base Design 30/6/2007 Attributes & Domains  Attributes will also have a domain.  The domain is the attribute's set of possible values.  The domain of the attribute "Grade Point Average" is a real number between 0 and 4.  The domain of the attribute "Gender" consists of only two possibilities, M or F (or some other equivalent code).  Attributes may share a domain.  The attribute PROFESSOR_AGE and STUDENT_AGE share the domain of all possible ages.

Module Title? Data Base Design 30/6/2007 Relationship  represented by  It is a association between one or more entities.  E.g. Employee worksfor department.

Module Title? Data Base Design 30/6/2007 Degree of Relationship  Degree of a Relationship is the number of entity types that participate in it  Unary Relationship or Recursive Binary  Binary Relationship  Ternary Relationship

Module Title? Data Base Design 30/6/2007 One entity related to another of the same entity type Entities of two different types related to each other Entities of three different types related to each other

Module Title? Data Base Design 30/6/2007 Example of Unary or Recursive Binary Relationship

Module Title? Data Base Design 30/6/2007 Example of Binary Relationship

Module Title? Data Base Design 30/6/2007 MOTHER FATHER CHILD PARENT TERNARY

Module Title? Data Base Design 30/6/2007 E-R Diagram with a Ternary Relationship

Module Title? Data Base Design 30/6/2007 Cardinality  Cardinality is the numerical mapping between entities.  This describes “how many” of one entity are related to “how many” of another entity.  For example, we can say that a Student entity is related to many Course entities and a Course entity is related to many Student entities.

Module Title? Data Base Design 30/6/2007 One-to-One (1:1)  An example of a one-to-one relationship might be the relationship between a Company Car entity and an Employee entity.  An employee is assigned one company car and a company car is assigned to one employee. EmployeeCar

Module Title? Data Base Design 30/6/2007 One-to-Many (1:N)  For example, we might have a relationship between an Instructor entity and a Course entity.  We might find that an instructor is related to (teach) several courses while each course has a single instructor. InstructorCourses

Module Title? Data Base Design 30/6/2007 Many-to-Many (N:M)  For example, we might have a relationship between an Instructor entity and a Student entity.  We might find that an instructor is related to (teach) several Students while each student has a many instructors. InstructorStudent

Module Title? Data Base Design 30/6/2007  Given a description of the real world enterprise, the following guidelines help in drawing an ER diagram to represent the data model.  Identify all the entities and their corresponding attributes.  Note that an attribute cannot exist by itself. Eg. address is an attribute, not an entity, because it doesn’t exist without a customer entity or a student entity.  Identify all relationships between these entities.  All entities and relationships should be uniquely identifiable usually by some key attribute(s).  Determine degree of relationships by looking at relationship from both sides. Drawing E/R Diagrams

Module Title? Data Base Design 30/6/2007 A SIMPLE EXAMPLE  A company has several departments. Each department has a supervisor and at least one employee.  Employees must be assigned to at least one, but possibly more departments. At least one employee is assigned to a project, but an employee may be on vacation and not assigned to any projects.  The important data fields are the names of the departments, projects, supervisors and employees, as well as the supervisor and employee number and a unique project number.

Module Title? Data Base Design 30/6/2007 Identify Entities  The entities in this system are Department, Employee, Supervisor and Project.  One is tempted to make Company an entity, but it is a false entity because it has only one instance in this problem.  True entities must have more than one instance.

Module Title? Data Base Design 30/6/2007 Entity Relationship Matrix DepartmentEmployeeSupervisor Project Department is assigned run by Employeebelongs to works on Supervisorruns Project uses Draw Rough ERD

Module Title? Data Base Design 30/6/2007 Fill in Cardinality  Each department has exactly one supervisor.  A supervisor is in charge of one and only one department.  Each department is assigned at least one employee.  Each employee works for at least one department.  Each project has at least one employee working on it.  An employee is assigned to 0 or more projects.

Module Title? Data Base Design 30/6/2007 Fill in Cardinality

Module Title? Data Base Design 30/6/2007 Define Primary Keys  Primary Keys are:  Department Name,  Supervisor Number,  Employee Number,  Project Number.

Module Title? Data Base Design 30/6/2007 Draw Key Based ERD  There are two many-to-many relationships in the rough ERD above, between Department and Employee and between Employee and Project.  Thus we need the associative entities Department-Employee and Employee-Project.  The primary key for Department-Employee is the concatenated key Department Name and Employee Number.  The primary key for Employee-Project is the concatenated key Employee Number and Project Number.

Module Title? Data Base Design 30/6/2007

Module Title? Data Base Design 30/6/2007 Identify Attributes The only attributes indicated are the names of the departments, projects, supervisors and employees, as well as the supervisor and employee NUMBER and a unique project number. Map Attributes Attribute Entity Attribute Entity Department Name Department Supervisor Number Supervisor Employee Number EmployeeSupervisor Name Supervisor Employee Name EmployeeProject Name Project Project Number Project

Module Title? Data Base Design 30/6/2007 Draw Fully Attributed ERD