DE10128883A1 - Verfahren und System für die Verteilung von Anwendungsdaten auf verteilte Datenbanken mit verschiedenen Formaten - Google Patents

Abstract

System und Verfahren für die Verteilung von Anwendungsprogrammdaten zur Aktualisierung einer Vielzahl von Datenbanken mit unterschiedlichen Formaten einschließlich eines Anwendungszugriffsprogramms mit einem Geschäftsobjekt, einem Speicherobjekt und einem Datenzugriffsobjekt, das zu einer Datenbank behört. Das Geschäftsobjekt erzeugt nach Bedarf Datenobjekte und sendet Datenbankzugriffsanforderungen an das Speicherobjekt. Jedes Datenzugriffsobjekt registriert sich bei dem Speicherobjekt, und das Speicherobjekt benachrichtigt jedes Datenzugriffsobjekt, wenn eine Datenzugriffsanforderung empfangen wird. Das Speicherobjekt sendet dann das Datenobjekt an die Datenzugriffsobjekte. Die in dem Datenobjekt gekapselten Daten werden in ein Format für jede Datenbank umgewandelt, in der die Daten gespeichert werden sollen. Wenn eine Leseanforderung empfangen wird, werden die Daten aus einer Datenbank gelesen, die als primäre Datenbank gekennzeichnet ist. Wenn eine Schreibanforderung empfangen wird, werden die Daten in mehreren Formaten formatiert, und in jede Datenbank werden Daten eines bestimmten Formats geschrieben.

Description

Die vorliegende Erfindung bezieht sich im Allgemeinen auf verteilte Datenverarbeitungssysteme und insbesondere auf ein System und Verfahren für die Verteilung von Anwendungsdaten auf verteilte Datenbanken mit verschiedenen Formaten.

Viele älteren Unternehmensanwendungen speichern Daten in ihren eigenen, firmenspezifischen Datenbankformaten. Parallel zur Entwicklung der Anforderungen von Geschäftsanwendern fand auch eine Entwicklung der Anwendungssoftware statt, und eine Richtung einer derartigen Entwicklung besteht in einer Tendenz weg von firmenspezifischen Datenbankarchitekturen hin zu standardmäßigen relationalen oder objektbasierten Datenbankmodellen.

In einer relationalen Datenbank werden die Daten in mehrdimensionalen Tabellen gespeichert. Jede Tabelle verfügt über mehrere Zeilen und Spalten mit Daten, welche die Beziehung zwischen den Datenelementen beschreiben. Die Verwendung einer relationalen anstelle einer firmenspezifischen Datenbank hat den offensichtlichen Vorteil, dass die Daten für die große Anzahl der Abfrage- und Datenbearbeitungshilfsprogramme für relationale Datenbanken erschlossen werden, die bei Entwicklern von Unternehmenssoftware verbreitet sind. Außerdem können der Geschäftsanwender und auch die eigentliche Anwendung so die bewährte Zuverlässigkeit einer gewerblichen Unternehmensdatenbankmaschine nutzen. Eine relationale Datenbank ist nicht an ein bestimmtes Datensatz- und Dateiformat gebunden; Schreibhilfsprogramme von Kunden für die Verbindung zur Datenbank sind wesentlich von den Änderungen und Hinzufügungen betroffen, die Anwendungsentwickler an der Datenbank vornehmen.

Viele ältere Softwareanwendungen arbeiten nach wie vor mit Daten in ihrem eigenen, firmenspezifischen Format, so dass diese Daten für die überwiegende Zahl neuer Softwarehilfsprogramme nicht zugänglich sind. Darüber hinaus zögern viele Anwender mit dem Austausch ihrer älteren Software, da sie erhebliche Investitionen in die vorhandene Softwareanwendung und die zugehörigen Hilfsprogramme getätigt haben. Die Anwender scheuen außerdem für einem unvermittelten Übergang von einer älteren Datenbank, die problemlos funktioniert hat, zu einem brandneuen System, das unvorhergesehene Probleme mit sich bringen kann, zurück. Aus diesem Grund sind Softwareentwickler gezwungen, diese älteren Datenbanksysteme, die nicht mehr leistungsfähig oder flexibel sind, weiter zu unterstützen.

Zusammenfassung der Erfindung

In Anbetracht der obigen Ausführungen ist es daher eine Aufgabe der vorliegenden Erfindung, ein System und Verfahren bereitzustellen, das die gleichzeitige Unterstützung mehrerer Datenbankmodelle durch eine vorgegebene Softwareanwendung ermöglicht.

Es ist ferner eine weitere Aufgabe der vorliegenden Erfindung, ein System und Verfahren für die Vorbereitung eines älteren Datenbanksystems auf die Migration zu einem neuen Softwareanwendungsdatenbanksystem eines anderen Formats bereitzustellen.

Die obigen Zielsetzungen werden durch eine verteilte Architektur erreicht, die durch ein Speichersubsystem bestimmt ist, das von einem Geschäftsobjekt Datenobjekte empfängt, in denen die zu speichernden Daten gekapselt sind. Das Speichersubsystem ist für die Verteilung der Datenobjekte auf Umsetzer zuständig, welche die Daten in das Format umwandeln, das erforderlich ist, um die Attribute des Datenobjekts in einer Datenbank eines vorgegebenen Typs zu speichern.

Geschäftsobjekte stehen für eine Softwareanwendung, die in der Datenbank der Softwareanwendung gespeicherte Daten anzeigt oder bearbeitet. Geschäftsobjekte erzeugen Datenobjekte über ein Fabrikobjekt (Factory Object). Fabrikobjekte sind abstrakte Fabriken, die Datenobjekte verschiedener Typen erzeugen. Datenobjekte stellen eine bestimmte logische Gruppierung von Daten dar, auf die eine Anwendung zugreifen kann. So kann ein Datenobjekt, das für eine Person in einer Adressbuchanwendung steht, beispielsweise alle relevanten Informationen zu dieser Person enthalten, die in dem Adressbuch geführt wird. Speicherobjekte stellen die Schnittstelle zu Softwareanwendungen oder Geschäftsobjekten dar. Datenzugriffsobjekte bzw. Umsetzer sind für die Umsetzung von Daten eines Datenobjekts in ein anderes Format zuständig, das für die Speicherung der gekapselten Daten des Datenobjekts in einer Datenbank verwendet werden kann. Datenbankschnittstellenobjekte empfangen Daten von den Datenzugriffsobjekten und speichern diese Daten in physischen Datenbanken.

Geschäftsobjekte verfügen über Methoden, die für die Verbindung zu Softwareanwendungen bestimmt sind. Wenn eine Softwareanwendung bereit ist, Daten in eine Datenbank zu schreiben, fordert das Geschäftsobjekt die Erzeugung eines Datenobjekts aus einem Fabrikobjekt an. Das Datenobjekt wird erzeugt, und das Geschäftsobjekt füllt das Datenobjekt dann mit Daten von der Softwareanwendung. Nachdem das Datenobjekt mit Daten gefüllt wurde, fordert das Geschäftsobjekt das Speicherobjekt auf, die Daten in diesem Datenobjekt in einer Vielzahl externer Datenbanken zu speichern, und übergibt dieses Datenobjekt an das Speicherobjekt. Das Speicherobjekt benachrichtigt lokale und entfernte Datenzugriffsobjekte über die Daten, und diese Datenzugriffsobjekte speichern dann das Datenobjekt über eine Datenbankschnittstelle in ihren jeweiligen Datenbanken. Die Daten können in verschiedenen Datenbanken in unterschiedlichen Formaten gespeichert werden.

Dieses System stellt einen Pfad für die reibungslose Migration zwischen zwei Datenbankmodellen bereit und ist in der Lage, eine große Anzahl von Datenbankmodellen zu unterstützen. Datenbanken unterschiedlicher Format können parallel zueinander vorhanden sein und aktualisiert werden, so dass die Anwender die Flexibilität erhalten, nach ihrem Ermessen auf die Daten zuzugreifen. Die Anwender können dann je nach ihren Anforderungen und zeitlichen Planungen von einem firmenspezifischen Format zu einem Format nach Industriestandard wechseln. Das System trägt auch dazu bei, die Entwicklungsmitarbeiter von den Beschränkungen des älteren Datenbankformats zu befreien, und gestattet die Weiterentwicklung der Datenbank, indem neue Merkmale und Funktionalitäten hinzugefügt werden. Die ältere Datenbank kann ihre gegenwärtige Struktur beibehalten, während zu der neuen relationalen Datenbank Merkmale hinzugefügt werden. Dadurch können die Anwender die neuen Merkmale der relationalen Datenbank nutzen, ohne nachteilige Auswirkungen auf ihre vorhandenen Hilfsprogramme in Kauf nehmen zu müssen.

Kurze Beschreibung der Zeichnungen

Die Erfindung wird besser verständlich mit Blick auf die folgende ausführliche Beschreibung der bevorzugten Ausführungsform in Verbindung mit den beigefügten Zeichnungen, wobei:

Fig. 1 zeigt ein System mit zwei Datenbanken, die unterschiedliche Formate aufweisen können und auf zwei verschiedenen Speichervorrichtungen gespeichert sind.

Fig. 2 ist ein Beispiel für ein Klassendiagramm in der Unified Modeling Language (UML), das die Beziehungen zwischen verschiedenen Objekten des Systems für die Verteilung von Anwendungsdaten gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung zeigt.

Fig. 3 ist ein beispielhaftes Diagramm, das die Wechselwirkungen zwischen verschiedenen Objekten des Systems für die Verteilung von Anwendungsdaten gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung zeigt.

Fig. 4 ist ein beispielhaftes Diagramm, das die Beziehung zwischen physischen Datenbanken, abgeleiteten Datenzugriffsobjekten und abstrakten Basisklassen des Systems für die Verteilung von Anwendungsdaten gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung zeigt.

Ausführliche Beschreibung der bevorzugten Ausführungsform

Die folgende Beschreibung verwendet Begriffe, die in der objektorientierten Programmierung üblich sind, da die Erfindung vorzugsweise unter Verwendung einer objektorientierten Programmiersprache realisiert wird. Bei einer detaillierten Betrachtung der Zeichnungen, bei denen gleichlautende Ziffern in den verschiedenen Ansichten für identische Teile stehen, zeigt Fig. 1 ein System 2 mit zwei unterschiedlichen Datenbanken, die von einer einzigen Computersoftwareanwendung verwaltet werden sollen. Das System 2 enthält einen Computer 3 mit einer Zentraleinheit (CPU) 4, einer Speichervorrichtung 5 und einer Zugriffslogik 6. Es enthält ferner eine lokale Speichervorrichtung 7 mit einer lokalen Datenbank 8, eine Servervorrichtung 10 sowie eine entfernte Speichervorrichtung 7' mit einer entfernten Datenbank 9. Die entfernte Datenbank 9 kann in derselben Speichervorrichtung gespeichert sein wie die lokale Datenbank 8, und die entfernte Speichervorrichtung 7' kann auch ohne den Umweg über ein Netzwerk 11 direkt mit dem Computer 3 verbunden sein.

Eine Computersoftware-Datenbankanwendung läuft auf dem Computer 3 und greift auf die Daten zu, die in der lokalen Datenbank 8 gespeichert sind; entsprechend greift die auf dem Server 10 gespeicherte Datenbanksoftware auf Daten zu, die in der entfernten Datenbank 9 gespeichert sind. Ein lokales Softwareanwendungsprogramm kann über das Netzwerk 11 auf die entfernte Datenbank zugreifen. Die lokale Datenbank 8 kann ein anderes Format als die entfernte Datenbank 9 aufweisen. Im Rahmen dieser Beschreibung soll die lokale Datenbank 8 eine firmenspezifische Datenbank sein, während die entfernte Datenbank 9 eine relationale oder objektorientierte Datenbank sein soll. Die Computersoftwarezugriffsanwendung wird in der Regel unter Verwendung eines objektorientierten Programmieransatzes entwickelt und verwendet Objekte, um verschiedene Rechenelemente darzustellen und ihre Schnittstellenfunktionen zu kapseln.

Fig. 2 ist ein Beispiel für ein Klassendiagramm in der Unified Modeling Language (UML), das die Beziehung zwischen verschiedenen Objekten einer bevorzugten Ausführungsform der vorliegenden Erfindung zeigt. UML verfügt über zwei Hauptkomponenten - ein Metamodell und eine Notation. Das Metamodell beschreibt die Objekte, Attribute und Beziehungen, die für die Darstellung der UML-Konzepte in einer Softwareanwendung erforderlich sind. Eine Notation wiederum dient zur Modellierung der dynamischen Elemente eines Entwurfs wie beispielsweise Objekte, Nachrichten und endliche Ablaufsteuereinheiten (Finite State Machine, FSM).

In einer objektorientierten Anwendung verfügen die Klassen über Attribute (Elementvariablen), Operationen (Elementfunktionen) und Beziehungen. Das grundlegende Element des Klassendiagramms in UML ist ein Symbol, das die Klasse darstellt. Ein Klassensymbol wird in UML durch ein Rechteck dargestellt, das in drei Bereiche unterteilt ist. Der obere Bereich enthält den Namen der Klasse. Der mittlere Bereich enthält eine Liste der Attribute, und der untere Bereich enthält eine Liste der Operationen (Funktionen). In vielen Diagrammen werden die beiden unteren Bereiche weggelassen. Wenn sie vorhanden sind, dienen sie zur Darstellung von Attributen und Operationen, die für das betreffende Diagramm von Nutzen sind.

Eine schwarze Raute steht für Komposition. Eine Pfeilspitze am anderen Ende der Beziehung macht deutlich, dass die Beziehung nur in eine Richtung navigierbar ist. In UML sind Beziehungen in der Regel bidirektional, sofern dies durch eine Pfeilspitze nicht anderweitig angegeben wird. Kompositionsbeziehungen sind eine starke Form des Einschlusses bzw. der Aggregation. Aggregation bezeichnet eine Teile/Ganzes-Beziehung. Die schwache Form der Aggregation wird mit einer offenen Raute dargestellt. Die Beziehung gibt an, dass die Aggregatklasse auf eine bestimmte Art und Weise das Ganze ist und dass die andere Klasse der Beziehung auf eine bestimmte Art und Weise ein Teil des Ganzen ist. In UML werden die beiden Enden einer Beziehung als ihre Rollen bezeichnet. Wenn das Ende einer Beziehung mit einem * gekennzeichnet ist, bedeutet das, dass die Klasse am Aggregatklassenende (Client-Ende) viele Exemplare (Aggregatobjekte) der Klasse am pfeilseitigen Einde enthält. Die Nummer an jedem Ende einer Beziehungslinie gibt die Kardinalität an. Die Kardinalität legt fest, wie viele Exemplare einer Klasse einem einzelnen Exemplar ein anderen Klasse zugeordnet sein dürfen.

Eine dreieckige Pfeilspitze steht in UML für die Vererbungsbeziehung. Der Pfeil zeigt auf die Basisklasse. Eine oder mehrere Linien können von der Basis der Pfeilspitze ausgehen und sie mit den abgeleiteten Klassen verbinden. Wenn der Name einer Klasse in Kursivschrift geschrieben ist, gibt dies an, dass es sich um eine abstrakte Klasse handelt. Wenn die Operationen kursiv geschrieben sind, gibt dies an, dass es sich um virtuelle Operationen handelt.

Eine Assoziationsbeziehung wird zur Darstellung von Einschlussformen verwendet, die keine Teile/Ganzes-Beziehung beinhalten. Eine Assoziation wird durch eine Verbindungslinie zwischen zwei beteiligten Klassen dargestellt. Wenn die Assoziation über eine Pfeilspitze verfügt, gibt dies an, dass die Klasse am Ende des Pfeils über die zugewiesene Klasse nichts weiß. Mitunter ist die Beziehung zwischen zwei Klassen sehr schwach. Ein gestrichelter Pfeil stellt eine Abhängigkeitsbeziehung zwischen einer Client-Klasse und einer Lieferantenklasse dar und zeigt, dass die Client-Klasse darauf angewiesen ist, dass die Lieferantenklasse ihr bestimmte Services zur Verfügung stellt.

In Fig. 2 ist Geschäftsobjekt 12 ein Objekt in einer Anwendung, das Zugriff auf Daten benötigt, die in einer Datenbank gespeichert sind. Das Geschäftsobjekt 12 hat in der Regel eine geschäftsbezogene Aufgabe wie beispielsweise die Verwaltung eines Hauptkontenbuchs, die Überprüfung der Schreibweise eines Worts oder die Ausführung einer anderen Art von Analyse für die Anwendung. Die Anwendung kann Daten abrufen, die in einer lokalen Datenbank gespeichert sind, sie verarbeiten und sie dann sowohl in die lokale als auch in eine entfernte Datenbank zurückspeichern. Zur besseren Anschaulichkeit soll die lokale Datenbank eine firmenspezifische Datenbank und die entfernte Datenbank eine relationale oder objektorientierte Datenbank sein. Es kann auch mehrere Datenbanken geben, und die entfernte Datenbank kann auf einer Plattform gespeichert sein, auf der ein anderes Betriebssystem ausgeführt wird.

Das Geschäftsobjekt 12 kann über eine Vielzahl von definierten Methoden verfügen, zu denen z. B. read(), write() und createDataObject() zählen können. Das Geschäftsobjekt 12 kann über seine Methode createDataObject() anfordern, dass von der Datenobjektfabrik 22 ein Datenobjekt 20 erzeugt wird. Das Geschäftsobjekt 12 kann mehrere Exemplare des Datenobjekts 20 verarbeiten. Es handelt sich dabei um eine einmehrdeutige Beziehung (1: *-Beziehung) zwischen dem Geschäftsobjekt 12 und dem Datenobjekt 20. Das Datenobjekt 20 stellt eine bestimmte logische Gruppierung von Daten für eine Anwendung dar. So enthält beispielsweise ein Personendatenobjekt für eine Adressbuchanwendung alle relevanten Informationen zu der Person, die in dem Adressbuch geführt wird. Das Datenobjekt 20 wird ausgehend von den Anforderungen des Geschäftsobjekts 12 von der Datenobjektfabrik 22 erzeugt.

Die Datenobjektfabrik 22 ist ein Einzelobjekt (Singleton). Ein Einzelobjekt ist einfach ausgedrückt eine Klasse, die für eine bestimmte Anwendung nur ein einziges Mal spezialisiert (instanziert) wird. Die Aufgabe der Datenobjektfabrik 22 besteht darin, auf Anfragen zur Erzeugung von Objekten zu warten und diese Objekte an den Anforderer zurückzugeben. Das Datenobjekt 20 wird mit der Methode createDataObject() der Datenobjektfabrik 22 erzeugt. In der Regel ist eine Fabrik spezialisiert und erzeugt nur einen einzigen Objekttyp. Wenn es mehrere Objekttypen erzeugt, sind die Objekttypen meist eng miteinander verwandt. So kann ein einzelnes Fabrikobjekt für Bilanzierungssummen z. B. Objekte für die Speicherung von Bilanzierungssummen und Objekte für Bilanzierungsendsummen erzeugen.

Das Speicherobjekt 24 stellt die Schnittstelle zu einem Speicherteilsubsystem dar. Das Speichersubsystem ist für die Verteilung der Daten auf Umsetzer zuständig, welche die Daten in ein geeignetes Format für die Speicherung in einer Datenbank eines vorgegebenen Typs umwandeln. Das Speicherobjekt 24 ist außerdem für die Verwaltung einer Liste der teilnehmenden Datenzugriffsobjekte und für die Ausgabe von Anforderungen zu Datenbankaktualisierung an die einzelnen Objekte zuständig, wenn es von einem Geschäftsobjekt 12 dazu aufgefordert wird. Das Geschäftsobjekt 12 interagiert mit dem Speicherobjekt 24, wenn es Zugriff auf eine Datenbank benötigt. Das Speicherobjekt 24 verfügt über die folgenden Beispielmethoden: attach(), detach(), notify(), write() und read(). Das Speicherobjekt 24 ist ebenfalls ein Einzelobjekt.

Die Datenzugriffsobjekte (Data Access Objects, DAO) müssen sich bei dem Speicherobjekt 24 registrieren lassen, indem sie dem Speicherobjekt 24 zugewiesen (attaching) werden. DAOs sind Datenbeobachter. Das Beobachtungsmuster ist als eine einmehrdeutige Beziehung zwischen Objekten definiert, so dass, wenn ein Objekt seinen Status wechselt, alle seine abhängigen Einheiten automatisch benachrichtigt und aktualisiert werden. Mit Bezug auf diese Erfindung bedeutet das, dass, wenn das Speicherobjekt 24 eine Anforderung von dem Geschäftsobjekt 12 empfängt, aus der Datenbank zu lesen bzw. in sie zu schreiben, das Speicherobjekt 24 die verschiedenen DAOs benachrichtigt. Dies erfolgt durch die Ausgabe einer Anforderung zur Datenbankaktualisierung an seine teilnehmenden DAOs, die besagt, dass eine Anforderung empfangen wurde, und durch anschließende die Übergabe des Datenobjekts 20 an die DAOs, so dass diese entsprechend reagieren können. Dabei ist zu beachten, dass Feld 32 in Fig. 2 eine einfache Beschreibung einer Benachrichtigung durch das Speicherobjekt 24 ist, wenn von dem Speicherobjekt 24 eine Schreibanforderung empfangen wird.

Das lokale Datenzugriffsobjekt (DAO) 34 und das entfernte DAO 36 sind in dieser Beschreibung "Beobachter". Das lokale DAO 34 ist im Allgemeinen auf derselben Plattform gespeichert wie das Speicherobjekt 24. Das entfernte DAO 36 kann auf einer Plattform gespeichert sein, die von dem Speicherobjekt 24 räumlich getrennt ist. Auf dieser entfernten Plattform kann ein Betriebssystem ausgeführt werden, das sich von dem Betriebssystem auf der lokalen Plattform unterscheidet. Das entfernte DAO 36 kann als eigenständiger Serverprozess vorhanden sein und über zusätzliche Logik verfügen, um so über das Netzwerk 11 übertragene Anforderungen zu verarbeiten. Die DAOs 34, 36 sind für die Umwandlung der Daten von einem Datenobjektformat in ein Format zuständig, das für die Speicherung der gekapselten Daten des Datenobjekts in einer Datenbank verwendet wird. Das DAO 36 verfügt über eine entfernte Ausgabeschnittstelle, einen so genannten Schnittstellenanschluss (Stub), der dem Speicherobjekt 24 zur Verfügung steht und ermöglicht, dass das Datenobjekt 24 serialisiert und an ein entferntes DAO 36 übergeben wird. Wenn ein entferntes DAO 36 spezialisiert (instanziert) wird, besteht ein Teil seiner Konfiguration aus der Adresse der Maschine, auf der die primäre Anwendung mit dem Geschäftsobjekt 12 läuft. Es registriert sich bei seinem Speicherobjekt 24, wenn es für den Empfang von Aktualisierungsanforderungen bereit ist, und erzeugt etwaige zusätzliche Objekte, die erforderlich sind, damit es über seine Datenbankschnittstelle mit seiner Zieldatenbank kommunizieren kann. In dieser Beschreibung sind sowohl das lokale DAO 34 als auch das entfernte DAO 36 mit den folgenden Methoden definiert: readAttributes(), storeAttributes() und format().

Die DAOs 34, 36 reduzieren das Datenobjekt 20, indem sie die Daten in ein geeignetes Format umwandeln, bevor sie sie an das Schlüsseldateiobjekt 38 oder eine andere firmenspezifische Datenbankschnittstelle übergeben, wenn die Daten in einer firmenspezifischen Datenbankdatei gespeichert werden sollen, bzw. an ein Datenbankmaschinenobjekt 40, wenn die Daten in einer relationalen oder objektorientierten Datenbank gespeichert werden sollen. Das firmenspezifische Datenbankschnittstellenobjekt 38 ist ein Objekt, das für den Kleinsignal-Eingang/Ausgang (E/A) für eine bestimmte firmenspezifische Datenbankdatei zuständig ist und diesen verwaltet. Das firmenspezifische Datenbankschnittstellenobjekt verfügt in der Regel über die Methoden read() und write(), um so die vom DAO 34 übergebenen Verarbeitungsbefehle für die Datei zu verarbeiten. Das Datenbankmaschinenobjekt 40 ist ein Objekt, das für eine reale Datenbankmaschinenanwendung steht, die von dem DAO 36 übergebene SQL-Befehle (Structured Query Language) verarbeitet. SQL ist eine interaktive Standardprogrammiersprache für den Zugriff auf Daten in einer Datenbank und die Aktualisierung einer Datenbank. Abfragen treten in Form einer Befehlssprache auf, welche die Auswahl, Einfügung, Aktualisierung und Lokalisierung von Daten ermöglicht. Das Datenbankmaschinenobjekt 40 verfügt über die Methoden select(), insert() und update(), um eine relationale Datenbank zu verarbeiten.

Fig. 3 ist ein Beispiel eines UML-Interaktionsdiagramms für ein Schreib-Szenario in eine Datenbank. Die Objektnamen wurden zu Darstellungszwecken verallgemeinert. Bei dem abgebildeten Szenario wird davon ausgegangen, dass die folgenden Ereignisse bereits stattgefunden haben:

• 1. Alle Geschäftsobjekte 12, Speicherobjekte 24 und Datenzugriffsobjekte (DAOs) 34, 36 wurden erfolgreich spezialisiert (instanziert).
• 2. Die lokalen 34 oder entfernten 36 DAOs haben sich bei dem Speicherobjekt 24 registriert, das den Zielteil der Datenbank verwaltet.
• 3. Das Geschäftsobjekt 12, das den Schreibvorgang in die Datenobjektdatenbank anfordert, hat ein entsprechendes Datenobjekt 20 erzeugt, mit dem Daten aus der Datenbank gelesen werden, und hat die darin gekapselten Daten so verarbeitet, dass sie gespeichert werden können.

Die nachstehende Abfolge von Schritten, die als Reaktion auf eine Anforderung zum Schreiben von Daten ausgeführt wird, entspricht den nummerierten Schritten am linken Bildrand von Fig. 3.

Schritt 1:
Das Geschäftsobjekt 12 fordert an, dass die Attribute eines Datenobjekts in die Datenbanken geschrieben werden, indem es StorageObject::write(DO) aufruft und das Datenobjekt (DO) 20 übergibt.

Schritt 2:
StorageObject::write(DO) ruft StorageObject::notify(DO) auf, um das DO 20 erneut zu übergeben. Aufgabe der Methode Notify ist es, das aktualisierte DO 20 an alle teilnehmenden Datenzugriffsobjekte 34, 36 auszugeben.

Schritt 3:
Da im vorliegenden Fall die lokale Version der Datenbank die primäre Version ist, wird ihre Datenbank zuerst aktualisiert. Notify(DO) ruft hierfür o → storeAttributes(DO) auf, wobei "o" ein Zeiger auf das lokale DAO-Objekt 34 ist.

Schritt 4:
In diesem Beispiel verfügt das lokale DAO 34 über eine Schnittstelle zu einem Schlüsseldateiobjekt 38, das eine bestimmte firmenspezifische Datenbankdatei verarbeitet. LocalDAO::storeAttributes(DO) ruft LocalDAO::format(DO) auf, um die Attribute des DO zu einem Datensatz zu reduzieren, der einen Schlüssel enthält und in einem Pufferspeicher gespeichert wird. Der Pufferspeicher wird an LocalDAO::storeAttributes(DO) zurückgegeben.

Schritt 5:
LocalDAO::storeAttributes(DO) ruft danach LocalKeyedFileObject::write(buffer) auf und übergibt den formatierten Pufferspeicher. Die Methode write liest den Schlüssel aus den ersten n Byte des Datensatzes und extrapoliert einen physischen Datensatz als Ersatz in der Schlüsseldatei. Anschließend schreibt der Schreibpufferspeicher den Datensatz in diese Speicherstelle. Wenn der Datensatz durch einen anderen Prozess blockiert ist oder wenn ein anderweitiger Fehler auftritt, wird ein Fehlerobjekt erzeugt und an das lokale DAO 34 zurückgegeben. Nach Abschluss der Operation wird die Steuerung wieder an StorageObject::notify(DO) übertragen.

Schritt 6:
StorageObject::notify(DO) ruft nun über seinen entfernten Ausgabeschnittstellenanschluss die Methode storeAttributes des entfernten DAO 36 auf und übergibt erneut das DO 20. Der Schnittstellenanschluss serialisiert das übergebene Datenobjekt und überträgt den serialisierten Datenstrom an das entfernte DAO, wo der Datenstream wieder in ein spezialisiertes (instanziertes) Datenobjekt (DO) entserialisiert wird.

Schritt 7:
RemoteDAO::storeAttributes(DO) ruft seine Methode format auf, um die Attribute des DO zu einem oder mehreren SQL- Aktualisierungsbefehlen zu reduzieren, die dann in einer Gruppe von Pufferspeichern an storeAttributes zurückgegeben werden.

Schritt 8:
storeAttributes(DO) durchläuft dann die Gruppe von Pufferspeichern und ruft jeweils den SQL- Aktualisierungsbefehl auf, so dass die Datenbankmaschine 40 die Anforderung verarbeiten und die Datenbank aktualisieren kann.

Der Fachmann weiß, dass diesem Prozess mühelos weitere DAOs hinzugefügt werden können. Bei mehreren DAOs wird ein DAO 20 für einen vorgegebenen Datenobjekttyp als das primäre DAO gekennzeichnet. Alle DAOs, die nicht als primäres DAO gekennzeichnet sind, werden als sekundäre DAOs definiert. Nur das primäre DAO wird über read()-Anforderungen, die von einem Geschäftsobjekt 12 gesendet und von einem Speicherobjekt 24 empfangen werden, benachrichtigt, da es logisch keinen Sinn macht, die gleichen Daten aus mehreren Datenbanken zu lesen. Alle DAOs, sowohl primäre als auch sekundäre, werden über write()-Anforderungen benachrichtigt.

In der bevorzugten Ausführungsform werden Threads für die Aktualisierung der sekundären DAOs verwendet, da der Abschluss ihrer Aktualisierung für die Integrität des Systems nicht von zentraler Bedeutung ist und die serielle Aktualisierung der sekundären DAOs, insbesondere der entfernten DAOs, mit einiger Wahrscheinlichkeit sehr zeitaufwendig ist, was eine erhebliche negative Auswirkung auf die Systemleistung hat. Dies steht im Gegensatz zur Aktualisierung des primären DAO, die seriell erfolgen muss, um die Datenbankintegrität in einem ereignisgesteuerten System zu gewährleisten, in dem die Reihenfolge der Objekte, die ein bestimmtes Ereignis empfangen, nicht notwendigerweise determiniert ist.

Für die sekundären DAOs können Threads erzeugt werden, um Aufrufe an die sekundären DAOs auszugeben und die Ergebnisse dieser Aufrufe zu überwachen. Dadurch kann die Hauptanwendung trotz der Verarbeitungszeit für die sekundären DAOs und ihres entfernten Standorts mit der Verarbeitung fortfahren. Fehler, die von den erzeugten Threads festgestellt werden, können Ereignisse auslösen und die Aufzeichnung von Anwendungsereignissen verursachen.

Obwohl dies für die vorliegende Erfindung nicht von entscheidender Bedeutung ist, werden die Speicherobjekte 24 vorzugsweise von Fabriken erzeugt und verfügen über virtuelle Basisklassen, die ihr gemeinsames Verhalten definieren. Die Datenzugriffsobjekte 34, 36 werden ebenfalls vorzugsweise von Fabriken erzeugt und weisen eine Mehrfachvererbung von zwei virtuellen Basisklassen auf. Die erste Basisklasse definiert Verhalten, das die lokalen DAOs 34 oder die entfernten DAOs 36 gemeinsam haben. Die zweite Basisklasse definiert Verhalten, das für den Datenbanktyp üblich ist, mit dem die DAOs 34, 36 in Verbindung stehen.

Ein Datenbankzugriffsobjekt verfügt hauptsächlich über zwei bestimmende Merkmale: Die Datenbank, für deren Verarbeitung es zuständig ist, und die Typen von Datenobjekten, für deren Empfang und Verarbeitung es programmiert wurde. Bei einer vorgegebenen Anwendung kann jeweils eine Vielzahl von DAOs für die Aktualisierung der Datenbank X zuständig sein, wobei jedes über einen anderen Datentyp verfügt, der von verschiedenen Datenobjekten Ys abgeleitet wurde. Außerdem kann eine Vielzahl von DAOs für die Verarbeitung eines Datenobjekts Y zuständig sein, wobei jedes für die Aktualisierung einer anderen Datenbank X zuständig ist. Aus diesem Grund sollte das Objektmodell so konzipiert werden, dass das gemeinsame Verhalten für die Datenbank X deklariert wird und in einer Basisklasse für diese Datenbank bzw. diesen Datenbanktyp definiert wird. Außerdem sollte eine Basisklasse definiert werden, die das gemeinsame Verhalten für die Verarbeitung von Datenobjekten eines bestimmten Typs beschreibt. Dies ergibt eine zweidimensionale Matrix für die Verhaltensdefinition und beschreibt damit einen Mehrfachvererbungsentwurf für das Speichersubsystem. Ein vorgegebenes DAO, das für die Verarbeitung bestimmter Datenobjekte und die Aktualisierung einer bestimmten Datenbank vorgesehen ist, erbt somit von der Datenobjektklasse und der Datenbankklasse, die für seine Aufgabenstellung zuständig ist, und bestimmt danach in der neuen Unterklasse das weiter erforderliche Verhalten.

Fig. 4 stellt ein Beispieldiagramm der Beziehung zwischen physischen Datenbanken, abgeleiteten Datenzugriffsobjekten und abstrakten Basisklassen des Speichersubsystems dar. Die in Klammern stehenden Ziffern dieser Beschreibung beziehen sich auf die Referenzziffern in Fig. 4. Dieses stark vereinfachte Diagramm zeigt nur zwei Typen von Datenobjekten 21, 23 und zwei Typen von Datenbanken 37, 39 (die über ihre jeweiligen Datenbankschnittstellen der physischen relationalen Datenbank 43 und der physischen firmenspezifischen Datenbank 41 zueinander gehören). Außerdem sind vier Datenzugriffsobjekte - DAO1 (29), DAO2 (31), DAO3 (33) und DAO4 (35) - abgebildet. Die durchgehenden Linien mit den dreieckigen Pfeilspitzen zwischen den DAOs und den Datenbanktypen sowie den Datenobjekttypen geben die Vererbung an. So erbt in der abgebildeten Situation DAO1 (29) von der relationalen Datenbank (37) und dem Datenobjekttyp 1 (21). DAO2 (31) erbt von der firmenspezifischen Datenbank 39 und dem Datenobjekttyp 1 (21). Das Datenzugriffsobjekt 3 (33) erbt von der relationalen Datenbank 37 und dem Datenobjekttyp 2 (23). DAO4 (35) erbt schließlich von der firmenspezifischen Datenbank 39 und dem Datenobjekttyp 2 (23). Wie in Fig. 4 ebenfalls dargestellt, gehören DAO1 (29) und DAO3 (33) über eine Datenbankschnittstelle (nicht abgebildet) der physischen relationalen Datenbank 43 zueinander. Entsprechend gehören DAO2 (31) und DAO4 (35) über eine firmenspezifische Datenbankschnittstelle (nicht abgebildet) der physischen firmenspezifischen Datenbank 41 zueinander.

Die folgende Erörterung bezieht sich auf die Nutzung von entfernten Datenzugriffsobjekten unter Verwendung der C++- und Java-Methodik. Zum gegenwärtigen Zeitpunkt stellt die C++-Programmiersprache keine eigene, einfache Umgebung für den entfernten Methodenaufruf zur Verfügung, wie dies mit der Java Remote Method Invocation (RMI)/Jini für die Java- Sprache bereitgestellt wird. Die Infrastruktur der Jini- Technologie ist um ein Modell von Clients herum aufgebaut, die auf Services warten. Der Begriff "Service" beinhaltet dabei den Zugriff auf Daten, die Verarbeitung, Software für die Ausführung bestimmter Aufgaben und im Allgemeinen alle Komponenten, die einen Anwender bei der Erreichung eines bestimmten Ziels unterstützen. In der Jini-Architektur muss ein Service als ein Datentyp der Java-Programmiersprache definiert sein, der von verschiedenen Exemplaren des Service auf verschiedene Art und Weisen verarbeitet werden kann. Das Jini-System bezieht sich ausschließlich auf die Java- Technologie. Die Jini-Architektur verdankt einen großen Teil ihrer Einfachheit der Annahme, dass die Java- Programmiersprache als Implementierungssprache für Komponenten verwendet wird. Die Fähigkeit zum dynamischen Herunterladen und Ausführen von Code ist für viele Merkmale der Jini-Architektur von entscheidender Bedeutung, wobei die Konzentration der Jini-Architektur auf die Java-Technologie stärker an die Java-Anwendungsumgebung gebunden ist als an die eigentliche Java-Programmiersprache. Mit einem Compiler, der zur Java-Programmiersprache kompatible Bytecodes erzeugen würde, könnte ein Jini-System eine beliebige Programmiersprache unterstützen.

Ein Jini-System besteht aus Services, die zur Ausführung einer bestimmten Aufgabe gebündelt werden können. Services können andere Services nutzen, und ein Client, der einen Service in Anspruch nimmt, kann wiederum ein Service mit eigenen Clients sein. In einem Jini-System kommunizieren Services über ein Serviceprotokoll miteinander, das aus einer Gruppe von Schnittstellen besteht, die in der Java- Programmiersprache geschrieben sind. Diese Gruppe von Protokollen ist offen. Die Kommunikation zwischen den Services kann anhand des "Remote Method Invocation (RMI)"- Methodenaufrufs von Java erfolgen. Die Infrastruktur für die Kommunikation zwischen den Services ist selbst kein Service, der erkannt und genutzt wird; sie ist vielmehr ein Teil der Infrastruktur der Jini-Technologie. RMI stellt Mechanismen für die Suche, Aktivierung und Löschung von Objektgruppen aus dem Speicher (Garbage Collection) bereit. Grundsätzlich betrachtet, ist RMI eine Java-programmiersprachenfähige Erweiterung von herkömmlichen Mechanismen für entfernte Prozeduraufrufe. RMI ermöglicht nicht nur die Weiterleitung von Daten von Objekt zu Objekt in einem Netzwerk, sondern von ganzen Objekten einschließlich Code. Die Einfachheit des Jini-Systems rührt zu einem großen Teil von dieser Fähigkeit her, Code in gekapselter Form als Objekt in einem Netzwerk zu übertragen.

Unter Berücksichtigung der oben beschriebenen Erläuterung gibt es zwei mögliche Umsetzungsstrategien für die Verwendung entfernter DAOs:

• 1. Ein kleines DAO-Schnittstellenobjekt kann in dem lokalen Subsystem gespeichert sein und als Proxy-Objekt für das entfernte DAO dienen. Das lokale Proxy-DAO kann eine TCP/IP-Socket-Verbindung zu dem entfernten DAO herstellen und dann die Attribute des Datenobjekts serialisieren und über die Verbindungsleitung übertragen.
• 2. Die entfernten DAOs können als Java-Applets ausgeführt sein, und eine dünne JNI-Schnittstellenschicht (Java Native Interface) kann unterhalb der Hauptanwendung geschrieben werden, um so die C++-Datenobjekte in Java- Beans oder andere Java-basierte Objekttypen umzusetzen. Datenobjekte, die von einem Speicherobjekt an den lokalen Schnittstellenanschluss des DAO übertragen werden, werden dann serialisiert und mit einem entfernten Methodenaufruf über das Netzwerk an das entfernte DAO-Applet gesendet.

Wenn die Anwendung mit dem Geschäftsobjekt in C++ geschrieben ist, hat die erste Strategie den Vorteil, dass die lokale Anwendung und die entfernten DAOs in vollem Umfang C++-Objekte bleiben. Ihr Nachteil besteht darin, dass für jedes entfernte DAO ein neues lokales DAO-Proxy-Objekt benötigt wird, was möglicherweise zu einer großen Anzahl von Objekten führt, und dass für die Verwaltung und Koordination der zugehörigen Socket-Verbindungen Code hinzugefügt werden muss.

Ein Nachteil der zweiten Ausführungsstrategie besteht darin, dass die Anwendung möglicherweise in zwei verschiedenen Sprachen geschrieben werden muss. Java Native Interface (JNI) wurde jedoch speziell für die Integration von Java in C++-Anwendungen geschaffen. Der tatsächliche Vorzug einer Verwendung von Java besteht in der Jini/RMI-Implementierung, die Teil des Java Development Kit (JDK) ist und einen großen Teil des Netzwerkverwaltungscodes enthält, der für die Serialisierung der Datenobjekte und die Kommunikation zwischen der Hauptanwendung und den Applets erforderlich ist. Außerdem verfügt Java über die systemspezifische Fähigkeit, auf mehreren Plattformen ausführbar zu sein, ohne dass für jede Plattform ausführbare Programme kompiliert werden müssen. Insgesamt gesehen, sollten diese Faktoren die vollständige Umsetzung des Entwurfs der Erfindung vereinfachen. Aufgrund der Verfügbarkeit von RMI und der Unterstützung mehrerer Plattformen durch die Java-Sprache besteht die sauberste und wirksamste Umsetzungsstrategie in der Java-Implementierung.

Das System der vorliegenden Erfindung für die Verteilung von Anwendungsdaten auf verteilte Datenbanken mit unterschiedlichen Formaten wurde als ein Anwendungsprogramm beschrieben, das in einem Computersystem mit einer oder mehreren zugehörigen lokalen Datenbanken und einer oder mehreren entfernten Datenbanken gespeichert ist, wobei letztere über ein öffentliches, nicht vertrauenswürdiges Netzwerk wie beispielsweise das Internet zugänglich sind. In diesem Zusammenhang muss jedoch darauf hingewiesen werden, und dem Fachmann ist dies bewusst, dass die Mechanismen der vorliegenden Erfindung in verschiedenen Formen als Programmprodukt verteilt werden können und dass die vorliegende Erfindung unabhängig von dem jeweiligen Typ der signalübertragenden Medien gültig ist, der für die Realisierung der Verteilung verwendet wird. Beispiele für signalübertragende Medien beinhalten, ohne jedoch darauf beschränkt zu sein, Medien des Aufzeichnungstyps, wie beispielsweise Disketten oder CD-ROMS, sowie Medien des Übertragungstyps, wie analoge oder digitale Datenübertragungsleitungen.

Darüber hinaus sollen die entsprechenden Strukturen, Materialien, Handlungen und Äquivalente sämtlicher Mittel sowie die Funktionselemente in einem der nachstehenden Ansprüche sämtliche Strukturen, Materialien bzw. Handlungen für die Ausführung der Funktionen in Kombination mit anderen Elementen, auf die gesondert Anspruch erhoben wird, beinhalten.

Obwohl die Erfindung im Besonderen im Hinblick auf eine bevorzugte Ausführungsform davon gezeigt und unter Verwendung der objektorientierten Entwurfsvorgehensweise beschrieben wurde, weiß der Fachmann sehr wohl, dass verschiedene Änderungen an Form und Einzelheiten vorgenommen werden können, ohne vom Sinn und Geltungsumfang der vorliegenden Erfindung abzuweichen.

Claims (40)

1. Verfahren für die Verteilung von Anwendungsprogrammdaten auf eine Vielzahl von Datenbanken mit unterschiedlichen Formaten, wobei das Anwendungsprogramm ein Geschäftsobjekt, ein Speicherobjekt und eine Vielzahl von Datenzugriffsobjekten beinhaltet, die jeweils zu einer einzelnen Datenbank gehören, wobei das Verfahren die folgenden Vorgänge umfasst:
Erzeugen eines Datenobjekts durch das Geschäftsobjekt;
Empfangen einer Datenbankzugriffsanforderung von dem Geschäftsobjekt durch das Speicherobjekt;
Benachrichtigen eines jeden Datenzugriffsobjekts über die Datenbankzugriffsanforderung durch das Speicherobjekt;
Senden des Datenobjekts an jedes Datenzugriffsobjekt durch das Speicherobjekt;
Umwandeln der gekapselten Daten in dem Datenobjekt in ein geeignetes Format für die Datenbank, in der die Daten gespeichert werden sollen, durch die Datenzugriffsobjekte über eine Datenbankschnittstelle; und
Speichern der Daten in einer jeden Datenbank, die den Datenzugriffsobjekten zugewiesen ist.

2. Verfahren für die Verteilung von Anwendungsprogrammdaten nach Anspruch 1, das weiter die Registrierung eines jeden Datenzugriffsobjekts bei dem Speicherobjekt umfasst, indem ein jedes Datenzugriffsobjekt dem Speicherobjekt zugewiesen wird; und/oder
das weiter die Verwaltung einer Liste der teilnehmenden Datenzugriffsobjekte durch das Speicherobjekt umfasst; und/oder
wobei der Vorgang der Benachrichtigung die Ausgabe der Datenbankzugriffsanforderungen an die Datenzugriffsobjekte durch das Speicherobjekt umfasst, wenn dies von dem Geschäftsobjekt so angefordert wird; und/oder
das weiter die folgenden Vorgänge umfasst:
Bereitstellen von Schnittstellen, die dem Speicherobjekt von den Datenzugriffsobjekten zur Verfügung gestellt werden;
Serialisieren des Datenobjekts durch einen Datenzugriffsobjekt-Schnittstellenanschluss und Ermöglichen der Übergabe des Datenobjekts an mindestens eines aus einer Vielzahl von entfernten Datenbankzugriffsobjekten zur Verarbeitung.

3. Verfahren für die Verteilung von Anwendungsprogrammdaten nach Anspruch 1, wobei die Vielzahl der Datenbanken eine firmenspezifische Datenbank und eine relationale Datenbank beinhaltet.

4. Verfahren für die Verteilung von Anwendungsprogrammdaten nach Anspruch 1, wobei die Vielzahl der Datenbanken eine firmenspezifische Datenbank und eine objektorientierte Datenbank beinhaltet.

5. Verfahren für die Verteilung von Anwendungsprogrammdaten nach Anspruch 3, wobei die firmenspezifische Datenbank von einem Datenbankschnittstellenobjekt verarbeitet wird; und wobei die relationale Datenbank von einem Datenbankmaschinenobjekt verarbeitet wird.

6. Verfahren für die Verteilung von Anwendungsprogrammdaten nach Anspruch 4, wobei die objektorientierte Datenbank von einem Datenbankmaschinenobjekt verarbeitet wird; und wobei das Datenbankmaschinenobjekt Prozeduren für den Objektabruf, die Objektspeicherung und die Objektaktualisierung beinhaltet, um die objektorientierte Datenbank zu verarbeiten.

7. Verfahren für die Verteilung von Anwendungsprogrammdaten nach Anspruch 5, wobei das Schlüsseldateiobjekt Lese- und Schreibprozeduren für die Verarbeitung der firmenspezifischen Datenbank beinhaltet; und wobei das Datenbankmaschinenobjekt Auswahl-, Einfüge- und Aktualisierungsprozeduren für die Verarbeitung der relationalen Datenbank beinhaltet.

8. Verfahren für die Verteilung von Anwendungsprogrammdaten nach Anspruch 5, wobei das Datenbankmaschinenobjekt "Structured Query Language (SQL)"-Befehle verarbeitet, die von mindestens einem Datenzugriffsobjekt bereitgestellt werden.

9. Verfahren für die Verteilung von Anwendungsprogrammdaten nach Anspruch 1, wobei eine Datenbank lokal auf einem Computerverarbeitungssystem gespeichert ist; und wobei eine zweite Datenbank räumlich entfernt von dem Computerverarbeitungssystem gespeichert und über ein Datenübertragungsnetzwerk zugänglich ist.

10. Verfahren für die Verteilung von Anwendungsprogrammdaten nach Anspruch 1, wobei jede Datenbank lokal auf einem Computerverarbeitungssystem gespeichert ist.

11. Verfahren für die Verteilung von Anwendungsprogrammdaten nach Anspruch 10, wobei ein lokales Datenzugriffsobjekt auf der gleichen Plattform gespeichert ist wie das Speicherobjekt; und/oder wobei ein entferntes Datenzugriffsobjekt auf einer Plattform gespeichert ist, die zwar physisch von dem Speicherobjekt getrennt ist, jedoch lokal durch einen Datenzugriffsobjekt-Schnittstellenanschluss repräsentiert wird.

12. Verfahren für die Verteilung von Anwendungsprogrammdaten nach Anspruch 1, wobei das Speicherobjekt Prozeduren für das Zuweisen, das Aufheben der Zuweisung, das Benachrichtigen sowie das Lesen und Schreiben beinhaltet; und/oder
wobei das Geschäftsobjekt Prozeduren für das Lesen, Schreiben und die Erzeugung von Datenobjekten beinhaltet; und/oder
wobei die Datenzugriffsobjekte Prozeduren für das Lesen und Speichern von Attributen sowie das Formatieren beinhalten; und/oder
wobei eines aus der Vielzahl von Datenzugriffsobjekten als ein primäres Datenzugriffsobjekt für einen Datenobjekttyp festgelegt wird.

13. Verfahren für die Verteilung von Anwendungsprogrammdaten nach Anspruch 12, wobei das primäre Datenzugriffsobjekt für Datenbankleseanforderungen für das Datenobjekt verwendet wird, anstelle die gleichen Daten aus einer Vielzahl von Datenbank zu lesen; und
wobei alle Datenzugriffsobjekte für den Datenobjekttyp für Datenbank-Schreibanforderungen für das Datenobjekt verwendet werden; und
wobei die nicht als das primäre Datenzugriffsobjekt gekennzeichneten Datenzugriffsobjekte als sekundäre Datenzugriffsobjekte bezeichnet werden; und
das weiter die Erzeugung von Threads zur Aktualisierung der sekundären Datenzugriffsobjekte umfasst.

14. System für die Verteilung von Programmdaten auf eine Vielzahl von Datenbanken mit unterschiedlichen Formaten, das Folgendes umfasst:
einen Prozessor für die Ausführung einer Vielzahl von Programmanweisungen;
eine Vielzahl von Speichervorrichtungen für die Speicherung einer Vielzahl von Datenbanken, von denen mindestens zwei unterschiedliche Formate aufweisen; und
ein Anwendungsprogramm für den Zugriff auf Datenbanken mit unterschiedlichen Formaten, das ein Geschäftsobjekt, ein Speicherobjekt und eine Vielzahl von Datenzugriffsobjekten beinhaltet, die jeweils einer einzelnen Datenbank zugewiesen sind.

15. System für die Verteilung von Programmdaten nach Anspruch 14, wobei das Anwendungsprogramm Folgendes umfasst:
ein Modul, das ein Datenobjekt erzeugt, wenn dies von dem Geschäftsobjekt angefordert wird;
ein Modul, das eine Datenbankzugriffsanforderung von dem Geschäftsobjekt empfängt;
ein Modul, das jedes Datenzugriffsobjekt über die Datenbankzugriffsanforderung benachrichtigt;
ein Modul, welches das Datenobjekt an ein jedes Datenzugriffsobjekt sendet;
ein Modul, das die in dem Datenobjekt gekapselten Daten in ein Format umwandelt, das für eine jede Datenbank geeignet ist, in der die Daten über eine Datenbankschnittstelle von den Datenzugriffsobjekten gespeichert werden sollen;
und ein Modul, das die Daten in einer jeden Datenbank speichert, die den Datenzugriffsobjekten zugewiesen ist.

16. System für die Verteilung von Programmdaten nach Anspruch 13, wobei das Anwendungsprogramm weiter ein Modul umfasst, das ein jedes Datenzugriffsobjekt bei dem Speicherobjekt registriert, indem es einem jeden Datenzugriffsobjekt die Zuweisung zu dem Speicherobjekt ermöglicht; und/oder
wobei das Anwendungsprogramm weiter ein Modul umfasst, das eine Liste von teilnehmenden Datenzugriffsobjekten durch das Speicherobjekt verwaltet; und/oder
wobei das benachrichtigende Modul ein Teilmodul umfasst, das Datenbankzugriffsanforderungen an die Datenzugriffsobjekte ausgibt, wenn dies von dem Geschäftsobjekt so angefordert wird; und/oder
wobei das Anwendungsprogramm weiter Folgendes umfasst:
ein Modul, das Schnittstellen bereitstellt, die dem Speicherobjekt von den Datenzugriffsobjekten zur Verfügung gestellt werden;
ein Modul, welches das Datenobjekt über einen Datenzugriffsobjekt-Schnittstellenanschluss serialisiert und ermöglicht, dass es an mindestens eines aus einer Vielzahl von Datenbankzugriffsobjekten zur Verarbeitung übergeben wird.

17. System für die Verteilung von Programmdaten nach Anspruch 14, wobei die Vielzahl der Datenbanken eine firmenspezifische Datenbank und eine relationale Datenbank umfasst.

18. System für die Verteilung von Programmdaten nach Anspruch 14, wobei die Vielzahl der Datenbanken eine firmenspezifische Datenbank und eine objektorientierte Datenbank umfasst.

19. System für die Verteilung von Programmdaten nach Anspruch 17, wobei die firmenspezifische Datenbank von einem Datenbankschnittstellenobjekt verarbeitet wird; und wobei die relationale Datenbank von einem Datenbankmaschinenobjekt verarbeitet wird.

20. System für die Verteilung von Programmdaten nach Anspruch 18, wobei die objektorientierte Datenbank von einem Datenbankmaschinenobjekt verarbeitet wird; und wobei das Datenbankmaschinenobjekt ein Modul beinhaltet, das Objekte für die objektorientierte Datenbank abruft, Objekte speichert und Objekte aktualisiert.

21. System für die Verteilung von Programmdaten nach Anspruch 19, wobei das Schlüsseldateiobjekt ein Modul beinhaltet, das Daten für die firmenspezifische Datenbank liest und schreibt; und wobei das Datenbankmaschinenobjekt ein Modul beinhaltet, das Daten für die relationale Datenbank auswählt, einfügt und aktualisiert.

22. System für die Verteilung von Programmdaten nach Anspruch 19, wobei das Datenbankmaschinenobjekt ein Modul beinhaltet, das "Structured Query Language (SQL)"- Befehle verarbeitet, die von mindestens einem Datenzugriffsobjekt bereitgestellt werden.

23. System für die Verteilung von Programmdaten nach Anspruch 14, wobei eine jede Datenbank lokal auf einer Speichervorrichtung gespeichert ist, die direkt mit dem Prozessor verbunden ist.

24. System für die Verteilung von Programmdaten nach Anspruch 14, wobei eine Datenbank auf einer Speichervorrichtung gespeichert ist, die von dem Prozessor räumlich entfernt und über ein Datenübertragungsnetzwerk zugänglich ist.

25. System für die Verteilung von Programmdaten nach Anspruch 24, wobei ein lokales Datenzugriffsobjekt auf der gleichen Plattform wie das Speicherobjekt gespeichert ist; und wobei ein entferntes Datenzugriffsobjekt auf einer Plattform gespeichert ist, die zwar physisch von dem Speicherobjekt entfernt, jedoch lokal durch einen Datenzugriffsobjekt-Schnittstellenanschluss repräsentiert wird.

26. System für die Verteilung von Programmdaten nach Anspruch 14, wobei das Speicherobjekt ein Modul beinhaltet, das für die Vielzahl der Datenbanken Daten zuweist, die Zuweisung aufhebt, benachrichtigt sowie Daten liest und schreibt; und/oder
wobei das Geschäftsobjekt ein Modul beinhaltet, das Datenobjekte liest, schreibt und erzeugt; und/oder
wobei die Datenzugriffsobjekte ein Modul beinhalten, das Attribute liest, Attribute schreibt und Daten für ihre zugewiesenen Datenbanken formatiert; und/oder
wobei das Anwendungsprogramm weiter ein Modul umfasst, das eines aus der Vielzahl von Datenzugriffsobjekten als ein primäres Datenzugriffsobjekt für einen Datenobjekttyp festlegt.

27. System für die Verteilung von Programmdaten nach Anspruch 26, wobei das primäre Datenzugriffsobjekt für Datenbankleseanforderungen für das Datenobjekt verwendet wird, anstelle die gleichen Daten aus einer Vielzahl von Datenbank zu lesen; und
wobei alle Datenzugriffsobjekte für den Datenobjekttyp für Datenbankschreibanforderungen für das Datenobjekt verwendet werden; und
wobei die nicht als das primäre Datenzugriffsobjekt gekennzeichneten Datenzugriffsobjekte als sekundäre Datenzugriffsobjekte bezeichnet werden; und
wobei das Anwendungsprogramm weiter ein Modul umfasst, das Threads zur Aktualisierung der sekundären Datenzugriffsobjekte erzeugt.

28. Computerlesbares Medium, das ein Programmprodukt für die Verteilung von Programmdaten auf eine Vielzahl von Datenbanken mit unterschiedlichen Formaten enthält, wobei das Programmprodukt ein Geschäftsobjekt, ein Speicherobjekt und eine Vielzahl von Datenzugriffsobjekten beinhaltet, die jeweils zu einer einzelnen Datenbank gehören, wobei das Programmprodukt Folgendes umfasst:
Programmanweisungen, die ein Datenobjekt erzeugen, wenn dies von dem Geschäftsobjekt angefordert wird;
Programmanweisungen, die eine Datenbankzugriffsanforderung von dem Geschäftsobjekt empfangen;
Programmanweisungen, die ein jedes Datenzugriffsobjekt über die Datenbankzugriffsanforderung benachrichtigen;
Programmanweisungen, die das Datenobjekt an ein jedes Datenzugriffsobjekt senden;
Programmanweisungen, welche die gekapselten Daten in dem Datenobjekt in ein Format umwandeln, das für eine jede Datenbank geeignet ist, in der die Daten über eine Datenbankschnittstelle von den Datenzugriffsobjekten gespeichert werden sollen; und
Programmanweisungen, welche die Daten in einer jeden Datenbank speichern, die zu den Datenzugriffsobjekten gehört.

29. Programmprodukt für die Verteilung von Programmdaten nach Anspruch 28, das weiter Programmanweisungen umfasst, die ein jedes Datenzugriffsobjekt bei dem Speicherobjekt registrieren, indem sie die Zuweisung eines jeden Datenzugriffsobjekts zu dem Speicherobjekt ermöglichen; und/oder
das weiter Programmanweisungen umfasst, die eine Liste der teilnehmenden Datenzugriffsobjekte durch das Speicherobjekt verwalten; und/oder
wobei die benachrichtigenden Programmanweisungen Programmanweisungen umfassen, die Datenbankzugriffsanforderungen an die Datenzugriffsobjekte ausgeben, wenn dies von dem Geschäftsobjekt so angefordert wird; und/oder
das weiter Folgendes umfasst:
Programmanweisungen, die Schnittstellen bereitstellen, die dem Speicherobjekt über die Datenzugriffsobjekte zur Verfügung stehen;
Programmanweisungen, die das Datenobjekt über einen Datenzugriffsobjekt-Schnittstellenanschluss serialisieren und so ermöglichen, dass es an mindestens eines aus einer Vielzahl von entfernten Datenbankzugriffsobjekten zur Verarbeitung übergeben wird.

30. Programmprodukt für die Verteilung von Programmdaten nach Anspruch 28, wobei die Vielzahl der Datenbanken eine firmenspezifische Datenbank und eine relationale Datenbank beinhaltet.

31. Programmprodukt für die Verteilung von Programmdaten nach Anspruch 28, wobei die Vielzahl der Datenbanken eine firmenspezifische und eine objektorientierte Datenbank beinhaltet.

32. Programmprodukt für die Verteilung von Programmdaten nach Anspruch 30, wobei die firmenspezifische Datenbank von einem Datenbankschnittstellenobjekt verarbeitet wird; und wobei die relationale Datenbank von einem Datenbankmaschinenobjekt verarbeitet wird.

33. Programmprodukt für die Verteilung von Programmdaten nach Anspruch 31, wobei die objektorientierte Datenbank von einem Datenbankmaschinenobjekt verarbeitet wird; und wobei das Datenbankmaschinenobjekt Programmanweisungen beinhaltet, die Objekte für die objektorientierte Datenbank abrufen, Objekte speichern und Objekte aktualisieren.

34. Programmprodukt für die Verteilung von Programmdaten nach Anspruch 32, wobei das Schlüsseldateiobjekt Programmanweisungen beinhaltet, die Daten für die firmenspezifische Datenbank lesen und schreiben; und wobei das Datenbankmaschinenobjekt Programmanweisungen beinhaltet, die Daten für die relationale Datenbank auswählen, einfügen und aktualisieren.

35. Programmprodukt für die Verteilung von Programmdaten nach Anspruch 32, wobei das Datenbankmaschinenobjekt Programmanweisungen beinhaltet, die "Structured Query Language (SQL)"-Befehle verarbeiten, die von mindestens einem Datenzugriffsobjekt bereitgestellt werden.

36. Programmprodukt für die Verteilung von Programmdaten nach Anspruch 28, wobei eine Datenbank lokal auf einem Computerverarbeitungssystem gespeichert ist; und wobei eine zweite Datenbank räumlich entfernt von dem Computerverarbeitungssystem gespeichert und über ein Datenübertragungsnetzwerk zugänglich ist.

37. Programmprodukt für die Verteilung von Programmdaten nach Anspruch 28, wobei eine jede Datenbank lokal in einem Computerverarbeitungssystem gespeichert ist.

38. Programmprodukt für die Verteilung von Programmdaten nach Anspruch 36, wobei ein lokales Datenzugriffsobjekt auf der gleichen Plattform gespeichert ist wie das Speicherobjekt; und/oder wobei ein entferntes Datenzugriffsobjekt auf einer Plattform gespeichert ist, die zwar physisch von dem Speicherobjekt getrennt, jedoch lokal durch einen Datenzugriffsobjekt-Schnittstellenanschluss repräsentiert wird.

39. Programmprodukt für die Verteilung von Programmdaten nach Anspruch 28, wobei das Speicherobjekt Programmanweisungen beinhaltet, die für die Vielzahl der Datenbanken Daten zuweisen, die Zuweisung aufheben, benachrichtigen sowie Daten lesen und schreiben; und/oder
wobei das Geschäftsobjekt Programmanweisungen beinhaltet, die Datenobjekte lesen, schreiben und erzeugen; und/oder
wobei die Datenzugriffsobjekte Programmanweisungen beinhalten, die Attribute lesen, Attribute speichern und Daten für ihre zugewiesenen Datenbanken formatieren; und/oder
das Programmanweisungen beinhaltet, die eines aus der Vielzahl der Datenzugriffsobjekte als ein primäres Datenzugriffsobjekt für einen Datenobjekttyp festlegen.

40. Programmprodukt für die Verteilung von Programmdaten nach Anspruch 39, wobei das primäre Datenzugriffsobjekt für Datenbankleseanforderungen für das Datenobjekt verwendet wird, anstelle die gleichen Daten aus einer Vielzahl von Datenbanken zu lesen; und
wobei alle Datenzugriffsobjekte für den Datenobjekttyp für Datenbankschreibanforderungen für das Datenobjekt verwendet werden; und
wobei die nicht als das primäre Datenzugriffsobjekt gekennzeichneten Datenzugriffsobjekte als sekundäre Datenzugriffsobjekte bezeichnet werden; und
das weiter Programmanweisungen beinhaltet, die Threads für die Aktualisierung der sekundären Datenzugriffsobjekte erzeugen.