Introduction To Database Management System (CAS 372)
Uploaded by
nomankhanawanIntroduction To Database Management System (CAS 372)
Uploaded by
nomankhanawanIntroduction to Database Management System (CAS 372)
Lecture 5
Entity-Relationship (E-R) Model
High level conceptual data model Developed in 1976 (Chen) Describes DB structure and helps decide how retrieval & update transactions will work Design is independent of DB implementation Many DB support systems now allow automatic generation of applications and tables from E-R model
Limitations of original needed enhancements for:
elimination of problem of connection traps addition of semantic concepts (Enhanced E-R model)
Entity-Relationship Terminology
ENTITY
Person, place, object, event, concept about which organisation needs to maintain data Can be physical (Person) or abstract (Project) Entity type (or class) is generic name Entity occurrence (or instance) is a single example of one entity type (project A/123)
ENTITY TYPES
Patient Medical History
DECIDING ON THE ENTITIES
Obvious ones Source documents Procedure manuals
PATIENT ENTITY OCCURRENCES
Babbage Kilburn Eckert Watson
MAIN ENTITY TYPES
Strong - exists independently of other types (e.g. Patient) Weak - depends on other type (e.g. patients medical history)
Entity-Relationship Terminology (contd)
ATTRIBUTE
Property or characteristic of an entity (Patients telephone number) Can belong to more than one entity type (Doctors phone number) Similar things can be either entities or attributes in different organisations E-R models Sales organisation may have Product with attribute Colour Dyestuff manufacturer may have Entity Colour
One or more attributes chosen to be unique row identifier (Primary Key)
Different types of attribute:
SIMPLE COMPOSITE SINGLE-VALUED MULTI-VALUED Cannot be subdivided (Salary) Has sub-components (Address Street, Town, County, Postcode) Only ever takes one value (DateOfBirth) Can take more than one value (Qualifications)
DERIVED
Calculated from one attribute or a set of related attributes, e.g.
Age from DateOfBirth and SystemDate Dept.AverageSalary from all Employee entities Salary attribute
Entity-Relationship Terminology (contd)
ATTRIBUTE TYPES Town County
Street
Simple Single-valued
PostCode
Composite Single-valued
Address
TelNo
Branch Simple Muli-valued
BranchNo
FaxNo TotalSalary
Derived (Sum of Salary from related Employee entity occurrences)
Entity-Relationship Terminology (contd)
RELATIONSHIP
CARDINALITY (Number) Association between OPTIONALITY (Might or Must) one, two or more entities 1:1 Staff Branch Manages Conceptual model may include M:N Staff may (or not) manage only 1 branch relationships but Branch must have 1 (only 1) manager logical models usually limited to 1:1 or 1:N 1:M Staff Branch Employs Relationship has name describing Staff may be employed by 1 branch or no branches nature of Branch must have 1 and possibly have many employees relationship Relationships in Conceptual Model may have attributes, but not relationships in the Logical Model
N:M Newspaper
PlacesAdvert
Branch
Branch may place advert in 0, 1 or more newspapers Newspaper may carry adverts from 0, 1 or more branches
Entity-Relationship Terminology (contd)
RELATIONSHIP (cont)
MULTIPLE RELATIONSHIPS Employs Staff Manages
Can have different optionality and cardinality
More than one relationship allowed between each pair of entities
Branch
Recursive relationships involve same entity more than once, in different roles
RECURSIVE RELATIONSHIPS Staff Supervises
Must identify relationship between weak (existencedependent) entities and associated strong entity
Staff may supervise 0, 1 or many other staff Each staff may be supervised by 0 or 1 other staff
RELATIONSHIPS WITH WEAK ENTITIES
Staff HasKin NextOfKin
Entity-Relationship Terminology (contd)
SUPERCLASS & SUBCLASS
Superclass entity has distinct subclasses that are represented separately Subclass inherits superclass attributes Subclass key will include superclass key Relationships may be between entities or subentities
Relationship with subentity
Manages
Department
DeptNo DeptName
Employs
Relationship with entity
Staff Manager Secretary StaffNo Bonus StaffNo
StaffNo Name Address Phone Subentity Salesperson: StaffNo Name Address Phone CarAllowance SalesArea
NOTATION PROBLEM
SalesPerson StaffNo CarAllowanc SalesAreae
Can salesperson also be manager or are these subentities mutually exclusive?
Example Entity-Relationship Model
EMPLOYEES TRAINING/HISTORY RECORDING SYSTEM
Employees are allocated to a department immediately they join the company.
Employees may subsequently change departments and a history record is created for every department that the employee has worked for including the current one.
All employees except department heads are supervised by one other employee.
Each department should have a head of department although the position is currently vacant in at least one department.
Employees are encouraged to improve themselves by taking advantage of the training courses which the company offers. For maximum flexibility each course runs a number of times through the year and records are kept of which employees attend which courses, if any.
Example Entity-Relationship Model (contd)
INITIAL CHOICE OF ENTITIES It is important that you state your assumptions. Different assumptions result in different models.
Course type
Department
Course
Employee
Employee history
Example Entity-Relationship Model (contd)
Course type
Department
CoursesAlreadyRun
Manages
Currently employs
HasHistory Course Attended Employee Employee history
Supervises