1 Lecture 8 The Data Model. Database Design Process 1) i.d. users views and requirements 2) all...
-
Upload
millicent-ferguson -
Category
Documents
-
view
214 -
download
0
Transcript of 1 Lecture 8 The Data Model. Database Design Process 1) i.d. users views and requirements 2) all...
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