User Interface Design

16. Data modelling

 UID16: Data models
Kilder
UID: Soren Lauesen: User interface design - A software engineering perspective. Addison-
Wesley, 2005. 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 diagrams

A B stayID, paymethod
stayID, paymethod

A B
3. UID16.1 E/R data model for a hotel

Boxes with index cards Entity-relationship data model

Class = entity class

Guests All guests in  table
the database Guest
1:m
One guest may One-to-many relationship
have several stays. Stay
One stay has only
one guest m:m
Many-to-many relationship
Stays
Room
One stay may com-
prise many rooms. A class contains:
One room may be objects = entities
used for many stays.  records

Rooms
4. Extra: Some index cards
Guest
Name: Entity-relationship data model
John Simpson
Address: 456 Orange … Class = entity class
Phone:  table
23 558 … Guest
Passport:
1:m
One-to-many relationship
Stay 9802 Stay
Pay by: visa
Date Room m:m
E/R model: Many-to-many relationship
23/8 12 Lists forbidden
24/8 12 on a card Room
24/8 11

A class contains:
Room Put the date objects = entities
roomID: here?  records
12
bedCount: 2
Type: Double
Price 1: 80
Price 2: 60
5. UID16.2 Attributes and keys

Fields = attributes
Guests name, address,
Guest
phone, passport

Key field:
Unique identification

stayID, paymethod,
Stay
Stays

date

roomID, bedCount, type

Room
price1, price2
Rooms
6. UID16.3A Resolve m:m with connection class

Guests name, address,

Guest
phone, passport

stayID, paymethod
Stay
Stays

date
personCount,
state (booked | occ | repair) RoomState
RoomStates
enumeration type

roomID, bedCount, type

price1, price2 Room
Rooms
7. UID16.3B Final E/R model

name, address,
Guest
phone, passport

stayID, paymethod
Stay

date
personCount,
state (booked | occ | repair) RoomState

roomID, bedCount, type

price1, price2 Room
8. UID16.3B Hotel data model

Guest name, price

E.g.
Full breakfast 6$,
Continental 4$,
Telephone . . .
Service
Stay
Type

name,
address1,
address2, Guest
address3, name, price
phone,
passport
Service Service
Stay
stayID, Received Type Remove this class?
paymethod,
state (booked | in | date, quantity Add to ServiceReceived:
out | canceled) Room serviceType (fullBreakfast |
State continental | . . . )
date, personCount,
state (booked | occupied | repair)
roomID,
bedCount, type Room
price1, price2
9. UID16.4 Relational data model
Guest
guestID name address1 . . .
Primary
32 John Si... 456 Orange Gr Guest
key
33 Lise Ha... Dysseg... 57
- artificial
38 Yun Chen Kirch... 6

Foreign key, reference

Table Stay
(relation) stayID guestID paymethod . . .
9801 32 Cash
9802 38 Visa Stay Using the database
9805 38
Record Who stays in room 11
today 24/8?
RoomState Composite key

stayID roomID date state . . . Which rooms has

John Simpson today?
9801 12 23/8 occ
9801 11 24/8 occ
RoomState
Guest Thomson books,
9802 12 24/8 booked
Primary what happens?
9801 13 24/8 occ
key
Guest 38 is to be deleted
- natural Room - how?
roomID price1 . . .
11 80 Room Total amount for
12 60 room 13?
13 80
10. UID16.5 Data sources

Official source text

Car Owner 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,
A domain word may become: diesel, ...) and the registration date.
• an entity The vehicle office sends a registration
• an attribute certificate to the primary owner or user,
• a relationship but it doesn’t show the civil registration
• something outside the model number or the company registration
• printout/computation number.
• “noise” More than one owner and user may be
recorded.
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. Attribute missing
in data model
Attributes
1. name: Text, 50 chars [h] Guidelines for classes. Explain:
a) Name in the system vs. name in domain
b) Relationships to other classes
2. passport: Text, 16 chars [h]
c) Cases where connections are missing
d) Concerns when creating or deleting an entity
e) Typical and unusual examples
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 Guidelines for attributes. Explain:
E1. A guest who stays one night. f) From where in the domain do we get
E2. A company with employees staying now and then, each of them with his own stay
the values?
record where his name is recorded [d].
g) What are they used for in the domain?
E3. A guest with several rooms within the same stay.
h) Possible values
Attributes i) Special values, e.g. blanks, and when
1. name: Text, 50 chars [h] 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].
2. passport: Text, 16 chars [h]
Recorded for guests who are obviously foreigners [f, i]. Used for police
reports in case the guest doesn’t pay [g] . . .
13. UID16.7 Network model: Flight routes
Chicago NewYork
Route: AA331. Mon, Wed
AA331 Arr Dep
Chicago 10:45
Columbus Washington Columbus 11:40 12:20
Washington 13:30 14:15
New York 15:10
City Route
Leg

Route
attributes?
attributes?

From
City Leg attributes?
To
Next
1:1 relation
14. UID16.8 Example: Text processor

Document fileName, zoom

Style ??
Section margin, paperSize,
headers, columns

Paragraph alignment, indentation,

Picture ??
spacing . . .
Shape ??
Character font, underline . . .
15. UID16.9 Hierarchies

D1

D1.1 D1.2 D1.3

D1.1.1 D1.1.2 D1.3.1 D1.3.2

headqtID, name HeadQt

deptID, name, (headqtID) Dept Project

projID, name,
sDeptID, name, (deptID) SubDept (headqtID, deptID, sDeptID)
16. UID16.9 Hierarchies (cont.)

D1

D1.1 D1.2 D1.3

D1.1.1 D1.1.2 D1.3.1 D1.3.2

Dept
Dept Project
deptID name belongsTo
has

D1 HeadQt
be
l
on

? projID, name D1.1 Sales D1

gs

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
17. UID16.10 Network model: road map

Road ??

Section ??

Point ??

Copyright Melway Publishing Pty Ltd.

Reproduced from Melway Edition 31 with permission.
18. UID16.11 Sub-classes: Internet car broker
announce Advertisement
Class Customer Attributes
custID fromDate in UML way
phone1 toDate
see? make
phone2
year
miles
color
state
price
Private Dealer text
userID name
cardID address
expiry ... E/R solution
custID, phone1 . . . 1:
Sub-classes subClass (priv|dealer) Constraint -
Priv or Dealer
Customer

Private Dealer

custID, userID . . . custID, name . . .

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

Cardinality: 1:m variants:

Each A has zero or more Bs
A B
Each B has one A Referential
integrity
owns Each A owns one or more Bs
A B Each B belongs to one A
belongs

Each A has one or more Bs

A B
Each B has zero or one A

1:1 variant:
A B Each A has a B (don’t know about zero)
Each B has zero or one A

m:m variant
A B Each A has one or more Bs
Each B has zero or more As
21. UID16.12A Notational variations (cont.)

UML notation
1:1 1: Each A has one or more Bs
A B
Each B has one A

0:1 1:99 Each A has one to 99 Bs

A B
Each B has zero or one A

date, state
m m Diamond notation
Stay Room
m:m: Make diamond a connection class

#persons

1 m 1:m: Move attributes to RoomState

Stay RoomState
and make a 1:m crow’s foot.
22. SR2.2F Transformation rules

A B 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
Stay Room
state
23. UID16.12B UML and broken connectors

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

Activity Building Building Contract

wish period

Class Request Room Room

Line Request
activity hour hour

Room Room
Class
wish property

Class Property
Property
hours wish

Time User User Authoriz

table authoriz type
25. 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
Employee qualifications must be a fixed number of
empID name deptID deptName Courses fields of fixed length.
100 Thomson 5 Sales Windows, Word, Access
101 Smith 7 Accounting Word
102 Bunting 5 Sales Word, Access
Variable length
attribute
Employee qualifications
empID name deptID deptName courseID courseName year
100 Thomson 5 Sales 1 Windows 1996 Fixed
100 Thomson 5 Sales 2 Word 1996 length
100 Thomson 5 Sales 3 Access 1997 attributes
101 Smith 7 Accounting 2 Word 1996 Variable number
102 Bunting 5 Sales 2 Word 2000 of
102 Bunting 5 Sales 3 Access 2001 fields for same
key

Key repeated Redundancy Course list

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

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

CourseTaken Course
28. UID16.14C Third normal form & final model
Depends
only
Third normal form: on deptID
Second normal form +
Non-key fields must be independent. Employees
empID name deptID deptName
100 Thomson 5 Sales
Cure: 101 Smith 7 Accounting
Move interdependent fields to a separate table. 102 Bunting 5 Sales

Employees Departments
empID name deptID deptID deptName
100 Thomson 5 5 Sales Omit deptID and
101 Smith 7 7 Accounting use deptName
102 Bunting 5 as the key?

Employee Department
name
deptName

CourseTaken Course
year
courseName
29. UID16.14D Hotel system normalization
Depend
only
on type

Rooms
roomID type bedCount price1 price2 Hard to change
011 Double, bath 2 80 70 prices for 400
012 Single, toilet 1 60
rooms
013 Double, bath 2 80 70
014 Single, toilet 1 60
015 Double, bath 2 80 70
016 Single, bath 1 70
... Easy to change
prices for 8
room types

Third normal form:

Rooms RoomTypes
roomID roomType roomType description bedCount price1 price2
011 1 1 Double, bath 2 80 70
012 3 2 Double, toilet 2 70 60
013 1 3 Single, toilet 1 60
014 3 4 Single, bath 1 70
015 1 ...
016 4
...