Nachbildung eines Gegenstandes, wesentliche Eigenschaften werden hervorgehoben, nebensächliche vernachlässigt $\Rightarrow$ zweckgerichtetes vereinfachtes Abbild der Wirklichkeit\\
hier: Abstraktion (=zweckgerichtete Vereinfachung durch Weglassen von Details) eines Realitätsausschnitts\\
Daten sind Folgen von Bits. Durch Interpretation erschließen sich Informationen.\\
Wertebereich& Attribut A eines Entity-Typs E mit Wertebereich V: $A: E\rightarrow P(V)$\\
& Attributwert eines Entities: $A(e)$\\
\end{tabular}
\begin{center}
\includegraphics[width=\linewidth]{ERModell}
\end{center}
\begin{defi}[Beziehungstyp]
Ein Beziehungstyp B zwischen $n$ Entity-Typen $E_1, ..., E_n$ definiert eine Menge von Bezihungen (Relationship-Menge oder Beziehungsmenge) zwischen Entities der beteiligten Entity-Typen:\\
$B\subseteq E_1\times E_2\times ... \times E_n$\\
\\
Beziehungstyp und Beziehungsmenge werden mit dem gleichen Namen bezeichnet.\\
Ein Entity kann an einer Beziehung teilnehmen, ein Entity-Typ an einem Beziehungstyp.\\
Eine Instanz eines Beziehungstyps zwischen n Entity-Typen $E_1, ..., E_n$ schließt von jedem beteiligten Entity-Typ genau ein Entity mit ein.
\end{defi}
Wichtig: es kann nicht mehrere Beziehungsinstanzen eines Beziehungstyps geben mit denselben Entities!
\begin{defi}[Beziehungsmenge (Extension)]
Darstellung als Tabelle: für jeden Entity-Typ eine Spalte, für jede Beziehungsinstanz eine Zeile.\\
Es kann nicht mehrere Beziehungsinstanzen eines Beziehungstyps geben mit denselben Entities!\\
\end{defi}
Funktionalität/Kardinalität von Beziehungstypen:\\
\textbf{Grad eines Beziehungstyps:} Anzahl der beteiligten Entity-Typen.\\
\textbf{Rekursive Beziehungstypen:} ein Entity-Typ kommt mehrfach in einem Beziehungstyp vor $\Rightarrow$ jedes Vorkommen bekommt einen eigenen Rollen-Namen.\\
\textbf{Totale Teilnahme:} Jedes Entity eines Entity-Typs, der über eine doppelte Linie an den Beziehungstyp geknüpft ist, muss an mind. einer Beziehungsinstanz dieses Typs teilnehmen.\\
\textbf{(min, max)-Notation:} Beschriftung (min, max) an einer Kante gibt an, an wie vielen Beziehungsinstanzen jedes Entity dieses Entity-Typs mindestens und höchstens teilnimmt.\\
\textbf{Schwache Entity-Typen:} Existenzabhängige Entities, keine Schlüsselattribute, werden über andere beteiligte Entites identifiziert.
hat immer totale Teilnahme an identifizierendem Beziehungstyp $\Rightarrow$ Doppellinie bei Raute. Beim starken Entity steht immer eine 1, beim schwachen kann eine 1 stehen. Nicht sinnvoll wenn mehrere identifizierende Entity-Typen oder wenn der schwache Entity-Typ mit weiteren Entity-Typen in Beziehung steht
\section{EER}
\begin{defi}[Klassen]
Eine Entity-Menge bezeichnet man auch als Klasse.\\
Oberklasse: Obermenge einer Klasse\\
Unterklasse: Teilmenge einer Klasse (angedeutetes $\subset$)\\
d für disjunkt, o für Overlapping
\end{defi}
Achtung: Element der Unterklasse repräsentiert dasselbe Realweltobjekt wie Element der Oberklasse\\
Entities in einer Unterklasse erben alle Attribute aus der Oberklasse, ebenso alle Beziehungen. \\
Ein Schlüssel der Oberklasse ist immer auch Schlüssel der Unterklassen. Unterklassen können gegebenenfalls weitere alternative Schlüssel (nur für die Unterklasse) ergänzen.
Fremdschlüssel:& Attribut, das mit einem Primärschlüsselwert einer (anderen) Tabelle auf ein \\
& bestimmtes Tupel dieser (anderen) Tabelle verweist
\end{tabular}
\\
\\
Visualisierung einer Relation als Tabelle.\\
Mengeneigenschaft: Es gibt nie zwei gleiche Zeilen in einer Tabelle. Die Reihenfolge der Tabellenzeilen ist unerheblich, ebenso die Reihenfolge der Spalten (R(A,B) ist äquivalent zu R(B,A)).\\
\begin{wic}[Mathematisches Konzept einer Relation]
Relationenschema einer Relation R: $R(A_1, A_2, A_3, ... , A_n)$\\
Attribute $A_i$ definieren die einzelnen Komponenten der Tupel. i-te Komponente eines Tupels entspricht dem Wert des Attributs $A_i$ in diesem Tupel (Attributwert).\\
Relation: Teilmenge des Kreuzprodukts der Wertebereiche der Attribute.\\
nur skalare Werte, keine Struktur, keine Mehrfachbelegung, Wertebereiche haben einen Datentyp\\
Wertebereiche unterstützen die Konsistenzsicherung, reduzieren die Vergleichbarkeit (nur Attribute mit denselben Wertebereichen sind vergleichbar).\\
\\
NULL besagt: kein Wert, Wert ist unbekannt, Existenz des Wertes ist unbekannt\\
Erweiterung der Attributdefinition: NULL erlaubt oder nicht erlaubt.\\
Schlüsselkandidaten dürfen nicht NULL werden.\\
\\
\begin{tabular}{@{}ll}
NOT NULL:& darf keine NULL-Werte enthalten\\
UNIQUE:& darf keine Duplikate enthalten (NULL erlaubt, wenn nicht explizit verboten)\\
PRIMARY KEY:& darf weder NULL-Werte noch Duplikate enthalten, pro Tabelle nur einer.
\end{tabular}
\begin{defi}[Primärschlüssel]
Tupel sollen bereits durch ein Attribut (ggf. Attributkombination) unterscheidbar sein, d.h. jedes Element aus dem Wertebereichs dieses Attributs erscheint höchstens einmal in einem Tupel der Relation.\\
Der Attributwert identifiziert eindeutig ein einzelnes Tupel, kein anderes Tupel mit gleichem Attributwert.\\
Ein Attribut, das zum Primärschlüssel erklärt wurde, muss UNIQUE NOT NULL sein (inhärente Konsistenzregel).\\
\\
Schlüsselkandidat:\\
keine 2 Tupel der Relation in K haben den gleichen Wert (Eindeutigkeit) und\\
keine Untermenge von K besitzt die Eindeutigkeitseigenschaft (Minimalität).\\
\\
Datenbanksystem gewährleistet Einhaltung der Regel: System-enforced integrity.\\
Verstoß wird mit Fehlermeldung abgewiesen, falsche Daten gelangen gar nicht in den Datenbestand.\\
Nachteil: keine Ausnahmen, mehr Sicherheit, aber weniger Flexibilität
\end{defi}
\subsection{Referenzielle Integrität}
In einem Fremdschlüsselattribut dürfen nur Werte vorkommen, die es im referenzierten Primärschlüsselattribut auch wirklich gibt (Beispiel für inhärente Konsistenzregel).
\begin{defi}[Fremdschlüssel]
Primärschlüssel einer Relation wird als Attribut in andere Relation ausgenommen (als logischer Zeiger).\\
Jeder Fremdschlüsselwert muss auch tatsächlich als Primärschlüsselwert vorkommen, kein Verweis darf ins Leere gehen (NULL ist ok, verweist ja auf nichts). \\
Fremdschlüssel muss dem DBMS explizit bekanntgemacht werden, sodass die Existenz des Primärschlüsselwerts bei Änderungen überprüft werden kann.
\end{defi}
\textbf{Sicherstellung der Referenzielen Integrität:}\\
Löschen eines referenzierten Primärschlüssels\\
$\rightarrow$ RESTRICTED - Ablehnen der Operation\\
$\rightarrow$ CASCADES - Alle referenzierenden Tupel werden auch gelöscht\\
$\rightarrow$ NULLIFY - Referenzen werden auf NULL gesetzt, sofern erlaubt\\
$\rightarrow$ SET DEFAULT (wenn ein Default definiert ist)\\
Ändern eines referenzierten Primärschlüssels:\\
$\rightarrow$ RESTRICTED - Ablehnen der Operation\\
$\rightarrow$ CASCADES -Alle referenzierenden Tupel werden auch modifiziert\\
Benutzerdefinierte oder globale Integritätsbedingen:\\
$\rightarrow$ Bedingungen aus der Anwendungsdomäne, die explizit formuliert werden müssen\\
$\rightarrow$ Bsp.: Prädikate auf den Attributen, Wertebereichseinschränkungen\\
$\rightarrow$ kontrolliert durch das DBMS (Operationen, die Integritätsbedingungen verletzen, werden abgelehnt)
\section{Abbildung des E/R-Modells auf das relationale Datenmodell}
\textbf{Schritt 1: reguläre Entity-Typen}\\
Erzeug eine Relation R, die alle einfachen Attribute von E umfasst. \\
Bei zusammengesetzten Attributen nur Komponenten als eigenständige Attribute übernehmen.\\
Wähle von den Schlüsselatt. einen Primärschlüssel von R (wenn zusammengesetzt: alle Komponenten). \\
Jedes Attribut, das im E/R-Diagramm als Schlüssel markiert ist, aber nicht ausgewählt wurde, wird als UNIQUE NOT NULL gekennzeichnet.\\
\\
\textbf{Schritt 2: schwache Entity-Typen}\\
Erzeug eine Relation R, die alle einfachen Attribute von W umfasst.\\
Füg als Fremdschlüsselattribute die Primärschlüsselattribute der Owner-Typen ein (ggf. mehrere Owner!).\\
Der Primärschlüssel der Relation R ist die Kombination aller Fremdschlüsselattribute, die auf die Owner verweisen, zusammen mit dem partiellen Schlüssel des schwachen Entity-Typs (sofern es den gibt).\\
Zur Sicherung der referenziellen Integrität wird bei schwachen Entity-Typen typischerweise die Option CASCADE gewählt (für ON UPDATE und ON DELETE).\\
\\
Es wird empfohlen, zunächst für jeden Beziehungstyp eine eigene Relation vorzusehen. Ob eine eigene Beziehungstabelle oder eine reduzierte Abbildung besser geeignet ist, hängt von der Semantik der Daten, der Dynamik der Anwendung und der relativen Anzahl der Beziehungen ab.
\newpage
\textbf{Schritt 3: M:N-Beziehungen}\\
Erzeug eine Relation R, die alle einfachen Attribute von B umfasst.\\
Füg als Fremdschlüsselattribute die Primärschlüsselattribute der beiden Relationen ein, die zu den an B beteiligten Entity-Typen gehören. Der Primärschlüssel ist die Kombination dieser Fremdschlüsselattribute.\\
Zur Sicherung der referenziellen Integrität wird bei Relationen, die eine N:M-Beziehung repräsentieren, typischerweise die Option CASCADE gewählt (für ON UPDATE und ON DELETE).\\
Auch 1:N- und 1:1-Beziehungstypen können grundsätzliche wie N:M-Beziehungstypen abgebildet werden. Vermeidung von NULL-Werten in Fremdschlüssel. Anderer Primärschlüssel!\\
\\
\textbf{Schritt 4: N:1-Beziehungen}\\
Für jeden regulären binären N : 1-Beziehungstyp B,
identifizier die Relation R, die dem Entity-Typ E auf der N-Seite des
Beziehungstyps entspricht (gem. Chen-Notation).\\
Füg den Primärschlüssel des anderen Entity-Typs als Fremdschlüssel in R ein.\\ (Wenn E totale Teilnahme an B: Fremdschlüssel auf NOT NULL)\\
Füg alle einfachen Attribute des Beziehungstyps B als Attribute in R ein.\\
\textbf{Alternative:} Eigene Relation mit 2 Fremdschlüsselattributen
zzgl. der Attribute des Beziehungstyps B. Das Fremdschlüsselattribut, das N-Seite repräsentiert: Primärschlüssel, das andere: NOT NULL.\\
\\
\textbf{Schritt 5: 1:1-Beziehungen}\\
Identifizier die zugehörigen Relationen R und S, die den beteiligten Entity-Typen entsprechen.\\
Wähl eine Relation aus - hier R - und nimm Primärschlüssel von S als Fremdschlüssel in R auf (UNIQUE). \\
Am besten geeignet für R ist ein Entity-Typ mit totaler Partizipation in B.\\
Füg alle einfachen Attribute des Beziehungstyps B als Attribute in R ein.\\
\textbf{Alternative:} Eigene Relation mit zwei Fremdschlüsselattr.
zzgl. der Attribute des Beziehungstyps B. \\
Ein Fremdschlüsselattribut: Primärschlüssel, anderes UNIQUE NOT NULL.\\
{\footnotesize Hinweis: bei 1:1-Beziehungen kann es unter Umständen möglich sein, die beiden beteiligten Relationen zu einer einzigen neuen Relation zu verschmelzen (bei totaler Partizipation auf beiden Seiten). Das logische Schema ist damit konzeptionell schwerer zugänglich. Besonders wenn beide zugrundeliegenden Entity-Typen konzeptionell eigenständig verschiedene Beziehungen eingehen, wird ein logisches Mapping unübersichtlich.\\
Vorteil: Performance - da später Verbundoperationen entfallen + weniger Relationen im Schema.}\\
\\
\textbf{Schritt 6: Mehrwertige Attribute}\\
Für jedes mehrwertige Attribut A eines Entity-Typs E erzeug eine Relation R.\\
R erhält die folgenden Attribute: \\
Attribut A, das dem abzubildenden Attribut A entspricht, und \\
den Primärschlüssel K der Relation S, die zu E gehört, als Fremschlüssel auf S. \\
Der Primärschlüssel der Relation R ist die Kombination von A und K.\\
Erzeug eine Relation R, die alle einfachen Attribute von B umfasst.\\
Füg als Fremdschl. Primärschlüssel aller Relat. ein, die zu den an B beteiligten Entity-Typen gehören.\\
Der Primärschlüssel der Relation R ist i.Allg. die Kombination all dieser Fremdschlüssel.\\
{\footnotesize Beachte: 1 Entity-Typ mit Kardinalität 1: zugehöriger Fremdschl. nicht im Primärschl. (NOT NULL)\\
Gibt es mehrere Entity-Typen mit Kardinalität 1: es wird einer ausgewählt, dessen Fremdschlüssel nicht mit in den Primärschlüssel aufgenommen wird (NOT NULL, Kombination aus weggelassenem und Kardinalität N UNIQUE)}\\
Überführe jede Spezialisierung mit m Unterklassen und Oberklasse C mit den Attributen in eine der folgenden 4 Varianten:\\
%bild folie 5-36 ca einfügen!
\textbf{8A:}\\
Erzeuge eine Relation $L$ für $C$ mit Attrs$(L)=\{k, a_1, ..., a_n\}$ und PK(L)=k. Erzeug eine Relation $L_i$ für jede Unterklasse $S_i, 1\leq i \leq m$, mit den Attributen Attrs$(L_i)=\{k\}\cup$\{Attribute von $S_i$\} und $PK(L_i)=k$. Funktioniert immer\\
\textbf{8B:}\\
Erzeuge eine Relation $L_i$ für jede Unterklasse $S_i, 1\leq i\leq m$, mit den Attributen Attrs$(L_i)=\{$Attribute von $S_i\}\cup\{k, a_1,..., a_n\}$ und $PK(L_i)=k$. Funktioniert nur bei totaler und disjunkter Spezialisierung\\
\textbf{8C:}\\
Erzeuge eine Relation $L$ mit den Attributen Attrs$(L)=\{k, a_1, ..., a_n\}\cup\{$Attribute $S_1\}\cup ...\cup\{$Attribute $S_m\}\cup\{t\}$ und $PK(L)=k$.\\
Gedacht für disjunkte Unterklassen. t ist diskriminierendes Attribut, das angibt, zu welcher Unterklasse ein Tupel gehört. Funktioniert nur bei disjunkter Spezialisierung. Achtung: NULL-Werte\\
\textbf{8D:}\\
Erzeuge eine Relation $L$ mit den Attributen Attrs$(L)=\{k, a_1, ..., a_n\}\cup\{$Attribute $S_1\}\cup ...\cup\{$Attribute $S_m\}\cup\{t_1, t_2, ..., t_m\}$ und $PK(L)=k$.\\
Gedacht für überlappende Unterklassen. $t_i$ ist ein Boolescher Wert, der anzeigt, ob ein Tupel zur Unterklasse $S_i$ gehört oder nicht. Funktioniert immer, disjunkte Spezialisierung erfordert jedoch logischen Ausdruck als Regel für den gegenseitigen Ausschluss.\\
\\
\textbf{Schritt 9: Kategorien}\\
Bilde für jede Kategorie K eine Relation R. Führe ein Surrogat s als Primärschlüssel von R ein. Füge s als Fremdschlüssel in alle Oberklassen ein.
\section{Normalisierung}
\textbf{Ursache für Anomalien:}\\
Information, die eig. zu versch. Entity-Typen gehört, wurde in einer Relation zusammengefasst.\\
\textbf{Einfüge-Anomalie:}\\
Information vom Typ B kann nicht eingefügt werden, ohne zuvor Information vom Typ A einzufügen.\\
\textbf{Lösch-Anomalie:}\\
durch Löschen von Information vom Typ A kann Information vom Typ B aus Datenbank entfernt werden.\\
\textbf{Änderungs-Anomalie:}\\
Änderungen an einem Attribut $B_i$ müssen ggf. in vielen Tupeln durchgeführt werden\\
\\
\textbf{Ziel der Normalisierung:}\\
- Vermeidung von Anomalien\\
- Reduzierung von Redundanz (Aufspaltung in möglichst redundanzfreie Relationen)\\
\begin{defi}[Funktionale Abhängigkeit]
Sei $R$ eine Relation $R(A_1, A_2, ..., A_n)$ mit $X\subset\{A_1, A_2, ..., A_n\}$ und $Y\subset\{A_1, A_2, ..., A_n\}$.\\
Y ist funktional abhängig von X ($X\rightarrow Y$, X bestimmt Y), wenn es keine zwei Tupel geben darf, in denen für gleiche X-Werte verschiedene Y-Werte auftreten.\\
X wird auch Determinante genannt.\\
\\
Y ist voll funktional abhängig von X, wenn es keine echte Teilmenge Z von X gibt, für die gilt $Z\rightarrow Y$. Alle Attribute in X werden gebraucht, um Y zu bestimmen.
\end{defi}
Regeln für Funkt. Abhängigkeit:\\
\begin{tabular}{@{}lll}
Reflexivität:& Aus $\beta\subseteq\alpha$& folgt $\alpha\rightarrow\beta$\\
Verstärkung: & Aus $\alpha\rightarrow\beta$& folgt $\alpha\gamma\rightarrow\beta\gamma$ für $\gamma\subseteq U$\\
Transitivität:& Aus $\alpha\rightarrow\beta$ und $\beta\rightarrow\gamma$& folgt $\alpha\rightarrow\gamma$\\
Vereinigung:& Aus $\alpha\rightarrow\beta$ und $\alpha\rightarrow\gamma$& folgt $\alpha\rightarrow\beta\gamma$\\
Dekomposition:& Aus $\alpha\rightarrow\beta\gamma$& folgt $\alpha\rightarrow\beta$ und $\alpha\rightarrow\gamma$\\
Pseudotransitivität:& Aus $\alpha\rightarrow\beta$ und $\beta\gamma\rightarrow\delta$& folgt $\alpha\gamma\rightarrow\delta$
\end{tabular}\\
\\
\\
\begin{tabular}{@{}ll}
Superschlüssel:&
Attribut(kombination), von der alle Attr. einer Relation funktional abhängen\\
Schlüsselkandidat:&
min. Superschlüssel: keine Teilmenge ist ebenfalls Superschlüssel.\\
Schlüsselattribut:&
Attribut, das Teil eines Schlüsselkandidaten ist.\\
Nicht-Schlüsselattribut:& Attribut, das an keinem Schlüsselkandidaten beteiligt ist.
\end{tabular}\\
\\
\\
\textbf{Normalformen...}\\
...sind definiert auf der Basis von Funktionalen Abhängigkeiten\\
...vermeiden Anomalien\\
...bauen aufeinander auf, dh. die (i+1)-te NF setzt die i-te NF voraus\\
Vorgang der Überführung eines Relationenschemas R in höhere Normalformen durch Aufspaltung in Schemata $R_1, R_2,...,R_n$\\
Verlustlosigkeit: \\
- Informationen aus R müssen aus den Tupeln der neuen Relationen $R_1, R_2,...,R_n$ rekonstruierbar sein.\\
Abhängigkeitserhaltung: \\
- die für R geltenden Funktionalen Abhängigkeiten müssen auch für die Schemata $R_1, R_2,...,R_n$ gelten.
\end{defi}
\begin{defi}[Erste Normalform (1NF)]
Eine Relation ist in erster Normalform, wenn sie nur atomare Attributwerte besitzt.\\
Allgemein gilt:\\
- Es gibt keine zwei gleichen Tupel, die Reihenfolge der Tupel ist unerheblich\\
- Jeder Attributwert ist atomar und gehört zum Wertebereich des Attributs\\
- Jedes Attribut hat einen eindeutigen Namen, die Reihenfolge der Attribute ist unerheblich
\end{defi}
\begin{defi}[Zweite Normalform (2NF)]
Alle Nicht-Schlüsselattribute hängen voll funktional von jedem Schlüsselkandidaten ab.\\
Ziel: Eliminierung partieller Abhängigkeiten der Form R(A, B, C, D), AB $\rightarrow$ C, B $\rightarrow$ D\\
\\
Aufspaltung in mehrere Relationen: \\
für jede Determinante einer FA, die ein Nicht-Schlüsselattribut bestimmt und Teil eines Schlüsselkandidaten ist, leg eine neue Relation an.\\
\\
Aus R(A, B, C, D), AB $\rightarrow$ C, B $\rightarrow$ D, mache R1(A, B, C) und R2(B, D)
\end{defi}
\begin{defi}[Dritte Normalform (3NF)]
Kein Nicht-Schlüsselattribut ist transitiv abhängig von einem Schlüsselkandidaten. \\
\\
Aufspaltung in mehrere Relationen:\\
Für jede Determinante einer FA, die ein Nicht-Schlüsselattribut bestimmt und nicht Teil eines Schlüsselkandidaten ist, leg eine neue Relation an.
\end{defi}
Synthesealgorithmus:\\
Vorraussetzung: die Menge der Funktionalen Abhängigkeiten in R ist bekannt.\\
Schritt 1: bestimme die kanonische Überdeckung $F_C$ für F. Das heißt, dass jede FA, die aus F ableitbar \\
\hspace*{19mm}ist, auch aus $F_C$ ableitbar. Überflüssige Attribute sind entfernt. \\
Schritt 2: Erzeuge aus jeder FA in $F_C$ eine eigene Relation. (aus A $\rightarrow$ BC erzeug R1(\underline{A}, B, C))\\
Schritt 3: Falls ein Schlüssel aus R in einer FA in $F_C$ ist: fertig\\
\hspace*{19mm}Sonst: Erzege Schema zur Verknüfung der übrigen Teilschemata\\
\hspace*{19mm}z.B. wenn ABC Schlüssel in R und in keiner Relation enthalten ist,
erzeug R (A, B, C).\\
Schritt 4: Entferne überflüssige Teilschemata\\
\hspace*{19mm}z.B. falls R1 (A, B, C, D) und R2 (B, C) erzeugt wurden,
kann R2 entfernt werden.
\begin{defi}[Boyce-Codd Normalform]
Jede Determinante einer FA ist ein Superschlüssel.\\
Algorithmus: Liste alle Funktionalen Abhängigkeiten auf. Erzeuge für jede FA, deren Determinante kein Superschlüssel ist, eine neue Relation.
\end{defi}
\textbf{Mehrwertige Abhängigkeit:}\\
Ein Attribut ist mehrwertig abhängig von einem Attribut A, wenn durch den Wert von A eine Menge von Werten in B bestimmt wird.\\
Eine mehrwertige Abhängigkeit $A\rightarrow\rightarrow B$ ist nicht trivial, wenn B nicht in A enthalten ist und außer A und B noch mehr Attribute in R enthalten sind.
\begin{defi}[Vierte Normalform (4NF)]
Für jede nicht-triviale mehrwertige Abhängigkeit $X\rightarrow\rightarrow A$ in R gilt: X ist Superschlüssel von R.\\
\textbf{Wann ist eine Relation nicht in 4NF?}\\
Drei Kriterien:\\
- Die Relation muss mind. drei Attribute haben.\\
- A bestimmt mehrere Werte von B und mehrere Werte von C\\
- B und C sind unabhängig voneinander. \\
Auflösung der Redundanz: Jedes mehrwertig abhängige Attribut in eine eigene Relation extrahieren.
\end{defi}
Gezielte Denormalisierung: \\
Betrachte die folgende Relation:\\
- Personal (PersID, Name, Vorname, Ort, PLZ, Bundesland)\\
Die Relation ist nicht in 3NF, wegen PLZ $\rightarrow$ Ort, Bundesland\\
Diese Aufspaltung kostet Zugriffszeit! Um eine vollständige Adresse zu bekommen, muss jedes Mal in zwei
Relationen nachgesehen werden.\\
$\Rightarrow$ gezielte Denormalisierung ist ggf. sinnvoll. Sollte gut dokumentiert werden wg. Redundanz.
\section{Relationenalgebra}
Relation = Menge von Tupeln\\
Datenmodell erfordert auch Operationen auf diesen Daten\\
\begin{defi}[Relationenalgebra]
Menge von elementaren Operationen auf Relationen\\
\begin{tabular}{@{}ll}
Abgeschlossenheit:& Ergebnis einer Operation ist wieder eine Relation\\
Unäre Operationen:& auf einer Relation definiert\\
Binäre Operationen:& auf zwei Reltaionen definiert
\end{tabular}
\end{defi}
Relationen sind Mengen, d.h. die üblichen Mengenoperationen Vereinigung (union), Durchschnitt (intersection) und Differenz (difference) sind anwendbar - mit folgender Einschränkung: \\
Die Relationen müssen vereinigungsverträglich sein, d.h. gleiche Zahl von Attributen, übereinstimmende Wertebereiche. Die Ergebnisrelation verwendet Attributnamen des ersten Operanden.\\
\\
Vereinigung: $union(R,S)=\{r|r\in R \vee r\in S\}$\\
Durchschnitt: $intersection (R,S)=\{r|r\in R \wedge r\in S\}$\\
Kreuzprodukt: $crossproduct (R,S)=\{concat(r,s)| r\in R \wedge s\in S\}$
\begin{defi}[Selektion (Restriktion)]
$R (A_1, A_2, ... , A_n)$ Relation\\
$P (A_1, A_2, ... , A_n)$ Prädikat über den Attributen von R:\\
hat für ein konkretes Tupel entweder den Wert wahr oder falsch\\
$select[P(A_1, A_2, ... , A_n)](R)$\\
Prädikat P darf nur solche Operationen (insbesondere Vergleiche) auf Attribute anwenden, die mit den Wertebereichen verträglich sind
\end{defi}
\begin{defi}[Projektion]
$R (A_1, A_2, ... , A_n)$ Relation\\
$A=\{A_1, A_2, ... , A_n\}$ Menge der Attribute von R und $B=(A_{i1}, A_{i2}, ... , A_{ik})$ eine Folge von Attributen aus A (meistens verschieden, aber nicht notwendig)\\
Für $r=(a_1, a_2, ... , a_n)\in R$ sei $project[B](r)=(a_{i1}, a_{i2}, ... , a_{ik})$\\
$project[B](R)={project[B](r)| r\in R}$\\
Es gilt: $|project [B](R)| \leq |R|$ (Eliminierung von Duplikaten)\\
project [Wohnort] (Angestellte) ermittelt Wohnorte, in denen ein oder mehrere Angestellte wohnen.
Formale Definition, in Realisierung eine der beiden Relationen durchlaufen und zu jedem Tupel passende Verbund-Partner in der anderen Relation suchen.\\
\\
Natürlicher Verbund:\\
$W(A_i)=W(B_i)$, d.h. beide haben gleichen Wertebereich\\
Es werden immer alle gleichnamigen Attribute verknüpft.\\
Jedes Tupel r aus R wird mit all den Tupeln aus S verknüpft (konkateniert), die in $B_j$ gleichen Wert enthalten wie r in $A_i$.\\
\\
Verbund mit sich selbst (Auto-Join):\\
Bei Verbund einer Relation mit sich selbst muss man ihr Aliasnamen geben, damit man ersten und zweiten Operanden auseinanderhalten kann.
\end{defi}
\begin{defi}[Division]
$R_1(A_1, …, A_n, B_1, …, B_m)$ und $R_2(B_1, …, B_m)$ Relationen. Die Attribute des Divisors $R_2$ sind eine Teilmenge der Attribute des Dividenden $R_1$.\\
$divide (R1, R2)=\{ t | t = project [A_1, …, A_n](r_1)\wedge r_1\in R_1\wedge\forall r_2\in R_2: concat (t, r_2)\in R_1\}$\\
Das Ergebnis enthält die Attribute des Dividenden $R_1$, die nicht im Divisor $R_2$ vorkommen, also $A_1, …, A_n$.\\
Divison ist inverse Operation zum kartesischen Produkt.
\end{defi}
\section{SQL, Structured Query Language}
\textbf{Typen von Datenbanksprachen:}\\
1. prozedurale Datenbanksprachen: \\
tupel- oder satzorientiert, Programmierer denkt in Satzfolgen, Navigation über Zugriffspfade durch die vorhandenen Daten. Wird spezifiziert, WIE das DBS etwas zu suchen hat.\\
2. deskriptive Datenbanksprachen: \\
mengenorientiert (typisch für Relationenmodell), Programmierer denkt in Mengen von Sätzen (mit bestimmten Eigenschaften), Zugriff über inhaltliche Kriterien, Selektieren und Kombinieren. Wird spezifiziert, WAS das DBS zu suchen hat.\\
\\
Erfordernisse einer vollständigen DB-Sprache:\\
- Abfrage von Daten\\
- Änderungsdienst (Einfügen, Lösche, Modifizieren einer Menge von Tupeln)\\
- Datendefinition (Wertebereiche, Attribute und Relationen)\\
- Definition von Sichten\\
- Datenkontrolle (Integritätsbedingungen)\\
- Zugriffskontrolle im Sinne des Datenschutzes\\
- Kopplung mit einer Wirtssprache (Nutzung der Datenbank vom Programm aus)
\\
\\
Elementare Datentypen (Auszug)\\
INT, SHORTINT, FLOAT, DECIMAL, CHAR(n), BIT(n), VARCHAR(n), BIT VARYING(n), DATE, TIME, NULL (steht für unbekannte Werte oder die Information nicht zutreffend)\\
\\
SQL-Anfrage-Skelett:\\
\begin{tabular}{@{}ll}
SELECT&$<$was?$>$\\
FROM&$<$woher?$>$\\
WHERE&$<$mit welchen Eigenschaften?$>$\\
GROUP BY &\\
HAVING &\\
ORDER BY
\end{tabular}\\
\\
\\
\textbf{SELECT - Klausel:}\\
Projektion: Auswahl von einzelnen Attributen (Spalten) in der SELECT-Klausel (alles auswählen: *)\\
Duplikateliminierung kann durch DISTINCT erzwungen werden\\
Neue Spalten: SELECT MNR,(Gehalt * 1.1) AS Gehaltsprognose\\
Ziel: gemeinsames Vokabular für verschiedene XML-Dokumente\\
weltweit eindeutiger Schlüssel, innerhalb des Dokuments wird ein Kürzel definiert.\\
Kürzel wird als Präfix verwendet, um Namen einem Namensraum zuzuordnen: Kürzel:Name\\
Weder Name noch Präfix dürfen Doppelpunkt enthalten
\end{defi}
\begin{defi}[Entity]
Separate Dateneinheit, innerhalb eines Dokuments kann auf ein Entity verwiesen werden. Bei der Verarbeitung werden Entities vor der Validierung aufgelöst.\\
"ParsedEntity": XML-Fragment\\
- Intern: In der DTD definiert\\
- Extern: In einer anderen Datei definiert\\
"UnparsedEntity": andere Daten (z.B. Bilder)\\
- Wert eines Attributs vom Typ ENTITY oder ENTITIES\\
- Verweis auf externe Datei (z.B. eine URL)\\
Vordefinierte Entities: Bestimmte Zeichen haben def. Bedeutung in XML, deshalb vordef. Entities:\\
\begin{tabular}{ccccc}
\< &\> &\& &\&apos &\"\\
$<$&$>$&\&& ' & "
\end{tabular}\\
\\
Verweis auf Entities: \&Entityname\\
Verweis auf Elemente: das zu referenzierende Element muss Attribut des Typs ID haben. Auf ID kann in Attribut des Typs IDREF verwiesen werden. Funktioniert nur innerhalb eines Dokuments.
\end{defi}
\subsection{XPath}
XML-Dokumente werden als Bäume interpretiert\\
Knotentypen:\\
- Wurzelknoten: wird zusätzlich erzeugt\\
- Elementknoten: für jedes Element, kann ID besitzen\\
- Funktionen, dargestellt als Ovale mit Funktionsname\\
- Beziehungen zw. Funktionen\\
- Akteure (benutzen Funktionen), dargestellt als Strichmännchen\\
\\
\textbf{Beziehungstypen zw. Anwendungsfällen:}\\
1. $<<$include$>>$, auch: $<<$benutzt$>>$\\
Eine Teilfunktion (Use Case) wird in mehreren anderen Funktionen (Use Cases) wiederverwendet. \\
Funktionale Dekomposition\\
2. $<<$extend$>>$, auch: $<<$erweitert$>>$\\
Variation des normalen Verhaltens, Behandlung von Ausnahmefällen\\
Pfeil in Sprechrichtung: "Benutzergruppen verwalten erweitert Benutzer verwalten"\\
Vorgehen: normalen Anwendungsfall beschreiben, was kann schiefgehen, skizzier alle Variationen des Anwendungsfalls und ordne jeder Variation eine Bedingung zu \\
\\
Abstrakter Anwendungsfall: nicht ausführbar, Wiederverwendbarkeit eines gemeinsamen Verhaltens\\
\includegraphics[width=0.7\linewidth]{usecase}
\subsection{Aktivitätsdiagramm}
\textbf{Ziele:}\\
- Kontroll- und Datenfluss zwischen verschiedenen Aktionen\\
- Modellierung objektorientierter und nicht-objektorientierter Systeme\\
- in UML2: Modellierung von Geschäftsprozessen\\
\\
\textbf{Zentraler Begriff: Aktivität}\\
- Eine von Mensch oder Maschine auszuführende Aufgabe\\
- Aufruf einer Methode oder Arbeitsschritte im Ablauf eines Anwendungsfalls (Use Case)\\
- UML2: Aktivitäten können geschachtelt sein\\
- Atomare Bestandteile von Aktivitäten sind Aktionen\\
- Inhalt einer Aktivität: gerichteter Graph mit Aktivitätsknoten und Aktivitätskanten\\
untschiedl. Sprechw.)& Teilsynonyme (Begriffe stimmen in wesentlichen Bereichen überein)\\\hline
\end{tabular}\\
\\
Terminologische Kontrolle: Alle Maßnahmen,die direkt oder indirekt der Definition und Abgrenzung der Begriffe und der Zuordnung von Benennungen und Begriffen dienen\\
