% Studienarbeit von Andreas Boesch
%
% Universitaet Hamburg
% Fachbereich Informatik
% Arbeitsbereich DBIS
%
% Kapitel: Die Datenbank


\chapter{Die Datenbank}
\label{Kap. Datenbank}
Die Datenbank ist der Kern des f"ur den Index zur politischen Ikonographie entwickelten Protoypen. Der physische Index zur politischen Ikonographie besteht aus einer gro"sen Sammlung von Karteikarten mit aufgeklebten Bildern, die nach Stichworten geordnet sind. Die Datenbank des Prototypen wurde in Form von miteinander verkn"upften Tabellen f"ur die textuellen Daten (z.B. Stichworte oder Dateinamen von zu Bildkarten geh"origen Bildern) und einem Dateibaum, in dem die Bilder in Verzeichnissen mit jeweils hundert Bildern abgelegt sind, realisiert. Die Bilder liegen jeweils einmal im Kleinformat (ca. 50KB) und einmal im Gro"sformat (ca. 1MB) vor. Dies hat den Vorteil, da"s bei Anfragen an den Datenbestand zuerst eine "Ubersicht der in Frage kommenden Bilder im Kleinformat angezeigt werden kann und somit mehrere Bilder gleichzeitig auf dem Bildschirm sichtbar sind. Ist danach eines der Bilder von gr"o"serem Interesse, kann es im Gro"sformat angesehen werden.    

Im Abschnitt~\ref{Abs. Umsetzung} wird die Abbildung des bei der Analyse entstandenen OMT-Objekt\-mo\-dells auf ein relationales Datenbankschema nach \cite{R*91} erl"autert, bevor in Abschnitt~\ref{Abs. MS-Access} das f"ur den Prototyp verwendete Datenbankprogrammiersystem {\acc}  aus \cite{Ba94}, \cite{HK94} und \cite{Ze93} kurz vorgestellt wird. Danach wird in Abschnitt~\ref{Abs. JDE} ein "Uberblick "uber die {\jdb} gegeben. Diese sorgt f"ur die Kommunikation zwischen der Datenbank und der Benutzerschnittstelle (siehe Kapitel~\ref{Kap. Benutzerschnittstelle}).

\section{Umsetzung des OMT-Objektmodells in ein relationales Datenbankschema}
\label{Abs. Umsetzung}

Das relationale Datenmodell basiert auf dem Konzept der Tabelle. Ein RDBMS (\e {Relational Database Management System}) wie {\acc} ist ein Computerprogramm, da"s Tabellen administriert. Es setzt sich nach \cite{R*91} aus drei Hauptteilen zusammen:

\begin{description}
\item [Daten:]\hspace{.1cm}
Daten werden in Tabellen repr"asentiert. Tabellen haben eine festgelegte Anzahl von Spalten und eine beliebige Anzahl von Zeilen. Die Spalten einer Tabelle werden \e {Attribute} genannt und entsprechen den Attributen in Objektmodellen. Die Zeilen werden \e {Tupel} genannt und entsprechen den Objektinstanzen und den Verbindungen.
\end{description}
\begin{description}
\item [Operatoren:]\hspace{.1cm}
Operatoren dienen der Manipulation von Tabellen. Der Standard sowohl nach ANSI (\e {American National Standards Institute})  als auch ISO (\e {International Standards Organisation}) ist hier die Anfragesprache SQL. Mit Hilfe des SQL \e{select statement} k"onnen Daten aus Tabellen gelesen werden. Andere SQL-Operatoren k"onnen Daten aus Tabellen l"oschen, Tabellen erzeugen, Zeilen in Tabellen einf"ugen oder l"oschen, etc. 
\end{description}
\begin{description}
\item [Integrit"atsbedingungen:]\hspace{.1cm}
Man unterscheidet zwei Arten von Integrit"at. Die \e {existentielle} Integrit"at besagt, da"s jede Tabelle genau einen Prim"ar\-schl"us\-sel hat. Ein Pri\-m"ar\-schl"us\-sel ist eine Kombination von einem oder mehreren Attributen, deren Wert jede Zeile der Tabelle eindeutig identifiziert. \e {Referentielle} Integrit"at erfordert, da"s das RDBMS die Konsistenz jedes Fremdschl"ussels mit seinem zugeh"origen Prim"arschl"ussel "uberwacht. Ein Fremdschl"ussel ist ein Prim"arschl"ussel einer Tabelle, der in eine andere Tabelle integriert ist.
\end{description}

\subsection{"Ubersetzung von Objektklassen in Tabellen}
\label{Umsetz1}
Jede Klasse in einem OMT-Objektmodell entspricht einer oder mehrerer Tabellen. Eine Tabelle kann aber ebenfalls einer oder mehreren Klassen entsprechen (siehe Abschnitt~\ref{Umsetz2}). In Abbildung~\ref{Konv1} ist die Konvertierung einer Objektklasse in OMT-Notation in eine Tabelle dargestellt. Die Klasse \e {Karte mit Zitat aus Literatur} hat die Attribute \e {Zitat} und \e {Kommentar}. Die zugeh"orige Tabelle enth"alt diese Attribute und zus"atzlich die implizite Objekt-ID, die eine eindeutige Identifzierung der einzelnen Datens"atze erm"oglicht und daher als Prim"arschl"ussel dient.  

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=5cm
\epsffile{/usr/users/boesch/Studienarbeit/Latex/Bilder/datenbank/classtotable1.epsf}
\end{center}
\caption{Konvertierung einer Klasse in eine Tabelle}
\label{Konv1}
\end{figure}

\subsection{"Ubersetzung von bin"aren Assoziationen in Tabellen}
\label{Umsetz2}
Es kann keine generelle Aussage gemacht werden, ob eine Assoziation einer Tabelle entspricht oder nicht, denn dies h"angt vom Typ und der Kardinalit"at der Assoziation und den Pr"aferenzen des Datenbankentwicklers in Bezug auf Erweiterbarkeit, Anzahl der Tabellen und Leistungsanforderungen ab.

Jede n:m Assoziation entspricht einer eigenen Tabelle. Hierbei werden die Pri\-m"ar\-schl"us\-sel der beiden in Beziehung stehenden Klassen und alle Verbindungsattribute Attribute der Assoziationstabelle (siehe Abbildung~\ref{Konv2}). Die Kombination der Attribute \e {KartenID} und \e {Stichwortpfad} ergibt den Prim"arschl"ussel der Tabelle \e {abgelegtUnter}. Hierbei ist die "Uberwachung der referentiellen Integrit"at der beiden Attribute wichtig. Jedes Tupel der Tabelle \e {abgelegtUnter} mu"s eine \e {Karte} und ein \e {Stichwort} referenzieren, die in ihren eigenen Tabellen definiert werden. Die Tabellen f"ur die Klassen \e {Karte} und \e {Stichwort} "ahneln der \e {Zitatkarten}-Tabelle aus Abbildung~\ref{Konv1}.

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=14cm \epsfysize=6cm
\epsffile{/usr/users/boesch/Studienarbeit/Latex/Bilder/datenbank/classtotable2.epsf}
\end{center}
\caption{Konvertierung einer n:m Assoziation
 in eine Tabelle}
\label{Konv2}
\end{figure}

Die Abbildungen~\ref{Konv3} und~\ref{Konv4} zeigen zwei M"oglichkeiten, eine 1:n Assoziation in eine Tabelle umzuwandeln. Man kann eine separate Tabelle erzeugen oder einen Fremdschl"ussel in die Tabelle f"ur die \e{Bildkarten}-Klasse einbetten. Die Vorteile der Integration einer Assoziation in eine Klasse sind:
\begin {itemize}
\item weniger Tabellen
\item schnellerer Zugriff (in diesem Fall von der \e{Bildkarten}-Tabelle aus)
\end{itemize} 
Die Nachteile, eine Assoziation in eine Klasse zu integrieren, sind:
\begin{itemize}
\item \e{Geringere Designgenauigkeit}: Assoziationen werden zwischen voneinander unabh"angigen, gleichwertigen Objekten definiert. Daher ist es normalerweise nicht angemessen, Objekte mit dem Wissen "uber andere Objekte zu erweitern. 
\item \e {Reduzierte Erweiterbarkeit}: "Anderungen der Kardinalit"aten von Beziehungen k"onnen weitreichende Auswirkungen auf das Datenbankschema haben.
\item \e {Gr"o"sere Komplexit"at}: Eine asymmetrische Repr"asentation verkompliziert Such- und "Anderungsoperationen.
\end{itemize}
Die Tabellen f"ur die Klassen \e {Bildkarte} und \e {K"unstler} aus der Abbildung~\ref{Konv3} "ahneln der \e {Zitatkarten}-Tabelle aus Abbildung~\ref{Konv1}. 

Die Entscheidung, ob eine Assoziation in eine Klasse integriert wird oder nicht, h"angt letztlich von der Anwendung ab.

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=5cm
\epsffile{/usr/users/boesch/Studienarbeit/Latex/Bilder/datenbank/classtotable3.epsf}
\end{center}
\caption{Konvertierung einer 1:n Assoziation
 in eine Tabelle (a) }
\label{Konv3}
\end{figure}

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=3cm
\epsffile{/usr/users/boesch/Studienarbeit/Latex/Bilder/datenbank/classtotable4.epsf}
\end{center}
\caption{Integration einer 1:n Assoziation
 in eine Tabelle (b)}
\label{Konv4}
\end{figure}


\subsection{"Ubersetzung von Generalisierungsbeziehungen in Tabellen}
\label{Umsetz3}
Es gibt drei Ans"atze f"ur die "Ubersetzung von Generalisierungsbeziehungen in Tabellen. Als Grundlage f"ur die Erl"auterungen dieser Strategien dient Abbildung~\ref{Gen1}, die besagt, da"s eine Instanz der abstrakten Klasse \e{Karte} entweder eine Instanz der Klasse \e{Bildkarte}, der Klasse \e{Zitatkarte} oder der Klasse \e{Literaturkarte} ist. Au"serdem werden die Attribute der abstrakten Superklasse \e{Karte} auf ihre drei Subklassen vererbt.  

\begin{figure}[hbtp]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=6cm
\epsffile{/usr/users/boesch/Studienarbeit/Latex/Bilder/datenbank/general2.epsf}
\end{center}
\caption{Objektmodell einer Generalisierung}
\label{Gen1}
\end{figure}

\begin{figure}[hbtp]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=7cm
\epsffile{/usr/users/boesch/Studienarbeit/Latex/Bilder/datenbank/general3.epsf}
\end{center}
\caption{Tabellenmodell einer Generalisierung -- Super- und Subklassen}
\label{Gen2}
\end{figure}

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize= 4,5cm
\epsffile{/usr/users/boesch/Studienarbeit/Latex/Bilder/datenbank/general4.epsf}
\end{center}
\caption{Tabellenmodell einer Generalisierung -- mehrere Subklassen}
\label{Gen3}
\end{figure}

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=6cm
\epsffile{/usr/users/boesch/Studienarbeit/Latex/Bilder/datenbank/general5.epsf}
\end{center}
\caption{Tabellenmodell einer Generalisierung -- eine Superklasse}
\label{Gen4}
\end{figure}


Abbildung~\ref{Gen2} zeigt den "ublichen Ansatz. Sowohl die Superklasse als auch die Subklassen werden jeweils in eine Tabelle "ubertragen. Die Identit"at eines Objektes wird durch die gemeinsame \e {KartenID} sichergestellt. Dieser Ansatz ist zwar logisch klar und erweiterbar, erzeugt aber viele Tabellen und kann die Performanz der Datenbank bei Such- oder "Anderungsoperationen beeintr"achtigen.

Die Abbildungen~\ref{Gen3} und~\ref{Gen4} zeigen alternative Ans"atze, die die Navigation zwischen Superklasse und Subklassen vermeiden und dadurch Geschwindigkeitsvorteile erbringen k"onnen. Die Variante aus Abbildung~\ref{Gen3} kann sinnvoll sein, wenn die Superklasse nur eine geringe Anzahl von Attributen hat und im Anwendungsprogramm ermittelt wird, welcher Typ von Karte gesucht werden soll. 
Der Ansatz in Abbildung~\ref{Gen4} integriert alle Subklassenattribute in die Tabelle der Superklasse. Jedes Tupel in dieser Tabelle enth"alt nur die Attribute, die f"ur den jeweiligen Typ von Karte vorgesehen sind. Dieser Ansatz mag beim Bearbeiten einer \e {Bildkarte} noch sinnvoll sein, wenn aber eine \e {Literaturkarte} bearbeitet wird, enth"alt der Gro"steil der Attribute nur Nullwerte. Dieser Ansatz ist sinnvoll, wenn es nur zwei oder drei Subklassen mit wenigen Attributen gibt.

\section{{\acc} - ein "Uberblick}
\label{Abs. MS-Access}
{\acc} ist ein Datenbankprogrammiersystem zum Anlegen und Bearbeiten von relationalen Datenbanken unter {\win}. Zu einer {\acc}-Datenbank geh"oren folgende Objekte:

\begin{description}
\item [Tabellen:]\hspace{.1cm}
Eine Tabelle ist eine Sammlung von Daten einer Kategorie, z.B. eine Menge von Stichworten oder ein Menge von Bildkarten. Tabellen sind in Zeilen und Spalten unterteilt, wobei jede Zeile einer Tabelle genau einen aus mehreren Feldern bestehenden Datensatz enth"alt.
\end{description}
\begin{description}
\item [Abfragen:]\hspace{.1cm}
Abfragen stellen eine eingeschr"ankte Sicht auf eine Verkn"upfung mehrerer Tabellen durch einen Filter dar. So k"onnen Daten nach vom Benutzer ausgew"ahlten Kriterien aus einer oder mehreren Tabellen angezeigt werden. 
\end{description}
\begin{description}
\item [Formulare:]\hspace{.1cm}
Formulare basieren auf Tabellen oder Abfragen und zeigen die darin enthaltenen Daten an. W"ahrend Tabellen und Abfragen optisch einfach als Listen dargestellt werden, entsprechen Formulare eher Karteikarten und zeigen meist nur einen Datensatz an. In Formularen k"onnen beliebige Formatierungen der Daten vorgenommen werden.
\end{description}
\begin{description}
\item [Berichte:]\hspace{.1cm}
Berichte basieren wie Formulare auf Tabellen oder Abfragen und erm"oglichen ebenfalls die optisch ansprechende Gestaltung der darin enthaltenen Daten. Die angezeigten Daten k"onnen in einem Bericht nicht bearbeitet, sondern nur ausgedruckt werden. 
\end{description}
\begin{description}
\item [Makros:]\hspace{.1cm}
Makros werden zur Automatisierung h"aufig ben"otigter Aktionen, wie z.B. dem "Offnen einer Tabelle, verwendet.
\end{description}
\begin{description}
\item [Module:]\hspace{.1cm}
{\acc} enth"alt die Programmiersprache {\acc}-BASIC. {\acc}-BASIC ist eine Variante der Programmiersprache {\vb} (siehe Abschnitt~\ref{Abs. VB}), mit der Prozeduren und Funktionen zum L"osen spezieller Datenbankprobleme erstellt werden k"onnen. Diese Prozeduren und Funktionen werden dann in Modulen zusammengefa"st. 
\end{description}


Diese Objekte sind "uber das sogannte Datenbankfenster zug"anglich und werden zusammen mit den Daten in einer Datei abgelegt. Zur Unterst"utzung des Anwenders gibt es ein umfangreiches interaktives und kontextab\-h"angi\-ges Hilfesystem. Sogenannte \e {Assistenten} dienen der nahezu automatischen Generierung von Tabellen, Abfragen, Formularen und Berichten. Ein \e {Ratgeber} f"uhrt schrittweise zu Probleml"osungen und gibt dem Anwender detailliert Anleitungen zur Vorgehensweise. 

{\acc}  verf"ugt "uber umfassende, flexible Im- und Export-M"oglichkeiten. F"ur den Im- und Export von Textdateien lassen sich Text- und Spaltentrennzeichen sowie das Datumsformat festlegen. Dies wurde genutzt, um gro"se Textdatenbest"ande eines K"unstlerindex in die Datenbank zu integrieren und somit systematisch zug"anglich zu machen.  

Neben dem Import bietet {\acc}  die M"oglichkeit der Einbindung von Tabellen anderer Datenbanken (z.B. im {\sf dBase}-Format). Dabei erscheint dem Anwender die eingebundene Tabelle, als w"are sie Bestandteil der aktuellen Datenbank; in Wirklichkeit f"uhrt {\acc}  jedoch alle Operationen auf den Originaldaten direkt aus. Der Zugriff auf Datenbest"ande in Datenbanken anderer Hersteller erfolgt "uber die ODBC-Schnittstelle (\e {Open Database Connectivity}). Daten aus {\acc}-Datenbanken k"onnen "uber diese Schnittstelle ebenfalls von anderen Anwendungen gelesen werden.  

Die Kommunikation zwischen {\win}-Anwendungen erfolgt "uber die OLE-Schnittstelle (\e {Objekt Linking and Embedding}). Das bedeutet, da"s Daten aus {\acc}  mit einem Maus\-klick in andere {\win}-Anwendungen (z.B. Textverarbeitung), die ebenfalls OLE unterst"utzen, "ubernommen werden k"onnen und umgekehrt. 

Die M"oglichkeiten von {\acc} in Bezug auf die Einbindung von Tabellen anderer Datenbanken und auf die Kommunikation zwischen {\win}-Anwendungen waren w"ahrend dieser Arbeit nicht von Belang. {\acc} bietet mit ihnen aber eine gro"se Offenheit gegen"uber sp"ateren Erweiterungen.

\subsection{Der {\acc}-Tabelleneditor}
\label{Abs. Acc-Editoren1}
Im Zusammenhang mit dieser Arbeit waren der Tabelleneditor zur Definition der Tabellen und der Beziehungseditor (siehe Abschnitt~\ref{Abs. Acc-Editoren2}) zur Definition der Relationen zwischen den Tabellen besonders wichtig. Im Tabelleneditor enth"alt jede Zeile des Entwurfsformulars genau eine \e{Felddefinition}, bestehend aus 
\begin{itemize}
\item dem Feldnamen,
\item dem Felddatentyp und
\item der Feldbeschreibung.
\end{itemize}

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=9,5cm
\epsffile{/usr/users/boesch/Studienarbeit/Latex/Bilder/datenbank/acctab.ps}
\end{center}
\caption{Der {\acc}-Tabelleneditor}
\label{Acc1}
\end{figure}

Au"serdem werden f"ur jedes Feld die Feldeigenschaften festgelegt. Diese bestehen z.B. aus der Feldgr"o"se, dem Feldformat, dem Standardwert, einer G"ultigkeitsregel, etc. Mit diesen Feldeigenschaften k"onnen also Bedingungen f"ur den Feldinhalt definiert werden, die sp"ater bei jeder "Anderung eines Datensatzes automatisch von {\acc} "uberpr"uft werden und bei deren Nichteinhaltung eine Fehlermeldung erzeugt wird. Im Tabelleneditor wird auch der Prim"arschl"ussel einer Tabelle festgelegt.

In Abbildung~\ref{Acc1} ist die Tabelle \e{Bildkarten} im {\acc}-Tabelleneditor dargestellt. Der Pri\-m"ar\-schl"us\-sel ist hier das Feld \e{ID}, erkennbar an dem kleinen Schl"usselsymbol links vom Feldnamen. In der Spalte rechts neben dem Feldnamen wird der Felddatentyp festgelegt, in diesem Fall der Typ \e{Zahl}. Die L"ange des Feldes wird bei den Feldeigenschaften festgelegt. Eine Zahl vom Datentyp \e{Long Integer} ist eine ganze Zahl zwischen -2.2147.483.648 und 2.147.483.647 und belegt 4 Byte Speicherplatz. Das hei"st, mit der genauen Bestimmung der Gr"o"se eines Feldes l"a"st sich der Speicherplatzbedarf optimieren.

\subsection{Der {\acc}-Beziehungseditor}
\label{Abs. Acc-Editoren2}
Im Beziehungseditor k"onnen Relationen zwischen Tabellen grafisch definiert werden, indem man mit der Maus ein Feld einer Tabelle "uber ein mit diesem zu verkn"upfendes Feld einer anderern Tabelle zieht und es dort fallenl"a"st (\e{drag and drop}). Es k"onnen drei Arten von Beziehungen definiert werden:

\begin{description}
\item [1:1-Beziehungen:]\hspace{.1cm}
Zu jedem Datensatz einer Tabelle gibt es genau einen passenden Datensatz in einer anderen Tabelle. Die Verbindung zwischen den Tabellen wird dadurch hergestellt, da"s beide Tabellen den gleichen Prim"arschl"ussel haben.  1:1-Beziehungen sind meistens nur der "Ubersicht wegen sinnvoll. Ebensogut w"are es m"oglich, beide Tabellen zu einer zusammenzufassen.
\end{description}
 
\begin{description}
\item [1:n-Beziehungen:]\hspace{.1cm}
Ein Datensatz in einer Tabelle ist mit einem oder mehreren Datens"atzen einer zweiten Tabelle verkn"upft. 1:n-Beziehungen werden hergestellt, indem der Prim"arschl"ussel der Tabelle \e{1} in die Tabelle \e{n} eingef"ugt wird. 1:n-Beziehungen sind die am h"aufigsten auftretenden Beziehungen.
\end{description}

\begin{description}
\item [n:m-Beziehungen:]\hspace{.1cm}
Zu mehreren Datens"atzen einer Tabelle gibt es mehrere Datens"atze in einer anderen Tabelle. n:m-Beziehungen k"onnen in {\acc} nicht direkt abgebildet werden. Die Realisierung erfolgt mit Hilfe einer dritten Tabelle, die die n:m-Beziehung in zwei 1:n-Beziehungen aufl"ost.
\end{description}

Die {\acc}-Datenbankmaschine ({\jdb}, siehe Abschnitt~\ref{Abs. JDE}) sorgt bei Bedarf f"ur die "Uberwachnung der referentiellen Integrit"at der Daten und bietet au"serdem Funktionen zur automatischen Aktualisierungs- und L"oschweitergabe an: werden also Eintr"age einer Tabelle ge"andert oder gel"oscht, "ubertr"agt {\acc}  die "Anderungen automatisch auf die von ihr abh"angige Tabelle. 


In Abbildung~\ref{Acc2} ist die n:m-Beziehung zwischen den \e{Stichworten} und den ihnen zugeordneten \e{Karten} im {\acc}-Beziehungseditor dargestellt. Die Abbildung auf ein relationales Schema erfordert die Tabelle \e{abgelegtunter}, in der nicht nur die beiden Prim"arschl"ussel der beiden Tabellen enthalten sind, sondern auch das Verbindungsattribut \e{IstOriginal}, das festlegt, unter welchem Stichwort die physische Originalkarte im Index zur politischen Ikonographie eingeordnet ist. 

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=5cm
\epsffile{/usr/users/boesch/Studienarbeit/Latex/Bilder/datenbank/accbez.ps}
\end{center}
\caption{Der {\acc}-Beziehungseditor}
\label{Acc2}
\end{figure}


\section{Die Jet Datenbank-Engine}
\label{Abs. JDE}
Der Austausch von Daten zwischen dem Anwendungsprogramm und der Datenbank erfolgt im Falle des Protoypen f"ur den Index zur politischen Ikonographie "uber die {\jdb} der {\msc} Sie wird in {\acc} in der Version 2.0 verwendet, in {\vb} hingegen in Version 1.1. Daher k"onnen {\vb}-Applikationen erst nach der Installation einer Kompatibilit"atsschicht auf {\acc}-Datenbanken der Version 2.0 zugreifen. Diese Kompatibilit"atsschicht ist im Internet frei verf"ugbar und kann mit Hilfe des FTP (\e{File Transfer Protocol}) auf den lokalen Rechner "ubertragen werden. Nach der Installation der Kompatibilit"atsschicht erfolgt die Kommunikation zwischen {\vb} und {\acc} problemlos. Da jedoch der Funktionsumfang der {\jdb} mit der Version 2.0 erweitert wurde, gibt {\vb} bei Fehlern, die auf diesen Neuerungen beruhen, nur Fehlernummern aus und nicht wie sonst Hinweise auf die Ursache des aufgetretenen Fehlers.

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=6,5cm
\epsffile{/usr/users/boesch/Studienarbeit/Latex/Bilder/datenbank/Jet-Engine.epsf}
\end{center}
\caption{Hierarchie der Datenzugriffsobjekte der {\jdb}}
\label{Jet}
\end{figure}

Die {\jdb} besteht aus einer Hierarchie von unterschiedlichen Objekten. Die Pfeile in Abbildung~\ref{Jet} sind als Inklusionsbeziehung zwischen den Objekten zu verstehen, d.h. die \e{Jet Engine} enth"alt das Unterobjekt \e{Workspaces}, die \e{Workspaces} enthalten \e{Databases}, etc. Die Objekte im einzelnen:

\begin{description}
\item [Workspaces:]\hspace{.1cm}
 Ein \e{Workspace}-Objekt ist eine Art Beh"alter f"ur die aktuelle Sitzung eines Anwenders und enth"alt eine den Anwender identifizierende Benutzerkennung und sein Pa"swort. In Mehrbenutzer-Umgebungen existieren mehrere dieser \e{Workspace}-Objekte.
\end{description}

\begin{description}
\item [Databases:]\hspace{.1cm}
Jedes \e{Database}-Objekt repr"asentiert eine komplette Datenbank, inkl. Tabellen, Relationen, Abfragen, etc. 
\end{description}

\begin{description}
\item [Relations:]\hspace{.1cm}
Alle Beziehungsdefinitionen zwischen den in einer Datenbank enthaltenen Tabellen werden \e{Relations} genannt. 
\end{description}

\begin{description}
\item [TableDefs:]\hspace{.1cm}
Die Definitionen aller in einer Datenbank enthaltenen Tabellen mit ihren Feldern (\e{Fields}) und Indizes (\e{Indexes}) sind in dem Objekt \e{TableDefs} zusammengefa"st. 
\end{description}

\begin{description}
\item [QueryDefs:]\hspace{.1cm}
Jede \e{QueryDef} ist die Definition einer in der Datenbank enthaltenen Abfrage. 
\end{description}

\begin{description}
\item [RecordSets:]\hspace{.1cm}
\e{RecordSet}-Objekte enthalten Datens"atze, die auf Tabellen, Abfragen oder SQL-Anweisungen basieren. Diese Datens"atze k"onnen editiert und gel"oscht werden; auch das Hinzuf"ugen weiterer Datens"atze ist m"oglich. 
\end{description}

\begin{description}
\item [Containers:]\hspace{.1cm}
Ein \e{Container} enth"alt die Beschreibungen aller Objekte in einer Datenbank.
\end{description}

Das wichtigste im Zusammenhang mit dieser Arbeit ist die Steuerung des Zugriffs auf Datens"atze in Tabellen (\e{RecordSets}), deren Felder (\e{Fields}) und die Beziehungen zwischen den Tabellen (\e{Relations}). Mit Hilfe von \e{QueryDefs} lassen sich auch Anfragen in der Datenbank selbst abspeichern.  Allerdings k"onnte beim Aufruf solcher Abfragen vom Anwendungsprogramm aus die Transparenz des Programmablaufes f"ur den Programmierer verloren gehen. Au"serdem k"onnen Anfragen an die Datenbank teilweise erst zur Laufzeit des Programms mit Hilfe von Benutzereingaben formuliert werden, z. B. wenn es darum geht, nur die Bilder zu einem bestimmten Stichwort anzuzeigen. Aus diesem Grund wurden die \e{QueryDefs} nicht genutzt und die Anfragen an die Datenbank mit Hilfe von SQL im Anwendungsprogramm formuliert. 

