FÖ 7: Databaskursen 1. Datamodellering 2. Hierarkier 3. Specialisering i 4. Generalisering 5. Gruppering 6. Typ och instansnivå 7. Använda principen för e-meddelande för att modellera förändringar 8. Hemläxa: Modelleringsuppgift 1 Pär Douhan, pdo@du.se
Datamodellering Verksamhetsbeskrivning Vi har en e-tjänst, på en webbplats, där kunder kan logga in, och handla varor genom att lägga artiklar i en kundvagn. En kund kan, under en tidsperiod, besöka webbplatsen och handla flera gånger. Låter som om vi kan använda en grundmodell för handel! 2
Exempelmodell ll Vi kan snabbt identifiera, åtminstone, två objekt: KUND # kundnr * fnamn * enamn * lösenord * adress KUNDORDER # ordnr (#) kundnr * datum ARTIKEL # artnr (#)typnr * artnamn * pris * lager En kundorder möjliggör att en kund kan handla vid olika tidpunkter. Att skapa en kundorder är en handling som utförs av kunden. ARTIKELTYP # typnr * artikeltyp Aktiva objekt Komplexa objekt Passiva objekt 3
Exempelmodell ll KUND # kundnr * fnamn * enamn * lösenord * adress KUNDORDER # ordnr (#) kundnr * datum ARTIKELTYP # typnr * artikeltyp Tabellen kundvagn kan också kallas KUNDVAGN ARTIKEL för orderrad. Detta då den innehåller alla artiklar som en kund köper vid # id # artnr ett visst tillfälle, d.v.s. på en viss unik (#) ordnr (#)typnr kundorder. Du har säkert klickat på (#) artnr * artnamn en knapp i en webbläsare: "Lägg i * antal * pris kundvagn". Detta skapar ny rader i * lager tabellen Kundvagn. Aktiva objekt Komplexa objekt Passiva objekt 4
Tabeller med exempeldata KUNDORDER ordnr kundnr datum 2000 2556 20150126 2001 2556 20150203 2002 3056 20150315 ARTIKELTYP typnr artikeltyp 23 sport 33 kök 43 bil KUNDVAGN id ordnr artnr antal 702564 2000 400 2 702565 2000 800 3 702567 2001 800 5 702569 2002 450 3 702572 2002 800 15 ARTIKEL artnr typnr artnamn pris lager 400 23 Boll 550 550 450 33 Sil 39 26 800 43 glykol 55 15 850 43 spolarvätska 29 200 520 33 diskställ 149 0 5
Hierarkier MÅLGRUPP Kvinna Man Barn. KATEGORI Skor Kläder Sport & träning. UNDERKATEGORI Skjortor Jackor PRODUKT Alpha... 6
Specialisering, i Top Down FORDON MOTORCYKEL PERSONBIL LASTBIL BUSS Specialisering Underindelning är detsamma som specialisering. Motorcykel, personbil, lastbil och buss är specialiseringar av typen fordon. Alla objekttyper har inte exakt samma egenskaper. En motorcykel ha andra egenskaper än en buss. Vissa egenskaper är dock gemensamma och finns i objekttypen fordon. 7
Generalisering, i Bottom Up PERSON Generalisering LÄRARE ELEV FÖRÄLDER Ett läge för generalisering föreligger, om två eller flera objekttyper har delvis gemensamma variabeluppsättningar. Om man då finner att objekttyperna i någon rimlig mening kan vara undertyper av en gemensam övertyp, så kan man definiera i och namnge denna övertyp hänföra de gemensamma variablerna till den. Genom att generalisera objekttyper gör man det bl.a. möjligt att ge mera överblickbara objektgrafer. På en översiktsnivå kan man utelämna underindelningar av objekttyper, vilka istället kan redovisas i kompletterande detaljgrafer för olika delar av objektsystemet. 8
Nycklar vid generalisering? i PERSON # person_id * fnamn * enamn * adress LÄRARE # person_id * mail_jobb * telefon_jobb * utbildning ELEV # person_id * födelseår * nivå * il k l FÖRÄLDER # person_id * telefon_jobb * telefon_hem * i il tå d * tbild i * mail_skola * civilstånd 9 Parent-tabellen Persons PK blir PK och FK i child-tabellerna Kolumnen Person_id är alltså både PK och FK i tabellerna Lärare, Elev och Förälder.
Gruppering -en enklare lösning Exempel på persontyper: PERSONGRUPP Lärare # person_grp Elev * gruppnamn * beskrivning Förälder PERSON # person_id (#)person_grp * fnamn * enamn * adress o mobil * email En enklare och mer flexibel lösning är att låta alla personer ha samma uppsättning med attribut. I det förra exemplet hade ju alla undergrupper till Person delvis unika attribut. Om detta inte krävs, kan vi istället hänföra alla personer till en viss grupp av personer: lärare, elev eller förälder. Här har alla personer samma attribut. Detta sätt tillåter inte att vissa persontyper t. ex. lärare har egna unika egenskaper. 10
Fel generaliseringsnivå i i Fel generaliseringsnivå kan ge väldigt besvärliga modeller: MOTORCYKEL PERSONBIL MOTORCYKEL- ÄGARBYTE PERSONBIL- ÄGARBYTE ÄGARE LASTBIL LASTBIL- ÄGARBYTE BUSS BUSS- ÄGARBYTE 11
Exempel på generalisering i MOTORCYKEL Här är ett exempel på en modell som använt generalisering. Resultatet bli färre relationer och därmed en förenklad modell. PERSONBIL PERSON FORDON ÄGARBYTE ÄGARE LASTBIL FÖRETAG BUSS 12
En ännu enklare lösning FORDONSTYP # ftyp_id * fordonsslag * tillverkare * modell * årsmodell Exempel på fordonsslag: Motorcykel Personbil Lastbil Buss FORDON # regnr (#)ftyp_id * färg Här ligger alla egenskaper som är unika för varje fordonsexemplar ftyp_id kommer att informera om det är en personbil eller motorcykel eller något annat. 13
Exempel Genom att hänföra alla variabler för de olika fordonen till en gemensam typ så får vi en ännu enklare modell. Personer och företag skiljer sig åt så pass mycket att det inte går att gruppera dessa till en ägartyp. PERSON FORDONSTYP FORDON ÄGARBYTE ÄGARE FÖRETAG 14
Inte alltid bra att gruppera INSÄTTNING KUND UTTAG BANKKONTO ÖVERFÖRING Det är inte alltid bra att gruppera. Vi skulle kunna använda Transaktion och Transaktionstyp. En insättning betyder t. ex. något helt annat än ett uttag. Här blir datamodellen tydlig. Vi ser vilka handlingar kunder kan utföra på sina bankkonton. 15
Inte bra att gruppera KUND ERBJUDANDE BIL Enligt metoden Action-oriented Conceptual Modelling är det viktigt att skilja objekt åt som representerar olika verb: Att Erbjuda, att beställa, att bekräfta, att leverera och att fakturera (begäran om att få betalt) Detta då det innebär olika åtaganden och förpliktelser för olika aktörer (kund, bilhandlare). Ett erbjudande innebär att en bilhandlare åtar sig att leverera en bil till ett visst pris inom en viss tidsperiod. En kundorder innebär att en kund accepterar erbjudandet och åtar sig att betala när bilen levereras. Det är alltså åtaganden och förpliktelser som vi modellerar enligt denna metod. KUNDORDER BEKRÄFTELSE LEVERANS FAKTURA 16
Tydlig koppling till processen KUND ERBJUDANDE BIL KUNDORDER BEKRÄFTELSE LEVERANS FAKTURA 17
Typ och instansnivå i BOKTYP I detta exempel är det boktyper och bokexemplar i ett bibliotek. * isbn * titel Det skulle lika gärna vara filmtyper och filmexemplar i en * författaref filmuthyrningsbutik. * förlag Eller biltyper och bilexemplar på ett hyrbilsföretag. På typnivå lagras all information som är gemensam för alla exemplar. En boktyp kan existera utan att det finns några instanser (bokexemplar) som tillhör boktypen. BOKEXEMPLAR Om vi skulle lagra information om titel, författare och förlag för alla bokexemplar skulle vi få massor av fysisk redundans. # bokid (#)isbn Tänk om vi har 200 bokexemplar av boktypen med ISBN * info 186100690X, "Beginning Oracle Programming", "Thomas Kyte", "Wrox". Vi skulle då behöva lagra samma information på 200 rader. Därför lyfter vi upp denna information och lägger den på typnivå istället. 18
Fysisk redundans d BOKEXEMPLAR bokid isbn info författare förlag 22235556 1-861006-90-X Beginning Oracle Programming Thomas Kyte Wrox 22235557 1-861006-90-X Beginning Oracle Programming Thomas Kyte Wrox 22235558 1-861006-90-X Beginning Oracle Programming Thomas Kyte Wrox 22235559 91-44-35991-8 Databasorienterad systemutveckling Bo Sundgren Studentlitteratur 22235560 91-44-35991-8 Databasorienterad systemutveckling Bo Sundgren Studentlitteratur Här ser vi ett tydligt t exempel på fysisk redundans. d Detta är en följd av att vi inte gjort skillnad på typ och instans. Tabellen är i 2NF, detta då det finns ett delberoende mellan kolumnen isbn och (info, författare och förlag). Detta medför fysisk redundans. 19
Typ och instansnivå i BOKTYP isbn titel författare förlag 186100690X Beginning Oracle Programming Thomas Kyte Wrox 9144359918 Databasorienterad systemutveckling Bo Sundgren Studentlitteratur 1861004826 Expert one-on-one Thomas Kyte Wrox BOKEXEMPLAR bokid isbn info 22235556 186100690X ok 22235557 186100690X Några sidor har s.k. hundöron 22235558 186100690X ok 22235896 9144359918 ok Nu är all fysisk redundans borta. Gemensam information i för bokexemplaren lagras i tabellen Boktyp. Tabellerna är nu i 3NF. 22235896 9144359918 Mycket sliten 20
Relatera till rätt nivå! BOKTYP # isbn titel * författare * förlag * titel ut från biblioteket med en eller flera fysiska bokexemplar. BOKEXEMPLAR # bokid (#)isbn * info När vi skapar datamodeller är det mycket viktigt att relatera vissa företeelser till rätt nivå. En kund som lånar en bok på ett bibliotek, kommer att gå ut från biblioteket med en eller flera fysiska bokexemplar I datamodellen ska således ett boklån kopplas till bokexemplaret, d.v.s. till instansnivån. Om en kund däremot vill reservera en eller flera böcker ska reservationen kopplas till boktypen, d.v.s. till typnivån. Det spelar ju ingen roll för kunden vilket bokexemplar denne får, huvudsaken att det är rätt boktyp. Om en kund skulle reservera ett bokexemplar och detta exemplar aldrig återlämnas kommer systemet inte att kunna meddela kunden att den reserverade boken har kommit in. Om däremot en boktyp är reserverad kommer systemet att meddela kunden, kanske med ett SMS, när ett bokexemplar av den reserverade typen har återlämnats. 21
Relatera till rätt nivå BOKTYP * isbn RESERVERAR * titel * författare * förlag Kund BOKEXEMPLAR # bokid (#)typid * info LÅNAR Tänk på detta i datamodellen! 22
Verksamhetsbeskrivning k i AB Hyrbil hyr ut personbilar till företag. Det är vanligt att ett företag hyr flera bilar på samma gång. För att lösa det problemet så skapas alltid en hyrorder. Denna består av ett unikt hyrordernummer, datum, en referens till vem i personalen som hyrt ut bilen och vilket företag som hyrordern avser. AB Hyrbil har ett begränsat antal biltyper för uthyrning. De har bara modeller av Audi och Volvo. Av Audi finns modellerna A3, A4, A5 och A8. Av VOLVO finns modellerna S60, V60 och S80. Av en modell kan det finnas fler olika bilexemplar för uthyrning. Det kan t. ex. finnas 12 bilexemplar av Audi A8. Det enda som skiljer bilexemplaren åt är reg. nummer, färg och vilken typ av klädsel, skinn eller tyg. Det är samma pris på alla bilexemplar av samma biltyp. Detta oavsett om färgen är röd, blå, svart eller vit, eller om klädseln är i skinn eller i tyg. I en hyrorder kan det ingå fler olika bilexemplar. Varje exemplar som hyrs ut determinerar en egen hyrtid. Information om vad som hyrts ut sparas i minst 10 år. Rita ut PK = #, FK = (#), och attribut som nämns i verksamhetsbeskrivningen och relationerna mellan tabeller enligt modell från föreläsningarna. Datamodellen skall vara i 3NF. 23
Datamodell biluthyrning i FÖRETAG HYRORDER BILTYP # ftgnr # ordnr * ftgnamn (#) ftgnr * adress (#) pnr * orderdatum # typnr * modell * tillverkare * pris PERSONAL HYRORDERRAD # pnr # radnr * fnamn (#) ordnr * enamn (#) regnr * mobil * antal_dygn BILEXEMPLAR # regnr (#) typnr * färg * klädsel En insert i tabellen hyrorderrad innebär att en bil lämnar företaget. Ett hyrorderradsobjekt d.v.s. en rad i tabellen hyrorderrad innehåller alltid information om vilken hyrorder det gäller och vilken bil som hyrts ut och hur länge den får vara ute. Denna modell saknar stöd för återlämning av bilar. 24
Biluthyrning i - återlämning FÖRETAG HYRORDER BILTYP # ftgnr # ordnr * ftgnamn (#) ftgnr * adress (#) pnr * orderdatum # typnr * modell * tillverkare * pris PERSONAL HYRORDERRAD # pnr # radnr * fnamn (#) ordnr * enamn (#) regnr * mobil * antal_dygn BILEXEMPLAR # regnr (#) typnr * färg * klädsel ÅTERLÄMNING En hyrorderrad kan lämnas tillbaka en gång. En återlämning gäller alltid endast en hyorderrad. En # återid insert i tabellen återlämning innebär att en bil (#) radnr kommer tillbaka till företaget. Ett återlämningsobjekt (#) pnr innehåller alltid information om vilken hyrorderrad * återdatum t som återlämnats, och indirekt vilken bil det gäller. 25
Piä Prisändring? di PERSONAL PRISÄNDRING BILTYP # pnr * fnamn # pid (#)typnr # typnr * modell * enamn (#)pnr * tillverkare * mobil * pris * pris * prisdatum Genom att använda oss av Langefors e-meddelande kan BILEXEMPLAR vi modellera en prisändring i efter samma princip: i # regnr Referens till ett objekt = typnr, ett attributvärde = det nya (#) typnr priset, och en tidpunkt = prisdatum * färg En insert i tabellen Prisändring iä di innebär en förändring av * klädsell hyrpriset för en viss biltyp När ett pris ändras så uppdaterar vi priset som finns i tabellen Biltyp Tabellen Prisändring kommer att innehålla alla prisändringar, d.v.s. hela prishistoriken. Den används sedan för att kunna skicka faktura med rätt pris. 26
Eget arbete! Sätt dig ner och försök göra en datamodell över en biografverksamhet: Biografen är uppdelad i olika salonger I salongerna finns det rader med sittplatser Filmföreställning (aktivitet som utförs av personal på biografen) Biljett (Biljetter köps till föreställningar och är kopplade till en viss stol) Var visas filmen? Hur många biljetter går det att sälja till en viss föreställning? 27
The End 28