Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

Objektorientierung kommt ohne zentrale Datenadministration aus Der Daten-Manager ist tot - es lebe der Klassen-Manager Von Harry Sneed*

25.03.1994

Die logische Konsequenz der objektorientierten Datenverarbeitung ist die Abloesung der bisherigen Datenadministration. Schwerwiegende organisatorische Aenderungen werden den Anwenderbetrieben nicht erspart bleiben.

Die betriebliche Datenverwaltung hat ihren Zweck erfuellt. Sie wurde ins Leben gerufen, um ein einheitliches Datenmodell zu schaffen, dessen Notwendigkeit sich aus der gemeinsamen Nutzung von Datenbanken durch unterschiedliche Anwendungen ergab. Die Daten mussten so gruppiert und formatiert werden, dass sie allen Anwendungen gerecht wurden.

Vor allem in einer relationalen Datenbank, wo jedes Attribut nur einmal in einer Tabelle gespeichert ist, hat jeder Datentyp sorgfaeltig abgestimmt zu sein. Wenn auch jede Anwendung andere Sichten auf die Daten hat, so muessen doch die Einzeldaten mit ihren Sichten uebereinstimmen. Im Klartext: Die Postleitzahl ist notwendigerweise ueberall fuenfstellig numerisch. Auch die Formatierung der Daten, die Bestimmung der Datentypen, die Verschluesselung der Datenwerte und vor allem die Festlegung der Suchbegriffe sollte einheitlichen Regeln folgen.

In einer objektorientierten Umgebung eruebrigt sich diese zentrale Datenverwaltung. Dort ist jeder Datenobjekttyp in einer Klasse eingekapselt - zusammen mit allen Operationen auf die Objektauspraegungen. Eine Datenbanktabelle oder eine Datei stehen also nicht mehr allen Programmen zur Verfuegung, sondern nur dem Programm, das sie verwaltet. Andere Programme oder Klassen erhalten ihre Daten nur ueber die Exportschnittstelle der zustaendigen Klasse. Nicht das Format der Datenbanktabelle gibt den Ausschlag fuer den Datenaustausch, sondern das Format der Nachrichten, die zwischen den Klassen ausgetauscht werden.

Nur die Klasse kennt das Wie der Datenspeicherung

Ein Beispiel soll dies illustrieren: Die Klasse "Anschrift" verwaltet Adressen; eine einzelne Adresse ist eine Auspraegung des Objekttyps "Anschrift". Alle Veraenderungen, die die Adressen erfahren, werden von der zustaendigen Klasse ausgefuehrt. Ebenso beantwortet diese Klasse alle Abfragen auf die Adressen.

Weiter existiert ein Programm, das alle Adressen loescht, die seit sechs Monaten nicht abgefragt wurden. Dieses Programm schickt eine Anforderung an die Klasse "Anschrift", die wiederum ueber eine Methode verfuegt, um die angeforderte Aktion auszufuehren. Auf welche Weise die zur Adresse gehoerige Postleitzahl gespeichert ist - ob fuenfstellig numerisch oder vierstellig alphanumerisch - ist allein die Sache der Klasse "Anschrift", fuer die anderen Klassen also belanglos.

Vom jeweiligen Nachrichtenformat haengt hingegen ab, wie die Adresse ausgeliefert wird. Handelt es sich um eine englische Anschrift, so will die anfordernde Klasse ein vierstelliges alphanumerisches Kennzeichen haben, im Falle einer deutschen Adresse ist eine fuenfstellige numerische Postleitzahl gefragt. Geaendert hat sich in diesem Fall nicht die Datenbank, sondern das Nachrichtenformat.

Die Umsetzung vorzunehmen, obliegt der Klasse "Anschrift". Sie muss ueber eine Methode fuer das englische Postleit-Kennzeichen sowie jeweils eine Methode fuer die alten und die neuen deutschen Postleitzahlen verfuegen.

Dafuer, dass jeder Auftrag erledigt wird, sorgt ein Klassen-Manager. Er macht es moeglich, die Adressen auf einem eigenen Anschrift- Server zu halten, von wo aus sie an die Clients verteilt werden koennen. Fuer jedes Datenobjekt existiert eine eigene Klasse mit Import/Export-Schnittstellen. Diese Klassen sind miteinander vernetzt und kommunizieren ueber Nachrichten. Wichtig ist also die Abstimmung der Nachrichtenformate.

An die Stelle der zentralen Datenadministration wird also ein dezentrales Klassen-Management treten. Die Manager der Stammklassen muessen sich dabei mit den Managern der Transaktionsklassen ueber das Format der Nachrichten einigen. Dadurch, dass jeder mit jedem kommunizieren kann, wird die DV-Welt freier. Ob diese Freiheit ins Chaos oder zu einer groesseren Flexibilitaet fuehrt wird, wird sich erweisen.