Databasedesign HVA? HVORDAN? E/R diagram. Begrepsmessig databasedesign. Logisk databasedesign. Fysisk databasedesign

Transkript

1 Databasedesign HVA? Begrepsmessig databasedesign E/R diagram Logisk databasedesign HVORDAN? Fysisk databasedesign Databaser Leksjon 7: Logisk databasedesign - 1

2 Logisk databasedesign Fra E/R til tabellstruktur: Hvilke tabeller får vi? Hvilke kolonner inneholder tabellene? Hva blir primærnøkler og fremmednøkler? Utsnitt (views): Hva brukes utsnitt til? Hvordan er de implementert? Oppdaterbarhet av utsnitt Forskjellen på spørringer og utsnitt Pensum: Kapittel 8.1 og 8.3 Databaser Leksjon 7: Logisk databasedesign - 2

3 Eksempel: Flypark Fly Kjennetegn Navn Flytype Motortype Avgang Dato KlSlett Flyplass Kode Navn By Ankomst Avgang Lastefly Lastevolum Lasteevne Passasjerfly AntallSitteplasser Passasjer PassasjerNr Fornavn Etternavn Adresse Databaser Leksjon 7: Logisk databasedesign - 3

4 Entiteter, attributter og identifikatorer Passasjer PassasjerNr Fornavn Etternavn Adresse Entiteter tabeller Attributter kolonner. Identifikatorer primærnøkler PASSASJERNR FORNAVN ETTERNAVN ADRESSE 1 Per Hansen Hansegata 3 2 Lise Jensen Jenseveien 12 OBS! Valg av datatyper er ikke en del av logisk design! Hvorfor? Hvis vi velger datatyper i E/R-diagrammet, beholder vi disse under logisk design? Databaser Leksjon 7: Logisk databasedesign - 4

5 En-til-mange forhold Avgang Dato Klslett Flyplass Kode Navn By Ankomst Avgang Identifikatorene på «en-siden» blir kolonner på «mange-siden», og fremmednøkler tilbake mot «en-siden». Flyplass( Kode, Navn, By ) Avgang(, Dato, KlSlett, Ankomst *, Avgang * ) Hvorfor dykker ikke Kode opp i tabell Avgang? Hvorfor har vi i primærnøkkel? Databaser Leksjon 7: Logisk databasedesign - 5

6 Svake entiteter Fly Kjennetegn Navn Flytype Motortype Avgang Dato KlSlett Svake entiteter finnes alltid på mange-siden Som før blir primærnøkkel fra en-siden til en ny fremmednøkkel I tillegg blir den nye fremmednøkkel med i primærnøkkel. Fly( Kjennetegn, Navn, Flytype, Motortype ) Avgang( Kjennetegn *, Dato, KlSlett, ) Databaser Leksjon 7: Logisk databasedesign - 6

7 Avgang Dato KlSlett Mange-til-mange forhold Passasjer PassasjerNr Fornavn Etternavn Adresse Mange-til-mange forhold blir til «koblingstabeller». Identifikatorene for de involverte entitetene blir til en sammensatt primærnøkkel. Obs! «Kjennetegn» har blitt arvet i to steg! Kan løse opp slike forhold i modellen, eller ved generering. Avgang( Kjennetegn *, Dato, KlSlett, ) Passasjerliste( Kjennetegn *, Dato *, KlSlett *, PassasjerNr * ) Passasjer( PassasjerNr, Fornavn, Etternavn, Adresse ) Databaser Leksjon 7: Logisk databasedesign - 7

8 Eksempel: Flypark Fly Kjennetegn Navn Flytype Motortype Avgang Dato KlSlett Flyplass Kode Navn By Ankomst Avgang Lastefly Lastevolum Lasteevne Passasjerfly AntallSitteplasser Passasjer PassasjerNr Fornavn Etternavn Adresse Databaser Leksjon 7: Logisk databasedesign - 8

9 Løse opp mange-til-mange forhold Avgang Dato KlSlett Passasjerliste Røyk Av hensyn til lesbarhet løs opp mangetil-mange forhold i E/R diagrammet bare hvis du ønsker å knytte attributter til forholdet. Koblingsentiteten vil inngå i to mangetil-en forhold. Passasjer PassasjerNr Fornavn Etternavn Adresse Avgang( Kjennetegn *, Dato, KlSlett, ) Passasjerliste(Kjennetegn *, Dato*, KlSlett*, PassasjerNr *, Røyk) Databaser Leksjon 7: Logisk databasedesign - 9

10 «Kodetabeller» Tabell for Flytype? «Kodetabeller» gir oss kontroll med lovlige verdier (fremmednøkkel). Fly(Kjennetegn, Navn, Motortype, FlytypeKode*) Flytype(FlytypeKode, Beskrivelse) Databaser Leksjon 7: Logisk databasedesign - 10

11 Oppsummering av enkle regler Entiteter blir til tabeller Attributter blir til kolonner. Identifikatorer blir til primærnøkler. Mange-til-mange forhold blir til «koblingstabeller». Identifikatorene for de involverte entitetene blir til en sammensatt primærnøkkel. Identifikatorene på «en-siden» i en-til-mange forhold blir kolonner på «mange-siden», og fremmednøkler mot «en-siden». Svake entiteter arver primærnøkler fra entitetene de er avhengige av. Hva gjenstår: 1:1 forhold og subtyper. Databaser Leksjon 7: Logisk databasedesign - 11

12 En-til-en forhold Identifikatoren for entitet A blir til fremmednøkkel i B eller motsatt (eller begge deler). Hva gir færrest nullmerker? Koblingstabell et alternativ hvis begge varianter gir mange nullmerker. Kan vi slå sammen entitetene? Anbefalt hvis kardinalitet 1-1 begge sider! Ansatt(AnsNr, Fornavn, Etternavn, Stilling) Avdeling(AvdKode, Tlf, AnsNrLeder*) Har rollen «leder» blitt implementert her? Databaser Leksjon 7: Logisk databasedesign - 12

13 Koblingstabeller for en-til-en forhold Man kan også opprette koblingstabeller for en-til-en forhold. Nyttig hvis få forekomster fra begge sider deltar. Eksempel: En-til-en forholdet «kontorplass» mellom Ansatt og Rom. Bygningen har mange rom, noen få er kontorer. Bedriften har mange ansatte, kun noen få har kontor (og ingen deler kontor). Rom(RomNr, Tlf) Ansatt(AnsNr, Fornavn, Etternavn) Kontorplass(RomNr*,AnsNr*) Forholdet blir altså håndtert på samme måte som et mange-til-mange forhold. Databaser Leksjon 7: Logisk databasedesign - 13

14 Håndtering av subtyper Subtyper er en del av modelleringsspråket (E/R), men tradisjonelt støtter ikke relasjonsdatabaser dette. Dermed må vi «simulere» subtyper. Problemstillinger: 1 eller flere tabeller? Hva skal «arves»? Nullmerker? Hvordan representere tilhørighet til subtyper? Objektrelasjonelle databaser har støtte for subtyper. Det er en fordel at «modelleringsspråket» bygger på de samme prinsippene som «implementasjonsspråket». Databaser Leksjon 7: Logisk databasedesign - 14

15 Fly Kjennetegn Navn Flytype Motortype Subtyper I: Separasjon Lager tabeller for både supertype og subtyper. Subtyper arver identifikatoren fra supertypen. Forekomster vil ligge i både «subtabeller» og «supertabell»! Lastefly Lastevolum Lasteevne Passasjerfly AntallSitteplasser Fly(Kjennetegn, Navn, Flytype, Motortype) Lastefly(Kjennetegn *, Lastevolum, Lasteevne) Passasjerfly(Kjennetegn *, AntallSitteplasser) Databaser Leksjon 7: Logisk databasedesign - 15

16 Fly Kjennetegn Navn Flytype Motortype Subtyper II: Absorpsjon Lager tabell kun for supertypen. Tabellen for supertypen får samtlige attributter fra subtypene + et «subtype»- attributt. Kan gi mange nullmerker. Lastefly Lastevolum Lasteevne Passasjerfly AntallSitteplasser Fly(Kjennetegn, Navn, Flytype, Motortype, LastEllerPassasjer, Lastevolum, Lasteevne, AntallSitteplasser) Databaser Leksjon 7: Logisk databasedesign - 16

17 Subtyper III: Partisjonering Fly Kjennetegn Navn Flytype Motortype Lager tabeller kun for subtypene. Tabellene for subtypene arver samtlige attributter fra supertypen. For å lage en liste over samtlige forekomster i supertypen må vi koble tabeller. Kan være problematisk å håndtere løpenumre. Alle må tilhøre en subtype! Lastefly Lastevolum Lasteevne Passasjerfly AntallSitteplasser Lastefly(Kjennetegn *, Navn, Flytype, Motortype, Lastevolum, Lasteevne) Passasjerfly(Kjennetegn *, Navn, Flytype, Motortype, AntallSitteplasser) Databaser Leksjon 7: Logisk databasedesign - 17

18 Tabellstruktur for Fly-databasen Databaser Leksjon 7: Logisk databasedesign - 18

19 Utsnitt (views) Et utsnitt (view) er en «virtuell» tabell. Anvendelser: Sikkerhet bruker ikke aksess til visse tabeller Presentasjon oppdeling ikke synlig for bruker - tilpassing til forskjellige brukergrupper Representasjonsuavhengighet kan endre tabell definisjoner uten at bruker blir berørt Støtte for utsnitt: Utsnitt er en del av SQL-standarden. MySQL støtter utsnitt. Vanlig oppsett av Access støtter ikke utsnitt. Databaser Leksjon 7: Logisk databasedesign - 19

20 Generelt om utsnitt Et utsnitt blir definert slik: CREATE VIEW <Utsnittsnavn> ( <kolonner> ) AS <Utvalgsspørring uten ORDER BY> Utsnitt skal kunne betraktes som tabeller og tabeller er ikke sortert. Et utsnitt er en «brille» mot tabellene. Et utsnitt er ikke en fysisk kopi! Oppdatering i et utsnitt medfører oppdatering i den underliggende tabellen. Ikke alle utsnitt er oppdaterbare! Et utsnitt blir representert ved sin definerende spørring. DBHS lagrer definisjonen av utsnitt i en systemtabell. Databaser Leksjon 7: Logisk databasedesign - 20

21 Eksempel Et utsnitt som viser noen egenskaper om noen varer (vi bruker altså projeksjon og seleksjon) : CREATE VIEW Keramikk( Varekode, Navn ) AS SELECT VNr, Varenavn FROM Vare WHERE KategoriNr = 5 Hvis vi sløyfer kolonnenavnene etter utsnittsnavnet «arver» utsnittet kolonnenavn fra spørringen. Sikkerhet: Vi kan gi brukere innsyn i utsnittet Keramikk, men ikke i hele Vare-tabellen. Utsnitt gjør sikkerhetssystemet mer «finmasket». Databaser Leksjon 7: Logisk databasedesign - 21

22 Databasetabellen Vare (leksjon 2) VNr Betegnelse Pris Kategori Antall Hylle Marsipantang Konditor 0 B Malerskrin, 6 farger Hobbymaling 2 B Nisseskjegg, 30 cm Dukker Hengebegonia, 10 stk Blomster 206 E Kram tørrfluekorker Fiske 213 B Lakrisekstrakt, 100g Konditor 104 B Antron garn, hvit Fiske 21 B Glasskuler, 100 gr Dukker 0 E Tubeflueverktøy Fiske 39 B Blomkarse Blomster 206 E Moro med marsipan Bøker 140 C Gipsform marihøner Keramikk 124 B03 Kan vi unngå å skrive samme «Kategori» tekst flere ganger? Databaser Leksjon 7: Logisk databasedesign - 22

23 Tabellene Vare og Kategori (leksjon 2) KatNr Kategori 1 Blomster 2 Bøker 3 Konditor 4 Hobbymaling 5 Keramikk 6 Dukker 7 Fiske Oppslagstabell Fremmednøkkel Unngår skrivefeil. Sparer lagringsplass. Vi kan gjenskape den opprinnelige tabellen. VNr... KatNr Databaser Leksjon 7: Logisk databasedesign - 23

24 Utsnitt fra flere tabeller Utsnitt som grunnlag for salgsrapporter: CREATE VIEW Salg AS SELECT OL.*, V.Varenavn, K.navn, O.Ordredato, O.AnsattNr, O.KundeNr FROM Ordre AS O, Ordrelinje AS OL, Vare AS V, Kategori AS K WHERE OL.OrdreNr = O.OrdreNr AND OL.VNr = V.VNr AND V.KatNr = K.KatNr Presentasjon: Brukere av utsnittet trenger ikke å koble tabeller! Vi presenterer en «forenklet» database til brukerne. Databaser Leksjon 7: Logisk databasedesign - 24

25 Ordre og Ordrelinje (leksjon 2) OrdreNr Ordredato KNr Tenk på et ordreskjema. Ordreskjemaet består av et «hode» (dato, kundenr, ) og et antall «linjer», (varenummer, antall, ) Det er et en-til-mange forhold mellom en ordre og en linje på denne ordren. Primærnøkkel? Fremmednøkkel? OrdreNr VNr Pris Antall Databaser Leksjon 7: Logisk databasedesign - 25

26 Spørringer mot utsnitt Salg siste måned fordelt på varer: SELECT VNr, SUM(Antall*Pris) AS Totalt FROM Salg WHERE Year( Ordredato )= Year( Date() ) AND Month( Ordredato ) = Month( Date() ) GROUP BY VNr Spørringen over kan utføres ved å «sette inn» definisjonen av utsnittet Salg i spørringen. Hvordan ser resultatspørringen ut? Hvorfor er denne teknikken effektiv? Kan du tenke deg en alternativ framgangsmåte? Databaser Leksjon 7: Logisk databasedesign - 26

27 Eksempel: Sette-inn definisjonen av utsnittet Utsnitt: CREATE VIEW Keramikk AS SELECT VNr, Varenavn FROM Vare WHERE KategoriNr = 5 Spørring: SELECT * FROM Keramikk WHERE Antall < 5 Resultat av substitusjon : SELECT * FROM ( SELECT VNr, Varenavn FROM Vare WHERE KategoriNr = 5 ) WHERE Antall < 5 Optimert resultat: SELECT VNr, Varenavn FROM Vare WHERE KategoriNr = 5 AND Antall < 5 Databaser Leksjon 7: Logisk databasedesign - 27

28 Oppdatering «i» utsnitt Antall varer pr. kategori: CREATE VIEW AntallVarerPrKategori AS SELECT KatNr, COUNT(*) AS AntallVarer FROM Vare GROUP BY KatNr Vi kan skrive INSERT, UPDATE, DELETE mot (noen) utsnitt. Hva om vi endrer antall varer i kategorien meierivarer fra 5 til 2? Hva skal effekten for den underliggende tabellen være? Hvilke utsnitt er det mulig å oppdatere? Seleksjoner? Projeksjoner? Grupperinger? Koblinger? SQL har regler for hvilke utsnitt som er oppdaterbare. Databaser Leksjon 7: Logisk databasedesign - 28

29 Regler for oppdatering Regler varierer noe fra system til system. Skal sikre at oppdatering mot utsnitt kan oversettes til en oppdatering mot de underliggende tabellene! Forenklet oppsummering: Ikke DISTINCT, GROUP BY eller mengde-funksjoner i utsnitt. Utsnitt har ikke delspørringer i SELECT-delen. For utsnitt mot en enkelt tabell må primærnøkkelen være med i SELECT-delen. For utsnitt basert på kobling av flere tabeller kan oppdatering o o Kun berøre en av de undeliggende tabeller, og Primærnøkkel for denne tabellen må også være en kandidatnøkkel for utsnittet. Databaser Leksjon 7: Logisk databasedesign - 29

30 Representasjonsuavhengighet Utsnitt kan gjøre det lettere å endre hvordan databasen er organisert, f.eks.: Endre datatyper Innføre nye tabeller (som når vi innførte tabellen Kategori og erstattet KatNavn med KatNr i tabellen Vare) Anta at vi lager utsnitt av typen: CREATE VIEW VareUtsnitt AS SELECT * FROM Vare Anta videre at vi skriver spørringer mot disse utsnittene i stedet for direkte mot tabellene. Hvis vi gjør endringer i tabellstrukturen, må (riktig nok) utsnittene også endres. Men spørringene (generelt: applikasjonene) mot utsnittene kan i prinsippet være uendret. Utsnitt kan altså bidra til representasjonsuavhengighet. Databaser Leksjon 7: Logisk databasedesign - 30