Titel: In welche Richtungen werden sich Datenbanksysteme entwickeln

In welche Richtungen werden sich
Datenbanksysteme entwickeln?




Inhaltsverzeichnis

Inhaltsverzeichnis III

Abkürzungsverzeichnis IV

1. Einleitung 1

2. Trendforschung 2

2.1 Trends in der Informationstechnologie 2
2.2 Bewertung von Trendaussagen in der Informationstechnologie 2

3. Trends im Bereich Datenbanksysteme 3

3.1 Datenbankmodelle 3
3.1.1 Beschreibung der Modelle 4
3.1.2 Ausblick 6
3.2 Vernetzung von Datenbanksystemen 8
3.2.1 Formen der Datenverteilung 8
3.2.2 Notwendigkeit von Interoperabilität 9
3.2.3 Datenbankschnittstellen 10
3.2.4 Abfragesprachen 11
3.2.5 Zusammenfassung 13
3.3 Integration contra Diversifikation 14
3.3.1 Einbinden von Funktionalität 14
3.3.2 Klare Schnittstellen 16
3.3.3 Ausblick 17
3.4 Weitere Trends 18
3.4.1 Data Warehouse und Data Mining 18
3.4.2 Deduktive Datenbanksysteme 20
3.4.3 Parallele Datenbanksysteme 21

4. Zusammenfassung 22

Literaturverzeichnis V

Internetverzeichnis VIII

Ehrenwörtliche Erklärung X



Abkürzungsverzeichnis

BLOB Binary Large Objects
BSI Bundesamt für Sicherheit in der Informationstechnik
CAD Computer Aided Design
CAM Computer Aided Manufacturing
CASE Computer Aided Software Engineering
CTI Computer Telephony Integration
ebXML electronic business XML
EDI Electronic Data Interchange
GIS Geographic Information System
GQL Graphical Query Language
HTTP Hypertext Transfer Protocol
ISO International Organization for Standardization
ODMG Object Database Management Group
OLAP Online Analytic Processing
OLTP Online Transaction Processing
OQL Object Query Language
QBE Query By Example
SQL Structured Query Language
W3C World Wide Web Consortium
XML Extensible Markup Language
XQL XML Query Language
XSL Extensible Stylesheet Language
XSLT XSL Transformations
XSL-FO XSL Formatting Objects



1. Einleitung

,,Datenbanksysteme spielen eine immer größere Rolle."1

,,[Datenbanken haben] sicher einen Platz unter den ersten drei ... mit beinahe religiösem Eifer diskutierten Software-Kategorien."2

,,One of the most important application of computers."3

Das Thema Datenbanksysteme ist vier Jahrzehnte nach der Entwicklung der ersten Systeme aktueller denn je. Datenbanken werden heutzutage im Supermarkt, in Bibliotheken, in Unternehmungen und zuhause eingesetzt und reichen von einer Installation auf einem Einzelplatzrechner bis hin zu riesigen verteilten Informationssystemen. Entsprechend wichtig ist die Klärung der Frage, in welche Richtungen sich Datenbanksysteme entwickeln. Um dies zu beantworten, zeigt die vorliegende Hausarbeit Trends auf, die laut Experten in den nächsten Jahren eine große Rolle spielen werden.
Bei der Recherche sehr hilfreich war eine Studie des Bundesamts für Sicherheit in der Informationstechnik, die im Mai 2003 erschienen ist. Sie trägt den Namen ,,Kommunikations- und Informationstechnik 2010+3" und untersucht aktuelle Trends in den besagten Bereichen. Bücher, Zeitschriften und Internet unterstützten und erweiterten Inhalte der Studie umfangreich.

Inhaltlich gliedert sich die Hausarbeit wie folgt:


In Kapitel 2 wird zum besseren Verständnis der Thematik kurz erklärt, was eine Tendenz zu einem Trend macht. Es folgt eine Auflistung von Trends in der Informationstechnologie und eine Untersuchung, mit welchem Horizont hier überhaupt seriöse Aussagen getroffen werden können.
Kapitel 3 umfasst den Hauptteil der Arbeit. Hier werden die Trends in den Technologiegebieten Datenbankmodelle, Vernetzung von Datenbanksystemen und Integration bzw. Diversifikation aufgezeigt. Es schließt sich ein Überblick über weitere wichtige Trends an.
Abschließend folgt in Kapitel 4 eine Zusammenfassung der Thematik.

2. Trendforschung
Aufgabe der Trendforschung ist die Identifizierung von Dynamiken, welche die bisherigen Strukturen in Frage stellen.4 Diese Dynamiken werden ,,Trends" genannt. Sie lassen sich darin charakterisieren, dass sie evolutionär, langfristig und nachhaltig wirken.5 Um als solcher anerkannt zu werden, muss ein Trend daher eine Entwicklungsgeschichte aufweisen und seine Wirkung darf nicht von kurzer Dauer sein.

2.1 Trends in der Informationstechnologie
Zur Informationstechnologie gehören alle Vorgänge, die mit der Erfassung, Speicherung, Übertragung und Transformation von Daten zusammenhängen.6 Neben Datenbanken zählt man auch Softwareentwicklung, Hardware und Netzwerke zu den Teilgebieten der Informationstechnologie.Als übergreifende Trends in diesen Bereichen werden folgende Tendenzen ausgemacht, die zwar nicht alle im Bereich Datenbanksysteme entscheidend sind, allerdings einen guten Überblick über die Thematik bieten:7


Automatisierung und Vereinfachung zur Effizienzsteigerung,
Integration und Standardisierung zur Verzahnung von Netzen und Daten,
Kapazitäts- und Leistungssteigerung, um die wachsenden Anforderungen zu bewältigen,
Vernetzung und Flexibilisierung dienen der Verknüpfung verschiedener Plattformen,
Verteilung und Dezentralisierung zur Förderung von Sicherheit und Skalierbarkeit,
Virtualisierung zur Nutzung von Methoden nicht realer Objekte, z. B. im Internet.

2.2 Bewertung von Trendaussagen in der Informationstechnologie
Trendforschung in der Informationstechnologie ist ein relativ unsicheres Gebiet, da sich hier das Wissen besonders schnell erneuert. Im Gegensatz zu traditionellen Bereichen ist die Welt der Informationstechnologie sehr schnelllebig. Als Beispiel soll hier das Internet gelten, das sich seit 1992 in Europa etablierte.8 Mittlerweile ist das Internet kaum aus dem Alltag wegzudenken, und nach neusten Umfragen ist jeder Deutsche täglich durchschnittlich 49 Minuten online.9
Dies zeigt, dass seriöse Trendaussagen im IT-Bereich nur mit Vorsicht gemacht werden können. Über das nächste Jahrzehnt hinaus kann nur spekuliert werden. Entsprechend wird diese Hausarbeit sich auf die Entwicklung in den nächsten Jahren beschränken und dabei sorgfältig die verschiedenen Expertenmeinungen vergleichen.

3. Trends im Bereich Datenbanksysteme
Die Thematik der Datenbanksysteme gliedert sich in verschiedene Technologiefelder wie z. B. Datenbankmodelle, Vernetzung und Integration. Nach einer kurzen Einführung in diese Sachgebiete und eventuell konkurrierende Verfahren erfolgt eine Argumentation, welche Trends sich warum durchzusetzen scheinen.

3.1 Datenbankmodelle
Jedes Datenbankmanagementsystem basiert auf einem Datenbankmodell. Dieses Modell besteht aus Konzepten, mit deren Hilfe ein Datenmodell für eine Anwendung erzeugt wird.10 Die Datenbankmodelle stellen wohl eines der zur Zeit am meisten diskutierten Themen der Datenbankforschung dar.
In den 70er Jahren wurden die hierarchischen und Netzwerkdatenmodelle entwickelt, diese wurden ein Jahrzehnt später von den relationalen Datenbankmodellen abgelöst. Seit Mitte der 90er Jahre existieren die objektorientierten und objektrelationalen Datenbankmodelle.11 Jüngere so genannte postrelationale Modelle12 wurden entworfen und werden im Folgenden erklärt. Dabei werden die so genannten Legacy-Modelle13 - hierarchische und Netzwerkdatenbanken - ausgeklammert, da diese nur noch in Randbereichen eingesetzt werden.

3.1.1 Beschreibung der Modelle

Das relationale Modell repräsentiert die Datenbank als Sammlung von Relationen. Diese werden als Tabellen abgebildet, so dass gespeicherte Daten übersichtlich dargestellt werden können.14 Dieses Modell genügt bisher den meisten Anwendungen - laut Halpin 90 Prozent15 -, so dass die relationalen Datenbanksysteme das Technologiefeld als etabliertes Konzept dominieren. Durch das Aufkommen neuer Anforderung, wie z. B. die Speicherung von Multimedia, Dokumenten oder graphischen Formaten, stößt das relationale Modell allerdings an seine Grenzen.16 Diese Formate können nicht oder nur umständlich segmentiert und atomar dargestellt werden, weshalb sich relationale Datenmodelle für die Speicherung von komplexen Objekten disqualifizieren.17

Das objektorientierte Modell vereint die Paradigmen von Objektorientierung und Datenbanksystemen. Eigenschaften wie Komplexität, Objektidentität, Datenkapselung, Typen und Klassen, Vererbung, Polymorphismus, Vollständigkeit und Erweiterbarkeit werden mit den Prinzipien Dauerhaftigkeit, Verwaltung großer Datenbestände, Mehrbenutzerbetrieb, Rekonstruierbarkeit und Ad-hoc-Abfragemöglichkeit verknüpft.18 Dadurch können komplexe Objekte direkt in einer Datenbank gespeichert werden und müssen nicht mehr in flache Tabellen ,,gepresst" werden, was die Zusammenarbeit mit objektorientierten Programmiersprachen sehr vereinfacht.19
Anwendungsgebiete sind demnach Multimedia-Datenbanken mit Ton-, Bild- und Videodaten, geographische Informationssysteme und Entwurfsdatenbanken.20 Als Nachteil zeigt sich, dass die objektorientierten Produkte keinem universellen Datenmodell folgen und durch ihre Komplexität sehr kostspielig sind. Fehlende Standards und Erfahrungswerte werden als weitere Mängel genannt.21

Das objektrelationale Datenmodell will die Vorteile beider Datenmodelle kombinieren. Dabei ist der Ansatz, relationale Datenbanksysteme um Objekte zu erweitern, erfolgreicher als die Ergänzung von relationalen Prinzipien in objektorientierte Datenbanksysteme.22 Mit dem SQL3-Standard wurde das relationale Datenmodell u. a. um große Objekte (z. B. für Multimedia), geschachtelte Relationen, Referenzen und Objektidentität erweitert, so dass es möglich ist, Objekte innerhalb einer Relation zu speichern.23
Entsprechend bieten sich objektrelationale Datenmodelle durchaus als Alternative für relationale Datenmodelle an und können in den gleichen Bereichen eingesetzt werden. Gegenüber den objektorientierten Datenbanksystemen haben Sie den Vorteil, auch in Tabellenform vorliegende Daten effizient speichern zu können.
Geschäftsdaten erstrecken sich meistens über mehrere Dimensionen, wie z. B. die Zeit, das Produkt und die Abteilung.Zur Speicherung wurde deshalb das multidimensionale Datenmodell entworfen, welches die Daten in mehrdimensionalen Matrizen und Quadern - sogenannten ,,Cubes" - ablegt.24 Es wird in Data Warehouse-Produkten eingesetzt und vereinfacht das Abfragen von Daten, das Generieren von Berichten und das Durchführen von Analysen. Somit können Geschäftsdaten effizienter als mit anderen Datenmodellen gespeichert werden.25

Das semistrukturierte Datenmodell ist auf die Speicherung von semistrukturierten Daten ausgerichtet. Darunter versteht man Daten mit einer Struktur, die variieren kann26, selbstbeschreibend und indikativ ist und auch nur partiell vorhanden sein muss. Damit grenzt sich das semistrukturierte Datenmodell von den anderen Datenmodellen ab, die streng strukturiert sind.27 Dies prädestiniert das Modell für die Speicherung von XML-Dokumenten.
Für die Datenbank-Integration von XML gibt es zwei Ansätze. Die führenden Datenbankhersteller integrieren eine logische XML-Schnittstelle, um XML zu lesen und auszugeben.28 Stark strukturierte XML-Dokumente können auch relativ einfach übernommen werden. Sie werden entweder als BLOB29 gespeichert oder durch so genannte Mapping-Tools integriert.30 Dem gegenüber steht der Ansatz der nativen XML-Datenbanken. Diese werden immer beliebter, da sie XML nicht nur lesen und schreiben, sondern auch verwalten. Somit gibt es beim Integrieren von XML-Daten keinen Verlust. Native XML-Datenbanken nutzen die Dokumenttypdefinitionen als Schema und bilden davon eine Instanz, so dass die Verwaltung von XML viel einfacher als bei herkömmlichen Datenbanksystemen möglich ist.31 Darüber hinaus eignet sich XML ebenfalls zur Speicherung stark strukturierter Daten, so dass XML-Datenbanksysteme durchaus Potential haben.32 Die Nachteile von nativen XML-Datenbanken liegen darin, dass sie sich noch im Entwicklungsstadium befinden und noch nicht auf die Erfahrungswerte und das Marktgewicht von bestehenden Datenbanksystemen zurückgreifen können.33 Auch sollen sehr große Datenmengen einen unverhältnismäßig hohen Rechenaufwand erzeugen und erhöhen so die Hardwarekosten.34

3.1.2 Ausblick
Die Studie des BSI bekräftigt, dass sich die Bedeutung der Datenmodelle im Wandel befindet. Die folgende Abbildung stellt das Umfrageergebnis bezüglich der Bedeutung der Datenmodelle dar:



Abbildung 1: Bedeutung unterschiedlicher Datenmodelle

Quelle: Kommunikations- und Informationstechnik 2010+3 (2003), S. 220.

Laut der Studie werden die relationalen Datenbanken zwar in den nächsten Jahren noch dominieren, langfristig aber von modernen Datenbanksystemen abgelöst.
Nur einige Experten wie z. B. Meier35 sehen in den rein objektorientierten Systemen einen Trend. Indes werden sie sich wohl eher in wissenschaftlichen Spezialgebieten als Nischenprodukt platzieren können.36
Der Erfolg der objektrelationalen Datenbanken begründet sich damit, dass sie in der Lage sind, sowohl stark strukturierte Daten als auch komplexe Objekte zu speichern. Fast alle Experten - z. B. Elmasri37 und Stonebreaker38 - sind der Meinung, dass gerade die Verwaltung dieser komplexen Objekte entscheidend für den Erfolg eines Datenmodells ist. Immer wichtiger wird die Speicherung von Multimedia-Inhalten, geographischen Informationen, Konstruktionszeichnungen und anderen Formaten. Somit scheint die Ablösung relationaler Systeme eine Frage der Zeit zu sein.39
Die multidimensionalen Datenmodelle werden weiterhin in Spezialanwendungen mit großen Datenmengen dominieren. Da ihre Entwicklung allerdings noch nicht so weit fortgeschritten ist, werden ihnen nur langfristig große Chancen eingeräumt.40 Da Data Warehouse und Data Mining allgemein als Trend anerkannt sind,41 wird auch die Bedeutung des multidimensionalen Datenmodells mit Sicherheit wachsen.
Laut der BSI-Studie werden die semistrukturierten Datenmodelle, in der Abbildung ,,webbasierte Datenbanksysteme" genannt, an Gewicht zunehmen.42 Hier gibt es allerdings widersprüchliche Expertenmeinungen, inwieweit dieses neue Datenmodell das Technologiefeld der Datenbanksysteme verändern wird. Sicher ist, dass es sich hierbei ebenso wie bei dem objektrelationalen Datenmodell um einen Trend handelt. Dies zeigt sich darin, dass in diesem Jahr viele Publikationen zum Thema XML und Datenbanken erschienen sind. Und einige Experten behaupten sogar, dass der Einfluss von XML auf die Datenbanktechnologie größer sein wird als der von SQL43 und dem objektorientierten Datenmodell44. Unsicher ist allerdings, ob sich das semistrukturierte Datenmodell nur als logische Schnittstelle oder als natives System durchsetzen wird. Einige Experten wie Udell45 oder Helmer46 befürworten native Systeme, weil sie zur XML-Speicherung besser geeignet sind. Zur gleichen Zeit sind die großen Datenbankhersteller Oracle, IBM und Microsoft bemüht, XML so gut wie möglich zu integrieren.47 Zusammenfassend lässt sich sagen, dass native XML-Datenbanken den renommierten Systemen voraussichtlich in Teilgebieten Marktanteile abnehmen, aber sie nicht ablösen werden.

3.2 Vernetzung von Datenbanksystemen
Ein weiteres brisantes Thema sind vernetzte Datenbanksysteme. Diese bestehen aus Informationseinheiten, die auf mehreren Rechner verteilt sind, welche über ein Kommunikationsnetzwerk miteinander verbunden sind. Dabei sind die einzelnen Rechner autonom, haben aber die Aufgabe, andere Rechner mit Daten zu versorgen.48 Die Idee der dezentralen Speicherung existiert schon seit Mitte der 70er Jahre, allerdings handelte es sich hierbei meist um gleichartige Datenbanksysteme.49 Für unterschiedliche Datenbanksysteme fällt die Ist-Analyse eher negativ aus: es gibt bisher kaum Systeme, die Daten aus verschiedenartigen Quellen optimal integrieren.50 Das Schlagwort ,,Interoperabilität" steht in diesem Zusammenhang für die Fähigkeit unterschiedlicher Datenbanksysteme, miteinander zu kommunizieren.51
Im Folgenden wird untersucht, welche Formen der Datenverteilung es gibt, warum die Zusammenführung verschiedenartiger Datenbanken einen Trend darstellt und welche Voraussetzungen notwendig sind, um Interoperabilität zu ermöglichen.

3.2.1 Formen der Datenverteilung
Für die Verteilung der Daten gibt es verschiedene Formen, die vom Homogenitätsgrad abhängig sind. Zum einen gibt es verteilte Datenbanksysteme, die homogen und heterogen vorliegen können. In homogenen Datenbanksystemen verwenden Clients und Server das gleiche Datenbankmanagementsystem. Dabei werden die Inhalte auf verschiedene Systeme fragmentiert. In heterogenen Datenbanksystemen werden Datenbanken verschiedener Hersteller über Gateways miteinander verbunden.52 Von verteilten Datenbanksystemen erwartet man eine höhere Zuverlässigkeit und Verfügbarkeit der Daten. Sollte ein Datenknoten ausfallen, können weitere Knoten den Anfrager mit Daten versorgen. Des weiteren bieten sie eine bessere Performance, höhere Skalierbarkeit und große Transparenz.53 In heterogenen Umgebungen können die Stärken der einzelnen Datenbanksysteme je nach Anwendung kombiniert werden.54 Auch wird in der Datenbankforschung oft von dem Problem der ,,Wissensinseln" gesprochen. Durch die lokale Speicherung des Wissens und deren Vernetzung sollen diese zusammengeführt werden.55 Die Nachteile liegen in den höheren Kosten und vor allem in der Komplexität, wodurch leicht Fehler entstehen können.56
Neben den verteilten Datenbanksystemen gibt es die föderierten Datenbanksysteme. Sollte bei den verbundenen Datenbanken das Datenmodell abweichen, z. B. wenn hierarchische und relationale Datenbanken miteinander verbunden werden, muss ein föderiertes Datenbankschema erstellt werden, welches auf einer abstrakten Ebene die zugänglichen Knoten beschreibt.57 Die Verknüpfung findet hierbei über eine zusätzliche Softwareschicht statt, über welche die Datenbanksysteme miteinander kommunizieren.58 Aufgrund ihrer lokalen Autonomie werden die föderierten Datenbanken oft als Mischform zwischen zentralen und verteilten Datenbanken gesehen.59 In föderierten Datenbanksystemen geht es weniger um Vorteile wie Performancesteigerung oder Verfügbarkeit, als viel mehr um die grundliegende Notwendigkeit, Datenbanken miteinander zu verbinden.

3.2.2 Notwendigkeit von Interoperabilität
Das Thema Interoperabilität wird immer bedeutender. In den letzten Jahren wurden zunehmend verschiedenartige Datenbanksysteme miteinander verbunden. Dabei ist keine Trendwende abzusehen, im Gegenteil: die reibungslose Vernetzung von Datenbanken über ein föderiertes Schema wird immer wichtiger. Das zeigt sich am deutlichsten im Internet, wo mehr und mehr Datenbanken verknüpft werden. Selbst in einem Großunternehmen bleibt es eine Illusion, alle Daten in einem einzigen System integrieren zu können.60 Experten wie Halpin61, Carr62 und Sattler63 schließen sich deshalb der Meinung an, dass heterogene Datenbanken im Mittelpunkt aktueller Forschungen stehen und somit einen Trend darstellen.
Für die reibungslose Kommunikation zwischen Datenbanksystemen sind folgende wesentlichen Voraussetzungen notwendig:64


Die Kommunikation muss über einen Kanal und ein Protokoll gesichert sein.
Anfragen müssen generiert werden können.
Ein bekanntes Datenformat muss eingesetzt werden.
Die Daten müssen semantisch verstanden werden können.

Im Folgenden werden Entwicklungen in den Bereichen Datenbankschnittstellen und Datenbanksprachen untersucht, weil diese für die Erfüllung dieser Voraussetzungen am Wichtigsten sind. Ein Ausblick erfolgt direkt in den Kapiteln und eine Zusammenfassung schließt sich an.

3.2.3 Datenbankschnittstellen
Noch hat sich keine der standardisierten Datenbankschnittstellen auf dem Markt vollständig durchgesetzt. Zwar wird EDI bisher überwiegend zum Datentransfer genutzt, und die ISO hat Syntax-Regeln, Nachrichtentypen, deren Datenelemente und Dienste für Nachrichten normiert.65 Allerdings ist die Implementierung von EDI mit hohen Installationskosten aufgrund von Software- und Hardwareanpassungen und mit Online-Gebühren verbunden, weshalb nur große Firmen EDI einsetzen.66
So geht auch im Bereich der Interoperabilität der Trend in Richtung XML. Am meisten wird hierbei über ebXML diskutiert. Diese Schnittstelle ist wesentlich preiswerter zu integrieren und somit auch für kleine und mittelständische Unternehmen finanzierbar. Es müssen nur geringe Umprogrammierungen von Applikationen stattfinden, weil die kommunizierenden Geschäftsprozesse der Partner auf einfache Weise veröffentlicht werden.67 Im Gegensatz zu EDI ermöglicht XML eine flexible Spezifikation der Austauschformate und -bedingungen, so dass die Prozesse leicht angepasst und verbunden werden können.68
Derzeit gibt es Bemühungen der Standardisierungsgruppen hinter ebXML und EDI, welche darauf abzielen, beide Protokolle zu ergänzen, damit existierende EDI-Applikationen nicht umprogrammiert werden müssen.69 Trotzdem gehen die in der BSI-Studie befragten Experten davon aus, dass bereits 2006 EDI durch ebXML abgelöst wird.70 Und auch viele Autoren - Jenz71 und Halpin72 u. a. - sehen das genauso.

3.2.4 Abfragesprachen
Eine weitere wichtige Voraussetzung für Interoperabilität sind die Abfragesprachen. Momentan dominiert SQL als Sprache für relationale und objektrelationale Datenbanksysteme das Technologiefeld. Daneben gibt es noch weitere Sprachen wie z. B. XSL, XQL, OQL, GQL und QBE.
Mit Hilfe von SQL können Tabellen eingerichtet werden und Werte eingegeben, verändert und ausgegeben werden. Für die relationalen Systeme ist SQL de facto zum Industriestandard geworden.73 Neben SQL existieren für relationale Datenbanken zwar Sprachen wie QBE, Quel und Datalog, die allerdings kaum eingesetzt werden.74 Seit 1986 wird SQL permanent weiter entwickelt: 1998 wurde SQL in der Version 3 um objektorientierte Elemente erweitert, so dass SQL auch in objektrelationalen Datenbanksystemen eingesetzt werden kann. In SQL4, welches Ende 2003 erscheinen soll, wird neben anderen Funktionen auch die Verwaltung von XML und externen Daten integriert sein. In bezug auf XML werden Funktionen zur Generierung von XML, ein XML-Datentyp und Abbildungen von SQL zu XML-Dokumenten angeboten, so dass SQL nun XML lesen und erzeugen kann.75 Diese in den letzten fünf Jahren integrierten Funktionalitäten - Objekte, XML und externe Daten - haben dafür gesorgt, dass SQL nun einfacher in objekt- und XML-orientierten Umgebungen eingesetzt werden kann.
Als nachteilig gilt, dass der SQL-Standard XML nicht gut genug einbindet, wobei an einer Lösung weiter gearbeitet wird.76 Auch ist zweifelhaft, ob sich die Objektorientierung aus SQL3 durchsetzen kann, da SQL als einfache relationale Sprache kaum performant komplexe Objekte verwalten kann.77
Von der ODMG wurde die Abfragesprache OQL standardisiert, die das Objektmodell voll unterstützt.78 Seit SQL3 um Objekte erweitert wurde, wird OQL allerdings nur in rein objektorientierten Datenbankmanagementsystemen eingesetzt.79 Um Interoperabilität zu unterstützten, wird OQL stark an SQL angelehnt. So ist es durchaus möglich, dass dieses SQL nur erweitern wird, anstatt sich als eigenständige Sprache durchzusetzen. Die Verschmelzung gestaltet sich allerdings aufgrund der verschiedenartigen Ausrichtung auf Tabellen bzw. Objekten als kompliziert.80
Im Bereich der XML-Abfragesprachen wurden verschiedene Varianten entwickelt. Dabei wird XQL bereits kommerziell eingesetzt.81 Als reine Abfragesprache arbeitet es bei der Weiterverarbeitung und Präsentation der Anfragen mit XSL zusammen. XSL gliedert sich in die Teilbereiche XSLT für die Transformation, XPath, mit dessen Hilfe auf Teile eines XML-Baums zugegriffen wird, und XSL-FO für das Layout.82 XPath als Teilaspekt von XSL und damit XQL weist allerdings Defizite bei der XML-Anfrage auf.
Deshalb wurde vom W3C die Abfragesprache XQuery entwickelt, die sich sowohl um Anfragen als auch um die Präsentation kümmert. XQuery soll darüber hinaus nicht nur im Datenbank-Sektor eingesetzt werden, sondern auch zur Datenintegration und Dokumentenverarbeitung, z. B. bei der Volltextsuche.83 Es wird davon ausgegangen, dass XPath die Techniken XQL und XSL bald in nativen XML-Datenbanksystemen und als logische Schnittstelle ablöst84. Entsprechend wird XPath als zukunftsträchtige Abfragesprache gehandelt.85

Die BSI-Studie kam bei der Frage, welche Abfragesprache sich in den nächsten Jahren durchsetzen wird, auf folgende Antwort:



Abbildung 2: Bedeutung unterschiedlicher Datenbank-Abfragesprachen

Quelle: Kommunikations- und Informationstechnik 2010+3 (2003), S. 212.

Es ist demnach davon auszugehen, dass SQL seine Vormachtstellung behalten wird, während die XML-Sprachen gleichzeitig an Gewicht gewinnen. SQL wurde schon früh von Stonebreaker als ,,Intergalactic Dataspeak"86 bezeichnet, und dies scheint sich zu bewahrheiten: Durch die Anpassungen der letzten Jahre an neue Trends wird SQL weiter die meistgenutzte Sprache bleiben.87
Die XML-Sprachen erfüllen zwar noch nicht alle Anforderungen und es fehlen praktische Erfahrungen, dennoch werden diese Sprachen im Zuge der immer bedeutenderen Stellung von XML als Datenaustausch- und Datenbeschreibungsformat wichtiger.88
Auch OQL scheint an Bedeutung zu gewinnen, v. a. weil die Objektimplementierung in SQL noch nicht optimal umgesetzt ist.89 Allerdings wird sich die Verbreitung durch die Weiterentwicklung von SQL und XQuery auf die objektorientierte Datenwelt beschränken.

3.2.5 Zusammenfassung
Bei der Vernetzung von Datenbanksystemen werden die heterogenen und föderierte Datenbanksysteme eine immer größere Rolle spielen. Um für die notwendige Interoperabilität zur Kommunikation zwischen den verschiedenartigen Datenbanksystemen zu sorgen, wird ebXML als Schnittstelle EDI ablösen. Bei den Abfragesprachen wird die Weiterentwicklung von SQL und XQuery forciert. Wegen der großflächigen Verbreitung von SQL werden sich die XML-Sprachen allerdings nur langfristig durchsetzen.
Im Zusammenhang mit Interoperabilität gibt es über die genannten Bereiche hinaus Bestrebungen, die Kommunikation in vernetzen Datenbanken zu verbessern: dabei werden Web Services90 und Webserver-Fähigkeiten der Datenbanken91 wichtiger.

3.3 Integration contra Diversifikation
Geht es um die Integration von Anwendungen, gibt es zwei gegenläufige Überzeugungen: Diversifikation steht im Bezug auf Datenbanken für klare Schnittstellen und eine getrennte Bereitstellung von Applikationen, während der Begriff der Integration stellvertretend für ein Einbinden von möglichst viel Funktionalität in ein Datenbanksystem benutzt wird.92
Im Folgenden wird geklärt, welche einzubindenden Funktionalitäten einen Trend darstellen, und ob sich langfristig eher der Ansatz der Integration oder der Diversifikation durchsetzen wird.

3.3.1 Einbinden von Funktionalität
Bisher versuchen die großen Datenbankhersteller, möglichst viel Anwendung zu integrieren, damit zum einen ihre Produkte benutzerfreundlicher werden93 und zum anderen die immer anspruchsvoller werdenden Applikationen leichter angebunden werden können.94 Diese neuen Anforderungen verlangen von Datenbanksystemen einen Technologiebedarf, der von der Speicherung als BLOB bis zur Listenverwaltung komplexer Elementtypen, deren versionierter Speicherung sowie benutzerdefinierten Funktionen reicht.95 Relationale Datenmodelle konnten dies bisher nicht ausreichend ermöglichen, weil sie einen zu einfachen Aufbau besitzen.
Im Zuge der voranschreitenden Objektorientierung im Datenbankbereich96 wird die Erfüllung der wachsenden Ansprüche möglich, und so rechnen Datenbankexperten damit, dass folgende Formate in Zukunft in fast jedem Datenbankmanagementsystem unterstützt werden:


Mit CAD-Programmen werden Entwürfe von mechanischen und elektrischen Objekten gezeichnet. Eine CAD-Datenbank setzt voraus, dass sie CAD-Objekte mit Millionen von Teilen und Beziehungen verwalten kann und diese versionsgerecht speichert.97
CAM-Systeme sind ähnlich wie CAD-Programme aufgebaut, speichern allerdings nicht nur einen Entwurf, sondern auch Daten der Fertigung. Entsprechend werden Echtzeit-Reaktionen, eine schnelle Navigation und weitere Anforderungen erfüllt.98
Eine CASE-Anwendung unterstützt Mithilfe einer Entwicklungsumgebung den Zyklus einer Softwareentwicklung von Planung, Anforderung, Design, Entwicklung bis zu Tests, Wartung und Dokumentation. Auch hier werden besondere Anforderungen an die Versionierung und die Verwaltung sehr großer Entwürfe gestellt.99 In einer CASE-Datenbank werden entsprechend Quellcode, Beziehungen von Softwaremodulen, Variabelendefinitionen etc. gespeichert.100
Multimedia-Formate sind z. B. Bilder, räumliche Daten, Audio- und Videosequenzen.101 Multimedia-Datenbanken müssen nicht nur Multimedia effizient verwalten, sondern vor allem mit anderen Multimediaquellen zusammenarbeiten können.102
Ein Office Information System beinhaltet Geschäftsinformationen wie E-Mails, Dokumente und Rechnungen. Diese benötigen oft komplexe Datentypen wie Diagramme, formatierte Texte und Multimedia-Formate.103
GIS modellieren und verwalten raumbezogene zwei- oder dreidimensionale Informationen, und werden in der Geographie, Kartographie, Architektur und in Navigationssystemen eingesetzt.104 Dabei bieten sich objektrelationale105 und XML-Modelle106 als Basis zur Speicherung der räumlichen Daten an.

Im Bereich der Anwendungsintegration wird auch an speziellen Verfahren zur Lösung statistischer Probleme gearbeitet. Mit Hilfe von evolutionären Algorithmen sollen schwierige Probleme gelöst werden, z. B. eine optimale Ressourcenverteilung oder Probleme der Bioinformatik. Neuronale Netze sollen mit Hilfe von paralleler Informationsverarbeitung und Lernfähigkeit bei der Wissensgenerierung aus einer Datenbank und bei Grafik- und Sprachanalysen helfen. Diese Verfahren werden allerdings als nicht so wichtig wie die vorher genannten Anwendungen erachtet und deshalb im folgenden nicht weiter betrachtet.107

3.3.2 Klare Schnittstellen
Die Alternative zum Einbinden immer neuer Formate und Anwendungen in Datenbanksysteme heißt Diversifikation. Statt neue Formate wie räumliche Daten und Multimedia in die Datenbanksysteme zu integrieren, sollen klare Schnittstellen dafür sorgen, dass Funktionalitäten von externen Applikationen bereitgestellt werden können. Welches Maß die Integration annehmen darf, wird unter Datenbankexperten heftig diskutiert.108
Nachteile einer immer weitergehenden Integration liegen in der steigenden Komplexität und im Performancerückgang, welche allerdings bisher durch technologische Weiterentwicklungen aufgefangen werden konnten.109 Auch kommt es zu finanziellen Verlusten, weil meist mehr Merkmale eingebaut als verkauft werden, und zudem immer Daten vorliegen, deren Integration eine Umprogrammierung erfordert.110
Klare Schnittstellen werden deshalb immer wichtiger, um Funktionalität außerhalb des Datenbanksystems anzusiedeln. Auch hier wird XML eine große Rolle spielen: als einheitliche Programmierschnittstelle soll es dem Austausch zwischen Datenbanksystemen und Applikationen dienen.

3.3.3 Ausblick
Auch wenn einige Experten weniger Anwendungsintegration fordern, wird der Einbau von modernen Funktionalitäten vorerst sicher wichtig bleiben. Folgende Grafik zeigt, welche Bedeutung die vom BSI befragten Experten den einzelnen Funktionalitäten beimessen:



Abbildung 3: Bedeutung der Integration unterschiedlicher Funktionen in Datenbanksystemen

Quelle: Kommunikations- und Informationstechnik 2010+3 (2003), S. 205.

Vor allem geographische Daten und CASE werden dementsprechend eine große Rolle spielen, und auch CAM, CAD und CTI111 werden in ihrer Bedeutung steigen. Der Einbau von Multimedia wurde in diesem Zusammenhang zwar nicht erörtert, allerdings wird die Integration von räumlichen und multimedialen Daten in der neuen Literatur allerdings meist analog als ,,neue Entwicklung" eingestuft: U. a. sehen Halpin112, Vossen113 und Silberschatz114 GIS und Multimedia-verwaltende Datenbanken als wichtige neue Technologien an. Elmasri spricht sogar von einer Vormachtstellung von Multimedia-Informationssystemen115. Blažewicz unterstützt ihn darin.116
Laut der BSI-Studie erachten Experten Diversifikation für mindestens genauso wichtig wie Integration.117 Bis 2006 sollen Mithilfe von XML definierte und einheitliche Schnittstellen für Programmierer vorliegen, so dass diese leicht von außerhalb Funktionen integrieren können.118
Zusammenfassend lässt sich folgern, dass man nicht klar ausmachen kann, ob nun Diversifikation oder Integration wichtiger wird. Sicher ist, dass es einige Funktionalitäten gibt, deren Einbau direkt in das Datenbanksystem notwendig ist, um komplizierte Anforderungen zu erfüllen. Und offenkundig ist auch, dass Datenbanken und Applikationen auf Dauer nur effizient zusammenarbeiten können, wenn klare Schnittstellen geschaffen werden.

3.4 Weitere Trends
Bisher wurden die drei Sachgebiete der Datenbankmodelle, der Vernetzung von Datenbanken und der Integration bzw. Diversifikation untersucht. Es gibt allerdings in der Datenbankforschung noch eine Vielzahl weiterer Entwicklungen, die durchaus einen Trend darstellen, z. B. im Bereich Sicherheit oder bei den aktiven, temporalen oder webbasierten Datenbanken. Diese zu beschreiben würde den Rahmen dieser Arbeit sprengen, und so beschränken sich die folgenden Ausführungen auf die Trends Data Warehouse, Data Mining, deduktive und parallele Datenbanken.

3.4.1 Data Warehouse und Data Mining
Data Warehouses speichern historische und aktuelle Geschäftsdaten, um bei allen Entscheidungen zu unterstützen, die eine Unternehmung treffen muss. Die benötigten Daten liegen meist in unterschiedlichen Quellen vor und deren Integration und Verwaltung sowie die Analyse sind die Hauptaufgaben eines Data Warehouses.119 Die verwalteten Daten eines Data Warehouse müssen folgenden Anforderungen genügen:120


Um Entscheidungen zu unterstützen, müssen sie subjektorientiert sein.
Die Datenquellen müssen konsistent integriert werden.
Die Daten müssen zeitbezogen gespeichert werden.
Sie müssen beständig sein, d.h. sie dürfen nicht mehr ersetzt werden.

Die Geschäftsdaten werden in multidimensionalen Datenmodellen gespeichert und mit Hilfe von Techniken wie OLAP und Data Mining analysiert. Traditionelle Datenbanksysteme unterstützen dagegen OLTP, welches aktuelle Informationen verwaltet, und reichern Data Warehouses mit zuvor verdichteten Informationen an.121 OLAP basiert auf diesen verdichteten Daten und analysiert diese, um kritische Daten für Entscheidungsträger aufzubereiten.122
Data Mining kümmert sich um die Auswertung der Daten zur Generierung von neuem Wissen. Die Grenzen zu anderen Wissenschaften wie Statistik und Maschinelles Lernen sind hierbei fließend.123 Mit Hilfe von verschiedenen Regeln sollen zukünftige Eigenschaften der Daten aufgezeigt, unbekannte Sachverhalte identifiziert (z. B. ein Hackerangriff oder ein Gen in einem DNA-Strang), Klassifikationen von Daten erstellt und die Verteilung begrenzter Ressourcen optimiert werden.124
Laut der BSI-Studie wird die Bedeutung von Datenauswertung und Datenanalyse durch Data Warehouses und Data Mining in den nächsten Jahren weiter wachsen.125 Auch andere Systeme wie Knowledge Management und Decision Support Systems werden von diesen erweiterten Fähigkeiten profitieren und teilweise traditionelle Datenbanksysteme ablösen. Insbesondere den so genannten Business Intelligence-Anwendungen, die operative Daten in entscheidungsrelevante Informationen transferieren, wird insgesamt ein stabiler Markt zugetraut.126 Bei der Datenanalyse werden vor allem multidimensionales und hybrides OLAP127 eine Rolle spielen, allerdings auch das noch eher unbekannte OLCP. Mit Hilfe von OLCP können Datenbanken mit komplexen Objekten wie z. B. Multimedia oder Grafiken nach Inhalten durchsucht werden.128 Zur Weiterentwicklung von Data Mining wird vor allem die Forschung an den Techniken der Ähnlichkeitssuche und der Klassifikation von Objekten zunehmen.129
Die Bedeutung von Data Warehouse und Data Mining wird auch von anderen Experten hervorgehoben: Elmasri traut diesen Datenbanktechniken eine große Rolle im nächsten Jahrzehnt zu130. Und fast alle gängigen Datenbank-Publikationen nennen sie als Trend, u. a. Silberschatz131 und Halpin132.

3.4.2 Deduktive Datenbanksysteme
Eine weitere Methode, um Wissen aus Fakten einer Datenbasis zu gewinnen, ist das Prädikatenkalkül der Logikprogrammierung. Wird diese Logik in ein Datenbanksystem integriert, spricht man von einem deduktiven Datenbanksystem.133 Im Gegensatz zum Data Mining, das ebenso der Wissensgenerierung dient, bearbeitet es keine multidimensionalen, sondern relationale Datenbestände, und eignet sich so auch für herkömmliche Datenbanksysteme. Eingesetzt werden deduktive Datenbanksysteme z. B. in Verkehrsauskunfts-, wissensbasierten- und Expertensystemen.134
Ein deduktives Datenbanksystem basiert entsprechend der Logikprogrammierung auf Regeln und Fakten, welches die Tupel der Datenbasis sind. Im Gegensatz zu den traditionellen Datenbanksystemen ist das deduktive Konzept somit turingvollständig, d. h. dass sie jedes mathematisch berechenbare Problem lösen können.135 Tatsächlich wurde die Bedeutung von Deduktion mit der Integration rekursiver Sichten in SQL3 untermauert.136
Momentan sind die deduktiven Datenbanktechniken allerdings nicht ausgereift genug und stoßen bei Anwendern auf wenig Akzeptanz.137 Auch wenn diese Technik als elegant bezeichnet wird, sind noch einige Probleme zu lösen, z. B. wird Deduktion als zu langsam eingestuft.138 Schon 1996 versprachen sich Spezialisten von deduktiven Datenbanken langfristig eine zukunftsweisende Technologie.139 Tatsächlich sehen die von dem BSI befragten Experten heute erst recht eine Zukunft für deduktive Techniken und schätzen, dass diese 2007 in den gängigen Datenbanksystemen verfügbar sein werden.140

3.4.3 Parallele Datenbanksysteme
Mit den zu verarbeitenden Daten wachsen auch die Anforderungen an Datenbanksysteme. Einprozessor-Server werden in Zukunft kaum mehr ausreichen, um Anfragen an Informationssysteme zu beantworten. Parallelität stellt hierbei eine Schlüsseltechnologie zur Steigerung von Performance und Skalierbarkeit dar, und entsprechend aktiv wird im Bereich der parallelen Datenbanksysteme entwickelt.141 Ähnlich wie beim Architekturkonzept der verteilten Datenbanksysteme sind auch hier die Daten auf mehrere Plattformen verteilt. Allerdings liegt hier der Fokus auf der parallelen Bearbeitung von Operationen und auf der Schnelligkeit. Auch liegen die Knoten meist in einem Computer oder zumindest an einem Standort vor, anstatt geographisch verteilt zu sein.142
Man unterscheidet zwischen drei Architekturtypen:143


In der Shared-Memory-Architektur teilen sich mehrere Prozessoren einen Haupt- und Sekundärspeicher. Die Vorteile liegen in der einfachen Programmierung und optimalen Lastenverteilung. Die Nachteile liegen in der Synchronisation des Speicherzugriffs und der geringen Fehlerisolierung. Fehler treten dann auf, wenn Daten gleichzeitig in mehrere lokale Prozessor-Caches geladen und dort geändert werden: die Caches sind dann nicht mehr kohärent.
Bei der Shared-Disk-Architektur besitzt jeder Prozessor einen Hauptspeicher und teilt sich mit anderen den Sekundärspeicher. Auf jedem Knoten liegt eine Kopie der Datenbank vor, die mit anderen synchronisiert werden muss. Die Vorteile liegen hier in der einfachen Skalierbarkeit und der Möglichkeit, ganze Funktionen an andere Prozessoren weiterzugeben.
In der Shared-Nothing-Architektur hat jeder Prozessor seinen eigenen Speicher, so dass diese Architektur den verteilten Datenbanken sehr ähnlich ist. Optimal sind hier die Lastenverteilung, leichte Skalierbarkeit und gute Fehlerisolierung. Nachteilig sind die höheren Hardwarekosten.

Durch das steigende Datenvolumen und die ständige Forderung nach mehr Performance werden die parallelen Datenbanken als Entwicklungstrend immer wichtiger. Daher geht die BSI-Studie von einer weiten Verbreitung bis 2007 aus.144

4. Zusammenfassung
Die Welt der Datenbanksysteme entwickelt sich weiter. Welche Richtungen sie ansteuert, ist dabei nur mittelfristig zu beantworten. In den nächsten Jahren werden auf jeden Fall Datenbanksysteme wichtig sein, die nicht nur große Datenbestände verwalten können, sondern darüber hinausgehenden Ansprüchen gerecht werden: Sie müssen über ein Datenmodell verfügen, welches multimediale, geographische, semistrukturierte und andere komplexe Daten speichern kann. Ihre Daten sollen sie in verteilten Systemen ablegen können und darauf einen performanten Zugriff gewährleisten. Der Datenaustausch mit Applikationen und fremden Datenbanksystemen muss reibungslos funktionieren. Um den Benutzer zufrieden zu stellen, müssen sie neue Methoden zur Aufbereitung von Daten und zur Generierung von Wissen beherrschen.
Die Ansprüche werden nicht sinken, sondern wachsen: Komplexe Objekte, XML, Vernetzung, Verteilung, Anwendungsintegration, Standardisierung, Informationssysteme und Parallelität sind nur einige der Themen, welche auch in Zukunft die Datenbankhersteller herausfordern und den Bereich der Datenbanksysteme spannend gestalten.

Literaturverzeichnis

Alkassar, Ammar et al. (2003):
Kommunikations- und Informationstechnik 2010+3: Neue Trends und Entwicklungen in Technologien, Anwendungen und Sicherheit, Ingelheim 2003.
Begg, Carolyn et al. (1999):
Datenbanksysteme: Eine praktische Anleitung zu Design, Implementierung und Management, München 1999.
Blažewicz, Jacek / Morzy, Tadeusz (2003):
Management of Data: State-of-the-Art and Emerging Trends, in: Blažewicz, Jacek et al.: Handbook on Data Management in Information Systems, Berlin et al. 2003, S. 1-17.
Brinkhoff, Thomas / Weitkämper, Jürgen (2001):
Eine Architektur zur XML-basierten Repräsentation von bewegten Geo-Objekten, in: Heuer, Andreas et al. (Hrsg.): Datenbanksysteme in Büro, Technik und Wissenschaft, Berlin et al. 2001, S.127-143.
Disterer, Georg et al. (2003):
Taschenbuch der Wirtschaftsinformatik, 2. Auflage, München, Wien 2003.
Dorndorf, Ulrich / Pesch, Erwin (2003):
Data Warehouses, in: Blažewicz, Jacek et al.: Handbook on Data Management in Information Systems, Berlin et al. 2003, S. 387-430.
Elmasri, Ramez / Navathe, Shamkant B. (2002):
Grundlagen von Datenbanksystemen, 3., überarbeitete Auflage, München 2002.
Erbs, Heinz-Erich et al. (2003):
Datenbanken: Datenmodelle, Objekte, WWW, XML, Berlin, Offenbach 2003.
Ester, Martin / Sander, Jörg (2000):
Knowledge discovery in databases: Techniken und Anwendungen, Berlin et al. 2000.
Ghandeharizadeh, Shahram et al. (2003):
High Performance Parallel Database Management Systems, in: Blažewicz, Jacek et al.: Handbook on Data Management in Information Systems, Berlin et al. 2003, S. 194-220.
Hadeler, Thorsten / Arentzen, Ute (2000):
Gabler Wirtschaftslexikon, 15. Auflage, Wiesbaden 2001.
Halpin, Terry (2001):
Information modeling and relational databases: from conceptual analysis to logical design, London 2001.
Hansen, Hans Robert / Neumann, Gustaf (2001):
Wirtschaftsinformatik I, 8., völlig neubearbeitete und erweiterte Auflage, Stuttgart 2001.
Härder, Theo / Rahm, Erhard (1999):
Datenbanksysteme: Konzepte und Techniken der Implementierung, Berlin et al. 1999.
Helmer, Sven et al. (2003):
XML-Datenbanksysteme und ihre Anwendung, in: it - Information Technology, 45. Jg., Heft 3/2003, S. 137-142.
Horx, Matthias / Wippermann, Peter (1996):
Was ist Trendforschung?, Düsseldorf 1996.
IT-Director (2002):
Transformation von Daten in Wissen, in: IT-Director, 7. Jg., Heft 11/2002, S. 57.
Kazakos, Wassilios et al. (2002):
Datenbanken und XML, Berlin et al. 2002.
Kemper, Alfons / Eickler, André (2001):
Datenbanksysteme: eine Einführung, 4., überarbeitete und erweiterte Auflage, München et al. 2001.
Kemper, Alfons / Moerkotte, Guido (2003):
Object-Oriented Database Systems, in: Blažewicz, Jacek et al.: Handbook on Data Management in Information Systems, Berlin et al. 2003, S. 78-193.
Kleiner, Carsten / Lipeck, Udo W. (2001):
Web-Enabling Geographic Data with Object-relational Databases, in: Heuer, Andreas et al. (Hrsg.): Datenbanksysteme in Büro, Technik und Wissenschaft, Berlin et al. 2001, S.127-143.
Kramer, Christian (2001):
Analyse der Eignung von XML für die Verwendung von Datenmanagement in Datenbanken, Diplomarbeit, Berlin 2001.
Meier, Andreas / Wüst, Thomas (2000):
Objektorientierte und objektrelationale Datenbanken: ein Kompass für die Praxis, 2., überarbeitete und aktualisierte Auflage, Heidelberg 2000.
Michels, Jan-Eike et al. (2003):
The SQL Standard, in: it - Information Technology, 45. Jg., Heft 1/2003, S. 30-38.
Mittermeier, Ludwig (2003):
XML und Datenbanken: Naiv nativ, in: iX, Heft 8/2003, S. 42-52.
Pernul, Günther / Unland, Rainer (2003):
Datenbanken im Unternehmen: Analyse, Modellbildung und Einsatz, 2., korrigierte Auflage, München, Wien 2003.
Rolland, Fred (2003):
Datenbanksysteme im Klartext, München 2003.
Schulz, Hajo / Siering, Peter (2003):
Datendiener: Freie Datenbankserver im Vergleich, in: c′t, Heft 5/2003, S.142-147.
Silberschatz, Abraham et al. (1999):
Database system concepts, 3. Auflage, Boston et al. 1999.
Stickel, Eberhard (Hrsg.) (1997):
Gabler - Wirtschaftsinformatik - Lexikon, Wiesbaden 1997.
Vossen, Gottfried (2000):
Datenmodelle, Datenbanksprachen und Datenbankmanagementsysteme, 4., korrigierte und ergänzte Auflage, München et al. 2000.
Zhang, Weiping / Ritter, Norbert (2001):
Leistungsuntersuchung von ORDB-gestützten objektorientierten Anwendungssystemen, in: Heuer, Andreas et al. (Hrsg.): Datenbanksysteme in Büro, Technik und Wissenschaft, Berlin et al. 2001, S. 227-243.

Internetverzeichnis
Bager, Jo (1999):
Datenbanken: Wie man Informationen am besten organisiert, http://www.heise.de/ct/99/04/130/, 02.06.2000, Abruf am 01.12.2003.
Bry, François / Seipel, Dietmar (1996):
Deduktive Datenbanken, http://www.gi-ev.de/informatik/lexikon/inf-lex-deduktive-db.shtml, 1996, Abruf am 02.12.2003.
Carr, Eric (2001):
6 trends in business intelligence, http://asia.cnet.com/newstech/applications/printfriendly.htm? AT=38027571-39001103t-39000011c, 24.10.2001, Abruf am 01.12.2003.
Deutsche Informatik Akademie (2003):
9. Datenbank-Tutorientage 2003, http://www.dia-bonn.de/downloads/dbtt_2003.pdf, 2003, Abruf am 02.12.2003.
Devarakonda, Ramakanth S. (2002):
Object-Relational Database Systems - The Road Ahead, http://www.acm.org/crossroads/xrds7-3/ordbms.html, 01.03.2002, Abruf am 01.12.2003.
Fredegar, Florian (2003):
Was für unterschiedliche Arten an Programmiersprachen gibt es?, http://www.selflinux.org/ selflinux-devel/html/programmieren_allgemein03.html, 6.10.2003, Abruf am 02.12.2003.
IDG Interactive (2003):
Studie: Deutsche länger online, http://www.tecchannel.de/news/internet/13696/, 24.11.2003, Abruf am 28.11.2003.
Jenz, Dieter E. (2002):
ebXML kommt - und keiner merkt′s?, http://www.aboutit.de/view.php?ziel=/02/28/08.html, 17.08.2002, Abruf am 02.12.2003.
Klischewski, Ralf (2003):
Interoperabilität und Kooperation in der internetbasierten Verwaltung, http://swt-www.informatik.uni-hamburg.de/publications/files/klischewski_emisa03.pdf, 2003, Abruf am 02.12.2003.
Meehan, Michael (2001):
EDI, ebXML groups agree to cooperate, http://www.computerworld.com/printthis/ 2001/0,4814,61840,00.html, 02.07.2001, Abruf am 02.12.2003.
Münz, Stefan (2001):
Entstehung des Internet, http://selfhtml.teamone.de/intro/internet/entstehung.htm, Abruf am 28.11.2003.
North, Ken (1998):
Complex Processing, Analytical Processing, and Transactions, http://ourworld.compuserve.com/ homepages/Ken_North/complex.htm, Juni 1998, Abruf am 02.12.2003.
Oebbeke, Alfons (2003):
EDI / EDIFACT, http://www.glossar.de/glossar/z_edi.htm, Abruf am 02.12.2003.
Sattler, Kai-Uwe (2003):
Anfragetechniken für heterogene Datenbanksysteme, Habilitation, http://wwwiti.cs.uni-magdeburg.de/~sattler/papers/Habilschrift.pdf, 16.05.2003, Abruf am 02.12.2003.
Schmitz, Ludger (2002):
Relationale Datenbanken und XML, http://www.cowo.de/index.cfm?pageid=255&artid=42163, 23.10.2002, Abruf am 01.12.2003.
Siemens (2003):
Computer Telefonie Integration, http://w3.siemens.de/solutionprovider/_online_lexikon/ 8/f000478.htm, Abruf am 02.12.2003.
Udell, John (2003):
The future of XML documents and relational databases, http://www.infoworld.com/article/ 03/07/25/29FEdocs_1.html, 25.07.2003, Abruf am 02.12.2003.


--------------------------------------------------------------------------------

1 Vgl. Eickler, A. / Kemper, A. (2001), S. 15.

2 Schulz, H. / Siering, P. (2003), S. 142.

3 Vgl. Blažewicz, J. / Morzy, T. (2003), S. 2.

4 Vgl. Horx, M. / Wippermann, P. (1996), S. 19.

5 Vgl. Hadeler, T. / Arentzen, U. (2000), Stichwort ,,Trend".

6 Vgl. Hansen, H. R. / Neumann, G. (2001), S. 11.

7 Vgl. Alkassar, A. et al. (2003), S. 328.

8 Vgl. Münz, S. (2001), Abschnitt ,,Das Netz der Netze".

9 Vgl. IDG Interactive (2003).

10 Vgl. Pernul, G. / Unland, R. (2003), S. 11.

11 Vgl. Vossen, G. (2000), S. 6.

12 Vgl. Bager, J. (1999), Glossarstichwort ,,Postrelational".

13 Vgl. Elmasri, R. / Navathe, S. B. (2002), S. 468.

14 Vgl. Elmasri, R. / Navathe, S. B. (2002), S. 226.

15 Vgl. Halpin, T. (2001), S. 692.

16 Vgl. Kemper, A. / Eickler, A. (2001), S. 354.

17 Vgl. Erbs, H.-E. et al. (2003), S. 133.

18 Vgl. Meier, A. / Wüst, T. (2000), S. 5.

19 Vgl. Zhang, W. / Ritter, N. (2001), S. 228.

20 Vgl. Rolland, F. (2003), S. 154.

21 Vgl. Begg, C. et al. (1999), S. 783f.

22 Vgl. Silberschatz, A. et al. (1999), S. 272.

23 Vgl. Kemper, A. / Eickler, A. (2001), S. 392.

24 Vgl. Dorndorf, U. / Pesch, E. (2003), S. 416.

25 Vgl. Begg, C. et al. (1999), S. 910.

26 Die Variation erklärt sich dadurch, dass XML-Elemente fehlen oder hinzukommen können.

27 Vgl. Kazakos, W. et al. (2002), S. 28.

28 Ebenda, S: 284.

29 Eine Speicherung als BLOB kann einfach implementiert werden, erschwert allerdings eine Durchsuchung.

30 Vgl. Mittermeier, L. (2003), S. 43.

31 Vgl. Hansen, H. R. / Neumann, G. (2001), S. 1093.

32 Vgl. Kazakos, W. et al. (2002), S. 31.

33 Vgl. Mittermeier, L. (2003), S. 52.

34 Vgl. Kramer, Christian (2001), S. 74.

35 Vgl. Meier, A. / Wüst, T. (2000), S. VII.

36 Vgl. Alkassar, A. et al. (2003), S. 201.

37 Vgl. Elmasri, R. / Navathe, S. B. (2002), S. 469.

38 Vgl. Devarakonda, R. S. (2002).

39 Vgl. Meier, A. / Wüst, T. (2000), S. VII.

40 Vgl. Alkassar, A. et al. (2003), S. 201.

41 siehe Kapitel 3.4.1 ,,Data Warehouse und Data Mining".

42 Vgl. Alkassar, A. et al. (2003), S. 220.

43 Vgl. Kazakos, W. et al. (2002), S. VII.

44 Vgl. Udell, J. (2003), S. 1, Einleitung.

45 Vgl. Udell, J. (2003), S. 2, Abschnitt ,,The Future of Documents".

46 Vgl. Helmer, S. et al. (2003), S. 142.

47 Vgl. Schmitz, L. (2002).

48 Vgl. Kemper, A. / Eickler, A. (2001), S. 443.

49 Vgl. Hansen, H. R. / Neumann, G. (2001), S. 1082.

50 Vgl. Alkassar, A. et al. (2003), S. 207.

51 Vgl. Elmasri, R. / Navathe, S. B. (2002), S. 217.

52 Vgl. Rolland, F. (2003), S. 223f.

53 Vgl. Elmasri, R. / Navathe, S. B. (2002), S. 825.

54 Vgl. Alkassar, A. et al. (2003), S. 204.

55 Vgl. Begg, C. et al. (1999), S. 652.

56 Vgl. Silberschatz, A. et al. (1999), S. 626.

57 Vgl. Rolland, F. (2003), S. 223f.

58 Vgl. Silberschatz, A. et al. (1999), S. 622.

59 Vgl. Begg, C. et al. (1999), S. 662.

60 Vgl. Härder, T. / Rahm, E. (1999), S. 535.

61 Vgl. Halpin, T. (2001), S. 702.

62 Vgl. Carr, E. (2001), Abschnitt ,,Trend 1: More data in more places".

63 Vgl. Sattler, K.-U. (2003), S. 3.

64 Vgl. Klischewski, R. (2003), S. 3.

65 Vgl. Stickel, E. (1997), S. 216.

66 Vgl. Oebbeke, Alfons (2003), Abschnitt ,,EDI wird durch Internet und XML erschwinglich".

67 Vgl. Jenz, D. E. (2002), Absatz 1.

68 Vgl. Alkassar, A. et al. (2003), S. 208.

69 Vgl. Meehan, Michael (2001).

70 Vgl. Alkassar, A. et al. (2003), S. 224.

71 Vgl. Jenz, D. E. (2002), Absatz 4.

72 Vgl. Halpin, T. (2001), S. 702.

73 Vgl. Rolland, F. (2003), S. 99.

74 Vgl. Silberschatz, A. et al. (1999), S. 188.

75 Vgl. Michels, J.-E. et al. (2003), S. 32 ff.

76 Vgl. Kazakos, W. et al. (2002), S. 101.

77 Vgl. Pernul, G. / Unland, R. (2003), S. 258.

78 Vgl. Meier, A. / Wüst, T. (2000), S. 76.

79 Ebenda, S. 172.

80 Vgl. Kemper, A. / Moerkotte, G. (2003), S. 106.

81 Vgl. Kazakos, W. et al. (2002), S. 79.

82 Ebenda, S. 107.

83 Ebenda, S. 80.

84 Vgl. Deutsche Informatik Akademie (2003), S. 2, Abschnitt ,,Zugriff auf XML in Datenbanken".

85 Vgl. Udell, J. (2003), S. 2, Abschnitt ,, Query Strategies".

86 Stonebreaker, Michael, zitiert nach Michels, J.-E. et al. (2003), S. 38.

87 Vgl. Michels, J.-E. et al. (2003), S. 38.

88 Vgl. Kazakos, W. et al. (2002), S. 105.

89 Vgl. Pernul, G. / Unland, R. (2003), S. 258.

90 Web Services sind im Internet bereitliegende Funktionen, die für den Datenzugriff in eigene Applikationen eingebunden werden können. Vgl. Klischewski, R. (2003), S. 3.

91 Webserver-Fähigkeiten in DBS ermöglichen, dass Datenbankoperationen über HTTP gebündelt werden. Vgl. Alkassar, A. et al. (2003), S. 206.

92 Vgl. Alkassar, A. et al. (2003), S. 209.

93 Vgl. Carr, E. (2001), Abschnitt ,,Trend 6: Why more is less".

94 Vgl. Elmasri, R. / Navathe, S. B. (2002), S. 787.

95 Vgl. Härder, T. / Rahm, E. (1999), S. 169.

96 siehe Kapitel 3.1.1 ,,Beschreibung der Modelle".

97 Vgl. Begg, C. et al. (1999), S. 733.

98 Ebenda, S. 733.

99 Ebenda, S. 734.

100 Vgl. Silberschatz, A. et al. (1999), S. 252.

101 Ebenda, S. 252.

102 Vgl. Blažewicz, J. et al. (2003), S. 5.

103 Vgl. Begg, C. et al. (1999), S. 734.

104 Vgl. Vossen, G. (2000), S. 725.

105 Vgl. Kleiner, C. / Lipeck, U. W. (2001), S. 127.

106 Vgl. Brinkhoff, T. / Weitkämper, J. (2001), S. 144.

107 Vgl. Alkassar, A. et al. (2003), S. 205.

108 Ebenda, S. 204.

109 Ebenda, S. 209.

110 Vgl. Carr, E. (2001), Abschnitt ,,Trend 6: Why more is less".

111 CTI steht für die Integration von Telephonie in die Computerwelt, Vgl. Siemens (2003).

112 Vgl. Halpin, T. (2001), S. 700.

113 Vgl. Vossen, G. (2000), S. 725 ff.

114 Vgl. Silberschatz, A. et al. (1999), S. 710 und 719.

115 Vgl. Elmasri, R. / Navathe, S. B. (2002), S. 944.

116 Vgl. Blažewicz, J. / Morzy, T. (2003), S. 5.

117 Vgl. Alkassar, A. et al. (2003), S. 210.

118 Ebenda, S. 205.

119 Vgl. Dorndorf, U. / Pesch, E. (2003), S. 387.

120 Vgl. Begg, C. et al. (1999), S. 909.

121 Vgl. Vossen, G. (2000), S. 674.

122 Ebenda, S. 682.

123 Vgl. Ester, M. / Sander, J. (2000), S. 15.

124 Vgl. Elmasri, R. / Navathe, S. B. (2002), S. 916 ff.

125 Vgl. Alkassar, A. et al. (2003), S. 214 ff.

126 Vgl. IT-Director (2002), S. 57.

127 Hybrides OLAP ist eine Mischung aus relationalem und multidimensionalem OLAP.

128 Vgl. North, K. (1998), Abschnitt ,,OLCP".

129 Vgl. Alkassar, A. et al. (2003), S. 217.

130 Vgl. Elmasri, R. / Navathe, S. B. (2002), S. 932.

131 Vgl. Silberschatz, A. et al. (1999), S. 708.

132 Vgl. Halpin, T. (2001), S. 660.

133 Vgl. Kemper, A. / Eickler, A. (2001), S. 415.

134 Vgl. Disterer, Georg et al. (2003), S. 236.

135 Vgl. Fredegar, Florian (2003), Absatz 8.

136 Vgl. Bry, F. / Seipel, D. (1996), Absatz 1.

137 Vgl. Alkassar, A. et al. (2003), S. 201.

138 Vgl. Halpin, T. (2001), S. 700.

139 Vgl. Bry, F. / Seipel, D. (1996), letzter Absatz.

140 Vgl. Alkassar, A. et al. (2003), S. 202.

141 Vgl. Ghandeharizadeh, S. et al. (2003), S. 194.

142 Vgl. Begg, C. et al. (1999), S. 656.

143 Vgl. Vossen, G. (2000), S. 57.

144 Vgl. Alkassar, A. et al. (2003), S. 220.


Quelle: