Databanken 2
1. Datamodellering 1
ANSI/SPARC model
1. External level
- de views van de 2
gebruikers op de databank.
- beschrijft dat deel van
de databank dat relevant
is voor een bepaalde gebruiker. 3
2. Conceptual level
- Community view of the
database
- Beschrijft welke gegevens en
welke relaties tussen die gegevens in
de databank moeten bewaard worden.
3. Internal level
- Fysische voorstelling van de databank op de computer.
- Beschrijft hoe de gegevens worden opgeslagen in de databank.
Logische gegevensonafhankelijkheid
- Refereert naar de immuniteit van de externe schema’s bij wijzigingen van het
conceptuele schema.
- Bij wijzigingen van het conceptuele schema (toevoegen/ verwijderen van entiteiten) mag
dit geen wijzigingen vereisen bij extern schema of het herschrijven van een
applicatieprogramma.
Fysische gegevensonafhankelijkheid
- Refereert naar de immuniteit van het conceptuele schema bij wijzigingen van het interne
schema.
- Interne schema wijzigingen (zoals het gebruik van een andere bestandsorganisatie,
opslagstructuur of apparatuur) vereisen geen wijzigingen bij het conceptueel schema of
externe schema’s.
Gegevensmodellering
Goed database systeem vraagt om een goed datamodel. (Bottom up <-> top down werken)
Het datamodel moet
- Aan de noden van de gebruiker voldoen.
- Door de eindgebruiker gemakkelijk begrepen worden.
- Voldoende specificaties bevatten zodat vanuit het model de databank kan aangemaakt
worden.
Conceptueel ontwerp logisch ontwerp fysisch ontwerp
,Conceptueel gegevensmodel
Objectief: bepalen welke gegevensvereisten de onderneming heeft.
Een conceptueel model omvat: entiteitstypen, relatietypes, attributen en attribuutdomeinen,
primaire sleutels en alternatieve sleutels, integriteitsbeperkingen.
De documentatie van een conceptueel model is een ERD en een data dictionairy.
1. identificeer de entiteitstypes. (Bv. Restaurant, klant, tafel, bestelling,…)
2. identificeer de relatietypes. (Bv. 1:n, 1:1, …)
3. bepaal voor entiteitstypes de attributen. (Bv. Klantnaam : String, …)
4. bepaal de attribuut domeinen. (Bv. Geslacht: ‘M’ of ‘V’ , tafel: 1..99 , …)
5. bepaal kandidaat sleutels en primaire sleutel. (PK of FK)
6. bekijk het gebruik van uitgebreidere modelleerconcepten. (generalisatie/specialisatie)
7. controleer het model op redundantie.
8. overloop het conceptuele model met de gebruiker.
Logisch (relationeel) model
Objectief: het vertalen van het conceptuele model naar een logisch gegevensmodel.
Onafhankelijk van DBMS of andere fysische beschouwingen.
1. Leid tabellen af voor het logisch model = mapping. (entiteitstype tabel,
associatie foreign key, …)
surrogaat keys = gebruik van enkelvoudige identificatie van een rij. (meestal automatisch)
business keys = velden met betekenis voor de klant (Bv. Product serienummer)
2. Valideer de tabellen via normalisatie.(geen anomalieën en redundantie)
3. Valideer de tabellen t.o.v. de gebruikerstransacties.
4. Controleer de integriteitsbeperkingen. (geen NULL’ s, constraints, …)
Referentiële integriteitsregel = eist dat bij elke verwijzende sleutelwaarde (kind) een
ouderrij hoort.
Probleem bij het verwijderen van een ouderrij.
Probleem bij het wijzigen van de primaire-sleutelwaarde in een ouderrij.
Oplossing:
- RESTRICTED DELETE(update) = een poging tot delete van een ouderrij mislukt wanneer
er één of meer corresponderende kinderrijen bestaan: De opdracht kan enkel uitgevoerd
worden als er geen afhankelijke tuples meer zijn.
- CASCADING DELETE(update) = bij een poging tot delete van een ouderrij zal een poging
tot delete van alle corresponderende kinderrijen worden ondernomen. Is er een (andere)
regel die dat tegenhoudt, dan gaat de delete niet door.
- NULLIFYING DELETE(update) = bij een poging tot delete van een ouderrij wordt getracht
verwijzingen in eventuele kinderrijen op null te zetten. Is er een (andere) regel die dat
tegenhoudt dan gaat de delete niet door.
5. Overloop het logisch model met de gebruiker.
6. Breng de logische modellen samen tot één globaal model.
7. Controleer de toekomstige groei.
8. overloop het logisch model met de gebruiker.
Fysisch gegevensmodel
Objectief: vertaal het logisch model naar een target DBMS (fysisch model)
, Denormalisatie
= techniek waarbij aanpassingen gebeuren aan een gegevensstructuur in de derde normaalvorm,
waarbij opnieuw mogelijke delete en update inconsistentie binnen de gegevensstructuur kan komen.
De performantie is afhankelijk van de
- statische last: bepaald door de tabellen.
- Dynamische last: bepaald door tabellen die benaderd worden door taken van de
databank.
Manieren van denormalisatie:
1. Relaties samenbrengen in één bestand (entiteitstypen samenvoegen)
- Omdat ze samen worden gebruikt;
- Wegens de hoge gebruiksfrequentie.
2. Relatiegegevens onderbrengen in verschillende bestanden (redundantie inbouwen door
attributen te herhalen in meerdere entiteitstypes) :
- fysische en logische herhaling
3. Partitioneren van tabellen = Relaties splitsen in meerdere bestanden (entiteitstypen splitsen)
De horizontale partitionering: waarbij rijen (entiteiten) in meerdere
tabellen onderbrengen
De verticale partitionering: waarbij kolommen over meerdere tabellen
worden gesplitst.
- omdat de delen apart kunnen worden gebruikt;
- om de recordlengte te beperken;
- om privacy redenen.
2. Normalisatie en integratie normalisatieresultaten
normalisatie
= een proces waarbij een groep gegevens wordt opgesplitst in meerdere groepen gegevens, zodat bij
het gebruik en onderhoud geen anomalieën en zo weinig mogelijk redundantie voorkomt.
Anomalieën = onregelmatigheden bij het gebruik en het onderhoud van de gegevens.
- Insert anomalie = een nieuwe afdeling komt pas als er een medewerker wordt
opgenomen in MedewerkerAfdeling.
- Update anomalie = wanneer een afdeling een nieuw adres krijgt, moeten mogelijk
meerdere rijen aangepast worden.
- Delete anomalie = Als Jef het bedrijf verlaat, is er geen informatie terug te vinden over
afdeling B007.
Functionele afhankelijkheid = beschrijft de relatie tussen attributen binnen een entiteit.
- B A = A is functioneel afhankelijk van B
- B is een determinant voor A
0NV gegevens in entiteiten plaatsen en duid een PK aan
1NV herhalende groepen elimineren
2NV niet sleutelattributen moeten functioneel afhankelijk zijn van de volledige sleutel
3NV de entiteiten bevatten geen transitieve afhankelijkheden
1. Datamodellering 1
ANSI/SPARC model
1. External level
- de views van de 2
gebruikers op de databank.
- beschrijft dat deel van
de databank dat relevant
is voor een bepaalde gebruiker. 3
2. Conceptual level
- Community view of the
database
- Beschrijft welke gegevens en
welke relaties tussen die gegevens in
de databank moeten bewaard worden.
3. Internal level
- Fysische voorstelling van de databank op de computer.
- Beschrijft hoe de gegevens worden opgeslagen in de databank.
Logische gegevensonafhankelijkheid
- Refereert naar de immuniteit van de externe schema’s bij wijzigingen van het
conceptuele schema.
- Bij wijzigingen van het conceptuele schema (toevoegen/ verwijderen van entiteiten) mag
dit geen wijzigingen vereisen bij extern schema of het herschrijven van een
applicatieprogramma.
Fysische gegevensonafhankelijkheid
- Refereert naar de immuniteit van het conceptuele schema bij wijzigingen van het interne
schema.
- Interne schema wijzigingen (zoals het gebruik van een andere bestandsorganisatie,
opslagstructuur of apparatuur) vereisen geen wijzigingen bij het conceptueel schema of
externe schema’s.
Gegevensmodellering
Goed database systeem vraagt om een goed datamodel. (Bottom up <-> top down werken)
Het datamodel moet
- Aan de noden van de gebruiker voldoen.
- Door de eindgebruiker gemakkelijk begrepen worden.
- Voldoende specificaties bevatten zodat vanuit het model de databank kan aangemaakt
worden.
Conceptueel ontwerp logisch ontwerp fysisch ontwerp
,Conceptueel gegevensmodel
Objectief: bepalen welke gegevensvereisten de onderneming heeft.
Een conceptueel model omvat: entiteitstypen, relatietypes, attributen en attribuutdomeinen,
primaire sleutels en alternatieve sleutels, integriteitsbeperkingen.
De documentatie van een conceptueel model is een ERD en een data dictionairy.
1. identificeer de entiteitstypes. (Bv. Restaurant, klant, tafel, bestelling,…)
2. identificeer de relatietypes. (Bv. 1:n, 1:1, …)
3. bepaal voor entiteitstypes de attributen. (Bv. Klantnaam : String, …)
4. bepaal de attribuut domeinen. (Bv. Geslacht: ‘M’ of ‘V’ , tafel: 1..99 , …)
5. bepaal kandidaat sleutels en primaire sleutel. (PK of FK)
6. bekijk het gebruik van uitgebreidere modelleerconcepten. (generalisatie/specialisatie)
7. controleer het model op redundantie.
8. overloop het conceptuele model met de gebruiker.
Logisch (relationeel) model
Objectief: het vertalen van het conceptuele model naar een logisch gegevensmodel.
Onafhankelijk van DBMS of andere fysische beschouwingen.
1. Leid tabellen af voor het logisch model = mapping. (entiteitstype tabel,
associatie foreign key, …)
surrogaat keys = gebruik van enkelvoudige identificatie van een rij. (meestal automatisch)
business keys = velden met betekenis voor de klant (Bv. Product serienummer)
2. Valideer de tabellen via normalisatie.(geen anomalieën en redundantie)
3. Valideer de tabellen t.o.v. de gebruikerstransacties.
4. Controleer de integriteitsbeperkingen. (geen NULL’ s, constraints, …)
Referentiële integriteitsregel = eist dat bij elke verwijzende sleutelwaarde (kind) een
ouderrij hoort.
Probleem bij het verwijderen van een ouderrij.
Probleem bij het wijzigen van de primaire-sleutelwaarde in een ouderrij.
Oplossing:
- RESTRICTED DELETE(update) = een poging tot delete van een ouderrij mislukt wanneer
er één of meer corresponderende kinderrijen bestaan: De opdracht kan enkel uitgevoerd
worden als er geen afhankelijke tuples meer zijn.
- CASCADING DELETE(update) = bij een poging tot delete van een ouderrij zal een poging
tot delete van alle corresponderende kinderrijen worden ondernomen. Is er een (andere)
regel die dat tegenhoudt, dan gaat de delete niet door.
- NULLIFYING DELETE(update) = bij een poging tot delete van een ouderrij wordt getracht
verwijzingen in eventuele kinderrijen op null te zetten. Is er een (andere) regel die dat
tegenhoudt dan gaat de delete niet door.
5. Overloop het logisch model met de gebruiker.
6. Breng de logische modellen samen tot één globaal model.
7. Controleer de toekomstige groei.
8. overloop het logisch model met de gebruiker.
Fysisch gegevensmodel
Objectief: vertaal het logisch model naar een target DBMS (fysisch model)
, Denormalisatie
= techniek waarbij aanpassingen gebeuren aan een gegevensstructuur in de derde normaalvorm,
waarbij opnieuw mogelijke delete en update inconsistentie binnen de gegevensstructuur kan komen.
De performantie is afhankelijk van de
- statische last: bepaald door de tabellen.
- Dynamische last: bepaald door tabellen die benaderd worden door taken van de
databank.
Manieren van denormalisatie:
1. Relaties samenbrengen in één bestand (entiteitstypen samenvoegen)
- Omdat ze samen worden gebruikt;
- Wegens de hoge gebruiksfrequentie.
2. Relatiegegevens onderbrengen in verschillende bestanden (redundantie inbouwen door
attributen te herhalen in meerdere entiteitstypes) :
- fysische en logische herhaling
3. Partitioneren van tabellen = Relaties splitsen in meerdere bestanden (entiteitstypen splitsen)
De horizontale partitionering: waarbij rijen (entiteiten) in meerdere
tabellen onderbrengen
De verticale partitionering: waarbij kolommen over meerdere tabellen
worden gesplitst.
- omdat de delen apart kunnen worden gebruikt;
- om de recordlengte te beperken;
- om privacy redenen.
2. Normalisatie en integratie normalisatieresultaten
normalisatie
= een proces waarbij een groep gegevens wordt opgesplitst in meerdere groepen gegevens, zodat bij
het gebruik en onderhoud geen anomalieën en zo weinig mogelijk redundantie voorkomt.
Anomalieën = onregelmatigheden bij het gebruik en het onderhoud van de gegevens.
- Insert anomalie = een nieuwe afdeling komt pas als er een medewerker wordt
opgenomen in MedewerkerAfdeling.
- Update anomalie = wanneer een afdeling een nieuw adres krijgt, moeten mogelijk
meerdere rijen aangepast worden.
- Delete anomalie = Als Jef het bedrijf verlaat, is er geen informatie terug te vinden over
afdeling B007.
Functionele afhankelijkheid = beschrijft de relatie tussen attributen binnen een entiteit.
- B A = A is functioneel afhankelijk van B
- B is een determinant voor A
0NV gegevens in entiteiten plaatsen en duid een PK aan
1NV herhalende groepen elimineren
2NV niet sleutelattributen moeten functioneel afhankelijk zijn van de volledige sleutel
3NV de entiteiten bevatten geen transitieve afhankelijkheden
