diff --git a/horschtey_zusammenfassungen/.gitignore b/horschtey_zusammenfassungen/.gitignore new file mode 100644 index 0000000..f8088e6 --- /dev/null +++ b/horschtey_zusammenfassungen/.gitignore @@ -0,0 +1,5 @@ +*.aux +*.log +*.pdf +*.synctex.gz + diff --git a/horschtey_zusammenfassungen/aud/baum.png b/horschtey_zusammenfassungen/aud/baum.png new file mode 100644 index 0000000..71bb16f Binary files /dev/null and b/horschtey_zusammenfassungen/aud/baum.png differ diff --git a/horschtey_zusammenfassungen/aud/baumref.png b/horschtey_zusammenfassungen/aud/baumref.png new file mode 100644 index 0000000..f4bd2a2 Binary files /dev/null and b/horschtey_zusammenfassungen/aud/baumref.png differ diff --git a/horschtey_zusammenfassungen/aud/document.tex b/horschtey_zusammenfassungen/aud/document.tex new file mode 100644 index 0000000..076dfba --- /dev/null +++ b/horschtey_zusammenfassungen/aud/document.tex @@ -0,0 +1,930 @@ +\documentclass[12pt,a4paper]{article} +\usepackage[utf8]{inputenc} +\usepackage{amsmath} +\usepackage{amsfonts} +\usepackage{amssymb} +\usepackage{graphicx} +\usepackage{amsthm} +\usepackage{thmbox} +\parindent0pt +\usepackage[left=1.00cm, right=1.00cm, top=1.00cm, bottom=1.00cm]{geometry} +\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}} + \pagestyle{empty} + Wichtige Befehle in Java:\\ + Länge von Arrays: .length\\ + Objekte inhaltlich mittels equals vergleichen, mittels == werden Referenzen verglichen. + \section{Algorithmisches Denken} + \begin{defi}[Informatik] + Kunstwort aus den 60er Jahren, das die Assoziationen Informatik gleich Information und Technik oder Information und Mathematik erwecken sollte + \end{defi} + \begin{defi}[Algorithmus] + Folge einfacher Anweisungen, die folgende Eigenschaften aufweist: \\Endlichkeit, Terminierung, eindeutige Reihenfolge, eindeutige Wirkung + \end{defi} + Vorgehensweise bei der Lösung von Programmierproblemen:\\ + $\rightarrow$ Problem verstehen und abstrahiert beschreiben\\ + $\rightarrow$ Problemlösung in algorithmischer Form beschreiben\\ + $\rightarrow$ Algorithmus in Programmiersprache implementieren (Hochsprache)\\ + $\rightarrow$ Übersetzung des Programms in Maschinencode (Compiler)\\ + $\rightarrow$ Überprüfung: beschreibt die Spezifikation wirklich das Problem?\\ + $\rightarrow$ Nachweis, dass Algorithmus das spezifierte Problem korrekt löst (Semantik)\\ + $\rightarrow$ Setzt das Programm den Algorithmus korrekt um?\\ + $\rightarrow$ Aufwandsanalyse + \section{Grundlagen der Programmierung} + \subsection{Variablen} + \begin{defi}[Variablendeklaration] + legt Datentyp und Namen einer Variable fest\\ + bei Übersetzung wird Variable im Speicher erzeugt und Speicher reserviert (je nach Datentyp)\\ + Datentyp dient dazu, Speicherinhalt korrekt zu interpretieren + \end{defi} + Bezeichner können aus kleinen und großen lat. Buchstaben, Ziffern, \_ und \$ bestehen, jedoch keine Leerzeichen und keine Schlüsselwörter. Sollten mit Kleinbuchstaben beginnen und selbsterklärend sein (mnemonische Namen).\\ + \\ + Konstanten werden am Anfang eines Blocks definiert und in Großbuchst. geschrieben, \_ zur Worttrennung + \subsection{Datentypen} + Datentyp: Menge von Daten gleicher Art + \begin{defi}[primitive Datentypen] + \begin{tabular}{@{}ll} + ganze Zahlen:&\begin{tabular}{@{}llll} + byte:& $-2^7 =<$&$ \text{byte}$&$ =< 2^7-1$\\ + short:& $-2^{15} =< $&$\text{short}$&$ =< 2^{15}-1$ \\ + int:& $-2^{31}=<$&$ \text{int}$&$ =< 2^{31}-1$ \\ + long:& $-2^{63}=<$&$\text{long}$&$=< 2^{63}-1$ (Anhängen von L) + \end{tabular} + \\ + Fließkommazahlen:& dargestellt gemäß IEEE, float (32 bit), double (64 bit)\\ + & $\Rightarrow$ für genaue Rechnungen ungeeignet!\\ + Zeichen:& char (zwischen ' ', Zahlen in ASCII oder UNICODE interpretiert) \\ + boolescher Wert:& boolean (wahr oder falsch) + \end{tabular} + \end{defi} + Entscheidungsgehalt: Anzahl an Bit, die man benötigt, um jedes Element einer Menge eindeutig mit einem Bitmuster zu identifizieren:\\ + $H(M)=\lceil log_2 (|M|)\rceil$\\ + \\ + Zahlen in Binär: vorangestelltes 0b/0B\\ + Zahlen in Hex: vorangestelltes 0x\\ + Zahlen in Oktal: vorangestellte 0\\ + \\ + Aufzählungstyp enum $<$ Name $>$ \{ELEMENT1, ELEMENT2, ...\}\\ + \\ + Array: zusammengesetzter Datentyp, endliche Folge von Werten eines Datentyps\\ + Deklaration: int[] a=\{viele viele bunte Werte\} oder int[\ ] a=new int[10] + ACHTUNG: Indizierung beginnt bei 0. + + \subsection{Operatoren und Ausdrücke} + \begin{tabular}{@{}c|c|c c c|c|c} + $+$&$x+y$& Addition &\ \ \ \ \ \ \ \ \ &$>$&$x>y$& x größer y\\ + $-$&$x-y$& Subtraktion &&$>=$&$x\geq y$& x größer gleich y\\ + $*$&$x+y$& Multiplikation &\ &$<$&$x>$ right shift sign. Beachtet Vorzeichen, von links altes Vorzeichenbit einschieben.\\ + $>>>$ right shift no-sign. ignoriert Vorzeichen, von links neue Nullen einschieben.\\ + \\ + Auswertungsreihenfolge, von unten nach oben:\\ + \begin{tabular}{@{}ll} + Postfix-Operatoren & [] . (params) expr++ expr--\\ + unäre Operatoren & ++expr --expr +expr -expr ! ~\\ + Erzeugung oder Typumwandlung & new (type) expr\\ + Multiplikationsoperatoren &* / \%\\ + Additionsoperatoren & + -\\ + Verschiebeoperatoren & $<<$ $>>$ $>>>$\\ + Vergleichsoperatoren & $<$ $>$ $<=$ $>=$ instanceof\\ + Gleichheitsoperatoren & == !=\\ + Bitoperator Und & \&\\ + Bitoperator exklusives Oder & \textasciicircum\\ + Bitoperator inklusives Oder & $|$ \\ + logisches Und & \&\&\\ + logisches Oder &$||$\\ + Fragezeichenoperator& ?\\ + Zuweisungsoperatoren& = += -= *= /= \%= $>>$= $<<$= $>>>$= \&= \textasciicircum= $|$=\\ + \end{tabular} + \subsection{Typkonvertierung} + implizite Typkonvertierung: Automatische Konvertierung durch Compiler zu größeren Datentypen\\ + explizite Typkonvertierung: Konvertierung zu kleinerem Datentypen, muss von Programmierer explizit gefordert werden.\\ + Typkonvertierungsoperator: (Zieldatentyp) Wert\\ + \newpage + \section{Ablaufstrukturen und Methoden} + \begin{tabular}{@{}lll} + if-else:&& switch:\\ + if ($<$Bedingung$>$) \{&& switch ($<$Ausdruck$>$) \{\\ + $<$Anweisungen$>$&& case $<$konstanter Ausdruck$>$: $<$Anweisung$>$: break;\\ + \}else \{&& ...\\ + $<$Anweisungen$>$&& default: $<$Anweisung$>$;\\ + \}&\ \ \ \ \ \ \ \ \ \ \ \ &\}\\ + &&\\ + &&\\ + while ($<$Bedingung$>$) \{ && do \{\\ + $<$Anweisungen$>$&&$<$Anweisungen$>$\\ + \}&& \} while ($<$Bedingung$>$); + \end{tabular}\\ + \\ + while-Schleifen, wenn die Anzahl an Iterationen unbekannt ist. \\ + \\ + for:\\ + for ($<$Initialausdruck$>$; $<$Bedingung$>$; $<$Inkrementausdruck$>$) \{\\ + $<$Anweisungen$>$\\ + \} \\ + for-Schleifen, wenn die Anzahl an Iterationen bekannt ist.\\ + \\ + bedingter Ausdruck:\\ + allgemein: $<$Bedingung$>$ ? $<$Ausdruck1$>$ : $<$Ausdruck2$>$\\ + \begin{tabular}{@{}lll} + statt&\ \ \ \ \ \ \ & könnte man auch schreiben:\\ + int max;&& int max = $(i > j)$ ? i : j;\\ + if $(i>j)$ {max= i;} else {max=j;}&&\\ + \end{tabular} + \subsection{Ablaufdiagramme} + \includegraphics[width=0.58\linewidth]{ifelse} + \includegraphics[width=0.21\linewidth]{dowhile} + \includegraphics[width=0.21\linewidth]{while} + \subsection{Methoden} + Deklaration:\\ + $<$Sichtbarkeitsmodifikator$>$ $<$Rückgabetyp$>$ $<$Methodenname$>$ (Param 1, ..., Param n)\{\\ + Anweisungen;\\ + \}\\\\ + Methodenaufruf: $<$Objektname$>$.$<$Methodenname$>$($<$Eingabewerte$>$) + \newpage + \section{Rekursion} + \begin{defi}[Rekursion] + Eine Funktion heißt rekursiv, wenn zur Berechnung von f diese Funktion f wieder benutzt wird.\\ + Eine Methodendeklaration f(x) \{ ...\} heißt rekursive Methodendefinition, gdw. f im Block \{...\} aufgerufen wird. + Funktion ruft sich selbst auf $\Rightarrow$ Rekursionsschritt\\ + \\ + Voraussetzungen: Selbstähnlichkeit, Monotonieeigenschaft, Beschränktheit\\ + \\ + Eine Funktion heißt linear rekursiv, wenn sie in jedem Zweig einer Fallunterscheidung ihres Rumpfes höchstens einmal aufgerufen wird.\\ + Eine Methode f heiß endrekursiv, wenn der rekursive Methodenaufruf stets die letzte Aktion des Zweigs zur Berechnung von f ist. Kann unmittelbar entrekursiviert werden: rekursiv besser zum Aufschreiben, iterativ schneller in der Ausführung.\\ + Eine Methode f heißt kaskadenartig rekursiv, wenn in einem Zweig einer Fallunterscheidung im Rumpf von f zwei oder mehr Aufrufe von f auftreten.\\ + Zwei Methoden f und g heißen verschränkt (auch: wechselseitig) rekursiv, wenn die Methodendeklaration von f einen Aufruf der Methode g enthält und die Methodendeklaration von g einen Aufruf der Methode f enthält.\\ + Eine Methode f heißt verschachtelt rekursiv, wenn man zur Bestimmung der Parameter des rekursiven Aufrufs einen rekursiven Aufruf der Funktion ausführen muss. + \end{defi} + Terminierungsbeweis:\\ + finde ganzzahlige Terminierungsfunktion und beweise, dass t bei jedem Rekursionsschritt streng monoton fällt und nach unten beschränkt ist.\\ + \subsection{Entrekursivierung} + \begin{tabular}{@{}lll} + $f(x)$& $= g(x)$ falls $praed(x)$& (nicht rekursiver Basisfall)\\ + & $=f(r(x))$ sonst& (rekursiver Aufruf) + \end{tabular}\\ + \\ + \\ + arg = x; // Hilfsvariable\\ + while (!$praed(arg)$) \{\\ + \hspace*{10mm}arg = $r(arg)$; // modifiziere Parameter\\ + \}\\ + return $g(arg)$; // nicht-rekursiver Basisfall + \section{Rekursion im Einsatz} + 1. Durchreichen von Zwischenergebnissen\\ + 2. Dynamisches Programmieren: \\ + Mithilfe von einer Liste werden alle schon berechneten Werte gespeichert(erhöhter Speicherbedarf)\\ + Vorgehen:\\ + $\rightarrow$ rekursive Version implementieren\\ + $\rightarrow$ Tabelle zum Zwischenspeichern der Werte erzeugen und initialisieren\\ + $\rightarrow$ rekursive Version um Lookup/Memoization erweitern\\ + \hspace*{5mm}$\rightarrow$ Tabelle als zusätzliche Eingabe\\ + \hspace*{5mm}$\rightarrow$ zu berechnenden Wert in der Tabelle nachschlagen (Lookup)\\ + \hspace*{5mm}$\rightarrow$ falls bereits berechnet: Wert direkt zurückgeben\\ + \hspace*{5mm}$\rightarrow$ ansonsten:\\ + \hspace*{8mm}$\rightarrow$ Wert rekursiv berechnen\\ + \hspace*{8mm}$\rightarrow$ Wert in der Tabelle zwischenspeichern (Memoization)\\ + \hspace*{8mm}$\rightarrow$ Wert zurückgeben\\ + Backtracking, Rücksetzverfahren:\\ + systematisches Durchsuchen des Suchraums, dabei Anwendung von trial-and-error\\ + Grundgerüst:\\ + static int[\ ][\ ] backtrack(int[\ ][\ ] state) { //z.B. Sudoku\\ + \hspace*{5mm}if (isFinal(state)) \{\\ + \hspace*{10mm} return state;\\ + \hspace*{5mm} \} else \{\\ + \hspace*{10mm} // moegliche Erweiterungen aufzaehlen\\ + \hspace*{10mm} int[] candidates = getExtensions(state);\\ + \hspace*{10mm} for (int i = 0; i < candidates.length; i++) \{\\ + \hspace*{15mm} int c = candidates[i];\\ + \hspace*{15mm} state = apply(state, c); //z.B. Ziffer setzen\\ + \hspace*{15mm} if (backtrack(state) != null) \{ // Rekursion\\ + \hspace*{20mm} return state;\\ + \hspace*{15mm} \}\\ + \hspace*{15mm} state = revert(state, c); //z.B. Ziffer loeschen\\ + \hspace*{10mm} \}\\ + \hspace*{10mm} return null;\\ + \hspace*{5mm} \} + \section{Asymptotische Aufwandsanalyse} + Qualitätskriterien für Algorithmen:\\ + Korrektheit, hohe Verständlichkeit, einfache Implementierbarkeit, geringstmöglicher Bedarf an Ressourcen\\ + \\ + Der exakte Aufwand eines Algorithmus (z.B. als Anzahl Rechenschritte bis zur Terminierung oder als verbrauchte Zeit) kann nur schwer als Funktion von Umfang und Eingabewerten allgemein angegeben werden. Wichtiger ist die ungefähre Größenordnung, mit der der Aufwand in Abhängigkeit vom Umfang der Eingabe wächst.\\ + Eine Elementaroperation entspricht genau einer Instruktion des zugrunde liegenden Von-Neumann-Rechners und hat das Kostenmaß 1. + \begin{defi}[O-Notation (asympt. obere Schranke), Groß-O] + $f(n) \in O(g(n)):$ $f(n)$ wächst höchstens so schnell wie $g(n)$\\ + $O(g(n))=\{f:\mathbb{N}\rightarrow\mathbb{R}^+ | \exists n_0 \in \mathbb{N}, c\in \mathbb{R}, c>0:\forall n\geq n_0 \ f(n)\leq c\cdot g(n)\}$ + \end{defi} + \begin{defi}[$\Omega$ - Notation] + $f(n) \in \Omega (g(n)):$ $f(n)$ wächst mind. so schnell wie $g(n)$\\ + $\Omega(g(n))=\{h(n)|\exists c>0\ \exists n_0 >0\ \forall n\geq n_0: 0\leq c\cdot g(n)\leq h(n)\}$ + \end{defi} + \begin{defi}[$\Theta$ - Notation] + $f(n) \in \Theta (g(n)):$ $f(n)$ wächst ebenso so schnell wie $g(n)$\\ + $\Theta(g(n))=\{h(n)|\exists c_1>0\ \exists c_2>0\ \exists n_0 >0\ \forall n\geq n_0: 0\leq c_1\cdot g(n)\leq h(n)\leq c_2\cdot g(n)\}$ + \end{defi} + \begin{defi}[Rechenregeln für die O-Notation] + Seien $f(n)\in O(r(n)), g(n)\in O(s(n))$ und $c>0$ konstant. Dann gilt:\\ + a) $f(n)+g(n)\in O(r(n)+s(n))=O(max(r(n), s(n)))$\\ + b) $f(n)\cdot g(n)\in O(r(n)\cdot s(n))$\\ + c) $c\cdot f(n)\in O(r(n))$\\ + d) $f(n) \pm c \in O(r(n))$ + \end{defi} + + \section{Objektorientierte Programmierung: Klassen und Objekte} + Datentyp bisher: Daten gleicher Sorte, z.B. ganze Zahlen, Wahrheitswerte, Zeichenketten.\\ + Jetzt: Konzentration auf das Klassen- und Objektkonzept, das Grundlage der objektorientierten Programmierphilosophie ist. + \begin{defi}[Klasse] + Klasse (auch Objekttyp): Konzept der objektorientierten Modellierung und Programmierung, mit dem neue Datentypen definiert werden können.\\ + Die Deklaration einer Klasse stellt damit eine Art Bauanleitung oder Schablone für sog. Objekte (auch: Exemplare, Instanzen) dieser Klasse dar. \\ + Klassennamen sollen selbsterklärend sein und die Lesbarkeit des Programms fördern sowie Substantive sein und mit einem Großbuchstaben beginnen.\\ + \\ + Konkret wird in der Klassendeklaration festgelegt:\\ + - aus welchen Datenkomponenten (sog. Attributen) ein Objekt besteht\\ + - welche Methoden, z.B. zur Manipulation der zugehörigen Attributwerte, zur Verfügung stehen und\\ + - welche Konstruktoren zur Erzeugung von Objekten (auch Instanziierung) verwendet werden können + \end{defi} + \begin{defi}[Attribute] + Attribute sind Datenkomponenten, aus denen Objekte einer Klasse bestehen. Deklaration und Benennung erfolgen analog zu Variablen. Erlaubt sind Attribute primitiven und zusammengesetzten Typs. + \end{defi} + \begin{defi}[Konstruktoren] + Konstruktoren sind Operationen, die es ermöglichen, Objekte einer Klasse zu instanziieren, d.h. anzulegen oder zu erzeugen. Alle Konstruktoren einer Klasse haben denselben Namen, nämlich den der Klasse, zusätzlich können sie Parameter haben. Ein Rückgabetyp wird nicht angegeben.\\ + \\ + 1. explizite Konstruktoren\\ + Sie werden bei der Klassendeklaration angegeben und i.d.R. dazu genutzt, die Attributwerte des zu erzeugenden Objekts auf für den Anwendungszweck sinnvolle Startwerte zu setzen. Explizite Konstruktoren können Parameter haben. Eine Klasse kann mehrere explizite Konstruktoren haben, die aber unterschiedliche Parameterlisten haben müssen.\\ + 2. impliziter Konstruktor (auch Standard-Konstruktor, Default-Konstruktor)\\ + Wird kein expliziter Konstruktor angegeben, so legt der Übersetzer automatisch einen impliziten Konstruktor an. Ein impliziter Konstruktor hat immer die Form $<$Klassenname$>$()\{\ \}. + \end{defi} + Ein objektorientiertes Programm in Java besteht aus Folge von Klassendeklarationen, die jeweils Attribut-, Konstruktor- und Methodendeklarationen enthalten.\\ + In einer der Klassen muss die Methode main deklariert sein, mit der die Ausführung des Gesamtprogramms startet.\\ + Klasse, die die Methode main deklariert, nimmt i.d.R. Sonderrolle ein, nämlich die der Spezifikation des Hauptprogramms und nicht die der Deklaration des Datentyps einer Klasse von Objekten. In der Regel beginnt dort die Erzeugung der für die Problemlösung relevanten Objekte anhand der Klassendeklarationen. Diese Objekte verwalten eigene Daten (Werte der Attribute) und sie reagieren auf Nachrichten (Aufrufe von Methoden, die in der Klasse des Objekts deklariert wurden).\\ + Problemlösung durch schrittweise Objekterzeugung, - verknüpfung und - kommunikation. + \begin{defi}[Objekt] + Objekt ist Datenstruktur, deren Datentyp (Struktur, Verhalten) durch eine Klasse festgelegt ist. Objekt ist konkrete Ausprägung einer Klasse, deshalb auch Instanz genannt.\\ + Klassendeklaration legt fest, welche Attribute und Methoden für ein Objekt der Klasse zur Verfügung stehen und in welcher Form eine Instanziierung stattfinden kann.\\ + Während eine Klasse die Attribute i.d.R. nur deklariert, werden bei einem Objekt die Attribute durch den verwendeten Konstruktor oder durch Methodenaufrufe mit Attributwerten belegt. + \end{defi} + \begin{defi}[Objektvariablen] + Attribute von primitivem Typ sind Behälter im Objekt. Sie verhalten sich wie die Ihnen bekannten Variablen.\\ + Attribute vom Typ einer Klasse (sog. Objektvariablen) können einen Verweis/eine Referenz auf ein Objekt enthalten.\\ + Bei der Deklaration einer Objektvariable wird eine Variable angelegt, die einen Verweis auf ein Objekt der zugehörigen Klasse aufnehmen kann (deshalb auch Referenzvariable). \\ + Bei der Deklaration wird noch keine Objektinstanz erzeugt, der Wert der neu angelegten Variable ist eine sog. Null-Referenz. + \end{defi} + \begin{defi}[Instanziierung] + Instanziierung bezeichnet die Erstellung eines neuen Objekts einer Klasse. Das Objekt wird erzeugt, d.h. der entsprechende Platz im Speicher reserviert. Verweis auf dieses Objekt bzw. auf den Speicherbereich wird zurückgegeben. \\ + Form: Schlüsselwort new gefolgt von Konstruktoraufruf. + \end{defi} + \begin{defi}[Klassenattribut/Klassenmethode] + Klassenattribut (auch: statisches Attribut) ist Sonderfall, bei dem sich alle Objekte der Klasse denselben Attributwert teilen. Schreiboperationen in einem Objekt wirken sich damit auf alle anderen Objekte aus.\\ + Schlüsselwort static.\\ + Zugriff auf Klassenattribute von außen hat die Form $<$klassenname$>$.$<$attributname$>$ oder $<$objektname$>$.$<$attributname$>$, von innen $<$attributname$>$\\ + \\ + Klassenmethoden sind auch ohne instanziiertes Objekt verwendbar, da sie einer Klasse und nicht einem Objekt zugeordnet sind und bieten damit die Möglichkeit, Methoden direkt auf einer Klasse selbst auszuführen. \\ + Man verwendet sie als Getter und Setter für Klassenattribute oder wenn für die Methode kein Objekt der Klasse benötigt wird oder generell zu einer Klasse keine Objekte instanziiert werden sollen. So sparsam wie möglich zu verwenden, da eig. nicht der objektorientierten Philosophie entsprechend. + \end{defi} + \begin{defi}[Sichtbarkeit von Information] + Oft ist nur wichtig, was ein Objekt leistet, nicht aber, wie es realisiert ist. Es werden Programmiertechniken benötigt, mit denen man den Zugriff auf Attribute und Methoden von Objekten einschränken kann.\\ + Sichtbarkeits-Modifizierer:\\ + keiner (paketsichtbar): aus den Klassen desselben Paktes\\ + public: aus allen Klassen heraus\\ + private: nur aus definierender Klasse heraus\\ + protected: aus definierender Klasse, allen Unterklassen und Klassen desselben Pakets + \end{defi} + \begin{defi}[Datenkapselung] + Bezeichnet das Verbergen von Programmierdetails vor dem direkten Zugriff von Außen. Direkter Zugriff auf interne Datenstruktur wird unterbunden und erfolgt stattdessen über wohl definierte Schnittstellen (Black-Box-Modell). + \end{defi} + \begin{defi}[Wrapper-Klassen] + Viele Methoden erwarten Parameter von Typ Object. Um diesen Methoden Werte eines primitiven Datentyps zu übergeben, stell Java für jeden Datentyp eine sog. Wrapper-Klasse zur Verfügung, die diesen Wert kapselt. + \end{defi} + \subsection{UML - Unified Modelling Language} + Assoziation: setzt Objekte von genau 2 Klassen zueinander in Beziehung\\ + Einfache Linie zw. den Klassen, Name an der Mitte dieser notiert, Anzahlangaben (mit wie vielen Objekten der gegenüberliegenden Assoziationsseite ist je ein Objekt mind./höchst. verbunden)\\ + \\ + Multiplizitäten: geben an, wie viele Objekte der an der Assoziation beteiligten Klassen jeweils miteinander in Beziehung stehen können.\\ + 0..* wird mit Liste angegeben\\ + \\ + Aggregation: Spezialform der Assoziation, modelliert eine "hat-Beziehung"\\ + UML-Darstellung: unausgefüllte Raute am Beziehungsende auf der Seite des Ganzen\\ + \\ + Komposition: Spezialform der Aggregation, bei der ein Bestandteil genau zu einem Ganzen gehört und ohne dieses nicht existieren kann.\\ + UML-Darstellung: ausgefüllte Raute am Beziehungsende auf der Seite des Ganzen + \subsubsection{Klassenkarten} + \includegraphics[width=0.6\linewidth]{uml}\\ + Abstrakte Klassen: über dem Klassennamen $<<$abstract$>>$\\ + Interdaces: über dem Klassennamen $<<$interface$>>$\\ + statische Methoden und Attribute durch Unterstreichen kennzeichnen + + \section{OOP: Klassenbeziehungen, Polymorphie, Module} + \textbf{1. objektorientierte Analyse}\\ + Ziel: allgemeines Systemmodell erstellen ohne Implementierungsdetails. Beschreibung, was das System machen soll und Erstellung eines OOA-Modells\\ + \textbf{2. objektorientierter Entwurf, obj. orient. Design}\\ + Planung und Beschreibung, wie das geplante System die Anforderungen realisiert\\ + \textbf{3. objektorientierte Programmierung}\\ + Umsetzung in Quelltest der verwendeten objektorientierten Programmiersprache + \subsection{Vererbung} + Mechanismus, der es ermöglichst, sog. Unterklassen aus einer gegebenen Klasse abzuleiten.\\ + Die Unterklasse erbt dann von der (Ober-)Klasse die Attribute und Methoden, kann aber auf private Methoden und Attribute nicht zugreifen. Es können weitere Attribute und Methoden hinzukommen, die der Spezialisierung dienen.\\ + Ein Objekt der Unterklasse ist auch ein Objekt der Oberklasse.\\ + UML: Linie von Unter- zur Oberklasse mit unausgefülltem Dreieck als Pfeilspitze auf Seite der Oberklasse.\\ + Schlüsselwort super ermöglicht den expliziten Bezug auf Attribute oder Methoden der direkten Oberklasse der Klasse, in der es verwendet wird. + \subsection{Polymorphismus} + Polymorphie = Fähigkeit, verschiedene Gestalt anzunehmen\\ + Beispiel: polymorphe Methoden: haben gleichen Namen, tun aber etwas Unterschiedliches.\\ + \\ + Überladen:\\ + denselben Namen, aber unterschiedlicher Signatur (unterschiedlicher Rückgabetyp reich nicht)\\ + \\ + Überschreiben:\\ + liegt vor, wenn es zu einer Methode, die in einer Klasse deklariert ist, eine Methode in einer Unterklasse gibt, die denselben Namen, diesselbe Parameterliste und denselben Resultattyp hat.\\ + Anwendung: Obj. der Oberklasse: Methode d. Oberkl., Obj. der Unterklasse: Methode d. Unterkl.\\ + Auf eine überschriebene Instanzmethode der Oberklasse kann im Inneren der überschriebenen Klasse per super zugegriffen werden. Klassenmethoden können nicht überschrieben werden.\\ + \\ + Methodenauswahl in Java:\\ + 1. Finden der anwendbaren und zugreifbaren Methoden\\ + 2. Auswahl der spezifischsten Methode + \subsubsection{Polymorphe Variablen} + \textbf{Typ:} Eigenschaft von Variablen und Ausdrücken, definiert Mindestforderung bzgl. anwendbarer Operationen, rein syntaktisch festgelegt.\\ + \\ + \textbf{Klasse:} stellt Konstruktor für Objekte bereit, definiert Signatur oder Implementierung der Operationen. Objekt gehört zu der Klasse, mit deren Konstruktor es konstruiert wurde. Mit der Klassendefinition wird ein gleichnamiger Typ eingeführt.\\ + \\ + Polymorphe Variablen in typsicheren Sprachen:\\ + Typsicherheit:\\ + Es dürfen nur Methoden aufgerufen werden, die schon beim statischen Typ von m verfügbar sind, da der dynamische Typ erst zur Laufzeit feststeht, der Compiler jedoch zur Übersetzungszeit garantieren muss, dass die entsprechende Methode bzw. das entsprechende Attribut tatsächlich existiert.\\ + Eine polymorphe Variable kann im Laufe der Ausführung eines Programms Referenzen auf Objekte verschiedener Klassen haben. Sie hat einen\\ + - statischen Typ: wird durch Angabe der Klasse bei der Deklaration angegeben und kann bei der Übersetzung \\ + \hspace*{2mm}überprüft werden. Ändert sich nicht.\\ + - dynamischen Typ: wird durch die Klasse des Objekts angegeben, auf den die Variable zur Laufzeit zeigt.\\ + \hspace*{2mm} Zur Laufzeit bekannt, kann sich ändern.\\ + \\ + dynamische Bindung bei Instanzmethoden: zur Laufzeit wird in Abhängigkeit von der Tatsache, ob das Objekt eine Instanz der Ober- oder einer Unterklasse ist, die jeweilige Version der Methode aufgerufen.\\ + statische Bindung bei Klassenmethoden: es wird immer die Methode des Typs genutzt als der die Variable deklariert ist.\\ + \\ + Verdecken von (Klassen-)Attributen und Klassenmethoden:\\ + bedeutet, dass ein in der Unterklasse deklariertes Attribut denselben Namen aufweist wie ein entsprechendes Attribut der Oberklasse, oder dass eine in der Unterklasse deklarierte Klassenmethode diessebe Signatur aufweist, wie eine entsprechende Klassenmethode der Oberklasse.\\ + Hierbei wird innerhalb der Unterklasse das Attribut der Oberklasse durch das namensgleiche Attribut der Unterklasse verdeckt, oder die Klassenmethode der Oberklasse durch die signaturgleiche Klassenmethode der Unterklasse verdeckt.\\ + Regel: beim Zugriff auf (Klassen-)Attribute und Klassenmethoden ist immer der statische Typ an der Zugriffsstelle der relevante. + \newpage + \includegraphics[width=1\linewidth]{instanzklasse} + + \subsection{Schnittstellen} + Mit einer Schnittstelle (Schlüsselwort interface) wird in Java definiert, welche Methoden eine diese Schnittstelle implementierende Klasse (Schlüsselwort implements) mindestens haben muss.\\ + In Interface können Konstanten, Signaturen von Methoden deklariert werden, alles andere ist nicht zulässig.\\ + Konstantendeklarationen haben automatisch die Modifizierer static, final und public, Methodendeklarationen abstract und public. Deshalb brauchen diese nicht angegeben werden.\\ + \\ + Auflösung potentieller Mehrfachvererbung bei Schnittstellen:\\ + Methoden: Werden 2 gleich benannte Methoden über versch. Pfade ererbt, so wird bei identischen Signaturen eben diese Signatur übernommen, und bei unterschiedl. Signaturen beide übernommen und dann als überladene Methoden behandelt.\\ + Konstanten: werden 2 gleich benannte Konstanten über versch. Pfade geerbt, meldet der Übersetzer Fehler, nur wenn die Konstante verwendet wird. Ein Interface kann eine Konstante deklarieren, die eine/mehrere geerbte Konstanten gleichen Namens verdeckt.\\ + \\ + Eine abstrakte Klasse ist eine Art Oberklasse mit nur partieller Implementierung, restliche Implementierung muss in einer Unterklasse nachgeholt werden. + \subsection{Pakete und Klassenbibliotheken} + Paket: Zusammenstellung von als zusammengehörig betrachteten Java-Klassen und Interfaces.\\ + Paket besitzt einen Namen, der - wie von Dateiverzeichnissen her bekannt - hierarchisch aufgebaut sein kann. Der Paketname definiert Namensraum für die im Paket vorkommenden Klassendeklarationen und sollte nur aus Kleinbuchstaben bestehen.\\ + \\ + Um außerhalb eines Pakets eine Klasse oder Schnittstelle zu verwenden, gibt es zwei Möglichkeiten:\\ + 1. Zugriff auf Klasse in einem Paket über den qualifizierten Namen\\ + 2. Paketname mittels import bekannt machen. + \section{Robustes Programmieren} + \subsection{Fehlerquellen} + Strategien zum Umgang mit Fehlern bei der Programmentwicklung:\\ + 1. Identifizierung möglicher Fehlerquellen mit Checklisten\\ + 2. Absicherung von Quellcode gegen fehlerhafte Verwendung\\ + 3. Testen von Programmen\\ + 4. Formale Verifikation von Programmteilen\\ + 5. Toleranz gegen verbleibende Fehler\\ + \\ + Fehlervermeidung durch gemeinsame Programmentwicklung oder gemeinsames "Walkthrough" + \subsection{Fehlerbehandlung} + Ausgabe von Fehlermeldungen: System.err als Ausgabe an das Konsolenfenster\\ + \\ + Eine Ausnahme (engl. exception) ist ein Ereignis, durch das die normale Ausführungsreihenfolge unterbrochen wird.\\ + Man sagt: eine Exception wird geworfen (throw), wenn sie ausgelöst wird, und wird gefangen, wenn sie behandelt wird.\\ + Jeder Ausnahme wird ein Ausnahmetyp zugeordnet. Ausnahmetypen erben alle von der vordefinierten Klasse java.lang.Throwable mit genau zwei direkten Unterklassen: \\ + java.lang.Error (= serious problem) zeigt Probleme bei der Programmausführung an, die das Programm i.d.R. nicht selbst beheben kann/sollte. \\ + java.lang.Exception ist die Oberklasse, unter der alle Ausnahmetypen zusammengefasst werden, die das Programm selbst behandeln möchte/sollte.\\ + \\ + Alle Exceptions ohne RuntimeExceptions sind checked exceptions, alles andere aus Throwable sind unchecked exceptions. Checked Exceptions müssen behandelt oder weitergegeben werden.\\ + \\ + \includegraphics[width=\linewidth]{exceptionhierachy}\\ + \\ + \\ + Eigene Ausnahmeklassen erstellen: \\ + die Klasse sollte eine Unterklasse von java.lang.Exception sein.\\ + Ein Ausnahmeobjekt sollte den Fehlerzustand aufnehmen können, also muss man entsprechende Attribute vorsehen.\\ + \\ + Ausnahmen behandeln mit try-catch:\\ + try-Block umfasst Code, der Ausnahmen auslösen kann.\\ + Wird in einem try-Block eine Ausnahme geworfen, wird die Ausführung des try-Blocks sofort abgebrochen. Dann wird der Typ der Ausnahmeobjekts mit den Typangaben der nachfolgenden catch-Klauseln verglichen (von oben nach unten).\\ + Der erste catch-Block, dei dem der Ausnahmetyp bzgl. instanceof zur Typmenge passt, behandelt die Ausnahme und gibt dem Ausnahmeobjekt einen Namen.\\ + Passt keiner der catch-Blöcke oder löst der catch-Block selbst eine Ausnahme aus, so wird die Ausführung abgebrochen und die letzte Ausnahme an den Aufrufer übergeben.\\ + Falls keine Ausnahme ausgelöst wurde oder nach Bearbeitung der passenden catch-Klausel wird mit den nachfolgenden Anweisungen fortgesetzt.\\ + Manchmal soll im Anschluss an den Code im try-Block ein Stück Code auf jeden Fall ausgeführt werden. Solcher Code kann am Ende in einem sog. finally-Block angegeben werden.\\ + \\ + Ausnahmen weitergeben:\\ + Möglichkeit 1: Ausnahme in der verwendenden Methode mit try-catch abfangen\\ + Möglichkeit 2: Ausnahme an aufrufende Methode weiterleiten:\\ + $<$ModifierList$>$ $<$MethodName$>$($<$ParameterList$>$) throws $<$ExceptionClass$^1$$>$, ..., $<$ExceptionClass$^n$$>$ + \subsubsection{Stacktrace} + Ein Stacktrace zeigt die Methodenschachteln auf dem Stack. \\ + Hilfreich für die Rückverfolgung einer Ausnahme: in welcher Methode wurde die Ausnahme geworfen? von wo aus wurde diese Methode aufgerufen?\\ + Falls Exception in Java nicht gefangen wird, bricht Programm ab und Stacktrace wird ausgegeben. \\ + Kann auch manuell ausgegeben werden: printStackTrace() + \subsection{Zusicherungen} + Während der Programmentwicklung ist es möglich, Bedingungen zu formulieren, die am Beginn oder am Ende einer Methode oder während der Ausführung einer Schleife + gelten müssen, damit die Methode korrekt arbeitet (sog. Vor- bzw. Nachbedingung, Schleifeninvariante).\\ + Solche Bedingungen können als Behauptungen während der + Programmentwicklung (genauer: in der Testphase) automatisiert + mittels sog. Zusicherungen (engl. assertions) geprüft werden.\\ + Bei der Ausführung beim Anwender sollten sie nicht eingesetzt und korrekter Programmablauf sollte dort anders sichergestellt werden.\\ + \textbf{assert Expression1 : Expression2}\\ + Expression1 ist boolescher Ausdruck und Expression2 ein Fehlermeldungsausdruck. + \subsection{wp-Kalkül} + Zur Analyse eines Algorithmus A:\\ + Formulierung einer Nachbedingung Q: \\ + - logischer Ausdruck über den Variablen des Algorithmus\\ + - Anforderung an Methode, soll nach Abarbeitung von A erfüllt sein.\\ + Bestimmung der Vorbedingung P:\\ + - logischer Ausdruck über den Eingabewerten von A\\ + - Welche Eigenschaften müssen die Eingabewerte haben, damit nach der Ausführung von A die Nachbe-\\ + \hspace*{3mm}dingung Q auch tatsächlich erfüllt ist?\\ + A ist korekt, falls alle Eingabewerte, die tatsächlich auftreten können, P erfüllen.\\ + wp = weakest precondition, schwächste Vorbedingung\\ + Seien Algorithmus A und Nachbedingung Q gegeben. Das schwächste Prädikat P (also das, das bei möglichst vielen Eingabedaten x wahr ergibt), für das gilt P\{A\}Q gilt, heißt wp(A,Q):=P\\ + Das wp-Kalkül ist ein sog. Verifikationskalkül (verwenden rein syntaktische Regelwerke zur Ableitung zu verifizierender Aussagen, Regeln sind rein mechanisch anwendbar)\\ + \\ + Formale Definition:\\ + E: Menge der möglichen Eingabedaten\\ + O: Menge der möglichen Ausgabedaten\\ + Vorbedingung P: Prädikat auf E\\ + Nachbedingung Q: Prädikat auf E $\times$ O\\ + A: Algorithmus, der Eingabedaten in Ausgabedaten überführt.\\ + $\rightarrow$ ist also eine Abbildung A: E $\rightarrow$ O\\ + $\rightarrow$ A(x) bezeichnet die Ausgabedaten zu den konkreten Eingabedaten x\\ + Falls gilt $\forall x\in E: P(x) \rightarrow Q(x, A(x))$, dann schreibt man $\{P\} A\{Q\}$\\ + Das schwächste Prädikat P mit $\{P\} A\{Q\}$ heißt wp(A, Q).\\ + \\ + Allgemeines Vorgehen:\\ + Rückwärtsanalyse: A schrittweise von hinten abarbeiten, also in jedem Schritt letzte Anweisung X in A verarbeiten. Dazu Auswirkungen von X auf Nachbedingung bestimmen (was muss vor X gelten, damit nach X Nachbedingung erfüllt ist?). Ergebnis wird neue Nachbedingung für restliche Anweisungen in A.\\ + \\ + \begin{tabular}{@{}ll} + Zuweisungen:& in Q werden alle Vorkommen durch neuen Wert ersetzt.\\ + In-/Dekrement-Operatoren:& nach/vor der eigentlichen Substitution behandeln.\\ + Fallunterscheidungen: & Bedingung wahr: b erfüllt und X führt zur Nachbedingung\\ + & Bedingung falsch: b nicht erfüllt und Y führt zur Nachbedingung\\ + Datentypen:& Vereinfachung in Datentyp der Variable, explizit hinschreiben + \end{tabular} + \subsubsection{Korrektheit von Schleifen} + 2 Werkzeuge zum Korrektheitsbeweis von Schleifen:\\ + 1. Schleifeninvariante: muss vor/nach jedem Durchlauf wahr sein, beschreibt Verhalten der Schleife\\ + 2. Schleifenvariante: Funktion über Programm-Variablen, Beweis der Terminierung\\ + \\ + Schleifeninvariante:\\ + Sei eine Schleife der Form while (b) \{A;\} gegeben. Ein Prädikat I ist eine gültige Schleifeninvariante, falls gilt $\{I\wedge b\}\rightarrow wp(A,I)$\\ + Falls vor der Ausführung des Rumpfes die Invariante I und die Schleifen-Bedingung b erfüllt sind (d.h. die Schleife wird auch tatsächlich ausgeführt), dann muss nach Ausführung des Rumpfes zumindest die Invariante erfüllt sein.\\ + Eine geeignete Schleifeninvariante I hat zusätzlich folgende Eigenschaften:\\ + - das Prädikat I ist vor der Schleife erfüllt\\ + - die Nachbedingung Q lässt sich nach der Schleife aus I implizieren\\ + \\ + Schleifenvariante (auch: Terminierungsfunktion)\\ + Schleife muss nach endlich vielen Durchläufen abbrechen\\ + 1. V ist eine geeignete Funktion auf den in der Schleife verfügbaren Variablen\\ + 2. V ist ganzzahlig\\ + 3. V ist streng monoton fallend\\ + 4. V ist nach unten beschränkt ($\{I\wedge b\wedge V\}A\{c\leq V < z\}$ mit $c, z \in \mathbb{Z}$) + \section{Grundlegende Datentypen} + \subsection{Spezifikation von Datentypen} + Abstrakter Datentyp (ADT):\\ + Festlegung der auf den Typ anwendbaren Operationen (Schnittstelle)\\ + Festlegung der Wirkung der Operationen\\ + \\ + Man legt fest:\\ + - adt: Namen des ADTs\\ + - sorts: Liste verwendeter Datentypen\\ + - ops: Schnittstellen der Operationen: Name, Parameter-Typen und Ergebnis-Typ\\ + - axs: Axiome zur Beschreibung der Semantik: so allgemein wie möglich, so ausführlich wie nötig\\ + \\ + Dies geschieht in der Signatur (Bsp.):\\ + \begin{tabular}{@{}llll} + adt& IntSet&&\\ + sorts& IntSet, Int, Boolean&&\\ + ops& create:&& $\rightarrow$ IntSet\\ + & insert:& IntSet $\times$ Int& $\rightarrow$ IntSet\\ + & delete:& IntSet $\times$ Int& $\rightarrow$ IntSet\\ + & contains:& IntSet $\times$ Int& $\rightarrow$ Boolean\\ + & isEmpty: & IntSet & $\rightarrow$ Boolean\\ + axs& isEmpty(create) & = true&\\ + & isEmpty(insert(x,i)) & =false&\\ + & insert(insert (x,i),i) & = insert(x,i)&\\ + & contains(create, i) & = false&\\ + & contains(insert(x,j),i)& = \begin{tabular}{@{}ll} + true & falls i=j\\ + contains (x,i) & sonst\\ + \end{tabular}&\\ + end & IntSet &&\\ + \end{tabular}\\ + \\ + Vorteile:\\ + Man kann Datentyp genau soweit festlegen, wie gewünscht, ohne Implementierungsdetails vorwegzunehmen. Die Sprache, in der Axiome beschrieben werden, folgt formalen Regeln. Daher sind Entwurfswerkzeuge konstruierbar, die Spezifikation prüfen oder Prototyp erzeugen können.\\ + \\ + Nachteile:\\ + Bei komplexen Anwendungen wird die Zahl der Gesetze sehr groß. Es ist nicht immer leicht, anhand der Gesetze die intuitive Bedeutung eines Datentyps zu erkennen. Insbesondere ist es schwierig zu prüfen, ob die Menge der Gesetze vollständig ist\\ + \\ + Umsetzung in Java-Code:\\ + ops: Schnittstellen der Java-Methoden\\ + axs: Umsetzung der Java-Methoden\\ + \\ + \begin{tabular}{@{}ll} + Konstruktoren:& mit create und insert lassen sich alle mögl. Objekte erzeugen. Zwingend erforderlich.\\ + Hilfskonstrukt.:& erzeugen auch Datenobjekte des Typs, aber nicht zwingend erforderlich.\\ + Normalform:& konstruiert durch minimale Zahl von Konstruktoraufrufen. + \end{tabular} + \subsection{Generische/Parametrisierte Klassen} + Generische bzw. parametrisierte Klassen bieten sich an, wenn man feststellt, dass man mehrere Klassen für verschiedene Typen, aber mit ansonsten identischem Code benötigt.\\ + \\ + Vorteile: Code muss nur einmal geschrieben werden. Platzhalter kann durch einen beliebigen Typ ersetzt werden, der so verwendet werden kann, wie der Platzhalter im Code der generischen Klasse.\\ + \\ + Durch Angabe des Typplatzhalters T in spitzen Klammern wird Klasse zur generischen bzw. parametrisierten Klasse. Mehrere Typparameter werden durch Kommata getrennt angegeben. Typparameter können innerhalb der Klasse als Typen von Variablen oder Rückgabewerten oder als Parameter von Methoden genutzt werden.\\ + \\ + Mögliche Typen für Typparameter können eingeschränkt werden: nur Klassen die von bestimmter Klasse erben oder von bestimmtem Interface implementieren.\\ + Einschränkung mittels extends\\ + \\ + Typparameter dürfen nicht in statischen Elementen verwendet werden, da verschiedene Instanzen einer Klasse mit unterschiedlichen generischen Typen dennoch diesselben statischen Elemente verwenden. + \subsection{Elementare Listen} + Listen enthalten endliche Folgen von Objekten eines gegebenen Grundtyps in einer definierten Ordnung. Jedes Element hat Vorgänger und Nachfolger (außer 1. und letztes Element). Listen dürfen Duplikate enthalten. Man unterscheidet unsortierte und sortierte Listen.\\ + Listeneintrags-Objekte haben folgende Struktur:\\ + Verweis auf den Listeneintrag + Verweis auf den Nachfolger des Listeneintrags\\ + Liste besteht aus verketteten Listeneintrags-Objekten, die jeweils vorne angefügt werden\\ + \\ + \textbf{Stapel/Keller (Stacks)}\\ + Ein Stapel/Keller (engl. Stack) ist ein Spezialfall der elementaren Liste.\\ + Stapelprinzip: man kann nur oben etwas drauflegen oder herunternehmen. \\ + Nur oberstes Element ist sichtbar.\\ + Zuletzt eingefügtes Element wird als erstes entnommen: Last-In-First-Out\\ + \textbf{(Warte-) Schlangen (Queues)}\\ + Schlangen sind spezielle Listen, bei denen Elemente nur an einem Ende (vorne) entnommen und nur am anderen Ende (hinten) angehängt werden.\\ + Schlangen sind sog. First-In-First-Out Datenstrukturen. + \section{Verkettete Listen, dynamische Arrays, Mengen} + Einfach verkettete Liste: jedes Element kennt seinen direkten Nachfolger.\\ + Zweifach verkettete Liste: jedes Element kennt zusätzlich seinen direkten Vorgänger. + \subsection{Innere, geschachtelte und lokale Klassen} + 1. innere Klasse:\\ + nicht-statische Klasse innerhalb einer anderen Klasse\\ + Methoden der inneren Klasse können auf alle Elemente der äußeren Klasse zugreifen.\\ + Ein Objekt der inneren Klasse ist immer abhängig von einem Objekt der äußeren Klasse, d.h. es muss ein Objekt der äußeren Klasse existieren, um eines der inneren instanziieren zu können. Deshalb können innere Klasse keine statischen Elemente besitzen.\\ + \\ + 2. geschachtelte Klasse:\\ + statische Klasse innerhalb einer anderen Klasse\\ + wie statische Methoden können geschachtelte Klassen auf statische Elemente der sie enthaltenden Klasse zugreifen, nicht aber auf deren Instanzvariablen.\\ + Objekte sind nicht von einem Objekt der äußeren Klasse abhängig und können statische Elemente besitzen.\\ + \\ + 3. lokale Klasse:\\ + nicht-statische Klasse innerhalb einer Methode + \subsection{Einfach verkettete Listen} + Liste besteht aus verketteten Listeneintrags-Objekten mit sog. Wächter-Objekt. next der Wächterelements zeigt auf den vordersten Listeneintrag. Letzter Listeneintrag verweist auf Wächter $\rightarrow$ Zyklus\\ + \\ + Durchlaufen einer verketteten Liste:\\ + 1. per for-Schleife\\ + \hspace*{5mm}Medium elem;\\ + \hspace*{5mm}for (int i = 0; i $<$ medList.size(); i++) \{\\ + \hspace*{10mm} elem = medList.get(i);\\ + \hspace*{10mm} elem.print();\\ + \hspace*{5mm}\}\\ + 2. per for-each-Schleife\\ + \hspace*{5mm}for (BibMitglied bm : bmList) \{\\ + \hspace*{10mm} bm.print();\\ + \hspace*{5mm}\}\\ + 3. Listen-Iterator:\\ + \hspace*{5mm}Iterator$<$Medium$>$ iter = medList.iterator();\\ + \hspace*{5mm}Medium elem;\\ + \hspace*{5mm}while (iter.hasNext()) \{\\ + \hspace*{10mm} elem = iter.next();\\ + \hspace*{10mm} elem.print(); // mache etwas mit dem Listenelement\\ + \hspace*{5mm}\} + \subsection{Dynamische Arrays} + \begin{tabular}{l||l|l} + & einfach verkettete Listen & Standard-Arrays\\\hline\hline + Speicherbedarf:& ändert sich dynamisch mit der Anzahl & wird einmal festgelegt und ist dann \\ + & der enthaltenen Objekte & nicht veränderbar\\ + & immer nur so viel wie nötig & ggfs. Speicherverschwendung bei nicht \\ + & Speicherbedarf für Zeiger & voll belegtem Array\\ + Element suchen: & lineare Suche & binäre Suche (wenn sortiert)\\ + Zugriff i-tes Element:& Liste von vorne bis zur & direkter Zugriff möglich\\ + & betreffenden Stelle durchlaufen & + \end{tabular}\\ + \\ + Kombination der Vorteile ergibt sog. dynamisches Array + \subsection{Mengen} + Ziel:\\ + Mengen so darstellen, dass die klassischen Operationen Hinzufügen und Entnahme von Elementen, Vereinigung, Durchschnitt und Differenz effizient ausgeführt werden können. \\ + Mengen enthalten keine Duplikate von Elementen.\\ + Elemente haben keine feste Reihenfolge.\\ + \\ + 1. Implementierung mit einfach verketteter Liste ohne Sortierung der Elemente\\ + Mengenelemente werden in nicht-sortierter, einfach verketteter Liste gehalten.\\ + Neue Elemente werden vorne an der zugrundeliegenden Liste angefügt, sofern sie nicht bereits enthalten sind (Test erfordert Durchlaufen der Liste per linearer Suche).\\ + \\ + 2. Implementierung mit einfach verketteter Liste mit Sortierung der Elemente\\ + wenn die Elemente in der Menge aufsteigend sortiert sind, dann muss man nicht die ganze verkettete Liste durchlaufen, um nach Duplikaten zu suchen und die Mengenoperationen sind schneller, weil ein Reißverschlussverfahren verwendet werden kann.\\ + \\ + 3. Implementierung mit dynamischem Array mit Sortierung der Elemente\\ + Bei der Implementierung einer Menge mit Hilfe einer einfach verketteten Liste profitierten allein die Mengenoperationen von der Sortierung.\\ + Vom Suchaufwand her ist eine Implementierung mithilfe eines Arrays eine günstigere Lösung, da direkt auf die einzelnen Elemente zugegriffen werden kann.\\ + Die Speicherung als Array spart Platz, weil keine Verzeigerung nötig ist. Sie kostet Laufzeit, weil beim Änderung der Größe Kopierarbeit anfällt.\\ + \\ + 4. Implementierung als Bitvektor ohne Sortierung der Elemente + \subsection{Streutabellen} + Idee: aus dem Wert eines zu speichernden Mengenelements wird seine Adresse im Speicher berechnet.\\ + Speicher zur Aufnahme der Mengenelemente ist Streutabelle der Größe m, wobei m i.d.R. sehr viel kleiner als der Wertebereich ist. Die zu speichernden Mengenelemente haben einen eindeutigen Schlüssel.\\ + Erforderlich ist die Hash-Funktion $h: G\rightarrow S$. h ist nicht injektiv, möglichst surjektiv, sollte Schlüssel gleichmäßig auf den Bereich der Tabellenindizes verteilen und sollte effizient zu berechnen sein. h bildet ein Datenelement auf einen Hashwert ab, benötigt dazu einen Schlüssel, der ein Element eindeutig identifiziert. Der errechnete Hashwert wird als Index in die Tabelle verwendet, das Element wird in entsprechendem Bucket der Tabelle gespeichert.\\ + Belegungsfaktor BF = tatsächlich eingetragene Schlüssel / Indexmenge\\ + BF $<$ 50 \% $\rightarrow$ Verschwendung von Speicherplatz, BF $>$ 80\% $\rightarrow$ höhere Kollisionswahrscheinlichkeit.\\ + + Offenes Hashing: Behälter kann beliebig viele kollidierende Schlüssel aufnehmen (verkettete Liste).\\ + Geschlossenes Hashing: Behälter kann nur kleine konstante Anzahl von kollidierenden Schlüsseln aufnehmen. + \section{Bäume} + \subsection{Allgemeine Bäume} + Bäume erlauben es, hierarchische Beziehungen zwischen Objekten darzustellen.\\ + \\ + Liste: jedes Element hat einen Nachfolger\\ + Baum: jedes Element hat mehrere Nachfolger\\ + \includegraphics[width=0.5\linewidth]{baum}\\ + \\ + Höhe eines Knotens: Anzahl der Kanten des längsten Pfades zu einem Blatt.\\ + Höhe des Baumes: Höhe der Wurzel\\ + Bäume enthalten keine Zyklen.\\ + Verzweigungsgrad: Zahl der mögl. Nachfolger pro Element\\ + X ist Vater/Mutter von Y, fall es eine Kante von X nach Y gibt.\\ + X ist Kind von Y, falls es eine Kante von Y nach X gibt.\\ + X ist sibling eines Knoten Y, falls X und Y denselben direkten Vorgänger haben.\\ + X ist indirekter Vorgänger/Nachfolger von Y, falls es einen Pfad von X nach Y/Y nach X gibt.\\ + X ist ein Blatt, falls X keine Kinder hat.\\ + X ist ein innerer Knoten, falls X mind. ein Kind hat. + \newpage + \begin{defi}[Binärbäume] + Jeder Knoten hat nur 2 Nachfolger\\ + Der leere Baum ist ein Binärbaum.\\ + Wenn x ein Knoten ist und A und B Binärbäume sind, dann ist auch (AxB) ein Binärbaum.\\ + x heißt Wurzel, A linker Teilbaum, B rechter Teilbaum.\\ + Die Wurzeln von A und B heißen Kinder/Söhne von x, x ist ihr Elternknoten/Vaterknoten.\\ + Ein Knoten, dessen beide Kinder leere Bäume sind, heißt Blatt. + \end{defi} + \begin{tabular}{ll} + adt& BinTree\\ + sorts& BinTree, E, Boolean\\ + ops&\\ + & \begin{tabular}{@{}lll} + create: && $\rightarrow$ Bintree\\ + maketree:& BinTree $\times$ E $\times$ BinTree& $\rightarrow$ BinTree\\ + value:& BinTree & $\rightarrow$ E\\ + left, right: & BinTree & $\rightarrow$ BinTree\\ + leaf:& E & $\rightarrow$ BinTree\\ + isEmpty:& BinTree& $\rightarrow$ Boolean + \end{tabular}\\ + axs&\\ + & left(maketree(l,e,r))=l\\ + & right(maketree(l,e,r))=r\\ + & value(maketree(l,e,r))=e\\ + & leaf(v)= maketree(create,v,create)\\ + & isEmpty(create)=true\\ + & isEmpty(maketree(l,e,r)=false\\ + & ...\\ + end& BinTree + \end{tabular} + \begin{defi}[Allgemeine Bäume] + Anzahl der Kinder eines Knotens ist beliebig.\\ + Keine festen Positionen für Kinder.\\ + Rekursive Definition:\\ + 1. Der leere Baum ist ein (allgemeiner) Baum.\\ + 2. Wenn x ein Knoten ist und A1, … , An Bäume sind, dann ist auch das + n+1-Tupel (x, A1, … , An) ein Baum.\\ + \\ + Jeder Knoten speichert eine ArrayList von Referenzen auf seine Kinder + \end{defi} + andere Interpretation der Referenzen:\\ + \\ + \includegraphics[width=1\linewidth]{baumref} + \subsection{Binäre Suchbäume} + Bäume kann man sich als strukturelles Abbild des Teile-und- + Herrsche-Prinzips vorstellen, wenn man beim Zugriff jeweils + pro Knoten nur ein Kind weiterverfolgt.\\ + Eine solche Datenstruktur in Form eines Baums wird Suchbaum + genannt. Ein binärer Suchbaum hat max. zwei Kinder je Knoten.\\ + \newpage + \textbf{Traversierung, Besuchsreihenfolgen:}\\ + Breitensuche: Geschwister vor Kindern besuchen, noch zu besuchende Kntoen in Queue\\ + Tiefensuche: Kinder vor Geschwistern besuchen, noch zu besuchende Knoten auf Stack\\ + \begin{tabular}{@{}lllll} + Inorder: &\ \ \ \ \ & Preorder:&\ \ \ \ \ & Postorder:\\ + 1. linker Unterbaum&& 1. aktueller Knoten && 1. linker Unterbaum\\ + 2. aktueller Knoten&& 2. linker Unterbaum&& 2. rechter Unterbaum\\ + 3. rechter Unterbaum&& 3. rechter Unterbaum&& 3. aktueller Knoten\\ + \end{tabular} + \\ + \\ + \textbf{Klassifikation von Suchbäumen:}\\ + 1. Anzahl m der Kinder pro Knoten (Knotengrad):\\ + - Binärbaum: Anzahl $0\leq m\leq 2$\\ + - allgemeiner Baum: Anzahl beliebig\\ + 2. Speicherort der Nutzdaten:\\ + - natürlicher Baum: Nutzdaten werden bei jedem Knoten gespeichert.\\ + - Blattbaum/hohler Baum: Nutzdaten werden nur in Blattknoten gespeichert\\ + 3. Ausgewogenheit/Ausgeglichenheit/Balanciertheit:\\ + - balancierter Baum: die Höhen aller Unterbäume unterscheiden sich höchstens um $\Delta n$\\ + - vollständig ausgewogen: ANzahl der Knoten in Unterbäumen unterscheidet sich höchstens um 1\\ + - unbalancierter Baum: keine derartigen Einschränkungen\\ + \\ + \textbf{Suche nach einem Element:}\\ + - fange bei der Wurzel an\\ + - solange gesuchter Wert nicht gefunden:\\ + - falls gesuchter Wert kleiner als aktueller Wert: steige nach links ab\\ + - falls gesuchter Wert größer als aktueller Wert: steige nach rechts ab\\ + - falls kein entsprechendes Kind vorhanden: Wert nicht enthalten\\ + \textbf{Einfügen eines Wertes:}\\ + - Suche nach Einfügeposition mittels Suchalgorithmus\\ + - Einhängen des neuen Knotens an dieser Position\\ + \textbf{Löschen eines Wertes:}\\ + - Suche nach Knoten mittels Such-Algorithmus\\ + - falls zu löschender Knoten Blatt-Knoten ist: aus Baum entfernen\\ + - falls zu löschender Knoten kein Blatt-Knoten ist: Knoten ersetzen durch...\\ + - größten Knoten im linken Teilbaum oder kleinsten Knoten im rechten Teilbaum\\ + - dadurch ggf. weitere Ersetzungen in den Teilbäumen notwendig! + \subsection{AVL-Bäume} + Ein AVL-Baum ist ein binärer Suchbaum, in dem sich die Höhen seiner zwei Teilbäume höchstens um 1 unterscheiden. Wird dies durch Aktualisierungen verletzt, so muss sie durch eine Rebalancieroperation wieder hergestellt werden.\\ + \\ + Einfügen und Löschen wie bei Binärbaum, danach Rebalancierphase:\\ + In jedem Knoten wird dessen Balance geprüft: falls Knoten aus der Balance geraten, wird das durch eine Rebalancieroperation korrigiert.\\ + Balancefaktor eines Knoten: Differenz zw. Höhe des linken und Höhe des rechten Teilbaums\\ + Nach einer Einfügung genügt eine einzige Rotation oder Doppelrotation, um die Strukturinvariante des AVL-Baums (AVL-Bedingung) wiederherzustellen (und dabei die Suchbaumeigenschaft zu erhalten).\\ + \\ + Nachteile von AVL-Bäumen: zusätzlicher Platzbedarf in den Knoten zur Speicherung der Höhe oder der Balancefaktoren, komplizierte Implementierung\\ + \includegraphics[width=1\linewidth]{rotationavl} + \subsection{Halden} + Heap ist ein partiell geordneter Binärbaum.\\ + Max-Heap: Wurzel jedes Teilbaums ist größer als andere Knoten des Teilbaums\\ + Min-Heap: Wurzel jedes Teilbaums ist kleiner als andere Knoten des Teilbaums\\ + Verwendung als Prioritätswarteschlange\\ + effiziente Speicherung in Array möglich\\ + \\ + \textbf{Einfügen eines neuen Elements}\\ + - Element an die nächste freie Position in der untersten Ebene einfügen\\ + - falls Ebene voll: Element wird erster Knoten einer neuen Ebene\\ + - solange Halden-Eigenschaft in einem Teilbaum verletzt ist: \\ + \hspace*{3mm}Element entsprechend der Halden-Eigenschaft nach oben wandern lassen\\ + \textbf{Löschen eines Elements}\\ + - zu löschendes Element mit dem letzten Element ersetzen\\ + - solange Halden-Eigenschaft in einem Teilbaum verletzt ist:\\ + - Element entsprechend der Halden-Eigenschaft nach unten wandern lassen\\ + - Min-Heap: Tauschen mit kleinerem Kind\\ + - Max-Heap: Tauschen mit größerem Kind + \section{Sortieralgorithmen} + \textbf{internes Sortierverfahren:} + Alle Datensätze können gleichzeitig im Hauptspeicher gehalten werden. Direkter Zugriff auf alle Elemente ist möglich und erforderlich.\\ + \textbf{externes Sortierverfahren:} Sortieren von Massendaten, die auf externen Speichermedien gehalten werden. Zugriff ist auf einen Ausschnitt der Datenelemente beschränkt\\ + Sortieren durch Auswählen, Einfügen, Fachverteilen oder mittels Divide-and-Conquer-Verfahren\\ + Laufzeit: Vergleichsbasierte Sortierverfahren haben mindestens Laufzeit von O(n log n).\\ + in-situ: Sortierverfahren verwendet nur ein Array\\ + stabiles Sortierverfahren: gleiche Werte ändern ihre relative Reihenfolge nicht.\\ + \includegraphics[width=0.9\linewidth]{sortier}\\ + \textbf{SelectionSort}\\ + Lösche nacheinander die Maxima aus einer Liste und füge sie vorne an eine anfangs leere Ergebnisliste an.\\ + \textbf{InsertionSort}\\ + Starte mit erstem Element. Nimm jeweils das nächste Element und füge dieses an der richtigen Stelle in die Reihe ein.\\ + \textbf{BubbleSort}\\ + Das Array wird immer wieder durchlaufen und dabei werden benachbarte Elemente in die richtige Reihenfolge gebracht. Größere Elemente überholen so die kleineren und drängen an das Ende der Folge.\\ + \textbf{HeapSort}\\ + Die n zu sortierenden Elemente werden in eine max-Halde (min-Halde) eingefügt: Aufwand O(n log n). Dann wird n-mal das Maximum (Minimum) aus der Halde entnommen: Aufwand O(n log n).\\ + \textbf{MergeSort}\\ + falls zu sortierende Liste mehr als ein Element beinhaltet:\\ + - teile Liste in zwei kleinere Listen auf\\ + - verfahre rekursiv mit den beiden Teillisten\\ + - Listen mit maximal einem Element sind trivialerweise sortiert\\ + - verschmelze jeweils zwei sortierte Listen (Sortierung in verschmolzener Liste beibehalten)\\ + \textbf{QuickSort}\\ + falls zu sortierende Liste mehr als ein Element beinhaltet:\\ + - wähle ein Pivot-Element (zufälliges oder Median aus x Elementen wählen)\\ + - schiebe alle kleineren Elemente vor das Pivot-Element\\ + - schiebe alle größeren Elemente hinter das Pivot-Element\\ + - verfahre rekursiv mit den beiden Teillisten\\ + \textbf{BucketSort}\\ + Zu sortierende Werte sind ganze Zahlen zw. 0 und m-1. Man nutzt eine Menge von Behältern $B_0$ bis $B_{m-1}$, in die man alle Elemente passend einfügt. Am Ende schreibt man die Elemente in die Ergebnisfolge.\\ + \textbf{RadixSort}\\ + Voraussetzung: Elemente sind Zeichenfolgen über endlichem Alphabet, auf dessen Zeichen eine Totalordnung definiert ist. Für jedes Zeichen steht ein Fach zur Verfügung. \\ + Einzelne Stellen aller Elemente von hinten nach vorne abarbeiten.\\ + Partitionieren: Elemente abhängig von der aktuellen Stelle in das passende Fach legen.\\ + Einsammeln: Elemente wieder aus den Fächern nehmen vom 'kleinsten' Fach zum 'größten' Fach. + \section{Graphen und Graphalgorithmen} + \subsection{Grundbegriffe} + Ein Graph ist ein Paar $G=(V, E)$, wobei gilt:\\ + 1. V ist eine endliche nichtleere Menge (Knoten)\\ + 2. E ist eine zweistellige Relation\\ + Ein Pfad von v nach w ist eine endliche Folge von Knoten. Die Länge eines Pfades ist die Anzahl der Kanten im Pfad. Ein Pfad heißt einfach, wenn alle Knoten im Pfad paarweise verschieden sind.\\ + \\ + In einem gerichteten Graphen heißt ein Pfad der Länge von v nach v ein Zyklus. Ein Zyklus von v nach v heißt minimaler Zyklus, wenn außer v kein anderer Knoten mehr als einmal vorkommt. Bei ungerichteten Graphen muss ein Zyklus mindestens drei Knoten enthalten.\\ + \\ + Die Anzahl der direkten Vorgänger eines Knotens heißt Eingangsgrad des Knotens. Die Anzahl der direkten Nachfolger eines Knotens heißt Ausgangsgrad des Knotens. Bei ungerichteten Graphen spricht man vom Grad des Knotens.\\ + Ein Knoten mit Grad 0/* heißt Quelle. Ein Knoten mit Grad */0 heißt Senke.\\ + \\ + Ein gerichteter Graph heißt stark zusammenhängend (oder: stark verbunden), wenn es für alle v, w einen Pfad von v nach w gibt. Bei ungerichteten Graphen lässt man stark weg. Anschaulich: Jeder Knoten ist von jedem anderen Knoten aus erreichbar. Ein gerichteter Graph heißt schwach zusammenhängend, + wenn der zugehörige ungerichtete Graph (der durch Hinzunahme aller Rückwärtskanten entsteht) zusammenhängend ist.\\ + \\ + Sind G ein Graph und S ein zyklenfreier Teilgraph von G, der alle Knoten von G enthält, und sind G und S beide zusammenhängend, dann heißt S Spannbaum (auch: aufspannender Baum) von G. S ist ein minimaler Spannbaum, falls S ein Spannbaum von G ist, und die Summe der Kantengewichte in S kleiner oder gleich der aller anderen Spannbäume S' von G ist.\\ + Ein Knoten v eines gerichteten azyklischen Graphen (DAG) heißt Wurzel, falls es keine auf ihn gerichteten Kanten gibt.\\ + \\ + Ein Graph wird zu einem bewerteten/gewichteten Graphen, indem man eine Gewichtsfunktion ergänzt, die jeder Kante ein positives Gewicht zuordnet. Die Kosten eines Pfades definiert man in gewichteten Graphen als die Summe der Gewichte seiner Kanten. + \subsection{Darstellungen von Graphen} + Adjazenzmatrix: boolesche $n\times n$ Matrix mit $A_{ij} = true$, falls $(v_i,v_j)\in E$ und $A_{ij} = false$ sonst.\\ + Bei bewerteten/gewichteten Graphen speichert man statt true/false die Kantengewichte in der Matrix. Fehlende Kanten stellt man mit einem Spezialwert für Unendlich dar.\\ + Diese Repräsentation wählen, wenn Tests auf das Vorhandensein von Kanten häufig vorkommen.\\ + Adjazenzliste: Man verwaltet für jeden der n Knoten eine Liste seiner Nachfolger/Nachbarknoten + \subsection{Graphdurchlauf} + Tiefensuche: entspricht einem Preorder-Durchlauf von G, der jeweils in einem bereits besuchten Knoten von G abgebrochen wird.\\ + Die Tiefensuche durchläuft die Knoten eines Graphen in einer bestimmten Reihenfolge. Wenn jedem Knoten die Position in dieser Reihenfolge zugeordnet wird, ist das eine DFS-Nummerierung.\\ + Wenn v.dfsNr $<$ w.dfsNr, dann ist v Vorfahre von w in T.\\ + Breitensuche: besucht die Knoten von G ebenenweise, also zuerst die Knoten, die über einen Pfad der Länge 1 von der Wurzel aus erreichbar sind, dann über einen Pfad der Länge 2 usw. In einem bereits besuchten Knoten von G wird abgebrochen. + \subsection{Kürzeste Wege in Graphen} + Dijkstra:\\ + für alle Knoten gespeichert: Distanz, Vorgänger und 'besucht'-Markierung\\ + - Initialisierung:\\ + - Startknoten mit Distanz 0, alle anderen Knoten mit Distanz $\infty $\\ + - markiere alle Knoten als unbesucht\\ + - solange es noch unbesuchte Knoten im Graphen gibt:\\ + \hspace*{5mm}- wähle den Knoten v mit der geringsten Distanz aus (Min-Heap)\\ + \hspace*{5mm}- markiere diesen Knoten v als besucht\\ + \hspace*{5mm}- für alle unbesuchten Nachbarn u des aktuellen Knoten v\\ + \hspace*{10mm}- berechne die Länge des Pfades über v nach u:\\ + \hspace*{13mm}Gewicht = Pfad vom Startknoten nach v + Gewicht der Kante (v, u)\\ + \hspace*{10mm}- falls das berechnete Gewicht kleiner als die gespeicherte Distanz ist, dann\\ + \hspace*{13mm}a) aktualisiere die Distanz auf den neuen Wert\\ + \hspace*{13mm}b) speichere Knoten v als Vorgänger von u\\ + \\ + Floyd:\\ + es existiert eine direkte Kante $v\rightarrow w$ genau dann, wenn ein Pfad von v nach w existiert, der nur Knoten aus der Ursprungsmenge als Zwischenknoten verwendet. Der kürzeste derartie Pfad hat Kosten $\alpha$. + \subsection{Minimaler Spannbaum} + Algorithmus von Prim:\\ + Wähle einen beliebigen Knoten als Startgraph T.\\ + Solange T noch nicht alle Knoten enthält, führe aus:\\ + \hspace*{5mm} Wähle eine Kante e mit minimalen Kosten aus, die einen noch nicht in T enthaltenen Knoten v \\ + \hspace*{5mm} mit T verbindet. Füge e und v dem Graphen T hinzu.\\ + \\ + Algorithmus von Kruskal:\\ + gieriger Algorithmus, in jedem Schritt die kleinste Kante wählen, die 'nichts kaputt macht'\\ + - Eingabe: Graph G, dessen minimaler Spannbaum S bestimmt werden soll\\ + - S enthält zu Anfang nur die Knoten von G und keine Kanten\\ + - sortiere die Kanten von G aufsteigend nach ihrem Gewicht\\ + - solange S noch nicht zusammenhängend ist, betrachte die nächste Kante\\ + - wenn diese zwei getrennte Komponenten von S verbindet, dann zu S hinzufügen, andernfalls nicht + \section{Geometrische Algorithmen} + \begin{tabular}{@{}ll} + Punkt:& n-Tupel im n-dimensionalen Raum (n Koordinaten)\\ + Gerade:& Linie durch zwei beliebige Punkte\\ + Strecke:& Linie durch ihre beiden Endpunkte\\ + Streckenzug:& Folge von Strecken (Kanten), bei der der Endpunkt (Knoten) einer Strecke der \\ + & Anfangspunkt der nächsten Strecke ist\\ + Polygon:& der Anfangspunkt der ersten Strecke ist Endpunkt der letzten\\ + innen:& Polygon, dessen Kanten sich nicht kreuzen, umrahmt eine Region, deren Punkte innen sind\\ + konvex:& Polygon ist konvex, wenn jede Strecke zwischen zwei seiner Punkte komplett im Inneren \\ + & des Polygons liegt + \end{tabular}\\ + \\ + + \textbf{Punkt-in-Polygon-Problem}\\ + Wähle Punkt 'unendlich' weit außen und verbinde ihn mit dem Punkt P. Gehe auf der Verbindung in Richtung P.\\ + Wenn eine Polygonkante gekreuzt wird und wir außen (a) sind, gehen wir nach innen (i). Wenn eine Polygonkante gekreuzt wird und wir innen (i) sind, gehen wir + nach außen (a).\\ + \textbf{Konstruktion von Polygonen}\\ + Punkte zu Polygon verbinden\\ + Radius einer Kreisscheibe über alle Punkte rotieren. Verbinde den letzten zum Polygon hinzugefügten Punkt mir dem nächsten vom Radius überstrichenen Punkt. Als Mittelpunkt einen Randpunkt der Punktmenge wählen.\\ + \\ + \textbf{Konvexe Hülle}\\ + Die konvexe Hülle einer Punktmenge ist das kleinste konv. Polygon, das alle Punkte in seinem Innern hat.\\ + Beginne mit einem Polygon aus beliebigen drei Punkten der gegebenen Punktmenge. Wähle beliebigen noch nicht bearbeiteten Punkt P (möglichst weit außen). Liegt er außerhalb des bisher erzeugten Polygons, dann modifiziere die bisher gefundene Hülle, sodass sie den neuen Punkt enthält.\\ + Einpackalgorithmus: Beginne mit einem äußersten Punkt (z.B. äußerst links) und Schnur nach unten. Verbinde immer zu dem Punkt, den bei Drehung gegen den + Uhrzeigersinn die Einwickelschnur als nächstes erreicht (stützende Kante).\\ + \\ + \textbf{Ballung und nächstes Paar}\\ + Problem: Punktmenge soll in homogene Klassen eingeteilt werden.\\ + Zweck: ohne a-priori-Wissen bestimmen, was zusammengehört bzw. was sich ähnlich ist.\\ + Scharfe Klassifikation: Punkte werden zu Klassen zusammengefasst, sodass jeder Punkt genau zu einer Klasse gehört.\\ + Der Heterogenitätsindex einer Klasse gibt an, wie gut die Punkte einer Klasse zusammenpassen. \\ + Der Güteindex einer Klassifikation bewertet eine Klassifikation.\\ + Hierarchische Verfahren:\\ + - zusammenfassend/agglomerativ: zu Beginn enthält jede Klasse genau einen Punkt. \\ + \hspace*{3mm}Füge in jedem Schritt die zwei am wenigsten entfernten Klassen zusammen.\\ + - zerteilend/divisiv: beginne mit einer Klasse, die alle Punkte enthält. \\ + \hspace*{3mm}Teile in jedem Schritt eine Klasse in zwei Unterklassen.\\ + Für jede pro Schritt entstehende Klassifikation wird ein Güteindex berechnet. Wähle die Klassifikation, bei der sich im nächsten Schritt der Güteindex nur noch gering verbessern würde.\\ + \\ + Finde nächstes Paar: Diejenigen zwei Punkte einer Punktmenge mit geringstem gegenseitigen Abstand. \\ + Einfacher Algorithmus: Berechne alle Distanzen, wähle das Paar mit der kleinsten Distanz. +\end{document} \ No newline at end of file diff --git a/horschtey_zusammenfassungen/aud/dowhile.png b/horschtey_zusammenfassungen/aud/dowhile.png new file mode 100644 index 0000000..18a7fe3 Binary files /dev/null and b/horschtey_zusammenfassungen/aud/dowhile.png differ diff --git a/horschtey_zusammenfassungen/aud/exceptionhierachy.png b/horschtey_zusammenfassungen/aud/exceptionhierachy.png new file mode 100644 index 0000000..a717e9b Binary files /dev/null and b/horschtey_zusammenfassungen/aud/exceptionhierachy.png differ diff --git a/horschtey_zusammenfassungen/aud/ifelse.png b/horschtey_zusammenfassungen/aud/ifelse.png new file mode 100644 index 0000000..6d0f98e Binary files /dev/null and b/horschtey_zusammenfassungen/aud/ifelse.png differ diff --git a/horschtey_zusammenfassungen/aud/instanzklasse.PNG b/horschtey_zusammenfassungen/aud/instanzklasse.PNG new file mode 100644 index 0000000..720fcc9 Binary files /dev/null and b/horschtey_zusammenfassungen/aud/instanzklasse.PNG differ diff --git a/horschtey_zusammenfassungen/aud/rotationavl.PNG b/horschtey_zusammenfassungen/aud/rotationavl.PNG new file mode 100644 index 0000000..e7b60d4 Binary files /dev/null and b/horschtey_zusammenfassungen/aud/rotationavl.PNG differ diff --git a/horschtey_zusammenfassungen/aud/sortier.PNG b/horschtey_zusammenfassungen/aud/sortier.PNG new file mode 100644 index 0000000..66c52a1 Binary files /dev/null and b/horschtey_zusammenfassungen/aud/sortier.PNG differ diff --git a/horschtey_zusammenfassungen/aud/uml.png b/horschtey_zusammenfassungen/aud/uml.png new file mode 100644 index 0000000..17b4af0 Binary files /dev/null and b/horschtey_zusammenfassungen/aud/uml.png differ diff --git a/horschtey_zusammenfassungen/aud/while.png b/horschtey_zusammenfassungen/aud/while.png new file mode 100644 index 0000000..722eb2d Binary files /dev/null and b/horschtey_zusammenfassungen/aud/while.png differ diff --git a/horschtey_zusammenfassungen/gti/1erkomplement.png b/horschtey_zusammenfassungen/gti/1erkomplement.png new file mode 100644 index 0000000..8e90d5d Binary files /dev/null and b/horschtey_zusammenfassungen/gti/1erkomplement.png differ diff --git a/horschtey_zusammenfassungen/gti/2erkomplement.png b/horschtey_zusammenfassungen/gti/2erkomplement.png new file mode 100644 index 0000000..322ac74 Binary files /dev/null and b/horschtey_zusammenfassungen/gti/2erkomplement.png differ diff --git a/horschtey_zusammenfassungen/gti/CMOS.png b/horschtey_zusammenfassungen/gti/CMOS.png new file mode 100644 index 0000000..c065348 Binary files /dev/null and b/horschtey_zusammenfassungen/gti/CMOS.png differ diff --git a/horschtey_zusammenfassungen/gti/Fails1.PNG b/horschtey_zusammenfassungen/gti/Fails1.PNG new file mode 100644 index 0000000..312cbac Binary files /dev/null and b/horschtey_zusammenfassungen/gti/Fails1.PNG differ diff --git a/horschtey_zusammenfassungen/gti/Fails2.PNG b/horschtey_zusammenfassungen/gti/Fails2.PNG new file mode 100644 index 0000000..584b914 Binary files /dev/null and b/horschtey_zusammenfassungen/gti/Fails2.PNG differ diff --git a/horschtey_zusammenfassungen/gti/GrayCode.PNG b/horschtey_zusammenfassungen/gti/GrayCode.PNG new file mode 100644 index 0000000..a44e4f6 Binary files /dev/null and b/horschtey_zusammenfassungen/gti/GrayCode.PNG differ diff --git a/horschtey_zusammenfassungen/gti/Huffmancode4.png b/horschtey_zusammenfassungen/gti/Huffmancode4.png new file mode 100644 index 0000000..8e9d32a Binary files /dev/null and b/horschtey_zusammenfassungen/gti/Huffmancode4.png differ diff --git a/horschtey_zusammenfassungen/gti/Informationsgehalt.PNG b/horschtey_zusammenfassungen/gti/Informationsgehalt.PNG new file mode 100644 index 0000000..66f3e82 Binary files /dev/null and b/horschtey_zusammenfassungen/gti/Informationsgehalt.PNG differ diff --git a/horschtey_zusammenfassungen/gti/Parity.PNG b/horschtey_zusammenfassungen/gti/Parity.PNG new file mode 100644 index 0000000..5b02517 Binary files /dev/null and b/horschtey_zusammenfassungen/gti/Parity.PNG differ diff --git a/horschtey_zusammenfassungen/gti/Parity2.PNG b/horschtey_zusammenfassungen/gti/Parity2.PNG new file mode 100644 index 0000000..aa974fd Binary files /dev/null and b/horschtey_zusammenfassungen/gti/Parity2.PNG differ diff --git a/horschtey_zusammenfassungen/gti/Subtrahieren.PNG b/horschtey_zusammenfassungen/gti/Subtrahieren.PNG new file mode 100644 index 0000000..fba8291 Binary files /dev/null and b/horschtey_zusammenfassungen/gti/Subtrahieren.PNG differ diff --git a/horschtey_zusammenfassungen/gti/activehigh.PNG b/horschtey_zusammenfassungen/gti/activehigh.PNG new file mode 100644 index 0000000..c4d0209 Binary files /dev/null and b/horschtey_zusammenfassungen/gti/activehigh.PNG differ diff --git a/horschtey_zusammenfassungen/gti/activelow.PNG b/horschtey_zusammenfassungen/gti/activelow.PNG new file mode 100644 index 0000000..85e9568 Binary files /dev/null and b/horschtey_zusammenfassungen/gti/activelow.PNG differ diff --git a/horschtey_zusammenfassungen/gti/addierer.PNG b/horschtey_zusammenfassungen/gti/addierer.PNG new file mode 100644 index 0000000..92ecf4d Binary files /dev/null and b/horschtey_zusammenfassungen/gti/addierer.PNG differ diff --git a/horschtey_zusammenfassungen/gti/array.PNG b/horschtey_zusammenfassungen/gti/array.PNG new file mode 100644 index 0000000..3d493c6 Binary files /dev/null and b/horschtey_zusammenfassungen/gti/array.PNG differ diff --git a/horschtey_zusammenfassungen/gti/arraydiv.PNG b/horschtey_zusammenfassungen/gti/arraydiv.PNG new file mode 100644 index 0000000..af9d10f Binary files /dev/null and b/horschtey_zusammenfassungen/gti/arraydiv.PNG differ diff --git a/horschtey_zusammenfassungen/gti/arraymult.PNG b/horschtey_zusammenfassungen/gti/arraymult.PNG new file mode 100644 index 0000000..ac6b8ca Binary files /dev/null and b/horschtey_zusammenfassungen/gti/arraymult.PNG differ diff --git a/horschtey_zusammenfassungen/gti/auto1.PNG b/horschtey_zusammenfassungen/gti/auto1.PNG new file mode 100644 index 0000000..b6a3a72 Binary files /dev/null and b/horschtey_zusammenfassungen/gti/auto1.PNG differ diff --git a/horschtey_zusammenfassungen/gti/auto2.PNG b/horschtey_zusammenfassungen/gti/auto2.PNG new file mode 100644 index 0000000..6e8fc90 Binary files /dev/null and b/horschtey_zusammenfassungen/gti/auto2.PNG differ diff --git a/horschtey_zusammenfassungen/gti/auto3.PNG b/horschtey_zusammenfassungen/gti/auto3.PNG new file mode 100644 index 0000000..ce7062f Binary files /dev/null and b/horschtey_zusammenfassungen/gti/auto3.PNG differ diff --git a/horschtey_zusammenfassungen/gti/auto4.PNG b/horschtey_zusammenfassungen/gti/auto4.PNG new file mode 100644 index 0000000..b9cd1d2 Binary files /dev/null and b/horschtey_zusammenfassungen/gti/auto4.PNG differ diff --git a/horschtey_zusammenfassungen/gti/auto5.PNG b/horschtey_zusammenfassungen/gti/auto5.PNG new file mode 100644 index 0000000..61729ad Binary files /dev/null and b/horschtey_zusammenfassungen/gti/auto5.PNG differ diff --git a/horschtey_zusammenfassungen/gti/buendelstoerung.png b/horschtey_zusammenfassungen/gti/buendelstoerung.png new file mode 100644 index 0000000..c65d66d Binary files /dev/null and b/horschtey_zusammenfassungen/gti/buendelstoerung.png differ diff --git a/horschtey_zusammenfassungen/gti/cla.PNG b/horschtey_zusammenfassungen/gti/cla.PNG new file mode 100644 index 0000000..1675875 Binary files /dev/null and b/horschtey_zusammenfassungen/gti/cla.PNG differ diff --git a/horschtey_zusammenfassungen/gti/document.tex b/horschtey_zusammenfassungen/gti/document.tex new file mode 100644 index 0000000..1fb023c --- /dev/null +++ b/horschtey_zusammenfassungen/gti/document.tex @@ -0,0 +1,889 @@ +\documentclass[12pt,a4paper]{article} +\usepackage[utf8]{inputenc} +\usepackage{amsmath} +\usepackage{amsfonts} +\usepackage{amssymb} +\usepackage{graphicx} +\usepackage{picins} +\usepackage{thmbox} +\parindent0pt +\usepackage[left=1.00cm, right=1.00cm, top=1.00cm, bottom=1.00cm]{geometry} +\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{lol}{} + \renewcommand{\thelol}{\hspace{-0,5em}} + \pagestyle{empty} + \section{Einführung} + Technische Informatik ist diejenige Disziplin der Informatik, + die sich mit dem Entwurf von Systemen in Hard- und + Software beschäftigt. + \section{Funktion und Struktur} + \begin{defi}[System] + wird im Zusammenhang mit natürlichen, technischen und organisatorischen Gebilden mit komplexem Erscheinungsbild eingesetzt.\\ + Fülle an Merkmalen: Grad der Bestimmtheit, Entstehungsweise, örtliche und zeitliche Konzentriertheit, Zeitabhängigkeit\\ + Umfasst stets kleine Anteile - Untersysteme, Komponenten, Module, Bausteine, Elemente $\Rightarrow$ Objekte.\\ + Zwischen den Objekten eines Systems müssen Beziehungen materieller, energetischer und informationeller Natur bestehen. Gesamtheit dieser Beziehungen bildet zusammen mit den Objekten die Struktur des Systems, eine abgeschlossene Einheit. Nur über definierte Schnittstellen kann ein System betreten und verlassen werden. + \end{defi} + Darstellung:\\ + externe Sicht für Benutzer: keine Aussagen über interne Realisierung des Systems \\ + interne Sicht nur für den Hersteller und Betreiber: geeignete Beschreibungsmöglichkeit durch Funktion F\\ + Komplexe Systeme werden unterteilt in überschaubare Teilsysteme und einzeln bearbeitet. Einstufige Verfeinerung reicht meist nicht aus, deshalb mehrstufige Verfeinerung. Zwei Möglichkeiten: Top-Down-Prinzip oder Bottom-Up-Prinzip + \section{Nachricht und Signal} + \begin{defi}[Information] + Information ist nicht allgemein definiert, jedoch in der Gemeinsprache als Kenntnis über reale oder gedankliche Sachverhalte und Vorgänge bekannt.\\ + Nachrichten: Weitergabe von Information\\ + Daten: Verarbeitung von Informationen\\ + Zeichen: ein Element aus einer endlichen Menge von Objekten\\ + Alphabet: Zeichenvorrat, zur Darstellung von Information vereinbart\\ + Symbol: Zeichen mit bestimmter Bedeutung\\ + Signal: Die Darstellung von Nachrichten oder Daten mit physikalischen Mitteln + \end{defi} + Nur diskrete Signale, kontinuierliche Signale sind physikalisch und messtechnisch nicht möglich + \begin{defi}[Typen von Signalen] + Zeitdiskrete Signale: wertkontinuierlich, wobei man diskrete Abtastzeitpunkte hat\\ + Wertdiskrete Signale: zeitkontinuierlich + \end{defi} + In der Digitaltechnik hat man zeitdiskrete und wertdiskrete Signale. Ein Digitalwert repräsentiert immer ein Intervall an Werten. Grenzwerte werden durch undefinierte Bereiche überbrückt. + \begin{defi}[Binärsignale] + Signaldarstellung: Auswahl aus zwei Werten\\ + Binärsignal enthält Informationen von 1 Bit. Zur Abstraktion werden die Signale häufig als 0 und 1 bezeichnet. Da ein einziges Binärsignal nicht reicht, um Informationen weiterzuleiten, setzt man Binärsignale zusammen. Mit n Binärzahlen lassen sich $2^n$ unterschiedliche Kombinationen darstellen + \end{defi} + \section{Information und Codierung} + \subsection{Informationsgehalt} + \begin{defi}[Informationsgehalt] + Voraussetzung: Zeichen voneinander unabhängig\\ + $I(x)= ld \dfrac{1}{p(x)} = -ld p(x)$\\ + Zeichen werden quantitativ im Vergleich zu anderen Zeichen oder im Hinblick auf technischen Darstellungsaufwand bewertet (je seltener, desto mehr Information).\\ + 1 bit entspricht der elementaren Entscheidung zwischen zwei gleichwahrscheinlichen Möglichkeiten: $p(x) = 0.5$\\ + Für ein Alphabet mit N Zeichen gilt: $\sum\limits_{i=1}^{N} p (x_i) = 1 $ + \end{defi} + In einer Zeichenfolge mit L Zeichen ist die zu erwartende Häufigkeit eines speziellen Zeichens $x_i: L \cdot p(x_i)$\\ + Aus der zu erwartenden Häufigkeit und dem Informationsgehalt eines Zeichens, kann man den durchschnittlichen Informationsgehalt einer Quelle berechnen. + \begin{defi}[Entropie] + Alle beobachteten Zeichen des Typs $x_i$ liefern insgesamt den Informationsgehalt \[L\cdot p(x_i)\cdot I(x_i)=L\cdot p(x_i)\cdot ld \frac{1}{p(x_i)}\] + Wenn alle N Zeichen des Alphabets zusammen betrachtet werden, ist der durchschnittliche Informationsgehalt der Quelle (H ist Entropie der Quelle): + \[H=\sum_{i=1}^{N} p(x_i) \cdot ld \dfrac{1}{p(x_i)}\] + \end{defi} + \subsection{Codierung und Fehlerkorrektur} + \begin{defi}[Codewörter] + Code ist Vorschrift für eindeutige Zuordnung (Codierung). \\ + Die Zuordnung muss nicht umkehrbar eindeutig sein.\\ + Codewörter sind elementare Einheiten zur Darstellung von Informationen. Die max. Anzahl der Codewörter im Binären ist $2^m$.\\ + Anzahl strukturierter m-stelliger Codewörter mit genau k Einsen: $\binom{m}{k}=\dfrac{m!}{k!\cdot (m-k)!}$ + \end{defi} + \begin{defi}[Hammingdistanz HD] + Seien $CW_i$, $CW_j$ Binärvektoren und $HD_{ij}$ die Anzahl der Stellen, an denen sich $CW_i$ und $CW_j$ unterscheiden. Dann heißt $HD_ij$ die Hammingdistanz zwischen $CW_i$ und $CW_j$.\\ + Die Hammingdistanz zwischen zwei gleich langen Codewörtern gibt also die Anzahl der unterschiedlichen Binärstellen an. + \end{defi} + \begin{defi}[Minimale Hammingdistanz $HD_{min}$] + Gibt an, wie weit alle Codewörter aus einer Menge mindestens auseinander sind. Somit ist die minimale Hammingdistanz eine entscheidende Eigenschaft eines Codes, um Übertragungsfehler erkennen und korrigieren zu können. + \end{defi} + Bei einschrittigen Codes ist die Hammingdistanz zweier benachbarter Codes immer 1, z.B. Gray Code. + \subsubsection{Codes für Fehlererkennung/Fehlerkorrektur} + Fehlerschutz umfasst Fehlererkennung und Fehlerkorrektur. Diese Schutzwirkung wird durch Codierung realisiert.\\ + \\ + Es gibt mehrere Arten von Fehlern: Bitfehler, Burstfehler und Symbolfehler.\\ + Allgemein gilt: Geeignete Codes können Fehler erkennen und sogar korrigieren. Notwendig ist dabei die Hinzufügung von zusätzlichen/redundanten Informationen bzw. Bits. Es ist wichtig, dass man eine Systematik des Codes festlegt, z.b. minimale Hammingdistanz, Paritätsbits, Blocksicherungsverfahren, Hamming-Codes.\\ + \begin{defi}[Paritätsbit-Prüfverfahren] + Es wird ein zusätzliches Paritätsbit angehängt. Im Binärwort enthaltene Einsen werden entweder auf gerade oder ungerade Anzahl geprüft und an den Code angehängt. Die Überprüfung erfolgt beim Empfänger.\\ + Das Prinzip der Paritätssicherung ist zweidimensional anwendbar (heißt dann Blocksicherung). Dabei wird die Nachricht in Blöcke von n Codewörtern mit Paritätsbit eingeteilt. Zusätzlich wird am Ende jedes Blocks ein weiteres Codewort eingefügt, das alle Paritätsbits der Spalten enthält.\\ + Bei Auftreten von Einfachfehlern lassen sich dadurch Spalte und Zeile eindeutig ermitteln. Somit sind Einfachfehler korrigierbar und Bündelstörungen sind erkennbar.\\ + \end{defi} + \subsection{Hamming-Codes} + Mehrfachfehler korrigieren: + \begin{satz} [Zusammenhang zwischen $HD_{min}$ und Anzahl erkennbarer / korrigierbarer Fehler] + a) Sei $X \subseteq \{0,1\}^n$ ein Code mit $HD_{min}(x)=d$, Dann sind bis zu (d-1) Fehler erkennbar\\ + b) Sei $HD_{min}(X)=d=2e + 1$, Dann sind bis zu $e=((d-1)/2)$ Fehler korrigierbar + \end{satz} + Die Hammingdistanz kann man anhand eines Prüfbits erweitern, jedoch nicht durch weitere Prüfbits. + \subsubsection{Konstruktion von Hamming-Codes} + Stellen $x_i$ und $y_i$ lassen sich gemeinsam in einem Schema darstellen, das der Binärdarstellung ab dem Wert 1 entspricht.\\ + Prüfstellen $y_i$ besitzen nur eine einzige 1 in einer Spalte. \\ + Alle anderen Spalten stellen von rechts die Stellen $x_i$ dar. \\ + Eine Prüfstelle $y_i$ überprüft alle Informationsstellen $x_i$, die in der Zeile, in der $y_i$ den Wert 1 besitzt, selbst eine 1 in der Tabelle haben.\\ + \\ + \includegraphics[width=0.7\linewidth]{hammingcodes}\\ + \\ + Allgemein gilt: \\ + Bei m Informationsstellen $x_i$ werden k Prüfstellen $y_j$ zur Bildung des Hamming-Codes benötigt:\\ + $2^k - k - 1 \geq m$ + \subsection{Nachrichtenübertragung und Optimale Codes} + Ziele bei Nachrichtenübertragung:\\ + $\Rightarrow$ Darstellungsaufwand minimieren, wenig Bits\\ + $\Rightarrow$ Schutz gegen Verfälschungen und typische Fehlerfälle + \subsubsection{Bündelstörung} + Problem: längere Auswirkung einer Störung auf ein Signal, dadurch können mehrere Bits nacheinander gestört werden. \\ + Lösung: Scrambling von Datensequenzen + \begin{center} + \includegraphics[width=0.5\linewidth]{buendelstoerung} + \end{center} + Länger anhaltender Störeinfluss verfälscht nur Binärstellen von unterschiedlichen Codewörtern\\ + $\Rightarrow$ eine Störung mehrerer Bits ist damit erkennbar, denn pro Codewort ist nur 1 Bit verfälscht. + \subsubsection{Optimale Codes} + Optimale Codes versuchen, die im Mittel auftretende durchschnittliche Codewortlänge zu minimieren.\\ + Der minimal erreichbare Idealwert ist dabei der durchschnittliche Informationsgehalt des Zeichenvorrats.\\ + Häufig auftretende Buchstaben $\rightarrow$ möglichst kurze Codewörter,\\ + seltene Buchstaben $\rightarrow$ längere Codewörter\\ + \begin{defi}[Präfix-freie Codierung] + Kein Codewort ist Präfix eines anderen Codewortes, also kein Codewort darf den Beginn eines anderen Codewortes darstellen. + \end{defi} + \begin{defi}[Shannon-Fano-Code] + Zeichenvorrat nach aufsteigender Wahrscheinlichkeit linear sortieren, danach 2 Teilmengen so konstruieren, dass die Summenwahrscheinlichkeiten der beiden Teilmengen möglichst gleich groß sind. Solange wiederholen, bis nur noch 1 Zeichen in resultierenden Teilmengen enthalten ist. + \end{defi} + \begin{defi}[Huffman-Code] + Binärer Codierungsbaum repräsentiert Codewörter mit variabler Bitlänge, präfix-freie Codierung\\ + erzeugt optimalen Code\\ + \\ + Vorgehensweise: + \begin{enumerate} + \item Finde aus sortierter Liste die beiden Zeichen mit niedrigster Auftrittshäufigkeit (=AH) + \item Verschmelze die Zeichen zu neuem Element, dessen AH die Summe der beiden Einzelwahrscheinlichkeiten zugeordnet wird. Sortiere neues Element in Liste. + \item Abbruch, wenn nur noch 1 Objekt in Liste übrig + \end{enumerate} + \end{defi} + \newpage + \subsection{JPEG-Komprimierung} + \begin{enumerate} + \item Aufteilung des Bildes in 8x8-Pixelblöcke + \item Schnelle diskrete Cosinustransformation (FDCT): transformiert Daten aus Ortsbereich in Frequenzbereich. + \[ F(u,v)=\frac{1}{4} C_u C_v \sum_{x=0}^{7}\sum_{y=0}^{7} f(x,y) \cos \frac{(2y+1)u\pi}{16} \cos\frac{(2x+1)v\pi}{16} \] + \[C_u, C_v = \frac{1}{\sqrt{2}}\text{ für } u,v=0; 1 \text{ für } u,v=1...7\] + \item Quantisierung mithilfe einer Quantisierungsmatrix $Q(u,v)$, der eigentlich verlustbehaftete Vorgang in der Codierung. \\ + Ziel: möglichst viele Nullen in die Transformationsmatrix\\ + Ansatz: Menschliche Wahrnehmung viel empfindlicher für kleine Variation in Farbe und Helligkeit als für hochfrequente Schwankungen. \\ + $\Rightarrow$ Quantisierungsfaktoren für niederfrequente Koeffizienten kleiner wählen als für hochfrequente. + \item Umsortierung der Matrix mittels Zig-Zag-Verfahren, Sequenz mit möglichst langen Nullfolgen \\ + \includegraphics[width=0.7\linewidth]{umsortierung} + \item Lauflängencodierung mithilfe der Huffman-Codierung\\ + \includegraphics[width=0.7\linewidth]{lauflaengencodeirung} + \end{enumerate} + + \newpage + \subsection{Zahlensysteme} + \begin{defi}[Polyadische Zahlensysteme] + geben Ziffern ihren Wert in Abhängigkeit von ihrer Stelle innerhalb einer systematischen stellenorientierten Anordnung. \\ + Die Stellen werten entsprechen den Potenzen der Basis R des jeweiligen Zahlensystems.\\ + Aufbau allgemein: + \[ N= d_{n-1}\cdot R^{n-1}+\dots + d_1\cdot R^1+d_0\cdot R^0 \] + $N$: Zahl im Zahlensystem\\ + $R$: Basis\\ + $R^i$: Wertigkeit der i-ten Stelle\\ + $d_i$: Ziffer der Stelle i\\ + $Z$: Menge der Ziffern + \end{defi} + Bin $\rightarrow$ Hex: 4 Stellen zusammenfassen, Bin $\rightarrow$ Okt: 3 Stellen zusammenfassen\\ + Wenn anderes zum Umrechnen: Division durch Basis R des neuen Systems. Letzter Wert ist vorderste/linkeste Stelle der neuen Zahl in R.\\ + \begin{defi}[BCD-Code (Binary Coded Decimal)] + Jede Dezimalziffer ist durch 4-Bit Dualzahl dargestellt. \\ + Die nicht verwendeten BCDs werden Pseudotetraden genannt.\\ + Bei Addition muss zu Pseudotetraden und bei jedem Übertrag noch $6_{10}=0110_2$ addiert werden. + \end{defi} + \begin{defi}[Gleitkommazahlen] + Darstellung von Zahlen durch Vorzeichen (1 Bit), Exponent (8 Bit) und Mantisse (23 Bit)\\ + $Zahl = (-1)^V\cdot 2^{E-127}\cdot 1,M$\\ + Vorzeichen: $V=0 \Rightarrow$ positiv, $V=1 \Rightarrow$ negativ\\ + Mantisse: Die Mantisse ist normalisiert, d.h. dass vor dem Komma genau eine 1 steht. Diese wird nicht gespeichert, sondern nur die Nachkommastellen.\\ + Exponent: Der Exponent wird berechnet durch Subtraktion einer Verschiebedistanz (Bias): E-127. Dadurch ist E immer positiv.\\ + \\ + Spezialwerte:\\ + \begin{tabular}{@{}cc|cc} + Biased Exponent E & Mantisse M & Wert &\\ + $0$\\ + \hspace*{10mm}sequence\_of\_statements\\ + \hspace*{5mm}\{ when choice =$>$\\ + \hspace*{10mm}sequence\_of\_statements \}\\ + \hspace*{5mm}$[$ when others =$>$\\ + \hspace*{10mm}sequence\_of\_statements $]$\\ + end case;\\ + \\ + \textbf{Bereitstellung von Bibliotheken:}\\ + library IEEE;\\ + use IEEE.std\_logic\_1164.all;\\ + use IEEE.std\_logic\_misc.all;\\ + use IEEE.std\_logic\_arith.all;\\ + use IEEE.std\_logic\_components.all;\\ + \\ + \textbf{Entities:} beschreibt die Schnittstelle eines Moduls.\\ + Die port\_liste ist eine Liste der Ein- und Ausgänge (identifier : PORT\_MODUS Datentyp)\\ + ENTITY half\_adder IS\\ + \hspace*{5mm}PORT(\\ + \hspace*{10mm}i\_x : IN bit;\\ + \hspace*{10mm}i\_y : IN bit;\\ + \hspace*{10mm}i\_enable : IN bit;\\ + \hspace*{10mm}o\_carry : OUT bit;\\ + \hspace*{10mm}o\_result : OUT bit\\ + \hspace*{5mm});\\ + END half\_adder;\\ + \\ + \textbf{Architecture:} beschreibt den inneren Aufbau und die Funktion eines Moduls\\ + 1. Datenflussbeschreibung: eignet sich für reinkombinatorische, ungetaktete Logik. \\ + \hspace*{5mm}Durch ausschließliche Verwendung nebenläufiger Signale möglich.\\ + 2. Verhaltensbeschreibung: keine reinen Logikgleichungen, sondern Verhalten wird auf algorithmischer \\ + \hspace*{5mm}Ebene beschrieben. Im Allgemeinen übersichtlicher und weniger fehlerträchtig. \\ + \hspace*{5mm}Durch Verwendung von Prozessen möglich.\\ + 3. Strukturbeschreibung: Hierarchisches Design aus Komponenten, die durch eigene VHDL-Module \\ + \hspace*{5mm} beschrieben sind. Im Wesentlichen Umsetzung eines Schaltplans/Blockdiagramms: Instanziierung der \\ + \hspace*{5mm}Komponenten und Verdrahtung\\ + \newpage + ARCHITECTURE architecture\_name OF entity\_name IS\\ + -- Deklaration nur intern genutzter Signale\\ + BEGIN\\ + -- Body aus nebenläufigen Prozessen und Anweisungen\\ + \hspace*{5mm}Prozess (PROCESS): enthält sequentielle Anweisungen, z.B.\\ + \hspace*{5mm}process (i\_enable, i\_x, i\_y) is \ \ \ --- Sensitivitätsliste, enthält Signale, die das Ergebnis beeinflussen\\ + \hspace*{10mm}begin\\ + \hspace*{15mm} -- sequentielle Abarbeitung der Befehle -- \\ + \hspace*{5mm}end process;\\ + \hspace*{5mm}Prozess (PROCESS): enthält sequentielle Anweisungen\\ + \hspace*{5mm}nebenläufige Anweisung (concurrent statement);\\ + \hspace*{5mm}nebenläufige Anweisung (concurrent statement);\\ + \hspace*{5mm}nebenläufige Anweisung (concurrent statement);\\ + END [ARCHITECTURE] architecture\_name;\\ + \\ + \\ + Komponenten einarbeiten:\\ + architecture structure of full\_adder is\\ + \hspace*{5mm}component half\_adder\\ + \hspace*{10mm}port (i\_x, i\_y, i\_enable: in std\_logic;\\ + \hspace*{15mm}o\_result, o\_carry: out std\_logic );\\ + \hspace*{5mm}end component;\\ + \hspace*{5mm}signal c1, s1, c2 : std\_logic;\\ + begin\\ + \hspace*{5mm}HA1: half\_adder port map (\\ + \hspace*{10mm}i\_x $=>$ a, i\_y $=>$b, i\_enable $=>$ i\_enable, o\_result $=>$ s1, o\_carry $=>$ c1);\\ + \hspace*{5mm}HA2: half\_adder port map (s1, cin, i\_enable, sum, c2);\\ + \hspace*{5mm}cout $<=$ c1 or c2;\\ + end architecture structure;\\ + \\ + \\ + VHDL-Operatoren:\\ + - Logische Operatoren: and, or, nand, nor, xor\\ + - Relationale Operatoren: =, /=, $<$, $<$=, $>$, $>$=\\ + - Addition und Konkatenation: +, -, \&\\ + - Vorzeichen: +, -\\ + - Multiplikation: *, /, mod, rem\\ + - Exponent, Absolutbetrag, Komplement: **, abs, not\\ + \\ + Arrays:\\ + \includegraphics[width=1\linewidth]{array}\\ + Rechnungen auf std\_logic\_vector sind zu vermeiden, da teilweise gar nicht synthetisierbar. + \subsection*{Konstanten, Variablen, Signale} + Konstanten: der Wert einer Konstante kann nicht verändert werden.\\ + Variablen unterscheiden sich nicht von Variablen anderer höheren Programmiersprachen und werden im Rahmen von Zwischenrechnungen verwendet. Eine Variable hat kein Gegenstück in der Hardware!\\ + Zuweisung einer Variable: target\_variable := value\_expression;\\ + Variablen werden in Prozessen / Unterprogrammen deklariert und sind auch nur da sichtbar. \\ + Variablen werden zum Abspeichern temporärer Werte benutzt.\\ + Wertzuweisung bei Variablen erfolgt sofort, wenn die Variablenzuweisung ausgeführt wird.\\ + Signale sind in anderen Programmiersprachen nicht zu finden. Ein Signal kann man als verbindende physikalische Leitung bzw. als Register ansehen.\\ + Zuweisung eines Signals: target\_signal $<=$ value\_expression;\\ + Signale können nicht in Prozessen / Unterprogrammen deklariert werden.\\ + Signale stehen üblicherweise für Verbindungen oder Register in der Hardware.\\ + Wertzuweisung bei Signalen erfolgt nicht sofort, wenn die Signalzuweisung ausgeführt wird.\\ + - Die Signalzuweisung aktualisiert den Signaltreiber.\\ + - Der Signaltreiber gibt die Information an die Signale erst an das Signal weiter, wenn der Prozess \\ + \hspace*{3mm}angehalten hat. + \subsection*{Automaten} + Taktsteuerung: + \includegraphics[width=0.7\linewidth]{steuerung}\\ + \includegraphics[width=1\linewidth]{pegelflanke} + Definition der Zustandsmenge eines Automaten durch einen benutzerdefinierten Typ empfehlenswert, denn die Kodierung hat einen erheblichen Einfluss auf die Geschwindigkeit, die Störungsstabilität und die Fläche der synthetisierten Schaltung\\ + type my\_type is (S0, S1, S2);\\ + \\ + \textbf{Verzögerung und Zeit}:\\ + 1. träge Verzögerung (inertial delay), output $<$= NOT input AFTER 10 ns;\\ + \hspace*{5mm}erlaubt dem Benutzer, die Verzögerungszeit eines Gatters oder einer Operation anzugeben, und \\ + \hspace*{5mm}absorbiert Eingangssignale, die kürzer sind als die spezifzierte Verzögerungszeit\\ + 2. nichtträge Verzögerung (transport delay), output $<$= TRANSPORT NOT input AFTER 10 ns;\\ + \hspace*{5mm}gibt alle Eingangsimpulse weiter + + + + + + + + + + + + + + + + + + + + + + +\end{document} \ No newline at end of file diff --git a/horschtey_zusammenfassungen/gti/flanken.PNG b/horschtey_zusammenfassungen/gti/flanken.PNG new file mode 100644 index 0000000..5d98982 Binary files /dev/null and b/horschtey_zusammenfassungen/gti/flanken.PNG differ diff --git a/horschtey_zusammenfassungen/gti/frequenzteiler.PNG b/horschtey_zusammenfassungen/gti/frequenzteiler.PNG new file mode 100644 index 0000000..95407e9 Binary files /dev/null and b/horschtey_zusammenfassungen/gti/frequenzteiler.PNG differ diff --git a/horschtey_zusammenfassungen/gti/gatter.png b/horschtey_zusammenfassungen/gti/gatter.png new file mode 100644 index 0000000..59d90da Binary files /dev/null and b/horschtey_zusammenfassungen/gti/gatter.png differ diff --git a/horschtey_zusammenfassungen/gti/gatter2.png b/horschtey_zusammenfassungen/gti/gatter2.png new file mode 100644 index 0000000..259e360 Binary files /dev/null and b/horschtey_zusammenfassungen/gti/gatter2.png differ diff --git a/horschtey_zusammenfassungen/gti/getakt.PNG b/horschtey_zusammenfassungen/gti/getakt.PNG new file mode 100644 index 0000000..5898245 Binary files /dev/null and b/horschtey_zusammenfassungen/gti/getakt.PNG differ diff --git a/horschtey_zusammenfassungen/gti/hammingcodes.PNG b/horschtey_zusammenfassungen/gti/hammingcodes.PNG new file mode 100644 index 0000000..8e44eb1 Binary files /dev/null and b/horschtey_zusammenfassungen/gti/hammingcodes.PNG differ diff --git a/horschtey_zusammenfassungen/gti/inverter1.png b/horschtey_zusammenfassungen/gti/inverter1.png new file mode 100644 index 0000000..30a933d Binary files /dev/null and b/horschtey_zusammenfassungen/gti/inverter1.png differ diff --git a/horschtey_zusammenfassungen/gti/inverter2.png b/horschtey_zusammenfassungen/gti/inverter2.png new file mode 100644 index 0000000..509a13f Binary files /dev/null and b/horschtey_zusammenfassungen/gti/inverter2.png differ diff --git a/horschtey_zusammenfassungen/gti/inverter3.png b/horschtey_zusammenfassungen/gti/inverter3.png new file mode 100644 index 0000000..8d102b7 Binary files /dev/null and b/horschtey_zusammenfassungen/gti/inverter3.png differ diff --git a/horschtey_zusammenfassungen/gti/jkflipflop.PNG b/horschtey_zusammenfassungen/gti/jkflipflop.PNG new file mode 100644 index 0000000..31444ff Binary files /dev/null and b/horschtey_zusammenfassungen/gti/jkflipflop.PNG differ diff --git a/horschtey_zusammenfassungen/gti/lauflaengencodeirung.png b/horschtey_zusammenfassungen/gti/lauflaengencodeirung.png new file mode 100644 index 0000000..05373ed Binary files /dev/null and b/horschtey_zusammenfassungen/gti/lauflaengencodeirung.png differ diff --git a/horschtey_zusammenfassungen/gti/masterslave.PNG b/horschtey_zusammenfassungen/gti/masterslave.PNG new file mode 100644 index 0000000..37b5af8 Binary files /dev/null and b/horschtey_zusammenfassungen/gti/masterslave.PNG differ diff --git a/horschtey_zusammenfassungen/gti/multi.PNG b/horschtey_zusammenfassungen/gti/multi.PNG new file mode 100644 index 0000000..083fad0 Binary files /dev/null and b/horschtey_zusammenfassungen/gti/multi.PNG differ diff --git a/horschtey_zusammenfassungen/gti/nand.png b/horschtey_zusammenfassungen/gti/nand.png new file mode 100644 index 0000000..223f20d Binary files /dev/null and b/horschtey_zusammenfassungen/gti/nand.png differ diff --git a/horschtey_zusammenfassungen/gti/nmos1.png b/horschtey_zusammenfassungen/gti/nmos1.png new file mode 100644 index 0000000..a95018a Binary files /dev/null and b/horschtey_zusammenfassungen/gti/nmos1.png differ diff --git a/horschtey_zusammenfassungen/gti/nmos2.png b/horschtey_zusammenfassungen/gti/nmos2.png new file mode 100644 index 0000000..24912ff Binary files /dev/null and b/horschtey_zusammenfassungen/gti/nmos2.png differ diff --git a/horschtey_zusammenfassungen/gti/nor.png b/horschtey_zusammenfassungen/gti/nor.png new file mode 100644 index 0000000..e68c8ef Binary files /dev/null and b/horschtey_zusammenfassungen/gti/nor.png differ diff --git a/horschtey_zusammenfassungen/gti/pa1.png b/horschtey_zusammenfassungen/gti/pa1.png new file mode 100644 index 0000000..fa608fb Binary files /dev/null and b/horschtey_zusammenfassungen/gti/pa1.png differ diff --git a/horschtey_zusammenfassungen/gti/pa2.png b/horschtey_zusammenfassungen/gti/pa2.png new file mode 100644 index 0000000..1e2e3cc Binary files /dev/null and b/horschtey_zusammenfassungen/gti/pa2.png differ diff --git a/horschtey_zusammenfassungen/gti/pal.PNG b/horschtey_zusammenfassungen/gti/pal.PNG new file mode 100644 index 0000000..bd8fc3a Binary files /dev/null and b/horschtey_zusammenfassungen/gti/pal.PNG differ diff --git a/horschtey_zusammenfassungen/gti/pegelflanke.PNG b/horschtey_zusammenfassungen/gti/pegelflanke.PNG new file mode 100644 index 0000000..5b5e5da Binary files /dev/null and b/horschtey_zusammenfassungen/gti/pegelflanke.PNG differ diff --git a/horschtey_zusammenfassungen/gti/pla.PNG b/horschtey_zusammenfassungen/gti/pla.PNG new file mode 100644 index 0000000..05065a9 Binary files /dev/null and b/horschtey_zusammenfassungen/gti/pla.PNG differ diff --git a/horschtey_zusammenfassungen/gti/pmos1.png b/horschtey_zusammenfassungen/gti/pmos1.png new file mode 100644 index 0000000..fc93086 Binary files /dev/null and b/horschtey_zusammenfassungen/gti/pmos1.png differ diff --git a/horschtey_zusammenfassungen/gti/pmos2.png b/horschtey_zusammenfassungen/gti/pmos2.png new file mode 100644 index 0000000..3ae5d36 Binary files /dev/null and b/horschtey_zusammenfassungen/gti/pmos2.png differ diff --git a/horschtey_zusammenfassungen/gti/querschnitt.png b/horschtey_zusammenfassungen/gti/querschnitt.png new file mode 100644 index 0000000..d0060ab Binary files /dev/null and b/horschtey_zusammenfassungen/gti/querschnitt.png differ diff --git a/horschtey_zusammenfassungen/gti/realcmos.png b/horschtey_zusammenfassungen/gti/realcmos.png new file mode 100644 index 0000000..1082ae3 Binary files /dev/null and b/horschtey_zusammenfassungen/gti/realcmos.png differ diff --git a/horschtey_zusammenfassungen/gti/regischda.jpg b/horschtey_zusammenfassungen/gti/regischda.jpg new file mode 100644 index 0000000..052b8ec Binary files /dev/null and b/horschtey_zusammenfassungen/gti/regischda.jpg differ diff --git a/horschtey_zusammenfassungen/gti/register.PNG b/horschtey_zusammenfassungen/gti/register.PNG new file mode 100644 index 0000000..565d878 Binary files /dev/null and b/horschtey_zusammenfassungen/gti/register.PNG differ diff --git a/horschtey_zusammenfassungen/gti/registerfeld.PNG b/horschtey_zusammenfassungen/gti/registerfeld.PNG new file mode 100644 index 0000000..892b95c Binary files /dev/null and b/horschtey_zusammenfassungen/gti/registerfeld.PNG differ diff --git a/horschtey_zusammenfassungen/gti/rom.PNG b/horschtey_zusammenfassungen/gti/rom.PNG new file mode 100644 index 0000000..5d31366 Binary files /dev/null and b/horschtey_zusammenfassungen/gti/rom.PNG differ diff --git a/horschtey_zusammenfassungen/gti/schaltnorm.png b/horschtey_zusammenfassungen/gti/schaltnorm.png new file mode 100644 index 0000000..ab4377a Binary files /dev/null and b/horschtey_zusammenfassungen/gti/schaltnorm.png differ diff --git a/horschtey_zusammenfassungen/gti/schieberegister.PNG b/horschtey_zusammenfassungen/gti/schieberegister.PNG new file mode 100644 index 0000000..17c4c00 Binary files /dev/null and b/horschtey_zusammenfassungen/gti/schieberegister.PNG differ diff --git a/horschtey_zusammenfassungen/gti/schieberegister1.PNG b/horschtey_zusammenfassungen/gti/schieberegister1.PNG new file mode 100644 index 0000000..642d552 Binary files /dev/null and b/horschtey_zusammenfassungen/gti/schieberegister1.PNG differ diff --git a/horschtey_zusammenfassungen/gti/steuerung.PNG b/horschtey_zusammenfassungen/gti/steuerung.PNG new file mode 100644 index 0000000..13e7f18 Binary files /dev/null and b/horschtey_zusammenfassungen/gti/steuerung.PNG differ diff --git a/horschtey_zusammenfassungen/gti/sub.PNG b/horschtey_zusammenfassungen/gti/sub.PNG new file mode 100644 index 0000000..212b077 Binary files /dev/null and b/horschtey_zusammenfassungen/gti/sub.PNG differ diff --git a/horschtey_zusammenfassungen/gti/transistor1.png b/horschtey_zusammenfassungen/gti/transistor1.png new file mode 100644 index 0000000..a5d830e Binary files /dev/null and b/horschtey_zusammenfassungen/gti/transistor1.png differ diff --git a/horschtey_zusammenfassungen/gti/transistor2.png b/horschtey_zusammenfassungen/gti/transistor2.png new file mode 100644 index 0000000..afe5c15 Binary files /dev/null and b/horschtey_zusammenfassungen/gti/transistor2.png differ diff --git a/horschtey_zusammenfassungen/gti/ueberlauf.png b/horschtey_zusammenfassungen/gti/ueberlauf.png new file mode 100644 index 0000000..3ad7ae1 Binary files /dev/null and b/horschtey_zusammenfassungen/gti/ueberlauf.png differ diff --git a/horschtey_zusammenfassungen/gti/ula.PNG b/horschtey_zusammenfassungen/gti/ula.PNG new file mode 100644 index 0000000..8082107 Binary files /dev/null and b/horschtey_zusammenfassungen/gti/ula.PNG differ diff --git a/horschtey_zusammenfassungen/gti/umsortierung.png b/horschtey_zusammenfassungen/gti/umsortierung.png new file mode 100644 index 0000000..52ccfa1 Binary files /dev/null and b/horschtey_zusammenfassungen/gti/umsortierung.png differ diff --git a/horschtey_zusammenfassungen/gti/vhdl.PNG b/horschtey_zusammenfassungen/gti/vhdl.PNG new file mode 100644 index 0000000..518047c Binary files /dev/null and b/horschtey_zusammenfassungen/gti/vhdl.PNG differ diff --git a/horschtey_zusammenfassungen/konzmod/ERModell.jpg b/horschtey_zusammenfassungen/konzmod/ERModell.jpg new file mode 100644 index 0000000..36e77f3 Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/ERModell.jpg differ diff --git a/horschtey_zusammenfassungen/konzmod/Unbenannt.PNG b/horschtey_zusammenfassungen/konzmod/Unbenannt.PNG new file mode 100644 index 0000000..629de10 Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/Unbenannt.PNG differ diff --git a/horschtey_zusammenfassungen/konzmod/Unbenannt1.PNG b/horschtey_zusammenfassungen/konzmod/Unbenannt1.PNG new file mode 100644 index 0000000..9291b58 Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/Unbenannt1.PNG differ diff --git a/horschtey_zusammenfassungen/konzmod/aktivitaet.png b/horschtey_zusammenfassungen/konzmod/aktivitaet.png new file mode 100644 index 0000000..6fcc20e Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/aktivitaet.png differ diff --git a/horschtey_zusammenfassungen/konzmod/aktivitet.PNG b/horschtey_zusammenfassungen/konzmod/aktivitet.PNG new file mode 100644 index 0000000..dadccaa Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/aktivitet.PNG differ diff --git a/horschtey_zusammenfassungen/konzmod/assert.PNG b/horschtey_zusammenfassungen/konzmod/assert.PNG new file mode 100644 index 0000000..84f0ef0 Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/assert.PNG differ diff --git a/horschtey_zusammenfassungen/konzmod/bspmer.PNG b/horschtey_zusammenfassungen/konzmod/bspmer.PNG new file mode 100644 index 0000000..f349359 Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/bspmer.PNG differ diff --git a/horschtey_zusammenfassungen/konzmod/consider.PNG b/horschtey_zusammenfassungen/konzmod/consider.PNG new file mode 100644 index 0000000..9910221 Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/consider.PNG differ diff --git a/horschtey_zusammenfassungen/konzmod/datawarehouse.PNG b/horschtey_zusammenfassungen/konzmod/datawarehouse.PNG new file mode 100644 index 0000000..8dce152 Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/datawarehouse.PNG differ diff --git a/horschtey_zusammenfassungen/konzmod/dbgrundlage.png b/horschtey_zusammenfassungen/konzmod/dbgrundlage.png new file mode 100644 index 0000000..04e9462 Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/dbgrundlage.png differ diff --git a/horschtey_zusammenfassungen/konzmod/document.tex b/horschtey_zusammenfassungen/konzmod/document.tex new file mode 100644 index 0000000..19ff699 --- /dev/null +++ b/horschtey_zusammenfassungen/konzmod/document.tex @@ -0,0 +1,23 @@ +\documentclass[12pt,a4paper]{article} +\usepackage[utf8]{inputenc} +\usepackage{amsmath} +\usepackage{amsfonts} +\usepackage{amssymb} +\usepackage{graphicx} +\parindent0pt +\usepackage{thmbox} +\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}} + +\end{document} \ No newline at end of file diff --git a/horschtey_zusammenfassungen/konzmod/document2.tex b/horschtey_zusammenfassungen/konzmod/document2.tex new file mode 100644 index 0000000..013fb05 --- /dev/null +++ b/horschtey_zusammenfassungen/konzmod/document2.tex @@ -0,0 +1,1236 @@ +\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}} + \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} \ No newline at end of file diff --git a/horschtey_zusammenfassungen/konzmod/er1.png b/horschtey_zusammenfassungen/konzmod/er1.png new file mode 100644 index 0000000..ddd3245 Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/er1.png differ diff --git a/horschtey_zusammenfassungen/konzmod/er2.png b/horschtey_zusammenfassungen/konzmod/er2.png new file mode 100644 index 0000000..fc718e5 Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/er2.png differ diff --git a/horschtey_zusammenfassungen/konzmod/er3.png b/horschtey_zusammenfassungen/konzmod/er3.png new file mode 100644 index 0000000..3a19538 Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/er3.png differ diff --git a/horschtey_zusammenfassungen/konzmod/er4.png b/horschtey_zusammenfassungen/konzmod/er4.png new file mode 100644 index 0000000..5a92246 Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/er4.png differ diff --git a/horschtey_zusammenfassungen/konzmod/er5.png b/horschtey_zusammenfassungen/konzmod/er5.png new file mode 100644 index 0000000..cab9b51 Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/er5.png differ diff --git a/horschtey_zusammenfassungen/konzmod/er6.png b/horschtey_zusammenfassungen/konzmod/er6.png new file mode 100644 index 0000000..b95d91d Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/er6.png differ diff --git a/horschtey_zusammenfassungen/konzmod/generalisierung.PNG b/horschtey_zusammenfassungen/konzmod/generalisierung.PNG new file mode 100644 index 0000000..877bc73 Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/generalisierung.PNG differ diff --git a/horschtey_zusammenfassungen/konzmod/ignore.PNG b/horschtey_zusammenfassungen/konzmod/ignore.PNG new file mode 100644 index 0000000..77d8125 Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/ignore.PNG differ diff --git a/horschtey_zusammenfassungen/konzmod/kapitel4.png b/horschtey_zusammenfassungen/konzmod/kapitel4.png new file mode 100644 index 0000000..ad9da88 Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/kapitel4.png differ diff --git a/horschtey_zusammenfassungen/konzmod/kardinalitaet.png b/horschtey_zusammenfassungen/konzmod/kardinalitaet.png new file mode 100644 index 0000000..7048786 Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/kardinalitaet.png differ diff --git a/horschtey_zusammenfassungen/konzmod/kraehe.png b/horschtey_zusammenfassungen/konzmod/kraehe.png new file mode 100644 index 0000000..54a99a1 Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/kraehe.png differ diff --git a/horschtey_zusammenfassungen/konzmod/logischesschemabsp.PNG b/horschtey_zusammenfassungen/konzmod/logischesschemabsp.PNG new file mode 100644 index 0000000..38136ef Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/logischesschemabsp.PNG differ diff --git a/horschtey_zusammenfassungen/konzmod/lsutiegr.PNG b/horschtey_zusammenfassungen/konzmod/lsutiegr.PNG new file mode 100644 index 0000000..12bef83 Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/lsutiegr.PNG differ diff --git a/horschtey_zusammenfassungen/konzmod/mehrwertig.PNG b/horschtey_zusammenfassungen/konzmod/mehrwertig.PNG new file mode 100644 index 0000000..0205a14 Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/mehrwertig.PNG differ diff --git a/horschtey_zusammenfassungen/konzmod/meta.PNG b/horschtey_zusammenfassungen/konzmod/meta.PNG new file mode 100644 index 0000000..ce58dcb Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/meta.PNG differ diff --git a/horschtey_zusammenfassungen/konzmod/neg.PNG b/horschtey_zusammenfassungen/konzmod/neg.PNG new file mode 100644 index 0000000..9af30da Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/neg.PNG differ diff --git a/horschtey_zusammenfassungen/konzmod/ordnung.jpg b/horschtey_zusammenfassungen/konzmod/ordnung.jpg new file mode 100644 index 0000000..a19e283 Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/ordnung.jpg differ diff --git a/horschtey_zusammenfassungen/konzmod/pfeilnotation.png b/horschtey_zusammenfassungen/konzmod/pfeilnotation.png new file mode 100644 index 0000000..e63e111 Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/pfeilnotation.png differ diff --git a/horschtey_zusammenfassungen/konzmod/rekursion.PNG b/horschtey_zusammenfassungen/konzmod/rekursion.PNG new file mode 100644 index 0000000..7fdfd1d Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/rekursion.PNG differ diff --git a/horschtey_zusammenfassungen/konzmod/schleifen.jpg b/horschtey_zusammenfassungen/konzmod/schleifen.jpg new file mode 100644 index 0000000..4e61aca Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/schleifen.jpg differ diff --git a/horschtey_zusammenfassungen/konzmod/semantik.PNG b/horschtey_zusammenfassungen/konzmod/semantik.PNG new file mode 100644 index 0000000..7fa5200 Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/semantik.PNG differ diff --git a/horschtey_zusammenfassungen/konzmod/sequenz.jpg b/horschtey_zusammenfassungen/konzmod/sequenz.jpg new file mode 100644 index 0000000..c8f02b2 Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/sequenz.jpg differ diff --git a/horschtey_zusammenfassungen/konzmod/starsnowflake.PNG b/horschtey_zusammenfassungen/konzmod/starsnowflake.PNG new file mode 100644 index 0000000..cd9dd8f Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/starsnowflake.PNG differ diff --git a/horschtey_zusammenfassungen/konzmod/uml1.PNG b/horschtey_zusammenfassungen/konzmod/uml1.PNG new file mode 100644 index 0000000..781205c Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/uml1.PNG differ diff --git a/horschtey_zusammenfassungen/konzmod/uml2.PNG b/horschtey_zusammenfassungen/konzmod/uml2.PNG new file mode 100644 index 0000000..18e7f6f Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/uml2.PNG differ diff --git a/horschtey_zusammenfassungen/konzmod/uml3.PNG b/horschtey_zusammenfassungen/konzmod/uml3.PNG new file mode 100644 index 0000000..ff15e89 Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/uml3.PNG differ diff --git a/horschtey_zusammenfassungen/konzmod/uml4.PNG b/horschtey_zusammenfassungen/konzmod/uml4.PNG new file mode 100644 index 0000000..8508f76 Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/uml4.PNG differ diff --git a/horschtey_zusammenfassungen/konzmod/uml5.jpg b/horschtey_zusammenfassungen/konzmod/uml5.jpg new file mode 100644 index 0000000..46dedf9 Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/uml5.jpg differ diff --git a/horschtey_zusammenfassungen/konzmod/uml6.jpg b/horschtey_zusammenfassungen/konzmod/uml6.jpg new file mode 100644 index 0000000..1f0074a Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/uml6.jpg differ diff --git a/horschtey_zusammenfassungen/konzmod/uml7.jpg b/horschtey_zusammenfassungen/konzmod/uml7.jpg new file mode 100644 index 0000000..821ae8b Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/uml7.jpg differ diff --git a/horschtey_zusammenfassungen/konzmod/uml8.jpg b/horschtey_zusammenfassungen/konzmod/uml8.jpg new file mode 100644 index 0000000..1ad46fe Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/uml8.jpg differ diff --git a/horschtey_zusammenfassungen/konzmod/uml9.jpg b/horschtey_zusammenfassungen/konzmod/uml9.jpg new file mode 100644 index 0000000..586f319 Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/uml9.jpg differ diff --git a/horschtey_zusammenfassungen/konzmod/umldiagramme.PNG b/horschtey_zusammenfassungen/konzmod/umldiagramme.PNG new file mode 100644 index 0000000..b41acfa Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/umldiagramme.PNG differ diff --git a/horschtey_zusammenfassungen/konzmod/usecase.PNG b/horschtey_zusammenfassungen/konzmod/usecase.PNG new file mode 100644 index 0000000..a6165d2 Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/usecase.PNG differ diff --git a/horschtey_zusammenfassungen/konzmod/variation.png b/horschtey_zusammenfassungen/konzmod/variation.png new file mode 100644 index 0000000..c0ed992 Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/variation.png differ diff --git a/horschtey_zusammenfassungen/konzmod/variation2.png b/horschtey_zusammenfassungen/konzmod/variation2.png new file mode 100644 index 0000000..6e608f5 Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/variation2.png differ diff --git a/horschtey_zusammenfassungen/konzmod/xpath.png b/horschtey_zusammenfassungen/konzmod/xpath.png new file mode 100644 index 0000000..d9b0a32 Binary files /dev/null and b/horschtey_zusammenfassungen/konzmod/xpath.png differ diff --git a/horschtey_zusammenfassungen/mathe/document.tex b/horschtey_zusammenfassungen/mathe/document.tex new file mode 100644 index 0000000..0b7bb39 --- /dev/null +++ b/horschtey_zusammenfassungen/mathe/document.tex @@ -0,0 +1,1037 @@ +\documentclass[12pt,a4paper]{article} +\usepackage[utf8]{inputenc} +\usepackage{amsmath} +\usepackage{amsfonts} +\usepackage{amssymb} +\usepackage{graphicx} +\parindent0pt +\usepackage{thmbox} +\usepackage[left=1.00cm, right=1.00cm, top=1.00cm, bottom=1.00cm]{geometry} +\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}} + \pagestyle{empty} + \section{Grundlagen} + \subsection{Aussagenlogik} + \begin{defi}[Bivalenzprinzip] + Jede Aussage ist entweder wahr oder falsch $\Rightarrow$ extreme Präzision gefordert\\ + Aussagen können Variablen enthalten + \end{defi} + \begin{defi}[Aussagen] + definierende Gleichheit: $:=$\\ + $A\wedge B$ (A und B)ist genau dann wahr, wenn beide wahr sind.\\ + $A\vee B$ (A oder B) ist genau dann wahr, wenn eins von beiden wahr ist.\\ + $A\Leftrightarrow B$ (A äquivalent B) ist genau dann wahr, wenn beide denselben Wahrheitswert besitzen.\\ + $A\Rightarrow B$ (Implikation, aus A folgt B) ist genau dann wahr, wenn beide Werte gleich sind oder A falsch ist. + \end{defi} + + \begin{defi}[Äquivalenzen] + \begin{tabular}{@{}llcll} + (i)& A $\vee$ B& $\Rightarrow$& B $\vee$ A& Kommutativgesetz\\ + (ii)& A $\wedge$ B& $\Rightarrow$& B $\wedge$ A& Kommutativgesetz\\ + (iii)& (A $\vee$ B) $\vee$ C& $\Rightarrow$& A $\vee$ (B $\vee$ C)& Assoziativgesetz\\ + (iv)& (A $\wedge$ B) $\wedge$ C& $\Rightarrow$& A $\wedge$ (B $\wedge$ C)& Assoziativgesetz\\ + (v)& (A $\vee$ B) $\wedge$ C& $\Rightarrow$& (A $\wedge$ C) $\vee$ (B $\wedge$ C)& Distributivgesetz\\ + (vi)& (A $\wedge$ B) $\vee$ C& $\Rightarrow$& (A $\vee$ C) $\wedge$ (B $\vee$ C)& Distributivgesetz\\ + (vii)& $\neg$(A $\vee$ B)& $\Rightarrow$& $\neg$A $\wedge$ $\neg$B& de Morgan - Regel\\ + (viii)& $\neg$(A $\wedge$ B)& $\Rightarrow$& $\neg$A $\vee$ $\neg$B& de Morgan - Regel\\ + (ix)& $\neg$ $\neg$A& $\Rightarrow$& A& doppelte Negation\\ + (x)& (A $\Rightarrow$ B)& $\Rightarrow$& ($\neg$A $\vee$ B)& Charakterisierung der Implikation\\ + (xi)& (A $\Rightarrow$ B)& $\Rightarrow$& ($\neg$B $\Rightarrow$ $\neg$A)& Prinzip der Kontraposition/Widerspruchsbeweis\\ + (xii)& A $\vee$ $\neg$A& $\Rightarrow$& wahr& Tertium non datur\\ + (xiii)& A $\wedge$ $\neg$A& $\Rightarrow$& falsch& Tertium non datur\\ + (xiv)& A $\vee$ wahr& $\Rightarrow$& wahr& Absorption\\ + (xv)& A $\vee$ falsch& $\Rightarrow$& A & Absorption\\ + (xvi)& A $\wedge$ wahr& $\Rightarrow$& A & Absorption\\ + (xvii)& A $\wedge$ falsch& $\Rightarrow$& falsch & Absorption\\ + \end{tabular} + \end{defi} + \begin{defi}[Quantoren] + $\forall$: Allquantor, dh. für alle gilt, $\neg \forall$ entspricht $\exists\neg$\\ + $\exists$: Existenzquantor, dh. es existiert ein..., sodass, $\neg \exists$ entspricht $\forall\neg$\\ + Bei gleichartigen Quantoren darf die Reihenfolge vertauscht werden, sonst nicht.\\ + Bei Negation ändert sich immer die Art des Quantors:\\ + $\neg(\forall x\in M: A(x))\Leftrightarrow \exists x\in M: \neg A(x)$\\ + $\neg(\exists x\in M: A(x))\Leftrightarrow \forall x\in M: \neg A(x)$ + \end{defi} + \subsection{Mengen} + \begin{defi}[Mengendefinition nach Cantor] + Eine Menge ist eine Zusammenfassung von wohlbestimmten und wohlunterschiedenen Objekten zu einem Ganzen. Die Objekte heißen Elemente der Menge.\\ + Ist $a$ ein Element der Menge $M$, so schreiben wir $a\in M$, anderenfalls $a\notin M$. + \end{defi} + \begin{defi}[Teilmengen] + $M \ N :\Leftrightarrow \forall a \in M: a \in N \Leftrightarrow \forall a: (a\in M \Rightarrow a \in N)$ + \end{defi} + \begin{defi}[Gleichheit von Mengen] + $M=N :\Leftrightarrow M \ N \wedge N \ M$ + \end{defi} + \begin{defi}[Potenzmenge] + Menge aller Teilmengen von M:\\ + $P(M):=\{U|U\subseteq M\}$ + \end{defi} + \begin{defi}[Verknüpfung von Mengen] + $A \cup B := [x|x\in A \vee x\in B]$ (Vereinigung)\\ + $A\cap B := [x|x\in A \wedge x\in B]$ (Schnitt)\\ + $A\setminus B := [x|x\in A \wedge x\notin B]$ (Differenz, A ohne B) + \end{defi} + \begin{defi}[Paarmenge (Cartesisches Produkt)] + $A\times B := \{(a,b)|a\in A \wedge b \in B\}$ + \end{defi} + \begin{defi}[Verknüpfungsregeln für Mengen] + \begin{tabular}{@{}llcl} + (i)& A $\cap$ B& =& B $\cap$ A\\ + (ii)& A $\cup$ B& =& B $\cup$ A\\ + &&&\\ + (iii)& (A $\cap$ B) $\cap$ C&=& A $\cap$ (B $\cap$ C)\\ + (iv)& (A $\cup$ B) $\cup$ C&=& A $\cup$ (B $\cup$ C)\\ + &&&\\ + (v)& (A $\cap$ B) $\cup$ C&=& (A $\cup$ C) $\cap$ (B $\cup$ C)\\ + (vi)& (A $\cup$ B) $\cap$ C&=& (A $\cap$ C) $\cup$ (B $\cap$ C)\\ + &&&\\ + (vii)& $\mathcal{C}$(A $\cup$ B)&=& $\mathcal{C}$A $\cap$ $\mathcal{C}$B\\ + (viii)& $\mathcal{C}$(A $\cap$ B)&=& $\mathcal{C}$A $\cup$ $\mathcal{C}$B\\ + &&&\\ + (ix)& $\mathcal{C}$$\mathcal{C}$A&=& A\\ + &&&\\ + (x)& A $\cup$ $\mathcal{C}$A&=& $\Omega$\\ + (xi)& A $\cap$ $\mathcal{C}$A&=& $\emptyset $\\ + &&&\\ + (xii)& A $\cup$ $\Omega $&=& $\Omega$\\ + (xiii)& A $\cup$ $\emptyset$&=& A\\ + (xiv)& A $\cap$ $\Omega$&=& A\\ + (xv)& A $\cap$ $\emptyset$&=& $\emptyset$\\ + &&&\\ + (xvi)& A $\cup$ A&=& A \\ + (xvii)& A $\cap$ A&=& A \\ + \end{tabular} + \end{defi} + \subsection{Relationen} + \begin{defi}[Relation] + Eine Relation auf einer Menge M ist nichts weiter als eine Menge von Paaren, also eine Teilmenge von $M x M$. Statt $(a,b)\in R$ schreibt man $aRb$ oder $a \sim b$ + \end{defi} + \begin{defi}[Eigenschaften von Relationen] + \begin{tabular}{@{}ll} + (i)& reflexiv, falls $\forall x\in M : x \sim x$\\ + (ii)& symmetrisch, falls $\forall x, y\in M: (x \sim y \Rightarrow y \sim x)$\\ + (iii)& transitiv, falls $\forall x, y, z\in M : (x\sim y \wedge y\sim z \Rightarrow x\sim z)$\\ + (iv)& antisymmetrisch, falls $\forall x, y\in M : (x\sim y \wedge y\sim x \Rightarrow x = y)$\\ + (v)& alternativ, falls $\forall x, y\in M : (x\sim y\vee y\sim x )$ + \end{tabular} + \end{defi} + Äquivalenzrelation: genau dann wenn - reflexiv, symmetrisch und transitiv\\ + Ordnungsrelation: genau dann wenn - reflexiv, antisymmetrisch und transitiv. \\ + \hspace*{10mm}Wenn zusätzlich alternativ, heißt sie vollständig. + \begin{defi}[Partition] + Sei $M \neq \emptyset$ und seien $A_i, i\in I$ ein System von Teilmengen von M (I ist Indexmenge). Es seien die beiden folgenden Eigenschaften erfüllt:\\ + \begin{tabular}{@{}ll} + (i)& Die $A_i$ sind paarweise disjunkt, d.h. $\forall i, j \in I: i \neq j \Rightarrow A_i \cap A_j =\emptyset$\\ + (ii)& DIe $A_i$ füllen ganz M auf, d.h. $\bigcup_{i\in I} A_i =M$\\ + \end{tabular}\\ + Dann heißt das System der $A_i$ eine Partition von M. + \end{defi} + \begin{satz}[Äquivalenzrelationen und Partitionen] + Sei $\sim$ eine Äquivalenzrelation auf einer Menge $M\neq \emptyset$. Dann bilden die Klassen bezüglich dieser Relation eine Partition auf/von M.\\ + Sei umgekehrt eine Partition $(A_i) _{i \in I}$ einer Menge M gegeben. Dann ist durch die Setzung $x\sim y :\Leftrightarrow \exists i\in I: x, y \in A_i$ eine Äquivalenzrelation gegeben.\\ + Kurz: Jede Äquivalenzrelation erzeugt eine Partition der Menge, und zu jeder Partition einer Menge gehört auf kanonische Art und Weise eine Äquivalenzrelation. + \end{satz} + \begin{defi}[Äquivalenzklasse] + Sei $\sim$ eine Äquivalenzrelation auf einer Menge $M\neq\emptyset$. Die Menge aller zu einem $x\in M$ in Relation stehenden Elemente bezeichnen wir als die (Äquivalenz-)Klasse $[x]_{\sim}$ von x:\\ + $[x]_{\sim} := {y\in M | x\sim y}= {y\in M|y\sim x}$\\ + Es ist also $y\in [x]_{\sim} \Leftrightarrow x\sim y \Leftrightarrow y\sim x,$\\ + und insbesondere gilt immer $x\in [x]_{\sim}$ (Reflexivität). + \end{defi} + \subsection{Funktionen} + \begin{defi}[Abbildung/Funktion, Definitionsbereich, Wertevorrat] + Seien $M, N \neq \emptyset$ Mengen. \\ + Menge $f\subseteq M x N$ heißt Funktion/Abbildung, wenn es zu jedem $x\in M$ genau ein $y\in N$ gibt mit $(x,y)\in f$.\\ + $M$ heißt Definitionsbereich von $f$, $N$ heißt Wertevorrat oder Zielmenge von $f$.\\ + Gilt $(x,y) \in f$, so bezeichnet man $y$ als das Bild von $x$ und $x$ als ein Urbild von $y$.\\ + Man schreibt für $(x,y) \in F$ auch $y=f(x)$, statt $f \subseteq + M x N$ auch $f: M\rightarrow N, x\rightarrow f(x)$.\\ + Eine Funktion ordnet jedem Element des Definitionsbereichs genau ein Element des Wertevorrats zu. Jedoch nicht jedes Element $y$ des Wertevorrats muss ein Urbild $x$ haben. + \end{defi} + \begin{defi}[Bildmenge] + Die Menge $Bild(f):=f(M):={f(x) \in N| x\in M}$ heißt Bild von $f$ oder Bild der Menge $M$ unter der Abbildung $f$).\\ + Für $y\in N$ sei $f^{?1}(y) := \{x\in M | f(x)=y\}$ die Urbildmenge. + \end{defi} + \begin{defi}[injektiv, surjektiv, bijektiv] + 1. $f$ heißt injektiv, wenn für alle $x_1, x_2 \in M$ mit $x_1\neq x_2$ gilt: $f(x_1)\neq f(x_2)$, d.h. wenn jedes $y\in N$ \\ + \hspace*{5mm}höchstens ein Urbild hat.\\ + 2. $f$ heißt surjektiv, wenn $f(M)=N$, d.h. wenn jedes $y\in N$ mindestens ein Urbild hat.\\ + 3. $f$ heißt bijektiv, wenn $f$ injektiv und surjektiv ist, wenn also jedes $x\in N$ genau ein Urbild hat. + \end{defi} + \begin{defi}[Verkettung von Funktionen] + Seien $f: A\rightarrow B$ und $g: C\rightarrow D$ zwei Funktionen und es gelte $B \subseteq C$. Dann ist offensichtlich durch $x\rightarrow g(f(x))$ eine Abbildung von $A$ nach $D$ definiert, diese wird mit $g\circ f$ bezeichnet: + \[ g\circ f: A \rightarrow C, x\rightarrowtail (g\circ f)(x) := g(f(x)) \] + \end{defi} + \newpage + \begin{satz}[Eigenschaften verketteter Funktionen] + Seien $f: A\rightarrow B$ und $g: B\rightarrow C$ zwei Funktionen:\\ + Sind $f, g$ injektiv, so ist $g\circ f$ injektiv.\\ + Sind $f,g$ surjektiv, so ist $g\circ f$ surjektiv.\\ + Sind $f,g$ bijektiv, so ist $g\circ f$ bijektiv. + \end{satz} + \begin{defi}[Identische Abbildung] + Sei $M \neq \neg$ eine Menge und $f: M\rightarrow M$ die Abbildung mit $f(x)=x$ für alle $x\in M$. $f$ heißt dann identische Abbildung oder die Identität auf M und wird mit $ID_M$ (oder $id_M$ oder $I_M$ oder $1_M$) bezeichnet. + \end{defi} + \begin{defi}[Umkehrabbildung] + Sei $f: M\rightarrow N$ eine Abbildung. Eine Abbildung $g: N\rightarrow M$ heißt $f$, wenn \\ + $\forall x\in M: g(f(x)) = x \wedge \forall y\in N: f(g(y))=y$\\ + also wenn $g\circ f =Id_M und f\circ g = Id_N$.\\ + Die Umkehrabbildung wird mit $f^{-1}$ bezeichnet. + \end{defi} + \begin{satz}[Existenz der Umkehrfunktion] + Eine Abbildung $f$ besitzt genau dann eine Umkehrabbildung, wenn $f$ bijektiv ist. In diesem Fall ist dann auch die Umkehrabbildung bijektiv. Existiert eine Umkehrabbildung, so ist sie eindeutig bestimmt. + \end{satz} + \begin{defi}[Gleichmächtigkeit] + Zwei Mengen A und B heißen gleich mächtig, wenn es eine Bijektion von A nach B gibt. Eine Menge, die gleich mächtig zu $\mathbb{N}$ ist, heißt abzählbar unendlich. Eine unendliche Menge, die nicht gleich mächtig zu $\mathbb{N}$ ist, heißt überabzählbar. + \end{defi} + \begin{defi}[Monotonie] + Eine Funktion $f: D\rightarrowtail \mathbb{R}, D \subseteq \mathbb{R}$ heißt streng monoton wachsend/fallend, wenn für alle $x,y \in D$ mit $xf(y)$.\\ + Sie heißt schwach monoton wachsend/fallend, wenn für alle $x,y \in D$ mit $xf(j)$.\\ + Das Signum einer Permutatoin ist definiert als $sgn(f):= (-1)^{N(f)}\in [-1, 1]$, wobei $N(f)$ die Anzahl der Inversionen von f ist. + \end{defi} + \begin{defi}[Binomialkoeffizienten] + $\frac{n!}{k!(n-k)!}=: \binom{n}{k}$ + \end{defi} + \section{Aufbau des Zahlensystems} + \subsection{$\mathbb{N},\mathbb{Z},\mathbb{Q},\mathbb{R}$, vollständige Induktion und algebraische Strukturen} + \begin{defi}[Summen- und Produktzeichen] + $\sum\limits_{k=m}^{n}a_k := a_m+a_{m+1}+ ... +a_n, m\leq n)$,\hspace*{10mm} $\prod\limits_{k=m}^{n}a_k := a_m\cdot a_{m+1} \cdot ... \cdot a_n, m\leq n)$ + \end{defi} + \begin{defi}[Vollständige Induktion] + Induktionsanfang: $(n=1)$ muss erfüllt sein\\ + Induktionsschritt: $(n\rightarrow n+1)$: wenn $n$ wahr ist, ist auch sein Nachfolger wahr.\\ + Wenn Induktionsanfang und Induktionsschritt wahr, dann ist die Aussage bewiesen. + \end{defi} + \begin{defi}[Eigenschaften von Verknüpfungen] + Sei M eine nichtleere Menge und $\circ : M\times M \rightarrow M$ eine Abbildung. $\circ$ heißt\\ + kommutativ, falls $\forall a,b \in M: a\circ b= b\circ a$\\ + assoziativ, falls $\forall a,b \in M: (a\circ b) \circ c=a\circ (b\circ c)$ + \end{defi} + \begin{defi}[neutrales und inverses Element] + Ein Element $e\in M$ heißt neutrales Element von M bzgl. $\circ$, wenn $\forall x\in M: e\circ x= x\circ e=x$.\\ + Neutrales Element ist eindeutig.\\ + Sei $e$ neutrales Element von $(M, \circ)$ und sei $x\in M$. $y\in M$ heißt inverses Element von $x$ in $(M, \circ)$, wenn $x\circ y =y\circ x=e$.\\ + Jedes $x$ hat ein eigenes Inverses. + \end{defi} + \begin{defi} + Sei M eine nichtleere Menge und $\circ: M\times M \rightarrow M$ eine Abbildung. \\ + Dann gibt es in M höchstens ein neutrales Element bzgl $\circ$.\\ + Wenn $\circ$ assoziativ ist und ein neutrales Element hat, dann hat jedes $x\in M$ höchstens ein inverses Element. + \end{defi} + \begin{defi}[Gruppe] + Sei $M$ eine nichtleere Menge und $\circ: M\times M \rightarrow M$ eine Abbildung. $(M, \circ)$ heißt Gruppe, wenn\\ + (i) $(M, \circ)$ assoziativ ist,\\ + (ii) $(M, \circ)$ ein neutrales Element hat, und \\ + (iii) $(M, \circ)$ jedes Element ein Inverses hat.\\ + Falls $(M, \circ)$ zusätzlich kommutativ ist, heißt $(M, \circ)$ kommutative oder Abelsche Gruppe. + \end{defi} + \begin{satz} + In jeder Zeile und in jeder Spalte der Verknüpfungstabelle einer Gruppe kommt jedes Gruppenelement höchstens einmal vor.\\ Insbesondere für endliche Gruppen folgt: in jeder Zeile und in jeder Spalte der Verknüpfungstabelle einer Gruppe kommt jedes Gruppenelement genau einmal vor. + \end{satz} + \begin{defi}[Untergruppe] + Sei $(G, \circ)$ eine Gruppe und $U \subseteq G$ eine nichtleere Teilmenge. $U$ heißt Untergruppe von $G$, + falls + (i) $\forall a, b \in U : a \circ b \in U$ (Abgeschlossenheit von $U$ bzgl. $\circ$)\\ + (ii) $\forall a \in U : a^{-1} \in U$ (Abgeschlossenheit von $U$ bzgl. Inversenbildung) + \end{defi} + \begin{defi}[Grundgesetze der Addition] + Für alle $a, b, c \in\mathbb{R}$ gilt:\\ + A1) Assoziativgesetz: $a + (b + c) = (a + b) + c$.\\ + A2) Kommutativgesetz: $a + b = b + a$.\\ + A3) Neutrales Element: Es existiert genau eine Zahl $0\in \mathbb{R}$ mit $a + 0 = a$.\\ + A4) Inverses Element: Zu jedem $a$ existiert eine Zahl $(-a) \in \mathbb{R}$ mit $(-a) + a = 0$. + \end{defi} + \begin{defi}[Grundgesetze der Multiplikation] + Für alle $a, b, c \in \mathbb{R}$ gilt:\\ + M1) Assoziativgesetz: $a \cdot (b \cdot c) = (a \cdot b) \cdot c$.\\ + M2) Kommutativgesetz: $a \cdot b = b \cdot a$.\\ + M3) Neutrales Element: Es existiert genau eine Zahl $1\in\mathbb{R}$ mit $a \cdot 1 = a$, und $1\neq 0$. + M4) Inverses Element: Zu jedem $a\neq 0$ existiert ein $\frac{1}{a} \in \mathbb{R}$ mit $\frac{1}{a}\cdot a=1$. + \end{defi} + \begin{defi}[Ordnungsaxiome] + $\leq$ sei eine reflexive, transitive, antisymmetrische und alternative Relation auf $\mathbb{R}$ (also eine vollständige Ordnungsrelation).\\ + Monotonie der Addition: $\forall a, b, b \in \mathbb{R}: a0 \Rightarrow a\cdot c < b\cdot c$. + \end{defi} + Eine Menge mit +, die (A1-A4) erfüllt, ist eine ABELsche Gruppe.\\ + Eine Menge mit den Verknüpfungen + und $\cdot $, die die obigen + Eigenschaften (A1-A4, M1-M4) und das Distributivgesetz erfüllt, heißt Körper.\\ + Hat man zusätzlich die Ordnungsaxiome, so spricht man von einem total + geordneten Körper.\\ + \begin{defi}[Vollständigkeitsaxiom] + Zerlegt man die reellen Zahlen $\mathbb{R}$ in zwei nichtleere Mengen: $\mathbb{R}=L\cup R$, und $\forall x\in L, y\in R: x0\Rightarrow xz0$\\ + $a0 \Rightarrow y^{-1} < x^{-1}$\\ + $xy>0 \Leftrightarrow (x>0\wedge y>0)\vee (x<0\wedge y<0)$ + \end{defi} + \subsection{Die Dezimaldarstellung rationaler und reeller Zahlen} + \begin{satz}[Kriterium zur Unterscheidung rationaler und irrationaler Zahlen] + Eine reelle Zahl ist genau dann rational, wenn ihre Dezimaldarstellung (b-adische Darstellung) abbrechend oder periodisch ist. + \end{satz} + \begin{satz}[Mächtigkeit von $\mathbb{Q}$ und $\mathbb{R}$] + Die Menge der rationalen Zahlen ist abzählbar.\\ + Die Menge der reellen Zahlen ist überabzählbar. + \end{satz} + \subsection{Trigonometrische Funktionen} + \begin{defi}[Geometrische Definition] + Sei $(x,y)\in \mathbb{R}^2$ ein Punkt auf dem Einheitskreis. Sei $\phi$ der Winkel zwischen der positiven x-Achse und dem Strahl von $(0,0)$ nach $(x,y)$. Dann setzen wir $\cos \phi :=x, \sin \phi := y$.\\ + Der Winkel kann dabei im Gradmaß gemessen werden, d.h. ein Vollkreis $=360^\circ$, oder im Bogenmaß, d.h. ein Vollkreis $=2\pi$. + \end{defi} + Es gilt:\\ + 1. Bild$(\sin)$= Bild$(\cos) = [-1, 1]$\\ + 2. $\sin ^2 \alpha + \cos ^2 \alpha = 1 \forall\alpha\in\mathbb{R}$\\ + 3. $\sin (-\alpha) = -\sin \alpha, \cos (-\alpha)=\cos\alpha$\\ + 4. $\sin(\frac{\pi}{2}-\alpha)=\cos\alpha, \cos(\frac{\pi}{2}-\alpha)=\sin\alpha$\\ + 5. $\sin(\alpha\pm\pi)=-\sin\alpha, \cos(\alpha\pm\pi)=-\cos\alpha$\\ + \\ + $ \tan \alpha:=\frac{\sin\alpha}{\cos\alpha} $ + für alle $\alpha$, für die $\cos\alpha\neq 0$ ist. Der Tangens ist $\pi$-periodisch. + \begin{satz}[Trigonometrische Additionstheoreme] + $\sin(\alpha\pm\beta)=\sin\alpha\cos\beta\pm\cos\alpha\sin\beta$ + $\cos(\alpha\pm\beta)=\cos\alpha\cos\beta\mp\sin\alpha\sin\beta$ + \end{satz} + \subsection{Die komplexen Zahlen} + \begin{defi}[Die komplexen Zahlen $\mathbb{C}$] + Es sei $C: [a+bi| a,b\in \mathbb{R}]$, wobei gelte $i^2=-1$.\\ + Es gelten ferner alle Rechenregeln für Körper.\\ + \\ + Es sei $C: \mathbb{R}\times\mathbb{R}$. Auf dieser Menge definieren wir eine Addition und eine Multiplikation. \\ + Addition: $(a_1,b_1)+(a_2,b_2):=(a_1+a_2,b_1+b_2)$\\ + Multiplikation: $(a_1,b_1)\cdot(a_2, b_2):=(a_1a_2-b_1b_2, a_1b_2+b_1a_2)$\\ + \\ + a) Sei $z=a+bi$ mit $a,b\in \mathbb{R}$ eine komplexe Zahl. \\ + \hspace*{5mm}Dann heißt $a$ der Realteil von $z$ und $b$ der Imaginärteil von $z$: $a=$Re$(z), b=$Im$(z)$.\\ + \hspace*{5mm}Jede komplexe Zahl lässt sich also schreiben als $z=$Re$(z)+ i\cdot$Im$(z)$.\\ + b) \={z}$:= a-bi$ heißt die zu $z=a+bi$ konjugiert-komplexe Zahl.\\ + c) Der Betrag einer komplexen Zahl $z=a+bi$ wird definiert als $|z|:=\sqrt{a^2+b^2}=\sqrt{\text{Re}(z)^2+\text{Im}(z)^2}$\\ + d) Das sog. Argument $\phi=$arg$(z)$ einer komplexen Zahl $x\neq 0$ ist der Winkel zwischen der positiven \\ + \hspace*{5mm}horizontalen Achse und dem Ursprungsvektor von 0 nach $z$. Das Argument wird im Bogenmaß gemessen \\ + \hspace*{5mm}und ist nur modulo $2\pi$ bestimmt. Derjenige Wert des Arguments, der im Intervall $[0, 2\pi)$ liegt, wird als \\ + \hspace*{5mm} Hauptwert des Arguments bezeichnet, also z.B. arg$(-i)=3\pi /2$ (= Hauptwert des Arguments).\\ + \\ + Man kann durch Angabe von Betrag und Argument eine komplexen Zahl eindeutig beschreiben. \\ + Gibt man eine komplexe Zahl durch Betrag und Argument an, so spricht man von Polarkoordinaten. + \end{defi} + Rechenregeln:\\ + $|$\={z}$|=|a-bi|=\sqrt{a^2+(-b)^2}=\sqrt{a^2+b^2}=|z|$\\ + $z\cdot|$\={z}$=(a+bi)(a-bi)=a^2-(bi)^2=a^2+b^2=|z|^2$\\ + $\frac{1}{z}= \frac{\text{\={z}}}{|z|^2}$ für $z\neq 0$\\ + $Re(z^2)=Re(a^2+2abi+(ib)^2)=a^2-b^2, Im (z^2)=2ab$\\ + $z+|$\={z}$=(a+bi)+(a-bi)=2a=2Re(z)$\\ + $z-|$\={z}$=(a+bi)-(a-bi)=2bi=2i Im(z)$\\ + Komplement von $(z_1+z_2)=$\={z}$_1+$\={z}$_2$, Komplement von $(z_1\cdot z_2)=$\={z}$_1\cdot$\={z}$_2$ + \subsubsection{Darstellung von komplexen Zahlen} + 1. Jedes $z\in\mathbb{C}$ ist durch $a=Re(z), b=Im(z)$ eindeutig festgelegt (Kartesische Koordinaten). \\ + \hspace*{5mm}Zwei komplexe Zahlen sind nur dann gleich, wenn sie gleichen Real- sowie Imaginärteil haben.\\ + 2. Jedes $z\in\mathbb{C}\backslash \{0\}$ ist durch Betrag und Argument eindeutig festgelegt (Polarkoordinaten). \\ + \hspace*{5mm}Zwei komplexe Zahlen sind nur dann gleich, wenn sie gleichen Betrag sowie gleiches Argument haben.\\ + \\ + \subsubsection{Umrechnung und Rechnen im Komplexen} + Wenn Argument und Betrag gegeben:\\ + $z=Re(z)+i Im(z)=|z|\cos(\phi)+i|z|\sin(\phi)=|z| (\cos(\phi)+i\sin(\phi)), \phi=arg(z)$\\ + \\ + Wenn Real- und Imaginärteil gegeben:\\ + $|z|=\sqrt{a^2+b^2}=\sqrt{Re(z)^2+Im(z)^2}$ und $\tan\phi=\frac{\sin\phi}{\cos\phi}=\frac{|z|\sin\phi}{|z|\cos\phi}=\frac{Im(z)}{Re(z)}=\frac{b}{a}$\\ + Achtung im 2. und 3. Quadranten! + \begin{defi}[Multiplikation in $\mathbb{C}$ in Polarkoordinaten] + Beim Multiplizieren komplexer Zahlen multiplizieren sich die Beträge und addieren sich die Argumente: + \[ z_1 = r_1(\cos \phi_1+i\sin\phi_1), z_2 = r_2(\cos \phi_2+i\sin\phi_2) \] + \[ \Rightarrow z_1 z_2 = r_1 r_2[\cos (\phi_1+\phi_2)+i\sin(\phi_1+\phi_2)] \] + \[ \text{d.h. } |z_1 z_2|=|z_1|\cdot|z_2|, arg(z_1z_2)=arg(z_1)+arg(z_2) (mod 2\pi) \] + Für die Division gilt: $|\frac{z_1}{z_2}|=\frac{|z_1|}{|z_2|}, arg(\frac{z_1}{z_2})=arg(z_1)-arg(z_2) (mod 2\pi)$ + \end{defi} + \begin{defi}[Potenzbildung in $\mathbb{C}$ in Polarkoordinaten (De Moivre'sche Formel)] + n-te Potenz: Betrag mit n potenziert und Argument mit n multipliziert:\\ + $ z= r(\cos\phi+i\sin\phi) \Rightarrow z^n =r^n (\cos(n\phi)+i\sin(n\phi))$\\ + oder $ |z^n| = |z|^n, arg(z^n)=n\cdot arg(z) (mod 2\pi) $ + \end{defi} + \begin{satz}[n-te Wurzeln in $\mathbb{C}$] + Sei $z\in\mathbb{C}\backslash \{0\}$. Dann hat die Gleichung $w^n=z$ genau n Lösungen $w_0, ..., w_{n-1}$ mit\\ + $ |w_0|=...=|w_{n-1}|=\sqrt[n]{|z|} \text{ und } arg(w_k)=\frac{1}{n}arg(z)+\frac{2\pi k}{n}, k=0, ..., n-1$\\ + Also\\ + $ w_k= \sqrt[n]{|z|} [\cos(\frac{1}{n}arg(z)+\frac{2\pi k}{n})+i \sin (\frac{1}{n}arg(z)+\frac{2\pi k}{n}) ], k=0, ..., n-1$ + \end{satz} + \begin{defi}[Lösen von quadratischen Gleichungen] + Gleichung $z^2+pz+q =0$.\\ + Quadratische Ergänzung lieferte $(z+\frac{p}{2})^2 = \frac{p^2}{4}-q$ (rechte Seite $=: D$).\\ + \\ + Allgemeine Lösungsformel für quad. Gleichungen:\\ + $ z_{1,2}=-\frac{p}{2} \pm \sqrt{|D|} [\cos(\frac{1}{2}arg(D))+i\sin(\frac{1}{2} arg(D))], D:= \frac{p^2}{4}-q \neq 0, p,q\in \mathbb{C}$ + \end{defi} + \begin{satz}[Fundamentalsatz/Hauptsatz der Algebra] + Jedes Polynom $P:\mathbb{C}\rightarrow\mathbb{C}, P(z)=a_0+a_1z+ ... + a_nz^n$ mit Koeffizienten in $\mathbb{C}, n\in N, a_n\neq 0$ hat eine Darstellung (Linearfaktorzerlegung):\\ + $ P(z)=a_n \prod_{j=1}^{n}(z-z_j), \text{ wobei } z_1, ..., z_n \in \mathbb{C}$ + \end{satz} + Jedes Polynom vom Grad $\geq 1$ mit Koeffizienten in $\mathbb{C}$ hat mind. 1 NS in $\mathbb{C}$ (und höchstens $n$ viele). + \begin{satz} + Sei $ P_n(x)= \sum_{k=0}^{n}a_kx^k$ ein Polynom $n$-ten Grades mit reellen Koeffizienten $a_k \in \mathbb{R}, k=0,1,..., n, a_n\neq 0$. \\ + Dann gilt: Ist $z_0\in\mathbb{C}$ eine Nullstelle von $P_n(x)$, so auch die konjugiert komplexe Zahl $z_0$. + \end{satz} + Nichtreelle Nullstellen von $P_n$ treten stets paarweise auf: \\ + $z_0, \overline{z}_0 \in\mathbb{C}$ sind entweder beide Nullstellen oder beide keine Nulstellen.\\ + Ist Grad $P_n =2m+1$ eine ungerade Zahl, so hat $P_n$ mindestens eine reelle Nullstelle. + \begin{satz}[Dreiecksungleichung in $\mathbb{C}$] + Für alle $z_1, z_2 \in\mathbb{C}$ gilt $|z_1+z_2|\leq |z_1|+|z_2|$ + \end{satz} + \section{Lineare Algebra} + \subsection{Gaussches Eliminationsverfahren} + \begin{defi}[Lineares Gleichungssystem, LGS] + Ein Lineares Gleichungssystem (LGS) mit $n\in\mathbb{N}$ Unbekannten $x_1,x_2,...,x_n$ und $m\in\mathbb{N}$ Gleichungen hat die Form + \[ \begin{array}{ccc} + a_{11} x_1+ ...+ a_{1n}x_n & = & b_1\\ + ...&& ...\\ + a_{m1}x_1+ ...+ a_{mn}x_n &=& x_n + \end{array} \] + Dabei heißen die $b_1,...b_m$ die rechten Seiten und die $a_{ij}, i=1,...,m, j=1,...,n$ die Koeffizienten des LGS. \\ + Zur kürzeren Schreibweise führt man auch ein:\\ + $\vec{x}:= \left(\begin{array}{c} + x_1\\ ...\\x_n + \end{array}\right) \in \mathbb{R}^n$ Vektor der Unbekannten, \hspace*{5mm} $\vec{b}:= \left(\begin{array}{c} + b_1\\ ...\\b_m + \end{array}\right) \in \mathbb{R}^m$ Vektor der rechten Seite\\ + $A:= \left(\begin{array}{ccc} + a_{11} & ... & a_{1n}\\ ... && ...\\a_{m1}& ...& a_{mn} + \end{array}\right) = (a_{ij})_{i=1,...,m; j=1,...,n} \in \mathbb{R}^{m\times n}$ Koeffizientenmatrix, Systemmatrix\\ + \\ + Konventionen: Der Zeilenindex kommt immer vor dem Spaltenindex: $a_{ij}$ ($i$-te Zeile, $j$-te Spalte) \\ + $(a_{ij})$ ist die Matrix mit den Einträgen $a_{ij}$,\\ + $m=$ Anzahl Zeilen $=$ Anzahl Gleichungen,$n=$ Anzahl Spalten $=$ Anzahl Unbekannte,\\ + $(A|\vec{B})\in \mathbb{R}^{m\times(n+1)}$ bezeichnet man als erweiterte Koeffizientenmatrix. + \end{defi} + \textbf{3 verschiedene Typen von Stufenformen:}\\ + Typ I: Alle Stufen haben Höhe und Breite 1, unterhalb der Stufen stehen nur Nullen, auf der Diagonalen stehen von Null verschiedene Einträge, insbesondere sei $m\geq n$ vorausgesetzt, im Fall $m>n$ sind unten $m-n$ viele Nullzeilen enthalten.\\ + Es existiert genau eine Lösung, daher auch eindeutiger Typ.\\ + \\ + Typ II: Es gibt mind. eine Stufe der Breite $>1$, und in der $\vec{b}$-Spalte fängt keine neue Stufe an.\\ + Es existieren unendlich viele Lösungen, daher auch mehrdeutiger Typ.\\ + \\ + Typ III: Stufenform, bei der sich in der Spalte der rechten Seite eine Stufe befindet, d.h. es gibt eine Gleichung der Form $0\cdot x_1+0\cdot x_2 + ... + 0\cdot x_n =b_r$ mit $b_1 \neq 0$\\ + Es existiert keine Lösung, daher auch nicht lösbarer Typ. + \subsection{Vektorräume} + \subsubsection{Definitionen} + \begin{defi}[Komponentenweise Definition von Addition und Skalarmultiplikation für n-Tupel] + $\left(\begin{array}{c} + x_1\\ x_2\\ ...\\x_n + \end{array}\right)+ + \left(\begin{array}{c} + y_1\\ y_2\\ ...\\y_n + \end{array}\right) = + \left(\begin{array}{c} + x_1+y_1\\x_2+y_2\\...\\x_n+y_n + \end{array}\right)$ + und + $ \lambda\cdot \left(\begin{array}{c} + x_1\\ x_2\\ ...\\x_n + \end{array}\right)= + \left(\begin{array}{c} + \lambda x_1\\\lambda x_2\\ ...\\\lambda x_n + \end{array}\right) $ + \end{defi} + \begin{defi}[Vektorraum] + Sei $\mathbb{K}$ ein Körper und $V$ eine Menge mit einer Verknüpfung $+ : V\times V \rightarrow V$ (Vektoraddition). Außerdem sei eine Verknüpfung $\cdot \ : \mathbb{K}\times V \rightarrow V$ (Skalarmultiplikation) gegeben, und es gelte:\\ + - $(V, + )$ ist eine kommutative Gruppe\\ + - Es gelten die Distributivgesetze sowie das Assoziativgesetz\\ + - und weiter $1\cdot \vec{x}=\vec{x}$\\ + Dann nennt man V einen $\mathbb{K}$-Vektorraum. Die Elemente eines Vektorraums heißen Vektoren, die Elemente des zugrunde liegenden Körpers heißen Skalare.\\ + In jedem Vektorraum gilt $0\cdot \vec{x}=\vec{0}, \lambda\cdot\vec{0}=\vec{0}, -\vec{x}=(-1)\cdot\vec{x}$ + \end{defi} + \subsubsection{Unterräume und affine Räume} + \begin{defi} + Sei $V$ ein $\mathbb{K}$-Vektorraum und $U\subseteq V$ eine nichtleere Teilmenge. $U$ heißt Unterraum von $V$, falls für alle $\vec{x},\vec{y}\in U$ und $\alpha \in\mathbb{K}$ gilt:\\ + 1. $\vec{x}+\vec{y}\in U$\\ + 2. $\alpha \vec{x}\in U$\\ + Die Teilmenge U ist also bzgl. der Vektoraddition und Skalarmultiplikation abgeschlossen.\\ + \textbf{Alternativ:}\\ + EIne Menge $U\subseteq V$ ist genau dann Unterraum des Vektorraums V, wenn + $ \forall \vec{x},\vec{y}\in U, \alpha,\beta\in\mathbb{K}: \alpha\vec{x}+\beta\vec{y}\in U $\\ + \textbf{Ein notwendiges, nicht hinreichendes Kriterium:}\\ + Ist $U$ ein Unterraum eines $\mathbb{K}$-VR $V$, so gilt immer $\vec{0}\in U$ + \end{defi} + \begin{defi}[Lösungsmenge eines homogenen/heterogenen LGS] + Ein LGS $(A|\vec{b}), A\in \mathbb{K}^{m\times n}, \vec{b}\in\mathbb{K}^m,$ heißt homogen, wenn die rechten Seiten alle gleich null sind, also $\vec{b}=\vec{0}$. Andernfalls heißt es inhomogen.\\ + Die Lösungsmenge $L_{hom}$ eines homogenen LGS $(A|\vec{0})$\\ + - ist immer ein Unterraum des $\mathbb{K}^n$\\ + - ist niemals leer, denn $\vec{0}\in L_{hom}$. $\vec{0}$ heißt auch die triviale Lösung.\\ + Die Lösungsmenge $L$ eines inhomogenen LGS ist kein Unterraum. + \end{defi} + \begin{satz}[Lösungsmenge eines LGS und des zugehörigen homogenen LGS] + Sei $\emptyset\neq L\subseteq \mathbb{R}^n$ die nichtleere Lösungsmenge eines LGS $(A|\vec{b})$, und sei $L_{hom}\subseteq\mathbb{R}^n$ die Lösungsmenge des zugehörigen homogenen LGS $(A|\vec{0})$. Dann gilt\\ + $ L = \{\vec{x_0}\}+L_{hom} ( :=\{\vec{x_0}+\vec{x}|\vec{x}\in L_{hom}\})$\\ + wobei $\vec{x_0}$ ein beliebiges Element aus L ist. + \end{satz} + Also: um $L$ zu kennen, reicht es, $L_{hom}$ sowie ein einziges Element $\vec{x_0}\in L$ zu kennen. + \begin{defi}[affiner Raum] + Sei $U$ ein Unterraum eines $\mathbb{K}$-Vektorraums V. Ferner sei $\vec{x_0}\in V$. Dann nennt man die Menge\\ + $ \{\vec{x_0}\}+U:=\{\vec{x_0}+\vec{x}|\vec{x}\in U\} $\\ + einen affinen Raum oder affin-linearen Raum oder affinen Unterraum von V.\\ + Bsp: Geraden im $\mathbb{R}^2$, Geraden und Ebenen im $\mathbb{R}^3$ + \end{defi} + \subsubsection{Lineare (Un)Abhängigkeit, Erzeugendensysteme, Basen, Dimension} + \begin{defi}[Linearkombination, Lineare (Un)Abhängigkeit] + Seien $\vec{v_1}, ..., \vec{v_n}$ Elemente eines $\mathbb{K}$-Vektorraums $V$ gegeben. \\ + Vektoren der Bauart + $\sum\limits_{i=1}^{n}\alpha_i\vec{v_i}$ heißen Linearkombinationen (LK) der Vektoren $\vec{v_1}, ..., \vec{v_n}$. \\ + Die Linearkombination mit $\alpha_a=...=\alpha_n=0$ heißt triviale Linearkombination. \\ + Die Vektoren $\vec{v_1}, ..., \vec{v_n}$ heißen linear abhängig, wenn es eine nichttriviale LK gibt, die den Nullvektor ergibt, also wenn es $\alpha_1, ..., \alpha_n \in \mathbb{K}$, nicht alle $=0$ gibt, sodass $\sum\limits_{i=1}^{n}\alpha_i\vec{v_i}=\vec{0}$. \\ + Andernfalls, also wenn nur die triviale LK den Nullvektor ergibt, heißen die Vektoren linear unabhängig.\\ + \\ + In Formeln: + \[ \vec{v_1}, ..., \vec{v_n} \text{ lin. abh. \ \ } :\Leftrightarrow \exists \alpha_1, ..., \alpha_n \in\mathbb{K}: \sum_{i=1}^{n}\alpha_i\vec{v_i}=\vec{0} \wedge (\alpha_1, ..., \alpha_n)\neq (0, ..., 0)\] + \[ \vec{v_1}, ..., \vec{v_n} \text{ lin. unabh. } :\Leftrightarrow \forall \alpha_1, ..., \alpha_n \in\mathbb{K}: (\sum_{i=1}^{n}\alpha_i\vec{v_i}=\vec{0} \Rightarrow \alpha_1 = ...= \alpha_n=0)\] + \end{defi} + Um Vektoren auf lineare (Un)Abhängigkeit zu testen, bildet man die Matrix $A:=[\vec{v_1}, ..., \vec{v_n}]\in\mathbb{K}^{m\times n}$, und birngt diese durch elementare Umformungen auf Stufenform. \\ + Die Vektoren sind genau dann linear unabhängig, wenn die Stufenform von $A$ den Typ I hat, \\ + und linear abhängig, wenn sie Typ 2 hat.\\ + Ist $n>m$, so muss es Stufen der Breite $>1$ geben, d.h. die Stufenform kann nicht vom Typ 1 sein. Das heißt, Vektoren mit n>m sind immer linear abhängig.\\ + \begin{defi}[Erzeugendensysteme] + Vektoren $\vec{v_1}, ...,\vec{v_n}$ eines Vektorraumes $V$ mit der Eigenschaft, dass sich jeder Vektor $\vec{x}\in V$ als Linearkombination der $\vec{v_i}$ darstellen lässt, heißen Erzeugendensystem (kurz EZS) von $V$.\\ + $n$ := $\sum\limits_{i=1}^{n} x_i y_i = x^T y$ + \end{minipage} + \begin{minipage}{0.5\textwidth} + In Komplexen: $<\vec{x} , \vec{y}>$ := $\sum\limits_{i=1}^{n} x_i \overline{y_i} = x^T \overline{y}$ + \end{minipage} + \\ + $x_i y_i = x^T y$ und $x^T \overline{y}$ sind dabei als Matrix-Matrix Produkt zu verstehen. + \end{defi} + \begin{defi}[Wichtige Eigenschaften des Skalarproduktes] + S1: $<\vec{x},\vec{x}> \geq 0 \forall \vec{x}\in\mathbb{K}^n$\\ + S2: $<\vec{x},\vec{x}> = 0$ $\Leftrightarrow$ $\vec{x} = \vec{0}$\\ + S3: $<\vec{x},\vec{y}> = \overline{<\vec{y},\vec{x}>} \forall x\in\mathbb{K}^n$\\ + S4: $<\alpha \vec{x},\vec{y}> = \alpha <\vec{x},\vec{y}> \forall \alpha \in\mathbb{K}, \vec{x},\vec{y}\in\mathbb{K}^n$\\ + S5: $<\vec{x} + \vec{y} , \vec{z}> = <\vec{x},\vec{z}> + <\vec{y}, \vec{z}> \forall \vec{x}, \vec{y}, \vec{z} \in\mathbb{K}^n$ + \end{defi} + % 19 - 04 + \begin{defi}[Skalarprodukt und Orthogonalität] + Sei $V$ ein $\mathbb{K}$-Vektorraum. Eine Abbildung $<\cdot,\cdot>: V\times V\rightarrow \mathbb{K}$, die die Eigenschaften S1-S5 erfüllt, heißt Skalarprodukt auf V.\\ + $(V, <\cdot,\cdot>)$ nennt man dann einen Vektorraum mit Skalarprodukt.\\ + Vektoren $\vec{x},\vec{y}\in V$ heißen orthogonal bezüglich des Skalarprodukts, falls $<\vec{x},\vec{y}>=0$. + \end{defi} + \begin{satz}[Matrizen und Skalarprodukt] + Für eine Reelle Matrix gilt: \\ + $<\vec{x} , A \vec{y}> = < A^T \vec{x} , \vec{y}>$ und $< A \vec{x} , \vec{y}> = <\vec{x} , A^T \vec{y}> \forall \vec{x},\vec{y}\in\mathbb{R}^n$ + \end{satz} + \newpage + \begin{defi}[Norm, bzw. Länge eines Vektors] + N1: $||\vec{x}||\geq 0 \forall \vec{x}\in \mathbb{K}^n$\\ + N2: $||\vec{x}||=0 \Leftrightarrow \vec{x}=\vec{0}$\\ + N3: $||\alpha\vec{x}||=|\alpha|\ ||\vec{x}|| \forall\vec{x}\in\mathbb{K}^n$\\ + N4: $||\vec{x}+\vec{y}|| \leq ||\vec{x}||+||\vec{y}|| \forall\vec{x},\vec{y}\in\mathbb{K}^n$\\ + \\ + Sei $V$ ein $\mathbb{K}$-Vektorraum. Eine Abbildung $||\cdot||: V\rightarrow \mathbb{R}, \vec{x}\rightarrow ||\vec{x}||$, die die obigen Eigenschaften erfüllt, heißt Norm auf dem Vektorraum $V$.\\ + $(V, ||\cdot||)$ wird als normierter Vektorraum bezeichnet.\\ + \textbf{Euklidische Norm:}\\ + $||\vec{x} := \sqrt{\sum\limits_{i=1}^{n} |{x_i}|^2}$ + \end{defi} + \begin{satz}[Zusammenhang der Euklidischen Norm und des Skalarproduktes] + Sei $||\cdot ||$ die euklidische Norm und $<\cdot,\cdot>$ das euklidische Skalarprodukt. + Es gilt: $||\vec{x}|| = \sqrt{< \vec{x} , \vec{x}>}$ + \end{satz} + \begin{defi}[Orthogonal und Orthonormalsysteme] + Orthogonalsystem: Skalarprodukt aller Vektoren = 0\\ + Orthonormalsystem: Skalarprodukt aller Vektoren = 0 und $||\vec{a}_i|| =1$\\ + Die Vektoren beider Systeme sind immer linear unabhängig + \end{defi} + \begin{satz}[Darstellung bezüglich einer ONB] + Sei $\vec{x} \in V$ und sei $\{\vec{b_1},...,\vec{b_n}\}$ eine ONB eines reellen Vektorraumes V, Dann gilt:\\ + $\vec{x} = < \vec{x} , \vec{b_1}> \vec{b_1} + ... + <\vec{x} , \vec{b_n}> \vec{b_n}$ + \end{satz} + \begin{satz}[Norm eines Vektors bzgl. einer ONB dargestellt] + Sei $\{\vec{b}_1, ...,\vec{b}_n\}$ ONB eines $\mathbb{R}$-VR und sei $\vec{x}=\sum\limits_{i=1}^{n} \alpha_i \vec{b}_i$ (also $\alpha_i = <\vec{x}, \vec{b}_i>$). Dann ist $||\vec{x}=\sqrt{\sum\limits_{i=1}^{n} \alpha_i^2}$. + \end{satz} + \begin{defi}[orthogonale Projektion] + $\vec{x}_U$ heißt orthogonale Projektion des Vektors $\vec{x} \in$ V auf den Unterraum U von V, wenn es folgende Darstellung gibt: \[\vec{x} = \vec{x}_U + \vec{x}_U^\bot \ mit \ \vec{x}_U \in U \ und \ <\vec{x}_U , \vec{x}_U^\bot> = 0\] + \end{defi} + \begin{satz}[Orthogonalprojektion] + Sei U ein UR eines Vektorraums V, und sei $\{ \vec{b}_1 , ... , \vec{b}_m\}$ eine ONB von U. Sei $\vec{x} \in$ V. Dann berechnet sich die orthogonale Projektion von $\vec{x}$ auf U folgendermaßen: + $\vec{x}_U = \sum\limits_{i = 1}^{m} <\vec{x} , \vec{b}_i> \vec{b}_i $ + \end{satz} + Winkelberechnung: $<\vec{a} , \vec{b}> = ||\vec{a}|| \ ||\vec{b}|| $cos $\alpha$ +\end{document}