-
Die
Erfindung bezieht sich auf das Gebiet der Datenverwaltung und insbesondere
auf Datenbankmodule unter Zuhilfenahme des XML Standards (Extensible
Markup Language), in dem maschinen- und menschenlesbarer Dokumente in Form
einer Baumstruktur erstellt werden.
-
Programme
brauchen zur Verarbeitung Daten, die meist in Form von einer Datenbank 3 in
einem Datenbankmodul 1 vorliegen (siehe 1).
Die Daten werden zwischen Komponenten 4, 5, 6 und 7 verteilt,
die eine Sammlung von Funktionen und/oder Bibliotheken darstellen.
Nach dem Stand der Technik erfolgt der Datenzugriff der Komponenten 4, 5, 6 und 7 durch
eine Beobachterschnittstelle 2 auf die Datenbank 3.
Werden nun die Daten in den Komponenten verarbeitet 4, 5, 6 und 7 und
verändert
und an das Datenbankmodul 1 zurückgesendet, gibt die Beobachterschnittstelle 2 diese
Datenänderungen
an andere, ebenfalls registrierte Komponenten weiter. Ruft jedoch
eine Komponente während
der Bearbeitung einer gemeldeten Änderung wiederum Änderungsmethoden
des Datenbankmoduls 1 auf, kann es zu Endlosschleifen kommen
und zu inkonsistenten Daten in der Datenbank 3 führen. Auf
Grund rekursiver Datenänderungen,
die von den Komponenten 4 und 5 ausgehen, wird
das Datenbankmodul 1 andauern bei der Bereitstellung oder Übertragung
der Daten aus der Datenbank 3 an die Komponenten 4 und 5 unterbrochen
und muss stattdessen alle Komponenten über die Datenänderungen
immer wieder benachrichtigen. Dadurch ist auch die Erreichbarkeit der
Daten aus der Datenbank für
die Komponenten nicht gewährleistet.
Des Weiteren führen
Datenänderungen
bei großer
Komponentenanzahl zu hohen Änderungskosten.
Einerseits informiert das Datenbankmodul 1 jede Komponente,
auch wenn diese die Änderungsinformation
nicht benötigt.
Zusätzlich
können die Änderungen
weitere Änderungen
nach sich ziehen und so einen unerwartet hohen Aufwand haben. Ein
weiteres Problem tritt bei der Erweiterung der Daten, der Datenstruktur
sowie bei der Einbindung neuer Komponenten mit dem Datenbankmodul 1 auf. Änderungen
dieser Art verlangen eine Schnittstellenanpassung und damit eine
Recompilierung aller vorhandenen Komponenten. Sehr aufwendig sind
insbesondere Anpassungen bei Komponenten wie zum Beispiel der externen
Komponente 7, die nicht im gleichen Prozess wie bei dem
Datenbankmodul 1 läuft.
Diese Probleme wurden teilweise durch eine Fassade gelöst, die
die Komplexität
der Datenbank versteckt und eine einheitliche und oft vereinfachte Schnittstelle
des Datenbankmoduls für
eine Menge von Schnittstellen von Komponenten bietet. Die Anwendung
bzw. Programmierung einer solchen Fassade ist jedoch meist komplexer
als die einer eigens programmierten Datenverwaltung.
-
Dokument
DE 199 51 756 B4 offenbart
ein Verfahren zur Datenverwaltung in einem auf einem Computer installierten
Datenbanksystem, wobei die Daten in dem Datenbanksystem ohne relationale Verknüpfungen
zueinander gehalten werden, die Gesamtheit der Datenverwaltungsvorgänge in eine
Vielzahl von Funktionseinheiten aufgeteilt ist, welche Funktionseinheiten
die jeweils zugehörigen
Datenzugriffsbefehle enthalten und Verknüpfungen von in dem Datenbanksystem
gehaltenen Daten durch Verknüpfungen
zwischen den zugehörigen
Funktionseinheiten gebildet werden.
-
Dokument
EP 1 057 310 B1 offenbart
ein Verfahren zum Betreiben eines Dokumentenüberwachungssystems, das einen
Dokumentenüberwachungsserver
zum Überwachen
des Zugangs zu Dokumenten auf Dokumentenservern in einem internen Netzwerk
umfasst, wobei der Dokumentenüberwachungsserver
eine Liste von Klienten und eine Liste von Dokumenten enthält, in der
für Klienten
verfügbare
Dokumente aufgeführt
sind.
-
Die
Aufgabe der vorliegenden Erfindung liegt darin, eine bessere Organisation
von Daten und Bearbeitungsanfragen in einem Datenverwaltungssystem
zu erreichen, die die Wahrung der Datenkonsistenz bei multiplen
Anfragen und eine einfachere Er weiterung der Datenstrukturen ohne
eine komplette Recompilierung erlaubt.
-
Diese
Aufgabe wird durch einen Client für die Organisation von Daten
und Bearbeitungsanfragen in einem Datenverwaltungssystem gelöst, der
einen Beobachter zum Registrieren von bearbeiteten Daten, wobei
der Beobachter geeignet ist, mit mindestens einer Komponente verbunden
zu sein und bearbeitete Daten von einer verbundenen Komponente zu
empfangen, eine Datenbank zum Speichern und zum Bereitstellen der
Daten für
die mindestens eine verbundene Komponente, und eine Schnittstelle
zum Senden und Empfangen von mindestens den bearbeiteten Daten sowie
Empfang von einer Bestätigung,
wobei die Schnittstelle geeignet ist, mit einem Server verbunden
zu sein, umfaßt,
wobei der Client derart ausgestaltet ist, dass eine auf den bearbeiteten
Daten basierende Anfrage gesendet wird und daraufhin eine Bestätigung von
einem verbundenen Server empfangen wird, wobei die Datenbank mindestens
die bearbeiteten Daten nur bei einer von dem Client empfangenen
Bestätigung
speichert.
-
Vorteilhafterweise
verwendet die Vorrichtung XML Strukturen. Vorteilhafterweise umfasst
die Anfrage die bearbeiteten Daten. Vorteilhafterweise ist die Anfrage
asynchron zum Server.
-
Des
weiteren wird die Aufgabe durch einen Server für die Organisation von Daten
und Bearbeitungsanfragen in einem Datenverwaltungssystem gelöst, der
eine Schnittstelle zum Empfangen von Anfragen und zum Senden von
Bestätigungen,
wobei die Schnittstelle geeignet ist, mit einem Client gemäß Anspruch
1 verbunden zu sein, und eine Datenbank zum Speichern und zum Bereitstellen
von Daten und bearbeiteten Daten für den Client zu empfangen,
umfasst, wobei der Server derart ausgestaltet ist, dass eine auf
den bearbeiteten Daten des Clients basierende Anfrage empfangen
wird und daraufhin die Bestätigung
vom Server gesendet wird.
-
Vorteilhafterweise
umfasst die Bestätigung die
bearbeiteten Daten. Vorteilhafterweise umfasst die Bestätigung die
Spiegelung der Datenbank mit mindestens den bearbeiteten Daten.
Vorteilhafterweise ist die Bestätigung
asynchron zum Client. Vorteilhafterweise verwendet die Vorrichtung
XML Strukturen.
-
Des
weiteren wird die Aufgabe durch ein Verfahren für die Organisation von Daten
und Bearbeitungsanfragen in einem Datenverwaltungssystem gelöst, das
die Schritte Registrieren von verarbeiteten Daten durch einen Client,
wobei die bearbeiteten
-
Daten
durch eine Komponente erzeugt werden, Senden und Empfangen einer
auf den bearbeiteten Daten basierende Anfrage vom Client an einen Server,
Speichern der bearbeiteten Daten in einer Datenbank des Servers,
Senden und Empfangen einer auf den bearbeiteten Daten basierende
Bestätigung,
und Speichern mindestens der bearbeiteten Daten nach Empfang der
Bestätigung
in einer Datenbank des Clients, umfasst.
-
Vorteilhafterweise
liegen Daten in einer XML Datenstruktur vor. Vorteilhafterweise
umfasst die Anfrage die bearbeiteten Daten. Vorteilhafterweise umfasst
die Bestätigung
die bearbeiteten Daten. Vorteilhafterweise umfasst die Bestätigung die
Spiegelung der Datenbank mit mindestens den bearbeiteten Daten.
Vorteilhafterweise ist/sind die Anfrage und/oder die Bestätigung asynchron
zum Server und/oder Clients.
-
Die
oben genannte Aufgabe, und weitere Merkmale und Vorteile der vorliegenden
Erfindung werden durch die folgende detaillierten Darstellungen
offensichtlicher. Es zeigen:
-
1 ein
Beispiel eines Architekturmusters von einem Datenbankmodul aus dem
Stand der Technik,
-
2 eine
erste Ausgestaltung eines Architekturmusters der Erfindung, die
einen Datenbankmodul-Server und -Client umfasst,
-
3 eine
weitere Ausgestaltung der Erfindung, die einen Datenbankmodul-Server
und -Client umfasst,
-
4 ein
Beispiel eines internen Aufbaus eines Datenbankmodul-Clients,
-
5 ein
Beispiel einer Implementierung von Neuberechnungs Plug-ins in einem
Datenbankmodul-Server,
-
6 ein
Beispiel eines internen Aufbaus eines Datenbankmodul-Servers,
-
7 ein
Beispiel eines Zuweisungsablaufs einer Variablen zwischen Komponenten
und einem Datenbankmodul-Client,
-
8 ein
Beispiel eines Datenanfrageablaufs zwischen Komponenten und einem
Datenbankmodul-Client,
-
9 ein
Beispiel eines Datenänderungsablaufs
innerhalb einer Ausgestaltung der Erfindung,
-
10 ein
weiteres Beispiel eines Datenänderungsablaufs
innerhalb einer Ausgestaltung der Erfindung, in der die Daten durch
einen Server angepasst werden,
-
11 ein
Beispiel eines Datenanfrageablaufs durch eine Komponente, während eine
Datenänderung
einer anderen Komponente durchgeführt wird, und
-
12 ein
Beispiel eines Datenänderungsablaufs,
in der mehrere Änderungsanfragen
von Komponenten auf einem Server nacheinander eingereiht und abgearbeitet
werden.
-
1 zeigt
ein Beispiel eines Architekturmusters eines Datenverwaltungssystem 14 zur
Speicherung, Verarbeitung, Verwaltung und Verteilung von Daten mit
Hilfe einer Verknüpfung
und/oder Vernetzung eines Datenbankmoduls 1 mit Elementen, wobei
die Elemente eine erste Komponente 4, eine zweite Komponente 5,
eine Neuberechnungs-Komponente 6 und eine externe Komponente 7 umfassen.
-
Das
Datenbankmodul 1 umfasst einen Beobachter 2 und
Daten, wobei die Daten vorteilhafterweise in Form von einer Datenbank 3 gespeichert
sind. Des Weiteren umfasst das Datenbankmodul 1 die Strukturierung
und die Organisation der Daten. Die Daten liegen dadurch zum Beispiel
in Schemen vor. XML-Schema
ist eine komplexe Sprache zur Beschreibung eines XML- Typsystems. Dieses
XML-Typsystem umfasst die Spezifikation neuer XML-Elemente, deren
Attribute, sowie deren Kindelemente. Wie dem Fachmann bekannt, ist
das Datenbankmodul 1 im Allgemeinen das Konzept, die theoretische Grundlage,
für ein
Datenbanksystem und bestimmt, auf welche Art und Weise Daten prinzipiell
in einem Datenbanksystem gespeichert werden und wie man die Daten
manipulieren (zugreifen und ändern)
kann. Ein Datenbanksystem ist ein System zur elektronischen Datenverwaltung.
-
Der
Beobachter 2 ist ein Entwurfsmuster aus dem Bereich der
Softwareentwicklung und gehört
zu der Kategorie der Verhaltensmuster, welches eines der GoF-Muster
(Gang of Four-Muster) ist. Wie dem Fachmann bekannt, beschreiben
Verhaltensmuster die Interaktion zwischen Objekten und komplexen Kontrollflüssen. Der
Beobachter 2 ermöglicht
die Weitergabe von Änderungen
von Daten, im speziellen von Objekten, an angemeldete Elemente,
wobei die Elemente sich am Datenbankmodul 1 und somit am
Beobachter 2 registrieren müssen. Des Weiteren beschreibt
ein Entwurfsmuster eine bewährte,
dem Fachmann bekannte Schablone für ein Entwurfsproblem und stellt
damit eine wieder verwendbare Vorlage zur Problemlösung dar.
In diesem Fall werden Änderungen
von Daten an die erste Komponente 4, die zweite Komponente 5,
die Neuberechnungs-Komponente 6 und die externe Komponente 7 weitergeleitet.
-
In
diesem Beispiel befindet sich die externe Komponente 7 als
einziges Element im Bereich der Datenverwaltung eines Fertigungsprozesses,
während
die anderen Komponenten 4, 5, 6 sich
in einem anderen Bereich wie z. B. der Gesamtdatensicherung befinden,
was die Erfindung jedoch nicht darauf beschränkt. Des Weiteren können sich
die externe Komponente 7 von den anderen Komponenten 4, 5, 6 aufgrund
der Anwendungsgebiete in den Parametern und Variablen unterscheiden.
Die verschiedenen Variablen werden dann normalerweise durch eine Fassade
oder einer Anpassung der Variablen in die Datensicherung integriert.
-
Alle
Elemente 4, 5, 6, 7 haben Zugriff
auf die Daten des Datenbankmoduls 1 über den Beobachter 2.
Die Daten können über den
Beobachter 2 von der Datenbank 3 an die oben genannten
Elemente 4, 5, 6, 7 geschickt
werden und/oder umgekehrt. Die Komponenten 4, 5, 6 und 7 sind
jeweils über
die Verbindungen 9, 10, 12 und 11 mit
der Datenbank 3 verbunden. Die Komponente 6 erhält über die
Verbindung 13 Daten von der Datenbank 3 zur Neuberechnung. Zwar
können
die Komponenten 4, 5 und 7 ebenfalls Daten
aus der Datenbank 3 laden und/oder lesen, doch aus Gründen der
Klarheit wurden diese Pfeile, die ähnlich wie Pfeil 13 aussehen
könnten,
nicht dargestellt.
-
Die
erste Komponente 4 und die zweite Komponente 5 sind
jeweils eine Sammlung von Funktionen, die vorteilhafterweise in
einer Bibliothek untergebracht sind. Wenn eine Komponente eine Anfrage an
die Daten stellt, wird normalerweise mindestens eine Funktion Daten
vom Datenbankmodul 1 abfragen und sie verarbeiten. Veränderte,
bearbeitete Daten werden dann zurück an die Datenbank 3 des
Datenbankmoduls 1 geschickt.
-
2 zeigt
eine erste Ausgestaltung der Erfindung eines Architekturmusters
eines Datenverwaltungssystems 14a zur Speicherung, Verarbeitung, Verwaltung
und/oder Verteilung von Daten mit Hilfe einer Verknüpfung und/oder
Vernetzung eines Datenbankmodul-Servers 1a, eines Datenbankmodul-Clients 1b mit
Elementen, wobei die Elemente eine erste Komponente 4,
eine zweite Komponente 5 und eine Neuberechnungs-Komponente 6 umfassen. Die
Komponenten 4, 5, 6 entsprechen denen
aus 1 und sind über
die bereits in 1 besprochenen Verbindungen 9a, 10a, 12a, 13a an
den Client 1b angeschlossen.
-
Der
Datenbankmodul-Server 1a umfasst die Daten 3b und
die Schnittstelle 15a, ist durch eine Verbindung 16 über die
Schnittstelle 15a mit dem Datenbankmodul-Client 1b angeschlossen
und wird physisch vom besagten Client 1b und den Komponenten 4, 5, 6 durch
eine Verarbeitungsgrenze 8a getrennt. Die Verarbeitungsgrenze 8a bezeichnet
in diesem Fall das Gebiet eines Fertigungsprozesses, in dem der
Client 1b und die Komponenten 4, 5, 6 liegen,
wobei die Verarbeitungsgrenze 8a eine physische oder/und
eine gedankliche Trennung der beschriebenen Einheiten darstellen
kann. Der Server 1a kann selbstverständlich mit mehreren Clients 1b verbunden
sein und ist nicht auf einen einzigen Client beschränkt.
-
Der
Datenbankmodul-Client 1b umfasst die Daten 3c,
eine Schnittstelle 15b und einen Observer 2a und
ist über
von der Schnittstelle 15b durch die Verbindung 16 an
den Datenbankmodul-Server 1a angeschlossen. Des weiteren
ist der Client 1b mit der ersten Komponente 4,
der zweiten Komponente 5 und der Neuberechnungs-Komponente 6 jeweils über die
Verbindungen 9a, 10a und 12a verbunden.
-
Die
Komponente 5 erzeugt die Daten 3a, die von den
abgerufenen und/oder ursprünglichen
Daten des Clients 1b abweichen und aus der Rechnung mit einer
Funktion der Komponente 5 stammen können oder einfach nur neu zum
Beispiel durch einen Benutzer gesetzt wurden, und sendet sie via
der Verbindung 10a an den Client 1b zurück. Als
Nächstes
sendet der Client 1b eine Anfrage von der Schnittstelle 15b via
der Verbindung 16 an den Datenbankmodul-Server 1a.
Dieser Anfrage wird dann vom Server 1a abgearbeitet oder
wenn zu viele Anfragen anstehen, erst an eine Warteschlange des
Servers 1a verwiesen. Wenn die Anfrage vom Server 1a abgearbeitet
wird, werden die ursprünglichen
Daten des Servers 1a der Anfrage entsprechend in die Daten 3b abgeändert und
gespeichert. Die Anfrage umfasst die Daten 3a selbst. Nach
Abarbeitung der Anfrage erfolgt eine Benachrichtigung durch den
Server 1a, die den Client 1b über die Datenänderungen
informiert. Einerseits kann der Server 1a die Datenänderungen
in Form einer Benachrichtigung direkt an den Client 1b schicken,
wobei die Änderungen
entweder nur die zu ändernden
Daten 3b oder die komplette Datenbank des Servers 1a als
Spiegelung umfasst. An schließend
benachrichtigt der Client 1b die Komponenten über die
Datenänderung,
wodurch die Komponente 5 die aktualisierten Daten 3d erhält. Bei der
Nummerierung der Daten 3b, 3c und 3d soll
die schrittweise Abfolge der Aktualisierung der Daten bei den verschiedenen
Elementen 1a, 1b und 5 verdeutlicht werden.
Die veränderten
Daten 3a selbst werden zum Client 1b geschickt
und an die Komponente 5 anschließend weitergeleitet.
-
3 zeigt
eine weitere Ausgestaltung der Erfindung, die einen Datenbankmodul-Server 1a und einen
Datenbankmodul-Client 1b umfasst.
Beide Datenbankmodule 1a und 1b umfassen jeweils
eine öffentliche
XML Datenstruktur 17 (Extensible Markup Language) und sind über die
in 2 erwähnte
Verbindung 16 miteinander verbunden. Die XML Datenstruktur 17 definiert
die Sprache, mit der zwischen dem Server 1a und dem Client 1b und
weiteren wie in 2 erwähnten Komponenten kommuniziert wird.
Dabei wird die Datenstruktur 17 vom Server 1a ursprünglich definiert
oder liegt vorbestimmt auf dem Server 1a und wird zumindest
an den Client 1b gesendet. In einem anderen Fall kann der
Client 1b diese Struktur 17 selbst vom Server 1a kopieren.
Der Inhalt der Struktur ist weder dem Client 1b noch dem Server 1a bekannt,
wodurch Datenerweiterungen ohne die Wiederkompilierung von Komponenten möglich sind.
-
4 zeigt
eine detaillierte Strukturierung eines wie in 2 gezeigten
Datenbankmodul-Clients, der einen DM-Observer 19 (Datenbankmodul-Beobachter)
und eine abstrakte XML Struktur 18 umfasst. Die XML Struktur 18 umfasst
in diesem Fall die Klasse Observer 19, was durch den Kompositions-Strich 22 beschrieben
wird. Eine Klasse ist in der Objektorientierung ein abstrakter Oberbegriff
für die
Beschreibung der gemeinsamen Struktur und des gemeinsamen Verhaltens
von Objekten (Klassifizierung).
-
Der
Observer 19 hat über
die Operation 29 (notify(XML_Path) = 0;) keine Anwendung
implementiert. Dagegen wird das Element SpecificObserver 20,
insbesondere durch die Operation 30 (notify(XML_Path);)
im Observer 19 vollständig
spezifiziert. Die Pfeilspitze des Strichs 23, wobei der
Strich 23 eine Generalisierungsbeziehung zwischen Observer 19 und
SpecificObserver 20 darstellt, wird beim zu spezifizierenden
Element, in diesem Fall beim Observer 19, gezeichnet. Die
abstrakte XML Struktur 18 umfasst die öffentliche XML Datenstruktur 17,
die Operation 25 (attach(DMObserver, XML_Path)), die Operation 26 (set(XML_Path,
XML_String) = 0;) und die Operation 27 (get(XML_Path):XML_String);).
Wie an Hand der Darstellung des Strichs 24 erkennbar, wird
die XML Struktur 18 durch den DM-Client 21, insbesondere durch
die Operation 28, spezifiziert. Der Client 21 umfasst
die Operation 28 (set(XML_Path, XML_String)), wobei der
XML_String eine Struktur definiert. Die Operation 26 legt
fest, dass keine XML Struktur in der abstrakten XML Struktur 18 implementiert
ist, aber durch die Operation 27 eine XML Struktur über den
Client 21 implementiert wird. Die Operation 25 legt
fest, dass der Observer 19 als Klasse zur XML Struktur 18 hinzugefügt wird.
XML_Path ist eine Anfragesprache, um Teile eines XML-Dokuments zu
adressieren.
-
5 zeigt
eine weitere Ausgestaltung der Erfindung, die einen Datenbankmodul-Server 1a und einen
Datenbankmodul-Client 1b umfasst.
Der Server 1a umfasst eine öffentliche XML Datenstruktur 17 und
drei Neuberechnungs Plug-ins 31, 31a, 31b in diesem
Fall. Die Datenstruktur 17 und die Verbindung 16 entsprechen
jeweils der Struktur 17 und der Verbindung 16 aus 3.
Die Plug-ins 31, 31a, 31b spezifizieren
jeweils die Berechnung der Variablen und ermöglichen dadurch eine universelle
Einsetzbarkeit der Server abhängig
von ihrer Arbeitsumgebung. Des Weiteren umfassen die Plug-ins 31, 31a, 31b jeweils
eine eigene Datenstruktur 32 (aus Gründen der Klarheit wurde nur
die erste Datenstruktur 32 des Plug-in 31 nummeriert).
-
6 zeigt
eine detaillierte Strukturierung eines Datenbankmodul-Servers 1a in
Verbindung verschiedener Komponente, wie das Neuberechnungs Plug-in 34,
das Specific Plug-in 35, die XML Struktur 33,
die abstrakte XML Struktur 18 und die Konfigurationsdatei 36.
Die abstrakte XML Struktur 18 entspricht der Struktur 18 aus 4.
Die Konfigurationsein stellungen des Servers 1a und/oder
des Neuberechnungs Plug-ins 34 lassen
sich in einer Konfigurationsdatei 36 abspeichern. Das Neuberechnungs Plug-in 34 ist
eine Klasse des Servers 1a und wird durch den Specific
Plug-in 35 spezifiziert. Die Klassifizierung wird an Hand
des Strichs 40 und die Spezifizierung an Hand des Pfeils 42 dargestellt.
Des Weiteren ist die XML Struktur 33 eine Klasse des Servers 1a und
spezifiziert die abstrakte XML Struktur 18. Die Klassifizierung
wird an Hand des Strichs 38 und die Spezifizierung an Hand
des Pfeils 37 dargestellt.
-
7 zeigt
ein Beispiel eines Zuweisungsablaufs einer Variablen zwischen Komponenten 4 und 5 und
einem Datenbankmodul-Client 1b, wobei der Ablauf die 4
Schritte A1, A2, A3 und A4 umfasst. Des Weiteren ist ein Datenbankmodul-Server 1a dargestellt.
Alle aufgezählten
Elemente 4, 5, 1b und 1a von 7 entsprechend
denen aus 2. Auf dem Client 1b und
dem Server 1a ist der Variable „A" der Wert 3.5 anfänglich und bis auf weiteres
zugewiesen. Von den Elementen 4, 5, 1b und 1a ausgehend
laufen die zeitlichen Achsen von oben nach unten. Im A1 Schritt
wird von der ersten Komponente 4 ein attach-Befehl an den
Client 1b geschickt, um alle Änderungen des Wertes „A" zu bekommen. Im
A2 Schritt benachrichtigt der Client 1b die erste Komponente 4,
dass der Wert der Variable „A" 3.5 beträgt. Dieser
Wert wird der ersten Komponente 4 zugewiesen. Im A3 Schritt
wird von der zweiten Komponente 5 ein attach-Befehl an
den Client 1b geschickt, um alle Änderungen des Wertes „A" zu bekommen. Im A4
Schritt benachrichtigt der Client 1b die zweite Komponente 5,
dass der Wert der Variable „A" 3.5 beträgt. Dieser
Wert wird der zweiten Komponente 5 zugewiesen. Während dieses
Ablaufs ist keine Kommunikation mit dem Server 1a z. B.
zur Aktualisierung der Daten nötig.
-
8 zeigt
ein Beispiel eines Datenanfrageablaufs zwischen Komponenten 4 und 5 und
einem Datenbankmodul-Client 1b, wobei der Ablauf die 4 Schritte
B1, B2, B3 und B4 umfasst. Des Weiteren ist ein Datenbankmodul-Server 1a dargestellt.
Alle auf gezählten
Elemente 4, 5, 1b und 1a von 8 entsprechend
denen aus 2. Auf dem Client 1b und dem
Server 1a ist der Variable „A" anfänglich
und bis auf weiteres der Wert 3.5 zugewiesen. Von den Elementen 4, 5, 1b und 1a ausgehend
laufen die zeitlichen Achsen von oben nach unten. Im B1 Schritt
wird von der ersten Komponente 4 ein get-Befehl an den Client 1b geschickt,
um den Wert der Variable „A" abzufragen. Im B2
Schritt erhält
die erste Komponente 4 vom Client 1b den Wert
3.5 der Variable „A" durch einen return-Befehl
zugeschickt. Im B3 Schritt wird von der zweiten Komponente 5 ein
get-Befehl an den Client 1b geschickt,
um den Wert der Variable „A" abzufragen. Im B4
Schritt erhält
die zweite Komponente 5 vom Client 1b den Wert
3.5 der Variable „A" durch einen return-Befehl
zugeschickt. Während
dieses Ablaufs ist keine Kommunikation mit dem Server 1a z.
B. zur Aktualisierung der Daten nötig.
-
9 zeigt
ein Beispiel eines Datenänderungsablaufs
innerhalb einer Ausgestaltung der Erfindung, wobei der Ablauf die
8 Schritte C1, C2, C3, C4, C5, C6, C7 und C8 zwischen einem Datenbankmodul-Server 1a,
einem Datenbankmodul-Client 1b, einer ersten Komponente 4 und
einer zweiten Komponente 5 umfasst. Alle aufgezählten Elemente 4, 5, 1b und 1a von 9 entsprechend
denen aus 2. Auf dem Client 1b und
dem Server 1a ist der Variable „A" anfänglich
der Wert 3.5 zugewiesen, der während des
Ablaufs geändert
wird. Von den Elementen 4, 5, 1b und 1a ausgehend
laufen die zeitlichen Achsen von oben nach unten. Bevor die folgenden
Schritte ausgeführt
werden können,
muss der Zuweisungsablauf, wie er in 7 beschrieben
wird, zwischen den Komponenten 4, 5 und dem DM-Client 1b durchgeführt werden.
Im C1 Schritt wird von der ersten Komponente 4 ein set-Befehl
an den Client 1b geschickt, um den Wert der Variable „A" auf 4 zu setzen.
Im C2 Schritt schickt der Client 1b eine Änderungsanfrage an
den Server 1a, die den Wert der Variable „A" auf 4 setzen soll.
Im C3 Schritt verändert
der Server 1a den Wert der Variable „A" auf 4 in seiner Datenbank. Dieser Wert
entspricht dem durch die Änderungsanfrage übertragenen
Wert. Im C4 Schritt werden nötige
Neuberechnungen durchgeführt,
die mit der Änderung des
Variablenwerts „A" einhergehen. Diese
Neuberechnungen betreffen andere Variablen oder Formeln, die abhängig von
der Variable „A" sind. Im C5 Schritt
wird eine Benachrichtung vom Server 1a an den Client 1b geschickt.
Die Benachrichtigung umfasst Datenänderungen durch den Server 1a,
die im Schritt C2 vom Client 1b an den Server 1a angefragt worden
sind. Diese Datenänderungen
werden entweder in Form von der gesamten Datenbank des Servers 1a an
den Client 1b gespiegelt oder nur in Form der veränderten
Daten übertragen.
Des Weiteren können
die Datenänderungen
auch die im Schritt C4 kalkulierten Neuberechnungen umfassen. In
diesem Fall wird der Wert 4 der Variable „A" sowie weitere Neuberechnungen an den
Client 1b übertragen. Im
C6 Schritt werden die Datenänderungen
in die Datenbank des Clients 1b importiert, wodurch die
Datenbank des Clients 1b nun wieder der Datenbank des Servers 1a gleicht.
Im C7 Schritt benachrichtigt der Client 1b die erste Komponente 4,
dass der neue Wert der Variable „A" nun 4 beträgt. Im C8 Schritt benachrichtigt
der Client 1b die zweite Komponente 5, dass der
neue Wert der Variable „A" nun 4 beträgt.
-
10 zeigt
ein weiteres Beispiel eines Datenänderungsablaufs innerhalb einer
Ausgestaltung der Erfindung, in der die Daten angepasst werden, wobei
der Ablauf die 8 Schritte D1, D2, D3, D4, D5, D6, D7 und D8 sowie
einen Datenbankmodul-Server 1a,
einen Datenbankmodul-Client 1b, eine erste Komponente 4 und
eine zweiten Komponente 5 umfasst. Bevor die folgenden
Schritte ausgeführt
werden können,
muss der Zuweisungsablauf, wie er in 7 beschrieben
wird, zwischen den Komponenten 4, 5 und dem DM-Client 1b durchgeführt werden.
Die 10, ihre Elemente 1a, 1b, 4, 5 und
ihre 8 Schritte entsprechen der 9 und ihren
technischen Merkmalen. In diesem Beispiel wird statt dem Wert 4
der Variable „A" der Wert 3.9 in
den Schritten D1 und D2 übergeben.
In dem Schritt D3 wird dann statt 3.9 der vom Server 1a aufgerundete
Wert 4 in die Datenbank implementiert. Natürlich ist der Gegenstand der
Erfindung nicht nur auf das Aufrunden der ursprünglichen Daten durch den Server
beschränkt,
sondern kann jegliche mathematische Operation ausführen.
-
11 zeigt
ein Beispiel eines Datenanfrageablaufs durch eine Komponente, während eine Datenänderung
einer anderen Komponente durchgeführt wird, wobei der Ablauf
die 10 Schritte E1, E2, E3, E4, E5, E6, E7, E8, E9 und E10 sowie
einen Datenbankmodul-Server 1a, einen Datenbankmodul-Client 1b,
eine erste Komponente 4 und eine zweiten Komponente 5 umfasst.
Bevor die folgenden Schritte ausgeführt werden können, muss
der Zuweisungsablauf, wie er in 7 beschrieben
wurde, zwischen den Komponenten 4, 5 und dem DM-Client 1b durchgeführt werden.
Die Elemente 1a, 1b, 4, 5 der 11 entsprechen
den technischen Merkmalen der 9. Die Schritte
E1, E2, E3, E6, E7, E8, E9 und E10 entsprechen jeweils den Schritten
C1 bis C8 der 9. Die Schritte E4 und E5 entsprechen
jeweils den Schritten B3 und B4 von 8. Da die
Datenänderungensanfrage
des Clients 1b noch nicht vom Server 1a abgearbeitet
wurde und damit die Daten der Datenbank des Clients 1b und
die Daten der Komponenten noch nicht aktualisiert wurden, erhält die zweite
Komponente 5 im Schritt E5 den Wert 3.5 für die Variable „A".
-
12 zeigt
ein Beispiel eines Datenänderungsablaufs,
in der mehrere Änderungsanfragen von
Komponenten auf einem Server nacheinander eingereiht werden, wobei
der Ablauf die 15 Schritte F1, F2, F3, F4, F5, F6, F7, F8, F9, F10,
F11, F12, F13, F14, F15 und F16 sowie einen Datenbankmodul-Server 1a,
einen Datenbankmodul-Client 1b, eine erste Komponente 4 und
eine zweiten Komponente 5 umfasst. Bevor die folgenden
Schritte ausgeführt
werden können,
muss der Zuweisungsablauf, wie er in 7 beschrieben
wurde, zwischen den Komponenten 4, 5 und dem DM-Client 1b durchgeführt werden.
Die Elemente 1a, 1b, 4, 5 der 12 entsprechen
den technischen Merkmalen der 2. Die Schritte
F1, F2, F3, F4 entsprechen jeweils den Schritten E1 bis E3 und E6
aus 11. Die Schritte F5 und F6 basieren jeweils auf
den Schritten F1 und F2, wobei der Variable „A" der Wert 5 statt 4 durch die zwei te
Komponente 5 zugewiesen wird. Die Schritte F7 bis F10 entsprechen
jeweils den Schritten E7 bis E10. Die Schritte F11 bis F16 basieren
jeweils auf den Schritten F3, F4, F7 bis F10, wobei der Variable „A" der Wert 5 statt
4 zugewiesen wird. Dadurch soll verdeutlicht werden, dass die nächste Datenaktualisierung
des Servers 1a, des Clients 1b und der Komponenten 4 und 5 erst
mit Beendigung der vorherigen Datenaktualisierung beginnt.