Idag Modellering Varför modellera? Konceptuell modell Modelleringsverktyg Objektklasser Sambandsklasser Knepiga attribut Modelleringsprocessen DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2011 1 / 39
Varför modellera? I all ingenjörsverksamhet där man hanterar komplicerade system behöver man vara överens om många saker Då behöver man bygga modeller som a. kan förstås av alla inblandade och b. inte kan missförstås Punkt a säger oss att verktyget ska vara enkelt och punkt b att det ska vara stringent (noggrannt) DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2011 2 / 39
Modelleringsverktyget Alla sådana verktyg bygger på matematik men tack och lov finns oftast begriplig grafisk notation Varje disciplin har sina verktyg och det är oftast inte lyckat att använda modellverktyg som egentligen är avsett för annat ändamål därför kan det vara bra med mer än ett verktyg Här fokuserar vi för tillfället på databasbyggande enligt relationsmodellen DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2011 3 / 39
Modelleringsverktygets egenskaper Modelleringsverktyget ska ha egenskaper som gör att vi: inte behöver kunskap om de verktyg som senare krävs för att realisera systemet lätt får överblick över modellen har tillgång till detaljer när vi vill kan bortse från detaljer om vi vill slipper beroende av den dator som senare skall användas lätt kommer vidare från modell till databasstruktur DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2011 4 / 39
Databasmodellering Modellering Det verktyg som finns i boken duger bra Vi kan tillåta oss en viss frihet i användningen. Databasen är endast en del av det system som krävs för att täcka informationsbehovet hos en organistation Normalt måste man undersöka och analysera alla informationssystemets komponenter: Applikationsprogram Databashanteringssystem Databas Hårdvara Personal DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2011 5 / 39
Databasmodellering... Modellering Informationssystemplanering Systemdefinition Kravanalys Konceptuell design Databasdesign DBMS-val Logisk design Applikationsdesign Fysisk design Utveckling av prototyp Implementation Datakonvertering och Laddning Testning Operationellt underhåll DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2011 6 / 39
Databasmodellering... Modellering Vi kommer nästan bara bekymra oss om den streckade boxen med titeln Databasdesign och anta att det övriga är klart. På labbarna kommer vi testa SQL både för att söka i databaser ocg för att manipulera dem och vi kommer snegla lite på implementation DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2011 7 / 39
Vad modellerar man? Modellering Traditionellt väljer man att representera objekt och samband mellan dessa Objektklasser representerar alla objekt av samma typ Sambandsklasser representerar alla tänkbara kopplingar mellan objekt ur objektklasserna Alltså modellerar man möjligheter, tänkbara scenarier, inte faktiska kopplingar mellan enheter i modellen I tabellerna som man sedan skapar genom en kokboksmässig övergång mellan modell och databastabeller representerar raderna i tabellerna de faktiska förekomsterna Alltså är modellen en statisk representation av vad som kan förekomma medan databasen utgör en ögonblicksbild av vad som faktiskt förekommer vid en viss tidpunkt Behöver man beskriva dynamik (förändring) måste man komplettera med flödesmodeller och interaktionsscenarier och till det duger inte det här verktyget Eftersom modellen visar vilka möjligheter som finns kallas den konceptuell DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2011 8 / 39
Objekt och objektklasser Man börjar med att identifiera mängder av intressanta objekt i den verklighet man ska avbilda Dessa brukar man kalla objektklasser Det man avbildar i modellen är, som redan sagts, möjligheter Det kan finnas sådana objekt som beskrivs i objektklasserna Det är möjligt och troligt, men inte säkert Grafiskt brukar man markera objektklasserna som rektanglar med klassens namn i. Namnet är i singularis och ska vara beskrivande. Person DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2011 9 / 39
Objekt och objektklasser... Intressanta objektklasser brukar vara t.ex.: Objekt i egentlig mening: Flygplan, tåg, människor, hus, bilar, husgeråd kontor, fabriker, aktier, et.c. Roller: Läkare, lärare, husägare, bilist, hyresgäst, handledare, köpare, säljare, et.c. Händelser: Händelse, olycka, systemkrasch, födelsedag, et.c. (Kanske) DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2011 10 / 39
Objekt och objektklasser... Ett objekt är en instans av en objektklass, och är entydigt identifierbar genom en I-term (identifikationsterm). Informellt: ett objekt är en förekomst i en tabell med ett entydigt nyckelvärde som identifierar objektet. Ex.: Person Personnr FörNamn EfterNamn Gatuadress Nr 640111-0010 Kalle Andersson Karlavägen 12 640212-0028 Mona Pettersson Månvägen 7 640313-0046 Vera Lundström Verdandigatan 3 DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2011 11 / 39
Objekt och objektklasser... Objektklassens egenskaper beskrivs av ett antal attribut. Grafiskt: Person Personnr FörNamn EfterNamn Gatuadress Nr Eftersom stora modeller gärna blir väl plottriga kan man istället ha egenskaperna i en egenskapsmatris och endast representera klassen med en rektangel med dess namn i i modellen DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2011 12 / 39
Objekt och objektklasser... Klass Namn I-termer E-termer Objekt Person Personnr FörNamn, EfterNamn, Gatuadress, Nr För ett enskilt objekt har ett av dessa attribut, I-termen, ett för tabellkolumnen unikt värde ur motsvarande domän, medan övriga attribut (E-termer, egenskapstermer) har ett (inte säkert unikt) värde ur attributets domän eller är värdet null ( ). DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2011 13 / 39
Databasmodellering... Modellering Idén med informationssystemsmodeller är att beskriva de logiska elementen i den del av världen som vi vill representera, d.v.s. att finna alla kopplingar mellan alla objekt, (= alla samband mellan dem) samt objektens, och sambandens alla egenskaper (attribut). Modellen kommer att bestå av ett antal objektklasser, deras egenskaper (attribut) och dessutom de associationer (samband) som kan finnas mellan objekten i objektklasserna. Sambanden samlas i sambandsklasser som utgör kopplingen mellan objektklasserna. Så kommer hela modellen att utgöra en sammanhållen graf. DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2011 14 / 39
Samband och sambandsklasser Intressanta sambandsklasser brukar vara t.ex.: Allt som utgör en association mellan objektklasser: Försäljning, banklån, boklån, boende, flight, resa, m.m. (!! det här är inte alltid så säkert, mycket kan vara objektklasser!!). Allmänt: sambandsklasser definierar ett beroende mellan objektklasser. Identifieras med i-termerna från de objektklasser de associerar till varandra. Ett samband utgörs då av en förekomst i en tabell och identifieras entydigt av en nyckel bestående av flera i-termer. Samband samlas alltså i tabeller som motsvarar sambandsklassen. Sambandsklasser ritas som namngivna linjer dragna mellan de objektklasser som relateras till varandra. Namnet skall helst vara ett substantiv i singularis. DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2011 15 / 39
Sambandklassers grad Modellering Sambandsklasser som associerar två objekt ur samma klass med varandra kallas ibland (lite oegentligt) unära. Sambandsklasser som associerar objekt ur två klasser med varandra kallas binära. Sambandsklasser kan associera objekt ur fler än två klasser med varandra (sambandsklassen kan ha högre ordning än 2). Man kan lägga på restriktioner på en unär/binär sambandsklass. Den säges vara av typ 1:1 om ett objekt från den ena objektklassen associeras med max ett objekt från den andra och vice versa. 1:N om ett objekt från den ena objektklassen kan associeras med mer än ett objekt från den andra medan objekt från den andra klassen kan associeras med max ett objekt från den första. M:N om ett objekt från den ena objektklassen kan associeras med mer än ett objekt från den andra och vice versa. DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2011 16 / 39
Samband och sambandsklasser Kvinna Chef Författare Gift_med Basar_över Skrivit Man Anställd Bok 1:1 1:N M:N DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2011 17 / 39
Samband och sambandsklasser Projekt Beställning Material Leverantör DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2011 18 / 39
Samband och sambandsklasser Person Anställning Avdelning Projektmedverkan Projekt DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2011 19 / 39
Samband och sambandsklasser kan vara knepiga gift Person granne kollega motpart DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2011 20 / 39
Fördela egenskaper i modellen Oftast är det enkelt att bestämma var man ska representera en egenskap men man kan få lite huvudbry. person projanst projekt 1? 2? 3? Timpris Var timpriset ska representeras kan bero på många saker, här t.ex.: 1. man har samma lön oavsett vad man gör 2. man har lön efter sin roll (och sitt ansvar) i projektet 3. alla på samma projekt har samma lön DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2011 21 / 39
När man anser sig vara klar När man anser sig vara klar har man en sammanhängande graf kan man diskutera sig igenom hur man får svar på sina frågor är alla inblandade överens om vad modellen betyder ska man få en rimlig databasstruktur, annars... itererar man över modellen och databasstrukturen tills man är nöjd Databasstruktur?? men först lite mer om hur man kan tänka DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2011 22 / 39
Exempel vårt (mycket enkela) varuhus 1. Det finns varor till försäljning Vara DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2011 23 / 39
Exempel ett (mycket enkelt) varuhus 2. Det finns avdelningar där man säljer varorna Avdelning Vara DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2011 24 / 39
Exempel ett (mycket enkelt) varuhus 3. Det finns anställda som sköter försäljningen Anställd Avdelning Vara DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2011 25 / 39
Exempel ett (mycket enkelt) varuhus 4. Det finns leverantörer som levererar varor Anställd Avdelning Leverantör Vara DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2011 26 / 39
Exempel ett (mycket enkelt) varuhus 5. Man håller reda på hur mycket varje avdelning säljer, Anställd Avdelning Försäljning Leverantör Vara DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2011 27 / 39
Exempel ett (mycket enkelt) varuhus 6. vilka som jobbar på avdelningarna Anställd Anställning Avdelning Försäljning Leverantör Vara DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2011 28 / 39
Exempel ett (mycket enkelt) varuhus 7. och vad som levereras av vem till resp.avdelning Anställd Leverantör Anställning Lager Avdelning Försäljning Vara DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2011 29 / 39
Exempel ett (mycket enkelt) varuhus Jag väljer en egenskapsmatris för att representera egenskaperna Typ Namn I-termer E-termer Obj Vara varunr typ Avdelning avd våning Anställd namn lön, chef Leverantör företag adress Samb Försäljning avd, varunr volym Anställd namn, avd Lager företag, avd, varunr volym DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2011 30 / 39
Variationer på modellverktyget (1) Anställd Leverantör Anställning Lager Avdelning Vara Försäljning DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2011 31 / 39
Variationer på modellverktyget (2) Anställd Leverantör Anställning Avdelning Försäljning Lager Vara DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2011 32 / 39
Från modell till databas Modellering När vi analyserat den värld vi vill representera i en databas har vi tagit med alla möjliga kopplingar och beskrivit dem i en modell. Inte allt är nödvändigt att representera i databasen, 1:1- och 1:N-samband kan vi få med utan att ha en speciell tabell för representationen. Hade vi en sådan tabell skulle den bli uppenbart onödig Anställd Avdelning Kalle Eva Anders Sport Sport Mat Kalle, Eva och Anders förekommer endast en gång var i Anställd så vi kan lägga till avd i Anställd istället för att ha en extra tabell Vi kan faktiskt använda ett antal kokboks -regler för övergång till DB-struktur DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2011 33 / 39
Från modell till databas... Jag kommer att använda följande notation: TabellNamn (i-termer, e-termer) för att beteckna en tabell (basrelation) och följande regler finns i den utlovade kokboken a. En objektklass som innehåller e-term(-er) bildar en tabell b. En objektklass som inte har e-termer men finns på N-sidan av någon 1:N-sambandsklass bildar en tabell c. En sambandsklass av högre ordning än 2 bildar en tabell d. En M:N-sambandsklass bildar en tabell e. En 1:N-sambandsklass försvinner men 1-sidans objektklass i-term blir e-term i tabellen som bildas av n-sidans objektklass f. En 1:1-sambandsklass hanteras antingen som en 1:N-sambandsklass där man godtyckligt väljer en sida som N-sida eller tar man bort den och slår samman objektklasserna som sambandsklassen binder samman Regel f komplicerar lite grand ger ett icke-deterministiskt inslag DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2011 34 / 39
Från modell till databas... testa reglerna på varuhusmodellen och senare, på övning, på större modeller Anställd Leverantör Anställning Lager Avdelning Försäljning Vara DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2011 35 / 39
Från varuhusmodell till varuhusdatabas a. En objektklass som innehåller e-term(-er) bildar en tabell Vara (varunr, typ) Avdelning (avd, våning) Anställd (namn, lön, chef) Leverantör (företag, adress) b. En objektklass som inte har e-termer men finns på N-sidan av någon 1:N-sambandsklass bildar en tabell Finns ingen c. En sambandsklass av högre ordning än 2 bildar en tabell Lager (företag, avd, varunr, volym) DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2011 36 / 39
Från varuhusmodell till varuhusdatabas... Vi har... Vara (varunr, typ) Avdelning (avd, våning) Anställd (namn, lön, chef) Leverantör (företag, adress) Lager (företag, avd, varunr, volym) d. En M:N-sambandsklass bildar en tabell Försäljning (avd, varunr, volym) e. En 1:N-sambandsklass försvinner... Anställd (namn, lön, chef, avd) f. En 1:1-sambandsklass... Finns ingen DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2011 37 / 39
Från varuhusmodell till varuhusdatabas... slutresultat Vara (varunr, typ) Avdelning (avd, våning) Anställd (namn, lön, chef, avd) Leverantör (företag, adress) Lager (företag, avd, varunr, volym) Försäljning (avd, varunr, volym) DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2011 38 / 39
Nästa gång Modellering 1. Hur skapar vi och underhåller en databas? 2. Index? Vad är det? Behövs sånt? DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2011 39 / 39