Relationsdatabasdesign, 2I-4067

Transkript

1 Relationsdatabasdesign 2I-4067 Relationsdatabasdesign, 2I-4067 Lärare Maria Bergholtz, rum 4636, telefon 6658, Nikos Dimitrakas, Michael Persson, rum 2675, telefon 663, Peter Wibom, telefon Petia Wohed, rum 463, telefon 6674, Obligatoriska moment 2 Inlämningsuppgifter som redovisas på 2 Seminarier Tentamen av

2 Relationsdatabasdesign 2I-4067 Föreläsning Introduktion till relationsmodellen Informationssystem Konceptuell modellering ER-scheman Modelleringsmönster: - Supertyper - subtyper - kategori - Template-Copy - strukturer - Relationsobjekt - Ingår-i -strukturer Inlämningsuppgift 2 av

3 Relationsdatabasdesign 2I-4067 Konceptuell modell,m,t,p m,m,t,p dynamisk modell interactive & embeded SQL Användargränsnitt DBMS ISA,m,t,p kokbok transformering +normalisering DB 3 av

4 Relationsdatabasdesign 2I-4067 Vad är en databas? Logiskt sammanhängande mängd av data, med en därtill hörande betydelse, strukturerad och försedd med data avsedda för ett visst ändamål, en viss användargrupp i åtanke och återspeglande någon aspekt av världen. En gemensam samling av logiskt relaterade data för att möta ett företags informationsbehov. 4 av

5 Relationsdatabasdesign 2I-4067 Vad är ett databashanteringssystem? En mängd program som tillåter användaren att skapa och underhålla databaser 5 av

6 Relationsdatabasdesign 2I-4067 DATABASSYSTEM Användare/Programmerare Applikationsprogram/Frågor DBMS Program för att hantera frågor/program Program för att hantera lagrade data Lagrad databasdefinition (metadata) Lagrad databas 6 av

7 Relationsdatabasdesign 2I-4067 Problem med traditionella filbaserade system Data definieras i användarprogram Data måste dubbellagras för att kunna användas av flera användare Applikationsprogram är beroende av speciella filformat Data från olika filer kan vara icke kompatibla Data lagras på ett icke-användarvänligt sätt Mål för databasbaserade system Dataoberoende Delning Beständighet/flexibilitet 7 av

8 Relationsdatabasdesign 2I-4067 Relationsdatabasdesign Logisk relationsdatabasdesign Design- specificera form och struktur Designa - specificera form och struktur structur... fysisk db-design logisk db-design 8 av

9 Relationsdatabasdesign 2I-4067 Fysisk design En telefonkatalog innehåller en datamängd, där varje element består av namn, adress och telefonnummer. Katalogen består av ett antal A4-sidor där varje sida innehåller tre spalter. Ett dataelement upptar en eller flera rader. Dataelementen är sorterade på namn. Den beskriver hur data är representerat, inte vad det betyder. 9 av

10 Relationsdatabasdesign 2I-4067 Logisk design En telefonkatalog för ett område innehåller följande uppgifter: För alla hushåll i området som har telefon finns namn på en eller flera personer i hushållet, samt hushållets adress och telefonnummer Den beskriver vad data betyder, inte hur det är representerat. 0 av

11 Relationsdatabasdesign 2I-4067 Relationsdatabas En relationsdatabas är en databas som uppfattas av användaren som en samling tabeller - oberoende av hur datamängden fysiskt är lagrad. av

12 Relationsdatabasdesign 2I-4067 Relations schema Project PRNR START KLART PLATS BUDGET Attribut Domän t.ex. Domänen för attributen BUDGET är Integer större än noll Domän(BUDGET) = {x: x???z+} Grad - antal attribut 2 av

13 Relationsdatabasdesign 2I-4067 Project Relation PRNR START KLART PLATS BUDGET Prnr Goteborg 90 Prnr2 Prnr Falun Stockholm Tuppel ( sveng elska ) (Rad) Prnr Lund 550 Cell Kardinalitet - antalet rader (tuppler) 3 av

14 Relationsdatabasdesign 2I-4067 Egenskaper hos relationer Värden i varje cell är atomär Värden i varje kolumn är av samma typ Varje rad (tuple) är unik Ordningen mellan attributen är INTE oväsentlig Ordningen mellan raderna är oväsentlig Namnet för varje attribut är unikt för en relation 4 av

15 Relationsdatabasdesign 2I-4067 Relationsdatabasdesign Logisk databasdesign Logisk datamodell Fysisk databasdesign Sekundärminnesstrukturer för relationsdatabaser Transformation från logisk datamodell till relationsschema (syntetisk databasdesign) Normalisering av relationsschema (Analytisk databasdesign) Prestandaoptimering i relationsdatabaser 5 av

16 Relationsdatabasdesign 2I-4067 MODELLER Modell: En struktur som avbildar vissa aspekter av någon del av verkligheten Ex på modell - KARTA Modeller förenklar Modeller förvanskar - Grönland, Afrika Modeller fokuserar - topografisk, politisk 6 av

17 Relationsdatabasdesign 2I-4067 Konceptuell modellering En konceptuell modell beskriver data och datasamband på ett representationsoberoende sätt. Grundbegrepp: Objekt, Attribut (relationer), Typer (Entiteter), Regler. Objekt: företeelser av intresse Konkreta objekt: Eiffeltornet, George Washington, London Abstrakta objekt: Talet 7, Beethovens sjunde symfoni, Valutan Euro Attribut: Uttrycker relationer mellan objekt och egenskaper hos objekt. Typer (Entiteter) : Typer grupperar samman likartade objekt Konkreta typer: Personer, Byggnader, Bilar Abstrakta typer: Symfonier, Tal, Valutor Regler uttrycker vilka sakförhållanden som kan och bör föreligga i ett system En person kan vara gift med högst en annan person, En person måste ha ett personnummer. 7 av

18 Relationsdatabasdesign 2I-4067 Grafisk notation för konceptuella scheman: ER-diagram Entitet (typ) attribut (relation) APA Namn : Sträng 0.. äter..* BANAN attribut (relation) Avbildningsregel (för relationen, attributet) 8 av

19 Relationsdatabasdesign 2I-4067 ER-scheman på andra sätt : APA äter N BANAN Namn APA 0 äter BANAN Namn: Sträng 9 av

20 Relationsdatabasdesign 2I-4067 Attribut (relationer) har en DOMÄN och ett VÄRDEFÖRRÅD: APA Namn : Sträng 0....* BANAN Domän för äter är APA VÄrdeförråd för äter är BANAN Domän för namn är APA VÄrdeförråd för namn är Sträng En lexikal entitetstyp är en sträng eller ett tal (el. boolskt värde) Alla andra entiteter kallas icke lexikala entitetstyper. 20 av

21 Relationsdatabasdesign 2I-4067 BIL Regno : Sträng Avbildningsregler 0..* ägs_av PERSON Namn: Sträng En relation ( pil ) har avbildningsregler (kardinalitetsregler). Man kan sas läsa pilen i två riktningar och för varje riktning måste vi avgöra vilka avbildningsregler som gäller. Vi använder oss av en Minimum..Maximum -notation (alternativ finns...). I minimum-posistionen kan vi skriva värdet 0 eller. I maximimum -positionen kan vi skriva värdet eller *, där * står för många. Det ger oss fyra möjliga avbildningsregler: 0.., 0..*,.. och..*. I praktiken brukar man förkorta.. till. För att förstå vad de olika max..min-värdena står för kan vi börja med att betrakta relations-pilen från BIL:ens synvinkel. Om en BIL kan ägas av HÖGST EN PERSON så skriver vi en :a i max-positionen (annars *). Om en BIL måste ägas av NÅGON PERSON sätter vi en :a i min-positionen (annars 0). I just detta fall fattades beslutet att en BIL kan ägas av högst en person och att alla bilar ägas av någon. Dvs avbildningsregeln blev.., vilket vi förkortade till. Om en PERSON kan äga HÖGST EN BIl skriv en :a i max-position (annars *). Om en PERSON måste äga minst en BIL, skriv en :a i min-position (annars 0). Här tyckte vi att en PERSON kan äga många BIL:ar men inte nödvändigvis måste äga någon BIL, 0..*! 2 av

22 Relationsdatabasdesign 2I-4067 Avbildningsregler BIL Regno : Sträng ägs_av 0..* PERSON Namn: Sträng Även attribut (som t ex Regno och Namn) behöver få sina avbildningsregler bestämda. Detta kan i vissa notationer visas grafiskt i det konceptuella schemat (vilket har många fördelar). Ett sätt är att explicit rita ut relationen (via en pil) mellan entiteten i fråga och attributet: Regno BIL Sträng Ska utläsas varje BIL har högst ett registreringsnummer, Ett givet värde i mängden av text-strängar (t ex ABC23 ) kan vara relaterad till högst 0.. en BIL via attributet Regno. En BIL måste ha ett registreringnummer och, slutligen, det finns text-strängar (t ex Maria Bergholtz ) som inte utgör registreringsnummer. Som synes används samma princip som för avbildningsregler för relationer mellan entiteter. BIL Regno: Sträng UNIK, TOTAL Ett alternativ är att använda notationen ovan, den har nästan samma informationskapacitet som notationen till vänster ( en BIL kan ha högst ett värde på registreringsnummer, ett viss strängvärde hör till precis en BIL (dessa båda villkor gör Regno UNIKT) och en BIL måste ha ett registreringnummer (TOTAL:t). Däremot visar inte notationen ovan om det finns sträng-värden som inte utgör reg.nummer. 22 av

23 Relationsdatabasdesign 2I-4067 Modelleringsmönster: Arv Vilken verklighet man än vill avbilda så förekommer hierarkiska strukturer. Det betyder att vi måste fånga dessa strukturer i vår modell av samma verklighet. Däggdjur Djur Fåglar Gräsätare Rovdjur Pingvin Hovdjur Gnagare Tax Gnu Kanin 23 av

24 Relationsdatabasdesign 2I-4067 Konceptuell modell av en hierarkisk struktur: DJUR DÄGG- DJUR isa isa FÅGLAR HOVDJUR GRÄS- ÄTARE isa isa isa GNAGARE isa ROV- DJUR TAX isa isa PINGVIN isa isa GNU HARE 24 av

25 Relationsdatabasdesign 2I-4067 Boolean Militärtjänst 0..* isa MAN PERSON isa KVINNA 0.. Namn Arv Textsträng Heltal..* Skatt 0.. Pnr DJUR isa isa HUND KATT 0..* MAN och KVINNA är ömsesidigt uteslutande och uttömmande map PERSON HUND och KATT är ömsesidigt uteslutande men inte uttömmande map DJUR En arvs-hierarki består av sub- och supertyper. Subtyperna utgör en delmängd av supertypen. Om subtyperna täcker upp hela supertypen säger man att de är uttömmande (eng. exhaustive). Om en och samma instans inte kan tillhöra till flera subtyper säger man att subtyperna är ömsesidigt uteslut ande (eng. mutually independent). 25 av

26 Relationsdatabasdesign 2I-4067 Arv forts. En objekttyp kan ärva en annan objekttyp En objekttyp som ärver kallas subtyp Den objekttyp som ärvs från kallas supertyp Subtypen har samma attribut och samband som supertypen Subtypen kan ha ytterligare attribut och samband En supertyp kan vara abstrakt, dvs den kan inte instansieras Primärnyckeln för en subtyp måste vara densamma som för supertypen 26 av

27 Relationsdatabasdesign 2I-4067 Heltal Kundnr 0.. Arv Kund Kontohavare Konto..* Heltal Kontonr * Namn Textsträng Person Bankbok 0..* Börsnoterad Boolean Företag Arbetar på..* 0..* Lånesumma Heltal Lån Hur hade schemat blivit om isa-relationer inte använts? 27 av

28 Relationsdatabasdesign 2I-4067 Arv forts. Om subtyper har alla attribut och relationer gemensamma: Överväg att kombinera dem till en subtyp. Lägg ev. till ett extra attribut i entiteten som tjänas som typ-beteckning. Om en subtyp är uttömmande map supertypen: Låt subtypen uppgå i supertypen. Om flera subtyper inte har några egna attribut eller relationer: Överväg att göra dem till en subtyp. 28 av

29 Relationsdatabasdesign 2I-4067 Andra typer av hierarkiska strukturer CONTINENT stands_on 0..* COUNTRY belongs_to 0..* Detta är en hierarkisk struktur som inte utgörs av en sub/supertyps hierarki! CITY CITY situated_in 0..* STREET 29 av

30 Relationsdatabasdesign 2I-4067 Reifiering SJUKDOM..* botar 0..* BEHANDLING blir: botas BOT 0..*..* botmedel SJUKDOM procent 0..* Flyttal BEHAND- LING Relationen botar är M:M. Om man vill lagra information som berör relationen botar måste relationen reifieras, dvs göras till ett objekt. Övriga M:M kan lämnas som de är på modelleringsnivå, men måste brytas upp när man skapar en relationsdatabas! 30 av

31 Relationsdatabasdesign 2I-4067 Rekursiva strukturer ARTIKEL blir: Flyttal 0..* procent SPECIFIKATION 0..* 0..* består_av Som synes egentligen ett specialfall av reifiering! 0..* 0..* del_i ARTIKEL består_ av 3 av

32 Relationsdatabasdesign 2I-4067 Template-Copy strukturer Vissa objekt kan ses som mallar för andra objekt, kopior. En mall beskriver de generella dragen hos kopiorna som i sin tur kan innehålla ett antal idividuella drag. Mallar är ofta abstrakta objekt medan kopior är konkreta objekt. Kopior kan ses som materialiseringar av mallar. BOK är ett typiskt exempel på en mall, boken som ett litterärt verk. BOK:en har en titel, en författare osv. De individuella kopiorna är de fysiska exemplaren av det litterära verket som kan ha egenskaper som vikt, antal sidor etc. BOK titel 0..* KOPIA av_typ Textsträng Författare 0..* Titel..0 Vikt 0..* Textsträng Flyttal Observera att KOPIA inte utgör en delmängd av BOK. Template- Copies är inte samma sak som supertyp-subtyp. Heltal Antal_sidor 0..* 32 av

33 Relationsdatabasdesign 2I-4067 Provider-Transfer-Aquisition-Recipient strukturer PRODUCER producer 0..* PURCHASE 0..* article PRODUCT CONSUMER provider 0..* Provider-Transfer-Aquisition-Recipient strukturer är ett vanligt förekommande modelleringsmönster. Bilden till höger uttgör ett exempel på ett sådant mönster där PRODUCER är lika med Provider, PURCHASE lika med Transfer, PRODUCT svarar mot Aquisition och CONSUMER är lika med Recipient. Andra exempel: En person köper en bil från en bilhandlare En person lånar en bok från ett bibliotek En fotbollsklubb köper en spelare från en annan fotbollsklubb (PRODUCER och CONSUMER behöver alltså inte nödvändigtvis vara olika!) 33 av

34 Relationsdatabasdesign 2I-4067 Modelleringsarbete är ett SAMARBETE mellan verksamhetskunniga och systemkonstruktörer! Arbetet innefattar: analys skapande förhandling och beslut Arbetet kräver: erfarenhet fantasi/kreativitet kommunikationsförmåga 34 av

35 Relationsdatabasdesign 2I-4067 Differeces in Terminology Synonyms Homonyms Ex: lecturer teacher Ex: article Scale differences Ex: Dollar - Ecu Celsius - Fahrenheit 35 av

36 Relationsdatabasdesign 2I-4067 Differences in Structure MAN married_to WOMAN PERSON sex String MAN WOMAN PERSON husband wife ISA ISA MARRIAGE MAN WOMAN 36 av

37 Relationsdatabasdesign 2I-4067 Differences in Structure PERSON PERSON ISA of EMPLOYEE works_at COMPANY EMPLOY- MENT at COMPANY 37 av

38 Relationsdatabasdesign 2I-4067 Textsträng Namn 0.. PERSON Övning reifiering är_medlem_i Textsträng Klubbnamn KLUBB 0....* 0..* Uttöka det konceptuella schemat ovan så att det klarar av att representera att en viss person gick in i en viss klubb vid ett visst tillfälle! av