diff --git a/Datenbanksysteme - Cheatsheet.pdf b/Datenbanksysteme - Cheatsheet.pdf index c598d3a..0f74b9d 100644 Binary files a/Datenbanksysteme - Cheatsheet.pdf and b/Datenbanksysteme - Cheatsheet.pdf differ diff --git a/Datenbanksysteme - Cheatsheet.tex b/Datenbanksysteme - Cheatsheet.tex index c2e82be..9a5bb80 100644 --- a/Datenbanksysteme - Cheatsheet.tex +++ b/Datenbanksysteme - Cheatsheet.tex @@ -118,7 +118,7 @@ \setlength{\columnsep}{2pt} \section{SQL} -\begin{lstlisting}[ + \begin{lstlisting}[ language=SQL, showspaces=false, basicstyle=\ttfamily, @@ -129,10 +129,9 @@ CREATE TABLE t ( c1 TEXT, name VARCHAR NOT NULL, price INT DEFAULT 0, - - PRIMARY KEY (c1), + PRIMARY KEY (id), FOREIGN KEY (c1) REFERENCES t2(c2), - UNIQUE(c1,name), + UNIQUE(id,name), CHECK(id> 0 AND price >= id) ); @@ -142,14 +141,14 @@ ALTER TABLE t DROP COLUMN c; //Drop column ALTER TABLE t ADD constraint; //Add constraint ALTER TABLE t1 RENAME TO t2; //Rename table ALTER TABLE t DROP constraint; //Drop constraint -ALTER TABLE t1 RENAME c1TO c2; //Rename column +ALTER TABLE t1 RENAME c1 TO c2; //Rename column INSERT INTO t(column_list) VALUES(value_list); ...SELECT column_list FROM t2; UPDATE t SET c1= new_value; UPDATE t SET c1 = new_value WHERE condition; DELETE FROM t; //Delete all data -DELETE FROM tWHERE condition; //Delete subset +DELETE FROM t WHERE condition; //Delete subset SELECT c1, c2 FROM t //Query data SELECT c1, c2 FROM t1, t2 //cross join @@ -161,7 +160,7 @@ SELECT DISTINCT... //Query distinct rows ...WHERE condition //with condition ...IS [NOT] NULL - ...[NOT] LIKE pa%ttern_ //% kein/beliebig viele; $ genau ein Zeichen + ...[NOT] LIKE %xy_ //%=beliebig viele; $=ein Zeichen ...[NOT] IN value_list ...BETWEEN low AND high @@ -177,7 +176,6 @@ SELECT DISTINCT... //Query distinct rows ...FULL OUTER JOIN t2 ON condition ...CROSS JOIN t2 //Cartesian product -//Views CREATE VIEW v(c1,c2) AS SELECT c1, c2 FROM t; CREATE RECURSIVE VIEW... CREATE TEMPORARY VIEW... @@ -185,18 +183,20 @@ CREATE TEMPORARY VIEW... ...WITH [CASCADED | LOCAL] CHECK OPTION; DROP VIEW view_name; -//Index CREATE INDEX idx_name ON t(c1,c2); CREATE UNIQUE INDEX idx_name ON t(c3,c4); DROP INDEX idx_name; -//Trigger CREATE OR MODIFY TRIGGER trigger_name [BEFORE | AFTER] [INSERT | UPDATE | DELETE] ON table_name FOR EACH [ROW | STATEMENT] EXECUTE stored_procedure; DROP TRIGGER trigger_name; +CREATE ASSERTION name CHECK (praedikat) +GRANT rechte ON tabelle TO nutzer [with grant option] +REVOKE rechte ON tabelle TO nutzer [restrict | cascade ] + //AGGREGATE FUNCTIONS AVG //returns the average of a list COUNT //returns the number of elements of a list @@ -284,46 +284,6 @@ name: /ind/, // name is like %ind% \end{lstlisting} - \subsection{Überblick} - \begin{itemize*} - \item Daten = logisch gruppierte Informationseinheiten - \item Bank = Sicherheit vor Verlust, Dienstleistung - \end{itemize*} - - \subsection{Codd"sche Regeln} - \begin{enumerate*} - \item Integration: einheitliche, nichtredundante Datenverwaltung - \item Operationen: Speichern, Suchen, Ändern - \item Katalog: Zugriffe auf DBbeschreibungen im Data Dictionary - \item Benutzersichten - \item Integritätssicherung: Korrektheit des Datenbankinhalts - \item Datenschutz: Ausschluss unauthorisierter Zugriffe - \item Transaktionen: mehrere DB-Operationen als Funktionseinheit - \item Synchronisation: parallele Transaktionen koordinieren - \item Datensicherung: Wiederherstellung von Daten nach Systemfehlern - \end{enumerate*} - - Ziele: - \begin{itemize*} - \item Trennung von Modellierungssicht und interner Speicherung - \item Portierbarkeit - \item Tuning vereinfachen - \item standardisierte Schnittstellen - \end{itemize*} - - Schemata: - \begin{itemize*} - \item Konzeptuelles Schema (Ergebnis der Dateidefinition) - \item Internes Schema (Festlegung der Dateiorganisation und Zugriffspfade = Index) - \item Externes Schema (Ergebnis der Sichtdefinition) - \item Anwendungsprogramm (Ergebnis der Anwendungsprogrammierung) - \item Trennung Schema-Instanz - \begin{itemize*} - \item Schema: Metadaten, Datenbeschreibung - \item Instanz: Anwenderdaten, Datenbankzustand - \end{itemize*} - \end{itemize*} - Datenunabhängigkeit: \begin{itemize*} \item Stabilität der Benutzerschnittstelle gegen Änderungen @@ -331,6 +291,31 @@ name: /ind/, // name is like %ind% \item logisch: Änderung am konzeptuellen und gewissen externen Schemata haben keine Auswirkungen auf andere externe Schemata und Anwendungsprogramme \end{itemize*} + \subsection{Codd"sche Regeln} + \begin{description*} + \item[Integration] einheitliche, nichtredundante Datenverwaltung + \item[Operationen] Speichern, Suchen, Ändern + \item[Katalog] Zugriffe auf DBbeschreibungen im Data Dictionary + \item[Benutzersichten] + \item[Integritätssicherung] Korrektheit des Datenbankinhalts + \item[Datenschutz] Ausschluss unauthorisierter Zugriffe + \item[Transaktionen] mehrere DB-Operationen als Funktionseinheit + \item[Synchronisation] parallele Transaktionen koordinieren + \item[Datensicherung] Wiederherstellung von Daten nach Systemfehlern + \end{description*} + + Schemata: + \begin{itemize*} + \item Konzeptuelles Schema (Ergebnis der Dateidefinition) + \item Internes Schema (Festlegung Dateiorganisation/pfade = Index) + \item Externes Schema (Ergebnis der Sichtdefinition) + \item Anwendungsprogramm (Ergebnis der Programmierung) + \begin{itemize*} + \item Schema: Metadaten, Datenbeschreibung + \item Instanz: Anwenderdaten, Datenbankzustand + \end{itemize*} + \end{itemize*} + \paragraph{3 Schichten Architektur} Klassifizierung \begin{itemize*} @@ -351,49 +336,31 @@ name: /ind/, // name is like %ind% \item Betriebssystem: Externspeicherverwaltung, Speicherzuordnung \end{itemize*} - \begin{itemize*} - \item „Tabellenkopf“: Relationenschema - \item Eine Zeile der Tabelle: Tupel; Menge aller Einträge: Relation - \item Eine Spaltenüberschrift: Attribut - \item Ein Eintrag: Attributwert - \end{itemize*} - - Integritätsbedingungen: Schlüssel - \begin{itemize*} - \item Attribute einer Spalte identifizieren eindeutig gespeicherte Tupel - \item auch Attributkombinationen können Schlüssel sein - \item Schlüssel können durch Unterstreichen gekennzeichnet werden - \item Schlüssel einer Tabelle können in einer anderen Tabelle als eindeutige Verweise genutzt werden: Fremdschlüssel - \item ein Fremdschlüssel ist ein Schlüssel in einer fremden Tabelle - \end{itemize*} - \subsection{Relationenalgebra} - \begin{itemize*} - \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{description*} + \item[Selektion] $\sigma_{Bedingung} (Relation)$: Auswahl von Zeilen (WHERE) + \item[Projektion] $\pi_{Attributmenge}(Relation)$: Auswahl von Spalten; entfernt doppelte Tupel; (SELECT DISTINCT) + \item[Verbund] $R_1 \bowtie R_2$: verknüpft Tabellen über gleichbenannte Spalten, verschmilzt jew Tupel gleicher Werte; Tupel ohne Partner eliminiert (JOIN/ NATURAL JOIN) + \item[Umbenennung] $\beta_{neu\leftarrow alt} (R)$: Ändern von Attributnamen (AS) + \item[Vereinigung] $r_1 \cup r_2$ von zwei Relationen $r_1$ und $r_2$ (UNION) \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 - \end{itemize*} + \item[Differenz] $r_1 - r_2$ eliminiert die Tupel aus der ersten Relation, die auch in der zweiten Relation vorkommen (EXCEPT) + \item[Durchschnitt] $r_1 \cap r_2$: ergibt die Tupel, die in beiden Relationen gemeinsam vorkommen (INTERSECT) + \item[Quantoren/Mengenvergleiche] $\Theta =\{ all \| any \| some \}$ + \item[Assertion] Prädikat, das eine Bedingung ausdrückt, die von der Datenbank immer erfüllt sein muss + \item[Trigger] Anweisung/Prozedur, die bei Eintreten eines bestimmten Ereignisses automatisch vom DBMS ausgeführt wird + \item[Sicht] virtuelle Relationen (bzw virtuelle Datenbankobjekte in anderen Datenmodellen) + \end{description*} \paragraph{Datenbankmodelle im Überblick} \begin{itemize*} - \item HM: hierarchisches Modell, - \item NWM: Netzwerkmodell, + \item HM: hierarchisches Modell, + \item NWM: Netzwerkmodell, \item RM: Relationenmodell - \item NF 2: Modell der geschachtelten (Non-First-Normal-Form) Relationen + \item NF 2: Geschachtelte (Non-First-Normal-Form) Relationen \item eNF 2: erweitertes NF 2 -Modell \item ER: Entity-Relationship-Modell, SDM: semantische Datenmodelle \item OODM/C++: objektorientierte Datenmodelle @@ -407,160 +374,57 @@ name: /ind/, // name is like %ind% \begin{description*} \item[Entity] Objekt/Informationen \item[Entity Typ] Gruppierung von Entitys mit gleichen Eigenschaften - \item[Relationship] + \item[Relation/Relationship] Menge aller Einträge \begin{itemize*} \item beschreibt eine Beziehung zwischen Entities \item Menge von Zeilen einer Tabelle \end{itemize*} \item[Attribut] \begin{itemize*} - \item repräsentiert eine Eigenschaft von Entities oder Beziehungen - \item Spalte einer Tabelle + \item repräsentiert eine Eigenschaft von Entities/Beziehungen + \item Spalte/Spaltenüberschrift einer Tabelle \end{itemize*} \item[Tupel] Zeile einer Tabelle - \item[Werte] primitive Datenelemente, die direkt darstellbar sind - \item[Schlüssel] + \item[Werte] primitive Datenelemente; Attributwert + \item[Schlüssel] \begin{itemize*} \item identifizierende Eigenschaft von Entitys - \item minimale Menge von Attributen, deren Werte ein Tupel einer Tabelle eindeutig identifizieren + \item minimale Menge von Attributen, die Tupel eindeutig identifizieren \end{itemize*} - \item[Schlüsselattribute] Teilmenge der gesamten Attribute eines Entity-Typs + \item[Schlüsselattribute] Teilmenge gesamter Attribute von Entity-Typs \begin{itemize*} - \item in jedem Datenbankzustand identifizieren die aktuellen Werte der Schlüsselattribute eindeutig Instanzen des Entity-Typs E - \item bei mehreren möglichen Schlüsselkandidaten auswahl eines Primärschlüssels + \item Auswahl des Primärschlüssels bei mehreren Schlüsselkandidaten + \item Schlüssel durch Unterstreichen gekennzeichnet \end{itemize*} \item[Primärschlüssel] ein beim Datenbankentwurf ausgezeichneter Schlüssel - \item[Fremdschlüssel] Attributmenge, die in einer anderen Relation Schlüssel ist - \item[Beziehungstypen] Beziehungen zwischen Entities zu Beziehungstypen zusammengefasst - \item[Kardinalitäten/Funktionalität] Einschränkung von Beziehungstypen bezüglich der mehrfachen Teilnahme von Entitys an der Beziehung + \item[Fremdschlüssel] Attributmenge, die Schlüssel einer anderen Relation ist + \item[Beziehungstypen] Beziehungen zwischen Entities zu Beziehungstypen + \item[Kardinalitäten/Funktionalität] Einschränkung von Beziehungstypen bezüglich mehrfachen Teilnahme von Entitys an Beziehung \item[Stelligkeit/Grad] Anzahl der an einem Beziehungstyp beteiligten Entity Typen \end{description*} - Beziehungen + Stelligkeit \begin{description*} \item[0,*] legt keine Einschränkung fest (default) - \item[1:1] jedem Entity $e_1$ vom Entity-Typ $E_1$ ist maximal ein Entity $e_2$ aus $E_2$ zugeordnet und umgekehrt - \item[1:N] 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$ + \item[1:1] jedem Entity $e_1$ ist maximal ein Entity $e_2$ zugeordnet und umgekehrt + \item[1:N] jedem Entity $e_1$ sind beliebig viele Entities $E_2$ zugeordnet, aber zu jedem Entity $e_2$ gibt es maximal ein $e_1$ \item[N:1] invers zu 1:N, auf funktionale Beziehung \item[M:N] keine Restriktionen \item[Kardinalitätsangaben] - \begin{itemize*} + \begin{itemize*} \item partielle funktionale Beziehung: $lagertIn(Produkt[0,1],Fach[0,3])$ \item totale funktionale Beziehung: $liefert(Lieferant[0,*],Produkt[1,1])$ - \end{itemize*} + \end{itemize*} \end{description*} - \section{Datenbankentwurf} - \paragraph{Anforderungsanalyse} - \begin{itemize*} - \item informale Beschreibung des Fachproblems - \item Trennen der Informationen über Daten (Datenanalyse) von den Informationen über Funktionen (Funktionsanalyse) - \end{itemize*} - - \paragraph{Konzeptioneller Entwurf} - \begin{itemize*} - \item erste Formale Beschreibung des Fachproblems - \item Sprachmittel: semantisches Datenmodell - \begin{itemize*} - \item Sichtentwurf - \item Sichtanalyse - \item Sichtintegration - \end{itemize*} - \item Ergebnis: konzeptionelles Gesamtschema - \item Integrationskonflikte - \begin{description*} - \item[Namenskonflikte] Homonyme/Synonyme - \item[Typkonflikte] verschiedene Strukturen für das gleiche Element - \item[Wertebereichskonflikte] verschiedene Wertebereiche für ein Element - \item[Bedingungskonflikte] verschiedene Schlüssel für ein Element - \item[Strukturkonflikte] gleicher Sachverhalt durch unterschiedliche Konstrukte - \end{description*} - \end{itemize*} - - \paragraph{Verteilungsentwurf} - \begin{itemize*} - \item sollen Daten auf mehreren Rechnern verteilt vorliegen, muss Art und Weise der verteilten Speicherung festgelegt werden - \item horizontale Verteilung z.B. Kunden 1-1000 und Kunden 10001-20000 - \item vertikale Verteilung z.B. Adresse in DB1, Konto in DB2 - \end{itemize*} - - \paragraph{Logischer Entwurf} - \begin{itemize*} - \item Sprachmittel: Datenmodell des ausgewählten "Realisierungs"DBMS - \begin{enumerate*} - \item (automatische) Transformation des konzeptionellen Schemas - \item Verbesserung des relationalen Schemas anhand von Gütekriterien - \end{enumerate*} - \item Ergebnis: logisches Schema - \end{itemize*} - - \paragraph{Datendefinition} - \begin{itemize*} - \item Umsetzung des logischen Schemas in ein konkretes Schema - \item Sprachmittel: DDL und DML eines DBMS - \begin{itemize*} - \item Datenbankdeklaration in der DDL des DBMS - \item Realisierung der Integritätssicherung - \item Definition der Benutzersichten - \end{itemize*} - \end{itemize*} - - \paragraph{Physischer Entwurf} - \begin{itemize*} - \item Ergänzen des physischen Entwurfs um Zugriffsunterstützung bzgl Effizienzverbesserung - \item Index: - \begin{itemize*} - \item Zugriffspfad: Datenstruktur für zusätzlichen, schlüsselbasierten Zugriff auf Tupel - \item meist als B*-Baum realisiert - \end{itemize*} - \item Sprachmittel: Speicherstruktursprache SSL - \end{itemize*} - - \paragraph{Implementierung \& Wartung} - \begin{itemize*} - \item Wartung - \item weitere Optimierung der physischen Ebene - \item Anpassung an neue Anforderungen und Systemplattformen - \item Portierung auf neue Datenbankmanagementsysteme... - \end{itemize*} - - - \subsection{Kapazitätserhaltende Abbildungen} - Umsetzung des konzeptionellen Schemas - \begin{itemize*} - \item Umsetzung auf logisches Schema - \item Erhaltung der Informationskapazität - \item Kapazitäts\textbf{erhöhende} Abbildung: Abbildung auf R mit genau einem Schlüssel - \item Kapazitäts\textbf{vermindernde} Abbildung: Relationsschema mit einem Schlüssel - \item Kapazitäts\textbf{erhaltende} Abbildung: kapazitätserhaltend mit Schlüssel beider Entity Typen im Relationsschema als neuer Schlüssel - \end{itemize*} - - \subsection{ER-auf-RM Abbildung} - \paragraph{Abbildung von Beziehungstypen} - \begin{itemize*} - \item neues Relationenschema mit allen Attributen des Beziehungstyps, zusätzlich Übernahme aller Primärschlüssel der beteiligten Entity-Typen - \item Festlegung der Schlüssel: - \begin{itemize*} - \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 - \end{itemize*} - \end{itemize*} - \paragraph{Normalformen} \begin{itemize*} \item legen Eigenschaften von Relationenschemata fest - \item verbieten bestimmte Kombinationen von funktionalen Abhängigkeiten in Relationen + \item verbieten bestimmte Kombinationen von funkt. Abhängigkeiten \item sollen Redundanzen und Anomalien vermeiden \end{itemize*} \begin{description*} - \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[Erste Normalform] nur atomare Attribute in den Relationenschemata, d.h. als Attributwerte sind Elemente von Standard-Datentypen wie integer/string erlaubt, aber keine Konstruktoren [array/set] \item[Zweite Normalform] \begin{itemize*} \item Zweite Normalform eliminiert derartige partielle Abhängigkeiten bei Nichtschlüsselattributen @@ -568,8 +432,8 @@ name: /ind/, // name is like %ind% \end{itemize*} \item[Dritte Normalform] \begin{itemize*} - \item eliminiert (zusätzlich) transitive Abhängigkeiten - \item etwa Weingut $\rightarrow$ Anbaugebiet und Anbaugebiet $\rightarrow$ Region in Relation + \item eliminiert auch transitive Abhängigkeiten + \item etwa Weingut $\rightarrow$ Anbaugebiet und Anbaugebiet $\rightarrow$ Region \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*} @@ -583,46 +447,122 @@ name: /ind/, // name is like %ind% \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}$ \end{description*} - \subsection{Transformationseigenschaften} + \section{Datenbankentwurf} + \paragraph{Anforderungsanalyse} \begin{itemize*} - \item Abhänggikeitstreue (Kennung T1) + \item informale Beschreibung des Fachproblems + \item Trennen der Informationen über Daten (Datenanalyse) von den Informationen über Funktionen (Funktionsanalyse) + \end{itemize*} + + \paragraph{Konzeptioneller Entwurf} + \begin{itemize*} + \item formale Beschreibung des Fachproblems \begin{itemize*} - \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 Sichtentwurf + \item Sichtanalyse + \item Sichtintegration \end{itemize*} - \item Verbundtreue (Kennung T2) + \item Ergebnis: konzeptionelles Gesamtschema + \item Integrationskonflikte + \begin{description*} + \item[Namenskonflikte] Homonyme/Synonyme + \item[Typkonflikte] verschiedene Strukturen für das gleiche Element + \item[Wertebereichskonflikte] verschiedene Wertebereiche für Element + \item[Bedingungskonflikte] verschiedene Schlüssel für ein Element + \item[Strukturkonflikte] gleicher Sachverhalt durch unterschiedliche Konstrukte + \end{description*} + \end{itemize*} + + \paragraph{Verteilungsentwurf} + \begin{itemize*} + \item sollen Daten auf mehreren Rechnern verteilt vorliegen, muss Art und Weise der verteilten Speicherung festgelegt werden + \item horizontale Verteilung z.B. Kunden 1-100 und Kunden 101-200 + \item vertikale Verteilung z.B. Adresse in DB1, Konto in DB2 + \end{itemize*} + + \paragraph{Logischer Entwurf} + \begin{itemize*} + \item Datenmodell des ausgewählten DBMS + \item Transformation des konzeptionellen Schemas + \item Verbesserung des relationalen Schemas anhand von Gütekriterien + \end{itemize*} + + \paragraph{Datendefinition} + \begin{itemize*} + \item Umsetzung des logischen Schemas in ein konkretes Schema \begin{itemize*} - \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 - \end{itemize*} - \item Mehrwertige Abhängigkeit (kurz: MVD) - \begin{itemize*} - \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 + \item Datenbankdeklaration in der DDL des DBMS + \item Realisierung der Integritätssicherung + \item Definition der Benutzersichten \end{itemize*} \end{itemize*} + \paragraph{Physischer Entwurf} + \begin{itemize*} + \item Ergänzen des physischen Entwurfs um Zugriffsunterstützung + \begin{itemize*} + \item Zugriffspfad: Datenstruktur für zusätzlichen schlüsselbasierten Zugriff auf Tupel + \item meist als B*-Baum realisiert + \end{itemize*} + \item Sprachmittel: Speicherstruktursprache SSL + \end{itemize*} - \section{Relationale Theorie} - Ableitungsregel: + \paragraph{Implementierung \& Wartung} + \begin{itemize*} + \item Wartung; weitere Optimierung der physischen Ebene + \item Anpassung an neue Anforderungen und Systemplattformen + \item Portierung auf neue Datenbankmanagementsysteme... + \end{itemize*} + + \subsection{Kapazitätsändernde Abbildungen} + \begin{itemize*} + \item Kap.\textbf{erhöhend}: Abbildung auf R mit genau einem Schlüssel + \item Kap.\textbf{vermindernd}: Relationsschema mit einem Schlüssel + \item Kap.\textbf{erhaltend}: mit Schlüssel beider Entity Typen im Relationsschema als neuer Schlüssel + \end{itemize*} + + \subsection{ER-auf-RM Abbildung} + \begin{itemize*} + \item neues Relationenschema mit allen Attributen des Beziehungstyps, zusätzlich Übernahme aller Primärschlüssel der Entity-Typen + \item Festlegung der Schlüssel: + \begin{itemize*} + \item m:n-Beziehung: beide Primärschlüssel zusammen werden Schlüssel + \item 1:n-Beziehung: Primärschlüssel der n-Seite (Seite ohne Pfeilspitze) wird Schlüssel + \item 1:1-Beziehung: beide Primärschlüssel werden je ein Schlüssel, der Primärschlüssel wird dann aus diesen Schlüsseln gewählt + \end{itemize*} + \item optionale Beziehungen $[0,1]$ o. $[0,n]$ werden nicht verschmolzen + \item bei Kardinalitäten $[1,1]$ oder $[1,n]$ Verschmelzung möglich + \begin{itemize*} + \item $1:n$: Entity-Relationenschema der n-Seite integrieren + \item $1:1$: beide Entity-Relationenschemata integrieren + \end{itemize*} + \end{itemize*} + + \subsection{Transformationseigenschaften} + \begin{itemize*} + \item Abhänggikeitstreue (T1) + \begin{itemize*} + \item Menge der Abhängigkeiten äquivalent zu der Menge der Schlüsselbedingungen im resultierenden Datenbankschema + \item S charakterisiert vollständig F genau dann, wenn $F\equiv \{K\rightarrow R | (R,\bf{K})\in S, K\in\bf{K}\}$ + \end{itemize*} + \item Verbundtreue (T2) + \begin{itemize*} + \item Originalrelationen können durch den Verbund der Basisrelationen wiedergewonnen werden + \item nicht verbundtreu $F = \{A \rightarrow B, C \rightarrow B\}$ + \item verbundtreu $F" = \{A \rightarrow B, B \rightarrow C\}$ + \end{itemize*} + \item Mehrwertige Abhängigkeit (MVD) + \begin{itemize*} + \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 Beseitigung von Redundanzen: keine zwei MVDs zwischen Attributen + \item Elimination der rechten Seite einer der beiden mehrwertigen Abhängigkeiten, + \item linke Seite mit dieser rechten Seite in neue Relation kopiert + \end{itemize*} + \item Verbundabhängigkeit (JD): R kann ohne Informationsverlust in $R_1,..., R_p$ aufgetrennt werden: $\bowtie [R_1,..., R_p]$ + \item Inklusionsabhängigkeit (IND): auf der rechten Seite einer Fremdschlüsselabhängigkeit nicht unbedingt der Primärschlüssel + \end{itemize*} + + \paragraph{Ableitungsregel} \begin{itemize*} \item F1: Reflexivität $X\supseteq Y \Rightarrow X\rightarrow Y$ \item F2: Augumentation $\{X\rightarrow Y\}\Rightarrow XZ\rightarrow YZ, \text{ sowie } XZ\rightarrow Y$ @@ -632,36 +572,28 @@ name: /ind/, // name is like %ind% \item F6: Pseudotransitivität $\{X\rightarrow Y, WY\rightarrow Z\}\Rightarrow WX\rightarrow Z$ \end{itemize*} - F1-F3 bekannt als Armstrong-Axiome (sound, complete) + F1-F3 bekannt als Armstrong-Axiome \begin{itemize*} \item gültig (sound): Regeln leiten keine FDs ab, die logisch nicht impliziert \item vollständig (complete): alle implizierten FDs werden abgeleitet - \item unabhängig (independent) oder auch bzgl. $\subseteq$ + \item unabhängig (independent) oder auch bzgl. $\subseteq$ \item minimal: keine Regel kann weggelassen werden \end{itemize*} - Alternative Regelmenge + B-Axiome oder RAP-Regeln \begin{itemize*} - \item B-Axiome oder RAP-Regeln - \begin{itemize*} - \item R Reflexivität $\{\}\Rightarrow X\rightarrow X$ - \item A Akkumulation $\{X\rightarrow YZ, Z\rightarrow AW\}\Rightarrow X\rightarrow YZA$ - \item P Projektivität $\{X\rightarrow YZ\}\Rightarrow X\rightarrow Y$ - \end{itemize*} - \item Regelmenge ist vollständig, da Armstrong-Axiome daraus abgeleitet werden können + \item R Reflexivität $\{\}\Rightarrow X\rightarrow X$ + \item A Akkumulation $\{X\rightarrow YZ, Z\rightarrow AW\}\Rightarrow X\rightarrow YZA$ + \item P Projektivität $\{X\rightarrow YZ\}\Rightarrow X\rightarrow Y$ \end{itemize*} \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^+$ - \paragraph*{Reduktionsoperationen} Entfernen überflüssiger Attribute auf linker bzw. rechter Seite von FDs. + \paragraph{Reduktionsoperationen} Entfernen überflüssiger Attribute auf linker bzw. rechter Seite von FDs. - Unwesentliche Attribute: A heißt unwesentlich in $X\rightarrow Y$ bzgl. F, wenn + \paragraph{Unwesentliche Attribute} A heißt unwesentlich in $X\rightarrow Y$ bzgl. F, wenn \begin{itemize*} - \item $X=AZ,Z\not= X \Rightarrow (F-\{X\rightarrow Y\})\cup \{Z\rightarrow Y\} \equiv F$ oder - \item $Y=AW, W\not=Y\Rightarrow (F-\{X\rightarrow Y\})\cup \{X\rightarrow W\} \equiv F$ - \end{itemize*} - \begin{itemize*} - \item A kann also aus der FD $X\rightarrow Y$ entfernt werden, ohne dass sich die Hülle von F ändert + \item A kann aus der FD $X\rightarrow Y$ entfernt werden, ohne dass sich die Hülle von F ändert \item FD $X\rightarrow Y$ heißt linksreduziert, wenn kein Attribut in X unwesentlich ist \item FD $X\rightarrow Y$ heißt rechtsreduziert, wenn kein Attribut in Y unwesentlich ist \end{itemize*} @@ -670,1277 +602,280 @@ name: /ind/, // name is like %ind% \paragraph{Äquivalenzklassen} FDs mit äquivalenten linken Seiten werden zu einer Äquivalenzklasse zusammengefasst - Zweite Normalform - \begin{itemize*} - \item Y hängt partiell von X bzgl. F ab, wenn die FD $X\rightarrow Y$ nicht linksreduziert ist - \item Y hängt voll von X ab, wenn die FD $X\rightarrow Y$ linksreduziert ist - \item R ist in 2NF, wenn R in 1NF ist und jedes Nicht-Primattribut von R voll von jedem Schlüssel von R abhäng - \end{itemize*} - \subsection{Entwurfsverfahren} - Ziele: \begin{itemize*} - \item Universum $U$ und FD-Menge F gegeben - \item lokal erweitertes Datenbankschema $S=\{(R_1, K_1),...,(R_p, K_p)\}$ berechnen mit - \begin{itemize*} - \item T1: S charakterisiert vollständig F - \item S1: S ist in 3NF bezüglich F - \item T2: Dekomosition von $U$ in $R_1,...,R_p$ ist verbundtreu bezüglich F - \item S2: Minimalität, d.h. $\not\exists S":S"$ erfüllt T1,S1,T2 und $|S"|<|S|$ - \end{itemize*} + \item T1: S charakterisiert vollständig F + \item S1: S ist in 3NF bezüglich F + \item T2: Dekomosition von $U$ in $R_1,...,R_p$ ist verbundtreu bezüglich F + \item S2: Minimalität, d.h. $\not\exists S":S"$ erfüllt T1,S1,T2 und $|S"|<|S|$ \end{itemize*} - \section{Die relationale Anfragesprache SQL} - \paragraph{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 | + \section{Algebra \& Kalkül} + \begin{description*} + \item[Anfrage] Folge von Operationen, die aus Basisrelationen eine Ergebnisrelation berechnet + \item[Sicht] Folge von Operationen, die unter Sichtnamen langfristig abgespeichert wird und unter diesem Namen wieder aufgerufen werden kann; ergibt eine Sichtrelation + \item[Snapshot] Ergebnisrelation einer Anfrage, die unter Snapshot-Namen abgelegt wird, aber nie ein zweites Mal berechnet wird + \end{description*} + \paragraph{Kriterien für Anfragesprachen} + \begin{description*} + \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?“ + \item[Mengenorientiertheit] jede Operation soll auf Mengen von Daten gleichzeitig arbeiten + \item[Abgeschlossenheit] Ergebnis ist wieder Relation und kann als Eingabe für 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 (Komplexität max $\leq O(n^2)$) + \item[Sicherheit] keine Anfrage, die syntaktisch korrekt ist, darf in eine Endlosschleife geraten oder ein unendliches Ergebnis liefern + \item[Eingeschränktheit] Anfragesprache darf keine komplette Programmiersprache sein + \item[Vollständigkeit] Sprache muss mindestens die Anfragen einer Standardsprache ausdrücken können + \begin{description*} + \item[Minimale Relationenalgebra] $\Omega = \pi,\sigma,\bowtie,\beta,\cup, -$ + \item[unabhängig] kein Operator kann weggelassen werden + \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{description*} + \end{description*} - - - \paragraph{Quantoren und Mengenvergleiche} + \paragraph{Verbundvarianten} \begin{itemize*} - \item Quantoren: all, any, some und exists - \item Notation $\Theta$ { all | any | some } - \end{itemize*} - - \section{Grundlagen von Anfragen: Algebra \& Kalkül} - - Begriffe - \begin{itemize*} - \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) - \end{itemize*} - - Kriterien für Anfragesprachen - \begin{itemize*} - \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 - \end{itemize*} - - Relationenalgebra - \begin{itemize*} - \item Spalten ausblenden: Projektion $\pi$ - \item Zeilen heraussuchen: Selektion $\sigma$ - \item Tabellen verknüpfen: Verbund (Join) $\bowtie$ - \item Tabellen vereinigen: Vereinigung $\cup$ - \item Tabellen voneinander abziehen: Differenz $-$ - \item Spalten umbenennen: Umbenennung $\beta$ (wichtig für $\rtimes$ und $\cup$, $-$) - \end{itemize*} - - Projektion - \begin{itemize*} - \item Syntax $\pi_{Attributmenge}(Relation)$ - \item $\pi$ entfernt Duplikate (Mengensemantik) - \end{itemize*} - - Selektion - \begin{itemize*} - \item Syntax $\sigma_{Bedingung} (Relation)$ - \item Semantik (für $A\in R$) $\sigma_{A=a}(r) := \{t \in r | t(A) = a\}$ - \item Konstantenselektion $Attribut \Theta Konstante$ - \begin{itemize*} - \item boolesches Prädikat $\Theta$ ist = oder$\not=$, bei linear geordneten Wertebereichen auch $\leq, <, \geq$ oder $>$ - \end{itemize*} - \item Attributselektion $Attribut_1 \Theta Attribut_2$ - \item logische Verknüpfung mehrerer Konstanten- oder Attribut-Selektionen mit $\vee, \wedge$ oder $\neg$ - \item Eigenschaften - \begin{itemize*} - \item Kommutativität $\sigma_{A=a}(\sigma_{B=b} (r)) = \sigma_{B=b} (\sigma_{A=a} (r))$ - \item falls $A\in X, X \subseteq R: \pi_X(\sigma_{A=a} (r)) = \sigma_{A=a} (\pi_{X} (r))$ - \item Distributivität bzgl. $\cup, \cap, - , \sigma_{A=a} (r \cup s) = \sigma_{A=a} (r) \cup \sigma_{A=a} (s)$ - \end{itemize*} - \item Verbund - \begin{itemize*} - \item Syntax des (natürlichen) Verbundes (engl.: natural join) $Relation_1 \bowtie Relation_2$ - \item Semantik $r_1 \bowtie r_2 := {t | t(R_1\cup R_2 ) \vee [\forall i \in \{1, 2\}\exists t_i \in r_i : t_i = t(R_i )]}$ - \item Verbund verknüpft Tabellen über gleichbenannten Spalten bei gleichen Attributwerten - \item Schema für $r(R) \bowtie r(S)$ ist Vereinigung der Attributmengen $R = R \cup S$ - \item aus $R_1 \cap R_2 = \{\}$ folgt $r_1\bowtie r_2 = r_1 \times r_2$ - \item Kommutativität: $r_1 \rtimes r_2 = r_2 \rtimes r_1$ - \item Assoziativität: $(r_1 \rtimes r_2 ) \rtimes \ltimes r_3 = r_1 \ltimes (r_2 \rtimes r_3 )$ - \item daher erlaubt: $\bowtie_{i=1}^p r_i$ - \end{itemize*} - \item Umbenennung - \begin{itemize*} - \item Syntax $\beta_{neu\leftarrow alt} (Relation)$ - \item Semantik $\beta_{B\leftarrow A} (r) := \{t" | \exists t \in r : t" (R-A) = t(R-A) \vee t"(B) = t(A)\}$ - \item ändert Attributnamen von alt in neu - \end{itemize*} - \item Berechnung des Kreuzproduktes - \begin{itemize*} - \item natürlicher Verbund entartet zum Kreuzprodukt, wenn keine gemeinsamen Attribute existieren - \item Erzwingen durch Umbenennung - \item Kreuzprodukt + Selektion simuliert natürlichen Verbund - \end{itemize*} - \end{itemize*} - - Unabhängigkeit und Vollständigkeit - \begin{itemize*} - \item Minimale Relationenalgebra: $\Omega$ = $\pi$, $\sigma$, $\rtimes$, $\beta$, $\cup$ und - - \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 - \begin{itemize*} - \item $r(R) \bowtie_{C=D} r(S)$ - \end{itemize*} - \item Theta-Verbund (engl. $\Theta$-join): beliebige Verbundbedingung - \begin{itemize*} - \item $r(R) \bowtie_{C>D} r(S)$ - \end{itemize*} - \item Semi-Verbund: nur Attribute eines Operanden erscheinen im Ergebnis - \begin{itemize*} - \item $r(L) \bowtie r(R) = \pi_L (r(L) \bowtie r(R))$ - \end{itemize*} + \item Gleichverbund: Gleichheitsbedingung über explizit angegebene und evtl. verschiedene Attribute $r(R) \bowtie_{C=D} r(S)$ + \item Theta-Verbund ($\Theta$-join): beliebige Verbundbedingung $r(R) \bowtie_{C>D} r(S)$ + \item Semi-Verbund: nur Attribute eines Operanden erscheinen im Ergebnis $r(L) \bowtie r(R) = \pi_L (r(L) \bowtie r(R))$ \item äußere Verbunde (engl. outer join) \begin{itemize*} - \item voller äußerer Verbund übernimmt alle Tupel beider Operanden - \item linker äußerer Verbund übernimmt alle Tupel des linken Operanden - \item rechter äußerer Verbund übernimmt alle Tupel des rechten Operanden + \item voller ä.V. übernimmt alle Tupel beider Operanden + \item linker ä.V. übernimmt alle Tupel des linken Operanden + \item rechter ä.V. übernimmt alle Tupel des rechten Operanden \end{itemize*} \end{itemize*} - Problem: Quantoren - \begin{itemize*} - \item Allquantor in Relationenalgebra ausdrücken, obwohl in Selektionsbedingungen nicht erlaubt - \item Division (kann aus $\Omega$ hergeleitet werden) - \end{itemize*} - - > 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 $Y$ - \begin{itemize*} - \item 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 - \item Anwendung der Funktionen $f_i (x_i)$ auf die Teilmenge derjenigen Tupel von $r(R)$ die gleiche Attributwerte für die Attribute A haben - \end{itemize*} - \subsection{Anfragekalküle} - \begin{itemize*} - \item Kalkül: eine formale logische Sprache zur Formulierung von Aussagen - \item Ziel: Einsatz eines derartigen Kalküls zur Formulierung von Datenbank-Anfragen - \item Logikbasierter Ansatz: - \begin{itemize*} - \item Datenbankinhalte entsprechen Belegungen von Prädikaten einer Logik - \item Anfragen abgeleiteten Prädikaten - \end{itemize*} - \end{itemize*} - - Ein allgemeiner Kalkül - \begin{itemize*} - \item Motivation: mathematische Notation $\{x^2 | x \in N \vee x^3 > 0 \vee x^3 < 1000\}$ - \item Anfrage hat die Form $\{f(\bar{x}) | p(\bar{x})\}$ - \begin{itemize*} - \item x bezeichnet Menge von freien Variablen $x = \{x_1:D_1,...,x_n:D_n\}$ - \item Funktion f bezeichnet Ergebnisfunktion über $\bar{x}$ - \item p Selektionsprädikat über freien Variablen $\bar{x}$ - \end{itemize*} - \item Ergebnisbestimmung einer Anfrage + \begin{description*} + \item[Kalkül] eine formale logische Sprache zur Formulierung von Aussagen + \item[Ziel] Kalkül zur Formulierung von Datenbank-Anfragen + \item[allgemeines Kalkül] \begin{itemize*} + \item Anfrage hat die Form $\{f(\bar{x}) | p(\bar{x})\}$ + \begin{itemize*} + \item x bezeichnet Menge von freien Variablen + \item Funktion f bezeichnet Ergebnisfunktion über $\bar{x}$ + \item p Selektionsprädikat über freien Variablen $\bar{x}$ + \end{itemize*} \item Bestimme aller Belegungen der freien Variablen in x, für die das Prädikat p wahr wird. - \item Wende Funktion f auf die durch diese Belegungen gegebenen Werte an. \end{itemize*} - \item Unter welchen Umständen liefern Kalkülanfragen endliche Ergebnisse? $\rightarrow$ Sicherheit von Anfragen + \item[Relationale Kalküle] + \begin{itemize*} + \item Bereichskalkül: Variablen nehmen Werte elementarer Datentypen (Bereiche) an + \item 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. + \item Atomare Formeln: $\{x_1,..., x_n \| \phi(x_1,..., x_n )\}$ + \end{itemize*} + \item[Basiskalkül] + \begin{itemize*} + \item Einschränkung des Bereichskalküls: nur Konstanten, keine Funktionen + \item Tupelkalkül: Variablen variieren über Tupelwerte + \end{itemize*} + \item[Semantisch sichere Anfragen] Anfragen, die für jeden Datenbankzustand $\sigma(R)$ ein endliches Ergebnis liefern + \item[Syntaktisch sichere Anfragen] Anfragen, die syntaktischen Einschränkungen unterliegen, um die semantische Sicherheit zu erzwingen + \end{description*} + + \paragraph{Transaktion, Integrität \& Trigger} + \begin{description*} + \item[Typintegrität] Angabe von Wertebereichen zu Attributen; Erlauben/Verbieten von Nullwerten + \item[Schlüsselintegrität] Angabe eines Schlüssels für eine Relation + \item[Referentielle Integrität] die Angabe von Fremdschlüsseln + \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{description*} + + \paragraph{Transaktionen fordern ACID Eigenschaften} + \begin{description*} + \item[Atomicity] Transaktion wird entweder ganz oder gar nicht ausgeführt + \item[Consistency] Datenbank ist vor Beginn und nach Beendigung einer Transaktion jeweils in einem konsistenten Zustand + \item[Isolation] Nutzer, der mit einer Datenbank arbeitet, sollte den Eindruck haben, dass er mit dieser Datenbank alleine arbeitet + \item[Durability] nach erfolgreichem Abschluss einer Transaktion muss das Ergebnis dieser Transaktion „dauerhaft“ in der Datenbank gespeichert werden + \end{description*} + + Kommandos einer Transaktionssprache + \begin{itemize*} + \item Beginn einer Transaktion: Begin-of-Transaction-Kommando BOT + \item commit: die Transaktion soll erfolgreich beendet werden + \item abort: die Transaktion soll abgebrochen werden \end{itemize*} - Relationale Kalküle + Probleme im Mehrbenutzerbetrieb + \begin{description*} + \item[Nonrepeatable Read] gleiche Leseanweisung führt zu nicht wiederholbaren Ergebnissen + \item[Dirty read] rechnen mit Wert einer anderen Transaktion die abgebrochen wird + \item[Phantom-Problem] liest Wert anderer Transaktion ohne zu erkennen, dass andere Transaktion noch nicht abgeschlossen + \item[Lost Update] updates gehen verloren, wenn gleiche Variablen gleicheitig beschrieben werden (oder kurz nacheinander) + \item[Deadlock] ein oder mehrere Transaktionen warten, einen LOCK auf Datenbankobjekte abzusetzen und behindern sich gegenseitig + \item[Startvation] Warteschlange für gesperrte Objekte unfair abgearbeitet. Transaktion wartet endlos + \end{description*} + + Isolationsebenen + \begin{description*} + \item[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[read committed] nur Lesen endgültig geschriebener Werte, aber nonrepeatable read möglich + \item[repeatable read] kein nonrepeatable read, aber Phantomproblem kann auftreten + \item[serializable] garantierte Serialisierbarkeit + \end{description*} + + \paragraph{Integritätsbedingungen in SQL} + \begin{description*} + \item[not null] Nullwerte verboten + \item[default] Angabe von Default-Werten + \item[check] (search-condition) festlegung lokaler Integritätsbedingungen innerhalb der zu definierenden Wertebereiche, Attribute und Relationenschemata + \item[primary key] Angabe eines Primärschlüssel + \item[foreign key] Angabe der referentiellen Integrität + \item[create domain] Festlegung eines benutzerdefinierten Wertebereichs + \end{description*} + + \paragraph{Erhaltung der referentiellen Integrität} + \begin{description*} + \item[on update $\mid$ delete] Angabe eines Auslöseereignisses, das die Überprüfung der Bedingung anstößt + \item[cascade $\mid$ set null $\mid$ set default $\mid$ no action] Behandlung einiger Integritätsverletzungen pflanzt sich über mehrere Stufen fort + \item[deferred $\mid$ 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 + \end{description*} + + \section{Sichten und Zugriffskontrolle} \begin{itemize*} - \item Bereichskalkül: Variablen nehmen Werte elementarer Datentypen (Bereiche) an + \item Sichten sind externe DB-Schemata folgend der 3-Ebenen-Schemaarchitektur \begin{itemize*} - \item Terme: - \begin{itemize*} - \item Konstanten, etwa 42 oder "MZ-4" - \item Variablen zu Datentypen, etwa x Datentypangabe erfolgt in der Regel implizit und wird nicht explizit deklariert! - \item Funktionsanwendung $f(t_1,...,t_n )$: Funktion f, Terme $t_i$ , etwa $plus(12, x)$ bzw. in Infixnotation $12 + x$ - \end{itemize*} - \item Atomare Formeln: - \begin{itemize*} - \item Prädikatanwendung $\Theta(t_1,...,t_n ), \Theta\in\{<, >, \leq, \geq, \not = , =,...\}$ - \begin{itemize*} - \item Datentypprädikat, Terme $t_i$ - \item Zweistellige Prädikate wie üblich in Infix-Notation. - \item Beispiele: $x = y$, $42 > x$ oder $3 + 7 = 11$. - \end{itemize*} - \item Prädikatanwendungen für Datenbankprädikate, notiert als $R(t_1,...,t_n)$ für einen Relationennamen R - \begin{itemize*} - \item Voraussetzung: n muss die Stelligkeit der Relation R sein und alle $t_i$ müssen vom passenden Typ sein - \item Beispiel: "ERZEUGER(x, ’Hessen’, z)" - \end{itemize*} - \item Formeln wie üblich $\vee, \wedge, \neg, \forall, \exists$ - \end{itemize*} - \item Anfragen: $\{x_1,..., x_n | \phi(x_1,..., x_n )\}$ - \begin{itemize*} - \item $\phi$ ist Formel über den in der Ergebnisliste aufgeführten Variablen $x_1$ bis $x_n$ - \item Ergebnis ist eine Menge von Tupeln - \item Tupelkonstruktion erfolgt implizit aus den Werten der Variablen in der Ergebnisliste - \end{itemize*} - \item Basiskalkül - \begin{itemize*} - \item Einschränkung des Bereichskalküls: - \begin{itemize*} - \item Wertebereich: ganze Zahlen - \item Datentypprädikate werden wie bei der Relationenalgebra auf Gleichheit und elementare Vergleichsoperatoren eingeschränkt - \item Funktionsanwendungen sind nicht erlaubt; nur Konstanten dürfen neben Bereichsvariablen als Terme verwendet werden - \end{itemize*} - \item Tupelkalkül: Variablen variieren über Tupelwerte (entsprechend den Zeilen einer Relation) - \begin{itemize*} - \item Grundlage von SFW-Anfragen in SQL - \item Variablen sind tupelwertig - \item Beispiel: $\{w | w\in WEINE \vee w.Farbe = "Rot"\}$ - \end{itemize*} - \end{itemize*} + \item Sichtdefinition + \item Relationenschema (implizit oder explizit) + \item Berechnungsvorschrift für virtuelle Relation, etwa SQL-Anfrage \end{itemize*} - - Motivation: Die Sprache QBE + \item Vorteile \begin{itemize*} - \item „Query by Example“ - \item Anfragen in QBE: Einträge in Tabellengerüsten - \item Intuition: Beispieleinträge in Tabellen - \item Vorläufer verschiedener tabellenbasierter Anfrageschnittstellen kommerzieller Systeme - \item basiert auf logischem Kalkül mit Bereichsvariablen + \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 \end{itemize*} + \end{itemize*} - > Semantisch sichere Anfragen: Anfragen, die für jeden Datenbankzustand $\sigma(R)$ ein endliches Ergebnis liefern + \subsection{Änderungen auf Sichten} + Kriterien + \begin{description*} + \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[Datenschutz] Wird die Sicht aus Datenschutzgründen eingeführt, darf der bewusst ausgeblendete Teil der Basisdatenbank von Änderungen der Sicht nicht betroffen werden + \end{description*} - > Semantische Sicherheit Semantische Sicherheit ist im Allgemeinen nicht entscheidbar! + Klassifikation der Problembereiche + \begin{itemize*} + \item Verletzung der Schemadefinition + \item Datenschutz: Seiteneffekte auf nicht-sichtbaren Teil der Datenbank vermeiden + \item nicht immer eindeutige Transformation: Auswahlproblem + \item Aggregierungssichten: 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 + \end{itemize*} - > 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. + Einschränkungen für Sichtänderungen + \begin{itemize*} + \item änderbar nur Selektions- und Projektionssichten + \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 + \item keine Unteranfragen mit „Selbstbezug“ im where-Teil erlaubt + \item group by und having verboten + \end{itemize*} + + Statistische Datenbanken + \begin{itemize*} + \item Einzeleinträge unterliegen Datenschutz, aber statistische Informationen allen Benutzern zugänglich \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 + \item keine Anfragen, die weniger als n Tupel selektieren + \item statistische Anfragen nicht erlauben, die paarweise einen Durchschnitt von mehr als m vorgegebenen Tupeln betreffen + \item Data Swapping: Vertauschen von Attributwerten einzelner Tupel + \item Generalisierung: Attributwerte durch allgemeinere Werte ersetzen, die einer Generalisierungshierarchie entnommen sind (Alter 30-40, Weglassen von Stellen PLZ) + \item Löschen von Tupeln, welche die k-Anonymität verletzen und damit identifizierbar sind \end{itemize*} + \item k-Anonymität: ein bestimmter Sachverhalt kann nicht zwischen einer vorgegebenen Anzahl k von Tupeln unterschieden werden + \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“ - + \subsection{Datenmodelle für NoSQL} + \begin{description*} + \item[KV-Stores] binäre Relationen, bestehend aus einem Zugriffsschlüssel (dem Key) und den Nutzdaten (dem Value) \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*} + \item binäre Daten ohne Einschränkung, + \item Dateien oder Dokumente, $\rightarrow$ Document Databases + \item oder schwachstrukturierte Tupel $\rightarrow$ Wide Column Store \end{itemize*} - - \subsection{Transaktionsbegriff} - Beispiel: + \item[Wide Column] KV-Store mit schwachstrukturiertem Tupel als Value = Liste von Attributname-Attributwert-Paaren \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) - \end{itemize*} - \end{itemize*} - - 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{serializable}: garantierte Serialisierbarkeit - \end{itemize*} - - - \subsection{Integritätsbedingungen in SQL} - \begin{itemize*} - \item \textbf{not null}: Nullwerte verboten - \item \textbf{default}: Angabe von Default-Werten - \item \textbf{check} ( search-condition ): - \begin{itemize*} - \item Attributspezifische Bedingung (in der Regel Ein-Tupel-Integritätsbedingung) - \item Festlegung weitere lokale Integritätsbedingungen innerhalb der zu definierenden Wertebereiche, Attribute und Relationenschemata - \item Beispiel: - ```sql - create table WEINE ( - WeinID int primary key, - Name varchar(20) not null, - Jahr int check(Jahr between 1980 and 2010), - ... - ) - ``` - \end{itemize*} - \item \textbf{primary key}: Angabe eines Primärschlüssel - \item \textbf{foreign key} ( Attribut(e) ) references Tabelle( Attribut(e) ): Angabe der referentiellen Integrität - \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 Beispiel: "... foreign key (Weingut) references ERZEUGER (Weingut) on delete cascade" - \end{itemize*} - \end{itemize*} - - Die assertion-Klausel - \begin{itemize*} - \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) - "drop table relationenname [ restrict | cascade ]" - \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 - \end{itemize*} - \item Probleme - \begin{itemize*} - \item automatische Anfragetransformation - \item Durchführung von Änderungen auf Sichten - \end{itemize*} - \item Definition von Sichten in SQL - ```sql - create view SichtName [ SchemaDeklaration ] - as SQLAnfrage - [ with check option ] - ``` - \item 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" - ``` - \end{itemize*} - - \subsection{Änderungen auf Sichten} - Kriterien für Änderungen auf Sichten - \begin{itemize*} - \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 - \end{itemize*} - - Projektionssicht: $WNW:=\pi_{WeinID, Name, Weingut}(WEINE)$ - \begin{itemize*} - \item in sql mit create view Anweisung - "create view WNW as select WeinID, Name, Weingut from WEINE" - \item Änderungsanweisung für die Sicht WNW: - "insert into WNW values (3333, "Dornfelder", "Müller")" - \item Problem der Konsistenzerhaltung falls Farbe oder Jahrgang als not null deklariert! - \end{itemize*} - - 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 - ``` - \begin{itemize*} - \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 datenschutzverletzende Sichtänderungen: Benutzerkontrolle (with check option) - \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 - ```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 - \begin{itemize*} - \item select: Sichtattribute evtl. umbenennen bzw. durch Berechnungsterm ersetzen - \item from: Namen der Originalrelationen - \item konjunktive Verknüpfung der where-Klauseln von Sichtdefinition und Anfrage (evtl. Umbenennungen) - \item Vorsicht bei Aggregationssichten! - \begin{itemize*} - \item having versus where - \item keine geschachtelten Aggregationen in SQL - \end{itemize*} - \end{itemize*} - - \subsection{Rechtevergabe} - \begin{itemize*} - \item Zugriffsrechte (AutorisierungsID, DB-Ausschnitt, Operation) - \item AutorisierungsID ist interne Kennung eines „Datenbankbenutzers“ - \item Datenbank-Ausschnitte: Relationen und Sichten - \item DB-Operationen: Lesen, Einfügen, Ändern, Löschen - \end{itemize*} - - ```sql - grant Rechte - on Tabelle - to BenutzerListe - [with grant option] - ``` - \begin{itemize*} - \item In Rechte-Liste: all bzw. Langform all privileges oder Liste aus select, insert, update, delete - \item Hinter on: Relationen- oder Sichtname - \item Hinter to: Autorisierungsidentifikatoren (auch public, group) - \item spezielles Recht: Recht auf die Weitergabe von Rechten (with grant option) - \end{itemize*} - - 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 ] - ``` - \begin{itemize*} - \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\} \rightarrow 30-40$ - \item Weglassen von Stellen bei Postleitzahlen: $\{ 39106, 39114 \}\rightarrow 39***$ - \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 - \end{itemize*} - - - \subsection{Datenmodelle für NoSQL} - Datenmodelle für NoSQL - \begin{itemize*} - \item KV-Stores - \item Wide Column Stores - \item Dokumenten-orientierte Datenhaltung - \item Graph-Speicher - \item ... - \end{itemize*} - - Anfragesprachen für NoSQL - \begin{itemize*} - \item unterschiedliche Ansätze: - \item einfache funktionale API - \item Programmiermodell für parallele Funktionen - \item angelehnt an SQL-Syntax - \item ... - \end{itemize*} - - \subsection{KV-Stores und Wide Column} - Datenmodell: Key-Value-Stores - \begin{itemize*} - \item Key-Value-Store: binäre Relationen, bestehend aus - \begin{itemize*} - \item einem Zugriffsschlüssel (dem Key) und - \item den Nutzdaten (dem Value) - \end{itemize*} - \item Nutzdaten - \begin{itemize*} - \item binäre Daten ohne Einschränkung, - \item Dateien oder Dokumente, $\rightarrow$ Document Databases - \item oder schwachstrukturierte Tupel $\rightarrow$ Wide Column Store - \end{itemize*} - \item Anfragen an KV-Stores - \begin{itemize*} - \item einfache API - ```sql - store.put(key, value) - value = store.get(key) - store.delete(key) - ``` - \item aufgesetzte höherer Sprache angelehnt an SQL - \item Map-Reduce: Framework zur Programmierung paralleler Datenaggregation auf KV-Stores - \end{itemize*} - \item Beispielsysteme für KV-Stores - \begin{itemize*} - \item Amazon DynamoDB - \item Riak - \end{itemize*} - \end{itemize*} - - Datenmodell: Wide Column - \begin{itemize*} - \item Basisidee: KV-Store mit schwachstrukturiertem Tupel als Value - \item Value = Liste von Attributname-Attributwert-Paaren - \begin{itemize*} - \item schwache Typisierung für Attributwerte (auch Wiederholgruppen) - \end{itemize*} + \item schwache Typisierung für Attributwerte (auch Wiederholgruppen) \item nicht alle Einträge haben die selben Attributnamen - \begin{itemize*} - \item offene Tupel - \item Hinzufügen eines neuen Attributs unproblematisch - \item Nullwerte aus SQL ersetzt durch fehlende Einträge - \end{itemize*} - \item Beispiel in DynamoDB - \item Anfragen bei Wide Column - \begin{itemize*} - \item CRUD: Create, Read, Update und Delete - \item in DynamoDB: PutItem, GetItem, Scan - \item Aufruf über HTTP oder aus Programmiersprachen heraus - \end{itemize*} + \item Hinzufügen eines neuen Attributs unproblematisch + \item Nullwerte aus SQL ersetzt durch fehlende Einträge \end{itemize*} - - - \subsection{Document Stores} - Datenmodell: dokumentenorientierte Speicherung + \item[Document Stores] KV-Store mit (hierarchisch) strukturiertem Dokument als Value \begin{itemize*} - \item Basisidee: KV-Store mit (hierarchisch) strukturiertem Dokument als Value - \item strukturiertes Dokument: - \begin{itemize*} - \item JSON-Format: geschachtelte Wide Column-Daten - \item XML (eher unüblich auf KV-Stores) - \end{itemize*} - \item Anfragen bei dokumentenorientierter Speicherung - \begin{itemize*} - \item CRUD erweitert um dokumentspezifische Suche - \item Beispiele (MongoDB mit BSON statt JSON) "$db.kritiker.find(\{Name: "Bond"\})$" - \end{itemize*} - \item Beispielsysteme für dokumentenorientierte Speicherung - \begin{itemize*} - \item MongoDB - \item CouchDB - \end{itemize*} + \item JSON-Format: geschachtelte Wide Column-Daten + \item XML (eher unüblich auf KV-Stores) \end{itemize*} - - \subsection{Graph Stores} - Graph-Datenmodelle: Grundlagen - \begin{itemize*} - \item spezielle Form der Datenrepräsentation = Graphen, insb. Beziehungen zwischen Objekten - \item Anwendungsgebiete: - \begin{itemize*} - \item Transportnetze - \item Networking: Email-Verkehr, Mobilfunk-Nutzer - \item Soziale Netzwerke: Eigenschaften, Communities - \item Web: Verlinkte Dokumente - \item Chemie: Struktur chemischer Komponenten - \item Bioinformatik: Proteinstrukturen, metabolische Pathways, Genexpressionen - \end{itemize*} - \item Graph $G = (V, E)$ - \begin{itemize*} - \item $V$: Menge der Knoten (vertices) - \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 + \item[Graph Stores] spezielle Form der Datenrepräsentation = Graphen, insb. Beziehungen zwischen Objekten + \begin{description*} + \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{description*} + \item[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 + \item[Property-Graph-Modell] Knoten und (gerichtete) Kanten mit Eigenschaften (Properties) \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 + \item Elemente: Nodes, Relationships, Properties, Labels + \item Properties = Key-Value-Paare: Key (=String), Value (=Java-Datentypen + Felder) + \item Nodes mit Labels ($\approx$ Klassenname) + \item Relationships: sind gerichtet, mit Namen und ggf. Properties + \item Anfragen $(e:ERZEUGER)-[:LiegtIn]->(a:ANBAUGEBIET \{gebiet: "Napa Valley"\} )$ + \item match: Beispielmuster für Matching + \item return: Festlegung der Rückgabedaten (Projektion) + \item where: Filterbedingung für „gematchte“ Daten + \item create: Erzeugen von Knoten oder Beziehungen + \item set: Ändern von Property-Werten \end{itemize*} + \end{description*} - 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 " \ " und " "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: - ```sql - prefix wo: - prefix weine: - weine:2171 wo:name "Pinot Noir". - ``` - \item Komplexe Graphen - \begin{itemize*} - \item mehrere Aussagen zum gleichen Subjekt - \item Objekte nicht nur Literale sondern selbst Objekte (URI) - ```sql - weine:2171 wo:name "Pinot Noir". - weine:2171 wo:farbe "Rot". - weine:2171 wo:jahrgang "1999". - weine:2171 wo:erzeuger werzeuger:567 . - ``` - \end{itemize*} - \end{itemize*} + Ontologie = formale Spezifikation einer Konzeptualisierung, d.h. einer Repräsentation von Begriffen (Konzepten) und deren Beziehungen - Repräsentation, Schema und Vokabulare - \begin{itemize*} - \item Repräsentation von RDF-Daten: N-Tripel, RDF/XML - \item RDF Schema: - \begin{itemize*} - \item objektorientierte Spezifikationssprache - \item erweitert RDF um Typsystem: Definition von Klassen und Klassenhierarchien mit Eigenschaften, Ressourcen als Instanzen von Klassen - \item RDF Schema ist selbst RDF-Spezifikation - \end{itemize*} - \item Beispiel RDF Schema - ```sql - Wein rdf:type rdfs:Class . - Schaumwein rdf:type rdfs:Class . - Schaumwein rdfs:subClassOf Wein . - Name rdf:type rdf:Property . - Jahrgang rdf:type rdf:Property . - Jahrgang rdfs:domain Wein . - Jahrgang rdfs:range xsd:integer . - ``` - \item für komplexere Ontologien: OWL (Web Ontology Language) - \item Vokabular: vordefinierte Klassen und Eigenschaften - \begin{itemize*} - \item Bsp: Dublin Core (Metadaten für Dokumente), FOAF (Soziale Netze), ... - \item wichtig z.B. für Linked Open Data - \end{itemize*} - \end{itemize*} - - SPARQL als RDF-Anfragesprache - \begin{itemize*} - \item SPARQL Protocol And RDF Query Language: Anfragesprache für RDF - \item W3C-Recommendation - \item unterschiedliche Implementierungen möglich: - \begin{itemize*} - \item Aufsatz für SQL-Backends (z.B. DB2, Oracle) - \item Triple Stores (RDF-Datenbank) - \item SPARQL-Endpoints - \end{itemize*} - \item syntaktisch an SQL angelehnt, aber Unterstützung für Graph-Anfragen - \item SPARQL-Elemente - \begin{itemize*} - \item Grundelemente: select-where-Block und Tripelmuster "?wein wo:name ?name ." - \item Auswertung: finden aller Belegungen (Bindung) für Variable (?name) bei Übereinstimmung mit nicht-variablen Teilen - ```sql - wo:name "Pinot Noir". - wo:name "Creek Shiraz". - wo:name "Chardonnay". - ``` - \end{itemize*} - \item SPARQL: Basic Graph Pattern - \begin{itemize*} - \item Graphmuster (BGP = Basic Graph Pattern): Kombination von Tripelmustern über gemeinsame Variablen - ```sql - ?wein wo:name ?name . - ?wein wo:farbe ?farbe . - ?wein wo:erzeuger ?erzeuger . - ?erzeuger wo:weingut ?ename . - ``` - \item Einsatz in SPARQL-Anfragen im where-Teil - ```sql - select ?wein ?name ?farbe ?ename - where { ?wein wo:name ?name . - ?wein wo:farbe ?farbe . - ?wein wo:erzeuger ?erzeuger . - ?erzeuger wo:weingut ?ename . } - ``` - \end{itemize*} - \item SPARQL: Weitere Elemente - \begin{itemize*} - \item filter: Filterbedingungen für Bindungen - \item optional: optionale Muster – erfordern nicht zwingend ein Matching - ```sql - prefix wo: - select ?name - where { ?wein wo:name ?name . } - optional { ?wein wo:jahrgang ?jahrgang } . - filter ( bound(?jahrgang) \&\& ?jahrgang < 2010 ) - ``` - \end{itemize*} - \end{itemize*} - - Property-Graph-Modell - \begin{itemize*} - \item Knoten und (gerichtete) Kanten mit Eigenschaften (Properties) - \item nicht streng typisiert, d.h. Eigenschaften als Name-Wert-Paare - \item Unterstützung in diversen Graph-Datenbanksystemen: neo4j, Microsoft Azure Cosmos DB, OrientDB, Amazon, Neptune, ... - \item Property-Graph-Modell in Neo4j - \begin{itemize*} - \item Elemente: Nodes, Relationships, Properties, Labels - \item Properties = Key-Value-Paare: Key (=String), Value (=Java-Datentypen + Felder) - \item Nodes mit Labels ($\approx$ Klassenname) - \item Relationships: sind gerichtet, mit Namen und ggf. Properties - \end{itemize*} - \end{itemize*} - - Anfragen auf Graphen - \begin{itemize*} - \item keine Standardsprache - \item aber wiederkehrende Grundelemente - \begin{itemize*} - \item Graph Matching: Knoten, Kanten, Pfade (siehe BGP in SPARQL) - \item Filter für Knoten- und Kanteneigenschaften - \item Konstruktion neuer Graphen - \end{itemize*} - \item Anfragen in Cypher - \begin{itemize*} - \item Basis: Muster der Form „Knoten $\rightarrow$ Kante $\rightarrow$ Knoten ...“ "(von)-[:relationship]->(nach)" - \item Beschränkung über Label und Properties $(e:ERZEUGER)-[:LiegtIn]->(a:ANBAUGEBIET \{gebiet: "Napa Valley"\} )$ - \end{itemize*} - \item Klauseln - \begin{itemize*} - \item match: Beispielmuster für Matching - \item return: Festlegung der Rückgabedaten (Projektion) - \item where: Filterbedingung für „gematchte“ Daten - \item create: Erzeugen von Knoten oder Beziehungen - \item set: Ändern von Property-Werten - \end{itemize*} - \end{itemize*} - \end{itemize*} - - Zusammenfassung - \begin{itemize*} - \item NoSQL als Oberbegriff für diverse Datenbanktechniken - \item große Bandbreite: von einfachen KV-Stores bis zu Graphdatenbanken - \item höhere Skalierbarkeit / Performance gegenüber SQL-DBMS meist durch Einschränkungen erkauft - \item Abschwächung von ACID-Eigenschaften - \item begrenzte Anfragefunktionalität - \item Nicht-Standard bzw. proprietäre Schnittstellen - \end{itemize*} + Vokabular: vordefinierte Klassen und Eigenschaften \section{Anwendungsprogrammierung} - Lernziele: - \begin{itemize*} - \item Wissen zu Konzepten und Schnittstellen zum Zugriff auf SQL-Datenbanken aus Programmiersprachen heraus - \item Verständnis prozeduraler Schnittstellen am Beispiel von JDBC - \item Kenntnisse zu Embedded SQL und prozeduralen SQL-Erweiterungen - \item Grundverständnis objektrelationaler Abbildungen - \end{itemize*} \subsection{Programmiersprachenanbindung} - Kopplungsarten: \begin{itemize*} \item prozedurale oder CALL-Schnittstellen (call level interface) - \begin{itemize*} - \item Beispiele: SQL/CLI, ODBC, JDBC, ... - \end{itemize*} \item Einbettung einer DB-Sprache in Programmiersprachen - \begin{itemize*} - \item statische Einbettung: Vorübersetzer-Prinzip $\rightarrow$ SQL-Anweisungen zur Übersetzungszeit festgelegt - \item Beispiele: Embedded SQL, SQLJ - \item dynamische Einbettung $\rightarrow$ Konstruktion von SQL-Anweisungen zur Laufzeit - \end{itemize*} \item Spracherweiterungen und neue Sprachentwicklungen - \begin{itemize*} - \item Beispiele: SQL/PSM, PL/SQL, Transact-SQL, PL/pgSQL - \end{itemize*} - \item Cursor-Konzept - \begin{itemize*} - \item Cursor: Iterator über Liste von Tupeln (Anfrageergebnis) - \end{itemize*} \end{itemize*} - \subsection{JDBC} - \begin{itemize*} - \item Datenbankzugriffsschnittstelle für Java - \item abstrakte, datenbankneutrale Schnittstelle - \item vergleichbar mit ODBC - \item Low-Level-API: direkte Nutzung von SQL - \item Java-Package java.sql - \begin{itemize*} - \item DriverManager: Einstiegspunkt, Laden von Treibern - \item Connection: Datenbankverbindung - \item Statement: Ausführung von Anweisungen über eine Verbindung - \item ResultSet: verwaltet Ergebnisse einer Anfrage, Zugriff auf einzelne Spalten - \end{itemize*} - \end{itemize*} - - %![JDBC Struktur](Assets/Datenbanksysteme_JDBC_Struktur.png) - - %![JDBC Treiber](Assets/Datenbanksysteme_JDBC_Treiberkonzept.png) - - \paragraph{Ablauf} - \begin{enumerate*} - \item Aufbau einer Verbindung zur Datenbank - \begin{itemize*} - \item Angabe der Verbindungsinformationen - \item Auswahl und Laden des Treibers - \end{itemize*} - \item Senden einer SQL-Anweisung - \begin{itemize*} - \item Definition der Anweisung - \item Belegung von Parametern - \end{itemize*} - \item Verarbeiten der Anfrageergebnisse - \begin{itemize*} - \item Navigation über Ergebnisrelation - \item Zugriff auf Spalten - \end{itemize*} - \end{enumerate*} - - \paragraph{Verbindungsaufbau} - 1. Treiber laden "Class.forName("com.company.DBDriver");" - - 2. Verbindung herstellen - ```java - String url = "jdbc:subprotocol:datasource"; - Connection con = DriverManager.getConnection - (url, "scott", "tiger"); - ``` - - JDBC-URL spezifiziert - \begin{itemize*} - \item Datenquelle/Datenbank - \item Verbindungsmechanismus (Protokoll, Server und Port) - \end{itemize*} - - \paragraph{Anfrageausführung} - 1. Anweisungsobjekt (Statement) erzeugen "Statement stmt = con.createStatement();" - - 2. Anweisung ausführen - ```java - String query = "select Name, Jahrgang from WEINE"; - ResultSet rSet = stmt.executeQuery(query); - ``` - - Klasse java.sql.Statement - \begin{itemize*} - \item Ausführung von Anfragen (SELECT) mit executeQuery - \item Ausführung von Änderungsanweisungen (DELETE, INSERT, UPDATE) mit executeUpdate - \end{itemize*} - - \paragraph{Ergebnisverarbeitung} - 1. Navigation über Ergebnismenge (Cursor-Prinzip) - ```java - while (rSet.next()) { - // Verarbeitung der einzelnen Tupel - ... - } - ``` - - 2. Zugriff auf Spaltenwerte über getType-Methoden - \begin{itemize*} - \item über Spaltenindex "String wName = rSet.getString(1);" - \item über Spaltenname "String wName = rSet.getString("Name");" - \end{itemize*} - - \paragraph{Fehlerbehandlung} - \begin{itemize*} - \item Fehlerbehandlung mittels Exception-Mechanismus - \item SQLException für alle SQL- und DBMS-Fehler - \end{itemize*} - ```java - try { - // Aufruf von JDBC-Methoden - ... - } catch (SQLException exc) { - System.out.println("SQLException: " + - exc.getMessage()); - } - ``` - - \paragraph{Änderungsoperationen} - \begin{itemize*} - \item DDL- und DML-Operationen mittels executeUpdate - \item liefert Anzahl der betroffenen Zeilen (für DML-Operationen) - \end{itemize*} - ```java - Statement stmt = con.createStatement(); - int rows = stmt.executeUpdate( - "update WEINE set Preis = Preis * 1.1 " + - "where Jahrgang < 2000"); - ``` + Datenbankzugriffsschnittstelle + \begin{description} + \item[Java] JDBC + \item[Embedded SQL für Java] SQLJ + \item[LINQ] Language Integrated Query; Einbettung einer DB-Sprache in eine Programmiersprache (C\#) + \item[Hibernate] Java-Framework für objekt-relationales Mapping + \begin{itemize*} + \item DriverManager: Einstiegspunkt, Laden von Treibern + \item Connection: Datenbankverbindung + \item Statement: Ausführung von Anweisungen über eine Verbindung + \item ResultSet: verwaltet Ergebnisse einer Anfrage, Zugriff auf einzelne Spalten + \end{itemize*} + \end{description} \paragraph{Transaktionssteuerung} \begin{itemize*} @@ -1957,336 +892,76 @@ name: /ind/, // name is like %ind% \end{itemize*} \end{itemize*} - \subsection{SQLJ} - \paragraph{Embedded SQL für Java} - \begin{itemize*} - \item Einbettung von SQL-Anweisungen in Java-Quelltext - \item Vorübersetzung des erweiterten Quelltextes in echten Java-Code durch Translator sqlj - \item Überprüfung der SQL-Anweisungen - \begin{itemize*} - \item korrekte Syntax - \item Übereinstimmung der Anweisungen mit DB-Schema - \item Typkompatibilität der für Datenaustausch genutzten Variablen - \end{itemize*} - \item Nutzung von JDBC-Treibern - \end{itemize*} - %![SQLJ Prinzip](Assets/Datenbanksysteme_SQLJ_Prinzip.png) - - Anweisungen - \begin{itemize*} - \item Kennzeichnung durch \#sql Deklarationen - \item Klassendefinitionen für Iteratoren - \item SQL-Anweisungen: Anfragen, DML- und DDL-Anweisungen "\#sql { SQL-Operation };" - \item Beispiel: "\#sql { insert into ERZEUGER (Weingut, Region) values ( "Wairau Hills", "Marlborough") };" - \end{itemize*} - - Host-Variablen - \begin{itemize*} - \item Variablen einer Host-Sprache (hier Java), die in SQL-Anweisungen auftreten können - \item Verwendung: Austausch von Daten zwischen Host-Sprache und SQL - \item Kennzeichnung durch ":variable" - \item Beispiel: - ```java - String name; - int weinID = 4711; - \#sql { select Name into :name - from WEINE where WeinID = :weinID }; - System.out.println("Wein = " + name); - ``` - \item Nullwerte: Indikatorvariable "":variable:indvar"" - \end{itemize*} - - \paragraph{Iteratoren} - \begin{enumerate*} - \item Deklaration des Iterators "\#sql public iterator WeinIter(String Name, String Weingut, int Jahrgang);" - \item Definition des Iteratorobjektes "WeinIter iter;" - \item Ausführung der Anweisung "\#sql iter = { select Name, Weingut, Jahrgang from WEINE };" - \item Navigation - ```java - while (iter.next()) { - System.out.println(iter.Name() + " " iter.Weingut()); - } - ``` - \end{enumerate*} - - Dynamic SQL: SQL-Statements als zur Laufzeit konstruierte Strings - ```java - exec sql begin declare section; - AnfrageString char(256) varying; - exec sql end declare section; - exec sql declare AnfrageObjekt statement; - AnfrageString = "delete from WEINE where WeinID = 4711"; - ... - exec sql prepare AnfrageObjekt from :AnfrageString; - exec sql execute AnfrageObjekt; - ``` - - \subsection{LINQ} - Language Integrated Query (LINQ) - \begin{itemize*} - \item Einbettung einer DB-Sprache (SQL) in eine Programmiersprache (C\#) - \item spezielle Klassenmethoden $IEnumerable res = weine.Where(w => w.Farbe == "Rot").Select(w => new { w.Name });$ - \item eigene Sprachkonstrukte (ab C\#) $IEnumerable res = from w in weine where w.Farbe == "Rot" select new { w.Name };$ - \end{itemize*} - - \subsection{Objekt-relationales Mapping} - \begin{itemize*} - \item Einsatz von - \begin{itemize*} - \item relationalen Backends (SQL-DBMS) - \item objektrelationalen Anwendungen, Applikationsservern, Middleware, ... - \end{itemize*} - \item Implementierung von „Geschäftslogik“ in Form von Objekten (Kunde, Bestellung, Vorgang, ...) - \begin{itemize*} - \item z.B. als Java Bean, CORBA-Objekt - \end{itemize*} - \item erfordert: Abbildung Klasse $\leftrightarrow$ Relation - \item Aspekte: - \begin{itemize*} - \item konzeptionelle Abbildung - \item Laufzeitunterstützung - \end{itemize*} - \item Technologien/Produkte: JDO, Hibernate, ADO.NET Entity Framework... - \end{itemize*} - - %![ORM Prinzip](Assets/Datenbanksysteme_ORM_Prinzip.png) - - Klassen und Tabellen - \begin{itemize*} - \item OO: Klasse definiert Eigenschaften von Objekten (Intension) + umfasst Menge aller Objekte (Extension) - \item RM: Relation umfasst alle Tupel, Relationenschema beschreibt Struktur - \item naheliegend: Klasse = Tabelle - \item aber: Normalisierung zerlegt Relationen! - \begin{itemize*} - \item 1 Klasse = 1 Tabelle - \item 1 Klasse = n Tabellen - \item n Klassen = 1 Tabelle - \end{itemize*} - %\item Beispiel %![Klassen und Tabellen Beispiel](Assets/Datenbanksysteme_Tabellenbeispiel.png) - \end{itemize*} - - Beziehungen - \begin{itemize*} - \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 - \item konkrete Abbildung - \begin{itemize*} - \item 1:1-Beziehungen: eingebettete Fremdschlüssel - \item 1:n-Beziehungen: eingebettete Fremdschlüssel oder Fremdschlüsseltabellen - \item Beziehungen mit Attributen: Fremdschlüsseltabellen - \item m:n-Beziehungen: Fremdschlüsseltabellen - \item Drei- und mehrstellige Beziehungen: Fremdschlüsseltabellen - \end{itemize*} - %\item %![Beziehungen](Assets/Datenbanksysteme_Beziehungen.png) - \end{itemize*} - - Hibernate - \begin{itemize*} - \item Java-Framework für objekt-relationales Mapping - \item Idee: Abbildung von Java-Objekten auf Tupel einer relationalen Datenbank - \item Prinzip: Java-Klasse + Abbildungsvorschrift $\rightarrow$ SQL-Tabelle - \item keine expliziten SQL-Anweisungen nötig! - \item Unterstützung der Navigation über Beziehungen (automatisches Nachladen der referenzierten Objekte) - \item Anfragen über eigene Sprache (HQL bzw. QBC/QBE) - \item Deklaration der Abbildung in einer XML-Mapping-Datei - \item Abbildungsvorschrift wird zur Systemlaufzeit interpretiert - \end{itemize*} - - Objekterzeugung - ```java - Transaction tx = null; - - Wein wein = new Wein(); - wein.setName("Pinot Noir"); - wein.setFarbe("Rot"); - wein.setJahr(1999); - wein.setWeingut("Helena"); - - try { - tx = session.beginTransaction(); - session.save(wein); - tx.commit(); - } catch (HibernateException exc) { - if (tx != null) tx.rollback(); - } - ``` - - Anfragen - \begin{itemize*} - \item Anfragen über Hibernate-eigene Anfragesprache HQL - \item Formulierung auf dem konzeptuellen Schema (Java-Klassen) - \item Select-Klausel nicht benötigt (Ergebnisse sind immer Objekte) - \item Beispiel - ```java - Query query = session.createQuery("from Wein where Farbe = "Rot""); - Iterator iter = query.iterate(); - while (iter.hasNext()) { - Wein wein = (Wein) iter.next(); - ... - } - ``` - \end{itemize*} - - \subsection{Prozedurale SQL-Erweiterungen: SQL/PSM} - \begin{itemize*} - \item SQL-Standard für prozedurale Erweiterungen - \item PSM: Persistent Stored Modules - \begin{itemize*} - \item gespeicherte Module aus Prozeduren und Funktionen - \item Einzelroutinen - \item Einbindung externer Routinen (implementiert in C, Java, ...) - \item syntaktische Konstrukte für Schleifen, Bedingungen etc. - \item Basis für Methodenimplementierung für objektrelationale Konzepte - \end{itemize*} - \end{itemize*} - - Vorteile gespeicherter Prozeduren - \begin{itemize*} - \item bewährtes Strukturierungsmittel - \item Angabe der Funktionen und Prozeduren erfolgt in der Datenbanksprache selbst; daher nur vom DBMS abhängig - \item Optimierung durch DBMS möglich - \item Ausführung der Prozeduren erfolgt vollständig unter Kontrolle des DBMS - \item zentrale Kontrolle der Prozeduren ermöglicht eine redundanzfreie Darstellung relevanter Aspekte der Anwendungsfunktionalität - \item Konzepte und Mechanismen der Rechtevergabe des DBMS können auf Prozeduren erweitert werden - \item Prozeduren können in der Integritätssicherung verwendet werden (etwa als Aktionsteil von Triggern) - \end{itemize*} - - Variablendeklaration - \begin{itemize*} - \item Variablen vor Gebrauch deklarieren - \item Angabe von Bezeichner und Datentyp - \item optional mit Initialwert - \end{itemize*} - ```java - declare Preis float; - declare Name varchar(50); - declare Menge int default 0; - ``` - - \paragraph{Ablaufkontrolle} - \begin{itemize*} - \item Zuweisung "set var = 42;" - \item Bedingte Verzweigungen - ```java - if Bedingung then Anweisungen - [ else Anweisungen ] end if; - ``` - \item Schleifen - ```java - loop Anweisungen end loop; - while Bedingung do - Anweisungen end while; - repeat Anweisungen - until Bedingung end repeat; - ``` - \item Schleifen mit Cursor - ```java - for SchleifenVariable as CursorName cursor for - CursorDeklaration - do - Anweisungen - end for; - ``` - \end{itemize*} - - Ablaufkontrolle Beispiel: - ```java - declare wliste varchar(500) default " "; - declare pos integer default 0; - - for w as WeinCurs cursor for - select Name from WEINE where Weingut = "Helena" - do - if pos > 0 then - set wliste = wliste || "," || w.Name; - else - set wliste = w.Name; - end if; - set pos = pos + 1; - end for; - ``` \paragraph{Ausnahmebehandlung} \begin{itemize*} \item Auslösen einer Ausnahme (Condition) "signal ConditionName;" \item Deklarieren von Ausnahmen - $declare fehlendes_weingut condition; - declare ungueltige_region - condition for sqlstate value "40123";$ - \item Ausnahmebehandlung - ```java - begin - declare exit handler for ConditionName - begin - - Anweisungen zur Ausnahmebehandlung - end - - Anweisungen, die Ausnahmen auslösen können - end - ``` \end{itemize*} + \begin{lstlisting}[ + language=SQL, + showspaces=false, + basicstyle=\ttfamily, + commentstyle=\color{gray} + ] +$declare fehlendes_weingut condition; + declare ungueltige_region + condition for sqlstate value "40123";$ + \end{lstlisting} \paragraph{Funktionen} - \begin{itemize*} - \item Funktionsdefinition - ```java - create function geschmack (rz int) - returns varchar(20) - begin + \begin{lstlisting}[ + language=JAVA, + showspaces=false, + basicstyle=\ttfamily, + commentstyle=\color{gray} + ] +create function geschmack (rz int) +returns varchar(20) + begin return case - when rz <= 9 then "Trocken" - when rz > 9 and rz <= 18 then "Halbtrocken" - when rz > 18 and rz <= 45 then "Lieblich" - else "Süß" + when rz <= 9 then "Trocken" + when rz > 9 and rz <= 18 then "Halbtrocken" + when rz > 18 and rz <= 45 then "Lieblich" + else "Suess" end - end - ``` - \item Aufruf innerhalb einer Anfrage - ```java - select Name, Weingut, geschmack(Restzucker) from WEINE - where Farbe = "Rot" and geschmack(Restzucker) = "Trocken" - ``` - \item Nutzung außerhalb von Anfragen "set $wein_geschmack$ = geschmack (12);" - \end{itemize*} + end +//Aufruf innerhalb einer Anfrage +select Name, Weingut, geschmack(Restzucker) from WEINE + where Farbe = "Rot" and geschmack(Restzucker) = "Trocken" + \end{lstlisting} \paragraph{Prozeduren} Prozedurdefinition - ```java - create procedure weinliste (in erz varchar(30), + \begin{lstlisting}[ + language=SQL, + showspaces=false, + basicstyle=\ttfamily, + commentstyle=\color{gray} + ] +create procedure weinliste (in erz varchar(30), out wliste varchar(500)) begin - declare pos integer default 0; - for w as WeinCurs cursor for - select Name from WEINE where Weingut = erz - do xy - end for; - end; end; - ``` + declare pos integer default 0; + for w as WeinCurs cursor for + select Name from WEINE where Weingut = erz + do xy + end for; + end; +end; +// Nutzung ueber call-Anweisung +declare wliste varchar(500); +call weinliste ("Helena", wliste); + \end{lstlisting} - Nutzung über call-Anweisung - ```java - declare wliste varchar(500); - call weinliste ("Helena", wliste); - ``` - - Zugriffscharakteristik: Eigenschaften von Prozeduren, die Anfrageausführung und -optimierung beeinflussen - \begin{itemize*} - \item \textbf{deterministic}: Routine liefert für gleiche Parameter gleiche Ergebnisse - \item \textbf{no sql}: Routine enthält keine SQL-Anweisungen - \item \textbf{contains sql}:Routine enthält SQL-Anweisungen (Standard für SQL-Routinen) - \item \textbf{reads sql data}: Routine führt SQL-Anfragen (select-Anweisungen) aus - \item \textbf{modifies sql data}: Routine, die DML-Anweisungen (insert, update, delete) enthält - \end{itemize*} - - \subsection{Zusammenfassung} - \begin{itemize*} - \item Verbindung zwischen SQL und imperativen Sprachen - \item Call-Level-Schnittstelle vs. Embedded SQL - \item objektrelationales Mapping - \item SQL/PSM: imperative Erweiterungen von SQL $\rightarrow$ Implementierung von Funktionen und Prozeduren - \end{itemize*} - + \begin{description*} + \item[deterministic] Routine liefert für gleiche Parameter gleiche Ergebnisse + \item[no sql] Routine enthält keine SQL-Anweisungen + \item[contains sql] Routine enthält SQL-Anweisungen (Standard für SQL-Routinen) + \item[reads sql data] Routine führt SQL-Anfragen (select-Anweisungen) aus + \item[modifies sql data] Routine, die DML-Anweisungen (insert, update, delete) enthält + \end{description*} \end{multicols} \end{document} \ No newline at end of file diff --git a/README.md b/README.md index 6aae8b6..0c976f3 100644 --- a/README.md +++ b/README.md @@ -14,7 +14,7 @@ Unterlagen zu Informatik Vorlesungen der TU Ilmenau - [Computergrafik Cheatsheet](Computergrafik%20-%20Cheatsheet.pdf) (work in progress) - [Datenbanksysteme](Datenbanksysteme.md) - [Fragenkatalog](Datenbanksysteme%20-%20Fragen.md) - - [Cheatsheet](Datenbanksysteme%20-%20Cheatsheet.pdf) (work in progress) + - [Cheatsheet](Datenbanksysteme%20-%20Cheatsheet.pdf) - [Einführung in die Medizinische Informatik](Einführung%20in%20die%20Medizinische%20Informatik.md) - [Grundlagen und diskrete Strukturen](Grundlagen%20und%20Diskrete%20Strukturen.md) - [GudS - Cheatsheet](Grundlagen%20und%20Diskrete%20Strukturen%20-%20Cheatsheet.pdf)