1

Lecture 8

The Data Model

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(report)

User view (display)User view (display)

User view (transaction)User view (transaction)

Conceptual data modelConceptual data model

Internal data

model

Internal data

model

(adapted from p168 Database Management, McFadden & Hoffer)

Access

E-R diagram

Producing the Conceptual Relation Data Model

Objectives:to produce an Entity Relationship

diagram for the whole systemtransform data model into tables

(relations)Normalise tablesdevelop database rules

Entity Relationship Data Model

high level conceptual data model that is often used in database design

concise description of the users data requirements

describes the data types, relationships and constraints

no implementation details so doesn’t confuse non-technical users

ensures all users requirements are met and the requirements do not produce any conflicts

5

E-R diagrams

Model of the proposed systemIdentifies

Each component of the system The relationship between these

components What items of data need to be stored

6

Entities

The significant item about which the data is being held Object, people, event, material, process, conceptual

ideaRepresents the table in the database

e.g. employee and dept e.g. Students, Subject Information

7

Denoted by either

Entity Name

studentOR

8

Entity Class

Collection of entities that have similar characteristics e.g. Students; Products; Courses.(like a database table)

9

Attributes

How the entity is describedCharacteristics of an entity classAllows identification of the entity

E.g. ename, empno, loc, deptno etc. E.g. StudentID, FirstName, LastName

10

Denoted by either

Students

OR

FirstName

regnoFirstNameLastname

If attribute is underlined it is a unique identifier I.e. a primary key

STUDENTS

regno

11

Identifier

Each entity must have at least one attribute to uniquely identify it, some times two attributes are required.

e.g. Regno for students (like a Primary Key) e.g. Regno and Course Code for Registration

(like a Composite Primary Key)

12

Relationships

The join between the entitiesRelationship A relationship between

two data entities in a data model (also called an association) e.g. a student takes a course.

Represented by a line between the boxes that represent the entities

13

Denoted by either

OR

STUDENTS

regnoFirstNameLastname

FirstName

STUDENTS

regno

COURSES

coursecode

coursename

COURSES

coursecodecoursename

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

Denoted by

Staff member

Employee numberFirstNameLastnameJob titleDate of birth

Department

Department numberNameCost 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

Associations - Relationships between entity classes

These can be:1:1 one to one1:N one to manyM:N many to many (invalid construct)

e.g. marriedmen

marriedwomen

marriage (in U.K and Europe)

marriage

Department Lectureremploys

u/gradstudent

u/gradcourses

registration

Intersection entity

E-R Example No.1

Patient No.

Name

Doctor PatientResponsible

speciality

Name

OutpatientIn Patientbed Assigned

nurse

ward bed no.Patient No. Appointment

datedischargedate

admissiondate

Patient No.

ISA ISA(ISA denotes sub class)

Entity Class: Subclass

Patient

ISA

In-Patient Out-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

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

responsible Patients

assignedBed In Patient

Optional zero-many cardinality (0,1,2,...,many)

cardinality (contd)

OrderOrders-

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-119Chapter 4 - Dowling

E-R Example No.2

Reg. no

Student CourseRegisters

Name

Crs no.

Address

Tutor

Lecture time