DATABANKEN Prof. Ir. W. Verschelde Nuttige literatuur: 1. An Introduction to Database Systems C.J. Date Addison-Wesley Publishing Company ISBN 0-201-82458-2 2. Fundamentals of Database Systems Elmasri & Navathe Addison-Wesley ISBN 0-201-54263-3 3. Leerboek Databases: beginselen, ontwerp, implementatie David M. Kroenke Academic Service ISBN 90 395 0902 6
INLEIDING 1. Eerste definitie van “database”: Een bewaarplaats/opslagplaats (Engels: Repository) voor een verzameling gecomputeriseerde datafiles. Er zijn bijgevolg faciliteiten nodig voor: Op file-niveau: adding en removing. Op data-niveau: inserting, retrieving, updating en deleting.
2. Strategie: • •
Modelleren: Door inzicht te krijgen in het model dat de gebruikers hebben van de wereld. Dit resulteert in het gegevensmodel. Het ontwerpen van de relationele database: dus het omzetten in een ontwerp zo dat het een accurate weergave is van het model.
In deze cursus worden enkel de relationele databanken besproken. Een doelstelling is ook noties bij te brengen van SQL (= Structured Query Language), aangezien dit een standaardmiddel is om via een applicatie toegang te krijgen en bewerkingen uit te voeren in een databank. Voorbeelden van applicaties zijn o.a. zoekopdrachten (queries), het maken van overzichten enz…
3. Behandelde thema' s: I. II. III.
IV.
Grondbegrippen Gegevensmodellering (Entiteit/Relatie model) Ontwerp van databanken: - het relationele model - het normalisatieproces Database- implementatie
Noot: multi-user systemen en niet-relationele implemantaties zijn niet de topics van deze cursus.
HOOFDSTUK 1 : ALGEMENE BEGRIPPEN i.v.m. DATABASEVERWERKING 1. (relationele) tabel (file) a. Voorbeeld 1: Gegevens over een wijnkelder Iets waarover men informatie wil opslaan (= a distinguishable object) is een entiteit. De gegevens hebben verwantschap met elkaar, vormen een relatie, en worden in een relationele databank opgeslagen in een tabel. code 1 2 3
wijn Riesling Riesling Bordeaux
producent X Y Z
jaar 2002 2003 2001
aantal flessen 50 100 100
klaar 2003 2005 2006
Een rij van zo'n tabel is een: record of tupel (Engels: tuple). Een kolom van zo'n tabel is een: veld of attribuut. Noot: Data = waarden Informatie = betekenis van de waarden b. Voorbeeld 2 : Klanten - Wijn - Referenties Een vraag die zou kunnen gesteld worden, is de volgende: Welke wijn werd gekocht door welke klant en wie beval hem aan? Later zal blijken dat een goede oplossing zou kunnen bestaan in het creëren van 3 tabellen (via het DBMS, cfr. 1.2). In de rijen van de tabellen zijn gegevens toegevoegd die naar elkaar verwijzen, zodat de tabellen onderling gekoppeld zijn. De kolommen van de tabellen zouden respectievelijk de volgende kunnen zijn: Klanten: klantcode; klantnaam; adres; telefoon; referentiecode Wijn: wijncode; wijnsoort; prijs; klantcode Referenties: referentiecode; naam; adres Noot: Hier werd uitgegaan van het standpunt van een single-user database. Vaak moeten meerdere mensen tegelijk vanuit verschillende computers toegang hebben tot dezelfde databank. Dit kan bijvoorbeeld gebeuren via een LAN. Een probleem dat zich stelt is onder andere: wat als 2 klanten dezelfde fles wijn willen hebben. Het DBMS en de databasetoepassing moeten deze situatie herkennen.
Het kan ook nuttig zijn netwerken te gebruiken voor het opslaan en verwerken van multimedia gegevens (cfr. reclame). Een voorbeeld van een grote databank is deze gebruikt voor de nummerplaten administratie. Er zijn nu zeer veel gebruikers en er is een grote geheugencapaciteit nodig. Hoe is dit oplosbaar? In deze cursus wordt het standpunt van de “gebruiker” ingenomen. De speciale problemen van multi-user databanksystemen zijn voornamelijk gerelateerd met problemen “internal to the system” and dus niet zichtbaar voor de “user”. Daarom zijn ze in eerste instantie niet het interessepunt van deze cursus.
2. Het Data Base Management Svstem. Een database heeft vier componenten: 1. Data: • single-user of multi-user system • “integrated”: een databank is een soort unificatie van verschillende datafiles, waarbij redundantie zoveel mogelijk geëlimineerd wordt. • “shared”: dezelfde informatie kan door meerderen gebruikt worden. 2. Hardware: 3. Software: het DBMS is de software dat alle toegang (access) tot de databank afhandelt. De hoofdfunctie van het DBMS is een user-interface verschaffen tot de databank. (user-interface = a “boundary” below which eveything is invisable to the user) 4. Users: • end-users • applicatieprogrammeurs • database admistrator Appendix: Database-verwerkingssytemen zijn een grote vooruitgang ten opzichte van de vroegere bestandsverwerkingssystemen. Dan werden groepen records in afzonderlijke bestanden opgeslagen. Dit was dus File-processing. De voornaamstebeperkingen vandeze manier van werken waren: • gescheiden en geïsoleerde gegevens (probleem: hoe de twee files combineren?) • gegevens worden vaak gedupliceerd (problemen: opslagcapaciteit en gegevensintegriteit) • applicatieprogramma' s zijn afhankelijk van de gebruikte file-structuur • incompatibele bestanden (bijvoorbeeld: geschreven in een andere taal)
3. Werking van een DBMS a. Database architectuur (ANSI/SPARC): External Level: Van belang voor hoe (een gedeelte van) de data “gezien” worden door de individule gebruikers, er kunnen verschillende external views zijn, naargelang de noden van de gebruikers. Conceptual Level: Beschrijft de structuur van de gehele databank, er zal dus maar één conceptual view zijn, die toont hoe de databank in werkelijk eruit ziet. Internal Level: Beschrijft hoe de data fysisch opgeslagen zijn. Het systeem moet natuurlijk “bewust” gemaakt worden hoe de ene laag correspondeert met de andere. Deze beschrijvingen worden mappings genoemd. Zo zullen er External/Conceptual mappings bestaan tussen de external view en de conceptual view, alsook een Conceptual/ Internal mapping tussen de conceptual en de internal view. Bijvoorbeeld: Klantnummer in de C-taal correspondeert met: • CUSTOMER_NR CHARACTER (6) in de conceptuele view • die op zijn beurt correspondeert met EMP# TYPE = BYTE(6), in de internal view Iedere gebruiker heeft op zijn minst een “taal” ter beschikking (C, COBOL, ..) of “ontwerp gereedschappen” (Access). Deze bevatten een data sublanguage, zijnde een subset van de taal speciaal voor database objecten en bewerkingen. Een “taal” die door bijna alle courante systemen gesupporteerd wordt, is SQL. SQL kan: • interactief gebruikt worden (als een stand-alone query language) • “ingebed” zijn in andere talen als C, COBOL, … Maar ieder “data sublanguage” is alleszins een combinatie van minstens 2 ondergeschikte talen: • DDL: data definition language de definitie/declaratie van data-objects • DML: data manipulation language manipulatie of processing van data-objects Iedere “external view” is gedefinieerd door middel van een “external schema” (= definities van de externe recordtypes). Dit externe schema is geschreven, gebruik makend van het DDL gedeelte van de user's data sublanguage (dat daarom soms external DDL genoemd wordt). Bovendien dient de mapping gedefinieerd worden tussen het external schema en het onderliggende conceptual schema.
De “conceptual view” van het “conceptuallevel” is de voorstelling van de gehele informatieinhoud van de databank. Deze view is gedefinieerd door middel van het “conceptual schema” (= definities van elk van de verschillende records van de databank). Dit wordt geschreven in “conceptual DDL”. Deze DDL definities mogen echter geen beschouwingen insluiten van hoe de data fysisch gestockeerd worden (cfr. data onafhankelijkheid)! Analoge beschouwingen gelden voor de “internallevel”. De “internallevel” is de low-Ievel voorstelling van de gehele databank. De “internal view” is bijgevolg gedefinieerd door het “internal schema”, geschreven in “internal DDL”. Zoals reeds vermeld, definiëren “mappings” de overeenkomsten tussen de respectievelijke levels. Wat is het voordeel daarvan? Welnu, neem als voorbeeld de “conceptual/internal mapping”. Deze specifieert hoe de conceptuele records en velden voorgesteld worden op het “internallevel”. Welnu, als de structuur van de opgeslagen databank verandert, dan moet deze mapping overeenkomstig mee veranderd worden, zo dat het conceptuele schema onveranderd kan blijven!! Met andere woorden, de effecten van zulke veranderingen moeten geïsoleerd worden van het conceptuele niveau, zo dat de “data independence” kan gevrijwaard blijven. Noot: Taak van de database administrator : • Definieert het conceptuele schema: namelijk welke informatie moet gestockeerd worden? Welke zijn de entiteiten? (= logical database design). Hij gebruikt daarvoor de conceptuele DDL. • Bepaalt het “internal schema”, dit wil zeggen de beschrijving van de fysische stockage (= physical database design). • Andere taken zijn onder andere: het opstellen van de “security and integrity rules”, het monitoren van de performantie van de database, wijzigingen aanbrengen naargelang de vraag, ... b. Werking van het DBMS: Zoals reeds gezegd, is het DBMS de software dat alle access tot de databank behandelt: de user verzoekt om access (bijvoorbeeld via SQL): • het DBMS intercepteert dat verzoek en analyseert het • het DBMS onderzoekt het “external schema” voor die user • het DBMS onderzoekt de “external/conceptual” mapping • het DBMS onderzoekt het “conceptual schema” • het DBMS onderzoekt de “conceptual/internal” mapping • het DBMS onderzoekt de “storage-structure” definitie • het DBMS voert de nodige operaties uit op de databank
Functies van het DBMS zijn bijgevolg onder andere: • Het behandelen van de data-definities (external, conceptual, internal schema, mappings) in broncode en deze kunnen omzetten in objectcode, in andere woorden: het DBMS moet “language processor” componenten bevatten van de verschillende DDL-talen en de datadefinities kunnen interpreteren en linken met de onderliggende niveaus. • Data manipulatie: het DBMS moet een verzoek van de user kunnen behandelen, bijvoorbeeld: retrieve, update, delete, add: een DML-processor nodig. • Data security, gegevensintegriteit, data recovery. • Het DBMS moet in een data dictionary functie voorzien, deze bevat “data over de data” = metadata = definities van andere objecten in het databanksysteem. Dit wil zeggen: alle schema's (external, conceptual, internal) en mappings moeten fysisch opgeslagen worden in bron- en objectvorm in die bibliotheek, alsook andere informatie, zoals bijvoorbeeld: welke user heeft welk rapport nodig?
4. Het begrip database a. Wat? Een database is een zichzelf beschrijvende verzameling van geïntegreerde records. •
zichzelfbeschrijvend: dit wil zeggen, het bevat: o gebruikersgegevens o een beschrijving van zijn eigen structuur (data-dictionary) Het belang van die data-dictionary is tweevoudig: o De programma/gegevensonafhankelijkheid wordt erdoor vergroot. “Data independence” is de immuniteit van applicaties voor veranderingen in de manier waarop de gegevens gestockeerd worden en “ge-accessed” worden. Immers, externe documentatie over de bestands- en recordopmaak -zoals bij bestandsverwerkingssytemen- is niet nodig, want de structuur en de inhoud van de databank kan uit de database zelf worden gehaald. o Bij wijziging van de gegevensstructuur in de databank (bijvoorbeeld het toevoegen van nieuwe velden), hoeven deze wijzigingen alleen opgenomen te worden in de datadictionary.
•
Verzameling geïntegreerde records: een databank bestaat niet alleen uit bestanden, maar bevat ook meta-data, indexen, applicatiemeta-data.
Noot: Een databank is een model van een model! Dat wil zeggen, een databank is geen model van de werkelijkheid, maar een model van het gebruikersmodel van de werkelijkheid.
b. Waarom databanken? Een databank verschaft een “gecentraliseerde controle” van de data. De voordelen zijn onder andere: • Redundantie kan gereduceerd worden (in niet-databank systemen heeft iedere applicatie zijn eigen private files); Dit wil echter niet zeggen dat er geen redundantie meer mag zijn. • Bijgevolg kan inconsistentie vermeden worden. • De integriteit kan bewaard worden, dit wil zeggen het verzekeren dat de data in de databank accuraat zijn; dat heeft natuurlijk ook te maken met inconsistentie. Maar ook simpele tikfouten kunnen incorrecte informatie veroorzaken. Bijvoorbeeld: iemand werkt in afdeling "70", terwijl er maar 10 afdelingen zijn. Gecentraliseerde controle kan dit detecteren. • Data kunnen “geshared” worden. • Standardisatie van de gegevens (cfr. gegevensuitwisseling). • Veiligheidsbeperkingen i.v.m. de toegang tot de databank.
5. Historiek & de opgang van het Relationele Model In het begin werd databankverwerking vooral populair in grote bedrijven, cfr. transactieverwerking zoals boekhouden, stockbeheer, bestellingen enz.. Maar al snel werden ook nadelen ontdekt! Databaseverwerking maakt bedrijven ook kwetsbaarder! Maar de ontwikkeling van nieuwe methoden voor het controleren, beveiligen en bewaren van gegevens, bracht grote verbetering. Met de komst van de Pc’s kwamen er ook databanktoepassingen voor persoonlijk gebruik en werden die later in een netwerk verbonden (LAN’s). Nu worden databanken ook frequent gebruikt voor multimedia toepassingen op grote netwerken. Eind de jaren '70 werd een belangrijke stap gezet die tegemoet kwam aan de noden van de gebruikers: de mogelijkheid voor de gebruikers om zelf de data te kunnen benaderen (in plaats van enkel de “programmeurs”) en snel een antwoord te krijgen op hun vragen. Dit werd gerealiseerd door de ontwikkeling van het relationele model. Codd publiceerde in 1970 zijn ideeën en die werden uitgewerkt tot het relationele database model (eind '70, begin '80). Typisch voor dit model : • De data worden door de gebruiker waargenomen als tabellen. • De “operatoren”, ter beschikking van de gebruiker (bijvoorbeeld voor data retrieval) , genereren nieuwe tabellen uit de oude.
6. Enkele beschouwingen over multi-user systemen In 1979 bracht Ashton- Tate dBase II op de markt, een programma voor microcomputers. Dit programma deed vooral aan bestandsbeheer, maar vanaf dBase IV en de daaropvolgende versies zijn het echte relationele DBMS-producten geworden. Ook producten bedoeld voor mainframes werden aangepast voor gebruik op microcomputers, zoals bij voorbeeld: Oracle en Ingres. Later werden nog DBMS'n ontwikkeld voor microcomputers, zoals Paradox. Een belangrijk gevolg van deze evolutie was de enorme verbetering in DBMS-userinterfaces. Denk maar aan Access binnen MS- Windows, met zijn interfaces met grafische schermen. Na 1985, met de komst van de LAN’s, konden computers veel sneller gegevens uitwisselen. Er is een groot verschil van manier van werken ten opzichte van mainframes. Op een mainframe wordt maar 1 centrale processor gebruikt voor de databankverwerking. Op LAN’s kunnen meerdere processors tegelijkertijd bezig zijn met de gegevensverwerking. Om deze toenemende complexiteit te kunnen beheersen alsook om de systeemprestaties te verhogen en de communicatiekosten te verlagen, werd de client/server architectuur ontwikkeld.
7. Client/server architectuur Een client/server systeem bestaat uit een netwerk van computers: Client-computers : bevatten de applicatieprogramma's en voeren de applicaties uit; ze bevatten ook de DBMS-driver, die de aanvragen (bv. in SQL)voor gegevensverwerking van de applicatie ontvangen en doorgeven aan het DBMS, alsook de antwoorden van het DBMS accepteren en omzetten naar een geschikte vorm voor de applicatie. Ze bevatten ook de gebruikersinterface. server(s): bevat het DBMS en de programma's voor bestandsbeheer (m.b.v. besturingssysteemfuncties); hier wordt o.a. ook de “concurrency controle” (controle op gelijktijdige toegang tot gegevens) afgehandeld. Zowel de client-computers als de server bevatten communicatiesoftware om de berichten tussen DBMS-driver en DBMS te kunnen verzenden en ontvangen. Noot: Hier gaan we ervan uit dat -als er meerdere servers zouden zijn- ze onderling onafhankelijke databanken beheren, dit wil zeggen één databank per server. Is dit niet het geval, dan spreken we van een gedistribueerde database.
HOOFDSTUK 2 : HET ENTITEIT-RELATIEMODEL 1. Inleiding Het ontwikkelen van een databasetoepassing begint met het identificeren van de entiteiten, gevolgd door het beschrijven van de structuur en onderlinge relaties van deze entiteiten. Kort samengevat, betekent dit: het creëren van het gebruikersgegevensmodel = gegevensmodellering. Dit gebruikersgegevensmodel zal moeten aangeven wat moet ontwikkeld worden om aa de informatiebehoeften van de gebruikers te voldoen. Twee strategieën kunnen gevolgd worden: • top-down: men begint met het formuleren van een aantal bedrijfsdoelstellingen en vervolgens probeert men vast te stellen welke data en functies men moet hebben om deze doelstellingen te bereiken. Voordeel: de gegevensmodellen worden uitgewerkt vanuit het gezichtspunt van de hele organisatie. Het E/R-model is geschikter voor deze manier van ontwikkelen. • bottom-up : men ontwikkelt eerst een specifiek systeem, en vervolgens gaat men anaylseren om verder het systeem verder op te bouwen. Voordeel: sneller en minder riskant. Het entiteit-relatiemodel: cfr. Peter Chen (1976)
2. Definities • • • •
• • • •
domain: de verzameling van mogelijke scalaire waarden, allemaal van hetzelfde type, die een veld kan aannemen (eigenlijk vergelijkbaar met een data type). entiteit: een onderscheidbaar object uit de werkomgeving van de gebruiker; bijvoorbeeld: leverancier. zwakke entiteit: zwakke entiteiten zijn entiteiten, die voor hun bestaan in de databank (in logische zin) afhankelijk zijn van een andere entiteit, die dan de sterke entiteit is; vb. een medewerker (sterk) en zijn ondergeschikte (zwak). ID-afhankelijke entiteit: is een speciaal geval van zwakke entiteit; het is entiteit waarvan de identifier ook de identifier van een andere entiteit bevat; bijvoorbeeld: gebouw (Gebouwnaam) en zijn ID-afhankelijke entiteit appartement (Gebouwnaam, Appartementnummer). attribuut (eigenschap, Engels: property): beschrijft een kenmerk van de entiteit; bijvoorbeeld: leveranciersnaam. identifier: een of meer attributen van een entiteit, die entiteitsinstanties identificeren. Voorbeelden: leveranciersnaam, leveranciersnummer, …, een identifier kan uniek of nietuniek zijn, leveranciersnaam kan bijvoorbeeld niet-uniek zijn. sleutel: een groep van een of meer attributen die een rij in een tabel uniek identificeren. relatie: een verband tussen entiteiten.
• •
graad van de relatie: duidt aan hoeveel entiteiten in de relatie betrokken zijn. In het E/Rmodel worden bijna alleen binaire relaties gebruikt. subtype: als werknemers een entiteit is, dan kan bijvoorbeeld programmeurs een subtype zijn van het supertype werknemers; alle eigenschappen van werknemers zijn dan ook van toepassing op programmeurs (alhoewel het omgekeerde niet waar is!). Dus, de eigenschappen van het supertype worden "geërfd" (inherited) door het subtype.
3. De 3 soorten binaire relaties: a) De 1:1 relatie (één op één): bijvoorbeeld: KADERLID---1:1---AUTO b) De I:N relatie (één op veel): bijvoorbeeld: HUIS---1:N---BEWONER c) De N:M relatie (veel op veel) bijvoorbeeld: STUDENT---N:M---OPLEIDINGSONDERDEEL
4. E/R-diagrammen: Dit is een techniek om de logische structuur van een databank op een picturale manier voor te stellen. volgens M. Kroenke: • entiteit: door rechthoek • zwakke entiteit: door rechthoek met afgeronde hoeken (ook de bij horende relatie-ruit heeft afgeronde hoeken) • relatie: door een ruit • attribuut: door een ellips Noot 1: cardinaliteit • Maximale Cardinaliteit: het maximum aantal entiteiten (instanties) dat met een andere entiteit kan verbonden zijn (weergegeven in de ruit van de relatie). Meestal is dit 1 of N(M). • Minimale cardinaliteit: geeft het minimaal verplichte aantal verplichte entiteiten aan (meestalOof 1) ; Voorbeeld: KOTHUIS---0---1:N---1---STUDENT Dit wil zeggen: in een kothuis verblijft minimaal 1 student, maar een student hoeft niet in een kot te verblijven. Noot 2: recursieve relaties Relaties tussen entiteiten van dezelfde entiteitsklasse kunnen ook voorkomen! Een werknemer kan in dezelfde werkgroep zitten met andere werknemers.
5. Algemene stappen om te komen tot een gegevensmodel Algemeen beschouwd kunnen vier stappen onderscheiden worden: • identificeer een set van nuttige bruikbare concepten: entiteiten, attributen, identifiers, relaties tussen entiteiten en subtypes. • ontwerp een set van formele objecten (E/R model en E/R diagrammen). • bedenk de formele integriteitsregels. • bedenk de nodige formele operatoren (om stappen 2 en 3 te implementeren; gebaseerd op de relationele algebra). Hier wordt verder gebruik gemaakt van het E/R model. De ontwerp procedure ziet er bijgevolg als volgt uit: • gebruik het entiteit/relatie model om via top-down methodologie de "grote" relaties te ontwerpen, gebruik makend van entiteiten, zwakke entiteiten, enz… • maak van deze “grote” relaties “kleinere” efficiëntere relaties via normalisatie technieken.
HOOFDSTUK 3: NORMALISATIE 1. Definitie normalisatie Normalisatie is een procedure door dewelke een relatie, die bepaalde problemen bevat, kan geconverteerd worden naar 2 of meer relaties die deze problemen niet bevatten. Noot: een bijkomend voordeel is dat via dit proces de wenselijkheid en correctheid van relaties kan beoordeeld worden. E.F. Codd heeft baanbrekend werk op dit gebied verricht. Voor de meer formele behandeling moet verwezen worden naar o.a. het werk van Date.
2. Het relationele model relatie: een 2-dimensionele tabel, waarvan de rijen de gegevens bevatten van een grootheid en de kolommen gegevens over een bepaalde eigenschap van die grootheid; terminologie (cfr. Kroenke): Relationeel model relatie tupel (tuple) of rij attribuut
programmeur bestand record veld
gebruiker tabel rij kolom
Een tabel is pas een relatie als: Date: • there are no duplicate tuples • tuples are unordered, top to bottom • attributes are unordered, left to right • all attribute values are atomic Of nog uitgebreider: • iedere cel van de relatie bevat precies één (enkele) waarde • ieder attribuut heeft een unieke naam • de waarden van het attribuut zijn allemaal van hetzelfde domein • de volgorde van de attributen is niet van belang • ieder tupel is uniek, er zijn geen duplicaten • de volgorde van de tuples is niet van belang
Noot: a) De relatiestructuur, bijvoorbeeld: STUDENT (Naam, Voornaam, Leeftijd, Jaar, Geslacht), kan verschillende instanties hebben, aangezien het verwisselen van rijen of kolommen niets verandert aan de betekenis van de tabel. b) Voor het normalisatieproces zijn 2 begrippen belangrijk: functionele afhankelijkheid (wordt veroorzaakt door een onderling verband tussen attributen) en sleutel (cfr. verbanden tussen attributen in relaties).
3. Functionele afhankelijkheid Een verzameling van attributen Y is functioneel afhankelijk van een verzameling attributen X als en enkel als (voor alle mogelijke geldige waarden in de relatie) iedere X-waarde met juist één Y waarde correspondeert. Notatie: X Y met X = de determinant Merk wel op dat determinant en sleutel niet hetzelfde zijn! Een determinant hoeft niet uniek te zijn. Op te merken valt wel dat als X een kandidaat sleutel is, of een primaire sleutel, dan alle attributen Y functioneel afhankelijk moeten zijn van X. Een functionele afhankelijkheid impliceert dus een N: 1 verband tussen X en Y Een functionele afhankelijkheid kan vastgelegd zijn in een vergelijking: bijvoorbeeld: Totaal = PrijsPerStuk * AantalStukken Er kunnen ook groepen van attributen betrokken zijn: bijvoorbeeld: (SNR, Opleidingsonderdeel) Result Noot: de "closure" (ontsluiting) = voor een verzameling van attributen X bestaat de closure X + uit alle attributen die functioneel bepaald worden door X. Aan de hand hiervan kunnen de supersleutels en sleutels geïdentificeerd worden.
4. Sleutels Sleutel: per definitie heeft iedere relatie minstens één sleutel, dit is : een set van één of meer attributen waardoor een rij in een tabel uniek geïdentificeerd wordt. Supersleutel: een verzameling van attributen ( kan ook één attribuut zijn) die een rij uniek identificeert. Met andere woorden: een verzameling attributen dat minstens één kandidaat sleutel bevat. Het verschil met een sleutel is dat een sleutel minimaal moet zijn. Kandidaat sleutel: als een relatie meer dan I sleutel heeft, wordt iedere sleutel een kandidaat sleutel genoemd. Eén van die sleutels wordt gekozen en wordt aldus de primaire sleutel. Alle andere sleutels worden dan de secundaire sleutels genoemd. Vreemde sleutel: de primaire sleutel van een tabel, die gebruikt wordt in een andere tabel om een verband tussen de tupels van de eerste tabel met die van de tweede te maken. Opmerkingen: • Elke relatie heeft minstens één sleutel, ook al bestaat ze uit alle attributen van die relatie. • De determinant hoeft niet uniek te zijn, een sleutel wel!
5. Integriteit Het relationele model is frequent beschreven, includerend twee integriteitsregels: a) de entiteit integriteit: geen enkele primaire sleutel kan een NULL-waarde hebben (er kan geen informatie opgeslagen worden over iets dat niet kan geïdentificeerd worden) b) de referentie integriteit: een vreemde sleutel van een tabel moet verwijzen naar een primaire sleutel van de in verband gebrachte tabel (een tuple in één relatie die verwijst naar een andere relatie moet verwijzen naar een bestaande tuple in die relatie) Het zou accurater zijn nog een derde eraan toe te voegen: de attribuut integriteit: ieder attribuut moet voldoen aan de beperking dat zijn waarde komt uit een relevant domein.
6. Normalisatie a) Algemene definities: •
•
Een relatie is beschouwd in een bepaalde normaalvorm te zijn als ze voldoet aan een zeker aantal voorgeschreven set van voorwaarden. Naargelang de voorwaarden, spreken we van de eerste normaal vorm 1NF, 2NF, 3NF, de Boyce-Codd normaalvorm, 4NF, 5NF, de DK/NF (= de domein/sleutel normaalvorm). Normalisatie is het proces dat een relatie converteert in een set van relaties in een meer gewenste vorm. Het doel is redundantie en anomalieën te vermijden. De leidraad hierbij is dat een entiteit maar informatie, feiten mag bevatten over één onderwerp: "one fact in one place".
b) Modificatie anomalieën: Verwijderanomalie: wanneer bij het verwijderen van informatie over een bepaald feit er ook informatie over een ander feit verloren gaat. Invoeganomalie: wanneer gegevens over een bepaald feit pas kunnen ingebracht worden als er gegevens zijn over een ander feit.
