2. Redundans 3. Normalformer

Transkript

1 FÖ 6: Databaskursen 1. Normalisering 2. Redundans 3. Normalformer 4. UNF, 1NF, 2NF och 3NF 5. Funktionellt beroende 6. Determinanter 7. Datamodellering 8. Notation 9. Olika modeller 10. Begreppslista 11. Termkatalog 12. Bra och dåliga datamodeller 1 Pär Douhan, pdo@du.se

2 Normalisering Vi börjar med normalisering 2

3 Normalisering Normalisering i samband med datamodellering: Normalisering är en process för att avgöra vilka attribut som skall grupperas tillsammans i en tabell. Bygger på Ted Codd's normaliseringsregler. Det är en teori som används för att undvika dålig design på sin databas. Där dålig design medför problem vid borttag och uppdatering av data, dt samt en massa fysisk ik redundans. 3

4 Redundans redundans [-ah s el. -an s] subst. ~en Ordled: red-und-ans-en överflöd Bet.nyans: spec. överskott av information <term inom informationsteori, språkvetenskap m.m.> Det finns olika typer av redundans: 1. Fysisk redundans: När vi lagrar samma data på flera rader i en tabell (dubbellagring). Detta betraktas som någonting dåligt i samband med datamodellering. När vi får den här typen av redundans har vi för låg grad av normalisering. 2. Infologisk redundans: Data som kan härledas ur redan lagrad data. Ett exempel kan vara om vi lagrar data om egenskapen diameter hos olika bollar. Om vi även skulle lagra data om egenskapen volym så skulle detta vara exempel på infologisk redundans. Detta då vi lätt kan beräkna volymen hos en boll om vi vet dess diameter, d.v.s. volymen kan härledas utifrån diametern. 4

5 UNF UNF, Unnormalized Form: Tabell som innehåller en eller flera rader med icke atomära värden i celler. HYRDA_FILMER knr fnamn enamn mobil filmnr titel genre speltid åldersgräns 1 Eik Erik Olsson , Ouija, Horror, 89, 18, 856 Unbroken Drama Sven Eriksson Unbroken Drama Maria Ek Duplex Komedi 89 7 Tabellen e befinner e sig i UNF.. Det finns flera ea celler cee som innehåller eåe icke atomära a värden. Om vi tittar på kund med knr = 1, så ser vi exempel på detta i cellerna titel, genre, speltid och åldersgräns. Detta kommer inte att fungera i en relationsdatabas. 5

6 1NF 1NF, Första Normalformen: Unika rader HYRDA_FILMER Atomära värden i celler knr fnamn enamn mobil filmnr titel genre speltid åldersgräns 1 Erik Olsson Ouija Horror Erik Olsson Unbroken Drama Sven Eriksson Unbroken Drama Maria Ek Duplex Komedi 89 7 Tabellen uppfyller nu kraven för INF. Alla celler innehåller atomiska värden och varje rad är unik. Men det finns fortfarande problem: 6 1. Fysisk redundans, t. ex. är Erik Olssons mobilnummer är dubbellagrat (redundant). 2. Svårt att se vad tabellen betyder. Innehåller den information om kunder? Filmer? Uthyrda filmer? Det blir problem att ge tabellen ett bra namn.

7 FB, Funktionellt beroende X -> Y "Y är funktionellt beroende av X" "X determinerar (bestämmer) Y" "X är en determinant (då den determinerar) Y" "På varje rad, i en tabell Bil, där regnr = 'FND770', så kommer det alltid att stå 'mörkgrön' ö ' i kolumnen färg". Exempel på determinanter: personnummer -> förnamn postnummer -> stad ordernummer -> orderdatum ISBN -> boktitel 7

8 2NF 2NF, Andra Normalformen: INF Varje icke nyckelattribut ska vara beroende av hela PK STUDENT studnr fnamn enamn mobil 20 Vincent Ortiz Lena Ek Carl Björk KURS kursnr kursnamn poäng ämne 400 Java med swing 7.5 Informatik 450 Databaser 7.5 Informatik 800 Redovisning 15 Ekonomi TENTAMEN id studnr kursnr datum ects tolkas E tillräckligt B mycket bra E tillräckligt 8

9 FB - 2NF Vi ritar de funktionella beroenden som finns i föregående exempel på 2NF: datum ects id studnr fnamn enamn mobil kursnr kursnamn tolkas poäng Definition av 3NF: ämne 2NF Får inte innehålla några inbördes beroenden mellan icke-nyckelattribut (transitiva beroenden) ects tolkas För att uppfylla 3NF måste delberoendet bort! 9

10 3NF 3NF, Tredje Normalformen: 2NF Får inte innehålla några inbördes beroenden mellan ickenyckelattribut (transitiva beroenden) STUDENT studnr fnamn enamn mobil 20 Vincent Juares Lena Ek Carl Björk KURS kursnr kursnamn poäng ämne 400 Java med swing 7.5 Informatik 450 Databaser 7.5 Informatik 800 Redovisning 15 Ekonomi TENTAMEN id studnr kursnr datum ects E B BETYG ects tolkas ugvg A Utmärkt VG B Mycket bra VG E C Bra G 10

11 Växa i sidled När vi skapar en datamodell ska vi se till att tabeller inte behöver växa i sidled. D.v.s. vi ska inte behöva lägga till kolumner under driften av systemet. Studera följande exempel: LEVERANTÖR levnr namn kontaktperson1 kontaktperson2 20 ICA Urban Karlsson Roger Nyberg 30 COOP Maria Ekholm Om det tillkommer fler kontaktpersoner, så måste vi lägga till nya kolumner till tabellen. Detta är en dålig konstruktion. 11

12 Växa i sidled Vi konstruerar datamodellen så att vi lägger till nya rader, istället för kolumner. Vi ska kunna lösa problemet med DML (insert) och inte med DDL (alter). LEVERANTÖR levnr namn 20 ICA 30 COOP KONTAKTPERSON kontaktnr levnr kontaktperson 1 20 Urban Karlsson 2 20 Roger Nyberg Om det finns behov av att lägga till fler kontaktpersoner, så kan vi lösa detta genom att lägga till ny data i 3 30 Maria Ekholm tabellen Kontaktperson. 12

13 Slutsatser om normalisering Se till att din datamodell alltid uppfyller 3NF. Detta innebär att en tabell ska lagra information i om en företeelse, t. ex. kunder, fordon, fakturor, offerter etc. Alla kolumner som inte är PK eller FK ska beskriva (beteckna) denna företeelse och ingenting annat. Detta kommer att medföra att datamodellen blir flexibel. D.v.s. den går lätt att anpassa till nya situationer. ti Det kommer att vara enkelt att ge tabellerna bra namn. Datamodellen blir tydlig och lätt att förstå. 13

14 Datamodeller Vi fortsätter med datamodeller 14

15 Konceptuella modeller (repetition) Man bör inleda den infologiska delen av systemutvecklingsarbetet genom att modellera det stycke verklighet som IS (informationssystemet) ska handla om, och den verksamhet som IS ska understödja. Denna verklighet och verksamhet kallar vi också för objektsystemet. Objektsystemet t t = Object system = Reality of interest t = Universe of Discourse 15

16 Användarens bild av verkligheten Objektsystemet eller Universe of Discourse är användarens bild av en bit verklighet. 16

17 Repetition PERSON # persnr * fnamn * enamn o mobil ÄGARBYTE # id (#) persnr (#) regnr * datum 1 M M 1 FORDON # regnr * färg * märke * modell # Primary key (#) Foreign key * Mandatory o Optional M M M PK bildar FK i gaffelns riktning (vänster-höger) 17

18 Alternativ notation PERSON # persnr * fnamn * enamn o mobil ÄGARBYTE # id (#) persnr (#) regnr * datum 1 M M 1 FORDON # regnr * färg * märke * modell Pilar och gafflar används på motsatt sätt. En pil används för att peka ut varifrån en FK kommer, d.v.s. var den har sin parent-tabell bll(pk) (PK) M 18

19 Alternativ notation PERSON # persnr * fnamn * enamn o mobil ÄGARBYTE # id (#) persnr (#) regnr * datum 1 M M 1 FORDON # regnr * färg * märke * modell Ofta brukar bägge notationssätten kombineras för bästa tydlighet. 1 M 19

20 1:1 KUND # knr * fnamn * enamn o mobil 1 1 MEDLEM # mnr * regdatum En kund kan ha ett medlemskap. Ett medlemskap kan bara tillhöra en kund. Detta är ett exempel på ett 1:1 förhållande. I vilken tabell ska vi lägga en FK? Ska knr bilda FK i tabellen Medlem eller ska mnr bilda FK i tabellen Kund? 20

21 Undvik att skapa NULL-värden KUND # knr * fnamn * enamn o mobil 1 1 MEDLEM # mnr (#) knr * regdatum Vi kan välja vilket vi vill, men vi ska undvika att skapa onödiga NULLvärden. Om vi lägger in mnr som FK i tabellen Kund så kommer varje kund som inte vill bli medlem att få ett NULL-värde i kolumnen mnr. I detta fall är alltså den bästa lösningen att skapa en FK knr i tabellen Medlem. På detta sätt slipper vi NULL-värden. Detta då alla medlemmar som skapas måste ha en referens till en kund. 21

22 Olika modeller Olika metoder för att skapa datamodeller: 1 Top Down (OPR Framework) Identifiera viktiga entitet, begrepp eller verksamhetsobjekt samt relationer mellan dessa. M:M relationer bildar nya tabeller. 2 Action-oriented Conceptual modelling Här identifieras även handlingar som egna objekt direkt utan att gå omvägen via en relation. Dessa objekt brukar kallas för kommunikativa objekt eller institutionella objekt. Exempel på objekt kan vara: orderbekräftelse, olika erbjudanden, en begäran om att få betalt (faktura). Ibland närmar man sig detta tankesätt i OPR-modellen genom att säga att man objektifierar en relation. 3 Bottom Up 22 Vi kan studera funktionella beroenden mellan olika attribut.

23 Gemensamt Gemensamt för alla modeller är: Begreppslista och termkatalog brukar användas för att dokumentera modellen. I begreppslistan dokumenteras verksamhetsobjekten. Vi ger begreppen bra namn som alla i verksamheten känner till. Vi beskriver vilket syfte som begreppet har i vårt system. Varför finns denna tabell? Vilken funktion fyller den? I termkatalogen dokumenterar vi alla egenskaper eller attribut för verksamhetsobjekten. Vi bestämmer vilka attribut som ska identifiera objekten. Vi bestämmer vilka attribut som krävs för att beteckna (beskriva objekten) på ett tillräckligt bra sätt för att verksamheten ska fungera. Beskriv och vilken funktion som attributen har. Varför finns just detta attribut med i vår tabell? Denna dokumentation o utgör grunden för ett gemensamt e verksamhetsspråk. etssp. Detta är mycket viktigt! 23

24 Begreppslista Exempel på hur en begreppslista (begrepp = tabell) kan se ut: Begrepp Definition Identifierare System Kund Tabellen lagrar information om kunder. kundnr WeSell Kundorder d En kundorder d ordernr WeSell Sll medför att en kund kan beställa artiklar vid olika tidpunkter. Faktura En begäran att få betalt av en kund för varor som kunden fått levererade. fakturanr WeSell Alla IT-system ska ha ett namn! 24

25 Termkatalog Exempel på hur en termkatalog (term = attribut) kan se ut: Term Definition Identifierare Begrepp ordernr Används för att unikt identifiera en kundorder. ja Kundorder kundnr Beskriver vilken nej Kundorder d kund det är som äger kundordern. orderdatum Beskriver när nej Kundorder kundordern skapades. År, dag och tidpunkt. kundnr Används för att ja Kund unikt identifiera en kund. 25

26 Rita tydliga modeller Förslag från Bo Sundgren: Actors, aktiva objekt Complex Objects, objekt (Handlingar) ad ga) obje t Utilities, Passiva objekt Person Activity (Process) Resource, (Tjänst) Organisation Event Product Relation Atomic objects, things, concrete or abstract 26

27 Exempel på en dålig modell 27

28 Exempel på en bra modell Aktiva objekt Komplexa objekt Passiva objekt 28

29 Exempel Vi skall nu studera hur man kan komma fram till nedanstående exempelmodell genom att använda de tre metoderna. PERSON # persnr * fnamn * enamn o mobil ÄGARBYTE # id (#) persnr (#) regnr * datum FORDON # regnr * färg * märke * modell * datum modell Verksamhetsbeskrivning: En person kan vara registrerad ägare till flera fordon. Ett fordon kan, om vi betraktar tiden som ett tidsintervall, ägas av flera personer. När ett ägarbyte inträffar så registreras detta av en tjänsteman på Trafikverket. 29

30 Exempel på Top Down PERSON # persnr * fnamn * enamn o mobil ÄGARBYTE # id (#) persnr (#) regnr * datum FORDON # regnr * färg * märke * modell Vi identifierar verksamhetsobjekten Person och Fordon. Vidare finner vi att relationen Person - Fordon är av typen M:M. Detta innebär en ny tabell för att få bort M:M relationen. PK bildar FK i gaffelns riktning: Person -> Ägarbyte, Fordon -> Ägarbyte. PK -> FK. 30

31 Exempel på funktionella beroenden datum id persnr fnamn enamn mobil regnr färg märke modell Tre determinanter medför tre tabeller. 31

32 Action-orientedoriented Genom att läsa verksamhetsbeskrivningen ser att handlingen registrera ägarbyte utförs av en tjänsteman på Trafikverket. PERSON # persnr * fnamn * enamn o mobil ÄGARBYTE FORDON # id (#) persnr # regnr * färg (#) regnr * märke * datum * modell När vi skapar en ny instans av klassen ägarbyte, d.v.s. när vi gör en insert i tabellen Ägarbyte så innebär det att ett ägarbyte registreras. Detta ägarbyte innebär att ett visst fordon får en ny ägare. Det krävs alltså referenser (FK) till både ett fordon och en person samt en tidpunkt när bytet ägde rum. 32

33 The End 33