Databaser och databasdesign. Den relationella modellen, normalisering och modellering (2)

Relevanta dokument
Lite om databasdesign och modellering

Logisk databasdesign

Informationssystem och databasteknik

Modul DB1-1 Databasmodellering

Idag. Varför modellera? Modellering. Modelleringsverktygets egenskaper. Modelleringsverktyget

Idag. Modellering. Varför modellera? Konceptuell modell Modelleringsverktyg Objektklasser Sambandsklasser Knepiga attribut Modelleringsprocessen

Normalisering. Christer Stuxberg Institutionen för Informatik och Media

Vad är en databas? Databaser. Relationsdatabas. Vad är en databashanterare? Vad du ska lära dig: Ordlista

Idag. Varför modellera? Modellering. Modelleringsverktygets egenskaper. Modelleringsverktyget

Föreläsning 6: Normalisering & funktionella beroenden

Idag. Modellering. Varför modellera? Konceptuell modell Modelleringsverktyg Objektklasser Sambandsklasser Knepiga attribut Modelleringsprocessen

Databasdesign. E-R-modellen

Programdesign, databasdesign. Databaser - Design och programmering. Funktioner. Relationsmodellen. Relation = generaliserad funktion.

IT i organisationer och databasteknik

TENTAMEN. För kursen. Databasteknik. Ansvarig för tentamen: Cecilia Sönströd. Förfrågningar: Anslås inom 3 veckor

Databaser och Datamodellering Foreläsning IV

Tentamen 4,5 hp Delkurs: Databaser och databasdesign 7,5hp Tentander: VIP2, MMD2, INF 31-60, ASP

Webprogrammering och databaser. Konceptuell datamodellering med ER-modellen

Webprogrammering och databaser. Konceptuell datamodellering med ER-modellen

Karlstads Universitet, Datavetenskap 1

2. Redundans 3. Normalformer

Databaser - Design och programmering. Relationsmodellen. Relationer - som tabeller. Relationer som tabeller. Alternativa notationer: Relationsschema

Konceptuella datamodeller

Analytisk relationsdatabasdesign

Normalisering. Varför? För att åstadkomma en så bra struktur i databasen som möjligt med minimalt med dubbellagrad info.

Idag. Databaskvalitet(??) Databaskvalitet... Databaskvalitet...

GIS, databasteknik och kartografi. Databasmodellering

Modul DB1-2 Datamodellering

TENTAMEN. För kursen. Databasteknik. Ansvarig för tentamen: Cecilia Sönströd. Förfrågningar: Anslås inom 3 veckor

Databaser design och programmering. Design processen ER- modellering

Databaser design och programmering. Fö 2: Design processen, ER-modellering

Databaser Design och programmering

NORMALISERING. Mahmud Al Hakim

Vad är en databas? Databaser. Relationsdatabas. Vad är en databashanterare? Vad du ska lära dig: Ordlista

TENTAMEN För kursen. Databasteknik. Ansvarig för tentamen: Anna Palmquist. Förfrågningar: Anslås inom 3 veckor

Ett arbetsexempel Faktureringsrutin

Tentamen ISGB01, ISGB24. Databasdesign 7,5 Poäng

Föreläsning 3 Transformation från konceptuell datamodell till relationsschema ( Syntetisk databasdesign ) Vad är ett databashanteringssystem?

Karlstads Universitet, Datavetenskap 1

Logisk modell. Fysisk modell. Datamodeller Konceptuell modell

Tentamen EIT:DB Databastmetodik 11/ kl Lösningsförslag

Relationsdatabasdesign

Design och underhåll av databaser

Tentamen plus lösningsförslag

Tentamen ISGB01 (delkurs i ISGB24) Databasdesign 7,5 Poäng

Databasteori. Övningar

Webbprogrammering, grundkurs 725G54

Tentamen DATABASTEKNIK - 1DL116

Tentamen. i Databasteknik. lördagen den 13 mars Tillåtna hjälpmedel: Allt upptänkligt material

TENTAMEN. För kursen. Databasteknik. Ansvarig för tentamen: Cecilia Sönströd. Förfrågningar: Anslås inom 3 veckor

Vad är en databas? Exempel på databaser: Databas = Organiserad samling och lagring av information.

TENTAMEN. För kursen. Databasteknik. Ansvarig för tentamen: Cecilia Sönströd. Förfrågningar: Anslås inom 3 veckor

Tentamen NDA01G Öppen för alla. Tentamenskod: Inga hjälpmedel är tillåtna

Introduktion till databaskursen. Välkomna. till kursen. Databasteknik och informationssystem. DD1370 (kursomgång dbtinf12)

Tentamen för DD1370 Databasteknik och informationssystem

Relationell databasdesign

Varför ska man lära sig sånt? Välkomna. Vad är databaser bra till? Kursansvarig. till kursen. Databasteknik och informationssystem

Universitetet: ER-diagram

Tentamenskod: Tentamensdatum: Tid: 14:00-19:00. Inga hjälpmedel är tillåtna

Databasdesignspecifikation för Mätvärdeshanteringssystem

Varför ska man lära sig sånt? Välkomna. Vad är databaser bra till? Kursansvarig. till kursen. Databasteknik och informationssystem

Skriftlig tentamen i kurserna TDDD12 och TDDB48 Databasteknik kl

Tentamen. Databasmetodik Lördag 27 september 2014 kl

Disposition. 1. Kopplingen mellan Processanalys (DFDdiagram) 2. Treskikts Client-Server arkitektur (Fig 1.8) 3. Data layer

Databaser. Vad du ska lära dig: Ordlista

Rättningsmall tenta den 25e oktober Uppgift 1. Uppgift 2. se slides

Karlstads Universitet, Datavetenskap 1

Lösningsförslag till. tentamen för 1E1601

Exempel-Tentamen III

! Webprogrammering. ! Databasteori och praktik. ! Fö, le, la + projekt. ! Examination (tenta, dugga + labb, ! Studera användarna och deras problem

Föreläsning 3 Dagens föreläsning går igenom

Föreläsning 4 Transformation från konceptuell datamodell till relationsschema ( Syntetisk databasdesign ) Normalisering (Analytisk databasdesign)

Innehåll MySQL Intro. Ex på ett index Index typer ISAM Balanserat träd Pk och Fk i MySQL Eget index För o nackdelar med index

Frågor att lösa med SQL mot databasen kursdb_sql Sida 1 av 5

Tentamen 2I1033, IT i Organisationer och Databasteknik lördag 17/4 2004, kl LÖSNINGSFÖRSLAG

Relationsmodellen och syntetisk databasdesign

Lösningsförslag till fiktiv tentamen för DD1370 Databasteknik och informationssystem

(Data)Modellering. nikos dimitrakas rum 2423

Idag. Hur vet vi att vår databas är tillräckligt bra?

Grunderna för relationsmodellen!

TENTAMEN TDDB77 Databaser och Bioinformatik 12 juni 2007, kl 14-18

Del 2: ER-modellering och överföring till Databasstruktur v0.9

TDDD12 och TDDD46 Databasteknik. Lena Strömbäck

Webprogrammering och databaser. 729G28 Webprogrammering och databaser. Kursöversikt. Praktisk info. Webprogrammering. Ändringar mot förra året

TENTAMEN TDDB77 Databaser och Bioinformatik 15 mars 2002, kl 14-18

Webprogrammering och 729G28 databaser Webprogrammering och databaser Kursöversikt Webprogrammering Designprocessen Lösningsförslag

Lösningsförslag till tentamen för DD1370 Databasteknik och informationssystem

Databasteori Övningar

2NF Hästnamn, KursId, StartDatum, SlutDatum KursId NY!, där RIDKURS.KursId = KURS.KursId 3NF Hästnamn, Art, NY! NY! NY! NY!

TENTAMEN TDDB77 Databaser och Bioinformatik 24 april 2004, kl 14-18

Databaser och databasdesign, 7,5 hp

Lösningsförslag till Tentamen,

GIS, databasteknik och kartografi. Kursmaterial för databasdelen

Kompendium till databaser och informationssystem 10p för SY2 2000

Informationssystem och Databasteknik

Funktionella beroenden - teori

Laboration 1, Datamodellering. Observera. Tips. Förberedelse. Genomförande

Modul DB1-3 Datamodellering

Inst. för Data- och Systemvetenskap SU Maria Bergholtz. Tentamen. 21/ kl Inga hjälpmedel är tillåtna (annat än ordbok).

Transkript:

Databaser och databasdesign Den relationella modellen, normalisering och modellering (2)

Varför databaser (DB)? Vi vill och måste kunna lagra data på sätt som motsvarar olika verksamheters behov Vad är grundläggande? Grundläggande är att vi kan lägga till, ändra och ta bort data, och att lagrad data är korrekt Spelar databasdesignen nån roll? Designen är kritisk för att en databas ska fungera som önskat; för att vi effektivt kunna söka, hitta och lista data. 2

Databaser designas vi har en designuppgift! Modellering och design av relationsdatabaser bygger på: att vi korrekt analyserar vilka data som ska lagras att vi identifierar rätt objekt att lagra data om Objekten kan beskrivas grafiskt med en rektangel och objektets namn. Namnet ska vara beskrivande och i singular: Medlem Fordon Beställning 3

Objektsegenskaper De objekt vi identifierar har egenskaper (jfr. entiteter respektive attribut) En analys kan leda till att vi tilldelar ett objekt Medlem egenskaper som: Namn Adress Telefon E-post 4

Relationer/samband (1) Objekten har relationer till varandra. Vi kan identifiera relationer eller samband genom: association t ex att Kund gör Beställning eller Kund lägger Order struktur t ex att Order innehåller Artiklar 5

Relationer/samband (2) Vi kan behöva modellera relationer av typen en-tillmånga eller kort sagt 1:M. Ett exempel: Om en leverantör levererar flera produkter råder en 1:M-relation mellan Leverantör Produkt. Utläses som: En leverantör kan leverera många produkter. Vi kan benämna relationen Levererar 6

Relationer/samband (3) Vi kan behöva modellera relationer av typen många-till-många, kort sagt M:M. Ett exempel: En student kan läsa flera kurser, och en kurs kan läsas av flera studenter. Det råder en M:M-relation mellan Student Kurs. Vi kan benämna relationen Läser 7

På väg mot en E/R-graf Vi kan illustrera objekt och relationer med symboler: Leverantör Levererar Produkt 1 M 8

E/R-grafen En E/R-graf är en modell som visar alla viktiga objekt, objekts relationer och egenskaper (Se Chen notation). 9

10

I relationsdatabasen knyts objekt (tabeller) ihop till en logisk helhet genom ett nyckelsystem och matchning av värden Primärnyckel (PN) unik, identifierare PN Främmande nyckel (FN) - referens till PN i en primärtabell StudentID Fnamn Enamn ProgramID 8201139901 Anna Ek VIP07-10 8611221113 Hanna Ström IT106-09 8403200278 Bo Ahlberg VIP07-10 ProgramID VIP07-10 IT106-09 WEB05-08 Programbeskrivning Programmet syftar till... Programmet syftar... Programmet... 11

1:M relation En leverantör kan leverera många (flera) produkter. Leverantör LevID Leverantörsnamn Adress Tel Postnr 1001 Stål & Rost AB Sveavägen 1 629752 116 32 1002 Handelskompaniet Brogatan 12 173210 305 44 1033 ICA Flygstaden 1 700009 311 66 Produkt ProduktID Produktnamn Mått LevID 12-B-105 Fjäderbricka 6 1001 12-B-339 Bult 6 1001 10-A-991 Mutter 12 1002 12

Modelleringsregler 1:M I en 1:M-relation relation "lånar" objektet på M-sidan den identifierande egenskapen( PgmId) från objektet på 1-sidan, som blir en FN (referens) till primärtabellen Pnr Fnamn Enamn PgmID PgmID Pgmbeskrivning Student M Program Student Pnr Fnamn Enamn PgmId 1001 Anna Ek 1 1002 Hanna Ström 2 1006 Bo Al 2 Program PgmId Pgmbeskrivning 1 Programmet syftar till 2 Programmet syftar 13

FN ett eller fler attribut (kolumn) vars värden matchar ett värde för PN i relaterad tabell (primärtabellen) StudentID Fnamn Enamn Adress Postnr ProgramID 8201139901 Ann Ek Stigen 2 305 72 VIP07-10 8611221113 Eva Ström Ekvägen 1 119 34 IT106-09 8403200278 Bo Ahlberg Urgränd 9 305 72 VIP07-10 PN identifierande attribut (kolumn) med unika värden 14

M:M relationen involverar ett relationsobjekt Komposit/sammansatt PN {Ordernr, Artnr} Orderspec PN Order Ordernr Artnr Antal Ordernr Datum Kundnr 1001 110603 A-2137 1009 110722 B-4359 1001 12-B-105 75 1001 12-B-339 50 1009 10-A-991 300 PN Artikel Artnr Beskrivning Pris 12-B-105 SonyPS3 3990 12-B-339 PS3CoD 549 10-A-991 PS3PoP 650 15

Modelleringsregler M:M ex. (2) En M:M-relation kan ses som två 1:M-relationer. När en relation är M:M- skapar vi ett tredje objekt vars inlånade nycklar blir PN och FN. Beställning Bestnr Datum Kundnr 1001 060812 P13943 1009 060901 F00231 1 M Artikel M Artnr Artikel Pris 1 12-B-105 Mutter 3,50 12-B-339 Skruv 9,00 10-A-991 Bricka 1,35 Beställningsspecifikation Bestnr Artnr Antal 1001 12-B-105 75 1001 12-B-339 50 1009 10-A-991 300 relationsobjekt kallas ibland kopplingstabell 16

Funktionella beroenden (1) Funktionellt beroende (FD) definition: Låt R vara en relation och X och Y attribut i R. Då kan vi säga att Y är funktionellt beroende av X om, och endast om, varje X-värde i R är associerat med precis ett Y-värde i R. R X Y 1001 A 1002 B X är en determinant, bestämmer Y X Y 17

Funktionellt beroende (2) FD ett attribut bestämmer ett annat Tabellen Kund innehåller icke-nyckel attributen Kund, Adress Postnr och Ort. Ort är funktionellt beroende av Postnr värdet på postnummer bestämmer värdet för Ort; postnummer är determinant. Kund KundNr Kund Adress Postnr Ort 1001 Willys Storgatan 1 961 67 Boden 1002 Maxi Grågränd 3 961 67 Boden 1003 Arla Byholmen 961 98 Boden 18

Funktionellt beroende (3) Vilka funktionella beroenden som råder mellan attribut i en tabell bestäms av verksamhetsregler - inte av vilka data som lagras vid ett visst tillfälle! Vi kan se är vilka FD:s som ev. kan finnas; genom att de inte motsägs av de data som finns lagrade. 19

Vilka FD:s kan respektive kan inte finnas i tabellen nedan? A B C D 1 4 10 100 2 5 20 50 3 6 20 200 1 4 10 200 2 6 20 2 3 6 20 300 1 4 10 3 2 6 20 50 3 6 20 50 20

Det kan inte finnas ett FD: A B, då det för ett och samma värde på A finns olika värden på B. A B C D 1 4 10 100 2 5 20 50 3 6 20 200 1 4 10 200 2 6 20 2 3 6 20 300 1 4 10 3 2 6 20 50 3 6 20 50 Det kan t ex finnas ett FD: A C och B C. 21

Fullständigt funktionellt beroende (FFD) Attributet Antal i tabell Orderspec nedan är FFD av PN {OrderNr, ArtikelNr} av hela PN inte av en del av PN Det går inte att reducera PN (komposit), utan att PN förlorar sin unikt identifierande egenskap OrderNr och ArtikelNr behövs för att fastställa hur många artiklar som ingår i en viss order OrderNr ArtikelNr Antal OrderNr# Antal? (motsägs av data) 1001 101 2 ArtikelNr# Antal? (ej tidsoberoende) 1001 103 1 {OrderNr#, ArtikelNr#} Antal (gäller) 1001 105 3 1002 101 2 22

Normalisering (1) Normalisering är att tillämpa ett antal regler för att uppnå vissa centrala designmål en formell metod för att ge DB önskvärda egenskaper Normalisering av en relation/tabell kan innebära att den delas upp i flera tabeller, med vissa gemensamma data (jfr. PN och FN) 23

Normalisering (2) - formell grund för analys av DB utifrån nycklar och funktionella beroenden mellan attribut - konkreta riktlinjer för hur DB/tabeller bör designas för att undvika bl a redundans (onödig dubbellagring av data) och uppdateringsproblem - ett antal tester som kan göras för att kontrollera om en DB uppfyller villkoren för en viss normalform 24

Normalisering (3) - fem normalformer: 1NF 5 NF - varje normalform har vissa villkor som måste uppfyllas - en relation R sägs vara i en viss normalform om den uppfyller kraven som definierats för normalformen 25

Normalformer - 1NF endast ett värde i varje rad/kolumnposition (fält) tabellen ska ha en primärnyckel 127763-A1 Karl Larsson 035-173064, 070-353243 Haverdal 26

Normalformer - 2NF Tabellen uppfyller kraven för 1NF plus alla icke-nyckelattribut fullständigt funktionellt (FFD) beroende av hela primärnyckeln Normalformen gäller tabeller med komposit PN. Om inte alla icke-nyckelattribut är FFD av hela PN, så skapa en ny tabell med de beroende attributen och den del av PN de bestäms av 27

Ex. 2 NF och normalisering OrderNr ArtikelNr Antal Beskrivning Spec Vikt 1001 101 2 Mutter M6 20 1001 103 1 Skruv M12 40 1001 105 3 Bricka M12 3 1002 101 2 Mutter M6 20 ArtikelNr Beskrivning Spec Vikt 101 Mutter M6 20 103 Skruv M12 40 105 Bricka M12 3 101 Mutter M6 20 28

Normalformer - 3NF Tabellen uppfyller kraven för 2NF plus innehåller ej transitiva beroenden som t ex Kundnr Postnr Ort. Relationer i 3NF får ej innehålla icke nyckel-attribut som är funktionellt beroende av varandra KundNr Kund Adress Postnr Ort 1001 Willys Storgatan 1 961 67 Boden 1002 Maxi Grågränd 3 961 67 Boden Postnr Ort 961 67 Boden 961 98 Boden För att en DB skall vara i 3NF, måste alla tabeller uppfylla kraven för den normalformen! 29

Varför normalisering? Om en DB uppfyller villkoren för 3NF fungerar ofta grundläggande operationer (tillägg, uppdatering, borttagning på postnivå) utan problem vi blir även av med omotiverad redundans Normalisering underlättar uppdateringar, men ökar utsökningstiden (det omvända kan gälla för redundans) 30

Redundans och inkonsistens? 31

Förlustlös dekomposition? - En relation (tabell) som normaliserats måste kunna återskapas utan att data förloras; återskapas som den var innan normalisering 32

Ex. multivärda attribut (a) Kund Adress Kundnr {PN} Adress Tel [1-3] Kundnr# Kund Tele (b) Kund Har Kundtele Kundnr {PN} Adress 1.. 1 1.. 3 Kundtel {PN} Typ 33

Informationssystem (IS) livscykel och databasdesign Informationssystemplanering Systemdefinition Kravanalys Konceptuell design Val av DBMS? Logisk design Fysisk design Utveckla prototyp Applikationsdesign Implementering Datakonvertering Testning Drift och underhåll 34

Konceptuell databasdesign? Logisk databasdesign? Fysisk databasdesign (se C & B s.417, 436, 440-ff) 35

Framgångsfaktorer DB-design (ex.) - arbeta interaktivt med användare - välj ett datadrivet angreppssätt - använd en strukturerad metod vid datamodellering - inkludera eller bilägg struktur- och integritetsvillkor i modellen - validera konceptualisering, normalisering, transaktioner - komplettera modellen med DD (data dictionary) 36