2009Softwarekonstruktion / DB-design 11 Databasedesign 1 Fra begrebsmæssig model til relationel model.

Præsentationer af emnet: "2009Softwarekonstruktion / DB-design 11 Databasedesign 1 Fra begrebsmæssig model til relationel model."— Præsentationens transcript:

1 2009Softwarekonstruktion / DB-design 11 Databasedesign 1 Fra begrebsmæssig model til relationel model

2 2009Softwarekonstruktion / DB-design 12 OOD  Relationel database: Klasser Hver klasse afbildes over i en tabel. Klassens navn bruges som navn på tabellen. Hver af klassens attributter afbildes over i en søjle i tabellen. Tabellen udbygges med en søjle, som indeholder en entydig reference til ethvert objekt. For hver attribut overvejes endvidere –domæne (type) –muligheden for NULL værdier –relevante nøgler Kunde CPR-nr Navn Adresse kunde-IDCPR-nrnavnadresse 1010155-2321Jens AndersenSøndergade 6 2101289-7566Oda NielsenAlgade 99 1251060967-2390Pia SchrøderBispensgade 27

3 2009Softwarekonstruktion / DB-design 13 Aggregeringsstruktur: Mange-til-mange Kunde-Konto Konto Kunde kunde-IDkonto-ID 1 2 1 4 2 1 2 2 2 4 3 3 4 2 4 1251 5 1251 256 25 kunde-IDCPR-nrnavnadresse 1010155-2321Jens AndersenSøndergade 6 2101289-7566Oda NielsenAlgade 99 1251060967-2390Pia SchrøderBispensgade 27 konto-IDkonto-nrsidste-udtogkontotype 1615-6789280295checkkonto 2931-1453311294lån 256112-7290120395checkkonto Konto Saldo SidsteUdtog Kontotype Kunde CPR-nr Navn Adresse 0:m 1:m Ny tabel med primærnøglerne som fremmednøgler

4 2009Softwarekonstruktion / DB-design 14 Aggregeringsstruktur: en-til-mange Konto kontoIDkonto-nrsidste-udtogkontotype kundeID 1615-6789280295checkkonto 2 2931-1453311294lån 2 256112-7290120395checkkonto 25 Nøglen for den ene klasses objekter bliver til attribut- værdier (fremmednøgler) i den anden klasses objekter. Konto Saldo SidsteUdtog Kontotype Kunde CPR-nr Navn Adresse 1 1:m

5 2009Softwarekonstruktion / DB-design 15 Aggregeringsstruktur: en-til-en Nøglen for den ene klasses objekter bliver til attribut- værdier (fremmednøgler) i den anden klasses objekter. Konto Saldo SidsteUdtog Kontotype Kunde CPR-nr Navn Adresse 1 1 Kunde kunde-IDCPR-nrnavnadressekontoId 1010155-2321Jens AndersenSøndergade 6 2 2101289-7566Oda NielsenAlgade 99 1 1251060967-2390Pia SchrøderBispensgade 27

6 2009Softwarekonstruktion / DB-design 16 Aggregeringsstruktur: en-til-en Konto kontoIDkonto-nrsidste-udtogkontotype kundeID 1615-6789280295checkkonto 2 2931-1453311294lån 1 1251112-7290120395checkkonto 5 Nøglen for den ene klasses objekter bliver til attribut- værdier (fremmednøgler) i den anden klasses objekter. Konto Saldo SidsteUdtog Kontotype Kunde CPR-nr Navn Adresse 1 1

7 2009Softwarekonstruktion / DB-design 17 Aggregeringsstruktur: en-til-en På hvilken side skal nøglen inkluderes? –Oftest på aggregatets side, men afhænger af navigationsveje (use cases) –Husk også: minimer NULL-værdier Konto Saldo SidsteUdtog Kontotype Kunde CPR-nr Navn Adresse 1 1

8 2009Softwarekonstruktion / DB-design 18 Associeringsstruktur: Samme diskussion som ved aggregering Tre muligheder: –Én-til-én (1-1): En person er knyttet til en bil –Én-til-mange (1-n): En person kan være knyttet til mange biler, men en bil er kun knyttet til en person –Mange-til-mange (n-m): en person kan være knyttet til flere biler og en bil kan være knytte til flere personer Person Bil 11 PersonBil 1* Person Bil **

9 2009Softwarekonstruktion / DB-design 19 Associeringsstruktur: Samme diskussion som ved aggregering Én-til-én (1-1): –Inkluder den ene sides primærnøgle som fremmednøgle på den anden Én-til-mange (1-n): –1-sidens primærnøgle medtages som fremmednøgle på n-siden Mange-til-mange (n-m): –Ny tabel med begge siders primærnøgler som fremmednøgler Person Bil 11 PersonBil 1* Person Bil **

10 2009Softwarekonstruktion / DB-design 110 Klassestruktur: Generalisering Generalisering: tre alternativer 1.Hver klasse afbildes i en tabel. De generelle og specielle dele af et objekt bindes sammen med nøgler. 2.Hver specialiseringsklasse afbildes i en tabel, som også indeholder generaliseringsklassens attributter. 3.Generaliseringsklassen afbildes i en tabel, som også indeholder alle specialiseringsklassernes attributter. Konto KontoNr SidsteUdtog Checkkonto Rentesats SidsteHæfte Lån Hovedstol Afdrag Afdragsdato

11 2009Softwarekonstruktion / DB-design 111 Generalisering (1) konto-IDkonto-nrsidste-udtogkontotype 1615-6789280295checkkonto 2931-1453311294lån 256112-7290120395checkkonto konto-IDrentesatssidste-hæfte 10,1100395 2560,5221294 Konto konto-IDhovedstolafdragafdragsdato 225000250030 Checkkonto Lån Begrebsmæssig klar. Enkel og overskuelig. Let at ændre. Besværligt at tilgå objekter (kræver join). Konto KontoNr SidsteUdtog Checkkonto Rentesats SidsteHæfte Lån Hovedstol Afdrag Afdragsdato

12 2009Softwarekonstruktion / DB-design 112 Generalisering (2) Checkkonto konto-IDkonto-nrsidste-udtogrentesatssidste-hæfte 1615-67892802950,1100395 256112-72901203950,5221294 Ingen tabel for generaliseringsklassen. Enkel tilgang, når kontotypen kendes. Bedst når generaliseringsklassen har få attributter. Dur ikke ved overlap (redundans) Konto KontoNr SidsteUdtog Checkkonto Rentesats SidsteHæfte Lån Hovedstol Afdrag Afdragsdato

13 2009Softwarekonstruktion / DB-design 113 Generalisering (3) Konto Ingen tabeller for specialiseringsklasserne. Enkel tilgang. Bedst når generaliseringsklassen har mange attributter (og specialiseringerne få!). Giver mange NULL-værdier konto-IDkonto-nrsidste-udtogkontotyperentesatssidste-hæftehovedstolafdragafdragsdato 1615-6789280295checkkonto0,1100395 2931-1453311294lån25000250030 256112-7290120395checkkonto0,5221294

14 2009Softwarekonstruktion / DB-design 114 Sammenfatning Hver domæneklasse bliver til en tabel: –Attributter, nøgler, typer, NULLs? –Primærnøgle vælges/tilføjes. Associeringer og aggregeringer transformeres til fremmednøglereferencer: –1-1: Inkluder den ene sides primærnøgle som fremmednøgle på den anden –1-n: 1-sidens primærnøgle medtages som fremmednøgle på n-siden –n-m: Ny tabel med begge siders primærnøgler som fremmednøgler Generalisering: vælg én af følgende: 1.Hver klasse afbildes i en tabel. De generelle og specielle dele af et objekt bindes sammen med nøgler. 2.Hver specialiseringsklasse afbildes i en tabel, som også indeholder generaliseringsklassens attributter. 3.Generaliseringsklassen afbildes i en tabel, som også indeholder alle specialiseringsklassernes attributter.