DE10113515A1 - Datenbanksystem - Google Patents

Abstract

Die vorliegende Erfindung betrifft ein Datenbanksystem und ein Verfahren zum Durchführen von Operationen in einem Datenbanksystem, in dem eine Vielzahl von Datensätzen in einem Speicher eines Computers abspeicherbar sind, wobei jeder Datensatz eine beliebige Anzahl von Datenfeldern umfasst, dadurch gekennzeichnet, dass eine Datenbasis des Datenbanksystems eine mehrspaltige Wertetabelle mit einer beliebigen Anzahl von Zeilen, eine Inhaltstabelle zum Speichern von Datenfeldinhalten, eine Attributtabelle zum Speichern von Datenfeldattributen und eine Objekttabelle zum Speichern von Bezügen zwischen Objekten aufweist, wobei in der Wertetabelle: jede Zeile einem Datenfeld eines Datensatzes entspricht; eine Spalte (txt) Inhaltsreferenzen (TxtID) beinhaltet, die mehrfach für verschiedene Datenfelder vergeben sein können und jeweils eindeutig auf einen Eintrag (TXT, TxtID) der Inhaltstabelle referenzieren; eine weitere Spalte (tag) Attributreferenzen (TagID) beinhaltet, die mehrfach für verschiedene Datenfelder vergeben sein können und jeweils eindeutig auf einen Eintrag (TAG, TagID) der Attributtabelle referenzieren; und noch eine weitere Spalte (obj) Objektreferenzen (ObjID) beinhaltet, die mehrfach für verschiedene Datenfelder vergeben sein können, wobei die zu jeweils einer Objektreferenz gehörenden Datenfelder jeweils einen Datensatz bilden und die Objektreferenz (ObjID) jeweils eindeutig für einen Eintrag (OBJ, ObjID) der Objekttabelle referenzieren.

Description

Die vorliegende Erfindung betrifft ein Datenbanksystem, das insbesondere auf einer relationalen Datenbank basiert, bei dem eine Datenbasis, die aus einer Vielzahl von Datenfeldern besteht, gespeichert wird, und ein Verfahren zur Speicherung, Änderung und Anzeige der Datenbasis.

Unter dem Begriff Datenbank versteht man gemäß dem "Computer- Lexikon", 3. Aufl., 1998, S. 196 ff., erschienen im DTV Verlag, in der ursprünglichen Bedeutung einen strukturierten, inhaltlich zusammengehörigen Datenbestand, wie zum Beispiel Adressen, Kunden- oder Mitarbeiterdaten. Meist jedoch wird mit einer Datenbank das Anwendungsprogramm bezeichnet, das zur Verwaltung des Datenbestands dient. Die Daten selbst nennt man Datenbasis oder Datenbestand. Ein sogenanntes Datenbank-Managementsystem greift auf diese Datenbasis zu, zeigt Bestandteile der Datenbasis an, und ist fähig, die Datenbasis zu modifizieren und nach Bestandteilen zu suchen.

Bei bekannten Datenbanksystemen wird dabei die Datenbasis in strukturierter Form abgespeichert, gemäß dem Stand der Technik in Tabellenform. Eine Datenbasis besteht aus einer Reihe von Datensätzen, von denen sich jeder wiederum aus einer Reihe von Datenfeldern zusammensetzt. Bei einer Adreßdatenbank zum Beispiel entspricht jede Adresse einem Datensatz, und jeder Bestandteil der Adresse einem Feld.

In der Fig. 1 ist ein herkömmlicher Datensatz 100 dargestellt, der aus einer Adreßdatenbank stammt. Der Datensatz 100 besteht aus den Datenfeldern 110 Nachname, Vorname, Straße, Ort und Telefon. Beim gezeigten Datensatz der Fig. 1 enthält das Feld Nachname den Namen Huber, das Feld Vorname die Angabe Henriette usw. Diese Datenfeldangaben 120 werden im nachfolgenden auch als Datenfeldinhalte bzw. lediglich Inhalte bezeichnet.

Die Struktur der Datensätze wird beim Anlegen der Datenbasis festgelegt. Dazu gibt man an, aus welchen Datenfeldern sich ein Datensatz zusammensetzt und wieviel Platz für jedes Datenfeld reserviert werden soll. Bei einigen Programmen läßt sich die Struktur nachträglich ändern. So kann man Datenfelder einfügen oder den für ein Datenfeld reservierten Platz vergrößern oder verkleinern. Je nach der Definition der Datenbankstruktur werden dann die Daten für die einzelnen Datensätze eingegeben.

Dies ist jedoch nicht immer so. Diese Art von strukturierter Abspeicherung der Daten bedeutet, daß für jede Ablage bzw. Abspeicherung von einem Datensatz vorausgesetzt wird, daß der Datensatz, der abzulegen bzw. abzuspeichern ist, in seiner Struktur zumindest mit einer Teilstruktur der Datenbank übereinstimmt. Soll aber ein Datensatz abgespeichert werden, der in seiner Struktur nicht den vorhandenen Datenstrukturen bzw. Teilen davon entspricht, so muß die Datenbank selbst um das neue Strukturelement (Feld/Felder) erweitert werden, bevor der Datensatz abgespeichert werden kann, d. h. in der Tabelle werden Spalten hinzugefügt. Dies kann zu Redundanzen führen, da die "alten" Datensätze eventuell keine Informationen bezüglich den neuen Spalten besitzen.

Ein besonderes Problem stellt die Speicherung von Datensätzen mit einer neuen Datensatzstruktur dar. Diese Datensatzstruktur muß vom Anwender definiert werden. Hierfür sind Änderungen im Datenbank-Managementsystem und in den Anwendungsprogrammen, die mit dieser Datenbank arbeiten, nötig.

Zur Anzeige der Daten bieten die meisten Programme einen sogenannten Listenmodus (auch Browse-Modus genannt) und einen Formularmodus. Im Listenmodus werden alle bzw. ausgewählte Datensätze in tabellarischer Form angezeigt. Die Fig. 2 und 3 zeigen Beispiele solcher herkömmlichen tabellarisch angezeigten Datenbanken, wobei in Fig. 2 eine Datenbank, in der Kundenadressen gespeichert sind, und in Fig. 3 eine weitere Datenbank, in der einzelne Aufträge gespeichert sind, und die in Relation zur Kundendatenbank steht, dargestellt sind. In Fig. 2 sind mehrere vertikale Datensätze 200 dargestellt. In Fig. 3 steht jeder Datensatz 300 in einer eigenen Zeile, die Daten der einzelnen Felder sind spaltenweise angeordnet. In Fig. 2 ist die Bedeutung der Spalte mit der der Zeile vertauscht.

Die herkömmliche Datenbank kann nach einzelnen Datensätzen oder nach solchen Datensätzen durchsucht werden, die einem oder mehreren Kriterien entsprechen. Die Kriterien lassen sich gewöhnlich über Operatoren wie <, <, = , UND (AND), ODER (OR) oder NICHT (NOT) festlegen und miteinander verknüpfen - also zum Beispiel alle mit Namen Müller aus München; alle Müller, die nicht in München wohnen; alle Müller aus München und alle Schmidt aus Hamburg. Die gefundenen Datensätze können angezeigt oder in Listen- oder Formularform ausgedruckt werden. Im Formularmodus wird jeweils nur ein Datensatz angezeigt.

Für die Anzeige bzw. den Ausdruck lassen sich die Datensätze nach einem oder mehreren Feldern sortieren. Bei vielen Programmen muß dazu für die zu sortierenden Felder ein sogenannter Index angelegt werden. Der Index wird meist in einer eigenen Datei gespeichert und beschleunigt Sortier- und Suchvorgänge.

Einige Datenbankprogramme erlauben es, sehr komplexe Datenbanken zu erstellen, die von anderen Anwendern benutzt werden können, obwohl diese Anwender gar nicht über das Datenbankprogramm verfügen.

Datenbanken, die auf einer festen Struktur basieren, eignen sich gut zur Verwaltung von Daten, die immer gleich oder zumindest sehr ähnlich aufgebaut sind. Zur Verwaltung unstrukturierter Daten oder von Daten mit inhomogener Struktur sind sie kaum geeignet. Bereits eine Datenbank mit Daten unterschiedlicher Länge läßt sich nicht mit jedem Datenprogramm anlegen. Manche herkömmlichen Programme bieten dafür sogenannte Memo-Felder an, deren Längen meist mehrere KByte umfassen darf. Sind mehrere derartige Felder erforderlich oder sollte eine Strukturierung nicht möglich sein, benötigt man ein textorientiertes Datenbankprogramm, eine sogenannte Volltext-Datenbank, das die unstrukturierte Dateneingabe erlaubt und dennoch das Selektieren und Verknüpfen von Datensätzen ermöglicht.

Eine Alternative für derartige Aufgabenstellungen sind objektorientierte Datenbanken. Ein wesentliches Unterscheidungskriterium bei Datenbanken und gleichzeitig ausschlaggebend für die Leistungsfähigkeit des Programms ist das verwendete Datenbankmodell, das auch als Datenmodell bezeichnet wird und die Beziehungen der einzelnen Daten definiert. Im nachfolgenden werden zwei Datenmodelle genauer beschrieben.

Zum einen gibt es das hierarchische Datenmodell. In einer derartigen Datenbank sind die einzelnen Datensätze in einer Baumstruktur gespeichert, ähnlich wie bei einem hierarchischen Dateisystem. Dieses Datenmodell ist weit verbreitet. Werden zwei Daten verknüpft, so kann man jedem Datensatz der einen Datenbank genau einen Datensatz der anderen Datenbank zuordnen; mehrere gleichzeitig bestehende Verknüpfungen sind nicht erlaubt. Das hierarchische Datenmodell ist nur schwer mit typischen in der Praxis vorkommenden Datenstrukturen vereinbar. Beispielsweise könnten in einer Datenbank die einzelnen Mitarbeiter - aufgegliedert nach Abteilungen und Projekten - gespeichert werden. Doch in der Praxis kommt es häufig vor, daß einzelne Mitarbeiter für verschiedene Abteilungen und an mehreren Projekten arbeiten.

Ein weiteres häufig benutztes Datenmodell stellt die relationale Datenbank dar. Grundlage dieses Modells ist eine tabellenartige Struktur. Jede Zeile der Tabelle stellt einen Datensatz dar, der auch Tupel genannt wird; die einzelnen Spalten enthalten die Datenfelder. Bei derartigen Datenbanken kann man eine Beziehung, also eine Relation, zwischen verschiedenen Datenbeständen aufbauen. So könnte zum Beispiel eine Kundendatenbank mit einer Datenbank verknüpft werden, in der die eingegangenen Aufträge gespeichert sind (vgl. Fig. 2 und 3), und für jeden bzw. für ausgewählte Kunden die Adresse und die jeweiligen Aufträge angezeigt werden. Für komplexere Anwendungen, zum Beispiel bei der Auftragsabwicklung in Firmen, sind derartige Datenbanken unerläßlich.

Probleme ergeben sich bei der Einführung zusätzlicher Datenwerte oder Datenobjekte, die umfangreiche Änderungen an der Tabellendefinition erforderlich machen. Die relationale Datenbank führt bei ähnlichen Datenobjekten zu redundanten Inhalten, denen zum Teil durch die Auslagerung und Referenzierung in weiteren Tabellen begegnet wird, ohne diese vollständig zu unterbinden.

Eine Aufgabe der Erfindung ist es, ein Datenbanksystem vorzusehen, das keine Beschränkung bezüglich der Inhalte aufweist und im Hinblick auf Erweiterungen der Datenstrukturen und der Übertragbarkeit auf andere relationale Datenbanksysteme verschiedener Hersteller ohne Änderung der Tabellendefinitionen erweiterbar ist.

Eine weitere Aufgabe ist es, Redundanzen vollständig zu vermeiden.

Des weiteren soll ein Verfahren vorgesehen werden, das es erlaubt, Operationen in einem Datenbanksystem durchzuführen, das die oben beschriebenen Probleme löst.

Die Lösung der oben beschriebenen Probleme findet sich in den beigefügten Ansprüche wieder, wobei die vorliegende Erfindung durch die unabhängigen Ansprüche definiert wird. Bevorzugte Ausführungsformen werden in den abhängigen Ansprüchen beschrieben.

Die vorliegende Erfindung, deren Merkmale, Verwendungszwecke und Vorteile werden aus der folgenden Beschreibung der bevorzugten Ausführungsformen, wie sie in den beigefügten Zeichnungen veranschaulicht sind, deutlicher werden.

Fig. 1 zeigt einen herkömmlichen Datensatz aus einer Adreßdatenbank.

Fig. 2 zeigt eine herkömmliche tabellarische Datenbank, in der Kundenadressen gespeichert sind.

Fig. 3 zeigt eine weitere herkömmliche Datenbank, in der einzelne Aufträge gespeichert sind und die eine Relation zur Kundendatenbank der Fig. 2 aufweist.

Fig. 4 zeigt eine Ausführungsform der vorliegenden Erfindung.

Fig. 5 zeigt eine vierspaltige Wertetabelle gemäß der vorliegenden Erfindung.

Fig. 6 zeigt eine Objekttabelle gemäß der vorliegenden Erfindung.

Fig. 7 zeigt eine Attributtabelle gemäß der vorliegenden Erfindung.

Fig. 8 zeigt eine Inhaltstabelle gemäß der vorliegenden Erfindung.

Fig. 9 zeigt hierarchisch gegliederte Ortsbezüge.

Die Fig. 4 veranschaulicht eine Ausführungsform der vorliegenden Erfindung. Im erfindungsgemäßen Datenbanksystem werden mehrere Tabellen zur Festlegung eines Datenfelds eines Objekts verwendet. Man beachte, daß hier von einem Datenfeld eines Objekts und nicht von einem Datenfeld eines Datensatzes gesprochen wird. Im nachfolgenden ist ein Objekt äquivalent zu einem oder mehreren herkömmlichen Datensätzen. Um eine größtmögliche Flexibilität zu erreichen, was die Anzahl und den Inhalt der Datenfelder betrifft, muß man sich von der Vorstellung des herkömmlichen Datensatzes lösen. Der herkömmliche Datensatz war dadurch gekennzeichnet, daß er beispielsweise einer Zeile in einer relationalen (tabellarischen) Datenbankbasis entsprach, wobei die Anzahl der zum Datensatz gehörigen Datenfelder durch die Anzahl der Spalten der Datenbasis bestimmt war. Die möglichen Inhalte, die Reihenfolge und das Datenformat eines Datenfelds war durch die Spalte, die Spaltenreihenfolge und die Spalteneinheit festgelegt. So konnte man beispielsweise in einem Datenfeld, in dem beispielsweise Vornamen abgespeichert wurden, keine Telefonnummer eingeben, da als Eingabe Buchstaben und nicht Ziffern erwartet wurden. Um sich von dieser Vorstellung zu lösen, wird der Begriff Datensatz durch den Begriff Objekt substituiert. Unter einem Objekt ist alles zu verstehen, was im jeweiligen Anwendungsbereich sinnvollerweise in einer Datenbank zu archivieren ist.

Angenommen eine große Bibliothek möchte ihr Inventar in Form einer relationalen Datenbank elektronisch abrufbar abspeichern. Dabei sollen aber nicht nur die Bücher der Bibliothek, sondern auch jede andere Gegenstand wie etwa Stühle, Tische, Regale usw. erfaßt werden. Als weitere Gegenstände sind sogar Verträge denkbar, die die Bibliothek mit anderen Bibliotheken über die Leihe von Büchern getroffen hat. All diese Gegenstände sind Objekte. Die Objekte lassen sich verschiedenen Objekttypen zuordnen, die vom Benutzer der erfindungsgemäßen Datenbank beliebig erstellt werden können. Beispielsweise könnten alle Taschenbücher, Lexika, Romane, Sachbücher oder ähnliches als Objekte zum Objekttyp Buch gehören. Tische, Stühle und Regale könnten zum Objekttyp Möbel gehören.

Es ist leicht verständlich, daß Objekte unterschiedliche Eigenschaften aufweisen. So hat beispielsweise der Objekttyp Buch die Eigenschaften Autor, Erscheinungsjahr, Verlag usw. Der Objekttyp Möbel dagegen kann sich beispielsweise durch Eigenschaften wie Preis, Breite, Höhe, Tiefe oder ähnliches auszeichnen.

Würde man diese Objekte als Datensätze in eine herkömmliche Tabelle eintragen, wobei jeder Datensatz alle Eigenschaften aller möglichen Objekte in Form eines Datenfeldes beinhalten würde, d. h. für jede unterschiedliche Objekteigenschaft müßte eine Spalte in der herkömmlichen tabellarischen Datenbank erzeugt werden, würde dies zu einer Tabelle erheblicher Größe führen. Nur so wäre gewährleistet, daß ein beliebiger Gegenstand, egal zu welchem Objekttypen er gehört, in der Datenbank aufgenommen werden kann. Dies führt auch zwangsweise zu einer erheblichen Vielzahl von Redundanzen.

Eine andere Möglichkeit, dieses Problem zu lösen, wäre es, verschiedene Datenbanktabellen anzulegen, wobei für jeden Objekttyp eine eigene Tabelle angelegt werden müßte.

Durch die oben beschriebenen erfindungsgemäßen Objekte lassen sich diese Probleme umgehen. Jedes herkömmliche Datenfeld (d. h. Eigenschaft eines Objekts) wird in der erfindungsgemäßen Datenbank gemäß einer Ausführungsform als Zeile in einer vierspaltigen sogenannten Wertetabelle abgespeichert. In der Fig. 4 ist die Wertetabelle 400 in der Mitte dargestellt. Die vier Spalten der Wertetabelle 400 sind schematisch durch die vier Referenzen WertID 472, txt 463, tag 433 und obj 443 veranschaulicht. Die mit "txt" bezeichnete Spalte 463 referenziert auf eine Inhaltstabelle 460, die ebenfalls zwei Spalten 461 und 462 aufweist, die mit "TXT" und "TxtID" bezeichnet werden. Die mit "tag" bezeichnete Spalte 433 referenziert auf eine Attributtabelle 430, die zwei Spalten 431 und 432 aufweist, die mit "TAG" und "TagID" bezeichnet werden. Die mit "obj" bezeichnete Spalte 443 referenziert auf eine Objekttabelle 440, die zwei Spalten 441 und 442 aufweist, die mit "OBJ" und "ObjID" bezeichnet werden. Die mit "WertID" bezeichnete Spalte 472 dient zur durchlaufenden Numerierung und ist für die Funktionalität der Datenbank nicht zwingend erforderlich.

In Fig. 5 ist eine Wertetabelle 500, die in ihrer Struktur der Wertetabelle 400 der Fig. 4 entspricht, in größerem Detail dargestellt. Die Wertetabelle 500 wird aus vier Spalten gebildet. Eine Spalte 572, die mit "WertID" bezeichnet ist, beinhaltet laufende Nummern. Die laufenden Nummern kennzeichnen ein Datenfeld eineindeutig, d. h. jedem Datenfeld wird eine einzige Nummer zugeordnet und umgekehrt. Die mit "txt" bezeichnete Spalte 563 beinhaltet Inhaltsreferenzen, die mehrfach für verschiedene Datenfelder vergeben sein können und jeweils eindeutig auf einen Eintrag in der Inhaltstabelle 460 der Fig. 4 referenzieren. Vereinfacht gesagt, in den jeweiligen Feldern dieser Spalte befinden sich Zeiger, die auf den Inhalt des jeweiligen Datenfelds wie beispielsweise den Vornamen Max zeigen. Dieser Vorname kann jedoch für mehrere Personen, die in der Datenbank abgespeichert sind, vergeben sein. Genauso gut könnte "Max" aber auch als Nachname, Firmenname oder als sonstige Bezeichnung benutzt werden. Somit erklärt sich, daß die Inhaltsreferenzen von verschiedenen Datenfeldern auf einen identischen Eintrag in der Inhaltstabelle verweisen können. Eine mit "tag" bezeichnete Spalte 533 beinhaltet Attributreferenzen, die mehrfach für verschiedene Datenfelder vergeben sein können und ebenfalls eindeutig auf einen Eintrag in der Attributtabelle 430 der Fig. 4 referenzieren. Ähnlich wie bei der zweiten Spalte sind die Felder der dritten Spalte äquivalent zu Zeigern, die auf Datenfeld- bzw. Objekteigenschaften (d. h. beispielsweise auf Feldnamen 110 der Fig. 1) bzw. -attribute referenzieren. Eine Inhaltstabelle ist im Detail in der Fig. 8 dargestellt, auf die später genauer eingegangen werden wird. Jedoch ist klar, daß auch die Attribute von verschiedenen Objekten, die jedoch zum selben Objekttyp gehören, mehrfach auftreten können, wodurch bildhaft gesprochen mehrere Zeiger aus der dritten Spalte auf einen identischen Eintrag in der Attributtabelle zeigen können. Eine mit "obj" bezeichnete Spalte 543 der Wertetabelle 500 in der Fig. 5 beinhaltet Objektreferenzen, die mehrfach für verschiedene Datenfelder vergeben sein können und jeweils eindeutig auf einen Eintrag in der Objekttabelle 440 der Fig. 4 referenzieren. Ähnlich wie bei den beiden vorangegangenen Spalten stellen die Felder der "obj"-Spalte Zeiger dar, die auf ein in der Objekttabelle gespeichertes Objekt zeigen. Auch hier können mehrere Zeiger auf ein und dasselbe Objekt deuten. Dies wird klar, wenn man bedenkt, daß ein Objekt mehrere verschiedene Eigenschaften haben kann, d. h. mehrere Kombinationen aus ein und demselben Element der Spalte "obj" 543 mit mehreren verschiedenen Elementen der dritten Spalte "tag" 533 wie etwa Buch - Autor, Buch - Erscheinungsjahr oder ähnliches sind vorstellbar.

In den Fig. 6, 7 und 8 sind die in der Fig. 4, mit Ausnahme der Wertetabelle 400, dargestellten Tabellen im Detail mit Beispieleinträgen gezeigt. Die Zusammenhänge mit der in der Fig. 5 dargestellten Wertetabelle 500 werden nun ausführlich beschrieben werden.

In Fig. 6 ist eine Objekttabelle 640 gezeigt, die Beispielwerte beinhaltet und in ihrer Funktionalität der Objekttabelle 440 der Fig. 4 entspricht. Die Objekttabelle 640 ist zweispaltig aufgebaut. Eine erste Spalte 641 wird mit "OBJ" bezeichnet. Eine zweite Spalte 642 wird mit "ObjID" bezeichnet. Die Einträge der Objekttabelle 640 bestehen aus zwei Eintragungsteilen, nämlich einem ersten Eintragsteil entsprechend einem Element der ersten Spalte "OBJ", der einen Bezug zu einem anderen Objekt darstellt, und aus einem zu diesem ersten Eintragsteil gehörigen zweiten Eintragsteil entsprechend der Spalte "ObjID". Auf den zweiten Eintragsteil des (allgemeinen) Typs "ID" wird aus der "obj"-Spalte der Wertetabelle 500 der Fig. 5 verwiesen. Auf die Funktionalität des ersten Eintragsteils, entsprechend der Spalte 641 "OBJ" wird im folgenden näher eingegangen werden.

Über die Objekttabelle 640 wird nicht nur ein Objekt (im Sinne eines beliebigen Gegenstands im Beispiel der Bibliothek) eindeutigt gekennzeichnet, sondern auch gleichzeitig ein Bezug zu einem hierarchisch angeordneten Bezugssystem hergestellt. Dieses hierarchisch angeordnete Bezugssystem kann beispielsweise auf einem räumlichen Bezugssystem wie etwa den XYZ-Koordinaten eines Objekts basieren. Im oben genannten Beispiel der Bibliothek könnte das Ortsbezugssystem auch das Gebäude der Bibliothek als solches sein. Das Gebäude wiederum läßt sich untergliedern in einzelne Etagen bzw. Stockwerke. Diese Stockwerke kann man in einzelne Zimmer aufteilen. Die eben durchgeführte Gliederung hat sich jeweils auf die nächstkleinere örtliche Einheit bezogen. Genausogut ist eine Erweiterung des Bezugssystems denkbar, indem man vom Gebäude zur Stadt, zum Land usw. geht. Die Ortsbezüge sind eine hierarchische Gliederung eines Ortes, der eine Auskunft über das "Wer" und "Wo" gibt, d. h. welches Objekt sich an welchem Ort befindet.

In dem in der Fig. 6 dargestellten Beispiel der Objekttabelle 640 gibt es zwei verschiedene Eintragstypen für den ersten Eintragsteil, der einem Element der Spalte 641 "OBJ" entspricht. Dies ist einmal der Typ "Parent =" und zum anderen der Typ "Ref =". Der Bezugstyp Parent trifft eine Aussage bezüglich der hierarchischen Anordnung der Objekte. Das höchste Objekt in der Objekthierarchie trägt die Objekt-ID "0". Dem sogenannten Ursprungsobjekt mit der ObjID "0" können keine Objekte gleicher hierarchischer Ordnung zugewiesen werden. Der Bezugstyp Parent gibt somit in der Regel Auskunft über die nächsthöhere Hierarchie bezüglich eines Objekts. Beispielsweise ist von einem Buch mit der Objekt-ID "10" bekannt (siehe Fig. 6), daß es sich im ersten Geschoß der Bibliothek befinden muß, da der in der Objekttabelle 640 eingetragene Bezug zur Objekt-ID "10" lautet: "Parent = 9". Das bedeutet, es wird auf die Objekt-ID "9" verwiesen, zu der der Bezug "Parent = 0" gehört, d. h. hierin ist die Information zu sehen, daß das Buch sich im ersten Geschoß (Parent = 9) der Bibliothek (ObjID "9" → Parent = 0) befindet, wenn die Bibliothek als solche den höchsten hierarchischen Bezug, nämlich das Objekt mit der Objekt-ID "0", darstellt.

Die beiden eben genannten Bezugstypen "Parent =" und "Ref =" dienen lediglich der Vereinfachung der optischen Unterscheidung. Man kann diese auch weglassen, wobei jedoch die ihnen zugeordnete Ziffer, sprich die ObjID zwingend erforderlich ist.

Mit anderen Worten, jedes Objekt hat im Falle eines räumlichen Bezugssystems genau einen Ortsbezug, d. h. einen zu referierenden Vater ("Ref = . . ."). Allgemein gesprochen gibt es zu einem Objekt einen logischen Bezug, der das Objekt einem logischen Bezugssystem zuordnet. Jedoch wird der Ortsbezug der Objekte selbst wiederum als Objekt im System gespeichert und besitzt eine Referenz auf seinen "hierarchischen" Vater ("Parent = . . ."). Somit entsteht für Ortsobjekte eine einfache verkettete Liste mit anderen Ortsobjekten als Endknotenpunkte. Objekte auf der ersten Hierarchieebene verweisen auf einen sogenannten virtuellen Vater mit der ID = 0. Jedoch können mehrere Objekte einem Ort zugewiesen werden. Dies geschieht grundsätzlich durch den Bezug vom Typ "Ref = . . .". In der Objekttabelle 640 der Fig. 6 sind beispielsweise die drei Objekte mit den Objekt-IDs 26, 28 und 29 dem (Orts-)Objekt mit der Objekt-ID "45" zugewiesen. Das Objekt mit der ID = 45 ist durch den Ortsbezug "Parent = 10" dem (Orts-)Objekt mit der Objekt-ID "10" unterstellt, welches selbst wiederum dem (Orts- )Objekt 9 unterstellt ist. Das Objekt mit der Objekt-ID "9" ist dann schließlich dem virtuellen Vater mit der ID 0 unterstellt.

Als nächstes wird eine in der Fig. 7 dargestellte Attributtabelle 730 im Detail beschrieben werden. Die Attributtabelle 730 enthält zu den Fig. 5 und 6 passende Beispieleinträge. Sie ist gleichfalls wie die Objekttabelle 640 der Fig. 6 zweispaltig angeordnet. Die erste Spalte 731 ist mit "TAG" bezeichnet. Die zweite Spalte 732 ist mit "TagID" bezeichnet. Ein Eintrag (d. h. eine Zeile) in der Attributtabelle 730 besteht somit aus zwei Teilen. Der erste Eintragsteil TAG ist grundsätzlich in drei Teile gegliedert, die mit einem Punkt getrennt werden. Diese drei Komponenten bezeichnen zum ersten - den schon oben erwähnten - Objekttyp, zum zweiten einen Datenfeldnamen und zum dritten ein Attribut, das in diesem Zusammenhang als Einheit verstanden werden kann. Der Datenfeldname entspräche in der herkömmlichen Datenbankmodellierung den Feldbezeichnungen bzw. den Spaltenüberschriften. Die dritte Komponente des ersten Eintragsteils stellt eine Einheitengröße dar, die den Inhalt des damit verknüpften Datenfelds näher beschreibt. Mögliche Einheitengrößen sind zum Beispiel "Text", "Zahl", "Währung", oder "Datum". Ein zum ersten Eintragsteil gehöriger zweiter Eintragsteil TagID entspricht einem der Einträge in der Spalte 533 der Wertetabelle 500 der Fig. 5 und stellt das Ziel des dort bezeichneten Zeigers dar. Durch die TagID wird von der Wertetabelle 500 der Fig. 5 auf die Attributtabelle 730 der Fig. 7 referenziert. Der erste Eintragsteil eines Eintrags in der Attributtabelle 730 kann somit eine Struktur vom Typ "Objekttyp._Objekt-ID._.ID_" auf (siehe auch TAG zu TagID 362) aufweisen.

In Fig. 8 ist eine Inhaltstabelle 860 dargestellt, die in ihrer Funktionalität der Inhaltstabelle 460 der Fig. 4 entspricht. Die Inhaltstabelle 860 weist ebenfalls zwei Spalten auf. Die erste Spalte 861 wird mit "TXT" bezeichnet. Die zweite Spalte 862 wird mit "TxtID" bezeichnet. Die Einträge in die Inhaltstabelle 860 in der Fig. 8 sind beispielhaft und passen zu den in den Fig. 5, 6 und 7 dargestellten Einträgen.

Die in der Spalte 563 der Wertetabelle 500 der Fig. 5 enthaltenen Inhaltsreferenzen referenzieren auf einen zweiten Eintragsteil (TxtID) eines Eintrags der Inhaltstabelle 860. Ein zum zweiten Teil gehöriger erster Eintragsteil stellt den Inhalt des Datenfelds dar. So wird beispielsweise dem Datenfeld mit der Wert-ID "12" aus Fig. 5 über die Inhaltsreferenz mit der Text-ID "16" der Inhalt "500 501 02" zugewiesen, was der Bankverbindung einer Firma entspricht, wie man der Attributreferenz mit der Tag-ID "369" aus den Tabellen 5 und 7 entnehmen kann. Die zur Wert-ID "12" gehörige Objekt-ID "3" verweist gemäß der Objekttabelle 640 auf einen Ortsbezug "Ref = 1", womit dieses Objekt dem virtuellen Vater mit der ID = 0 zugewiesen wird, da dem Objekt mit der Objekt-ID "1" der Hierarchiebezug "Parent = 0" zugewiesen ist.

In der Fig. 9 ist der im Zusammenhang mit der Fig. 6 angeführte Bezug zwischen den Objekten in Form eines Ortsbezugs noch einmal beispielhaft verdeutlicht. Der Ortsbezug gliedert Informationen hierarchisch nach dem Ort, den sie betreffen oder an dem sie auftreten. In der Fig. 9 sind links einige Ortsbezüge wie Kunde, Nation, Stadt und Liegenschaft aufgeführt. Man sieht, daß jeder Ortsbezug mehrere untergeordnete Ortsbezüge enthalten kann. Jedem Ort wiederum können mehrere Objekte durch den Bezug des Typs "Ref = . . ." zugeordnet werden.

Im nachfolgenden werden einige allgemeinere Aussagen über die Funktionsweise der vorliegenden Erfindung gemacht werden.

Genauso wie die räumliche Zuordnung über die Ortsbezüge für einzelne Objekte möglich ist, erlaubt eine weitere Ausführungsform der Erfindung die zeitliche Zuordnung von Objekten. Beispielsweise könnte man daran interessiert sein - um im Bild des oben genannten Beispiels zu bleiben -, wo sich ein Buch XY der Bibliothek, das sich momentan im Raum Z des ersten Geschosses befindet, vorher befunden hat, bevor es in diesem Raum abgelegt wurde. Dazu wäre es erforderlich, daß man der Wertetabelle 500 der Fig. 5 auch zeitliche Informationen entnehmen kann. Dies wird erreicht, indem man eine weitere, zusätzliche Spalte definiert, die Zeitreferenzen beinhaltet. Diese Zeitreferenzen verweisen - ähnlich wie bei den Ortsbezügen - auf eine Zeittabelle (nicht dargestellt). Diese Zeittabelle ist ebenfalls zweispaltig angelegt. Die erste Spalte beinhaltet wiederum Bezüge zwischen Objekten, die zweite Spalte beinhaltet die zugehörigen Zeitreferenzen (Time-ID, nicht dargestellt), auf die die Zeitzeiger aus der weiteren Spalte der Wertetabelle zeigen.

Es versteht sich von selbst, daß es jederzeit möglich ist, ein neues Objekt anzulegen. Dabei werden entsprechend den zu erfassenden Eigenschaften des Objekts eine äquivalente Anzahl von Zeilen in der Wertetabelle 500 der Fig. 5 angelegt. Die Datenfelder können jeweils eine laufende Nummer zugeteilt bekommen, die bisher noch nicht vergeben ist. Des weiteren wird dem Objekt eine Objekt-ID zugewiesen, die für die neu einzutragenden Felder gleich ist, da es sich um ein und dasselbe Objekt handelt. Das Objekt selbst wiederum gehört einem Objektypen an. Beispielsweise gehört ein Taschenbuch ABC - wie schon eingangs erwähnt - zum Objekttyp Buch. Existiert für ein Objekt noch kein zugehöriger Objekttyp, so läßt sich dieser auf einfache Art und Weise anlegen, indem man in der Attributtabelle einen Eintrag der Form "neuer Objekttyp.Feldname.Einheit" anlegt. Gleiches gilt für die Eigenschaften des Objekts, die in der eben genannten Schreibweise dem Feldnamen entsprechen. Somit lassen sich beliebige Objekte mit beliebigen Eigenschaften in die Wertetabelle eintragen, ohne daß dabei Redundanzen, wie im Stand der Technik, auftreten.

Sämtliche Zugriffe auf Informationen in der erfindungsgemäßen Datenbank unterliegen frei definierbaren Zugriffsrechten. Es wird zwischen den Zugriffsrechten "Schreiben & Lesen", "Lesen" sowie "kein Zugriff" unterschieden. Die Rechte werden in sogenannten Benutzergruppen organisiert. Ein Benutzer ist immer mindestens einer Benutzergruppe zugehörig. Ein Objekt oder Ortsbezug ist nur dann für eine Benutzergruppe überhaupt sichtbar, wenn für das betreffende Objekt das Recht "Schreiben & Lesen" oder "Lesen" zugeteilt wurde. Sobald ein Objekt für den Schreibzugriff geöffnet ist, erhalten alle anderen lese- und schreibberechtigten Benutzer in dieser Zeit nur das Recht "Lesen". Sobald der Schreibzugriff beendet ist, sind die Schreibrechte auch für andere Benutzer verfügbar.

Des weiteren ist wie bei allen Datenbanken eine Suche möglich. Als Suchsprache kann beispielsweise SQL (Structured Query Language) benutzt werden. Die Suche ermöglicht das gezielte Finden von Objekten, beispielsweise im Ortsbezug. Der Ortsbezug kann dazu durch Navigieren in den gewünschten Ortsbezug (wie beispielsweise in Fig. 9 dargestellt) eingegrenzt werden. Des weiteren läßt sich auch eine erweiterte Suche durchführen. Die erweiterte Suche bietet zusätzlich die Möglichkeit, gezielt Informationen innerhalb von Objekten zu suchen, d. h. beispielsweise nach einer bestimmten Eigenschaft zu suchen. Dazu werden alle Eigenschaften des Objekts dargestellt. Wird kein Objekt ausgewählt bei der erweiterten Suche, so stehen die Feldeinträge aller Objekte zur Verfeinerung der Suche zur Verfügung. Das Datenbanksystem selbst arbeitet wo nur möglich mit Indizes der Tabellen, was für datenverarbeitende Systeme günstig ist.

Abschließend kann gesagt werden, daß durch das erfindungsgemäße Datenbanksystem folgende Vorteile gegenüber dem Stand der Technik erzielt werden.

Ein vorteilhafter Aspekt ist die Vermeidung von Redundanzen. Ein objektorientierter Datenzugriff ist möglich. Es werden keine zusätzlichen Tabellen beim Hinzufügen neuer Objekttypen erzeugt. Es existieren detaillierte bzw. kombinierte Suchmöglichkeiten bis hin zur Volltextsuche. Das Datenmodell gemäß der vorliegenden Erfindung basiert auf dem standardisierten, relationalen Datenbankmodell, was erhebliche Vorteile bezüglich der Importierbarkeit von Daten darstellt, da diese unabhängig vom jeweiligen Softwarehersteller benutzt werden können. Ferner ist der Datenexport nach XML möglich.

Ein weiterer Vorteil ist darin zu sehen, daß Objekte miteinander über einen standardisierten Mechanismus verknüpfbar sind.

Für einen Fachmann auf dem Gebiet der Softwaretechnik ist es klar, daß man die Wertetabelle transponieren, d. h. Zeilen mit Spalten vertauschen kann und umgekehrt, ohne die Funktionalität der Erfindung zu verändern. Ähnliches gilt für den Aufbau der drei bzw. weiteren Tabellen.

Ein Computerprogrammprodukt kann durch jedes geeignete Speichermedium dargestellt werden, auf dem das Computerprogramm abgespeichert ist, das das Verfahren gemäß der vorliegenden Erfindung ausführt.

Außerdem ist es für einen Fachmann aus dem vorangegangenen klar, daß verschiedene Ausführungsformen der vorliegenden Erfindung lediglich exemplarisch erklärt wurden und daß diese auf einfache Art und Weise verändert bzw. abgeändert werden können, ohne vom Umfang der vorliegenden Erfindung abzuweichen. Des weiteren ist festzustellen, daß die Elemente der beschriebenen Ausführungsformen sowohl durch Software als auch durch Hardware oder eine Kombination der beiden realisiert werden können.

Claims (19)

1. Datenbanksystem, in dem eine Vielzahl von Datensätzen in einem Speicher eines Computers abspeicherbar sind, wobei jeder Datensatz eine beliebige Anzahl von Datenfeldern umfasst, dadurch gekennzeichnet, daß
eine Datenbasis des Datenbanksystems eine mehrspaltige Wertetabelle mit einer beliebigen Anzahl von Zeilen, eine Inhaltstabelle zum Speichern von Datenfeldinhalten, eine Attributtabelle zum Speichern von Datenfeldattributen und eine Objekttabelle zum Speichern von Bezügen zwischen Objekten aufweist, wobei in der Wertetabelle:
jede Zeile einem Datenfeld eines Datensatzes entspricht;
eine Spalte (txt) Inhaltsreferenzen (TxtID) beinhaltet, die mehrfach für verschiedene Datenfelder vergeben sein können und jeweils eindeutig auf einen Eintrag (TXT, TxtID) der Inhaltstabelle referenzieren;
eine weitere Spalte (tag) Attributreferenzen (TagID) beinhaltet, die mehrfach für verschiedene Datenfelder vergeben sein können und jeweils eindeutig auf einen Eintrag (TAG, TagID) der Attributtabelle referenzieren; und
noch eine weitere Spalte (obj) Objektreferenzen (ObjID) beinhaltet, die mehrfach für verschiedene Datenfelder vergeben sein können, wobei die zu jeweils einer Objektreferenz gehörenden Datenfelder jeweils einen Datensatz bilden und die Objektreferenz (ObjID) jeweils eindeutig auf einen Eintrag (OBJ, ObjID) der Objekttabelle referenzieren.

2. Datenbanksystem gemäß Anspruch 1, wobei in der Wertetabelle eine weitere Spalte (WertID) laufende Nummern beinhaltet, die jeweils genau ein einziges Datenfeld bezeichnen.

3. Datenbanksystem gemäß Anspruch 1 oder 2, dadurch gekennzeichnet, daß die Inhaltstabelle, die Attributtabelle und die Objekttabelle jeweils zweispaltig oder zweizeilig sind.

4. Datenbanksystem gemäß einem der Ansprüche 1 bis 3, wobei die Wertetabelle transponiert ist, und somit vier Zeilen und eine beliebige Anzahl von Spalten aufweist, wobei die Spalten den Datenfeldern entsprechen.

5. Datenbanksystem gemäß einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß der Eintrag (OBJ, ObjID) der Objekttabelle der jeweiligen entsprechenden laufenden Nummer einen Ort zuweist, der ein Element eines hierarchisch angeordneten, räumlichen Bezugssystems ist.

6. Datenbanksystem gemäß einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, daß ein erster Eintragsteil (TXT) eines Eintrags der Inhaltstabelle einen datenformatsunabhängigen Inhalt eines entsprechenden Datenfelds beinhaltet, und ein zu diesem ersten Eintragsteil gehöriger zweiter Eintragsteil (TxtID) einer der Inhaltsreferenzen (txt) der Wertetabelle entspricht.

7. Datenbanksystem gemäß Anspruch 6, wobei der Inhalt eines Datenfelds als Zeichenkette gespeichert ist.

8. Datenbanksystem gemäß einem der Ansprüche 1 bis 4, wobei ein erster Eintragsteil (TAG) eines Eintrags der Attributtabelle aus drei Komponten besteht, nämlich einem Objekttyp, einem Datenfeldnamen (_ObjektID_) und einem Attribut (_ID_), und ein zu diesem ersten Eintragsteil gehöriger zweiter Eintragsteil (TagID) einer der Attributreferenzen (tag) der Wertetabelle entspricht.

9. Datenbanksystem gemäß einem der Ansprüche 1 bis 4, wobei ein erster Eintragsteil (OBJ) eines Eintrags der Objekttabelle den Bezug (Ref, Parent) zu einem anderen Objekt darstellt, und ein zu diesem ersten Eintragsteil gehöriger zweiter Eintragsteil (ObjID) einer Objektreferenz (Obj) der Wertetabelle entspricht.

10. Datenbanksystem gemäß den Ansprüchen 4 und 9, wobei der Bezug eine Information über den Ort eines durch den zweiten Eintragsteil (ObjID) eines Eintrags der Objekttabelle beschriebenen Objekts innerhalb des hierarchisch geordneten, räumlichen Bezugssystems beinhaltet.

11. Datenbanksystem gemäß einem der Ansprüche 6 bis 9, dadurch gekennzeichnet, daß der jeweilige zweite Eintragsteil (TxtID, TagID, ObjID) der Einträge der Inhalts-, Attribut-, oder Objekttabelle jeweils einmalig ist.

12. Datenbanksystem gemäß Anspruch 11, wobei der zweite Eintragsteil von einem Typ "ID" ist.

13. Datenbanksystem gemäß einem der vorangegangen Ansprüche, wobei die Einträge in der Wertetabelle jeweils ganzzahlig sind.

14. Datenbanksystem gemäß einem der vorangegangen Ansprüche, wobei die Wertetabelle eine weitere Spalte/Zeile (time) aufweist, die Zeitreferenzen (TimeID) aufweist, die mehrfach, für verschiedene Datenfelder, vergeben sein können und jeweils eindeutig auf einen Eintrag in einer Zeittabelle referenzieren, wobei die Zeittabelle zweizeilig/zweispaltig ist und zweiteilige Einträge aufweist, die sich aus einem ersten Eintragsteil (Time) und einem zu diesem gehörigen zweiten Eintragsteil (TimeID) zusammensetzt, wodurch ein Bezug zwischen Objekten in Abhängigkeit von der Zeit herstellbar ist.

15. Verfahren zum Durchführen von Operationen in einem Datenbanksystem, in dem eine Vielzahl von Datensätzen in einem Speicher eines Computers abspeicherbar sind, wobei jeder Datensatz eine beliebige Anzahl von Datenfeldern umfasst, dadurch gekennzeichnet, daß das Durchführen der Operationen jeweils umfasst
zugreifen auf und/oder abspeichern von Daten einer Datenbasis, wobei die Datenbasis des Datenbanksystems eine mehrspaltige Wertetabelle mit einer beliebigen Anzahl von Zeilen, eine Inhaltstabelle zum Speichern von Datenfeldinhalten, eine Attributtabelle zum Speichern von Datenfeldattributen und eine Objekttabelle zum Speichern von Bezügen zwischen Objekten aufweist, und wobei in der Wertetabelle:
jede Zeile einem Datenfeld eines Datensatzes entspricht;
eine Spalte (txt) Inhaltsreferenzen (TxtID) beinhaltet, die mehrfach für verschiedene Datenfelder vergeben sein können und jeweils eindeutig auf einen Eintrag (TXT, TxtID) der Inhaltstabelle referenzieren;
eine weitere Spalte (tag) Attributreferenzen (TagID) beinhaltet, die mehrfach für verschiedene Datenfelder vergeben sein können und jeweils eindeutig auf einen Eintrag (TAG, TagID) der Attributtabelle referenzieren; und
noch eine weitere Spalte (obj) Objektreferenzen beinhaltet, die mehrfach für verschiedene Datenfelder vergeben sein können und jeweils eindeutig auf einen Eintrag (OBJ, ObjID) der Objekttabelle referenzieren.

16. Verfahren gemäß Anspruch 15, dadurch gekennzeichnet, daß das Datenbanksystem ferner die Merkmale gemäß einem der Ansprüche 2 bis 14 aufweist.

17. Datenstruktur, die mindestens einen Datensatz aufweist, um das Verfahren gemäß Anspruch 15 oder 16 auszuführen.

18. Computerprogramm, das computerausführbare Instruktionen aufweist, um einen Computer dazu zu veranlassen, ein Verfahren gemäß Anspruch 15 oder 16 auszuführen.

19. Computerprogrammprodukt, das computerausführbare Instruk­ tionen aufweist, um einen Computer dazu zu veranlassen, ein Verfahren gemäß Anspruch 15 oder 16 auszuführen.