In der heutigen Zeit haben die Datenhaltung, -verarbeitung und -auswertung einen Stellenwert erreicht, der vor kurzem noch 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. Allein der Einsatz eines relationalen Datenbanksystems führt aber 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.
Mit unserer neuen dreiteiligen Artikelreihe bieten wir Ihnen eine Einführung in die Administration der Datenbank DB2.
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.
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.
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.
| |
Teil 1 | |
|---|---|
Teil 2 | Definition einer Datenbank |
Teil 3 | Unterschiedliche Einsatzgebiete |
Datenbankgrundlagen
Nicht erst seit der Einführung der elektronischen Datenverarbeitung beschäftigt man sich mit der Datenhaltung, -verwaltung, -verarbeitung und -auswertung.
Da wir zum Teil selbst die Veränderungen der EDV von der Lochkarte bis heute miterleben durften, denken wir, dass ein Blick auf die Historie und Grundlagen dieser Systeme sehr hilfreich ist, um ein gewisses Grundverständnis für die Aufgaben eines Datenbank-Managementsystems zu erlangen.
Es gibt auch heute noch genügend Anwendungen, die auf Vorgänger der relationalen Datenbanksysteme zugreifen, um mit "IMS" (Information Management System, eine hierarchische Datenbank) nur ein Beispiel zu nennen.
Historie der relationalen Datenbanksysteme
Den Anfang machten in den 70er Jahren Systeme wie hierarchische beziehungsweise Netzwerkdatenbanken. Diese hatten den Nachteil, dass die gesamte Anwendungslogik im Programmcode vorausgesetzt wurde. Einfache Abfragemöglichkeiten bestanden nicht.
Mitte der 70er Jahre schuf Edgar Codd in einem Forschungsprojekt bei IBM die theoretischen Grundlagen für relationale Datenbanken und Datenbanksysteme. Zusammen mit Chris Date wurden diese weiterentwickelt und vervollständigt.
Die Codd'schen Regeln
Die Grundlage für die Aufgaben eines relationalen Datenbanksystems bildeten die bis heute gültigen Codd'schen Regeln, die wir im Folgenden in unseren eigenen Worten aufführen.
Zugriff entsprechend dem Drei-Schichten-Modell: Der Zugriff auf die Daten über Sichten (Views), Schemata und Daten muss gewährleistet sein. Dies ermöglicht die Trennung der Benutzer-, der logischen und der physikalischen Schicht.
Mehrbenutzerzugriff (Multi User Access): Der gleichzeitige und konkurrierende Zugriff mehrerer Benutzer auf ein und dieselben Daten für Lese- und Schreiboperationen muss möglich sein.
Transaktionsorientierung: Die Anforderungen an Serialisierbarkeit, Protokollierbarkeit, Rücknehmbarkeit und Abgeschlossenheit der Daten müssen erfüllt sein. Das bedeutet, mehrere nacheinander durchgeführte Änderungen müssen als Einheit zusammengefasst werden können und entweder alle mit einer Bestätigung (COMMIT) durchgeführt werden, oder es werden durch eine Rücknahme (ROLLBACK) alle Änderungen zurückgesetzt. Hierdurch wird die Zusammenfassung mehrerer einzelner Aktionen zu einer logischen Einheit ermöglicht.
Online-Verarbeitung: Bei einem Datenzugriff aus Programmen heraus müssen die Transaktionseigenschaften gewährleistet sein.
Anforderungen an Sicherung (Backup) und Wiederherstellbarkeit (Recovery): Um einen Datenverlust durch logische Fehler oder Hardware-Fehler zu verhindern, muss ein Wiederherstellen der gesamten Datenbank gewährleistet sein. Hierzu muss das RDBMS (relationales Datenbank-Managementsystem) geeignete Sicherungs- und Wiederherstellungsverfahren zur Verfügung stellen. Ebenso muss die Möglichkeit bestehen, den Zustand der Daten zu einem bestimmten Zeitpunkt (Point in Time Recovery) bzw. zum letzten konsistenten Zeitpunkt (Rollforward bzw. Crash Recovery) wiederherzustellen.
Zugriffsrealisierung: Die Datenkonsistenz muss auch dann gewährleistet sein, wenn mehrere Benutzer ein und denselben Datensatz lesen bzw. ändern möchten. So genannte Anomalien ("Lost Updates") und Inkonsistenzen müssen verhindert werden.
Codd'sche Regeln II
SQL (Structured Query Language): Das RDBMS (relationales Datenbank-Managementsystem) muss eine nicht prozedurale, mengenorientierte Sprache zum Zugriff auf die Daten und Objekte für Lese- und Schreiboperationen zur Verfügung stellen.
Ad-hoc-Verarbeitung: Die konventionell geplante Verarbeitung der Daten mit SQL (Structured Query Language) oder anderen Schnittstellen muss sowohl über Programme als auch über interaktive Schnittstellen möglich sein. Die Anforderung des Unterwanderungsverbots muss ebenfalls gewährleistet sein. Das bedeutet, dass der SQL-Sprachumfang - auch durch zusätzlich zur Verfügung gestellte Schnittstellen - nicht erweitert werden darf.
Integrität des Wertebereichs (Domain Integrity): Die zulässige Wertemenge eines Attributs muss über das Datenbanksystem definierbar sein und ihre Einhaltung muss gewährleistet sein.
Referenzielle Integrität (Referential Integrity): Innerhalb einer relationalen Datenbank können Entitäten statische Beziehungen untereinander besitzen. Diese werden durch das Vorhandensein eines bestimmten Werts in einem Attribut eindeutig ausgedrückt und müssen vom RDBMS überwacht werden können.
Entitätenintegrität (Entity Integrity): Es muss gewährleistet sein, dass der Datentyp und somit die Dimensionen eines jeden Attributs einer Entität eingehalten werden. So darf zum Beispiel ein nummerisches (Integer-)Feld keine Buchstaben (Characters) enthalten.
Zugriffsberechtigung: Die Regelung der Rechte zum Zugriff auf Daten und Objekte der Datenbank und des Datenbank-Managementsystems muss im RDBMS integriert sein.
Historie der DB2
Auf Basis der zuvor erwähnten Codd'schen Regeln entstand 1975 und 1976 aus einem IBM-Forschungsprojekt mit System R die erste Implementierung des relationalen Modells. Diese wurde 1977 erstmalig als Prototyp bei IBM-Kunden installiert.
Auf der Grundlage dieses Systems stellte IBM 1982 mit dem Produkt SQL/DS erstmals ein relationales DBMS für die Betriebssysteme VM und VSE zur Verfügung.
DB2 hieß ursprünglich Database 2 und war zum ersten Mal 1983 unter dem Betriebssystem MVS verfügbar. Als Ausgangssystem diente ebenfalls System R. Es handelt sich hierbei also um eine parallele Entwicklung zu SQL/DS. Mit dem Betriebssystem OS/400 wird seit 1988 das integrierte SQL/400 ausgeliefert, das heute DB2 für AS400 heißt.
1987 kündigte IBM mit dem Betriebssystem OS/2 V1 und der Erweiterung OS/2 Extended Edition die ersten relationalen Datenbankfähigkeiten auf einem dezentralen System an. Hierbei handelt es sich um den Vorläufer der heutigen DB2 UDB. Als eigenständiges Datenbankprodukt erschien 1991 der Vorgänger von DB2 unter dem Namen OS/2 Database Manager. 1993 wurde die DB2-Datenbank unter dem Namen DB2 V1 für die Betriebssysteme OS/2 und AIX vermarktet. Seit der Version DB2 Common Server V2, der ersten objektrelationalen und webfähigen Datenbank, die 1995 veröffentlicht wurde, wird auch das Betriebssystem Windows unterstützt. Inzwischen werden mit der DB2 UDB V8 alle gängigen Server-Betriebssystemplattformen inklusive Linux unterstützt.
Nutzung von relationalen Datenbank-Managementsystemen
Um den Umgang mit der Komplexität relationaler DBMS zu erleichtern, teilt man die Aufgaben eines RDBMS wie folgt ein:
Datenmodellierung
Programmierung
Administration
Anwender (Endbenutzer)
Aufgaben des Modellierers
Das Datenmodell ist die wichtigste Grundlage einer konsistenten und performanten Datenbank. Der Modellierer erstellt auf Grund der Geschäftsanforderung das entsprechende Datenmodell. Die Arbeitsschritte der Modellierung sind in drei konzeptionelle Ebenen unterteilt:
Geschäftsebene (Business-Ebene): Auf dieser Ebene geht es darum, die Geschäftsprozesse und die Zusammenhänge zu erkennen und zu formalisieren.
Logische Ebene: Hier geht es darum, die formalisierten Geschäftsprozesse in ein Entity-Relationship-Modell (ER-Modell) umzusetzen und dabei die Konsistenzregeln (Normalformen) dieser Modellierungstechnik zu berücksichtigen.
Physikalische Ebene: Das erstellte ER-Modell wird in diesem Schritt um physikalische Aspekte erweitert und dann in der Datenbank implementiert, indem zughörige Datenbankobjekte erstellt werden.
Warum werden die Schritte der Modellierung auf drei Ebenen unterteilt? Wenn Sie vor der Aufgabe stehen, ein Datenmodell einer komplexeren Geschäftslogik zu erstellen, merken Sie sehr schnell, dass es sich dabei um eine nicht zu verachtende Herausforderung handelt.
Zum einen ist da der Endbenutzer, der Sie mit sämtlichen Informationen der Geschäftslogik überhäuft, zum anderen sind bestimmte Vorgänge und Verantwortungen in den Firmen häufig nicht definiert. Außerdem müssen Sie die Normalformen des relationalen DB-Designs einhalten, um ganz zum Schluss die Speicherform der Daten für die zum Einsatz kommende Datenbank in optimaler Form bestimmen zu können.
Bei der Verwaltung der eigenen Video-Filme mag das ja noch ganz gut aus dem Bauch heraus möglich sein. Bei komplexeren Geschäftsverfahren helfen hier jedoch nur ein akkurates Vorgehen und die getrennte Betrachtung der einzelnen Aufgaben nach den zuvor erwähnten Ebenen. Da die Komplexität der Datenmodellierung genug Stoff für ein eigenes Buch liefert, werden wir in diesem Kapitel nicht weiter darauf eingehen.
Dennoch möchten wir darauf hinweisen, dass bei den meisten Performance- und Tuning-Betrachtungen, die wir in der Praxis durchführen, die Ursachen für Probleme in unzureichendem Datenbank-Design zu finden sind. Und nicht zuletzt erschwert häufig eine fehlende Dokumentation die Untersuchung sowie die Nutzung des bestehenden Datenmodells.
Aufgaben des Programmierers
Der Programmierer hat im Wesentlichen zwei Hauptaufgaben:
Er erstellt die SQL-Anweisungen auf Grund des vorgegebenen Datenmodells.
Er erstellt die Verarbeitungsprogramme und die Benutzerschnittstellen in der entsprechenden Programmiersprache.
An dieser Stelle weisen wir darauf hin, dass die Trennung zwischen der eigentlichen Programmierung in einer Programmiersprache und der Erstellung der SQL-Befehle ganz strikt gehandhabt werden sollte.
Warum ist das so notwendig? Wir selbst hatten bis zu dem ersten Einsatz einer relationalen Datenbank mehrere Jahre Programmiererfahrung. Somit gingen wir unsere ersten Projekte zur Entwicklung von Datenbankanwendungen mit der Einstellung an: "Was man nicht selbst programmiert, kann nicht sehr performant sein."
Somit ist es für uns nicht verwunderlich, dass wir genau diese Einstellung bei den meisten Programmierern wiederfinden. SQL ist aber im Gegensatz zu einer prozeduralen oder einer objektorientieren Programmiersprache eine mengenorientierte Abfragesprache. Das bedeutet, hier müssen sich die Gedanken nicht auf das "Wie", sondern auf das "Was" konzentrieren. Dies sind zwei prinzipiell unterschiedliche Denkansätze, und sie sollten nicht vermischt werden.
Versucht man dennoch, diese Ansätze zu vermischen, führt das in der Praxis dazu, dass meist nur sehr einfache SQL-Statements erstellt werden und die eigentliche Verarbeitungslogik im Programm steckt. Da die Möglichkeiten des relationalen Datenbanksystems nicht genutzt werden, hat dies in den meisten Fällen den gefürchteten Performance-Verlust zur Folge.
Empfehlung für Programmierer
Somit lautet unsere Empfehlung wie folgt: Bevor überhaupt eine einzige Zeile Programmcode in Bezug auf die Datenbank geschrieben wird, sollten erst alle SQL-Anweisungen geschrieben und getestet werden. Beim Testen muss nicht nur auf die Richtigkeit, sondern auch schon auf die Performance geachtet werden. Hierzu stellt DB2 verschiedene ausgezeichnete Tools zur Verfügung (wie beispielsweise Explain). Wählt man diese getrennte Vorgehensweise, kann man sehr schnell und noch vor der eigentlichen Programmierung folgende Fragen klären:
Ist das Datenbank-Design aus mengenorientierter Sicht in Ordnung?
Werden alle benötigten logischen Konsistenzanforderungen wie Auslöser (Trigger) und referenzielle Integrität erfüllt?
Werden zusätzliche Datenbankobjekte wie z. B. benutzerdefinierte Funktionen (User Defined Functions - UDFs), benutzerdefinierte Datentypen (User Defined Types - UDTs) und gespeicherte Prozeduren (Stored Procedures) benötigt?
Müssen aus Performance-Gründen Änderungen am logischen oder physischen Datenbank-Design vorgenommen werden?
Können künstliche Redundanzen wie z. B. gespeicherte Abfragetabellen (Summary Tables bzw. Materialized Query Tables - MQTs) oder zusätzliche spezielle Indizes leistungssteigernd wirken?
Wir denken, die Vorteile der drei aufeinander folgenden Arbeitsschritte liegen klar auf der Hand. Denn missachtet man diese Trennung und Reihenfolge, und ist der Programmcode erst einmal geschrieben, sind die Änderungen sehr viel aufwendiger bzw. fast unmöglich.
Aufgaben des Administrators
Die Administration kann aus Sicht eines RDBMS in zwei Gebiete unterteilt werden:
Administration des Datenbank-Managementsystems (DB-Systemadministration)
Administration der Datenbank
Diese Aufteilung macht eine Trennung der plattformabhängigen und der plattformunabhängigen Aufgaben möglich. Während die Administration des DBMS stark vom Betriebssystem beeinflusst wird, ist die Administration der Datenbanken nahezu plattformunabhängig. Je nach Größe und Komplexität des Betriebs ist es sogar sinnvoll, diese Aufgabengebiete unterschiedlichen Personen zuzuordnen.
Aufgaben der Datenbank-Systemadministration
Das Aufgabengebiet der Datenbank-Systemadministration umfasst im Wesentlichen alle betriebssystemnahen Aufgaben.
Dazu gehören:
Installation und Pflege des DBMS
Erstellen und Wartung von Exemplaren (Instanzen)
Administration der Datenbankbenutzer
Verwaltung und Überwachung der benötigten Systemressourcen
Anlegen von Datenbanken
Aufgaben der Datenbankadministration
Die Aufgabe des Datenbankadministrators besteht in der eigentlichen Verwaltung der Datenbanken.
Hierunter fallen folgende Hauptaufgaben:
Anlegen und Verwalten von Datenbankobjekten
Performance-Überwachung und gegebenenfalls Tuning-Maßnahmen
Erstellen und Verwalten von Sicherungs-(Backup-) und Wiederherstellungs-(Recovery-)Verfahren
Exportieren und Laden von Daten
Erstellen, Implementieren und Überwachen von Datenbank- und DBMS- Sicherheitskonzepten inklusive Verwalten von Berechtigungen der Benutzer für die verschiedenen SQL-Befehle (wie Select, Insert, Update) auf die Datenbankobjekte
Verwalten von Berechtigungen der Benutzer für die verschiedenen Programme, die auf die Datenbank zugreifen
Pflege- und Wartungsarbeiten
Binden von Programmpaketen (Bind-Files) zur Erstellung von Zugriffsplänen
Pflegen der Statistiken
Reorganisieren der Daten
Der Datenbankadministrator ist derjenige, der das eingesetzte DBMS und dessen Eigenschaften sehr gut kennen muss. Er ist der Hauptansprechpartner für alle weiteren Beteiligten (Benutzer, Programmierer, Modellierer und Systemadministratoren). Je nach Größe des Unternehmens und Anzahl der eingesetzten DBMS bzw. Datenbanken handelt es sich bei dieser Aufgabe nicht selten um einen Vollzeitjob.
Dennoch stellen wir in der Praxis sehr häufig fest, dass genau dieser Job unterschätzt wird und einfach von einem Mitarbeiter nebenbei gemacht werden soll. Sicherlich wirbt heute jeder Datenbankhersteller mit einem nahezu wartungsfreien System. Aber auch hier gilt: Je wartungsfreier ein System ist, umso komplexer ist es.
Um wieder auf das Beispiel des Jumbojets zu kommen: Auch er besitzt eine hochkomplexe Technik, die dem Piloten und den Ingenieuren die Arbeit weit gehend abnimmt. Dennoch glauben wir nicht, dass man auf die Idee kommen würde, die Ausbildung und die Arbeit des Piloten zu unterschätzen. Das soll nicht heißen, dass jedes Unternehmen, das ein RDBMS einsetzt, einen Vollzeit-Administrator benötigt. Hier hängt es vielmehr davon ab, welche Ansprüche an das gesamte DV-System gestellt werden und welche Automatismen und Wartungsverfahren vorhanden und vorgesehen sind.
Aufgaben der Endbenutzer
Der Endbenutzer ist derjenige, der die Daten und Objekte, die von der Datenbank zur Verfügung gestellt werden, über die verschiedensten Schnittstellen nutzen kann.
Als Schnittstellen stehen dem Benutzer folgende Möglichkeiten zur Verfügung:
SQL-Standardabfrage-Tools, wie zum Beispiel:
QMF (Query Management Facility) BO (Business Objects)
Crystal Reports
OLAP-Werkzeuge, wie z. B.:
IBM OLAP-Server
Cognos-Werkzeuge
MicroStrategy-Werkzeuge
Mining-Werkzeuge
Speziell entwickelte Anwendungen
SQL-Schnittstellen von DB2
Im Prinzip gibt es zwei Gruppen von Endbenutzern:
Endbenutzer, die nur fertige Lösungen und vordefinierte Wege nutzen
Endbenutzer mit SQL-Kenntnissen, die ihre eigenen Abfragen gestalten
Der Endbenutzer, der mit vorgefertigten Wegen und Lösungen arbeitet, erkennt in der Regel keinen Unterschied zu Systemen, die kein RDBMS als Datenbankgrundlage nutzen. Im Gegensatz dazu wird der Nutzer mit SQL-Kenntnissen die Vorzüge eines RDBMS sehr schnell zu schätzen lernen. Die einfache Nutzung der SQL-Schnittstelle ermöglicht es dem Benutzer, jederzeit die gespeicherten Daten, die zur Verfügung gestellten Objekte und SQL-Erweiterungen, wie beispielsweise UDFs (User Defined Functions), UDTF (User Defined Table Functions), gespeicherte Prozeduren (Stored Procedures), gespeicherte Abfragetabellen (MQTs, also materialisierte Abfragetabellen) und Sichten (Views) für eigene Ad-hoc-Auswertungen zu nutzen.
Dieser enorme Vorteil einer relationalen Datenbank versetzt ein Unternehmen in die Lage, seine Auswertungen und somit seine benötigten Geschäftsinformationen schnell an die sich ändernden Bedingungen des Markts oder an eine bestimmte Situation anzupassen. Dies führt dazu, dass der eigentlich technische Vorteil sofort als betriebswirtschaftlicher Vorteil genutzt werden kann. Die Grundvoraussetzungen für eine sinnvolle und performante Nutzung der Daten bilden jedoch die SQL-Kenntnisse, das richtige Datenbank-Design und dessen übersichtliche Dokumentation.
Ausblick
Im nächsten Kapitel beschäftigen wir uns näher mit der grundlegenden Definition einer Datenbank. Zusätzlich erläutern wir einige ausgewählte Datenbankobjekte.
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.
| |
Teil 1 | |
|---|---|
Teil 2 | Definition einer Datenbank |
Teil 3 | Unterschiedliche Einsatzgebiete |