DB2-Administration: Datenbankdefinition

Die Datenhaltung, -verarbeitung und -auswertung haben einen Stellenwert erreicht, der früher undenkbar war. Selbst ein großes Unternehmen kam vor etwa 30 Jahren noch problemlos damit aus, Daten in Papierform zu erfassen, zu verwalten und auszuwerten. Dies ist heute in den Industrienationen nicht einmal mehr für eine Privatperson realisierbar. Die Datenflut - verursacht durch Bilder, digitale Video-Filme, Adressen, Telefonnummern, Geldanlagen, Steuererklärungen, Preisauskünfte über das Internet und nicht zuletzt E-Mails - markiert dabei lediglich den Beginn der Auswirkungen der "Elektronisierung" unserer Umwelt. Ein Blick auf die Art und Weise, wie heute die immer größer werdenden Datenmengen verwaltet und ausgewertet werden, lässt jedoch erkennen, dass genau bei dieser Aufgabe noch Pionierarbeit geleistet werden muss. Viele große Unternehmen sind deshalb in den letzten Jahren dazu übergegangen, relationale Datenbanksysteme einzusetzen. Doch es nützt nichts, sich einen Jumbojet zu kaufen, wenn man ihn dazu einsetzt, kurz um die Ecke zu fliegen, um Brötchen zu kaufen.

Damit wollen wir Folgendes sagen: Allein der Einsatz eines relationalen Datenbanksystems führt nicht zwangsweise zum gewünschten Erfolg. Denn je komplexer und mächtiger ein System ist, umso höher werden die Anforderungen an den Nutzer dieses Systems. Um auf den Jumbo zurückzukommen: Wer traut sich zu, einfach per "Learning by Doing" einen Jumbojet zu fliegen, oder wer möchte bei so einem Piloten Passagier sein?

Mit unserer neuen dreiteiligen Artikelreihe bieten wir Ihnen eine Einführung in die DB2-Administration.

• Der erste Teil befasst sich mit den Grundlagen der Datenbank. Neben einem Einblick in die Historie und die Codd'schen Regeln erfahren Sie mehr über die Aufgaben des Modellierers, des Programmierers, des Administrators und des Endbenutzers.

• externer Link Teil zwei beantwortet die Frage "Was ist eigentlich eine Datenbank?". In diesem Kapitel geht es um die Definition der Datenbank an sich sowie um die enthaltenen Objekte.

• externer Link Im dritten Kapitel behandeln wir die unterschiedlichen Einsatzgebiete der Datenbank. Neben dem Einsatz in homogenen Netzwerkumgebungen beleuchten wir auch den heterogenen Betrieb sowie die Einzelplatzvariante.

Unsere Artikelserie ist dem ersten Kapitel des Buches "DB2 Administration - Einführung, Handbuch und Referenz" von Jens Orhanovic, Ivo Grodtke und Michael Tiefenbacher entnommen. Erschienen ist das 640 Seiten umfassende Werk im Verlag Addison-Wesley. Sie können das komplette Buch in unserem Buchshop bestellen oder als eBook beziehen.

Serie: DB2-Administration

Teil 1	Datenbankgrundlagen
Teil 2	Definition einer Datenbank
Teil 3	Unterschiedliche Einsatzgebiete

Was ist eigentlich eine Datenbank?

Nachdem wir uns im vorigen Abschnitt mit der Historie, der Nutzung und den verschiedenen Benutzergruppen ganz allgemein befasst haben, wollen wir uns ab jetzt speziell mit der DB2 UDB Version 8 beschäftigen.

In der Literatur finden wir die unterschiedlichsten - und teilweise hoch wissenschaftlichen - Definitionen. Die Anforderungen, die eine relationale Datenbank erfüllen muss, werden ja in den Codd'schen Regeln beschrieben. Alle Anforderungen, die an ein RDBMS gestellt werden, sind uns zwar dann bekannt, doch es bleibt immer noch folgende Frage offen:

Was ist nun tatsächlich eine relationale Datenbank (RDB), und was ist der Unterschied zu dem relationalen Datenbankmanagementsystem (RDBMS)?

Definition einer Datenbank

Wenn wir im Brockhaus nachschlagen, finden wir folgende Beschreibung:

Eine Datenbank ist ein zentral verwaltetes System zur widerspruchsfreien und permanenten Speicherung von umfangreichen Datenmengen, auf die nach unterschiedlichen Anwendungskriterien zugegriffen werden kann. Es besteht aus der Datenbasis, in der die Daten abgelegt werden, und dem Datenbank-Managementsystem, einem Software-Paket, das insbesondere die Datenbestände und Zugriffsrechte verwaltet.

Reicht uns diese Erklärung aus, um zu verstehen, was eine relationale Datenbank beziehungsweise ein relationales Datenbankmanagementsystem ist?

Wir sind der Meinung, dass sich hinter diesen beiden Begriffen viel mehr verbirgt, als in dieser kurzen Beschreibung ausgedrückt werden kann. Wir bezeichnen eine Datenbank als ein logisches Objekt, das unter anderem Daten, Programmlogik und viele weitere logische Objekte beinhaltet.

Das Datenbankmanagementsystem ist das Programmsystem, das das logische Objekt "die Datenbank" betriebssystemunabhängig verwaltet und dem Datenbankbenutzer auf einer logischen Ebene zur Verfügung stellt. Ebenso übernimmt das RDBMS die Umsetzung von der logischen auf die physische Ebene.

Ausführliche Beschreibung einer Datenbank

An dieser Stelle möchten wir unsere detaillierte Sicht etwas genauer vorstellen und diese anhand eines einfachen Schaubildes erklären. Dieses Schaubild zeigt verschiedene Komponenten und soll deren Aufgaben sowie deren Zusammenspiel im Gesamtsystem verdeutlichen. Diese Darstellung hat uns selbst und vielen Teilnehmern unserer Kurse geholfen, ein gewisses Grundverständnis zu erwerben. Somit schaffen wir hiermit eine wichtige Grundlage für das Arbeiten mit Datenbanken und Datenbankmanagementsystemen.

Diese Sicht passt zwar nicht hundertprozentig auf jedes RDBMS (Oracle, DB2 für z/OS, Informix, SQL Server usw.), kann aber bis auf kleine Unterschiede auch hier angewendet werden.

Komponenten des Schaubildes

• Benutzer

• CLP (command line processor)

• DBMS (Datenbankmanagementsystem)

• Datenbank (logisches Objekt)

• Objekte der Datenbank

• Betriebssystem

• API-Schnittstellen

• Plattensysteme beziehungsweise Dateien

Begriffserklärung der Komponenten

Benutzer

In diesem Schaubild möchte der Benutzer über die interaktive Schnittstelle SQL beziehungsweise Datenbankbefehle eingeben. Da Benutzerzugriffe über Programme und Tools nicht über den CLP (Command Line Prozessor) an das DBMS gesendet werden, betrachten wir hier nur die interaktive Schnittstelle über den CLP.

CLP

Der Command Line Prozessor wird benötigt, da das jeweilige Betriebssystem (Windows, Unix) weder die SQL-Syntax noch die Syntax der Datenbankbefehle verarbeiten kann. Der CLP ist also ein Programm, dem die entsprechenden SQL- oder Datenbankbefehle übergeben werden und das diese dann nach einer einfachen Syntaxprüfung an das DBMS weiterleitet.

Begriffserklärung DBMS

Das Datenbankmanagementsystem interpretiert die eingehenden Befehle (SQL- oder Datenbankbefehle) und führt diese aus, falls sie fehlerfrei sind. Da in SQL-Befehlen nur logische und keinerlei physische Objekte vorkommen, ist es die Aufgabe des DBMS zu erkennen, welche physischen Objekte angesprochen werden müssen, um den jeweiligen Befehl auszuführen. Somit bildet das DBMS die Schnittstelle zwischen der logischen Ebene (Datenbank) und der physischen Ebene (Betriebssystem). Da die logische Sicht auf die Datenbankobjekte völlig hardware-unabhängig ist, kann dieser Teil der Verarbeitungslogik gekapselt werden und bildet den Kern (Kernel) des DBMS.

Hierunter fallen Aufgaben wie zum Beispiel die Prüfung der SQL-Befehle, SQL-Optimierung sowie die Verwaltung und Zuordnung von logischen und physischen Objekten. Ebenso ist der Hardware-abhängige Teil der Verarbeitungslogik, wie Festplattenzugriffe, Zugriffe auf den Hauptspeicher et cetera, gekapselt. Diese Technik ermöglicht es, den eigentlichen und weitaus größeren Teil, der ein RDBMS ausmacht, völlig unabhängig von der Hardware zu betrachten. Dies war bei der DB2 UDB (Universal Data Base) für die dezentralen Plattformen nicht immer so. Erst ab der Version DB2 UDB V2.x bzw. DB2 UDB V5.x wurde diese Trennung durchgeführt. Dieser Schritt machte es IBM jedoch möglich, die bis dahin verschiedenen DB2-Produkte, die es für die dezentralen Plattformen gab (DB2 für OS/2, DB2 für AIX usw.), zu einem Produkt, der DB2 UDB, zu vereinen.

Heute ist ein Zustand erreicht, in dem sich die DB2 UDB auf allen dezentralen Plattformen aus reiner SQL-Sicht (hauptsächlich für Programmierer interessant) identisch und zu großen Teilen aus Sicht der Datenbankbefehle (betrifft hauptsächlich DB-Administratoren) bis auf ein paar Nuancen gleich verhält.

Dies gilt jedoch nicht für die Systeme AS/400 und z/OS (Mainframe). Diese Systeme besitzen bisher einen völlig anderen Datenbankkern (Kernel) für die logische Verarbeitung. Bei der AS/400 ist dieser Datenbankkern sogar völlig in das Betriebssystem OS/400 integriert.

IBM verwendet inzwischen den Begriff der DB2 UDB für alle Plattformen. Es ist IBM sogar gelungen, für die dezentralen Plattformen dieselbe Versionsnummerierung wie für z/OS zu verwenden und für beide Welten nahezu dieselben logischen Datenbankobjekte (zum Beispiel Trigger, stored procedures) zur Verfügung zu stellen. Dennoch ist es an dieser Stelle sehr leicht zu verstehen, dass sich diese verschiedenen DB2 UDB-Systeme nicht gleich verhalten können, solange der Datenbankkern nicht identisch ist.

Somit müssen sowohl der Programmierer und noch viel mehr der Administrator die Unterschiede zwischen den beiden Welten z/OS, AS/400, VM/VSE und den dezentralen Plattformen (Unix, Windows) beachten.

Die Komponente Datenbank

Die Datenbank kann als logisches Objekt betrachtet werden, das wiederum weitere logische Objekte wie benutzerdefinierte Tabellen, Indizes, Systemkatalogtabellen, Auslöser (Trigger), benutzerdefinierte Funktionen (user defined fuctions - UDF), gespeicherte Prozeduren (stored procedures - SPs), Berechtigungen enthält.

Da die Anzahl und das Vorhandensein der logischen Objekte innerhalb einer Datenbank vom Administrator frei definiert werden kann, muss diese Beschreibung der Objekte dem DBMS zu Verfügung gestellt werden. Dies geschieht in den Systemkatalogtabellen. Somit ist es verständlich, dass es pro möglichem Datenbankobjekttyp meistens mindestens eine Systemtabelle gibt.

Beispiele hierfür sind:

• SYSIBM.SYSTABLES - Hier finden Sie die Beschreibung aller Tabellen dieser Datenbank. Pro vorhandener Tabelle gibt es einen Eintrag.

• SYSIBM.SYSCOLUMNS - Hier finden Sie die Beschreibung (Name, Datentyp usw.) jeder Spalte der Tabellen dieser Datenbank. Pro Spalte gibt es ein Eintrag.

Dass für manche Datenbankobjekt-Typen unterschiedliche Systemtabellen zu Verfügung stehen, liegt einfach daran, dass diese Datenbankobjekte weitere Eigenschaften besitzen können, die dann in weiteren Systemtabellen beschrieben werden.

Die DB2 UDB für dezentrale Plattformen besitzt also pro Datenbank einen umfangreichen Satz von Systemtabellen, die die logische und teilweise die physische Struktur der Objekte beschreiben. Diese werden automatisch vom DBMS beim Anlegen einer Datenbank erzeugt und während des weiteren Betriebs automatisch vom DBMS bei entsprechenden Benutzeraktionen (zum Beispiel beim Anlegen einer neuen Tabelle und Runstats) aktualisiert und gepflegt.

Sie können vom Benutzer weder explizit erzeugt noch geändert oder gelöscht werden. Eine Ausnahme bilden die Systemtabellen auf den Statistiken. Hier können Änderungen über die vorhandenen Sichten vorgenommen werden. Reine Lesezugriffe auf die Systemtabellen sind über die entsprechenden Sichten (SYSCAT.xxxxxxxx) jederzeit möglich.

Die obere Aussage über die Systemtabellen gilt nur für die DB2 UDB für dezentrale Plattformen (Windows und Unix). Ein Beispiel für eine Ausnahme sehen wir bei DB2 für z/OS. Hier gilt, dass die Systemtabellen pro Subsystem erstellt und verwaltet werden. Datenbanken werden hier nur durch Einträge in die entsprechenden Systemtabellen des Subsystems verwaltet.

Nur wenn sich die gesamte Datenintegritätslogik in der Datenbank befindet, kann sichergestellt werden, dass die Integrität der Daten zu 100 Prozent gewährleistet ist. Sobald sich ein Teil dieser Logik in Programmen befindet, kann diese Datenintegrität nicht mehr garantiert werden. Dies rührt daher, dass ein RDBMS jederzeit direkte Zugriffe, also ohne zusätzliche Programmlogik, auf die Daten ermöglicht. Dabei kann nicht gewährleistet werden, dass genau diese externen Programmteile, die die Logik zur Einhaltung der Datenintegrität beinhalten, aufgerufen werden. Somit müssen, um die Datenintegrität sicherzustellen, diese Programmteile in die Datenbank integriert werden.

Leider müssen wir in der Praxis immer wieder feststellen, dass genau diese Forderung viel zu oft verletzt wird. Die Auswirkungen machen sich dann bei Reporting-, OLAP- und Mining-Projekten nicht selten in solch einem Ausmaß bemerkbar, dass die Ergebnisse dieser Projekte für das eigentliche "Business" unbrauchbar sind. Nur eine 100-prozentig richtige Datenbasis gibt einem Unternehmen die so wichtigen Reporting- und Analysemöglichkeiten.

Objekte der Datenbank

Das logische Objekt Datenbank kann weitere logische Objekte beinhalten. In der folgenden Liste führen wir ein paar Beispielobjekte auf und erläutern sie kurz.

• Tabellen: In einer Tabelle sind die Daten logisch nach Spalten (Attribute der Tabelle) und Zeilen (Entitäten einer Tabelle beziehungsweise Datensätze) angeordnet.

• Systemtabellen: Das sind spezielle Tabellen, die nur vom DBMS verwaltet werden und unter anderem die Beschreibung der Datenbank enthalten.

• Index: Eine Menge von Attributen, die nach Benutzervorgaben physisch sortiert und redundant vom RDBMS abgelegt werden. Ein Index wird häufig für den Zugriff auf die eigentlichen Datentabellen verwendet.

• Benutzerberechtigungen: Hiermit sind Benutzerberechtigungen auf Datenbankobjekte gemeint.

• Tabellenbereiche (Tablespaces): Logische Platzhalter für Tabellen.

• RI: Eine referenzielle Integrität definiert die Abhängigkeiten der einzelnen Tabellen voneinander.

• Auslöser (Trigger): Dies sind Aktionen, die beim Insert, Update oder Delete eines Datensatzes ausgelöst werden.

• Stored procedures: Gespeicherte Prozeduren sind Programmmodule, die sich auf dem Datenbank-Server befinden und über SQL-Befehle aufgerufen werden können.

• UDT: Benutzerdefinierte Datentypen (user defined types).

• UDF: Benutzerdefinierte Funktionen (user defined functions) können in einer SQL-Anweisung in Kombination mit oder anstelle von Spalten verwendet werden und erweitern den SQL-Sprachumfang.

• UDTF: Benutzerdefinierte Tabellenfunktionen (user defined table functions) können in einer SQL-Anweisung anstelle von Tabellen stehen.

• Ablaufpläne (Packages; dt. Pakete): Pakete werden benötigt, um in der Datenbank entsprechende Zugriffspläne bekannt zu machen.

Weitere Objekte und APIs

• Bufferpools: (Puffer-Pools) Speicherbereiche der Datenbank.

• Views: Logische Sichten auf Tabellen.

• MQTs: Materialisierte Views oder so genannte materialisierte Abfragetabellen (materialized query tables).

• Aliase: Aliasnamen für Datenbankobjekte.

• Schemata: Kennungen, wie zum Beispiel Benutzer-IDs, dienen unter anderem zur Gruppierung von Datenbankobjekten.

API (Application Programming Interface)

Allgemein: Definition von standardisierten Programmierschnittstellen. Diese Schnittstellen stellen die Funktionalität des jeweiligen Programms für externe Programme zur Verfügung.

Betriebssystem

Alle Hardware-Einheiten wie Platten, Hauptspeicher, Dateien und ähnliche werden von der DB2 UDB nur über das Betriebssystem angesprochen. Eine Ausnahme bildet der Zugriff auf Daten über unformatierte Einheiten (raw devices). Das Betriebssystem stellt seine Funktionalität nach außen über eine standardisierte API-Schnittstelle zur Verfügung.

Platteneinheiten und Dateien

Sie dienen zur physischen Speicherung aller logischen Objekte.

Ausblick

Im nächsten und letzten Teil unserer Kurzserie über die DB2-Administration beschäftigen wir uns mit den verschiedenen Einsatzgebieten. Neben dem Einzelplatzbetrieb werfen wir sowohl einen Blick auf homo- als auch auf heterogene Netzwerkumgebungen.

Unsere Artikelserie ist dem ersten Kapitel des Buches "DB2 Administration - Einführung, Handbuch und Referenz" von Jens Orhanovic, Ivo Grodtke und Michael Tiefenbacher entnommen. Erschienen ist das 640 Seiten umfassende Werk im Verlag Addison-Wesley. Sie können das komplette Buch in unserem Buchshop bestellen oder als eBook beziehen.

Serie: DB2-Administration

Teil 1	Datenbankgrundlagen
Teil 2	Definition einer Datenbank
Teil 3	Unterschiedliche Einsatzgebiete