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 2) Databasteknik och informationssystem 7,5 hp Hösten 2009 1 / 33 DD1370 (Föreläsning 2) Databasteknik och informationssystem 7,5 hp Hösten 2009 2 / 33 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 2) Databasteknik och informationssystem 7,5 hp Hösten 2009 3 / 33 DD1370 (Föreläsning 2) Databasteknik och informationssystem 7,5 hp Hösten 2009 4 / 33
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 al 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 2) Databasteknik och informationssystem 7,5 hp Hösten 2009 5 / 33 DD1370 (Föreläsning 2) Databasteknik och informationssystem 7,5 hp Hösten 2009 6 / 33 Databasmodellering... Vad modellerar man? Vi kommer till att börja med bara bekymra oss om den streckade boxen med titeln Databasdesign och anta att det övriga är klart. På labbarna kommer vi testa SQL de facto standard för manipulation av databaser och vi kommer snegla lite på implementation DD1370 (Föreläsning 2) Databasteknik och informationssystem 7,5 hp Hösten 2009 7 / 33 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 2) Databasteknik och informationssystem 7,5 hp Hösten 2009 8 / 33
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) DD1370 (Föreläsning 2) Databasteknik och informationssystem 7,5 hp Hösten 2009 9 / 33 DD1370 (Föreläsning 2) Databasteknik och informationssystem 7,5 hp Hösten 2009 10 / 33 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.: nr 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: nr 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 2) Databasteknik och informationssystem 7,5 hp Hösten 2009 11 / 33 DD1370 (Föreläsning 2) Databasteknik och informationssystem 7,5 hp Hösten 2009 12 / 33
Objekt och objektklasser... Databasmodellering... Klass Namn I-termer E-termer Objekt nr 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 2) Databasteknik och informationssystem 7,5 hp Hösten 2009 13 / 33 DD1370 (Föreläsning 2) Databasteknik och informationssystem 7,5 hp Hösten 2009 14 / 33 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 2) Databasteknik och informationssystem 7,5 hp Hösten 2009 15 / 33 DD1370 (Föreläsning 2) Databasteknik och informationssystem 7,5 hp Hösten 2009 16 / 33
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 2) Databasteknik och informationssystem 7,5 hp Hösten 2009 17 / 33 DD1370 (Föreläsning 2) Databasteknik och informationssystem 7,5 hp Hösten 2009 18 / 33 Samband och sambandsklasser Samband och sambandsklasser kan vara knepiga Anställning gift granne Projektmedverkan Projekt kollega motpart DD1370 (Föreläsning 2) Databasteknik och informationssystem 7,5 hp Hösten 2009 19 / 33 DD1370 (Föreläsning 2) Databasteknik och informationssystem 7,5 hp Hösten 2009 20 / 33
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 2) Databasteknik och informationssystem 7,5 hp Hösten 2009 21 / 33 DD1370 (Föreläsning 2) Databasteknik och informationssystem 7,5 hp Hösten 2009 22 / 33 1. Det finns varor till försäljning 2. Det finns avdelningar där man säljer varorna DD1370 (Föreläsning 2) Databasteknik och informationssystem 7,5 hp Hösten 2009 23 / 33 DD1370 (Föreläsning 2) Databasteknik och informationssystem 7,5 hp Hösten 2009 24 / 33
3. Det finns anställda som sköter försäljningen 4. Det finns leverantörer som levererar varor DD1370 (Föreläsning 2) Databasteknik och informationssystem 7,5 hp Hösten 2009 25 / 33 DD1370 (Föreläsning 2) Databasteknik och informationssystem 7,5 hp Hösten 2009 26 / 33 5. Man håller reda på hur mycket varje avdelning säljer, 6. vilka som jobbar på avdelningarna Anställning DD1370 (Föreläsning 2) Databasteknik och informationssystem 7,5 hp Hösten 2009 27 / 33 DD1370 (Föreläsning 2) Databasteknik och informationssystem 7,5 hp Hösten 2009 28 / 33
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 2) Databasteknik och informationssystem 7,5 hp Hösten 2009 29 / 33 DD1370 (Föreläsning 2) Databasteknik och informationssystem 7,5 hp Hösten 2009 30 / 33 Variationer på modellverktyget (1) Variationer på modellverktyget (2) Anställning Lager Anställning Lager DD1370 (Föreläsning 2) Databasteknik och informationssystem 7,5 hp Hösten 2009 31 / 33 DD1370 (Föreläsning 2) Databasteknik och informationssystem 7,5 hp Hösten 2009 32 / 33
Nästa gång 1. Från modell till databasstruktur 2. Prata med databaser (frågepsråket SQL) DD1370 (Föreläsning 2) Databasteknik och informationssystem 7,5 hp Hösten 2009 33 / 33