DB2-Administration: Datenbankdefinition

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.