anskaffelse og kravspecifikation uid16_datamodels

28
Anskaffelse og kravspecifikation UID16_Datamodels

Upload: jevon-bissett

Post on 14-Dec-2015

213 views

Category:

Documents


0 download

TRANSCRIPT

Anskaffelse og kravspecifikationUID16_Datamodels

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

A B stayID, paymethod stayID, paymethod

Guests

Rooms

All guests inthe database

One guest may have several stays.One stay has only one guest

One stay may com-prise many rooms.One room may be used for many stays.

Stays

Boxes with index cards

Guest

Stay

Room

1:mOne-to-many relationship

m:mMany-to-many relationship

A class contains:objects = entities records

Class = entity class table

Entity-relationship data model

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

Guest

Stay

Room

1:mOne-to-many relationship

m:mMany-to-many relationship

A class contains:objects = entities records

Class = entity class table

Entity-relationship data model

4. Extra: Some index cards

GuestName:

Address:

Phone:

Passport:

John Simpson

456 Orange …

23 558 …

RoomroomID:

bedCount:

Type:

Price 1:

Price 2:

12

2

Double

80

60

StayPay by:

Date Room

9802

23/8 1224/8 1224/8 11

visa

E/R model:Lists forbidden

on a card

Put the date here?

5. UID16.2 Attributes and keys

name, address,phone, passport

stayID, paymethod,

roomID, bedCount, typeprice1, price2

Fields = attributes

Key field:Unique identification

Guest

Stay

Room

Guests

Rooms

Stays

date

6. UID16.3A Resolve m:m with connection class

name, address,phone, passport

stayID, paymethod

roomID, bedCount, typeprice1, price2

personCount,state (booked | occ | repair)

Guest

Stay

RoomState

Room

Guests

Rooms

Stays

RoomStates

enumeration type

date

StayService

Type

name, priceGuest

Stay

RoomState

Room

ServiceReceived

ServiceType

date, personCount,state (booked | occupied | repair)

name, address1, address2, address3, phone,passport

roomID,bedCount, typeprice1, price2

name, price

date, quantity

Guest

stayID,paymethod,state (booked | in | out | canceled)

E.g. Full breakfast 6$,Continental 4$,Telephone . . .

Add to ServiceReceived:serviceType (fullBreakfast |continental | . . . )

Remove this class?

7. UID16.3B Hotel data model

Guest

Stay

RoomState

Room

8. UID16.4 Relational data model

Guest

Stay

RoomState

Room

stayID guestID paymethod . . .

9801 32 Cash9802 38 Visa9805 38

roomID price1 . . .

11 8012 6013 80

stayID roomID date state . . .

9801 12 23/8 occ9801 11 24/8 occ9802 12 24/8 booked9801 13 24/8 occ

guestID name address1 . . .

32 John Si... 456 Orange Gr33 Lise Ha... Dysseg... 5738 Yun Chen Kirch... 6

Table(relation)

Record

Foreign key, reference

Primary key- artificial

Primary key- natural

Using the database

Who stays in room 11today 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?

Composite key

9. UID16.5 Data sources

Car Owner

A domain word may become:

• an entity• an attribute• a relationship• something outside the model• printout/computation• “noise”

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.

?

10. 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].

ExamplesE1. 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.

Attributes1. name: Text, 50 chars [h]

2. passport: Text, 16 chars [h]

Attribute missingin data model

Guidelines for classes. Explain:a) Name in the system vs. name in domainb) Relationships to other classesc) Cases where connections are missingd) Concerns when creating or deleting an entitye) Typical and unusual examples

11. 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].

ExamplesE1. 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.

Attributes1. name: Text, 50 chars [h]

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] . . .

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].

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 valuesi) Special values, e.g. blanks, and whenj) Typical and unusual examples

12. UID16.7 Network model: Flight routes

Chicago

Columbus Washington

NewYork

AA331

RouteCity

Route: AA331. Mon, Wed

Arr Dep

Chicago 10:45Columbus 11:40 12:20Washington 13:30 14:15New York 15:10

Leg

Route

LegCity

Next1:1 relation

From

To

attributes?

attributes?

attributes?

13. UID16.8 Example: Text processor

Character

Paragraph

Document

alignment, indentation,spacing . . .

margin, paperSize,headers, columns

font, underline . . .

fileName, zoom

SectionStyle ??

Picture ??

Shape ??

14. 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)

D1

D1.1 D1.2 D1.3

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

Dept Project

projID, name?

has

belongs

DeptdeptID name belongsTo

D1 HeadQtD1.1 Sales D1D1.2 Personnel D1D1.3 Development D1D1.1.1 Sydney D1.1D1.1.2 Melbourne D1.1D1.3.1 Hardware D1.3D1.3.2 Software D1.3

15. UID16.9 Hierarchies (cont.)

16. UID16.10 Network model: road map

Road ??

Section ??

Point ??

Copyright Melway Publishing Pty Ltd. Reproduced from Melway Edition 31 with permission.

17. UID16.11 Sub-classes: Internet car broker

CustomercustIDphone1phone2

AdvertisementfromDatetoDatemakeyearmilescolorstatepricetext

announce

see?

Attributesin UML way

Class

Dealernameaddress. . .

PrivateuserIDcardIDexpiry

Sub-classes

E/R solution 1:Constraint -Priv or Dealer

Customer

Dealer Private

custID, phone1 . . .

subClass (priv|dealer)

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

CustomercustIDphone1phone2

AdvertisementfromDatetoDatemakeyearmilescolorstatepricetext

announce

see?

Attributesin UML way

Class

Dealernameaddress. . .

PrivateuserIDcardIDexpiry

Cust&Priv

Dealer

E/R solution 2:Always spacefor Private

E/R solution 3:Customer may have several roles. All possible attributes.Many nil - depending on role. Customer

Role role (private | dealer | reader),userID, name, address, cardID, expiry, custID

18. UID16.11 Sub-classes (cont.)

A

A

1:m variants:Each A has zero or more BsEach B has one A

Each A has one or more BsEach B has zero or one A

Cardinality:

A Each A owns one or more BsEach B belongs to one A

owns

belongs

Referentialintegrity

B

B

B

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

m:m variantEach A has one or more BsEach B has zero or more As

A B

19. UID16.12A Notational variations

A B 1:1 1:

UML notationEach A has one or more BsEach B has one A

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

Each B has zero or one A

Stay RoomState 1:m: Move attributes to RoomState

and make a 1:m crow’s foot.

date, state

Stay Room

#persons

Diamond notationm:m: Make diamond a connection class

m

m

m

1

20. UID16.12A Notational variations (cont.)

21. SR2.2F Transformation rules

A B C

A C

A B C

A C

Two feet facing the same waymake one long foot

Two feet facing oppositeways make many-to-many

Stay Room

Stay Roomstate

Room

Resolve many-to-many with a connection box

Line Classactivity

RequestRequest

hourRoomhour

Room

Contractperiod

Activity

Class

Classhours

Timetable

UserUser

authorizAuthoriz

type

Roomproperty

PropertyPropertywish

Roomwish

Buildingwish

Building

1:1

0:

1:

1:1

0: 0:1

1: 1:1

1:1

0: 1:1

1:

1:

1:1

0: 0:1

1:1

0:

0:

1:1

1:11:

1:1

1:1

0:

0:

0: 1:1

1:10:

0:1

0:

1:10:

1:1

1:1

0:1

1:1

1:1

1:1

1:1

0:10:

0: 0:

1: 0:

0:

0:

0:

22. UID16.12B UML and broken connectors

Line Classactivity

RequestRequest

hourRoomhour

Room

Contractperiod

Activity

Class

Classhours

Timetable

User Userauthoriz

Authoriztype

Roomproperty

PropertyPropertywish

Roomwish

Buildingwish

Building

23. UID16.12B Room allocation system in E/R notation

24. UID16.14A Normalization and first normal form

First normal form:For each primary key, there must be a fixed number of fields of fixed length.

Variable length attribute

Purpose: Avoid redundancy (same data several places)Find the “true” objectsEnsure “table format”

Employee qualificationsempID name deptID deptName Courses100 Thomson 5 Sales Windows, Word, Access101 Smith 7 Accounting Word102 Bunting 5 Sales Word, Access

Course list

Employee qualificationsempID name deptID deptName courseID courseName year100 Thomson 5 Sales 1 Windows 1996100 Thomson 5 Sales 2 Word 1996100 Thomson 5 Sales 3 Access 1997101 Smith 7 Accounting 2 Word 1996102 Bunting 5 Sales 2 Word 2000102 Bunting 5 Sales 3 Access 2001

Fixed lengthattributes

Key repeated Redundancy

Variable number offields for same key

Cure:Move variable-length stuff to a separate table. CoursesTaken

empID courseID courseName year

100 1 Windows 1996100 2 Word 1996100 3 Access 1997101 2 Word 1996102 2 Word 2000102 3 Access 2001

Employee CourseTaken

EmployeesempID name deptID deptName100 Thomson 5 Sales101 Smith 7 Accounting102 Bunting 5 Sales

25. UID16.14A Normalization and first normal form (cont.)

26. UID16.14B Second normal form

Second normal form:First normal form +Non-key fields must depend on entire key.

Doesn’t dependon empID

CoursesTakenempID courseID courseName year

100 1 Windows 1996100 2 Word 1996100 3 Access 1997101 2 Word 1996102 2 Word 2000102 3 Access 2001

Cure:Move fields depending on a partial key to a separate table.

CoursesTakenempID courseID year

100 1 1996100 2 1996100 3 1997101 2 1996102 2 2000102 3 2001

CoursescourseID courseName1 Windows2 Word3 Access

CourseCourseTaken

27. UID16.14C Third normal form & final model

Third normal form:Second normal form +Non-key fields must be independent. Employees

empID name deptID deptName100 Thomson 5 Sales101 Smith 7 Accounting102 Bunting 5 Sales

Depends onlyon deptID

Omit deptID and use deptNameas the key?

Cure:Move interdependent fields to a separate table.

DepartmentEmployee

EmployeesempID name deptID

100 Thomson 5101 Smith 7102 Bunting 5

DepartmentsdeptID deptName5 Sales7 Accounting

CourseCourseTaken

name

year

deptName

courseName

28. UID16.14D Hotel system normalization

RoomsroomID type bedCount price1 price2011 Double, bath 2 80 70012 Single, toilet 1 60013 Double, bath 2 80 70014 Single, toilet 1 60015 Double, bath 2 80 70016 Single, bath 1 70. . .

Depend onlyon type

Hard to change prices for 400 rooms

RoomsroomID roomType011 1012 3013 1014 3015 1016 4. . .

RoomTypesroomType description bedCount price1 price2

1 Double, bath 2 80 702 Double, toilet 2 70 603 Single, toilet 1 604 Single, bath 1 70

. . .

Third normal form:

Easy to change prices for 8 room types