Relationsmodellen och syntetisk databasdesign

Transkript

1 Relationsmodellen och syntetisk databasdesign Den teoretiska grunden för relationsdatabaser Från konceptuellt schema till databas Relationsmodellen Bil Ägare En relationsdatabas är en databas som uppfattas av användaren som en samling tabeller - oberoende av hur datamängden fysiskt är lagrad. Relationsmodellen är grunden för relationsdatabaserna. 1

2 Relationsmodellens grundbegrepp Tabell/Relationsnamn Varje tabell identifieras av sitt namn Relationsschema (tabell-definition) En lista av attribut (kolumner) som specificerar vad relationen handlar om TABELLNAMN : String 1122 : String Eva Ålder: Integer 22 Lön: Integer Attribut (kolumn) En etikett som kan användas för att beskriva data i en tabell Olle Erik Stina Tuppel (rad) En lista, en n-tuppel, av värden som passar med relationsschemat Domän En mängd av värden som används för att ange tillåtna värden hos en kolumn Relation (tabell) En mängd av tupler Ett relationsschema Tabell/Relationsnamn Varje tabell identifieras av sitt namn Relationsschema (tabelldefinition) En lista av attribut (kolumner) som specificerar vad relationen handlar om TABELLNAMN : String. String Ålder: Integer Lön: Integer Graden för ett relationsschema är lika med antalet kolumner i schemat. I detta exempel är graden 4. Ett relationsschema kan skrivas linjärt på följande enkla sätt (där identifierande attribut vanligen är understruket): TABELLNAMN(,, Ålder, Lön) Attribut (kolumn) En etikett som kan användas för att beskriva data I en tabell Domän En mängd av värden som används för att ange tillåtna värden hos en kolumn 2

3 En relation : String 1122 : String Eva Ålder: Integer 22 Lön: Integer Kardinaliteten för en relation är lika med antalet tuppler i schemat. I detta exempel är kardinaliteten Olle Erik Stina Tuppel (rad) En lista, en n-tuppel, av värden som passar med relationsschemat Relation (tabell) En mängd av tupler Relationer och relationsscheman : String : String Ålder: Integer Lön: Integer 1122 Eva Olle Erik : String Stina : String Lisa Pia Nils Greta Ålder: Integer Lön: Integer Det kan finnas flera relationer som instansierar samma relationsschema. 3

4 Egenskaper hos relationer En relation är en mängd Varje rad (tuppel) är unik En mängd har inga dublett-element! Ordningen mellan raderna är oväsentlig Elementen i en mängd är oordnade! Men, fysiskt, då, raderna måste väl ändå ligga i någon slags ordning? Javisst, på en dators hårddisk kommer raderna förstås att ligga på olika ställen, eventuellt sorterade i sekvens. Användaren behöver dock inte känna till något om hur raderna ligger lagrade fysiskt för att kunna använda databasen! När man optimerar databaser måste man dock ta hänsyn till hur raderna är sorterade fysiskt. Egenskaper hos relationer En relation är en mängd Varje rad (tuppel) är unik En mängd har inga dublett-element! Relation Olle Lisa Olle Olle Lisa Ej relation! 4

5 Egenskaper hos relationer En relation är en mängd Ordningen mellan raderna är oväsentlig Elementen i en mängd är oordnade! Olle Lisa Samma relation Olle Lisa Egenskaper hos relationer En rad är en n-tuppel Ordningen mellan attributen är väsentlig! Vikt Olle En tabell! Olle. Lisa Lisa Vikt En annan tabell! Olika tabeller! 5

6 Nycklar Ettsättattvisa vad som utgör primärnyckelkolumn (kolumner om primärnyckeln är sammansatt) är att stryka under den! Olle. Lisa Vikt En nyckel är en mängd attribut (t ex ett) som unikt identifierar en rad. Mängden av alla sådana möjliga nycklar för en viss tabell kallas tabellens kandidatnycklar. Det nyckel som av databas-administratören valts att användas som identifierare av en rad kallas primärnyckel de övriga nycklarna kallas, efter valet av primärnyckel, för alternativnycklar. Övning - primärnyckel FILMVISNING Filmtitel Biograf Startid Pris Vilka attribut identifierar en rad unikt? Filmtitel Filmtitel, Biograf Filmtitel, Biogfraf, Starttid Filmtitel, Biograf, Startid, Pris 6

7 En möjlig lösning - primärnyckel FILMVISNING Filmtitel Biograf Startid Pris Filmtitel Filmtitel, Biograf Filmtitel, Biogfraf, Starttid Filmtitel, Biograf, Startid, Pris NULL-värde Regnr ABC123 DEF456 GHI789 Märke Volvo Saab Skoda Ägare Eva NULL NULL används för att beteckna ett okänt värde på ett visst attribut på en viss rad. NULL-värden anses problematiska eftersom de kan tolkas på olika sätt. Vad betyder NULL? Värde finns men är okänt, just nu. Det kanske registreras en ägare till bil GHI789 senare Värde är ej tillämpligt (på alla rader, jfr arvs-hierarkier ) Värde saknas 7

8 Primärnyckel Olle. Lisa Vikt Att välja en kolumn (eller flera kolumner) till primärnnyckel innebär att ingen del av dessa kolumner någonsin får vara NULL (primärnyckelns roll är ju att identifiera en rad och den måste alltså alltid finnas!). Alternativnycklar får däremot vara NULL (men måste inte vara det). Denna regel brukar kallas entity integrity. Vad är en främmande nyckel? Kolumen Ägare i tabellen BIL utgör främmande nyckel mot primärnyckeln i tabellen Olle Lisa BIL Regnr ABC123 DEF111 BEF222 TAX455 Ägare En främmande nyckel i en tabell är ett eller flera attribut som refererar till primärnyckeln i en ANNAN tabell (eller i vissa specialfall mot samma tabell) Alla kolumnvärden som förekommer i främmande nyckel-kolumnerna (kolumnen) måste motsvaras av värden i den tabell som den främmande nyckeln refererar till, eller också vara NULL. Denna regel brukar kallas referential integrity 8

9 Vad är en främmande nyckel? BIL Regnr Ägare Olle ABC DEF BEF Lisa TAX Brott mot referential integrity främmande nyckelvärdet refererar inte till något existerande primärnyckelvärde! Främmande nycklar - syntax KUND Pnr Rum Hotell HOTELL Hotellnamn Antal_stjärnor } RUM Rumsnr Hotellnamn } Främmande nycklar kan specificeras grafiskt, som ovan, via pilar. Pilen utgår från den (de) kolumn (-er) som utgör främmande nyckel och pekar på motsvarande primärnyckel-kolumner. Ett annat sätt är att skriva ut vilka främmande nyckel-kolumner som svarar mot vilka primärnyckel-kolumner. I fallet ovan har KUND en sammansatt främmande nyckel mot RUM och RUM har en främmande nyckel mot HOTELL: KUND.(Rum, Hotell) utgör FN mot RUM.(Rumsnr, Hotell) RUM.Hotellnamn utgör FN mot HOTELL.Hotellnamn 9

10 Surrogatnycklar BOENDE Från Till Olle Lisa Petia Vanliga användardefinierade nycklar kan vara bristfälliga på olika sätt: De förändras över tid. T ex kan verksamhetsreglerna ändras, det attribut som en gång var unikt kanske inte längre är det Olika användargrupper kan använda olika kolumner för att identifiera en och samma tabell Nycklar bestående av riktiga attribut kan bli mycket långa (i värsta fall alla kolumnerna i tabellen) En surrogatnyckel är en konstgjord identifierare, genererad av databashanteringssystemet som garanterar att den alltid är unik. Surrogatnycklar Surrogatnyckel Id Olle Lisa Från Till Användarna behöver inte vara medvetna om surrogatet Surrogatnycklar är vanligen inte synliga i användargränssnitt mot databasen. Fortfarande har man alltså behov av att kunna använda naturliga attribut (som, Från, Till, etc.) i sökningar mot databasen Analys av vilka naturliga kolumner som eventuellt identifierar en rad skall alltså alltid göras oberoende av om surrogatnyckel används eller ej Surrogatet används dock internt som en unik identifierare och även i främmande nyckel-referenser 10

11 Syntetisk databasdesign från konceptuellt schema till relationsdatabasschema: översättningsregler Klassiagram Relationsdatabasschema Klass Envärt attribut Flervärt attribut 0/1:1 association 0/1:M association M:M association Generalisering Regler Regler Tabell Kolumn Tabell + främmande nyckel Främmande nyckel/tabell Främmande nyckel/tabell Tabell + främmande nycklar Främmande nyckel/tabell Nyckel, främmande nyckel Domändef, triggers etc. Från klass till tabell : String 1..1 : String 1..1 Varje klass i klassdiagrammet översätts till en tabell i relationsdatabasschemat. Attributen i klassen ger upphov till kolumner och ibland till nya klasser. Klassens identifierande attribut blir en nyckel i tabellen. 11

12 Från envärt attribut till kolumn : String 1..1 : String 1..1 Varje envärt attribut i en klass ger upphov till en kolumn I motsvarande tabell. Från flervärt attribut till tabell : String 1..1 : String 1..1 Titel: String 1..* TITEL Varje flervärt attribut ger upphov till en extra tabell. Primärnyckeln i den nya tabellen är sammansatt av det flervärda attributet tillsammans med den gamla primärnyckelkolumnen. Den nya tabellen har en främmande nyckelkolumn som refererar till primärnyckeln i den första tabellen. Titel 12

13 Översättning av associationer Varje 1:1 eller 0:1 association mellan två klasser kan översättas som en främmande nyckel mellan de de två tabeller som svarar mot klasserna. Men om man har en en 0:1 association så så kan man väl råka ut utför NULL-värden? Jo, så såär ärdet och NULLvärden vill man ju juhelst undvika. Därför kan man ibland behöva introducera extra tabeller vid översättning av av associationer. Från 0:1 association till främmande nyckel-kolumn : String 1..1 : String äger BIL Regnr: String 1..1 Märke: String 1..1 BIL Regnr Märke Ägare 1122 ABC123 Volvo 2233 Eva DEF456 Saab Eva 3344 Nisse GHI789 Skoda NULL En association med max-värde 1 i BÅDA rollerna ger upphov till en främmande nyckel i endera tabellen! Vi får välja! Vet vi att fler :er saknar BIL än BIL:ar som saknar ägare så väljer vi lösningen ovan! Men NULL-problem blir det hursomhelst eftersom båda rollerna har 0 i minimivärde! 13

14 Från 0:1 association till extra tabell : String 1..1 : String äger BIL Regnr: String 1..1 Märke: String 1..1 BILÄGANDE BIL Ägare Bil Regnr 1122 ABC123 ABC Eva Eva DEF456 DEF Nisse GHI789 I denna översättning introducerar vi en extra tabell för att hantera associationen äger. På detta sätt undviker man NULL-värden. Märke Volvo Saab Skoda Från 0/1:M association till främmande nyckel-kolumn : String 1..1 : String * äger BIL Regnr: String 1..1 Märke: String 1..1 BIL Notera att M ( många ) också ofta symboliseras av * eller n Regnr Märke Ägare En 0:M eller 1:M (där alltså EN av rollerna har M som max-värde) association översätts till en främmande nyckel. Den nya kolumnen placeras på många-sidan, d.v.s. i den tabell som svarar mot den klass som ligger på många-sidan av associationen. Just här, eftersom båda rollerna dessutom har 0 i minimivärde så gäller samma NULL-problematik som i tidigare bild. 14

15 Från M:M association till extra tabell : String 1..1 : String * 0..* äger BIL Regnr: String 1..1 Märke: String 1..1 BILÄGANDE Ägare Bil En M:M association måste alltid översättas till en extra tabell. Denna tabell kommer att innehålla främmande nycklar till primärnycklarna i de tabeller som svarar mot de associerade klasserna. BIL Regnr Märke Översättning av generalisering Avd.: String 1..1 KONSULT ISA ISA : String 1..1 : String 1..1 Projekt: String 1..1 KONSULT Eva Personn 1122 Avd Sko 2233 Projekt Proj1 Vid generalisering så blir var och en av subklasserna en egen tabell med en primärnyckel som kommer från superklassen. Denna primärnyckel blir också en främmande nyckel mot primärnyckeln i den tabell som svarar mot superklassen. 15

16 Övning : String 1..1 : String 1..1 : String 1..1 : String 1..1 ISA Anstnr: String 1..1 Översätt de två klassdiagrammen ovan till två olika relationsdatabasscheman! gift_med Anstnr: String 1..1 Övning forts. : String 1..1 : String 1..1 ISA Anstnr: String 1..1 Anstnr 16

17 En svårare övning : String 1..1 : String gift_med Anstnr: String 1..1 Anstnr En svårare övning : String 1..1 : String 1..1 ISA Anstnr: String 1..1 : String 1..1 : String 1..1 Informationsförlust! gift_med Relationsmodellen är semantiskt fattig! Anstnr: String 1..1 Anstnr 17

18 Översättning av sammansatta identifierare KURS KURSTILLFÄLLE * Kurskod: Integer 1..1 Från: Date 1..1 av Kursnamn: String Till: Date Ansvarig_lärare: String 1..1 Översätt klasschemat till ett relationsdatabasschema! Men inget av attributen i klassen KURSTILLFÄLLE är ju unikt? Inte ens om vi kombinerar ihop alla attributen har vi en unik identifierare (t ex kan en lärare vara ansvarig för flera kurstillfällen som går samtidigt)? Det beror på att en del av ett KURSTILLFÄLLE.s identifierare helt enkelt utgörs av dess association mot KURS! Översättning av sammansatta identifierare KURS Kurskod: Integer 1..1 Kursnamn: String av 0..* KURSTILLFÄLLE Från: Date 1..1 Till: Date 1..1 Ansvarig_lärare: String 1..1 KURS KURSTILLFÄLLE Kurskod Kursnamn Kurs Från Till Ansvarig Den sammansatta primärnyckeln i tabellen KURSTILLFÄLLE utgörs av kolumnerna Kurs, Från, och Till. Två KURSTILLFÄLLE:n av samma KURS kan alltså inte ges samtidigt! Kolumnen Kurs utgör vidare främmande nyckel mot tabellen KURS. 18

19 Övning översättning av sammansatta identifierare Klass Klass KUND KUND identifieras identifieras av av sitt sitt Pnr. Pnr. Klass Klass RUM RUM identifieras identifieras av av sitt sitt Rumsnamn Rumsnamn och och sin sin association association mot mot HOTEL. HOTEL. Klass Klass HOTELL HOTELL identifieras identifieras av av sitt sitt Hotelnamn. Hotelnamn. KUND Pnr: Integer 1..1 : String 1..1 RUM 1..1 Rumsnr: Integer 0..* * 1..1 HOTELL Hotelnamn: String 1..1 Antal_stjärnor: Int 1..1 Översätt klasschemat ovan till ett relationsdatabasschema! Ange tabellnamn, namn på alla kolumner, primärnycklar och främmande nycklar! Lösning översättning av sammansatta identifierare KUND Pnr: Integer 1..1 : String 1..1 RUM 1..1 Rumsnr: Integer 0..* * 1..1 HOTELL Hotellnamn: String 1..1 Antal_stjärnor: Int 1..1 KUND Pnr Rum Hotell } RUM Rumsnr } HOTELL Hotellnamn Hotellnamn Antal_stjärnor Notera att främmande nyckel-kolumnerna inte behöver heta likadant som de primärnycklar de svarar mot! (De kan dock göra det som vi sett förut!) 19

20 Från klasschema till relationsdatabas Regler Vart tog tog alla alla regler som fanns i i det det konceptuella schemat vägen när närvi vi översatte till till databas? Datatyp! Datatyp! Min-värde! Min-värde! Översättning av regler fortsättning Men Men vissa regler har harväl redan implementerats när närvi vi översatte från från konceptuellt schema till till databas? Javisst, t ex har funktionella beroenden mellan attribut i en klass gett upphov till val av primärnycklar när klassen översattes till en tabell. Attribut med max-värde = 1 har gett upphov till kolumner. Flervärda attribut har gett upphov till tabeller. 20

21 Översättning av regler fortsättning Vart tog tog alla alla andra regler vägen? Domänbeskrivningar Referensregler (främmande nyckel-regler) Andra domän-regler, t ex triggers (triggers går vi igenom på SQL-föreläsningen) Kontroll av data ska ske så tidigt som möjligt! Systemet ska inte kontrollera att informationen inte är felaktig, det ska så långt det är möjligt undanröja möjligheten att felaktig information matas in eller lagras! Domän Ett värdeförråd ur vilket ett eller flera attribut får sina värden Regler som begränsar tillåtna värden Två attribut är jämförbara endast om de får sina värden ur samma domän Alla värden är atomära 21

22 Domän Varför är det bra att använda domän-konceptet för kontroll av datavärden? Det flyttar kontrollen från applikationsnivå till systemnivå (DBMS) Varje domän behöver deklareras endast en gång Flexibelt,enklare att ändra, enklare dokumentation Domän-regler Domänregler Exempel Datatyp Längd Format Defaultvärde Max/Min-.värden (kardinalitetsregler) Heltal, flyttal, textsträng, tecken 5 signifikanta siffror, 30 tkn, ååmmdd, nnnnnnnnnnnn John Doe Minst en, högst fyra, 22

23 Domän-regler och främmande nyckel regler via DDL Datatyp! Datatyp! Maxvärde! Maxvärde! Min-värde! Min-värde! Tabellerna ovan, inklusive datatyper och främmande nycklar (och andra regler) kan definieras via SQL DDL SQL har en DDL-del (lite mer okänd än DML-delen) DDL Data Definition Language, DML Data Manipulation Language Via DDL definierar vi tabeller, regler etc. Via DML kan vi sen ställa frågor mot de tabeller vi skapat DDL Datatyp! Datatyp! FÖRETAG Företagsnamn: String 1..1 Antal_anställda: Int 1..1 FÖRETAG Företagsnamn Antal_anställda Min-värde! Min-värde! CREATE TABLE FÖRETAG (Företagsnamn Varchar(25) NOT NULL, Antal_anställda Integer NOT NULL, Primary key (Företagsnamn)) 23

24 DDL Främmande nyckel-regler FÖRETAG Anstnr Mitt_företag Företagsnamn Antal_anställda Maria Paul Petia BULT AB BULT AB SKRUV AB BULT AB SKRUV AB 2 1 CREATE TABLE (Anstnr String NOT NULL, String NOT NULL, Mitt_företag Varchar(25) NOT NULL, Primary key(anstnr), Foreign key(mitt_företag) REFERENCES FÖRETAG(Företagsnamn) ON DELETE restrict ON UPDATE cascade) DDL Främmande nyckel-regler FÖRETAG Anstnr Mitt_företag Företagsnamn Antal_anställda Maria Paul Petia BULT AB BULT AB SKRUV AB BULT AB SKRUV AB 2 1 CREATE TABLE (Anstnr String NOT NULL, String NOT NULL, Mitt_företag Varchar(25) NOT NULL, Primary key(anstnr), Foreign key(mitt_företag) REFERENCES FÖRETAG(Företagsnamn) ON DELETE cascade ON UPDATE cascade) Anstnr Maria Paul Mitt_företag BULT AB BULT AB FÖRETAG Företagsnamn BULT AB Antal_anställda 2 24

25 DDL Främmande nyckel-regler FÖRETAG Anstnr Mitt_företag Företagsnamn Antal_anställda Maria BULT AB BULT AB Paul Petia BULT AB SKRUV AB SKRUV AB 1 CREATE TABLE (Anstnr String NOT NULL, String NOT NULL, Mitt_företag Varchar(25) NOT NULL, Primary key(anstnr), Foreign key(mitt_företag) REFERENCES FÖRETAG(Företagsnamn) ON DELETE cascade ON UPDATE cascade) Anstnr Maria Paul Petia Mitt_företag BULTIA AB BULTIA AB SKRUV AB FÖRETAG Företagsnamn BULTIA AB SKRUV AB Antal_anställda