1. Anskaffelse og kravspecifikation
UID16_Datamodels

2. UID16: Data models A B A B Kilder
UID: Soren Lauesen: User interface design - A software engineering perspective. Addison-Wesley, Fra kapitel 16.
SR: En enkelt slide er fra Soren Lauesen: Software requirements - Styles and techniques. Addison-Wesley, 2002.
© 2002, 2005, Pearson Education retains the copyright to the slides from the books, but allows restricted copying for teaching purposes only. It is a condition that the source and copyright notice is preserved on all the material.
Bits and pieces for making E/R slides: And reports: A B
stayID, paymethod
stayID, paymethod
D6. Stay A B

3. 3. UID16.1 E/R data model for a hotel
Boxes with index cards
Guest
Stay
Room
1:m
One-to-many relationship
m:m
Many-to-many relationship
A class contains:
objects = entities
 records = rows
Class = entity class
 table
Entity-relationship data model
Guests
All guests in
the database
One guest may have several stays.
One stay has only one guest
Stays
One stay may com-prise many rooms.
One room may be used for many stays.
Rooms

4. Lists forbidden on a card
4. Extra: Some index cards
Guest
Name:
Address:
Phone:
Passport:
John Simpson
456 Orange … …
Guest
Stay
Room
1:m
One-to-many relationship
m:m
Many-to-many relationship
A class contains:
objects = entities
 records
Class = entity class
 table
Entity-relationship data model
Stay
Pay by:
Date Room
9802
23/8 12
24/8 12
24/8 11
visa
E/R model:
Lists forbidden on a card
Room
roomID:
bedCount:
Type:
Price 1:
Price 2: 12 2
Double 80 60
Put the date here?

5. 5. UID16.2 With attributes and domain keys
Fields = attributes
Guests
name, address,
phone, passport
Guest
Stay
Room
Key field: Underscore
Unique identification
stayID, paymethod,
Stays
date
Rooms
roomID, bedCount, type
price1, price2

6. state (booked | occ | repair)
6. UID16.3A Resolve m:m with connection class
Guests
Rooms
Stays
RoomStates
name, address,
phone, passport
Guest
Stay
RoomState
Room
stayID, paymethod
date
personCount,
state (booked | occ | repair)
enumeration field
roomID, bedCount, type
price1, price2

7. state (booked | occ | repair)
7. UID16.3B Final E/R model
name, address,
phone, passport
Guest
Stay
RoomState
Room
stayID, paymethod
date
personCount,
state (booked | occ | repair)
roomID, bedCount, type
price1, price2

8. 8. UID16.3C Full hotel data model
Guest
E.g.
Full breakfast 6$,
Continental 4$,
Golf
name, price
Service
Type
Stay
Stay
Room
State
Service
Received
Type
date, personCount,
state (booked | occupied | repair)
name,
address1,
address2,
address3,
phone,
passport
roomID,
bedCount, type
price1, price2
name, price
date, quantity
Guest
stayID,
paymethod,
state (booked | in |
out | canceled)
Add to ServiceReceived:
serviceType (fullBreakfast |
continental | )
Remove this class?

9. 9. UID16.4 Relational data model - design level
Guest
guestID name address
32 John Si Orange Gr
33 Lise Ha... Dysseg... 57
38 Yun Chen Kirch... 6
Primary key
- artificial
- natural
Guest
Foreign key, reference
Table
(relation)
Stay
stayID guestID paymethod . . .
Cash
Visa
Stay
Using the database
Who stays in room 11 today 24/8?
Which rooms has John Simpson today?
Guest Thomson books, what happens?
Guest 38 is to be deleted - how?
Total amount for room 13?
Record
= Row
Composite key
RoomState
stayID roomID date state . . .
/8 occ
/8 occ
/8 booked
/8 occ
RoomState
Room
roomID price
11 80
12 60
13 80
Room

10. 10. UID16.5 Data sources Official source text
When a car is registrated it gets a license number (shown on the license plate). The Vehicle Office also records the owner’s name and address, civil registration number or company tax file number, the make (producer and model), chassis number, fuel type (gas, diesel, ...) and the registration date.
The vehicle office sends a registration certificate to the primary owner or user, but it doesn’t show the civil registration number or the company registration number.
More than one owner and user may be recorded.
Car
Owner ?
A domain word may become:
an entity
an attribute
a relationship
something outside the model
printout/computation
“noise”

11. 11. UID16.6 Data dictionary
D1: Class: Guest [Notes a, b ... refer to guidelines]
The guest is the person or company who has to pay the bill. A person has one or more stay records. A company may have none [b, c]. “Customer” is a synonym for guest, but in the database we only use “guest” [a]. The persons staying in the rooms are also called guests, but are not guests in database terms [a].
Examples
E1. A guest who stays one night.
E2. A company with employees staying now and then, each of them with his own stay
record where his name is recorded [d].
E3. A guest with several rooms within the same stay.
Attributes
1. name: Text, 50 chars [h]
2. passport: Text, 16 chars [h]
Attribute missing
in data model
Guidelines for classes. Explain:
a) Name in the system vs. name in domain
b) Relationships to other classes
c) Cases where connections are missing
d) Concerns when creating or deleting an entity
e) Typical and unusual examples

12. 12. UID16.6 Data dictionary (cont.)
D1: Class: Guest [Notes a, b ... refer to guidelines]
The guest is the person or company who has to pay the bill. A person has one or more stay records. A company may have none [b, c]. “Customer” is a synonym for guest, but in the database we only use “guest” [a]. The persons staying in the rooms are also called guests, but are not guests in database terms [a].
Examples
E1. A guest who stays one night.
E2. A company with employees staying now and then, each of them with his own stay
record where his name is recorded [d].
E3. A guest with several rooms within the same stay.
Attributes
1. name: Text, 50 chars [h]
2. passport: Text, 16 chars [h]
Guidelines for attributes. Explain:
f) From where in the domain do we get the values?
g) What are they used for in the domain?
h) Possible values
i) Special values, e.g. blanks, and when
j) Typical and unusual examples
The name stated by the guest [f]. For companies the official name since the bill is sent there [g]. Longer names exist, but better truncate at registration time than at print out time [g, j].
Recorded for guests who are obviously foreigners [f, i]. Used for police reports in case the guest doesn’t pay [g] . . .

13. 13. UID16.7 Network model: Flight routes
Chicago
NewYork
Route: AA331. Mon, Wed
Arr Dep
Chicago 10:45
Columbus 11:40 12:20
Washington 13:30 14:15
New York 15:10
AA331
Columbus
Washington
Leg
Route
City
Route
Leg
City
attributes?
From To
Next
1:1 relation

14. 14. UID16.8 Example: Text processor
Document
font, underline . . .
fileName, zoom
Section
Style ??
Picture
Shape
margin, paperSize,
headers, columns
Paragraph
alignment, indentation,
spacing . . .
Character

15. 15. UID16.9 Hierarchies D1 D1.1 D1.2 D1.3 D1.1.1 D1.1.2 D1.3.1 D1.3.2
HeadQt
Dept
SubDept
Project
projID, name,
(headqtID, deptID, sDeptID)
headqtID, name
deptID, name, (headqtID)
sDeptID, name, (deptID)

16. 16. UID16.9 Hierarchies (cont.)
Dept
deptID name belongsTo
D1 HeadQt
D1.1 Sales D1
D1.2 Personnel D1
D1.3 Development D1
D1.1.1 Sydney D1.1
D1.1.2 Melbourne D1.1
D1.3.1 Hardware D1.3
D1.3.2 Software D1.3
Dept
Project
has
belongs ?
projID, name

17. 17. UID16.10 Network model: road map??
Section ??
Point
Copyright Melway Publishing Pty Ltd.
Reproduced from Melway Edition 31 with permission.

18. 18. UID16.11 Sub-classes: Internet car broker
announce
Attributes
in UML way
Class
Customer
custID
phone1
phone2
Advertisement
fromDate
toDate
make
year
miles
color
state
price
text
see?
Dealer
name
address
. . .
Private
userID
cardID
expiry
Sub-classes
File card extensions
E/R solution 1:
Constraint -
Priv or Dealer
Customer
Dealer
Private
custID, phone
subClass (priv|dealer)
custID, userID . . .
custID, name . . .
Customer
custID
phone1
phone2
userID
. . .
name
E/R solution 0:
Include all fields.
Allow nulls.
Which
combinations?

19. 19. UID16.11 Sub-classes (cont.)
announce
Attributes
in UML way
Class
Customer
custID
phone1
phone2
Advertisement
fromDate
toDate
make
year
miles
color
state
price
text
see?
Private
userID
cardID
expiry
Dealer
name
address
. . .
E/R solution 3:
Customer may have several
roles. All possible attributes.
Many null - depending on role.
Customer
Role
role (private | dealer | reader),
userID, name, address,
cardID, expiry, custID
Cust&Priv
Dealer
E/R solution 2:
Always space
for Private

20. 20. Extra: Two kinds of abstraction: Sub-class and type
Hotel Employee
Super-class
Sub-class
Receptionist
Waiter
Maid
Boss
Room
Room Type
Item Type Type
room number
type name, price
Copy
Version
Book
item bar code
year, ISBN + barcode
author, title

21. 21. UID16.12A Notational variations
Cardinality:
1:m variants:
Each A has zero or more Bs
Each B has one A
Referential
integrity A B
owns
Each A owns one or more Bs
Each B belongs to one A A B
belongs
Each A has one or more Bs
Each B has zero or one A A B
Main rule: Don't use | and o. Noise!
Only to emphasize something A B
1:1 variant:
Each A has a B (don’t know about zero)
Each B has zero or one A
m:m variant
Each A has one or more Bs
Each B has zero or more As

22. 22. UID16.12A Notational variations (cont.)
UML notation
Each A has one or more Bs
Each B has one A
1:1
1: A B
0:1
1:99
Each A has one to 99 Bs
Each B has zero or one A A B
Stay
RoomState
1:m: Move attributes to RoomState and make a 1:m crow’s foot.
date, state
Room
#persons
Diamond notation
m:m: Make diamond a connection class m 1

23. 23. SR2.2F Transformation rulesB C
Two feet facing the same way
make one long foot A C A B C
Two feet facing opposite
ways make many-to-many A C
Stay
Room
Resolve many-
to-many with a
connection box
Room
state
Stay
Room

24. 24. UID16.12B UML and broken connectors
0:
Building
wish
1:1
Contract
period
Activity
Building
0:1
0:
0:
1:1
1:1
0:
1:
0:
1:1
1:1
0:
0:1
Class
activity
0:
1:
Request
hour
Room
hour
1:
Line
Request
Room
0:1
1:1
1:1
1:1
0:
1:1
1:
0:
1:1
1:1
0:
1:1
0:
Room
wish
0:
Room
property
Class
0:
1:1
1:1
0:
1:
1:1
0:
Class
hours
Property
wish
Property
0:
1:1
1:
1:1
0:1
1:1
Time
table
0:1
0:
User
authoriz
1:1
Authoriz
type
User
0:
1:1
0:

25. 25. UID16.12B Room allocation system in E/R notation
Building
wish
Contract
period
Activity
Building
Class
activity
Request
hour
Room
hour
Line
Request
Room
Room
wish
Room
property
Class
Class
hours
Property
wish
Property
Time
table
User
authoriz
Authoriz
type
User

26. Several records for same key
26. UID16.14A Normalization and first normal form
Purpose:
Avoid redundancy (same data several places)
Find the “true” objects
Ensure “table format”
First normal form:
For each primary key, there must be a fixed number of fields of fixed length.
Employee qualifications
empID name deptID deptName Courses
100 Thomson 5 Sales Windows, Word, Access
101 Smith 7 Accounting Word
102 Bunting 5 Sales Word, Access
List
attribute
Course list
Employee qualifications
empID name deptID deptName courseID courseName year
100 Thomson 5 Sales 1 Windows 1996
100 Thomson 5 Sales 2 Word 1996
100 Thomson 5 Sales 3 Access 1997
101 Smith 7 Accounting 2 Word 1996
102 Bunting 5 Sales 2 Word 2000
102 Bunting 5 Sales 3 Access 2001
Fixed length
attributes
Key repeated
Redundancy
Several records for same key

27. 27. UID16.14A Normalization and first normal form (cont.)
Cure:
Move variable-length stuff to a separate table.
CoursesTaken
empID courseID courseName year
100 1 Windows 1996
100 2 Word 1996
100 3 Access 1997
101 2 Word 1996
102 2 Word 2000
102 3 Access 2001
Employees
empID name deptID deptName
100 Thomson 5 Sales
101 Smith 7 Accounting
102 Bunting 5 Sales
Employee
CourseTaken

28. 28. UID16.14B Second normal form
Doesn’t depend
on empID
Second normal form:
First normal form +
Non-key fields must depend on entire key.
CoursesTaken
empID courseID courseName year
100 1 Windows 1996
100 2 Word 1996
100 3 Access 1997
101 2 Word 1996
102 2 Word 2000
102 3 Access 2001
Cure:
Move fields depending on a partial key to a separate table.
CoursesTaken
empID courseID year
Courses
courseID courseName
1 Windows
2 Word
3 Access
Course
CourseTaken

29. 29. UID16.14C Third normal form & final model
Depends only
on deptID
Third normal form:
Second normal form +
Non-key fields must be independent.
Employees
empID name deptID deptName
100 Thomson 5 Sales
101 Smith 7 Accounting
102 Bunting 5 Sales
Cure:
Move interdependent fields to a separate table.
Department
Employee
Employees
empID name deptID
100 Thomson 5
101 Smith 7
102 Bunting 5
Departments
deptID deptName
5 Sales
7 Accounting
Course
CourseTaken
name
year
deptName
courseName
Omit deptID and use deptName
as the key?
The "true" objects

30. 30. UID16.14D Hotel system normalization
Depend only
on type
Rooms
roomID type bedCount price1 price2
011 Double, bath
012 Single, toilet 1 60
013 Double, bath
014 Single, toilet 1 60
015 Double, bath
016 Single, bath 1 70
. . .
Hard to change prices for 400 rooms
Rooms
roomID roomType
011 1
012 3
013 1
014 3
015 1
016 4
. . .
RoomTypes
roomType description bedCount price1 price2
1 Double, bath
2 Double, toilet
3 Single, toilet 1 60
4 Single, bath 1 70
Third normal form:
Easy to change prices for 8 room types