SQL:2003 aus objektrelationaler Sicht

Inhaltsverzeichnis

1 Einführung

2 Umsetzung objektrelationaler Konzepte in SQL:2003
2.1 Typkonstruktoren und Typhierarchien
2.2 Benutzerdefinierte Datentypen
2.3 Methoden
2.4 Tupeltabellen
2.5 Typisierte Tabellen und Tabellenhierarchien
2.6 Typisierte Sichten und Sichtenhierarchien

3 Microsoft SQL Server 2005 und SQL:2003

4 Zusammenfassung und Fazit

1 Einführung

Objektrelationale Datenbanksysteme erweitern relationale Ansätze um Konzepte der Ob- jektorientierung. Dadurch wird es ermöglicht, dass die aus relationalen Datenbanksyste- men bekannte effiziente und fehlertolerante Verwaltung von Daten im Mehrbenutzerbe- trieb erhalten bleibt. Die Kombination mit objektorientierten Ansätzen, wie Objekttypen, Typvererbung, Objekttabellen und Tabellenhierarchien hat das Ziel eine bessere Unter- stützung der Anwendungssemantik durch das Datenbanksystem hervorzurufen und die Datenbankmodellierung und -entwicklung intuitiver zu gestalten (Vgl. [Gep02, S.1, Tür03, S.V, Tür06, S.V],).

Das relationale Modell und SQL wurden in den siebziger Jahren entwickelt. Die daraus ab- geleiteten relationalen Datenbankverwaltungssysteme gewannen in den achtziger Jahren einen großen Marktanteil und finden bis heute einen verbreiteten Einsatz in Firmen. Pa- rallel zur Ausbreitung der relationalen Datenbankverwaltungssysteme entstand in der Programmiertechnik das Konzept der Objektorientierung, durch die eine umweltnähere Modellierung von Sachverhalten ermöglicht wurde. Die wesentlichen Ansätze, die dabei eine wichtige Rolle spielen sind Vererbung und Verhalten als Eigenschaften von Objekten und ihren Typen. Durch objektorientierte Programmiersprachen wie C++ und Java ist ein direkter Übergang vom objektorientierten Entwurf in die Implementierung möglich (Vgl. [Gep02, S.1]).

Die Verknüpfung von objektorientierten Anwendungen mit relationalen Datenbanken führte zu der Erkenntnis, dass das relationale Modell, bei dem alle zu modellierenden Sachverhalte durch Relationen repräsentiert werden, mit einigen Einschränkungen ver- bunden ist. Beispielsweise kann die Spezialisierung von Objekttypen nur durch primitivere Konstrukte in relationalen Datenbanken abgebildet werden. Das Verhalten von Umweltob- jekten kann nicht durch relationale Modelle repräsentiert werden (Vgl. [Gep02, S.1 f., Tür03, S.V, Tür06, S.V]).

In den 80er Jahren bildeten sich zwei Forschungsrichtungen heraus um den Impedance Mismatch¹zu reduzieren. Daraus resultierten die Konzepte der objektorientierten und der objektrelationalen Datenbanksysteme. Während die objektorientierten Datenbanksysteme völlig neue Datenbanksysteme mit objektorientierten Konzepten darstellten, entstanden die objektrelationalen Datenbanksysteme aus der Erweiterung und Weiterentwicklung von relationalen Datenbanksystemen mit Ansätzen der Objektorientierung (Vgl. [Gep02, S.2]).

Die objektrelationalen Konzepte wurden vom SQL-Standard aufgenommen. Standard-SQL gilt seit SQL:1999 als objektrelational. Der aktuelle Standard SQL:2003 erweitert SQL:1999 in Bezug auf Objektrelationalität um einige wenige Aspekte, wie aus einer viel zitierten Ver- öffentlichung von Andrew Eisenberg hervorgeht ([Eis04, S.1 ff.]). Allerdings kam durch die Anbindung von XML in SQL:2003 ein als bedeutend einzustufendes Konzept hinzu, da es von führenden DBMS-Herstellern, wie IBM, Oracle und auch Microsoft durchgängig aufge- griffen wurde.

Ziel dieser Ausarbeitung ist es, einen Überblick über die Umsetzung der wichtigsten ob- jektrelationalen Konzepten in SQL:2003 vorzustellen und deren Einschätzung in der aktu- ellen Standard-Literatur darzulegen. Zur Erklärung sollen in dieser Ausarbeitung grundle- gende Beschreibungen und kleinere Beispiele dienen. Für einen detaillierten Einblick in die objektrelationalen Konstrukte von Standard-SQL wird auf die Literatur [Gep02, Mel02, Pet03, Tür03, Tür06] verwiesen. Die komplette Definition von SQL:2003 ist in den 14 Teilen der Veröffentlichung „ISO International Standard: Database Language SQL“ von ANSI/ISO/IEC zu finden [ANS03a, ANS03b, ANS03c, ANS03d, ANS03e, renANS03f, ANS03g, ANS03h, ANS03i, ANS03j, ANS03k]. In Kapitel 3 wird zusätzlich die Umsetzung des aktuel- len SQL-Standards im SQL Server 2005 von Microsoft untersucht und die allgemeine Prob- lematik der Umsetzung des Standards in der Praxis thematisiert.

2 Umsetzung objektrelationaler Konzepte in SQL:2003

Objektrelationale Datenbanksysteme sind eine Erweiterung von relationalen Datenbanksystemen mit Konzepten, deren Ursprung in der Objektorientierung liegt. Mit der Objektorientierung in Datenbanksystemen werden die folgenden Vorteile verbunden: (Vgl. [Tür03, S.5, Tür06, S.11, Gep02, S.26])

- Verringerung des Impedance Mismatch
- Einfache Abbildung und Darstellung von komplexen Realweltobjekten
- Schnellere Entwicklung von Datenbankanwendungen
- Wiederverwendung von in der Datenbank gespeicherter Funktionalität
- Besseres Verständnis und einfachere Verwaltung und Anpassung komplexer An- wendungen
- Bessere Performance durch Kenntnis der inneren Struktur der Objekte durch das DBMS¹

Die Frage nach der Definition objektrelationaler Datenbanksysteme kann nicht eindeutig beantwort werden, da über eine allgemeingültige Abgrenzung Uneinigkeit herrscht (Vgl. [Tür06, S.11 f.]). Deswegen orientiert sich die aktuelle Literatur an den Konzepten des SQL- Standards, um den Begriff „Objektrelationalität“ einzugrenzen ([Gep02, S.55 ff., Tür03, S.4 ff., Tür06, S.11 ff.], [Bar05, S.2]). Diese direkte Verknüpfung mit dem SQL-Standard lässt einen höheren Abstraktionsgrad der Objektrelationalität kaum zu. Dennoch ist es Ziel die- ses Kapitels die Umsetzung im SQL-Standard kritisch zu betrachten. Es lassen sich die folgenden objektrelationalen Konzepte aus der aktuellen Standardliteratur ([Gep02, Tür03, Tür06,) ableiten:

- Typkonstruktoren
- benutzerdefnierte Datentypen - Typhierarchien
- Methoden
- Objektidentifikatoren und Referenzen, - typisierte Tabellen bzw. Objekttabellen - Tabellenhierarchien
- typisierte Sichten bzw. Objektsichten - Sichtenhierarchien

Im Folgenden werden die einzelnen Konzepte vorgestellt und Ihre Umsetzung in StandardSQL betrachtet und bewertet.

2.1 Typkonstruktoren und Typhierarchien

Jedes Datenmodell besitzt Basisdatentypen, die den elementaren Wertevorrat festlegen. Darauf aufbauend lassen sich mit Hilfe von Typkonstruktoren komplexe konstruierte Da- tentypen ableiten. Dabei sind Typkonstrukturen nicht veränderbare Basiskonstrukte in einem Datenmodell. Es wird in objektrelationalen Datenmodellen aktuell zwischen den folgenden verschiedenen Typkonstruktoren unterschieden: Tupeltypkonstruktor, Array- typkonstruktor, Multimengentypkonstruktor, Referenztypkonstruktor, Mengentyp- konstruktor, Listentypkonstruktor und Objekttypkonstruktor (Vgl. [Tür06, S.104]).

Tupeltypkonstruktoren¹werden seit SQL:1999 über den „ROW“-Konstruktor realisiert. Dieser ermöglicht die Abbildung strukturierter Attribute. Ein Tupeltypkonstruktor erzeugt einen komplexen Datentyp, den Tupeltyp, der eine feste Anzahl von Feldern beinhaltet. Jedes Feld des Tupeltyps besitzt einen Namen, sowie einen Basisdatentyp oder einen kon- struierten Datentyp². Die Konstruktion eines Tupeltyps kann mit der folgenden SQL- Syntax realisiert werden:

ROW(<Feldname> <Datentyp>, …, <Feldname> <Datentyp>) (Quelle: [Tür03, S.45])

Auf die Datentypen in einem Tupeltyp wird über den jeweiligen Feldnamen zugegriffen. Es lässt sich festhalten, dass die Tupeltypkonstruktoren in SQL:2003 durch ein klares und durchsichtiges Konzept umgesetzt werden. Damit wird die relationale Einschränkung aufgehoben, dass ein Attributwert nicht wiederum strukturiert sein kann.

Die mit SQL:1999 eingeführten Arraytypkonstruktoren dienen der Modellierung von homogenen Kollektionen¹mit einer vordefinierten Maximalkardinalität (Vgl. [Gep02, S.58]). Dazu definiert SQL:2003 die Typ-erzeugende Syntax wie folgt:

<Elementtyp> ARRAY[<Max-Kardinalität>] (Quelle: [Tür03, S.47])

Der Zugriff auf die Elemente des Arraytyps erfolgt über die Angabe der Position (Vgl. [Tür03, S.47]).

Durch die Arraytypen wird es ermöglicht mehrwertige Attribute direkt zu modellieren, ohne für die Kollektion eine eigene Relation zu bilden, wie es im relationalen Modell erforderlich ist. Die Schwäche dieser Umsetzung besteht darin, dass die Länge des Arraytyps bei seiner Deklaration beschränkt wird. Für Kollektionen unbekannter Länge eignet sich dieser Konstruktor folglich nicht. Diese Problematik wurde durch den erstmals in SQL:2003 umgesetzten Multimengentypkonstruktor umgangen.

Der Multimengentypkonstruktor erzeugt einen Multimengentyp:

<Elementtyp> MULTISET (Quelle: [Tür06, S. 149])

Mit Hilfe eines Multimengenkonstruktors lässt sich aus einem Multimengentyp eine Multimenge erzeugen:

SET <Bezeichnung der Multimenge> = MULTISET[<SQLAnfrage>|<Werteliste>] (Quelle: Tür06, S. 130)

Ein Multimengentyp unterscheidet sich von einem Arraytyp durch seine ungeordnete Struktur und seine flexible Größe. Multimengen sind demnach homogene ungeordnete Kollektionen. Jede Multimenge darf Duplikate enthalten.

Das Konzept der Multimengen in SQL:2003 ermöglicht die Durchführung mengenbasierter Operationen an Kollektionen und deckt eine große Lücke ab, die SQL:1999 offen gelassen hat (Vgl. [UN04, S.44]).

Ein weiterer kollektionsbasierter Typkonstruktor ist der Listentypkonstruktor, der in Standard-SQL bisher noch nicht umgesetzt wurde. Mit dem Arraytypkonstruktor können geordnete und größenbeschränkte Kollektionen modelliert werden, mit dem Multimen- gentypkonstruktor dagegen ungeordnete und nicht größenbeschränkte. Ein Listentyp- konstruktor definiert dagegen geordnete und nicht größenbeschränkte Kollektionen. Au- ßerdem kann mit einem Iterator auf die einzelnen Listenelemente zugegriffen werden (Vgl. [Tür06, S.49]). Die Umsetzung dieses Konzepts soll hier als Erwartungshaltung an zukünftige SQL-Standards gestellt werden.

Der Mengentypkonstruktor, der sich von dem Multimengentypkonstruktor darin unter- scheidet, dass keine Duplikate zugelassen werden, wurde ebenfalls nicht mit in SQL:2003 aufgenommen (Vgl. [Tür06, S.106]). Eine mögliches Motiv der Nichtberücksichtigung ist die Tatsache, dass die geforderte Funktionalität über den Multimengentypkonstruktor abgebildet werden kann, in dem manuelle Kontrollmechanismen gegen Duplikate einge setzt werden. Dennoch wird dadurch dem jeweiligen Datenbankprogrammierer Arbeit auferlegt, die mit einem Mengentypkonstruktor überflüssig wäre. Die zukünftige Umsetzung in Standard-SQL wäre demnach sinnvoll.

Als letztes soll in diesem Abschnitt der Referenztypkonstruktor erwähnt werden, der Referenztypen erzeugt und seit SQL:1999 in Standard-SQL existiert: (Vgl. Tür03, S.48)

REF(<Typname>) [SCOPE(<Tabellenname>)] (Quelle: [Tür03, S.48])

Dabei steht eine Referenz für einen Verweis auf eine Instanz des referenzierten Typs. Verweist der Referenztyp auf eine Zeile innerhalb einer typisierten Tabelle muss als SCOPE der Tabellenname der typisierten Tabelle angegeben werden (Vgl. [Tür03, S.48]). Die Referenzierung in Standard-SQL wird zusammen mit der Problematik der Objektidentifikation in Abschnitt 2.5 näher betrachtet.

Objekttypkonstruktoren werden in SQL:2003 über benutzerdefinierte Datentypen realisiert und daher im nächsten Abschnitt untersucht.

2.2 Benutzerdefinierte Datentypen

Benutzerdefinierte Datentypen erlauben die Definition von benannten Datentypen und werden mit den Vorteilen Erweiterbarkeit, Widerverwendbarkeit, Typisierung und Performance in Verbindung gebracht (Vgl. [Tür06, S.107]). Es wird zwischen zwei Arten benutzerdefinierter Datentypen unterschieden, den Distinct-Typen und den Strukturdatentypen (Vgl. [Tür06, S.107, Gep02, S.59]).

Distinct-Typen erlauben die Definition von Datentypen als Kopie bereits bestehender Da- tentypen mit einem neuen Namen. Die Instanzen zweier verschiedener Distinct-Typen sind nicht miteinander vergleichbar, auch wenn beiden Distinct-Typen der gleiche Quell- datentyp zu Grunde liegt. Die Instanzen zweier verschiedener Distinct-Typen können nur dann zu Vergleichen herangezogen werden, wenn entsprechende CASTS¹durchgeführt werden. Ein CAST in den entsprechenden Quelltyp ist immer möglich, aber ein CAST zwi- schen zwei verschiedenen DISTINCT-Typen muss manuell definiert werden (Vgl. [Tür06, S.108]).

Standard-SQL hat mit SQL:1999 das Konzept der Distinct-Typen aufgegriffen und in SQL:2003 unverändert fortgeführt:

CREATE TYPE <Distinct-Typname> AS <Quelltyp> FINAL (Quelle: [Tür03, S.50])

Dadurch wird es ermöglicht semantisch unzulässige Vergleiche und Zuweisungen zu ver- bieten (Strenge Typisierung, Vgl. [Tür06, S.13]). Beispielsweise kann so korrekterweise ein Distinct-Typ „Dollar“ nicht mit einem Distinct-Typ „Euro“ verglichen werden, obwohl sich beide auf den gleichen Quelldatentyp beziehen. Die Schwachstelle in SQL:2003 bildet die Einschränkung des Quelldatentyps auf Basisdatentypen (Vgl. [Tür03, S.50]). Es ist also nicht

[...]

¹ Die grundlegende Problematik des Impedance Mismatch entsteht durch die fehlende Abbildung von objektorientierten Strukturen auf das Datenmodell relationaler Datenbankmanagementsyste- me (RDBMS).

¹ Datenbankmanagementsystem

¹Tupeltypkonstruktoren werden oft auch als Zeilentypkonstruktoren bezeichnet

² Dieses Konzept ermöglicht die Verschachtelung von Datentypen

¹ Sammlung von Werten des gleichen Elementtyps

¹Typumwandlungen