- Stark deklarative DML, integrierte Datenbankprogrammiersprache
- Objektorientierte Datenbanksysteme
- Daten in komplexeren Objektstrukturen (Trennung Objekt und seine Daten)
- Deklarative oder navigierende DML
- Oft integrierte Datenbankprogrammiersprache
- Oft keine vollständige Ebenentrennung
- Neue Hardwarearchitekturen
- Multicore-Prozessoren, Hauptspeicher im TB-Bereich: In-Memory-Datenbanksysteme (z.B. SAP HANA)
- Unterstützung für spezielle Anwendungen
- Cloud-Datenbanken: Hosting von Datenbanken, Skalierbare Datenmanagementlösungen (Amazon RDS, Microsoft Azure)
• Datenstromverarbeitung: Online-Verarbeitung von Live-Daten, z.B. Börseninfos, Sensordaten, RFID-Daten, ...(StreamBase, MS StreamInsight, IBM Infosphere Streams)
- Big Data: Umgang mit Datenmengen im PB-Bereich durch hochskalierbare, parallele Verarbeitung, Datenanalyse (Hadoop, Hive, Google Spanner & F1, ...)
- primary key kennzeichnet Spalte als Schlüsselattribut
- foreign key kennzeichnet Spalte als Fremdschlüssel
- not null schließt in bestimmten Spalten Nullwerte als Attributwerte aus
- null repräsentiert die Bedeutung „Wert unbekannt“, „Wert nicht anwendbar“ oder „Wert existiert nicht“, gehört aber zu keinem Wertebereich
- null kann in allen Spalten auftauchen, außer in Schlüsselattributen und den mit not null gekennzeichneten
## Grundoperationen: Die Relationenalgebra
- Anfrageoperationen auf Tabellen
- Basisoperationen auf Tabellen, die die Berechnung von neuen Ergebnistabellen aus gespeicherten Datenbanktabellen erlauben
- Operationen werden zur sogenannten Relationenalgebra zusammengefasst
- Mathematik: Algebra ist definiert durch Wertebereich sowie darauf definierten Operationen
- für Datenbankanfragen entsprechen die Inhalte der Datenbank den Werten, Operationen sind dagegen Funktionen zum Berechnen der Anfrageergebnisse
- Anfrageoperationen sind beliebig kombinierbar und bilden eine Algebra zum „Rechnen mit Tabellen“ – die Relationenalgebra
- Selektion $\sigma$: Auswahl von Zeilen einer Tabelle anhand eines Selektionsprädikats
- Projektion $\pi$: Auswahl von Spalten durch Angabe einer Attributliste
- Die Projektion entfernt doppelte Tupel
- Verbund $\bowtie$ (engl. join): verknüpft Tabellen über gleichbenannte Spalten, indem er jeweils zwei Tupel verschmilzt, falls sie dort gleiche Werte aufweisen
- Tupel, die keinen Partner finden (dangling tuples), werden eliminiert
- Umbenennung $\beta$: Anpassung von Attributnamen mittels Umbenennung
- Vereinigung $r_1 \cup r_2$ von zwei Relationen $r_1$ und $r_2$:
- Gesamtheit der beiden Tupelmengen
- Attributmengen beider Relationen müssen identisch sein
- Differenz $r_1 − r_2$ eliminiert die Tupel aus der ersten Relation, die auch in der zweiten Relation vorkommen
- Durchschnitt $r_1 \cap r_2$: ergibt die Tupel, die in beiden Relationen gemeinsam vorkommen
## SQL als Anfragesprache
```sql
SELECT farbe FROM weine WHERE Jahrgang = 2002
```
- SQL hat Multimengensemantik — Duplikate in Tabellen werden in SQL nicht automatisch unterdrückt!
- Mengensemantik durch distinct
- Verknüpfung von Tabellen
- Kreuzprodukt: `` select * from Weine, Erzeuger``
- Verbund: `` select * from Weine natural join Erzeuger``
- Verbund mit Bedingung: `` select * from Weine, Erzeuger where Weine.Weingut = Erzeuger.Weingut``
- Kombination von Bedingungen
- Vereinigung in SQL explizit mit union
## Änderungsoperationen in SQL
- insert: Einfügen eines oder mehrerer Tupel in eine Basisrelation oder Sicht
- `` INSERT INTO table (attribut) VALUE (ausdruck) ``
- optionale Attributliste ermöglicht das Einfügen von unvollständigen Tupeln
- nicht alle Attribute angegeben ⇝ Wert des fehlenden Attribut Land wird null
- update: Ändern von einem oder mehreren Tupel in einer Basisrelation oder Sicht
- `` UPDATE relation SET attribut=ausdruck ``
- delete: Löschen eines oder mehrerer Tupel aus einer Basisrelation oder Sicht
- `` DELETE FROM table WHERE id=123 ``
- Löschoperationen können zur Verletzung von Integritätsbedingungen führen!
Lokale und globale Integritätsbedingungen müssen bei Änderungsoperationen automatisch vom System überprüft werden
> **Datenbankmodell**: Ein Datenbankmodell ist ein System von Konzepten zur Beschreibung von Datenbanken. Es legt Syntax und Semantik von Datenbankbeschreibungen für ein Datenbanksystem fest.
Datenbankbeschreibungen = Datenbankschemata
1. statische Eigenschaften
1. Objekte
2. Beziehungen
- inklusive der Standard-Datentypen, die Daten über die Beziehungen und Objekte darstellen können,
- **Entity**: Objekt der realen oder der Vorstellungswelt, über das Informationen zu speichern sind, z.B. Produkte (Wein, Katalog), Winzer oder Kritiker; aber auch Informationen über Ereignisse, wie z.B. Bestellungen
- **Relationship**: beschreibt eine Beziehung zwischen Entities, z.B. ein Kunde bestellt einen Wein oder ein Wein wird von einem Winzer angeboten
- **Attribut**: repräsentiert eine Eigenschaft von Entities oder Beziehungen, z.B. Name eines Kunden, Farbe eines Weines oder Datum einer Bestellung
- Attribute modellieren Eigenschaften von Entities oder auch Beziehungen
- alle Entities eines Entity-Typs haben dieselben Arten von Eigenschaften; Attribute werden somit für Entity-Typen deklariert
- **Werte**: primitive Datenelemente, die direkt darstellbar sind
- Wertemengen sind beschrieben durch Datentypen, die neben einer Wertemenge auch die Grundoperationen auf diesen Werten charakterisieren
- ER-Modell: vorgegebene Standard-Datentypen, etwa die ganzen Zahlen int, die Zeichenketten string, Datumswerte date etc.
- jeder Datentyp stellt Wertebereich mit Operationen und Prädikaten dar
- **Entities** sind die in einer Datenbank zu repräsentierenden Informationseinheiten
- im Gegensatz zu Werten nicht direkt darstellbar, sondern nur über ihre Eigenschaften beobachtbar
- Entities sind eingeteilt in Entity-Typen, etwa $E_1 , E_2,...$
- **Schlüsselattribute**: Teilmenge der gesamten Attribute eines Entity-Typs $E(A_1,... , A_m)$
- in jedem Datenbankzustand identifizieren die aktuellen Werte der Schlüsselattribute eindeutig Instanzen des Entity-Typs E
- bei mehreren möglichen Schlüsselkandidaten: Auswahl eines Primärschlüssels
- **Beziehungstypen**: Beziehungen zwischen Entities werden zu Beziehungstypen zusammengefasst
- Beziehungen können ebenfalls Attribute besitzen
Merkmale von Beziehungen
- Stelligkeit oder Grad:
- Anzahl der beteiligten Entity-Typen
- häufig: binär
- Beispiel: Lieferant liefert Produkt
- Kardinalität oder Funktionalität:
- Anzahl der eingehenden Instanzen eines Entity-Typs
- Formen: 1:1, 1:n, m:n
- stellt Integritätsbedingung dar
- Beispiel: maximal 5 Produkte pro Bestellung
- 1:1 Beziehung
- jedem Entity $e_1$ vom Entity-Typ $E_1$ ist maximal ein Entity $e_2$ aus $E_2$ zugeordnet und umgekehrt
- Bsp: Prospekt *beschreibt* Produkt
- 1:N Beziehung
- jedem Entity $e_1$ aus $E_1$ sind beliebig viele Entities $E_2$ zugeordnet, aber zu jedem Entity $e_2$ gibt es maximal ein $e_1$ aus $E_1$
- Bsp: Lieferant *liefert* Produkte, Mutter *hat* Kinder
- N:1 Beziehung
- invers zu 1:N, auf funktionale Beziehung
- M:N Bezeihung
- keine Restriktionen
- Bsp: Bestellung *umfasst* Produkte
[min,max]-Notation
- schränkt die möglichen Teilnahmen von Instanzen der beteiligten Entity-Typen an der Beziehung ein, indem ein minimaler und ein maximaler Wert vorgegeben wird
- Spezielle Wertangabe für $max_i$ ist ∗
Kardinalitätsangaben
- [0, ∗] legt keine Einschränkung fest (default)
- $R(E_1 [0, 1], E_2 )$ entspricht einer (partiellen) funktionalen Beziehung $R : E_1 \rightarrow E_2$ , da jede Instanz aus $E_1$ maximal einer Instanz aus $E_2$ zugeordnet ist
- totale funktionale Beziehung wird durch $R(E_1 [1, 1], E_2 )$ modelliert
- Änderungsoperationen auf Basisrelationen mit Redundanzen nur schwer korrekt umsetzbar:
- wenn eine Information redundant vorkommt, muss eine Änderung diese Information in allen ihren Vorkommen verändern
- mit normalen relationalen Änderungsoperationen und den in
- relationalen Systemen vorkommenden lokalen
- Integritätsbedingungen (Schlüsseln) nur schwer realisierbar
Funktionale Abhängigkeit zwischen Attributemengen X und Y
> Wenn in jedem Tupel der Relation der Attributwert unter den X-Komponenten den Attributwert unter den Y-Komponenten festlegt.
- Unterscheiden sich zwei Tupel in den X-Attributen nicht, so haben sie auch gleiche Werte für alle Y-Attribute
- Notation für funktionale Abhängigkeit (FD, von functional dependency): X → Y
> Ziel des Datenbankentwurfs: alle gegebenen funktionalen Abhängigkeiten in Schlüsselabhängigkeiten umformen, ohne dabei semantische Information zu verlieren
## Normalformen
Schemaeigenschaften
- Relationenschemata, Schlüssel und Fremdschlüssel so wählen, dass
1. alle Anwendungsdaten aus den Basisrelationen hergeleitet werden können,
2. nur semantisch sinnvolle und konsistente Anwendungsdaten dargestellt werden können und
3. die Anwendungsdaten möglichst nicht-redundant dargestellt werden.
- Hier: Forderung 3
- Redundanzen innerhalb einer Relation: Normalformen
- globale Redundanzen: Minimalität
Normalformen
- legen Eigenschaften von Relationenschemata fest
- verbieten bestimmte Kombinationen von funktionalen Abhängigkeiten in Relationen
- sollen Redundanzen und Anomalien vermeiden
1. Erste Normalform
- erlaubt 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
2. Zweite Normalform
- Zweite Normalform eliminiert derartige partielle Abhängigkeiten bei Nichtschlüsselattributen
- partielle Abhängigkeit liegt vor, wenn ein Attribut funktional schon von einem Teil des Schlüssels abhängt
- etwa Weingut $\rightarrow$ Anbaugebiet und Anbaugebiet $\rightarrow$ Region in Relation
- man beachte: 3 NF betrachtet nur Nicht-Schlüsselattribute als Endpunkt transitiver Abhängigkeiten
- Beispielrelation in 3NF, transitive Abhängigkeit in R3, d.h. R3 verletzt 3NF
- R3_1(Weingut, Anbaugebiet)
- R3_2(Anbaugebiet, Region)
> Dritte Normalform:
> - $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$
> - erweitertes Relationenschema $R=(R, \bf{K})$ ist in 3 NF bezüglich F genau dann, wenn $\not\exists A \in R$:
> - A ist Nicht-Primattribut in R
> - $\wedge A$ transitiv abhängig von einem $K\in \bf{K}$ bezüglich $F_i$.
> - Nicht-Primattribut: A ist in keinem Schlüssel von R enthalten
> 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
Minimalität
- Global Redundanzen vermeiden
- andere Kriterien (wie Normalformen) mit möglichst wenig Schemata erreichen
| | 2 NF | keine partielle Abhängigkeit eines Nicht-Primattributes von einem Schlüssel |
| S1 | 3 NF | keine transitive Abhängigkeit eines Nicht-Primattributs von einem Schlüssel |
| | BCNF | keine transitive Abhängigkei eines Attributes von einem Schlüssel |
| S2 | Minimalität | minimale Anzahl von Relationsschemata, die die anderen Eigenschaften erfüllt |
## Transformationseigenschaften
- bei einer Zerlegung einer Relation in mehrere Relationen ist darauf zu achten, dass
1. nur semantisch sinvolle und konsistente Anwendungsdaten dargestellt (Abhängigkeitstreue) und
2. alle Anwendungsdaten aus den Basisrelationen hergeleitet werden können (Verbundtreue)
- Abhänggikeitstreue (Kennung T1)
- alle gegebenen Abhängigkeiten sind durch Schlüssel repräsentiert
- eine Menge von Abhängigkeiten kann äquivalent in eine zweite Menge von Abhängigkeiten transformiert werden
- spezieller: in die Menge der Schlüsselabhängigkeiten, da diese vom Datenbanksystem effizient überprüft werden kann
- die Menge der Abhängigkeiten soll äquivalent zu der Menge der Schlüsselbedingungen im resultierenden Datenbankschema sein
- Ä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
- 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}\}$
- Verbundtreue (Kennung T2)
- Originalrelationen können durch den Verbund der Basisrelationen wiedergewonnen werden
- zur Erfüllung des Kriteriums der Normalformen müssen Relationenschemata teilweise in kleinere Relationenschemata zerlegt werden
- 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
- Zerlegung des Relationenschemas $R = ABC$ in $R_1 = AB$ und $R_2 = BC$
- Dekomposition bei Vorliegen der Abhängigkeiten $F = \{A \rightarrow B, C \rightarrow B\}$ ist nicht verbundtreu
- dagegen bei Vorliegen von $F′ = \{A \rightarrow B, B \rightarrow C\}$ verbundtreu
> Verbundtreue: Die Dekomposition einer Attributmenge $X$ in $X_1,..., X_p$ mit $X = \bigcup_{i=1}^p X_i$ heißt verbundtreu ($\pi \bowtie$-treu, lossless) bezüglich einer Menge von Abhängigkeiten F über X genau dann, wenn $\forall r \in SAT_X(F) : \pi_{X_1}(r) \bowtie ··· \bowtie \pi_{X_p}(r) = r$ gilt.
## Weitere Abhängigkeiten
- Mehrwertige Abhängigkeit (kurz: MVD)
- 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
- Folge der 1NF: Mehrwertige Abhängigkeiten erzeugen Redundanz
- eine (oder mehrere) Gruppe von Attributwerten ist von einem Schlüssel bestimmt, unabhängig von anderen Attributen
- Resultat: Redundanz durch Bildung aller Kombinationen
- wünschenswerte Schemaeigenschaft bei Vorliegen von MVDs: vierte Normalform
- fordert die Beseitigung derartiger Redundanzen: keine zwei MVDs zwischen Attributen einer Relation
- Elimination der rechten Seite einer der beiden mehrwertigen Abhängigkeiten,
- linke Seite mit dieser rechten Seite in neue Relation kopiert
- Verbundabhängigkeit (kurz: JD)
- R kann ohne Informationsverlust in $R_1,..., R_p$ aufgetrennt werden: $\bowtie [R_1,..., R_p]$
- Inklusionsabhängigkeit (kurz: IND)
- auf der rechten Seite einer Fremdschlüsselabhängigkeit nicht unbedingt der Primärschlüssel einer Relation
> 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}$
- F5: Vereinigung $\{X\rightarrow Y, X\rightarrow Z\}\Rightarrow X\rightarrow YZ$
- F6: Pseudotransitivität $\{X\rightarrow Y, WY\rightarrow Z\}\Rightarrow WX\rightarrow Z$
F1-F3 bekannt als Armstrong-Axiome (sound, complete)
- gültig (sound): Regeln leiten keine FDs ab, die logisch nicht impliziert
- vollständig (complete): alle implizierten FDs werden abgeleitet
- unabhängig (independent) oder auch bzgl. ⊆ minimal: keine Regel kann weggelassen werden
Alternative Regelmenge
- B-Axiome oder RAP-Regeln
- R Reflexivität $\{\}\Rightarrow X\rightarrow X$
- A Akkumulation $\{X\rightarrow YZ, Z\rightarrow AW\}\Rightarrow X\rightarrow YZA$
- P Projektivität $\{X\rightarrow YZ\}\Rightarrow X\rightarrow Y$
- Regelmenge ist vollständig, da Armstrong-Axiome daraus abgeleitet werden können
> 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^+$
- Hülle einer Attributmenge X bzgl. F ist $X^+_F := \{A | X\rightarrow A \in F^+\}$
- Membership-Problem kann durch das modifizierte Problem $Y\subseteq X_F^+$ in linearer Zeit gelöst werden
Überdeckungen
- F heißt äquivalent zu G; oder
- F Überdeckung von G; kurz: $F\equiv G$ falls $F^+=G^+$
- verschiedene Formen von Überdeckung: nicht-redundant, reduziert, minimal, ringförmig
Reduktionsoperationen
- Ziel: Entfernen überflüssiger Attribute auf linker bzw. rechter Seite von FDs
- Linksreduktion: entfernt unwesentliche Attribute auf der linken Seite einer FD
- Rechtsreduktion: entsprechend auf der rechten Seite
- erw. Relationenschema $R = (R, K)$, FD-Menge F über R, A ist ein Attribut aus R und $X\rightarrow Y$ eine FD aus F
> Unwesentliche Attribute
> A heißt unwesentlich in $X\rightarrow Y$ bzgl. F, wenn
>- $X=AZ,Z\not= X \Rightarrow (F-\{X\rightarrow Y\})\cup \{Z\rightarrow Y\} \equiv F$ oder
- A kann also aus der FD $X\rightarrow Y$ entfernt werden, ohne dass sich die Hülle von F ändert
- FD $X\rightarrow Y$ heißt linksreduziert, wenn kein Attribut in X unwesentlich ist
- FD $X\rightarrow Y$ heißt rechtsreduziert, wenn kein Attribut in Y unwesentlich ist
Minimale Überdeckung
- Eine minimale Überdeckung ist eine Überdeckung, die eine minimale Anzahl von FDs enthält
- Auswahl der kleinsten aller nicht-redundanten Überdeckungen
- FD-Menge F heißt minimal gdw. $\forall F' [F'\equiv \Rightarrow |F|\leq |F'|]$
- Bestimmung etwa durch reduzierte Überdeckung mit anschließender Äquivalenzklassenbildung (später)
Äquivalenzklassen
- FDs mit äquivalenten linken Seiten werden zu einer Äquivalenzklasse zusammengefasst
- FDs $X_1 \rightarrow Y_1$ und $X_2\rightarrow Y_2$ liegen in einer Äquivalenzklasse, wenn $X_1\rightarrow X_2$ und $X_2\rightarrow X_1$ gelten
- In einigen Fällen können nun zwei solche FDs in einer Äquivalenzklasse zu einer FD $X\rightarrow Y_1 Y_2$ zusammengefasst werden
- Da die FDs einer Äquivalenzklasse in die Form $X_1\rightarrow X_2, X_2\rightarrow X_3,..., X_n\rightarrow X_1, X_1\rightarrow Y$ überführt werden können, nennt man eine Überdeckung dieser Form eine ringförmige Überdeckung
- linke Seiten sind äquivalent, wenn sie sich gegenseitig funktional bestimmen
## Mehr zu Normalformen
- partielle Abhängigkeit liegt vor, wenn ein Attribut funktional schon von einem Teil des Schlüssels abhängt
- Hinweis: partiell abhängiges Attribut stören nur, wenn es kein Primattribut ist
- 2NF formal: erweitertes Relationenschema $R = (R, K)$, FD-Menge F über R
> Zweite Normalform
> - Y hängt partiell von X bzgl. F ab, wenn die FD $X\rightarrow Y$ nicht linksreduziert ist
> - Y hängt voll von X ab, wenn die FD $X\rightarrow Y$ linksreduziert ist
> - R ist in 2NF, wenn R in 1NF ist und jedes Nicht-Primattribut von R voll von jedem Schlüssel von R abhäng
## Entwurfsverfahren
Ziele:
- Universum $U$ und FD-Menge F gegeben
- lokal erweitertes Datenbankschema $S=\{(R_1, K_1),...,(R_p, K_p)\}$ berechnen mit
- T1: S charakterisiert vollständig F
- S1: S ist in 3NF bezüglich F
- T2: Dekomosition von $U$ in $R_1,...,R_p$ ist verbundtreu bezüglich F
- S2: Minimalität, d.h. $\not\exists S':S'$ erfüllt T1,S1,T2 und $|S'|<|S|$
Dekomposition:
- Geg.: initiales Universalrelationenschema $R = (U, K(F))$ mit allen Attributen und einer von erfassten FDs F über R implizierten Schlüsselmenge
- Attributmenge U und eine FD-Menge F
- suche alle $K\rightarrow U$ mit K minimal, für die $K\rightarrow U \in F^+$ gilt $(K(F))$
- Ges.: Zerlegung in $D = \{R_1, R_2,... \}$ von 3NF-Relationenschemata
- Prinzip: Synthese formt Original-FD-Menge F in resultierende Menge von Schlüsselabhängigkeiten G so um, dass $F\equiv G$ gilt
- „Abhängigkeitstreue“ im Verfahren verankert
- 3NF und Minimalität wird auch erreicht, reihenfolgeunabhängig
- Zeitkomplexität: quadratisch
Syntheseverfahren für Relationenschema R mit FDs F
- Ges.: verlustfreie und abhängigkeitstreue Zerlegung in $R_1,... R_n$, wobei alle $R_i$ in 3NF sind
- Bilde Äquivalentklassen $C_i$ von FD aus $\hat{F}$ mit gleichen oder äquivalenten linken Seiten, d.h. $C_i=\{X_i\rightarrow A_{i1},X_i\rightarrow A_{i2},...\}$. Bilde zu jeder Äquivalenzklasse $C_i$ ein Schema der Form $R_{Ci}=\{X_i\cup \{A_{i1}\}\cup \{A_{i2}\}\cup ... \}$. Falls keines der Schemata $R_{Ci}$ enthält einen Schlüssel von R, erzeuge weiteres Relationenschema $R_K$ mit Attributen aus R, die Schlüssel bilden
- Vereinigung, Durchschnitt und Differenz als union, intersect und except
- orthogonal einsetzbar:
-`select * from (select Weingut from ERZEUGER except select Weingut from WEINE)`
- äquivalent zu `select * from ERZEUGER except corresponding WEINE`
- über corresponding by-Klausel: Angabe der Attributliste, über die Mengenoperation ausgeführt wird
-`select * from ERZEUGER except corresponding by (Weingut) WEINE`
- bei Vereinigung: Defaultfall ist Duplikateliminierung (union distinct); ohne Duplikateliminierung durch union all
### Geschachtelte Anfragen
Schachtelung von Anfragen
- für Vergleiche mit Wertemengen notwendig:
- Standardvergleiche in Verbindung mit den Quantoren all ($\forall$) oder any ($\exists$)
- spezielle Prädikate für den Zugriff auf Mengen, in und exists
- in-Prädikat und geschachtelte Anfragen
- Notation: `attribut in ( SFW-block )`
- Beispiel: `select Name from WEINE where Weingut in (select Weingut from ERZEUGER where Region = 'Bordeaux')`
- Auswertung von geschachtelten Anfragen
1. Auswertung der inneren Anfrage zu den Weingütern aus Bordeaux
2. Einsetzen des Ergebnisses als Menge von Konstanten in die äußere Anfrage hinter in
3. Auswertung der modifizierten Anfrage
`select Name from WEINE where Weingut in ( 'Château La Rose', 'Château La Pointe')`
- interne Auswertung: Umformung in einen Verbund
`select Name from WEINE natural join ERZEUGER where Region = 'Bordeaux'`
- Negation des in-Prädikats
- Simulation des Differenzoperators $^π Weingut^{(ERZEUGER)}- ^π Weingut^{(WEINE)}$ durch SQL-Anfrage
`select Weingut from ERZEUGER where Weingut not in ( select Weingut from WEINE )`
### Mächtigkeit des SQL-Kerns
| Relationenalgebra | SQL |
| -- | -- |
| Projektion | select distinct |
| Selektion | where ohne Schachtelung |
| Verbund | from, where\\ from mit join oder natural join |
| Umbenennung | from mit Tupelvariable; as |
| Differenz | where mit Schachtelung\\ except corresponding |
| Durchschnitt | where mit Schachtelung\\ intersect corresponding |
| Vereinigung | union corresponding |
## Erweiterungen des SFW-Blocks
Erweiterungen des SFW-Blocks
- innerhalb der from-Klausel weitere Verbundoperationen (äußerer Verbund),
- innerhalb der where-Klausel weitere Arten von Bedingungen und Bedingungen mit Quantoren,
- innerhalb der select-Klausel die Anwendung von skalaren Operationen und Aggregatfunktionen,
- zusätzliche Klauseln group by und having
- rekursive Anfragen
### Skalare Ausdrücke
Umbenennung von Spalten: `ausdruck as neuer-name`
- skalare Operationen auf
- numerischen Wertebereichen: etwa +, −, ∗ und /,
- Strings: Operationen wie char_length (aktuelle Länge eines Strings), die Konkatenation ∥ und die Operation substring (Suchen einer Teilzeichenkette an bestimmten Positionen des Strings),
- Datumstypen und Zeitintervallen: Operationen wie current_date (aktuelles Datum), current_time (aktuelle Zeit), +, − und ∗
- bedingte Ausdrücke
- Typkonvertierung
- skalare Ausdrücke können mehrere Attribute umfassen
- Anwendung ist tupelweise: pro Eingabetupel entsteht ein Ergebnistupel
- Ausgabe der Namen aller Grand Cru-Weine
`select substring(Name from 1 for (char_length(Name) - position('Grand Cru' in Name))) from WEINE where Name like '%Grand Cru'`
- Annahme: zusätzliches Attribut HerstDatum in WEINE
`alter table WEINE add column HerstDatum date update WEINE set HerstDatum = date '2004-08-13' where Name = 'Zinfandel'`
- Anfrage:
`select Name, year(current_date - HerstDatum) as Alter from WEINE`
### Bedingte Ausdrücke
- case-Anweisung: Ausgabe eines Wertes in Abhängigkeit von der Auswertung eines Prädikats
`case when prädikat_1 then ausdruck_1 ... when prädikat_n−1 then ausdruck_n−1 [ else ausdruck_n ] end`
- Einsatz in select- und where-Klausel
`select case when Farbe = 'Rot' then 'Rotwein' when Farbe = 'Weiß' then 'Weißwein' else 'Sonstiges' end as Weinart, Name from WEINE`
### Typkonvertierung
- explizite Konvertierung des Typs von Ausdrücken
`cast(ausdruck as typname)`
- Beispiel: int-Werte als Zeichenkette für Konkatenationsoperator
`select cast(Jahrgang as varchar) || 'er ' || Name as Bezeichnung from WEINE`
### Quantoren und Mengenvergleiche
- Quantoren: all, any, some und exists
- Notation
`attribut θ { all | any | some } ( select attribut from ...where ...)`
- all: where-Bedingung wird erfüllt, wenn für alle Tupel des inneren SFW-Blocks der θ-Vergleich mit attribut true wird
- any bzw. some: where-Bedingung wird erfüllt, wenn der θ-Vergleich mit mindestens einem Tupel des inneren SFW-Blocks true wird
- Bestimmung des ältesten Weines
`select * from WEINE where Jahrgang <= all ( select Jahrgang from WEINE)`
- alle Weingüter, die Rotweine produzieren
`select * from ERZEUGER where Weingut = any ( select Weingut from WEINE where Farbe = 'Rot')`
### Vergleich von Wertemengen
- Test auf Gleichheit zweier Mengen allein mit Quantoren nicht möglich
- Beispiel: „Gib alle Erzeuger aus, die sowohl Rot- als auch Weißweine produzieren.“
- falsche Anfrage `select Weingut from WEINE where Farbe = 'Rot' and Farbe = 'Weiß'`
- richtige Anfrage `select w1.Weingut from WEINE w1, WEINE w2 where w1.Weingut = w2.Weingut and w1.Farbe = 'Rot' and w2.Farbe = 'Weiß'`
### Das exists/not exists-Prädikat
- einfache Form der Schachtelung
`exists ( SFW-block )`
- liefert true, wenn das Ergebnis der inneren Anfrage nicht leer ist
- speziell bei verzahnt geschachtelten (korrelierte) Anfragen sinnvoll
- in der inneren Anfrage wird Relationen- oder Tupelvariablen-Name aus dem from-Teil der äußeren Anfrage verwendet
### Verzahnt geschachtelte Anfragen
Weingüter mit 1999er Rotwein
```sql
select * from ERZEUGER
where 1999 in (
select Jahrgang from WEINE
where Farbe='Rot' and
WEINE.Weingut = ERZEUGER.Weingut)
```
konzeptionelle Auswertung
1. Untersuchung des ersten ERZEUGER-Tupels in der äußeren Anfrage (Creek) und Einsetzen in innere Anfrage
2. Auswertung der inneren Anfrage
3. Weiter bei 1. mit zweitem Tupel ...
## Aggregatfunktionen und Gruppierungen
- Aggregatfunktionen berechnen neue Werte für eine gesamte Spalte, etwa die Summe oder den Durchschnitt der Werte einer Spalte
- Beispiel: Ermittlung des Durchschnittspreises aller Artikel oder des Gesamtumsatzes über alle verkauften Produkte
- bei zusätzlicher Anwendung von Gruppierung: Berechnung der Funktionen pro Gruppe, z.B. der Durchschnittspreis pro Warengruppe oder der Gesamtumsatz pro Kunde
- Aggregatfunktionen in Standard-SQL:
- count: berechnet Anzahl der Werte einer Spalte oder alternativ (im Spezialfall count(∗)) die Anzahl der Tupel einer Relation
- sum: berechnet die Summe der Werte einer Spalte (nur bei numerischen Wertebereichen)
- avg: berechnet den arithmetischen Mittelwert der Werte einer Spalte (nur bei numerischen Wertebereichen)
- max bzw. min: berechnen den größten bzw. kleinsten Wert einer Spalte
- Argumente einer Aggregatfunktion:
- ein Attribut der durch die from-Klausel spezifizierten Relation,
- ein gültiger skalarer Ausdruck oder
- im Falle der count-Funktion auch das Symbol ∗
- vor dem Argument (außer im Fall von count(∗)) optional auch die Schlüsselwörter distinct oder all
- distinct: vor Anwendung der Aggregatfunktion werden doppelte Werte aus der Menge von Werten, auf die die Funktion angewendet wird
- all: Duplikate gehen mit in die Berechnung ein (Default-Voreinstellung)
- Nullwerte werden in jedem Fall vor Anwendung der Funktion aus der Wertemenge eliminiert (außer im Fall von count(∗))
- Beispiel: Anzahl der Weine:
`select count(*) as Anzahl from WEINE`
- Beispiel: Anzahl der verschiedenen Weinregionen:
`select count(distinct Region) from ERZEUGER`
- Weine, die älter als der Durchschnitt sind:
`select Name, Jahrgang from WEINE where Jahrgang < ( select avg(Jahrgang) from WEINE)`
- Schachtelung von Aggregatfunktionen nicht erlaubt
`select f 1 (f 2 (A)) as Ergebnis from R ...` -- (falsch!);
mögliche Formulierung: `select f 1 (Temp) as Ergebnis from ( select f 2 (A) as Temp from R ...)`
- Aggregatfunktionen in where-Klausel
- Aggregatfunktionen liefern nur einen Wert ⇝ Einsatz in Konstanten-Selektionen der where-Klausel möglich
- alle Weingüter, die nur einen Wein liefern:
`select * from ERZEUGER e where 1 = ( select count(*) from WEINE w where w.Weingut = e.Weingut )`
- group by und having
- Notation
- select ...
- from ...
- [where ...]
- [group by attributliste ]
- [having bedingung ]
- Beispiel
- Regionen mit mehr als einem Wein
`select Region, count(*) as Anzahl from ERZEUGER natural join WEINE group by Region having count(*) > 1`
- bisher: Relationenschemata mit Basisrelationen, die in der Datenbank gespeichert sind
- jetzt: „abgeleitete“ Relationenschemata mit virtuellen Relationen, die aus den Basisrelationen berechnet werden (Basisrelationen bleiben unverändert)
Begriffe
- Anfrage: Folge von Operationen, die aus den Basisrelationen eine Ergebnisrelation berechnet
- Ergebnisrelation interaktiv auf dem Bildschirm anzeigen oder
- per Programm weiterverarbeiten („Einbettung“)
- Sicht: Folge von Operationen, die unter einem Sichtnamen langfristig abgespeichert wird und unter diesem Namen wieder aufgerufen werden kann; ergibt eine Sichtrelation
- Snapshot: Ergebnisrelation einer Anfrage, die unter einem Snapshot-Namen abgelegt wird, aber nie ein zweites Mal (mit geänderten Basisrelationen) berechnet wird (etwa Jahresbilanzen)
Kriterien für Anfragesprachen
- Ad-Hoc-Formulierung: Benutzer soll eine Anfrage formulieren können, ohne ein vollständiges Programm schreiben zu müssen
- Deskriptivität: Benutzer soll formulieren „Was will ich haben?“ und nicht „Wie komme ich an das, was ich haben will?“
- Mengenorientiertheit: jede Operation soll auf Mengen von Daten gleichzeitig arbeiten, nicht navigierend nur auf einzelnen Elementen („one-tuple-at-a-time“)
- Abgeschlossenheit: Ergebnis ist wieder eine Relation und kann wieder als Eingabe für die nächste Anfrage verwendet werden
- Adäquatheit: alle Konstrukte des zugrundeliegenden Datenmodells werden unterstützt
- Orthogonalität: Sprachkonstrukte sind in ähnlichen Situationen auch ähnlich anwendbar
- Optimierbarkeit: Sprache besteht aus wenigen Operationen, für die es Optimierungsregeln gibt
- Effizienz: jede Operation ist effizient ausführbar (im Relationenmodell hat jede Operation eine Komplexität ≤ O(n 2 ), n Anzahl der Tupel einer Relation).
- Sicherheit: keine Anfrage, die syntaktisch korrekt ist, darf in eine Endlosschleife geraten oder ein unendliches Ergebnis liefern
- Eingeschränktheit: (folgt aus Sicherheit, Optimierbarkeit, Effizienz) Anfragesprache darf keine komplette Programmiersprache sein
- Vollständigkeit: Sprache muss mindestens die Anfragen einer Standardsprache ausdrücken können
## Anfragealgebren
- Mathematik: Algebra definiert durch Wertebereich und auf diesem definierte Operatoren
- für Datenbankanfragen: Inhalte der Datenbank sind Werte, und Operatoren definieren Funktionen zum Berechnen von Anfrageergebnissen
- Relationenalgebra
- Algebra-Erweiterungen
Relationenalgebra
- Spalten ausblenden: Projektion π
- Zeilen heraussuchen: Selektion σ
- Tabellen verknüpfen: Verbund (Join) ⋊
- Tabellen vereinigen: Vereinigung ∪
- Tabellen voneinander abziehen: Differenz −
- Spalten umbenennen: Umbenennung β (wichtig für ⋊ und ∪, −)
Projektion
- Syntax $\pi_{Attributmenge}(Relation)$
- Semantik $\pi_X (r) := \{t(X) | t \in r\}$
- für r(R) und X ⊆ R Attributmenge in R
- Eigenschaft für Y ⊆ X ⊆ R
- $\pi_Y (\pi_X (r)) = \pi_Y (r)$
- Achtung: π entfernt Duplikate (Mengensemantik)
Selektion
- Syntax $\sigma_{Bedingung} (Relation)$
- Semantik (für A ∈ R) $\sigma_{A=a}(r) := \{t \in r | t(A) = a\}$
- Konstantenselektion $Attribut θ Konstante$
- boolesches Prädikat θ ist = oder$\not=$, bei linear geordneten Wertebereichen auch ≤, <, ≥ oder >
- Attributselektion $Attribut1 θ Attribut2$
- logische Verknüpfung mehrerer Konstanten- oder Attribut-Selektionen mit ∧, ∨ oder ¬
- unabhängig: kein Operator kann weggelassen werden ohne Vollständigkeit zu verlieren
- andere unabhängige Menge: ⋉ und β durch × ersetzen
- Relationale Vollständigkeit: jede andere Menge von Operationen genauso mächtig wie Ω
- strenge relationale Vollständigkeit: zu jedem Ausdruck mit Operatoren aus Ω gibt es einen Ausdruck auch mit der anderen Menge von Operationen
## Erweiterungen der Relationenalgebra
Verbundvarianten
- Gleichverbund (engl. equi-join): Gleichheitsbedingung über explizit angegebene und evtl. verschiedene Attribute
- $r(R) \bowtie_{C=D} r(S)$
- Theta-Verbund (engl. θ-join): beliebige Verbundbedingung
- $r(R) \bowtie_{C>D} r(S)$
- Semi-Verbund: nur Attribute eines Operanden erscheinen im Ergebnis
- $r(L) \bowtie r(R) = \pi_L (r(L) \bowtie r(R))$
- äußere Verbunde (engl. outer join)
- voller äußerer Verbund übernimmt alle Tupel beider Operanden
- linker äußerer Verbund übernimmt alle Tupel des linken Operanden
- rechter äußerer Verbund übernimmt alle Tupel des rechten Operanden
Problem: Quantoren
- Allquantor in Relationenalgebra ausdrücken, obwohl in Selektionsbedingungen nicht erlaubt
- Division (kann aus Ω hergeleitet werden)
> 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.
Gruppierungsoperator γ
- erweitert Attributschema von r(R) um neue Attribute, die mit den Funktionsanwendungen $f_1 (x_1 ), f_2 (x_2 ),..., f_n (x_n )$ korrespondieren
- Anwendung der Funktionen $f_i (x_i)$ auf die Teilmenge derjenigen Tupel von $r(R)$ die gleiche Attributwerte für die Attribute A haben
## Anfragekalküle
- Kalkül: eine formale logische Sprache zur Formulierung von Aussagen
- Ziel: Einsatz eines derartigen Kalküls zur Formulierung von Datenbank-Anfragen
- Logikbasierter Ansatz:
- Datenbankinhalte entsprechen Belegungen von Prädikaten einer Logik
- basiert auf logischem Kalkül mit Bereichsvariablen
> 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.
- Syntaktisch sichere Anfragen: Anfragen, die syntaktischen Einschränkungen unterliegen, um die semantische Sicherheit zu erzwingen.
- Bindung an endliche Bereiche muss für die ganze Bedingung gelten, also insbesondere für alle Zweige einer Disjunktion
## Eigenschaften des Bereichskalküls
- Ausdrucksfähigkeit des Bereichskalküls: Bereichskalkül ist streng relational vollständig, d.h. zu jedem Term τ der Relationenalgebra gibt es einen äquivalenten (sicheren) Ausdruck η des Bereichskalküls.
- 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
- **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
- 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)
- 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: 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
- Ä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
- 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
- oft einfach als Etikett einer Neuentwicklung eines DBMS pauschal vergeben
Was ist NoSQL?
- SQL - No!
- SQL-Datenbanken sind zu komplex, nicht skalierbar, ...
- man braucht was einfacheres!
- Not only SQL
- SQL-Datenbanken haben zu wenig (oder die falsche) Funktionalität
- Operationen auf Graphen, Data Mining Operatoren, ...
- New SQL
- SQL-Datenbanken sind (software-technisch) in die Jahre gekommen
- eine neue Generation von DBMS muss her (ohne die etablierten Vorteile von SQL zu ignorieren)
Kritik an RDBMS / SQL
- nicht skalierbar
- Normalisierung von Relationen, viele Integritätsbedingungen zu prüfen
- kann man in RDBMS auch vermeiden!
- starre Tabellen nicht flexibel genug
- schwach typisierte Tabellen (Tupel weichen in den tatsächlich genutzten Attributen ab)
- viele Nullwerte wenn alle potentiellen Attribute definiert
- alternativ Aufspaltung auf viele Tabellen
- Schema-Evolution mit alter table skaliert bei Big Data nicht
- tatsächlich in vielen Anwendungen ein Problem
- Integration von spezifischen Operationen (Graphtraversierung, Data-Mining-Primitive) mit Stored Procedures zwar möglich führt aber oft zu schwer interpretierbarem Code
## Datenmodelle für NoSQL
Datenmodelle für NoSQL
- KV-Stores
- Wide Column Stores
- Dokumenten-orientierte Datenhaltung
- Graph-Speicher
- ...
Anfragesprachen für NoSQL
- unterschiedliche Ansätze:
- einfache funktionale API
- Programmiermodell für parallele Funktionen
- angelehnt an SQL-Syntax
- ...
## KV-Stores und Wide Column
Datenmodell: Key-Value-Stores
- Key-Value-Store: binäre Relationen, bestehend aus
- einem Zugriffsschlüssel (dem Key) und
- den Nutzdaten (dem Value)
- Nutzdaten
- binäre Daten ohne Einschränkung,
- Dateien oder Dokumente, → Document Databases
- oder schwachstrukturierte Tupel → Wide Column Store
- Anfragen an KV-Stores
- einfache API
```sql
store.put(key, value)
value = store.get(key)
store.delete(key)
```
- aufgesetzte höherer Sprache angelehnt an SQL
- Map-Reduce: Framework zur Programmierung paralleler Datenaggregation auf KV-Stores
- Beispielsysteme für KV-Stores
- Amazon DynamoDB
- Riak
Datenmodell: Wide Column
- Basisidee: KV-Store mit schwachstrukturiertem Tupel als Value
- Value = Liste von Attributname-Attributwert-Paaren
- schwache Typisierung für Attributwerte (auch Wiederholgruppen)
- nicht alle Einträge haben die selben Attributnamen
- offene Tupel
- Hinzufügen eines neuen Attributs unproblematisch
- Nullwerte aus SQL ersetzt durch fehlende Einträge
- Beispiel in DynamoDB
- Anfragen bei Wide Column
- CRUD: Create, Read, Update und Delete
- in DynamoDB
- *PutItem* fügt einen neuen Datensatz mit der gegebenen Attribut-Wert-Liste ein bzw. ersetzt einen existierenden Datensatz mit gleichem Schlüssel.
- *GetItem*-Operation liest alle Felder eines über einen Primärschlüssel identifizierten Datensatzes.
- *Scan* erlaubt einen Lauf über alle Datensätze mit Angabe von Filterkriterien.
- Aufruf über HTTP oder aus Programmiersprachen heraus
## Document Stores
Datenmodell: dokumentenorientierte Speicherung
- Basisidee: KV-Store mit (hierarchisch) strukturiertem Dokument als Value
- strukturiertes Dokument:
- JSON-Format: geschachtelte Wide Column-Daten
- XML (eher unüblich auf KV-Stores)
- Anfragen bei dokumentenorientierter Speicherung
- CRUD erweitert um dokumentspezifische Suche
- Beispiele (MongoDB mit BSON statt JSON) `db.kritiker.find({Name: "Bond"})`
- Beispielsysteme für dokumentenorientierte Speicherung
- MongoDB
- CouchDB
## Graph Stores
Graph-Datenmodelle: Grundlagen
- spezielle Form der Datenrepräsentation = Graphen, insb. Beziehungen zwischen Objekten
- OO: Klasse definiert Eigenschaften von Objekten (Intension) + umfasst Menge aller Objekte (Extension)
- RM: Relation umfasst alle Tupel, Relationenschema beschreibt Struktur
- naheliegend: Klasse = Tabelle
- aber: Normalisierung zerlegt Relationen!
- 1 Klasse = 1 Tabelle
- 1 Klasse = n Tabellen
- n Klassen = 1 Tabelle
- Beispiel 
Beziehungen
- eingebetteter Fremdschlüssel in der Relation der Klasse, d.h. der Identifikator des assoziierten Objektes wird als Fremdschlüssel in zusätzlichen Spalten gespeichert
- Fremdschlüsseltabellen: die Beziehungsinstanz wird als Tupel mit den Schlüsseln der beteiligten Objekte repräsentiert
- Abbildung der in Beziehung stehenden Klassen auf eine einzelne Tabelle: Verletzung der Normalformen
- konkrete Abbildung
- 1:1-Beziehungen: eingebettete Fremdschlüssel
- 1:n-Beziehungen: eingebettete Fremdschlüssel oder Fremdschlüsseltabellen
- Beziehungen mit Attributen: Fremdschlüsseltabellen
- m:n-Beziehungen: Fremdschlüsseltabellen
- Drei- und mehrstellige Beziehungen: Fremdschlüsseltabellen
