mirror of
https://gitlab.cs.fau.de/ik15ydit/latexandmore.git
synced 2024-11-22 19:59:31 +01:00
1249 lines
68 KiB
TeX
1249 lines
68 KiB
TeX
\documentclass[12pt,a4paper]{article}
|
||
\usepackage[utf8]{inputenc}
|
||
\usepackage{amsmath}
|
||
\usepackage{amsfonts}
|
||
\usepackage{amssymb}
|
||
\usepackage{graphicx}
|
||
\parindent0pt
|
||
\usepackage{thmbox}
|
||
%\usepackage{picins}
|
||
\usepackage[left=1.00cm, right=1.00cm, top=1.00cm, bottom=1.0cm]{geometry}
|
||
\pagestyle{empty}
|
||
\begin{document}
|
||
\newtheorem[S,bodystyle=\normalfont]{defi}{Definition}
|
||
\newtheorem[S,bodystyle=\normalfont]{satz}{Satz}
|
||
\newtheorem[S,bodystyle=\normalfont]{bew}{Beweis}
|
||
\renewcommand{\thedefi}{\hspace{-0.5em}}
|
||
\renewcommand{\thesatz}{\hspace{-0.5em}}
|
||
\renewcommand{\thebew}{\hspace{-0.5em}}
|
||
\newtheorem[S,bodystyle=\normalfont]{wic}{Wichtig!}
|
||
\renewcommand{\thewic}{\hspace{-0.5em}}
|
||
\newtheorem[S,bodystyle=\normalfont]{lol}{}
|
||
\renewcommand{\thelol}{\hspace{-0.5em}}
|
||
\date{Wintersemester 2016/2017}
|
||
\title{Zusammenfassung KonzMod}
|
||
\author{Eva Dengler}
|
||
\maketitle
|
||
\subsubsection*{Maintaining:}
|
||
Diese Zusammenfassung wird auf \textit{https://gitlab.cs.fau.de/ik15ydit/latexandmore/} maintain't.\\
|
||
\textbf{Generated by texlive: \today}
|
||
|
||
\section{Einführung}
|
||
\begin{defi}[Modell]
|
||
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.\\
|
||
\\
|
||
Zweck von Modellen: \\
|
||
- Spezifizieren\\
|
||
- Konstruieren\\
|
||
- Visualisieren\\
|
||
- Dokumentieren \ \ \ \ \ ...von Software-Systemen
|
||
\end{defi}
|
||
\section{Datenbanken}
|
||
\begin{defi}[Datenbank]
|
||
"A database is a collection of related data", "One fact in one place"\\
|
||
Sammlung zusammenhängender Daten, anwendungs-unabhängig\\
|
||
repräsentiert einen Ausschnitt der realen Welt und hat einen definierten Zweck\\
|
||
\\
|
||
Vorteile:\\
|
||
- Vermeidung redundanter Daten (keine untersch. Änderungsstände, Vermeidung von Inkonsistenzen) \\
|
||
- Zentrale Kontrolle der Datenintegrität (logische/physische Datenintegrität)\\
|
||
- Synchronisation im Mehrbenutzerbetrieb\\
|
||
- Fehlertoleranz (z.B. wenn Fehler auftreten)\\
|
||
- Performanz, Erweiterbarkeit, Flexibilität\\
|
||
\\
|
||
Nachteile:\\
|
||
- hohe initiale Kosten, erfordert Rechenleistung\\
|
||
- DBMS (Datenbankmanagement-System) muss erst konfiguriert werden
|
||
\end{defi}
|
||
\includegraphics[width=0.25\linewidth]{dbgrundlage}\\
|
||
\\
|
||
\begin{tabular}{@{}ll}
|
||
Datenbank-Management-System (DBMS) & Erzeugung, Wartung und konsistenter Zugriff auf DB\\
|
||
& koordinierter Zugriff auf DB\\
|
||
Datenbanksystem (DBS)& DB + DBMS\\
|
||
Datenbankanwendung& DB + DBMS + Anwendungsprogramme\\
|
||
Datenmodell& Strukturierungsvorschrift für Daten\\
|
||
Datenbankschema& Beschreibung einer konkreten Datenbank\\
|
||
&\\
|
||
Nutzdaten& eigentliche Datenbank\\
|
||
Metadaten& Beschreibungsdaten (Struktur, Speicherung)
|
||
\end{tabular}
|
||
\begin{defi}[Drei Arten von Schemata]
|
||
- Konzeptionell: beschreibt Daten auf logischer Ebene (Datenunabhängigkeit, Anwendungsneutralität)\\
|
||
- Extern: beschreibt Ausschnitt einer Datenbank (Anwendung) auf log. Ebene, anwendungsspez. Sichten\\
|
||
- Intern: beschreibt interne Speicherungsstrukturen (Zugriffspfade, Speicherungsstrukturen)
|
||
\end{defi}
|
||
Datenunabhängigkeit der Anwendung:\\
|
||
Benutzung der Daten ohne Bezug auf Details der Speicherung, nur logische Sicht auf die Daten\\
|
||
\\
|
||
Anwendungsneutralität der Datenbank:\\
|
||
Strukturen nicht nur für die eine erste Anwendung, sondern so, dass auch andere Zugriffe möglich sind (Wiederverwendung)
|
||
\subsection{Wie komme ich zum konzeptionellen Datenbankschema?}
|
||
Verwendung von Zwischensprachen: \\
|
||
Methoden zur genauen Beschreibung der Miniwelt $\Leftrightarrow$ möglichst einfach zu verstehen\\
|
||
\\
|
||
Vorgehensweise: \\
|
||
Miniwelt $\Rightarrow$ Abbildung auf semantisches Datenmodell (E/R-Modell)$\Rightarrow$ Datenmodell (relationales DM)\\
|
||
oder\\
|
||
Miniwelt $\rightarrow$ Anforderungsanalyse $\rightarrow$ Datenbankanforderungen $\rightarrow$ Konzeptioneller Entwurf $\rightarrow$ Konzeptionelles Schema $\rightarrow$ Logischer Entwurf $\rightarrow$ Logisches Schema $\rightarrow$ Physischer Entwurf $\rightarrow$ Internes Schema\\
|
||
\\
|
||
Konzeptioneller Entwurf:\\
|
||
Erzeugen des DBS, Beschreibung der Anforderungen, Integritätsbedingungen\\
|
||
keine Implementierungsdetails\\
|
||
\section{Entity/Relationship-Modell}
|
||
\begin{tabular}{@{}ll}
|
||
Entity:& zu beschreibendes Objekt\\
|
||
& eigenständige Existenz, identifizierbar, beschreibbar, relevant\\
|
||
Entity-Typ:& Beschreibung gleichartiger Objekte (Intension)\\
|
||
Attribut:& Eigenschaft/Merkmal von Objekten eines Entity-Typs\\
|
||
& Zusammengesetzte, mehrwertige, abgeleitete oder komplexe Attribute\\
|
||
& Notation: (..., ..., ...) zusammengesetzt, \{...\} mehrwertig\\
|
||
Schüsselattribut:& Attributkombination, die ein Entity identifiziert (dh. es gibt keine Duplikate)\\
|
||
& manchmal zusammengesetztes Schlüsselattribut\\
|
||
Entity-Menge:& Menge gleichartiger Objekte (Extension)\\
|
||
&\\
|
||
Relationship:& Beziehung zw. 2 oder mehr Objekten, Existenzabhängigkeit\\
|
||
Relationship-Typ:& Beschreibung gleichartiger Beziehungen\\
|
||
& können auch Attribute haben (keine Schlüsselattribute!)\\
|
||
Relationship-Menge:& Menge gleichartiger Beziehungen\\
|
||
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:\\
|
||
\includegraphics[width=0.5\linewidth]{kardinalitaet}\\
|
||
\\
|
||
\includegraphics[width=0.6\linewidth]{er1}\\
|
||
\\
|
||
\includegraphics[width=0.65\linewidth]{er2}\\
|
||
\\
|
||
\includegraphics[width=0.65\linewidth]{er3}\\
|
||
\includegraphics[width=0.6\linewidth]{er4}\\
|
||
\\
|
||
\includegraphics[width=0.65\linewidth]{er5}\\
|
||
\\
|
||
\includegraphics[width=0.6\linewidth]{er6}\\
|
||
\\
|
||
\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.
|
||
\begin{center}
|
||
\includegraphics[width=0.48\linewidth]{variation}\ \ \ \ \includegraphics[width=0.48\linewidth]{variation2}
|
||
\end{center}
|
||
\begin{tabular}{@{}ll}
|
||
Spezialisierung:& Definition der Unterklassen ausgehend von einer Oberklasse\\
|
||
Generalisierung:& Definition von Oberklassen ausgehend von einer Unterklasse\\
|
||
Hierarchie:& jede Unterklasse hat genau eine Oberklasse\\
|
||
Netz:& eine Unterklasse kann mehrere Oberklassen haben\\
|
||
\end{tabular}
|
||
\begin{defi}[Kategorie]
|
||
Eine Kategorie ist eine Teilmenge der Vereinigungsmenge von mehreren Entitymengen.
|
||
\end{defi}
|
||
Partielle Kategorie: es kann Personen und/oder Firmen geben, die nicht Besitzer sind.\\
|
||
Totale Kategorie: es kann keine PKWs oder LKWs geben, die nicht Fahrzeuge sind.
|
||
\subsection{Notationen}
|
||
Schlüsselattribute:\\
|
||
Elmasri/Navathe: es können mehrere alternative Schlüssel angegeben werden\\
|
||
Kemper/Eickler: nur ein Schlüssel wird ausgewählt (alles unterstrichene)\\
|
||
Heuer/Saake: Kanten zu Attributen werden durch Querbalken verbunden\\
|
||
\\
|
||
Krähenfuß-Notation: \\
|
||
in Analogie zur Chen-Notation: Krähenfuß = N, kein Krähenfuß = 1\\
|
||
\includegraphics[width=\linewidth]{kraehe}\\
|
||
\\
|
||
Pfeil-Notation:\\
|
||
Pfeilspitze entspricht einer 1 in Chen-Notation\\
|
||
\includegraphics[width=\linewidth]{pfeilnotation}
|
||
\section{Relationenmodell}
|
||
Achtung! Relationenmodell ungleich ER! Teilweise gleiche Begriffe, die aber nicht dasselbe meinen!\\
|
||
Gründe für ein Datenmodell: Sprache für die Beschreibung von Daten in einem Schema.\\
|
||
Merke: Das Datenmodell ist für ein bestimmtes DBMS fest.\\
|
||
\begin{defi}[Generischer Systementwurf]
|
||
erzwingt ein formales Rahmenwerk (Datenmodell, legt Bedeutung des Schemas fest) für die Beschreibung der Miniwelt.\\
|
||
Schema: Ergebnis der Datendefinition. Beschreibt die Daten.\\
|
||
Daten: Beschreibung von Gegenstand oder Ereignis aus der realen Welt.
|
||
\end{defi}
|
||
Bestandteile eines Datenmodells:\\
|
||
einfache Datentypen und Konstruktoren für zusammengesetzte Datentypen\\
|
||
Konsistenzregeln: ermöglichen Einschränkungen hinsichtlich der Zulässigkeit von Daten.\\
|
||
$\rightarrow$ inhärente Konsistenzregeln: gelten für ein Datenmodell per Konvention.\\
|
||
$\rightarrow$ explizite Konsistenzregeln: werden für eine Anwendung im Zuge der Datendefinition festgelegt.\\
|
||
Benennungskonventionen für die Bezeichnung von Datenbankelementen
|
||
\begin{defi}[Relationenmodell]
|
||
Ziel: Abfrage der Daten über inhaltliche Kriterien, nicht über Speicherungsstrukturen.\\
|
||
Annahme: Einheitliche logische Datenstruktur für alle Daten\\
|
||
Datenbank: alle Daten werden in Tabellen abgelegt mit Zeilen und Spalten.\\
|
||
Tabelle wird als Relation bezeichnet.\\
|
||
Relationale Datenbank = Menge von Relationen
|
||
\end{defi}
|
||
Konzept der Relation:\\
|
||
\includegraphics[width=0.53\linewidth]{kapitel4}\\
|
||
\\
|
||
\begin{tabular}{@{}ll}
|
||
Relation:& Menge (!) von gleichartig aufgebauten Tupeln\\
|
||
Tupel:& Zeile einer Tabelle, Aneinanderreihung atomarer Attributwerte\\
|
||
Kardinalität:& Anzahl der Tupel in einer Relation (nicht verwechseln mit E/R-Modell)\\
|
||
Attribut:& Spalte einer Tabelle, Darstellung von Merkmalen durch Werte\\
|
||
Grad der Relation:& Anzahl der Attribute\\
|
||
Relationenschema:& Beschreibung einer Relation (Intension). Besteht aus Relationennamen und \\
|
||
& einer Menge (!) von Attributen. Jedes Attribut wird definiert über einen \\
|
||
& Attributnahmen und einen Wertebereich. \\
|
||
& notiert als: Personen (PNr, Vorname, Nachname, Abteilung)\\
|
||
Relat. Datenbankschema:& Menge von Relationenschemata\\
|
||
Wertebereich:& Menge der zulässigen Attributwerte für ein Attribut\\
|
||
Schlüsselkandidat:& Attribut oder Attributkombination, die ein Tupel eindeutig identifiziert\\
|
||
Primärschlüssel:& ausgewählter Schlüsselkandidat\\
|
||
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.\\
|
||
$R(A_1, A_2, A_3, ... , A_n) \subseteq W(A_1)\times W(A_2)\times W(A_3)\times\dots\times W(A_n)$
|
||
\end{wic}
|
||
Alle Attributwerte sind atomar: \\
|
||
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).\\
|
||
Bedingungen: Wertebereiche müssen übereinstimmen\\
|
||
\\
|
||
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\\
|
||
\\
|
||
\textbf{Integritätsbedingungen:}\\
|
||
System-enforced Integrity: Modell-inhärente Integritätsbedingen:\\
|
||
$\rightarrow$ Primärschlüsseleigenschaften\\
|
||
$\rightarrow$ Referenzielle Integrität\\
|
||
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.\\
|
||
\\
|
||
\textbf{Schritt 7: Mehrstellige Beziehungstypen}\\
|
||
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)}\\
|
||
\begin{center}
|
||
{\footnotesize
|
||
\begin{tabular}{@{}c|c}
|
||
ER-Modell & Relationenmodell\\\hline
|
||
Entity-Typ & Entity-Relation\\
|
||
1:1-oder 1:N-Beziehungstyp & Fremdschlüssel(FS) - oder...\\
|
||
M:N-Beziehungstyp & Beziehungstabelle mit 2 FS\\
|
||
N-ärer Beziehungstyp & Beziehungstabelle mit N FS\\
|
||
Einfaches Attribut & Attribut\\
|
||
Zusammengesetztes Attribut & Menge von Attributen \\
|
||
Mehrwertiges Attribut & Attribut-Relation mit FS\\
|
||
Wertebereich & Wertebereich\\
|
||
Schlüsselattribut & Schlüsselkandidat $\rightarrow$ Primärschlüssel
|
||
\end{tabular}}
|
||
\end{center}
|
||
\textbf{Schritt 8: Unterklassen, Generalisierung/Spezialisierung}\\
|
||
Ü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\\
|
||
\\
|
||
\textbf{Wir unterscheiden:}\\
|
||
1. Normalform(1NF), 2. Normalform(2NF), 3. Normalform(3NF), Boyce-Codd-Normalform(BCNF), \\
|
||
4. Normalform (4NF), 5. Normalform (5NF), Domain-Key-Normalform (DKNF)
|
||
\begin{defi}[Normalisierung]
|
||
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\\
|
||
$\rightarrow$ Aufspaltung: Personal (PersID, Name, Vorname, PLZ), Orte (PLZ, 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\}$\\
|
||
Differenz: $difference (R,S) = \{r|r\in R\wedge r\notin S\}$\\
|
||
Konkatenation: $concat (a,b) =: (a_1, a_2, ... , a_n, b_1, b_2, ..., b_m)$\\
|
||
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.
|
||
\end{defi}
|
||
\begin{defi}[Verbund]
|
||
$R(A_1, A_2, ... , A_n)$ und $S(B_1, B_2, ... , B_m)$ Relationen\\
|
||
$P (A_1, A_2, ... , A_n, B_1, B_2, ... , B_m)$ Prädikat über den Attributen von R und S\\
|
||
$join[P (A_1, A_2, ... , A_n, B_1, B_2, ... , B_m)](R,S)= select[P (A_1, A_2, ... , A_n, B_1, B_2, ... , B_m)](crossproduct(R, S))$\\
|
||
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\\
|
||
$P(A_1,A_2, ..., A_n, B_1, B_2, ..., B_m)= (A_i = B_j)$\\
|
||
\\
|
||
$natjoin (R,S) = project [A_1, ..., A_n, ..., B_{j-1}, B_{j+1}, ..., B_m](join [A_i=B_j](R,S))$\\
|
||
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\\
|
||
Aggregationsfunktionen:\\
|
||
MIN($<$Attribut$>$), MAX($<$Attribut$>$), COUNT($<$Attribut$>$), AVG($<$Attribut$>$), SUM($<$Attribut$>$)\\
|
||
\\
|
||
\textbf{FROM - Klausel:}\\
|
||
\\
|
||
\textbf{WHERE - Klausel:}\\
|
||
Restriktion: Auswahl von einzelnen Tupeln (Zeilen) in der WHERE-Klausel\\
|
||
Einschränkungen vor der Gruppenbildung\\
|
||
geschachtelte Anfragen: WHERE AbtNR IN (SELECT...)\\
|
||
EXISTS: überhaupt Element enthalten oder nicht?\\
|
||
Quantoren: ALL, ANY, SOME\\
|
||
\\
|
||
\textbf{Verbundoperationen:}\\
|
||
alternativ (oder auch zusammen mit WHERE) einsetzbar.\\
|
||
CROSS JOIN, JOIN ... ON, JOIN ... USING, NATURAL JOIN\\
|
||
Äußerer Verbund nimmt auch Tupel, die keinen Partner finden, mit auf und ergänzt Null-Werte:\\
|
||
NATURAL LEFT OUTER JOIN: nimmt Tupel von linker Tabelle\\
|
||
NATURAL RIGHT OUTER JOIN: nimmt Tupel von rechter Tabelle\\
|
||
NATURAL FULL OUTER JOIN: nimmt Tupel beider Tabellen\\
|
||
\\
|
||
\textbf{GROUP BY - Klausel:}\\
|
||
Anwenden einer Aggregationsfunktion auf Untermengen der Eingaberelation\\
|
||
Attribute, die nicht im GROUP BY genannt werden, dürfen nur aggregiert im SELECT verwendet werden\\
|
||
\\
|
||
\textbf{HAVING - Klausel:}\\
|
||
Einschränkungen nach der Gruppenbildung\\
|
||
z.B.\\
|
||
SELECT P.AbtNr, COUNT(*) AS Rang, P.Nachname\\
|
||
FROM Angestellte P, Angestellte A\\
|
||
WHERE P.AbtNr = A.AbtNr AND P.Gehalt $<$= A.Gehalt\\
|
||
GROUP BY P.PersNr, P.Nachname, P.AbtNr\\
|
||
HAVING count(*) $<$= 10;\\
|
||
\\
|
||
\textbf{ORDER BY - Klausel:}\\
|
||
Sortierung der Tupel: ORDER BY ASC/DESC\\
|
||
\\
|
||
in SQL verfügbar: UNION, INTERSECTION, EXCEPT\\
|
||
Unteranfragen dürfen an den Stellen eingebettet werden wo ein Mengenausdruck erlaubt ist\\
|
||
Abarbeitung einer SQL-Anfrage: FROM, WHERE, GROUP BY, HAVING, SELECT, ORDER BY\\
|
||
\\
|
||
\\
|
||
\textbf{Einfügen von Tupeln:}\\
|
||
INSERT\\
|
||
INTO $<$Relation$>$ [($<$Attributliste$>$)]\\
|
||
VALUES ($<$Werteliste$>$);\\
|
||
Wird Attributliste weggelassen, müssen in VALUES-Klausel Werte für
|
||
alle in CREATE TABLE definierten Attribute in der Reihenfolge ihrer
|
||
Definition angegeben werden. Andernfalls dürfen nur für die in Attributliste spezifizierten Attribute Werte
|
||
angegeben werden; die anderen Attribute erhalten Null-Werte.\\
|
||
Statt einzelner Tupel auch ganze Relationen einfügen: anstatt VALUES eine SELECT-Klausel\\
|
||
\\
|
||
\textbf{Löschen von Tupeln:}\\
|
||
DELETE\\
|
||
FROM $<$Relation$>$\\
|
||
$[$ WHERE $<$Bedingung$>$ $]$\\
|
||
\\
|
||
\textbf{Ändern von Attributwerten:}\\
|
||
UPDATE $<$Relation$>$\\
|
||
SET $<$Attribut$>$ = $<$Wert$>$ [, $<$Attribut$>$ = $<$Wert$>$, ... ]\\
|
||
$[$ WHERE $<$Bedingung$>$ $]$\\
|
||
\\
|
||
\textbf{Sicht erstellen:}\\
|
||
CREATE VIEW *NameDerSicht* (*AttributeDerSicht*) AS\\
|
||
\hspace*{8mm} SELECT ...\\
|
||
\\
|
||
\textbf{Zugangskontrolle:}\\
|
||
GRANT $<$privilege\_name$>$\\
|
||
ON $<$object\_name$>$\\
|
||
TO \{ $<$user\_name$> |$ PUBLIC $| <$role\_name$>$ \}\\
|
||
$[$WITH GRANT OPTION$]$;
|
||
\section{XML}
|
||
XML: eXtendedMarkup Language, Metasprache / Untermenge der SGML\\
|
||
\\
|
||
\textbf{Bedeutung von XML}\\
|
||
- textbasiert: jeder beliebige Texteditor kann verwendet werden\\
|
||
\hspace*{3mm} auch ohne technische Interpretation gut lesbar\\
|
||
- Datenidentifikation: durch Tags können Elemente vor Verarbeitung erkannt werden\\
|
||
- Präsentation: kann in Stylesheets beschrieben werden\\
|
||
- Wiederverwendbarkeit: Modularisierung, Reduzierung von Datenvolumen, Redundanzfreiheit, Konsistenz\\
|
||
- Erweiterbare Referenzierbarkeit\\
|
||
|
||
\textbf{Textbasierte Auszeichnungssprache:}\\
|
||
Tags werden zur Strukturierung in einen Text eingefügt (als Markup bezeichnet).\\
|
||
Textausschnitt wird immer durch ein Beginn-und ein Ende-Tag markiert:
|
||
$<$text$>$Das ist ein Text$<$/text$>$\\
|
||
\\
|
||
\textbf{Element:}
|
||
Die Daten, die durch ein Anfangs-und ein Ende-Tag eingeschlossen werden, bilden ein Element, das durch das Tag benannt wird.\\
|
||
Tags können geschachtelt werden, Überlappungen sind nicht zulässig.\\
|
||
\\
|
||
\textbf{Attribut:}\\
|
||
Elemente können durch Attribute genauer beschrieben werden.\\
|
||
Attribute zu einem Element stehen immer im zugehörigen Anfangs-Tag. Einem Attribut wird ein Wert zugewiesen.
|
||
\begin{defi}[Wohlgeformtheit]
|
||
Ein XML-Dokument ist wohlgeformt, wenn es alle syntaktischen Regeln von XML einhält, dazu gehören:\\
|
||
- Jedes Dokument hat genau ein Wurzelelement.\\
|
||
- Zu jedem Anfangs-Tag gibt es ein Ende-Tag.\\
|
||
- Wohlgeformtheit ist Voraussetzung für eindeutige Bestimmung hierarchischer Datenstrukturen.\\
|
||
- Alleinstehende Tags können als Flags(Positions-Markierungen) sinnvoll sein. \\
|
||
\hspace*{3mm}Dafür werden in XML leere Tags verwendet: Für $<$flag$><$/flag$>$ist als Abkürzung $<$flag/$>$erlaubt.\\
|
||
- Elemente können nicht überlappen.\\
|
||
- Verschiedene Attribute in einem Element haben verschiedene Namen.
|
||
\end{defi}
|
||
\begin{defi}[Gültigkeit]
|
||
Ein XML-Dokument ist gültig, wenn\\
|
||
- das XML-Dokument einem Schema zugeordnet ist und\\
|
||
- das Wurzelelement mit den untergeordneten Elementen den Deklarationen im Schema entspricht.\\
|
||
- Voraussetzung ist die Wohlgeformtheit des Dokuments.\\
|
||
- Möglichkeit, ein Schema zu definieren: DocumentType Definition (DTD), wird Dokument beigefügt
|
||
\end{defi}
|
||
\subsection{Struktur eines XML-Dokuments}
|
||
Ein XML-DOkument besteht aus\\
|
||
- dem Prolog,\\
|
||
- der DocumentTypeDefinition(DTD, optional)und\\
|
||
- dem Wurzelelement(das weitere Elemente enthalten kann $\Rightarrow$ Baumstruktur).\\
|
||
\\
|
||
Prolog: \\
|
||
- version: Version von XML – nicht optional (meist $<$?xml version="1.0"$>$)\\
|
||
- encoding: Zeichensatz, z.B. "ISO-8859-1" = "Latin-1" (Default ist "compressedUnicode": UTF-8.)\\
|
||
- standalone: Gibt an, ob externe Entities oder externe DTDs von diesem Dokument referenziert werden.\\
|
||
\\
|
||
Zusätzlich: Kommentare ($<$!-- Kommentar --$>$)und Verarbeitungsanweisungen ($<$?Name Daten ?$>$) an jeder Stelle außerhalb der Tags\\
|
||
Beliebige Zeichenfolgen können mit $<$![CDATA[ ... ]]$>$ in ein XML-Dokument eingebettet werden\\
|
||
\\
|
||
\subsection{DTD}
|
||
- Definiert die zulässige Struktur des Dokuments\\
|
||
- Analog zum Datenbankschema\\
|
||
- Definition von Elementtypen\\
|
||
Nutzen:\\
|
||
- Möglichkeit zur Validierung, Information über das Dokument\\
|
||
- Gleiche Struktur für mehrere Dokumente erzwingen, Vergleichbarkeit von Dokumenten\\
|
||
- Automatische Verarbeitung bestimmter Dokumenttypen\\
|
||
\\
|
||
\textbf{Document Type Definition:}\\
|
||
$<$!DOCTYPE Name0 [\\
|
||
$<$!ELEMENT Elementname (Inhaltsmodell)$>$\\
|
||
$<$!ATTLIST Elementname\\
|
||
\hspace*{10mm}Attributname Typ Attributbedingungen\\
|
||
\hspace*{10mm}Attributname Typ Attributbedingungen\\
|
||
\hspace*{10mm}… $>$\\
|
||
... ]$>$\\
|
||
\\
|
||
\textbf{Inhaltsmodell}\\
|
||
- EMPTY\\
|
||
- ANY(wohlgeformt; Elementtypen nur aus DTD)\\
|
||
- (\#PCDATA)\\
|
||
- Unterelemente (müssen auch als Element aufgeführt werden!)\\
|
||
\\
|
||
\textbf{Attributtypdefinition:}\\
|
||
- Definition der Attribute, die für einen bestimmten Elementtyp gelten\\
|
||
- Attributnamen müssen für den betreffenden Elementtyp eindeutig sein\\
|
||
Attributbedingungen: \#REQUIRED, \#IMPLIED (kann da sein), [\#FIXED] Vorbelegung (Konstante o. Default)\\
|
||
Attributtypen: \\
|
||
\begin{tabular}{@{}ll}
|
||
CDATA& Zeichenkette\\
|
||
ID & Identifikationstyp (Werte müssen im Dokument eindeutig sein)\\
|
||
IDREF & Referenztyp (Verweis auf IDs)\\
|
||
IDREFS & Menge von Verweisen\\
|
||
NMTOKEN & Namens-Token (Zeichenkette, in der nur bestimmte Zeichen zugelassen sind)\\
|
||
NMTOKENS& Liste von Token, durch Leerzeichen getrennt
|
||
\end{tabular}\\
|
||
Aufzählungstyp: Wertebereich explizit definiert – nur Token sind zulässig:\\
|
||
$<$!ATTLIST Gehalt Währung (Dollar $|$ Euro) "Euro" $>$
|
||
\begin{defi}[Namensräume (name spaces)]
|
||
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\\
|
||
- Attributknoten: für jedes Attribut\\
|
||
- Textknoten: für zusammenhängenden Text
|
||
- zudem: Verarbeitungsanweisungsknoten, Kommentarknoten, Namensraumknoten\\
|
||
\\
|
||
XPath-Ausdrücke werden ausgehend von bestimmten Knoten ausgewertet\\
|
||
- explizite Pfadangabe\\
|
||
- Prädikate: zur genaueren Spezifikation
|
||
\hspace*{10mm}2. Buch: /bib/buch$[$2$]$)\\
|
||
\hspace*{10mm}letztes Buch: /bib/buch$[$last()$]$ \\
|
||
\hspace*{10mm} alle Kinder von bib: /bib/*\\
|
||
- hierachie-unabhängige Knoten-Lokalisierung: //BBB\\
|
||
\includegraphics[width=0.7\linewidth]{xpath}
|
||
|
||
\section{Multidimensionale Modellierung}
|
||
- komplexer als Relationenmodell, mehr Modellierungskonstrukte\\
|
||
- Speziell auf Anwendungen zur Datenanalyse zugeschnitten\\
|
||
$\Rightarrow$ nur nützlich für analytische Anwendungen, für diese aber sehr mächtig\\
|
||
\\
|
||
\includegraphics[width=0.7\linewidth]{datawarehouse}\\
|
||
\\
|
||
\textbf{Charakterisierung der Datenanalyse:}\\
|
||
- qualifizierende und quantifizierende Daten:\\
|
||
\hspace*{3mm} spezielle funktionale Abhängigkeiten $\rightarrow$ spezifische Repräsentation\\
|
||
- Klassifikationshierachien: aggregierende Anfragen nutzen Hierarchien zu ihrem Vorteil\\
|
||
- spärlich gefüllte Datenräume: Repräsentation durch Null-Werte\\
|
||
- stabile Daten: Daten werden fast nie geändert, nur neue Daten hinzugefügt\\
|
||
- Zugriff auf materialisierte Sichten: voraggregierte Daten
|
||
\begin{defi}[Mikro-, Makro- und Meta-Daten]
|
||
Mikro-Daten: beschreiben Elementarereignisse, Ergebnis der Ladephase $\rightarrow$ Basisdaten\\
|
||
Makro-Daten: Aggregierte Daten für die Datenanalyse\\
|
||
- Ergebnis der Auswertungsphase $\rightarrow$ Data Warehouse, Data Mart\\
|
||
Meta-Daten: Beschreibungsdaten für Eigenschaften von Mikro-Daten und Makro-Daten, Entstehungsprozess
|
||
\end{defi}
|
||
Über welche "Wege" sollen die Daten später analysiert werden? Wie grob sollen die Daten sein?\\
|
||
$\rightarrow$ Datenwürfel, der flexibel durchsucht werden kann ("Hypercube")\\
|
||
\\
|
||
\textbf{Datenstrukturen:}\\
|
||
- Qualifizierende Daten – Dimensionen des Würfels\\
|
||
\hspace*{8mm} Klassenhierarchien mit qualifizierenden Attributen, Startpunkt für die Datenanalyse\\
|
||
- Quantifizierende Daten – Zellen des Datenwürfels\\
|
||
\hspace*{8mm} Fakten – z.B. Anzahl der Verkäufe, Umsatz etc.\\
|
||
\\
|
||
Ziel: Dimensionen müssen unabhängig sein, eindeutige Trennung von Fakten.\\
|
||
\\
|
||
\textbf{Konzeptionelles Schema: mE/R}\\
|
||
Spezialisierung und Erweiterung des E/R-Modells\\
|
||
- Spezialisierung: neue Modellierungskonstrukte sind Spezialfälle der bereits vorhandenen Konstrukte\\
|
||
- Erweiterung: neues Modell sollte leicht erlernbar sein, minimale Zahl neuer Konstrukte\\
|
||
- Multidimensionale Semantik: Darstellung sollte multidimensionale Semantik der Daten umfassen\\
|
||
\includegraphics[width=\linewidth]{logischesschemabsp}\\
|
||
links: Logisches Schema, rechts: mE/R-Modell\\
|
||
\\
|
||
\textbf{Logisches Schema einer Dimension:}\\
|
||
- Partiell geordnete Menge D von Klassifikationsstufen\\
|
||
- $(\{D_1, ..., D_n, TopD\}; \rightarrow)$, $D_1$ ist kleinstes Element bzgl. $\rightarrow$\\
|
||
- Partielle Ordnung erlaubt parallele Hierarchien: "Pfade"\\
|
||
- $\rightarrow$ bedeutet auch Funktionale Abhängigkeit (N:1 Beziehung)\\
|
||
- Orthogonalität: Verschiedene Dimensionen sind unabhängig.\\
|
||
\\
|
||
\textbf{Instanz einer Dimension:}\\
|
||
- Funktionale Abhängigkeiten sind Baumstruktur auf Instanzebene\\
|
||
- Jeder Pfad im Schema einer Dimension definiert eine Klassenhierarchie.\\
|
||
- Klassenhierarchie ist ein balancierter Baum.\\
|
||
- Instanz einer Dimension ist die Menge aller Klassenhierarchien.\\
|
||
\\
|
||
\textbf{Schema eines Datenwürfels (Data Cube)}\\
|
||
\begin{tabular}{@{}ll}
|
||
Struktur:& $C [G, M]$\\
|
||
Menge von Fakten: & $M = (M_1, ..., M_m)$\\
|
||
Granularität: & $G = (G_1, ..., G_n)$
|
||
\end{tabular}\\
|
||
Jedes $G_i$ ist ein dimensionales Attribut. Im Allgemeinen gibt es für jede aufzunehmende Dimension ein $G_i$.\\
|
||
\\
|
||
\textbf{Instanz eines Würfels:}\\
|
||
- Alle Zellen aus Def.-bereich des Datenwürfels als
|
||
existierend angenommen, egal ob physisch vorhanden\\
|
||
- Im relationalen Datenmodell: Nichts wird angenommen, was nicht explizit als Datensatz vorhanden ist \\
|
||
\hspace*{3mm}("Intension vs. Extension").\\
|
||
Merke: Würfel ist nur eine Metapher!\\
|
||
\\
|
||
\textbf{Fakten (Kenngrößen)}\\
|
||
- können auch Eigenschaften zugesprochen werden.\\
|
||
- keine Datenstruktur an sich, eher analog zu Wertebereich (Bsp: Maßeinheit bei physik. Faktdaten)\\
|
||
\\
|
||
\textbf{Aggregationstyp:}\\
|
||
- nicht-triviale Eigenschaft neben Name und Wertebereich\\
|
||
- definiert, welche Aggregationsoperationen auf einer Kenngröße ausgeführt werden dürfen!\\
|
||
\hspace*{15mm}1. beliebig aggregierbar (Sales, Turnover, ... ): FLOW\\
|
||
\hspace*{15mm}2. nicht temporal summierbar (Stock, Inventory, ... ): STOCK\\
|
||
\hspace*{15mm}3. nicht summierbar (Preis, Steuer, i.Allg. Faktoren): VPU (Value per Unit)\\
|
||
- Immer durchgeführt werden dürfen MIN-, MAX-, und AVG-Operationen.\\
|
||
\\
|
||
\newpage
|
||
\textbf{Multidimensionale Operatoren:}\\
|
||
- Slicing (Selektion von Scheiben) und Dicing (Selection eines Teilwürfels)\\
|
||
- Drill-Down: Abstieg in der Klassifikationshierarchie zu feinerem Granulat\\
|
||
- Roll-Up / Consolidate: Aufstieg in der Klassifikationshierarchie hin zu gröberem Granulat\\
|
||
\hspace*{5mm} Ggf. zuerst Expansion des Datenraums auf den Zielknoten in der Hierarchie\\
|
||
- Drill-Across: Verknüpfung mehrerer Datenwürfel mit gemeinsamen Dimensionen\\
|
||
\hspace*{5mm} Binäre Operationen zwischen mehreren Datenwürfeln: "Cubic Join"\\
|
||
- Drill-Through: Wechsel zu den Originaldaten\\
|
||
- Pivotierung: Wechsel der Darstellung in einer Pivottabelle, entspricht Drehen des Würfels\\
|
||
\\
|
||
\textbf{Aggregation:} \\
|
||
- Zusammenfassen mehrerer Zellen, Bsp: vom Tag zum Monat, vom Produkt zur Kategorie\\
|
||
- Operationen: SUM, AVG, MIN, MAX, COUNT, cumulating, ranking (Top(N))\\
|
||
- Problem: nicht alle Funktionen sind summierbar, Datenstrukturen müssen best. Anforderungen erfüllen\\
|
||
\\
|
||
\textbf{Multidimensionaler Schemaentwurf (Kimball)}\\
|
||
Zentrale Frage: wie kommt man zu einem vernünftigen MD-Schema?\\
|
||
1. Auswahl eines Geschäftsprozesses (Subjektorientierung)\\
|
||
2. Auswahl der Erfassungsgranularität (Tag, Monat, Jahr?)\\
|
||
3. Auswahl der Dimensionen (Orthogonalität, Funkt. Abhängigkeiten)\\
|
||
4. Auswahl der Kennziffern (Aggregationstyp)\\
|
||
\\
|
||
\textbf{Implementierungsvarianten:}\\
|
||
1. Multidimensional\\
|
||
+ Straightforward\\
|
||
– Dünne Besetzung: weniger als 5 Prozent der Zellen besetzt!\\
|
||
– Skalierbarkeit: riesige Arrays nicht einfach abzuspeichern!\\
|
||
\\
|
||
2. Relational\\
|
||
+ Skalierbare, ausgereifte Technologie\\
|
||
– Relationale Datenbanken sind für OLTP und nicht für OLAP konzipiert\\
|
||
– Mangelnde Unterstützung an Operatoren\\
|
||
– Teilweise schlechtere Performance\\
|
||
\\
|
||
ROLAP – Relationale Abbildung\\
|
||
- Tabelle mit zusammengesetztem Primärschlüssel aus den Dimensionen\\
|
||
- (Nur) für jede vorhandene Datenzelle wird ein Tupel abgespeichert\\
|
||
- Trennung von Struktur und Inhalt führt zur Aufteilung in zentrale "Fact Table" und Dimensionstabellen\\
|
||
- ROLAP-Varianten:\\
|
||
\includegraphics[width=0.7\linewidth]{starsnowflake}\\
|
||
- Star Schema: eine Tabelle für jede Dimension\\
|
||
- Snowflake Schema: Normalisierung der Dimensionstabellen
|
||
\subsection*{OLAP vs. OLTP}
|
||
\textbf{Datenhaltung in betrieblichen Informationssystemen:}\\
|
||
\begin{tabular}{@{}c||c|c}
|
||
& transaktional & analytisch\\\hline\hline
|
||
Fokus& Lesen, Schreiben, Modifizieren, Löschen & Lesen, periodisches Hinzufügen\\\hline
|
||
Transaktionsdauer u. -typ & kurze Lese/Schreibtransaktionen & lange Lesetransaktionen\\\hline
|
||
Anfragestruktur & einfach strukturiert & komplex \\\hline
|
||
Datenvolumen von Anfragen & wenige Datensätze & viele Datensätze\\\hline
|
||
Datenmodell & anfrageflexibles Datenmodell & analysebezogenes Datenmodell
|
||
\end{tabular}\\
|
||
\\
|
||
\\
|
||
\textbf{Datenperspektive:}\\
|
||
\begin{tabular}{@{}c||c|c}
|
||
& transaktional & analytisch\\\hline\hline
|
||
Datenquellen & meist eine & mehrere\\\hline
|
||
Eigenschaften & nicht abgeleitet, zeitaktuell, & abgeleitet/konsolidiert,\\
|
||
& autonom, dynamisch & historisiert, integriert, stabil\\\hline
|
||
Datenvolumen & Megabyte - Gigabyte & Gigabyte - Terabyte\\\hline
|
||
Zugriffe & Einzeltupelzugriff/Punktanfragen & Bereichsanfragen
|
||
\end{tabular}\\
|
||
\\
|
||
\\
|
||
\textbf{Anwenderperspektive:}\\
|
||
\begin{tabular}{@{}c||c|c}
|
||
& transaktional & analytisch\\\hline\hline
|
||
Anwendertyp & Ein-/Ausgabe durch & Auswertungen durch Manager,\\
|
||
& Sachbearbeiter & Controller, Analysten\\\hline
|
||
Anwenderzahl & sehr viele & wendige (bis einige hundert)\\\hline
|
||
Antwortzeit & ms - s & s - min
|
||
\end{tabular}
|
||
|
||
\section{UML} % bilder und formatierung
|
||
Graphische Modellierungssprache zum Spezifizieren, Konstruieren, Visualisieren und Dokumentieren von Softwaresystemen.\\
|
||
Modelle werden graphisch in Form von Diagrammen repräsentiert.\\
|
||
\\
|
||
Modellierung funktionaler und deklarativer Anforderungen \\
|
||
- Ausgangspunkt: objektorientierte Programmiersprachen\\
|
||
- Gesucht: Methoden für objektorientierte Analyse und Entwurf\\
|
||
Ziel: Sprache zur Beschreibung unterschiedlicher Aspekte von Softwaresystemen\\
|
||
\begin{center}
|
||
\includegraphics[width=0.7\linewidth]{umldiagramme}
|
||
\end{center}
|
||
\newpage
|
||
\subsection{Anwendungsfall-Diagramm / Use Case}
|
||
beschreibt Benutzeranforderungen\\
|
||
\textbf{Modellierungselemente:}\\
|
||
- 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\\
|
||
\\
|
||
\\
|
||
\includegraphics[width=0.7\linewidth]{aktivitaet}\\
|
||
\newpage
|
||
\textbf{Arten von Knoten:}\\
|
||
1. Aktionsknoten: repräsentieren vordef. UML-Aktionen, empfangen Eingaben, produzieren Ausgaben\\
|
||
2. Kontrollknoten: steuert Aktivitätsabläufe, Festlegung von Start und Ende\\
|
||
\hspace*{5mm}- Initialknoten: kennzeichnet Beginn (runder, ausgemalener Kreis)\\
|
||
\hspace*{5mm}- Aktivitätsendknoten: beendet alle Abläufe (Fisheye)\\
|
||
\hspace*{5mm}- Ablaufendknoten: beendet nur einen bestimmten Ablauf ($\bigotimes$)\\
|
||
\hspace*{5mm}- Entscheidungsknoten: abhängig von einer Bedingung wird Pfad gewählt\\
|
||
\hspace*{5mm}- Vereinigungsknoten: führt alternative Pfade zusammen\\
|
||
\hspace*{5mm}- Parallelisierungsknoten: parallele Verzweigung\\
|
||
\hspace*{5mm}- Synchronisierungsknoten: Zusammenführung paralleler Pfade\\
|
||
3. Objektknoten: Ein- und Ausgabeparameter\\
|
||
\\
|
||
\textbf{Arten von Kanten:} Alle Kanten werden als Pfeile dargestellt\\
|
||
\hspace*{5mm}- Kontrollflusskanten: Darstellung von Reihenfolgeabhängigkeiten\\
|
||
\hspace*{5mm}- Objektflusskanten: Weitergabe von Daten / Objekten zw. Aktionen\\
|
||
\includegraphics[width=1\linewidth]{aktivitet}\\
|
||
|
||
\subsection{Sequenzdiagramm}
|
||
Modellierung ...\\
|
||
\hspace*{5mm}- der Interaktion eines Systems mit seiner Umwelt, um Systemgrenzen festzulegen\\
|
||
\hspace*{5mm}- des Zusammenspiels der internen Struktur einer Klasse, Komponente oder Kollaboration\\
|
||
\hspace*{5mm}- des Interaktionsaspekts der Verknüpfung von verschiedenen Systemteilen\\
|
||
\hspace*{5mm}- Modellierung der Interaktionen der Operationen einer Klasse\\
|
||
\\
|
||
\textbf{Notation:}\\
|
||
\hspace*{5mm}- Rechteck mit Pentagon, darin Diagrammtyp sd gefolgt von Name und evtl. Parametern in Klammern\\
|
||
\hspace*{5mm}- 2 Dimensionen: vertikale = Zeitachse, horizontale = Interaktionspartner\\
|
||
\hspace*{5mm}- Interaktionspartner durch gestrichelte Lebenslinie dargestellt, oben Kopf mit Name und Typ der Rolle\\
|
||
\\
|
||
\textbf{Begriffe:}\\
|
||
1. Interaktionen = Abfolge sogenannter Ereignisspezifikationen\\
|
||
\hspace*{5mm}- zB. Senden/Empfangen einer Nachricht\\
|
||
\hspace*{5mm}- Partitionieren eine Lebenslinie in Zeitsegmente\\
|
||
\hspace*{5mm}- Reihenfolge durch Lebenslinie festgelegt\\
|
||
\hspace*{5mm}- Definieren einen potenziellen Ereigniseintritt zu Laufzeit\\
|
||
2. Folge von konkreten Ereigniseintritten = Trace: gibt Ablauf einer Interaktion zur Laufzeit wieder\\
|
||
3. Ausführungsspezifikation\\
|
||
\hspace*{5mm}- Periode, in der ein Interaktionspartner (in)direkt ein bestimmtes Verhalten ausführt\\
|
||
\hspace*{5mm}- Wird durch Start- und Ende-Ereignis definiert\\
|
||
\\
|
||
\includegraphics[width=0.5\linewidth]{uml1} \hspace*{20mm} \includegraphics[width=0.3\linewidth]{rekursion}
|
||
\newpage
|
||
Nachrichtentypen:\\
|
||
1. Synchrone Nachrichtenübermittlung: Sender wartet, bis durch Nachricht ausgelöste Interaktion beendet\\
|
||
2. Asynchrone Nachrichtenübermittlung: Sender wartet nicht auf die Antwort des Empfängers\\
|
||
3. Antwortnachrichten\\
|
||
4. Verlorene Nachricht: Nachricht an unbekannten / nicht relevanten Interaktionspartner verschicken\\
|
||
5. Gefundene Nachricht: Von einem solchen Interaktionspartner empfangen\\
|
||
\includegraphics[width=1\linewidth]{sequenz}\\
|
||
\\
|
||
Kombinierte Fragmente: zur Modellierung komplexer Kontrollstrukturen\\
|
||
\hspace*{5mm}- beinhaltet Interaktionsoperator und einen/mehrere -operanden\\
|
||
\hspace*{5mm}- Operatoren zur Festlegung der Auswahl und Reihenfolge der gesendeten Nachrichten
|
||
\begin{center}
|
||
\includegraphics[width=0.6\linewidth]{uml2}
|
||
\end{center}
|
||
\subsubsection*{Operatoren für kombinierte Fragmente} % folie 11-34
|
||
Verzweigungen und Schleifen:\\
|
||
\includegraphics[width=1\linewidth]{schleifen}
|
||
\\
|
||
\\
|
||
Nebenläufigkeit und Ordnung:\\
|
||
\includegraphics[width=1\linewidth]{ordnung}
|
||
\newpage
|
||
\textbf{Filterungen und Zusicherungen:}\\
|
||
\begin{tabular}{@{}l|l|l|l}
|
||
\includegraphics[width=0.22\linewidth]{ignore}
|
||
& \includegraphics[width=0.22\linewidth]{consider}
|
||
& \includegraphics[width=0.22\linewidth]{assert}
|
||
& \includegraphics[width=0.22\linewidth]{neg}
|
||
\\\hline
|
||
&&&\\
|
||
unwichtige Interaktionen & wichtige Interaktionen & Zusicherung & ungültige Interaktionen\\
|
||
spielen keine Rolle, & Interaktionen sind & einzig gültiges Verhalten & explizite Modellierung eines\\
|
||
können vorkommen& hier besonders wichtig & nicht modellierte Ereign. & ungültigen Ablaufs\\
|
||
& & dürfen nicht auftreten &
|
||
|
||
\end{tabular}\\
|
||
\\% folie 11- 42
|
||
\\
|
||
\textbf{Wiederverwendung von Fragmenten und Modularisierung}\\
|
||
- Interaktionsreferenzen: Referenzierung anderer Sequenzdiagramme\\
|
||
- ganze Interaktionsabläufe oder einzelne Lebenslinien
|
||
\begin{flushright}
|
||
\includegraphics[width=1\linewidth]{uml7}
|
||
Interaktionsreferenzen Beispiel
|
||
\end{flushright}
|
||
\includegraphics[width=1\linewidth]{uml8}\\
|
||
- Verknüpfungspunkte: Verbindung von Nachrichten zwischen \\
|
||
\hspace*{3mm} Sequenzdiagrammen, Interaktionsreferenzen oder kombinierten Fragmenten\\
|
||
- Vielleicht zuerst als verlorene und gefundene Nachrichten,nun aber benannt und verknüpft
|
||
\subsection{Klassendiagramme}
|
||
- Klassen entsprechen Entity-Typen des E/R-Modells\\
|
||
\hspace*{3mm} $\Rightarrow$ Gegenstand der Modellierung sind Software-Artefakte, nicht Ausschnitte der realen Welt\\
|
||
- Beziehungen werden modelliert durch Assosiationen, Aggregationen, Generalisierungen, Abhängigkeiten\\
|
||
%\parpic[r]{
|
||
\includegraphics [width=5.5cm]{uml6.jpg}
|
||
%}
|
||
\textbf{Namensfeld:} Eigenschaftsangaben, häufig \{abstract\}\\
|
||
\textbf{Attribute:} beschreiben Eigenschaften (Instanzattribut, \underline{Klassenattribut})\\
|
||
- Sichtbarkeit: + public, $\sim$ (innerhalb Paket), - private, \# protected \\
|
||
- Abgeleitete Attribute: / vorangestellter Schrägstrich\\
|
||
- Multiplizitätsangabe: Anzahl der Werte, die das Attr. annehmen kann\\
|
||
- Typangabe, Initialwert\\
|
||
\textbf{Operationen:} Unterschied zu Attributen ist Parameterliste\\
|
||
|
||
\begin{tabular}{@{}l|ll}
|
||
& ordered & unordered\\\hline
|
||
unique & ordered & set\\
|
||
nonunique & sequence & bag
|
||
\end{tabular}
|
||
|
||
\newpage
|
||
\textbf{Aktive Klassen:}\\
|
||
- Klassen, für die ein eigenes Verhalten definiert ist (mit Zustands/Aktivitätsdiagramm)\\
|
||
- Kontrollfluss, Reaktionen auf Ereignisse\\
|
||
- Notation: \{active\} oder vertikal doppelter Rahmen\\
|
||
\\
|
||
\textbf{Objekte:}\\
|
||
- Instanzen von Klassen\\
|
||
- Notation: \underline{Objektname:Klassenname}\\
|
||
- Links: Beziehungen zw. Objekten, Darstellung als einfache Kante\\
|
||
\\
|
||
\textbf{Assoziationen:} Beziehungen zw. Klassen\\
|
||
\includegraphics[width=0.5\linewidth]{uml4}\\
|
||
- navigierbare Assoziation: Pfeil, Spitze zeigt Richtung an, anderes Ende: X\\
|
||
\\
|
||
\textbf{Multiplizitäten:} mögl. Anzahl an Links, die ein Objekt der gegenüberliegenden Klasse hat \\
|
||
\hspace*{5mm}0..1 keiner oder einer, 0..* beliebig viele, 1..1 genau eins, 1..* mindestens eins\\
|
||
bei mehrwertigen Assoziationsenden:\\
|
||
- Ordnung \{ordered\}, \{unordered\} (ohne Angabe unordered)\\
|
||
- Eindeutigkeit \{unique\}, \{nonunique\} (ohne Angabe unique)\\
|
||
\\
|
||
\textbf{Assoziationsklassen:} Assoziationen soll durch Attribute näher beschrieben werden\\
|
||
\\
|
||
\includegraphics[width=0.5\linewidth]{uml5}\includegraphics[width=0.45\linewidth]{uml9} \\
|
||
\\
|
||
\includegraphics[width=0.5\linewidth]{mehrwertig} \ \ N-äre Assoziationen\\
|
||
\\
|
||
\textbf{Teil-Ganze-Beziehungen}\\
|
||
\begin{tabular}{@{}lll}
|
||
Aggregation & \ \ \ \ & Komposition\\
|
||
\includegraphics[width=0.4\linewidth]{Unbenannt}
|
||
&& \includegraphics[width=0.4\linewidth]{Unbenannt1}\\
|
||
Eintrag kann Bestandteil einer Liste sein, kann && darf Teil höchstens eines Ganzen sein \\
|
||
aber auch unabhängig davon existieren und in && 1..1 : existenzabhängig \\
|
||
mehreren Listen stehen. && 0..1 : kann ohne Ganzes existieren
|
||
\end{tabular}\\
|
||
\\
|
||
\\
|
||
\textbf{Generalisierung:} IS\_A-Beziehung\\
|
||
\includegraphics[width=0.3\linewidth]{generalisierung}\ \ \ \ \ \includegraphics[width=0.55\linewidth]{lsutiegr}
|
||
\newpage
|
||
\subsection{Metamodellierung}
|
||
Metamodell = Modell über ein Modell\\
|
||
Ziel: Beschreibung der Architektur von UML, bessere Interpretierbarkeit der UML-Modelle\\
|
||
\includegraphics[width=0.9\linewidth]{meta}
|
||
\section{Ontologien}
|
||
"An ontology is a formal explicit specification of a shared conceptualization."\\
|
||
{\footnotesize Ontologie ist eine formale explizite Spezifikation einer gemeinsamen Konzeptualisierung.}\\
|
||
{\footnotesize "an ontology defines a set of representational primitives with which to model a domain of knowledge or discourse"\\
|
||
= Ontologie definiert Menge von Repräsentationsprimitiven, um eine Domäne des Wissens oder des Diskurses zu modellieren}\\
|
||
\\
|
||
für uns: Spezifikation von gemeinsam zu verwendenden Begriffen und deren Zusammenhängen\\
|
||
Zweck: gemeinsames Verständnis\\
|
||
\\
|
||
Kommunikation führt zu Mehrdeutigkeiten:\\
|
||
\begin{tabular}{@{}|l|l|}
|
||
\hline
|
||
\textbf{Homonyme} & \textbf{Synonyme}\\\hline
|
||
Homophone (gleiche Sprechweise) & Vollsynonyme (genau gleicher Begriff)\\
|
||
Homographe (gl. Schreibweise, & Quasisynonyme (feine begriffl. Unterschiede)\\
|
||
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\\
|
||
\\
|
||
\textbf{Ebenen der Allgemeingültigkeit:}\\
|
||
- Top-level-Ontologie: \\
|
||
\hspace*{5mm}allgemeingültige Kategorien (Objekt – Prozess – Qualität)\\
|
||
- Kern-Ontologie (Top-Domänen-Ontologie): \\
|
||
\hspace*{5mm}Kategorien für einen größeren Anwendungsbereich (Mensch – Krankheit – Größe)\\
|
||
- Domänen-Ontologie: \\
|
||
\hspace*{5mm}Kategorien für einen spezifischen Anwendungsbereich (Leukozyt – chronisch lymphatische Leukämie)\\
|
||
\\
|
||
\textbf{Unterscheidung nach Grad der Formalisierung:}\\
|
||
- informal: Begriffsliste, (kontrolliertes) Vokabular, Katalog, Glossar\\
|
||
- Begriffshierarchie: Taxonomie, Nomenklaturen Z.B. ICD, MeSH\\
|
||
- semiformal: Thesaurus, semantisches Netz, UML-oder E/R-Diagramme\\
|
||
- formal: Formalisierte logische Theorie Z.B. SNOMED
|
||
\newpage
|
||
\textbf{Formal Ontology:}\\
|
||
Ziel: formale Beschreibung von Dingen, Modi, Strukturen und Prozessen der Welt auf Grundlage von Kategoriensystemen\\
|
||
Methoden aus Fachwissenschaft, Logik, KI, Philosophie, Kognitionspsychologie\\
|
||
\\
|
||
\\
|
||
\textbf{Sinn und Zweck von Ontologien in der Informatik:}\\
|
||
Ziele: Kompatible Systeme, effizientes Vorgehen, Referenzen für Systementwickler\\
|
||
$\Rightarrow$ Ontologische Übereinkunft: Festlegung auf Spezifikationen einer bestimmten Ontologie\\
|
||
- Spezielle Methoden zur Spezifikation von Ontologien\\
|
||
$\Rightarrow$ Semantic Web: Identifizierbarkeit über URls, semantische Typisierung von URls, ...\\
|
||
\hspace*{5mm} Ontologien für das Semantic Web:\\
|
||
\hspace*{5mm} - RDF (Resource Description Framework)\\
|
||
\hspace*{5mm} - Web Ontology Language OWL: W3C-Standard zur Beschreibung von Web-Ontologien\\
|
||
\\
|
||
\textbf{RDF:}\\
|
||
- RDF und XML sind komplementär: XML für Struktur und Elemente, RDF deren Bezüge\\
|
||
- RDF basiert auf Klassensystem, Vererbung\\
|
||
- Ressource: Ding, das durch RDF-Ausdruck beschreibbar ist, bestimmt durch Universal Resoure Identifier\\
|
||
- Eigenschaft (Property): Aspekt, Charakteristik, Attribut oder Beziehung zur Ressourenbeschreibung\\
|
||
\hspace*{3mm} jede Eigenschaft hat spezifische Bedeutung, def. zugelassene Werte, Typen und Beziehungen\\
|
||
- Objekt: kann String, ein in XML def. primitiver Datentyp oder weitere Ressource sein\\
|
||
- Anweisung (Statement): spezifische Ressoure zusammen mit bezeichneter Eigenschaft und Wert
|
||
\subsection{Ontologie in der Philosophie}
|
||
Ontologie von griech. Ontos (Sein) + Logos (Wort, Lehre)\\
|
||
- Lehre des Seins, des Existierenden\\
|
||
- Einteilung der Dinge in fundamentale Kategorien\\
|
||
- wie kann die Natur der Dinge beschrieben werden?\\
|
||
- Mereologie: Lehre vom Teil und Ganzen\\
|
||
- Erforschung der Kategorien die allem Sein zugrunde liegen\\
|
||
- unversöhnliche philosophische Lehrmeinungen:\\
|
||
\hspace*{5mm} 1. Realismus: Sprache reflektiert menschl. Erfahrung\\
|
||
\hspace*{11mm} Grundstruktur des Existierenden ist über Sprache erfahrbar\\
|
||
\hspace*{5mm} 2. Konstruktivismus: Sprache ist Projektion des Denkens und hängt von menschl. Erkenntnis ab\\
|
||
\hspace*{11mm} Grundstruktur des Existierenden ist nicht unmittelbar erfahrbar\\
|
||
\\
|
||
- Ontologie ist eng verknüpft mit Epistemologie = Erkenntnistheorie\\
|
||
- Frage nach den Möglichkeiten und Grenzen menschl. Wahrnehmens und Erkennens\\
|
||
- Beschreibt Ontologie die Welt wie sie wirklich ist? Oder nur wie sie uns erscheint?\\
|
||
\\
|
||
Frage: wie kommen wir zu einem gemeinsamen Verständnis über die Sachverhalte der realen Welt?\\
|
||
- zur Kommunikation brauchen wir gemeinsame Sprache\\
|
||
- zur Repräsentation von Sprache brauchen wir Zeichen / Symbole\\
|
||
%\parpic[r]{
|
||
\includegraphics [width=5.5cm]{semantik.PNG}
|
||
%}
|
||
\textbf{Semiotik:} Lehre von den Zeichen und den Symbolen\\
|
||
- Syntax: korrekte Schreibweise\\
|
||
- Semantik: Bedeutung (semiotisches Dreieck)\\
|
||
- Pragmatik: Wirkung
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
\end{document}
|