Databaser Relasjonsmodellen 1 Læreboka: Kap. 2 Relasjonsmodellen Faglærere: Tore Mallaug, Kjell Toft Hansen
Tema for dagen Relasjonsmodellen Hvorfor relasjoner? Fra ER diagram til relasjoner 22.09.2008 Kjell Toft Hansen 2
Relasjonsmodellen Vi betrakter en relasjon som en to dimensjonal tabell attributt (kolonne) tuppel (rad) 22.09.2008 Kjell Toft Hansen 3
Relasjonsmodellen Rekkefølgen på tupler (rader) er vilkårlig Antall tupler : kardinalitet Antall attributter : grad Hver rute (celle) i tabellen må inneholde atomiske verdier En relasjonsdatabase er en samling med relasjoner 22.09.2008 Kjell Toft Hansen 4
Relasjonsmodellen primærnøkkel : sikrer at alle radene i tabellen er forskjellige 22.09.2008 Kjell Toft Hansen 5
Relasjonsmodellen nøkler Primærnøkkelen sikrer entitetsintegritetsregelen: Underforstått: enhver tabell må ha én primærnøkkel Primærnøkkelen sikrer at ingen rader er like (entydighet) Ingen del av primærnøkkelen kan ha NULL verdi Kandidatnøkkel Ett eller en kombinasjon av attributter hvis verdier det finnes bare én av i tabellen Vi velger relasjonens primærnøkkel blant kandidatnøklene 22.09.2008 Kjell Toft Hansen 6
Relasjonsmodellen nøkler Alternative nøkkel Den kandidatnøkkelen som ikke blir valgt til primærnøkkel Sammensatt nøkkel En primærnøkkel/kandidatnøkkel som består av flere attributt og hvor det er kombinasjonen av verdier som er entydig identifiserer en rad i tabellen Surrogatnøkkel En systemgenerert attributtverdi (teller) som alltid vil inneholde entydige verdier 22.09.2008 Kjell Toft Hansen 7
Relasjonsmodellen nøkler Fremmednøkkelen sikrer referanseintegritetsregelen. For å knytte to tabeller sammen må de to tabellene ha et fellesattributt: primærnøkkelen i mor tabellen blir fremmednøkkel i barne tabellen Referanseintegritetsregelen: En verdi må være kjent fra mor tabellen (primærnøkkel) for at den skal kunne registreres i barne tabellen (fremmednøkkel) En fremmednøkkelverdi (barne tabellen) kan være NULL 22.09.2008 Kjell Toft Hansen 8
Relasjonsmodellen kandidatnøkkel primærnøkkel fremmednøkkel primærnøkkel 22.09.2008 Kjell Toft Hansen 9
Hvorfor relasjoner? Det er en svært enkel modell Det utgjør den abstrakte modellen bak SQL (Structured Query Language) Den virker ofte sammenfallende med hvordan vi tenker Relasjonsmodellen er settbasert (relasjons operatorene gir tabeller med rader som resultat) Vi bruker ER modellen til å designe databaser og konverterer deretter ER modellen til et relasjonsskjema (tabeller på relasjonell form) 22.09.2008 Kjell Toft Hansen 10
Hvorfor relasjoner? Det finnes også andre databasemodeller Objekt relasjon Objekt basert Hierarkisk Nettverk 22.09.2008 Kjell Toft Hansen 11
Entitetstyper blir tabeller med samme sett attributter Sammenhengstypenes multiplisitet i ER modellen vil avgjøre hvilken primærnøkkel som blir fremmednøkkel og dermed knytter tabellene sammen Hvis sammenhengstypen i ER modellen har attributter, bli de attributter i en tabell i relasjonsmodellen 22.09.2008 Kjell Toft Hansen 12
Fra en til mange til relasjonsskjema (relasjonell form): FORLAG(forlag_id, forlag_navn, adresse, telefon) BOK(bok_id, tittel, utgitt_aar, forlag_id*) Det er alltid primærnøkkelen på 1 siden i en en til mange sammenhengstype som blir fremmednøkkel på mange siden 22.09.2008 Kjell Toft Hansen 13
Forlag fremmednøkkel primærnøkkel primærnøkkel Bok 22.09.2008 Kjell Toft Hansen 14
Fra mange til mange til relasjonsskjema (relasjonell form): BOK(bok_id, tittel, utgitt_aar) FORFATTER(forfatter_id, fornavn, etternavn, fode_aar, dod_aar, nasjonalitet) BOK_FORFATTER(bok_id*, forfatter_id*) Når vi oversetter en mange til mange sammenhengstype til relasjonsmodellen, må vi inn med en koblingstabell 22.09.2008 Kjell Toft Hansen 15
Forfatter Bok Bok_forfatter * * primærnøkkel primærnøkkel Sammensatt primærnøkkel 22.09.2008 Kjell Toft Hansen 16
Hvordan oversetter vi en sammenhengstype med attributt til relasjonsskjema (relasjonell form)? STUDENT(studid, etternavn, fornavn, adresse) FAG(fagkode, fagnavn, eksamens_dato) PÅMELDING(studid*, fagkode*, p_dato) 22.09.2008 Kjell Toft Hansen 17
1..1 Kunde -kundenr {PK} -etternavn -fornavn -adresse -har_referanse 0..* Rekursiv sammenhengstype til relasjonsskjema (relasjonell form): KUNDE(kundenr, k_referansenr*, etternavn, fornavn, adresse) 22.09.2008 Kjell Toft Hansen 18
Flerverdiattributt til relasjonsskjema (relasjonell form): KUNDE(kundenr, etternavn, fornavn, adresse) TELEFON(tlfnr, kundenr*) 22.09.2008 Kjell Toft Hansen 19
Flervegs sammenhengstyper til relasjonsskjema (relasjonell form): ANSATT(ansattnr, etternavn, fornavn, adresse, avdnr*) AVDELING(avdnr, avdnavn, l_ansattnr*) 22.09.2008 Kjell Toft Hansen 20
Oversettelse av en svak entitetstype (identitetsavehengighet) til relasjonsskjema (relasjonell form): HØGSKOLE(h_navn, h_adresse, h_telefon) AVDELING(a_navn, h_navn*, a_adresse, a_telefon, ant_ansatte) En tabell basert på en svak entitetstype må inkludere attributter fra hele primærnøkkelen inklusive de attributtene som tilhører andre entitetstyper i tillegg til sine egne ikke nøkkel attributt 22.09.2008 Kjell Toft Hansen 21
Fra subtyping til relasjonsskjema (relasjonell form): SKIP(navn, lengde, vekt) TANKSKIP(navn*, kapasitet, type) PASSASJERSKIP(navn*, ant_passasjerer) Legg merke til at Skip har en rad i alle tabellene: Finn alle båter over 80 meter!! 22.09.2008 Kjell Toft Hansen 22
eksistensavhengighet Fra eksistensavhengighet i ER modellen til fysisk realisering i relasjonsmodellen: ANSATT(ansattnr, etternavn, fornavn, adresse, avdnr*) AVDELING(avdnr, avdnavn) 22.09.2008 Kjell Toft Hansen 23
Fysisk realisering med SQL med entitets og referanseintegritet: CREATE TABLE avdeling ( avdnr INT NOT NULL, avdnavn VARCHAR(30) NOT NULL, PRIMARY KEY(avdnr) )TYPE=INNODB; Entitetsintegritet - primærnøkkel CREATE TABLE ansatt ( ansattnr INT NOT NULL, etternavn VARCHAR(30) NOT NULL, fornavn VARCHAR(30) NOT NULL, adresse VARCHAR(30), avdnr INT NOT NULL )TYPE=INNODB; eksistensavhengighet Referanseintegritet fremmednøkkel ALTER TABLE ansatt ADD FOREIGN KEY(avdnr) REFERENCES avdeling(avdnr) ON DELETE RESTRICT; 22.09.2008 Kjell Toft Hansen 24
Referanseintegritet og bruk av CASCADE: ALTER TABLE ansatt ADD FOREIGN KEY(avdnr) REFERENCES avdeling(avdnr) ON DELETE RESTRICT; Du kan ikke slette en avdeling hvis det er ansatte som jobber i denne avdelingen (hvis et avdnr fra tabellen Avdeling finnes i avdnr i tabellen Ansatt) ALTER TABLE ansatt ADD FOREIGN KEY(avdnr) REFERENCES avdeling(avdnr) ON DELETE CASCADE; Du kan slette en avdeling også hvis det er ansatte som jobber i denne avdelingen med det resultatet at også alle ansatte som jobber i avdelingen vil bli slettet fra tabellen Ansatt dette er ikke ønskelig i dette tilfelle. Hva med ON UPDATE CASCADE? 22.09.2008 Kjell Toft Hansen 25