DE69533786T2 - Vorrichtung zum Erzeugen von objektorientierten Schnittstellen für relationale Datenbanken und von dieser Vorrichtung durchgeführtes Verfahren - Google Patents

Vorrichtung zum Erzeugen von objektorientierten Schnittstellen für relationale Datenbanken und von dieser Vorrichtung durchgeführtes Verfahren Download PDF

Info

Publication number
DE69533786T2
DE69533786T2 DE69533786T DE69533786T DE69533786T2 DE 69533786 T2 DE69533786 T2 DE 69533786T2 DE 69533786 T DE69533786 T DE 69533786T DE 69533786 T DE69533786 T DE 69533786T DE 69533786 T2 DE69533786 T2 DE 69533786T2
Authority
DE
Germany
Prior art keywords
relational
class
objects
methods
database
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE69533786T
Other languages
English (en)
Other versions
DE69533786D1 (de
Inventor
François Exertier
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Bull Sa Les Clayes Sous Bois Fr
Original Assignee
Bull SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bull SA filed Critical Bull SA
Application granted granted Critical
Publication of DE69533786D1 publication Critical patent/DE69533786D1/de
Publication of DE69533786T2 publication Critical patent/DE69533786T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28Databases characterised by their database models, e.g. relational or object models
    • G06F16/289Object oriented databases
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99931Database or file accessing
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99941Database schema or data structure
    • Y10S707/99943Generating database or data structure, e.g. via user interface
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99941Database schema or data structure
    • Y10S707/99944Object-oriented database structure

Description

  • Die vorliegende Erfindung betrifft eine Vorrichtung zum Erzeugen von objektorientierten Schnittstellen, um den Zugriff von neuen Anwendungen, die in objektorientierten Umgebungen entwickelt worden sind, auf vorhandene relationale Datenbanken zuzulassen. Außerdem betrifft sie ein Verfahren, das von der Vorrichtung ausgeführt wird.
  • Um Daten einfacher darzustellen lassen und eine höhere Produktivität der Entwickler und der Anwender zu ermöglichen, wird häufig im Allgemeinen das relationale Datenmodell verwendet, denn es ermöglicht eine Tabellendarstellung sowohl von Objekten als auch von Beziehungen zwischen Objekten. In diesem Fall stellt sich eine relationale Datenbank als eine Gesamtheit von Relationen dar, woher der Name des Modells stammt, wobei diese Relationen auch als Tabellen bezeichnet werden. Einer Datenbank ist ein Konzeptionsschema zugeordnet, das die Struktur und den Typ der Daten, die sie enthält, und gegebenenfalls, und dies ist bei der vorliegenden Anwendung der Fall, die Bedingungen oder Regeln, die immer verifiziert sein müssen, beschreibt, wobei die Datenbank selbst durch ein Datenbanken-Steuersystem gesteuert wird. Auch jede Relation besitzt ein Schema, das ihre Struktur beschreibt, sowie eine Erweiterung, die dem Zustand dieser Relation zu einem bestimmten Zeitpunkt entspricht. Das Schema einer Tabelle ist aus einer Gesamtheit von Attributen (oder Spalten) gebildet, wovon eine Teilmenge den Schlüssel bildet, der ermöglicht, die weiteren Attribute der Relation oder ein Element (n-Tupel) der Relation zu identifizieren. Die Erweiterung einer Relation ist aus einer Menge von n-Tupeln (oder Zeilen) gebildet. Ein n-Tupel entspricht einer Menge von Werten, die von den Attributen einer Tabelle angenommen werden, um ein Objekt oder eine Beziehung zwischen Objekten der realen Welt darzustellen. Zwei Relationen, die Attribute desselben Feldes gemeinsam haben, können miteinander verbunden werden, wobei dann von einem Verbinden der Relationen gesprochen wird, wobei dieses Verbinden entsprechend einem oder mehreren dieser Attribute, die als Verbindungsattribute bezeichnet werden, verwirklicht wird. Das Verbinden von zwei Tabellen kann auf diese Weise erzielt werden; es ermöglicht, durch Vergleichen der Werte der Spalten dieser zwei Tabellen einen Zusammenhang zwischen diesen beiden Tabellen herzustellen. Die für den Vergleich verwendeten Spalten werden als Verbindungsspalten bezeichnet. Das Ergebnis dieser Verbindung ist eine dritte Tabelle, deren Spalten aus den zwei Tabellen stammen, wobei die Zeilen diejenigen der beiden Tabellen sind, die das Vergleichskriterium bestätigen. In diesem Sinne scheint der Gebrauch einer Standardsprache zur Definition und Manipulation von Daten, wie beispielsweise der Sprache SQL (Structured Query Language), für die Definition und die Manipulation von relationalen Datenbanken sehr vorteilhaft zu sein. Das Modell ermöglicht außerdem, zusätzliche semantische Informationen über die Attribute der Relationen zu liefern, indem referentielle Integritätsbedingungen zugewiesen werden. Die Schlüssel betreffend ermöglicht folglich ein Attribut, das als Primärschlüssel definiert ist, eindeutig das n-Tupel zu bestimmen, dem er angehört, da ein gegebener Wert für dieses Attribut nicht in zwei verschiedenen n-Tupeln angetroffen werden kann. Außerdem ermöglicht ein Attribut, dass als Fremdschlüssel definiert ist, den Primärschlüssel einer weiteren Tabelle zu bezeichnen. Es ist dann möglich, mittels des Fremdschüsselattributs und des bezeichneten Primärschlüssels einen Zusammenhang zwischen diesen beiden Tabellen zu definieren.
  • Neben der Einfachheit und der Verbesserung der Leistungsfähigkeit, die auf die Verwendung des relationalen Datenmodells zurückzuführen sind, hat die Normung einer Sprache, wie etwa der Sprache SQL, die einfach im Gebrauch ist, zu einer raschen Verbreitung von relationalen Datenbanken beigetragen. So sind bis heute die meisten der entwickelten Anwendungen, und dies seit mehr als einem Jahrzehnt, Anwendungen, die dafür vorgesehen sind, von Systemen zum Steuern von relationalen Datenbanken benutzt zu werden. Die aktuelle Tendenz ist jedoch eher eine Entwicklung in Richtung der Konzeption von Anwendungen, die von objektorientierten Verfahren Gebrauch machen. Gleichwohl müssen diese beiden Techniken nebeneinander bestehen können, und die vorhandenen relationalen Datenbanken müssen weiterhin in den verschiedenen Systemen benutzt werden können, wodurch sich das Problem des Zugriffs von Anwendungen, die in objektorientierten Umgebungen entwickelt worden sind, auf relationale Datenbanken stellt. Folglich wird es unerlässlich und dringend, eine zweckmäßige und effiziente Lösung für dieses Zugriffsproblem zu finden.
  • Um dieses Problem zu beheben sind mehrere Lösungen vorgeschlagen worden, darunter die zwei folgenden:
  • Die erste Lösung (vom Fachmann auf dem Gebiet als "eingebettetes SQL" bezeichnet) besteht darin, SQL-Anfragen in dem Objektprogramm einzuschließen, wie dies bei der gemeinsamen Verwendung des Steuersystems für relationale Datenbanken und der herkömmlichen Programmiersprache möglich ist, wobei die Zuordnung der Datentypen dann vom Programmierer hergestellt wird. Der Nachteil dieser Lösung ist jedoch, dass sie für den Anwendungsprogrammierer sehr schwer zu implementieren ist, sie folglich wenig praktikabel ist, denn sie setzt ihrerseits eine vorzügliche Kenntnis der Sprache SQL, des relationalen Modells, des Schemas der Datenbank und der spezifischen Mechanismen des Datenbanken-Steuersystems, wie beispielsweise der Manipulation von Cursoren und der Umsetzung von Daten voraus. Zusätzlich zur Beschreibung der Zuordnung der Datentypen muss der Programmierer noch die Zuordnung zwischen den Entitäten der relationalen Datenbank und den Objekten der Objektanwendung übernehmen.
  • Die zweite Lösung besteht darin, generische Klasse zu schaffen, die eine Darstellung von relationalen Konzepten in der Objektwelt ermöglichen (Klasse "Tabelle", Klasse "n-Tupel" usw.), wobei diese Klassen eine Vereinfachung der Manipulation relationaler Daten ermöglichen. Diese Lösung hat ebenfalls als Hauptnachteil, dass sie schwierig zu implementieren ist; der Programmierer muss nämlich immer noch eine vorzügliche Kenntnis des relationalen Modells und des Schemas der Datenbank haben, nur solche Aspekte wie das Management der Zuordnung der Typen oder der Cursoren bleiben ihm erspart. Die Umsetzung dieser Lösung besteht darin, dem Programmierer eine Bibliothek von generischen Klassen zu liefern, die als Schnittstelle für das Steuersystem der relationalen Datenbank dient, wobei er außerdem die Zuordnung zwischen den Entitäten der relatio nalen Datenbank und den Objekten der Objektanwendung übernehmen muss. Eine solche Lösung ist von Doug Wright in "Designing a relational database interface in C++", Object Magazine, Bd. 4 (Nr. 2), S. 55–56, Mai 1994, beschrieben worden.
  • Die vorliegende Erfindung hat zum Ziel, die verschiedenen vorgebrachten Nachteile durch bekannte Lösungen zu beseitigen, und schafft eine Vorrichtung zum Erzeugen von objektorientierten Schnittstellen, die derart konzipiert sind, dass die relationalen Daten auf eine einfache und für den Objektprogrammierer durchsichtige Weise manipuliert werden können.
  • Zu diesem Zweck zeichnet sich die Vorrichtung zum Erzeugen von objektorientierten Schnittstellen, die im Oberbegriff erwähnt ist, dadurch aus, dass sie gemäß einem Verfahren zur Erzeugung von objektorientierten Schnittstellen und anhand des Schemas der relationalen Datenbank ein Objektschema erzeugt, das eine objektorientierte Ansicht der vorhandenen relationalen Datenbank darstellt, wobei diese Ansicht, die die objektorientierte Schnittstelle bildet, aus einer Gruppe von Klassen zusammengesetzt ist, die die in der relationalen Datenbank gespeicherten Entitäten repräsentieren, wobei am Eingang der Vorrichtung zum Schnittstellenerzeugen die Beschreibung der Datenbank in einer Standardsprache zur Definition und Manipulation von Daten angewendet wird.
  • In Analogie und für ein besseres Verständnis, wobei vorausgesetzt wird, dass eine Objektansicht mit einer relationalen Ansicht vergleichbar ist, ohne dass deswegen diese Letztere verwendet wird, sollte in Erinnerung gebracht werden, dass der Begriff der Ansicht, wie er im relationalen Bereich bekannt ist, eingeführt worden ist, um einem Anwender zu ermöglichen, die Daten anders als über die in der Datenbank definierten Tabellen zu manipulieren. Eine Ansicht ist dann eine besondere Wahrnehmung der Daten aus einer oder mehreren der Tabellen; sie wird in Form einer Auswahlanforderung in dem Datenverzeichnis gespeichert. Eine Ansicht ist im Grunde genommen eine virtuelle Tabelle, d. h. eine Datensammlung ohne physische Existenz, ein Objekt, dessen Definition aus jenen der Tabellen und/oder weiterer Ansichten abgeleitet ist und das als Auswertung einer Datenbankabfrage betrachtet werden kann. Folglich besteht gemäß der Erfindung die Lösung darin, dem Programmierer eine objektorientierte Ansicht der Datenbank, auf die zuzugreifen ist, anzubieten, wobei die gelieferten Klassen repräsentativ für Entitäten sind, die für die Anwendung in der Datenbank geeignet sind, beispielsweise "Teilnehmer" anstelle von "Tabellen" oder "n-Tupeln", hier im Vergleich zu der zweiten Lösung, die zuvor erwähnt worden ist und darin besteht, generische Klassen zu liefern. Dies läuft darauf hinaus festzustellen, dass dem Programmierer eine Schnittstelle für den Zugriff auf das Steuersystem der Datenbank geboten wird, wobei die Schnittstelle für die Anwendung und folglich für die Datenbank, auf die zuzugreifen ist, spezifisch ist, und folglich für jede Datenbank eine solche Schnittstelle konstruiert werden muss. Deshalb muss eine Erzeugungsvorrichtung, auch Generator genannt, verwendet werden, um die Schnittstellen für die relationale Datenbank zu erzeugen, wobei die Erzeugungsvorrichtung als Eingangsgröße eine Beschreibung der Datenbank entgegennimmt. Anders ausgedrückt: Die Erzeugungsvorrichtung ermöglicht, anhand des relationalen Schemas oder einer Beschreibung der höchsten Ebene eine objektorientierte Schnittstelle für den Zugriff auf die Daten dieses Schemas zu erzeugen, wobei die Ansicht, die die Schnittstelle bildet, sich aus einer Gruppe von Klassen zusammensetzt, die die logischen Entitäten des Datenschemas repräsentieren und den Zugriff auf diese Daten ausführen. Dank der Erfindung ist es folglich nicht notwendig, dass der Programmierer die relationalen Konzepte kennt, nur die Kenntnis der in der Datenbank gespeicherten Entitäten, die der Anwendung eigen sind, ist zweckdienlich.
  • Außerdem zeichnet sich die Vorrichtung zum Erzeugen von objektorientierten Schnittstellen gemäß der Erfindung dadurch aus, dass sie für die Verwaltung von Objekten im Speicher und die Manipulation von Objektgruppen eine als Sammlungsklasse bezeichnete generische Klasse erzeugt, die eine Durchsuchung einer Gruppe von Instanzen einer Klasse oder der Instanzen, die Auswahlkriterien entsprechen, ermöglicht, wobei diese Sammlungsklasse, um einen schnellen Zugriff auf die Daten zu ermöglichen, Mechanismen des Steuersystems der relationalen Datenbank, wie etwa Cursoren, einschließt, derart, dass die auf die Objekte im Speicher bezogenen Daten durch das Datenbanken-Steuersystem selbst verwaltet werden.
  • Im Allgemeinen kann nämlich eine Anfrage eine Menge von Zeilen zurückgeben, deren Anzahl vor der Ausführung unbekannt ist. Um dieses Problem zu lösen bieten die relationalen Systeme die Verwendung eines Cursor genannten Arbeitsbereiches und ermöglichen, die Zeilen, die eine vorgegebene Bedingung erfüllen, einzeln auszuwählen (den Host-Variablen Werte zuzuweisen). Dieser Cursor entspricht folglich einem Speicherbereich, dessen Größe während der Ausführung des Programms dynamisch festgelegt wird, der die Gesamtheit der ausgewählten Zeilen enthält und auf diese Weise die Auswahl einer Menge von Zeilen ermöglicht, ohne dass jedoch die Anzahl der ausgewählten Zeilen im Voraus bekannt ist. Ein Cursor ist einer Anfrage zugeordnet; in ein und demselben Programm kann es genau so viele Cursoren wird Anfragen geben, wobei jedoch alle diese Cursoren verschiedene Namen tragen müssen. Daher wird gemäß der Idee der Erfindung, statt mehrere Objekte wiederzugewinnen und sie alle auf einmal zu erzeugen, eine generische Sammlungsklasse erzeugt, die ermöglicht, die Cursoren des Steuersystems der relationalen Datenbanken einzuschließen. Die Objekte werden dann nach und nach während des Durchgangs durch die Datensammlung erzeugt, obwohl alle in der relationalen Datenbank gesichert sind, selbst wenn sie nicht im Objektspeicher erzeugt werden. Das Einschließen dieser herkömmlichen Mechanismen für den Zugriff auf relationale Datenbanken ermöglicht in sehr vorteilhafter Weise, eine Leistungsfähigkeit zu bewahren, die jener einer herkömmlichen Anwendung, die in einer herkömmlichen Sprache unter Verwendung des Einschlusses von SQL-Anfragen (eingebettetes SQL, wie weiter oben erwähnt) geschrieben ist, gleichkommt. Die Rekonstruktion von derartigen Mechanismen auf der Objektseite, Mechanismen, die bereits von jedem relationalen System geboten werden, bedeutet nämlich erhebliche Verminderung der erzielten Leistungsfähigkeit. Außerdem ermöglicht das Einschließen dieser Mechanismen zu vermeiden, dass das Verwalten der Daten im Speicher ausgeführt werden muss, da dieses Letztere schon durch die eingeschlossenen Mechanismen realisiert wird.
  • Vorzugsweise umfasst die erzeugte Sammlungsklasse zwei private Attribute sowie zwei öffentliche Methoden, eine Methode zur Erzeugung von Instanzen der Klasse, die nur gelegentlich angewendet wird, und eine Methode zum Durchlaufen der Sammlung, die die Wiedergewinnung der Objekte der Sammlungsklasse einzeln ermöglicht, wobei die Methode zur Erzeugung von Instanzen von Klassen als Eingangsparameter eine Anforderung in der Standardsprache zur Definition und Manipulation von Daten verwendet, die der Anwender ausgeben will, diese Anforderung ausführt und den Identifizierer des Cursors wiedergewinnt, der die n-Tupel enthält, die eine Antwort auf die Kriterien der Anforderung darstellen, wobei dann, wenn effektiv gewünscht ist, die der Anforderung entsprechenden Objekte zu erzeugen, die Methode zum Durchlaufen der Sammlung für die wiedergewonnene Sammlung gestartet wird, wobei die Objekte dann einzeln erzeugt werden.
  • Es ist an dieser Stelle zu präzisieren, dass gemäß der Erfindung die Methode zur Erzeugung von Instanzen der Klassen selbstverständlich nur ausnahmsweise angewendet wird (siehe nachfolgend beschriebenes Beispiel).
  • Außerdem umfasst die Vorrichtung zum Erzeugen von objektorientierten Schnittstellen gemäß der Erfindung in kennzeichnender Weise, um die Steuerung von Transaktionen zuzulassen, zum einen eine Datenbank-Administrator genannte Klasse, die vier Methoden für die Verwirklichung von Funktionen in Bezug auf die Validierung einer Transaktion, die Annullierung einer Transaktion, den Anschluss an das System zur Steuerung der relationalen Datenbanken und schließlich das Trennen von dem System zur Steuerung der relationalen Datenbanken implementiert, und erzeugt zum anderen für jede Klasse, die eine relationale Tabelle repräsentiert, eine Tabelle, die einerseits die Identifizierer der im Speicher vorhandenen Objekte, wobei ein Objektidentifizierer ein primärer Schlüssel ist, der das entsprechende relationale Objekt identifiziert, und andererseits die Adressen der Objekte enthält, wobei diese Tabellen durch die Methoden, die für die Erzeugung oder die Unterdrückung eines Objekts verwendet werden, aktualisiert werden, wobei für jede Klasse eine Tabellenklasse, zu der der Name der Klasse ge hört, erzeugt wird, um diese Methoden zu implementieren, die Funktionen zur Steuerung des Speichers verwirklichen und die Beschreibung der Tabelle enthalten, die die im Speicher vorhandenen Objekte verzeichnet, wobei eine solche Steuerung somit ermöglicht, dieselbe relationale Entität nur einmal in das Objekt zu laden.
  • Was die Datenmanipulation betrifft, so ist es im Allgemeinen notwendig, relationale Daten vorübergehend auf Objektdaten abzubilden, damit eine Anwendung auf in der relationalen Datenbank gespeicherte relationale Daten zugreifen kann. Diese Kopien umfassen nur die n-Tupel, die an der Verarbeitung der Objektanwendung beteiligt sind. Das Laden der Daten erfolgt mittels einer Phase des Zugriffs auf die Daten in der relationalen Datenbank, um die n-Tupel wiederzugewinnen, die den Kriterien einer Anfrage genügen, anschließend mittels einer Phase der Steuerung des konkurrierenden Zugriffs auf das Betriebsmittel und schließlich mittels einer Phase der Übersetzung der wiedergewonnenen n-Tupel in Objektdaten. Das Steuern des konkurrierenden Zugriffs auf die relationale Datenbank erfolgt durch ein implizites Verriegeln der Daten, das je nach Art der Verarbeitung ausgeführt wird. Jeder Befehl zum Lesen eines Datums hat das Setzen einer Verriegelung zur Folge, die den ermittelten Daten gemeinsam ist, und jeder Aktualisierungsbefehl hat das Setzen einer exklusiven Verriegelung für diese Daten zu Folge. Es ist jedoch möglich, das Setzen einer exklusiven Verriegelung bei einem Lesen zu erzwingen, was für das Laden von Daten in die Objektwelt gemacht wird; dies ermöglicht sicherzustellen, dass die Daten bei Abschluss der Verarbeitung als Objekt nicht ungültig sind, da es nicht mehr möglich ist, sie während dieser Zeit in der relationalen Umgebung zu modifizieren. Was insbesondere die Steuerung der Transaktionen anbelangt, so ist es erforderlich, die bei einer Transaktion verwendeten Betriebsmittel freigeben zu können und die Aktualisierung auf der Platte einzuleiten. Um die Betriebsmittel in der Objektanwendung zu steuern werden einerseits Methoden zum Steuern der relationalen Datenbank und andererseits Methoden zum Verwalten des Objektspeichers angewendet. Folglich ist es gemäß der Idee der Erfindung erforderlich, der Objektanwendung zu ermöglichen, bestimmte Funktionen der Datenverwaltung zu nutzen. Deswegen wird einerseits, um das Steuern der relationalen Datenbank zu ermöglichen, eine Datenbank-Administrator-Klasse geschaffen, die vier Methoden für die Verwirklichung der folgenden Funktionen ausführt:
    • – einer Funktion zur Validierung der Transaktion, die unter anderem die relationale Datenbank aktualisieren, die Betriebsmittel freigeben und während der Verarbeitung verwendete Objekte aus dem Speicher entfernen soll,
    • – einer Funktion zur Annullierung der Transaktion, die ermöglicht, alle seit der letzten Validierung erfolgten Aktualisierungen rückgängig zu machen, und die außerdem den Objektspeicher leert,
    • – einer Funktion für den Anschluss an das Steuersystem der relationalen Datenbanken, die außerdem, um ausgeführt zu werden, das Verbindungswort und das Passwort des Anwenders anfordert, wobei das Öffnen der relationalen Datenbank implizit erfolgt,
    • – einer Funktion für das Trennen von dem Steuersystem der relationalen Datenbanken, wobei das Schließen der relationalen Datenbank ebenfalls implizit erfolgt.
  • Genauso werden andererseits Verfahren zum Verwalten des Objektspeichers benutzt. Es ist nämlich erforderlich, den von den Objekten benutzten Speicherraum nach jeder Transaktion leeren zu können, denn wenn die Transaktion auf relationaler Seite erst einmal abgeschlossen ist, werden die Verriegelungen freigegeben und die Daten im Objektspeicher sind nicht mehr gültig. Deswegen ist es notwendig, zusätzliche Klassen, in denen die für dieses Rücksetzen nützlichen Daten gespeichert sind, sowie die Methoden für die Verwaltung des Arbeitsspeichers zu schaffen. Die schon im Speicher vorhandenen Objekte müssen bekannt sein, um zu vermeiden, dass sie bei jedem Zugriff dupliziert werden, wodurch es möglich ist, die Kohärenz im Speicher aber auch in der relationalen Datenbank zu bewahren. Um ein effizientes Steuern dieser Kohärenz zu ermöglichen, schlägt die Erfindung vor, für jede Klasse, die eine relationale Tabelle repräsentiert, eine Tabelle zu erzeugen, die einerseits die Identifizierer (Schlüssel des entsprechen den n-Tupels) der im Speicher vorhandenen Objekte und andererseits die Adressen dieser Objekte enthält, wobei diese Tabellen mit den Methoden aktualisiert werden, die für die Erzeugung oder die Unterdrückung eines Objekts verwendet werden. Es ist also die Lebensdauer dieser Tabellen zu bestimmen, d. h. es muss bekannt sein, wann sie zu erzeugen sind und wann sie zu vernichten sind. Es ist möglich, beim Starten der Anwendung statisch eine Tabelle pro Klasse zu erzeugen; jedoch besitzt diese Lösung den wesentlichen Nachteil, dass sie mit einem übermäßigen Bedarf an Speicherplatz einhergeht. Eine dynamische Lösung, bei der jede Klasse eine statische Variable enthält, die angibt, ob die Anwesenheitstabelle erzeugt oder nicht erzeugt worden ist, ist klar vorzuziehen, da diese Lösung ermöglicht, die Anzahl der Tabellen im Speicher auf die für eine gegebene Transaktion benutzte Anzahl Klassen zu beschränken. Für jede Klasse wird eine Tabellenklasse, zu der der Name der Klasse gehört, erzeugt, wobei die Funktionen zur Speicherverwaltung sowie die Beschreibung der Tabelle, die die im Speicher vorhandenen Objekte verzeichnet, implementiert werden. Dazu sind typischerweise verschiedene Steuerungsmethoden erforderlich. Eine erste Methode ermöglicht, Kenntnis darüber zu erlangen, ob das Objekt, das dem in einen Parameter überführten Schlüssel entspricht, bereits im Speicher vorhanden ist, und, falls ja, dann ist es unnütz, ihn erneut zu erzeugen, es genügt, einfach seine Adresse wiederzugewinnen. Eine zweite Methode ermöglicht, das Objekt als im Speicher vorhanden zu verzeichnen. Schließlich ermöglicht eine dritte Methode im Fall der Zerstörung des Objekts, es von der Liste der im Speicher vorhandenen Objekte zu streichen. Um mit der Sprache C++ die Instanz der Tabellenklasse, die zu dem Namen der Klasse C gehört, von der sie abhängt, wiederzufinden, enthält die Klasse C einen Zeiger auf diese Instanz der Tabellenklasse, wobei der Zeiger als statische Variable deklariert ist. Außerdem ist jede dieser Tabellenklassen eine Klasse, die von einer Haupttabellenklasse geerbt ist. Dies ermöglicht, die Adressen der Instanzen der Tabellenklassen in einer Objekttabelle zu speichern und anschließend diese durchzugehen, um für jede Instanz der Tabellenklasse den Aufruf einer Methode zum Löschen des Objektspeichers, der die Instanzobjekte dieser Klasse enthält, zu starten, um die Speicherzuweisung aufzuheben, wenn eine Funktion zur Validierung oder Annullierung einer Transaktion ausgeführt wird. Die Methode zum Löschen des Objektspeichers, die über eine Tabellenklasse definiert ist, durchsucht diese Tabelle, um alle bezeichneten Objekte zu vernichten, selbstverständlich ohne die entsprechenden relationalen Daten zu zerstören. Diese Methode zum Löschen wird nicht auf der Ebene der Haupttabellenklasse ausgeführt, da sie dort auf abstrakte Weise beim Durchgehen durch die Tabelle definiert wird; es ist die Methode zum Löschen des einer Tabellenklasse zugehörigen Objektspeichers, die aktiviert wird.
  • Auf bemerkenswerte Weise ermöglicht das Verfahren zum Erzeugen von objektorientierten Schnittstellen, das von der Vorrichtung zum Erzeugen von Schnittstellen gemäß der Erfindung ausgeführt wird, in mehreren Phasen das Objektschema anhand des relationalen Schemas zu erzeugen, indem es systematisch einerseits die relationalen Tabellen in Klassen übersetzt, und andererseits die relationalen Verbindungsglieder zwischen den Tabellen, die durch Fremdschlüssel ausgedrückt sind, in Verbindungsglieder zwischen Objekten, die durch Methoden repräsentiert werden, übersetzt, wobei es hierzu in einer ersten Phase der lexikalischen und syntaktischen Analyse den Syntaxbaum erzeugt, der das relationale Schema anhand der Standardsprache zur Definition und Manipulation von Daten beschreibt, anschließend in einer zweiten Phase ein erstes Mal den Baum durchläuft, um alle Verbindungstabellen, d. h. die Tabellen, die als Attribute nur Fremdschlüssel besitzen, zu ermitteln, dann in einer dritten Phase den Baum ein zweites Mal durchläuft, um eine Klasse für jede Tabelle zu erzeugen, die keine Verbindungstabelle ist, wobei für jeden Fremdschlüssel einer solchen Tabelle Verbindungssteuerungsmethoden erzeugt werden, und wobei für jede Verbindungstabelle, die diese Tabelle betrifft, außerdem die Verbindungsmethoden, die der Klasse dieser Tabelle entsprechen, erzeugt werden.
  • Folglich wird gemäß diesem Verfahren die Vorrichtung zum Erzeugen von Schnittstellen ausgehend von der Beschreibung der Datenbank in der Standardsprache zur Definition und Manipulation von Daten, die auf ihren Eingang Anwendung findet, in der ersten Phase der lexikalischen und syntaktischen Analyse den Syntaxbaum konstruieren, der die Beschreibung des Konzeptionsschemas ist, wobei dieser Baum den schriftlichen Ausdruck in der Sprache zur Definition und Manipulation von Daten, z. B. SQL, darstellt. Wenn der Baum erst einmal auf diese Weise konstruiert worden ist, wird er mit herkömmlichen Durchlaufalgorithmen zweimal durchlaufen: Ein erstes Mal, um die Verbindungstabellen wiederaufzufinden, wobei bekannt ist, dass die Verbindungstabellen die Tabellen sind, die als Attribute nur Fremdschlüssel haben, wobei diese Tabellen nicht entsprechend der Klassen übersetzt werden, sondern dann dazu verwendet werden, Verbindungsmethoden über die erzeugten Entitäten zu erzeugen. Danach wird der Baum ein zweites Mal durchlaufen, um die übrigen Tabellen, die folglich keine Verbindungstabellen sind, wiederzugewinnen und um für jede dieser Tabellen eine Klasse zu erzeugen, so dass folglich jeder Tabelle eine Klasse entspricht. Neben den Verbindungsmethoden, die anhand der Verbindungstabellen erzeugt werden, die einer bestimmten Klasse entsprechen, wird auch für jeden Fremdschlüssel einer Tabelle, die keine Verbindungstabelle ist, eine Verbindungsmethode erzeugt. Es kann jedoch hinzugefügt werden, dass für die Tabellen, die keine Verbindungstabellen sind, jedoch mehr als ein Fremdschlüsselattribut umfassen, in diesem Fall zum gleichen Zeitpunkt, zu dem die bezeichneten Klassen der Verbindungsmethoden erzeugt werden, eine Klasse erzeugt wird.
  • Die folgende Beschreibung anhand der beigefügten Zeichnung, wobei das Ganze nur beispielhaft und nicht einschränkend ist, wird verständlich werden lassen, wie die Erfindung umgesetzt werden kann.
  • 1 zeigt schematisch die Umgebung der Vorrichtung zum Erzeugen von objektorientierten Schnittstellen.
  • 2 unterbreitet ein Anwendungsbeispiel zur Erzeugung von Klassen anhand eines relationalen Schemas.
  • Die Beschreibung und die Wiedergabe von 1 ermöglichen, die allgemeinen Prinzipen der Vorrichtung GEN zum Erzeugen von objektorientierten Schnittstellen darzulegen, die dafür vorgesehen ist, den Zugriff von neuen Anwendungen OOA, die in objektorientierten Umgebungen entwickelt worden sind, auf vorhandene relationale Datenbanken RDB, die von einem oder mehreren Steuersystemen RDBMS für relationale Datenbanken gesteuert werden, zuzulassen. Typischerweise erzeugt die Vorrichtung GEN zur Schnittstellenerzeugung gemäß einem Verfahren zum Erzeugen von objektorientierten Schnittstellen und anhand des Schemas der relationalen Datenbank RDB ein Objektschema, das eine objektorientierte Ansicht der vorhandenen relationalen Datenbank RDB darstellt, wobei diese Ansicht, die die objektorientierte Schnittstelle OOI bildet, aus einer Gruppe von Klassen zusammengesetzt ist, die die in der Datenbank gespeicherten Entitäten repräsentieren. Diese Gruppe von Klassen bildet nämlich die Schnittstelle für den Zugriff auf das Steuersystem RDBMS, die von der Anwendung OOA benutzt wird. Die Schnittstelle OOI bietet somit eine Gruppe von Funktionen für die Manipulation und den Zugriff auf Daten, wie etwa die Manipulation einer Sammlungen von Objekten, die Erzeugung, die Unterdrückung oder die Aktualisierung eines Objekts, den einfachen Zugriff auf ein Datum, den Zugriff auf ein Datum oder die Navigation über ein relationales Verbindungsglied. Außerdem erlaubt die Schnittstelle OOI auch das Steuern von Transaktionen unter Anwendung von bekannten Mechanismen, die Systemen zum Steuern von relationalen Datenbanken eigen sind. Am Eingang der Vorrichtung GEN zur Schnittstellenerzeugung findet die Beschreibung der Datenbank RDB in einer Standardsprache zur Definition und Manipulation von Daten Anwendung, beispielsweise in der Sprache SQL, wobei die Definitionen der Tabellen der Datenbank mit Hilfe dieser Sprache durchsucht werden. Nach dem Verfahren gemäß der Erfindung wird das Objektschema anhand des relationalen Schemas erzeugt, indem systematisch folgende Übersetzungsregeln angewendet werden: Jede relationale Tabelle wird in eine Klasse übersetzt, und jedes relationale Verbindungsglied zwischen den Tabellen, das durch Fremdschlüssel ausgedrückt ist, wird in einen Zusammenhang zwischen Objekten übersetzt, der durch Methoden, und insbesondere Methoden zur Erzeugung einer Verbindung, zur Unterdrückung der Verbindung und zum Durchlaufen der Verbindung, repräsentiert ist. Folglich werden die Verbindungstabellen, die verwendet werden, um die relationalen Verbindungsglieder auszudrücken, nicht in Klassen übersetzt. Allgemein können verschiedene Typen von relationalen Verbindungsgliedern in einem relationalen Schema darge stellt werden; sie können verschiedene Kardinalitäten (1-1, 1-n, n-m) oder Eigenschaften, die ihnen zugeordnet sind, aufweisen, wobei die Kardinalität von den Eindeutigkeitsbedingungen abhängt, die in den Fremdschlüsseln deklariert sind (das Fremdschlüsselattribut kann "eindeutig" definiert sein, kann ein Primärschlüssel sein usw.).
  • Folglich wird gemäß der Erfindung keine Objektsprache, wie etwa die SQL-Objektsprache, benutzt, sondern der Zugriff auf Daten wird in vorteilhafter Weise durch Methoden in den erzeugten Klassen verwirklicht. Es ist zu beachten, dass die Vorrichtung zur Schnittstellenerzeugung die relationale Datenbank nicht in eine Objektdatenbank transformieren wird. Im Grunde genommen werden die relationalen Daten mit dem Ablauf der Benutzeranwendung in Objekte übersetzt: Wenn diese Letztere ein Datum anfordert, wird dieses in ein Objekt übersetzt, wobei nur die Daten übersetzt werden, die in die Verarbeitung eingehen. Außerdem werden, um die Kohärenz zwischen der relationalen Welt und der Objektwelt zu gewährleisten, die Daten im Relationalen verriegelt, sobald sie von der Anwendung benutzt werden. Außerdem muss überwacht werden, dass die relationalen Daten nicht als Objekt dupliziert werden, um auch hier die Kohärenz zwischen diesen beiden Welten sicherzustellen. Wenn entsprechend der Anwendung gewünscht wird, auf ein Datum zuzugreifen, wird auf diese Weise bevor es in ein Objekt übersetzt wird, verifiziert, dass es noch nicht übersetzt worden ist.
  • 2 ermöglicht die Veranschaulichung eines sehr einfachen Anwendungsbeispiels zur Erzeugung von Klassen anhand eines relationalen Schemas, wobei insbesondere gezeigt wird, wie die üblichen relationalen Tabellen in Klassen übersetzt werden, während die Verbindungstabellen hingegen in Methoden übersetzt werden, die die relationalen Verbindungsglieder repräsentieren. In der Figur sind drei relationale Tabellen gezeigt; sie ermöglichen, Studenten, den Studenten angebotene Kurse sowie den Besuch dieser Kurse durch die Studenten aufzuzeichnen. Eine erste Tabelle STUDENT, die die Studenten betrifft, umfasst drei Spalten, welche jeweils die den Studenten identifizierende Nummer ST_NUM, die ein Primärschlüssel ist, den Namen des Studenten NAME bzw. schließlich das Alter des Studenten AGE enthalten. Diese Tabelle wird in eine Klasse STUDENT übersetzt, die drei Attribute ATTRIBUTES umfasst, die den Spalten der übersetzten Tabelle entsprechen. Eine zweite Tabelle COURSE, die sich auf die Kurse bezieht, umfasst ebenfalls drei Spalten, die jeweils die den Kurs identifizierende Nummer CS_NUM, die ein Primärschlüssel ist, die Benennung des Kurses TITLE bzw. die Anzahl der diesem Kurs zugeteilten Stunden NB_HRS enthalten. Diese Tabelle wird in eine Klasse COURSE übersetzt, die drei Attribute ATTRIBUTES umfasst, die den Spalten der übersetzten Tabelle entsprechen. Eine dritte Tabelle ATTEND, die den Besuch dieser Kurse durch die Studenten betrifft, umfasst zwei Spalten, welche die den Studenten identifizierende Nummer ST_NUM und die den Kurs identifizierende Nummer CS_NUM enthalten, die Fremdschlüssel FK sind, die Primärschlüsseln mit der gleichen Bezeichnung entsprechen, wobei diese Tabelle typisch eine Verbindungstabelle ist, denn sie enthält nur Fremdschlüssel, wobei jedes n-Tupel ein relationales Verbindungsglied zwischen einem Studenten und einem Kurs repräsentiert. Diese Tabelle wird folglich nicht in eine Klasse, sondern in Methoden METHODS in den Klasen, auf die sie verweist übersetzt: in der Klasse STUDENT mittels einer Methode Courses(), die eine Sammlung von Kursen Collection<Course> zurückgibt, und in der Klasse COURSE durch eine Methode Students(), die eine Sammlung Student Collection<Student> zurückgibt. Ein derartiges relationales Schema kann unter Verwendung beispielsweise der Sprache SQL als Sprache zur Definition und Manipulation von Daten wie folgt dargestellt werden:
    CREATE TABLE STUDENT(
    ST_NUM number (6) PRIMARY KEY,
    NAME char (80),
    AGE number (3));
    CREATE TABLE COURSE(
    CS_NUM number (6) PRIMARY KEY,
    TITLE char (80),
    NB_HRS number (3));
    CREATE TABLE ATTEND
    ST_NUM number (6) REFERENCES STUDENT (ST_NUM),
    CS_NUM number (6) REFERENCES COURSE (CS_NUM));
  • Außerdem bedeutet in Bezug auf die Bestimmung der Kardinalität die Tatsache, dass keine Eindeutigkeitsbedingungen über die Attribute der dem Besuch der Kurse ATTEND zugehörigen Relation definiert sind, dass die Kardinalität des relationalen Verbindungsglieds von der Ordnung n-m ist, d. h. dass ein Student mehrere Kurse besuchen kann und dass ein Kurs von mehreren Studenten besucht werden kann. Wenn hingegen das Attribut ST_NUM der Relation ATTEND als "eindeutig" oder als ein Primärschlüssel deklariert wäre, dann wäre die Kardinalität des relationalen Verbindungsglieds von der Ordnung 1-n, was bedeutet, dass ein Student nur einen einzigen Kurs besuchen kann, denn er kann nur ein einziges Mal in der Tabelle ATTEND erscheinen, während ein Kurs von mehreren Studenten besucht werden kann. In diesem Fall könnte die Methode Courses() der erzeugten Klasse STUDENT keine Sammlung von Kursen, sondern nur einen einzigen Kurs zurückgeben.
  • 2 zeigt folglich einen Teil der Schnittstelle der von der Vorrichtung GEN zur Schnittstellenerzeugung erzeugten und implementierten Klassen, wobei diese Implementierung den wirklichen Zugang zu dem Steuersystem RDBMS der Datenbanken erlaubt. Jede erzeugte Klasse enthält eine Gruppe von gemeinsamen Methoden, wovon einige auf die Klasse, d. h. auf die Gruppe aller Instanzen, anwendbar sind, während andere auf Objekte, d. h. auf Instanzen, anwendbar sind. Für die Erzeugung von Schnittstellen gemäß der Erfindung sind die Methoden der Klasse, insbesondere in der Sprache C++, durch statische Funktionen dargestellt, wie beispielsweise die Erzeugungsmethoden oder Methoden zur Suche oder Abfrage, die ermöglichen, ein Objekt zu erhalten, wenn sein Schlüssel bekannt ist, oder eine Gruppe von Objekten zu erhalten, indem einfache Auswahlkriterien angewendet werden. Die direkt auf Objekte anwendbaren Methoden sind für Operationen zur Unterdrückung oder Aktualisierung geeignet. Ein Beispiel für eine (unter Verwendung der Sprache C++) erzeugte Klasse für die zuvor beschriebene Tabelle STUDENT ist nachstehend gegeben:
  • Figure 00170001
  • Wie aus diesem Beispiel hervorgeht, ist folglich eine Menge von Operationen für die Manipulation von Daten und für den Zugriff auf diese vorgesehen und wird mit der auf diese Weise erzeugten objektorientierten Schnittstelle angeboten. Für ein besseres Verständnis der Operationen, die in diesem Beispiel ausgeführt werden, folgen einige Präzisierungen in Bezug auf die benutzten Methoden.
  • Die Erzeugungsmethode, die ein Objekt erzeugt und gleichzeitig die entsprechenden Daten (den Schlüssel des Objekts und gegebenenfalls die Initialisierungsparameter, die eingegeben sind) aus der Datenbank einfügt, ist im Grunde genommen, gemäß der Sprache C++, die in dem vorliegenden Beispiel verwendet worden ist, der Konstrukteur der erzeugten Klasse. In dem vorhergehenden Beispiel nimmt der Konstrukteur, der folglich die Methode zur Erzeugung von Klasseninstanzen ist, als Parameter den Schlüssel der Entität Student, der die Nummer des Studenten ist:
    Student (int key);
  • Die Methode zur Unterdrückung, die ein Objekt und gleichzeitig die entsprechende Entität aus der Datenbank entfernt, entspricht der Methode "destroy", die im vorhergehenden Beispiel benutzt worden ist:
    destroy(); // lösche das Objekt und die Daten in db
    ~Student(); // entferne das Objekt aus dem Speicher (und nur aus dem Speicher)
  • Der Zerstörer "~Student" wird in erster Linie intern verwendet, er steht jedoch für den Programmierer, der die Zuweisung oder die Aufhebung der Zuweisung von Speicherplatz managen möchte, zur Verfügung, wobei bekannt ist, dass das Löschen des Objekts im Speicher sich nicht auf eine Modifikation auswirkt, die während einer Transaktion an einer Entität verwirklicht worden sein könnte, und folglich diese nicht annulliert, da der Zerstörer nur das Objekt aus dem Speicher entfernt.
  • Für jede Klasse werden zwei Methoden zur Abfrage und zur Suche erzeugt: Die Methode "get" gibt ein Objekt zurück, dessen Schlüssel sie kennt, während die Methode "query" eine Gruppe von Objekten zurückgibt, deren Attribute einfachen Kriterien genügen:
    static Student *get (int key);
    static Collection<Student> *query (char *where);
  • Die Aktualisierungen werden mit Hilfe von Methoden ausgeführt, denen Attribute zugeordnet sind. Dies sind die Methoden zum Lesen und zum Schreiben von Attributen, wobei die Methoden zum Schreiben von Attributen die an den Objekten vorgenommenen Modifikationen in die Datenbank hineintragen. Bei der üblichen C++-Version manipuliert der Programmierer die Attribute nicht direkt, es müssen auch zugeordnete Methoden benutzt werden. Es gibt keine Methode, um die zu den Schüsseln gehörenden Attribute zu aktualisieren, da sie die Entität identifizieren. Die Methoden zum Lesen und zum Aktualisieren des Attributs "age" sind also folgende:
    int age (); // lesen
    void age (int); // schreiben
  • Außerdem werden Methoden für die Navigation durch die relationalen Verbindungsglieder erzeugt. In der erzeugten Klasse Student gibt es folglich eine Methode, um durch das relationale Verbindungsglied "attend" (erste Zeile) zu navigieren, eine zweite, um ein relationales Verbindungsglied zwischen dem laufenden Objekt "Student" und einem Objekt "Kurs" (zweite Zeile) zu schaffen, und eine dritte, um eine derartige Relation aufzuheben (dritte Zeile).
    Collection<Course> *attend_course ();
    void create_attend (Course*);
    void delete_attend (Course*);
  • Die meisten dieser Methoden schließen Mechanismen der Sprache zur Definition und Manipulation von Daten wie etwa SQL ein; beispielsweise wird die Methode "attend course" unter Verwendung der folgenden SQL-Mechanismen implementiert:
    SELECT C.* FROM COURSE C, ATTEND A WHERE A.ST_NUM = st_num (des Zustands des Objekts) AND A.CS_NUM = C.CS_NUM
  • Außerdem wird eine generische Klasse "Collection" verwendet, um Gruppen von Objekten zu manipulieren; sie ermöglicht, die Gruppe der Instanzen einer Klasse oder der Instanzen, die Auswahlkriterien entsprechen, zu durchsuchen.
  • Diese Klasse schließt nämlich vorteilhaft die Cursoren des Datenbanken-Steuersystems RDBMS ein, derart, dass das Speichern der Daten durch das System RDBMS und nicht auf Objektebene erfolgt. Die Objekte werden erst erzeugt, wenn eine Suchoperation vom Typ "fetch" angefordert ist. Die Sammlungen resultieren oftmals aus Methoden vom Typ "query" oder "Navigation in den relationalen Verbindungsgliedern".
  • Figure 00200001
  • Die Steuerung von Transaktionen kann ebenfalls mit Hilfe desselben Beispiels eindeutig ausgedrückt werden, wobei im Gedächtnis behalten wird, dass das Grundprinzip bei der vorliegenden Erfindung darauf zurückzuführen ist, dass die Erzeugungsvorrichtung GEN ermöglicht, Objektschnittstellen zu liefern, um auf vorhandene Daten, die in einem Datenbanken-Steuersystem RDBMS gespeichert sind, zuzugreifen, und dass die manipulierten Objekte nur Ansichten der relationalen Daten sind. Dies bedeutet, dass sich die erzeugte Schnittstelle vorteilhaft auf die Mechanismen des Datenbanken-Steuersystems stützen kann, etwa auf die Steuerung von Transaktionen oder auf die Cursoren, die einfach von den Sammlungen eingeschlossen werden.
  • Alle an den Objekten ausgeführten Operationen werden direkt in entsprechende relationale Operationen übersetzt, und die Daten in den Pufferspeichern des Steuersystems RDBMS sind die Nachbildung des Zustands der Objekte in dem Speicher, wobei diese Objekte nur Ansichten des Zustands der Datenbank RDB sind. Die tatsächliche Aktualisierung der Datenbank wird mit Hilfe von Befehlen vom Typ "commit" und "abort" (die Funktionen zur Validierung bzw. Annullierung von Transaktionen entsprechen) erzielt, die von der Anwendung über eine Steuerungsklasse ausgelöst werden, die als Datenbank-Administrator bezeichnet wird und für die Steuerung von Transaktionen geschaffen worden ist. Auf diese Weise werden beispielsweise alle Erzeugungs-, Lösch- und Modifizie rungs-Operationen direkt in das Datenbanksystem hineingetragen, jedoch nur dann validiert, wenn ein Validierungsbefehl vom Typ "commit" ausgeführt wird, oder unterdrückt, wenn ein Unterdrückungsbefehl vom Typ "abort" (oder "rollback", dem mit dem relationalen Datenbanksystem Oracle (eingetragenes Warenzeichen der Oracle Corporation) benutzten Befehl) ausgeführt wird.
  • Dieser Aspekt kann besonders gut anhand des folgenden Beispiels veranschaulicht werden, bei dem die Methode zur Aktualisierung des Attributs AGE der Klasse STUDENT unter Verwendung eines SQL-Befehls vom Typ "UP-DATE" implementiert ist:
  • Figure 00210001
  • Die gespeicherten Objekttabellen werden gehalten, so dass vermieden wird, die relationalen Entitäten zweimal zu laden, da durch ein Duplizieren Inkohärenzen entstehen können. Außerdem werden diese Tabellen verwendet, um den Speicher zu löschen, wenn ein Validierungsbefehl vom Typ "commit" gegeben wird.
  • Die Methode vom Typ "commit" der erzeugten Klasse "Datenbank-Administrator" wird mittels eines vom Steuersystem RDBMS ausgegebenen Befehls vom Typ "commit" implementiert, wobei der Speicher geleert wird. Die Schnittstelle dieser Klasse "Datenbank-Administrator" ist nachstehend unterbreitet:
  • Figure 00210002
  • Die Vorrichtung zum Erzeugen von objektorientierten Schnittstellen kann in einer zentralisierten Umgebung oder aber in einer verteilten Umgebung vorteilhaft eingesetzt werden, wobei sie in diesem letzteren Fall in bemerkenswerter Weise als Komponente für den Zugriff auf eine Datenbank benutzt wird, die das Verfahren zum Erzeugen von objektorientierten Schnittstellen ausführt, um einerseits Schnittstellen zu erzeugen, die in der Sprache zur Beschreibung der Schnittstelle der verschiedenen Klassen ausgedrückt sind, und um andererseits ausgehend von dieser Komponente einen Server zu erzeugen.
  • So können die Vorrichtung zum Erzeugen von objektorientierten Schnittstellen sowie das von der Vorrichtung ausgeführte Verfahren mit und integriert in CORBA (Common Object Request Broker Architecture) verwendet werden, wovon die Architektur von OMG (Object Management Group) in dem Dokument "The Common Object Request Broker: Architecture and specification), OMG-Dokument Nr. 93.12.43 vom Dezember 1993 beschrieben worden ist.
  • In diesem Kontext bildet nämlich die Gruppe der erzeugten C++-Klassen eine objektorientierte Zugriffskomponente auf eine Datenbank, die in einem Modus vom Typ Client/Server von verschiedenen entfernten CORBA-Clients benutzt werden kann, sobald die IDL-Schnittstellen der Sprache zur Beschreibung der Schnittstelle der verschiedenen Klassen erzeugt sind und ausgehend von dieser Komponente ein CORBA-Server als eine Gruppe von Klasse geschaffen worden ist. Deswegen werden die Gruppe der C++-Klassen, d. h. der Server, und die entsprechenden IDL-Schnittstellen gleichzeitig geschaffen. Diese IDL-Schnittstellen werden dann von dem IDL-Compiler, der in diesem Umgebungstyp geliefert wird, und genauer mit dem ORB (Object Request Broker), compiliert, um die von dem Client verwendeten Leerroutinen (vom Fachmann auf dem Gebiet auch als "stubs" (engl.) bezeichnet) und die Grundgerüste für die Konstruktion des Servers zu erhalten.
  • Das übliche Verfahren, um einen derartigen CORBA-Server zu konstruieren, ist, die IDL-Schnittstellen zu definieren, mittels des IDL-Compilers die Grundgerüste zu erzeugen und dann diese Grundgerüste manuell, d. h. durch Schreiben, zu vervollständigen, um die Objekte, die den erzeugten Grundgerüsten entsprechen, zu implementieren. Die Vorgehensweise gemäß der Erfindung ist vollkommen anders, weil die Implementierung des Servers auf Grund der Tatsache, dass die Vorrichtung zum Erzeugen von Schnittstellen die Gruppe von C++-Klassen erzeugt hat und anschließend die entsprechende IDL-Sprache definiert worden ist, schon vorhanden ist. Außerdem sind die erzeugten IDL-Schnittstellen von den C++-Listenköpfen vollkommen verschieden, da es die Konzepte statischer Funktionen und generischer Typen in der IDL-Sprache von CORBA nicht gibt. Dies bedeutet, dass für jede C++-Klasse, beispielsweise für die zuvor erwähnte Klasse "Student" drei IDL-Schnittstellen erzeugt werden: eine, die die Klasse repräsentiert und die statischen Funktionen enthält (Klasse Student), eine weitere, die ein Objekt repräsentiert, mit den nicht statischen Funktionen (Student), und eine, die die Objektsammlungen dieser Klasse repräsentiert, die im Allgemeinen von den Funktionen zur Navigation in den relationalen Verbindungsgliedern oder den Funktionen vom Typ "query" (CollectionStudent) zurückgegeben werden. Die Grundgerüste des Servers entsprechen diesen IDL-Schnittstellen und werden einfach durch Einschließen von Aufrufen der erzeugten Klassen durch die Vorrichtung zur Schnittstellenerzeugung implementiert. Die IDL-Schnittstellen, die von der Vorrichtung gemäß der Erfindung entsprechend der Klasse "Student" erzeugt werden, sind die folgenden:
  • Figure 00230001
  • Figure 00240001
  • Außerdem kann die Integration mit Objekttransaktionsdiensten, insbesondere mit OTS (Object Transaction Service) von CORBA, verwirklicht werden. Die meisten Datenbanken-Steuersysteme liefern nämlich adäquate Schnittstellen; beispielsweise liefert das System von Oracle die Schnittstelle XA des verteilten Transaktionsverarbeitungsmodells ((Distributed Transaction Processing Model von X/OPEN), die von OTS für die Betriebsmittelsteuerung verwendet werden kann.
  • Zusammenfassend lässt sich sagen, dass die vorliegende Erfindung ermöglicht, die anerkannten Vorteile einer Technologie, die die Steuerung von relationalen Datenbanken betrifft, mit der neuentwickelten objektorientierten Technologie, die derzeit gut angenommen wird, zu kombinieren, wobei man diese beiden Umgebungen auf eine einfache und effiziente Weise zusammenarbeiten lässt und sogar integriert.
  • Schlussfolgerung: Die hier beanspruchte Vorrichtung zum Erzeugen von objektorientierten Schnittstellen liefert auf vorteilhafte Weise einen objektorientierten Zugriff auf jede vorhandene relationale Datenbank, wobei sie ermöglicht, Daten zu erzeugen, zu unterdrücken, zu lesen und zu aktualisieren. Anhand des relationalen Schemas wird eine Gruppe von Klassen erzeugt, um eine Schnittstelle zu schaffen, wodurch sich der Zugriff auf Daten vereinfacht. Diese Klassen können örtlich von irgendeiner Anwendung oder in einer verteilten Umgebung als Server verwendet werden, auf den über ein Netz ein entfernter Client zugreifen kann, insbesondere ein CORBA-Client über ORB.
  • Ein Programmierer, der eine objektorientierte Anwendung entwickelt und die relationalen Datenbanken benutzten möchte, hat durch die Erfindung folgende Vorteile:
    • – Die Phase der Konzeptübersetzung der Objekte, ausgehend von Tabellen, vereinfacht sich erheblich.
    • – Gewöhnlich bedeutet der Zugriff auf eine relationale Datenbank ausgehend von einer beliebigen Programmiersprache zwangsläufig die sehr schwierige und mühselige Entwicklung eines Codes, um die Cursoren, die Übereinstimmung der Typen und der Variablen zu managen. All dies wird gemäß der Erfindung mit der Implementierung der Klassen der Schnittstelle automatisch erzeugt.
    • – Der Programmierer der Anwendung braucht sich nicht mit den Problemen befassen, die mit der Logik des Zugriffs auf die Daten einhergehen, er muss sich nur mit der Logik der Anwendung beschäftigen. Außerdem stößt er nicht mehr auf Probleme der Datenkohärenz bei der Speicherung von Daten (Verriegelungen, Duplizieren, usw.), wobei diese Letzteren automatisch von der Verwaltung der gespeicherten Objekte gelöst werden, die mit der Vorrichtung gemäß der Erfindung geliefert wird.
    • – Der Programmierer der Anwendung braucht nur ein Modell, das Objektmodell, und eine Sprache (beispielsweise kein "eingebettetes SQL") zu kennen.
  • Da das Verfahren zur Erzeugung automatisiert ist, kann die Vorrichtung zum Erzeugen von Schnittstellen gemäß der Erfindung in irgendeine Umgebung CASE (Computer Aided Software Engineering) integriert werden.
  • Ein weiterer Vorteil, der mit der Erfindung einhergeht, ist, dass der Zugriff auf relationale Datenbanken verwirklicht werden kann, wobei es weder erforderlich ist, die Datenbank in ein neues Datenbanken-Steuersystem wandern zu lassen, noch die Datenbank zu modifizieren. Außerdem wird der Zugriff von neuartigen objektorientierten Anwendungen gemeinsam mit früheren, vorhandenen Anwen dungen zugelassen, da die Objektverwaltung auf Transaktionsmechanismen der Steuerungssysteme der relationalen Datenbanken beruht.
  • Diese Vorrichtung zum Erzeugen von Schnittstellen kann auch bei der Konzeption von neuen Datenbanken verwendet werden. Für Anwendungen, für die die relationale Speicherung zweckmäßiger ist, kann zunächst das Schema der relationalen Datenbank unter Verwendung einer Methodik, die auf den Daten beruht, entworfen werden, wobei anschließend automatisch die Klassen erhalten werden, die benutzt werden, um auf die Daten zuzugreifen und sie zu manipulieren. Der dynamische Teil der Anwendung kann dann mittels einer objektorientierten Methodik entwickelt werden.
  • Außerdem war bei der Entwicklung der Vorrichtung gemäß der Erfindung die gewählte Option, keine objektorientierte Abfragesprache vom Typ SQL zu entwickeln, und zwar aus folgenden Gründen:
    • – Es wäre dann erforderlich gewesen, diese Sprache in die Programmiersprache zu integrieren.
    • – Der überwiegende Teil der komplizierten Anfragen zur Abfrage oder zum Suchen, d. h. jene, die in den relationalen Anwendungen mehr als eine Tabelle einbeziehen, sind mit dem Ziel formuliert, durch die Verbindungstabellen zu navigieren; derartige Anfragen sind in den erzeugten Methoden der relationalen Verbindungsglieder vordefiniert.
    • – Außerdem sind in diesem Bereich die Standards nicht klar festgelegt.
  • Es ist vielmehr bevorzugt worden, einfache Funktionen zu verwenden, die gut in die erzeugten Klassen integriert sind.
  • Außerdem ist es möglich, in Bezug auf die Eingangsgrößen der Vorrichtung zum Erzeugen von Schnittstellen zwischen zwei Lösungen zu wählen. Eine erste Lösung besteht darin, das Konzeptionsmodell der Datenbank zu betrachten, das gewöhnlich unter Verwendung eines Modells Entität-Verbindung beschrieben ist, das die Entitäten der Anwendung gemeinsam mit den Verbindungen in Bezug auf die Entitäten repräsentiert. Eine zweite Lösung, wobei diese Lösung gewählt worden ist, besteht darin, als Eingangsgrößen das eigentliche Schema der relationalen Datenbank zu nehmen, das im Allgemeinen unter Verwendung der Sprache zur Definition und Manipulation von Daten dargestellt ist. Die Entscheidung für diese zweite Lösung ist aus verschiedenen Gründen getroffen worden. Ein erster Grund ist, dass es keine Standarddarstellung für ein Konzeptionsmodell (nicht einmal für ein Modell Entität-Verbindung) gibt, die als Eingangsgröße verwendet werden könnte. Des Weiteren enthält das Konzeptionsmodell keine Informationen über die physische Speicherung, d. h. in welchen der Tabellen die Daten sind, was erforderlich ist, um die Zugriffsschnittstelle zu erzeugen. Außerdem bietet die Einführung von referentiellen Integritätsbedingungen in eine Sprache vom Typ SQL ein Standardmittel, um die Verbindungen in einem relationalen Schema darzustellen. Schließlich ist die Sprache zur Definition und Manipulation von Daten vom Typ SQL mit referentiellen Integritätsbedingungen, wie etwa den Fremdschlüsseln, eine Standardbeschreibung der Eingangsgrößen einer relationalen Datenbank.
  • Schließlich ermöglicht die Konzeption der Vorrichtung gemäß der Erfindung in vorteilhafter Weise die folgenden Perspektiven in Angriff zu nehmen:
    • – die Möglichkeit, objektorientierte Schnittstellen anhand von relationalen Ansichten zu erzeugen, was ermöglichen würde, für einen bestimmten Kunden individuell gestaltete Schnittstellen zu schaffen, die direkt an die Erfordernisse der Anwendung anpassbar sind. Dies stellt einen offensichtlichen Vorteil bei der Erzeugung von Objekten, die den Zugriff auf eine relationale Datenbank ausführen, anhand der Beschreibung der Zuordnung zwischen den Strukturen von Daten, wie etwa Objekten, und einer Anfrage vom Typ SQL, dar.
    • – Der Entwickler von objektorientierten Anwendungen kann sich auch für die Speicherung von neuen Objekten, die in der Anwendung definiert sind, in dem System zur Steuerung von relationalen Datenbanken interessieren; so könnte die Vorrichtung zur Schnittstellenerzeugung außerdem verwendet werden, um die umgekehrte Funktionalität zu liefern, d. h. anhand eines objektorientierten Sche mas eine relationale Speicherung zu erzeugen. Dies bedeutet, dass das entsprechende relationale Schema sowie die Implementierung der Klassen, die von dem relationalen Schema Gebrauch machen, um die Speicherung auszuführen, erzeugt werden müssen. Die Übersetzungsregeln und die in diesem Fall erzeugten Klassen sind jenen ähnlich, die weiter oben beschrieben worden sind, könnten aber etwas komplexer sein, denn das objektorientierte Schema kann zusätzliche Konzepte wie etwa die Vererbung von Objekten enthalten.
    • – Für ein gegebenes Netz, insbesondere für ein gegebenes ORB, könnte der CORBA-Server, der anhand der erzeugten Klassen konstruiert ist und der objektorientierten Schnittstelle entspricht, mit den IDL-Definitionen erzeugt werden.

Claims (7)

  1. Vorrichtung (GEN) zum Erzeugen von objektorientierten Schnittstellen (OOI), um den Zugriff (OOA) von neuen Anwendungen, die in objektorientierten Umgebungen entwickelt worden sind, auf vorhandene relationale Datenbanken (RDBM) zuzulassen, mit Mitteln, die gemäß einem Verfahren zur Erzeugung objektorientierter Schnittstellen (OOI) und anhand eines Schemas (DBD) der relationalen Datenbanken (DBR) ein Objektschema erzeugen, das eine objektorientierte Ansicht der vorhandenen relationalen Datenbanken (DBR) bildet, wobei diese Ansicht, die die objektorientierte Schnittstelle (OOI) bildet, aus einer Gruppe von Klassen zusammengesetzt ist, die die in der relationalen Datenbank (DBR) gespeicherten Entitäten repräsentieren, wobei die Vorrichtung Mittel umfasst, die ermöglichen, am Eingang der Schnittstellenerzeugungsvorrichtung (GEN) die Beschreibung der Datenbank (DBD) in einer Standardsprache zur Definition und Manipulation von Daten einzugeben, dadurch gekennzeichnet, dass die Ansicht außerdem aus Verbindungsgliedern zwischen Objekten zusammengesetzt ist, die die relationalen Verbindungsglieder zwischen den Banken (DBR) repräsentieren, die durch Methoden repräsentiert sind, und dass die Vorrichtung versehen ist mit Mitteln, um die Objekte im Speicher zu verwalten und um die Objekte zu manipulieren, und Mitteln, die eine generische Klasse (Sammlung), die Sammlungsklasse genannt wird, erzeugen, die die Durchsuchung einer Gruppe von Instanzen einer Klasse oder der Instanzen, die Auswahlkriterien entsprechen, ermöglicht, um einen schnellen Zugriff auf die Daten zu ermöglichen, und die Mechanismen (RDBMS) des Steuersystems der relationalen Datenbank wie etwa die Cursor einkapselt, derart, dass die auf die Objekte im Speicher bezogenen Daten durch das Steuersystem (RDBMS) der Datenbank selbst verwaltet werden.
  2. Vorrichtung (GEN) zur Erzeugung von objektorientierten Schnittstellen (OOI) nach Anspruch 1, mit Mitteln zum Ausführen einer semantischen Analyse des relationalen Schemas unter Berücksichtigung des Vorhandenseins oder Fehlens von Attributen und von Schlüsseln, dadurch gekennzeichnet, dass sie Mittel umfasst, die in verschiedenen Phasen das Objektschema anhand des relationalen Schemas (DBD) dadurch erzeugen, dass sie systematisch einerseits die relationalen Tabellen in Klassen übersetzen und andererseits die relationalen Verbindungsglieder zwischen den Tabellen, die durch fremde Schlüssel (FK) ausgedrückt sind, in Verbindungsglieder zwischen Objekten, die durch Methoden repräsentiert werden, übersetzen, wobei sie hierzu durch Mittel zur lexikalischen und syntaktischen Analyse den Syntaxbaum erzeugen, der das relationale Schema anhand der Standardsprache zur Definition und Manipulation von Daten beschreibt, dann Mittel umfasst, die im ersten Durchlauf des Baums alle Verbindungstabellen, d. h. die Tabellen, die als Attribute (ATTRIBUTES) nur die fremden Schlüssel (FK) besitzen, bezeichnen, und dann Mittel umfasst, die für jede Tabelle, die keine Verbindungstabelle ist, in einem zweiten Durchlauf des Baums eine Klasse erzeugen, wobei für jeden fremden Schlüssel einer solchen Tabelle Verbindungsmethoden erzeugt werden, die auf der Erzeugung und der Verwendung generischer Klassen (STUDENT, COURSE) für die Steuerung von Objektsammlungen basieren, und für jede Verbindungstabelle, die die Tabelle betrifft, außerdem die Verbindungsmethoden, die der Klasse dieser Tabelle entsprechen, erzeugt werden.
  3. Vorrichtung (GEN) zur Erzeugung von objektorientierten Schnittstellen (OOI) nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Sammlungsklasse, die sie erzeugt, zwei private Attribute (ATTRIBUTES), sowie zwei öffentliche Methoden (METHODS) umfasst, eine Methode zur Erzeugung von Instanzen der Klasse und eine Methode zum Durchlaufen der Sammlung, die die Wiedergewinnung der Objekte der Sammlungsklasse einzeln ermöglicht, wobei die Methode zur Erzeugung von Instanzen von Klassen als Eingangsparameter eine Anforderung in der Standardsprache zur Definition und Manipulation von Daten verwendet, die der Anwender ausgeben will, diese Anforderung ausführt und den Identifizierer des Cursors wiedergewinnt, der die n-Tupel enthält, die eine Antwort auf die Kriterien der Anforderung darstellen, wobei dann, wenn effektiv gewünscht ist, die der Anforderung entsprechenden Objekte zu erzeugen, die Methode zum Durchlaufen der Sammlung für die wiedergewonnene Sammlung gestartet wird, wobei die Objekte dann einzeln erzeugt werden.
  4. Vorrichtung (GEN) zur Erzeugung von objektorientierten Schnittstellen (OOI) nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass sie eine Datenbank-Administrator genannte Klasse enthält, die die Steuerung von Transaktionen gewährt und vier Methoden für die Verwirklichung von Funktionen zur Validierung einer Transaktion bzw. zur Annullierung einer Transaktion bzw. für den Anschluss an das System (RDBMS) zur Steuerung der relationalen Datenbanken bzw. zum Trennen von dem System (RDBMS) zur Steuerung der relationalen Datenbanken implementiert, und Mittel umfasst, die ermöglichen, für jede Klasse, die eine relationale Tabelle repräsentiert, eine Tabelle zu erzeugen, die einerseits die Identifizierer der im Speicher vorhandenen Objekte, wobei ein Objektidentifizierer ein primärer Schlüssel ist, der das entsprechende relationale Objekt identifiziert, und andererseits die Adressen der Objekte enthält, wobei diese Tabellen durch die Methoden, die für die Erzeugung oder die Unterdrückung eines Objekts verwendet werden, aktualisiert werden, wobei für jede Klasse eine Tabellenklasse, zu der der Name der Klasse gehört, erzeugt wird, um diese Methoden zu implementieren, die die Funktionen zur Steuerung des Speichers verwirklichen und die Beschreibung der Tabelle enthalten, die die im Speicher vorhandenen Objekte verzeichnet, wobei eine solche Steuerung somit ermöglicht dieselbe relationale Entität nur einmal in das Objekt zu laden.
  5. Vorrichtung (GEN) zur Erzeugung von objektorientierten Schnittstellen (OOI) nach Anspruch 4, dadurch gekennzeichnet, dass für die Verwirklichung der Funktionen zur Steuerung des Speichers die Vorrichtung (GEN) Mittel umfasst, die ermöglichen, drei Methoden zu implementieren, wobei eine erste Methode ermöglicht, Kenntnis darüber zu erlangen, ob das Objekt, das dem zu dem Parameter gewordenen Schlüssel entspricht, bereits im Speicher vorhanden ist, und, falls dieses der Fall ist, seine Adresse wiederzugewinnen, eine zweite Methode ermöglicht, das Objekt als im Speicher vorhanden zu verzeichnen, und schließlich eine dritte Methode ermöglicht, bei der Zerstörung des Objekts dieses aus der Liste der im Speicher vorhandenen Objekt zu entfernen.
  6. Verfahren zur Erzeugung von objektorientierten Schnittstellen (OOI), das von der Vorrichtung (GEN) zur Erzeugung von Schnittstellen nach einem der vorhergehenden Ansprüche ausgeführt wird, umfassend eine semantische Analyse des relationalen Schemas unter Berücksichtigung des Vorhandenseins oder Fehlens von Attributen und von Schlüsseln, dadurch gekennzeichnet, dass es beim Durchlaufen verschiedener Phasen ermöglicht, das Objektschema anhand des relationalen Schemas (DBD) zu erzeugen, indem es systematisch einerseits die relationalen Tabellen in Klassen übersetzt und andererseits die relationalen Verbindungsglieder zwischen den Tabellen, die durch fremde Schlüssel (FK) ausgedrückt sind, in Verbindungsglieder zwischen Objekten, die durch Methoden repräsentiert werden, übersetzt, indem es hierzu in einer ersten Phase zur lexikalischen und syntaktischen Analyse den Syntaxbaum erzeugt, der das relationale Schema anhand der Standardsprache zur Definition und Manipulation von Daten beschreibt, dann in einer zweiten Phase ein erstes Mal den Baum durchläuft, um alle Verbindungstabellen, d. h. die Tabellen, die als Attribute (ATTRIBUTS) nur fremde Schlüssel (FK) besitzen, zu bezeichnen, dann in einer dritten Phase den Baum ein zweites Mal durchläuft, um eine Klasse für jede Tabelle zu erzeugen, die keine Verbindungstabelle ist, wobei für jeden fremden Schlüssel einer solchen Tabelle Verbindungsmethoden erzeugt werden, die auf der Erzeugung und Verwendung von generischen Klassen (STUDENT, COURSE) basieren, um Objektsammlungen zu verwalten, und wobei für jede Verbindungstabelle, die diese Tabelle betreffen, ebenfalls die Verbindungsmethoden, die der Klasse dieser Tabelle entsprechen, erzeugt werden.
  7. Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass es Phasen der Verwendung der Vorrichtung (GEN) zur Erzeugung von objektorientierten Schnittstellen (OOI) als Komponente für den Zugriff auf eine Datenbank (DBR) in einer verteilten Umgebung umfasst, um einerseits die Schnittstellen (OOI) zu erzeugen, die in der Schnittstellenbeschreibungssprache der verschiedenen Klassen (STUDENT, COURSE) ausgedrückt sind, und um andererseits einen Server anhand dieser Komponente zu erzeugen.
DE69533786T 1994-09-13 1995-09-08 Vorrichtung zum Erzeugen von objektorientierten Schnittstellen für relationale Datenbanken und von dieser Vorrichtung durchgeführtes Verfahren Expired - Lifetime DE69533786T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR9410912A FR2724471B1 (fr) 1994-09-13 1994-09-13 Dispositif de generation d'interfaces orientees objet pour des bases de donnees relationnelles et procede mis en oeuvre par ledit dispositif
FR9410912 1994-09-13

Publications (2)

Publication Number Publication Date
DE69533786D1 DE69533786D1 (de) 2004-12-30
DE69533786T2 true DE69533786T2 (de) 2005-11-24

Family

ID=9466897

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69533786T Expired - Lifetime DE69533786T2 (de) 1994-09-13 1995-09-08 Vorrichtung zum Erzeugen von objektorientierten Schnittstellen für relationale Datenbanken und von dieser Vorrichtung durchgeführtes Verfahren

Country Status (5)

Country Link
US (1) US5832498A (de)
EP (1) EP0702312B1 (de)
CA (1) CA2156227C (de)
DE (1) DE69533786T2 (de)
FR (1) FR2724471B1 (de)

Families Citing this family (61)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6356886B1 (en) * 1995-11-30 2002-03-12 Electronic Data Systems Corporation Apparatus and method for communicating with a knowledge base
US6035300A (en) * 1995-12-15 2000-03-07 International Business Machines Corporation Method and apparatus for generating a user interface from the entity/attribute/relationship model of a database
US6105025A (en) * 1996-03-08 2000-08-15 Oracle Corporation Method for using an index as a workspace for deferred enforcement of uniqueness constraints
US6457017B2 (en) * 1996-05-17 2002-09-24 Softscape, Inc. Computing system for information management
US6038566A (en) * 1996-12-04 2000-03-14 Tsai; Daniel E. Method and apparatus for navigation of relational databases on distributed networks
US6134540A (en) * 1997-05-09 2000-10-17 International Business Machines Corporation System, method, and program for applying query rewrite technology to object building
EP0877328A3 (de) * 1997-05-09 2000-01-19 International Business Machines Corporation Datenbanksuchsystem und -verfahren
US5963955A (en) * 1997-09-30 1999-10-05 International Business Machines Corporation Bridge for exporting and importing objects between object oriented programming environments
US6108664A (en) 1997-10-31 2000-08-22 Oracle Corporation Object views for relational data
US6898591B1 (en) * 1997-11-05 2005-05-24 Billy Gayle Moon Method and apparatus for server responding to query to obtain information from second database wherein the server parses information to eliminate irrelevant information in updating databases
US6038565A (en) * 1998-01-16 2000-03-14 International Business Machines Corporation Object oriented data format mapping mechanism
US6151605A (en) * 1998-05-29 2000-11-21 Hewlett-Packard Company Generic configuration file processing library and executable
FR2780588A1 (fr) * 1998-06-30 1999-12-31 Bull Sa Procede et dispositif d'acces a une base de donnees relationnelle a partir d'une application d'administration
US6292829B1 (en) * 1998-07-15 2001-09-18 Nortel Networks Limited Method and device for network management
US6397203B1 (en) * 1998-09-30 2002-05-28 International Business Machines Corporation Defining object classes to match corresponding specialized data types in a relational database
US6456995B1 (en) 1998-12-31 2002-09-24 International Business Machines Corporation System, method and computer program products for ordering objects corresponding to database operations that are performed on a relational database upon completion of a transaction by an object-oriented transaction system
US6591272B1 (en) * 1999-02-25 2003-07-08 Tricoron Networks, Inc. Method and apparatus to make and transmit objects from a database on a server computer to a client computer
WO2000055767A2 (en) * 1999-03-18 2000-09-21 Matrix One, Inc. System and method for real-time interoperation between a database management system and multiple data sources
US6192371B1 (en) * 1999-04-28 2001-02-20 Lucent Technologies, Inc Object morphing in an object oriented computing environment using relational database query procedure
US6631406B1 (en) * 1999-06-03 2003-10-07 Fujitsu Network Communications, Inc. Common management information base (MIB)
WO2003094009A1 (en) * 2002-05-03 2003-11-13 William Kenneth Ryan Multiple use of identical names to identify different ip numerical addresses
US20040162916A1 (en) * 1999-06-22 2004-08-19 Ryan William Kenneth Multiple use of identical names to identify different IP numerical addresses
US6412014B1 (en) * 1999-06-22 2002-06-25 William Kenneth Ryan Internet directory based upon names related to domain names
US6714952B2 (en) * 1999-11-10 2004-03-30 Emc Corporation Method for backup and restore of a multi-lingual network file server
US6901403B1 (en) 2000-03-02 2005-05-31 Quovadx, Inc. XML presentation of general-purpose data sources
US7143108B1 (en) * 2000-04-06 2006-11-28 International Business Machines Corporation Apparatus and method for deletion of objects from an object-relational system in a customizable and database independent manner
US6591275B1 (en) * 2000-06-02 2003-07-08 Sun Microsystems, Inc. Object-relational mapping for tables without primary keys
US6502092B1 (en) * 2000-08-01 2002-12-31 Bmc Software, Inc. Referential integrity navigation in a database system
US6609122B1 (en) * 2000-08-01 2003-08-19 Bmc Software, Inc. Navigation of view relationships in database system
US6687704B1 (en) 2000-08-31 2004-02-03 Hewlett-Packard Development Company, L.P. Database model system and method
US6694490B2 (en) * 2002-07-10 2004-02-17 Hewlett-Packard Development Company, L.P. DIMM and method for producing a DIMM
US20030105732A1 (en) * 2000-11-17 2003-06-05 Kagalwala Raxit A. Database schema for structure query language (SQL) server
US6711579B2 (en) 2001-04-20 2004-03-23 Sree Ayyanar Spinning And Weaving Mills Limited Data storage schema independent programming for data retrieval using semantic bridge
US20030056194A1 (en) * 2001-07-16 2003-03-20 Lino Iglesias Enhanced software components
US6799182B2 (en) * 2001-11-13 2004-09-28 Quovadx, Inc. System and method for data source flattening
US20030103080A1 (en) * 2001-12-05 2003-06-05 Bahman Radjabi System and method for developing a code generator for object-oriented communication protocol
US7062502B1 (en) 2001-12-28 2006-06-13 Kesler John N Automated generation of dynamic data entry user interface for relational database management systems
ZA200503462B (en) * 2002-10-10 2006-09-27 Intec Telecom System Plc Systems and methods for maintaining and distributing a commerce catalogue
US20060179171A1 (en) * 2003-03-19 2006-08-10 Stefaniak Joseph P Server consolidation analysis
US7200608B2 (en) * 2003-10-23 2007-04-03 Microsoft Corporation Application programming interface for centralized storage of principal data
US7631060B2 (en) * 2003-10-23 2009-12-08 Microsoft Corporation Identity system for use in a computing environment
US7689542B2 (en) * 2004-01-13 2010-03-30 Oracle International Corporation Dynamic return type generation in a database system
US7512599B2 (en) * 2004-01-13 2009-03-31 Oracle International Corporation Query duration types
US7624374B2 (en) * 2005-08-30 2009-11-24 Microsoft Corporation Readers and scanner design pattern
US8589195B2 (en) * 2006-01-18 2013-11-19 Google Inc. Multi-passenger multi-route travel planning
US8005695B2 (en) 2006-01-18 2011-08-23 Ita Software, Inc. Bias of queries for multi-passenger multi-route travel planning
US20070168854A1 (en) * 2006-01-18 2007-07-19 De Marcken Carl G User interface for presentation of solutions in multi-passenger multi-route travel planning
US8185418B2 (en) * 2006-01-18 2012-05-22 Google Inc. Multi-passenger multi-route travel planning
US8185419B2 (en) * 2006-01-18 2012-05-22 Google Inc. Incremental searching with partial solutions for multi-passenger multi-route travel planning
US8005696B2 (en) * 2006-01-18 2011-08-23 Ita Software, Inc. Incremental searching in multi-passenger multi-route travel planning
US7921022B2 (en) * 2006-01-18 2011-04-05 Ita Software, Inc. Multi-passenger multi-route travel planning
US8306835B2 (en) * 2006-01-18 2012-11-06 Google Inc. User interface for inputting multi-passenger multi-route travel planning query
US7801856B2 (en) * 2006-08-09 2010-09-21 Oracle International Corporation Using XML for flexible replication of complex types
ITMI20071825A1 (it) * 2007-09-20 2009-03-21 Mario Ballerini Sistema dinamico per la creazione e gestione di un database
US7991794B2 (en) * 2007-12-18 2011-08-02 Oracle International Corporation Pipelining operations involving DML and query
US9251239B1 (en) * 2008-05-15 2016-02-02 Salesforce.Com, Inc. System, method and computer program product for applying a public tag to information
WO2010147453A1 (en) * 2009-06-16 2010-12-23 Emanual System Sdn Bhd System and method for designing a gui for an application program
US20150154279A1 (en) * 2013-12-04 2015-06-04 Electronics And Telecommunications Research Institute Apparatus and method for building relation model based on resource management architecture
WO2017044119A1 (en) * 2015-09-11 2017-03-16 Hewlett Packard Enterprise Development Lp Graph database and relational database mapping
US10437564B1 (en) 2016-09-16 2019-10-08 Software Tree, LLC Object mapping and conversion system
JP7225596B2 (ja) * 2018-07-30 2023-02-21 トヨタ自動車株式会社 プログラム更新システム、プログラム更新サーバーおよび車両

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5604899A (en) * 1990-05-21 1997-02-18 Financial Systems Technology Pty. Ltd. Data relationships processor with unlimited expansion capability
US5212787A (en) * 1991-03-12 1993-05-18 International Business Machines Corporation Method and apparatus for accessing a relational database without exiting an object-oriented environment
US5596746A (en) * 1991-10-21 1997-01-21 General Electric Company Method for transforming relational data base schemas into object models using ideal table meta models
US5566333A (en) * 1992-11-05 1996-10-15 Trace Technologies, Inc. Relational database information management system for facilitating normalization of a relational database
WO1995004960A2 (en) * 1993-08-02 1995-02-16 Persistence Software, Inc. Method and apparatus for managing relational data in an object cache
US5548749A (en) * 1993-10-29 1996-08-20 Wall Data Incorporated Semantic orbject modeling system for creating relational database schemas
US5542078A (en) * 1994-09-29 1996-07-30 Ontos, Inc. Object oriented data store integration environment for integration of object oriented databases and non-object oriented data facilities

Also Published As

Publication number Publication date
CA2156227C (fr) 1999-08-03
EP0702312A1 (de) 1996-03-20
FR2724471A1 (fr) 1996-03-15
FR2724471B1 (fr) 1996-10-25
CA2156227A1 (fr) 1996-03-14
DE69533786D1 (de) 2004-12-30
US5832498A (en) 1998-11-03
EP0702312B1 (de) 2004-11-24

Similar Documents

Publication Publication Date Title
DE69533786T2 (de) Vorrichtung zum Erzeugen von objektorientierten Schnittstellen für relationale Datenbanken und von dieser Vorrichtung durchgeführtes Verfahren
DE60022152T2 (de) Parallele optimierte Ereignisauslösung in parallelen Datenbanksystemen
DE69736748T2 (de) Editierumgebung für objektmodelle und verfahren zu deren anwendung
DE4323947C2 (de) Verfahren zum Steuern von Datenbankabfragen in einem heterogenen, verteilten Datenbanksystem
EP1088280B1 (de) Verfahren und system zur schnellen speicherresidenten verarbeitung von transaktionsdaten
DE60035432T2 (de) System zur verwaltung der rdbm fragmentierungen
DE60035800T2 (de) Verfahren zum unterstützen von verteilten transaktionen mit jdbc 1.0 -treibern
EP0929864B1 (de) Koordinations-system
DE69531513T2 (de) Vervielfältigungssystem
DE69636761T2 (de) Speichern und wiederauffinden von geordneten schlüsselmengen in einem kompakten 0-kompletten baum
DE112020000749T5 (de) Indexerstellung für sich entwickelnde umfangreiche Datensätze in Hybriden Transaktions- und Analysenverarbeitungssystemen mit mehreren Mastern
DE202019005594U1 (de) Sicheres gemeinsames Benutzen von Daten in einem mandantenfähigen Datenbanksystem
DE69818135T2 (de) Verfahren zum Zugriff auf Datenbankinformation
DE10040987B4 (de) Verfahren und Vorrichtung für übereinstimmende Aktualisierungen von redundanten Daten in relationalen Datenbanken
DE3743890A1 (de) Verfahren zum schnellen eroeffnen von plattendateien
DE10104831A1 (de) Datenstruktur für Informationssysteme
CH658329A5 (de) Verfahren zur steuerung des daten-zugriffes in einer datenbank und apparat zu seiner durchfuehrung.
DE69936257T2 (de) Erzeugen und uberprüfen von referenz-adresszeigern
DE4135347C2 (de) Verfahren zur Aufrechterhaltung einer gegenseitigen Beziehung zwischen mehreren Objekten in einem für objekt-orientierte Sprache vorgesehenen Computer-System und Vorrichtung zur Durchführung eines derartigen Verfahrens
DE19715723A1 (de) Array-Verfahren
EP1502211B1 (de) Verfahren und vorrichtung zur zugriffssteuerung in wissensnetzen
DE10110039A1 (de) Ein Verfahren zur generischen Beschreibung und Manipulation beliebiger Datenstrukturen
DE10056765A1 (de) Generieren von Statistiken für Datenbankabfragen mit Hilfe von Tensordarstellungen
DE10209803A1 (de) Verfahren und Vorrichtung zum Liefern eines Dateisystemzugriffs auf ein Plattenarray
EP1516234A2 (de) Informationserzeugungssystem für die produktentstehung

Legal Events

Date Code Title Description
8327 Change in the person/name/address of the patent owner

Owner name: BULL S.A., LES CLAYES SOUS BOIS, FR

8364 No opposition during term of opposition