De fleste af plancherne vedrører kompendiet. De er nummeret sådan: KA: Fig 16.1 E/R data model... dvs. Kompendiet, del A, Fig (Står nummeret i parentes, er planchen en tilføjelse til denne del af kompendiet). Ekstra plancher til Anskaffelse og kravspecifikation, Forår 2007 Kompendiet del A: User Interface Design 16. Data Modelling

KA: Fig 16.1 E/R data model Guests Rooms All guests in the 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 How objects relate to each other 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

KA: Fig 16.2 Attributes and keys name, address, phone, passport stayID, paymethod, room1, date1 room2, date2... ? roomID, bedCount, type price1, price2 Problem: E/R-model requires fixed number of attributes Fields = attributes Key field: Unique identification Guest Stay Room Guests Rooms Stays date?

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

KA: Fig 16.3B Hotel data model Stay Service Type name, price Guest Stay Room State Room Service Received Service 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) E.g. Full breakfast 6$, Continental 4$, Telephone... Add to ServiceReceived: serviceType (fullBreakfast | continental |... ) Remove this class?

Guest Stay RoomState Room KA: Fig 16.4 Relational data model Guest Stay RoomState Room stayIDguestIDpaymethod Cash Visa roomIDprice stayIDroomIDdatestate /8occ /8occ /8booked /8occ guestIDnameaddress John Si Orange Gr 33Lise Ha...Dysseg Yun ChenKirch... 6 Table (relation) Record Foreign key, reference Primary key - artificial Primary key - natural 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?

KA: Fig 16.5 Data sources CarOwner 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. ?

D1:Klasse: Gæst [a, b... henviser til de gode råd] Gæsten er den person eller det firma der skal betale regningen. En person har en eller flere opholds-records. Et firma behøver ikke have nogen [b, c]. “Kunde” er et andet ord for gæst, men i databasen bruger vi kun gæst [a]. Personerne der bor i værelset kaldes også gæster, men de er ikke gæster i database-forstand [a]. Eksempler a.En gæst der overnatter én nat. b.Et firma med medarbejdere der overnatter nu og da, hver af dem med sit eget navn i det registrerede ophold [e]. c.En gæst med flere værelser i løbet af opholdet. Attributter 1. navn:Tekst, 50 tegn [h] 2. pasnr:Tekst, 16 tegn [h] Der mangler et attribut i datamodellen KA: Fig 16.6A Data dictionary = Databeskrivelse Anbefalinger for klasser. Forklar: a)Navn brugt i systemet vs. navne i domænet b) Koblinger til andre klasser c) Tilfælde hvor koblingerne mangler d) Særlige forhold ved oprettelse og sletning e) Typiske og usædvanlige eksempler

D1:Klasse: Gæst [a, b... henviser til de gode råd] Gæsten er den person eller det firma der skal betale regningen. En person har en eller flere opholds-records. Et firma behøver ikke have nogen [b, c]. “Kunde” er et andet ord for gæst, men i databasen bruger vi kun gæst [a]. Personerne der bor i værelset kaldes også gæster, men de er ikke gæster i database-forstand [a]. Eksempler a.En gæst der overnatter én nat. b.Et firma med medarbejdere der overnatter nu og da, hver af dem med sit eget navn i det registrerede ophold [e]. c.En gæst med flere værelser i løbet af opholdet. Attributter 1. navn:Tekst, 50 tegn [h] 2. pasnr:Tekst, 16 tegn [h] Registreres for gæster der tydeligvis er udlændinge [f, i]. Bruges til politianmeldelse hvis gæsten ikke betaler [g]... Det navn gæsten selv angiver [f]. For firmaer dog det officielle navn fordi regningen skal sendes dertil [g]. Der findes længere navne, men det er bedre at forkorte dem på indtastningstidspunktet ind når de printes [g, j]. KA: Fig 16.6B Data dictionary = Databeskrivelse Anbefalinger for attributter. Forklar: f) Hvor i domænet kommer værdierne fra g) Hvad bruges værdien til i domænet h) Hvilke værdier er mulige i)Specielle værdier, fx blanke og hvornår j)Typiske og usædvanlige eksempler

KA: Fig 16.7 Network model: Flight routes Chicago ColumbusWashington NewYork AA331 Route City Route: AA331. Mon, Wed ArrDep Chicago10:45 Columbus11:4012:20 Washington13:3014:15 New York15:10 Leg Route Leg City Next 1:1 relation From To attributes?

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

KA: Fig 16.9 Hierarchies D1 D1.1D1.2D1.3 D1.1.1D1.1.2D1.3.1D1.3.2 HeadQt Dept SubDept Project projID, name, (headqtID, deptID, sDeptID) headqtID, name deptID, name, (headqtID) sDeptID, name, (deptID)

(KA: Fig 16.9 Hierarchies, cont.) D1 D1.1D1.2D1.3 D1.1.1D1.1.2D1.3.1D1.3.2 DeptProject projID, name ? has belongs Dept deptIDnamebelongsTo D1HeadQt D1.1SalesD1 D1.2PersonnelD1 D1.3Development D1 D1.1.1SydneyD1.1 D1.1.2MelbourneD1.1 D1.3.1HardwareD1.3 D1.3.2SoftwareD1.3

KA: Fig Network model: road map Road ?? Section ?? Point ?? Copyright Melway Publishing Pty Ltd. Reproduced from Melway Edition 31 with permission.

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

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

KA: Fig 16.12A Notational variations A B A B 1:m variants: Each A has zero or more Bs Each B has one A Each A has one or more Bs Each B has zero or one A Cardinality : A B Each A owns one or more Bs Each B belongs to one A owns belongs Referential integrity A B 1:1 variant: Each A has a B (don’t know about zero) Each B has zero or one A A B m:m variant Each A has one or more Bs Each B has zero or more As

A B 1:1 1:  UML notation Each A has one or more Bs Each B has one A A B 0:11: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 notation m:m: Make diamond a connection class m m m 1 (KA: Fig 16.12A Cont.)

SR: Fig 2.2F Transformation rules A B C A C A B C A C Two feet facing the same way make one long foot Two feet facing opposite ways make many-to-many Stay Room Stay Room state Room Resolve many- to-many with a connection box

Line Class activity Request hour Room hour Room Contract period Activity Class hours Time table User authoriz Authoriz type Room property Property wish Room wish Building wish Building 1:1 0:  1:  1:1 0:  0:1 1:  1:1 0:  1:1 1:  1:1 0:  0:1 1:1 0:  1:1 1:  1:1 0:  1:1 0:  0:1 0:  1:1 0:  1:1 0:1 1:1 0:1 0:  1:  0:  KA: Fig 16.12B Room allocation system in UML (smooth)

Line Class activity Request hour Room hour Room Contract period Activity Class hours Time table User authoriz Authoriz type Room property Property wish Room wish Building wish Building 1:1 0:  1:  1:1 0:  0:1 1:  1:1 0:  1:1 1:  1:1 0:  0:1 1:1 0:  1:1 1:  1:1 0:  1:1 0:  0:1 0:  1:1 0:  1:1 0:1 1:1 0:1 0:  1:  0:  (Fig 16.12B, Room allocation system, broken connectors)

Line Class activity Request hour Room hour Room Contract period Activity Class hours Time table User authoriz Authoriz type Room property Property wish Room wish Building wish Building (Fig 16.12B Room allocation system in E/R)