Datamodellering

Innehåll
Relationsdatabas
Databasdesign
Objekt
Relationer
Normalisering
Vad är referensintegritet?

Relationsdatabas
Det är en databas i vilken olika information är sammankopplade. Man hämtar ny information genom den informationen man redan har.

Till exempel: Om du söker relations databasen för efternamnen, du kan ta fram den persons lön ut den relativa konto databasen.

Med andra ord: En relationsdatabas är en databas som uppfattas av användaren som en samling tabeller - oberoende av hur data mängden fysiskt är lagrad

Databasdesign
Görs för att få en bättre överblick över vilka data som hör ihop. Placera sammanhörande data i samma tabell. Se till att alla data som hör ihop ingår i tabellen samt att inga data som borde höra dit hamnar i en annan tabell.

Att inte lägga data i en enda stor tabell utan i flera olika tabeller med relationer som länkar samman tabellerna reducerar redundansen i databasen. (man behöver t ex inte skriva samma adress flera gånger)

Detta är viktigt för det fortsatta uppbyggandet av databasen då man kommer att se ett logiskt samband mellan de olika delarna. Det blir lättare att uppdatera och ändra då man bara behöver ändra på ETT ställe.

Objekt
Föra att göra en datamodell måste man börja med att hitta objekten , de viktigaste hörnpelarna som illustrerar tabeller. Kring objekten kan sedan flertalet begrepp och enskilda dataelement logiskt grupperas. Det är meningslöst att börja rita relationer fritt, utan att anknyta dessa till objekt. Objekt är stommen i en data modell.

Relationer, som illustreras med linjer mellan objekt, anger logiska samband och kopplar i ihop objekt. Relationen är "limmet" som gör det möjligt för en modern databashanterare att vid ett rapporttillfälle snabbt plocka ihop och presentera information från flera objekt och relationer (tabeller).

Det finns 3 saker ett objekt måste uppfylla för att klassificeras som objekt,

• Ha betydelse för just den verksamhet som avgränsats som intressant.
• Representera en självständig företeelse.
• Kunna identifieras med en "unik nyckel".

Det finns olika typer av objekt som man bör skilja på och som används för olika ändamål. Självständiga objekt är vanligast, ett självständigt objekt klarar sig bra själv, är inte beroende av något annat objekt för sin existens. Praktiskt betyder detta att ett självständigt objekt har en helt egen lagringsnyckel. Självständiga objekt har i regel ett till många relationer eller många till många relationer till omgivande objekt.

KUND, TRANSAKTION och PRODUKT är typiska exempel på självständiga "objekt". Dessa kan identifieras med en primär nyckel såsom KUNDNR. En primär nyckel består av ett eller flera fält och ger en unik identifikation av varje post i en tabell.

En sekundärnyckel består av ett eller flera tabellfält som refererar till primär fältet eller fältet i en annan tabell.

Relationer
Relationer är logiska samband som kopplar ihop objekten. Det är limmet som gör det möjligt att presentera information från flera objekt och relationer (tabeller). Det finns olika typer av relationer:

En-till-många.
Är en relation som t.ex uppstår när man har en leverantör (med unik nyckel, t.ex leverantörsnummer) som levererar flera produkter. En leverantör (1) kan leverera många produkter (1-3) men varje produkt har bara en leverantör.

Nyckeln kopieras, dvs produkten "hänger ihop" med leverantören. Detta möjliggör att man snabbt kan få information från databasen och slipper att dubbellagra information.

Många-till-många.
Är en relation där objekten knyts samman via ett relationsobjekt.

Relationsobjekt kan innehålla egna egenskaper. Här är namngivning viktigt. (Är svårt, kan "sänka" systemet.) En sådan relation kan du bara skapa genom att definiera en tredje tabell. I ovanstående exempel kan mna få reda på vilka produkter som en viss order innehåller.

En-till-en.
Är en relation när man behöver kompletterande information endast en gång. Man lägger då den kompletterande informationen i en egen tabell. Relationen mellan produkt och produktbeskrivningen är exempel på en-till-en relation.

Den här relationen är inte vanlig eftersom den normalt placeras i samma tabell. Man kan använda en en-till-en relation om man vill dela en tabell med många fält (om man har för mycket data i en tabell) eller vill avgränsa tabellen. I ovanstående ligger produktbeskrivningen i en separat tabell.

Normalisering
För att få en logisk och rationell struktur på datamodeller och tabeller kan man använda Tedd Codds s.k. Normaliseringsregler. Detta regelverk hjälper oss att placera varje data-element(kolumn) på rätt ställe, i rätt tabell. Om man har gjort detta på ett rätt sätt så kan eventuella problem med rendudans och konsistens förebyggas.

 Regel 1: Det måste finnas en unik nyckel

Dvs man måste vara helt säker på att hitta rätt rad. Det kan finnas flera olika kunder med samma namn
fast i olika brancher. Kundnummer är däremot unika.

 Regel 2: Man måste se till att varje egenskap i en tabell beror på hela nyckeln.

(installationer)

Med ovan tabell får vi en mängd onödiga dubbellagringar. Istället gör vi som nedan.

(produkt )

(maskin)

(installationer)

För ovan gäller följande: Om vi delar upp tabellen i sina logiska delar får vi 3 tabeller (äpplen är äpplen-päron är päron)

Regel 3: En egenskap får bara ha ett beroende till nyckeln.

(kund)

Även här blir följden en dubbellagring. Ett distriktnamn ändras ju inte när det tillkommer ytterligare en kund i distriktet. Distriktnamn har ett inbördes förhållande till distrikt.

Vi delar upp tabellen i sina logiska delar och får då två tabeller.

(kund)

(distrikt)

I det här fallet blir DISTRIKT en främmande nyckel i tabellen KUND.

Vad är referensintegritet?
Om du har en tabell, till exempel över anställda,där det står den anställdes nummer, namn, och vilken avdelning han eller hon jobbar på:

ANSTÄLLD

Och så antar vi att det finns en annan tabellöver företagets olika avdelningar,där det står varje avdelnings nummer, namn och den våning avdelningen finns på:

AVDELNING

Nu kan AVD i tabellen ANSTÄLLD vara ett referensattribut,ibland kallad främmande nyckel, till tabellen AVDELNING. Dvs, när jag ser att Klas jobbar på avdelning 4, så kan jag gå till tabellen AVDELNING och se att avdelning 4 heter "Städning", och ligger på andra våningen.

Men vad händer med Lotta, som jobbar på avdelning 5? Den avdelningen finns ju inte!

Referensintegritet betyder att varje värde som används i ett referensattribut alltid måste finnas i den andra tabellen. Dvs, om det står att Lotta jobbar på avdelning 5, så ska det också finnas en avdelning 5.

Många databashanterare hjälper till att kolla detta, om man anger att AVD är ett referensattribut till tabellen AVDELNING.

Slut