Samenvatting Databanken D.E.R.P.

Transcriptie

1 Samenvatting Databanken D.E.R.P. 26 december 2017

2 Inleiding Deze samenvatting is gemaakt voor De Examen Repo Plaats (DERP), een github organisatie die te vinden is op die dergelijke samenvattingen bevat. Het doel van DERP is om een plaats te hebben voor de LATEX broncode van samenvattingen, zodat deze altijd up to date kunnen gehouden worden. Deze specieke samenvatting is te vinden in de releases van ugent.be/derp/databanken. Als je een fout tegenkomt, of bepaalde stukken wilt uitbreiden, kan dat altijd door de repo te forken en een pull request aan te maken met jouw aanpassingen. Na een review kan jouw contributie deel uitmaken van het DERP project en zo toekomstige studentjes uit de nood helpen. Contributors Deze samenvatting is FOSS met dank aan: ˆ Thibault Van Gheluwe ˆ Lorin Werthen-Brabants ˆ Ilion Beyst ˆ Jeroen De Clerck ˆ Maxime Fernández Alonso

3 Hoofdstuk 1 Databases & Databasesystemen 1.1 Wat is het verschil tussen data en informatie? Met data bedoelen we letterlijk `gegeven feiten', zoals `6 Juni 1944', `D-Day', `Normandië', `gealliëerden'. Informatie verwijst naar de samenhang van de data: `Op 6 Juni 1944 zijn de gealliëerden Normandië binnengevallen, deze dag staat bekend als D-Day'. 1.2 Wat is een database? Denitie 1. Een database is een collectie van persistente data. Met persistent bedoelen we een manier van opslaan waardoor de data niet verloren gaat bij het uitschakelen van het systeem (zoals harde schijven, CD's, USB-sticks, etc.). 1.3 Databasesysteem Een computersysteem dat is opgezet voor het beheer van databases noemen we een databasesysteem. In een databasesysteem onderscheiden we 3 hoofdcomponenten: de hardware, de data en de software Hardware De hardware van een databanksysteem is opgebouwd uit 3 eenheden: de CPU, het Primaire Geheugen en het Secundaire Geheugen. CPU De CPU is verantwoordelijk voor het berekenen van software-instructies. Primair Geheugen Het primair geheugen is rechtstreeks aanspreekbaar door de CPU. Het is het snelste geheugen dat het databasesysteem kent, maar ook het duurste. De geheugencapaciteit is ook erg beperkt. Het primaire geheugen bestaat uit 2 delen: 1. Statisch RAM-geheugen: Dit wordt ook wel het cachegeheugen genoemd en wordt hoofdzakelijk gebruikt door de CPU om programma's te versnellen. 2. Dynamisch RAM-geheugen: Dit is het belangrijkste werkgeheugen voor het databasesysteem, daarom wordt het ook wel het hoofdgeheugen genoemd. Het heeft een lagere kostprijs dan het Statisch RAM-geheugen, maar is ook trager. In het primaire geheugen zitten minstens twee databasebuers: Terwijl de ene buer wordt ingelezen of naar wordt weggeschreven kan de CPU de andere buer gebruiken om data te verwerken. Omdat dit soort geheugen maar een tijdelijk karakter heeft, is er nood aan een ander soort geheugen voor de eectieve opslag. Secundair Geheugen Dit is de eigenlijke gegevensdrager. Secundair geheugen is vaak veel goedkoper en heeft een grotere opslagcapaciteit, maar is ook veel trager dan het primair geheugen. Veelgebruikte dragers voor secundair geheugen zijn: 1

4 1. Magneetschijfgeheugen: Dit zijn onder andere harde schijven. Dit is de populairste keuze momenteel. 2. CD-ROM en DVD: Deze worden vaak gebruikt voor databases die enkel geraadpleegd moeten worden. De data is dus statisch. 3. Magneetbandgeheugens: Deze worden vaak gebruikt als archivering en backup opslagmedia, aangezien ze een extreem grote opslagcapaciteit hebben, maar niet herschrijfbaar zijn Data Een database wordt meestal gestructureerd opgeslagen als een collectie van records. Elk record is opgebouwd uit één of meerdere velden die data bevatten. Deze velden zijn vastgelegd in het recordtype en hebben een naam en een datatype. In het secundaire geheugen worden deze records opgeslagen in bestanden. De verzameling van al die bestanden noemen we een database, we zien dit dus als een geïntegreerd geheel Software De belangrijkste software in een databasesysteem is het databasemanagementsysteem. Denitie 2. Een databasemanagementsysteem of DBMS is de softwarecomponent van een databasesysteem die instaat voor het beheer van de database. Voorbeelden hiervan zijn MySQL en PostgreSQL. Het DBMS wordt gebruikt om een abstractielaag tussen de databank en de gebruiker te leggen. Denitie 3. Een datawarehouse is een grote database die bedoelt is voor data-analyse. Denitie 4. Datamining is het proces die tot doel heeft zinvolle verbanden te leggen in de data, die tot dan niet bekend waren. 1.4 Gebruikers Een database wordt vaak gebruikt door meerdere personen, hierin onderscheiden we een paar individuen Data-Administrator De Data-Administrator (DA) is verantwoordelijk voor alle data die de database moet beheren. Hij beslist onder andere welke data, in welk formaat en in welke database dingen moeten opgeslagen worden. Verder legt hij ook de bedrijfsstrategie vast, beslist welke gebruikersproelen er moeten zijn, hoe de beveiliging er moet uitzien enzovoort Database-Administrator De Database-Administrator (DBA) is verantwoordelijk voor het technisch werken en implementeren van de database. Ook het onderhoud, het herstel-na-falen, de consistentie en de controle vallen onder zijn verantwoordelijkheden. Deze taak wordt meestal verdeeld over meerdere personen Toepassingsontwikkelaar De toepassingsontwikkelaar staat in voor de ontwikkeling van de software die het toelaat om voor de gebruiker op een interactieve manier met de data in de database te werken. Hij is dus de schakel tussen de gebruikers en de database. Dit is meestal een grotere groep mensen Eindgebruiker Dit is de persoon die de data zal gebruiken. Hij gebruikt de software ontwikkeld door de toepassingsontwikkelaars. 2

5 1.5 Hoe werkt het databasemanagementsysteem? De belangrijkste taken van een DBMS zijn de denitie, manipulatie en constructie van de databases. Daarnaast kan het DBMS ook functies hebben voor het delen, beveiligen en controleren van data Denitie In de denitie van een database moet de semantiek vastgelegd worden die helpen de integriteit te garanderen, dit wordt gedaan aan de hand van semantische regels. Het moet bijvoorbeeld onmogelijk zijn om, bij een database van personen, een sterfdatum in te geven die voor de geboortedatum ligt Manipulatie Met manipulatie bedoelen we het toevoegen, bewerken, verwijderen of opzoeken van gegevens uit de database. De voorschriften voor de denitie en manipulatie van een databank zijn vastgelegd in een databasemodel. Dit zien we verder Constructie Het DBMS moet ervoor zorgen dat databases op een eciënte manier worden bijgehouden: de toepassingsontwikkelaars zouden zich geen zorgen moeten maken over hoe de data wordt opgeslagen Delen Er moeten meerdere gebruikers op hetzelfde moment aan dezelfde data kunnen. Daarvoor moet het DBMS speciale procedures volgen zodat de gebruikers elkaar niet tegenwerken. Deze procedures wordt later besproken Beveiliging Het DBMS moet de database ook beschermen tegen ongeoorloofd gebruik en tegen het fysiek falen van het systeem. Dit wordt meestal gedaan met een soort authenticatieprocedure waardoor gebruikers toegang kunnen krijgen tot de databank. 1.6 Hoe is een database opgebouwd? Elke hedendaagse database werkt volgens een 3-lagenstructuur: de externe laag, de logische laag en de interne laag Interne laag De interne laag of opslaglaag staat het dichtst bij de fysieke opslag van de database. Hierin worden de databaserecords bijgehouden. Daarbij wordt aandacht besteed aan structuur, manier van opslag en toegangspunten. Hierbij wordt ook rekening gehouden of records een vaste of variabele lengte hebben. Indien records een vaste lengte hebben, kunnen er overows optreden die de database corrupt kunnen maken. Voor een betere en snellere toehankelijkheid voor velden die vaak opgezocht worden, kan een index gecreëerd worden. Dit kan in zijn eenvoudigste vorm gezien worden als een geordende lijst koppels van de vorm <veldwaarde, referentie>. Hierbij is veldwaarde de waarde van het veld uit een record, en referentie een pointer naar de geheugenplaats waar een record met die veldwaarde is opgeslagen Logische laag In de logische of gemeenschappelijke laag werken we met een abstracte voorstelling van de database. Hierdoor worden de fysieke opslagdetails verborgen voor de gebruiker, zodat de aandacht gaat naar de inhoud van de database. De abstracte beschrijving van de database dient te gebeuren volgens de voorschriften van het gebruikte databasemodel, dit noemen we het databaseschema. Dit wordt later verder besproken. 3

6 1.6.3 Externe laag De externe of individuele laag staat het dichtst bij de gebruiker, hier worden zogenaamde views op de database gecreëerd. Een view is een bepaalde kijk op de database die bepaalt hoe de structuur van de data naar de gebruiker toe wordt getoond Mappings Mappings zijn procedures die de drie lagen gebruiken om met elkaar te communiceren. Een voorbeeld van communicatie tussen de logische en externe laag is bijvoorbeeld het converteren van een UNIXtimestamp naar een datum- en tijd-representatie Voordelen van de 3-lagenstructuur Het grote voordeel hier is het feit dat er dataonafhankelijkheid gecreëerd wordt, het is in feite een soort van abstractie. Fysieke dataonafhankelijkheid De interne beschrijving van de data kan gemakkelijk worden aangepast, aangezien alleen de interne laag aan de fysieke data kan. Als men bijvoorbeeld van opslagmedium wil veranderen, moet men alleen de interne laag aanpassen. Logische dataonafhankelijkheid De logische beschrijving van de database kan worden aangepast zonder dat de externe laag moet worden aangepast. Alleen de logische laag moet herschreven worden. De logische beschrijving van de data moet worden aangepast als er bijvoorbeeld nieuwe recordtypes gemaakt zijn, of bestaande recordtypes aangepast moeten worden. Hoofdstuk 2 Datamodellen & databasemodellen Denitie 5. Een datamodel is een verzameling van voorschriften en regels die het mogelijk maken om de structuur en het gedag te beschrijven van data die in bepaalde software voorkomt. Denitie 6. Een databasemodel is een verzameling van voorschriften en regels die het mogelijk maken om zowel de structuur, beperking voor integriteit en beveiliging, als het gedrag van een database te beschrijven op het niveau van de logische laag uit een drielagen-structuur voor databasemanagementsystemen. Denitie 7. Het resultaat van het opbouwen van de structuur, beperkingen en gedrag van een database voor een specieke toepassing, volgens de voorschriften en regels van het databasemodel, noemen we een databaseschema. We onderscheiden drie hoofdcategorieën: operationele modellen, structurele modellen en semantische modellen. 2.1 Operationele modellen Deze modellen zijn ontworpen met oog op eciënte opslag en opzoeken van gegevens ( eciënte operaties). Ze leunen dicht aan bij de primaire en secundaire bestandsorganisatie. De bekendste operationele modellen zijn het hiërarchisch model en het netwerkmodel. 4

7 2.1.1 Hiërarchisch model Het hiërarchisch model organiseert records in boomstructuren. Zie p35 voor een voorbeeld Netwerkmodel Het netwerkmodel is een veralgemening van het het hiërarchisch model: de boomstructuur wordt veralgemeend naar een graafstructuur. Records worden hierbij voorgesteld door knopen, en relaties door lussen. Zie p39 voor een voorbeeld. 2.2 Structurele modellen Bij structurele modellen ligt de nadruk op abstracte datamodellering. Het bekendste structurele model is het relationele model Relationeel model Dit model structureert alle data in tabellen met een vooraf gedeniëerde vorm. Elke kolom van de tabel heeft een unieke naam en een datatype. Deze tabellen worden steeds opgebouwd uit atomaire waarden. Verwantschappen tussen tabellen worden weergegeven met behulp van kandidaatsleutels en vreemde sleutels. Denitie 8. Een kandidaatsleutel is een irreducibele verzameling van kolommen die een rij uniek identiceert. Voor elke tabel dient een kandidaatsleutel gedeniëerd te worden. Door opname van zijn kanditaatsleutel kan dan naar een andere tabel verwezen worden. Deze hierbij toegevoegde kolommen vormen dan een vreemde sleutel. De denitie en manipulatie van een relationele database gebeurt met de standaardtaal SQL (Structured Query Language). 2.3 Semantische modellen Bij semantische modellen ligt de nadruk op het modelleren van de betekenis van data. Voorbeelden hiervan zijn objectgeoriënteerde modellen, objectrelationele modellen en postrelationele of hybride modellen Objectgeoriënteerde modellen Deze databasemodellen werden vooral populair door de opkomst van objectgeoriënteerde programmeertalen zoals Java en C++. Ze ondersteunen het modelleren van complexe objecten. Deze objecten worden voorgesteld door klassen. Relaties modelleren we door methodes te schrijven voor deze klassen. Hierdoor is er ook een overervingssysteem mogelijk. De bekendste objectgeoriënteerde datamanipulatietalen zijn UML (Unied Modelling Language) en OQL (Object Query Language). Dit model wordt in hoofdstuk 7 in detail besproken Objectrelationeel model Dit model is een samenvoeging van het objectgeoriënteerd model en het relationeel model. Het laat toe om objecten, klassen en methodes op te slaan, maar dan in tabelvorm Hybride modellen Bij een hybride model worden in de logische laag meerdere databasemodellen beschouwd. 5

8 2.4 Verdere ontwikkelingen Als gevolg van incompatibiliteiten kan er informatie verloren gaan bij de omzetting van informatie uit een databanksysteem naar een datastructuur in een programmeertaal of vice versa. Men blijft onderzoek doen naar semantisch rijkere databankmodellen om deze zogeheten impedance mismatch weg te werken. Hoofdstuk 3 Conceptueel databaseontwerp Het ontwerpen van een database bestaat uit 4 stappen: 1. Informatievergaring Hier verzamelen we de informatie die we in de database willen stoppen. 2. Conceptueel ontwerp Hier nemen we de vergaarde informatie en zetten die om in een conceptueel model zoals een EERdiagram. 3. Logisch ontwerp Hier zetten we het conceptueel model om in een databasemodel met bijvoorbeeld een relationeel model. 4. Fysiek ontwerp Hier schrijven we de DDL-code voor het maken van de database. 3.1 Informatievergaring In de informatievergaring-stap zijn er drie grote taken: domeinanalyse, functionele analyse en behoefteanalyse. Domeinanalyse Hier bepaalt men hoe breed men wilt gaan bij het verzamelen van informatie. Bijvoorbeeld: Als men personen interviewt, is het nodig om hun geboortejaar of schoenmaat te kennen? Een goede domeinanalyse kan ervoor zorgen dat de data compacter is en geen nutteloze elementen bevat. Functionele Analyse Hier wordt de herkomst van informatie, hoe de informatie werd verwerkt en of daarbij nieuwe informatie aan het licht komt geanalyseerd. Eventuele dubbele of irrelevante elementen kunnen verwijderd worden. Behoefteanalyse Hier wordt gekeken naar de applicaties de database zullen gebruiken. Hebben die applicaties al deze data nodig? Moet er nog meer informatie verzameld worden? Met welke potentiëel nieuwe informatie moet men rekening houden? 3.2 Conceptueel ontwerp Het conceptueel ontwerp kunnen we splitsen in 3 stappen: abstrahering, modellering en implementatie. Abstrahering Het schetsen van een duidelijk beeld van wat belangrijk en wat minder belangrijk is. Hierbij wordt goed gekeken naar de domeinanalyse. 6

9 Modellering Het omzetten van de informatie naar een algemeen diagram. Wij kiezen voor het enhanced entity relationship (EER) diagram. Een alternatief is het UML-klassendiagram. Dit is echter vooral bedoeld voor objectgeoriënteerde softwareontwikkeling. Implementatie Dit gebeurt in een DDL (Data Denition Language), het meest gebruikte voorbeeld hiervan is SQL. Het modelleren en implementeren wordt vaak gedaan met behulp van CASE-tools (Computer Aided System Engineering). Deze tools hebben vaak de functionaliteit om interactief een EER- of relationeel diagram op te stellen, en deze dan om te zetten in DDL-code. 3.3 Het EER-diagram Entiteiten Denitie 9. Een entiteit is een `ding' dat zelfstandig bestaat, het kan attributen hebben en elke entiteit hoort tot een entiteittype. We stellen een entiteittype voor met een rechthoek, zijn attributen worden in ovalen errond gezet en ermee verbonden met een lijn. Denitie 10. Een relatietype is een verwantschap tussen twee of meer entiteitstypes. Deze kunnen ook attributen hebben. We stellen een relatie voor met een ruit, de entiteittypes worden verbonden met lijnen. Denitie 11. Attributen kunnen meerwaardig, afgeleid, samengesteld of sleutelattributen zijn. Meerwaardige attributen bevatten meerdere instanties van het attribuuttype. Afgeleide attributen zijn attributen die bepaald kunnen worden door een functie uit te voeren op andere attributen. Samengestelde attributen zijn opgebouwd door een combinatie van attributen. Sleutelattributen identiceren een relatie of entiteit. Ze zijn uniek en irreducibel. Alle voorgenoemde attributen zijn orthogonaal, dat wil zeggen dat ze op willekeurige manier gecombineerd kunnen worden. 7

10 Denitie 12. Een zwakke entiteit is een entiteit die niet zelfstandig kan bestaan, ze zijn afhankelijk van een andere identicerende entiteit. Hierbij introduceren we ook identicerende relaties, ze stellen de verwantschap tussen het zwakke en het identicerende entiteittype voor. Denitie 13. Kardinaliteitsrestricties zijn restricties op het maximaal aantal entiteiten die mogen voorkomen in de relatie. Denitie 14. Participatierestricties zijn restricties op hoeveel entiteiten van het entiteitstype aan die relatie moeten voldoen. Indien alle entiteiten van dat entiteitstype aan de relatie voldoen spreken we van totale participatie. Anders spreken we van partiële participatie. Totale participatie stellen we voor door een dubbele lijn, partiële door een enkele. De kardinaliteit wordt weergegeven naast de lijnen van de relaties. Vaak wordt er ook gebruik gemaakt van de (min,max)-notatie voor kardinaliteitsrestricties Overerving Denitie 15. Een subtype is een entiteittype dat een subcollectie van entiteiten karakteriseert. Het entiteittype van de collectie waarbinnen deze subcollectie wordt beschouwd, is het supertype. Het subtype erft alle attributen en verwante relatietypes van zijn supertype. De sub/supertype relatie wordt aangeduid met een. De boog is gericht naar het supertype. Het speciëren van subtypes voor een bepaalde entiteit noemen we specialisatie. Het speciëren van supertypes voor een bepaalde entiteit noemen we generalisatie. 8

11 Er zijn ook verschillende soorten overerving: disjuncte, overlappende en geconditioneerde. Disjuncte Dit wilt zeggen dat de subtypes niet overlappen: een Juweel kan geen Wandtapijt zijn. We noteren een `d' in de cirkel van de overerving. Overlappende Dit wilt zeggen dat de subtypes wel kunnen overlappen: een Schilder kan ook Tekenaar zijn. We noteren een `o' in de cirkel van de overerving. Geconditioneerde Een geconditioneerde overerving is eigenlijk een disjuncte of overlappende overerving waarbij het subtype een attribuut van het supertype invult. Elk subtype heeft een andere waarde voor dit attribuut. Het attribuut in kwestie wordt geschreven bij de lijn van het supertype naar de overervingscirkel. De waardes van elk subtype worden geschreven bij de lijn van het subtype naar de overervingscirkel. 9

12 3.3.3 Participatiegraad Een laatste restrictie op overerving is de participatiegraad: zijn alle subtypes deel van dezelfde overervingscirkel. Links is totale participatie, rechts is partiële participatie Categorieën Denitie 16. Een categorie of unietype is een speciaal subtype met verschillende supertypes, dat wordt ingevoerd om de entiteiten van deze supertypes te groeperen. Elke entiteit uit een categorie kan slechts één van de supertypes zijn. We stellen een categorie voor met een in de overervingscirkel. Daarnaast gebruiken we weer een op de lijn, maar deze keer van het supertype naar de subtypes. Categoriën kunnen ook geconditioneerd zijn zoals bij overerving. Hoofdstuk 4 Het relationeel databasemodel 4.1 Basisrelatie Een basisrelatie is een relatie die een verzameling atomaire datatypes met elkaar verbindt op een logische manier. Denitie 17. Een atomair datatype wordt gespeciceerd door een verzameling van toegelaten (atomaire) waarden en een verzameling van operatoren die inwerken op deze (atomaire) waarden. Denitie 18. Het schema R(A 1 : T 1,..., A n : T n ) van een relatie R is opgebouwd uit een relatienaam R en en een eindige verzameling van attributen A 1 : T 1,..., A n : T n. Elk attribuut A i : T i heeft een attribuutnaam (A i ) en een atomair datatype (T i ). Denitie 19. De extentie of corpus van een basisrelatie R met schema R(A 1 : T 1,..., A n : T n ) is een met de tijd variërende verzameling van m n-tuples uit het schema. Elke n-tuple t i = (A 1, w i,1,..., A n, w i,n ) heeft n naam-waardeparen (A i, w i,j ) waarbij w i,j behoort tot het domein van het datatype T i. Denitie 20. Het aantal attributen n uit het schema van een relatie noemen we de graad van de relatie. 10

13 Denitie 21. Het aantal tuples m uit de extentie van een relatie noemen we de kardinaliteit van de relatie. 4.2 Metadata Metadata is data aangemaakt door het DBMS op het moment van de databankcreatie. Dit zijn bijvoorbeeld gebruikers. Alle systeemgedenieerde relaties vormen de catalogus of `data dictionary'. Gebruikers kunnen deze data niet veranderen, alleen raadplegen. Om deze data aan te passen is interventie van de DBA vereist. 4.3 Views Denitie 22. Een view is een benoemde, virtuele relatie die afgeleid is van basisrelaties en/of andere views. Een view wordt bepaald door een deniërende expressie. Het nut van views is divers: ˆ Ze kunnen een extra laag van abstracie vormen. ˆ Ze kunnen gebruikt worden om gebruikers slechts toegang te geven tot bepaalde (eventueel afgeleide) gegevens. In SQL kunnen views als volgt aangemaakt worden: CREATE VIEW <naam> AS <SQL SELECT QUERY> 4.4 Indexen Een index is een gesorteerde verzameling van een of meerdere attributen uit een relatie. In de index worden dan verwijzingen naar de corresponderende tuples opgeslagen. In SQL wordt een index als volgt aangmaakt: CREATE INDEX <naam> ON <relatie> (<attribuut> ASC/DESC) Het indexeren gebeurt dus volledig automatisch door het DBMS en vraagt geen interactie van de gebruiker. Bij het opvragen van tuples met indexen wordt de index automatisch gesubstitueerd met de juiste waarde. Het gebruik van een index maakt het bevragen van een tabel eciënter, maar heeft negatieve gevolgen op de prestatie van het manipuleren van de data: niet enkel de betreende tabel, maar ook de index moeten worden aangepast. Een speciale index is de uniciteitsindex, een index waarin elk tuple slechts eenmaal mag voorkomen (een uniciteitsindex kan dus enkel zinnig gedeniëerd worden voor een kandidaatsleutel). 11

14 4.5 Ontbrekende data Twee hoofdredenen voor het ontbreken van informatie zijn: 1. Onbekende informatie: de gegevens bestaan, maar zijn niet voorhanden. 2. Niet-gedenieerde informatie: de gegevens bestaan niet of zijn niet van toepassing. Ontbrekende data wordt opgeslagen als NULL. INSERT INTO personen (naam,geboren,gestorven) VALUES (John Doe, 1995, NULL) Denitie 23. De wet van uitgesloten derde stelt dat a a en a a Een probleem bij gebruik van NULL-waarden is dat de wet van uitgesloten derde niet geldt. Er kan worden afgeleid dat null null null en null null null. Voorbeeld: Stel men zoekt alle mensen in een tabel die geboren zijn voor 1800, en voegt die samen met al de mensen geboren na Intuïtief zou de resulterende tabel alle resultaten moeten bevatten. Als er echter NULL-waarden bij het geboortejaar zitten, worden deze rijen niet geïncludeerd in de resulterende verzameling. Hier moet door de gebruiker rekening mee gehouden worden. Bij het deniëren van een relatie kan er ook een standaardwaarde opgegeven met de DEFAULT-operator. CREATE TABLE bankaccounts ( naam VARCHAR, saldo INTEGER DEFAULT 0 ) In de praktijk is een standaardwaarde nuttig om het probleem met de wet van uitgesloten derde te vermijden. Echter zijn deze waarden vaak een benadering en kunnen verkeerde resultaten geven bij het aeiden van de data. 4.6 Integriteit Sleutels Verwantschappen tussen relaties worden in het relationeel model weergegeven via sleutels. Er zijn 3 sleutels: kandidaatsleutels, primaire sleutels en vreemde sleutels. Kandidaatsleutels Denitie 24. Als K een deelverzameling is van de verzameling van alle attributen van een gegeven basisrelatie R, dan is K een kandidaatsleutel voor R als en slechts als voldaan is aan: 1. De uniciteiteigenschap: geen enkele legale extentie van R bevat twee tuples met dezelfde waarden voor alle attributen uit K 2. De irreducibiliteitseigenschap: wanneer uit K attributen worden weggelaten, mag niet meer voldaan zijn aan de uniciteiteigenschap. Of simpelweg gezegd, een kandidaatsleutel bepaalt een tuple in de relatie uniek. Primaire sleutels Voor elke relatie moet er precies één primaire sleutel gekozen worden uit de kandidaatsleutels van die relatie. De overige kandidaatsleutels noemt men alternatieve sleutels. Omdat de attributen in de primaire sleutel uniek moeten zijn mogen zij niet NULL zijn. IN SQL wordt de primaire sleutel aangeduid met PRIMARY KEY tijdens de creatie van de tabel. 12

15 Vreemde sleutels Denitie 25. Een vreemde sleutel F van een basisrelatie R 2 is een verzameling van attributen van R 2 waarvoor het volgende geldt: 1. Er bestaat een basisrelatie R 1 (R 1 niet noodzakelijk verschillend van R 2 ) met een kandidaatsleutel K, die evenveel attributen bevat als F en waarbij er een één-op-ééncorrespondentie is tussen de attributen van K en de attributen van F, zodat corresponderende attributen dezelfde geassocieerde datatypes hebben. 2. Op elk tijdstip komt elke reguliere waarde van F in R 2 eveneens voor als waarde van K in een tuple van R 1. Een vreemde sleutel is een attribuut dat verwijst naar een kandidaatsleutel van een andere relatie. In SQL duiden we dit aan met FOREIGN KEY. CREATE TABLE schilderij_tabel ( naam VARCHAR, FOREIGN KEY (schilder) REFERENCES schilder_tabel(naam) ) De meeste databasesystemen staan het niet toe om binnen de specicatie van een vreemde sleutel de verwijzen naar een relatie die nog niet is aangemaakt. Soms komt het voor dat de volgorde van aanmaak van relaties geen oplossing biedt voor het probleem van onbekende relatiename. Dit is het geval bij cyclische referenties wanneer er bijvoorbeeld in R 1 een vreemde sleutel staat die verwijst naar R 2 en er in R 2 een vreemde sleutel staat die verwijst naar R 1. In dat geval kan een van de vreemde sleutels pas worden toegevoegd bij een latere aanpassing van de specicatie van R 1, met de SQL-instructie 'ALTER TABLE'. Het kan gebeuren dat een vreemde sleutel betrekking heeft op een kandidaatsleutel van dezelfde relatie. In dat geval spreekt men van zelfreferentie Integriteitsrestricties Denitie 26. Een integriteitsrestrictie is een voorwaarde waaraan alle data uit de relatie op elk moment moet voldoen. Ze is ofwel een toestands- of transitierestrictie. In SQL wordt een integriteitsrestrictie aangemaakt met CREATE ASSERTION. Denitie 27. Een toestandsrestrictie waakt over de correctheid van de databank, ze wordt uitgevoerd bij elke toevoeging, aanpassing of verwijdering van data. Voorbeeld: de geboortedatum van een persoon mag niet later vallen dan zijn sterfdatum. Denitie 28. Een transitierestrictie waakt over de integriteit bij de overgang van een oude toestand naar een nieuwe toestand. Voorbeeld: controle of het loon van een werknemer niet afgenomen is, controle of de burgelijke stand van een persoon wel correct is aangepast (bijvoorbeeld niet is gewijzigd van `ongehuwd' naar `gescheiden'). Denitie 29. De referentiële integriteitsrestrictie is een toestandsrestrictie die de integriteit van de vreemde sleutels behoudt bij het verwijderen van data. Voorbeeld: na het betalen van alle werknemers moet de tabel onbetaalde_werknemers leeg zijn en de grootte van de tabel betaalde_werknemers gelijk aan het aantal werknemers Stored Procedures & Triggers Denitie 30. Een stored procedure is een voorgecompileerde groep bewerkingen, geschreven in SQL/PSM (SQL Persistant Storage Module). Deze bewerkingen voeren een actie uit op de databank, of op de data van de databank. Eventueel wordt er een resultaat terug gegeven. IN SQL wordt een procedure gemaakt met CREATE PROCEDURE. Variabelen gaan voor met en het keyword OUTPUT bepaalt dat de procedure deze waarde zal teruggeven. 13

16 CREATE PROCEDURE INTEGER OUTPUT AS BEGIN = Manager FROM HumanResources.Employee WHERE Employee END Denitie 31. Een trigger is een stored procedure die automatisch wordt uitgevoerd wanneer een bepaalde gebeurtenis voldoet aan een bepaalde conditie. De conditie is optioneel. In SQL wordt een trigger gemaakt met CREATE TRIGGER CREATE TRIGGER employeebackuptrigger ON employees AFTER INSERT AS BEGIN INSERT INTO employees_backup (SELECT * FROM INSERTED) END 4.7 Relationele algebra De relationele algebra bestaat uit acht basisoperatoren: ˆ De aangepaste versies van de traditionele verzamelingoperatoren vereniging (unie), doorsnede (intersectie), verschil en cartesiaans product. ˆ De speciale relationele operatoren selectie, projectie, join en deling Vereniging De vereniging is analoog aan de unie uit de verzamelingenleer, met de bijkomende restrictie dat bij een vereniging R 1 UNION R 2 alle tuples ofwel voorkomen in R 1, ofwel voorkomen in R 2, ofwel voorkomen in beide Doorsnede De doorsnede is analoog aan de doorsnede uit de verzamelingenleer, waarbij in doorsnede R 1 INTER- SECT R 2 alle tuples van R 1 voorkomen in R Verschil Het verschil is analoog aan het verschil uit de verzamelingenleer, waarbij in verschil R 1 MINUS R 2 alle tuples van R 1 niet voorkomen in R Cartesiaans product Het cartesiaans product R 1 TIMES R 2 geeft de verzameling weer waarbij elke combinatie van tuples uit R 1 met tuples uit R 2 aanwezig zijn Selectieoperator De selectieoperator, ook restrictieoperator genoemd, gebruiken we om tuples te selecteren uit een relatie R die voldoen aan logische expressie e. We noteren dit met R WHERE e. 14

17 4.7.6 Projectieoperator Als R een relatie is en {A 1 : T 1, A 2 : T 2,..., A p : T p } een deelverzameling is van de attributen van R dan resulteert de projectie R{A 1, A 2,..., A p } in een nieuwe relatie met enkel de attributen van de tuples in de relatie Joinoperator Het samenvoegen van resultaten met andere resultaten (horizontaal) noemen we joinen. Hiervoor zijn een aantal varianten beschikbaar. In SQL doet men dit via SELECT * FROM <tabel1> <joinoperator> <tabel2> ON <conditie> INNER JOIN Dit is de meest natuurlijke join, hij combineert tuples uit de eerste relatie met tuples uit de tweede relatie en plakt ze aan elkaar (horizontaal). In SQL is dit de INNER JOIN of gewoon JOIN operator. Elke rij in de eerste tabel wordt gematcht aan een rij in de tweede tabel, indien er geen matchende rij is in de tweede tabel wordt de rij niet opgenomen in het resultaat. OUTER JOIN Deze soort join is een uitbreiding van de normale join met de uitzondering dat als er rijen zijn van de eerste tabel die geen matches hebben in de rijen van de tweede tabel, dan worden de waarden van de kolommen van de tweede tabel op NULL gezet. Dit gedrag kan omgewisseld worden (rijen van de eerste tabel niet gevonden voor rijen van de tweede tabel) door het keyword RIGHT te gebruiken. Een duidelijke guur staat in het boek op p132. DIVIDE BY-join Dit is eigenlijk een omgekeerde join, het verwijdert alle rijen van de eerste tabel die niet gevonden worden in de tweede tabel, en verwijdert dan alle kolommen van de eerste tabel die ook in de tweede tabel zitten. Een duidelijke guur staat in het boek op p Het gesloten zijn en nut van de relationele algebra Elke operator van de relationele algebra werkt in op één of twee relaties en resulteert in een nieuwe relatie. Deze eigenschap noemen we het gesloten zijn van de relationele algebra en maakt dat het mogelijk is om expressies op te bouwen waarin meerdere operatoren samengesteld worden toegepast. Hoofdstuk 5 Logisch databaseontwerp Bij het logisch databaseontwerp kiezen we een databasemodel. Als er gewerkt wordt met EERmodellering, moeten we het EER-diagram dat resulteert uit de conceptuele ontwerpfase omzetten naar een databaseschema dat is opgebouwd volgens de voorschriften van het gekozen databasemodel. Daartoe gebruiken we een omzettingsalgoritme. Het proces van logisch databaseontwerp noemen we ook `forward engineering'. Ook voor de inverse omzetting, van een databaseschema naar een EER-diagram, bestaan er algoritmes. Deze zijn belangrijk bij `reverse engineering': ze stellen je in staat om het EER-diagram te actualiseren na aanpassing van het databaseschema. 15

18 Nadat het databaseschema is gamaakt, moeten we de functionele beschrijvingen nog omzetten naar gedragspecicaties. Zo zetten we een functionele beschrijving soms om naar een alternatieve sleutel (afdwingen van uniciteit), een integriteitsrestrictie (implementatie van een beperking), een stored procedure of een trigger (implementatie van een `business rule). CASE-tools kunnen ook op dit vlak ondersteuning bieden. Een normaalvorm kan je zien als een kwaliteitsnorm voor basisrelaties: hoe hoger de normaalvorm van de relatie, hoe minder conicten men kan hebben met die relatie. Het verhogen van de normaalvorm heet het normalisatieproces; een basisrelatie met een lagere normaalvorm wordt opgesplitst en omgezet naar verschillende relaties die allemaal een hogere normaalvorm hebben. Normalisatie kan overtollige data en anomalieën wegwerken en gegevensverlies tegengaan. Denitie 32. Een verzameling van attributen Y is functioneel afhankelijk van een verzameling van attributen X als de waarden van de attributen van Y op elk moment uniek zijn vastgelegd door de waarden van de attributen in X. X wordt de determinant van de functionele afhankelijkheid genoemd. Denitie 33. Y is irreducibel functioneel afhankelijk van X (genoteerd: X Y ) als Y functioneel afhankelijk is van X en 1. X en Y zijn disjunct 2. Er is geen deelverzameling X X zodat Y functioneel afhankelijk is van X 5.1 Eerste normaalvorm (1NF) Denitie 34. Een relatie staat in 1NF als de datatypes van al zijn attributen atomair zijn. Bijvoorbeeld: Een artiest die een array van verblijfplaatsen heeft staat niet in 1NF (een array is niet atomair). Dit moet opgesplitst worden in een tabel met artiesten en een tabel die artiesten linkt aan verblijfplaatsen. 5.2 Tweede normaalvorm (2NF) Denitie 35. Een relatie staat in 2NF als ze in 1NF staat, en elk attribuut (dat geen deel uitmaakt van een kandidaatsleutel) irreducibel functioneel afhankelijk is van elke kandidaatsleutel. Bijvoorbeeld: Een schilderij dat de naam, het geboortejaar en het sterftejaar van zijn schilder bijhoudt staat niet in 2NF. Dit moet opgesplitst worden in een schilderij-tabel een een artiest-tabel. 5.3 Derde normaalvorm (3NF) Denitie 36. Een irreducibele functionele afhankelijkheid X Z is transitief als er een verzameling Y bestaat (die geen kandidaatsleutel of deelverzameling van een kandidaatsleutel is) waarvoor geldt dat X Y en Y Z. Denitie 37. Een relatie staat in 3NF als ze in 2NF staat, en elk attribuut van de relatie (dat geen deel uitmaakt van een kandidaatsleutel) niet transitief irreducibel functioneel afhankelijk is van een kandidaatsleutel. 16

19 Bijvoorbeeld: Een adres slaat de provincie en het land op, dit staat niet in 3NF (adres_id provincie land). Dit moet verandert worden naar een adres-tabel dat een vreemde sleutel heeft naar een provincie-tabel. 5.4 Boyce-Codd normaalvorm (BCNF) Denitie 38. Een relatie staat in BCNF als ze in 1NF staat, en elke determinant een kandidaatsleutel is. Een simpele redenering is dat een relatie niet in BCNF staat als er overlapping is in alle mogelijke primaire sleutels. Bijvoorbeeld: Een adres slaat zowel de gemeente als de postcode op. Dit staat niet in BCNF, aangezien postcode gemeente en vice versa. Dit moet opgesplitst worden, of één van de twee attributen moet worden verwijderd. 5.5 Vierde normaalvorm (4NF) Denitie 39. Y is meerwaardig functioneel afhankelijk van X (genoteerd als X Y ) als de attributen van X op elk moment een collectie met meerdere waarden voor de attributen van Y vastleggen. Denitie 40. Een relatie staat in 4NF als ze in BCNF staat en geen enkele meerwaardige functionele afhankelijkheid bevat. Bijvoorbeeld: Een tabel die een schilderij_id, het thema en de kleuren bijhoudt. Er wordt verondersteld dat een schilderij maar 1 thema heeft, maar meerdere kleuren bevat. Dit staat niet in 4NF (thema is meerwaardig functioneel afhankelijk). Dit wordt opgelost door een tabel met kleuren en een tabel met thema's te maken. 17

20 Hoofdstuk 6 Relationele databases: fysiek databaseontwerp en SQL Bij het fysieke ontwerp van een relationele database moeten het databaseschema, de (alternatieve) sleutels, de integriteitrestricties, de stored procedures en de triggers, die resulteren uit het logisch databaseontwerp, worden geïmplementeerd in een gekozen relationeel dbms. Alle SQL-instructies worden verwerkt, gevalideerd en geoptimaliseerd. We zullen hier niet alle SQL-commando's oplijsten, aangezien dit in de oefeningen behandeld is. 6.1 Verwerking van DML-instucties Het DBMS gebruikt een 3-delig stappenplan om binnenkomende DML-queries uit te voeren: 1. SQL-validatie 2. SQL-optimalisatie 3. SQL-uitvoering SQL-validatie Bij de validatie wordt de binnenkomende DML instructie gescand op fouten: Er wordt gecontroleerd op syntaxfouten, gecheckt dat alle vernoemde elementen wel bestaan,... Tijdens die controle wordt de DML instructie omgezet naar een interne representatie (meer speciek een relationele expressie) die een eciënte optimalisatie toelaat. Dit wordt gedaan zodat de DML abstracter kan zijn, en daardoor beter begrijpbaar door de gebruiker SQL-optimalisatie In deze stap zal het DBMS proberen om de relationele expressie om te zetten naar een equivalente expressie (die dus identieke resultaten garandeert), maar eciënter is om uit te voeren. Eenmaal die equivalente expressie gevonden is wordt een zogenaamd queryplan opgesteld. In het queryplan wordt vastgelegd hoe de expressie werkelijk uitgevoerd moet worden. Optimalisatie wordt in de praktijk niet sterk doorgedreven, omdat het zoeken naar een eciënt queryplan vaak langer duurt dan de oneciënte expressie uit te voeren SQL-uitvoering Hier wordt het queryplan van de vorige stap uitgevoerd. Dit is de stap waar de query in contact komt met de echte data. 6.2 Query-By-Example Bij deze techniek worden de DML-instructies opgebouwd door het invullen van grasche templates die de structuur weergeven van de relaties uit de database. Een voordeel hiervan is dat er geen programmeertaal gekend moet zijn het volstaat de codes, namen en condities in te vullen. Een nadeel van dit systeem is dat het moeilijk te koppelen is aan in huis ontwikkelde programmacode en dat niet alle SQL-queries zonder problemen kunnen worden omgezet naar QBE-specicaties. QBE is hierom niet relationeel compleet. 18

21 Hoofdstuk 7 Objecttechnologie in databases Door het gebruik van objectgeoriënteerde programmeertalen ontstond de behoefte aan een techniek om objecten persistent te maken. Denitie 41. Objecten zijn datatypes met een complexe waarde, dit wordt de toestand van het object genoemd. Objecten worden opgebouwd uit objecttypes, waarin de datastructuur als de specieke operaties voor het object bepaald zijn. Die operaties noemt met het gebruikersgedenieerde gedrag. Denitie 42. Een operator bestaat uit een signatuur en een methode. De signatuur zijn de uiterlijke kenmerken: de naam, de argumenten... De methode of corpus is de innerlijke implementatie. Het verbergen van de methode naar de buitenwereld wordt inkapseling genoemd. Inkapseling wordt gebruikt om gebruikers af te schermen van implementatiedetails. Sommige omgevingen vereisen dat alle aanpassingen aan het object via operatoren moeten gebeuren. Dit heet volledige inkapseling. Denitie 43. Overerving is het concept waar de toestand en het gedrag van een objecttype (gedeeltelijk of volledig) bepaald wordt door zijn supertype. Denitie 44. Het herdeniëren van operatoren van het supertype noemt men operatoroverloading. Om een object persistent te maken moet het opgeslagen worden in het permanent computergeheugen. Dit wordt doorgaans gedaan met combinatie van het naamgevings- en bereikbaarheidsmechanisme. Denitie 45. Het naamgevingsmechanisme houdt in dat een object persistent kan gemaakt worden door het een unieke, persistente naam te geven. Denitie 46. Het bereikbaarheidsmechanisme houdt in dat elk object dat voorkomt in een persistent object, ook persistent gemaakt wordt. In relationele databases zullen objecten geïdenticeerd worden door een unieke objectidenticator (OID). Deze wordt aangemaakt door het DBMS en kan niet gewijzigd worden. 7.1 Het ODMG-model Het ODMG-model (Object Database Management Group) is de voorgestelde standaard voor objectgeoriënteerde databanken. De belangerijkste componenten zijn het objectmodel, de objectdenitietaal (ODL) en de objectbevragingstaal (OQL) Objectmodel Het objectmodel bij ODMG steunt op het principe dat alle objecttypes door de gebruiker zijn aangemaakt, en gebouwd zijn uit een aantal bouwstenen (literaaltype's, interface's of klassen). Literaaltype Een literaaltype is de bouwsteen die gebruikt wordt voor het modelleren van structurele kenmerken. Er zijn drie categorieën: basistypes, gestructureerde types en collectietypes. ˆ Basistypes kunnen vergeleken worden met atomaire datatypes uit het relationeel databasemodel. Daarnaast kunnen er ook enumeratietypes zijn. ˆ Gestructureerde types zijn types die uit een aantal componenten zijn samengesteld, deze componenten zijn op zich weer literaaltypes of klassen. ˆ Collectietypes worden gebruikt om datacollecties weer te geven. De belangrijkste soorten zijn set, bag, list en array. sets en bags zijn ongeordende collecties, array en list zijn geordend. In een set mag elk element maar eenmaal voorkomen. lists en arrays mogen dubbele elementen hebben. Een list heeft geen voorbepaalde grootte, een array wel. 19

22 Interfaces Interfaces zijn bouwstenen die we gebruiken voor het modelleren van gedrag. opgebouwd uit operatoren. Meestal wordt deze Klassen De structurele- en gedragskenmerken van een objecttype worden vastgelegd in een klasse. Deze kunnen een aantal attributen hebben, die literaaltypes of klassen moeten zijn. Met het objectmodel kunnen enkel binaire verwantschappen tussen klassen worden gemodelleerd. Dit kan op twee manieren: unidirectioneel en bi-directioneel. Bij de uni-directionele werkwijze wordt de gerelateerde klasse opgenomen als type van het attribuut. Bij de bi-directionele werkwijze worden twee relaties gebruikt: één in elk van de betrokken klassen. Beide relaties fungeren als inverse van elkaar. Elke relatie heeft een naam, een verwijzing naar de gerelateerde klasse en een verwijzing naar zijn inverse. Enkel bij de bi-directionele werkwijze vindt de controle van referentiële integriteit plaats. Overerving Er zijn twee soorten overerving: `isa'-overerving en `extends'-overerving. `isa'-overerving het supertype is een interface en het subtype een klasse of interface. Meervoudige overerving is toegestaan, maar verbiedt operatoroverloading. `extends'-overerving Zowel het super- als subtype zijn klassen. Het subtype erft alle attributen, relaties en operatoren van het supertype. Meervoudige overerving is niet toegestaan, maar operatoroverloading wel. Instanties van objecten & literalen Bij elk literaaltype en objecttype hoort een domein, dit is de verzameling van alle toegestane waarden voor dat type. Deze waarden noemen wij instanties. De instanties van een literaaltype noemen we literalen, analoog voor het objecttype en objecten. Interfaces hebben geen instanties. Het ODMG-model schrijft voor dat alleen objecten kunnen persistent gemaakt worden. Hierbij worden alle (eventueel overgeërfde) attributen en relaties opgeslagen. Ze worden gekenmerkt door een objectidenticator, deze is uniek over de hele database en wordt door het DBMS toegekend en bijgehouden. Een gebruiker kan één of meerdere objectnamen toekennen aan een persistent object, deze moeten ook uniek zijn over de volledige database en worden in OQL gebruikt als toegangspunt. Extenties en sleutels Een databaseontwerper kan kiezen om voor een bepaald objecttype alle persistente objecten op te slaan in een verzameling, dit noemt men de extentie van dat objecttype. Hierbij kunnen sleutels worden vastgelegd. Een sleutel bestaat uit één of meerdere attributen en/of relaties waarvan de waarden uniek moeten zijn voor elk object in de instantie Objectdenitietaal De objectdenitietaal (ODL) is een programmeertaalonafhankelijke specicatietaal die het mogelijk maakt om logische databaseschemas te beschrijven die zijn opgebouwd volgens de voorschriften van het ODMG-objectmodel. Een voorbeeld van een ODL schema kan gevonden worden in het boek op pagina Objectbevragingstaal Het ODMG-model beschikt niet over een programmeertaalonafhankelijke objectmanipulatietaal, deze zijn geïntegreerd in de programmeertaal van de software die de database gebruikt. Om een attribuut aan te passen in de database, moet enkel het attribuut gewijzigd worden met behulp van de programmeertaal. Dit is volledig naadloos geïntegreerd. 20

23 Het ODMG-model beschikt wel over een programmeertaalonafhankelijke objectbevragingstaal (OQL). Net zoals SQL is OQL een beschrijvende taal die ook gebaseerd is op een `SELECT-FROM- WHERE-GROUP BY-HAVING-ORDER BY' structuur, maar die veel exibeler is op het vlak van zoekmogelijkheden en weergave van de resultaten. De inter-objectrelaties zorgen voor ingewikkeldere mogelijkheden bij het opzoeken van data. Toegangspunten Voor elke query is een toegangspunt tot de database vereist, dit kunnen persistente object-namen zijn of extentienamen. Iterators Een iteratorvariabele maakt het mogelijk om alle elementen in de collectie te doorlopen. Extra functies Net zoals in SQL zijn er ook aggregatieoperatoren (MIN, MAX, AVG... ). Er zijn een paar extra functies toegevoegd om te werken met collecties: rst, last... Het `GROUP BY' sleutelwoord is vervangen door `PARTITION'. 7.2 SQL3 De nieuwste SQL standaard is SQL3, hierin hebben ook relationele databases faciliteiten voor objectoriëntatie gekregen. Het relationeel model wordt uitgebreid met het objectrelationeel model en is daarom nog altijd gebaseerd op het concept relatie Gebruikersgedenieerde datatypes SQL3 kent twee typeconstructoren voor gebruikersgedenieerde datatypes: row en array. 1. `row' gebruiken we voor het aanmaken van gestructureerde tupletypes. Hierin kunnen een aantal attributen worden opgeslagen. Deze typeconstructor lijkt het meeste op de objecten van een objectgëorienteerde programmeertaal. 2. `array' gebruiken we voor het aanmaken van collectietypes van het rijtype. Hierin ligt een beperking dat het type in een rijtype geen rijtype mag zijn, geneste rijtypes zijn niet toegestaan Tuple identiteiten Een tuple-identicator is een unieke referentie naar een tuple. Er zijn twee mogelijkheden om deze identicator te maken: het kan afgeleid worden uit de primaire sleutel van die tuple of het kan door het DBMS opgebouwd worden. In SQL wordt dit genoteerd als REF IS identificatornaam {DERIVED SYSTEM GENERATED} Operatoren Operatoren worden gedeniëerd als methodes in SQL3. De syntax is METHOD operatornaam (argumentenlijst) RETURNS type. Elke operatorsignatuur moet gekoppeld worden aan een implementatiecode, deze kan in SQL worden geimplementeerd, maar ook in een externe programmeertaal. Dit wordt aangeduid met EXTERNAL NAME extern_bestand LANGUAGE programeertaal_naam Overerving In SQL3 wordt overerving aangeduid met het sleutelwoord UNDER. Het nieuwe tupletype zal alle componenten en operatoren van al zijn supertypes overerven. Als de supertypes een operator/attribuut met dezelfde naam hebben zal het subtype de operator/het attribuut van de eerste supertype in de lijst krijgen. 21

24 7.2.5 Multimedia SQL3 geeft de mogelijkheid om multimediaobjecten voor te stellen. Dit wordt gedaan aan de hand van het `blob' datatype (binary large object). Dit is een datatype dat een grote bitsequentie voorstelt. Zo'n `blob' kan dan bijvoorbeeld een video-, audio- of afbeeldingbestand zijn. Ook werd een `clob' (character large object) ingevoerd. Dit gebruiken we voor het weergeven van grote karaktersequenties, die samen een tekst vormen. 7.3 Objectrelationele mapping Er bestaat specieke software voor het omzetten van objecttypes, die geschreven zijn met een objectgeoriënteerde programmeertaal zoals C++ of Java, naar een relationeel databaseschema. Deze omzetting wordt objectrelationele mapping genoemd. Hoofdstuk 8 Toegangsmogelijkheden voor applicaties 8.1 API's Een API voor databasetoegang zorgt voor de verbinding of interface tussen de applicatie en het dbms. De API wordt door de applicatie gebruikt om instructies door te geven aan het dbms en wordt omgekeerd door het dbms gebruikt om resultaten en status- en foutcodes door te geven aan de applicatie Databasetoegang via ingebouwde API's Bij een ingebouwde API worden de instructies voor databasetoegang integraal ingebouwd in de applicatiecode. De uitvoering van de `verrijkte' applicatiecode bewerkstelligt de interactie 8.2 Embedded SQL Embedded SQL stelt je in staat om SQL-instructies via een specieke taalconstructie in te bouwen in de programmacode. Deze code wordt eerst voorverwerkt door een precompiler, die de Embedded SQL code omzet naar een intern formaat dat uitvoerbaar is door het DBMS. Embedded SQL heeft als nadeel dat het databasespeciek is, waardoor een applicatie steeds moet aangepast zijn aan de API van de databaseconstructeur. Deze ingebedde SQL instructies worden voorafgegaan door de sleutelwoorden EXEC SQL en beëindigd met ; of END-EXEC. De datauitwisseling gebeurd via hostvariabelen, dit zijn variabelen uit de programmeertaal. Embedded SQL kan deze datacontainers lezen als ze tussen een EXEC SQL BEGIN DECLARE SECTION en EXEC SQL END DECLARE SECTION blok zitten. De naam van een hostvariabele wordt voorafgegaan door een `:'. Er wordt ook teruggegeven of de SQL instructie gelukt is: een waarde van 0 duid een succesvolle uitvoering aan, een positieve waarde wilt zeggen dat er geen resultaten gevonden werden een een negatieve waarde duidt op een fout bij uitvoering. Een voorbeeld van Embedded SQL kan gevonden worden in het boek p253. Om de resultaten van een query te overlopen voorzien Embedded SQL de cursor. Dit is een soort iteratorconstructie. De syntax is EXEC SQL OPEN cursornaam, gevolgd door EXEC SQL FETCH cursornaam INTO: hostvariabelen en beëindigd door EXEC SQL CLOSE cursornaam. Het precompileren van Embedded SQL noemen we statische SQL. Indien de programmeur een exibelere foutcontrole vereist, wordt de Embedded SQL niet gecompileerd maar uitgevoerd `at runtime'. Dit noemt men late binding. 22

25 8.3 SQLJ Dit is de tegenganger van Embedded SQL, speciek ontwikkeld voor Java. SQLJ ondersteunt alleen statische SQL. Je kan SQLJ niet gebruiken zonder JDBC. 8.4 Call-level API Een call-level API scheidt de databasetoegang vie aparte software die de tussenpersoon tussen de applicatie en het DBMS speelt. Dit heeft als voordeel dat het principe van late binding wordt toegepast zodat de applicatie dynamischer kan werken. Het nadeel is dat de code, elke keer dat de applicatie uitgevoerd wordt, opnieuw moet uitgevoerd worden (wat vertragingen met zich meebrengt). We bespreken hier kort de volgende 5 call-level API's: ODBC, JDBC, SQL/CLI, OLE DB en ADO ODBC en JDBC De standaard ODBC (Open Database Connectivity) stelt je in staat om de database op een DBMSonafhankelijke manier te benaderen. Hiervoor gebruikt hij een combinatie van applicatie-interfaces, driverbeheerders en ODBC-drivers. Een applicatie kan een data-aanvraag doen via de applicatie-interface. Deze zal dan de driverbeheerder aanspreken. De driver zorgt voor de communicatie met het DBMS, de driverbeheerder bepaalt welke driver noodzakelijk is. JDBC is de opvolger van ODBC, speciek voor Java. De foutbehandeling van ODBC wordt omgezet naar Java-exceptions SQL/CLI De SQL/CLI (SQL Call Level Interface) is een deel van de SQL standaard en dus bedoeld voor toegang tot relationele databases. Deze lijkt erg op ODBC. Om een database toegankelijk te maken moeten we een `enviroment' en `connection' record aanmaken, hierna moet een `statement' record gemaakt worden met de specieke SQL instructie. Eventuele parameters kunnen aangeduid worden met een `?' OLE DB en ADO Niet alle databases zijn SQL. Er zijn ook XML-bestanden, pure tekstbestanden,... Het OLE DB (Object Linking and Embedding for Databases) werd ontwikkeld door Microsift om dergerlijke databronnen op uniforme wijze te kunnen benaderen. Ze neemt het concept van ODBC over, maar in plaats van met drivers te werken werkt OLE DB met COM-objecten, deze hebben elk hun functionaliteit en zijn afgestemd op de karakteristieken van de databron. Voorbeelden van zo COM-objecten zijn: ˆ data-providers: dit COM-object is een interface die communiceert met de databron. gebruikt door de data-consumer (de applicatie). Ze wordt ˆ service-providers: deze COM-objecten bieden een bepaalde dienst aan, waardoor de functionaliteit uitgebreid wordt. Al deze COM-objecten communiceren met elkaar via interfaces. Omdat OLE DB in C++ is geschreven, is het benaderen ervan moeilijk in programmeertalen zonder pointers (zoals Java). Om dit te verhelpen werd ADO (ActiveX Data Objects) als extra toegangslaag toegevoegd. ADO is een gebruikersvriendelijke call-level API die werkt met eenvoudigere functies die kunnen worden opgeroepen zonder pointers. Deze eenvoudigere functies worden dan intern omgezet naar complexere OLE DB functies. 23

26 Hoofdstuk 9 Beveiliging tegen ongeoorloofd gebruik 9.1 Beveiligingsstrategiën Gebruikers Gebruikers vormen de moeilijkst te controleren component. Er moet een soort toegangscontrole gedaan worden waarbij de authenticiteit van elke gebruiker gecontroleerd wordt op basis van een uniek identicatiemiddel (zoals gebruikersnaam en wachtwoord, stem, vingerafdruk,... ). Andere afschrikkingsmiddelen zijn bijvoorbeeld een auditbestand, wanneer een gebruiker weet dat al zijn acties en instructies worden opgeslagen zal hij minder snel ongeoorloofde dingen proberen. Er moet ook worden gecontroleerd dat een opvolging van legale handelingen geen aanleiding kan geven tot ongeoorloofd gebruik, dit wordt de `controle van informatiestromen' of `ow'-controle genoemd. Informatie mag niet via een legale omweg (`covert channel') worden bewerkt zodat de beveiliging omzeilt wordt Hardware Het spreekt voor zich dat hardware achter slot en grendel moet bewaard worden Software Het is sterk aangeraden om het `default' wachtwoord van het DBMS te veranderen Data Natuurlijk hebben niet alle gebruikers dezelfde graad van authenticiteit, bepaalde data moet kunnen afgeschermd worden via toegangsbeperkingen. Dit kan gebeuren via de normale toegangscontrole, of via externe technieken. Zo'n externe techniek is het gebruik van views. De data moet ook beschermd worden tegen het mogelijk auisteren van de communicatie, daarvoor worden versleuteltechnieken gebruikt. Dit heeft als nadeel dat het versleutelen extra resources en rekentijd inpakt. 9.2 Toegangscontrole en toegangsbeperking In SQL wordt een gebruiker aangemaakt met CREATE USER gebruikersnaam IDENTIFIED BY wachtwoord. Het wijzigen van het wachtwoord gebeurt met ALTER USER gebruikersnaam IDENTIFIED BY wachtwoord. Om een gebruiker te verwijderen: DROP USER gebruikersnaam. Na de authenticatie kunnen nog toegangsbeperkingen opgelegd worden, daarbij kunnen de volgende technieken gebruikt worden: privileges, gebruikersproelen, beveiligingsniveaus en statische bevraging Privileges en gebruikersproelen Deze technieken hebben als onderliggende gedachte dat geen enkele instructie mag uitgevoerd worden zonder expliciete toestemming. Een toegangscontrole die werkt met privileges wordt ook een `DACtoegangscontrole' genoemd. Er zijn twee soorten privileges: datadenitie- en datamanipulatie-privileges. 24

27 Toekennen van privileges in SQL GRANT {privileges ALL PRIVILEGES} [WHEN {condities}] ON {componentnaam} TO {gebruikersnamen PUBLIC} [WITH GRANT OPTION]. PUBLIC betekent aan alle gebruikers. WITH GRANT OPTION betekent dat die gebruikers de gespeciceerde privileges ook mogen doorgeven aan andere gebruikers. Er kunnen contextafhankelijke condities worden meegegeven in de WHEN clausule. Bijvoorbeeld: die gebruiker mag niet aanmelden in het weekend. De belangrijkste privileges zijn SELECT, DELETE, INSERT, UPDATE, REFERENCES, CREATE, ALTER, DROP, INDEX, CREATE VIEW, CREATE ROUTINE, CREATE USER. Intrekken van privileges in SQL REVOKE [GRANT OPTION FOR] {privileges ALL PRIVILEGES} ON {componentnaam} FROM {gebruikersnamen PUBLIC} [RESTRINCT CASCADE]. De GRANT OPTION FOR optie zorgt ervoor dat alleen het privilege om de gespeciceerde privileges door te geven, wordt ingetrokken. Als gebruiker A een bepaald privilege kon doorgeven (en dat ook gedaan heeft) aan gebruiker B, en daarna dat privilege van A wordt ingetrokken, noemt men het privilege van B een verlaten privilege. Gebruikersproelen Het toekennen van privileges aan individuele gebruikers is een omslachtige taak, daarom werden gebruikersproelen gemaakt. Een gebruikersproel is een benoemde verzameling van privileges die als geheel aan een gebruiker kunnen worden toegekend. In SQL wordt een gebruikersproel gemaakt met de instructie CREATE ROLE profielnaam. Er kunnen dan privileges aan gegeven worden via de GRANT instructie. Aan een gebruiker kan dan dit proel gegeven worden via GRANT profielnaam TO Beveiligingsniveaus Een beveiligingsniveau is een soort label dat aangeeft hoe goed een bepaald gegeven moet worden afgeschermd. Voorbeelden zijn `publiek', `vertrouwelijk', `geheim' en `top geheim'. Een toegangsniveau is een label van een gebruiker dat aangeeft tot welk beveiligingsniveau die gebruiker toegang heeft. Een gebruiker kan alleen maar gegevens lezen waarvoor zijn toegangsniveau groter of gelijk is aan het beveiligingsniveau van de data. Een gebruiker kan alleen maar gegevens schrijven waarvoor zijn toegangsniveau kleiner of gelijk is aan het beveiligingsniveau. Deze restrictie wordt de stereigenschap genoemd. Hij bestaat om te voorkomen dat data van een sterker afgeschermd beveiligingsniveau naar een lager niveau wordt gekopieerd. Een toegangscontrole die werkt met beveiligingsniveaus wordt ook een `MAC-toegangscontrole' (Mandatory Access Control) genoemd. Het is niet mogelijk om in SQL met beveiligingsniveaus te werken Statistische bevraging Het idee hierachter is dat een gebruiker slechts specieke data uit de database mag halen. Er zijn verschillende technieken: ˆ Opzoekinstructies worden beperkt tot aggregatie-instructies, deze instructies geven een `geaggregeerde' waarde terug, bijvoorbeeld het minimum, maximum, gemiddelde,... ˆ Er worden slechts benaderde resultaatwaarden teruggegeven. Bijvoorbeeld: het maximumloon van een werknemer ligt tussen 2500 en ˆ Bij telinstructies worden benaderde waarden teruggegeven. Bijvoorbeeld: er voldoen tussen de 5 en 10 records aan de zoekinstructie. 25

28 9.3 Auditbestanden Een auditbestand is een bestand waarin de acties van gebruikers automatisch (door het DBMS) worden in opgeslagen. Het kan de volgende gegevens omvatten: de gebruikersnaam, de instructie, het tijdstip van uitvoeren, de locatie van uitvoeren, de impact van de instructie. 9.4 Versleutelen Om te vermijden dat de communicatielijnen kunnen worden afgeluisterd, is het nodig om de data te versleutelen in transmissie. Hiervoor kunnen twee soorten algoritmen worden gebruikt: ˆ Symmetrische algoritmen zijn algoritmen waar de codeer- en decodeersleutel gelijk zijn. Deze algoritmen zijn de snelste soort, daarom worden zij het meest gebruikt. Een voorbeeld is AES. ˆ Asymmetrische algoritmen zijn algoritmen met een aparte codeer- en decodeersleutel. Omdat de codeersleutel kan publiek worden gemaakt spreekt men soms van `publieke sleutel'-algoritmen. Een voorbeeld is RSA. Versleuteling kan (optioneel) door externe software worden behandeld, dit verlaagt de last op het DBMS. 9.5 Views Het beveiligen via views van bepaalde data houdt in dat de data wordt `geprojecteerd' op een versimpelde weergave. Bijvoorbeeld: een tabel met gebruikersnamen en wachtwoorden wordt geprojecteerd op een tabel met alleen gebruikersnamen. In SQL wordt een view gemaakt met CREATE VIEW viewnaam AS select_instructie FROM tabellijst WHERE conditie. Hoofdstuk 10 Beveiliging tegen falen 10.1 Transacties en OLTP Een transactie is een hoeveelheid werk (één of meerdere instructies) waarvan het dbms garandeert dat het ofwel volledig met succes wordt uitgevoerd, ofwel helemaal niet wordt uitgevoerd. Dit houdt dus in dat de database altijd in een consistente toestand moet zijn. Het DBMS verwerkt alle SQL instructies als transacties. Alle transacties voldoen aan de 4 `ACID' eigenschappen: ˆ Atomair: Alle transacties moeten atomair (ondeelbaar) zijn. ˆ Consistent: Elke transactie moet de consistentie van de database bewaren. 26

29 ˆ Isolatie: Het DBMS moet ervoor zorgen dat transacties geïsoleerd van elkaar uitgevoerd worden. ˆ Duurzaam: De resultaten van een (update-) transactie moeten opgeslagen worden in de database. Aangezien het DBMS elke instructie omzet in een transactie, volledig transparant voor de gebruiker, spreken we van impliciete transacties. In SQL zijn de sleutelwoorden START TRANSACTION, COMMIT WORK en ROLLBACK WORK beschikbaar voor transacties. Indien een transactie wordt afgesloten zonder een COMMIT instructie, voert het DBMS automatisch een ROLLBACK instructie uit. Sommige SQL instructies kunnen niet ongedaan worden (bvb DROP TABLE,... ). Om bij te houden waar verschillende transacties beginnen werkt het DBMS met synchronisatiepunten. Sommige DBMS laten toe dat de gebruiker zelf tussentijdse synchronisatiepunten toevoegt, deze worden savepoints genoemd. Elke database is een OLTP (Online Transaction Processing System) Oorzaken van falen ˆ Overmacht: stroomuitval, kernbom,... ˆ Falen van hardware: kapotte harde schijven,... ˆ Softwarefouten: softwarebugs,... ˆ Bewuste onderbreking ˆ Ongelukken door gebruikers ˆ Sabotage of diefstal We noemen een `soft crash' een crash van het primaire geheugen van de databank. Een `hard crash' is een crash van het secundair geheugen Falen voorkomen Backup- en logbestanden De DBA moet ervoor zorgen dat op gepaste tijden een kopieën gemaakt wordt van de database. Dit kunnen backup- of logbestanden zijn. Backupbestanden Hierbij kan de volledige database gekopieerd worden op een extern opslagvolume. Er kan ook gewerkt worden met een incrementele backup, waarbij alleen de veranderingen sinds de vorige backup worden opgeslagen. Logbestanden Een logbestand is een apart bestand waarin alle impliciete en expliciete transacties sinds de laatste backup worden geregistreerd. Bij beschadiging van de database kan het logbestand gebruikt worden om de data te herstellen. Bij beschadiging van het logbestand moet onmiddellijk en nieuwe backup gemaakt worden Stroomuitval Er kunnen generators of UPS (Uninterruptable Power Supply) machines gebruikt worden om, indien de stoom uitvalt, de database nog even online te houden tot de DBA hem goed kan afsluiten. 27

30 Hardwarefalen Om dataverlies door hardwarefalen te voorkomen gebruikt men vaak RAID (Redundant Array of Independent Disks) systemen. Deze `splitsen' de data over meerdere schijven zodat, indien een van de schijven faalt, de andere schijven toch nog de data kunnen heropbouwen. Bekende RAID conguraties zijn RAID0 (`striping' geen redundantie), RAID1 (`mirroring'), RAID5 en RAID Schaduwpagina's Bij deze hersteltechniek deelt men de pagina's in het magneetschijfgeheugen op in werkpagina's en schaduwpagina's. Bij het begin van de transactie zijn de werk- en schaduwpagina's dezelfde. Aanpassingen door de transactie worden alleen gedaan op de werkpagina's. Na een COMMIT instructie worden de gewijzigde werkpagina's naar hun schaduwpagina's gekopieerd. Hierdoor heeft men dus geen logbestanden nodig Herstel van `soft crashes' Het primaire geheugen van de databasesysteem bevat alle transacties die nog niet klaar zijn. Het falen hiervan zorgt er dus voor dat deze transacties onbeëindigd zijn. Het wegschrijven van data uit het primaire geheugen naar het secundaire geheugen noemt men ushing. De meeste databanksystemen gebruiken een `steal, no force'-strategie om te ushen. ˆ Met `steal' wordt bedoelt dat het DBMS mag ushen terwijl er nog transacties bezig zijn. ˆ Met `no force' wordt bedoelt dat het ushen niet mag veroorzaakt worden door een COMMIT instructie. Indien men dit wel toelaat, moet het DBMS veel meer ushen (wat meer tijd kost). Omdat de operaties van transacties worden uitgevoerd op de data in de buers (en niet in de echte database), en transacties worden opgenomen in het logbestand, moet een speciale maatregel gebruikt worden om de duurzaamheid van die transacties te kunnen garanderen: de `write-ahead log' regel. Deze regel houdt in dat de COMMIT instructie van een transactie naar het logbestand moet worden geschreven net voor de transactie wordt afgesloten en bevestigd. Om bij te houden wanneer er `geusht' is, houd het DBMS controlepunten bij. Als er nu een soft crash plaatsvindt, moeten alle transacties die op het controlepunt niet afgewerkt zijn opnieuw uitgevoerd worden. 28

31 Hoofdstuk 11 Concurrency controle Aangezien ze meestal parallel worden uitgevoerd, kunnen bepaalde transacties elkaar tegenwerken. We bespreken 3 problemen: lost update, uncommited depencency en problemen van inconsistente analyse. `Lost Update'-problemen Hierbij wordt de aanpassingsoperatie door de ene transactie overschreven door een aanpassingsoperatie van een andere (latere) transactie. `Uncommitted Dependency'-problemen Bij een `uncommitted dependency' werkt een bepaalde transactie met gegevens die door een andere transactie zijn aangepast, maar die transactie wordt gerollbackt. Inconsistente analyse Hierbij past een transactie gegevens aan terwijl een andere transactie nog bezig is met de verwerking van deze gegevens. Dit wordt ook een `dirty read' genoemd. Problemen die hierbij voorkomen zijn `nonrepeatable read' en `phantom read': ˆ Non-repeatable read is het probleem dat, als een transactie twee keer dezelfde waarde leest, verschillende resultaten krijgt. ˆ Phantom read is het probleem dat, als een transactie twee keer eenzelfde opzoekinstructie uitvoert, er een verschillend aantal records zijn in de twee resultaten. 29