Relationsmodellen och syntetisk databasdesign

Relevanta dokument
Informationssystem och Databasteknik

Analytisk relationsdatabasdesign

IT i organisationer och databasteknik

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

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

Relationsdatabasdesign

Karlstads Universitet, Datavetenskap 1

Tentamen. Databasmetodik Lördag 27 september 2014 kl

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

Konceptuella datamodeller

Informationssystem och Databasteknik

Databasens består av: Tabell Kolumner fält Rader poster (varje post är unik)

NORMALISERING. Mahmud Al Hakim

ÖVNING 10 2NF Hästnamn, KursId, StartDatum, SlutDatum KursId NY! 3NF Hästnamn, Art, NY! NY! NY! NY! KursId, StartDatum, SlutDatum KursId NY!

TER3. Försättsblad till skriftlig tentamen vid Linköpings universitet G28 TEN1 Webprogrammering och databaser Tentamen IDA 1 (7)

SQLs delar. Idag. Att utplåna en databas. Skapa en databas

Grunderna för relationsmodellen!

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

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

Tentamen Databasmetodik DB:DSK/FK/DVK/ATD/SP/EIT mfl. äldre kurstillfällen 8 augusti 2013 kl. 9-13

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

Design och underhåll av databaser

Idag. Hur skapar vi och underhåller en databas? DD1370 (Föreläsning 4) Databasteknik och informationssystem 7,5 hp Hösten / 20

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

Databasdesign. E-R-modellen

Tentamen Databasmetodik DB:DSK/FK/DVK/ATD/SP/EIT mfl. äldre kurstillfällen Lördag 8 juni kl

DDL Kommandon CREATE/DROP Database CREATE /ALTER/DROP Table ALTER/ADD/DROP Column CREATE /ALTER/DROP Index

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

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

Concepts learned this far. ER till relationer. ER till relationer. ER till relationer. TDDD12 Database Technology

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

02/12/14. Databasteknik och informationssystem DD1370. Behövs Föreläsning 8? Dagens föreläsning. Om Lab 1. De 11 Stegen (Kokbok)

25/11/14. Databasteknik och informationssystem DD1370. Påminnelse inför Lab 1 redovisningen. Repetition: ER modellering (gammalt + nytt)

Exempel-tentamen 1. + Lösningsförslag. Inga hjälpmedel är tillåtna.

För att XCOPY i SQL Server Express ska fungera måste data och logg ligga i samma mapp, vilket naturligtvis inte är så bra.

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

Tentamen för DD1370 Databasteknik och informationssystem

Informationssystem och databasteknik

Databaser och Datamodellering Foreläsning IV

Tentamen för DD1370 Databasteknik och informationssystem

Relationsdatabasdesign, 2I-4067

Exempel-Tentamen III

Tentamen för DD1370 Databasteknik och informationssystem

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

Viktigt! Glöm inte att skriva Tentamenskod på alla blad du lämnar in.

IT i organisationer och databasteknik

Databaser - Design och programmering. Kursöversikt. Exempel: telefonbok. Varför databaser?

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

Databaser. Vad du ska lära dig: Ordlista

Inga hjälpmedel är tillåtna

Tentamen DATABASTEKNIK - 1DL116

Exempel tentamen. Skriv bara på en sida av pappret Skriv namn på varje papper Skriv läsligt, annars rättas inte tentamen Alla hjälpmedel är tillåtna

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

! Teori och praktik. ! Ändringar från förra året. ! Examination (tenta, projekt) LiU. ! Varför ni? ! Varför överhuvudtaget? LiU

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

Tentamen i Databasteknik

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

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

Databaser - Design och programmering

Tentamen för DD1370 Databasteknik och informationssystem

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

Föreläsning 2: Översikt över ett databassystem

Tentamen plus lösningsförslag

Databaskunskap 7,5 högskolepoäng Provmoment: Ladokkod: Tentamen ges för:

(Data)Modellering. nikos dimitrakas rum 2423

732G16: Databaser - Design och programmering

Reducering till relationsscheman

Tentamen för DD1370 Databasteknik och informationssystem

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

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

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

Logisk databasdesign

08/12/14. Databasteknik och informationssystem DD1370. Behövs Föreläsning 8? Kursens (återstående) mål Dagens föreläsning

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

Prova på-laboration i SQL

Universitetet: ER-diagram

D1. Create Domain TEXT30 char(30) Default INGET VÄRDE! ;

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

1.Lär känna MS SQL Observera. Tips. Förberedelse

729G28 Webprogrammering och databaser. Föreläsning 1: Diverse praktiskt om kursen Webprogrammering Databaser, terminologi

Starta MySQL Query Browser

Skriftlig tentamen i kurserna TDDD12 och TDDB48 Databasteknik kl

Relationsmodellen. Relations modellen är idag den mest änvända datamodellen för kommersiella

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

Lösningsförslag, tentamen i Databaser

Informationssystem och Databasteknik, 2I-1100 HT2001. Relationsalgebra. Relationsalgebran är sluten: R 1 op R 2 R 3.

Föreläsning 6: Normalisering & funktionella beroenden

Lär känna MS SQL 2008 / Övning. Observera. Tips. Förberedelse

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

Webbprogrammering, grundkurs 725G54

Lösningsförslag Tentamen, 25 april 03

Konceptuell modellering

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

Föreläsning 5: Relationsmodellen

Tentamen. TDDB38 - Databasteknik

Uppstart Inloggning SSMS Skapa Databas Skapa Tabell Skapa Diagram, Fk, RI Hantering av Index, Pk, Fk, Ix Constraints Beräknande fält Några funktioner

Modul DB1-1 Databasmodellering

Databaser design och programmering. Design processen ER- modellering

Transkript:

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

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 19000 Attribut (kolumn) En etikett som kan användas för att beskriva data i en tabell. 2233 3344 4455 5566 Olle Erik Stina 33 44 55 66 Tuppel (rad) En lista, en n-tuppel, av värden som passar med relationsschemat 29000 39000 49000 59000 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

En relation : String 1122 : String Eva Ålder: Integer 22 Lön: Integer 19000 Kardinaliteten för en relation är lika med antalet tuppler i schemat. I detta exempel är kardinaliteten 5. 2233 3344 4455 5566 Olle Erik Stina 33 44 55 66 Tuppel (rad) En lista, en n-tuppel, av värden som passar med relationsschemat 29000 39000 49000 59000 Relation (tabell) En mängd av tupler Relationer och relationsscheman : String : String Ålder: Integer Lön: Integer 1122 Eva 22 19000 2233 Olle 33 29000 3344 Erik 44 39000 4455 5566 : String 1122 2233 6677 4545 7788 Stina : String Lisa Pia Nils Greta 55 66 Ålder: Integer 22 33 77 44 55 49000 59000 Lön: Integer 19000 29000 69000 29000 59000 Det kan finnas flera relationer som instansierar samma relationsschema. 3

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! 111111-1111 111111-2222 999999-9999 Relation Olle Lisa 111111-1111 Olle 111111-1111 Olle 999999-9999 Lisa Ej relation! 4

Egenskaper hos relationer En relation är en mängd Ordningen mellan raderna är oväsentlig Elementen i en mängd är oordnade! 111111-1111 111111-2222 999999-9999 Olle 111111-2222 111111-1111 Lisa 999999-9999 Samma relation Olle Lisa Egenskaper hos relationer En rad är en n-tuppel Ordningen mellan attributen är väsentlig! Vikt 111111-1111 Olle 81 111111-2222 59.. En tabell! 999999-9999 Olle. Lisa Lisa 111111-1111 222222-2222. 999999-9999 63 Vikt 81 59 63 En annan tabell! Olika tabeller! 5

Nycklar Ettsättattvisa vad som utgör primärnyckelkolumn (kolumner om primärnyckeln är sammansatt) är att stryka under den! 111111-1111 111111-2222. 999999-9999 Olle. Lisa Vikt 81 59 63 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

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

Primärnyckel 111111-1111 111111-2222. 999999-9999 Olle. Lisa Vikt 81 59 63 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 111111-1111 111111-2222 222222-2222 999999-8888 Olle Lisa BIL Regnr ABC123 DEF111 BEF222 TAX455 Ägare 111111-1111 222222-2222 999999-8888 999999-8888 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

Vad är en främmande nyckel? BIL Regnr Ägare 111111-1111 Olle ABC123 111111-1111 111111-2222 DEF111 222222-2222 222222-2222 BEF222 777777-1111 999999-8888 Lisa TAX455 999999-8888 Brott mot referential integrity främmande nyckelvärdet 777777-1111 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

Surrogatnycklar BOENDE Från Till Olle 2000-08-28 2000-09-01 Lisa 1999-09-01 2006-01-02 Petia 2004-05-06 2004-05-07 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 111111-1111 111111-2222 999999-8888 Olle Lisa Från 2000-08-28 1999-09-01 2004-05-06 Till 2000-09-01 2006-01-02 2004-05-07 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

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

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

Ö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 1..1 0..1 0..1 ä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

Från 0:1 association till extra tabell : String 1..1 : String 1..1 0..1 0..1 äger BIL Regnr: String 1..1 Märke: String 1..1 BILÄGANDE BIL Ägare Bil Regnr 1122 ABC123 ABC123 2233 Eva Eva DEF456 DEF456 3344 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 1..1 0..1 0..* ä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

Från M:M association till extra tabell : String 1..1 : String 1..1 0..* 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 1122 2233 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

Ö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! 1..1 1..1 gift_med Anstnr: String 1..1 Övning forts. : String 1..1 : String 1..1 ISA Anstnr: String 1..1 Anstnr 16

En svårare övning : String 1..1 : String 1..1 1..1 1..1 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! 1..1 1..1 gift_med Relationsmodellen är semantiskt fattig! Anstnr: String 1..1 Anstnr 17

Översättning av sammansatta identifierare KURS KURSTILLFÄLLE 1..1 0..* Kurskod: Integer 1..1 Från: Date 1..1 av Kursnamn: String Till: Date 1..1 1..1 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 1..1 1..1 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

Ö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 1..* 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 1..* 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

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

Ö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

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

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

DDL Främmande nyckel-regler FÖRETAG Anstnr Mitt_företag Företagsnamn Antal_anställda 11111 22222 33333 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 11111 22222 33333 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 11111 22222 Maria Paul Mitt_företag BULT AB BULT AB FÖRETAG Företagsnamn BULT AB Antal_anställda 2 24

DDL Främmande nyckel-regler FÖRETAG Anstnr Mitt_företag Företagsnamn Antal_anställda 11111 Maria BULT AB BULT AB 2 22222 33333 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 11111 22222 33333 Maria Paul Petia Mitt_företag BULTIA AB BULTIA AB SKRUV AB FÖRETAG Företagsnamn BULTIA AB SKRUV AB Antal_anställda 2 1 25