uni/gdb/G62B1_Dittrich-Lindemann-Martens.tex

\documentclass[ngerman]{gdb-aufgabenblatt}
\renewcommand{\Aufgabenblatt}{1}
\renewcommand{\Ausgabedatum}{Mi. 16.10.2013}
\renewcommand{\Abgabedatum}{Fr. 01.11.2013}
\renewcommand{\Gruppe}{Tim Dittrich, Sebastian Lindemann, Jim Martens}

% define how the sections are rendered
\def\thesection{Aufgabe \arabic{section}:}
\def\thesubsection{\alph{subsection})}
\def\thesubsubsection{(\roman{subsubsection})}

\begin{document}


\section{Informationssysteme}
	\subsection{} %a
	Ein Informationssystem zeichnen sich durch Kommunikationsbeziehungen zwischen Menschen und Maschine aus. Rechnergestützte Informationssysteme beinhalten automatisierte Anwendungssysteme, welche zur Beschaffung, Speicherung, Veränderung und Veranschaulichung von Informationen genutzt werden.
	
	Die Informationen dienen dazu zielorientiertes Wissen zu generieren. Dieses Wissen dient dann wiederum zur Vorbereitung und Durchführung von Handlungen und Entscheidungen. Somit werden Informationssysteme beispielsweise genutzt um Arbeitsabläufe im Unternehmen zu organisieren und unterstützen.
	\subsection{} %b
	Legt man die 3-Schicht-Architektur eines Datenbankmanagementsystems (DBMS), mit der Sicht-Ebene, logischen Ebene und physischen Ebene zu Grunde, so kann man generell Datenunabhängigkeit als die Immunität der einzelnen Schichten auf Änderungen innerhalb der nächsten tieferen Schicht beschreiben. Um im Folgenden den Unterschied zwischen der logischen und physischen Datenunabhängigkeit leichter verdeutlichen zu können folgendes Szenario:
	
	Es gebe eine Anwendung zum Verwalten von Immobilien für Immobilienmakler. Dabei gibt es 2 Sichten auf die Daten (Sicht-Ebene). Einmal die "`Chefsicht"' auf alle Daten und die "`Verkäufersicht"' auf nur ein Teil der Daten. Alle Immobilen werden in einer Tabelle gespeichert (logische Ebene) und es werden verschiedene Indexstrukturen und Algorithmen für die Optimierung von Abfragen verwendet (physische Ebene).
	
	Die physische Datenunabhängigkeit bezieht sich auf die beiden unteren Ebenen (logische- und physische-Ebene). Wird beispielsweise der Speicherort einzelner Daten aus optimierungstechnischen Gründen geändert, hat dies kein Einfluss auf das festgelegte Schema. Die beiden Ebenen sind also voneinander entkoppelt. 
	
	Die logische Datenunabhängigkeit bezieht sich auf die beiden oberen Schichten (Sicht-und logische-Ebene). Kommt es zu einer Änderung im Schema, beispielsweise es wird ein Attribut in der Tabelle hinzugefügt, hat dies im Idealfall keinen Einfluss auf die einzelnen Sichten. In der Praxis ist dies nicht immer ganz so leicht umsetzbar. Aber die logische Datenunabhängigkeit hat große Vorteile, so muss im besten Fall nichts an der Anwendung geändert werden wenn es zu einer Änderung am Schema kommt. 
	\subsection{} %c
	Informationssysteme werden zum Beispiel im öffentlichen Nahverkehr verwendet, um den Informationsbedarf von Passagieren bezüglich Fahrplanauskunft oder anderen Informationsinhalten zu befriedigen. Steht ein Passagier an einer Bushaltestelle werden ihm beispielsweise mit Hilfe geeigneter Informations- und Kommunikationstechnik mögliche Verspätungen oder die Ankunftszeit des nächsten Busses auf einem Bildschirm angezeigt. Hierfür reicht es nicht statische Daten in einer Datenbank abzulegen, sondern es werden dynamische Informationen über den derzeitigen Aufenthaltsort der einzelnen Busse benötigt. Dies geschieht in der Praxis mit modernen Sende- und Empfangseinheiten.   
	
	 Auch im Gesundheitswesen kommen Informationssysteme zum Einsatz, um Patienteninformationen zu verwalten und am richtigen Ort zur richtigen Zeit zur Verfügung zu stellen. Zum einen werden bei der Ankunft von Patienten im Krankenhaus neue Daten über deren derzeitigen Gemütszustand erhoben, zum anderen ist es besonders wichtig für einen behandelnden Arzt Einsicht in die Patientenakte zu haben, um über mögliche Vorerkrankungen informiert zu sein. 
	 Es ist vorstellbar, dass aus der Patientenakte die wichtigsten Informationen automatisiert zusammengefasst und in geeigneter Form kompakt dem Arzt dargestellt werden. An diesem Beispiel wird sehr gut die Kommunikationsbeziehung zwischen Mensch und Maschine deutlich. 
	 
	 Ein weiteres Anwendungsbeispiel ist die intelligente Routenplanung im Logistikwesen. Der Ölpreis steigt seit Jahren und es wird dadurch immer wichtiger Treibstoff einzusparen. Hierbei kommen nicht nur mathematische Optimierungsverfahren zum Einsatz, um eine möglichst kurze Strecke zu berechnen, sondern auch beispielsweise die Bewertung aktueller Verkehrsinformationen um Staus oder Sperrungen mit in die Routenplanung einzubeziehen. Hierfür kommen natürlich wieder Informationssysteme zum Einsatz. Auch interessant ist der Einsatz bei der Live-Planung wobei Routen geändert werden können, um zusätzliche Aufträge mit in die geplante Route zu integrieren.
\section{Miniwelt}
	\subsection{} %a
		Anhand der Beschreibung der Miniwelt werden folgende Objekttypen benötigt, die jeweils explizite oder implizite Funktionalitäten haben.
		
		\begin{itemize}
			\item	Mitglieder: können sich am System anmelden und müssen daher identifizierbar sein (Name, EMail, Passwort)
			\item	Tippspielgemeinschaften: haben einen Namen und einen Gründer, der ein Mitglied ist
			\item	Wettbewerbe: werden einer Tippspielgemeinschaft zugeordnet
			\item	Begegnungen: werden einem Wettbewerb zugeordnet, beinhalten die Info wer gegen wen spielt und was für ein Ergebnis herauskommt
			\item	Tipps: werden einem Mitspieler und einer Begegnung zugeordnet und enthalten den eigentlichen Tipp
			\item	Punkte: werden einem Mitspieler und einer Tippspielgemeinschaft zugeordnet und enthalten die Punkte des Mitspielers in der Gemeinschaft
		\end{itemize}
		Ergänzend zu den genannten Objekttypen, die je eine Tabelle im konzeptuellen Schema ausmachen, gibt es noch eine Tabelle, die Mitglieder den Tippspielgemeinschaften zuordnet.
		
		Folgende Vorgänge müssen durch die Anwendung abgebildet werden:
		\begin{itemize}
			\item	Anmeldung bei Anwendung
			\item	Registrierung bei Anwendung
			\item	Gründen einer Tippspielgemeinschaft
			\item	Erstellen eines Wettbewerbs für eine Gemeinschaft
			\item	Erstellen von Begegnungen für einen Wettbewerb
			\item	Eintragen von Ergebnissen für eine Begegnung
			\item	Hinzufügen von Mitspielern zu einer Gemeinschaft
			\item	Entfernen von Mitspielern aus einer Gemeinschaft
			\item	Tipp auf eine Begegnung in einem Wettbewerb in einer Gemeinschaft, der der Mitspieler angehörig ist, abgeben
			\item	Betrachten des Punktestandes innerhalb einer Gemeinschaft
			\item	Ergebnisse von Begegnungen ansehen
		\end{itemize}
		Das Errechnen der Punkte erfolgt im gleichen Atemzug wie das Eintragen von Ergebnissen und geschieht ohne Zutun des Bedieners.
	\subsection{} %b
		Zunächst werden die Anforderungen an die Anwendung erfasst, um dann die in der Vorlesung genannten allgemeinen Anforderungen an Datenbanksysteme anhand des hier beschriebenen Beispiels zu diskutieren.
		
		\begin{itemize}
			\item	Die Anwendung muss als Mehrbenutzersystem konzipiert werden und gleichzeitige Anfragen von unterschiedlichen Nutzern bearbeiten können. 
			\item	Ebenso muss die Anwendung bei jeder Anfrage darauf achten nur die Inhalte zurückzugeben, auf die der anfragende Benutzer Zugriff hat. So sollte ein Benutzer nur Tipps in einer Gemeinschaft abgeben können, wenn er Teil dieser Gemeinschaft ist.
			\item	Nachdem die Ergebnisse einer Begegnung eingetragen worden sind, darf kein Mitspieler mehr Tipps setzen oder vorhandene ändern können.
			\item	Sobald Ergebnisse eingetragen wurden, kann die Begegnung nicht mehr gelöscht werden, da sie bereits stattgefunden hat.
			\item	Der Gründer einer Tippspielgemeinschaft kann nicht aus eben jener Gemeinschaft austreten.
			\item	Die Punkte dürfen nur automatisch durch die Anwendung berechnet werden. Ein manuelles Verändern darf nicht möglich sein (weder vom betreffenden Mitspieler noch vom Gründer der Gemeinschaft).
			\item	Wenn der Browser vor dem Abschließen einer Aktion geschlossen wird, darf nichts verändert werden.
		\end{itemize}
		
		Diese Anforderungen sind zum einen Teil anwendungsspezifisch und zum anderen Teil allgemein für jede Anwendung mit persistenten Daten wichtig. 
		
		Da die Anforderungen an die Anwendung nun bekannt sind, werden die Anforderungen an Datenbanksysteme nun an diesem Beispiel diskutiert.
		
		So müssen Datenbanksysteme einen Schutz vor inkonsistenten Daten bieten. So wird eine Transaktion erst dann zur Persistierung freigegeben, wenn sie komplett erfolgreich durchlief. Sollte der Browser während einer Transaktion geschlossen werden, wird sie nicht abgeschlossen und damit nicht persistiert.
		
		Außerdem müssen gleichzeitige Anfragen problemlos bearbeitet werden, solange sie nicht im Konflikt stehen. Eine Abfrage von Ergebnissen einer Begegnung steht beispielsweise nicht im Konflikt mit dem Hinzufügen eines Mitspielers in eine Gemeinschaft oder dem Registrieren eines neuen Mitglieds. Um Konflikte zu vermeiden ist eine weitgehende Isolierung im Datenbanksystem von Nöten.
		
		Die Rechteverwaltung hängt von der Implementation ab. Die oben angewandte Methode benutzt einen Anwendungszugang zur Datenbank, womit die Zugriffskontrolle auf die Anwendung übergeht. Theoretisch wäre auch ein Datenbankzugang pro Benutzer denkbar, der dann eben nur entsprechende Rechte hätte. Allerdings wäre dies ein unnötiger Datenbankzugang, der zudem auch nur das konzeptuelle Schema berücksichtigt. So könnte ein Nutzer entweder alle Punkte aller Mitglieder ansehen oder keine. 
		
		Die externe Anwendungssicht auf die Daten umfasst hingegen eine logische Sicht, die auf das Fallbeispiel zugeschnitten ist. Daher sind die Zugriffskontrollen des Datenbanksystems viel zu vage, um sinnvoll für das Beispiel geeignet zu sein. Deswegen muss die Zugriffskontrolle hier auf Seiten der Anwendung stattfinden, die dann nur erlaubte Anfragen an das Datenbanksystem sendet.
		
		
\section{Transaktionen}
	Zunächst betrachten wir den Stromausfall zum Zeitpunkt A. Daraus ergeben sich mehrere Fälle. Die ersten beiden Fälle betrachten immer ein Datenbanksystem, die letzten beiden immer ein Dateisystem.
	
	\begin{itemize}
		\item Das System hat die Änderung am Konto mit der ID 5 nicht persistent gespeichert. Sie bleibt also im Hauptspeicher, bzw. wird daraus gelöscht bei dem Stromausfall. Somit wird die Überweisung nicht durchgeführt und es herrscht der Ausgangszustand.

		\item Das System hat die Änderungen am Konto mit der ID 5 persistent gespeichert. Die Daten werden auf die Festplatte geschrieben. Es gibt nach der Abbuchung der 1000 Euro einen Stromausfall. Das System "`merkt"' sich diesen Zeitpunkt. Nach erneutem Start des Systems wird der letzte bekannte Zustand rekonstruiert und danach in den Ausgangszustand zurück versetzt.
		
		\item Das System hat die Änderung am Konto mit der ID 5 noch nicht persistent gespeichert. Sie bleibt also im Hauptspeicher, bzw. wird daraus gelöscht bei dem Stromausfall. Somit wird die Überweisung nicht durchgeführt und es herrscht der Ausgangszustand.
		
		\item Das System hat die Änderung am Konto mit der ID 5 persistent gespeichert. Also die Daten bereits auf die Festplatte geschrieben. Somit werden 1000 Euro vom Konto mit der ID 5 abgebucht. Da aber kein Datenbanksystem verwendet wird, gibt es keinen Wiederaufnahmepunkt, an welchem das System wiedereinsteigen könnte. Somit werden keine 1000 Euro dem Konto mit der ID 7 gutgeschrieben und das Geld ist weg.
	\end{itemize}
	
	Anschließend betrachten wir den Stromausfall B.

	\begin{itemize}
		\item Das System hat die Änderung an beiden Konten nicht persistent gespeichert. Sie bleibt also im Hauptspeicher; bzw. wird daraus gelöscht bei dem Stromausfall. Somit wird die Überweisung nicht durchgeführt und es herrscht der Ausgangszustand. Es gibt aber eine falsche Meldung  dem Clienten gegenüber für den Kontostand des Kontos mit der ID 7.
		
		\item Das System hat die Änderungen an beiden Konten persistent gespeichert. Die Daten werden auf die Festplatte geschrieben. Es gibt nach der Überweisung einen Stromausfall. Jedoch wurde der Print Vorgang für das Konto mir der ID 5 nicht abgeschlossen. Dieser würde eine benutzerdefinierte Meldung an den Clienten zurückgeben. Da der Komplette Vorgang noch nicht abgeschlossen war werden beide Konten wieder in ihren Ausgangszustand zurück versetzt. Es gibt somit aber eine falsche Meldung dem Clienten gegenüber für den Kontostand des Kontos mit der ID 7.
		
		\item Das System hat die Änderungen an beiden Konten nicht persistent gespeichert. Sie bleibt also im Hauptspeicher, bzw. wird daraus gelöscht bei dem Stromausfall. Somit wird die Überweisung nicht durchgeführt und es herrscht der Ausgangszustand. Es gibt somit aber eine falsche Meldung dem Clienten gegenüber für den Kontostand des Kontos mit der ID 7.
		
		\item Das System hat die Änderungen an beiden Konten persistent gespeichert. Somit werden an beiden Konten die richtigen Aktionen durchgeführt. Das Konto mit der ID 5 wird mit 1000 Euro belastet und das Konto mit der ID 7 werden 1000 Euro gutgeschrieben. Jedoch gibt es vor dem Printbefehl für das Konto mit der ID 5 den Stromausfall. Der letzte Zustand kann nicht wiederhergestellt werden und somit fehlt dieser Print Befehl und der Client bekommt den falschen Kontostand für dieses Konto angezeigt. 
	\end{itemize}	
	
	Zusammenfassend kann gesagt werden, dass es bei einem Datenbanksystem zu jedem Zeitpunkt immer nur konsistente Daten gibt.  Bei einem reinen Dateisystem können die Daten hingegen inkonsistent zurückgelassen werden.

\section{Warm-Up MySQL}
	\subsection{} %a
		Es wurde eine Tabelle mit dem Namen \texttt{user} in der Datenbank \texttt{gdb\textunderscore gruppe062} angelegt, die drei Felder (id, name, passwort) hat. Anschließend wurde ein Nutzer in diese Tabelle eingetragen mit den Werten (1 für id, "`gdbNutzer"' für name und "`geheim"' für passwort).
	\subsection{} %b
		Zunächst wurde die Zeile mit dem eben angelegten Nutzer komplett ausgelesen und anschließend die user-Tabelle gelöscht.
	\subsection{} %c
		Die MySQL-Architektur hat einen ähnlichen Aufbau wie die ANSI-SPARC Architektur. Das Dateisystem entspricht der internen Ebene. Die Speicherengines repräsentieren diese interne Ebene gegenüber der konzeptuellen Ebene und abstrahieren die tatsächliche Speicherung der Daten. 
		
		Damit stellen die Engines auch das Zugriffssystem dar. Die Metadatenverwaltung findet sich bei den Verwaltungsdiensten und -tools. Der Verbindungspool ist eine spezifische Implementation für Mehrbenutzersysteme, sodass mehrere Verbindungen gleichzeitig mit der Datenbank verbunden sein können. Auf dieser Ebene findet auch die Authentifizierung statt.
		
		Über den Verbindungspool, welcher die technische Schnittstelle zu externen Anwendungen darstellt, gelangen die Anfragen zu einer Zwischenebene, die die Anfragen parsed, optimiert und gegebenenfalls bereits gecachte Daten zurückgibt. Diese Ebene ist dafür zuständig die Datenbankzugriffe so effizient und schnell wie möglich zu gestalten. Damit ist diese Ebene das Datensystem des ANSI-SPARC Modells.
\end{document}