Building Database Systems Chapter 2Objectives
At the end of this chapter you should be able to:
Discuss the use and features of a data model
Define the terms entity and attribute and reference them to corresponding terms in table design
Select suitable entities and attributes for a given case study
Describe and select suitable primary keys
2
e.g. names, addresses, stock quantities, appointment times etc.
We could hold all this data in a single table
What would be the disadvantages ?
A data model provides us with a way of visually deciding how we might break up the data into chunks so that the data items in a chunk all relate to the same object or entity
A data model may be produced using a technique known as entity modelling
3
Entity modelling
The relationships between these entities are then shown on a diagram and we can see the structure of the proposed database
The diagram is often called an entity relationship diagram (ERD)
The data model consists of the ERD and the accompanying documentation
A model in this sense is a selection of features that describe a certain aspect of a system
4
What is an Entity ?
An entity is anything of significance about which we wish to hold information
Entities can be
real world objects such as Employee, Chair and Car
intangible objects such as Purchase Order, Current Account, and Seat Reservation. These entities should contain all the information that we need to hold in the database
5
Entities and attributes
The requirements of the system are first analysed to find what is significant and what is not
Entities are described by a set of attributes
An attribute is a data item that can be used to describe the state of an entity
6
attributes
Occurrence
An entity will allow us to generate an occurrence or a particular example of an entity.
36285
Brenda
Wooltorton
Yes
8
Occurrence
Every customer would have values for most, if not all, of these attributes
Each entity can potentially give rise to any number of occurrences
9
Understand the problem domain
Conduct an analysis of the user’s present system and future requirements
Use interviews, existing documentation and observation
14
Be clear about the context
In this case the context is the selection and booking of courses for staff members
Names of the possible entities must be
expressed in the singular
start with an upper case letter
Picking out the nouns is one way of making up a list of possible entities
15
SFU example
Staffordshire Free University employs a large number of staff who need to keep up to date with a whole variety of subjects. The staff may work in different departments within the university. A system is required that will keep track of bookings made by staff members to go on various training courses. The courses may be internal or external.
16
SFU example (cont)
Each course, whether internal or external, occurs on a number of occasions and staff members are free to choose which offering they wish to take. Each course has a title and it is required to know when they start. Each course offering for the same course will last for the same time and this must be recorded. The course offerings may be at any number of different locations and will only run if there are a minimum number of students booked onto the course offering. Each course offering also has a maximum number of students who are allowed to be booked onto it.
17
SFU example (cont)
The staff are allowed to browse the different courses available and then select the particular course they wish to go on and the offering that suits them best. When a staff member makes a booking the system should record the date on which it was made.
Detail of the staff member booking a course offering include the name, job title, date of birth, date appointed and department name.
The database should allow the training officer in SFU to see which members of staff are booked onto which courses
18
Department Training Course Number of occasions
Course Offering Course Title Start Date
Booking Course Duration Location
Booking Date Staff Name Job Title
Date of Birth Date Appointed Department Name
Training Officer
Guidelines for selection of entities
Must be something about which we wish to store information in the context of the case study
There must be more than one occurrence of each entity
Make sure you have an entity and not an attribute. If it is an entity there will be more than one attribute you will want to have for it. It is very common to need to decide if you have an attribute or an entity.
20
Guidelines for selection of entities
Consider if the entity name is vague. It should be specific
Call an entity by one name
Think of two or three attributes it might contain that we need to operate the system
Don’t include the name of the company for which you are performing the data model. The entire E-R diagram is representing the company
Don’t expect to get a full list of entities immediately
21
Course Offering
We need to remember that we may add to this list of entities later.
22
Attributes
Each attribute can take on only one value for any one occurrence of that entity
If you are putting in an attribute with an ‘s’ on the end – stop and think. This may be an entity in its own right
23
Each attribute name should be in the singular
If attribute is plural then you must create another entity where you can place that attribute in its singular form
The chosen name should be specific
e.g. choose quantity in stock or order quantity or re-order quantity rather than quantity
24
Guidelines for placing attributes in entities
Check that you can choose a suitable value for that attribute for a given occurrence
An attribute should be placed in one entity only
Choose the most natural home for its placement
Resist the temptation to put an attribute in more than one place
e.g. customer ID could be placed in the Customer or Order entity
25
Guidelines for placing attributes in entities
Don’t include attributes whose values may be determined from other attribute values
e.g.For example don’t include Total Value if it is simply the sum of a number of Sub-totals that you are already keeping
Never use the term ‘details’
Check against the case study for omissions
26
27
Second level
Third level
Fourth level
Fifth level
Worries
a course offering apparently has no details of the course title
a booking does not know for which person or course it is made!
28
Primary key
Uniquely identify each occurrence of an entity by reference to the values of its attributes
Choose one or more attributes such that if we know their value we can uniquely identify that occurrence
One or more attributes that perform such a function are known as the primary key of that entity
29
Sometimes a primary key already exists
Choose the minimum number of attributes possible to form the primary key
If Customer ID is a unique number such that no two customers can have identical numbers then Customer ID could be a primary key
30
Primary key
Combinations of other attributes would not guarantee a way of uniquely identifying a customer
Underline the attribute(s) forming the primary key
31
32
Click to edit Master text styles
Second level
Third level
Fourth level
Fifth level
Placing attributes in more than one entity
We may relax our rule of placing an attribute in only one entity if we need it in another entity to form part of a primary key
See Course ID for the Course entity
and Course ID for Course Offering
33
Can we uniquely identify some small items ?
We need to identify the name of the entity as a type of object
e.g. we might call an entity Stock Item Type and have attributes of Item #, Item Description and Quantity in Stock
Two occurrences then might be:
Item # Item Description Quantity in Stock
237654 2” steel nail 4000
421889 4mm bolt 43
Entities are often chosen from nouns in requirements specification
Test to see if an entity has two attributes (or more) that we need to know to make our system work
Don’t put any single attribute in more than one place
35
References
Software System Development – A Gentle Introduction 3rd Edition, Britton & Doake, 2003, McGraw Hill (Essential reading)
ISBN 0077099745