\documentclass[a4paper]{article}
\usepackage[ngerman]{babel}
\usepackage{multicol}
\usepackage{calc}
\usepackage{ifthen}
\usepackage[landscape,left=1cm,top=1cm,right=1cm,nohead,nofoot]{geometry}
\usepackage{amsmath,amsthm,amsfonts,amssymb}
\usepackage{color,graphicx,overpic}
\usepackage{xcolor, listings}
\usepackage{textcomp}
\usepackage[compact]{titlesec} %less space for headers
\usepackage{mdwlist} %less space for lists
\usepackage[utf8]{inputenc}
\usepackage{tikz}
\usepackage{pdflscape}
\usepackage{verbatim}
\usetikzlibrary{mindmap, arrows,shapes,positioning,shadows,trees}
\tikzstyle{every node}=[draw=black,thin,anchor=west, minimum height=2em]
\usepackage[hidelinks,pdfencoding=auto]{hyperref}

\pdfinfo{
    /Title (Datenbanksysteme - Cheatsheet)
    /Creator (TeX)
    /Producer (pdfTeX 1.40.0)
    /Author (Robert Jeutter)
    /Subject ()
}
% Information boxes
\newcommand*{\info}[4][16.3]{
  \node [ annotation, #3, scale=0.65, text width = #1em, inner sep = 2mm ] at (#2) {
  \list{$\bullet$}{\topsep=0pt\itemsep=0pt\parsep=0pt
    \parskip=0pt\labelwidth=8pt\leftmargin=8pt
    \itemindent=0pt\labelsep=2pt}
    #4
  \endlist
  };
}

%%% Code Listings
\definecolor{codegreen}{rgb}{0,0.6,0}
\definecolor{codegray}{rgb}{0.5,0.5,0.5}
\definecolor{codepurple}{rgb}{0.58,0,0.82}
\definecolor{backcolour}{rgb}{0.95,0.95,0.92}
\lstdefinestyle{mystyle}{
  backgroundcolor=\color{backcolour},   
  commentstyle=\color{codegreen},
  keywordstyle=\color{magenta},
  numberstyle=\tiny\color{codegray},
  stringstyle=\color{codepurple},
  basicstyle=\ttfamily,
  breakatwhitespace=false, 
}
\lstset{style=mystyle, upquote=true}

% This sets page margins to .5 inch if using letter paper, and to 1cm
% if using A4 paper. (This probably isn"t strictly necessary.)
% If using another size paper, use default 1cm margins.
\ifthenelse{\lengthtest { \paperwidth = 11in}}
    { \geometry{top=.5in,left=.5in,right=.5in,bottom=.5in} }
    {\ifthenelse{ \lengthtest{ \paperwidth = 297mm}}
        {\geometry{top=1cm,left=1cm,right=1cm,bottom=1cm} }
        {\geometry{top=1cm,left=1cm,right=1cm,bottom=1cm} }
    }

% Redefine section commands to use less space
\makeatletter
\renewcommand{\section}{\@startsection{section}{1}{0mm}%
                                {-1ex plus -.5ex minus -.2ex}%
                                {0.5ex plus .2ex}%x
                                {\normalfont\large\bfseries}}
\renewcommand{\subsection}{\@startsection{subsection}{2}{0mm}%
                                {-1explus -.5ex minus -.2ex}%
                                {0.5ex plus .2ex}%
                                {\normalfont\normalsize\bfseries}}
\renewcommand{\subsubsection}{\@startsection{subsubsection}{3}{0mm}%
                                {-1ex plus -.5ex minus -.2ex}%
                                {1ex plus .2ex}%
                                {\normalfont\small\bfseries}}
\makeatother

% Define BibTeX command
\def\BibTeX{{\rm B\kern-.05em{\sc i\kern-.025em b}\kern-.08em
    T\kern-.1667em\lower.7ex\hbox{E}\kern-.125emX}}

% Don"t print section numbers
\setcounter{secnumdepth}{0}

\setlength{\parindent}{0pt}
\setlength{\parskip}{0pt plus 0.5ex}    
% compress space
\setlength\abovedisplayskip{0pt}
\setlength{\parskip}{0pt}
\setlength{\parsep}{0pt}
\setlength{\topskip}{0pt}
\setlength{\topsep}{0pt}
\setlength{\partopsep}{0pt}
\linespread{0.5}
\titlespacing{\section}{0pt}{*0}{*0}
\titlespacing{\subsection}{0pt}{*0}{*0}
\titlespacing{\subsubsection}{0pt}{*0}{*0}

%My Environments
\newtheorem{example}[section]{Example}

% Turn off header and footer
\pagestyle{empty}
\begin{document}

\raggedright
\begin{multicols}{3}
    \scriptsize
    % multicol parameters
    % These lengths are set only within the two main columns
    %\setlength{\columnseprule}{0.25pt}
    \setlength{\premulticols}{1pt}
    \setlength{\postmulticols}{1pt}
    \setlength{\multicolsep}{1pt}
    \setlength{\columnsep}{2pt}

    \section{SQL}
\begin{lstlisting}[
        language=SQL,
        showspaces=false,
        basicstyle=\ttfamily,
        commentstyle=\color{gray}
     ]
CREATE TABLE t (
    id INT PRIMARY KEY,
    c1 TEXT,
    name VARCHAR NOT NULL,
    price INT DEFAULT 0,

    PRIMARY KEY (c1),
    FOREIGN KEY (c1) REFERENCES t2(c2),
    UNIQUE(c1,name), 
    CHECK(id> 0 AND price >= id)
);

DROP TABLE t; //Delete table
ALTER TABLE t ADD column; //Add new column
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

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

SELECT c1, c2 FROM t //Query data
SELECT c1, c2 FROM t1, t2 //cross join
SELECT * FROM t //Query all rows
SELECT DISTINCT... //Query distinct rows
    ...UNION [ALL] //Combine rows from queries
    ...INTERSECT //Return intersection
    ...MINUS //Subtract result

...WHERE condition //with condition
    ...IS [NOT] NULL
    ...[NOT] LIKE pa%ttern_ //% kein/beliebig viele; $ genau ein Zeichen
    ...[NOT] IN value_list
    ...BETWEEN low AND high

...GROUP BY c1 //Group rows
...GROUP BY c1 HAVING condition; //Filter
...ORDER BY c1 ASC [DESC] //Sort result
...HAVING bedingung // !TODO
...LIMIT n OFFSET offset //return n rows

...INNER JOIN t2 ON condition
...LEFT JOIN t2 ON condition
...RIGHT JOIN t2 ON condition
...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... 
...UNION [ALL]
...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;

//AGGREGATE FUNCTIONS
AVG     //returns the average of a list
COUNT   //returns the number of elements of a list 
SUM     //returns the total of a list
MAX     //returns the maximum value in a list
MIN     //returns the minimum value in a list
\end{lstlisting}

    \section{NoSQL (MongoDB)}
    \begin{lstlisting}[
        language=SQL,
        showspaces=false,
        basicstyle=\ttfamily,
        commentstyle=\color{gray}
     ]
db.createUser({
    user: "dbadmin",
    pwd: "12345678",
    roles: [{ role: "dbOwner", db: "admin" }],
})

db.users.insert({
    userid: "123",
    age: 18,
    name: "vikash",
})

db.users
    .distinct("name")   //show distinct value for
    .find(
        { //where clauses
            name: "vikash",
        },
        { //select fields
            name: 1, 
            age: 1,
        }
    )
    .limit(2)
    .skip(5)
    .sort({
        age: 1,
    })
    .count() // number of documents in collection

db.users.update({
    name: "vikash",
},{
    $set: { age: 19 }, //update field
    $inc: { age: 5 }, //increase field
},{
    multi: true,
})

db.users.remove({})
db.users.remove({
    name: "vikash",
})

db.users.aggregate([
    { $match: {name: "vikash"} },
    { $group: {_id: "$age", num_usr: {$sum: 1} } }
    { $sort: {age: 1} }
])

db.users.ensureIndex()  //Create an index on field 
db.users.dropIndex()    //Drop an index from field

show dbs //show all database 	
db.getName() //show current database
use usersdb //switch or create to database 'userdb'

db.dropDatabase() //drop current database
db.getCollectionNames() //show all collections
db.createCollection("users") //create collection 'users' 	
db.users.drop() //drop collection 'users'

//Aggregate Functions
$ne: "contr"    // negate clause
$or: [{a},{b}]  // a or b
$gt: x          // greater than x
$lt: x          // less than
$gte: x         // greater than even
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
        \item physisch: Änderung der Dateiorganisation und Zugriffspfade haben keinen Einfluss auf das konzeptuelle Schema
        \item logisch: Änderung am konzeptuellen und gewissen externen Schemata haben keine Auswirkungen auf andere externe Schemata und Anwendungsprogramme
    \end{itemize*}

    \paragraph{3 Schichten Architektur}
    Klassifizierung
    \begin{itemize*}
        \item Definitionskomponenten: Datendefinition, Dateiorganisation, Sichtdefinition
        \item Programmierkomponenten: DB-Programmierung mit eingebetteten DB-Operationen
        \item Benutzerkomponenten: Anwendungsprogramme, Anfrage und Update interaktiv
        \item Transformationskomponenten: Optimierer, Auswertung, Plattenzugriffssteuerung
        \item Data Dictionary (Datenwörterbuch): Aufnahme der Daten aus Definitionskomponenten, Versorgung der anderen Komponenten
    \end{itemize*}

    \paragraph{5 Schichten Architektur}
    Verfeinerung
    \begin{itemize*}
        \item Datensystem: Übersetzung, Zugriffspfadwahl
        \item Zugriffssystem: Logische Zugriffspfade, Schemakatalog, Sortierung, Transaktionsverwaltung
        \item Speichersystem Speicherungsstrukturen, Zugriffspfadverwaltung, Sperrverwaltung, Logging, Recovery
        \item Pufferverwaltung: Systempufferverwaltung, Seitenersetzung, Seitenzuordnung
        \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{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*}

    \paragraph{Datenbankmodelle im Überblick}
    \begin{itemize*}
        \item HM: hierarchisches Modell, 
        \item NWM: Netzwerkmodell, 
        \item RM: Relationenmodell
        \item NF 2: Modell der geschachtelten (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
        \begin{itemize*}
            \item OEM: objektorientierte Entwurfsmodelle (etwa UML),
            \item ORDM: objektrelationale Datenmodelle
        \end{itemize*}
    \end{itemize*}

    \subsection{ER Modell}
    \begin{description*}
        \item[Entity] Objekt/Informationen
        \item[Entity Typ] Gruppierung von Entitys mit gleichen Eigenschaften
        \item[Relationship]
        \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
        \end{itemize*}
        \item[Tupel] Zeile einer Tabelle
        \item[Werte] primitive Datenelemente, die direkt darstellbar sind
        \item[Schlüssel] 
        \begin{itemize*}
            \item identifizierende Eigenschaft von Entitys
            \item minimale Menge von Attributen, deren Werte ein Tupel einer Tabelle eindeutig identifizieren
        \end{itemize*}
        \item[Schlüsselattribute] Teilmenge der gesamten Attribute eines 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
        \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[Stelligkeit/Grad] Anzahl der an einem Beziehungstyp beteiligten Entity Typen
    \end{description*}

    Beziehungen
    \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[N:1] invers zu 1:N, auf funktionale Beziehung
        \item[M:N] keine Restriktionen
        \item[Kardinalitätsangaben]
    \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{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 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[Zweite Normalform]
        \begin{itemize*}
            \item Zweite Normalform eliminiert derartige partielle Abhängigkeiten bei Nichtschlüsselattributen
            \item partielle Abhängigkeit liegt vor, wenn ein Attribut funktional schon von einem Teil des Schlüssels abhängt
        \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 3 NF betrachtet nur Nicht-Schlüsselattribute als Endpunkt transitiver Abhängigkeiten
            \item $A \in R$ heißt transitiv abhängig von X bezüglich F genau dann, wenn es ein $Y\subseteq R$ gibt mit $X \rightarrow Y, Y \not\rightarrow X, Y \rightarrow A, A \not\in XY$
        \end{itemize*}
        \item[Boyce-Kodd-Normalform] (Verschärfung der 3NF): Eliminierung transitiver Abhängigkeiten auch zwischen Primattributen $\not\exists A \in R$: A transitiv abhängig von einem $K\in\bf{K}$ bezüglich F
        \item[Minimalität]
        \begin{itemize*}
            \item Global Redundanzen vermeiden
            \item andere Kriterien (wie Normalformen) mit möglichst wenig Schemata erreichen
            \item Beispiel: Attributmenge ABC, FD-Menge ${A \rightarrow B, B \rightarrow C}$
        \end{itemize*}
        \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}
    \begin{itemize*}
        \item Abhänggikeitstreue (Kennung T1)
        \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}\}$
        \end{itemize*}
        \item Verbundtreue (Kennung T2)
        \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
        \end{itemize*}
    \end{itemize*}


    \section{Relationale Theorie}
    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$
        \item F3: Transitivität $\{ X\rightarrow Y,Y\rightarrow Z\}\Rightarrow X\rightarrow Y$
        \item F4: Dekomposition $\{X\rightarrow YZ\} \Rightarrow X\rightarrow Y$
        \item F5: Vereinigung $\{X\rightarrow Y, X\rightarrow Z\}\Rightarrow X\rightarrow YZ$
        \item F6: Pseudotransitivität $\{X\rightarrow Y, WY\rightarrow Z\}\Rightarrow WX\rightarrow Z$
    \end{itemize*}

    F1-F3 bekannt als Armstrong-Axiome (sound, complete)
    \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 minimal: keine Regel kann weggelassen werden
    \end{itemize*}

    Alternative Regelmenge
    \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
    \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.

    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 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*}

    \paragraph{Minimale Überdeckung} Eine minimale Überdeckung ist eine Überdeckung, die eine minimale Anzahl von FDs enthält

    \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*}
    \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 |




    \paragraph{Quantoren und Mengenvergleiche}
    \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 ä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
        \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{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
    \end{itemize*}

    Relationale Kalküle
    \begin{itemize*}
        \item Bereichskalkül: Variablen nehmen Werte elementarer Datentypen (Bereiche) an
        \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*}
        \end{itemize*}

        Motivation: Die Sprache QBE
        \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
        \end{itemize*}

        > Semantisch sichere Anfragen: Anfragen, die für jeden Datenbankzustand $\sigma(R)$ ein endliches Ergebnis liefern

        > Semantische Sicherheit Semantische Sicherheit ist im Allgemeinen nicht entscheidbar!

        > Syntaktische Sicherheit: Jede freie Variable $x_i$ muss überall in $\phi(x_1,...)$ durch positives Auftreten $x_i = t$ oder $R(. . . , x_i , . . . )$ an endliche Bereiche gebunden werden.
        \begin{itemize*}
            \item Syntaktisch sichere Anfragen: Anfragen, die syntaktischen Einschränkungen unterliegen, um die semantische Sicherheit zu erzwingen.
            \item Bindung an endliche Bereiche muss für die ganze Bedingung gelten, also insbesondere für alle Zweige einer Disjunktion
        \end{itemize*}

        \subsection{Eigenschaften des Bereichskalküls}
        Ausdrucksfähigkeit des Bereichskalküls: Bereichskalkül ist streng relational vollständig, d.h. zu jedem Term $\tau$ der Relationenalgebra gibt es einen äquivalenten (sicheren) Ausdruck $\eta$ des Bereichskalküls.

        \section{Transaktionen, Integrität und Trigger}
        \subsection{Grundbegriffe}
        Integritätsbedingung (engl. integrity constraint oder assertion): Bedingung für die „Zulässigkeit“ oder „Korrektheit“

        \begin{itemize*}
            \item Typintegrität
            \begin{itemize*}
                \item SQL erlaubt Angabe von Wertebereichen zu Attributen
                \item Erlauben oder Verbieten von Nullwerten
            \end{itemize*}
            \item Schlüsselintegrität
            \begin{itemize*}
                \item Angabe eines Schlüssels für eine Relation
            \end{itemize*}
            \item Referentielle Integrität
            \begin{itemize*}
                \item die Angabe von Fremdschlüsseln
            \end{itemize*}
        \end{itemize*}

        \subsection{Transaktionsbegriff}
        Beispiel:
        \begin{itemize*}
            \item Platzreservierung für Flüge gleichzeitig aus vielen Reisebüros $\rightarrow$ Platz könnte mehrfach verkauft werden, wenn mehrere Reisebüros den Platz als verfügbar identifizieren
            \item überschneidende Kontooperationen einer Bank
            \item statistische Datenbankoperationen $\rightarrow$ Ergebnisse sind verfälscht, wenn während der Berechnung Daten geändert werden
        \end{itemize*}

        > Transaktion: Eine Transaktion ist eine Folge von Operationen (Aktionen), die die Datenbank von einem konsistenten Zustand in einen konsistenten, eventuell veränderten, Zustand überführt, wobei das ACID-Prinzip eingehalten werden muss.
        \begin{itemize*}
            \item Aspekte:
            \begin{itemize*}
                \item Semantische Integrität: Korrekter (konsistenter) DB-Zustand nach Ende der Transaktion
                \item Ablaufintegrität: Fehler durch "gleichzeitigen" Zugriff mehrerer Benutzer auf dieselben Daten vermeiden
            \end{itemize*}
            \item ACID-Eigenschaften
            \begin{itemize*}
                \item Atomicity (Atomarität): Transaktion wird entweder ganz oder gar nicht ausgeführt
                \item Consistency (Konsistenz oder auch Integritätserhaltung): Datenbank ist vor Beginn und nach Beendigung einer Transaktion jeweils in einem konsistenten Zustand
                \item Isolation (Isolation): Nutzer, der mit einer Datenbank arbeitet, sollte den Eindruck haben, dass er mit dieser Datenbank alleine arbeitet
                \item Durability (Dauerhaftigkeit / Persistenz): nach erfolgreichem Abschluss einer Transaktion muss das Ergebnis dieser Transaktion „dauerhaft“ in der Datenbank gespeichert werden
            \end{itemize*}
            \item Kommandos einer Transaktionssprache
            \begin{itemize*}
                \item Beginn einer Transaktion: Begin-of-Transaction-Kommando BOT (in SQL implizit!)
                \item commit: die Transaktion soll erfolgreich beendet werden
                \item abort: die Transaktion soll abgebrochen werden
            \end{itemize*}
        \end{itemize*}

        Vereinfachtes Modell für Transaktion
        \begin{itemize*}
            \item Repräsentation von Datenbankänderungen einer Transaktion
            \begin{itemize*}
                \item "read(A,x)": weise den Wert des DB-Objektes A der Variablen x zu
                \item "write(x, A)": speichere den Wert der Variablen x im DB-Objekt A
            \end{itemize*}
            \item Beispiel einer Transaktion T:
            \begin{itemize*}
                \item "read(A, x); x := x - 200; write(x, A);"
                \item "read(B, y); y := y + 100; write(y, B);"
            \end{itemize*}
            \item Ausführungsvarianten für zwei Transaktionen $T_1 , T_2$:
            \begin{itemize*}
                \item seriell, etwa $T_1$ vor $T_2$
                \item „gemischt“, etwa abwechselnd Schritte von $T_1$ und $T_2$
            \end{itemize*}
            \item Probleme im Mehrbenutzerbetrieb
            \begin{itemize*}
                \item Inkonsistentes Lesen: Nonrepeatable Read
                \item Variablen/Speicher ändert sich durch fertigstellen anderer Transaktionen während des Ablaufs
                \item dirty read
                \item Das Phantom-Problem: durch "insert" ändert sich "select" ergebnis; nachfolgende rechnungen auf vorherigen abruf sind falsch
                \item Verlorengegangenes Ändern: "Lost Update" updates gehen verloren, wenn gleiche Variablen gleicheitig beschrieben werden (oder kurz nacheinander)
            \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 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*}
        \end{itemize*}


        \subsection{Document Stores}
        Datenmodell: dokumentenorientierte Speicherung
        \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*}
        \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
        \begin{itemize*}
            \item Sprache zur Repräsentation von Informationen über (Web)-Ressourcen
            \item Ziel: automatisierte Verarbeitung
            \item zentraler Bestandteil von Semantic Web, Linked (Open) Data
            \item Repräsentation von Daten, aber auch Wissensrepräsentation (z.B. Ontologie)
        \end{itemize*}

        Ontologien
        \begin{itemize*}
            \item Ontologie = formale Spezifikation einer Konzeptualisierung, d.h. einer Repräsentation von Begriffen (Konzepten) und deren Beziehungen
            \item Anwendung: Annotation von Daten, semantische Suche
        \end{itemize*}

        RDF: Graphen \& Tripel
        \begin{itemize*}
            \item Graph = Menge von Tripeln, die Aussagen über Web-Ressourcen repräsentieren
            \item Identifikation der Web-Ressourcen über Uniform Resource Identifier (URI)
            \item Tripel: subjekt prädikat objekt .
            \item Beispiel "<http://weindb.org/weine/2171> \ " und "<http://weindb.org/ontologie/name> "Pinot Noir"."
            \item Subjekt: URI-Referenz, d.h. Ressource, auf die sich die Aussage bezieht
            \item Prädikat: Eigenschaft, ebenfalls in Form einer URI-Referenz
            \item Objekt: Wert der Eigenschaft als Literal (Konstante) oder URI- Referenz
            \item abkürzende Notation für Namensräume über Präfixe:
            ```sql
            prefix wo: <http://weindb.org/ontologie/>
            prefix weine: <http://weindb.org/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*}

        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
                <http://weindb.org/weine/2171> wo:name "Pinot Noir".
                <http://weindb.org/weine/2168> wo:name "Creek Shiraz".
                <http://weindb.org/weine/2169> 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: <http://weindb.org/ontologie/>
                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*}

    \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");
    ```

    \paragraph{Transaktionssteuerung}
    \begin{itemize*}
        \item Methoden von Connection
        \begin{itemize*}
            \item commit ()
            \item rollback ()
        \end{itemize*}
        \item Auto-Commit-Modus
        \begin{itemize*}
            \item implizites Commit nach jeder Anweisung
            \item Transaktion besteht nur aus einer Anweisung
            \item Umschalten mittels setAutoCommit (boolean)
        \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<string> res = weine.Where(w => w.Farbe == "Rot").Select(w => new { w.Name });$
        \item eigene Sprachkonstrukte (ab C\#) $IEnumerable<op> 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*}

    \paragraph{Funktionen}
    \begin{itemize*}
        \item Funktionsdefinition
        ```java
        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üß"
        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*}

    \paragraph{Prozeduren}
    Prozedurdefinition
    ```java
    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;
    ```

    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*}


\end{multicols}
\end{document}