Informatik/Datenbanksysteme - Cheatsheet.tex

\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, er}
\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 (id),
    FOREIGN KEY (c1) REFERENCES t2(c2),
    UNIQUE(id,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 c1 TO c2; //Rename column

INSERT INTO t(column_list) VALUES(value_list);
...SELECT column_list FROM t2;
UPDATE t SET c1= new_value;
UPDATE t SET c1 = new_value WHERE condition;
DELETE FROM t; //Delete all data
DELETE FROM t WHERE 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 %xy_ //%=beliebig viele; $=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

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;

CREATE INDEX idx_name ON t(c1,c2);
CREATE UNIQUE INDEX idx_name ON t(c3,c4);
DROP INDEX idx_name;

CREATE OR MODIFY TRIGGER trigger_name
    [BEFORE | AFTER] [INSERT | UPDATE | DELETE] 
    ON table_name FOR EACH [ROW | STATEMENT]
    EXECUTE stored_procedure;
DROP TRIGGER trigger_name;

CREATE ASSERTION name CHECK (praedikat)
GRANT rechte ON tabelle TO nutzer [with grant option]
REVOKE rechte ON tabelle TO nutzer [restrict | cascade ]

//AGGREGATE FUNCTIONS
AVG     //returns the average of a list
COUNT   //returns the number of elements of a list 
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}

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

    \subsection{Codd"sche Regeln}
    \begin{description*}
        \item[Integration] einheitliche, nichtredundante Datenverwaltung
        \item[Operationen] Speichern, Suchen, Ändern
        \item[Katalog] Zugriffe auf DBbeschreibungen im Data Dictionary
        \item[Benutzersichten]
        \item[Integritätssicherung] Korrektheit des Datenbankinhalts
        \item[Datenschutz] Ausschluss unauthorisierter Zugriffe
        \item[Transaktionen] mehrere DB-Operationen als Funktionseinheit
        \item[Synchronisation] parallele Transaktionen koordinieren
        \item[Datensicherung] Wiederherstellung von Daten nach Systemfehlern
    \end{description*}

    Schemata:
    \begin{itemize*}
        \item Konzeptuelles Schema (Ergebnis der Dateidefinition)
        \item Internes Schema (Festlegung Dateiorganisation/pfade = Index)
        \item Externes Schema (Ergebnis der Sichtdefinition)
        \item Anwendungsprogramm (Ergebnis der Programmierung)
        \begin{itemize*}
            \item Schema: Metadaten, Datenbeschreibung
            \item Instanz: Anwenderdaten, Datenbankzustand
        \end{itemize*}
    \end{itemize*}

    \paragraph{3 Schichten Architektur}
    Klassifizierung
    \begin{itemize*}
        \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*}

    \subsection{Relationenalgebra}
    \begin{description*}
        \item[Selektion] $\sigma_{Bedingung} (Relation)$: Auswahl von Zeilen (WHERE)
        \item[Projektion] $\pi_{Attributmenge}(Relation)$: Auswahl von Spalten; entfernt doppelte Tupel; (SELECT DISTINCT)
        \item[Verbund] $R_1 \bowtie R_2$: verknüpft Tabellen über gleichbenannte Spalten, verschmilzt jew Tupel gleicher Werte; Tupel ohne Partner eliminiert (JOIN/ NATURAL JOIN)
        \item[Umbenennung] $\beta_{neu\leftarrow alt} (R)$: Ändern von Attributnamen (AS)
        \item[Vereinigung] $r_1 \cup r_2$ von zwei Relationen $r_1$ und $r_2$ (UNION)
        \begin{itemize*}
            \item Gesamtheit der beiden Tupelmengen
            \item Attributmengen beider Relationen müssen identisch sein
        \end{itemize*}
        \item[Differenz] $r_1 - r_2$ eliminiert die Tupel aus der ersten Relation, die auch in der zweiten Relation vorkommen (EXCEPT)
        \item[Durchschnitt] $r_1 \cap r_2$: ergibt die Tupel, die in beiden Relationen gemeinsam vorkommen (INTERSECT)
        \item[Quantoren/Mengenvergleiche] $\Theta =\{ all \| any \| some \}$
        \item[Assertion] Prädikat, das eine Bedingung ausdrückt, die von der Datenbank immer erfüllt sein muss
        \item[Trigger] Anweisung/Prozedur, die bei Eintreten eines bestimmten Ereignisses automatisch vom DBMS ausgeführt wird
        \item[Sicht] virtuelle Relationen (bzw virtuelle Datenbankobjekte in anderen Datenmodellen)
    \end{description*}

    \paragraph{Datenbankmodelle im Überblick}
    \begin{itemize*}
        \item HM: hierarchisches Modell,
        \item NWM: Netzwerkmodell,
        \item RM: Relationenmodell
        \item NF 2: Geschachtelte (Non-First-Normal-Form) Relationen
        \item eNF 2: erweitertes NF 2 -Modell
        \item ER: Entity-Relationship-Modell, SDM: semantische Datenmodelle
        \item OODM/C++: objektorientierte Datenmodelle
        \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[Relation/Relationship] Menge aller Einträge
        \begin{itemize*}
            \item beschreibt eine Beziehung zwischen Entities
            \item Menge von Zeilen einer Tabelle
        \end{itemize*}
        \item[Attribut]
        \begin{itemize*}
            \item repräsentiert eine Eigenschaft von Entities/Beziehungen
            \item Spalte/Spaltenüberschrift einer Tabelle
        \end{itemize*}
        \item[Tupel] Zeile einer Tabelle
        \item[Werte] primitive Datenelemente; Attributwert
        \item[Schlüssel]
        \begin{itemize*}
            \item identifizierende Eigenschaft von Entitys
            \item minimale Menge von Attributen, die Tupel eindeutig identifizieren
        \end{itemize*}
        \item[Schlüsselattribute] Teilmenge gesamter Attribute von Entity-Typs
        \begin{itemize*}
            \item Auswahl des Primärschlüssels bei mehreren Schlüsselkandidaten
            \item Schlüssel durch Unterstreichen gekennzeichnet
        \end{itemize*}
        \item[Primärschlüssel] ein beim Datenbankentwurf ausgezeichneter Schlüssel
        \item[Fremdschlüssel] Attributmenge, die Schlüssel einer anderen Relation ist
        \item[Beziehungstypen] Beziehungen zwischen Entities zu Beziehungstypen
        \item[Kardinalitäten/Funktionalität] Einschränkung von Beziehungstypen bezüglich mehrfachen Teilnahme von Entitys an Beziehung
        \item[Stelligkeit/Grad] Anzahl der an einem Beziehungstyp beteiligten Entity Typen
    \end{description*}

    Stelligkeit
    \begin{description*}
        \item[0,*] legt keine Einschränkung fest (default)
        \item[1:1] jedem Entity $e_1$ ist maximal ein Entity $e_2$ zugeordnet und umgekehrt
        \item[1:N] jedem Entity $e_1$ sind beliebig viele Entities $E_2$ zugeordnet, aber zu jedem Entity $e_2$ gibt es maximal ein $e_1$
        \item[N:1] invers zu 1:N, auf funktionale Beziehung
        \item[M:N] keine Restriktionen
        \item[Kardinalitätsangaben]
        \begin{itemize*}
            \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*}

    \paragraph{Normalformen}
    \begin{itemize*}
        \item legen Eigenschaften von Relationenschemata fest
        \item verbieten bestimmte Kombinationen von funkt. Abhängigkeiten
        \item sollen Redundanzen und Anomalien vermeiden
    \end{itemize*}
    \begin{description*}
        \item[Erste Normalform] nur atomare Attribute in den Relationenschemata, d.h. als Attributwerte sind Elemente von Standard-Datentypen wie integer/string erlaubt, aber keine Konstruktoren [array/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 auch transitive Abhängigkeiten
            \item etwa Weingut $\rightarrow$ Anbaugebiet und Anbaugebiet $\rightarrow$ Region
            \item 3 NF betrachtet nur Nicht-Schlüsselattribute als Endpunkt transitiver Abhängigkeiten
            \item $A \in R$ heißt transitiv abhängig von X bezüglich F genau dann, wenn es ein $Y\subseteq R$ gibt mit $X \rightarrow Y, Y \not\rightarrow X, Y \rightarrow A, A \not\in XY$
        \end{itemize*}
        \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*}

    \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 formale Beschreibung des Fachproblems
        \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 Element
            \item[Bedingungskonflikte] verschiedene Schlüssel für ein Element
            \item[Strukturkonflikte] gleicher Sachverhalt durch unterschiedliche Konstrukte
        \end{description*}
    \end{itemize*}

    \paragraph{Verteilungsentwurf}
    \begin{itemize*}
        \item sollen Daten auf mehreren Rechnern verteilt vorliegen, muss Art und Weise der verteilten Speicherung festgelegt werden
        \item horizontale Verteilung z.B. Kunden 1-100 und Kunden 101-200
        \item vertikale Verteilung z.B. Adresse in DB1, Konto in DB2
    \end{itemize*}

    \paragraph{Logischer Entwurf}
    \begin{itemize*}
        \item Datenmodell des ausgewählten DBMS
        \item Transformation des konzeptionellen Schemas
        \item Verbesserung des relationalen Schemas anhand von Gütekriterien
    \end{itemize*}

    \paragraph{Datendefinition}
    \begin{itemize*}
        \item Umsetzung des logischen Schemas in ein konkretes Schema
        \begin{itemize*}
            \item Datenbankdeklaration in der DDL des DBMS
            \item Realisierung der Integritätssicherung
            \item Definition der Benutzersichten
        \end{itemize*}
    \end{itemize*}

    \paragraph{Physischer Entwurf}
    \begin{itemize*}
        \item Ergänzen des physischen Entwurfs um Zugriffsunterstützung
        \begin{itemize*}
            \item Zugriffspfad: Datenstruktur für zusätzlichen schlüsselbasierten Zugriff auf Tupel
            \item meist als B*-Baum realisiert
        \end{itemize*}
        \item Sprachmittel: Speicherstruktursprache SSL
    \end{itemize*}

    \paragraph{Implementierung \& Wartung}
    \begin{itemize*}
        \item Wartung; weitere Optimierung der physischen Ebene
        \item Anpassung an neue Anforderungen und Systemplattformen
        \item Portierung auf neue Datenbankmanagementsysteme...
    \end{itemize*}

    \subsection{Kapazitätsändernde Abbildungen}
    \begin{itemize*}
        \item Kap.\textbf{erhöhend}: Abbildung auf R mit genau einem Schlüssel
        \item Kap.\textbf{vermindernd}: Relationsschema mit einem Schlüssel
        \item Kap.\textbf{erhaltend}: mit Schlüssel beider Entity Typen im Relationsschema als neuer Schlüssel
    \end{itemize*}

    \subsection{ER-auf-RM Abbildung}
    \begin{itemize*}
        \item neues Relationenschema mit allen Attributen des Beziehungstyps, zusätzlich Übernahme aller Primärschlüssel der Entity-Typen
        \item Festlegung der Schlüssel:
        \begin{itemize*}
            \item m:n-Beziehung: beide Primärschlüssel zusammen werden Schlüssel
            \item 1:n-Beziehung: Primärschlüssel der n-Seite (Seite ohne Pfeilspitze) wird Schlüssel
            \item 1:1-Beziehung: beide Primärschlüssel werden je ein Schlüssel, der Primärschlüssel wird dann aus diesen Schlüsseln gewählt
        \end{itemize*}
        \item optionale Beziehungen $[0,1]$ o. $[0,n]$ werden nicht verschmolzen
        \item bei Kardinalitäten $[1,1]$ oder $[1,n]$ Verschmelzung möglich
        \begin{itemize*}
            \item $1:n$: Entity-Relationenschema der n-Seite integrieren
            \item $1:1$: beide Entity-Relationenschemata integrieren
        \end{itemize*}
    \end{itemize*}

    \subsection{Transformationseigenschaften}
    \begin{itemize*}
        \item Abhänggikeitstreue (T1)
        \begin{itemize*}
            \item Menge der Abhängigkeiten äquivalent zu der Menge der Schlüsselbedingungen im resultierenden Datenbankschema
            \item S charakterisiert vollständig F genau dann, wenn $F\equiv \{K\rightarrow R | (R,\bf{K})\in S, K\in\bf{K}\}$
        \end{itemize*}
        \item Verbundtreue (T2)
        \begin{itemize*}
            \item Originalrelationen können durch den Verbund der Basisrelationen wiedergewonnen werden
            \item nicht verbundtreu $F = \{A \rightarrow B, C \rightarrow B\}$
            \item verbundtreu $F" = \{A \rightarrow B, B \rightarrow C\}$
        \end{itemize*}
        \item Mehrwertige Abhängigkeit (MVD)
        \begin{itemize*}
            \item innerhalb einer Relation r wird einem Attributwert von X eine Menge von Y-Werten zugeordnet, unabhängig von den Werten der restlichen Attribute $\rightarrow$ Vierte Normalform
            \item Beseitigung von Redundanzen: keine zwei MVDs zwischen Attributen
            \item Elimination der rechten Seite einer der beiden mehrwertigen Abhängigkeiten,
            \item linke Seite mit dieser rechten Seite in neue Relation kopiert
        \end{itemize*}
        \item Verbundabhängigkeit (JD): R kann ohne Informationsverlust in $R_1,..., R_p$ aufgetrennt werden: $\bowtie [R_1,..., R_p]$
        \item Inklusionsabhängigkeit (IND): auf der rechten Seite einer Fremdschlüsselabhängigkeit nicht unbedingt der Primärschlüssel
    \end{itemize*}

    \paragraph{Ableitungsregel}
    \begin{itemize*}
        \item F1: Reflexivität $X\supseteq Y \Rightarrow X\rightarrow Y$
        \item F2: Augumentation $\{X\rightarrow Y\}\Rightarrow XZ\rightarrow YZ, \text{ sowie } XZ\rightarrow Y$
        \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
    \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*}

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

    \paragraph{Membership Problem} Kann eine bestimmte FD $X\rightarrow Y$ aus der vorgegebenen Menge F abgeleitet werden, d.h. wird sie von F impliziert? $X\rightarrow Y \in F^+$

    \paragraph{Reduktionsoperationen} Entfernen überflüssiger Attribute auf linker bzw. rechter Seite von FDs.

    \paragraph{Unwesentliche Attribute} A heißt unwesentlich in $X\rightarrow Y$ bzgl. F, wenn
    \begin{itemize*}
        \item A kann aus der FD $X\rightarrow Y$ entfernt werden, ohne dass sich die Hülle von F ändert
        \item FD $X\rightarrow Y$ heißt linksreduziert, wenn kein Attribut in X unwesentlich ist
        \item FD $X\rightarrow Y$ heißt rechtsreduziert, wenn kein Attribut in Y unwesentlich ist
    \end{itemize*}

    \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

    \subsection{Entwurfsverfahren}
    \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*}

    \section{Algebra \& Kalkül}
    \begin{description*}
        \item[Anfrage] Folge von Operationen, die aus Basisrelationen eine Ergebnisrelation berechnet
        \item[Sicht] Folge von Operationen, die unter Sichtnamen langfristig abgespeichert wird und unter diesem Namen wieder aufgerufen werden kann; ergibt eine Sichtrelation
        \item[Snapshot] Ergebnisrelation einer Anfrage, die unter Snapshot-Namen abgelegt wird, aber nie ein zweites Mal berechnet wird
    \end{description*}

    \paragraph{Kriterien für Anfragesprachen}
    \begin{description*}
        \item[Ad-Hoc-Formulierung] Benutzer soll eine Anfrage formulieren können, ohne ein vollständiges Programm schreiben zu müssen
        \item[Deskriptivität] Benutzer soll formulieren „Was will ich haben?“
        \item[Mengenorientiertheit] jede Operation soll auf Mengen von Daten gleichzeitig arbeiten
        \item[Abgeschlossenheit] Ergebnis ist wieder Relation und kann als Eingabe für nächste Anfrage verwendet werden
        \item[Adäquatheit] alle Konstrukte des zugrundeliegenden Datenmodells werden unterstützt
        \item[Orthogonalität] Sprachkonstrukte sind in ähnlichen Situationen auch ähnlich anwendbar
        \item[Optimierbarkeit] Sprache besteht aus wenigen Operationen, für die es Optimierungsregeln gibt
        \item[Effizienz] jede Operation ist effizient ausführbar (Komplexität max $\leq O(n^2)$)
        \item[Sicherheit] keine Anfrage, die syntaktisch korrekt ist, darf in eine Endlosschleife geraten oder ein unendliches Ergebnis liefern
        \item[Eingeschränktheit] Anfragesprache darf keine komplette Programmiersprache sein
        \item[Vollständigkeit] Sprache muss mindestens die Anfragen einer Standardsprache ausdrücken können
        \begin{description*}
            \item[Minimale Relationenalgebra] $\Omega = \pi,\sigma,\bowtie,\beta,\cup, -$
            \item[unabhängig] kein Operator kann weggelassen werden
            \item[Relationale Vollständigkeit] jede andere Menge von Operationen genauso mächtig wie $\Omega$
            \item[strenge relationale Vollständigkeit] zu jedem Ausdruck mit Operatoren aus $\Omega$ gibt es einen Ausdruck auch mit der anderen Menge von Operationen
        \end{description*}
    \end{description*}

    \paragraph{Verbundvarianten}
    \begin{itemize*}
        \item Gleichverbund: Gleichheitsbedingung über explizit angegebene und evtl. verschiedene Attribute $r(R) \bowtie_{C=D} r(S)$
        \item Theta-Verbund ($\Theta$-join): beliebige Verbundbedingung $r(R) \bowtie_{C>D} r(S)$
        \item Semi-Verbund: nur Attribute eines Operanden erscheinen im Ergebnis $r(L) \bowtie r(R) = \pi_L (r(L) \bowtie r(R))$
        \item äußere Verbunde (engl. outer join)
        \begin{itemize*}
            \item voller ä.V. übernimmt alle Tupel beider Operanden
            \item linker ä.V. übernimmt alle Tupel des linken Operanden
            \item rechter ä.V. übernimmt alle Tupel des rechten Operanden
        \end{itemize*}
    \end{itemize*}

    \subsection{Anfragekalküle}
    \begin{description*}
        \item[Kalkül] eine formale logische Sprache zur Formulierung von Aussagen
        \item[Ziel] Kalkül zur Formulierung von Datenbank-Anfragen
        \item[allgemeines Kalkül]
        \begin{itemize*}
            \item Anfrage hat die Form $\{f(\bar{x}) | p(\bar{x})\}$
            \begin{itemize*}
                \item x bezeichnet Menge von freien Variablen
                \item Funktion f bezeichnet Ergebnisfunktion über $\bar{x}$
                \item p Selektionsprädikat über freien Variablen $\bar{x}$
            \end{itemize*}
            \item Bestimme aller Belegungen der freien Variablen in x, für die das Prädikat p wahr wird.
        \end{itemize*}
        \item[Relationale Kalküle]
        \begin{itemize*}
            \item Bereichskalkül: Variablen nehmen Werte elementarer Datentypen (Bereiche) an
            \item Bereichskalkül ist streng relational vollständig, d.h. zu jedem Term $\tau$ der Relationenalgebra gibt es einen äquivalenten (sicheren) Ausdruck $\eta$ des Bereichskalküls.
            \item Atomare Formeln: $\{x_1,..., x_n \| \phi(x_1,..., x_n )\}$
        \end{itemize*}
        \item[Basiskalkül]
        \begin{itemize*}
            \item Einschränkung des Bereichskalküls: nur Konstanten, keine Funktionen
            \item Tupelkalkül: Variablen variieren über Tupelwerte
        \end{itemize*}
        \item[Semantisch sichere Anfragen] Anfragen, die für jeden Datenbankzustand $\sigma(R)$ ein endliches Ergebnis liefern
        \item[Syntaktisch sichere Anfragen] Anfragen, die syntaktischen Einschränkungen unterliegen, um die semantische Sicherheit zu erzwingen
    \end{description*}

    \paragraph{Transaktion, Integrität \& Trigger}
    \begin{description*}
        \item[Typintegrität] Angabe von Wertebereichen zu Attributen; Erlauben/Verbieten von Nullwerten
        \item[Schlüsselintegrität] Angabe eines Schlüssels für eine Relation
        \item[Referentielle Integrität] die Angabe von Fremdschlüsseln
        \item[Semantische Integrität] Korrekter (konsistenter) DB-Zustand nach Ende der Transaktion
        \item[Ablaufintegrität] Fehler durch "gleichzeitigen" Zugriff mehrerer Benutzer auf dieselben Daten vermeiden
    \end{description*}

    \paragraph{Transaktionen fordern ACID Eigenschaften}
    \begin{description*}
        \item[Atomicity] Transaktion wird entweder ganz oder gar nicht ausgeführt
        \item[Consistency] Datenbank ist vor Beginn und nach Beendigung einer Transaktion jeweils in einem konsistenten Zustand
        \item[Isolation] Nutzer, der mit einer Datenbank arbeitet, sollte den Eindruck haben, dass er mit dieser Datenbank alleine arbeitet
        \item[Durability] nach erfolgreichem Abschluss einer Transaktion muss das Ergebnis dieser Transaktion „dauerhaft“ in der Datenbank gespeichert werden
    \end{description*}

    Kommandos einer Transaktionssprache
    \begin{itemize*}
        \item Beginn einer Transaktion: Begin-of-Transaction-Kommando BOT
        \item commit: die Transaktion soll erfolgreich beendet werden
        \item abort: die Transaktion soll abgebrochen werden
    \end{itemize*}

    Probleme im Mehrbenutzerbetrieb
    \begin{description*}
        \item[Nonrepeatable Read] gleiche Leseanweisung führt zu nicht wiederholbaren Ergebnissen
        \item[Dirty read] rechnen mit Wert einer anderen Transaktion die abgebrochen wird
        \item[Phantom-Problem] liest Wert anderer Transaktion ohne zu erkennen, dass andere Transaktion noch nicht abgeschlossen
        \item[Lost Update] updates gehen verloren, wenn gleiche Variablen gleicheitig beschrieben werden (oder kurz nacheinander)
        \item[Deadlock] ein oder mehrere Transaktionen warten, einen LOCK auf Datenbankobjekte abzusetzen und behindern sich gegenseitig
        \item[Startvation] Warteschlange für gesperrte Objekte unfair abgearbeitet. Transaktion wartet endlos
    \end{description*}

    Isolationsebenen
    \begin{description*}
        \item[read uncommitted]
        \begin{itemize*}
            \item schwächste Stufe: Zugriff auf nicht geschriebene Daten, nur für read only Transaktionen
            \item statistische und ähnliche Transaktionen (ungefährer Überblick, nicht korrekte Werte)
            \item keine Sperren $\rightarrow$ effizient ausführbar, keine anderen Transaktionen werden behindert
        \end{itemize*}
        \item[read committed] nur Lesen endgültig geschriebener Werte, aber nonrepeatable read möglich
        \item[repeatable read] kein nonrepeatable read, aber Phantomproblem kann auftreten
        \item[serializable] garantierte Serialisierbarkeit
    \end{description*}

    \paragraph{Integritätsbedingungen in SQL}
    \begin{description*}
        \item[not null] Nullwerte verboten
        \item[default] Angabe von Default-Werten
        \item[check] (search-condition) festlegung lokaler Integritätsbedingungen innerhalb der zu definierenden Wertebereiche, Attribute und Relationenschemata
        \item[primary key] Angabe eines Primärschlüssel
        \item[foreign key] Angabe der referentiellen Integrität
        \item[create domain] Festlegung eines benutzerdefinierten Wertebereichs
    \end{description*}

    \paragraph{Erhaltung der referentiellen Integrität}
    \begin{description*}
        \item[on update $\mid$ delete] Angabe eines Auslöseereignisses, das die Überprüfung der Bedingung anstößt
        \item[cascade $\mid$ set null $\mid$ set default $\mid$ no action] Behandlung einiger Integritätsverletzungen pflanzt sich über mehrere Stufen fort
        \item[deferred $\mid$ immediate] legt Überprüfungszeitpunkt für eine Bedingung fest
        \item[deferred] Zurückstellen an das Ende der Transaktion
        \item[immediate] sofortige Prüfung bei jeder relevanten Datenbankänderung
    \end{description*}

    \section{Sichten und Zugriffskontrolle}
    \begin{itemize*}
        \item 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*}
    \end{itemize*}

    \subsection{Änderungen auf Sichten}
    Kriterien
    \begin{description*}
        \item[Effektkonformität] Benutzer sieht Effekt als wäre die Änderung auf der Sichtrelation direkt ausgeführt worden
        \item[Minimalität] Basisdatenbank sollte nur minimal geändert werden, um den erwähnten Effekt zu erhalten
        \item[Konsistenzerhaltung] Änderung einer Sicht darf zu keinen Integritätsverletzungen der Basisdatenbank führen
        \item[Datenschutz] Wird die Sicht aus Datenschutzgründen eingeführt, darf der bewusst ausgeblendete Teil der Basisdatenbank von Änderungen der Sicht nicht betroffen werden
    \end{description*}

    Klassifikation der Problembereiche
    \begin{itemize*}
        \item Verletzung der Schemadefinition
        \item Datenschutz: Seiteneffekte auf nicht-sichtbaren Teil der Datenbank vermeiden
        \item nicht immer eindeutige Transformation: Auswahlproblem
        \item Aggregierungssichten: keine sinnvolle Transformation möglich
        \item elementare Sichtänderung soll genau einer atomaren Änderung auf Basisrelation entsprechen: 1:1-Beziehung zwischen Sichttupeln und Tupeln der Basisrelation
    \end{itemize*}

    Einschränkungen für Sichtänderungen
    \begin{itemize*}
        \item änderbar nur Selektions- und Projektionssichten
        \item 1:1-Zuordnung von Sichttupeln zu Basistupeln: kein distinct in Projektionssichten
        \item Arithmetik und Aggregatfunktionen im select-Teil sind verboten
        \item genau eine Referenz auf einen Relationsnamen im from-Teil erlaubt
        \item keine Unteranfragen mit „Selbstbezug“ im where-Teil erlaubt
        \item group by und having verboten
    \end{itemize*}

    Statistische Datenbanken
    \begin{itemize*}
        \item Einzeleinträge unterliegen Datenschutz, aber statistische Informationen allen Benutzern zugänglich
        \begin{itemize*}
            \item keine Anfragen, die weniger als n Tupel selektieren
            \item statistische Anfragen nicht erlauben, die paarweise einen Durchschnitt von mehr als m vorgegebenen Tupeln betreffen
            \item Data Swapping: Vertauschen von Attributwerten einzelner Tupel
            \item Generalisierung: Attributwerte durch allgemeinere Werte ersetzen, die einer Generalisierungshierarchie entnommen sind (Alter 30-40, Weglassen von Stellen PLZ)
            \item Löschen von Tupeln, welche die k-Anonymität verletzen und damit identifizierbar sind
        \end{itemize*}
        \item k-Anonymität: ein bestimmter Sachverhalt kann nicht zwischen einer vorgegebenen Anzahl k von Tupeln unterschieden werden
    \end{itemize*}

    \subsection{Datenmodelle für NoSQL}
    \begin{description*}
        \item[KV-Stores] binäre Relationen, bestehend aus einem Zugriffsschlüssel (dem Key) und den Nutzdaten (dem Value)
        \begin{itemize*}
            \item binäre Daten ohne Einschränkung,
            \item Dateien oder Dokumente, $\rightarrow$ Document Databases
            \item oder schwachstrukturierte Tupel $\rightarrow$ Wide Column Store
        \end{itemize*}
        \item[Wide Column] KV-Store mit schwachstrukturiertem Tupel als Value = Liste von Attributname-Attributwert-Paaren
        \begin{itemize*}
            \item schwache Typisierung für Attributwerte (auch Wiederholgruppen)
            \item nicht alle Einträge haben die selben Attributnamen
            \item Hinzufügen eines neuen Attributs unproblematisch
            \item Nullwerte aus SQL ersetzt durch fehlende Einträge
        \end{itemize*}
        \item[Document Stores] KV-Store mit (hierarchisch) strukturiertem Dokument als Value
        \begin{itemize*}
            \item JSON-Format: geschachtelte Wide Column-Daten
            \item XML (eher unüblich auf KV-Stores)
        \end{itemize*}
        \item[Graph Stores] spezielle Form der Datenrepräsentation = Graphen, insb. Beziehungen zwischen Objekten
        \begin{description*}
            \item[Tiefensuche (DFS)] zunächst rekursiv alle Kindknoten besuchen bevor alle Geschwisterknoten besucht werden (Bestimmung der Zusammenhangskomponente)
            \item[Breitensuche (BFS)] zunächst alle Geschwisterknoten besuchen bevor die Kindknoten besucht werden (Bestimmung des kürzesten Weges)
        \end{description*}
        \item[Subjekt-Prädikat-Objekt-Modell: RDF]
        \begin{itemize*}
            \item Sprache zur Repräsentation von Informationen über (Web)-Ressourcen
            \item zentraler Bestandteil von Semantic Web, Linked (Open) Data
            \item Repräsentation von Daten, aber auch Wissensrepräsentation (z.B. Ontologie)
        \end{itemize*}
        \item[Property-Graph-Modell] Knoten und (gerichtete) Kanten mit Eigenschaften (Properties)
        \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
            \item Anfragen  $(e:ERZEUGER)-[:LiegtIn]->(a:ANBAUGEBIET \{gebiet: "Napa Valley"\} )$
            \item match: Beispielmuster für Matching
            \item return: Festlegung der Rückgabedaten (Projektion)
            \item where: Filterbedingung für „gematchte“ Daten
            \item create: Erzeugen von Knoten oder Beziehungen
            \item set: Ändern von Property-Werten
        \end{itemize*}
    \end{description*}

    Ontologie = formale Spezifikation einer Konzeptualisierung, d.h. einer Repräsentation von Begriffen (Konzepten) und deren Beziehungen

    Vokabular: vordefinierte Klassen und Eigenschaften

    \section{Anwendungsprogrammierung}

    \subsection{Programmiersprachenanbindung}
    \begin{itemize*}
        \item prozedurale oder CALL-Schnittstellen (call level interface)
        \item Einbettung einer DB-Sprache in Programmiersprachen
        \item Spracherweiterungen und neue Sprachentwicklungen
    \end{itemize*}

    Datenbankzugriffsschnittstelle
    \begin{description}
        \item[Java] JDBC
        \item[Embedded SQL für Java] SQLJ
        \item[LINQ] Language Integrated Query; Einbettung einer DB-Sprache in eine Programmiersprache (C\#)
        \item[Hibernate] Java-Framework für objekt-relationales Mapping
              \begin{itemize*}
                  \item DriverManager: Einstiegspunkt, Laden von Treibern
                  \item Connection: Datenbankverbindung
                  \item Statement: Ausführung von Anweisungen über eine Verbindung
                  \item ResultSet: verwaltet Ergebnisse einer Anfrage, Zugriff auf einzelne Spalten
              \end{itemize*}
    \end{description}

    \paragraph{Transaktionssteuerung}
    \begin{itemize*}
        \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*}


    \paragraph{Ausnahmebehandlung}
    \begin{itemize*}
        \item Auslösen einer Ausnahme (Condition) "signal ConditionName;"
        \item Deklarieren von Ausnahmen
    \end{itemize*}
    \begin{lstlisting}[
        language=SQL,
        showspaces=false,
        basicstyle=\ttfamily,
        commentstyle=\color{gray}
     ]
$declare fehlendes_weingut condition;
    declare ungueltige_region
    condition for sqlstate value "40123";$
    \end{lstlisting}

    \paragraph{Funktionen}
    \begin{lstlisting}[
        language=JAVA,
        showspaces=false,
        basicstyle=\ttfamily,
        commentstyle=\color{gray}
     ]
create function geschmack (rz int)
returns varchar(20)
    begin
        return case
            when rz <= 9 then "Trocken"
            when rz > 9 and rz <= 18 then "Halbtrocken"
            when rz > 18 and rz <= 45 then "Lieblich"
            else "Suess"
        end
    end
//Aufruf innerhalb einer Anfrage
select Name, Weingut, geschmack(Restzucker) from WEINE
    where Farbe = "Rot" and geschmack(Restzucker) = "Trocken"
    \end{lstlisting}

    \paragraph{Prozeduren}
    Prozedurdefinition
    \begin{lstlisting}[
        language=SQL,
        showspaces=false,
        basicstyle=\ttfamily,
        commentstyle=\color{gray}
     ]
create procedure weinliste (in erz varchar(30),
    out wliste varchar(500))
    begin
        declare pos integer default 0;
        for w as WeinCurs cursor for
            select Name from WEINE where Weingut = erz
            do xy
        end for;
    end; 
end;
// Nutzung ueber call-Anweisung
declare wliste varchar(500);
call weinliste ("Helena", wliste);
    \end{lstlisting}

    Eigenschaften von Prozeduren, die Anfrageausführung und -optimierung beeinflussen
    \begin{description*}
        \item[deterministic] Routine liefert für gleiche Parameter gleiche Ergebnisse
        \item[no sql] Routine enthält keine SQL-Anweisungen
        \item[contains sql] Routine enthält SQL-Anweisungen (Standard für SQL-Routinen)
        \item[reads sql data] Routine führt SQL-Anfragen (select-Anweisungen) aus
        \item[modifies sql data] Routine, die DML-Anweisungen (insert, update, delete) enthält
    \end{description*}

\end{multicols}

\newpage

\begin{centering}
    \section{Klausurvorbereitung}
\end{centering}

\begin{multicols*}{2}
    \section{Entity-Relationship-Diagramm}
    \includegraphics[width=\textwidth/5]{Assets/DB_ERD_01.png}
    \includegraphics[width=\textwidth/5]{Assets/DB_ERD_02.png}

    \section{relationale Algebra}
    \scriptsize{
        $\sigma_{\{Datum=14.12.2017\}} (PRUEFUNG) \bowtie (\pi_{\{Matrikel, Name\}} (STUDENT))$
    }

    \section{Bereichskalkül}
    Bereichskalkül: $KUNDE(x,y,z)$ vs. Tupelkalkül: $KUNDE(k)$

    Ein Ausdruck hat die Form:$\{x1, x2, ... | \phi(x1, x2, ...)\}$
    \vspace{3mm}

    Beispiel: Kunden mit Bestellung

    $KUNDE(kdnr, kname, adresse, ort)$ und $AUFTRAG(auftragsnr, kdnr, warennr, menge)$

    Kunden mit Bestellung: $\{x,y,z| KUNDE(x,y,z,\_) \wedge AUFTRAG(\_,x,\_,\_)\}$

    \section{SQL Anfrage}
    \begin{lstlisting}[
        language=SQL,
        showspaces=false
     ]
     SELECT Matrikel, Name FROM Student WHERE Matrikel>2010;
    \end{lstlisting}

    \section{Integrität}
    \begin{description}
        \item[Nutzerdefinierte Domäne] eines Attributs, d.h. bestimmte Werte
        \item[Primärschlüssel PRIMARY KEY] nicht null, existiert und ist unique
        \item[Fremdschlüssel FOREIGN KEY] wie primary key aus anderer tabelle
        \item[CHECK-Bedingungen] werte vor insert prüfen
        \item[ASSERTIONs] 
        \item[Trigger]
    \end{description}

    \section{CLOSURE-Algorithmus / RAP-Regeln}
    \begin{tabular}{c|c|l}
        R & Reflexivität & $\{\} \Rightarrow X\rightarrow X$ \\
        A & Akkumulation & $\{X\rightarrow YZ, Z\rightarrow AW\}\Rightarrow X\rightarrow YZA$\\
        P & Projektivität & $\{X\rightarrow YZ\}\Rightarrow X\rightarrow Y$
    \end{tabular}

    \section{Normalformen}
    \begin{description*}
        \item[1.NF] Wertebereiche der Merkmale sind atomar (es gibt keine zusammengesetzten Werte).
        \item[2.NF] 1. NF + Nichtschlüsselmerkmale sind von allen Schlüsselmerkmalen voll funktional abhängig.
        \item[3.NF] 2. NF + kein Nichtschlüsselmerkmal ist von irgendeinem Schlüssel transitiv abhängig.
        \item[Boyce Codd] 3.NF + entgernen funktionaler Abhängigkeiten 
        \item[4.NF] BC + Abhängigkeiten von mehrwertigen Attributmengen trivial und Attributmenge der Schlüsselkandidat
    \end{description*}


\section{Konsultation}
Mehrere theoretische Fragen? Nicht multiple choice wie in Moodle sondern zB Definitionen erklären (was ist Transaktion/Sicht?)

ERD->Relationenschema
 bei 1:N Beziehung kommt Schlüssel von N Seite
 bei M:N Beziehung kommen Schlüssel von beiden Seiten
 bei 1:1 Beziehung kann Schlüssel von entweder einer oder der anderen seite gewählt werden


\end{multicols*}

\end{document}