5 Schemadefinition in objektrelationalen Datenbanksystemen

Transkript

1 75 5 Schemadefinition in objektrelationalen Datenbanksystemen In diesem Kapitel wird die Definition objektrelationaler Schemata am Beispiel von DB2 konkretisiert. Zu diesem Zweck wird zunächst das DBMS DB2 kurz vorgestellt. Für die Beschreibung objektrelationaler Erweiterungen beziehen wir uns auf das vorherige Kapitel. Objektrelationale Konzepte werden nur dann ausführlich erklärt, wenn sie in DB2 stark von SQL:99 abweichen oder dort nicht definiert sind. Für die meisten Konzepte werden sowohl ihre Syntax in DB2 als auch Beispiele präsentiert. In diesem Kapitel wird lediglich die Schemadefinition eingeführt. Da die Implementierung von Methoden, Funktionen und Prozeduren etc. Anfrage- und Änderungsoperationen verwenden, wird die Implementierung des benutzerdefinierten Verhaltens in Kapitel 7 nach der Behandlung der Datenmanipulation in Kapitel 6 diskutiert. 5.1 DB2 Im Rest des objektrelationalen Teiles wird DB2 als Beispielsystem verwendet und soll deshalb hier eingeführt werden. DB2 Universal Database (DB2 UDB, im folgenden auch einfach»db2«genannt) ist das objektrelationale Datenbanksystem von IBM. DB2 läuft auf einer Vielzahl von Hardware-Plattformen und Betriebssystemen. DB2 UDB»an sich«existiert nicht; vielmehr bietet IBM eine Reihe unterschiedlicher»editionen«für verschiedenste Einsatzzwecke (und Geldbeutel) an: Die Personal Edition erlaubt die Definition mehrerer Datenbasen und Schemata, sie ist aber beschränkt auf einen einzelnen, lokalen Benutzer (diese Version ist auf der CD enthalten). Die Workgroup Edition erlaubt zusätzlich mehrere Benutzer und den entfernten (remote) Zugriff auf lokale Datenbanken. Der Zugriff aus dem Datenbanksystem auf entfernte Datenbanken ist jedoch nicht möglich. Die Enterprise Edition kennt diese Einschränkungen nicht: Lokale und entfernte Benutzer können auf lokale und entfernte Datenbanken zugreifen. Die Anzahl der Benutzer, die gleichzeitig mit dem DB2-Editionen

2 76 5 Schemadefinition in objektrelationalen Datenbanksystemen System arbeiten können, ist höher als in der Workgroup Edition. Sofern vorhanden, kann die Enterprise Edition mehrere Prozessoren eines Rechners für die parallele Verarbeitung von Anfragen ausnutzen. Die Enterprise-extended Edition schließlich geht darüber hinaus, indem sie weitere Parallelisierungskonzepte ausnutzt. So können hier Daten auf mehrere Rechner verteilt und die gesamte Rechenleistung bei der Anfrageausführung ausgenützt werden. Alle Beispiele und Musterlösungen des objektrelationalen Teiles wurden unter einer Enterprise Edition für Sun Solaris entwickelt. Prinzipiell sind sie jedoch auch unter anderen Editionen (z.b. Personal Edition) und/oder Betriebssystemen (Windows, Linux) lauffähig Datenbank- und Schemaarchitektur DB2-Systeme DB2-Instanzen DB2-Datenbanken DB2-Schemata DB2-Datenbanksysteme sind durch eine mehrstufige Organisation gekennzeichnet (s. Abb. 5 1). Ein System entspricht einer DB2-Installation auf typischerweise einem einzelnen Rechner. Für ein System können eine oder mehrere (Datenbank-)Instanzen erzeugt werden. Eine Instanz besteht wiederum aus Datenbanken. Die verschiedenen Aufgaben einer Instanz werden durch unterschiedliche Benutzer wahrgenommen, die bei der Erzeugung einer Instanz mitgeneriert werden, sofern sie nicht schon existieren. Insbesondere wird die Instanz auf Betriebssystemebene durch einen neuen Benutzer repräsentiert. Dieser Benutzer ist autorisiert, Server-Prozesse zu starten und anzuhalten und sonstige Verwaltungsaufgaben durchzuführen. In einer Instanz können beliebig viele Datenbanken erzeugt werden. Dies ist mit dem Befehl create database oder mit einem der graphischen Werkzeuge möglich. Datenbanken gehören einem Benutzer, dieser kann bei der Erzeugung der Datenbank angegeben werden. Ohne diese Angabe gehört eine Datenbank dem Benutzer, der sie erzeugt (d.h. das Kommando create database ausgeführt) hat. Der Datenbankeigner besitzt automatisch die Privilegien eines Datenbankadministrators. Sollen Datenbanken weiter strukturiert werden, so können Schemata definiert werden. Schemata sind in DB2 Gruppierungen logisch zusammengehöriger Definitionen (d.h. Tabellen etc.). Sie können implizit von DB2 oder explizit durch Benutzer erzeugt werden. Bei der expliziten Schemadefinition wird ein Schema mit Hilfe der Anweisung create schema angelegt. Hierbei kann ebenfalls angegeben werden, welcher Benutzer der Besitzer des Schemas ist. Ohne weitere Angaben gehört das neue Schema dem Benutzer, der es erzeugt.

3 5.1 DB2 77 System Abb. 5 1 Aufbau von DB2- Datenbanksystemen Instanzen Datenbanken Schemata create type... create table... create type... create table... create type... create table... Tabellen Schemata können auch implizit erzeugt werden. In diesem Fall legt DB2 selbständig ein neues Schema an, sobald in einer DDL-Anweisung der Name eines Schemas verwendet wird, welches noch nicht existiert. Auf der untersten Ebene der Datenbank- und Schemaarchitektur befinden sich schließlich die eigentlichen Daten in Tabellen. Den Tabellen und allen anderen Schemaelementen wird dabei ein zweistufiger Name verliehen, der dafür sorgt, daß alle Definitionen nicht nur innerhalb eines Schemas, sondern auch innerhalb der gesamten Datenbank eindeutig sind. Der erste Teil des zweistufigen Namens identifiziert das Schema, in dem das Schemaelement definiert wurde. Der zweite Teil ist der bei der Erzeugung des Schemaelementes angegebene Name. Wird in Datenbankbefehlen kein Schemaname angegeben, sondern nur ein einstufiger Name, so setzt DB2 automatisch einen Schemanamen ein. Um effektiv in DB2 Schemaelemente zu definieren und Daten abzufragen oder zu ändern, muß zuvor eine Verbindung zu einer Datenbank eröffnet werden (mittels connect to...). Für jede solche Verbindung verwaltet DB2 eine Reihe von Systemregistern (z.b. USER, SCHEMA, PATH Implizite Schemaerzeugung Zweistufige Namen in DB2 Verbindungen

4 78 5 Schemadefinition in objektrelationalen Datenbanksystemen Systemregister etc.). Das Register USER enthält den Namen des aktuellen Benutzers. SCHEMA bezeichnet den Schemanamen, mit dem der Benutzer arbeitet. Der Wert dieses Registers wird von DB2 verwendet, um zweistufige Namen zu bilden. Ist dieses Register nicht initialisiert, wird der Wert des USER-Registers verwendet. Das Register PATH schließlich enthält Namen von Schemata, in denen DB2 die Definition von Funktionen und Methoden sucht Schnittstellen und Werkzeuge DB2 bietet für die Datenbankadministration eine Reihe von Schnittstellen und Werkzeugen. Unter den interaktiven Schnittstellen sind hier insbesondere die zeilenorientierte und textbasierte Schnittstelle (Command Line Processor, CLP) und der Control Center zu nennen. Letzterer bietet eine graphische Benutzerschnittstelle und eine Reihe von Werkzeugen für die Verwaltung von und den Zugriff auf Instanzen und Datenbanken. Interaktive Anfragen können ebenfalls mit dem CLP oder einem Element des Control Center, dem Command Center, formuliert werden. Die folgenden Beispiele sind mit beiden Varianten lauffähig. Verwaltungs- und Administrationsaufgaben wie die Erzeugung von Datenbanken können durch spezielle Programme auf Betriebssystemebene erledigt werden, interaktiv im CLP oder über entsprechende Teile des Control Center. Schließlich unterstützt DB2 eine Reihe von Programmierschnittstellen wie z.b. CLI (Call Level Interface) und Sprachanbindungen (für Java, C/ C++, Cobol etc.). Die folgenden zwei Beispielsitzungen illustrieren den Gebrauch des CLP, den Verbindungsaufbau, die Erzeugung von Schemata und Datenbanken sowie die Verwendung des SCHEMA-Registers. Beispielsitzung im Command Line Processor von DB2 Erzeugung einer Datenbank Verbindungsaufbau Erzeugung eines Schemas unix> db2 (c) Copyright IBM Corporation 1993,2001 Command Line Processor for DB2 SDK db2 => create database moviedb DB20000I The CREATE DATABASE command completed successfully. db2 => connect to moviedb Database Connection Information Database server = DB2/SUN SQL authorization ID = GEPPERT Local database alias = MOVIEDB... db2 => create schema moviesschema db2 => set schema moviesschema

5 5.1 DB2 79 db2 => create table movies (title varchar(40), date date) db2 => insert into movies values ( Casablanca, 07/07/2001 ) db2 => terminate DB20000I The TERMINATE command completed successfully. Tabellendefinition Verbindungsabbau unix> db2 (c) Copyright IBM Corporation 1993,2001 Command Line Processor for DB2 SDK db2 => connect to moviedb... db2 => select * from moviesschema.movies TITLE DATE Casablanca 07/07/ record(s) selected. db2 => set schema moviesschema db2 => select * from movies TITLE DATE Casablanca 07/07/ record(s) selected. db2 => Weitere Funktionen in DB2 Wir werden uns im folgenden hauptsächlich auf die (objekt)relationalen Konzepte von DB2 konzentrieren. DB2 unterstützt darüber hinaus noch eine extensive Sammlung von Funktionen, wie z.b. Werkzeuge und Konzepte für Data Warehousing und Business Intelligence, föderierte Datenbanksystemfunktionalität (Zugriff auf Daten in anderen Datenbanksystemen wie z.b. Oracle und Sybase), parallele Abarbeitung von Anfragen sowie Erweiterungsmöglichkeiten für spezielle Anforderungen wie Verwaltung geographischer oder Multimediadaten. Weitere Funktionsbereiche in DB2

6 80 5 Schemadefinition in objektrelationalen Datenbanksystemen Diese Konzepte werden hier aus verschiedenen Gründen nicht diskutiert. Zum einen würde ihre Behandlung den Rahmen dieses Buches bei weitem sprengen. Zweitens sind einige dieser Funktionen z.b. im Bereich Data Warehousing noch nicht allzu gut mit den objektrelationalen Konzepten integriert. Drittens sind die»effekte«und Vorzüge zum Beispiel hinsichtlich paralleler Anfrageverarbeitung nur bei sehr großen Datenmengen, die normalerweise das für praktische Übungen vertretbare Volumen übersteigen, überhaupt erfahrbar. Schließlich würde eine praktische Erprobung dieser Konzepte zahlreiche weitere Hard- und Software-Abhängigkeiten implizieren (z.b. ein Mehrprozessorsystem für die parallele Anfrageverarbeitung, Installation weiterer, nicht aus dem Hause IBM stammender Systeme für föderierte Datenbankkonzepte). 5.2 Schemaentwurf in DB2: Überblick Abbildung von Klassen Abbildung von Typen und Strukturen Abbildung des Verhaltens In diesem Abschnitt soll zunächst diskutiert werden, wann welche objektrelationalen Konstrukte beim logischen Datenbankentwurf eingesetzt werden können bzw. sollen. Wir gehen davon aus, daß ein konzeptueller Entwurf z.b. in UML bereits vorliegt. Mögliche Umsetzungsregeln sind dann die in Tabelle 5 1 wiedergegebenen. Diese Transformationen sind als Richtlinien gemeint; in vielen Fällen können einzelne Transformationen z.b. aufgrund fehlender Unterstützung durch das verwendete DBMS nicht durchgeführt werden. Klassen werden in der Regel in UDTs umgesetzt. Für jeden instantiierbaren UDT wird außerdem eine typisierte Tabelle definiert. Die Strukturdefinition der Klassen wird in entsprechende Attributdefinitionen der UDTs transformiert. Die Spezialisierungshierarchie des konzeptuellen Schemas wird direkt in die UDT- und Tabellenhierarchie abgebildet, sofern keine Mehrfachvererbung verwendet wurde. Im konzeptuellen Entwurf verwendete Typen (Basistypen wie String oder integer oder Strukturen) werden sofern vorhanden auf vordefinierte Basistypen des objektrelationalen Systems abgebildet. Ist kein adäquater Basistyp vordefiniert und läßt sich der Typ auf einen vorhandenen zurückführen, so kann ein adäquater Distinct Type im logischen Schema definiert werden. Schließlich können für komplexe Typen bzw. Hilfsklassen des konzeptuellen Schemas UDTs im logischen Schema spezifiziert werden. Klassenspezifisches Verhalten (d.h. Methoden der konzeptuellen Klassen) werden zu Methoden der entsprechenden UDTs. Klassenunabhängiges Verhalten wird im logischen Schema durch Funktionen oder Prozeduren implementiert.