\item Selektion $\sigma$: Auswahl von Zeilen einer Tabelle anhand eines Selektionsprädikats
\item Projektion $\pi$: Auswahl von Spalten durch Angabe einer Attributliste
\begin{itemize*}
\item Die Projektion entfernt doppelte Tupel
\end{itemize*}
\item Verbund $\bowtie$: verknüpft Tabellen über gleichbenannte Spalten, indem er jeweils zwei Tupel verschmilzt, falls sie dort gleiche Werte aufweisen
\begin{itemize*}
\item Tupel, die keinen Partner finden (dangling tuples), werden eliminiert
\end{itemize*}
\item Umbenennung $\beta$: Anpassung von Attributnamen mittels Umbenennung
\item Vereinigung $r_1\cup r_2$ von zwei Relationen $r_1$ und $r_2$:
\begin{itemize*}
\item Gesamtheit der beiden Tupelmengen
\item Attributmengen beider Relationen müssen identisch sein
\end{itemize*}
\item Differenz $r_1- r_2$ eliminiert die Tupel aus der ersten Relation, die auch in der zweiten Relation vorkommen
\item Durchschnitt $r_1\cap r_2$: ergibt die Tupel, die in beiden Relationen gemeinsam vorkommen
\item m:n-Beziehung: beide Primärschlüssel zusammen werden Schlüssel im neuen Relationenschema
\item 1:n-Beziehung: Primärschlüssel der n-Seite (bei der funktionalen Notation die Seite ohne Pfeilspitze) wird Schlüssel im neuen Relationenschema
\item 1:1-Beziehung: beide Primärschlüssel werden je ein Schlüssel im neuen Relationenschema, der Primärschlüssel wird dann aus diesen Schlüsseln gewählt
\end{itemize*}
\item optionale Beziehungen ([0,1] oder [0,n]) werden nicht verschmolzen
\item bei Kardinalitäten [1,1] oder [1,n] (zwingende Beziehungen) Verschmelzung möglich:
\begin{itemize*}
\item 1:n-Beziehung: das Entity-Relationenschema der n-Seite kann in das Relationenschema der Beziehung integriert werden
\item 1:1-Beziehung: beide Entity-Relationenschemata können in das Relationenschema der Beziehung integriert werden
\item[Erste Normalform] nur atomare Attribute in den Relationenschemata, d.h. als Attributwerte sind Elemente von Standard-Datentypen wie integer oder string erlaubt, aber keine Konstruktoren wie array oder set
\item etwa Weingut $\rightarrow$ Anbaugebiet und Anbaugebiet $\rightarrow$ Region in Relation
\item 3 NF betrachtet nur Nicht-Schlüsselattribute als Endpunkt transitiver Abhängigkeiten
\item$A \in R$ heißt transitiv abhängig von X bezüglich F genau dann, wenn es ein $Y\subseteq R$ gibt mit $X \rightarrow Y, Y \not\rightarrow X, Y \rightarrow A, A \not\in XY$
\end{itemize*}
\item[Boyce-Kodd-Normalform] (Verschärfung der 3NF): Eliminierung transitiver Abhängigkeiten auch zwischen Primattributen $\not\exists A \in R$: A transitiv abhängig von einem $K\in\bf{K}$ bezüglich F
\item[Minimalität]
\begin{itemize*}
\item Global Redundanzen vermeiden
\item andere Kriterien (wie Normalformen) mit möglichst wenig Schemata erreichen
\item[Vierte Normalform] erweitertes Relationenschema $R =(R, \bf{K})$ ist in vierter Normalform (4NF) bezüglich M genau dann, wenn für alle $X\rightarrow\rightarrow Y \in M^+$ gilt: $X\rightarrow\rightarrow Y$ ist trivial oder $X\supseteq K$ für ein $K\in\bf{K}$
\item alle gegebenen Abhängigkeiten sind durch Schlüssel repräsentiert
\item eine Menge von Abhängigkeiten kann äquivalent in eine zweite Menge von Abhängigkeiten transformiert werden
\item spezieller: in die Menge der Schlüsselabhängigkeiten, da diese vom Datenbanksystem effizient überprüft werden kann
\item die Menge der Abhängigkeiten soll äquivalent zu der Menge der Schlüsselbedingungen im resultierenden Datenbankschema sein
\item Äquivalenz sichert zu, dass mit den Schlüsselabhängigkeiten semantisch genau die gleichen Integritätsbedingungen ausgedrückt werden wie mit den funktionalen oder anderen Abhängigkeiten vorher
\item S charakterisiert vollständig F (oder: ist abhängigkeitstreu bezüglich F) genau dann, wenn $F\equiv\{K\rightarrow R | (R,\bf{K})\in S, K\in\bf{K}\}$
\item Originalrelationen können durch den Verbund der Basisrelationen wiedergewonnen werden
\item zur Erfüllung des Kriteriums der Normalformen müssen Relationenschemata teilweise in kleinere Relationenschemata zerlegt werden
\item für Beschränkung auf „sinnvolle“ Zerlegungen gilt Forderung, dass die Originalrelation wieder aus den zerlegten Relationen mit dem natürlichen Verbund zurückgewonnen werden kann
\item Zerlegung des Relationenschemas $R = ABC$ in $R_1= AB$ und $R_2= BC$
\item Dekomposition bei Vorliegen der Abhängigkeiten $F =\{A \rightarrow B, C \rightarrow B\}$ ist nicht verbundtreu
\item dagegen bei Vorliegen von $F" =\{A \rightarrow B, B \rightarrow C\}$ verbundtreu
\item innerhalb einer Relation r wird einem Attributwert von X eine Menge von Y-Werten zugeordnet, unabhängig von den Werten der restlichen Attribute $\rightarrow$ Vierte Normalform
\item Folge der 1NF: Mehrwertige Abhängigkeiten erzeugen Redundanz
\item eine (oder mehrere) Gruppe von Attributwerten ist von einem Schlüssel bestimmt, unabhängig von anderen Attributen
\item Resultat: Redundanz durch Bildung aller Kombinationen
\item wünschenswerte Schemaeigenschaft bei Vorliegen von MVDs: vierte Normalform
\item fordert die Beseitigung derartiger Redundanzen: keine zwei MVDs zwischen Attributen einer Relation
\item Elimination der rechten Seite einer der beiden mehrwertigen Abhängigkeiten,
\item linke Seite mit dieser rechten Seite in neue Relation kopiert
\item Verbundabhängigkeit (kurz: JD)
\item R kann ohne Informationsverlust in $R_1,..., R_p$ aufgetrennt werden: $\bowtie[R_1,..., R_p]$
\item Inklusionsabhängigkeit (kurz: IND)
\item auf der rechten Seite einer Fremdschlüsselabhängigkeit nicht unbedingt der Primärschlüssel einer Relation
\paragraph{Membership Problem} Kann eine bestimmte FD $X\rightarrow Y$ aus der vorgegebenen Menge F abgeleitet werden, d.h. wird sie von F impliziert? $X\rightarrow Y \in F^+$
\item Anfrage: Folge von Operationen, die aus den Basisrelationen eine Ergebnisrelation berechnet
\item Sicht: Folge von Operationen, die unter einem Sichtnamen langfristig abgespeichert wird und unter diesem Namen wieder aufgerufen werden kann; ergibt eine Sichtrelation
\item Snapshot: Ergebnisrelation einer Anfrage, die unter einem Snapshot-Namen abgelegt wird, aber nie ein zweites Mal (mit geänderten Basisrelationen) berechnet wird (etwa Jahresbilanzen)
\item Ad-Hoc-Formulierung: Benutzer soll eine Anfrage formulieren können, ohne ein vollständiges Programm schreiben zu müssen
\item Deskriptivität: Benutzer soll formulieren „Was will ich haben?“ und nicht „Wie komme ich an das, was ich haben will?“
\item Mengenorientiertheit: jede Operation soll auf Mengen von Daten gleichzeitig arbeiten, nicht navigierend nur auf einzelnen Elementen („one-tuple-at-a-time“)
\item Abgeschlossenheit: Ergebnis ist wieder eine Relation und kann wieder als Eingabe für die nächste Anfrage verwendet werden
\item Adäquatheit: alle Konstrukte des zugrundeliegenden Datenmodells werden unterstützt
\item Orthogonalität: Sprachkonstrukte sind in ähnlichen Situationen auch ähnlich anwendbar
\item Optimierbarkeit: Sprache besteht aus wenigen Operationen, für die es Optimierungsregeln gibt
\item Effizienz: jede Operation ist effizient ausführbar (im Relationenmodell hat jede Operation eine Komplexität $\leq$ O(n 2 ), n Anzahl der Tupel einer Relation).
\item Sicherheit: keine Anfrage, die syntaktisch korrekt ist, darf in eine Endlosschleife geraten oder ein unendliches Ergebnis liefern
\item Eingeschränktheit: (folgt aus Sicherheit, Optimierbarkeit, Effizienz) Anfragesprache darf keine komplette Programmiersprache sein
\item Vollständigkeit: Sprache muss mindestens die Anfragen einer Standardsprache ausdrücken können
\item unabhängig: kein Operator kann weggelassen werden ohne Vollständigkeit zu verlieren
\item andere unabhängige Menge: $\ltimes$ und $\beta$ durch × ersetzen
\item Relationale Vollständigkeit: jede andere Menge von Operationen genauso mächtig wie $\Omega$
\item strenge relationale Vollständigkeit: zu jedem Ausdruck mit Operatoren aus $\Omega$ gibt es einen Ausdruck auch mit der anderen Menge von Operationen
\end{itemize*}
\subsection{Erweiterungen der Relationenalgebra}
Verbundvarianten
\begin{itemize*}
\item Gleichverbund (engl. equi-join): Gleichheitsbedingung über explizit angegebene und evtl. verschiedene Attribute
> Division: Die ganzzahlige Division ist in dem Sinne die Inverse zur Multiplikation, indem sie als Ergebnis die größte Zahl liefert, für die die Multiplikation mit dem Divisor kleiner ist als der Dividend.
Analog gilt: $r = r_1/ r_2$ ist die größte Relation, für die $r \bowtie r_2\subseteq r_1$ ist.
> Semantisch sichere Anfragen: Anfragen, die für jeden Datenbankzustand $\sigma(R)$ ein endliches Ergebnis liefern
> Semantische Sicherheit Semantische Sicherheit ist im Allgemeinen nicht entscheidbar!
> Syntaktische Sicherheit: Jede freie Variable $x_i$ muss überall in $\phi(x_1,...)$ durch positives Auftreten $x_i = t$ oder $R(. . . , x_i , . . . )$ an endliche Bereiche gebunden werden.
\begin{itemize*}
\item Syntaktisch sichere Anfragen: Anfragen, die syntaktischen Einschränkungen unterliegen, um die semantische Sicherheit zu erzwingen.
\item Bindung an endliche Bereiche muss für die ganze Bedingung gelten, also insbesondere für alle Zweige einer Disjunktion
\end{itemize*}
\subsection{Eigenschaften des Bereichskalküls}
Ausdrucksfähigkeit des Bereichskalküls: Bereichskalkül ist streng relational vollständig, d.h. zu jedem Term $\tau$ der Relationenalgebra gibt es einen äquivalenten (sicheren) Ausdruck $\eta$ des Bereichskalküls.
\section{Transaktionen, Integrität und Trigger}
\subsection{Grundbegriffe}
Integritätsbedingung (engl. integrity constraint oder assertion): Bedingung für die „Zulässigkeit“ oder „Korrektheit“
\begin{itemize*}
\item Typintegrität
\begin{itemize*}
\item SQL erlaubt Angabe von Wertebereichen zu Attributen
\item Erlauben oder Verbieten von Nullwerten
\end{itemize*}
\item Schlüsselintegrität
\begin{itemize*}
\item Angabe eines Schlüssels für eine Relation
\end{itemize*}
\item Referentielle Integrität
\begin{itemize*}
\item die Angabe von Fremdschlüsseln
\end{itemize*}
\end{itemize*}
\subsection{Transaktionsbegriff}
Beispiel:
\begin{itemize*}
\item Platzreservierung für Flüge gleichzeitig aus vielen Reisebüros $\rightarrow$ Platz könnte mehrfach verkauft werden, wenn mehrere Reisebüros den Platz als verfügbar identifizieren
\item überschneidende Kontooperationen einer Bank
\item statistische Datenbankoperationen $\rightarrow$ Ergebnisse sind verfälscht, wenn während der Berechnung Daten geändert werden
\end{itemize*}
> 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.
\begin{itemize*}
\item Aspekte:
\begin{itemize*}
\item Semantische Integrität: Korrekter (konsistenter) DB-Zustand nach Ende der Transaktion
\item Ablaufintegrität: Fehler durch "gleichzeitigen" Zugriff mehrerer Benutzer auf dieselben Daten vermeiden
\end{itemize*}
\item ACID-Eigenschaften
\begin{itemize*}
\item Atomicity (Atomarität): Transaktion wird entweder ganz oder gar nicht ausgeführt
\item Consistency (Konsistenz oder auch Integritätserhaltung): Datenbank ist vor Beginn und nach Beendigung einer Transaktion jeweils in einem konsistenten Zustand
\item Isolation (Isolation): Nutzer, der mit einer Datenbank arbeitet, sollte den Eindruck haben, dass er mit dieser Datenbank alleine arbeitet
\item Durability (Dauerhaftigkeit / Persistenz): nach erfolgreichem Abschluss einer Transaktion muss das Ergebnis dieser Transaktion „dauerhaft“ in der Datenbank gespeichert werden
\end{itemize*}
\item Kommandos einer Transaktionssprache
\begin{itemize*}
\item Beginn einer Transaktion: Begin-of-Transaction-Kommando BOT (in SQL implizit!)
\item commit: die Transaktion soll erfolgreich beendet werden
\item abort: die Transaktion soll abgebrochen werden
\end{itemize*}
\end{itemize*}
Vereinfachtes Modell für Transaktion
\begin{itemize*}
\item Repräsentation von Datenbankänderungen einer Transaktion
\begin{itemize*}
\item "read(A,x)": weise den Wert des DB-Objektes A der Variablen x zu
\item "write(x, A)": speichere den Wert der Variablen x im DB-Objekt A
\end{itemize*}
\item Beispiel einer Transaktion T:
\begin{itemize*}
\item "read(A, x); x := x - 200; write(x, A);"
\item "read(B, y); y := y + 100; write(y, B);"
\end{itemize*}
\item Ausführungsvarianten für zwei Transaktionen $T_1 , T_2$:
\begin{itemize*}
\item seriell, etwa $T_1$ vor $T_2$
\item „gemischt“, etwa abwechselnd Schritte von $T_1$ und $T_2$
\end{itemize*}
\item Probleme im Mehrbenutzerbetrieb
\begin{itemize*}
\item Inkonsistentes Lesen: Nonrepeatable Read
\item Variablen/Speicher ändert sich durch fertigstellen anderer Transaktionen während des Ablaufs
\item dirty read
\item Das Phantom-Problem: durch "insert" ändert sich "select" ergebnis; nachfolgende rechnungen auf vorherigen abruf sind falsch
\item Verlorengegangenes Ändern: "Lost Update" updates gehen verloren, wenn gleiche Variablen gleicheitig beschrieben werden (oder kurz nacheinander)
Abhängigkeiten von nicht freigegebenen Daten: Dirty Read
\begin{itemize*}
\item$T_1$ ändert X
\item$T_2$ liest X und rechnet damit
\item$T_1$ bricht ab und setzt änderung zurück
\item Ergebnis von $T_2$ ist damit falsch
\end{itemize*}
> 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
\subsection{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
\begin{itemize*}
\item\textbf{read uncommitted}
\begin{itemize*}
\item schwächste Stufe: Zugriff auf nicht geschriebene Daten, nur für read only Transaktionen
\item statistische und ähnliche Transaktionen (ungefährer Überblick, nicht korrekte Werte)
\item keine Sperren $\rightarrow$ effizient ausführbar, keine anderen Transaktionen werden behindert
\end{itemize*}
\item\textbf{read committed}: nur Lesen endgültig geschriebener Werte, aber nonrepeatable read möglich
\item\textbf{repeatable read}: kein nonrepeatable read, aber Phantomproblem kann auftreten
\item\textbf{create domain}: Festlegung eines benutzerdefinierten Wertebereichs
\begin{itemize*}
\item 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, ...)
```
\end{itemize*}
\end{itemize*}
Erhaltung der referentiellen Integrität
\begin{itemize*}
\item Überprüfung der Fremdschlüsselbedingungen nach Datenbankänderungen
\item Überprüfungsmodi von Bedingungen
\begin{itemize*}
\item "on update | delete": Angabe eines Auslöseereignisses, das die Überprüfung der Bedingung anstößt
\item "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
\item "deferred | immediate" legt Überprüfungszeitpunkt für eine Bedingung fest
\item "deferred": Zurückstellen an das Ende der Transaktion
\item "immediate": sofortige Prüfung bei jeder relevanten Datenbankänderung
\item Assertion: Prädikat, das eine Bedingung ausdrückt, die von der Datenbank immer erfüllt sein muss
\item Syntax (SQL:2003) "create assertion name check ( prädikat )"
\end{itemize*}
\subsection{Trigger}
\begin{itemize*}
\item Trigger: Anweisung/Prozedur, die bei Eintreten eines bestimmten Ereignisses automatisch vom DBMS ausgeführt wird
\item Anwendung:
\begin{itemize*}
\item Erzwingen von Integritätsbedingungen („Implementierung“ von Integritätsregeln)
\item Auditing von DB-Aktionen
\item Propagierung von DB-Änderungen
\end{itemize*}
\item Definition:$create trigger ... after Operation Anweisungen$
\item Spezifikation von
\begin{itemize*}
\item Ereignis und Bedingung für Aktivierung des Triggers
\item Aktion(en) zur Ausführung
\end{itemize*}
\item verfügbar in den meisten kommerziellen Systemen (aber mit anderer Syntax)
\item Weitere Angaben bei Triggern
\begin{itemize*}
\item\textbf{for each row} bzw. \textbf{for each statement}: Aktivierung des Triggers für jede Einzeländerungen einer mengenwertigen Änderung oder nur einmal für die gesamte Änderung
\item\textbf{before} bzw. \textbf{after}: Aktivierung vor oder nach der Änderung
\item\textbf{referencing new as} bzw. \textbf{referencing old as}: Binden einer Tupelvariable an die neu eingefügten bzw. gerade gelöschten („alten“) Tupel einer Relation $\rightarrow$ Tupel der Differenzrelationen
\end{itemize*}
\end{itemize*}
Integritätssicherung durch Trigger
\begin{itemize*}
\item Bestimme Objekt $o_i$ , für das die Bedingung $\phi$ überwacht werden soll
\begin{itemize*}
\item i.d.R. mehrere $o_i$ betrachten, wenn Bedingung relationsübergreifend ist
\item Kandidaten für $o_i$ sind Tupel der Relationsnamen, die in $\phi$ auftauchen
\end{itemize*}
\item Bestimme die elementaren Datenbankänderungen $u_{ij}$ auf Objekten $o_i$ , die $\phi$ verletzen können
\begin{itemize*}
\item Regeln: z.B. Existenzforderungen beim Löschen und Ändern prüfen, jedoch nicht beim Einfügen etc.
\end{itemize*}
\item Bestimme je nach Anwendung die Reaktion $r_i$ auf Integritätsverletzung
\begin{itemize*}
\item Rücksetzen der Transaktion (rollback)
\item korrigierende Datenbankänderungen
\end{itemize*}
\item Formuliere folgende Trigger:
\begin{itemize*}
\item create trigger $t_{phi_{ij}}$ after $u_{ij}$ on $o i$ when $\neq\phi$ begin $r i$ end
\end{itemize*}
\item Wenn möglich, vereinfache entstandenen Trigger
\end{itemize*}
Trigger in Oracle: Arten
\begin{itemize*}
\item Prädikat zur Einschränkung (when)
\item Zugriff auf altes (:old.col) bzw. neues (:new.col) Tupel
\begin{itemize*}
\item für delete: nur (:old.col)
\item für insert: nur (:new.col)
\item in when-Klausel nur (new.col) bzw. (old.col)
\end{itemize*}
\item Transaktionsabbruch durch $raise_application_error(code, message)$
\item Unterscheidung der Art der DML-Anweisung
\begin{itemize*}
\item "if deleting then ... end if;"
\item "if updating then ... end if;"
\item "if inserting then ... end if;"
\end{itemize*}
\end{itemize*}
\subsection{Schemaevolution}
\begin{itemize*}
\item Änderung eines Datenbankschemas durch neue/veränderte Anforderungen
\begin{itemize*}
\item Hinzufügen oder Löschen von Tabellen, Spalten, Integritätsbedingungen
\item Umbenennen oder Datentypänderungen
\end{itemize*}
\item erfordert oft auch Anpassung/Übertragung der vorhandenen Datenbank $\rightarrow$ Datenbankmigration
\item leider nur eingeschränkte Unterstützung durch DB-Werkzeuge (DDL + Export/Import der Daten)
\end{itemize*}
\begin{itemize*}
\item SQL-DDL zum Löschen von Tabellen
\begin{itemize*}
\item Löschen von Tabellendefinitionen (beachte Unterschied zu delete)
\item cascade: erzwingt Löschen aller Sichten und Integritätsbedingungen, die zu dieser Basisrelation gehören
\item restrict (Defaultfall): das drop-Kommando wird zurückgewiesen, falls noch solche Sichten und Integritätsbedingungen existieren
\end{itemize*}
\item SQL-DDL zur Änderung von Tabellen
\begin{itemize*}
\item "alter table relationenname modifikation"
\item\textbf{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
\item\textbf{drop column spaltenname} löscht die angegebene Spalte (inkl. restrict- bzw. cascade)
\item\textbf{alter column spaltenname set default defaultwert} verändert Defaultwert der Spalte
\end{itemize*}
\item Änderung von Integritätsbedingungen
\begin{itemize*}
\item nachträgliches Hinzufügen/Löschen von Tabellenbedingungen über \textbf{alter table}
\item Vergabe von Namen für Bedingungen über constraint bed-name-Klausel
```sql
alter table WEINE
add constraint $WeinBed_Eindeutig$
unique (Name, Weingut)
```
\item Löschen über Namen "alter table WEINE drop constraint $WeinBed_Eindeutig$"
\end{itemize*}
\end{itemize*}
\section{Sichten und Zugriffskontrolle}
\subsection{Sichtenkonzept}
> Sichten: virtuelle Relationen (bzw virtuelle Datenbankobjekte in anderen Datenmodellen) (englisch view)
\begin{itemize*}
\item Sichten sind externe DB-Schemata folgend der 3-Ebenen-Schemaarchitektur
\begin{itemize*}
\item Sichtdefinition
\item Relationenschema (implizit oder explizit)
\item Berechnungsvorschrift für virtuelle Relation, etwa SQL-Anfrage
\end{itemize*}
\item Vorteile
\begin{itemize*}
\item Vereinfachung von Anfragen für den Benutzer der Datenbank, etwa indem oft benötigte Teilanfragen als Sicht realisiert werden
\item Möglichkeit der Strukturierung der Datenbankbeschreibung, zugeschnitten auf Benutzerklassen
\item logische Datenunabhängigkeit ermöglicht Stabilität der Schnittstelle für Anwendungen gegenüber Änderungen der Datenbankstruktur
\item Beschränkung von Zugriffen auf eine Datenbank im Zusammenhang mit der Zugriffskontrolle
\item Effektkonformität: Benutzer sieht Effekt als wäre die Änderung auf der Sichtrelation direkt ausgeführt worden
\item Minimalität: Basisdatenbank sollte nur minimal geändert werden, um den erwähnten Effekt zu erhalten
\item Konsistenzerhaltung: Änderung einer Sicht darf zu keinen Integritätsverletzungen der Basisdatenbank führen
\item 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
\item Änderungsoperationen hier in der Regel nicht eindeutig übersetzbar:
"insert into WE values (3333, "Dornfelder", "Rot", 2002, "Helena", "Barossa Valley", "Südaustralien")"
\item Änderung wird transformiert zu
"insert into WEINE values (3333, "Dornfelder", "Rot", 2002, "Helena")"
\item plus Änderung auf ERZEUGER !
\end{itemize*}
Klassifikation der Problembereiche
\begin{itemize*}
\item Verletzung der Schemadefinition (z.B. Einfügen von Nullwerten bei Projektionssichten)
\item Datenschutz: Seiteneffekte auf nicht-sichtbaren Teil der Datenbank vermeiden (Tupelmigration, Selektionssichten)
\item nicht immer eindeutige Transformation: Auswahlproblem
\item Aggregierungssichten (u.a.): keine sinnvolle Transformation möglich
\item 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)
\end{itemize*}
SQL-92-Standard
\begin{itemize*}
\item Integritätsverletzende Sichtänderungen nicht erlaubt
\item Sichten mit nicht-eindeutiger Transformation: Sicht nicht änderbar (SQL-92 restriktiver als notwendig)
\end{itemize*}
Einschränkungen für Sichtänderungen
\begin{itemize*}
\item änderbar nur Selektions- und Projektionssichten (Verbund und Mengenoperationen nicht erlaubt)
\item 1:1-Zuordnung von Sichttupeln zu Basistupeln: kein distinct in Projektionssichten
\item Arithmetik und Aggregatfunktionen im select-Teil sind verboten
\item genau eine Referenz auf einen Relationsnamen im from-Teil erlaubt (auch kein Selbstverbund)
\item keine Unteranfragen mit „Selbstbezug“ im where-Teil erlaubt (Relationsname im obersten SFW-Block nicht in from-Teilen von Unteranfragen verwenden)
\item group by und having verboten
\item seit SQL:2003 Aufhebung einiger Einschränkungen, insbesondere
\begin{itemize*}
\item updates auf union all-Sichten (ohne Duplikateliminierung)
\item Inserts in Verbundsichten mit Primär-/Fremdschlüsselbeziehungen (mit einigen Einschränkungen)
\item Updates auf Verbundsichten mit Cursor
\end{itemize*}
\end{itemize*}
Alternative: Sichtänderungen mit Instead-of-Triggern
Definition von Triggern auf Sichten zur anwendungsspezifischen Propagierung der Änderungen auf die Basistabellen
\item restrict: Falls Recht bereits an Dritte weitergegeben: Abbruch von revoke
\item cascade: Rücknahme des Rechts mittels revoke an alle Benutzer propagiert, die es von diesem Benutzer mit grant erhalten haben
\end{itemize*}
\subsection{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
\begin{itemize*}
\item elektronische Autobahn-Mautsysteme: Überwachung von Fahrzeugen
\item Kreditkartenaktivitäten und diverse Payback- bzw. Rabattkarten: Kaufverhalten von Kunden
\item Mobilfunksysteme: Bewegungsprofile der Nutzer
\item RFID-Technologie: etwa im Einzelhandel Kaufverhalten, Warenflüsse, etc.
\end{itemize*}
Statistische Datenbanken
\begin{itemize*}
\item Datenbanken, in denen die Einzeleinträge dem Datenschutz unterliegen, aber statistische Informationen allen Benutzern zugänglich sind
\item statistische Information = aggregierte Daten (Durchschnittseinkommen etc.)
\item Problem: Gewinnung von Einzelinformationen durch indirekte Anfragen
\begin{itemize*}
\item Abhilfe: keine Anfragen, die weniger als n Tupel selektieren
\item Abhilfe: statistische Anfragen nicht erlauben, die paarweise einen Durchschnitt von mehr als m vorgegebenen Tupeln betreffen
\end{itemize*}
\end{itemize*}
> 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
\begin{itemize*}
\item für viele Zwecke (klinische Studien etc.) werden auch Detaildaten (Mikrodaten) benötigt
\begin{itemize*}
\item weitere Zuordnungen (Namen etc.) etwa durch Verbund mit anderen Daten möglich?
\item Lösung: Data Swapping (Vertauschen von Attributwerten einzelner Tupel)
\item eine Anfrage nach einer beliebigen Kombination von Alter, Geschlecht, Familienstand und Postleitzahl liefert entweder eine leere Relation oder mindestens k Tupel
\end{itemize*}
\item Ansätze
\begin{itemize*}
\item Generalisierung: Attributwerte durch allgemeinere Werte ersetzen, die einer Generalisierungshierarchie entnommen sind
\item die Verallgemeinerung des Alters einer Person zu Altersklassen: $\{35, 39\}\rightarrow30-40$
\item Weglassen von Stellen bei Postleitzahlen: $\{39106, 39114\}\rightarrow39***$
\item Unterdrücken von Tupeln: Löschen von Tupeln, welche die k-Anonymität verletzen und damit identifizierbar sind
\end{itemize*}
\end{itemize*}
\section{NoSQL Datenbanken}
\subsection{Motivation für NoSQL}
\begin{itemize*}
\item NoSQL = Not only SQL
\item im Umfeld vieler aktueller Buzzwords
\begin{itemize*}
\item NoSQL
\item Big Data
\item BASE
\item ...
\end{itemize*}
\item oft einfach als Etikett einer Neuentwicklung eines DBMS pauschal vergeben
\end{itemize*}
Was ist NoSQL?
\begin{itemize*}
\item SQL-No!
\begin{itemize*}
\item SQL-Datenbanken sind zu komplex, nicht skalierbar, ...
\item man braucht was einfacheres!
\end{itemize*}
\item Not only SQL
\begin{itemize*}
\item SQL-Datenbanken haben zu wenig (oder die falsche) Funktionalität
\item Operationen auf Graphen, Data Mining Operatoren, ...
\end{itemize*}
\item New SQL
\begin{itemize*}
\item SQL-Datenbanken sind (software-technisch) in die Jahre gekommen
\item eine neue Generation von DBMS muss her (ohne die etablierten Vorteile von SQL zu ignorieren)
\end{itemize*}
\end{itemize*}
Kritik an RDBMS / SQL
\begin{itemize*}
\item nicht skalierbar
\begin{itemize*}
\item Normalisierung von Relationen, viele Integritätsbedingungen zu prüfen
\item kann man in RDBMS auch vermeiden!
\end{itemize*}
\item starre Tabellen nicht flexibel genug
\begin{itemize*}
\item schwach typisierte Tabellen (Tupel weichen in den tatsächlich genutzten Attributen ab)
\item viele Nullwerte wenn alle potentiellen Attribute definiert
\item alternativ Aufspaltung auf viele Tabellen
\item Schema-Evolution mit alter table skaliert bei Big Data nicht
\item tatsächlich in vielen Anwendungen ein Problem
\end{itemize*}
\item Integration von spezifischen Operationen (Graphtraversierung, Data-Mining-Primitive) mit Stored Procedures zwar möglich führt aber oft zu schwer interpretierbarem Code
\item$E \subseteq V \times V$: Menge der Kanten (edges)
\item Kanten können mit Gewicht versehen werden
\end{itemize*}
\item Adjazenzmatrix
\begin{itemize*}
\item Repräsentation von Graphen durch Matrix (Knoten als Zeilen und Spalten)
\item ungerichteter Graph: symmetrische Matrix
\item ungewichteter Graph: Zellen nur 0 oder 1
\end{itemize*}
\item Knotengrad
\begin{itemize*}
\item Eigenschaft eines Knotens: Anzahl der verbundenen Knoten
\item bei gerichteren Graphen: Unterscheidung in Eingangs- und Ausgangsgrad
\end{itemize*}
\item Traversierung
\begin{itemize*}
\item Tiefensuche (DFS): zunächst rekursiv alle Kindknoten besuchen bevor alle Geschwisterknoten besucht werden (Bestimmung der Zusammenhangskomponente)
\item Breitensuche (BFS): zunächst alle Geschwisterknoten besuchen bevor die Kindknoten besucht werden (Bestimmung des kürzesten Weges)
\end{itemize*}
\end{itemize*}
Subjekt-Prädikat-Objekt-Modell: RDF
\begin{itemize*}
\item Sprache zur Repräsentation von Informationen über (Web)-Ressourcen
\item Ziel: automatisierte Verarbeitung
\item zentraler Bestandteil von Semantic Web, Linked (Open) Data
\item Repräsentation von Daten, aber auch Wissensrepräsentation (z.B. Ontologie)
\end{itemize*}
Ontologien
\begin{itemize*}
\item Ontologie = formale Spezifikation einer Konzeptualisierung, d.h. einer Repräsentation von Begriffen (Konzepten) und deren Beziehungen
\item Anwendung: Annotation von Daten, semantische Suche
\end{itemize*}
RDF: Graphen \& Tripel
\begin{itemize*}
\item Graph = Menge von Tripeln, die Aussagen über Web-Ressourcen repräsentieren
\item Identifikation der Web-Ressourcen über Uniform Resource Identifier (URI)
\item Tripel: subjekt prädikat objekt .
\item Beispiel "<http://weindb.org/weine/2171> \ " und "<http://weindb.org/ontologie/name> "Pinot Noir"."
\item Subjekt: URI-Referenz, d.h. Ressource, auf die sich die Aussage bezieht
\item Prädikat: Eigenschaft, ebenfalls in Form einer URI-Referenz
\item Objekt: Wert der Eigenschaft als Literal (Konstante) oder URI- Referenz
\item abkürzende Notation für Namensräume über Präfixe:
\item eingebetteter Fremdschlüssel in der Relation der Klasse, d.h. der Identifikator des assoziierten Objektes wird als Fremdschlüssel in zusätzlichen Spalten gespeichert
\item Fremdschlüsseltabellen: die Beziehungsinstanz wird als Tupel mit den Schlüsseln der beteiligten Objekte repräsentiert
\item Abbildung der in Beziehung stehenden Klassen auf eine einzelne Tabelle: Verletzung der Normalformen
