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 "Digitalisierung" 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 anzuschaffen, 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 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.
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 | |
Teil 3 | Unterschiedliche Einsatzgebiete |
Welche Einsatzgebiete gibt es?
Ein DBMS (Database Management System) kann in unterschiedlichen Systemumgebungen und Einsatzgebieten verwendet werden.
Einzelplatz-Einsatz (Stand-Alone)
Im homogenen Netzwerkbetrieb
Im heterogenen Netzwerkbetrieb
Im Internetbetrieb
An dieser Stelle möchten wir noch etwas näher erläutern, was wir unter den unterschiedlichen Einsatzgebieten verstehen.
DB2 im Einzelplatz-Einsatz auf einem Standalone-Rechner
Im Einzelplatz-Einsatz läuft das DBMS auf demselben Rechner wie alle Programme, die Anforderungen an das DBMS senden. Das bedeutet, die Hardwareressourcen wie CPU, Hauptspeicher, Platteneinheiten und so weiter werden sowohl von dem DBMS als auch von den Datenbankprogrammen geteilt. Somit kann der Datenaustausch zwischen dem anfordernden Programm und dem DBMS über einen gemeinsamen Hauptspeicher erfolgen.
Folgende Betriebssysteme werden als Einzelplatz-Betriebssysteme unterstützt:
Windows-Derivate wie Windows 2000, Windows NT, Windows XP und Windows .NET
OS/2 (weitere Unterstützung ist nur über entsprechende Fixpacks von DB2 UDB Version 7.x verfügbar)
Linux
DB2 im homogenen Netzwerkbetrieb
Als homogenen Netzwerkbetrieb bezeichnen wir ein Netzwerk, in dem sowohl die als Server verwendeten Betriebssysteme als auch die auf dem Client verwendeten Betriebssysteme aus Sicht des DBMS zueinander homogen sind. Homogen bedeutet, das DBMS verhält sich für alle diese verwendeten Betriebssysteme gleich und benötigt somit identische Produktkomponenten.
Folgende Betriebssysteme können als Betriebssystem für den DB2-Datenbankserver verwendet werden:
Windows-Server-Derivate wie Windows 2000, Windows NT und Windows .NET
Verschiedenen Unix-Derivate wie AIX, Linux, Sun Solaris, HP-UX
OS/2 (Unterstützung ist nur bis DB2 UDB Version 7.x verfügbar)
Bei diesen Server-Betriebssystemen handelt es sich um genau die Betriebssysteme, die denselben Datenbankkern besitzen.
Folgende Client-Betriebssysteme können für das DBMS als homogene Client-Betriebssysteme bezeichnet werden:
Windows-Derivate wie Windows 3.1, Windows XP, Windows 95, Windows 98, Windows 2000, Windows NT und Windows .NET
Verschiedene Unix-Derivate wie AIX, Linux, Sun Solaris, HP-UX
OS/2
Mac OS
Im homogenen Netzwerkbetrieb können die Programme, die Anforderungen an das DBMS senden, sowohl auf derselben Maschine als auch auf einem separaten, über das Netz verbundenen Rechner (Client) laufen.
Befindet sich das anfordernde Programm auf derselben Maschine wie das DBMS, spricht man bei dem anfordernden Programm von einer Server-Anwendung beziehungsweise einer Server-Applikation. Sollte das Programm, das die Anforderungen an das DBMS schickt, von einem über das Netz verbundenen Rechner ausgeführt werden, spricht man bei dem anfordernden Programm von einer Client-Applikation.
Dabei spielt es keine Rolle, ob es sich bei dem Rechnersystem, auf dem die DB2-Client-Applikation läuft, um einen Server (z. B. Applikationsserver oder Datei-Server) oder um einen tatsächlichen Client handelt. Für das DBMS ist diese Anwendung immer eine DB2-Client-Applikation. Da sich diese Applikation nicht auf demselben Rechnersystem wie das DBMS befindet, können sich diese beiden Programme auch keine Hardwareressourcen teilen. Der Datenaustausch über einen gemeinsamen Hauptspeicherbereich (shared memory) ist also nicht möglich.
DB2 im heterogenen Netzwerkbetrieb
Als heterogenen Netzwerkbetrieb bezeichnen wir ein Netzwerk, in dem sowohl die als Server verwendeten Betriebssysteme als auch die vom Client verwendeten Betriebssysteme aus Sicht des DBMS zueinander nicht homogen sind. Das bedeutet, das DBMS verhält sich für die im Netzwerk verwendeten Betriebssysteme nicht gleich (nicht homogen). Dies macht den Einsatz weiterer Produktkomponenten notwendig.
Wann ist eine Betriebssystemumgebung nicht mehr homogen? Dies ist der Fall, wenn sich in dem Netzwerk zusätzlich zu den als homogen bezeichneten Betriebssystemen folgende Komponenten befinden:
OS/400
z/OS, OS/390, VM oder VSE
DB2 im Internetbetrieb
Für den Internetbetrieb können alle der oben genannten Systemumgebungen (Einzelplatz, homogene Netzwerkumgebung, heterogene Netzwerkumgebung) eingesetzt werden.
Rein technisch sind keine weiteren DB2-Komponenten erforderlich.
Produktkomponenten der unterschiedlichen Einsatzgebiete - Gesamtübersicht
SQLDA
Die SQL Data Area, kurz SQLDA genannt, beinhaltet sowohl die Beschreibung der Daten (Datentyp, Läge, Pointer auf den Dateninhalt) als auch den eigentlichen Dateninhalt.
SQLCA
Die SQL Communication Area, kurz SQLCA, dient zur Übermittlung der Kommunikationsdaten, z. B. von Fehlermeldungen, Warnhinweisen und weiteren Informationen.
RC
Der Run-Time Client simuliert sozusagen das auf dem Client nicht vorhandene DBMS. Er nimmt den CONNECT-Befehl entgegen und schaut in den entsprechenden Katalogeinträgen nach, auf welchem Server sich die Datenbank befindet
Über das konfigurierte Übertragungsprotokoll nimmt er dann mit dem entsprechenden Agenten (AS - Applikationsserver) auf dem Datenbank-Server Kontakt auf und stellt über diesen die Verbindung zu dem Ziel-DBMS her.
Das Anwendungsprogramm baut diesem Fall den Speicherbereich für die SQLCA und die SQLDA mit dem RC auf. Der RC wiederum kopiert diese Daten dann über den AS zum entsprechenden Datenbank-Server.
AS
Der Applikationsserver ist sozusagen der Server-Agent für alle RCs (Run-Time Clients), die sich mit dem Datenbank-Server verbinden. Er besitzt mit dem DBMS den Server-Speicherbereich für die SQLDA und die SQLCA und tauscht Daten über das verwendete Protokoll (TCP/IP, NetBios, SNA, NPIPE) mit dem Speicherbereich des RC auf dem Datenbank-Client aus.
Der AS ist die Komponente, die für Remote-Zugriffe auf das DBMS notwendig ist. Er hat Zugriff auf dieselben Hardwareressourcen wie das DBMS. Dadurch wird der Datenaustausch über shared memory möglich.
DRDA AR (Application Requestor)
Wie schon erwähnt, besitzen in heterogenen Umgebungen die Datenbank-Server verschiedene Datenbankkerne und verhalten sich nicht nur für den Administrator, sondern auch für den Benutzer und den Programmierer unterschiedlich. Ebenso sind weitere Unterschiede wie eventuell verschiedene Zeichendarstellungen (EBCDIC-Code oder ASCII-Code), Sicherheitsprüfungen und so weiter vorhanden.
Die Transformationsschichten
Um Datenbanken unterschiedlicher Systeme miteinander zu verbinden und diese Unterschiede der Systeme nicht für den Anwender (hier sind alle Nutzergruppen wie Administratoren, Programmierer gemeint) transparent zu machen, wurde das DRDA-Protokoll (Distributed Relational Database Architecture) entwickelt. Diese Architektur wird auf dem eigentlichen Übertragungsprotokoll (Beispielsweise TCP/IP) eingesetzt und besitzt fünf verschiedene Transformationsschichten.
Die Trennung der unterschiedlichen Aufgaben in verschiedene Transformationsschichten ermöglicht eine größtmögliche Flexibilität und eine Anbindung von Anwendungen an die unterschiedlichsten Datenbanksysteme.
MSA (Management Services Architecture)
Diese Schicht übernimmt den Transfer und das Management von Fehlern.
Protokollschicht
Die Protokollschicht übernimmt die Unterstützung und das Management der folgenden beiden Übertragungsprotokolle:
SNA (System Network Architecture) beziehungsweise APPC (Advanced Program to Program Communication)
CP/IP (Transmission Control Protocol/Internet Protocol)
DDM (Distributed Data Management Architecture)
Diese Schicht ermöglicht einen Datenaustausch zwischen bekannten und unbekannten Systemen. Unterschiede zwischen den unterschiedlichen Befehlen, Parametern, Datenobjekten und Meldungen der ungleichen Systeme werden in dieser Schicht ausgeglichen.
FD:OCA (Formatted Data: Object Content Architecture)
Verschiedene relationale DBMS besitzen andere Eigenschaften in der Formatierung und der Beschreibung der Attribute. Diese Schicht sorgt dafür, dass die Unterschiede eliminiert werden.
CRDA (Character Data Representation Architecture)
Die Nutzung verschiedener Code-Pages und Zeichensätze für grafische und Character-Daten kann durch diese Schicht ausgeglichen werden.
DRDA AS (Distributed Relational Database Architecture Application Server)
Der DRDA AS bildet auf Seiten des Datenbank-Servers quasi das Gegenstück zum DRDA AR. Er ist auf dem anzusprechenden Datenbank-Server installiert.
Abspann und Überblick
Mit diesem Teil endet unsere Kurzserie über die DB2-Administration.
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 | |
Teil 3 | Unterschiedliche Einsatzgebiete |