1. 1 Lecture 8 The Data Model

2. Database Design Process 1) i.d. users views and requirements 2) all requirements are mapped into relational model which is technology-independent 3) Map relational model onto database package which is technology dependent User view (report) User view (display) User view (transaction) Conceptual data model Internal data model (adapted from p168 Database Management, McFadden & Hoffer) Access E-R diagram

3. Producing the Conceptual Relation Data Model Objectives: zto produce an Entity Relationship diagram for the whole system ztransform data model into tables (relations) zNormalise tables zdevelop database rules

4. Entity Relationship Data Model zhigh level conceptual data model that is often used in database design zconcise description of the users data requirements zdescribes the data types, relationships and constraints zno implementation details so doesn’t confuse non-technical users zensures all users requirements are met and the requirements do not produce any conflicts

5. 5 E-R diagrams zModel of the proposed system zIdentifies yEach component of the system yThe relationship between these components yWhat items of data need to be stored

6. 6 Entities zThe significant item about which the data is being held yObject, people, event, material, process, conceptual idea zRepresents the table in the database ye.g. employee and dept ye.g. Students, Subject Information

7. 7 Denoted by either Entity Name student OR

8. 8 Entity Class zCollection of entities that have similar characteristics e.g. Students; Products; Courses.(like a database table)

9. 9 Attributes zHow the entity is described zCharacteristics of an entity class zAllows identification of the entity yE.g. ename, empno, loc, deptno etc. yE.g. StudentID, FirstName, LastName

10. 10 Denoted by either Students OR FirstName regno FirstName Lastname If attribute is underlined it is a unique identifier I.e. a primary key STUDENTS regno

11. 11 Identifier z Each entity must have at least one attribute to uniquely identify it, some times two attributes are required. ye.g. Regno for students (like a Primary Key) ye.g. Regno and Course Code for Registration (like a Composite Primary Key)

12. 12 Relationships zThe join between the entities zRelationshipA relationship between two data entities in a data model (also called an association) e.g. a student takes a course. zRepresented by a line between the boxes that represent the entities

13. 13 Denoted by either OR STUDENTS regno FirstName Lastname FirstName STUDENTS regno COURSES coursecode coursename COURSES coursecode coursename

14. 14 Cardinality and participation Cardinality “The number of instances of an entity that can take part in a relationship determined by the business rules for an organization or by facts that exist in the real world” (Dowling p43)

15. 15 Denoted by Staff member Employee number FirstName Lastname Job title Date of birth Department Department number Name Cost Centre Circle represents optional participation in relationship Bar represents mandatory participation in relationship Single line represents the ‘one’ end of the relationship Crow’s foot represents the ‘many’ end of the relationship Dowling p43 works in

16. Associations - Relationships between entity classes These can be: 1:1one to one 1:None to many M:Nmany to many (invalid construct) e.g. married men married women marriage (in U.K and Europe) marriage Department Lecturer employs u/grad student u/grad courses registration Intersection entity

17. E-R Example No.1 Patient No. Name DoctorPatient Responsible speciality Name Outpatient In Patient bed Assigned nurseward bed no. Patient No. Appointment date discharge date admission date Patient No. ISA (ISA denotes sub class)

18. Entity Class: Subclass Patient ISA In-PatientOut-Patient Student ISA undergrad. postgrad. Each entity subclass takes part in different relationships e.g. a patient can either be a In-Patient or Out-Patient but not both at the same time

19. Relationship Cardinality Mandatory 1 cardinality Mandatory Many (M) cardinality (1,2,..., many) Optional 0 or 1 cardinality defn: cardinality - a statement of the maximum and minimum values in an association (the business rules) Doctor responsible Patients assigned Bed In Patient

20. Optional zero-many cardinality (0,1,2,...,many) cardinality (contd) Order Orders- for- Customers Customer In the above example, the Orders-for-Customer relationship, there is exactly one Customer instance and zero,one or many Order instances. Further reading -, Database Management, McFadden and Hoffer, chapter 3. p91-119 Chapter 4 - Dowling

21. E-R Example No.2 Reg. no StudentCourse Registers Name Crs no. Address TutorLecture time