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 = <veldwaarde,referentie>     ! 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 ien 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)<aanpassing‐timestamp(d) => rollback   b) Timestamp(T)>=aanpassing‐timestamp(d) => uitvoeren + updaten lees‐timestamp 

2. T wil d aanpassen   a) timestamp<lees‐timestamp(d)  => rollback    b) timestamp<aanpassing‐timestamp(d) => 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)<validatie(B) 

      Niet geslaagd? ‐> rollback en opnieuw starten anders gewoon schrijffase 3. Schrijffase: eventuele aanpassingen in kopieën overgezet ‐> succesvol? ‐> commit