Analyse 3 INFANL01-3 week 2 CMI Informatica

Roosterprobleem 4 11:20 12:10 INFANL01-3 WD.04.002 - INF1A, INF1B (Analyse 3)   5 13:00 12:30 Lunch lezing H1.206 6 13:50

Analyse 3- INFANL01-3 Vorige les Primaire sleutel, uniek en verwijssleutel Normaliseren

Vorige les

Tabellen kolom (attribuut, veld) domein (‘M’,’V’) tabel (relatie) waarde=’V’ rij (record, tuple, occurence) Een tabel (of relatie) bestaat uit rijen (horizontaal) en kolommen (verticaal) andere namen voor rij zijn : record, tuple, occurence; andere namen voor kolom : attribuut, veld. De structuur van een tabel is de definitie van de kolommen van een tabel en de domeinen/datatypen van die kolommen/attributen. Uit een plaatje van een tabel is de structuur af te lezen uit de heading (kop). Een meer formele notatie : patient(PAT#, ....). De rijen onder de kop geven de inhoud van een tabel weer. De structuur van een tabel wordt van te voren gedefinieerd mbv DDL, en ligt daarna vast (vgl.declaratie van een variabele (int i)). De inhoud van een tabel (de aanwezige rijen of records, vgl. de waarde van een variabele (i=1)) kan worden gemanipuleerd met DML. De volgorde van de rijen is niet belangrijk / onbepaald. De waarde van een database tabel is daarom een verzameling (Eng. set) rijen. De definitie van een tabel bestaat uit een verzameling kolommen. tabelstructuur : patient(PAT#,PNAAM,LEEFTIJD,GESLACHT,ARTS)

Entiteit Relatie Diagram Elementen Entiteiten Attributen Sleutels (Identifiers) Relaties

Het relationele model

Vorige les

Entiteit Relatie Diagram – Sleutels Sleutels (Identifiers) zijn speciale attributen in een tabel: attribuut of attributen die een entiteit identificeren uniek of niet uniek samengesteld

Sleutels Een sleutel is een groep van één of meerdere attributen waardoor een rij uniek wordt geïdentificeerd

Soorten sleutels Primaire sleutel (primary key) Simpel Samengesteld (composite) Zelfbedacht (artificial of surrogate) Verwijssleutel (foreign key) Verwijst een rij of meerdere rijen van een tabel naar een rij of meerdere rijen van een andere tabel (zie relaties slide)

Relaties (1) - typen binaire relaties één op één ( 1 : 1) één op veel ( 1 : N) veel op veel ( N : M) Wat zijn mogelijke sleutels voor de boven staande entiteiten? Primary key (simple en composite), unique key en foreign key

Relaties(5) - zwakke entiteiten Entiteiten waarvan het bestaan afhankelijk is van een andere entiteit (lifetime dependency)

Relaties(4) - recursiviteit relaties tussen entiteiten uit dezelfde entiteitsklasse

Oefening Identificeer het type sleutel voor elk entiteit in het volgend diagram (Barker notatie) a. Primaire sleutel (simple) b. Samengestelde sleutel (composite) c. Samengestelde sleutel van een relatie en een attribuut (composite) Entiteit boat: primary Entiteit racer: composite key Entiteit account: composite (account.number+ company.number ) In Barker notatie een streepje over een relatie betekend dat de id van de identiteit company maakt een deel uit van de primaire sleutel van de entiteit account

normaliseren

Functionele afhankelijkheid(1) Functionele afhankelijkheid = verband tussen attributen Attribuut Y is functioneel afhankelijk van attribuut X als de waarde van X de waarde van Y bepaalt. De waarde wordt verkregen door “opzoeken” in de database. Notatie: Studentnummer  afstudeervak Computernummer  geheugenomvang Determinant Samengestelde determinant Voorbeeld: CIJFERS(Studentnummer,Vak,Cijfer) (Studentnummer,Vak)  Cijfer

Modificatie anomalieën Verwijder anomalie Invoeg anomalie Een update-anomalie is een fout die optreedt bij een afwijking van de 'standaard werkwijze' bij het vernieuwen (updaten) van gegevens in een database. Dit fenomeen treedt op door weinig (lees: onvoldoende) normalisatie. Naast de overkoepelende term update-anomalie worden ook de specifiekere termen invoeg-anomalie en verwijder-anomalie gebruikt voor anomalieën die zich voordoen specifiek bij het invoegen en verwijderen van gegevens. Sporadisch wordt in het Nederlands de term modificatie-anomalie gebruikt. In een genormaliseerd gegevensmodel kunnen de gegevens van één entiteit met één simpele opdracht worden opgeslagen. Soms wordt om technische of praktische redenen een ontwerp gekozen waarbij het invoegen, verwijderen of veranderen van gegevens meer actie vergt om alle gegevens consistent te houden. Een dergelijk model noemt men gedenormaliseerd, het heeft een of meer update-anomalieën.

Kern van normalisatie Databasenormalisatie is een techniek bij het ontwerpen van databases. Ze dient twee doelen: het spaarzaam omgaan met opslagruimte en het vermijden van meervoudige vastlegging van dezelfde data, een potentiele bron van fouten.

Normaalvormen We gaan tot de derde normaalvorm in de praktijk toepassen

Eerste normaalvorm Een tabel die voldoet aan de voorwaarden voor een relatie, is in de eerste normaalvorm. elk attribuut is atomair, en bevat dus één enkele waarde geen enkel attribuut wordt herhaald alle attributen blijven constant in de tijd bijvoorbeeld een adres-attribuut mag geen twee adressen bevatten

Tweede normaalvorm Een relatie is in de tweede normaalvorm als alle attributen die niet in de sleutel zijn opgenomen, afhankelijk zijn van de gehele sleutel.

Derde normaalvorm Een relatie is in de derde normaalvorm als het in de tweede normaalvorm is en geen transitieve afhankelijkheden kent. Transitieve afhankelijkheid

3e normaalvorm (3NF)

Database ontwerp : Hoe doe je het? Ontwerpmethoden: E/R (entity-relationship) semantisch object model Controle: normaliseren

Database ontwerp voorbeeld: administratie van uitgeleende boeken (1) Voor wie? de eigenaar van de boeken Functie : het geven van een actueel overzicht van alle uitgeleende boeken; bovendien per boek: aan wie (het boek is uitgeleend) sinds wanneer (het boek is uitgeleend)

Database ontwerp voorbeeld: administratie van uitgeleende boeken (2) Bedenk eerst …. hoe je het zonder geautomatiseerd systeem zou doen! ?

Database ontwerp voorbeeld: administratie van uitgeleende boeken (3) Bedenk eerst hoe je het zonder geautomatiseerd systeem zou doen! schrift met 1 regel per uitgeleend boek (auteur, titel, lener_naam, lener_telnr, sinds) spreadsheet vgl. database met 1 tabel:‘uitgeleende boeken’

Database ontwerp voorbeeld: administratie van uitgeleende boeken (4) Problemen: wijzigen van telnr op meerdere plaatsen bij terugbrengen boek ook telnr weg Hoe komt dit ? afhankelijkheid : lener_naam -> lener_telnr lener_naam is een determinant van lener_telnr

Database ontwerp voorbeeld: administratie van uitgeleende boeken (5) Oplossing: 2 tabellen schrift met uitgeleende boeken adresboekje (of GSM telefoon): naam + telnr

Normaliseren - recap

Normalisatie: 1NF (first normal form) Definitie 1NF: Een tabel is in 1NF als voor elke waarde van die tabel elke rij precies 1 waarde voor elke attribuut heeft voorbeeld: in de tabel leners heeft elke rij 1 naam en 1 telnr

Normalisatie: 2NF Definitie 2NF: (aanname: er is slechts 1 kandidaat sleutel die de primaire sleutel is) Een tabel is in 2NF als deze in 1NF is, en elk niet-sleutel attribuut (op de een of andere manier) afhankelijk is van de primaire sleutel

Normalisatie: 2NF PK

Normalisatie: 2NF PK PK

Normalisatie: 3NF Definitie 3NF: (aanname: er is slechts 1 kandidaat sleutel die de primaire sleutel is) Een tabel is in 3NF als deze in 2NF is, en elk niet-sleutel attribuut niet-transitief afhankelijk is van de primaire sleutel Vooral aan de orde als de primaire sleutel uit 2 of meer attributen bestaat.

Normalisatie: 3NF PK 2NF 3NF