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

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 Jens AndersenSøndergade Oda NielsenAlgade Pia SchrøderBispensgade 27

2009Softwarekonstruktion / DB-design 13 Aggregeringsstruktur: Mange-til-mange Kunde-Konto Konto Kunde kunde-IDkonto-ID kunde-IDCPR-nrnavnadresse Jens AndersenSøndergade Oda NielsenAlgade Pia SchrøderBispensgade 27 konto-IDkonto-nrsidste-udtogkontotype checkkonto lån checkkonto Konto Saldo SidsteUdtog Kontotype Kunde CPR-nr Navn Adresse 0:m 1:m Ny tabel med primærnøglerne som fremmednøgler

2009Softwarekonstruktion / DB-design 14 Aggregeringsstruktur: en-til-mange Konto kontoIDkonto-nrsidste-udtogkontotype kundeID checkkonto lån checkkonto 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

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 Jens AndersenSøndergade Oda NielsenAlgade Pia SchrøderBispensgade 27

2009Softwarekonstruktion / DB-design 16 Aggregeringsstruktur: en-til-en Konto kontoIDkonto-nrsidste-udtogkontotype kundeID checkkonto lån checkkonto 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

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

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 **

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 **

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

2009Softwarekonstruktion / DB-design 111 Generalisering (1) konto-IDkonto-nrsidste-udtogkontotype checkkonto lån checkkonto konto-IDrentesatssidste-hæfte 10, , Konto konto-IDhovedstolafdragafdragsdato 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

2009Softwarekonstruktion / DB-design 112 Generalisering (2) Checkkonto konto-IDkonto-nrsidste-udtogrentesatssidste-hæfte , , 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

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 checkkonto0, lån checkkonto0,

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.