\section{Informationssysteme und Datenbanksysteme}
\label{Informationssysteme und Datenbanksysteme}

In diesem Abschnitt wird zun"achst eine wichtige Klasse von Softwaresystemen
vorgestellt, die als \e{Informationssysteme} bezeichnet werden, und die sich
durch charakteristische Eigenschaften (Persistenz, Quantit"at, Reaktivit"at,
Integrit"at) von anderen Softwaresystemen unterscheiden (Abschnitt 1.1.1).

Darauf aufbauend werden \e{Datenbanksysteme als generische Diensterbringer}
zur effizienten Realisierung von Informationssystemen unter besonderer
Ber"ucksichtigung dieser charakteristischen Systemeigenschaften beschrieben
(Abschnitt 1.1.2). In diesem Zusammenhang werden \e{Datenbanksprachen}
ben"otigt, um die generischen Dienste eines Datenbanksystems, die durch ein
\e{Datenbankmodell} beschrieben werden, flexibel an die speziellen
Anforderungen eines konkreten Informationssystems anzupassen.

Die Persistenz, Quantit"at, Reaktivit"at und Integrit"at von
Informationssystemen besitzt wichtige system- und softwaretechnische
Konsequenzen, die zu konkreten Anforderungen an Datenbankmodelle,
Datenbanksprachen und Datenbanksprachschnittstellen f"uhren (Abschnitt
1.1.3). Die klassischen Datenbankmodelle machen dar"uber hinaus weitere
implizite spezialisierende Annahmen "uber die Struktur und Nutzung von
Informationssystemen, die auch Hinweise f"ur die k"unftige Weiterentwicklung
von Datenbankmodellen liefern (Abschnitt 1.1.4).

Der Einsatz (standardisierter) Datenbankdienste bei der Realisierung von
Informationssystemen f"uhrt in der Praxis zu erheblichen Produktivit"ats- und
Qualit"atsverbesserungen "uber den gesamten Softwarelebenszyklus hinweg, die in
Abschnitt 1.1.5 genauer beleuchtet werden.

Dieser Abschnitt schlie"st mit der Beschreibung eines prototypischen
Firmeninformationssystems, das durchg"angig als Beispiel im ersten Kapitel
verwendet wird (Abschnitt 1.1.6).

\subsection{Charakteristika von Informationssystemen}
\label{Charakteristika von Informationssystemen}

Sp"atestens Ende der 60er Jahre hat sich recht deutlich ein Wandel im Einsatz
von Softwaresystemen vollzogen. Computer sind als Instrumente zur L"osung
numerischer Berechnungsaufgaben zunehmend in den Hintergrund getreten und
werden allgemein als Systeme zur Repr"asentation und Verarbeitung von 
\e{Informationen} eingesetzt. Die meisten der heute kommerziell entwickelten
Softwaresysteme sind sogenannte \e{Informationssysteme}, die oft auch als
datenintensive Anwendungen oder spezieller als Datenbankanwendungen bezeichnet
werden.

Informationssysteme wurden historisch gesehen zun"achst in
Verwaltungsabteilungen gros\-ser Organisationen, wie Versicherungen, Banken,
Telekommunikationsunternehmen oder Versandunternehmen, f"ur kaufm"annische
informationsverarbeitende Aktivit"aten eingesetzt. Durch die weite Verbreitung
von Computern als Arbeitsplatz-, Gruppen- und Abteilungsrechner existieren
jedoch heutzutage auch zahlreiche dezentralisierte Informationssysteme f"ur
Informationsbest"ande verschiedenster Gr"o"se und Komplexit"at, die von
unterschiedlichen Benutzergruppen in verschiedenen Modalit"aten (lokal und
entfernt, interaktiv und programmgest"utzt) bearbeitet werden.

Allgemein l"a"st sich ein \e{Informationssystem} als ein Softwaresystem mit
folgenden charakteristischen Eigenschaften definieren (\glqq
PQRI-Anforderungen\grqq\ , s. auch Abbildung \ref{Informationssystem}):

%\renewcommand{\epsfsize}[2]{0.7#1}

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfig{file=Bilder/PostScript/1.eps}
\caption{Schematische Struktur eines Informationssystems}
\label{Informationssystem}
\end{center}
\end{figure}

\begin{description}

\item[Persistenz (Langlebigkeit):] Ein Informationssystem 
verwaltet einen Informationsbestand, dessen Lebensdauer nicht 
durch die Lebensdauer individueller informationsverarbeitender 
Aktivit"aten beschr"ankt ist.

\item[Quantit"at:] Ein Informationssystem verwaltet einen umfangreichen, 
regul"ar strukturierten Informationsbestand, dessen Struktur 
zum Entwurfszeitpunkt des Informationssystems fixiert wird, dessen 
Gr"o"se jedoch "uber die gesamte Lebensdauer des Informationssystems 
hinweg dynamisch variiert.

\item[Reaktivit"at:] Ein Informationssystem ist in die
informationsverarbeitenden Aktivit"aten seiner Umgebung eingebunden. Es
aktualisiert seinen Informationsbestand unmittelbar basierend auf einkommenden
Informationen, antwortet auf explizite Informationsanfragen und l"ost auch
selbst"andig Aktivit"aten in der Umgebung aus.

\item[Integrit"at:] Ein Informationssystem wahrt Integrit"atsbedingungen, 
die sich sowohl auf seinen persistenten Informationsbestand als 
auch auf die einkommenden und ausgehenden Informationen beziehen 
k"onnen. 

\end{description}

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfig{file=Bilder/PostScript/3.eps}
\caption{Realisierung eines Informationssystems mit einer Datenbank}
\label{Informationssystem und Datenbank}
\end{center}
\end{figure}

Der Vergleich zwischen Abbildung \ref{Informationssystem} und
Abbildung \ref{Informationssystem und Datenbank} zeigt, wie
\e{Datenbanksysteme als Diensterbringer} bei der Realisierung von
Informationssystemen eingesetzt werden. Dabei werden die Aufgaben der
persistenten Datenspeicherung und des effizienten Massendatenzugriffs
an ein Datenbanksystem delegiert. Dar"uber hinaus k"onnen Teilaufgaben
der Integrit"atsverwaltung und der Realisierung der Reaktivit"at
ebenfalls durch das Datenbanksystem "ubernommen werden.  Das
\e{Datenbankschema} definiert dabei die Schnittstelle zwischen den
verbleibenden informationsverarbeitenden Algorithmen des
Informationssystems und den Diensten der Datenbank.

In Abbildung \ref{Informationssystem und Datenbank} wird, wie auch
im folgenden Text, zwischen \e{Daten} und \e{Informationen}
unterschieden. Daten sind kodierte, maschinenlesbare
\e{Repr"asentationen} von Informationen. Umgekehrt werden
Informationen aus Daten abgeleitet und zum \e{Probleml"osen}
eingesetzt (s. Reaktivit"at). Diese Unterscheidung hat sich in der
Informatik allgemein durchgesetzt und liegt auch zahlreichen
Standards, wie ISO, DIN, etc., zugrunde [xx]. An dieser Stelle gen"ugt
es darauf hinzuweisen, da"s teilweise nur ein gradueller Unterschied
zwischen Daten und Informationen besteht, wobei zum Beispiel der
Begriff Datenbestand eine eher \e{maschinenorientierte} Sicht und der
Begriff Informationsbestand eine eher \e{problemorientierte} Sicht
eines Systemzustandes bezeichnet.

Eine \e{Datenbank} ist also ein Softwaredienst zur Verwaltung eines
organisierten, langlebigen, strukturierten Datenbestands, w"ahrend ein 
\e{Informationssystem} zus"atzlich zu der Datenbank noch Algorithmen zur
Interpretation der Daten als Informationen und umgekehrt zur Repr"asentation
von Informationen durch Daten umfa"st. 

\subsection{Dienstgest"utzte Realisierung von Informationssystemen}
\label{Dienstgestuetzte Realisierung von Informationssystemen}

Ein wesentliches Ziel der angewandten Informatik ist die Entwicklung von
Modellen, Sprachen und \e{generischen} Diensterbringern oder Werkzeugen, die
den Vorgang der Anwendungs- und Systementwicklung effizienter und effektiver
gestalten. Im Unterschied zu \e{spezifischen} Diensten und
Softwarewerkzeugen, wie zum Beispiel Druckdiensten, e-mail Diensten,
Finanzbuchhaltungssoftware oder Textverarbeitungssoftware, die ein konkretes
Anwendungsproblem l"osen, leisten generische Dienste und Werkzeuge einen
Beitrag f"ur eine gesamte \e{Problemklasse}. So sind zum Beispiel
Programmiersprachen generische Werkzeuge zur algorithmischen Programmierung,
GUI-Toolkits sind generische Werkzeuge zur Benutzerschnittstellengestaltung,
und Kommunikationssoftware bietet generische Dienste zur Anwendungsentwicklung
in Netzwerken.

Voraussetzung f"ur die Entwicklung erfolgreicher generischer Dienste und
Werkzeuge ist eine ad"aquate Konzeptualisierung der Problemklasse durch 
\e{Modellbildung}, typischerweise gepaart mit der Entwicklung
modellunterst"utzender \e{sprachlicher Notationen}. Diese Notationen werden
schlie"slich von den Dienstbenutzern zur \e{Dienstspezialisierung} bei der
Benutzung der generischen Werkzeuge eingesetzt.

So erlauben zum Beispiel eine Programmiersprache die Definition eines konkreten
Algorithmus', eine GUI Notation die Definition einer konkreten
Benutzerschnittstelle und eine Protokollbeschreibungssprache die Definition
einer konkreten Client/Server Verbindung.

In diesem Sinn sind Datenbanksysteme generische Diensterbringer (\e{general
purpose software}), die f"ur die L"osung der charakteristischen, bei der
Realisierung von \e{Informationssystemen} immer wiederkehrenden
PQRI-Anforderungen eingesetzt werden, und Datenbanksprachen sind Notationen zur
Dienstspezialisierung gem"a"s eines vorgegebenen Datenbankmodells.

Wie in Abbildung \ref{gen. Diensterbringer} dargestellt, wird also
der Implementierungsaufwand f"ur die in Abbildung
\ref{Informationssystem und Datenbank} angedeutete Datenbank im
wesentlichen auf die Beschreibung des spezifischen Datenbankschemas
reduziert, das eine Spezialisierung des generischen Datenbankdienstes
an die Anforderungen des speziellen Informationssystems leistet.

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/4.eps}
\caption{Datenbanksysteme als generische Diensterbringer bei der Realisierung 
von Informationssystemen}
\label{gen. Diensterbringer}  
\end{center}
\end{figure}

Zur Realisierung der Datenbanken zu den Informationssystemen \p{A} und
\p{B} in Abbildung \ref{gen. Diensterbringer} gen"ugt also die
Definition von geeigneten Datenbankschemata.  Die Dienste zur
Speicherung der Daten und zur Integrit"ats"uberwachung werden in
generischer Form vom Datenbanksystem zur Verf"ugung gestellt und durch
die Datenbankschemata f"ur die speziellen Anforderungen des
Informationssystems \p{A} bzw. \p{B} spezialisiert. Es ist dabei
unerheblich, ob beide Informationssysteme auf dem gleichen
physikalischen Datenbanksystem arbeiten oder jedes auf einer eigenen
Auspr"agung, wichtig ist, da"s der Aufwand f"ur die Erstellung dieses
Systems nur einmal anf"allt.

An dieser Stelle ist es hilfreich, den Zusammenhang zwischen den Begriffen
Datenbanksystem, Datenbankmodell, Datenbankschema, Datenbank und
Datenbanksprache und ihren Analogien auf dem Gebiet der Programmiersprachen
explizit aufzuzeigen.

\begin{description}

\item[] Ein \e{Datenbankschema} beschreibt die Menge der Invarianten
  auf einer speziellen Datenbank. Diese Invarianten umfassen die Namen
  der Datenbankobjekte, ihre (regul"are) Strukturen, die Beziehungen
  zwischen Datenbankobjekten, sowie die verf"ugbaren
  Datenbank\-operationen (Lesen, Einf"ugen, L"oschen, Aktualisieren).
  Ein Datenbankschema "ahnelt daher einer Modulschnittstelle, die
  Konstanten, Typen, typisierte Variablen und Prozedursignaturen
  definiert.

\item[] Eine \e{Datenbank} ist ein dynamischer, langlebiger
  Datenbestand, der den Invarianten seines Datenbankschemas gen"ugt.
  Eine Datenbank "ahnelt daher einer Modulimplementierung, die
  typkompatible Implementierungen aller in ihrer Schnittstelle
  genannten Namen exportiert. Die Semantik von Datenbanken
  unterscheidet sich jedoch wie folgt erheblich von der traditionellen
  Modulsemantik:

\begin{enumerate}
\item Die Zust"ande der exportierten Objekte einer Datenbank werden
  \e{persistent} (langlebig) gespeichert.

\item Mehrere Prozesse, die simultan auf der gleichen Datenbank
  arbeiten, referenzieren gemeinsam genutzte Objekte (\e{shared
    objects}), w"ahrend im Programmiersprachenkontext mehrere
  Prozesse, die das gleiche Modul importieren, proze"slokale Kopien
  der Modulobjekte (insbesondere der Modulvariablen) erhalten.
\end{enumerate}

\item[] Ein \e{Datenbankmodell} definiert die
  Strukturierungsmechanismen, Identifikationskonzepte und generischen
  Operationen, die zur Konstruktion eines Datenbankschemas und zur
  Beschreibung von Datenbankoperationen zur Verf"ugung stehen. Ein
  Datenbankmodell "ahnelt daher einem abstrakten
  Programmiersprachenmodell.

\item[] Ein \e{Datenbanksystem} stellt generische Implementierungen
  aller Operationen und Datenstrukturen eines Datenbankmodells zur
  Verf"ugung.  Datenbanksysteme f"ur einfache Datenbankmodelle (zum
  Beispiel f"ur das Netzwerkdatenmodell) k"onnen in Analogie zu
  generischen Modulen in Programmiersprachen gesehen werden: Ein
  Klient eines generischen Moduls spezialisiert die
  Modulfunktionalit"at durch (Typ-) Parametrisierung f"ur seine
  speziellen Bed"urfnisse. Datenbanksysteme f"ur moderne
  Datenbankmodelle erfordern hingegen wesentlich leistungsf"ahigere
  Parametrisierungskonzepte, um zum Beispiel deklarative
  Datenbankanfragen, Integrit"atsverwaltung und Aktivit"atssteuerung
  zu unterst"utzen.

\item[] Eine \e{Datenbanksprache} bietet diese weitergehenden
  Parametrisierungskonzepte, die zur Spezialisierung der
  Datenbanksystemdienste erforderlich sind. Sie definiert insbesondere
  Benennungsmechanismen, Sichtbarkeitsregeln, Lebensdauerregeln und
  Kombinationsregeln f"ur benutzerdefinierte Klassen, Beziehungen,
  Operationen und Integrit"atsbedingun\-gen.  Eine Datenbanksprache
  "ahnelt daher selbst einem spezialisierten
  Schnittstellenbeschreibungsformalismus (\e{interface definition
    language}, IDL), wie er zum Beispiel in modularen
  Programmiersprachen und in verteilten Objektsystemen zu finden ist.
\end{description}


\subsection{Anforderungen an Datenbankmodelle und Datenbanksprachen}
\label{Anforderungen an Datenbankmodelle und Datenbanksprache}

Die Persistenz, Quantit"at, Reaktivit"at und Integrit"at von 
Informationssystemen besitzt konkrete Konsequenzen f"ur die bei 
ihrer Softwarerealisierung eingesetzten Methoden, Modelle und 
Werkzeuge, die in den nachfolgenden Unterabschnitten beschrieben 
werden. Diese Beschreibung liefert gleichzeitig einen Anforderungskatalog 
f"ur die generischen Dienste von Datenbanksystemen, die, wie 
im vorangegangenen Abschnitt erl"autert wurde, durch Datenbankmodelle 
und Datenbanksprachen formalisiert werden.

\subsubsection{Unterst"utzung der Persistenz}
\label{Unterstuetzung der Persistenz}

Ein Informationssystem verwaltet einen Informationsbestand, dessen
Lebensdauer nicht durch die Lebensdauer individueller
informationsverarbeitender Aktivit"aten beschr"ankt ist.

In der Terminologie von Softwaresystemen werden alle Daten, deren 
Lebensdauer die Lebensdauer eines einzelnen Betriebssystemprozesses 
(also einer einzelnen Programmaktivierung) "uberschreitet, als 
\e{persistent} oder langlebig bezeichnet.

Gem"a"s der klassischen Sicht von Datenbanken ist der persistente 
Zustand eines Informationssystems ein Modell des 
\e{aktuellen} Zustands der Realit"at, genauer gesagt, der 
Aspekte der Realit"at, die f"ur das Informationssystem als relevant 
erachtet werden. So wird zum Beispiel der Kern eines Reservierungssystems 
durch die Daten der aktuellen Ressourcenbelegung gebildet. 

Die folgenden Beispiele verdeutlichen jedoch, da"s innerhalb 
von Informationssystemen neben dem Datenbankzustand mit quasi 
unendlicher Lebensdauer auch weitere persistente Datenbest"ande 
ben"otigt werden, deren Lebensdauer in weiten Grenzen variiert:

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/6.eps}
\caption{Unterst"utzung der Persistenz}
\label{Persistenz}  
\end{center}
\end{figure}

\begin{itemize}
\item Speicherung des transienten Zustands einer langandauernden
  Aktivit"at (z.B. einer aufwendigen numerischen Berechnung oder einer
  mehrstufigen Kommunikation mit entfernten Agenten) an einem
  \e{Sicherungspunkt}, um eine Fehlererholung im Falle eines
  Systemausfalls durchzuf"uhren (Minuten).

\item Speicherung einkommender Informationsanfragen oder
  Systemereignisse in \e{Warteschlangen} bis zu ihrer Bearbeitung
  durch das Informationssystem (Stunden).

\item Speicherung des Zustandes eines \e{Systemdialogs}
  (Fensteranordnung, Werkzeugpaletten, Standardeinstellungen) "uber
  mehrere interaktive Sitzungen hinweg (Tage).

\item Speicherung alternativer \e{Versionen} von Datenbest"anden f"ur
  experimentelle und vergleichende Studien (Wochen, Monate).

\item Speicherung von \e{Protokollinformationen} "uber relevante
  Systemereignisse, die h"aufig aus juristischen oder
  betriebswirtschaftlichen Gr"unden erforderlich sind (Jahre).

\item Speicherung von \e{historischen Datenbanksystemzust"anden }zur
  Archivierung und f"ur temporale Datenbankanfragen (Jahrzehnte).
\end{itemize}

Der heutige Stand der Technik erlaubt eine persistente Speicherung 
dynamischer Datenbest"ande nur auf Sekund"arspeichern (magnetische 
oder optische Festplatten) oder Terti"arspeichern (B"andern, 
Wechselplatten), wohingegen eine Datenverarbeitung ausschlie"slich 
mit Daten im Prim"arspeicher (RAM) m"oglich ist. Eine Hauptaufgabe 
von Datenbanksystemen ist daher die Verwaltung einer 
\e{Speicherhierarchie}, d.h. der effiziente Datentransfer 
zwischen Prim"ar-, Sekund"ar- und Terti"arspeicher. 

Moderne Datenbanksprachen bieten direkte Mechanismen zur Benennung und
Manipulation langlebiger Daten und erfordern keine expliziten Lade-
und Speicherungsoperationen. Sie erlauben dem Datenbankprogrammierer
damit eine \e{Persistenzabstraktion}. Somit werden die komplexen
Details des Datentransfers aus den Algorithmen des Informationssystems
eliminiert, und es wird dem Datenbanksystem ein erheblicher
Optimierungsspielraum bei der Organisation von Speicherzugriffen
gegeben.

Die persistente Speicherung des aktuellen Zustands eines Informationssystems 
erfordert auch die persistente Speicherung von Beschreibungsinformationen, 
wie zum Beispiel die Namen, Sichtbarkeitsbereiche und Strukturen 
der Nutzdaten, damit diese Daten langlebig interpretiert werden 
k"onnen. Die Beschreibungsdaten werden auch als 
\e{Metadaten }oder \e{Schemadaten} bezeichnet, w"ahrend die 
\e{Nutzdaten} den aktuellen Informationssystemzustand beschreiben.

Aufgrund der Langlebigkeit der Informationsbest"ande sind in 
praktisch allen Informationssystemen inkrementelle "Anderungen 
der Algorithmen zur Informationsverarbeitung und Integrit"atssicherung 
erforderlich, die eventuell auch eine Restrukturierung der Datenbankstrukturen 
nach sich ziehen, die aber nicht zu einem Verlust der bisher 
gespeicherten Informationen f"uhren d"urfen (\e{Schemaevolution}).


Bei der Realisierung der informationsverarbeitenden Algorithmen eines
Informationssystems ben"otigt man daher \e{inkrementelle }und \e{
  dynamische Bindungsmechanismen} zur Bindung von Variablennamen in
Algorithmen an persistente Datenbankobjekte. Datenbanksprachen bieten
daher typischerweise Anweisungen (z.B.\ \p{connect database}, \p{open
  table}, \p{open cursor}, etc.), um unter Benutzung der Metadaten zur
Programmlaufzeit solche Bindungen inkrementell und dynamisch zu
etablieren.

In diesem Zusammenhang bezeichnet der Begriff der
\e{Datenunabh"angigkeit} (\e{data independence}) die (relative)
Robustheit der informationsverarbeitenden Aktivit"aten gegen"uber
"Anderungen der Datenrepr"asentation in der Datenbank. So mu"s zum
Beispiel eine Literaturdatenbank verschiedenartige Anfrageformen, wie
z.B.\ den direkten Zugriff "uber Signaturen aber auch die
Volltextsuche und die Suche "uber Autoren, unterst"utzen, die durch
sehr unterschiedliche Datenbankzugriffsstrukturen (Streuspeicherung,
invertierte Dateien, physische Nachbarschaft auf dem
Sekund"arspeicher) realisiert werden k"onnen. Es ist daher zu
erwarten, da"s die Datenrepr"asentation einer Literaturdatenbank "uber
ihre Lebensdauer hinweg ver"andert werden mu"s, zum Beispiel um neuen
Benutzeranforderungen gerecht zu werden.

Eine weitere Konsequenz der Persistenz von Informationssystemen 
ist die Notwendigkeit, den Informationsbestand Ausf"alle einzelner 
Prozesse, Prozessoren oder Kommunikationsverbindungen "uberdauern 
zu lassen (\e{Fehlererholung}). In diesem Zusammenhang wird in Abschnitt 
1.4.7 ausschlie"slich die transaktionale Fehlererholung diskutiert, 
da sich weitergehende Modell- und Sprachkonzepte zur Fehlererholung 
(Ausnahmebehandlung, Replikation, partielle Sicherungspunkte) 
in der Praxis bisher nicht durchgesetzt haben.

\subsubsection{Unterst"utzung der Quantit"at}
\label{Unterstuetzung der Quantitaet}

Ein Informationssystem verwaltet einen umfangreichen, regul"aren 
Informationsbestand, dessen Struktur zum Entwurfszeitpunkt des 
Informationssystems fixiert werden kann, dessen Gr"o"se jedoch 
"uber die gesamte Lebensdauer des Informationssystems hinweg 
dynamisch variiert.

Die \e{Regularit"at} der Informationsstrukturen typischer
Informationssysteme l"a"st sich vorteilhaft zur kompakten
Datenmodellierung und effizienten Datenmanipulation nutzen. So lassen
sich in persistenten Informationsbest"anden h"aufig \e{Klassen} von
anonymen \e{Objekten} gleicher Struktur unterscheiden.  Zwischen den
Objekten dieser Klassen bestehen \e{Beziehungen}, und es k"onnen
\e{Invarianten} auf Informationsbest"anden formuliert werden, die
"uber die gesamte Lebensdauer des Systems g"ultig sind.

Zum Beispiel werden die Informationen einer Literaturdatenbank durch
Objekte von Klassen, wie \p{Artikel}, \p{Journal}, \p{Report},
\p{Buch}, \p{Institution}, \p{Katalog} und \p{Standort}, beschrieben,
zwischen denen Beziehungen, wie \p{publiziert-von}, \p{indiziert-in}
und \p{ausleihbar-an}, existieren. Eine m"ogliche Invariante einer
Literaturdatenbank ist die Forderung, da"s jeder Report von genau
einer Institution publiziert wird.

Zum Entwurfszeitpunkt eines Informationssystems sind also die Klassen
(ihre Namen und Strukturen), die m"oglichen Beziehungen zwischen den
Klassen (ihre Namen und Strukturen) und die Invarianten (Pr"adikate
auf Objekten, Klassen und Beziehungen) bekannt (\e{statische
  Typisierung}).W"ahrend der gesamten Lebensdauer des
Informationssystems werden Objekte dynamisch angelegt und gel"oscht,
in Beziehung zu anderen Objekten gesetzt, wobei jeweils die
G"ultigkeit der Invarianten gesichert werden mu"s (\e{dynamische
  Datenspeicherung}). Das \e{Datenbankschema} eines
Informationssystems ist also zeitlich stabil, w"ahrend sich der
\e{Datenbankzustand} eines Informationssystems dynamisch "andert.

Zur Realisierung von Klassen und Beziehungen werden \e{Massendatenstrukturen
  (bulk data types)} eingesetzt. Beispiele f"ur Massendatenstrukturen sind
sequentielle Dateien, Tabellen, Listen, Mengen oder Multimengen. Diesen
Datenstrukturen ist gemeinsam, da"s sie Kollektionen von Elementen mit
gleicher Elementstruktur beschreiben, wie z.B. eine Tabelle mit Artikeln oder
eine Liste mit Querverweisen, auf denen dynamische Einf"uge- und
L"oschoperationen durchgef"uhrt werden k"onnen.

Bei der Realisierung von Algorithmen auf Massendatenstrukturen treten h"aufig
stereotype Programmuster auf, um "ahnliche Informationsanfragen zu
befriedigen. Beispiele f"ur solche Programmuster sind: Existiert ein Element
in der Massendatenstruktur, das eine bestimmte Bedingung erf"ullt? Erf"ullen
alle Elemente der Massendatenstruktur eine bestimmte Bedingung? Erzeuge eine
Massendatenstruktur, die alle Elemente einer anderen Massendatenstruktur
enth"alt, die eine bestimmte Bedingung erf"ullen, usw.. Es besteht also ein
Bedarf nach \e{Iterationsabstraktion} (existenzielle Quantifizierung,
universelle Quantifizierung, Selektion, etc.), die es erm"oglicht, stereotype
\e{imperative} Programmuster wie Schleifen, Bedingungen und Rekursionen durch
eine \e{deklarative} Beschreibung der Informationsanfrage zu ersetzen.


Die obige Diskussion von Massendatenstrukturen und Iterationsabstraktionen
hebt nur die softwaretechnischen Vorteile in Bezug auf die
informationsverarbeitenden Prozesse (geringerer Kodieraufwand, verbesserte
Verst"andlichkeit, Wartbarkeit und Modularit"at) hervor. Ein in der Praxis
mindestens ebenso wichtiges Argument f"ur die Nutzung von Datenbankdiensten
f"ur diese Aufgaben ist jedoch die \e{Effizienz der Datenselektion}, die von
Datenbanksystemen mittels Iterationsabstraktionen "uber Massendatenstrukturen
erreicht wird.

Wie bei der Diskussion der Persistenz im vorigen Abschnitt bereits
angesprochen, werden die Daten eines Informationssystems langfristig auf
Sekund"ar- und Terti"arspeichern gehalten. Im Gegensatz zu vielen
Standardwerkzeugen (Spreadsheets, Textverarbeitungsprogramme, Grafikpakete,
CAD Werkzeuge) "uberschreitet im Regelfall die Gesamtgr"o"se der
Informationsstrukturen eines Informationssystems jedoch deutlich die
(physische und virtuelle) Hauptspeicherkapazit"at des zur
Informationsverarbeitung eingesetzten Computers. Daher k"onnen
Informationssysteme nicht wie diese Standardwerkzeuge auf einem einfachen
\e{load / save} Modell aufbauen, bei dem die ben"otigten persistenten Daten
komplett zur Bearbeitung in den Hauptspeicher geladen werden.  Andererseits
bearbeiten die meisten Aktivit"aten in Informationssystemen nur einen kleinen
Ausschnitt des gesamten persistenten Datenbestandes.  Eine vordringliche
Aufgabe bei der Realisierung von Datenbanksystemen ist daher die effiziente
Selektion der aktuell ben"otigten Daten, wobei nur eine m"oglichst kleine
Obermenge der f"ur eine Aktivit"at ben"otigten Daten vom Sekund"ar- oder
Terti"arspeicher in den Hauptspeicher transferiert werden darf.

Wie in Kapitel xx (DB-Implementierung) erkl"art wird, verf"ugen 
Datenbanksysteme "uber ein reiches Repertoire an Implementierungen 
f"ur Massendatenstrukturen und Algorithmen zur Realisierung von 
Iterationsabstraktionen, die auf das spezielle Problem der effizienten 
Datenselektion auf Sekund"arspeichern spezialisiert sind. Daher 
erreichen Datenbanksysteme generell eine erhebliche Effizienzsteigerung 
verglichen mit handkodierten Datenselektionen.

Die enorme Bedeutung der effizienten Informationsselektion f"ur 
die Gesamtperformanz von Datenbanksystemen verdeutlicht der folgende 
Vergleich der Zugriffszeiten heutiger Prim"ar-, Sekund"ar- und 
Terti"arspeicher. Der direkte Zugriff auf eine lokale Variable 
in einer Programmiersprache l"a"st sich idealerweise mit einer 
Maschineninstruktion implementieren und ben"otigt etwa xx Nanosekunden 
auf einem Personalcomputer. Der direkte Zugriff auf eine Datenbankvariable 
erfordert mindestens den Transfer eines Datenblocks von der Festplatte 
in den Hauptspeicher und ben"otigt etwa xx Millisekunden. Der 
direkte Zugriff auf eine bestimmte Bandstelle auf einer VHS Videokassette 
in einer roboterbedienten Jukebox ben"otigt etwa xx Sekunden. 
Setzt man diese Gr"o"senverh"altnisse in \glqq erfahrbare\grqq\ menschliche 
Zeitintervalle um, so steht ein Hauptspeicherzugriff, der eine 
Sekunde ben"otigt, im Verh"altnis zu einem Sekund"arspeicherzugriff 
von 15 Minuten und einem Terti"arspeicherzugriff von 
11 Tagen und 12 Stunden.

\subsubsection{Unterst"utzung der Reaktivit"at}
\label{Unterstuetzung der Reaktivitaet}

Ein Informationssystem ist in die informationsverarbeitenden 
Aktivit"aten seiner Umgebung eingebunden. Es aktualisiert seinen 
Informationsbestand unmittelbar basierend auf einkommenden Informationen, 
antwortet auf explizite Informationsanfragen und l"ost auch selbst"an\-dig 
Aktivit"aten in der Umgebung aus.

Bei den informationsverarbeitenden Aktivit"aten in der Umgebung 
eines Informationssystems handelt es sich typischerweise um 
\e{menschliche Aktivit"aten}, wie z.B. die Erledigung von Bankgesch"aften, Personalverwaltung, Literaturrecherche, Adre"sverwaltung, u."a., die durch 
\e{Agenten} abgewickelt werden. Handelt es sich bei den Agenten 
um menschliche Nutzer, so wird die Interaktion direkt "uber (textuelle 
oder grafische) 
\e{Benutzeroberfl"achen} abgewickelt. Die Interaktion mit 
computerbasierten Agenten wird "uber Kommunikationsdienste oder 
Bibliotheksschnittstellen realisiert (\e{Dienstschnittstellen}).

Eine zentrale Aufgabe eines Informationssystems ist dabei die implizite oder
explizite \e{Synchronisation} nebenl"aufiger Aktivit"aten, die auf den
gleichen Informationsbestand zugreifen. Aus der Sicht des Informationssystems
lassen sich lesende \e{Anfragen }und \e{ }zustandsver"andernde
\e{Anweisungen}, die von Agenten an das Informationssystem gerichtet werden,
von den \e{aktiv} durch das Informationssystem selbst ausgel"osten
\e{Aktionen} unterscheiden.

In klassischen Informationssystemen werden \glqq zusammengeh"orige\grqq\ 
Anfragen und Anweisungen eines Agenten zu einer \e{Transaktion} zusammengefa"st,
die atomar, konsistenzerhaltend und isoliert von anderen Transaktionen
ausgef"uhrt wird. Das klassische Transaktionsparadigma f"uhrt also zu einer
engen Verzahnung der Aspekte der Fehlererholung mit den Aspekten der
Synchronisation und Integrit"atssicherung.

Moderne Informationssysteme erfordern h"aufig jedoch komplexere
\e{Konversationen }mit Agenten, dies sind Folgen von Anfragen, R"uckfragen,
Best"atigungen, Anweisungen und Aktionen, die nicht ad"aquat in isolierte
Transaktionen zu zerlegen sind.

Das Konzept eines reaktiven Informationssystems geht deutlich "uber das
einfache Paradigma der \e{stapelorientierten Verarbeitung} hinaus, bei der ein
Proze"s sequentiell die drei Phasen Dateneingabe, Datenverarbeitung und
Datenausgabe durchl"auft. Dieses Konzept liegt immer noch vielen
Softwarewerkzeugen wie Compilern, Programmgeneratoren, Satzsystemen (TeX),
Simulatoren oder Statistikpaketen zugrunde. Aber auch Datenbanksysteme mit der
F"ahigkeit zur unmittelbaren Transaktionsverarbeitung (\e{Online Transaction
  Processing}, OLTP) k"onnen nur als Zwischenstufe auf dem Weg von der
stapelorientierten zur voll reaktiven Bearbeitung persistenter Datenbest"ande
betrachtet werden, da jede einzelne Transaktion wiederum dem rigiden
sequentiellen Schema Dateneingabe, atomare Datenverarbeitung und Datenausgabe   
gehorchen mu"s.

Die Reaktivit"at von Informationssystemen erfordert den Einsatz algorithmisch
vollst"andi\-ger Sprachen zur \e{Verhaltensmodellierung}.  Die Notwendigkeit der
konzeptionellen und sprachlichen Integration der Verhaltensmodellierung mit der
Datenmodellierung f"uhrt schlie"slich zu der Problematik der
\e{Programmierspracheneinbettung} von Datenbankdiensten, die in Abschnitt
\ref{Integrierte Datenbanksprachen} genauer behandelt wird.

\subsubsection{Unterst"utzung der Integrit"at}
\label{Unterstuetzung der Integritaet}

Ein Informationssystem wahrt Integrit"atsbedingungen, die sich 
sowohl auf seinen persistenten Informationsbestand als auch auf 
die einkommenden und ausgehenden Informationen beziehen k"onnen. 
Dabei lassen sich zwei komplement"are Aspekte der Integrit"atssicherung 
unterscheiden:

\begin{description}
\item[Binnenwirkung:] Aus der Sicht des Software-Engineering beschreiben und
  kontrollieren die Integrit"atsbedingungen eines Informationssystems die
  Konsistenz eines \e{gekapselten} langlebigen Systemzustands, bei dem es
  sich, wie in Abschnitt \ref{Unterstuetzung der Persistenz} angedeutet,
  um ein Systemmodell eines speziellen Realit"atsausschnitts handelt.

\item [Au"senwirkung:] Aus der Sicht der Agenten in der Umgebung des
  Informationssystems definieren und erzwingen die Integrit"atsbedingungen
  \e{Informationsstrukturen} und \e{Gesch"afts\-praktiken}, die von allen
  informationsverarbeitenden Aktivit"aten in der Umgebung des
  Informationssystems einzuhalten sind.
\end{description}

In diesem ersten Kapitel des Datenbankhandbuchs sind vor allem die
Binnenwirkung von Integrit"atsbedingungen und die Sprachmechanismen zur
Integrit"atsformulierung in verschiedenen Datenbankmodellen von Interesse. Die
korrekte und flexible Modellierung von Integrit"atsbedingungen basierend auf
ihrer Au"senwirkung ist Gegenstand von Kapitel xx (Konzeptioneller
Datenbankentwurf).

Beim Einsatz eines Datenbankmodells zur Realisierung eines Informationssystems
lassen sich Integrit"atsbedingungen zun"achst wie folgt klassifizieren:

\begin{description}
\item[] \e{Modellinh"arente Integrit"atsbedingungen} werden bereits implizit
  durch die Strukturen und Operationen des gew"ahlten Datenbankmodells
  erzwungen und sind in diesem Sinne in jedem Datenbankzustand und bei jeder
  Zustands"anderung erf"ullt Das einfachste Beispiel einer modellinh"arenten
  Konsistenzbedingung ist die \e{Typisierung} eines Objektattributs. So l"a"st
  sich zum Beispiel im Datenbankschema definieren, da"s das Attribut \p{Alter}
  eines Objekts der Klasse \p{Person} nur ganzzahlige Werte annehmen kann.
  Zuweisungen typinkompatibler Werte an das Attribut \p{Alter} werden durch
  das Datenbanksystem bei der Ausf"uhrung der Zuweisung (oder bereits bei
  ihrer "Ubersetzung) als fehlerhaft zur"uckgewiesen.

\item[] \e{Applikationsspezifische Integrit"atsbedingungen} schr"anken die
  Menge der zul"assigen Datenbankzust"ande und -zustands"uberg"ange weiter ein
  und m"ussen im Datenbankschema explizit deklariert werden oder durch die
  informationsverarbeitenden Algorithmen explizit "uberpr"uft werden. Zum
  Beispiel kann die Bedingung, da"s das Alter einer Person nur Werte zwischen
  0 und 200 annehmen kann, und da"s das Alter jeder Person "uber die
  Lebensdauer der Datenbank nur monoton wachsen kann, in keinem kommerziell
  relevanten Datenmodell direkt durch Datenmodellkonstrukte beschrieben
  werden.
\end{description}

Weiterhin ist eine Klassifikation von Integrit"atsbedingungen 
aufgrund ihrer zeitlichen Ausdehnung m"oglich:

\begin{description}
\item[] \e{Statische Integrit"atsbedingungen} m"ussen in jedem Datenbankzustand
  S erf"ullt sein, unabh"ang\-ig von der Historie, die zu diesem Zustand f"uhrt.
  Sie lassen sich durch logische Formeln (quantifizierte \e{Pr"adikate}) "uber
  die Zustandsvariablen von S spezifizieren (\glqq Jeder Mitarbeiter arbeitet in
  genau einer Abteilung\grqq ).

\item[] \e{Dynamische Integrit"atsbedingungen} m"ussen bei jeder
  Datenbankzustands"anderung von einen Zustand S$_{n}$ in einen Zustand
  S$_{n+1}$ erf"ullt sein. Im einfachsten Fall l"a"st sich eine dynamische
  Integrit"atsbedingung durch einen \e{Pr"adikattransformer} spezifizieren, dies
  ist eine logische Formel, die ein Pr"adikat "uber S$_{n+1}$ aus einem
  Pr"adikat "uber S$_{n}$ ableitet (\glqq Geh"alter von Mitarbeitern nehmen nie
  ab\grqq ). Im allgemeinen k"onnen dynamische Integrit"atsbedingungen sich
  jedoch auf die gesamte Historie beziehen, die zu einem Zustand S$_{n}$ f"uhrt.
  In diesem Fall werden logische Formeln von \e{temporalen Logiken} zur
  Integrit"atsdefinition benutzt, die spezielle temporale Quantoren "uber
  Variablenhistorien anbieten (\glqq Ein Mitarbeiter kehrt niemals in eine
  Abteilung zur"uck, die er einmal verlassen hat\grqq ).
\end{description}

Integrit"atsbedingungen lassen sich schlie"slich gem"a"s ihres Sichtbarkeits-
oder Wirkungsbereichs klassifizieren, der sich auf ein einzelnes \e{Attribut,
  }ein einzelnes \e{Objekt}, eine einzelne \e{Klasse, }eine einzelne
\e{Beziehung} zwischen zwei Klassen oder auf beliebig viele Attribute, Objekte
oder Klassen simultan beziehen kann.

W"ahrend sich statische, lokale Integrit"atsbedingungen ad"aquat 
durch Konzepte der algorithmischen Programmierung (Attributtypisierung, 
Rekordtypisierung, Objektkapselung, Datentypabstraktion) unterst"utzen 
lassen, erfordern Informationssysteme zus"atzlich die Kontrolle 
komplexer \e{nicht-lokaler Integrit"atsbedingungen}, die verschiedene 
Informationsstrukturen zueinander in Beziehung setzen. 

\begin{description}
\item[] \e{Deklarative Integrit"atssicherung} ist ein "uber klassische
  Typisierungskonzepte hinausgehender Dienst von modernen Datenbanksystemen.
  Dabei werden Integrit"atsbedingungen "uber spezielle Schl"usselworte,
  Klauseln oder quantifizierte boole' sche Pr"adikate im Datenbankschema
  definiert. Das Datenbanksystem garantiert die Einhaltung dieser Bedingungen,
  indem es integrit"atsverletzende "Anderungsoperationen auf der Datenbank
  erkennt und (evtl. benutzerdefinierte) Schritte zur \e{Ausnahmebehandlung}
  (z.B. einen Transaktionsabbruch oder kaskadierte L"oschoperationen)
  einleitet.

  Eine deklarative Integrit"atsbedingung f"ur eine Literaturdatenbank ist zum
  Beispiel die Forderung, da"s zu jedem Element \p{r} der Massendatenstruktur
  \p{Report} genau ein Element der Massendatenstruktur Institution geh"ort,
  das \p{r} als Publikation nennt (referentielle Integrit"at, vgl. Abschnitt
  \ref{Referentielle Integritaet}).

\item[] \e{Prozedurale Integrit"atssicherung} erfordert hingegen explizit
  programmierte Tests bei Datenbankzustands"anderungen. Zur Sicherung der
  referentiellen Integrit"at im obigen Beispiel sind explizite Tests beim
  Einf"ugen und "Andern jedes Objekts der Klasse \p{Report} notwendig sowie
  beim Einf"ugen, L"oschen und "Andern jedes Objekts der Klasse
  \p{Institution.}
\end{description}

Eine deklarative Integrit"atssicherung besitzt folgende Vorteile:

\begin{itemize}
\item Verbesserte Systemwartbarkeit, da eine Integrit"atsbedingung nur an
  genau einer Stelle (im Datenbankschema) lokalisiert ist und der
  Applikationskode nicht ver"andert werden mu"s.

\item Verbesserte Verstehbarkeit, da deklarative Integrit"atsbedingungen
  h"aufig einfacher als kaskadierte \p{if}-Anfragen zu lesen sind.

\item Optimierbarkeit, da zum Beispiel ein Datenbanksystem bei der Kenntnis
  referentieller Integrit"atsbedingungen explizite Zugriffspfadunterst"utzung
  f"ur die wiederholte "Uberpr"u\-fung von Integrit"atsbedingungen und die
  Verkn"upfung (\e{join}) von Tabellen anbieten kann.
\end{itemize}

Beim gegenw"artigen Stand der Technik f"uhren deklarative
Integrit"atssicherungsma"snah\-men in komplexen Modellierungssituationen jedoch
zu folgenden Problemen:

\begin{itemize}
\item Die Ausnahmebehandlungsoperationen verschiedener Integrit"atsbedingungen
  (kaskadiertes L"oschen, Propagieren, Transaktionsabbruch) sind nur schwer zu
  synchronisieren und k"onnen zu nicht-deterministischem Systemverhalten
  f"uhren.

\item Eine deklarativ spezifizierte Ausnahmebehandlung kann zu kaskadierten
  Integrit"atsver\-letzungen f"uhren, die wiederum Ausnahmebehandlungen
  ausl"osen. Eine Terminierung und Konsistenz von
  Ausnahmebehandlungsoperationen ist nicht garantiert.

\item In einem gro"sen Datenbankschema ist es schwierig, alle f"ur eine
  gegebene Datenbankoperation relevanten Integrit"atsbedingungen zu
  lokalisieren.

\item Die von Datenbanksystemen angebotenen Sprachmittel zur Formulierung von
  Ausnahmebehandlungsroutinen sind nicht ad"aquat (fehlende algorithmische
  Vollst"andigkeit).
\end{itemize}

Die Wahrung der Integrit"at eines Informationsbestandes erfordert auch die
Kontrolle "uber die \e{Subjekte} (Agenten, vgl. Abschnitt
\ref{Unterstuetzung der Reaktivitaet}), die an den
informationsverarbeitenden Aktivit"aten in der Umgebung des
Informationssystems teilnehmen. Die in diesem Zusammenhang auftretenden
Probleme der \e{Authentisierung} von Benutzern gegen"uber dem
Informationssystem (zum Beispiel durch Passworte) und der \e{Autorisierung},
also der Vergabe und Kontrolle von Zugriffsrechten von Subjekten auf
Datenbankobjekte werden in Kapitel xx n"aher behandelt.


\subsection{Datenbankdienste f"ur moderne Informationssysteme}
\label{Datenbankdienste fuer moderne Informationssysteme}

In diesem Abschnitt wird indirekt die bisher offengebliebene 
Frage \glqq was ist ein Datenbanksystem\grqq\ beantwortet, indem diejenigen 
Dienste aufz"ahlt werden, die von Datenbanksystemen zur Realisierung 
von Informationssystemen angeboten werden. Detailliertere Erl"auterungen 
zu jedem dieser Dienste finden sich in den vorangegangenen Unterabschnitten. 
Dabei werden Datenbankdienste in drei Kategorien klassifiziert:

\begin{enumerate}
\item \e{Verpflichtende Datenbankdienste:} Persistente
  Datenspeicherung, Verwaltung einer Speicherhierarchie mit
  effizienter Datenselektion, dynamische Massendatenstrukturen,
  Synchronisationsprimitive, Dienstschnittstellen f"ur den
  Datenbankzugriff aus Programmiersprachen.

\item \e{Datenbankkerndienste:} Zus"atzlich Persistenzabstraktion,
  Metadatenverwaltung, inkrementelle und dynamische Bindung,
  Datenunabh"angigkeit durch Schemaschichtung, Iterationsabstraktion,
  transaktionale Integrit"atssicherung, Fehlererholung und
  Paralleli\-t"atskontrolle im Mehrbenutzerbetrieb.

\item \e{Erweiterte Datenbankdienste:} Zus"atzlich orthogonale
  Persistenz, Persistenzunabh"angig\-keit, deklarative
  Integrit"atssicherung, Verhaltensmodellierung, Ausnahmebehandlung,
  Unterst"utzung f"ur Konversationen und langandauernde Aktivit"aten,
  Benutzeroberfl"a\-chen, erweiterte Dienstschnittstellen (4GL,
  Benutzeroberfl"ache, Reportgenerator, entfernter Datenbankzugriff).
\end{enumerate}

Abschlie"send sei bemerkt, da"s w"ahrend der letzten zehn Jahre 
ein erheblicher Zuwachs des Funktionsumfangs und der Ausdrucksm"achtigkeit 
von Datenbanksprachen und -modellen zu beobachten ist, der aber 
gleichzeitig auch die Komplexit"at der Datenbanksystemsoftware 
deutlich erh"oht hat. Analog zu der Entwicklung von CISC zu RISC 
Hardwarearchitekturen und der Entwicklung von 
\e{micro-kernels} in Betriebssystemen kann spekuliert werden, 
da"s eventuell eine Reduktion der Funktionalit"at der eigentlichen 
Datenbanksoftware gekoppelt mit leistungsf"ahigen, problemorientierten 
Werkzeugen (Applikationsgeneratoren, Bibliotheken, Werkzeugk"asten) 
zu effizienteren und flexibleren Informationssystemen f"uhrt, 
als sie mit monolithischen 
\e{general-purpose} Datenbanksystemen zu realisieren sind. 
Diese Hypothese wird durch das Aufkommen von vergleichsweise 
primitiven Objektspeichersystemen, Repositories, und Multi-Media-Servern 
gest"utzt.


\subsection{Vorteile der Nutzung standardisierter Datenbankdienste}
\label{Vorteile der Nutzung standardisierter Datenbankdienste}

Der Einsatz von Datenbanksystemen bei der Realisierung von
Informationssystemen f"uhrt zun"achst zu den bekannten positiven Effekten, die
allgemein beim Einsatz generischer Dienst\-erbringer bei der Softwareentwicklung
zu beobachten sind:

\begin{itemize}
\item Reduzierter Implementierungs- und Wartungsaufwand durch die
  \e{Wiederverwendung} kommerziell verf"ugbarer, vordefinierter und
  ausgereifter Systemfunktionalit"at.

\item Erh"ohte \e{Portabilit"at} der entwickelten Software durch die
  Benutzung standardisierter, plattformunabh"angiger Dienste.

\item Verbesserte \e{Systemskalierbarkeit} durch die M"oglichkeit zum
  Austausch von Diensterbringern (Beispiel: Migration eines
  Informationssystems von einem Einbenutzerdatenbanksystem "uber ein
  Mehrbenutzerdatenbanksystem zu einem verteilten Datenbanksystem).
\end{itemize}

Dar"uber hinaus leisten Datenbanksysteme weitere wichtige Beitr"age 
zur Qualit"at der mit ihnen entwickelten Informationssysteme:

\begin{description}

\item[Datenabstraktion (data abstraction):] Die Verf"ugbarkeit von
  ausdrucksm"achtigen Datenbankschemainformationen garantiert die
  Interpretierbarkeit des Datenbankzustandes unabh"angig von seiner
  Repr"asentation im Computer (Rekordlayout, Dateilayout,
  Adressierungsmechanismen, Datenformate, etc.) und unabh"angig von
  speziellen Anwendungsprogrammen.  Damit erh"ohen Datenbanksysteme
  entscheidend die Nutzbarkeit des Datenbestandes f"ur
  \glqq unvorhergesehene\grqq\ informationsbearbeitende Aktivit"aten (\e{ad
    hoc queries}).

\item[Gemeinsame Informationsnutzung (information sharing):] Im
  Gegensatz zu applikationsspezifischen Speicherungssystemen erlauben
  Datenbanksysteme einen gemeinsamen Datenzugriff aus unabh"angig
  entwickelten Anwendungsprogrammen, aus verschiedenen
  Programmiersprachen und durch parallel exekutierende Agenten.

\item[Integrierte Datenbeschreibung (information integration)] Die
  Evolution von Informationssystemen f"uhrt h"aufig zu der
  Notwendigkeit, bestehende Informationsbest"ande zu erweitern oder
  gar unabh"angig entstandene Informationssysteme konsistenzerhaltend
  zu integrieren. Datenbanksysteme leisten bei diesem Vorgang eine
  wichtige Hilfestellung, indem sie es gestatten, verschiedene
  \e{Sichten} auf ein Datenobjekt zu definieren, und damit eine
  Replikation von Informationen in verschiedenen Speicherungssystemen
  zu vermeiden. Au"serdem erm"oglichen Datenbanksysteme die Definition
  von Konsistenzbedingungen, die sich "uber mehrere, urspr"unglich
  unabh"angige Objektklassen erstrecken.
\end{description}

Bereits an dieser Stelle sei auf Probleme hingewiesen, die sich 
durch das Herausl"osen der Datenhaltungskomponente aus individuellen 
Anwendungsprogrammen ergeben k"onnen:

\begin{itemize}
\item \e{Redundanz} oder Inkonsistenz zwischen den
  Informationsstrukturbeschreibungen in der Programmiersprache, in dem
  Datenbankschema, in der Benutzerschnittstellendefinition und in den
  Kommunikationsprotokollbeschreibungen.

\item \e{Ineffiziente Datenspeicherung} oder ineffizienter
  Datenzugriff aufgrund von Modellierungsdiskrepanzen zwischen den
  Informationsstrukturen des Informationssystems und
  Datenmodellierungskonzepten der Datenbank (Beispiel: Textdaten, CAD
  Daten).
\end{itemize}

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/5.eps}
\caption{Datenbanksysteme als Teil der Middleware}
\label{middleware}  
\end{center}
\end{figure}

Abschlie"send sei bemerkt, da"s generische Diensterbringer wie
Datenbanksysteme in der Literatur teilweise unter dem Begriff der
\e{Middleware} zusammengefa"st werden, da sie architekturell und
konzeptionell zwischen der anwendungsspezifischen Software und der
fest vorgegebenen, plattformspezifischen Betriebssystemsoftware
angesiedelt sind [Bernstein 93] (s.a.\ Abbildung \ref{middleware}).

\subsection{Beispiel: Ein Firmeninformationssystem}
\label{Beispiel: Ein Firmeninformationssystem}

Dieser Abschnitt illustriert die Charakteristika von
Informationssystemen an dem konkreten Beispiel eines prototypischen
\e{Firmeninformationssystems} (Abbildung \ref{fis}). Dieses Beispiel
wird durchg"angig im gesamten ersten Kapitel verwendet.

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/2.eps}
\caption{Ein Firmeninformationssystem}
\label{fis}  
\end{center}
\end{figure}

\subsubsection{Dienstschnittstellen}
\label{Dienstschnittstellen}

\comment{Sicht des Systems von au"sen, Modalit"aten des Zugriffs}

\begin{figure}[hbt]
\begin{center}
\leavevmode
%\epsffile{Bilder/PostScript/Informationssystem.ps}
\caption{Dienstschnittstellen des Firmeninformationssystems}
\label{Dienstschnittstellen FIS}
\end{center}
\end{figure}
 
\comment{Abbildung: X-11 GUI Schnittstelle, RPC Schnittstelle, C++ Algorithmen,

relationales Datenbankschema, Oracle Datenbank}

\subsubsection{Informationsstrukturen}
\label{Informationsstrukturen}

Das System verwaltet Informationen "uber Projekte, Mitarbeiter und
Abteilungen, deren regul"are Informationsstrukturen und
Integrit"atsbedingungen sich wie folgt beschreiben lassen:

Jedes \e{Projekt} besitzt einen Projekttitel, eine eindeutige, maximal
f"unfstellige Projektnummer sowie ein Budget, das monatlich auf zwei
Nachkommastellen genau verwaltet wird und nie "uberzogen werden kann.

Jeder \e{Mitarbeiter} besitzt einen Namen. Einige Mitarbeiter sind
Werkstudenten, die auf einer Stundenbasis zu einem festen Tarif pro
Stunde besch"aftigt werden. Die "ubrigen Mitarbeiter sind
Festangestellte und besitzen ein festes Monatsgehalt. Jeder
Mitarbeiter kann einen festgelegten prozentualen Anteil seines
monatlichen Gehalts aus dem Budget eines oder mehrerer Projekte
erhalten. Das "ubrige Gehalt wird von der Abteilung gezahlt, die den
Mitarbeiter besch"aftigt.  Jeder Mitarbeiter wird von genau einer
Abteilung besch"aftigt.

Jede \e{Abteilung} besitzt einen Namen, ein eindeutiges
Abteilungsk"urzel, bestehend aus bis zu vier Buchstaben, und einen
Abteilungsleiter, der auch als Mitarbeiter in dieser Abteilung
besch"aftigt ist.  Eine Abteilung ist f"ur die Durchf"uhrung der ihr
zugeordneten Projekte verantwortlich. Die Mitarbeiter einer Abteilung
d"urfen ihr Gehalt ausschlie"slich von Projekten beziehen, f"ur deren
Durchf"uhrung die Abteilung auch verantwortlich ist. F"ur ein Projekt
k"onnen mehrere Abteilungen verantwortlich sein. F"ur jedes Projekt
ist mindestens eine Abteilung verantwortlich. Die Abteilungen sind in
einer Hierarchie organisiert, da einige Abteilungen eine Oberabteilung
besitzen, an die projektbezogene Informationen weitergeleitet werden
m"ussen. Die Informationsweitergabe erfolgt "uber mehrere
Hierarchieebenen hinweg.

Die Informationsstrukturen sind grafisch in OMT-Notation dargestellt.
Diese Notation wird erst in Abschnitt \ref{Abstraktionsmechanismen zur
  Datenstrukturierung} eingef"uhrt, ist aber auch intuitiv
verst"andlich.

\begin{figure}[hbt]
\begin{center}
\leavevmode
%\epsffile{Bilder/PostScript/??}
\caption{Informationsstrukturen des Firmeninformationssystems}
\label{Informationsstrukturen FIS}
\end{center}
\end{figure}


Ein Zustand des Informationsbestandes der Projektverwaltung, 
der die oben genannten Konsistenzbedingungen erf"ullt, ist in 
tabellarischer Form in Abbildung \ref{Tabelle FIS} dargestellt.

\comment{Am Schlu"s erstellen, sobald alle Daten und Attribute 

klar, evtl Tabelle statt Bild ?}

\begin{figure}[hbt]
\begin{center}
\leavevmode
% \epsffile{Bilder/PostScript/??}
\caption{Ein zul"assiger Zustand des Informationsbestandes der 
Projektverwaltung in tabellarischer Form}
\label{Tabelle FIS}  
\end{center}
\end{figure}


\subsubsection{Informationsverarbeitende Aktivit"aten }
\label{Informationsverarbeitende Aktivit"aten }

Das System unterst"utzt die folgenden informationsverarbeitenden Aktivit"aten:

\comment{W"ahle Beispiele basierend auf sp"ateren SQL Beispielen 
im Text}

\begin{description}
\item[] \e{Elementare Transaktionen}\\ 

  Projekt: Akquisition (Titel, Nummer, Anfangsbudget, verantwortliche
  Abteilungen, Zuordnung Mitarbeiter), Budgetprognose f"ur
  Folgemonate.  Projektabschlu"s.

  Mitarbeiter: Einstellung. Austritt. Monatsabrechnung. Ausscheiden
  aus Projekt. "Ubernahme Projektverantwortung. Abteilungswechsel zum
  Monatsende.

  Abteilung: Gr"undung, Aufl"osung. Reorganisation in der Hierarchie.
  Leiterwechsel.

\item[] \e{Anfragen}: Anzeige einzelner Mitarbeiter, Projekte und
  Abteilungen (Attribute und assoziierte Objekte).

  Identifikation von M, P, A durch Attribute \& Beziehungen
  (Navigation).

  Ausgabe von Listen (geordnet)

  Bestimmung aller Projekte, die von Unterabteilung bearbeitet werden
  (Rekursive Beziehungen)

\item[] \e{Konversationen:} Gesch"aftsproze"s: Einstellung neuer
  Mitarbeiter: Personalabteilung, Anfrage bei Projektleiter,
  Gehaltsanpassung, Projektbudgetierung.
\end{description}

\comment{Zeige Generalisierungen auf:\\

Bilder als Attribute [Personaldaten], Handschriftenprobe, Trigger \\
zum Ausl"osen von Aktionen [Geburtstag, Budget"uberschreitung], \\
Projektdokumente im Rechnernetz, e-Mail Korrespondenz im Archiv. \\ 
Fax-Versendung, Telefonvermittlung, Digitale Bibliotheken, Multi-Media \\
Datenbanken, Volltextrecherche}

