Idag Varför modellera? Varför modellera? Konceptuell modell sverktyg Objektklasser Sambandsklasser Knepiga attribut sprocessen 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 2010 1 / 40 DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2010 2 / 40 sverktyget sverktygets egenskaper 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 sverktyget 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 2010 3 / 40 DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2010 4 / 40
Databasmodellering Databasmodellering... 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 Informationssystemplanering Systemdefinition Kravanalys Databasdesign Konceptuell design DBMS-val Logisk design Applikationsdesign Utveckling av prototyp Fysisk design Implementation Datakonvertering och Laddning Testning Operationellt underhåll DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2010 5 / 40 DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2010 6 / 40 Databasmodellering... Vad modellerar man? 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 2010 7 / 40 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 2010 8 / 40
Objekt och objektklasser 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. 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) Person DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2010 9 / 40 DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2010 10 / 40 Objekt och objektklasser... 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 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 2010 11 / 40 DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2010 12 / 40
Objekt och objektklasser... Databasmodellering... 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 ( ). 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 2010 13 / 40 DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2010 14 / 40 Samband och sambandsklasser Sambandklassers grad Intressanta sambandsklasser brukar vara t.ex.: Allt som utgör en association mellan objektklasser:, 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. 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 2010 15 / 40 DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2010 16 / 40
Samband och sambandsklasser Samband och sambandsklasser Kvinna Chef Författare Gift_med Basar_över Skrivit Projekt Beställning Material Man Bok 1:1 1:N M:N DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2010 17 / 40 DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2010 18 / 40 Samband och sambandsklasser Samband och sambandsklasser kan vara knepiga Person Anställning gift Person granne Projektmedverkan Projekt kollega motpart DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2010 19 / 40 DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2010 20 / 40
Fördela egenskaper i modellen När man anser sig vara klar Oftast är det enkelt att bestämma var man ska representera en egenskap men man kan få lite huvudbry. projanst person 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 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 2010 21 / 40 DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2010 22 / 40 Exempel vårt (mycket enkela) varuhus 1. Det finns varor till försäljning 2. Det finns avdelningar där man säljer varorna DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2010 23 / 40 DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2010 24 / 40
3. Det finns anställda som sköter försäljningen 4. Det finns leverantörer som levererar varor DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2010 25 / 40 DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2010 26 / 40 5. Man håller reda på hur mycket varje avdelning säljer, 6. vilka som jobbar på avdelningarna Anställning DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2010 27 / 40 DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2010 28 / 40
7. och vad som levereras av vem till resp.avdelning Jag väljer en egenskapsmatris för att representera egenskaperna Typ Namn I-termer E-termer Anställning Lager Obj varunr typ avd våning namn lön, chef företag adress Samb avd, varunr volym namn, avd Lager företag, avd, varunr volym DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2010 29 / 40 DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2010 30 / 40 Variationer på modellverktyget (1) Variationer på modellverktyget (2) Anställning Lager Anställning Lager DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2010 31 / 40 DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2010 32 / 40
Idag 1. Från modell till databasstruktur Från verklighet via modell till databas 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 2. Prata med databaser (frågepsråket SQL) Kalle Eva Sport Sport Anders Mat Kalle, Eva och Anders förekommer endast en gång var i så vi kan lägga till avd i 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 2010 33 / 40 DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2010 34 / 40 Från verklighet via modell till databas Testa reglerna på varuhusmodellen 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 och senare, på övning, på större modeller 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 Anställning Lager Regel f komplicerar lite grand ger ett icke-deterministiskt inslag DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2010 35 / 40 DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2010 36 / 40
Från varuhusmodell till varuhusdatabas Från varuhusmodell till varuhusdatabas... a. En objektklass som innehåller e-term(-er) bildar en tabell (varunr, typ) (avd, våning) (namn, lön, chef) (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) Vi har... (varunr, typ) (avd, våning) (namn, lön, chef) (företag, adress) Lager (företag, avd, varunr, volym) d. En M:N-sambandsklass bildar en tabell (avd, varunr, volym) e. En 1:N-sambandsklass försvinner... (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 2010 37 / 40 DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2010 38 / 40 Från varuhusmodell till varuhusdatabas... slutresultat Nästa gång (varunr, typ) (avd, våning) (namn, lön, chef, avd) (företag, adress) Lager (företag, avd, varunr, volym) 1. Hur skapar vi och underhåller en databas? 2. Index? Vad är det? Behövs sånt? (avd, varunr, volym) DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2010 39 / 40 DD1370 (Föreläsning 3) Databasteknik och informationssystem 7,5 hp Hösten 2010 40 / 40