Samenvatting: Databanken
Hoofdstuk 1 1.1 Enkele basisconcepten Data zijn gegeven feiten Informatie ‐> betekenis van gegevens Een database is een collectie van persistente (permanent geheugen van de pc) data Een computersysteem voor het beheer van databases wordt een databasesysteem genoemd. 1.2 Gegevensbeheer door de eeuwen heen Gegevens registreren en conserveren ‐> geleidelijk aan structureren Relationeel databasemodel ‐> verzameling van samenhangende tabellen. 1.3 Databasesysteem 3 Hoofdcomponenten in databasesysteem: ‐ Hardware: CPU en geheugen Primair geheugen: Statisch (cache) en dynamisch (werk/hoofdgeheugen) RAM Meestal databasebuffers Hoe meer geheugen ‐> betere prestatie Secundair geheugen: Schrijven, CD‐Rom,… Bestandsorganisatie: Primair: manier waar fysiek wordt opgeslagen Secundair: toegang optimaliseren ‐> extra data (locatie & verbanden) ‐ Data: Database = coalitie van records Record= opgebouwd uit 1 of meerdere velden (vastgelegd in het recordtype) die data kunnen bevatten. In het secundair geheugen ‐> records opgeslagen in bestanden Database ‐> geïntegreerd geheel: linken behouden ‐ Software: Het databasemanagementsysteem (dbms) is de softwarecomponent van een databasesysteem die instaat voor het beheer van de databases. Toepassingsprogramma’s ‐> indirecte manier want gaan via dbms Tools voor gemak en automatiseren van de taken Bv: back‐up software Communicatiesoftware (database verspreid) Datawarehouse: Grote database bedoeld voor data‐analyse Vaak gestructureerd volgens tijdsdimensie Datamining heeft tot doel zinvolle verbanden te vinden die voorheen niet bij de gebruiker bekend waren. Rapportgeneratoren ‐ Gebruikers: Persoon, op 1 of andere manier interactie met dbs Verschillende ‐> gebruikersprofielen Data‐administrator: centraal verantwoordelijk Database‐administrator: Technisch verantwoordelijk voor implementatie en onderhoud Toepassingsontwikkelaar Eindgebruiker: dagelijks werken met de database Gewone: afgeschermd Geavanceerd: complexe instructies
1.4 Databasemanagementsysteem ‐ Hoofdfunctionaliteit: Databasedefinitie: Zowel structuur als semantische regels vastleggen ‐> integriteit (correctheid vd data) Manipulatie: Efficiënt toevoegen, verwijderen, aanpassen en doorzoeken Constructie: Opslag in geheugen ‐ Andere functionaliteit: Delen van data: Simultane toegang tot de database, conflicten verhinderen Beveiliging van data: Ongeoorloofd gebruik of fysiek falen tegengaan Optimaal systeemgedrag: Alles realiseren zonder nadeel voor de gebruiker. ‐ Architectuur: 3‐lagen architectuur Interne laag (opslaglaag) : Databaserecords in bestanden Sommige recordvelden zijn meerwaardig Sommige velden van het recordtype zijn optioneel Fileheader/prefixveld Index =
! anders voor variabele lengte Logische laag: Abstracte voorstelling van de database Enkel entiteiten, verbanden,… Volgens databaseschema Externe laag (individuele laag) : Dichtst bij eindgebruiker In de laag worden views gedefinieerd Views: bepaalt hoe de database gezien wordt door bepaalde eindgebruikers Mappings: Omzettingsprocessen van data en operaties tussen de 3 lagen van de architectuur ‐ Dataonafhankelijkheid: (gegarandeerd door het gebruik van meerdere lagen) Fysieke DO: Interne beschrijving aangepast zonder impact op de logische beschrijving Logische DO: Logische beschrijving aangepast zonder impact op de diverse views 1.5 Wanneer gebruik je een databasesysteem Voordelen en nadelen zie boek pg 27
Hoofdstuk 2 2.1 Enkele basisconcepten Een datamodel is een verzameling van voorschriften en regels die het mogelijk maken om de structuur en het gedrag te beschrijven van data die in bepaalde software voorkomen. Een databasemodel is een verzameling van voorschriften en regels die het mogelijk maken om zowel de structuur, de beperkingen voor integriteit en beveiliging, als het gedrag van een database te beschrijven op het niveau van de logische laag uit een ‘drielagen’‐architectuur voor databasemanagementsystemen. 2.2 De operationele modellen ‐ Het hiërarchisch databasemodel: Hiërarchisch georganiseerd in boomstructuren Boomstructuur is opgebouwd uit knopen ‐> root, kindknopen, bladknopen, subbomen,… Databaseschema ‐> collectie van boomstructuren ( knopen: recordtypes) Database ‐> collectie van bomen (knopen: records) ! elke kind maar 1 ouder ‐> kopie nemen (gevaarlijk) ‐> virtuele ouder‐kind relatie Opgeslagen als hiërarchische recordsequentie ‐> lineair te ordenen, overlopen in pre‐order Manipuleren via hosttaal m.b.v. hostvariabelen ‐> doorgeefluik (controle) $ ‐> ingebedde operatoren ‐ Het netwerkmodel: Veralgemening van het hiërarchisch databasemodel (boomstructuur ‐> graafstructuur) Graaf: ook cyclisch, gericht, … Recordtypes = toegangspunten tot de database (zie voorbeeld pg 39) Toegang ‐> efficiënter, manipulatie ‐> complexer (verborgen voor gebruiker) Eveneens via hosttaal en hostvariabelen 2.3 De structurele modellen Abstracte structuur!! ‐ Het relationeel databasemodel: Data gestructureerd in tabellen ‐> vooraf gedefinieerde vorm Tabel : voorstellingsvorm van het wiskundige concept relatie Waarden in tabel zijn atomaire waarden ‐> niet verder opgesplitst Elke kolom ‐> unieke naam en datatype Kandidaat‐sleutel van een tabel is een irreducibele verzameling van kolommen, waarvan de waarden de rijen op een unieke manier identificeren. M.a.w. 2 eigenschappen: Uniciteit : voor elke rij in de tabel is de combinatie van de waarden van de kolommen van de kandidaat‐sleutel uniek binnen de tabel Irreducibiliteit: je kunt geen enkele kolom uit de kandidaat‐sleutel weglaten zonder dat hierdoor de uniciteiteigenschap teniet wordt gedaan Vreemde sleutel ‐> verwantschap tussen rijen van 2 tabellen Manipulatie aan de hand van SQL 2.4 De semantische modellen Modelleren van semantiek van gegevens benadrukt!! ‐ De objectgeoriënteerde databasemodellen: Tegemoet komen aan extra noden door nieuwe programmeertalen enzo Steunen op notie van objecten die elk een unieke identiteit hebben en gedefinieerd ‐> datatypes of objectprototypes ‐> structuur en gedrag klasse ‐> rechthoek, overerving ‐> pijl van specifieke klasse naar algemene klasse, binaire verwantschappen ‐> gemarkeerde pijlen (dubbele of enkele pijl ‐> meerdere of enkele verwantschappen)
‐ Het objectrelationeel databasemodel: Uitgaan van relationeel model, met extra objectgeoriënteerde faciliteiten (overerving, operatoren enkel geldig op bepaalde tabellen,…) ‐ Hybride databasemodellen: Postrelationeel model ‐> beschouwt verschillende databasemodellen in de logische laag Mapping naar de onderliggende laag gemaakt ‐> kan simpel overschakelen 2.5 Verdere ontwikkelingen Impedance mismatch ‐> incompatibiliteit ‐> nadelig informatieverlies ‘vage’ databasemodellen 2.6 Wanneer gebruik je welk databasemodel Aspecten die de keuze kunnen beïnvloeden: Snelheid, aanwezige kennis en technologie, aanleercurve voor gebruikers, duurzaamheid, standaardisatie, schaalbaarheid, technische support en ondersteuning,…
Hoofdstuk 3
3.1 Het volledige databaseontwerpproces Bestaat uit 4 fasen: Informatievergaring, conceptueel, logisch en fysiek ontwerp. (vb. pg 57) ‐ Informatievergaring: Cruciaal ‐> juiste betekenis en context (domeinanalyse) Informatiestromen vinden ‐> functionele analyse Behoefteanalyse: zicht op informatiebehoeften ‐ Abstrahering, modellering en implementatie: Abstrahering: schetsen wat het belangrijkst is ‐> verwantschappen!! Modellering: representatietechniek ‐> EER‐diagram Alternatief ‐> UML (objectgeorienteerd) Implementatie: kies model, zet schema om naar instructies in de DDL van model Aangevuld met andere shizzle (pg60) ‐ Het gebruik van CASE‐tools: Gedeeltelijk geautomatiseerd Meestal optie ‐> grafisch conceptueel model te bouwen 3.2 Het (uitgebreid) ‘entity‐relationship’‐model ‐ Entiteitstypes en relatietypes: Structurele aspecten: Een entiteit is een ‘ding’ dat een zelfstandig bestaan leidt in de reële wereld. Een entiteittype (rechthoek) karakteriseert een collectie van entiteiten en wordt gekenmerkt door een naam & een verzameling van attributen (ovaal) Een relatietype (ruit) is een verwantschap tussen twee of meer al dan niet verschillende entiteittypes. Men spreekt respectievelijk van een binair, ternair of n‐air (n>3) relatietype. Verder wordt elk relatietype gekenmerkt door een naam. Karakteristieken en restricties: Attributen: Verder karakteriseren ‐> betere semantiek Meerwaardige (op elk tijdstip collectie van waarden kan aannemen) <‐> enkelwaardige attributen (op elk tijdstip 1 waarde kan aannemen) Meerwaardig ‐> dubbel ovaal Samengesteld (opgebouwd uit andere attr.) <‐> enkelvoudig Ovaal verbonden met ‘hoofd’‐attribuut Afgeleide attributen ‐> berekenen uit andere attributen (ovaal stippellijn) Sleutelattributen zijn attributen van een sleutel Sleutel = verzameling van attributen waarvoor uniciteit en irreduc. gelden Sleutel ‐> onderstreept in ovaal Orthogonaliteit: kunnen willekeurig gecombineerd voorkomen Zwakke entiteittypes: Een zwak entiteittype karakteriseert zwakke entiteiten. Dit zijn entiteiten die niet op zichzelf kunnen bestaan, maar die voor hun bestaan afhankelijk zijn van het bestaan van andere, identificerende entiteiten. Partiële sleutels : sleutelattributen van het zwakke entiteittype Zwak ‐> dubbele rechthoek Identificerend relatietype ‐> dubbele ruit Partiële sleutel ‐> onderstreepte stippellijn
Relatietypes: Kardinaliteitsrestrictie: max aantal entiteiten op een gegeven tijdstip ‐> 1 of N schrijven naast verbindingslijn Participatierestricitie: bepaalt op op elk tijdstip moet voorkomen Totale participatie <‐> partiële participatie ‐> dubbele lijn : totale participatie , enkele lijn: partiële participatie Wordt ook gebruik gemaakt van de (min,max)‐notatie ‐ Subtypes, supertypes en overerving: Structurele aspecten: Een subtype is een entiteittype dat een subcollectie van entiteiten karakteriseert. Het entiteittype van de collectie waarbinnen deze subcollectie wordt beschouwd, wordt het supertype genoemd. Erft alle attributen en verwante relatietypes van supertype Kan aparte specifieke attributen en relatietypes hebben In schema : C (deelverzamelingsymbool) Diverse subtypes binnen dezelfde onderverdeling ‐> cirkeltje Het creëren van specifieke subtypes voor een gegeven entiteittype noemen we specialisatie. Het creëren van een algemeen supertype dat de gemeenschappelijke attributen en relatietypes van een aantal gegeven entiteittypes verenigt, noemen we generalisatie. Supertype/subtype‐netwerk <‐> supertype/subtype‐hiërarchie (elk entiteitype heeft maar 1 supertype) Karakteristieken en restricties: Overlappende versus disjuncte subtypes: Verschillende subtypes ‐> aangegeven of entiteit van supertype tegelijkertijd kan voorkomen in meerder subtypes‐> overlappende (o) Anders disjunct (d) Geconditioneerde subtypes: Om te zien of bepaalde entiteit supertype ook entiteit subtype ‐> bepaalde conditie definiëren bij attribuut van supertype als voldoet aan de vwe ‐> geconditioneerd subtype. Als hetzelfde attribuut ‐> alle subtypes ‐> attribuutgedefinieerde supertype/subtype‐verwantschap (naam naast verbindingslijn schrijven) Participatierestrictie voor supertype/subtype‐verwantschappen: Totale participatie (moet een entiteit zijn van minstens 1 subtype) versus partiële participatie ‐ Categorieën: Structurele aspecten: Een categorie of een unietype is een ‘speciaal’ subtype met verschillende supertypes, dat wordt ingevoerd om de entiteiten van deze supertypes te groeperen. Elke entiteit van een categorie ‐> entiteit van precies 1 van de supertype Gevolg ‐> overerving werkt selectief Cirkeltje met een U in en deelverzameling teken op de verbinding Karakteristieken en restricties: Geconditioneerde supertypes: Een entiteit van de categorie behoort tot het supertype waarvoor zijn attribuutwaarde voldoet aan de geassocieerde conditie (naam naast verbindingslijn schrijven)
Participatierestrictie voor categorieën: Idem hierboven 3.3 Het ontwerp van een (E)ER‐diagram ‐ Bijzonder aandachtspunt: de ‘connection trap’: Ternair relatietype is niet semantisch equivalent met 3 binaire relatietypes. Wel weergeven met behulp van een zwak entiteitstype ‐ Casestudie: database voor een jeugdvereniging ‐ Casestudie: reserveringssysteem voor een theater ‐ Casestudie: database voor een softwarefirma Elementen/verbindingen in (E)ER‐schema Entiteittype Rechthoek Attribuut Ovaal Relatietype Ruit Meerwaardige attributen Dubbel ovaal Afgeleide attributen Stippellijn ovaal Sleutel attributen Onderstreept in ovaal Zwak entiteittype Dubbele rechthoek Identificerend relatietype Dubbele ruit Partieel sleutel attribuut Onderstreept stippellijn in ovaal Kardinaliteitsrestrictie 1 of N schrijven naast verbindingslijn Totale participatie Dubbele lijn Partiële participatie Enkele lijn Subtype C (deelverzamelingsymbool) Diverse subtypes in zelfde onderverdeling cirkeltje Overlappende subtypes O in cirkeltje disjuncte subtypes D in cirkeltje Geconditioneerde subtypes,categories naam naast verbindingslijn schrijven Categorie U in cirkeltje en deelverzamelingteken
Hoofdstuk 4
4.1 Structurele aspecten ‐ basisrelaties: Geïnspireerd op het wiskundige concept relatie Atomaire datatypes: Bouwstenen van een basisrelatie Een atomair datatype wordt gespecificeerd door een verzameling van toegelaten atomaire waarden (het domein van het datatype) en een verzameling van operatoren die allemaal inwerken op de domeinwaarden en het gedrag van het datatype vastleggen. Atomair ‐> niet verder conceptueel opdeelbaar Typecompatibel ‐> domeinwaarden van het ene datatype kunnen omzetten naar domeinwaarden van het andere datatype Omschrijving van een basisrelatie: Het schema R(A1:T1, A2:T2, … ,An:Tn) van een relatie is opgebouwd uit een relatienaam R en een eindige verzameling van attributen {A1:T1,A2:T2, … ,An:Tn}. Elk attribuut Ai:Ti, 1<=i<=n is op zijn beurt opgebouwd uit een attribuut i en een geassocieerd atomair datatype Ti. Wordt ook wel hoofding of intentie van R genoemd De extentie van een basisrealtie met schema R(A1:T1, A2:T2, … ,An:Tn) is een met de tijd variërende verzameling van m (m>=0) n‐tuples, die allemaal volledig worden gekarakteriseerd door de attributen uit het schema van de relatie. Elk n‐tuple ti= (A1:wi,1, A2:wi,2, … ,An:wi,n), 1<=i<=m is op zijn beurt opgebouwd uit n (attribuutnaam:waarde)‐paren Aj:wi,j, 1<=j<=n, waarbij er geldt dat wi,j behoort tot het domein van het atomair datatype Tj. Een basisrelatie wordt gevisualiseerd in een tabel. Terminologie: Graad = aantal attributen Datatype van attribuut = attribuuttype n‐tuples = tuples kardinaliteit = aantal tuples Eigenschappen: ‐ Binnen een relatie kunnen geen dubbele tuples voorkomen ‐ De tuples van een relatie zijn niet geordend ‐ De attributen van een relatie zijn niet geordend ‐ Alle attribuutwaarden van een relatie zijn atomair Interpretatie: ‐ Metadata: de catalogus: Relationele database ‐> opgebouwd als een verzameling van basisrelaties Metadata = data over de data: gevolg van interactie met een toepassing of gebruiker Gebruikergedefinieerde relaties ‐> aangemaakt door de database ontwerper Systeemgedefinieerde relaties ‐> automatisch aangemaakt door het dbms SG basisrelaties vormen samen de catalogus/ data dictionary ‐ Views: Het concept view: Een view is een benoemde, virtuele relatie die is afgeleid van gebruiker‐ gedefinieerde en/of systeemgedefinieerde basisrelaties en/of andere views. Wordt ook afgeleide of virtuele relatie genoemd. Definiërende expressie Niet gematerialiseerd want materialiseren ‐> redundante gegevensopslag
Geen redundantie: Enkel genormaliseerde basisrelaties materialiseren Geen afleidbare data opnemen in basisrelaties Het nut van views: Basisrelaties ‐> logische laag Views ‐> externe laag (concretiseren) Ook: Nieuwe data af te leiden Bevragingsinstructies in te korten In individuele gebruikersbehoeften te voorzien Data af te schermen Het werken met views: Doel: door gebruikers niet te onderscheiden van een basisrelatie Zoeken: Geen onderscheid tussen views en basisrelaties Querymodificatie: vraagstelling m.b.t. een view omgezet naar vraagstelling enkel betrekking op basisrelaties (m.b.v. definiërende expressie) Aanpassen, toevoegen en verwijderen: Essentieel: view expliciet als aanpasbaar gedefinieerd Manipulatie niet conflicterend met definiërende expressie Geen manipulaties op afgeleide data ‘with check option’ ‐> aanpasbaar maken Opletten: tuple verwijderen ‐> tuple in basisrelatie verwijderen (ook niet zichtbare attributen) tuple aanpassen ‐> attr.waarde in basisrelatie ook aangepast tuple toevoegen ‐> tuple in basisrelatie toevoegen (informatie ontbreekt voor niet zichtbare attributen) ‐ Indexen: Een index over n attributen van een basisrelatie R kan worden omschreven als een geordende lijst van (n+1)‐tuples. Voor elk tuple t uit de extentie van R is er één (n+1)‐tuple opgenomen in de lijst. Dit (n+1)‐tuple is opgebouwd uit de n beschouwde attribuutwaarden van t en een referentie naar t. De (n+1)‐tuples zijn geordend op basis van de n attribuutwaarden, volgens een opgegeven volgorde. Referenties kunnen zowel fysieke als logische pointers zijn ‘create index’ Uniciteitindex ‐> uniciteit af te dwingen van de waarden van een attribuut in de extentie van een relatie ‐Ontbrekende informatie: Onbekende info en niet‐gedefinieerde info Null‐waarden: Pseudo‐beschrijving ‐> ontbrekend Kan opleggen dat iets niet null mag zijn Defaultwaarden: Benadering/model 4.2 Integriteitaspecten ‐ Sleutels: Kandidaatsleutels: Als K een deelverzameling is van de verzameling van alle attributen van een gegeven basisrelatie R, dan is K een kandidaat‐sleutel 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.
Primaire sleutels: Precies 1 gekozen uit de kandidaat‐sleutels (rest : alternatieve sleutels) Mogen geen null waarden bevatten ‘primary key’ <‐> ‘unique’ Vreemde sleutels: Een vreemde sleutel F van een basisrelatie R2 is een verzameling van attributen van R2 waarvoor het volgende geldt: 1. Er bestaat een basisrelatie R1 (R1 niet noodzakelijk verschillend van R2) met een kandidaat‐ sleutel 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 R2 eveneens voor als waarde van K in een tuple van R1. ‘foreign key’ ‘references’ Cyclische referenties ‐> alter table (want volgorde is belangrijk) Zelfreferentie kan ook ! referentiële integriteit ! ( alle niet null waarden van vreemde sleutels komen op elk ogenblik voor als waarden van kandidaatsleutels) ‐ Integriteitrestricties: Een integriteitrestrictie is een voorwaarde waaraan alle data uit een database op elk moment moeten voldoen. Naam en logische expressie ‘create assertion’ ‘check’ ‘drop assertion’ Toestands‐ en transitierestricties vs. relatie‐ en databaserestrictie Toestand: waakt over correcte toestand Transitie: waakt over de integriteit bij overgang naar een nieuwe toestand Relatie: data uit 1 relatie <‐> database: verschillende relaties ! Referentiële integriteitrestrictie ! ‐ Stored procedures en triggers: businessregels Stored procedures: Expliciete procedure oproep Create Procedure procedurenaam (parameterlijst (in/out)) Lokale_declaraties Procedure_corpus ‘execute procedure’ Triggers: triggered action bij een trigger event als voldaan aan trigger condition 1. naam 2. Trigger event 3. Trigger condition 4. Triggered action 4.3 Gedragsaspecten: relationele algebra ‐ De operatoren vereniging, doorsnede, verschil e cartesiaans product: (traditionele verzamelingoperatoren) Twee relatieschema’s zijn van hetzelfde type als ze evenveel attributen bevatten en er een één‐op‐ééncorrespondentie is tussen hun attributen, zodat corresponderende attributen dezelfde geassocieerde datatypes hebben. Als R een relatie is waarin het attribuut A:T voorkomt, dan resulteert de ‘rename’‐ operatie R RENAME A as Anew in een nieuwe relatie met een schema dat we verkrijgen uit het schema van R door het attribuut A:T te vervangen door het attribuut Anew:T en met dezelfde extentie als R.
Vereniging: Als R1 en R2 twee relaties zijn met schema’s van hetzelfde type, dan is de vereniging, R1 UNION R2 van deze relaties een relatie met een schema van hetzelfde type en met een extentie die bestaat uit alle tuples die ofwel voorkomen in R1, ofwel voorkomen in R2, ofwel voorkomen in R1 en R2. Doorsnede: Als R1 en R2 twee relaties zijn met schema’s van hetzelfde type, dan is de doorsnede, R1 INTERSECT R2 van deze relaties een relatie met een schema van hetzelfde type en met een extentie die bestaat uit alle tuples die zowel voorkomen in R1 als in R2. Verschil: Als R1 en R2 twee relaties zijn met schema’s van hetzelfde type, dan is het verschil, R1 MINUS R2 van deze relaties een relatie met een schema van hetzelfde type en met een extentie die bestaat uit alle tuples die wel voorkomen in R1 en niet in R2. Cartesiaans Product: Als R1 en R2 twee relaties zijn die geen gemeenschappelijke attributen hebben, dan is het cartesiaans product, R1 TIMES R2 van deze relaties een nieuwe relatie waarvan de attributen uit het relatieschema worden verkregen door de unie te nemen van de verzameling van de attributen van R1 en de verzameling van de attributen van R2. De extentie van de resulterende relatie bestaat uit alle tuples die worden verkregen door een tuple die voorkomt in R1 samen te voegen met een tuple die voorkomt in R2. ‐ De operatoren selectie, projectie, join en deling: (relationele operatoren) Selectie: Als R een relatie is en e een logische expressie is waarvan alle parameters attributen zijn van R dan resulteert de selectie, R WHERE e in een nieuwe relatie die dezelfde attributen heeft als R en waarvan de extentie bestaat uit alle tuples van R waarvoor de expressie e evalueert naar de waardeheidswaarde ‘waar’. Projectie: Als R een relatie is en {A1:T1,A2:T2,…,Ap:Tp} een deelverzameling is van de attributen van R dan resulteert de projectie, R {A1,A2,… Ap} in een nieuwe relatie waarvan het schema verkregen wordt uit het schema van R door alleen de attributen uit {A1:T1,A2:T2,…,Ap,Tp} te behouden en waarbij de extentie bestaat uit alle tuples t=(A1:w1,A2:w2 ,…,Ap:wp) waarvoor een tuple voorkomt in R met attribuutwaarde w1 voor A1, w2 voor A2, … en wp voor Ap. Join: 2 verschillende variëteiten Inner join: Als R1 een relatie is met attributen {X1:TX1,X2:TX2,…,Xm:TXm, Y1:TY1,Y2:TY2,…,Yn:TYn} en R2 een relatie is met attributen { Y1:TY1,Y2:TY2,…,Yn:TYn ,Z1:TZ1,Z2:TZ2,…,Zp:TZp} –dus beide relaties hebben de attributen Y1:TY1,Y2:TY2,…,Yn:TYn gemeenschappelijk ‐ dan resulteert de join, R1 JOIN R2 in een nieuwe relatie waarvan het schema bestaat uit de attributen {X1:TX1,X2:TX2,…,Xm:TXm,Y1:TY1,Y2:TY2,…,Yn:TYn, Z1:TZ1,Z2:TZ2,…,Zp:TZp } en waarvan de extentie bestaat uit alle tuples die worden verkregen door een tuple van R1 samen te voegen met een tuple van R2 onder de voorwaarde dat alle gemeenschappelijke attributen gelijke waarden moeten hebben.
Outer join: Als R1 een relatie is met attributen {X1:TX1,X2:TX2,…,Xm:TXm, Y1:TY1,Y2:TY2,…,Yn:TYn} en R2 een relatie is met attributen { Y1:TY1,Y2:TY2,…,Yn:TYn ,Z1:TZ1,Z2:TZ2,…,Zp:TZp} dan resulteert de (left) outer join, R1 OUTER JOIN R2 in een nieuwe relatie die verkregen wordt door het resultaat van de join‐operatie R1 JOIN R2 uit te breiden met alle tuples uit R1 waarvoor minstens één van de gemeenschappelijke attributen een null‐ waarde bevat en daarbij de ontbrekende p attribuutwaarden van R2 weet te geven met extra null‐waarden. Deling: Als R1 een relatie is met attributen {X1:TX1,X2:TX2,…,Xm:TXm, Y1:TY1,Y2:TY2,…,Yn:TYn} en R2 een relatie is met attributen {X1:TX1,X2:TX2,…,Xm:TXm } dan resulteert de deling, R1 DIVIDEBY R2 in een nieuwe relatie waarvan het schema bestaat uit de attributen { Y1:TY1,Y2:TY2,…,Yn:TYn} en de extentie bestaat uit alle tuples t=(Y1:wY1,Y2:wY2,…,Yn:wYn) waarvoor alle mogelijke samenvoegingen met een tuple uit R2 voorkomen in R1. ‐ Bijkomende operatoren voor de relationele algebra: Uitbreiding: Als R een relatie is, {A1:T1,A2:T2,…,Ap:Tp } een deelverzameling is van de attributen van R en {B1:F1,B2:F2,…,Bq:Fq} een verzameling is van afgeleide attributen Bi:Fi, i:1,2,…,q met Bi een unieke attribuutnaam, die niet voorkomt in R en Fi een functie is over de attributen van R, die constanten kan bevatten en gebruikt wordt om de waarden van Bi te berekenen, dan resulteert de uitbreiding, EXTEND R {A1,A2,…,Ap} (B1:F1,B2:F2,…,Bq:Fq) in een nieuwe relatie waarvan het schema verkregen wordt door de afgeleide attributen uit {B1:F1,B2:F2,…,Bq:Fq} toe te voegen aan het schema van de projectie R {A1,A2,…,Ap} en waarvan de extentie wordt verkregen door elk tuple van R {A1,A2,…,Ap} uit te breiden met de waarden Bi:wi, i=1,2,…,q, met wi de waarde die verkregen wordt door Fi te evalueren met de attribuutwaarden van het corresponderende tuple uit R. Groepeer: Als R een relatie is en {A1:T1,A2:T2,…,Ap:Tp } een deelverzameling is van de attributen van R dan resulteert de groepering, R GROUP (A1,A2,…,Ap) in een nieuwe relatie met hetzelfde schema als R, maar waarbij de tuples in de extentie gegroepeerd zijn in disjuncte deelverzamelingen zodat een deelverzameling enkel tuples bevat met een gelijke waarde voor elk van de attributen A1,A2,…,Ap. Aggregatie: Doel = 1 waarde te berekenen uit alle tuples uit de extentie van een relatie. COUNT, MIN, MAX, AVG, SUM In combinatie met de uitbreidingsoperator (eventueel ook groepeeroperator) ‐ Het gesloten zijn en nut van de relationele algebra: Elke operator werkt in op 1 of 2 relaties ‐> nieuwe relatie= gesloten zijn
Hoofdstuk 5 5.1 Logisch relationeel databaseontwerp met behulp van een (E)ER‐diagram ‐Overzicht: Van (E)ER‐diagram omzetten naar databaseschema ‐> omzettingsalgoritmen Logisch databaseontwerp: forward engineering (reverse engineering bestaat ook) Ook functionele beschrijvingen omzetten naar gedragspecificaties ‐ Het omzettingsalgoritme voor relationele databases: Stap 1: Omzetting van reguliere entiteittypes: * relatienaam=naam van entiteittype (ET) * toevoegen enkelvoudige, enkelwaardige en niet‐afgeleide attributen (v.h. ET) * voor samengestelde attributen: enkel toevoeging van “” “” “” componentattributen * attributen uit sleutel (v.h. ET) vormen primaire sleutel Stap2: Omzetting van zwakke entiteittypes: * relatienaam=naam van zwak entiteittype (ZET) * idem van ZET * idem * vreemde sleutels ‐> attributen van elke primaire sleutel ( van identificerend ET) * toevoegen van enkelv. , enkelw. , niet‐afg. atrributen van de IET * primaire sleutel: samenvoeging van attributen v.d. vreemde sleutels + partiele sleutel van ZET Stap 3: Omzetting van specialisaties en generalisaties: (pg.146) Met 1 supertype (enkelvoudige overerving): * verschillende basisrelaties, voor het supertype en de subtypes * verschillende basisrelaties, enkel voor de subtypes * één basisrelatie met één typeattribuut * één basisrelatie met meerdere typeattributen Met verschillende supertypes (meervoudige overerving): * diverse basisrelaties, voor de supertypes en het subtype * één basisrelatie Stap 4: Omzetting van categorieën: De supertypes ‐> verschillende primaire sleutels: * artificieel indentificatorattribuut toevoegen, surrogaatsleutel * primaire sleutel van basisrelatie ‐> vreemde sleutel basisrelaties v alles supertypes De supertypes ‐> dezelfde primaire sleutel: * primaire sleutel toevoegen aan basisrelatie *in basisrelaties van alle supertypes ook gespecificeerd als vreemde sleutel Stap 5: Omzetting van binaire ‘één‐op‐één’ relatietypes: * Samenvoegen van beide basisrelaties * Behoud van beide basisrelaties, geen extra basisrelatie * behoud van beide basisrelaties, met extra basisrelatie Stap 6: Omzetting van binaire ‘één‐op‐meerdere’ relatietypes: *Primaire sleutel van de 1‐zijde toevoegen als vreemde sleutel aan de meerdere‐zijde * Enkelv., enkelw., niet‐afgeleide attr. toevoegen aan gekozen basisrelatie Stap 7: Omzetting van binaire ‘meerdere‐op‐meerdere’ relatietypes: * nieuwe basisrelatie ‐> relatienaam * primaire sleutels toevoegen als vreemde sleutels in nieuwe basisrelatie * Enkelv., enkelw., niet‐afgeleide attr. toevoegen aan gekozen basisrelatie * primaire sleutel = samenvoeging attributen van beide vreemde sleutels Stap 8: Omzetting van meerwaardige attributen: * gepaste relatienaam * primaire sleutels basisrelatie ‐> vreemde sleutel nieuwe relatie
* attributen toevoegen aan nieuwe basisrelatie om 1 waarde te kunnen opslaan * primaire sleutel = samenvoeging alle attributen Stap 9: Omzetting van n‐aire relatietypes waarbij n>2: * gepaste relatienaam * primaire sleutels basisrelatie ‐> vreemde sleutel nieuwe relatie * Enkelv., enkelw., niet‐afgeleide attr. toevoegen aan gekozen basisrelatie * primaire sleutel = samenvoeging attributen van alle vreemde sleutels ‐ Aanmaken van gedragspecificaties: Richtlijnen: Uniciteit van attribuutwaarden van dezelfde basisrelatie ‐> omzetten naar een alternatieve sleutel. Beperking op de tuples ‐> omzetten integriteitrestrictie Uitvoering complexe actie ‐> omzetten stored procedure of trigger ‐ Casestudie: database voor een jeugdvereniging ‐ Casestudie: reserveringssysteem voor een theater: ‐ Casestudie: database voor een softwarefirma: 5.2 Normalisatie Normaalvorm = kwaliteitsnorm voor basisrelaties Normalisatieproces = relatie met lagere NV ‐> opgesplitst in relaties met hogere NV ‐ Probleemstelling: Bepaalde data worden overtollig opgeslagen Overtollige data kunnen anomalieën bevatten Gegevens kunnen ongewenst verloren gaan ‐ Het normalisatieproces: 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 worden vastgelegd door de waarden van de attributen van X. Als de attribuutwaarden van X bekend zijn, zijn daardoor ook de attribuutwaarden van Y bekend. X wordt de determinant van de functionele afhankelijkheid genoemd. Een verzameling van attributen Y is irreducibel functioneel afhankelijk van een verzameling van attributen X (genoteerd X ‐> Y) als Y functioneel afhankelijk is van X en er bovendien geldt dat: 1. X en Y disjunct zijn en dus geen gemeenschappelijke attributen hebben. 2. ER geen echte deelverzameling X’ c X van X bestaat, zodat Y functioneel afhankelijk is van X’. Kan voorgesteld worden in een functioneel afhankelijkheidsdiagram Een relatie staat in eerste normaalvorm als de datatypes van al de voorkomende attributen atomair zijn. Een relatie staat in tweede normaalvorm als ze in eerste normaalvorm staat en elk attribuut van de relatie, dat geen deel uitmaakt van een kandidaat‐sleutel, irreducibel functioneel afhankelijk is van elke kandidaat‐sleutel van de relatie. Een irreducibele functionele afhankelijkheid X ‐> Z is transitief, als er een verzameling van attributen Y bestaat, die geen kandidaat‐sleutel of deelverzameling van een kandidaat‐ sleutel is, waarvoor geldt dat X ‐> Y en Y ‐> Z. Een relatie staat in derde normaalvorm als ze in tweede normaalvorm staat en elk attribuut van de relatie, dat geen deel uitmaakt van een kandidaat‐sleutel, niet transitief irreducibel functioneel afhankelijk is van een kandidaat‐sleutel van de relatie. Een relatie staat in ‘Boyce‐Codd’‐normaalvorm als ze in eerste normaalvorm staat en elke determinant een kandidaat‐sleutel is van de relatie. Een verzameling van attributen Y is meerwaardig functioneel afhankelijk van een verzameling van attributen X ( genoteerd X ‐> ‐> Y) als de waarden van de attributen van X op elk moment een collectie met meerdere waarden voor de attributen van Y vastleggen.
Een relatie staat in vierde normaalvorm als ze in ‘Boyce‐Codd’‐normaalvorm staat en geen enkele meerwaardige functionele afhankelijkheid bevat, tenzij dit de enige afhankelijkheid is die voorkomt in de relatie. 5.3 Denormalisatie Nadelen van normalisatie proces : door opsplitsen ‐> heel veel relaties extra tijd : opvraging opnieuw samenvoegen, aanpassen, verwijderen,… denormalisatie: lagere normaalvorm om betere prestaties te krijgen extra controle tegen inconsistentie van de data
Hoofdstuk 6 6.1 Overzicht Laatste ontwerpfase: fysiek databaseontwerp: databaseschema, sleutels, integriteitrestricties, stored procedures en triggers geïmplementeerd in relationeel dbms. SQL wordt hiervoor gebruikt (SQL‐scripts, DDL‐scripts, forward‐ and reverse‐engeneering,…) 6.2 Enkele voorbeschouwingen over SQL Kerntaal + pakketten Kerntaal : datadefinitietaal (DDL) en datamanipulatietaal (DML) Beschrijvende taal: niet hoe maar wat Kan worden ingebed in een hosttaal (bv:java, C/C++,…) Elke constructeur werkt met eigen dialect BNF‐notatie: zie figuur 6.3 pg 187 Identificatoren en gereserveerde woorden 6.3 Datadefinitietaal Databases: Aanmaken: CREATE SCHEMA naam [AUTHORIZATION maker] Meestal uitgebreide paramaters Verwijderen: DROP SCHEMA naam [RESTRICT|CASCADE] Restrict: enkel leeg wordt verwijderd<‐> cascade : wordt altijd verwijderd Domeinen: Aanmaken: CREATE DOMAIN naam [AS] datatype [DEFAULT defaultwaarde] [CHECK (logische_expressie)] Datatype: atomair datatyp, check: restrictie,… Ook geavanceerde opties Verwijderen en aanpassen: DROP DOMAIN naam [RESTRICT|CASCADE] ALTER DOMAIN Relaties: Aanmaken: CREATE TABLE naam ( ({kolomnaam datatype [NOT NULL][UNIQUE] [DEFAULT defaultwaarde][CHECK (logische_expressie)]} [,…]) {PRIMARY KEY (lijst_van_kolomnamen) [,]} ([UNIQUE (lijst_van_kolomnamen)] [,…]) ([FOREIGN KEY (lijst_van_kolomnamen) REFERENCES tabelnaam [ON DELETE actie] [ON UPDATA actie] [,…]) ([CHECK(logische_expressie)] [,…]) Aanpassen: ALTER TABLE naam {ADD [COLUMN] kolomnaam datatype [NOT NULL][UNIQUE] [DEFAULT defaultwaarde][CHECK (logische_expressie)] | DROP [COLUMN] kolomnaam [RESTRICT|CASCADE] | ADD [CONSTRAINT [restrictienaam]] restrictieoptie | DROP CONSTRAINT restrictienaam [RESTRICT|CASCADE] | ALTER [COLUMN] kolomnaam SET DEFAULT defaultoptie | ALTER [COLUMN] kolomnaam DROP DEFAULT} Verwijderen: DROP TABLE naam [RESTRICT|CASCADE]
Indexen: Aanmaken: CREATE [UNIQUE] INDEX indexnaam ON tabelnaam ((kolomnaam [ASC|DESC][,…])) Verwijderen: DROP INDEX indexnaam Views : Aanmaken: CREATE VIEW viewnaam [((nieuwe_kolomnaam [,…]))] AS definiërende_expressie [WITH CHECK OPTION] Verwijderen: DROP VIEW viewnaam [RESTRICT|CASCADE] 6.4 Datamanipulatietaal ‐ Instructies voor het toevoegen, aanpassen en verwijderen van data: Toevoegen van data: Toevoeging van een tuple waarvan de waarden expliciet worden opgegeven: INSERT INTO naam [(kolomlijst)] VALUES (Lijst_met_attribuutwaarden) Toevoeging van tuples die afkomstig zijn van een andere relatie: INSERT INTO naam [(kolomlijst)] (select_instructie) Toevoeging van data die afkomstig zijn uit een databestand: LOAD FROM bestand [DELIMITER karakter] INSERT INTO naam [(kolomlijst)] Aanpassen van data: UPDATE naam SET ({kolomnaam=expressie}[,…]) [WHERE zoekconditie] Verwijderen van data: DELETE FROM naam [WHERE zoekconditie] ‐ Instructies voor het opzoeken van data: SELECT [ALL|DISTINCT] {*|kolomexpressie [AS nieuwe_naam][,…]} FROM ({naam} [alias][,…]) [WHERE zoekconditie] [{GROUP BY kolomlijst}[HAVING zoekconditie]] [ORDER BY (kolomexpressie [ASC|DESC][,…])] FROM Tuple bevindt zich in de relatie waarvan de naam gegeven is WHERE Tuples moeten voldoen aan voorwaarde GROUP BY Tuples worden gegroepeerd op basis van gelijke waarden voor alle attributen die voorkomen in kolomlijst (HAVING enkele degene die aan de voorwaarde voldoen) SELECT Enkel de attributen bijgehouden die gevraagd worden (* = alle attributen) ORDER BY Tuples worden geordend op basis van hun waarden voor alle attributen die voorkomen in kolomlijst Dingen hieronder vrij simpel, niet de moeite om op teschrijven: pg’s in boek staan erbij Basisfunctionaliteit: zie pg 200 Gebruik van verschillende relaties: zie pg 202 Aggregatiefuncties: zie pg 203 Groepering: zie pg 204
Werken met geneste queries: zie pg 205 Werken met de operatoren voor unie, intersectie en verschil: 6.5 Verwerking van DML‐instructies door een databasemanagementsysteem ‐ Validatie en omzetting van een DML‐instructie: DML‐instructie gescand op fouten Vertaald naar een expressie (opgebouwd uit operatoren van de relationele algebra) zodat efficiënte optimalisatie mogelijk is zie figuur 6.6 en 6.7 pg 208‐209 ‐ Optimalisatie: Dbms zal proberen relationele expressie om te vormen naar een equivalente expressie die efficiënter werkt. Queryplan puntjes pg 211 6.6 De ‘Query‐By‐Example’‐techniek DML‐instructie wordt opgebouwd door het invullen van grafische templates die de structuur weergeven van de relaties uit de datebase. Zie figuur 6.8 pg 212
Hoofdstuk 7 7.1 Voorbeschouwing Semantisch rijkere gegevensmodellen Object = autonome entiteit Structuur en gedrag vastgelegd in objecttype ‐ Basisconcepten van het objectgeoriënteerde programmeerparadigma : Object, objecttype, toestand en gedrag: In elke objectgeoriënteerde aanpak wordt gewerkt met objecten die een complexe waarde hebben, die de toestand van het object wordt genoemd. In een systeem dat werkt met datatypes worden objecten opgebouwd via objecttypes, waarin zowel de complexe datastructuur van de toestand, als de specifieke operaties die voor het object gedefinieerd zijn, door de softwareontwikkelaars zijn vastgelegd. Inkapseling van operatoren: Slechts de signatuur van een operator wordt zichtbaar gemaakt voor de gebruikers. Het verborgen houden van de methode van de operator wordt inkapseling genoemd. Overerving en typehiërarchieën: Een ander basisconcept is overerving. Objectoriëntatie schrijft voor dat in nieuwe objecttypes een deel van de toestands‐ en gedragsspecificaties van bestaande objecttypes overgenomen kan worden. De toestand en het gedrag van het nieuwe objecttype worden dan bepaald door de combinatie van de overgenomen en de eigen specificaties. Het mechanisme dat vastlegt hoe en onder welke voorwaarden deze combinatie gebeurt, wordt het overervingsmechanisme genoemd. Operatoroverlading en –polymorfisme: Bij objectoriëntatie maakt het overervingsmechanisme het doorgaans mogelijk om overgeërfde operatoren te herdefiniëren binnen het nieuwe objecttype en daarbij de naam van de operator te behouden. Dit heet operatoroverlading. Dezelfde operatornaam verwijst dan naar verschillende operatoren (en methodes). ‐ Objectgeoriënteerde databasetechnologie : Objectpersistentie: Opnemen database ‐> persistent: worden bewaard in het computergeheugen. Naamgevingsmechanisme: unieke persistente naam Bereikbaarheidsmechanisme: object dat voorkomt in persistent object ‐> ook persist wordt gemaakt. Objectidentiteit: Elk object wordt daarom geïdentificeerd door een unieke objectidentificator (OID) die door het dbms wordt aangemaakt en toegekend. Deze identificator kan niet worden gewijzigd (ook niet door het dbms). Een objectidentificator wordt na verwijdering van het object het liefst niet meer opnieuw gebruikt door het dbms. 7.2 ODMG 3.0 ‐ Het objectmodel : Constructie van objecttypes: Objecttypes zijn opgebouwd uit bouwstenen Bouwstenen bestaat uit 1 specificatie en 1 of meerdere implementaties Literaaltypes: Modeleren van structurele kenmerken Basistypes: gehele getallen, reële getallen, boolean,…
Ook de mogelijkheid tot enumeratietypes Gestructureerde types zijn uit componenten samengesteld: datum, tijd,… Collectietypes: datacollecties: set, bag, list, array,… Interfaces: Modeleren van gedrag Klassen: Structurele kenmerken en gedragskenmerken worden vastgelegd in klasse Structuur: attributen en relaties Gedrag: operatoren Overerving: Isa‐overerving: supertype=interface, subtype= klasse of interface Subtype erft alle operatoren van het supertype Extends‐overerving: zowel super‐ als subtype = klasse Objecten en literalen: Instanties zijn waarden uit het domein Literalen zijn instanties van een literaaltype Objecten zijn instanties van een objecttype Elk object gekenmerkt door een toestand Extensies en sleutels: Extentie is de verzameling van alle persistente objecten van een objecttype Sleutel zijn 1 of meerdere attributen/relaties waarvan de waarden uniek moeten zijn voor elk object in de extentie. Integriteitsrestricties: Geen extra faciliteiten
‐ ODL :
Specificatietaal die het mogelijk maakt om logische databaseschema’s te beschrijven die zijn opgebouwd volgens de regels/voorschriften van het ODMG‐objectmodel. Taalbindingen nodig voor fysiek databaseontwerp Zie vb: figuur 7.2 pg 227 ‐ OQL : Objectbevragingstaal die enkel wordt gebruikt voor het opzoeken van data. Objectdatabase enkel doorzoeken vanuit programmeercode ‐> beperking ivm SQL Taalbindingen zorgen ervoor dat de resultaten worden voorgesteld met een datastructuur uit de programmeertaal ‐> naadloze integratie Toegangspunten tot de database: Toeganspunt: vereist bv objectnamen (persistente objecten) ,namen (extenties) Iteratorvariabelen: Als er gewerkt wordt met elementen van een collectie ‐> iteratorvariabele Aggregatieoperatoren: Min, max, sum, avg, count,… Werken met geordende collecties: Eerste, laatste of ide element oproepen Groeperen: Iteratorvariabele aangeduid met partition 7.3 SQL 3 Basis relationeel model uitgebreid tot objectrelationeel model ‐ Gebruikergedefinieerde datatypes : De type constructor ‘row’ : Aanmaken van gestructureerde tupletypes CREATE TYPE typenaam AS [ROW] (componentspecificaties) Waarden van de componenten van een tupletype bereikt met dot‐notatie CREATE TABLE tabelnaam OF typenaam
Mogelijkheid relatie op te bouwen op basis van een tupletype De type constructor ‘array’ : Aanmaken van collectietypes van het rijtype Type ARRAY[aantal_elementen] Bereiken elementen van een rij met []‐notatie ‐ Tuple‐identiteit : Tuple‐identificator is een unieke referentie naar een tuple Twee mogelijkheden: DERIVED en SYSTEM GENERATED Afgeleid van primaire sleutel of onafhankelijk door het systeem opgebouwd Aangeven bij aanmaken van een tabel: Werkwijze 1: create tabel instructie uitgebreid REF IS identificatornaam {DERIVED|SYSTEM GENERATED} Werkwijze 2: extra referentieattribuut Attribuutnaam REF(naam_tupletype)[SCOPE(tabelnaam)] VALUES FOR attribuutnaam ARE {DERIVED|SYSTEM GENERATED} Bereiken warden van de attributen van het gerefereerde tuple met ‐> notatie ‐ Inkapseling van operatoren : Signatuur van gebruikersgedef. operator toevoegen als component van tupletype METHOD operatornaam (argumentlijst) RETURNS type Moet worden gekoppeld aan implementatiecode Werkwijze 1: vindt plaats in SQL/PSM‐taal METHOD CREATE FUNCTION operatornaam (parameterlijst) RETURNS type FOR naam_tupletype AS [locale_declaratie] {functie_corpus} Werkwijze 2: vindt plaats in algemene objectgeoriënteerde programmeertaal METHOD CREATE FUNCTION operatornaam (parameterlijst) RETURNS type FOR naam_tupletype AS EXTERNAL NAME padnaam_voor_bestand LANGUAGE naam_taal Standaard ingebouwde functies Constructorfunctie T() Nieuw object o aanmaakt en teruggeeft Observatiefunctie A(o) Waarde van A in o teruggeeft Mutatorfunctie Waarden attribuut aan te passen ‐ Overerving : Overerving bij tupletypes: Tupletypes kunnen componenten en operatoren overerven van andere tt’s Verschillende supertypes dezelfde component ‐> enkel die eerst in de lijst CREATE TYPE typenaam UNDER (naam_supertype[,…]) AS [ROW] (componentspecificaties) Overerving bij de aanmaak van relaties: Nieuwe relatie erft attributen, operatoren en ook alle tuples CREATE TABLE naam_subtabel UNDER naam_supertabel ‐ Multimedia : ‘clob’: character large object Weergeven van grote karaktersequenties die samen een tekst vormen ‘blob’: binary large object Grote bitsequenties weer te geven
7.4 Logisch databaseontwerp ‐ Ontwerp van objectgeoriënteerde databaseschema’s : Stap 1: Omzetting van reguliere entiteittypes: *klassenaam : naam entiteittype * maak extentie aan voor klasse * voeg alle attributen toe: samengesteld ‐> gestructureerde datatypes meerwaardig ‐> collectietypes * maak voor sleutelattributen een sleutel aan Stap 2: Omzetting van zwakke entiteittypes: Zelfde manier al reguliere entiteittypes Alternatief: 1 identificerend relatietype ‐> attribuut daarvan M.b.v. set<struct{…}>, list<struct{…}>,… Stap 3: Omzetting van binaire relatietypes: Voor ‘één‐op‐één’ relatietypes: * toevoegen als attribuut bij één van de klasses * als relatietype attributen heeft: nieuwe klasse aanmaken (stap 4) anders bij beide een relatie toevoegen (inverse van elkaar) Voor ‘één‐op‐meerdere’ relatietypes: * toevoegen als attribuut(collectietype) bij klasse (kardinaliteit 1) * toevoegen als attribuut bij klasse (kardinaliteit meerdere) * als relatietype attributen heeft: nieuwe klasse aanmaken (stap 4) anders bij beide een relatie toevoegen (inverse van elkaar) Voor ‘meerdere‐op‐meerdere’ relatietypes: *als relatietype attributen heeft: nieuwe klasse aanmaken (stap 4) anders bij beide een relatie toevoegen (inverse van elkaar) Stap 4: Omzetting van n‐aire relatietypes waarbij n>2: * klassenaam : naam relatietype *betrokken entiteittypes ‐> relatie toegevoegd aan nieuwe klasse in klasse entiteittype eveneens inverse relatie toegevoegd *toevoegen alle attributen Stap 5: Omzetting van categorieën: moeilijkst : verwantschap tussen categorie en haar supertypes modelleren door aan haar corresponderende klasse en klassen die corresponderen met de supertypes relaties toe te voegen. Geen enkele relatie mag gespecificeerd zijn over collectietype Stap 6: Toevoeging van operatoren: Functionele beschrijving omgezet naar gedragspecificaties Uniciteit ‐> sleutels Andere ‐> vertaald naar operatoren Stap 7: Omzetting van specialisaties en generalisaties: *enkelvoudige overerving: naam supertype ‐> extends clausule * meervoudige: alle attributen, relaties en operatoren van supertypes kopiëren naar subtype (ODMG ondersteunt geen meervoudige extends) ‐ Objectrelationele mapping : (equivalent paragraaf 5.1.2) *samengestelde attributen: tupletypes *meerwaardige attributen: rijtypes * specialisaties en generalisaties: op basis van tupletypes en overerving bij tupletypes * relatietypes: referentie attributen * gedragsspecificaties: ingekapselde, gebruikersgedefinieerde operatoren
Hoofdstuk 8 8.1 Voorbeschouwing Verschillende technieken om vanuit applicaties toegang te krijgen tot databasesystemen ALTIJD gebruikt gemaakt van API (applicatieprogramma‐interface) 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. 8.2 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 met het dbms, dat op zijn beurt verantwoordelijk is voor de correcte afhandeling van de instructies en de feitelijke databasetoegang. Gebruikte programmeertaal : hosttaal ‐ ‘Embedded’ SQL : SQL‐instructies inbouwen via specifieke taalconstructies Precompiler Nadeel: databasespecifiek Ingebedde SQL‐instructies: Voorafgegaan door ‘EXEC SQL’ en beëindigt met ; of ‘END‐EXEC’ CONNECT en DISCONNECT Hostvariabelen: Enige variabelen die kunnen voorkomen in embedded SQL BEGIN DECLARE SECTION … END DECLARE SECTION Bij gebruik: naam voorafgegaan door : Foutbehandeling: Status‐ en foutcode bv. SQLCODE Cursors: Iteratorconstructie die toelaat om tuples één voor één op te halen en te verwerken DECLARE … OPEN … FETCH … CLOSE Dynamische SQL: Statische SQL vormt soms een te grote beperking DSQL vraag late binding foutcontrole en omzetting instructie gebeurt bij uitvoering ‐ SQLJ : Tegenhanger van embedded SQL API databaseonafhankelijk proberen maken 8.3 Databasetoegang via ‘call‐level’ API’s Bij een ‘call‐level’ API geschiedt de databasetoegang via aparte software die zowel communiceert met de applicatie als met het dbms. Binnenkomende functieoproepen van de applicatie worden door de software omgezet naar een intern formaat dat voor uitvoering wordt doorgegeven aan het dbms. Geretourneerde resultaten, status‐ en foutcodes worden door de software omgezet naar een dataformaat dat door de applicatie kan worden gelezen en verwerkt. Situatie van late binding ‐> laat dynamischer werken toe. Nadeel: omzetting moet elke keer opnieuw gebeuren Voordeel: eenvoudiger verschillende databases werken ‐ ODBC en JDBC : Open DataBase Connectivity: relationele DB op dbms onafhankelijke manier benaderen vanuit applicaties. Applicatieinterface, driverbeheerder en ODBC‐drivers Belangrijkste functies: zie pg. 256‐257
Java DataBase Connectivity: opvolger van ODBC Operatoren: zie pg. 257 ‐ SQL/CLI : Call Level Interface, bouwt verder op ODBC. ‘Handles’: environment‐, connection‐, statement‐, descriptionrecords. ‐ OLE DB en ADO : Object Linking and Embedding for Databases ontwikkeld om heterogene (e‐mail, rekenbladen,webpagina’s,…) databronnen op een uniforme wijze vanuit een applicatie te kunnen benaderen Wordt gewerkt met COM‐objecten Moeilijk rechtstreeks oproepen ‐> ActiveX Data Objects Data consumers, data providers en service providers blablabla 8.4 Databasetoegang via webpagina’s: ASP, JSP en PHP Dynamische webpagina’s. webpagina vernieuwd: gegevens opnieuw uit de databron opgehaald en in de pagina geladen. Web‐client = data consumer/applicatie Meest bekende : ASP(Active Server Pages) JSP(Java Server Pages) en PHP ASP en JSP ‐> ADO PHP ‐> ODBC 8.5 Databasetoegang via het J2EE‐ en .NET‐framework J2EE gericht op Java ‐> JDBC .NET ‐> OLE DB en ADO = ADO.NET ‐> ODBC.NET
Hoofdstuk 9 9.1 Mogelijke gevaren en vormen van ongeoorloofd gebruik Diefstal, fraude, schending privacy, beschadiging database en sabotage databasesysteem 9.2 Beveiligingsstrategieën Gebruikers: Alles registreren in een auditbestand (toegangscontrole vereist) Ook belangrijk om de volledige bevoegdheid te verdelen over verschillende admin’s Flow‐control (covert channel) via opeenvolging legale handelingen toch ongeoorloofd gebruik. Hardware: Diefstal, beschadiging, componenten uitgeschakeld/bijgeplaatst,… Software: Installatie‐ en werkingsvoorschriften goed volgen Beveiligingsfaciliteiten regelmatig onderhouden Toepassingsprogramma’s grondig installeren Programmeurs ‐> bewust achterpoortjes open laten (moeilijk te vinden) Data: Afgeschermd door toegangsbeperkingen Alternatief: views Afluisteren ‐> versleuteltechnieken Ook hier auditbestand 9.3 Toegangscontrole en toegangsbeperking Authenticatie is het controleproces om uit te maken of een gebruiker is wie hij of zij beweert te zijn. Aanmaken gebruikersaccount (best standaardpaswoord vervangen) CREATE USER gebruikersnaam IDENTIFIED BY wachtwoord ALTER USER gebruikersnaam IDENTIFIED BY nieuw_wachtwoord DROP USER gebruikersnaam Ook toegangsbeperkingen (zie volgende puntjes) ‐ Werken met privileges en gebruikersprofielen : Een instructie waarvoor expliciet toestemming wordt verleend, wordt een privilege genoemd. Vergetelheid ‐> minder erg dan bij bepaalde instructies verbieden i.p.v. privileges Datadefinitie <‐> datamanipulatie DAC‐toegangscontrole (Discretionary Access Control) Toekennen van privileges: GRANT {privilegelijst | ALL PRIVILEGES} ON {componentnaam |[databasenaam.]* |*.*} TO {lijst_met_gebruikersnaam|PUBLIC} [WITH GRANT OPTION] (mogen zelf mensen ook privileges geven) Mogelijkheden voor de ON‐clausule Databasecomponent Componentnaam Alle relaties uit de opgegeven database databasenaam.* Alle relaties uit de geactiveerde database * Alle relaties van alle databases *.* Belangrijkste privileges: SELECT, DELETE, INSERT, UPDATE, REFERENCES, CREATE, ALTER, DROP, INDEX, CREATE VIEW, CREATE ROUTINE en CREATE USER Privileges kunnen ook contextafhankelijk zijn (ingebouwde functies: TODAY, DAY,NOW, TERMINAL,…
GRANT {privilegelijst | ALL PRIVILEGES} ON {componentnaam |[databasenaam.]* |*.*} WHEN contextafhankelijke_condities TO {lijst_met_gebruikersnaam|PUBLIC} [WITH GRANT OPTION] Intrekken van privileges: REVOKE [GRANT OPTION FOR] {privilegelijst|ALL PRIVILEGES} ON {compenentnaam |[databasenaam.]*|*.*} FROM {lijst_met_gebruikersnamen |PUBLIC} [RESTRICT|CASCADE] restrict niet uitvoeren als verlaten privilege, cascade verlaten privileges ook intrekken Verlaten privilege is een privilege dat gegeven is door iemand die nu het GRANT privilege zelf kwijt is. Gebruikersprofielen: Een gebruikersprofiel is een benoemde verzameling van privileges, die als geheel aan een gebruiker kunnen worden toegekend. Elke toevoeging of verwijdering van privileges aan een gebruikersprofiel, beïnvloedt direct de bevoegdheden van alle gebruikers aan wie het gebruikersprofiel is toegekend. CREATE ROLE profielnaam DROP ROLE profielnaam Grant en revoke instructies aangepast (toevoegen van gebruikersprofielen) GRANT {privilegelijst | ALL PRIVILEGES | lijst_met_profielnamen} [ON {componentnaam | [databasenaam.]* |*.*}] TO {lijst_met_gebruikersnamen|lijst_met_profielnamen|PUBLIC} [WITH GRANT OPTION] REVOKE [GRANT OPTION FOR] {privilegelijst|ALL PRIVILEGES|lijst_met_profielnamen} ON {componentnaam |[databasenaam.]*|*.*} FROM {lijst_met_gebruikersnamen |PUBLIC|lijst_met_profielnamen} [RESTRICT|CASCADE] ‐ Werken met beveiligingsniveaus : Een beveiligingsniveau kan worden gezien als een label dat aangeeft hoe goed een bepaald gegeven moet worden afgeschermd. Een toegangsniveau wordt gezien als een label dat aangeeft tot welke beveiligingsniveaus een gebruiker toegang heeft. Bell en La Padula ‐> 2 beperkingen 1: Enkel lezen op kleiner of gelijk aan niveau 2: Enkel schrijven op groter of gelijk aan niveau (stereigenschap/ *‐eigenschap) MAC‐toegangscontrole (Mandatory Access Control) SQL‐> beveiligingsniveau gekoppeld aan attriuten en tuples van relaties De ‘meer‐niveau’‐relatie die correspondeert met de relatie met schema R(A1:T1,A2:T2,…,An:Tn) heeft als schema Rm(A1:T1,B1:TB,A2:T2,B2:TB,…,An:Tn,Bn:TB,B:TB) waarbij het domein van TB bestaat uit de labels van alle beschouwde beveiligingsniveaus. In het schema van de ‘meer‐niveau’‐relatie is met elk attribuut Ai;Ti,1<=i<=n een extra attribuut Bi:TB geassocieerd waarmee het beveiligingsniveau van elke attribuutwaarde van Ai wordt bijgehouden. Verder is er meestal nog een extra
afgeleid attribuut B:TB voorzien waarmee het beveiligingsniveau van elk tuple van de relatie wordt bijgehouden. Dit niveau is het laagste (minst afgeschermde) niveau van alle beveiligingsniveaus van de attribuutwaarden van het tuple. B(beveiligingsniveau) bepaalt toegankelijkheid van het tuple Bi(beveiligingsniveaus v attribuutwaarden) meer afgeschermde locale toegankelijkheid Filteren: tuples van een lager niveau worden afgeleid uit tuples van een hoger niveau Polyinstantiatie: extra tuples nodig om verschil in attribuutwaarden op verschillende niveaus te kunnen weergeven. ‐ Werken met statistische bevraging : Enkel geaggregeerde data opvragen. Technieken: aggregatie‐instructies als opzoekinstructies Benaderende resultaatwaarde Benaderende aantallen Gevoelig voor covert channels Tracker: zoekconditie die het mogelijk maakt vinden van cover channel Antitracker: query restriction (max aantal opzoekinstructies) Data swapping 9.4 Auditbestanden Acties die betrekking hebben op de database worden geregistreerd. Naam, instructie, datum, locatie, impact(before/after image),… 9.5 Versleutelen van de data Data onleesbaar en onbruikbaar maken. Welke data moeten worden versleutels? Gecommuniceerde data, data in database (niet hele database uiteraard, eerder gevoeligde data of back‐ups) Welk versleutelalgoritme moet worden gebruikt? Symmetrische algoritmen codeersleutel als decodeersleutel Snellere uitvoeringstijd, conventie 128‐bit sleutels Asymmetrische algoritmen aparte codeer‐ en decodeer sleutel Publieke sleutel algoritme Veel trager Moet de versleuteling door het dbms of door externe software gebeuren? dbms: Eenvoudig te implementeren Veel rekentijd Toepassingsprogramma’s niet aanpassen Software: ontlast dbms, date versleuteld waar wordt aangemaakt Beheer sleutels los van dbms (veiliger) Toepassingsprogramma’s telkens aanpassen + meer communicatie Wie heeft toegang tot de decodeersleutels? Verschillende (1 gestolen ‐> geen drama) Buiten database bewaren Automatisch genereren en regelmatig vernieuwen 9.6 Beveiliging via views Views houden het beschermde gedeelte van de data verborgen
Hoofdstuk 10 10.1 Transactie en OLTP ‐ Basisconcepten : 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. 2 situaties: 1: geen problemen, alles uitgevoerd, transactie bevestigd COMMIT 2: wel probleem, onderbroken, gedane werk ongedaan gemaakt ROLL‐BACK Transactiemanager: meerdere transacties te plannen en op te volgen ‐ Eigenschappen van transacties : ACID‐eigenschappen: Atomair: beschouwd als ondeelbare blokken, alles of niets eigenschap Consistent: consistentie moet bewaard blijven Isolatie: geïsoleerd van elkaar worden uitgevoerd, mogen elkaar niet beïnvloeden Duurzaam: succelvol ‐> permanent in database ‐ Werken met transacties : Impliciete transacties: volledig transparant voor de gebruiker Expliciete transactie: transactie van verscheidene impliciete transacties START TRANSACTION, COMMIT WORK, ROLLBACK WORK Werken met synchronisatiepunten Bij start en bij elke commit ‐> als teruggegaan moet worden ‐> dichtste synchropunt Gebruiker zelf tussentijds synchropunt ‐> savepoints ‐ OLTP : Online Transaction Processing genoemd 10.2 Mogelijke oorzaken van falen * Problemen door overmacht * Beschadiging of falen van hardware * Softwarefouten * Bewuste onderbreking * onachtzaamheden van de gebruikers * Sabotage of diefstal bij ongeoorloofd gebruik Soft crash (verlies volatiel primair geheugen) <‐> hard crash (verlies secundair geheugen) 10.3 Faciliteiten ter voorkoming en herstel van falen ‐ Back‐up‐ en logbestanden : Volledige database of incrementele back‐up (eerst transacties afwerken voor back‐up) Logbestand voor de niet opgeslagen aanpassingen ook te kunnen doen na restoren van oude waarden. Log bestand en back‐up apart bewaren ‐> altijd mogelijkheid tot recuperatie ‐ Beveiliging tegen stroompieken en stroomuitval : ‐ RAID‐systemen : Verschillende schijven ‐> samen 1 geheel 2 technieken: mirroring: altijd een identieke kopie (parallelle leestoegang mogelijk) striping: logisch geheel van data verdeeld over n schijven ‐> datatoegang n maal sneller 10.4 Herstel bij ‘soft crashes’ ‐ Werking van de databasebuffers : Flushing: vrijmaken van een databasebuffer Transacties op data in buffer (+ logbestand) Steal, no force strategie
Steal: dbms mag flushing uitvoeren terwijl transacties nog niet committed zijn No force: fluching mag niet veroorzaakt door impliciete of explciete COMMIT De ‘write‐ahead‐log’‐regel is een maatregel die stelt dat de ‘COMMIT’‐instructie van een transactie naar het logbestand moet worden geschreven net voor de transactie wordt afgesloten en bevestigd (‘comitted’). ‐ Controlepunten : Aanpassingen reconstrueren ‘redo’ en ‘undo’ Een controlepunt is een tijdstip waarop de database en het logbestand worden gesynchroniseerd door alle databasebuffers te ‘flushen’. ‐ Hersteltechnieken met uitgestelde aanpassing : Voor no steal strategie Verwerking van transacties door het dbms: *registreer elke transactie in het logbestand * voer instructies die database aanpassen niet uit * schrijf COMMIT naar logbestand ‐> gebruik after images om wijzigingen direct uit te voeren in de database, bevestig dan pas de transactie * transactie afgebroken? ‐> Registratie gewoon negeren Herstel na een ‘soft crash’: * Doorloop logbestand achter naar voor, stop bij laatste controlepunt Bevestiging en startinstructie? ‐> opnieuw uitvoeren (gebruik after images) * geen bevestiging? ‐> niets ‐ Hersteltechnieken met onmiddellijke aanpassing : Voor steal strategie Verwerking van transacties door het dbms: * registreer elke transactie in het logbestand * database aanpassen? ‐> before en after image opslaan onmiddellijk erna uitvoeren * eerstvolgende flushing? ‐> weggeschreven naar database * bevestiggen? ‐> commit Herstel na een ‘soft crash’: * lege undo en redo lijst * Doorloop logbestand achter naar voor, stop bij laatste controlepunt Bezig op moment van controlepunt? ‐> undo lijst * Doorloop logbestand van controlepunt naar einde Begin transactie? ‐> undo lijst Commit? ‐> van undo naar redo lijst * Doorloop nogmaals van einde naar cp Undo? ‐> before images (reverse volgorde) * Laatste maal doorlopen van cp naar einde Redo? ‐> after images (straight forward volgorde) ‐ Hersteltechnieken met schaduwpagina’s : Bewerkingen op werkpagina (schaduwpagina als back‐up) Bij commit ‐> gekopieerd naar schaduwpagina Geen logbestand, geen redo en undo zever Nadeel ‐> versnippering van schijf 10.5 Herstel bij ‘hard crashes’ * verwijder niet verloren gegane delen * laad recentste back‐up * herstel recentste consistentie (m.b.v. logbestand) Doorloop van achter naar voor: start en commit? ‐> wijzigingen uitvoeren (after image) Geen bevestiging? ‐> niets doen
Hoofdstuk 11 11.1 De behoefte aan ‘concurrency’‐controle Meerdere gebruikers tegelijkertijd ‐> meerdere transacties Parallelle transacties <‐> interleaved transacties (afwisselend, lijkt tesamen) Maatregelen nodig anders kunnen er zich bepaalde problemen voordoen ‐ ‘Lost‐update’‐problemen : De aanpassingsoperatie van de ene transactie wordt overschreven door de aanpassingsoperatie van de andere transactie ‐ ‘Uncommitted dependency’‐problemen : (dirty read) Transactie werkt met data die is aangepast door een andere transactie, echter ongeldige data: eerste transactie wordt ongedaan gemaakt (rollback) ‐ Problemen van inconsistente analyse : Transactie past gegevens aan terwijl een andere transactie nog bezig is met verwerken van deze gegevens Nonrepeatable read: dezelfde gegeven meermaals opvragen ‐> andere waarde Phantom read: dezelfde opzoekinstructie ‐> extra record in resultaat 11.2 Serialiseerbaarheid van transacties ‐ Serialiseerbaarheid : Concurrency problemen doen zich niet voor als alle transacties een seriële sequentie vormen Als een instructiesequentie van (‘gelijktijdige’) transacties via omvormingsregels kan worden omgezet naar een seriële sequentie zegt men dat de instructiesequentie serialiseerbaar is. De instructiesequentie produceert dan dezelfde resultaten als de verkregen seriële sequentie. Omvormingsregels : conflictserialiseerbaarheidsregels ‐ Werken met isolatieniveaus : Transacties worden geïsoleerd van elkaar uitgevoerd ‐> vertraging Maar kan isolatieniveau kiezen ‐> minder vertraging en toch controle Verschillende isolatieniveaus Read uncommitted Minst veilig: risico op dirty, nonrepeatable en phantom read Read committed Beveiligt tegen dirty read (nonrepeatable en phantom nog steeds mogelijk) Repeatable read Beveiligt tegen dirty en nonrepeatable read (phantom nog steeds mogelijk) Serializable Vereist: instructiesequentie serialiseerbaar ‐> speelt op veilig 11.3 ‘Timestamping’‐methoden Timestamping en locking zijn pessimistische methoden omdat ze de uitvoering van de transactie uitstellen in geval van mogelijk conflict ‐> vaak onnodige vertragingen Principe: kent prioriteiten toe aan transacties op basis van leeftijd (oud voorrang) Een ‘timestamp’ is een unieke identificator die de relatieve starttijd van een transactie aanduidt. Basisregels: * transactie wenst te lezen/aanpassen, enkel toegestaan als recenste aanpassing gebeurde door een oudere transactie * andere geval: geweigerd en ongedaan gemaakt (rollback) opnieuw gestart met een nieuwe/recentere timestamp (elk gegeven: lees‐timestamp en aanpassing‐timestamp) Protocol: 1. Transactie T wil gegeven d lezen a) Timestamp(T) rollback b) Timestamp(T)>=aanpassing‐timestamp(d) => uitvoeren + updaten lees‐timestamp
2. T wil d aanpassen a) timestamp rollback b) timestamp rollback c) andere gevallen => uitvoeren + updaten : aanpassing‐timestamp(d)=timestamp(T) De aanpassingsregel van Thomas: 2b: T negeren zonder rollback (mogelijk omdat recentere aanpassing gebaseerd op oudere waarde en dus geen problemen oplevert zolang aanpassing niet doorvoeren) Na beëindigen van T ‐> nieuwe transactie opgestart ‐> aanpassing later uitgevoerd Granulariteit: Belangrijk om weten hoe groot de data‐eenheid is Granulariteit: database, relatie, tuple of attribuut Hoe fijner granulariteit ‐> meer timestamps ‐> meer gelijktijdige transacties ‐ ‘Lost‐updates’‐problemen opnieuw bekeken : Probleem doet zich niet meer voor ‐ ‘Uncommitted dependency—problemen opnieuw bekeken : Dirty read kan zich nog steeds voordoen ‐ Problemen van inconsistente analyse opnieuw bekeken : Probleem kan zich niet meer voordoen 11.4 ‘Locking’‐methoden Principe: voor transactie data kan lezen/aanpassen eerst een gepaste lock verkrijgen ‐> beperking dus voor andere transacties, op einde terug vrijgeven. Een ‘lock’ is een soort van reservering op een gegeven, waardoor een transactie een exclusieve of gedeelde toegang tot het gegeven krijgt en de gewenste operatie kan uitvoeren. Exclusieve(write) en gedeelde(read) ‘locks’: Exclusieve lock: reservering exclusief, alle andere transacties moeten wachten Gedeelde lock: reservering niet exclusief, andere transacties kunnen ook een gedeelde lock op gegeven verkrijgen. Transactie: gedeelde lock ‐> enkel lezen Basisregels: * transactie wil lezen? ‐> eerst gedeelde lock verkrijgen * transactie wil aanpassen? ‐> eerst exclusieve lock verkrijgen Protocol: 1. lezen? ‐> gedeelde lock verkrijgen ‐> mag geen exclusieve lock zijn op gegeven 2. aanpassen? ‐> exclusieve lock verkrijgen ‐> mag geen gedeelde of exclusieve lock zijn op gegeven. Als transactie enige is die gedeelde lock heeft ‐> gepromoveerd 3. lock‐aanvraag gaat niet direct? ‐>in wachttoestand plaatsen, wel ervoor zorgen dat niet eeuwig moet wachten (livelock) 4. locks worden vrijgegeven aan het einde van de transactie Het ‘twee‐fase locking’‐protocol houdt in dat een transactie kan worden opgedeeld in twee fasen. In de eerste fase, die we de groeifase noemen, kan de transactie ‘locks’ aanvragen en toegekend krijgen. In de tweede fase, de krimpfase, worden de verkregen ‘locks’ vrijgegeven. Tijdens de krimpfase kan de transactie geen nieuwe ‘locks’ meer verkrijgen. Het ‘twee‐fase locking’‐theorema: Als alle transacties werken volgens het ‘twee‐fase locking’‐protocol, dan zijn de instructiesequenties van alle ‘gelijktijdige’ uitvoeringen van deze transacties serialiseerbaar. Granulariteit: Wederom grootte van de data‐eenheid Hoe fijner granulariteit ‐> meer locks ‐> meer gelijktijdige transacties ‐ ‘Lost‐updates’‐problemen opnieuw bekeken : Probleem kan zich niet meer voordoen
In ons voorbeeld zijn beide transacties echter in een wachttoestand gekomen waarbij de ene transactie wacht op een actie van de andere ‐> deadlock ‐ ‘Uncommitted dependency—problemen opnieuw bekeken : Probleem kan zich niet meer voordoen ‐ Problemen van inconsistente analyse opnieuw bekeken : Probleem kan zich niet meer voordoen Ook hier weer deadlock in ons voorbeeld 11.5 ‘Deadlock’ Een ‘deadlock’ is een situatie waarbij twee of meer transacties tegelijkertijd in een wachttoestand verkeren en elk van deze transacties, om zelf verder te kunnen werken, wacht op het moment dat één van de andere transacties ‘locks’ vrijgeeft. Dbms moet ingrijpen! ‘Deadlock’‐detectie: Met behulp van een ‘wacht‐voor’‐graaf: gerichte graaf‐> knopen zijn transacties Gerichte boog: knoop A ‐> knoop B duidt aan dat A wacht op het vrijgeven van lock van B deadlock doet zich voor als er een cyclus is in de graaf brengt bijkomende vertraging met zich mee, vaak slechts na verloop van tijd gebeuren ‐> goed inschatten, soms te vroeg ‐> veel overhead, soms te laat ‐> al lang in deadlock beter gebruik maken van variabele tijdsduur bij controle: geen deadlock? ‐> langer interval, wel deadlock? ‐> korter interval soms wordt er ook met een eenvoudige time‐out gewerkt i.p.v. met ‘wacht‐voor’‐graaf ‘Deadlock’‐herstel: Één transactie afbreken (rollback) ‐> locks vrijgegeven ‐> later opnieuw opstarten Criteria tot slachtoffer keuze: recentste, minste wijzigingen heeft uitgevoerd tot nu toe, bij meerdere deadlocks ‐> transactie gekozen als slachtoffer, die de meeste locks vrijgeeft Wel opletten starvation (telkens hetzelfde slachtoffer bij opeenvolgende deadlocks) ‘Deadlock’‐preventie: * ‘wait‐die’‐techniek: Enkel oudere transacties mogen wachten op jongere transacties Als jongere moet wachten ‐> onmiddellijk afgebroken (rollback) Opnieuw gestart met dezelfde timestamp ‐> anders wordt de transactie niet ouder * ‘wound‐wait’‐techniek: Enkel jongere transactie mogen wachten op oudere transacties Als oudere moet wachten ‐> onmiddellijk afgebroken (rollback) Opnieuw gestart met nieuwe timestamp ‐> anders altijd afgebroken 11.6 Optimistische methoden Principe: veronderstel dat conflicten weinig voorkomen, laten transactie wel uitvoeren, net voor succesvol beëindigen/bevestigen van transactie ‐> controle (minder vertraging) Enkel interessant als er effectief weinig ‘concurrency’‐problemen voorkomen, anders brengt rollback en opnieuw opstarten een te grote overhead met zich mee Protocol: 1. Leesfase: leest en kopie ‐> bewerkingen op kopie (tot net voor commit van de transactie) 2. Valideerfase: lees/aanpassingsoperaties serialiseerbaarheid verhinderen? Elke transactie A ‐> timestamp start(A), validatie(A) en einde(A) Slagen validatietest? Voldoen aan 1 van volgende voorwaarden a) start(A)<start(B) ‐> einde(A)<start(B) b) start(B)<einde(A) ‐> geen enkele gegeven die aangepast werd door A gelezen worden door B EN start(B)<einde(A) rollback en opnieuw starten anders gewoon schrijffase 3. Schrijffase: eventuele aanpassingen in kopieën overgezet ‐> succesvol? ‐> commit
