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.
	
	\begin{itemize}
		\item	Es gibt kein Datenbanksystem und die Daten wurden nicht auf die Platte geschrieben. In diesem Fall hat der Ausfall keine negativen Folgen, da die Daten sich in einem konsistenten Zustand befinden.
		\item	Es gibt ein Datenbanksystem und die Daten wurden nicht auf die Platte geschrieben. In diesem Fall hat der Ausfall ebenfalls keine negativen Folgen, da die Transaktion ohnehin nicht beendet war und damit keine Veränderungen hätten vorgenommen werden dürfen.
		\item	Es gibt kein Datenbanksystem und die Daten wurden auf die Platte geschrieben. In diesem Fall befinden sich die Daten in einem inkonsistenten Zustand, da zwar der Saldo bei dem einen Konto verringert, bei dem anderen aber nicht erhöht wurde. Da es kein DBS gibt, kann dieser inkonsistente Zustand nicht leicht behoben werden.
		\item	Es gibt ein Datenbanksystem und die Daten wurden auf die Platte geschrieben. In diesem Fall kann das DBS aufgrund von Logs nachvollziehen, dass die Transaktion noch nicht beendet war und wird die Veränderung an dem Saldo von Konto 5 rückgängig machen.
	\end{itemize}
	
	Anschließend betrachten wir den Stromausfall zum Zeitpunkt B.
	
	\begin{itemize}
		 \item	Es gibt kein DBS und die geänderten Zustände von Konto 5 und 7 wurden auf die Platte geschrieben. In diesem Fall befinden sich beide Daten in einem konsistenten Zustand und es muss lediglich noch der Kontostand von Konto 5 ausgegeben werden.
		 \item	Es gibt ein DBS und die geänderten Zustände von Konto 5 und 7 wurden auf die Platte geschrieben. In diesem Fall befinden sich die Daten in einem konsistenten Zustand aber das DBS wird die Änderungen rückabwickeln, da die Transaktion nicht beendet wurde.
		 \item	Es gibt kein DBS und nur die Änderungen an Konto 7 sind persistiert. In diesem Fall befinden sich die Daten in einem inkonsistenten Zustand, da die Änderung an Konto 5 verloren gegangen ist.
		 \item	Es gibt ein DBS und nur die Änderungen an Konto 7 sind peristiert. In diesem Fall befinden sich die Daten in einem inkonsistenten Zustand, aber das DBS wird die Änderungen an Konto 7 rückabwickeln und die Daten wieder in einen konsistenten Zustand bringen.
	\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}