3 - Ontwerpen van een relationele database Het omzetten van een ERM-model naar een relationeel model Hoofdstuk 2.1 Hoofdstuk 2.2 Hoofdstuk 2.3 Hoofdstuk 2.4 Hoofdstuk 2.5 Hoofdstuk 2.6 Hoofdstuk 3.1 Hoofdstuk 3.2 Hoofdstuk 3.3 Hoofdstuk 3.4 Hoofdstuk 3.5
1 - Het omzetten van een ERM-model naar een relationeel model   
|
© Instruct |
|
Bij het omzetten van een ERM-model naar een relationeel model spelen de volgende componenten een rol:
We besteden eerst aandacht aan het omzetten van relatietypen en cardinaliteiten. Het is dan het meest overzichtelijk als we gebruik maken van een schematische weergave, waarvan het ERD het uitgangspunt is. Hierin worden stap voor stap enkele wijzigingen aangebracht. Het resultaat is een grafisch model waaruit duidelijk blijkt waar (in welke relaties) de vreemde sleutels moeten komen. |
| 2 - Omzetten één-op-veel relatie naar relationeel model
|
© Instruct |
|
Allereerst het één-op-veel verband tussen klas en student:
De regel die we gaan toepassen luidt: plaats een pijl die begint bij de cardinaliteit n en die wijst in de richting van het relatietype. Het resultaat zie je in de volgende figuur:
De volgende stap is het verwijderen van het relatietype, en de beide entiteittypen met elkaar verbinden met behulp van de getekende pijl.
De vreemde sleutel moet geplaatst worden in de relatie aan de pijlpunt:
<afdeling, klasnummer>)Klas (afdeling, klasnummer, aantal_studenten) |
| 3 - Omzetten veel-op-veel relatie naar relationeel model
|
© Instruct |
|
Bij een veel-op-veel verband tussen twee entiteittypen is er een belangrijk verschil tussen het ERD en het relationele model.
We laten dat zien aan de hand van de relatie tussen Leverancier en Product.
De regel die we eerder toegepast hebben, passen we nu twee maal toe: plaats een pijl die begint bij de cardinaliteit n en die wijst in de richting van het relatietype. Het resultaat zie je in de volgende figuur.
Bij een veel-op-veel verband wordt het relatietype niet verwijderd, maar wordt het omgezet in een relatie. De resulterende figuur bevat nu dus drie relaties:
In de relatie Kan leveren komen nu twee vreemde sleutels: de ene vreemde sleutel refereert aan de relatie Leverancier, de andere vreemde sleutel refereert aan de relatie Product. Deze twee vreemde sleutels zijn tegelijk de enige attributen van de relatie Kan leveren. Aangezien een primaire sleutel verplicht is, moeten we voor de relatie Kan_leveren ook een primaire sleutel benoemen. Die primaire sleutel wordt dan gevormd door de combinatie van de beide vreemde sleutels. De drie relaties worden nu:
Product (productcode, productomschrijving, inkoopprijs, verkoopprijs, voorraad) Kan_leveren ( <leveranciercode>, <productcode>)De relatie Kan leveren bevat dus niet meer dan één primaire sleutel en twee vreemde sleutels. Deze relatie is uitsluitend bedoeld om een veel-op-veel verband te realiseren. De combinatie ‘leveranciercode, productcode’ is altijd uniek. Als dat niet het geval zou zijn, dan zou het feit dat een bepaalde leverancier een bepaald product kan leveren, meer dan eens vastgelegd kunnen worden. Dat is natuurlijk niet de bedoeling. |
| 4 - Omzetten één-op-één relatie naar relationeel model
|
© Instruct |
|
Het omzetten van een één-op-één verband verloopt weer anders. We kunnen nu geen pijl tekenen die van een cardinaliteit n loopt naar een relatietype. Dat betekent dat we nu een keuze moeten maken. In het voorbeeld van het relatietype tussen de entiteittypen Docent en Klas moet nu gekozen worden in welke relatie de vreemde sleutel komt.
De vraag is: hoort de docent bij de klas of hoort de klas bij de docent? Dat laatste lijkt het meest voor de hand te liggen. Dus zouden we kunnen besluiten om de vreemde sleutel aan te brengen in de relatie klas. De pijl moet dan lopen vanaf het entiteittype Docent naar het relatietype is mentor van.
De grafische weergave wordt dan:
De relaties die hierbij horen zijn:
Klas (afdeling, klasnummer, aantalstudenten, <docentcode>) |
