Lade Inhalt...

SchemaSQL - eine Erweiterung von SQL zur Verarbeitung von Informationen aus Multidatenbanksymenste

von Sebastian Behrens (Autor) Sven Wollrabe (Autor)

Hausarbeit 2002 23 Seiten

Informatik - Wirtschaftsinformatik

Leseprobe

Inhaltsverzeichnis

1. Einleitung

2. Multidatenbank-Architektur

3. Multidatenbanksprachen
3.1 Allgemein
3.2 MSQL

4. SchemaSQL
4.1 Allgemeine Einfuhrung
4.2 SchemaSQL - Eine Erweiterung zum SQL-Standard
4.3 Aufbau von SchemaSQL-Anweisungen
4.4 Sichten in SchemaSQL

5. Implementation Architecture von Lakshmanan
5.1 Lakshmanan Architektur
5.2 Lakshmanan Algorithmus
5.3 Abfrage-Optimierung
5.4 Redundanz und Inkonsistenz

6. Schlusswort

II Abkurzungsverzeichnis

III Literaturverzeichnis

IV Abbildungsverzeichnis

1. Einleitung

Die vorliegende Hausarbeit soil einen Einblick in die Multidatenbanksprache SchemaSQL geben. Dabei wird ein gewisses Vorwissen zu Datenbanksystemen, insbesondere zu foderierten Datenbanksystemen, sowie SQL-Kenntnisse vorausgesetzt. Zunachst wird ein Einblick in die Multidatenbank-Architektur gegeben und die Notwendigkeit von Multidatenbanksprachen herausgestellt. Da es neben SchemaSQL auch noch MSQL, eine etwas altere Form von Multidatenbanksprachen gibt, wird auch diese kurz beschrieben. Der Hauptteil dieser Arbeit setzt sich dann mit SchemaSQL auseinander, einer Erweiterung von SQL zur Verarbeitung von Informationen aus Multidatenbanksystemen. SchemaSQL wurde 1996 durch den indischen Wissenschaftler Laks Lakshmanan entwickelt. Im letzten Gliederungspunkt wird auch auf die SchemaSQL - Implementierungs - Architektur und den zugrunde liegenden Algorithmus, ebenfalls von Lakshmanan entwickelt, eingegangen.

2. Multidatenbank-Architektur

Unter einem Multidatenbanksystem versteht man den Verbund eines oder mehrerer DBS. Dabei unterscheidet man foderierte und nicht foderierte DBS. Eine von mehreren Architekturformen foderierter DBS ist die Multidatenbank-Architektur nach Litwin (siehe Abb.1).

Die Hauptidee hinter der Multidatenbank-Architektur steckt darin, dass ein Benutzer auf eine Foderation zugreifen kann, ohne dass ein globales Schema existiert. Er muss also direkt, mittels einer speziellen Multidatenbanksprache auf verschiedene Komponenten zugreifen konnen. Allerdings muss der Benutzer sich auch um die Integration der Komponentendatenbanksysteme und die Auflosung der Konflikte (semantische Heterogenitat) kummern. Diese Architektur ist in Abb. 1 skizziert. [LR99]

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1 : Multidatenbank-Architektur nach Litwin [LR99]

Auch bei der Multidatenbank-Architektur existieren mehrere Schemata, auf die wir im Folgenden naher eingehen werden:

- Physisches Schema - Jede an der Multidatenbank beteiligte lokale Datenbank hat ein physisches Schema, das die interne (physische) Struktur der von dem Komponentensystem verwalteten Daten beschreibt. Dies entspricht dem internen Schema der ANSI/SPARC Architektur.
- Internes logisches Schema - entspricht dem konzeptionellen Schema der ANSI/SPARC Architektur
- Konzeptionelles Schema - beschreibt den Ausschnitt aus den Daten, der an die Federation weitergegeben wird (wie das Export- Schema bei der Import/Export bzw. das externe Schema bei der ANSI/SPARC Architektur). Allerdings wird verlangt, dass das konzeptionelle Schema in der gesamten Multidatenbank dasselbe Datenmodell und dieselbe Anfragesprache verwendet. Entspricht das konzeptionelle Schema dem internen logischen Schema, werden also alle Daten an die Federation weitergegeben, so entfallt das letztere. Ist dem nicht so, entspricht das konzeptionelle Schema dem externen Schema bei der ANSI/SPARC Architektur.
- Externes Schema - kann sich jeder Benutzer selbst zusammenstellen. Dabei integriert er mehrere konzeptionelle Schemata in ein externes Schema und greift anschlieRend auf dieses Schema wie auf eine zentralisierte Datenbank zu. Die externen Schemata dienen also nicht der Zugriffskontrolle, wie das bei der ANSI/SPARC Architektur der Fall ist. AuRerdem kann der Benutzer direkt auf die konzeptionelle n Schemata zugreifen (z.B. fur eine einmalige Anfrage). In beiden Fallen muss er sich selbst um die Integration der Komponentendatenbanksysteme kummern.
- Abhangigkeitsschema - beschreibt Interdatenbankabhangigkeiten, also Komponentenubergreifende Integritatsbedingungen, Sicherung der Konsistenz der redundanten Datenbestande etc. Ebenfalls konnen durch die Abhangigkeitsschemata neue Integritatsbedingungen eingefuhrt werden. Ihre Einhaltung soll dann durch das Multidatenbanksystem garantiert werden (obwohl unklar ist, wie die allgemeine Losung aussieht).

Die gesamten Schemata konnen in drei Ebenen eingeordnet werden: die externe Ebene mit den externen Schemata der Benutzer, die konzeptionelle Multidatenbankebene, die aus den konzeptionellen und den Abhangigkeitsschemata besteht, und die interne Ebene, der die physischen und die internen logischen Schemata zugewiesen werden. Die Multidatenbanksprachen, die fur Anfragen an ein solches System bereitgestellt werden mussen, werden im folgenden Abschnitt erlautert. [LR99]

3. Multidatenbanksprachen

3.1 Uberblick

Die Aufgabe eines Datenbanksystems besteht unter anderem in der Gewahrleistung der Lese/Schreib-Zugriffe der Benutzer. Ein foderiertes DB-System gewahrleistet die Zugriffe auf seine Komponentendatenbanksysteme. Das Problem dabei ist, dass die herkommlichen Datenanfragesprachen keine Konstrukte zur Unterstutzung dieser Zugriffe enthalten. Wahrend bei einem foderierten DBS, mit einem foderierten bzw. globalen Schema, der Benutzer uber die externen Schemata auf den Foderierungsdienst zugreift, und die Integration vor ihm verborgen bleibt, muss er sich bei einer Architektur, wie der Multidatenbank-Architektur, selbst darum kummern. Folglich brauchen die auf dieser Architektur basierenden foderierten DBS eine spezielle Abfragesprache, die den Zugriff auf mehrere Komponentendatenbanksysteme bezeichnet. Vertreter dieser Sprachen sind MSQL und SchemaSQL. [LR99]

3.2 MSQL

Die Sprache MSQL ist fur das Multidatenbanksystem MRDSM entwickelt worden. In diesem werden verschiedene relationale DBS lose gekoppelt. Da relationale DBS alle „SQL“ sprechen, wird auf der Multidatenbankebene eine Sprache benotigt, die neben SQL noch bestimmte Funktionalitaten unterstutzt, die fur den Zugriff auf unterschiedlichen DBS erforderlich sind. Sie muss dem Benutzer ermoglichen, Mengen von Komponentendatenbanken zu definieren und diese in einer nicht prozeduralen Weise zu manipulieren. Ein Schritt in diese Richtung ist die Einfuhrung von Datenbanknamen in Anfragen. Das wird durch SQL nicht unterstutzt. AuRerdem besitzt MSQL folgende, durch SQL nicht abgedeckte Features:

- Mehrere Komponentendatenbanken konnen zu einer explizit benannten Multidatenbank zusammengefasst werden, die dann der Wirkungsbereich der Multidatenbankanfragen ist
- Innerhalb der Multidatenbank konnen bestimmte Datendefinitionsfunktionen angewandt werden. Dadurch ist es moglich bestehende Relationen innerhalb der DB zu modifizieren oder neue Relationen zu bestellen.
- Durch die Definition von Einheiten und die Genauigkeit von Datenwerten fur die Komponenten-DBS, kann eine automatische Konvertierung der heterogenen Werte erreicht werden.
- Es sind die so genannten multiplen Anfragen moglich. Diese Anfragen werden auf einer Menge von Relationen ausgefuhrt, und zwar so, dass der enthaltene SQL-Teil auf jeder Relation der Menge ausgefuhrt wird. Dabei mussen die einzelnen Relationen nicht einmal komplett ubereinstimmen. Eine Gbereinstimmung in dem von der Anfrage betroffenen Teil der Relation ist ausreichend.
- Die zusatzlichen eingebauten Funktionen erleichtern die Arbeit mit einer Multidatenbank, z.B. kann man mit Hilfe dieser Funktionen die Daten als Meta Daten (also Schema) ansprechen.
- MSQL bietet besondere Views auch Multidatenbanksichtdefinition genannt. Dies sind Relationen, die von mehreren Datenbanken abgeleitet werden und zu einer Datenbank gehoren.
- MSQL bietet spezielle Konstrukte zur Spezifikation und Gberwachung globaler Integritatsbedingungen.

Laut Litwin sind das die Mindestanforderungen an eine Multidatenbanksprache, wobei zu beachten ist, das Litwin auch der Erfinder von MSQL ist. Eine zweite Sprache, welche eine sehr neue und moderne Entwicklung darstellt, ist das SchemaSQL, das Hauptthema dieser Arbeit, welches im folgenden Kapitel ausfuhrlich erlautert wird. Ruckblickend auf die beiden Sprachen bleibt zu betonen, dass ein direkter Vergleich der beiden Sprachen nicht unbedingt fair ware, da das SchemaSQL ein Jahrzehnt junger als das MSQL ist, und vielmehr als Nachfolger von MSQL anzusehen ist, der sehr von der Kritik an MSQL profitiert hat. Beide Sprachen basieren auf SQL und sind abwartskompatibel, wobei das SchemaSQL eindeutig machtiger als SQL ist. Die breite Akzeptanz von SQL auf dem Gebiet der Datenbanksysteme hat dazu gefuhrt, dass heute die meisten Multidatenbanksprachen von SQL abstammen. [LR99]

4. SchemaSQL

4.1 Allgemeine Einfuhrung

Aus den im vorherigen Kapitel (3.1) geschilderten Problemen, resultierten Bemuhungen eine Anfragesprache zu entwickeln, die in der Lage ist Anfragen zu formulieren, die auf Daten in verschiedenen Datenbanken, mit verschiedenen Relationenschemata, etc. zugreift, und die entsprechenden Anfrageergebnisse zuruckliefert. Die bisherigen Versionen von SQL schienen dafur denkbar ungeeignet, da Konstrukte fehlten, die den Zugriff auf in einem foderierten Datenbanksystem enthaltene, Komponentendatenbanksysteme, gewahrleisten konnten. Verschiedene Bemuhungen fuhrten 1996 zur Entwicklung von SchemaSQL, durch Laks Laksmanan einem Wissenschaftler der Universitat von Bombay/Indien. Mit SchemaSQL ist es moglich Daten aus verschiedenen Datenbanken einer Foderation anzufragen, die zwar semantisch identisch, syntaktisch aber unterschiedlich aufgebaut sind. Die wichtigsten Anforderungen die an eine Multidatenbanksprache gestellt werden erfullt SchemaSQL. Eine solche Sprache muss in der Lage sein, unabhangig vom Schema nach dem die Datenbank strukturiert ist, Anfragen auf dieser auszufuhren. Das heiRt Anfragen wie „Finde alle Namen“, mussen auch abfragbar bleiben, wenn sich die Struktur der zugrunde liegenden Datenbank bzw. Relation andert. Des Weiteren muss die Sprache die vollen Moglichkeiten zur Datenmanipulation und - definition, wie sie auch Standard-SQL anbietet, bereitstellen. Schlussendlich mussen Anfragen effizient und effektiv formulierbar und ausfuhrbar sein. [LL96]

4.2 SchemaSQL - Eine Erweiterung zum SQL-Standard

SchemaSQL wird grundsatzlich als Erweiterung zu SQL angesehen. Es bietet einige Gemeinsamkeiten, sowie einige Unterschiede auf die wir nun im Detail etwas genauer eingehen werden. Um die Erklarungen etwas zu veranschaulichen, mochten wir alle praktischen Obungen in dieser Arbeit an einem ausgewahlten Beispiel demonstrieren. Das Beispiel besteht aus vier Datenbank, in denen jeweils die Preise fur Benzin und Diesel der Tankstellenketten Aral und Shell, in den Stadten Hamburg, Berlin, Munchen und Dortmund hinterlegt sind. Die Datenbanknamen sind gleich der Stadtenamen der Daten die in ihnen gespeichert sind. (siehe Abb. 2)

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2: Aufbau verschiedener Datenbanken einer Federation (alle folgenden Beispiele beziehen sich darauf)

Wie unschwer zu erkennen ist, sind in alien Datenbanken identische Informationen hinterlegt, jede Datenbank ist aber unterschiedlich aufgebaut.

Allgemein lasst sich sagen, dass SchemaSQL Standard SQL erweitert. Es bietet somit alle Funktionalitaten, die auch im „einfachen“ SQL vorhanden sind. Alle Anfragen welche in einem SQL Standard formuliert sind, lassen sich so auch in SchemaSQL umformen.

Wo setzen nun aber die Erweiterungen von SchemaSQL an? In Standard SQL lassen sich in einer Anfrage Variablen deklarieren. Die Deklaration erfolgt im „From - Block“ der Anweisung, und erzeugt eine Variable die als Wertebereich alle Tupel der zugrunde liegenden Relation enthalt. Deshalb werden diese Variablen auch als Tupe-Variablen bezeichnet. Auf Basis der Datenbank „Berlin“, wurde eine Anfrage die alle Preise aus der Relation „PreisInfo“ extrahieren soll, die niedriger als 1 Euro sind, folgendermaRen aufgebaut sein:

[...]

Details

Seiten
23
Jahr
2002
ISBN (eBook)
9783638151641
ISBN (Buch)
9783638697408
Dateigröße
506 KB
Sprache
Deutsch
Katalognummer
v8088
Institution / Hochschule
Hochschule Harz - Hochschule für angewandte Wissenschaften (FH) – FB Wirtschaftswissenschaften
Note
1,3
Schlagworte
SchemaSQL Erweiterung Verarbeitung Informationen Multidatenbanksymenste Föderierte Geografische Informationssysteme

Autoren

Zurück

Titel: SchemaSQL - eine Erweiterung von SQL zur Verarbeitung von Informationen aus Multidatenbanksymenste