Kapitel 9+10

Datenbanksysteme.md

@@ -1198,13 +1198,429 @@ Motivation: Die Sprache QBE
 
 # Transaktionen, Integrität und Trigger
 ## Grundbegriffe
+Integritätsbedingung (engl. integrity constraint oder assertion): Bedingung für die „Zulässigkeit“ oder „Korrektheit“
+
+1. Typintegrität
+    - SQL erlaubt Angabe von Wertebereichen zu Attributen
+    - Erlauben oder Verbieten von Nullwerten
+2. Schlüsselintegrität
+    - Angabe eines Schlüssels für eine Relation
+3. Referentielle Integrität
+    - die Angabe von Fremdschlüsseln
+
 ## Transaktionsbegriff
+Beispiel:
+- Platzreservierung für Flüge gleichzeitig aus vielen Reisebüros → Platz könnte mehrfach verkauft werden, wenn mehrere Reisebüros den Platz als verfügbar identifizieren
+- überschneidende Kontooperationen einer Bank
+- statistische Datenbankoperationen → Ergebnisse sind verfälscht, wenn während der Berechnung Daten geändert werden
+
+> Transaktion: Eine Transaktion ist eine Folge von Operationen (Aktionen), die die Datenbank von einem konsistenten Zustand in einen konsistenten, eventuell veränderten, Zustand überführt, wobei das ACID-Prinzip eingehalten werden muss.
+- Aspekte:
+  - Semantische Integrität: Korrekter (konsistenter) DB-Zustand nach Ende der Transaktion
+  - Ablaufintegrität: Fehler durch "gleichzeitigen" Zugriff mehrerer Benutzer auf dieselben Daten vermeiden
+
+ACID-Eigenschaften
+- Atomicity (Atomarität): Transaktion wird entweder ganz oder gar nicht ausgeführt
+- Consistency (Konsistenz oder auch Integritätserhaltung): Datenbank ist vor Beginn und nach Beendigung einer Transaktion jeweils in einem konsistenten Zustand
+- Isolation (Isolation): Nutzer, der mit einer Datenbank arbeitet, sollte den Eindruck haben, dass er mit dieser Datenbank alleine arbeitet
+- Durability (Dauerhaftigkeit / Persistenz): nach erfolgreichem Abschluss einer Transaktion muss das Ergebnis dieser Transaktion „dauerhaft“ in der Datenbank gespeichert werden
+
+Kommandos einer Transaktionssprache
+- Beginn einer Transaktion: Begin-of-Transaction-Kommando BOT (in SQL implizit!)
+- commit: die Transaktion soll erfolgreich beendet werden
+- abort: die Transaktion soll abgebrochen werden
+
+Vereinfachtes Modell für Transaktion
+- Repräsentation von Datenbankänderungen einer Transaktion
+  - `read(A,x)`: weise den Wert des DB-Objektes A der Variablen x zu
+  - `write(x, A)`: speichere den Wert der Variablen x im DB-Objekt A
+- Beispiel einer Transaktion T:
+  - `read(A, x); x := x − 200; write(x, A);`
+  - `read(B, y); y := y + 100; write(y, B);`
+- Ausführungsvarianten für zwei Transaktionen T_1 , T_2 :
+  - seriell, etwa T_1 vor T_2
+  - „gemischt“, etwa abwechselnd Schritte von T_1 und T_2
+- Probleme im Mehrbenutzerbetrieb
+  - Inkonsistentes Lesen: Nonrepeatable Read
+    - Variablen/Speicher ändert sich durch fertigstellen anderer Transaktionen während des Ablaufs
+  - Abhängigkeiten von nicht freigegebenen Daten: Dirty Read
+    - T_1 ändert X
+    - T_2 liest X und rechnet damit
+    - T_1 bricht ab und setzt änderung zurück
+    - Ergebnis von T_2 ist damit falsch
+  - Das Phantom-Problem
+    - durch `insert` ändert sich `select` ergebnis; nachfolgende rechnungen auf vorherigen abruf sind falsch
+  - Verlorengegangenes Ändern: Lost Update
+    - updates gehen verloren, wenn gleiche Variablen gleicheitig beschrieben werden (oder kurz nacheinander)
+
+> Serialisierbarkeit: Eine verschränkte Ausführung mehrerer Transaktionen heißt serialisierbar, wenn ihr Effekt identisch zum Effekt einer (beliebig gewählten) seriellen Ausführung dieser Transaktionen ist.
+- Schedule: "Ablaufplan" für Transaktion, bestehend aus Abfolge von Transaktionsoperationen
+
 ## Transaktionen in SQL
+Aufweichung von ACID in SQL: Isolationsebenen
+```sql
+set transaction
+  [ { read only | read write }, ]
+  [isolation level
+    { read uncommitted |
+      read committed |
+      repeatable read |
+      serializable }, ]
+  [ diagnostics size ...]
+```
+Standardeinstellung:
+```sql
+set transaction read write,
+  isolation level serializable
+```
+
+Bedeutung der Isolationsebenen
+- **read uncommitted**
+  - schwächste Stufe: Zugriff auf nicht geschriebene Daten, nur für read only Transaktionen
+  - statistische und ähnliche Transaktionen (ungefährer Überblick, nicht korrekte Werte)
+  - keine Sperren → effizient ausführbar, keine anderen Transaktionen werden behindert
+- **read committed**: nur Lesen endgültig geschriebener Werte, aber nonrepeatable read möglich
+- **repeatable read**: kein nonrepeatable read, aber Phantomproblem kann auftreten
+- **serializable**: garantierte Serialisierbarkeit
+
+
 ## Integritätsbedingungen in SQL
+- **not null**: Nullwerte verboten
+- **default**: Angabe von Default-Werten
+- **check** ( search-condition ):
+    - Attributspezifische Bedingung (in der Regel Ein-Tupel-Integritätsbedingung) 
+    - Festlegung weitere lokale Integritätsbedingungen innerhalb der zu definierenden Wertebereiche, Attribute und Relationenschemata
+    - Beispiel:
+      ```sql
+      create table WEINE (
+        WeinID int primary key,
+        Name varchar(20) not null,
+        Jahr int check(Jahr between 1980 and 2010),
+        ...
+      )
+      ```
+- **primary key**: Angabe eines Primärschlüssel
+- **foreign key** ( Attribut(e) ) **references** Tabelle( Attribut(e) ): Angabe der referentiellen Integrität
+- **create domain**: Festlegung eines benutzerdefinierten Wertebereichs
+    - Beispiel:
+      ```sql
+        create domain WeinFarbe varchar(4)
+          default 'Rot'
+          check (value in ('Rot', 'Weiß', 'Rose'))
+
+        create table WEINE ( WeinID int primary key, Name varchar(20) not null, Farbe WeinFarbe, ...)
+      ```
+
+Erhaltung der referentiellen Integrität
+- Überprüfung der Fremdschlüsselbedingungen nach Datenbankänderungen
+- Überprüfungsmodi von Bedingungen
+  - `on update | delete`: Angabe eines Auslöseereignisses, das die Überprüfung der Bedingung anstößt
+  - `cascade | set null | set default | no action`: Kaskadierung: Behandlung einiger Integritätsverletzungen pflanzt sich über mehrere Stufen fort, z.B. Löschen als Reaktion auf Verletzung der referentieller Integrität
+  - `deferred | immediate` legt Überprüfungszeitpunkt für eine Bedingung fest
+    - `deferred`: Zurückstellen an das Ende der Transaktion
+    - `immediate`: sofortige Prüfung bei jeder relevanten Datenbankänderung
+  - Beispiel: `... foreign key (Weingut) references ERZEUGER (Weingut) on delete cascade`
+
+Die assertion-Klausel
+- Assertion: Prädikat, das eine Bedingung ausdrückt, die von der Datenbank immer erfüllt sein muss
+- Syntax (SQL:2003) `create assertion name check ( prädikat )`
+
 ## Trigger
+- Trigger: Anweisung/Prozedur, die bei Eintreten eines bestimmten Ereignisses automatisch vom DBMS ausgeführt wird
+- Anwendung:
+  - Erzwingen von Integritätsbedingungen („Implementierung“ von Integritätsregeln)
+  - Auditing von DB-Aktionen
+  - Propagierung von DB-Änderungen
+- Definition:
+  ```sql
+    create trigger ...
+    after Operation
+    Anweisungen
+  ```
+- Beispiel: Einfügen von neuen Aufträgen
+  ```sql
+  create trigger Auftragszählung+
+    on insertion of Auftrag A:
+    update Kunde
+    set AnzAufträge = AnzAufträge + 1
+    where KName = new A.KName
+
+  create trigger Auftragszählung-
+    on deletion ...:
+    update ...- 1 ...
+  ```
+- Spezifikation von
+  - Ereignis und Bedingung für Aktivierung des Triggers
+  - Aktion(en) zur Ausführung
+- Syntax in SQL:2003 festgelegt
+  ```sql
+  create trigger Name
+  after | before Ereignis
+  on Relation
+  [ when Bedingung ]
+  begin atomic SQL-Anweisungen end
+  ```
+- verfügbar in den meisten kommerziellen Systemen (aber mit anderer Syntax)
+- Weitere Angaben bei Triggern
+  - **for each row** bzw. **for each statement**: Aktivierung des Triggers für jede Einzeländerungen einer mengenwertigen Änderung oder nur einmal für die gesamte Änderung
+  - **before** bzw. **after**: Aktivierung vor oder nach der Änderung
+  - **referencing new as** bzw. **referencing old as**: Binden einer Tupelvariable an die neu eingefügten bzw. gerade gelöschten („alten“) Tupel einer Relation ⇝ Tupel der Differenzrelationen
+
+Integritätssicherung durch Trigger
+1. Bestimme Objekt $o_i$ , für das die Bedingung $\phi$ überwacht werden soll
+  - i.d.R. mehrere $o_i$ betrachten, wenn Bedingung relationsübergreifend ist
+  - Kandidaten für $o_i$ sind Tupel der Relationsnamen, die in $\phi$ auftauchen
+2. Bestimme die elementaren Datenbankänderungen $u_{ij}$ auf Objekten $o_i$ , die $\phi$ verletzen können
+  - Regeln: z.B. Existenzforderungen beim Löschen und Ändern prüfen, jedoch nicht beim Einfügen etc.
+3. Bestimme je nach Anwendung die Reaktion $r_i$ auf Integritätsverletzung
+  - Rücksetzen der Transaktion (rollback)
+  - korrigierende Datenbankänderungen
+4. Formuliere folgende Trigger:
+  `create trigger t-phi-ij after u ij on o i when ¬φ begin r i end`
+5. Wenn möglich, vereinfache entstandenen Trigger
+
+Trigger in Oracle: Arten
+- Prädikat zur Einschränkung (when)
+- Zugriff auf altes (:old.col) bzw. neues (:new.col) Tupel
+  - für delete: nur (:old.col)
+  - für insert: nur (:new.col)
+  - in when-Klausel nur (new.col) bzw. (old.col)
+- Transaktionsabbruch durch raise_application_error(code, message)
+- Unterscheidung der Art der DML-Anweisung
+  - `if deleting then ... end if;`
+  - `if updating then ... end if;`
+  - `if inserting then ... end if;`
+
 ## Schemaevolution
+- Änderung eines Datenbankschemas durch neue/veränderte Anforderungen
+  - Hinzufügen oder Löschen von Tabellen, Spalten, Integritätsbedingungen
+  - Umbenennen oder Datentypänderungen
+- erfordert oft auch Anpassung/Übertragung der vorhandenen Datenbank ⇝ Datenbankmigration
+- leider nur eingeschränkte Unterstützung durch DB-Werkzeuge (DDL + Export/Import der Daten)
+
+- SQL-DDL zum Löschen von Tabellen
+  - Löschen von Tabellendefinitionen (beachte Unterschied zu delete)
+    `drop table relationenname [ restrict | cascade ]`
+  - cascade: erzwingt Löschen aller Sichten und Integritätsbedingungen, die zu dieser Basisrelation gehören
+  - restrict (Defaultfall): das drop-Kommando wird zurückgewiesen, falls noch solche Sichten und Integritätsbedingungen existieren
+- SQL-DDL zur Änderung von Tabellen
+  - `alter table relationenname modifikation`
+  - **add column spaltendefinition** fügt eine neue Spalte hinzu; alle bereits in der Tabelle existierenden Tupel erhalten als Wert der neuen Spalte den angegebenen Defaultwert bzw. den null-Wert
+  - **drop column spaltenname** löscht die angegebene Spalte (inkl. restrict- bzw. cascade)
+  - **alter column spaltenname set default defaultwert** verändert Defaultwert der Spalte
+- Änderung von Integritätsbedingungen
+  - nachträgliches Hinzufügen/Löschen von Tabellenbedingungen über **alter table**
+  - Vergabe von Namen für Bedingungen über constraint bed-name-Klausel
+    ```sql
+    alter table WEINE
+      add constraint WeinBed_Eindeutig
+      unique (Name, Weingut)
+    ```
+  - Löschen über Namen `alter table WEINE drop constraint WeinBed_Eindeutig`
 
 # Sichten und Zugriffskontrolle
+## Sichtenkonzept
+> Sichten: virtuelle Relationen (bzw virtuelle Datenbankobjekte in anderen Datenmodellen) (englisch view)
+- Sichten sind externe DB-Schemata folgend der 3-Ebenen-Schemaarchitektur
+  - Sichtdefinition
+    - Relationenschema (implizit oder explizit)
+    - Berechnungsvorschrift für virtuelle Relation, etwa SQL-Anfrage
+- Vorteile
+  - Vereinfachung von Anfragen für den Benutzer der Datenbank, etwa indem oft benötigte Teilanfragen als Sicht realisiert werden
+  - Möglichkeit der Strukturierung der Datenbankbeschreibung, zugeschnitten auf Benutzerklassen
+  - logische Datenunabhängigkeit ermöglicht Stabilität der Schnittstelle für Anwendungen gegenüber Änderungen der Datenbankstruktur
+  - Beschränkung von Zugriffen auf eine Datenbank im Zusammenhang mit der Zugriffskontrolle
+- Probleme
+  - automatische Anfragetransformation
+  - Durchführung von Änderungen auf Sichten
+- Definition von Sichten in SQL
+  ```sql
+    create view SichtName [ SchemaDeklaration ]
+    as SQLAnfrage
+    [ with check option ]
+  ```
+- Beispiel: alle Rotweine aus Bordeaux
+  ```sql
+  create view Rotweine as
+    select Name, Jahrgang, WEINE.Weingut
+    from WEINE natural join ERZEUGER
+    where Farbe = 'Rot' and Region = 'Bordeaux'
+  ```
 
+## Änderungen auf Sichten
+Kriterien für Änderungen auf Sichten
+- Effektkonformität: Benutzer sieht Effekt als wäre die Änderung auf der Sichtrelation direkt ausgeführt worden
+- Minimalität: Basisdatenbank sollte nur minimal geändert werden, um den erwähnten Effekt zu erhalten
+- Konsistenzerhaltung: Änderung einer Sicht darf zu keinen Integritätsverletzungen der Basisdatenbank führen
+- Respektierung des Datenschutzes: Wird die Sicht aus Datenschutzgründen eingeführt, darf der bewusst ausgeblendete Teil der Basisdatenbank von Änderungen der Sicht nicht betroffen werden
+
+Projektionssicht: $WNW:=\pi_{WeinID, Name, Weingut}(WEINE)$
+- in sql mit create view Anweisung
+  `create view WNW as select WeinID, Name, Weingut from WEINE`
+- Änderungsanweisung für die Sicht WNW:
+  `insert into WNW values (3333, 'Dornfelder', 'Müller')`
+  - Problem der Konsistenzerhaltung falls Farbe oder Jahrgang als not null deklariert!
+
+Selektionssichten: $WJ:=\sigma_{Jahrgang>2000}(\pi_{WeinID, Jahrgang}(WEINE))$
+  ```sql
+  create view WJ as
+  select WeinID, Jahrgang
+  from WEINE
+  where Jahrgang > 2000
+  ```
+
+Kontrolle der Tupelmigration
+```sql
+create view WJ as
+select WeinID, Jahrgang
+from WEINE
+where Jahrgang > 2000
+with check option
+```
+
+Verbundsichten $WE := WEINE \bowtie ERZEUGER$
+- In SQL:
+  ```sql
+  create view WE as
+  select WeinID, Name, Farbe, Jahrgang,
+    WEINE.Weingut, Anbaugebiet, Region
+  from WEINE, ERZEUGER
+  where WEINE.Weingut = ERZEUGER.Weingut
+  ```
+- Änderungsoperationen hier in der Regel nicht eindeutig übersetzbar:
+  `insert into WE values (3333, 'Dornfelder', 'Rot', 2002, 'Helena', 'Barossa Valley', 'Südaustralien')`
+- Änderung wird transformiert zu
+  `insert into WEINE values (3333, 'Dornfelder', 'Rot', 2002, 'Helena')`
+- plus Änderung auf ERZEUGER !
+
+Aggregierungssichten
+  ```sql
+  create view FM (Farbe, MinJahrgang) as
+  select Farbe, min(Jahrgang)
+  from WEINE
+  group by Farbe
+  ```
+- Folgende Änderung ist nicht eindeutig umsetzbar:
+  ```sql
+  update FM
+  set MinJahrgang = 1993
+  where Farbe = 'Rot'
+  ```
+
+Klassifikation der Problembereiche
+1. Verletzung der Schemadefinition (z.B. Einfügen von Nullwerten bei Projektionssichten)
+2. Datenschutz: Seiteneffekte auf nicht-sichtbaren Teil der Datenbank vermeiden (Tupelmigration, Selektionssichten)
+3. nicht immer eindeutige Transformation: Auswahlproblem 
+4. Aggregierungssichten (u.a.): keine sinnvolle Transformation möglich
+5. elementare Sichtänderung soll genau einer atomaren Änderung auf Basisrelation entsprechen: 1:1-Beziehung zwischen Sichttupeln und Tupeln der Basisrelation (kein Herausprojizieren von Schlüsseln)
+
+SQL-92-Standard
+- Integritätsverletzende Sichtänderungen nicht erlaubt
+- datenschutzverletzende Sichtänderungen: Benutzerkontrolle (with check option)
+- Sichten mit nicht-eindeutiger Transformation: Sicht nicht änderbar (SQL-92 restriktiver als notwendig)
+
+Einschränkungen für Sichtänderungen
+- änderbar nur Selektions- und Projektionssichten (Verbund und Mengenoperationen nicht erlaubt)
+- 1:1-Zuordnung von Sichttupeln zu Basistupeln: kein distinct in Projektionssichten
+- Arithmetik und Aggregatfunktionen im select-Teil sind verboten
+- genau eine Referenz auf einen Relationsnamen im from-Teil erlaubt (auch kein Selbstverbund)
+- keine Unteranfragen mit „Selbstbezug“ im where-Teil erlaubt (Relationsname im obersten SFW-Block nicht in from-Teilen von Unteranfragen verwenden)
+- group by und having verboten
+- seit SQL:2003 Aufhebung einiger Einschränkungen, insbesondere
+  - updates auf union all-Sichten (ohne Duplikateliminierung)
+  - Inserts in Verbundsichten mit Primär-/Fremdschlüsselbeziehungen (mit einigen Einschränkungen)
+  - Updates auf Verbundsichten mit Cursor 
+
+Alternative: Sichtänderungen mit Instead-of-Triggern
+- Definition von Triggern auf Sichten zur anwendungsspezifischen Propagierung der Änderungen auf die Basistabellen
+```sql
+create view V_WEINERZEUGER as
+  select * from WEINE natural join ERZEUGER;
+create trigger V_WEINERZEUGER_Insert
+  instead of insert on V_WEINERZEUGER
+referencing new as N
+for each row
+begin
+  insert into WEINE values (:N.WeinID, :N.Name,
+  :N.Farbe, :N.Jahrgang, :N.Weingut);
+end;
+```
+
+Auswertung von Anfragen an Sichten
+- select: Sichtattribute evtl. umbenennen bzw. durch Berechnungsterm ersetzen
+-  from: Namen der Originalrelationen
+- konjunktive Verknüpfung der where-Klauseln von Sichtdefinition und Anfrage (evtl. Umbenennungen)
+- Vorsicht bei Aggregationssichten!
+  - having versus where
+  - keine geschachtelten Aggregationen in SQL
+
+## Rechtevergabe
+- Zugriffsrechte (AutorisierungsID, DB-Ausschnitt, Operation)
+- AutorisierungsID ist interne Kennung eines „Datenbankbenutzers“
+- Datenbank-Ausschnitte: Relationen und Sichten
+- DB-Operationen: Lesen, Einfügen, Ändern, Löschen
+
+```sql
+grant Rechte
+on Tabelle
+to BenutzerListe
+[with grant option]
+```
+- In Rechte-Liste: all bzw. Langform all privileges oder Liste aus select, insert, update, delete
+- Hinter on: Relationen- oder Sichtname
+- Hinter to: Autorisierungsidentifikatoren (auch public, group)
+- spezielles Recht: Recht auf die Weitergabe von Rechten (with grant option)
+
+Autorisierung für public: „Jeder Benutzer kann seine Aufträge sehen und neue Aufträge einfügen (aber nicht löschen!).“
+```sql
+create view MeineAufträge as
+select *
+from AUFTRAG
+where KName = user;
+grant select, insert
+on MeineAufträge
+to public;
+```
+
+Zurücknahme von Rechten
+```sql
+revoke Rechte
+on Tabelle
+from BenutzerListe
+[restrict | cascade ]
+```
+- restrict: Falls Recht bereits an Dritte weitergegeben: Abbruch von revoke
+- cascade: Rücknahme des Rechts mittels revoke an alle Benutzer propagiert, die es von diesem Benutzer mit grant erhalten haben
+
+
+## Privacy-Aspekte
+> Privacy (Privatsphäre): das Recht jedes Einzelnen auf einen geschützten privaten Raum, der von anderen nur in definierten Ausnahmefällen verletzt werden darf
+- elektronische Autobahn-Mautsysteme: Überwachung von Fahrzeugen
+- Kreditkartenaktivitäten und diverse Payback- bzw. Rabattkarten: Kaufverhalten von Kunden
+- Mobilfunksysteme: Bewegungsprofile der Nutzer
+- RFID-Technologie: etwa im Einzelhandel Kaufverhalten, Warenflüsse, etc.
+
+Statistische Datenbanken
+- Datenbanken, in denen die Einzeleinträge dem Datenschutz unterliegen, aber statistische Informationen allen Benutzern zugänglich sind
+- statistische Information = aggregierte Daten (Durchschnittseinkommen etc.)
+- Problem: Gewinnung von Einzelinformationen durch indirekte Anfragen
+  - Abhilfe: keine Anfragen, die weniger als n Tupel selektieren
+  - Abhilfe: statistische Anfragen nicht erlauben, die paarweise einen Durchschnitt von mehr als m vorgegebenen Tupeln betreffen
+> Sind nur Ergebnisse von Aggregatfunktionen erlaubt, dann benötigt eine Person 1 + (n − 2)/m Anfragen, um einen einzelnen Attributwert zu ermitteln
+
+> k-Anonymität: ein bestimmter Sachverhalt kann nicht zwischen einer vorgegebenen Anzahl k von Tupeln unterschieden werden
+- für viele Zwecke (klinische Studien etc.) werden auch Detaildaten (Mikrodaten) benötigt
+  - weitere Zuordnungen (Namen etc.) etwa durch Verbund mit anderen Daten möglich?
+  - Lösung: Data Swapping (??)
+    - Vertauschen von Attributwerten einzelner Tupel
+    - statistische Analysen noch gültig?
+  - eine Anfrage nach einer beliebigen Kombination von Alter, Geschlecht, Familienstand und Postleitzahl liefert entweder eine leere Relation oder mindestens k Tupel
+- Ansätze
+  - Generalisierung: Attributwerte durch allgemeinere Werte ersetzen, die einer Generalisierungshierarchie entnommen sind
+    - die Verallgemeinerung des Alters einer Person zu Altersklassen: $\{35, 39\} \rightarrow 30-40$
+    - Weglassen von Stellen bei Postleitzahlen: $\{ 39106, 39114 \}\rightarrow 39***$
+  - Unterdrücken von Tupeln: Löschen von Tupeln, welche die k-Anonymität verletzen und damit identifizierbar sind
 
 # NoSQL Datenbanken
+
+# Anwendungsprogrammierung