<Desc/Clms Page number 1>
Die vorliegende Erfindung betrifft ein Programm zur Abfrage und Bearbeitung von Daten, die in unterschiedlichen Datenbanksystemen gespeichert sind.
In der elektronischen Datenverarbeitung werden üblicherweise relationale Datenbanksysteme dazu verwendet, eine Vielzahl von Daten, wie etwa Kundendaten, Bestellungen, Lieferungen oder dergleichen abzuspeichern. Zum Zweck der Abfrage und Manipulation dieser Daten werden verschiedene Abfragesprachen verwendet, die jeweils an das Datenbanksystem angepasst sind.
In grösseren Organisationen sind oftmals verschiedene Datenbanksysteme parallel im Einsatz.
Dadurch kann eine Reihe von Problemen entstehen : * Grundsätzlich zusammengehörige Daten werden getrennt (Informationsver- lust) ; . Die selben Daten werden mehrfach gespeichert (Redundanz) ; * Die selben Daten werden in unterschiedlichen Formaten (welche Tabellen,
Beziehungen, Felder, Datentypen) gespeichert (Redundanz, Inkonsistenz) ; * Gleichartige Daten werden unterschiedlich repräsentiert (Datentyp, Feldlänge, Genauigkeit,...) (Inkonsistenz) ; * Die unterschiedlichen Datenbanksysteme stellen unterschiedliche Daten- zugriffsmethoden zur Verfügung ;
Die oben genannten Probleme führen zu Inkonsistenzen im Datenmaterial, Informationsverlust, hohem Aufwand beim "Synchronisieren" der Daten, hohem administrativem Aufwand und zu Schwierigkeiten beim Verknüpfen von Daten.
Ein weiterer Problemkreis stellt sich auf der Ebene der Benutzeroberfläche dar.
Auf verschiedenen Anwendungsgebieten haben sich einige wenige Programme durchgesetzt (Textverarbeitung, Tabellenkalkulation,...). Diese sogenannte Standardsoftware ist weit verbreitet und auf den jeweiligen Einsatzzweck gut abgestimmt. Daten, die beim Arbeiten mit Standardsoftware entstehen, werden in der Regel in einem proprietären Dateiformat als Datei auf einem Datenträger gespeichert.
Das Verknüpfen von Daten, die in einem Datenbanksystem gespeichert sind, mit der Standardsoftware ist problematisch. Lesezugriffe sind für Anwender mit einfachen Abfrageassistenten möglich, allerdings wird dabei Wissen über die Datenbankstruktur vorausgesetzt. Schreibzugriffe werden in der Regel nicht unterstützt.
<Desc/Clms Page number 2>
Ein einfaches und häufig vorkommendes Beispiel für ein Problem aus diesem Bereich : Man schreibt in der Textverarbeitung einen Brief an einen Geschäftspartner. Die Adressdatenbank enthält alle benötigten Informationen über diesen Ge- schäftspartner. Problematisch ist jedoch das Finden von Name und Anschrift in der Adressdatenbank und das Übernehmen des Suchergebnisses in den Brief.
Wirklich lösen lässt sich eine derartige Problematik nur mit Programmierkenntnissen. Standardsoftware enthält meist eine Makroprogrammiersprache und/oder lässt den Zugriff auf ihre Daten über eine öffentliche Klassenbibliothek zu. In jedem Fall muss man sich in einer bestimmten Programmiersprache für eine bestimmte Datenzugriffsmethode entscheiden, mit selbst geschriebenem Programmcode Datenbankabfragen stellen und die Ergebnisse übernehmen. Für Anwender ohne Programmierkenntnisse ist diese Vorgangsweise undurchführbar und für Fachleute zeitaufwendig.
Ferner treten bei der Entwicklung von Software zunehmende Probleme auf. Es ist zwar in vielen Bereichen erforderlich, Datenbanksysteme einzusetzen, jedoch gibt es praktisch keine standardisierte Datenzugriffsmethode. Grundsätzlich bestehen zwei Möglichkeiten, um Software mit Datenbankzugriff zu erstellen : 'Das Datenbanksystem enthält eine Programmiersprache.
. Das Datenbanksystem enthält eine Schnittstelle, über die höhere Program- miersprachen auf Datenbanken zugreifen können.
Beide Möglichkeiten unterliegen keinerlei Normierung. Jeder Hersteller eines Datenbanksystems legt die enthaltene Programmiersprache auf die Fähigkeiten seines Datenbanksystems aus und erzeugt damit eine eigene Programmiersprache, die mit anderen Systemen naturgemäss inkompatibel ist. Schnittstellen für höhere Programmiersprachen sind äusserst zahlreich, und die Treiber der einzelnen Datenbanksysteme sind meistens inkompatibel.
Eine Möglichkeit, diese Probleme zu verringern bestünde darin, sich auf ein Datenbanksystem festzulegen. Ein relationales Datenbankmodell führt jedoch bei grossen Datenbeständen zu komplexen Datenbankstrukturen mit einer Vielzahl von Entities (Tabellen) und Relations (Beziehungen).
Logisch zusammengehörige Datenbestände sind oft aus Gründen der Performance, Redundanz und Konsistenz in mehreren physischen Tabellen gespeichert. Es ist aufwendig, Beziehungen definieren, welche Datenzeilen (unterschiedlicher) Tabellen zueinander gehören und die zusammengehörigen Daten zu verknüpfen.
Unterschiedliche Abteilungen eines Unternehmens haben vielfach unterschiedliche, auf die jeweiligen Erfordernisse angepasste Datenbanken. Oft ist es notwendig, die Daten unterschiedlicher Abteilungen (die in unterschiedlichen Datenbanken gespeichert sind), zu verknüpfen (z. B. für statistische Analysen). Dabei treten die oben beschriebenen Probleme auf.
<Desc/Clms Page number 3>
Aufgabe der vorliegenden Erfindung ist es, diese Nachteile zu vermeiden und ein Programm zu schaffen, das es ermöglicht in einfacher Weise Daten zu handhaben, die in verschiedenen Datenbanksystemen gespeichert sind. Dabei soll eine möglichst einfache und sichere Manipulation der Daten gewährleistet sein.
Erfindungsgemäss ist vorgesehen, dass die Daten aus den einzelnen Datenbanksystemen analysiert und ausgelesen werden, dann zu den einzelnen Datentypen in einem ersten Speicher Steuerinformationen abgespeichert werden, die Datenwerte in einem zweiten Speicher in einer verallgemeinerten Form abgespeichert werden, worauf die Daten in einer einheitlichen Benutzerschnittstelle dargestellt und ausgegeben werden, wobei die Benutzerschnittstelle die Möglichkeit bietet, die Daten zu manipulieren, wobei die entsprechenden Datenwerte aus dem zweiten Speicher entnommen werden, der jeweiligen Bearbeitung unterzogen werden und unter Verwendung der Steuerinformationen aus dem ersten Datenspeicher in das jeweilige Datenbanksystem zurückgeschrieben werden.
Wesentlich an der vorliegenden Erfindung ist, dass die Datenquellen, die in den einzelnen Datenbanksystemen repräsentiert sind grundsätzlich erhalten bleiben.
Dies bedeutet, dass benutzerspezifische Anwendungsprogramme, die auf diese Daten zugreifen, bzw. diese Daten generieren und manipulieren, in unveränderter Weise beibehalten werden können. Für datenbankübergreifende Manipulationen und Darstellungen wird jedoch ein einheitliches Programm verwendet, das im Kern unabhängig von den jeweiligen Datenbanksystemen ist. Die datenbankspezifischen Kommunikationsmodule sind in einer eigenen Zugriffsschicht getrennt von dem übrigen Programm zusammengefasst, sodass bei neu hinzutretenden Datenbanksystemen oder bei Änderungen in den Abfragemodalitäten für bestehende Datenbanksysteme lediglich entsprechende Anpassungen in der Zugriffsschicht durchgeführt werden müssen.
Ein weiterer wesentlicher Aspekt der Erfindung ist, dass die in den Datenbanksystemen enthaltenen Daten in einer standardisierten und verallgemeinerten Form abgespeichert werden, um einen einheitlichen Zugriff und eine einheitliche Bearbeitung zu gewährleisten. Da das erfindungsgemässe Programm nicht nur die Möglichkeit einer Datenabfrage, sondern auch die Möglichkeit einer Manipulation von Daten vorsieht, das heisst, dass die Daten neu geschrieben, geändert, kopiert, usw. werden können, müssen für eine Rückumwandlung der Daten in die spezifischen Formate der einzelnen Datenbanksysteme besondere Vorkehrungen getroffen werden. Eine bevorzugte Möglichkeit ist die Abspeicherung von Daten in der Form skalarer Werte. Darunter versteht man Datenstrukturen, die aus mehreren Elementen bestehen.
Ein Element ist dabei der Datenwert selbst, der in der Form einer Zeichenkette vorliegt. Weitere Elemente definieren den Datentyp und gegebenenfalls vorhandene Restriktionen, die beispielsweise zulässige
<Desc/Clms Page number 4>
Wertebereiche definieren. So kann beispielsweise festgelegt werden, dass ein Datenelement, das eine Postleitzahl repräsentiert, ein ganzzahliger Wert ist, der nur zulässig ist, wenn er zwischen 1000 und 9999 liegt. Auf diese Weise können Fehlerbehandlungsprozeduren und dergleichen effizienter gestaltet werden. Allgemein können beispielsweise die Datentypen Zahl (Festkommazahl oder Gleitkommazahl), Zeichenkette, Datum, Uhrzeit, Datum mit Uhrzeit, logischer Wert oder dergleichen unterschieden werden.
Datenwerte können auch als Nullwerte abgespeichert sein, d. h. dass durch eine besondere Kenzeichnung festgelegt wird, dass der Datenwert nicht null ist, sondern überhaupt nicht vorliegt.
In einer besonders bevorzugten Ausführungsvariante des erfindungsgemässen Programms ist vorgesehen, dass ein erster Übersetzungsmodul vorgesehen ist, der die in einer einheitlichen Abfrage- und Manipulationssprache formulierten Abfragen und Manipulationsbefehle in Befehle umwandelt, die an das jeweilige Datenbanksystem angepasst sind. Auf diese Weise wird nicht nur der Datenaustausch vereinheitlicht und standarisiert, sondern es werden auch die logischen Operationen wie Bedingungen, Schleifen oder dergleichen in einfacher und handhabbarer Weise vereinheitlicht.
Die Anwenderfreundlichkeit kann insbesondere dadurch gesteigert werden, dass ein zweiter Übersetzungsmodul vorgesehen ist, der dazu ausgebildet ist, mit bestehenden Softwareprogrammen zusammenzuarbeiten und Daten auszutauschen. Eine Vielzahl von Anwendern ist es gewöhnt, mit bestimmten Standardprogrammen, wie etwa HTML, MICROSOFT EXCEL, MICROSOFT WORD oder dergleichen zu arbeiten. Durch das Anbieten entsprechender Schnittstellen kann die Arbeit mit dem erfindungsgemässen Programm für solche Benutzer wesentlich vereinfacht werden, da es in einfacher Weise möglich ist, aus den obigen Programmen auf die Daten zuzugreifen und diese gegebenenfalls zu bearbeiten.
Eine weitere Vereinfachung der Benutzung kann dadurch erreicht werden, dass die einheitliche Abfrage- und Manipulationssprache 5QL-basiert ist. Um auch eine Änderung und Bearbeitung von Daten zu ermöglichen, kann dabei der Befehlssatz erweitert sein.
Die Prozesssicherheit kann besonders dadurch erhöht werden, dass eine einheit- liche Protokollschicht vorgesehen ist, die die durchgeführten Abfragen und Mani- pulationen aufzeichnet und protokolliert und die eine Fehlerbehandlung durchführt.
Weiters betrifft die Erfindung ein Verfahren zur Abfrage und Bearbeitung von Daten, die in unterschiedlichen Datenbanksystemen gespeichert sind, bei dem Daten aus unterschiedlichen Datenbanksystemen ausgelesen werden, wobei in ei- nem ersten Speicher Steuerinformationen abgelegt werden, die Eigenschaften
<Desc/Clms Page number 5>
der Daten abbilden, und in einem zweiten Speicher die Datenwerte in einer verallgemeineren Form abgespeichert werden, um diese in einer einheitlichen Form ausgeben und bearbeiten zu können. Vorzugsweise werden die Daten im zweiten Speicher in der Form skalarer Werte abgespeichert.
In der Folge wird die Erfindung anhand der in den Figuren dargestellten Ausführungsbeispiele näher erläutert.
Fig. 1 zeigt ein Blockdiagramm eines allgemeinen Aufbaus des erfindungsgemä- ssen Programms ; Fig. 2 ein Beispiel eines hardwaremässigen Aufbaus, bei dem das erfindungsgemässe Programm verwendet wird ; Fig. 3 stellt ein logisches Datenbankmodell in vereinfachter Form dar ; Fig. 4 zeigt schematisch eine physische Repräsentation des Datenbankmodells von Fig. 3 ; Fig. 5 zeigt den Aufbau einer virtuellen Tabelle aus dem Datenmodell der Fig. 3 und 4 ; Fig. 6 zeigt schematisch Komponenten eines Programms"Kunde" ; und Fig. 7 den Quellcode des Programms von Fig. 6.
Allgemein besteht das erfindungsgemässe Programm aus einer Benutzerschnittstelle 1, die die Kommunikation mit Anwendungsprogrammen bzw. MarkupLanguages wie MS EXCEL, MS WORD, HTML, DHTML oder Programmiersprachen, die COM-fähig sind, gewährleistet. Eine Kontroll- und Manipulationsschicht 2 stellt einen ersten Speicher dar, in dem Steuerinformationen abgelegt sind und sie beinhaltet Routinen, um den Programmablauf zu steuern. In einer Speicherschicht 3 werden die Daten in Form skalarer Werte abgelegt. Allgemeine Variable, wie etwa Steuersätze oder dergleichen werden in Form von Einzeldatenwerten abgelegt, während ansonsten die Daten in Form von zweidimensionalen Tabellen gespeichert werden. Eine Zugriffsschicht 4 stellt mit entsprechenden Routinen die Verbindung zu den Datenquellen 5 her.
Eine Protokollschicht 6 dokumentiert die Vorgänge und führt die Fehlerbehandlung durch.
In einer beispielhaften Konfiguration gemäss Fig. 2 existieren zwei Datenbankserver, die-einander ergänzend-die Kundendaten einer Firma verwalten. Auf einem weiteren Server und einem Client laufen die Teamwork Softwarekomponenten. Alle Rechner sind durch ein Netzwerk verbunden. Es ist jedoch in gleicher Weise möglich, die verschiedenen Datenbanksysteme auf einem Server zu verwalten.
Server A speichert grundlegende Kundendaten.
Betriebssystem : Linux
Datenbanksystem : Progress
Datenbankzugriff : ODBC
<Desc/Clms Page number 6>
Server B kann für jeden Kunden eine zusätzliche Lieferadresse speichern.
EMI6.1
Windows NT ServerDatenbanksystem : Oracle
Datenbankzugriff : ODBC Server C stellt einerseits die Dienste der Kontroll- und Manipulationsschicht 2 sowie der Speicherschicht 3 für Clients zur Verfügung und nutzt andererseits die Zugriffsschicht 4, um auf Datenbanken zuzugreifen.
Betriebssystem : Windows NT Server
Zugriff : DCOM Auf Client X läuft elne DHTML basierte Anwendung, die es ermöglicht, Kun- dendaten zu suchen, zu verändern und zu speichern. Die Anwendung nutzt ausschliesslich Dienste von Server C und greift nicht direkt auf die Datenbank- server A und B zu. Für Anwender ist nicht erkennbar, dass die grundlegenden
Kundendaten und die Lieferadresse in unterschiedlichen Datenbanksystemen verwaltet werden.
Fig. 3 zeigt ein logisches Datenmodell, auf das sich die folgenden Beispiele beziehen. Das Objekt Kunde wird durch den eindeutigen Schlüssel IdKunde identifiziert und verfügt über die Eigenschaften Namel, Name2, Adresse, Postleitzahl und Ort. Das Objekt Lieferadresse wird durch den eindeutigen Schlüsse ! IdLiefe- radresse identifiziert und verfügt über die Eigenschaften LieferAdresse, LieferPostleitzahl, LieferOrt und LieferLand. Kunde und Lieferadresse stehen in einer 1 : 0... 1 Beziehung, d. h. jeder Kunde kann eine Lieferadresse haben und jede Lieferadresse gehört zu genau einem Kunden.
Die Daten des logischen Datenmodells werden physisch gemäss Fig. 4 gespeichert. Server A speichert die Tabelle Kunde, Server B die Tabelle Lieferadresse.
Eindeutige Schlüssel sind numerisch, alle anderen Felder sind alphanumerisch.
Die Benutzerschnittstelle 1 auf Client X stellt Daten dar, nimmt Eingaben des Benutzers entgegen und verändert als Reaktion darauf die Datendarstellung und/oder den Dateninhalt. Durch die vorliegende Erfindung gibt es zu herkömmlichen Softwareprogrammen vor allem folgende Unterschiede : . Datenbanktabellen und Datenbankfelder werden nicht in lokalen Variablen sondern in der Speicherschicht 3 auf Server C gespeichert. Die Benutzer- schnittstelle 1 fordert den benötigten Speicherplatz mit einem geeigneten
Funktionsaufruf an und kann in weiterer Folge auf diesen Speicherplatz zugreifen.
<Desc/Clms Page number 7>
Datenbankzugriffe erfolgen nicht in der Benutzerschnittstelle 1 sondern in der Kontroll- und Manipulationsschicht 2 auf Server C.
Die Benutzerschnittstelle 1 fordert die gewünschte Funktionalität an, und übergibt einen Verweis auf die zu speichernden Daten in der Speicherschicht 3 (Schreibzugriff) bzw. erhält einen Verweis auf die geladenen Daten in der Speicherschicht 3 (Lesezugriff).
. Da die Benutzerschnittstelle 1 keinen direkten Datenbankzugriff vornimmt, müssen auf Client X keine Datenbanktreiber installiert, konfiguriert und ge- wartet werden.
. Da die Benutzerschnittstelle 1 keinen direkten Datenbankzugriffe vornimmt, muss sie kein Wissen über die Datenbankstruktur enthalten.
. Falls mehrere Programme auf den gleichen Datenbestand zugreifen (sowohl die Kundenwartung als auch das Mahnwesen benötigen die Kundendaten), können beide Programme die selbe Funktionalität der Kontroll- und Manipula- tionsschicht 2 nützen.
Vorgang : Daten anfordern Um Zugriff auf die Daten eines bestimmten Kunden zu erlangen, geht die Benutzerschnittstelle 1 folgendermassen vor : . Die Kontroll- und Manipulationsschicht 2 wird angewiesen, das Programm
Kunde zu laden und die darin enthaltene Funktion Laden (kurz : Kunde. Laden) auszuführen. Als Eingabeparameter wird die gewünschte Kundennummer (Id-
Kunde) übergeben.
. Die Kontroll- und Manipulationsschicht 2 führt nun die erforderlichen Daten- bankzugriffe durch. Ergebnisdaten werden in die Speicherschicht 3 übertragen und dort in der neuen Tabelle Kunde abgelegt.
Sobald alle benötigten Daten in der Tabelle Kunde abgelegt sind signalisiert die Kontroll- und Manipulationsschicht 2 der Benutzerschnittstelle 1, dass die
Funktion Kunde. Laden erfolgreich durchgeführt wurde. Die gewünschten Da- ten werden in Form eines Verweises auf die neue Tabelle Kunde übergeben.
'Die Benutzerschnittsteiie l kann nun mit Hilfe des übergebenen Verweises auf die Speicherschicht 3 zugreifen und den Inhalt der neuen Tabelle Kunde an- zeigen bzw. verändern.
<Desc/Clms Page number 8>
<Desc/Clms Page number 9>
EMI9.1
Benutzerschnittstefte l zeigt dem Anwender an, dass die Änderungen er-folgreich durchgeführt wurden.
Vorgang : Daten löschen
EMI9.2
zum Ändern funktioniert das Löschen von Daten :Kunde zu laden und die darin enthaltene Funktion Löschen auszuführen. Als Eingabeparameter werden die zu löschende Kundennummer (IdKunde) und die zu löschende Lieferadressennummer (IdLieferadresse) übergeben.
EMI9.3
EMI9.4
EMI9.5
Die Kontroll- und Manipulationsschicht 2 führt nun die erforderlichen Daten-onen ermögiichen, unabhängig davon, auf weichem Rechner diese Prozesse laufen.
EMI9.6
<Desc/Clms Page number 10>
Andere Prozesse von Schreibzugriffen auf alle gespeicherten InformationenVorgang : Skalaren Wert erzeugen Um einen neuen skalaren Wert zu erzeugen, wird eine entsprechende Funktion der Speicherschicht 3 aufgerufen.
Eingabeparameter sind eine Kontext-ID und ein innerhalb dieser Kontext-ID eindeutiger Name, Ausgabeparameter ist ein Verweis auf den neuen skalaren Wert.
Beispiel : Die Benutzerschnittstelle 1 erzeugt beim Programmstart einen skalaren Wert im Kontext"Kundenwartung"mit dem eindeutigen Namen"Kundennum- mer".
Vorgang : Skalaren Wert ändern Skalare Werte sind zusammengesetzte Objekte, die den eigentlichen Wert und auch Zusatzinformationen (Datentyp, maximale Stringlänge, Maximalwert) speichern können. Sobald die Speicherschicht 3 einen neuen skalaren Wert erzeugt hat, kann sowohl auf den eigentlichen Wert als auch auf die Zusatzinformationen zugegriffen werden. Der Zugriff erfolgt immer über einen Verweis auf den entsprechenden Wert. Falls ein solcher Verweis nicht mehr verfügbar ist, kann er von der Speicherschicht 3 unter Angabe der Kontext-ID und des eindeutigen Namens abgefragt werden.
Beim Zuweisen eines Wertes überprüft die Speicherschicht 3, ob der zuzuweisende Wert mit allen Zusatzinformationen kompatibel ist (Stringlänge zulässig, numerischer Wertebereich eingehalten,...). Falls der zuzuweisende Wert im Widerspruch zu einer Zusatzinformation steht, wird die Zuweisung verhindert und ein entsprechender Fehler ausgelöst.
Im Gegensatz zu herkömmlichen Programmiersprachen kann jeder skalare Wert einen sog. Nullwert speichern, also die Information, dass kein Wert gespeichert ist.
Beispiel : Die Benutzerschnittstelle 1 setzt für den skalaren Wert"Kundennum- mer den Datentyp auf "Zahl", den Minimalwert auf 0 und den Maximalwert auf 999999.
Beispiel: Die Benutzerschnittstelle 1 setzt den Wert der "Kundennummer" auf 4711.
EMI10.1
<Desc/Clms Page number 11>
:Vorgang : Skalaren Wert löschen Nicht mehr benötigte skalare Werte werden mit einer entsprechenden Funktion der Speicherschicht 3 gelöscht. Eingabeparameter sind die Kontext-ID und der eindeutige Name.
Beispiel : Die Benutzerschnittstelle 1 löscht am Programmende den skalaren Wert "Kundennummer".
Vorgang : Tabelle erzeugen Um eine neue Tabelle zu erzeugen, wird eine entsprechende Funktion der Speicherschicht 3 aufgerufen. Eingabeparameter sind eine Kontext-ID und ein innerhalb dieser Kontext-ID eindeutiger Name, Ausgabeparameter ist ein Verweis auf die neue Tabelle.
Beispiel : Die Benutzerschnittstelle 1 erzeugt beim Programmstart eine Tabelle im Kontext"Kundenwartung"mit dem eindeutigen Namen Änderungsprotokoll".
Vorgang : Tabelle ändern Tabellen bilden den Inhalt von Datenbanktabellen im Hauptspeicher ab. Sie speichern einerseits eine zweidimensionale Matrix skalarer Werte und andererseits Zusatzinformationen (Tabellenname, aktuelle Zeile, aktuelle Spalte, Spaltenname, Vorschlagswert, Datentyp, etc.).
Sobald die Speicherschicht 3 eine neue Tabelle erzeugt hat, kann auf Zusatzinformationen zur Tabellenstruktur zugegriffen werden. Der Zugriff erfolgt immer über einen Verweis auf die entsprechende Tabelle. Falls ein solcher Verweis nicht mehr verfügbar ist, kann er von der Speicherschicht 3 unter Angabe der KontextID und des eindeutigen Namens abgefragt werden. Nach dem Erzeugen einer neuen Tabelle muss die Tabellenstruktur definiert werden (Spaltennamen, Daten- typen,...). Das kann durch den Aufruf entsprechender Funktionen oder durch das Laden einer Strukturvorlage geschehen.
Nach der Definition der Tabellenstruktur kann auf die Daten zugegriffen werden.
Es stehen unter anderem Funktionen zur Verfügung, um neue Zeilen zu erzeugen und bestehende Zeilen zu löschen. Jede Zeile besteht gemäss der zuvor definierten Tabellenstruktur aus einer bestimmten Anzahl skalarer Werte. Ein einzelner skalarer Wert wird als Zelle bezeichnet.
Beispiel : Die Benutzerschnittstelle 1 fügt der Tabelle Änderungsprotokoll" die Spalten IdKunde (Datentyp "Zahl") und Zeitpunkt (Datentyp "Zeitpunkt") hinzu.
<Desc/Clms Page number 12>
Beispiel : Die Benutzerschnittstelle 1 fügt der Tabelle "Änderungsprotokoll" eine neue Zeile hinzu.
Vorgang : Zelle ändern Der Zugriff auf eine einzelne Zelle erfolgt immer über einen Verweis auf jene Tabelle, welche die betreffende Zelle enthält. Falls ein solcher Verweis nicht mehr verfügbar ist, kann er von der Speicherschicht 3 unter Angabe der Kontext-ID und des eindeutigen Namens abgefragt werden.
Da jede Tabelle mehrere Zeilen und jede Zeile mehrere Zellen enthält ist beim Zugriff auf einzelne Zeilen bzw. Zellen eine Adressierungsmethode nötig. Implizite Adressierung wird dadurch ermöglicht, dass jede Tabelle eine aktuelle Zeile und eine aktuelle Spalte verwaltet. Die aktuelle Zeile adressiert eine bestimmte Zeile, die aktuelle Spalte eine bestimmte Spalte. Gemeinsam adressieren die beiden Werte eine bestimmte Zelle. Bei expliziter Adressierung werden der Zugriffsmethode als Eingabeparameter Zeilen- und/oder Spaltenindex übergeben. Die jeweilige Zugriffsfunktion liefert in jedem Fall einen Verweis auf einen skalaren Wert zurück, der wie weiter oben beschrieben verwendet werden kann.
Beim Zuweisen eines Wertes überprüft die Speicherschicht 3, ob der zuzuweisende Wert mit allen Zusatzinformationen des skalaren Wertes und der Tabelle kompatibel ist. Im Gegensatz zum "normalen" skalaren Wert erfolgt hier also eine mehrstufige Konsistenzprüfung ! Falls der zuzuweisende Wert im Widerspruch zu einer Zusatzinformation steht, wird die Zuweisung verhindert und ein entsprechender Fehler ausgelöst.
Beispiel : Die Benutzerschnittstelle 1 setzt die aktuelle Zeile und die aktuelle Spalte der Tabelle "Änderungsprotokoll" auf 1.
Beispiel : Die Benutzerschnittstelle 1 setzt die aktuelle Zelle der Tabelle "Änderungsprotokoll" auf 4711.
Beispiel : Die Benutzerschnittstelle 1 setzt die zweite Spalte der ersten Zeile auf ,, 18. Jänner 2000 15 : 02".
Vorgang : Tabelle löschen
Nicht mehr benötigte Tabellen werden mit einer entsprechenden Funktion der
Speicherschicht 3 gelöscht. Eingabeparameter sind die Kontext-ID und der ein- deutige Name.
Beispiel : Die Benutzerschnittstelle 1 löscht am Programmende die Tabelle "Ände- rungsprotokoll".
<Desc/Clms Page number 13>
Server C stellt die Kontroll- und Manipulationsschicht 2 zur Verfügung, um Benutzerschnittstellen 1 gleichartigen Zugriff auf unterschiedliche Datenquellen 5 zu ermöglichen.
Funktionen
EMI13.1
Funktionen erzeugen zur Laufzeit Datenmanipulationsanweisungen und setzen diese mit Hilfe der Zugriffsschicht 4 gegen Datenbanken ab. Schreibzugriffe erfolgen derart, dass Daten aus der Speicherschicht 3 ausgelesen, bei Bedarf umgewandelt und in eine entsprechende Datenmanipulationsanweisung ein- gefügt werden. Ergebnisdaten von Lesezugriffen werden bei Bedarf umge- wandelt und in der Speicherschicht 3 abgelegt.
. Funktionen können Verweise auf Einträge der Speicherschicht 3 entgegen- nehmen (Eingabeparameter) und/oder zurück liefern (Ausgabeparameter).
Der Aufbau von Funktionen folgt einem fixen Syntaxschema, das Ähnlichkei- ten mit bekannten Programmiersprachen hat.
Funktionen nutzen die Speicherschicht 3, um auf Daten zuzugreifen.
Funktionen nutzen die Zugriffsschicht 4, um auf Datenbanken zuzugreifen.
Programme Programme werden über einen eindeutigen Namen identifiziert.
Programme fassen logisch zusammengehörige Funktionen zusammen.
Programme ermöglichen es, eine umfangreiche Gesamtaufgabe in Teilaufga- ben zu zerlegen und damit eine übersichtliche Struktur zu bilden.
Einfache Programme können vom Anwender unter Zuhilfenahme von Konfigu- rations-Assistenten automatisch erzeugt werden. Komplexe Programme wer- den vom Systemadministrator erzeugt.
<Desc/Clms Page number 14>
Ausführung Funktionen werden in der bevorzugten Ausführungsvariante von einem Sub- modul der Kontroll- und Manipulationsschicht 2 interpretiert ; es ist jedoch grundsätzlich auch möglich, ausführbaren Maschinencode zu erzeugen (z. B. aus Performancegründen).
Für das laufende Beispiel erscheint es sinnvoll, ein Programm "Kunde" zu erstellen, wie es in Fig. 6 dargestellt ist. Dieses enthält Funktionen zum Laden, Speichern und Löschen von Kundendaten.
Die Kundendaten werden in der Speicherschicht 3 in Form der "virtuellen" Tabelle twKunde gemäss Fig. 5 gespeichert. twKunde enthält alle Felder der physischen Tabellen Kunde und Lieferadresse. Die Funktionen im Programm Kunde haben die Aufgabe, zwischen der Tabellenstruktur twKunde und der physischen Datenbanktabellenstruktur zu übersetzen.
Sowohl die Struktur und Funktionsweise des Programms Kunde als auch die Form der Tabelle twKunde liegen im Ermessen des Systemadministrators. Die hier gezeigte Ausprägung ist beispielhaft ! Fig. 7 zeigt eine mögliche Ausprägung der Funktion "Laden" im Programm "Kunde".
Um die Daten eines bestimmten Kunden zu laden, geht die Benutzerschnittstelle 1 wie folgt vor : * Skalaren Wert IdKunde"anlegen und initialisieren . Funktion "Kunde. Laden" auszuführen, Eingabeparameter ist ein Verweis auf den skalaren Wert "IdKunde", Ausgabeparameter ist ein Verweis auf die Ta- belle "twKunde".
Auf Auf Tabelle "twKunde"zugreifen, um Daten anzuzeigen.
Die Zugriffsschicht 4 läuft auf Server C und ist für den physischen Datenaustausch mit den Datenbank-Managementsystemen auf den Servern A und B zu- ständig : . Die Zugriffsschicht 4 nützt so weit wie möglich bestehende Protokolle und
EMI14.1
jeweils verwendeten Datenzugriffsmethode bzw. des jeweils verwendeten Datenbanksystems erwartet.
<Desc/Clms Page number 15>
. Ausgabeparameter (Daten) werden im Format der jeweils verwendeten Da- tenzugriffsmethode bzw. des jeweils verwendeten Datenbanksystems zurück- geliefert.
Details der jeweiligen Datenzugriffsmethode werden hinter einer einheitlichen
Schnittstelle versteckt.
Einzelne Datenzugriffsobjekte werden entweder vorab vom Systemadminist- rator konfiguriert und abgespeichert oder zur Laufzeit durch die Software er- stellt.
Vorgang : Datenzugriff definieren Beispiel : Auf Server C ist sowohl der Progress ODBC Treiber als auch der Oracie ODBC Treiber installiert. Der Systemadministrator (SA) stellt sicher, dass zwei Datenzugriffsobjekte für Lese- und Schreibzugriff auf die beiden Datenbanken A und B existieren : . SA legt in der Windows NT Systemsteuerung je einen System DSN für die
Progress Datenbank A und für die Oracle Datenbank B an.
SA legt im Teamwork Konfigurationsprogramm je ein Datenzugriffsobjekt für die Progress Datenbank A und für die Oracle Datenbank B an.
. SA stellt für beide Datenzugriffsobjekte als Datenzugriffsmethode ADO"ein.
. SA verknüpft beide Datenzugriffsobjekte mit dem entsprechenden System
DSN.
SA nimmt in beiden Datenzugriffsobjekten ADO-spezifische Einstellungen vor (cursor location, lock type,...).
EMI15.1
Vorgang : Datenzugriff taden Um ein Datenzugriffsobjekt zu laden, wird eine entsprechende Funktion der Zugriffsschicht 4 aufgerufen. Eingabeparameter sind eine Kontext-ID und ein innerhalb dieser Kontext-ID eindeutiger Name, Ausgabeparameter ist ein Verweis auf das neue Datenzugriffsobjekt.
<Desc/Clms Page number 16>
Da die zur Verfügung stehenden Datenzugriffsobjekte bereits vom Systemadministrator eingerichtet wurden sind der Zugriffsschicht 4 alle notwendigen Einstellungen bekannt, um Datenzugriffe durchzuführen.
Beispiel : Die Kontroll- und Manipulationsschicht 2 lädt beim Ausführen der Funk-
EMI16.1
Das Öffnen einer Verbindung erfolgt immer über einen Verweis auf ein Datenzugriffsobjekt. Falls der entsprechende Verweis nicht mehr verfügbar ist, kann er von der Zugriffsschicht 4 unter Angabe der Kontext-ID und des eindeutigen Namens abgefragt werden. Durch das Öffnen einer Verbindung erfolgt i. d. R. eine Anmeldung am jeweiligen Datenbanksystem.
Beispiel : Die Kontroll- und Manipulationsschicht 2 öffnet beim Ausführen der Funktion Kunde. Laden eine Verbindung über Datenzugriffsobjekt A', um auf die Datenbank A Abfragen absetzen zu können.
Vorgang : Transaktion durchführen Das Durchführen von Transaktionen erfolgt immer über einen Verweis auf ein Datenzugriffsobjekt. Falls der entsprechende Verweis nicht mehr verfügbar ist, kann er von der Zugriffsschicht 4 unter Angabe der Kontext-ID und des eindeutigen Namens abgefragt werden. Eingabeparameter ist eine Zeichenkette, welche die durchzuführenden Anweisungen - etwa in SQL-enthält. Ausgabeparameter sind ein Erfolgscode und etwaige Ergebnisdaten.
Beispiel : Die Kontroll- und Manipulationsschicht 2 setzt beim Ausführen der Funktion Kunde. Laden die SQL Datenbankabfrage SELECT * FROM Kunde WHERE IdKunde = 4711" ab und erhält als Ergebnis ein ADO Recordset mit den Daten der entsprechenden Kundennummer.
Vorgang : Verbindung schliessen Das Schliessen einer Verbindung erfolgt immer über einen Verweis auf ein Datenzugriffsobjekt. Falls der entsprechende Verweis nicht mehr verfügbar ist, kann er von der Zugriffsschicht 4 unter Angabe der Kontext-ID und des eindeutigen Namens abgefragt werden. Durch das Schliessen einer Verbindung erfolgt i. d. R. eine Abmeldung vom jeweiligen Datenbanksystem.
<Desc/Clms Page number 17>
Beispiel : Die Kontroll- und Manipulationsschicht 2 schliesst beim Ausführen der Funktion Kunde. Laden die Verbindung über Datenzugriffsobjekt A"nachdem Abfragen abgesetzt wurden.
Vorgang : Datenzugriff löschen Nicht mehr benötigte Datenzugriffsobjekte werden mit einer entsprechenden Funktion der Zugriffsschicht 4 aus dem Hauptspeicher entfernt. Eingabeparameter sind die Kontext-ID und der eindeutige Name des Datenzugriffsobjekts.
Beispiel : Die Kontroll- und Manipulationsschicht 2 löscht nach dem Ausführen der Funktion Kunde. Laden das Datenzugriffsobjekt A".
<Desc / Clms Page number 1>
The present invention relates to a program for querying and processing data that are stored in different database systems.
Relational database systems are usually used in electronic data processing to store a large number of data, such as customer data, orders, deliveries or the like. For the purpose of querying and manipulating this data, various query languages are used, each of which is adapted to the database system.
Different database systems are often used in parallel in larger organizations.
This can result in a number of problems: * Basically related data is separated (loss of information); . The same data is saved several times (redundancy); * The same data is in different formats (which tables,
Relationships, fields, data types) saved (redundancy, inconsistency); * Similar data are represented differently (data type, field length, accuracy, ...) (inconsistency); * The different database systems provide different data access methods;
The above-mentioned problems lead to inconsistencies in the data material, loss of information, high effort in "synchronizing" the data, high administrative effort and difficulties in linking data.
Another problem area arises at the user interface level.
A few programs have prevailed in various fields of application (word processing, spreadsheets, ...). This so-called standard software is widespread and well tailored to the respective application. Data that is created when working with standard software is usually saved in a proprietary file format as a file on a data carrier.
Linking data stored in a database system to the standard software is problematic. Read access is possible for users with simple query wizards, however knowledge of the database structure is required. Write access is usually not supported.
<Desc / Clms Page number 2>
A simple and common example of a problem in this area: You write a letter to a business partner in word processing. The address database contains all the information you need about this business partner. However, finding the name and address in the address database and transferring the search results to the letter is problematic.
Such a problem can only really be solved with programming knowledge. Standard software usually contains a macro programming language and / or allows access to your data via a public class library. In any case, you have to decide in a certain programming language for a certain data access method, make database queries with your own program code and take over the results. This procedure is impractical for users without programming knowledge and time-consuming for experts.
There are also increasing problems in the development of software. Although database systems are required in many areas, there is practically no standardized data access method. There are basically two ways to create software with database access: 'The database system contains a programming language.
. The database system contains an interface through which higher programming languages can access databases.
Both options are not subject to any standardization. Every manufacturer of a database system interprets the programming language it contains based on the capabilities of its database system, thereby creating its own programming language that is naturally incompatible with other systems. Interfaces for higher programming languages are extremely numerous, and the drivers of the individual database systems are mostly incompatible.
One way to alleviate these problems would be to commit to a database system. A relational database model, however, leads to complex database structures with a large number of entities (tables) and relations for large databases.
Logically related databases are often stored in several physical tables for reasons of performance, redundancy and consistency. It is complex to define relationships, which data rows (of different) tables belong to each other and to link the related data.
Different departments of a company often have different databases that are adapted to the respective requirements. It is often necessary to link data from different departments (which are stored in different databases) (e.g. for statistical analysis). The problems described above occur.
<Desc / Clms Page number 3>
The object of the present invention is to avoid these disadvantages and to create a program which makes it possible to handle data which are stored in different database systems in a simple manner. This should ensure that the data is manipulated as simply and safely as possible.
According to the invention, it is provided that the data from the individual database systems are analyzed and read out, then control information for the individual data types is stored in a first memory, the data values are stored in a generalized form in a second memory, whereupon the data is displayed in a uniform user interface and output, the user interface offering the possibility of manipulating the data, the corresponding data values being taken from the second memory, being subjected to the respective processing and being written back from the first data memory into the respective database system using the control information.
It is essential to the present invention that the data sources that are represented in the individual database systems are basically preserved.
This means that user-specific application programs that access this data or that generate and manipulate this data can be kept unchanged. However, a uniform program is used for cross-database manipulations and representations, which is essentially independent of the respective database systems. The database-specific communication modules are combined in a separate access layer separate from the rest of the program, so that in the case of new database systems or changes in the query modalities for existing database systems, only corresponding adjustments in the access layer need to be carried out.
Another essential aspect of the invention is that the data contained in the database systems are stored in a standardized and generalized form in order to ensure uniform access and processing. Since the program according to the invention provides not only the possibility of data interrogation, but also the possibility of manipulating data, that is to say that the data can be rewritten, changed, copied, etc., the data must be converted back into the specific formats of the special precautions are taken for individual database systems. A preferred option is to store data in the form of scalar values. This is data structures that consist of several elements.
One element is the data value itself, which is in the form of a character string. Other elements define the data type and any existing restrictions, such as those that are permissible
<Desc / Clms Page number 4>
Define value ranges. For example, you can specify that a data item that represents a zip code is an integer value that is only allowed if it is between 1000 and 9999. In this way, error handling procedures and the like can be made more efficient. In general, for example, the data types number (fixed point number or floating point number), character string, date, time, date with time, logical value or the like can be distinguished.
Data values can also be stored as zero values, i. H. that a special label specifies that the data value is not zero, but is not available at all.
In a particularly preferred embodiment variant of the program according to the invention, provision is made for a first translation module to be provided which converts the queries and manipulation commands formulated in a uniform query and manipulation language into commands which are adapted to the respective database system. In this way, not only is the data exchange standardized and standardized, but also the logical operations such as conditions, loops or the like are standardized in a simple and manageable manner.
User-friendliness can be increased in particular by providing a second translation module that is designed to work with existing software programs and to exchange data. A large number of users are used to working with certain standard programs, such as HTML, MICROSOFT EXCEL, MICROSOFT WORD or the like. By offering appropriate interfaces, working with the program according to the invention can be considerably simplified for such users, since it is possible in a simple manner to access the data from the above programs and to edit them if necessary.
A further simplification of use can be achieved in that the uniform query and manipulation language is based on 5QL. The command set can be expanded to enable data to be changed and edited.
Process reliability can be increased in particular by providing a uniform protocol layer that records and logs the queries and manipulations that are carried out and that performs error handling.
Furthermore, the invention relates to a method for querying and processing data stored in different database systems, in which data are read out from different database systems, control information being stored in a first memory, the properties
<Desc / Clms Page number 5>
map the data, and the data values are stored in a more general form in a second memory in order to be able to output and process them in a uniform form. The data are preferably stored in the second memory in the form of scalar values.
The invention is explained in more detail below on the basis of the exemplary embodiments illustrated in the figures.
1 shows a block diagram of a general structure of the program according to the invention; 2 shows an example of a hardware structure in which the program according to the invention is used; 3 illustrates a logical database model in a simplified form; Fig. 4 schematically shows a physical representation of the database model of Fig. 3; 5 shows the structure of a virtual table from the data model of FIGS. 3 and 4; 6 schematically shows components of a "customer" program; and FIG. 7 shows the source code of the program of FIG. 6.
In general, the program according to the invention consists of a user interface 1, which ensures communication with application programs or markup languages such as MS EXCEL, MS WORD, HTML, DHTML or programming languages that are COM-compatible. A control and manipulation layer 2 represents a first memory in which control information is stored and it contains routines to control the program sequence. The data are stored in the form of scalar values in a storage layer 3. General variables, such as tax rates or the like, are stored in the form of individual data values, while the data are otherwise stored in the form of two-dimensional tables. An access layer 4 uses appropriate routines to establish the connection to the data sources 5.
A protocol layer 6 documents the processes and carries out error handling.
In an exemplary configuration according to FIG. 2, there are two database servers which, in addition to one another, manage the customer data of a company. The teamwork software components run on a further server and a client. All computers are connected by a network. However, it is possible in the same way to manage the various database systems on one server.
Server A stores basic customer data.
Operating system: Linux
Database system: Progress
Database access: ODBC
<Desc / Clms Page number 6>
Server B can store an additional delivery address for each customer.
EMI6.1
Windows NT Server database system: Oracle
Database access: On the one hand, ODBC Server C provides the services of the control and manipulation layer 2 and the storage layer 3 for clients, and on the other hand uses the access layer 4 to access databases.
Operating system: Windows NT Server
Access: DCOM A client-based application is running a DHTML-based application that makes it possible to search, change and save customer data. The application uses only services from server C and does not directly access database servers A and B. It is not apparent to users that the basic
Customer data and the delivery address can be managed in different database systems.
Figure 3 shows a logical data model to which the following examples relate. The customer object is identified by the unique key IdKunde and has the properties Name, Name2, address, postcode and city. The object delivery address is by the clear conclusions! IdLieferadresse identifies and has the properties delivery address, delivery post code, delivery location and delivery country. Customer and delivery address are in a 1: 0 ... 1 relationship, i.e. H. every customer can have a delivery address and each delivery address belongs to exactly one customer.
The data of the logical data model are stored physically according to FIG. 4. Server A stores the customer table, server B the delivery address table.
Unique keys are numeric, all other fields are alphanumeric.
The user interface 1 on client X represents data, accepts input from the user and changes the data display and / or the data content in response. Due to the present invention, there are the following differences from conventional software programs: Database tables and database fields are not stored in local variables but in storage layer 3 on server C. The user interface 1 requests the required storage space with a suitable one
Function call and can subsequently access this storage space.
<Desc / Clms Page number 7>
Database accesses do not take place in the user interface 1 but in the control and manipulation layer 2 on server C.
The user interface 1 requests the desired functionality and transfers a reference to the data to be stored in the storage layer 3 (write access) or receives a reference to the loaded data in the storage layer 3 (read access).
. Since user interface 1 does not provide direct database access, no database drivers need to be installed, configured and maintained on Client X.
. Since the user interface 1 does not make direct database accesses, it need not contain any knowledge of the database structure.
. If several programs access the same database (both customer maintenance and dunning require customer data), both programs can use the same functionality of control and manipulation layer 2.
Process: Requesting data In order to gain access to the data of a specific customer, the user interface 1 proceeds as follows:. The control and manipulation layer 2 is directed to the program
Load customer and execute the Load function (short: Customer. Load) contained therein. The desired customer number (Id-
Customer).
. The control and manipulation layer 2 now carries out the necessary database accesses. Result data are transferred to storage layer 3 and stored there in the new customer table.
As soon as all the required data are stored in the customer table, the control and manipulation layer 2 of the user interface 1 signals that the
Function customer. Loading was successful. The requested data is transferred in the form of a reference to the new customer table.
The user interface can now access the storage layer 3 with the aid of the reference provided and can display or change the content of the new customer table.
<Desc / Clms Page number 8>
<Desc / Clms Page number 9>
EMI9.1
User interface l indicates to the user that the changes have been made successfully.
Operation: delete data
EMI9.2
deleting data works to change: load the customer and execute the delete function contained therein. The customer number (IdKunde) to be deleted and the delivery address number (IdDelivery address) to be deleted are transferred as input parameters.
EMI9.3
EMI9.4
EMI9.5
The control and manipulation layer 2 now enables the necessary data on, regardless of which computer these processes run on.
EMI9.6
<Desc / Clms Page number 10>
Other processes of write access to all stored information Process: Generate scalar value In order to generate a new scalar value, a corresponding function of the storage layer 3 is called.
Input parameters are a context ID and a name that is unique within this context ID, output parameters are a reference to the new scalar value.
Example: When starting the program, user interface 1 generates a scalar value in the context of "customer maintenance" with the unique name "customer number".
Process: Change scalar value Scalar values are composite objects that can store the actual value and also additional information (data type, maximum string length, maximum value). As soon as the storage layer 3 has generated a new scalar value, both the actual value and the additional information can be accessed. Access is always via a reference to the corresponding value. If such a reference is no longer available, it can be queried by the storage layer 3 specifying the context ID and the unique name.
When assigning a value, memory layer 3 checks whether the value to be assigned is compatible with all additional information (string length permitted, numerical value range maintained, ...). If the value to be assigned contradicts additional information, the assignment is prevented and a corresponding error is triggered.
In contrast to conventional programming languages, each scalar value can store a so-called zero value, i.e. the information that no value is stored.
Example: User interface 1 sets the data type to "Number" for the scalar value "Customer number", the minimum value to 0 and the maximum value to 999999.
Example: User interface 1 sets the value of the "customer number" to 4711.
EMI10.1
<Desc / Clms Page number 11>
: Process: Delete scalar value Scalar values that are no longer required are deleted with a corresponding function in storage layer 3. Input parameters are the context ID and the unique name.
Example: User interface 1 deletes the scalar value "customer number" at the end of the program.
Process: Create table To create a new table, a corresponding function of storage layer 3 is called. Input parameters are a context ID and a name that is unique within this context ID, output parameters are a reference to the new table.
Example: When starting the program, user interface 1 creates a table in the context of "customer service" with the unique name change log ".
Process: Change table Tables map the content of database tables in main memory. On the one hand, they store a two-dimensional matrix of scalar values and, on the other hand, additional information (table name, current row, current column, column name, default value, data type, etc.).
As soon as the storage layer 3 has generated a new table, additional information on the table structure can be accessed. Access is always via a reference to the corresponding table. If such a reference is no longer available, it can be queried by the storage layer 3 specifying the context ID and the unique name. After creating a new table, the table structure must be defined (column names, data types, ...). This can be done by calling the appropriate functions or by loading a structure template.
After defining the table structure, the data can be accessed.
There are functions available, among other things, to create new lines and delete existing lines. According to the table structure previously defined, each line consists of a certain number of scalar values. A single scalar value is called a cell.
Example: User interface 1 adds the columns ID customer (data type "number") and time (data type "time") to the change log table.
<Desc / Clms Page number 12>
Example: User interface 1 adds a new row to the "Change log" table.
Process: Change cell Access to a single cell is always via a reference to the table that contains the cell in question. If such a reference is no longer available, it can be queried by the storage layer 3 specifying the context ID and the unique name.
Since each table contains several rows and each row contains several cells, an addressing method is necessary when accessing individual rows or cells. Implicit addressing is made possible by the fact that each table manages a current row and a current column. The current row addresses a specific row, the current column a specific column. Together, the two values address a specific cell. If addressing is explicit, the access method is passed as the row and / or column index input parameters. The respective access function always returns a reference to a scalar value that can be used as described above.
When assigning a value, the storage layer 3 checks whether the value to be assigned is compatible with all additional information of the scalar value and the table. In contrast to the "normal" scalar value, a multi-level consistency check is carried out here! If the value to be assigned contradicts additional information, the assignment is prevented and a corresponding error is triggered.
Example: The user interface 1 sets the current row and the current column of the "Change log" table to 1.
Example: User interface 1 sets the current cell in the "Change log" table to 4711.
Example: User interface 1 sets the second column of the first line to "January 18, 2000 3:02 PM".
Action: delete table
Tables that are no longer required are provided with a corresponding function of
Storage layer 3 deleted. The input parameters are the context ID and the unique name.
Example: User interface 1 deletes the table "Change log" at the end of the program.
<Desc / Clms Page number 13>
Server C provides the control and manipulation layer 2 in order to enable user interfaces 1 to have similar access to different data sources 5.
Functions
EMI13.1
Functions generate data manipulation instructions at runtime and use the access layer 4 to set them against databases. Write accesses take place in such a way that data are read out from the storage layer 3, converted if necessary and inserted into a corresponding data manipulation instruction. Result data from read accesses are converted if necessary and stored in the storage layer 3.
. Functions can accept references to entries in storage layer 3 (input parameters) and / or return them (output parameters).
The structure of functions follows a fixed syntax scheme, which is similar to known programming languages.
Functions use memory layer 3 to access data.
Functions use access layer 4 to access databases.
Programs Programs are identified by a unique name.
Programs combine functions that logically belong together.
Programs make it possible to break down an extensive overall task into subtasks and thus form a clear structure.
Simple programs can be created automatically by the user with the help of configuration wizards. Complex programs are created by the system administrator.
<Desc / Clms Page number 14>
Execution Functions are interpreted in the preferred embodiment variant by a submodule of the control and manipulation layer 2; In principle, however, it is also possible to generate executable machine code (e.g. for performance reasons).
For the current example, it seems sensible to create a "customer" program as shown in FIG. 6. This contains functions for loading, saving and deleting customer data.
The customer data are stored in the storage layer 3 in the form of the “virtual” table customer according to FIG. 5. twKunde contains all fields of the physical tables customer and delivery address. The functions in the Customer program are used to translate between the table structure twKunde and the physical database table structure.
Both the structure and functionality of the Customer program and the form of the table twKunde are at the discretion of the system administrator. The version shown here is exemplary! 7 shows a possible form of the "load" function in the "customer" program.
To load the data of a specific customer, user interface 1 proceeds as follows: * Create and initialize scalar value IdCustomer "Function" Customer. Load ", input parameter is a reference to the scalar value" IdKunde ", output parameter is a reference to the table" twKunde ".
Access the twCustomer table to view data.
The access layer 4 runs on server C and is responsible for the physical data exchange with the database management systems on servers A and B. The access layer 4 uses existing protocols and as far as possible
EMI14.1
expected data access method or database system used in each case.
<Desc / Clms Page number 15>
. Output parameters (data) are returned in the format of the data access method used or the database system used.
Details of the respective data access method are behind a uniform
Interface hidden.
Individual data access objects are either configured and saved in advance by the system administrator or created by the software at runtime.
Process: Define data access Example: Both the Progress ODBC driver and the Oracie ODBC driver are installed on server C. The system administrator (SA) ensures that two data access objects for read and write access to the two databases A and B exist:. SA creates a system DSN for each in the Windows NT system control
Progress database A and for the Oracle database B.
SA creates a data access object for the Progress database A and one for the Oracle database B in the teamwork configuration program.
. SA sets ADO "as the data access method for both data access objects.
. SA links both data access objects with the corresponding system
DSN.
SA makes ADO-specific settings in both data access objects (cursor location, lock type, ...).
EMI15.1
Process: Load data access To load a data access object, a corresponding function of access layer 4 is called. Input parameters are a context ID and a name that is unique within this context ID, output parameters are a reference to the new data access object.
<Desc / Clms Page number 16>
Since the available data access objects have already been set up by the system administrator, the access layer 4 is aware of all the necessary settings for carrying out data access.
Example: The control and manipulation layer 2 loads when the radio
EMI16.1
A connection is always opened via a reference to a data access object. If the corresponding reference is no longer available, it can be queried by the access layer 4 specifying the context ID and the unique name. By opening a connection i. d. Usually a registration at the respective database system.
Example: Control and manipulation layer 2 opens when the Customer function is executed. Load a connection via data access object A 'in order to be able to send queries to database A.
Process: Executing a transaction Transactions are always carried out via a reference to a data access object. If the corresponding reference is no longer available, it can be queried by the access layer 4 specifying the context ID and the unique name. The input parameter is a character string that contains the instructions to be carried out - for example in SQL. Output parameters are a success code and any result data.
Example: Control and manipulation layer 2 sets customer when executing the function. Load the SQL database query SELECT * FROM customer WHERE IdKunde = 4711 "and receive an ADO recordset with the data of the corresponding customer number.
Process: Closing a connection A connection is always closed via a reference to a data access object. If the corresponding reference is no longer available, it can be queried by the access layer 4 specifying the context ID and the unique name. By closing a connection i. d. Usually a deregistration from the respective database system.
<Desc / Clms Page number 17>
Example: The control and manipulation layer 2 closes when the customer function is executed. Load the connection via data access object A "after queries have been issued.
Process: Delete data access Data access objects that are no longer required are removed from the main memory with a corresponding function of the access layer 4. The input parameters are the context ID and the unique name of the data access object.
Example: The control and manipulation layer 2 deletes after executing the customer function. Load the data access object A ".