-
GEBIET DER
ERFINDUNG
-
Die
vorliegende Erfindung betrifft Datenbanksysteme und spezifischer
die Verwendung von anwenderdefinierten Datentypen innerhalb von
Datenbanksystemen.
-
HINTERGRUND
DER ERFINDUNG
-
Typischerweise
werden Datenelemente in einem nichtflüchtigen Speicher auf eine andere
Art gespeichert, als sie in einem flüchtigen Speicher gespeichert
werden. Somit muss dann, wenn sie von einem nichtflüchtigen
Speicher in einen flüchtigen
Speicher geladen werden, eine Umwandlungsoperation durchgeführt werden.
Gleichermaßen
muss dann, wenn sie von einem flüchtigen
Speicher zurück
in einen nichtflüchtigen Speicher
gespeichert werden, eine weitere Umwandlungsoperation durchgeführt werden.
Zu Erklärungszwecken
wird der Prozess zum Umwandeln von Daten von einem flüchtigen
Format zu einem nichtflüchtigen
Format hierin "Pickling" ("Pickeln", engl. pickle: einlegen;
hier auch Seriealisieren, Einpacken oder "flattening") des Datenelements genannt und wird
der Prozess zum Umwandeln von Daten von einem nichtflüchtigen
Format zu einem flüchtigen
Format hierin "Unpickling" des Datenelements
genannt.
-
Viele
herkömmliche
Bezugsdatenbanksysteme führen
ein automatisches Pickling und Unpickling für nur einige Typen von Daten
durch. Die Typen von Daten, die durch solche Systeme unterstützt werden,
enthalten typischerweise skalare Typen, wie beispielsweise Zahlen
und Datumsangaben. In Bezug auf andere Programmierumgebungen, wie
beispielsweise "C" und "Java", ist die Gruppe
von Datentypen, die durch typische Datenbanksysteme unterstützt werden,
extrem eingeschränkt.
Somit entstehen dann Schwierigkeiten, wenn die Datenbanksysteme
zum Speichern von Daten verwendet werden, die durch Computerprogramme erzeugt
und verwendet werden, die in diesen anderen Umgebungen geschrieben
wurden.
-
Beispielsweise
kann ein Anwender eine Gruppe von Programmen erzeugen, die Daten
darstellen und manipulieren, die einen komplexen anwenderdefinierten
Datentyp ("TYP1") verwenden. Zum
Zwecke einer Darstellung werden die anwenderimplementierten Programme
bzw. Routinen, die TYP1 verwenden, hierin gemeinsam APP1 genannt.
-
Die
Struktur von TYP1 oder von irgendeinem seiner Attribute kann signifikant
anders als die Struktur von irgendeinem Datentyp sein, der durch
ein Datenbanksystem ("DBS1") unterstützt wird.
Zum Weiterleiten der durch APP1 verwendeten Daten zu einer durch
DBS1 gemanagten Datenbank muss jedes TYP1-Datenelement in einen oder mehrere Fälle der
Datentypen umgewandelt werden, die durch DBS1 unterstützt werden. Wenn
die Daten einmal in Datentypen umgewandelt sind, die DBS1 versteht
und unterstützt,
kann DBS1 die Daten von einer Diskette speichern und wiedergewinnen.
Gleichermaßen
müssen
die Daten, die für
APP1 zum Verwenden von Daten von DBS1 von der Struktur, die zu den
Datentypen gehört,
die durch DBS1 unterstützt werden,
in die Struktur und das Format, die und das zu TYP1 gehören, umgewandelt
werden.
-
Nimmt
man Bezug auf 1, ist diese ein Blockdiagramm,
das die Umwandlungsoperationen darstellt, die durchgeführt werden
müssen,
um zuzulassen, dass APP1 seine Daten innerhalb von DBS1 speichert.
Spezifisch wird ein innerhalb von APP1 erzeugtes Datenelement gemäß der Struktur
und dem Format vom Anwender-TYP1
gespeichert. Zum Weiterleiten des Datenelements in DBS1 zur Speicherung
wird das Datenelement in einen Datentyp umgewandelt, der durch DBS1
unterstützt
wird (DBTYP1). Während
es in einem flüchtigen
Speicher innerhalb von DBS1 ist, ist das Datenelement als einem
Unpickling unterzogener DBTYP1 gespeichert. DBS1 unterzieht das
DBTYP1-Datenelement einem Pickling, um es auf einer Diskette bzw.
Platte zu speichern.
-
Zum
Versorgen von APP1 mit einem auf einer Diskette gespeicherten Datenelement
führt DBS1
ein Unpickling des Datenelements durch, um ein einem Unpickling
unterzogenes DBTYP1-Datenelement zu erzeugen. Das einem Unpickling
unterzogene DBTYP1-Datenelement wird dann in den Anwender-TYP1-Datentyp
umgewandelt, bevor es zu den Programmen bzw. Routinen innerhalb
von APP1 zugeführt
wird, die das Datenelement manipulieren.
-
Ein
Beispiel für
einen anwenderdefinierten Typ ist ein Typ, der wie folgt deklariert
ist:
-
Diese
Deklaration kann beispielsweise innerhalb des Quellencodes von APP1
auftreten. Der Quellencode von APP1 enthält auch eines oder mehrere
Verfahren, die zum Manipulieren von Daten verwendet werden, die
in einer TYP1-Datenstruktur
gespeichert sind. Ein Beispiel für
die Schnittstelle für
ein solches Verfahren ist folgendes:
my_method(TYPE1 *me, int
i);
-
Ein
TYP1-Datenelement kann durch Abbilden der Attribute von TYP1 auf
Datentypen, die durch DBS1 unterstützt werden, wie beispielsweise
Nummer bzw. Zahl und Datum, in DBS1 weitergeleitet werden. Ein Beispiel
für eine
Angabe zum Erzeugen eines Datenbankobjekts zum Speichern von Daten
von einem TYP1-Datenelement
ist folgendes:
-
Zum
Umwandeln von Daten zwischen der durch APP1 verwendeten TYP1-Struktur
und der innerhalb von DBS1 zum Speichern von TYP1-Daten verwendeten
DBTYP1-Struktur kann die folgende Struktur verwendet werden:
-
Bei
diesem Beispiel wurde angenommen, dass die Attribute von TYP1 durch
Datentypen adäquat
dargestellt werden konnten, die durch DBS1 unterstützt werden.
Jedoch werden Datentypen, die in allgemeinen Programmiersprachen
(wie beispielsweise C oder Java) entwickelt und implementiert sind,
vom Datenbanksystem nicht auf einfache Weise begriffen, weil ihre
internen Strukturen unter Verwendung der besonderen Konstrukte der
Sprache modelliert sind und vom Datenbanksystem nicht verstanden
werden.
-
Objektorientierte
Datenbanken sind eng an eine bestimmte Programmiersprache gekoppelt
und selbst dann, wenn sie ein Modellieren von Datentypen in dieser
Sprache ermöglichen,
wird die Flexibilität
einer Sprachneutralität
im Datenbanksystem verloren. Wenn beispielsweise DBS1 um dieselbe
Sprache entwickelt ist, wie sie zum Erzeugen von APP1 verwendet
wurde, dann kann DBS1 den TYP1-Datentyp
unterstützen. Wenn
aber andererseits DBS1 um eine andere Sprache entwickelt ist, als
sie zum Erzeugen von APP1 verwendet wurde, können noch komplizierte Umwandlungen
nötig sein.
-
Um
die Belastung zu reduzieren, die zu einem Umwandeln von anwenderdefinierten
Typen gehört,
deren Attribute Datentypen nicht eng entsprechen, die durch ein
Datenbanksystem unterstützt
werden, unterstützen
einige Datenbanksysteme einen "RAW"-Datentyp bzw. "URSPRUNGS"-Datentyp. Aus der
Perspektive des Datenbanksystems ist ein RAW-Datenelement bzw. URSPRUNGS-Datenelement
einfach eine abgeladene Masse von Bytes ohne Struktur. Wie bei anderen
datenbankunterstützten
Datentypen können
RAW-Datenelemente in den Spalten von Bezugstabellen gespeichert
werden. Weil das Datenbanksystem keinerlei Struktur für ein RAW-Datenelement
annimmt, kann das RAW-Datenelement zum Speichern der Daten für komplexe anwenderdefinierte
Datentypen verwendet werden, die Attribute haben, die nicht auf
einfache Weise in irgendeinen Datentyp umgewandelt werden, der durch
das Datenbanksystem unterstützt
wird.
-
Die
folgenden Anweisungen erzeugen eine Tabelle mit einer RAW-Spalte,
die beispielsweise zum Speichern von Daten von einem TYP1-Datenelement
verwendet werden kann.
create table t (= Tabelle t erzeugen)
(col1
raw(20), ...);
-
Die
folgende Anweisung erzeugt eine Routine, die intern von der Datenbank
ist, zum Aufrufen der externen Routine my_method:
create procedure
mymethod(a IN RAW) (= Prozedur mymethod(a IN RAW) erzeugen)
-
Die
Eingabe zu dieser internen Routine ist ein RAW-Datenelement, während die
externe Routine my_method ein TYP1-Datenelement erwartet. Folglich
muss die Implementierung der Prozedur mymethod (= meinemethode)
die folgende Form annehmen:
-
Bei
diesem Beispiel empfängt
die Routine mymethod ein RAW-Datenelement "a".
Die Angabe raw-to-struct(a) ruft eine anwenderzugeführte Routine
auf, die das Datenelement aus dem durch die Datenbank zum Speichern
des Datenelements verwendeten RAW-Format in das durch APP1 verwendete
TYP1-Format umwandelt. Die Angabe "manipulate" (= "manipulieren") stellt allgemein
Aufrufe zu anwenderzugeführten Routinen
dar, die das TYP1-Datenelement manipulieren. Nachdem die erwünschten
Operationen am Datenelement durchgeführt worden sind, wandelt der
Aufruf zu struct-to-raw(a) das Datenelement von der TYP1-Struktur
zurück
in das von der Datenbank verwendete RAW-Format um.
-
Nimmt
man Bezug auf 2, ist sie ein Blockdiagramm,
das die Umwandlungsoperationen darstellt, die durchgeführt werden
müssen,
um zuzulassen, dass APP1 seine Daten innerhalb einer Datenbank (DBS1) speichert,
die den RAW-Datentyp unterstützt.
Spezifisch ist ein innerhalb von APP1 erzeugtes Datenelement demgemäß als "Anwendertyp1" formatiert. Zum
Weiterleiten des Datenelements in DBS1 zur Speicherung wird das
Datenelement in den RAW-Datentyp umgewandelt. Während es in einem flüchtigen
Speicher innerhalb von DBS1 ist, wird das Datenelement als einem
Unpickling unterzogene RAW-Daten gespeichert. DBS1 unterzieht die
RAW-Daten bzw. URSPRUNGS-Daten einem Pickling zum Speichern von
ihnen auf einer Diskette.
-
Zum
Versorgen von APP1 mit einem in der Datenbank gespeicherten Datenelement
unterzieht DBS1 das RAW-Datenelement einem Unpickling zum Erzeugen
von einem Unpickling unterzogenen Daten. Die einem Unpickling unterzogenen
RAW-Daten werden dann in den Anwender-TYP1 umgewandelt, bevor sie
zu den Routinen innerhalb von APP1 zugeführt werden, die das Datenelement
manipulieren.
-
Wie
es durch das Beispiel dargestellt ist, ist sogar bei Datenbanksystemen,
die den RAW-Datentyp unterstützen,
der Anwender, der den anwenderdefinierten Typ erzeugt, (der "Typ-Implementierer") zum Liefern von
Routinen zum Umwandeln von RAW-Größen rückwärts und vorwärts in ihre
geeigneten strukturierten Äquivalente
jedes Mal dann verantwortlich, wenn die Steuerung von der Datenbank
zu Anwenderroutinen übergeben
wird. Spezifisch ist beim oben angegebenen Beispiel der Typ-Implementierer
für ein
Schreiben der Routinen raw-to-struct und struct-to-raw verantwortlich.
-
Es
gibt verschiedene Nachteile, die zu einem Speichern von Daten von
anwenderdefinierten Typen als RAW-Datenelemente innerhalb der Datenbank
gehören.
Beispielsweise unterstützt
diese Technik keine starke Typisierung. Das bedeutet, dass die zu
anderen anwenderdefinierten Typen gehörenden Datenelemente in der Datenbank
als derselbe Datenbanktyp gespeichert werden. Somit können die
Anwender des Datenbanksystems und von einer anderen Datenbank einen
von diesen Typen nicht von einem anderen unterscheiden, da sie durch
das Datenbankmanagementsystem alle als Ursprungsgrößen bzw.
Raw-Größen behandelt
werden. Folglich wäre
das Datenbanksystem nicht dazu fähig,
Situationen zu erfassen, in welchen ein Anwender Daten von einer
Art eines anwenderdefinierten Datentyps fehlerhaft in einer RAW-Spalte
speichert, für
die angenommen ist, dass sie Daten von einer anderen Art eines anwenderdefinierten
Datentyps hält.
-
Zusätzlich stellt
die Technik zum Speichern von anwenderdefinierten Typen als RAW-Daten
eine schlechte Modellierung zur Verfügung. Es ist sehr mühsam für einen
Typ-Implementierer, um die Unfähigkeit eines
Datenbanksystems herum zu arbeiten, um anwenderdefinierte Datentypen
zu speichern. Weiterhin stellt diese Technik eine relativ schlechte
Leistungsfähigkeit
zur Verfügung,
weil ein Durchfüh ren
von Umwandlungen jedes Mal dann, wenn sich Daten zwischen dem Datenbanksystem
und der Anwenderanwendung rückwärts und
vorwärts
bewegen, rechenintensiv ist.
-
Um
eine Unterstützung
einer starken Typisierung zur Verfügung zu stellen sowie um einen
Vorteil aus einer Datenbankunterstützung für den RAW-Datentyp zu ziehen,
können
die Daten für
anwenderdefinierte Typen in Datenbankobjekttypen gespeichert werden,
die URSPRUNGS- bzw. RAW-Attribute haben. Beispielsweise soll angenommen
sein, dass ein Typ-Implementierer zwei Typen TYP1 und TYP2 definiert
hat. Daten vom Anwendertyp TYP1 können in Datenbankobjekten gespeichert
werden, die durch die folgenden Angaben erzeugt sind:
-
Gleichermaßen können Daten
von Anwendertyp TYP2 in Datenbankobjekten gespeichert werden, die durch
die folgenden Angaben erzeugt sind:
-
Durch
Verwenden von datenbankdefinierten Objekten in Kombination mit dem
RAW-Datentyp auf diese Weise können
die zu anwenderdefinierten Datentypen TYP1 und TYP2 gehörenden Daten
innerhalb des Datenbanksystems voneinander unterschieden werden.
Jedoch ist der Typ-Implementierer noch verantwortlich für ein Zuführen von
Formatumwandlungsroutinen von-urspunglich-zu-maschinenspezifisch. Zusätzlich setzt
man sich dem Zusatz, der zu einem Aufrufen der Umwandlungsroutinen
gehört,
noch jedes Mal dann aus, wenn Daten für die anwenderdefinierten Typen
zwischen dem Datenbanksystem und den anwenderzugeführten Routinen
laufen.
-
Spezifisch
muss jedes Mal dann, wenn die Routine mymethod1 aufgerufen wird,
um irgendeine Datenmanipulation durchzuführen, das RAW-Attribut des
eingegebenen Datenelements "a" von einem RAW-Datenelement
zu einem TYP1-Datenelement
umgewandelt werden. Nach der Manipulation muss das TYP1-Datenelement zurück zu dem
RAW-Datenattribut umgewandelt werden. Diese Umwandlungen müssen jedes
Mal dann durchgeführt
werden, wenn das Datenelement zwischen dem vom Datenbanksystem gesteuerten
flüchtigen
Speicher und dem durch die anwenderzugeführten Routinen verwendeten
flüchtigen
Speicher übergeben
wird. Gleichermaßen
würde jeder
Aufruf zu der Routine mymethod2 ein Umwandeln eines RAW-Attributs in
ein TYP2-Datenelement, ein Aufrufen einer externen Routine und ein
darauf folgendes Umwandeln des TYP2-Datenelements zurück zu einem
RAW-Datenattribut enthalten.
-
In "Universal Data Option
for Informix Dynamic Server",
INFORMIX CORPORATION, 1998 (Online), Seiten 1–8, XP002128177 ist eine konfigurierbare
Option beschrieben, die die Basisfunktionalität eines objektbezogenen Datenbankmanagementsystems
(ORDMBS) erweitert, um anwenderdefinierte Datentypen und Datenbankroutinen
zu unterstützen.
Sie stellt die Fähigkeit
zum Unterstützen
nicht herkömmlicher
Datentypen, wie beispielsweise Bilder, Klang, html-Seiten, etc.,
zur Verfügung.
Die enge Integration der konfigurierbaren Option mit dem Datenbankserver
ermöglicht,
dass der Server neue, anwenderdefinierte Datentypen auf gleiche
Weise behandelt, auf welche er seine eigenen eingebauten Datentypen
behandelt.
-
In
Riggs R. et al. "Pickling
state in the Java/sup TM/system",
Proceedings of 2nd conference on object-oriented
technologies and systems (COOTS), Toronto, Ont., Canada, 17.–21. Juni
1996, Seiten 241 bis 250, XP002128178, Berkeley, Ca, USA, USENIX
Assoc. USA, ist ein Pickling-Mechanismus beschrieben, der zum Serialisieren
von Objekten oder Objektkurven anwendbar ist, so dass sie als Blobs
bzw. Farbflecke in Datenbanken gespeichert und wiedergewonnen werden
können.
Pickling ist der Prozess zum Erzeugen einer serialisierten Darstellung
von Objekten und Unpickling ist der komplementäre Prozess zum Erzeugen von
Objekten aus der serialisierten Darstellung.
-
Basierend
auf dem Vorangehenden ist es klar, dass es erwünscht ist, einen Mechanismus
zur Verfügung
zu stellen, der zulässt,
dass ein Typ-Implementierer Datentypen in der Programmiersprache
der Auswahl eines Typ-Implementierers (C, JAVA, etc.) konstruiert.
Es ist weiterhin erwünscht,
ein Datenbanksystem diese Datentypen speichern und indexieren zu
lassen, auch wenn es die interne Struktur von solchen Typen nicht versteht.
Zusätzlich
ist es erwünscht,
einen Mechanismus zur Verfügung
zu stellen, der zulässt,
dass Daten von anwenderdefinierten Typen in ihrer maschinenspezifischen
Sprachumgebung in ihrer maschinenspezifischen Form (wie C-Strukturen
oder Java-Klassen) erscheinen, während
auf sie fortgesetzt von anderen Sprachumgebungen im Datenbankmanagementsystem
zugegriffen werden kann. Es ist auch erwünscht, die Notwendigkeit zu
reduzieren oder zu eliminieren, Umwandlungen jedes Mal dann durchzuführen, wenn
eine Gruppe von Daten zwischen der Datenbankumgebung und ihrer ursprünglichen
Sprachumgebung läuft.
-
ZUSAMMENFASSUNG
DER ERFINDUNG
-
Ein
Verfahren und eine Vorrichtung zum Handhaben von Datenelementen,
denen Datentypen zugehörig
sind, deren ursprüngliche
Struktur dem Datenbanksystem nicht bekannt ist, innerhalb eines
Datenbanksystems sind zur Verfügung
gestellt. Die Datenelemente werden innerhalb des Datenbanksystems
in ihrer ursprünglichen
Struktur gespeichert, selbst wenn sie vom Datenbanksystem nicht
verstanden wird. Zum Speichern der Datenelemente ruft das Datenbanksystem
eine Pickling-Routine
auf, die durch den Anwender zur Verfügung gestellt wird, oder durch
das Laufzeit-Untersystem der Programmierumgebung, die maschinenspezifisch
für das
Datenelement ist. Zum Wiedergewinnen der Routine von einem Speicher
ruft das Datenbanksystem eine Unpickling-Routine auf, die auch durch
den Anwender oder das geeignete Laufzeit-Untersystem zur Verfügung gestellt
ist. Weil die Datenbank die Datenelemente in ihrem maschinenspezifischen
Format beibehält,
sind keine Umwandlungen erforderlich, wenn die Datenelemente zwischen
dem Datenbanksystem und externen Routinen übergeben werden, die die Datenelemente
manipulieren.
-
Es
sind auch Techniken zum Deklarieren von Attributen des Datenelements
zur Verfügung
gestellt, auf das innerhalb des Datenbanksystems zugegriffen werden
kann. Der Anwender stellt Routinen für das Datenbanksystem zur Verfügung, um
zum Zugreifen auf die deklarierten Attribute aufzurufen, welche
anders als die aktuellen Attribute sein können, die das Datenelement
in seiner maschinenspezifischen Umgebung hat.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
Die
vorliegende Erfindung wird anhand eines Beispiels und nicht mittels
einer Beschränkung
in den Figuren der beigefügten
Zeichnungen dargestellt, wobei sich gleiche Bezugszeichen auf gleiche
Elemente beziehen und wobei:
-
1 ein
Blockdiagramm ist, das die verschiedenen Umwandlungen darstellt,
die dann auftreten, wenn eine Anwendung ihre Daten unter Verwendung
eines Datenbanksystems speichert, das die durch die Anwendung verwendeten
Datenstrukturen nicht unterstützt.
-
2 ein
Blockdiagramm ist, das die verschiedenen Umwandlungen darstellt,
die dann auftreten, wenn eine Anwendung ihre Daten unter Verwendung
eines Datenbanksystems speichert, das den RAW-Datentyp unterstützt, aber die durch die Anwendung
verwendeten Datenstrukturen nicht unterstützt.
-
3 ein
Blockdiagramm eines Computersystems ist, auf welchem Ausführungsbeispiele
der Erfindung implementiert werden können; und
-
4 ein
Blockdiagramm ist, das darstellt, wie Datenelemente nicht umgewandelt
werden, wenn sie zwischen dem Datenbanksystem und externen Routinen
laufen, wenn Datenelemente in ihrem maschinenspezifischen Format
innerhalb des Datenbanksystems gespeichert sind, und zwar gemäß einem
Ausführungsbeispiel
der Erfindung.
-
DETAILLIERTE
BESCHREIBUNG DES BEVORZUGTEN AUSFÜHRUNGSBEISPIELS
-
Ein
Verfahren und eine Vorrichtung zum Speichern von anwenderimplementierten
Datentypen in Datenbanksystemen werden beschrieben. In der folgenden
Beschreibung werden zu Erklärungszwecken
zahlreiche spezifische Details aufgezeigt, um für ein sorgfältiges Verstehen der vorliegenden
Erfindung zu sorgen. Es wird einem Fachmann auf dem Gebiet jedoch
offensichtlich werden, dass die vorliegende Erfindung ohne diese
spezifischen Details ausgeführt
werden kann. In anderen Fällen
sind wohlbekannte Strukturen und Vorrichtungen in Blockdiagrammform
gezeigt, um ein unnötiges
Verdunkeln der vorliegenden Erfindung zu vermeiden.
-
HARDWARE-ÜBERSICHT
-
3 ist
ein Blockdiagramm, das ein Computersystem 300 darstellt,
auf welchem ein Ausführungsbeispiel
der Erfindung implementiert werden kann. Das Computersystem 300 enthält einen
Bus 302 oder einen anderen Kommunikationsmechanismus zum
Kommunizieren von Information und einen mit dem Bus 302 gekoppelten
Prozessor 304 zum Verarbeiten von Information. Das Computersystem 300 enthält auch
einen Hauptspeicher 306, wie beispielsweise einen Direktzugriffsspeicher
(RAM) oder eine andere dynamische Speichervorrichtung, der mit dem
Bus 302 zum Speichern von Information und Anweisungen,
die durch den Prozessor 304 auszuführen sind, gekoppelt ist. Der
Hauptspeicher 306 kann auch zum Speichern von temporären Variablen
oder anderer Zwischeninformation während einer Ausführung von
Anweisungen, die durch den Prozessor 304 auszuführen sind,
verwendet werden. Das Computersystem 300 enthält weiterhin
einen Nurlesespeicher (ROM) 308 oder eine andere statische
Speichervorrichtung, der oder die mit dem Bus 302 gekoppelt
ist, zum Speichern von statischer Information und Anweisungen für den Prozessor 304.
Ein Speichervorrichtung 310, wie beispielsweise eine Magnetplatte
oder eine optische Platte, ist vorgesehen und mit dem Bus 302 gekoppelt,
um Information und Anweisungen zu speichern.
-
Das
Computersystem 300 kann über den Bus 302 mit
einer Anzeige 312 gekoppelt sein, wie beispielsweise einer
Kathodenstrahlröhre
(CRT), um einem Computeranwender Information anzuzeigen. Eine Eingabevorrichtung 314,
die alphanumerische und andere Tasten enthält, ist mit dem Bus 302 zum
Kommunizieren von Information und Befehlsauswahlen zum Prozessor 304 gekoppelt.
Ein weiterer Typ einer Anwender-Eingabevorrichtung ist eine Cursorsteuerung 316,
wie beispielsweise eine Maus, ein Trackball oder Cursorführungstasten,
zum Kommunizieren von Führungsinformation
und Befehlsauswahlen zum Prozessor 304 und zum Steuern
einer Cursorbelegung auf der Anzeige 312. Diese Eingabevorrichtung
hat typischerweise zwei Freiheitsgrade in zwei Achsen, und zwar
einer ersten Achse (z.B. x) und einer zweiten Achse (z.B. y), was
zulässt,
dass die Vorrichtung Positionen in einer Ebene spezifiziert.
-
Die
Erfindung bezieht sich auf die Verwendung eines Computersystems 300 zum
Speichern von anwenderimplementierten Datentypen in Datenbanksystemen.
Gemäß einem
Ausführungsbeispiel
der Erfindung werden anwenderimplementierte Datentypen in einem
Datenbanksystem, das auf dem Computersystem 300 ausführt, in
Reaktion auf einen Prozessor 304 gespeichert, der eine
oder mehrere Sequenzen von einer oder mehreren Anweisungen ausführt, die
in einem Hauptspeicher 306 enthalten sind. Solche Anweisungen
können von
einem anderen computerlesbaren Medium, wie beispielsweise einer
Speichervorrichtung 310, in den Hauptspeicher 306 gelesen
werden. Eine Ausführung
der Sequenzen von Anweisungen, die im Hauptspeicher 306 enthalten
sind, veranlasst, dass der Prozessor 304 die hierin beschriebenen
Verarbeitungsschritte durchführt.
Bei alternativen Ausführungsbeispielen
kann eine hartverdrahtete Schaltung anstelle von oder in Kombination
mit Softwareanweisungen zum Implementieren der Erfindung verwendet
werden. Somit sind Ausführungsbeispiele
der Erfindung nicht auf irgendeine spezifische Kombination aus einer
Hardwareschaltung und Software beschränkt.
-
Der
Ausdruck "computerlesbares
Medium", wie er
hierin verwendet wird, bezieht sich auf irgendein Medium, das beim
Liefern von Anweisungen zum Prozessor 304 zur Ausführung teilnimmt.
Ein solches Medium kann viele Formen annehmen, einschließlich, aber
nicht darauf beschränkt,
nichtflüchtiger
Medien, flüchtiger
Medien und Übertragungsmedien.
Nichtflüchtige
Medien enthalten beispielsweise optische oder magnetische Platten,
wie beispielsweise eine Speichervorrichtung 310. Flüchtige Medien
enthalten einen dynamischen Speicher, wie beispielsweise den Hautspeicher 306. Übertragungsmedien
enthalten Koaxialkabel, Kupferdraht und optische Fasern, einschließlich der
Drähte,
die den Bus 302 aufweisen. Die Übertragungsmedien können auch
die Form von akustischen Wellen oder Lichtwellen annehmen, wie beispielsweise
diejenigen, die während
Funkwellen- und Infrarot-Datenkommunikationen erzeugt werden.
-
Allgemeine
Formen von computerlesbaren Medien enthalten beispielsweise eine
Floppy Disk (=Diskette), eine flexible Disk (=Diskette), eine Festplatte,
ein Magnetband oder irgendein anderes magnetisches Medium, einen
CD-ROM, irgendein anderes optisches Medium, Lochkarten, ein Papierband,
irgendein anderes physikalisches Medium mit Mustern von Löchern, einen
RAM, einen PROM und einen EPROM, einen FLASH-EPROM, irgendeinen
anderen Speicherchip oder eine Speicherkassette, eine Trägerwelle,
wie es hierin nachfolgend beschrieben ist, oder irgendein anderes
Medium, von welchem ein Computer lesen kann.
-
Verschiedene
Formen von computerlesbaren Medien können beim Tragen von einer
oder mehren Sequenzen von einer oder mehreren Anweisungen zum Prozessor 304 zur
Ausführung
beteiligt sein. Beispielsweise können
die Anweisungen anfangs auf einer Magnetplatte eines entfernten
Computers getragen sein. Der entfernte Computer kann die Anweisungen
in seinen dynamischen Speicher laden und die Anweisungen über eine
Telefonleitung unter Verwendung eines Modems senden. Ein Modem,
das beim Computersystem 300 lokalisiert ist, kann die Daten
auf der Telefonleitung empfangen und einen Infrarotsender zum Umwandeln der
Daten in ein Infrarotsignal verwenden. Ein Infrarotdetektor kann
die im Infrarotsignal getragenen Daten empfangen und eine geeignete
Schaltung kann die Daten auf dem Bus 302 platzieren. Der
Bus 302 trägt
die Daten zum Hauptspeicher 306, von welchem sie der Prozessor 304 ausliest
und die Anweisungen ausführt. Die
vom Hauptspeicher 306 empfangenen Anweisungen können optional
entweder vor oder nach einer Ausführung durch den Prozessor 304 in
der Speichervorrichtung 310 gespeichert werden.
-
Das
Computersystem 300 enthält
auch eine Kommunikationsschnittstelle 318, die mit dem
Bus 302 gekoppelt ist. Die Kommunikationsschnittstelle 318 stellt
eine Zweiwege-Datenkommunikationskopplung zu einer Netzwerkverbindung 320 zur
Verfügung,
die mit einem lokalen Netzwerk 322 verbunden ist. Beispielsweise kann
die Kommunikationsschnittstelle 318 eine Karte für ein dienstintegriertes
digitales Netzwerk (ISDN) oder ein Modem zum Bereitstellen einer
Datenkommunikationsverbindung zu einem entsprechenden Typ einer
Telefonleitung sein. Als weiteres Beispiel kann die Kommunikationsschnittstelle 318 eine
Karte für
ein lokales Netzwerk (LAN) sein, um eine Datenkommunikationsverbindung
zu einem kompatiblen LAN zur Verfügung zu stellen. Ebenso können drahtlose
Verbindungen implementiert sein. Bei jeder derartigen Implementierung
sendet die Kommunikationsschnittstelle 318 elektrische,
elektromagnetische oder optische Signale und empfängt diejenigen,
die digitale Datenströme
tragen, die verschiedene Typen von Information darstellen.
-
Die
Netzwerkverbindung 320 stellt typischerweise eine Datenkommunikation über eines
oder mehrere Netzwerke zu anderen Datenvorrichtungen zur Verfügung. Beispielsweise
kann die Netzwerkverbindung 320 eine Verbindung über ein
lokales Netzwerk 322 zu einem Host-Computer 324 oder
zu einem Datengerät,
das durch einen Internet-Serviceprovider (ISP) 326 betrieben
wird, zur Verfügung
stellen. Der ISP 326 liefert infolge davon Datenkommunikationsdienste über das
weltweite Paketdaten-Kommunikationsnetzwerk, das nun allgemein "Internet" 328 genannt
wird. Das lokale Netzwerk 322 und das Internet 328 verwenden
beide elektrische, elektromagnetische oder optische Signale, die
digitale Datenströme
tragen. Die Signale durch die verschiedenen Netzwerke und die Signale
auf der Netzwerkverbindung 320 und durch die Kommunikationsschnittstelle 318,
die die digitalen Daten zu und von einem Computersystem 300 tragen,
sind beispielhafte Formen von Trägerwellen,
die Information transportieren.
-
Das
Computersystem 300 kann Nachrichten senden und Daten, einschließlich eines
Programmcodes, über
das (die) Netzwerk(e), die Netzwerkverbindung 320 und die
Kommunikationsschnittstelle 318 empfangen. Beim Beispiel
des Internets könnte
ein Server 330 einen angeforderten Code für ein Anwendungsprogramm über das
Internet 328, den ISP 326, das lokale Netzwerk 322 und
die Kommunikationsschnittstelle 318 übertragen.
-
Der
empfangene Code kann durch den Prozessor 304 ausgeführt werden,
wenn er empfangen wird, oder für
eine spätere
Ausführung
in der Speichervorrichtung 310 oder einem anderen nichtflüchtigen
Speicher gespeichert werden. Auf diese Weise kann das Computersystem 300 einen
Anwendungscode in der Form einer Trägerwelle erhalten.
-
ÜBERBLICK ÜBER UNVERSTÄNDLICHE
TYPEN
-
Gemäß einem
Aspekt der Erfindung registriert ein Typ-Implementierer eines Datentyps,
der durch ein Datenbanksystem nicht unterstützt wird, den Datentyp bei
dem Datenbanksystem. Während
der Registrierung wird dem Datenbanksystem Information über den
Datentyp zugeführt.
Die zugeführte
Information über
den Datentyp kann beispielsweise einen Namen für den Datentyp, Namen für Attribute
des Datentyps, Routinen für ein
Pickling und ein Unpickling des Datentyps und Routinen zum Bekommen
und Einstellen von individuellen Attributen des Datentyps enthalten.
-
Die
zum Datenbanksystem zugeführte
Information lässt
zu, dass das Datenbanksystem Mechanismen zum Durchführen eines
Picklings an der maschinenspezifi schen Struktur eines Datenelements
aufruft, das zum anwenderdefinierten Datentyp gehört, so dass
das Datenelement auf einer Diskette bzw. Platte gespeichert werden
kann, und zum Durchführen
eines Unpickling an dem Datenelement, um das Datenelement von der
Platte in seiner maschinenspezifischen Struktur wiederzugewinnen.
Während
es in einem flüchtigen
Speicher innerhalb des Datenbank gespeichert ist, bleibt das Datenelement
in seiner maschinenspezifischen Struktur, so dass dann, wenn es
zwischen dem Datenbanksystem und externen Routinen geführt wird,
keine Umwandlungen erforderlich sind.
-
Anwenderdefinierte
Datentypen, die auf diese Weise registriert werden, werden hierin "unverständliche
Typen" genannt,
weil Datenelemente, die zu solchen anwenderdefinierten Datentypen
gehören,
innerhalb des Datenbanksystems in Strukturen sitzen, die dem Datenbanksystem
nicht bekannt sind oder von diesem nicht verstanden werden.
-
VON EINEM
TYP-IMPLEMENTIERER ZUGEFÜHRTE
PICKLING-ROUTINEN
-
Wie
es oben angegeben ist, kann der Typ-Implementierer während des
Registrierungsprozesses für einen
unverständlichen
Typ Pickling- und Unpickling-Routinen zur Verwendung beim unverständlichen
Typ zum Datenbanksystem zuführen.
-
Die
Pickling-Routine wandelt Daten von der Struktur und dem Format,
die und das durch externe Routinen erwartet werden, die den unverständlichen
Typ (die "maschinenspezifische
Struktur") manipulieren,
in ein Format um, das für
eine dauerhafte Speicherung geeignet ist (eine "speicherbare Struktur"). Gegensätzlich dazu
wandelt die Unpickling-Routine Daten von der speicherbaren Struktur
in die maschinenspezifische Struktur um. Das Datenbanksystem ruft
die Pickling- und Unpickling-Routinen für den anwenderzugeführten Datentyp
unter denselben Bedingungen auf, unter welchen sie die eingebauten
Pickling- und Unpickling-Routinen für die durch die datenbankunterstützten Datentypen
aufruft. Spezifisch wird die Unpickling-Routine in Reaktion auf
ein Lesen eines Datenelements des anwenderdefinierten Typs aus einem
nichtflüchtigen
Speicher in einen durch das Datenbanksystem gesteuerten flüchtigen
Speicher aufgerufen. Die Pickling-Routine wird vor einem Speichern
zu einem nichtflüchtigen
Speicher eines Datenelements des anwenderdefinierten Typs aufgerufen,
das in einem durch das Datenbanksystem gesteuerten flüchtigen
Speicher sitzt.
-
Weil
das Datenbanksystem eine Steuerung der Pickling- und Unpickling-Routine
für den
unverständlichen
Typ hat, können
zum unverständlichen
Typ gehörende
Datenelemente in ihrer maschinenspezifischen Struktur existieren,
während
sie noch innerhalb des Datenbanksystems sind. Weil die Struktur
und das Format der Datenelemente innerhalb des Datenbanksystems
dieselbe Struktur und dasselbe Format sind, die durch die externen
Routinen erfordert sind, die die Datenelemente manipulieren, müssen die
Datenelemente nicht umgewandelt werden, wenn sie zwischen diesen
Routinen und dem Datenbanksystem rückwärts und vorwärts geführt werden.
-
Nimmt
man Bezug auf 4, ist sie ein Blockdiagramm,
dass die Umwandlungsoperationen darstellt, die durchgeführt werden
müssen,
um zuzulassen, dass APP1 seine Daten innerhalb eines Datenbanksystems (DBS1)
speichert, das unverständliche
Typen unterstützt.
Spezifisch wird ein innerhalb von APP1 erzeugtes Datenelement innerhalb
von APP1 gemäß der Struktur
und dem Format vom Anwender-TYP1
gespeichert und manipuliert. Innerhalb von DBS1 bleibt das Datenelement
in seiner maschinenspezifischen Struktur und seinem maschinenspezifischen
Format. Somit wird kein Umwandlung durchgeführt, wenn das Datenelement
zur Speicherung in das DBS1 geführt
wird. DBS1 führt
ein Pickling des Datenelements durch, um es auf einer Diskette bzw.
Platte zu speichern, indem es eine Pickling-Routine aufruft, die
durch den Typ-Implementierer zugeführt ist.
-
Zum
Zuführen
eines auf einer Platte gespeicherten Datenelements zu APP1 führt DBS1
ein Unpickling des Datenelements durch Aufrufen einer durch den
Typ-Implementierer
zugeführten
Unpickling-Routine durch. Während
es innerhalb von DBS1 einem Unpickling unterzogen wird, ist das
Datenelement in seiner maschinenspezifischen Struktur und seinem
maschinenspezifischen Format. Somit kann das einem Unpickling unterzogene
Datenelement zu den Routinen innerhalb von APP1 zugeführt werden,
das das Datenelement manipuliert, ohne irgendwelche zusätzlichen
Umwandlungen durchzuführen.
-
Der
Wert der Fähigkeit,
ein Durchführen
von Umwandlungen jedes Mal dann zu vermeiden, wenn ein Datenelement
zwischen dem Datenbanksystem und externen Routinen verläuft, wird
größer, wenn
die Kosten für
die Umwandlungsoperation größer werden.
Beispielsweise soll angenommen werden, dass ein anwenderdefinierter
Datentyp Daten für
große
digitale Bilder hält.
Aus Leistungsfähigkeitsgründen sind
die externen Routinen derart entwickelt, dass sie nicht komprimierte
Bilder manipulieren. Um jedoch Platz auf der Platte bzw. Diskette
zu sparen, sind die Bilder auf der Platte in einem komprimierten
Format zu speichern.
-
In
einem Datenbanksystem, das unverständliche Typen nicht unterstützt, würden zum
Sicherstellen, dass die Bilder komprimiert werden, bevor sie durch
das Datenbanksystem gespeichert werden, die externen Routinen jedes
Bild komprimieren müssen,
bevor sie das Bild zum Datenbanksystem führen. Gleichermaßen würden die
externen Routinen jedes vom Datenbanksystem empfangene Bild dekomprimieren
müssen.
-
Unter
Verwendung der Unterstützung
für unverständliche
Typen kann der Anwender Pickling- und Unpickling-Routinen registrieren,
die jeweils die Kompression und die Dekompression durchführen. Folglich
würden
die zu einer Kompression gehörenden
Kosten nur dann entstehen, wenn ein Bild tatsächlich zu einer Platte gespeichert
oder aus dieser wiedergewonnen wird, und nicht jedes Mal dann, wenn
das Bild zwischen dem Datenbanksystem und den externen Routinen
verläuft.
-
AUF DER SPRACHE
BASIERENDES PICKLING UND UNPICKLING
-
Gemäß einem
weiteren Aspekt der Erfindung können
unverständliche
Typen in Sprachumgebungen erzeugt werden, in welchen die Sprachumgebung
vorschreibt, wie Datenelemente einem Pickling und einem Unpickling
zu unterziehen sind. Beispielsweise sind JAVA-implementierte Datentypen
in Klassendateien gespeichert, die ein bestimmtes Format haben,
und das JAVA-Laufzeit-Untersystem liefert einen Mechanismus zum
Laden von JAVA-Klassen in einen Speicher. Unter diesen Bedingungen
müssen
keine spezifischen Pickling- und Unpickling-Routinen für jede einzelne
JAVA-Klasse registriert werden. Vielmehr speichert das Datenbanksystem
Metadaten, die anzeigen, welche unverständlichen Typen JAVA-Klassen
sind. Das Datenbanksystem ruft dann automatisch die geeigneten JAVA-Routinen
innerhalb des JAVA-Laufzeit-Untersystems auf, um Objekte, die zu
solchen JAVA-Klassen gehören,
einem Pickling und einem Unpickling zu unterziehen.
-
ZUGREIFEN
AUF ATTRIBUTE VON UNVERSTÄNDLICHEN
TYPEN
-
Während des
Registrierungsprozesses für
einen unverständlichen
Typ kann der Typ-Implementierer dem Datenbanksystem Namen für Attribute
des unverständlichen
Typs und Routinen zum Bekommen und Einstellen von individuellen
Attribu ten des unverständlichen
Typs zuführen.
Beispielsweise kann der Typ-Implementierer
die folgenden Angaben zum Datenbanksystem unterbreiten:
-
Bei
diesem Beispiel wird dem Datenbanksystem eine Deklaration eines
unverständlichen
Typs für
einen unverständlichen
Typ mit dem Namen "foo" vorgelegt. Die Deklaration
für einen
unverständlichen
Typ führt Namen
für zwei
Attribute innerhalb des unverständlichen
Typs zu (attrib1 und attrib2). Für
jedes der Attribute spezifiziert die Deklaration einen datenbankunterstützten Datentyp.
Spezifisch ist der für
attrib1 spezifizierte datenbankunterstützte Datentyp NUMBER (= NUMMER)
und ist der für
attrib2 spezifizierte datenbankunterstützte Typ char(31). Jedoch bleibt
selbst mit dieser Namens- und Typeninformation der unverständliche
Datentyp unverständlich,
weil das Datenbanksystem die maschinenspezifische Struktur des unverständlichen Typs
nicht versteht. Somit kann das Datenbanksystem nicht auf die individuellen
Attribute innerhalb eines Datenelements von Typ foo ohne Unterstützung zugreifen.
-
Um
zuzulassen, dass das Datenbanksystem auf individuelle Attribute
innerhalb eines Datenelements vom Typ foo zugreift, registriert
der Typ-Implementierer beim Datenbanksystem Routinen zum Zugreifen
auf individuelle Attribute. Beispielsweise kann der Anwender zwei
Routinen foo.attrib1.get(a OUT NUMBER) und foo.attrib1.set(a IN
NUMBER) zuführen.
Die Routine foo.attrib1.get stellt den Wert eines Eingangsparameters des
Typs NUMBER auf den Wert des Attributs attrib1 eines Datenelements
vom Typ foo ein. Die Routine foo.attrib1.set stellt den Wert des
Attributs attrib1 eines Datenelements vom Typ foo auf den Wert eines
Eingangsparameters vom Typ NUMBER ein.
-
Es
muss keine Eins-zu-Eins-Abbildung zwischen den Attributen, die in
der Definition für
einen unverständlichen
Typ aufgelistet sind, die zum Datenbanksystem zugeführt ist,
und den Attributen in der Definition eines maschinenspezifischen
Datentyps geben. Folglich hat ein Typ-Implementierer ein hohes Maß an Flexibilität in Bezug
darauf, auf welche Teile eines unverständlichen Typs, wenn überhaupt,
innerhalb der Datenbanksystemumgebung zugegriffen werden kann. Beispielsweise
kann ein Typ-Implementierer einen Datentyp "web_page" unter Verwendung der Deklaration der
ursprünglichen
Sprache erzeugen:
-
Jedoch
kann der Typ-Implementierer den Typ web_page beim Datenbanksystem
unter Verwendung der folgenden Deklaration für einen unverständlichen
Typ registrieren:
-
Die
Deklaration für
einen unverständlichen
Typ teilt dem Datenbanksystem mit, dass ein Datenelement web_page
zwei Attribute hat: firstword und checksum (erstes Wort und Prüfsumme).
In seiner maschinenspezifischen Umgebung hat das Datenelement web_page
tatsächlich
zwei unterschiedliche Attribute: header und body (= Anfangsblock
und Körper).
Weil es, wie bei diesem Beispiel, sein kann, dass die in der Deklaration
für einen
unverständlichen
Typ spezifizierten Attribute keinem der der maschinenspezifischen
Attribute des Datentyps entsprechen, werden sie hierin Attribute
für einen
unverständlichen
Typ genannt.
-
Auf
die Attribute header und body kann zugegriffen werden und sie können manipuliert
werden, indem externe Routinen aufgerufen werden, die sich über die
maschinenspezifischen Struktur des Typs web_page bewusst sind, aber
auf sie kann innerhalb des Datenbanksystems nicht direkt zugegriffen
werden. Das Datenbanksystem weiß nicht
einmal, dass diese Attribute existieren, weil sie in der Deklaration
für einen
unverständlichen
Typ nicht genannt sind.
-
Der
Typ-Implementierer erzeugt die Routinen, die zulassen, dass auf
die Attribute für
einen unverständlichen
Typ innerhalb des Datenbanksystems zugegriffen wird. Weil diese
Routinen in der maschinenspezifischen Umgebung des Datentyps geschrieben
sind, sind sie sich über
alle ursprünglichen
Attribute des Datentyps bewusst und können auf diese zugreifen. Die
Attributenzugriffsroutinen, die durch den Typ-Implementierer zum
Datenbanksystem zugeführt
sind, bestimmen, auf welche Attribute für einen unverständlichen
Typ zugegriffen werden kann und wie auf sie zugegriffen wird. Beispielsweise
kann der Typ-Implementierer des Datentyps web_page eine Funktion
web_page.firstword.get (a OUT Char(10)) registrieren, die das erste
Wort innerhalb des Körpers
eines Datenelements web_page in eine Datenbankvariable speichert.
Gleichermaßen kann
der Typ-Implementierer eine Routine web_page.checksum.out(a OUT
Char(10)) registrieren, die eine Prüfsumme, die durch Anwenden
einer Hash-Funktion auf den Körper
eines Datenelements web_page erzeugt ist, in eine Datenbank-NUMMER-Variable
speichert.
-
In
der vorangehenden Beschreibung ist die Erfindung unter Bezugnahme
auf ihre spezifischen Ausführungsbeispiele
beschrieben worden. Es wird jedoch klar sein, dass verschiedene
Modifikationen und Änderungen
daran durchgeführt
werden können,
ohne vom Schutzumfang der Erfindung abzuweichen. Die Beschreibungen
und die Zeichnungen sind demgemäß eher in
einem illustrativen als in einem beschränkenden Sinn anzusehen.
