samenvatting

K, dit is mijn laatste update.
Deze is wel iets anders dan de vorigen. De vorigen waren foutcorrecties, deze is bedoeld om details in te vullen.
Normaalgezien is een samenvatting altijd minder gedetailleerd dan de cursus, maar kan da geen kwaad.
Soms echter is de prof een oud fosiel die geen relevante vragen kan stellen maar alleen maar mierenneuken op details, en in dat geval is mijn samenvatting niet gedetaileerd genoeg.
Let op, ik zeg niet dat de prof een oud fosiel is, maar toch, ik heb heel de boek doorlezen om nog wa details toe te voegen aan mijn samenvatting.

p1.2 Hier moeten nog een paar bijkomende definities komen:
   De connection trap: 3 binaire relaties zijn niet equivalent aan n ternaire relatie:
      maw het volgende:
         A levert onderdeel B;
         A levert aan project C;
         Onderdeel B wordt geleverd aan project C;
      zegt minder dan
         A levert onderdeel B aan project C.
   Het data-model is de abstracte, logische definitie vd objecten waaruit de data opgebouwd is.
   De implementatie is de fysische realisatie vh data-model op een gegeven machine.
p3.1 Het feit dat het resultaat van elke bewerking op de tabellen steeds een tabel is is de relationele closure.
p6.4 Bij "relaties vs. tabellen": de interpretation rules zijn de regels die we nodig hebben om een tabel als een voorstelling ve relatie te aanvaarden.
p7.1 Bij de inleiding: We kunnen de operatoren indelen in 2 groepen:
      De eerste 4 (unie, doorsnede, verschil en carth. prod) zijn (aangepaste versies) vd wiskundige set-operatoren.
      De laatste 4 (restrict, project, join, divide) zijn operatoren specifiek gedefinieerd voor relationele brol.
   Van de 4 set-operatoren moeten we natuurlijk nog zeggen in hoeverre ze aangepast zijn:
      De unie-, doorsnede- en verschil-operatoren moeten in een relationele context inwerken op twee relaties van hetzelfde type. In wiskundige context is dit niet vereist.
      Het cartesiaans product levert in een wiskundige context geordende sets op, dus wiskundig is a*b <> b*a. In relationeel opzicht zijn deze gelijk, omdat er geen ordening vd attributen is.
p12.2 Die eerste stelling (Gegeven een relvar R... gelijk aan de join van zijn projecties...) heet Heathis' theorema.
Verder is de definitie van 1NF niet 100% correct; beter is:
   Een relvar R is in 1NF aesa voor elke toegelaten waarde voor R elk tuple t van R exact n waarde voor elk attribuut heeft.
p12.5 Onderaan "5. Dependency preservation" voeg je de volgende definitie toe:
   Een relvar R is atomair aesa er geen onafhankelijke, niet-triviale verliesloze decompositie van R op R1 en R2 bestaat.
p13.2 Boven "1.2. De vierde normale vorm" voeg je toe:
   Het theorema van Fagin zegt ons dat een relvar R met samengestelde attributen A,B,C gelijk is aan de unie van zijn projecties op {A,B} en {A,C} aesa de MVD's
      A->->B|C
   voldaan zijn.
p13.3 Die laatste eigenschap is eigenlijk een herformulering van het theorema van Fagin.
p15.5 Nog wat extra uitleg bij commit in 2 fases:
   Fase1: De prepare fase: Het mainframe ontvant OK of NIET-OK van beide databases. Een database geeft OK aesa de transactie goed uitgevoerd is n hij zijn write-ahead log reeds weggeschreven heeft.
   Fase2: De commit fase: Als hij tweemaal OK ontvangen heeft schrijft hij zelf een recovery-log weg met zijn beslissing (om commit uit te voeren) erin. Vervolgens geeft hij beide databases zijn beslissing door.
p16.2 Voeg puntje "1.5 nader bekeken" toe, met als inhoud:
   RR: Transactie A leest een waarde, die achteraf ook door B gelezen wordt -> Dit levert geen problemen op.
   RW: niet-herhaalbare lezing: A leest, en B overschrijft dit vervolgens. A werkt dus met een "verouderde" waarde.
   WR: Dirty read: A schrijft, B leest vervolgens. Als A een ROLLBACK uitvoert, hebben we het "ontuitgevoerde afhankelijkheidsprobleem".
   WW: Dirty Write: A schrijft, en B schrijft vervolgens. Het schrijven van A is dus verloren (lost update).
p16.3 Voeg vlak boven "2.2" de volgende definitie toe:
   We hebben starvation (ook livelock genaamd) aesa B eeuwig wacht op het vrijgeven van een lock (dit kan zijn omdat A het nooit vrijgeeft, of omdat C,D,... altijd voorkruipen)
p16.5 Onderste stuk van "4. Serialiseerbaarheid" is het 2-fasige locking theorema.
p16.7 Bij "7.Intent Locking" definiren we locking granularity als het leggen van locks op iets anders dan een tuple.
p16.8 Definitie: lock escalation: Als we teveel granulaire locks op nzelfde relvar krijgen (bv massa's IS), dan vervangen sommige databases al deze locks door n globale lock op de relvar (in ons voorbeeld door 1 'S'-lock).
   Dit om locking-overhead te verminderen...
p17.3 Voeg onderaan "2.3: Audit trails" toe:
      Een audit trail is een log die alle uitgevoerde operaties op de database (tesamen met gebruiker, computer, tijdsstip,...) bijhoudt.
   Deze log kan dan via de gewone DML opgevraagd worden (tenminste, als je daar toestemming voor hebt). Hierdoor kan je zien wie wat uitgespookt heeft.
p17.5 Onderaan "3.3" voeg je toe:
   poly-instantiation hebben we als dezelfde data er anders uitziet voor verschillende gebruikers (dus tgv BNiveau).

That's it, ik hoop dat dit wat nuttig is,
groetjes,
...

ps sorry dat dit zo laat is maar een boek van 550pagina's lees je niet eventjes op 3uur...