DE10104831A1

DE10104831A1 - Datenstruktur für Informationssysteme

Info

Publication number: DE10104831A1
Application number: DE10104831A
Authority: DE
Inventors: Axel Von Bergen; Volker Sauermann; Arne Schwarz
Original assignee: SAP SE
Current assignee: SAP SE
Priority date: 2001-02-01
Filing date: 2001-02-01
Publication date: 2002-08-08
Also published as: EP1360616A2; EP1393206B1; EP1393206A2; WO2002061613A3; AU2002249161B2; US7257599B2; ATE316266T1; US20040088307A1; EP1360616B1; JP2004518225A; AU2002229734B2; JP2004518226A; CA2434081A1; WO2002061612A2; WO2002061613A2; DE60208778T2; DE60238179D1; US20040093329A1; ATE487186T1; DE60208778D1

Abstract

Beschrieben wird eine mehrdimensionale Datenstruktur mit optimierenden Algorithmen für einen schnellen Zugriff für Datenbankanwendungen. Die Datenstruktur eignet sich für Speichermedien mit wahlfreiem Zugriff (z. B. RAM) und beseitigt die Beschränkungen von Indexverwaltungen und Datenmodellen. Indizes gibt es nicht, denn die Daten selbst liefern in ihrer Organisationsform die benötigten Eigenschaften.

Description

Die Erfindung bezieht sich auf das Speichern und Abfragen von Information in wahlfreien Speichermedien, insbesondere für Datenbanken.

Insbesondere durch den Einsatz des Internets ergeben sich an kommerziell genutzte Softwarekomponenten erweiterte Anforderungen. Datenverarbeitung findet in zunehmendem Maße über die Grenzen eines einzelnen Unternehmens statt. Damit befinden sich zwangsläufig heterogene Systemlandschaften in einem Kommunikationsverbund. Verschiedene Anwendungen eines Herstellers haben in der Regel bei dem Zusammenwirken weniger Probleme, weil funktionale Schnittstellen aufeinander abgestimmt sind oder die selben Datenformate auf Speichermedien verwendet werden. Die Verbindung von Produkten verschiedener Softwarehersteller ist nur dann möglich, wenn die Partnerprogramme entweder über gleich definierte funktionale Schnittstellen oder über eine gleich strukturierte Datenbasis verfügen, die dann als Kommunikationsschnittstelle dient. Große integrierte Softwarepakete benutzen meistens auch intern eine solche Datenbasis, um die Integration aller beteiligten Module zu erreichen. Relationale Datenbanken sind momentan der Stand der Technik, um in der Regel diese Anforderungen abzudecken.

Der Nachteil dieser Datenbanken, ist die Beschränkung das relationalen Modells, das diesen Anwendungen zu Grunde liegt. Es ist abgestimmt auf die Semantik der beabsichtigten Programme. Neue Funktionen mit anderer Modellsicht können nur schwer in ein vorhandenes Modell eingebunden werden. Der Grund dafür ist, daß ein Modell in der Umsetzung in eine konkrete Implementation mit Indizes arbeitet, die ein schnelles Auffinden von gespeicherter Information ermöglichen. Diese Indizierung ist abgestimmt auf die vorhandenen Funktionen und paßt oft nicht mit den neuen Anforderungen zusammen, so daß Einbußen bei der Performance eines Systems die Folgen sind.

Ein relationales Datenmodell abstrahiert einen Ausschnitt der realen Welt zur Lösung definierter Aufgabenstellungen in der Informationstechnologie. Dabei müssen alle Anforderungen an das Modell, die durch die anschließende Programmierung von Anwendungen genau bestimmt werden, bereits zum Zeitpunkt der Modellbildung bekannt sein, um ein zeitlich effizientes Verhalten des Gesamtsystems zu gewährleisten.

Wenn Programm und Datenmodell nicht zusammenpassen sind aus Sicht der Performance ungünstige Datenbankanfragen die Konsequenz. In der Praxis gibt es zwei Gründe dafür. Zum einen konnten bei der Modellbildung noch nicht alle zukünftigen Anforderungen formuliert werden, so daß eine spätere Ausweitung von Problemstellungen und deren Lösung durch Programme (z. B. SQL) sich im Datenmodell nur unzureichend widerspiegelt. Das Datenmodell ist damit veraltet und paßt nicht mehr richtig zur Aufgabenstellung. Zum anderen liegt die Ursache in dem zu oberflächlichen Wissen der Programmierer, deren Kenntnis sich auf das formale Beherrschen der Syntax einer Programmiersprache beschränkt ohne die Auswirkungen von ungünstig formulierten SQL- Statements abschätzen zu können. Erfahrungen aus der Praxis haben gezeigt, daß Anwendungsprogrammierer syntaktisch korrekte Programme erstellen, die funktional das richtige Ergebnis liefern. Aber aus dem Blickwinkel der Performance sind solche Programme häufig unzureichend, weil das vorhandene Datenmodell beim Programmentwurf unberücksichtigt geblieben ist.

Dieses Problem läßt sich durch eine Anpassung des Datenmodells lösen, was aber insbesondere bei großen Installationen nur einen theoretischen Charakter hat oder man versucht die Programme durch eine geschickte "Umformulierung teurer Datenbankanfragen" zu ändern. Eine weitere Möglichkeit ist das Anlegen von Sekundärindizes, um das Datenmodell auf diese Weise an die neuen Anforderungen anzupassen. Letzteres ist in der Praxis die bevorzugte Methode, da ein Neudesign des Datenmodells auch umfangreiche Änderungen an bestehenden Programmen zur Folge hätte und dieser Aufwand normalerweise schon aus Kosten- und Zeitgründen nicht vertretbar ist.

Sekundärindizes sind nachträglich definierte Kombinationen von Tabellenfeldern als Schlüssel, die immer dann zum Einsatz gelangen, wenn Anwendungsprogramme eine Sicht auf den Datenbestand erforderlich machen, die nicht durch den Primärindex (oder ein Teil davon) abgedeckt ist. Ein Sekundärindex ist streng genommen immer ein Hinweis auf einen Entwurfsfehler bei dem zugrundeliegenden relationalen Modell oder die Folge von neuen, bislang unberücksichtigten Anforderungen durch Programme an das Datenmodell.

Sekundärindizes können allerdings nur begrenzt zur Behebung der eben genannten Problematik beitragen, da jeder zusätzlich definierte Sekundärindex die Leistungsfähigkeit (Performance) aller Zugriffe auf eine betroffene Tabelle negativ beeinflußt. Dies liegt an dem erhöhten Pflegeaufwand zusätzlicher Verwaltungsstrukturen durch das System, insbesondere beim Einfügen und Löschen von Daten in die betroffene Tabelle.

Ein optimaler Zugriff auf den Datenbestand ist unter zeitlichen Aspekten immer dann gegeben, wenn in einer Anfrage der Primärindex (oder ein Teil davon) verwendet werden kann, der in der Regel einen Datensatz identifiziert. Da Magnetplattenspeicher in den meisten Fällen für eine dauerhafte Datenhaltung sorgen und dieses Speichermedium physikalisch gesehen ein sequentielles Speichermedium ist, wird der Primärindex auch dafür verwendet, die Datensätze einer Tabelle nach diesem Kriterium sortiert dort abzuspeichern.

Der zeitlich ungünstigste Fall einer Datenbankoperation liegt dann vor, wenn kein Index benutzt wird. Dies kann beispielsweise vorkommen, wenn ein Attribut als Schlüssel in einem Programm verwendet wird, für das kein Index vorhanden ist. In diesem Fall ist ein sogenannter "Full-Table-Scan" die Folge, bei dem alle Inhalte des betreffenden Attributs der Tabelle gelesen und mit dem Schlüsselwert verglichen werden müssen.

Als weitere Schwachstelle bei Datenbanksystemen stellt sich oft die Bestimmung des Zugriffspfads heraus. Datensätze werden in der Regel über formulierte Bedingungen selektiert. Dabei werden einzelnen Attributen einschränkende logische Ausdrücke zugeordnet. Nur die Datensätze, die diesen Bedingungen entsprechen, sollen selektiert werden. Dabei gibt es oft mehrere Möglichkeiten, wie das Ergebnis erzeugt werden kann. Das Ziel eines optimierenden Zugriffssystems ist es immer, einen unter Performancegesichtspunkten günstigen Einstieg in die Datensammlung zu finden. Dabei spielt die Selektivität eines Attributs eine entscheidende Rolle. Je selektiver ein Attribut ist, um so wahrscheinlicher ist es, daß die erzeugte Zwischenergebnismenge klein bleibt, auf die dann eine weiter Bedingung angewendet werden kann, um die Zwischenergebnismenge wiederum einzuschränken. Die endgültige Ergebnismenge der selektierten Datensätze liegt vor, wenn alle Bedingungen dafür erfüllt sind. Der Nachteil üblicher optimierender Verfahren ist in der Tatsache begründet, daß eine exakte Treffermenge für ein Attribut mit einer konkreten Bedingung nicht vor dem eigentlichen Zugriff bestimmt werden kann. Es werden auf Regeln oder Wahrscheinlichkeitsrechnung gestützte Verfahren eingesetzt, die für eine konkrete Konstellation einer Anfrage oft gar nicht einen optimalen Zugriffspfad ermitteln.

Mit den im folgenden beschrieben Ringstrukturen im Zusammenspiel mit den Zugriffsalgorithmen wird eine Implementation eines Datenmodells erreicht, bei der die semantische Funktion des Datenmodells erhalten bleibt und die bei Datenbanken typischen Einschränkungen einer Indexverwaltung wegfallen. Indizes gibt es nicht und auch die Sichtweise einer herkömmlichen relationalen Datenbank ist nicht anwendbar. Wie später gezeigt wird, geht die Struktur über den relationalen Ansatz hinaus. Relationale Datenbanken sind aber stark verbreitet und diese Ringstrukturen sind auch in der Lage ein relationales Modell (als Untermenge weitaus komplexerer Modelle) abzubilden. Deshalb wird so oft wie möglich die Analogie zu diesen Datenbanken hergestellt und auch in den Beispielen verwendet.

Das Atom der Informatik ist bis heute das Bit. Aus der Sicht einer Software-Anwendung ist ein Atom eher die kleinste Informationseinheit, also etwa eine Variable mit einem Wert oder ein Feld einer Tabelle. Diese Sichtweise wird für das folgende Design gewählt. Objektorientierte Programmiersprachen, wie beispielsweise C++, unterstützen dabei diese Sichtweise bei einer Implementation erheblich. Für den Aufbau der Struktur wird das Atom als InfoCell bezeichnet und ist in der implementierten Version ein strukturierter (zusammengesetzter) Datentyp. Neben der eigentlichen Information, den eine InfoCell aufnehmen kann (ein Wert der möglichen Datentypen der gewählten Programmiersprache oder ein Pointer, sozusagen als "Nutzlast"), gibt es mehrere Zeiger (Pointer), die auf andere Elemente zeigen können. Damit lassen sich semantische Zusammenhänge erzeugen. Eine Person hat einen Vornamen und einen Nachnamen. Erst die Verknüpfung beider InfoCells über Pointer erzeugt beispielsweise die Semantik und kennzeichnet damit die betreffende Person.

Ein Datenmodell einer Datenbank würde mit einer Tabellendefinition diese Semantik bereits implizit liefern. Dazu wären dann auch gleich noch die Schlüssel vereinbart, mit denen auf die Informationen zugegriffen werden soll und das ganze ließe sich zur Laufzeit nicht mehr so leicht ändern. Nicht so in diesem Fall. Eine Semantik läßt sich auch später noch erzeugen (dynamisch), indem beliebige InfoCells (oder andere Strukturelemente, die später beschrieben werden) miteinander verbunden werden können. Bezogen auf die Datenstruktur bedeutet das, daß Verbindungen zu beliebigen anderen InfoCells jederzeit hergestellt werden können. Damit lassen sich im Endeffekt sogar mehrere Datenmodelle verschiedener Anwendungen logisch übereinander legen, die eine gleiche Teilmenge an Information benötigen.

Damit ein initialer Zustand in einem Informationsmodell erreicht werden kann, soll es eine Basisstruktur geben. Nach einer definierten Vorgabe müssen die Daten beim ersten Auftreten im Speicher mit Pointern versehen werden, die dann beliebig erweitert werden können. Informationen liegen auch in den wenigsten Fällen in atomarer Form ohne semantischen Zusammenhang vor. Diese Semantik wird benutzt, um die Algorithmen anzustoßen, die eine erste Ausprägung der Speicherstruktur vornehmen. Danach kann die Struktur entsprechend einer weiteren Semantik beliebig ergänzt werden. Für einen Aufbau dieser Basisstruktur eignet sich beispielsweise auch eine Strukturinformation des Data Dictionarys einer relationalen Datenbank. Die Beispiele zeigen deshalb zuerst, wie die Strukturen einer relationalen Datenbank abgebildet werden können. Anschließend werden dann die Erweiterungen gezeigt, die über das relationale Modell hinausgehen, um beliebige semantische Zusammenhänge abzubilden.

Die Ringstrukturen werden hier schrittweise entwickelt, um die Arbeitsweise besser nachvollziehen zu können. Dabei werden die Strukturen nach Möglichkeit auf die in der Informatik bekannten Grundstrukturen reduziert, um die Verständlichkeit zu erhöhen. Dabei haben die reduzierten Strukturen in den Abbildungen zum Teil exemplarischen Wert, um die Herleitung der gesamten Struktur transparenter zu gestalten. Die gewünschte Funktionalität ist erst in dem Zusammenspiel bei der vollständig ausgebauten Struktur vorhanden.

Nach der Herleitung der Basisstruktur wird in verschiedenen Beispielen die Arbeitsweise der Algorithmen für primitive Zugriffe gezeigt. Dabei spielen Kennzahlen eine entscheidende Rolle, die für die Optimierung des Zugriffs benutzt werden. Im Gegensatz zum Stand der Technik, kann eine exakte Berechnung der Treffermengen für jede Bedingung erfolgen, so daß ein Optimierungsalgorithmus alle Informationen erhält, um daraus den günstigsten Pfad für einen Zugriff zu berechnen.

Das Kernstück der Beschreibung ist eine Datenstruktur mit den dazugehörenden Algorithmen. Diese Datenstruktur bildet die Grundlage für Überlegungen, die zu einfachen Zugriffsalgorithmen führen. Es wird das Ziel verfolgt, eine Datenstruktur in einem Speichermedium mit wahlfreiem Zugriff (z. B. RAM) zu erzeugen und dabei die Einschränkungen zu beseitigen, die eine Indexverwaltung mit sich bringt. Indizes gibt es nicht, sondern die Daten selbst liefern in ihrer mehrdimensionalen Organisationsform die benötigten Eigenschaften. Dabei wird auf hohe Effizienz beim Zugriff Wert gelegt. Die Grundelemente sind in der Informatik bereits bekannte Elemente. Zeiger (Pointer) bilden hierbei die Basis bei den verwendeten Ringstrukturen. Die Ringe lassen sich zum großen Teil so organisieren, daß implizit binäre Baumstrukturen darin vorkommen.

In einem komplexen mehrdimensionalen Design wird eine Eigenschaft erzeugt, die in Verbindung mit darauf abgestimmten Zugriffsalgorithmen eine Unabhängigkeit von den heute einschränkenden Eigenschaften eines real implementierten Datenmodells bei Datenbanken darstellt. Beim Zugriff werden Kennzahlen ausgewertet, die eine exakte Prüfung der Selektivität erlauben und die Optimierung des günstigsten Zugriffspfads unterstützen.

Es zeigen:

Abb. 1 Darstellung der statischen Hierarchie des gesamten Systems

Abb. 2 Anker als initiales Element und für InfoType und InfoCourse und auch Element gleichen Typs für den Informationsträger InfoCell

Abb. 3 Teilstruktur: Anker mit einem InfoCell-Element

Abb. 4 Teilstruktur: Anker mit zwei InfoCell-Elementen als Ringstrukturen mit einer impliziten binären Baumstruktur

Abb. 5 InfoCluster mit drei InfoTypes in binärer Baumdarstellung

Abb. 6 InfoCourse als binärer Baum, sortiert über die InfoType-Identifizierungsnummer (Id) und als Tabelle dargestellt

Abb. 7 Teilstruktur: 4-dimensionale Verkettung von InfoCell-Elementen mit Darstellung einer äquivalenten Tabelle

Abb. 8 Doppelt verketteter Selbst-Ring mit Kennzahl für die Mächtigkeit des Rings

Abb. 9 Kennzahl für die Mächtigkeit einer mehrdimensionalen Struktur

Abb. 10 Darstellung einer Tabelle als 6-dimensionale Struktur

Abb. 11 Y-Adaper InfoBridge für beliebige Verkettung von Informationen

Abb. 12 InfoBridge mit drei Flagleisten als Diskriminator

Abb. 13 Baumstruktur mit Ringen für die Beispiele

Abb. 14 Reduzierung der Struktur aus Abb. 13 für eine bessere Darstellung der Beispiele

Abb. 15 Beispiel 1: Suchbedingung (key = 54)

Abb. 16 Beispiel 2: Suchbedingung (key < 20)

Abb. 17 Beispiel 3: Suchbedingung (key < 28) - Formel für die Treffermenge (M)

Abb. 18 Fortsetzung Beispiel 3: Suchbedingung (key < 28) - Formel für die Treffermenge (M)

Abb. 19 Fortsetzung Beispiel 3: Suchbedingung (key < 28) - Formel für die Treffermenge (M)

Abb. 20 Fortsetzung Beispiel 3: Suchbedingung (key < 28) - Formel für die Treffermenge (M)

Abb. 21 Beispiel 4: Suchbedingung (key < 10)

Abb. 22 Beispiel 5: Suchbedingung (key between 24 and 54)

Abb. 23 Beispiel 6: Optimierung

Ein komplettes System ist hierarchisch aufgebaut (und besteht beispielsweise bei der Implementation eines Prototyps aus C++ Code zum Testen der Datenstruktur mit den Algorithmen) aus Klassen-Objekten, von denen zur Laufzeit beliebig viele Instanzen erzeugt werden können (Abb. 1). Die Begrenzung wird dabei durch die physische Größe des Speichermediums bestimmt (beim Prototyp beispielsweise der Hauptspeicher (RAM) des Test-Rechners). Für die Veranschaulichung der folgenden Abschnitte werden nur die relevanten Teile gezeigt, nicht das ganze System. Der Einstieg in die Datenstrukturen wird bewußt über die Abbildung einer herkömmlichen Datenbanktabelle erfolgen, weil damit eine bekannte Analogie zu existierenden Datenbanken verwendet werden kann. Im Anschluß wird aber sehr bald deutlich, daß die vorgestellte Struktur weitaus mehr leistet. Es wird gezeigt, daß sich beliebige Informationszusammenhänge abbilden lassen. Ein kurzer Vorgeschmack dazu erhöht aber das Verständnis der folgenden Ausführungen.

Beispielsweise gehört dazu die Tatsache, daß eine InfoCell sowohl einen einzelnen Wert eines einzelnen elementaren Typs aufnehmen kann, als auch im anderen Extremfall mehrere InfoAreas gleichzeitig adressieren kann, was einer Mehrzahl weiterer kompletter Datenbanken entspricht (Die Kontrolle der dabei entstehenden möglichen beabsichtigten oder ungewollten Rekursionen sind nicht Gegenstand dieser Ausführung und wären außerdem Aufgabe von zukünftig zu erstellenden Algorithmen, falls so eine komplexe Funktionalität praktisch - im geistigen Sinne gemeint - überhaupt zu beherrschen ist. Die Strukturen leisten das aber und zwar nicht nur theoretisch).

Das Test-System ist zwar in einer objektorientierten Sprache erstellt worden, kann aber auch in einer "normalen" Programmiersprache implementiert werden, die Pointerprogrammierung unterstützt. Die mit den Algorithmen erzeugten InfoAreas (Datenbanken) sind ebenfalls nicht objektorientiert, da als kleinste Einheit am Ende immer eine InfoCell mit genau einem Wert eines elementaren Typs steht. Eine beliebige Objektsicht kann aber zur Laufzeit durch eine semantische Verknüpfung über InfoCourse erzeugt werden. Übertragen auf relationale Datenbanken kann ein InfoCourse einer Datensatzdefinition genau einer Tabelle entsprechen, wie in den folgenden Beispielen zuerst gezeigt wird, als auch einer, der sich über beliebige Felder unterschiedlicher Tabellen und sogar unterschiedlicher Datenbanken (InfoAreas) erstreckt (mit Verästelung, wenn gewünscht). Auf ähnliche Weise kann man auch eine referentielle Integrität sicherstellen, indem beispielsweise Werte einer Prüftabelle nicht in die Anwendungstabelle kopiert werden, wie bei einer herkömmlichen Datenbank, sondern die betreffende InfoCell besitzt als Wert einen Pointer auf die InfoCell des entsprechenden InfoClusters, was der Prüftabelle entsprechen würde. Damit kommt der Wert tatsächlich nur ein einziges Mal vor, nämlich in der "Prüftabelle" und alle anderen Werte sind Pointer, die darauf zeigen. Mit dem eben beschriebenen, wird auch schon ein wenig deutlicher, wie es funktioniert, wenn verschiedene Datenmodelle logisch übereinander gelegt werden, die dieselben Informationen beinhalten. Pointer zeigen einfach auf dieselbe InfoCell mit der betreffenden Information. Ändert sich die Information, ändert sie sich für alle Datenmodelle exakt zum gleichen Zeitpunkt. Redundanz und Aktualitätsprobleme gehören damit in die Vergangenheit!

Zunächst wird die statische Definition (Abb. 1) einer Basisstruktur des InfoSystems gezeigt, die anschließend dynamisch erweitert werden kann. Um die Analogie zu einer relationalen Datenbank herzustellen, wird gleich mit gezeigt, welche Elemente einer herkömmlichen relationalen Datenbank auf diese Hierarchie des InfoSystems abgebildet werden kann:
InfoSystem ← Management System
InfoArea ← Datenbank
InfoCluster ← Tabelle
InfoType ← Attribut
InfoCourse ← Datensatz
InfoCell ← Feld
InfoBridge ← (kein Vergleich)

Das InfoSystem stellt die Laufzeitumgebung mit den Algorithmen zur Verfügung und besteht bezogen auf die diskutierte Datenstruktur zunächst nur aus einem Anker, der (dynamisch) beliebig viele Instanzen vom Typ InfoArea verwalten kann. Jede InfoArea hat wiederum einen Anker mit der selben Funktionalität bezogen auf die InfoCluster. Ein InfoCluster verwaltet mehrere Anker. Zwei davon gehören zur Datenverwaltung im Sinne einer herkömmlichen Datenbank. InfoType kann als Attribut einer Tabelle angesehen werden und ein InfoCourse startet immer in einem InfoCluster. Bleibt der InfoCourse mit seinen adressierten InfoCell-Elementen, die einem Feld einer Tabelle entsprechen, innerhalb eines InfoClusters, dann entspricht er einem Datensatz einer herkömmlichen Tabelle. Dieser Fall wird bei den folgenden Darstellungen zuerst gezeigt und mit den dazu entwickelten Algorithmen unterstützt.

Zur weiteren Erklärung wird der eben beschriebene "Top-Down- Ansatz" verlassen und auf eine "Bottom-Up-Sichtweise" gewechselt. Begonnen wird deshalb mit den hierarchisch kleinsten Elementen der Struktur, also mit InfoCell und den direkt damit beteiligten Ankern. Bei der Erzeugung einer Instanz vom Typ InfoType wird auch ein Anker erzeugt, der eine Instanz vom Typ InfoCell ist. Dieser Anker hat die Funktion, die anschließend folgende Struktur aus InfoCell-Elementen zu verwalten und ist zunächst initial (Abb. 2). Der Anker besitzt, wie die eigentlichen InfoCell-Informationsträger auch, sieben Pointer, die der Reihen nach erklärt werden.

Aus Abb. 2 wird ersichtlich, das nach der Erzeugung eines Ankers alle Pointer zurück auf den Anker zeigen. Das ist der initiale Zustand, der zugleich die kleinste Ausprägung der Ringstrukturen zeigt. Jeder Pointer der Struktur hat damit eine gültige Adresse. Der Fall eines nicht definierten Pointers (Nullpointer) wird dadurch vermieden, um bei einer Navigation durch die Struktur immer mit gültigen Adressen arbeiten zu können. Der Anker hat darüber hinaus die Funktion einer Marke, die von den Algorithmen beispielsweise als Abbruchbedingung von Schleifen genutzt wird. Die Abb. 3 zeigt wie eine InfoCell mit einer Information an den Anker angehängt wird. Die Ringstruktur bleibt dabei erhalten, da jetzt zwei Pointer (LVR + RVR) von der neuen InfoCell zurück auf den Anker zeigen und sogenannte vertikale Ringe bilden. Gleichzeitig wird durch die Verwendung von zwei Pointern ein binärer Baum erzeugt. Neue InfoCell-Elemente (Knoten) werden gemäß einer Sortierreihenfolge des Typs der Information in den linken oder rechten Ring eingefügt. Das Einfügen erfolgt bei einem kleineren Wert links und bei einem größeren Wert rechts gemäß der bekannten Baumlogik (Abb. 4). Das Einfügen neuer Knoten erfolgt immer vor dem Anker. Um bei einer größeren Anzahl von Knoten eine höhere Effizienz bei späteren Zugriffen zu erreichen, kann zusätzlich die AVL-Baumlogik genutzt werden (Die Ausgleichsmechanismen der AVL-Bäume sind hier nicht Gegenstand der Betrachtungen, da sie in der Fachliteratur bereits ausgiebig beschrieben worden sind. Sie werden in den Algorithmen und beim Aufbau des Test-System lediglich benutzt und tragen so zur Steigerung der Effizienz der Zugriffsalgorithmen bei).

Abb. 5 zeigt den eben beschriebenen impliziten binären Baum für drei InfoTypes die zu einem InfoCluster gehören. Um die Grafik übersichtlicher zu halten, sind in der Darstellung die Pointer, die zurück zu den Ankern führen, weggelassen worden. Der semantische Zusammenhang von Information wird in Abb. 6 ersichtlich. Am InfoCluster hängt ein weiterer Anker, der ebenfalls vom Typ InfoCell ist und Knoten verwaltet, die InfoCourse genannt werden. Ein InfoCourse ist mit einem Datensatz einer Tabelle vergleichbar, solange es sich nur um eine einfache Form (wie in diesem Fall) handelt. Im Gegensatz zu einem Datensatz ist der InfoCourse aber keine lineare Aneinanderreihung von Attributen, gemäß einer definierten Reihenfolge in einer Tabelle, sondern ebenfalls eine Ringstruktur (im folgenden auch Ring-Baum genannt) mit einem impliziten binären Baum (Pointer LHR + RHR), der über eine eindeutige Identifizierungsnummer sortiert ist, die zum InfoType gehört. Die Pointer, die zurück auf den InfoCourse (kleinerer Anker-Pos 1 = Pfeil mit der 1 im Bauch) zeigen, sind in der Darstellung wieder weggelassen worden. Genau genommen handelt es sich wie oben wieder um Ringe. (Die einzelnen InfoCouse- Elemente bilden übrigens ebenfalls die gleiche Ringstruktur mit impliziten Bäumen nach einer InfoCourse-Id sortiert und hängen so am darüberliegenden Anker. Es hängt also genau genommen am obersten Anker (Pos. 2) ein "Ring-Baum" aus Ankern, deren einzelne Anker wieder auf einen "Ring-Baum" zeigen, deren einzelne Anker (Pos. 1) jeweils einen einzelnen Datenpfad beschreiben. Da diese Tatsache momentan aber keine Rolle spielt, ist die Grafik auch hier stark vereinfacht). Die Abb. 6 zeigt unten in der Grafik die tabellarische Form der Information. In der Abb. 7 sind die Knoten gemäß der Semantik aus der vollständigen Tabelle (unten in der Grafik) verkettet worden. (Alle Pointer, die eher zur Verwirrung führen sind in der Grafik wieder weggelassen worden)

Die Struktur von InfoType kann die Funktionalität einer vorher definierten Wertemenge besitzen, deshalb könnten darin durchaus auch Knoten vorkommen, die in keinem InfoCourse hängen (ähnlich einer Werte-Tabelle). Der implizite Baum enthält demnach alle Werte, die vorkommen dürfen auch nur einmal. Umgekehrt benutzt aber ein InfoCourse diese Werte ebenfalls direkt und es kann vorkommen, daß mehrere InfoCourse den selben Wert nutzen müssen. Für dieses Ereignis müssen zwei Fälle unterschieden werden, je nachdem ob eine weitere fertige Struktur bereits vorliegt auf deren Instanzen mittels eines Pointers referenziert werden kann oder ob eine gleiche Struktur für den InfoCourse benutzt werden soll. Der erste Fall soll zurückgestellt werden, weil dazu die vollständige Struktur verstanden worden sein muß.

Zusätzliche Anmerkung: Man hätte eine Referenzierung auch konsequent - im Sinne einer logisch "saubereren" Lösung - einführen können, dann wären alle Werte aller InfoTypes tatsächlich nur einmal vorhanden und würden von einem InfoCourse aus gesehen immer referenziert werden (generelle Abtrennung der Semantik vom Wert). Da aber in der Praxis nur wenige Daten einen Charakter aufweisen, die beispielsweise einem Prüfwert entsprechen, wurde zu Gunsten schnellerer Zugriffe und einfacherer Algorithmen die folgende Selbst-Ring Architektur gewählt, die zunächst (für die Basisstruktur) das gleiche leistet. Eine Referenzierung von jedem Knoten eines InfoCourse aus, würde sonst auch immer eine indirekte Adressierung bei einer konkreten Implementation bedeuten, die zusätzlich Zeit und Speicherplatz kostet. Diese Methode wird später aber eingesetzt, allerdings nur da, wo tatsächlich semantische Zusammenhänge zu schon existierenden Daten bestehen. Auch für "große Informationen", wie BLOBs (binary large objects) oder lange Zeichenketten, wird (steuert der Datentyp) eine Referenzierung gewählt, um Speicherplatz zu sparen. Ebenfalls wird sich beispielsweise ein zusätzlich zu definierendes Datenmodell, das bereits existierende Strukturen benutzen möchte, genau dieser Vorgehensweise bedienen. Dazu würde dann beispielsweise eine neue InfoArea ihre eigenen InfoCluster definieren, die auf bestehende InfoTypes referenzieren, die zu einer bereits bestehenden anderen InfoArea - oder mehreren - gehören. Das wäre dann eine Art View über mehrere Tabellen und ggf. verschiedene Datenbanken! Ebenso könnten auch noch eigene InfoTypes dazu erzeugt werden, die eigene InfoCells (Wert ist dann ein Pointer) haben, die dann auf bestehende InfoCells (mit Werten) referenzieren. Dann hätte man eine gezielte Selektion von Daten, weil nur eine Teilmenge der existierenden Daten in der neuen Datenbank benötigt wird. Ein dazu gehörender neuer InfoCourse ginge dann jeweils über eine referenzierende InfoCell und nicht über die referenzierte. Die gehören ja zur Basisstruktur (und einem anderen InfoCourse), die gerade hergeleitet wird.

Werte können auch mehrfach vorkommen, weil verschiedene InfoCourse der gleichen Struktur auch den gleichen Wert benötigen. Die Werte, die im impliziten Baum von InfoType enthalten sind, sollen aber nur einmal in der Baumsortierung vorkommen. Auf eine Referenzierung soll beim Aufbau der ersten Basisstruktur aber ebenfalls verzichtet werden (siehe auch oben: Zusätzliche Anmerkung). Deshalb findet bei Bedarf eine Vervielfachung eines Knotens mit einer doppelt verketteten Ringstruktur statt (Abb. 8).

Eine einfache Verkettung erfüllt die erforderliche Funktionalität bereits, da durch die Ringstruktur immer alle Knoten des gleichen Werts erreichbar wären. Aber die Rückwärtsverkettung bietet einen Performancevorteil beim Zugriff auf die Struktur. Erfahrungsgemäß wird von den meisten Anwendungen auf jüngere Information häufiger zugegriffen, als auf ältere. Da beim Einfügen neuer Information der jüngste Knoten den Master-Knoten bildet, der auch Mitglied der InfoType-Ring-Baumstruktur wird, wandert sein Vorgänger in den Selbst-Ring. Dadurch entsteht ein nach Alter sortierter Ring von der Knoten gleichen Werts, die zu unterschiedlichen InfoCourses gehören. Bei einem Zugriff, der (über InfoCourse bei Auswertung einer komplexen logischen Bedingung) mitten in einem solchen Ring landet, kann jetzt sofort in Rückwärtsrichtung weiter gesucht werden, wobei die Knoten bis zum Ring-Master immer jünger werden. Nach dem Passieren dieses Knotens kommt dann erst die älteste Information des Rings und von dort werden die Knoten wieder jünger. Die Anzahl der Mitglieder des Selbst- Rings ist im Ring-Master vermerkt, um die Algorithmen bei der Optimierung eines Zugriffs zu unterstützen, wie später in den Beispielen gezeigt wird. Dabei zeigt nur der Ring-Master die momentan richtige Anzahl, weil nach dem Einfügen ansonsten alle Selbst-Ring-Knoten besucht werden müßten, um den Zähler entsprechend anzupassen. Da aber für die Algorithmen eine Information darüber ausreicht, ob es überhaupt weitere Ringmitglieder gibt oder der Knoten als einziger diesen einen Wert besitzt, reicht ein von Null verschiedener Wert für den Zähler in diesen Fall aus. Das ist für alle Selbst-Ring- Knoten zu jedem Zeitpunkt der Fall. Eine Null ist also immer der Hinweis darauf, daß die Wertausprägung nur einmal vorhanden ist und es sich dann natürlich auch um den Ring-Master handeln muß.

Die optimierenden Algorithmen, die später zum Teil in den Beispielen in ihrer Arbeitsweise gezeigt werden, benötigen Informationen über die Größe der beteiligten Struktur, um einen effizienten Zugriffspfad bestimmen zu können. Dazu wird in jeder InfoCell die Anzahl aller benachbarten Knoten meherer Ringe bis zum Anker, die über vier Pointer erreichbar sind als Summe abgelegt (Abb. 9). Dazu werden die Zählerstände der Knoten, die jeweils über die beiden Pointer der vertikalen Ringe angesprochen werden können (enthalten ja ebenfalls einen eigenen mehrdimensionalen Zählerstand, weil die Struktur rekursiv ist), mit der Selbst-Ring-Ausprägung addiert, wobei eine Null im Ring-Master für die Berechnung durch eine Eins (für den Knoten selbst) ersetzt werden muß. Damit enthält eine InfoCell die Anzahl aller Knoten, die sich in allen Pfaden der Struktur bis zum Anker befinden (Nachbarschaftsbeziehungen zu InfoCourse- Knoten und die später noch beschriebenen InfoBridge- Beziehungen bleiben dabei außen vor). Damit können die Algorithmen dann günstige Zugriffspfade mittels Mengenoperationen berechnen, ohne alle betroffenen Knoten selbst besuchen zu müssen, wie die Beispiele später zeigen.

In Abb. 10 ist die (oben links in der Grafik) gezeigte Tabelle als 6-dimensionale Struktur aufgeführt. Dabei sind alle Zähler und Identifizierungsnummern bei allen Knoten vollständig eingezeichnet. Auf die Anker-Elemente und alle Pointer, die jeweilige Ringe schließen würden, wurde der Übersichtlichkeit halber wieder verzichtet.

Der Pointer IF (Abb. 2) spielt eine besondere Rolle in der Struktur. Er ist in jeder Instanz jedes Objekttyps vorhanden und ist multifunktional (entspricht einem varianten Typ, in C++ Union mit allen Pointertypen aller Klassenobjekte). Damit kann er auf jede beliebige andere Instanz zeigen. Welchen Typs diese Instanz ist, ergibt sich entweder aus einem konkreten logischen Zusammenhang oder wird durch einen Diskriminator bestimmt. Das ist entweder eine Flagleiste (Abb. 12) oder ein entsprechend definierter Zustandsgraph (gemäß der Automatentheorie) in jedem Knoten. Die Flagleiste eignet sich, wenn die Anzahl der Bits entsprechend klein ist, so daß die Maschinenwortlänge (Effizienz) nicht überschritten wird, ansonsten eignet sich ein Zustandsgraph eigentlich sowieso besser, weil damit auch umfangreichere semantische Zusammenhänge und Abläufe mit verschiedenen Zuständen (und ggf. definierten Folgezuständen) besser abgebildet werden können.

Mit Hilfe dieses Pointers können beliebige Verknüpfungen zu anderen Instanzen hergestellt werden. Das kann direkt geschehen oder über eine InfoBridge. Die InfoBridge ist eine Art Y- Adapter, der auch noch kaskadierbar ist (Abb. 11). Da der Y-Adapter darüber hinaus auch noch bidirektional sein kann, läßt sich ein beliebiges Netzwerk über die Basisstruktur legen. Der Y-Adaper beinhaltet ebenfalls für jeden varianten Pointer (Ausgänge des Y-Adapters) eine eigene Flagleiste oder Variable für den Zustandsgraphen. Damit kann ein Algorithmus mit der Information über den Typ der folgenden Instanz versorgt werden und entsprechende Handlungen durchführen.

Mit dieser Architektur wird der relationale Ansatz herkömmlicher Datenbanken überschritten. Alle Anwendungsmöglichkeiten an diese Stelle aufzuzählen würde das Thema sprengen, deshalb soll ein Ausblick auf ein geplantes Vorhaben genügen. Da sich individuelle Verbindungen (Links) zwischen einzelnen InfoCells erzeugen lassen ohne auf den ganzen InfoType zurückzuwirken, können "intelligente Algorithmen" zum Einsatz gelangen, die auf Grund der Anforderungen einer übergeordneten Anwendung, diese Verschaltung von Informationen ganz individuell vornehmen können. Damit kann ein dynamisch wachsendes (lernendes) fein granuliertes Datenmodell erzeugt werden (entspricht individuellen Links auf Datensatzebene). Die Links können dabei nicht nur auf unterster Ebene, wie eben beschrieben, sondern auch auf höheren Hierarchiestufen durchgeführt werden, wobei dann Informationsstrukturen entstehen, die einen generischen Charakter haben (entspricht beispielsweise einem View oder Join, der dann auch für später eingefügte Datensätze gilt).

Der Pointer IF hat aber auch noch eine ganz simple Funktion. Transaktion verändern grob betrachtet in der Regel viele Daten gleichzeitig. Mikroskopisch gesehen passiert das aber sequentiell auf dem Speichermedium. Die Transaktion wird beispielsweise bei Datenbanken mit einem Commit work oder einem Rollback abgeschlossen, was bedeutet das entweder alle Änderungen gültig werden oder komplett zurückgenommen werden müssen. Für das Speichersystem bedeutet dieser Umstand, daß beispielsweise bei einer Wertänderung beide Werte jeweils in einer eigenen InfoCell temporär vorgehalten werden müssen, bis die Entscheidung gefallen ist. Um die semantische Verbindung zwischen den beiden Werten herzustellen, eignet sich die InfoBridge. In der Abb. 12 ist dieser Fall dargestellt. Die obere InfoBridge verbindet zwei InfoCells miteinander. Die Verbindung hätte auch direkt zwischen den beiden InfoCells ohne die InfoBridge stattfinden können, denn jede InfoCell besitzt ja einen Pointer mit genau der gerade beschriebenen Funktionalität, die in einer InfoBridge lediglich (mindestens) drei Mal vorkommt. Dann könnten aber keine weiteren Instanzen mehr angeschlossen werden, weil kein freier Pointer mehr zur Verfügung wäre. Damit wäre dann diese Dimension für dazu kommende Anforderungen erloschen. Durch das Einfügen einer InfoBridge bleibt der Freiheitsgrad erhalten und kann durch die Kaskade noch beliebig erweitert werden, wie die gestrichelte InfoBridge in der Abb. 12 zeigt.

Dieser Y-Adapter kann in mehreren Varianten zum Einsatz kommen. Mit drei Anschlüssen lassen sich in der Kaskade bereits beliebige Mehrwege-Strukturen erzeugen. Bei entsprechendem Bedarf sind aber auch mächtigere Adapter mit vielen Anschlüssen denkbar.

Damit ist die Erklärung der Datenobjekte, die Gegenstand dieser Struktur sind, abgeschlossen. Damit die Datenstruktur, die sich zur Speicherung beliebiger Informationen eignet, betrieben werden kann, sind eine Reihe weiterer Datenobjekte, zum Teil mit temporären Charakter, notwendig. Diese Erweiterungen sind nicht Gegenstand dieser Abhandlung, werden aber in den folgenden Beispielen erwähnt, wenn sie zum Verständnis beitragen (beispielsweise Guide-Objekte). Die Funktionsweise der Algorithmen für den primitiven Zugriff werden zusammen mit den Beispielen unabhängig von einer konkreten Programmiersprache erklärt.

Beispiele

Auf gespeicherte Information eines Datenhaltungssystems wird in der Regel über den Inhalt zugegriffen, deren Charakteristik beschrieben wird. Aus diesem Grund gibt es dafür Sprachkonstrukte, die diesen Zweck unterstützen. Standard-SQL ist beispielsweise eine genormte Variante, die sich für relationale Datenbanken eignet. Die folgenden Beispiele sollen aber nicht den Befehlssatz einer Sprache behandeln, sondern lediglich elementare Bedingungen betrachten, aus denen sich konkrete Sprachkonstrukte erstellen lassen. Außerdem müßte der Sprachumfang über ein Standard-SQL hinausgehen, da diese Datenstruktur mehr leisten kann. In den folgenden Beispielen wird deshalb exemplarisch gezeigt, wie Zugriffe auf InfoCells erfolgen, die genau einem einen InfoType entsprechen und verschiedenen logischen Bedingungen gehorchen sollen. Dazu wird nur eine Teilansicht der Struktur benötigt. In der Abb. 13 ist die Teilstruktur dargestellt. Für den Zugriff werden in der praktischen Umsetzung eines Algorithmus die vertikalen Ringe und die Selbst-Ring-Ausprägung benötigt. Die Pointer, die zurück zum Anker führen, sind aus Gründen der besseren Übersicht in der Grafik wieder durch ein kleines Ankersymbol ersetzt worden. Für die folgenden Beispiele soll die Struktur aber nochmals stark vereinfacht werden (Abb. 14). Wenn man für die theoretische Betrachtung die Prämisse setzt, daß jeder Wert nur einmal vorhanden sein darf (in der Praxis ein eher selten auftretender Fall und deswegen ist die reduzierte Struktur auch praktisch so nicht einsetzbar), dann kann der Selbst-Ring entfallen. Da jetzt auch die Anker und die Ringpointer in der Grafik weggelassen wurden, bleibt die Darstellung eines binären AVL- Baums als Gerippe übrig. An diesem reduzierten "Theorie-Baum", der auch dem linken Baum aus der Teilstruktur mit den Pointern LVR und RVR in der Abb. 5 entspricht, sollen die folgenden logischen Bedingungen und der Zugriff gezeigt werden, weil damit das Prinzip zum Finden von Ergebnismengen über Mengenoperationen deutlich wird.

Beispiel 1 Suchbedingung (key = 54)

Die Suche im Baum beginnt in der Abb. 15 nach dem passieren des Ankers (der in der Grafik weggelassen wurde) mit der Wurzel (Pos 1 = Pfeil mit der 1 im Bauch) des Baums. Da das Suchargument (54) größer als der Wert der InfoCell mit dem Wert (40) ist, muß der gesuchte Knoten rechts von der Wurzel liegen. Die Überprüfung des nächsten Knotens ist iterativ bis zu einer Abbruchbedingung der Schleife. Beim Knoten der Pos 2 ist das Suchargument (54) kleiner als der Wert (60) der InfoCell, so daß links weiter gesucht wird. Bei Pos 3 (50) wird nach der Prüfung der rechte Pfad gewählt und bei Pos 4 (55) der linke Pfad. Bei Pos 5 (54) ist die InfoCell gefunden, bei der das Suchargument mit dem Wert übereinstimmt. Da die InfoCell, wie in der Abb. 6 auch mit den Pointern LHR und RHR ausgestattet ist, kann auf semantisch benachbarte Informationen über den InfoCourse zugegriffen werden. Da es sich bei den InfoCourse- Pointern auch um einen Ring-Baum handelt, kann immer der Anker des betreffenden InfoCourse gefunden werden und von dort aus ist dann jeder Knoten der InfoCourse-Struktur erreichbar. Aus Performancegründen kann in jeder InfoCell ein zusätzlicher Pointer untergebracht werden, der direkt auf diesen InfoCourse- Anker zeigt, um ein unnötiges Durchhangeln bis zum Anker zu vermeiden. Das kann bei großen Strukturen von Vorteil sein und wurde auch im Test-System so eingebaut.

Zusammenfassend kann man feststellen, daß von der Wurzel ausgehend immer in Richtung des Sucharguments durch den Baum abgestiegen wird, bis das Abbruchkriterium erreicht wird. Dieser Fall ist gegeben, wenn der Wert gefunden wurde oder das Ankerelement erreicht worden ist, was dann gleichbedeutend damit ist, daß ein horizontaler Pfad einmal vollständig durchlaufen wurde. Beim Einfügen eines Werts wird identisch verfahren. Angenommen der Wert (53) hätte eingefügt werden sollen - Pos 6 (53) gestrichelt in der Grafik -, dann wäre genau der gleiche Pfad im Baum beschritten worden mit dem Unterschied, daß die neue InfoCell vor dem Anker eingefügt worden wäre, also nach dem Knoten (54) über den LVR-Pointer. (Da der Baum dann nicht mehr der AVL-Bedingung entsprechen würde, die besagt, daß ausgehend von jedem Knoten die Länge eines linken und rechten Pfads sich höchsten um die Länge "Eins" unterscheiden darf (trifft für die Pos 4 (55) und Pos 2 (60) zu), würde der Baum jetzt einem Umsortieralgorithmus folgen, der die Ausgeglichenheit wieder herstellt. Dieser Algorithmus ist aber nicht Thema dieser Ausführung und ist in der Fachliteratur ausgiebig beschrieben.)

Beispiel 2 Suchbedingung (key < 20)

In der Abb. 16 wird eine Teilmenge durch die Baumstruktur ermittelt. Der Einstieg in die Struktur erfolgt wieder über die Wurzel Pos 1 (40). Da das Suchargument kleiner ist, erfolgt der iterative Abstieg nach links. Mit Pos 2 (20) ist die Abbruchbedingung der Schleife erfüllt und die Suchbedingung genau erfüllt. Da der Operator kleiner bedeutet, erfüllen alle Knoten Pos 3 (3, 5, 7, 10, 11) des linken Pfads die Bedingung. Ohne die einzelnen Knoten dieser Teilstruktur besuchen zu müssen, kann ein in Beispiel 6 beschriebener Optimierungsalgorithmus über die Mächtigkeit dieser Teilstruktur informiert werden. Wie in der Abb. 9 ersichtlich ist, wird in jedem Knoten die Mächtigkeit der komplexen Unterstruktur gespeichert. In Abb. 16 ist der Selbst-Ring mit den Pointern LSR und RSR aus Gründen einer besseren Lesbarkeit der Grafik nicht mit eingezeichnet worden, aber diese Knoten zählen in der praktischen Implementation des Algorithmus mit dazu. Wie ein Optimierungsalgorithmus mit dieser Information arbeitet, die in der InfoCell (10) gespeichert ist und innerhalb des kleinen Quadrats mit x1 bezeichnet ist, wird im Beispiel 6 dann näher erläutert.

Beispiel 3 Suchbedingung (key < 28)

In diesem Beispiel (Abb. 17) wird die Mengenlogik deutlich, die zur Ermittlung einer Treffermenge (M) führt. Der Abstieg im Baum erfolgt wieder in Richtung des Sucharguments (28). Da dieser Wert nicht in der Baumstruktur vorkommt, wird die Abbruchbedingung der Iteration der Anker sein, der in der Grafik aus den genannten Vereinfachungsgründen nicht mit eingezeichnet worden ist. Der Einstieg erfolgt wieder über die Wurzel Pos 1 (40) und erfüllt beim Knoten Pos 2 (20) die Bedingung. Wie aus der Grafik zu entnehmen ist, ist mit der Angabe der Mächtigkeit x1, die im Knoten der Pos 2 (20) vermerkt ist das Ergebnis noch nicht gültig, da sich in der Struktur noch Knoten (30, 35) befinden, die fälschlicherweise mitgezählt werden, weil sie nicht der Bedingung entsprechen. Der Algorithmus schaltet jetzt auf Subtraktion um und verfolgt den Pfad weiter in Richtung des Sucharguments (28) bis er auf einen Knoten stößt der nicht mehr der Suchbedingung (< 28) entspricht. Dieser Fall (Abb. 18) ist bereits beim nächsten Knoten Pos 3 (30) erreicht. Die Mächtigkeitsangabe y1 der InfoCell des Knotens Pos 3 (30) wird folglich subtrahiert, wobei jetzt die Knoten (22, 25, 27) zuviel abgezogen werden. Der Algorithmus schaltet seine Mengenarithmetik wieder auf addieren um und setzt die Suche im Pfad in Richtung des Sucharguments (28) fort bis er auf einen Wert stößt der wieder der Suchbedingung entspricht. In der Abb. 19 wird dieser Fall wieder beim nächsten Knoten Pos 4 (25) erreicht und die Mächtigkeit x2 der vollständigen Unterstruktur (einschließlich der Selbst-Ringe, die hier nicht eingezeichnet sind - vgl. Abb. 9 -) addiert. Der Algorithmus schaltet wieder auf Subtraktion um und setzt seine Suche fort. Da er bis zum Anker keinen Knoten mehr findet, der außerhalb der Suchbedingung (< 28) liegt, stellt (M) jetzt das Endergebnis dar (Abb. 20) und weist die Treffermenge exakt aus.

Damit reicht ein einziger Abstieg im Baum in Richtung des Sucharguments aus, um die jeweiligen Teilmengen zu identifizieren und im Wechsel einer Addition und Subtraktion das Trefferergebnis exakt zu ermitteln. Damit kann einem folgenden Optimierungsalgorithmus (Beispiel 6) eine Information zur weiteren Berechnung eines optimalen Zugriffspfads einer zusammengesetzten Bedingung zur Verfügung gestellt werden.

Beispiel 4 Suchbedingung (key < 10)

In der Abb. 21 wird die gleiche Logik, wie im Beispiel 3 gezeigt, noch einmal mit einer anderen Suchbedingung (age < 10) gezeigt. Die Beschreibung kann deshalb verkürzt erfolgen ohne auf die Berechnung der Mächtigkeit im Detail eingehen zu müssen.

Der Einstieg wieder über die Wurzel Pos 1 (40) erfüllt bereits die Bedingung. Damit gehört der Knoten selbst und der ganze rechte Teilbaum zur Treffermenge, weil dort nur Werte vorkommen können, die größer als die Wurzel Pos 1 (40) sein können. Deshalb muß nur noch im linken Pfad nach Knoten gesucht werden, die nicht der Bedingung entsprechen. Für den Knoten Pos 2 (20) gilt das gleiche, so daß auch diese Treffermenge identifiziert ist. Bei der Pos 3 (10) ist die Abbruchbedingung erfüllt, da das Suchargument (< 10) getroffen wurde. Es müssen jetzt ebenfalls alle Knoten des rechten Pfads dazu genommen werden mit Ausnahme des Knotens Pos 3 (10) selbst. Hätte die Bedingung (< =) gelautet, dann wäre auch dieser Knoten dabei gewesen.

Die Berechnung der Mächtigkeit der Treffermenge (M) erfolgt analog zu Beispiel 3. Der Wurzelknoten enthält die Mächtigkeit der ganzen Struktur (einschließlich der nicht eingezeichneten Selbst-Ringstrukturen aller Knoten). Die erste Subtraktion erfolgt bei Pos 3 (10), wobei dann im Anschluß nur noch die Mächtigkeit der rechten Struktur wieder dazu gezählt werden muß, die hier nur aus einem Knoten (11) besteht.

Beispiel 5 Suchbedingung (key between 24 and 54)

In der Abb. 22 wird eine Between-Logik gezeigt, die zwei Abstiege im Baum benötigt, um die Treffermenge zu ermitteln. Ein Between könnte auch in zwei elementare Bedingungen zerlegt werden (key <= 24 and key <= 54), aber so geht es eleganter. Auf eine detaillierte Erklärung der Arithmetik dazu kann verzichtet werden, weil sie in den Beispielen zuvor schon gezeigt wurde.

Der Einstieg in die Struktur erfolgt über die Wurzel (40). Da der Knoten innerhalb der Suchbedingung liegt, muß sowohl der linke Pfad mit der unteren Grenze (24) der Suchbedingung, als auch der rechte Pfad mit der oberen Grenze (54) der Suchbedingung durchlaufen werden. Die jeweilige Logik entspricht dabei der elementaren Logik aus den zuvor beschriebenen Beispielen.

Würde der Wurzelknoten außerhalb der Suchbedingung liegen, was beispielsweise der Fall wäre, wenn die Suchbedingung (between 54 and 56) sein würde, dann muß zuvor im Pfad des Baums in Richtung einer Grenze (entweder 54 oder 56) abgestiegen werden, bis ein Knoten innerhalb der Suchbedingung liegt. Das wäre der Fall beim Knoten (55). Danach kann der Teilbaum mit diesem Knoten als Wurzel genommen werden und mit dem in diesem Beispiel beschriebenen Algorithmus begonnen werden.

Beispiel 6 Optimierung des Zugriffspfads

Zum Abschluß soll am Beispiel einer komplexen Bedingung gezeigt werden, wie ein Optimierungsalgorithmus von der vorgestellten Datenstruktur profitiert und welche Rolle die Kennzahlen der Mächtigkeiten dabei spielen. Als Beispiel soll eine AND-Kette dienen:

key_1 < 28 and key_2 <= wert_2 and key_3 < wert_3

Um eine solche komplexe Bedingung effizient abarbeiten zu können, soll ein Optimierer wissen, welche Treffermenge sich bei jeder einzelnen Bedingung ergibt, bevor er mit der eigentlichen Auswertung des Ausdrucks beginnt. Damit kann er sich dann für die logische Bedingung entscheiden, die zur kleinsten Zwischenergebnismenge führt, um darauf die nächst kleinere Bedingung anzuwenden und so weiter.

Also ist es notwendig, zuerst alle drei Bedingungen auf ihre jeweilige Treffermenge zu untersuchen. Das kann mit jeweils einem einzigen Abstieg eines Pfads im betreffenden Baum erledigt werden, wie in den Beispielen zuvor gezeigt wurde. Dabei können aber gleichzeitig sogenannte Start-Adressen von Knoten (in sogenannten Guides) gespeichert werden, die auf ein Kopfelement von gültigen Teilbäumen des jeweiligen logischen Ausdrucks zeigen. Das hat den Vorteil, daß der Optimierer nachdem er Kenntnis über die günstigste Bedingung erlangt hat, nicht noch einmal den Baum untersuchen muß, sondern gleich auf gültigen Knoten operieren kann. Knoten, die nicht zur Treffermenge gehören müssen überhaupt nicht besucht werden. Folgendes Szenario soll das aber noch einmal in kleinen Schritten verdeutlichen:
Dazu kann die Abb. 17 im Rückblick benutzt werden, da die erste Bedingung der AND-Kette genau diesem Fall entspricht. Bei Knoten Pos 2 (20) ist die Suchbedingung (key_1 < 28) das erste Mal erfüllt. Neben dem Beginn der Berechnung der Kennzahl für die Mächtigkeit der gesamten Treffermenge, die im Beispiel 3 zur Ermittlung der Menge (M) führt, wird eine temporäre Instanz eines Objekts vom Typ Guide erzeugt, das die Adresse dieses Knotens speichert (Guide-Objekte sollen hier nicht ausführlicher erläutert werden). Dazu kann gleich noch ein Iterationswert It erzeugt werden, der sich wie in Abb. 23 gezeigt, berechnen läßt It entspricht immer der Anzahl aller gültigen Knoten (Treffer) eines Teilbaums (einschließlich aller Knoten jedes Selbst-Rings). Dieser Iterationswert ist später die Abbruchbedingung einer Schleife für einen Algorithmus zum Traversieren des Teilbaums einschließlich der Zwischenstops bei jedem Knoten im Baum zum Abarbeiten der Selbst-Ringe. Damit kann man sich beim Traversieren den ständigen Vergleich der Suchbedingung mit dem Wert eines Knotens sparen, denn genau nach dem Besuch aller gültigen Knoten ist die Abbruchbedingung erfüllt. It ist immer vom Typ Integer und damit in der Regel schneller als der Vergleich mit einem Wert des Knotens, der beispielsweise auch eine lange Zeichenkette sein kann

Aus der Abb. 19 Pos 4 (25) ist ersichtlich, das es noch einen weiteren Teilbaum gibt, der traversiert werden muß, wenn diese Bedingung (key_1 < 28) vom Optimierer später als erste genommen wird. Dazu wird ein weiterer Guide erzeugt, der genauso die Start-Adresse vom Knoten (25) speichert und den Iterationswert dazu, der diesmal genau x2 entspricht.

Bei sehr mächtigen Baumstrukturen können mehrere solche Teilbäume, die gültige Treffermengen beinhalten, während eines Abstiegs identifiziert werden. Für jedes Kopfelement eines solchen Teilbaums wird ein Guide erzeugt, der die entsprechende Start-Adresse und den Iterationswert enthält. Alle Guides bilden eine verkettete lineare Liste, die der jeweiligen Bedingung zugeordnet wird.

Nachdem alle Bedingungen der AND-Kette auf ihre Treffermenge (M) untersucht worden sind und der Optimierer die Bedingung mit der kleinsten Treffermenge ausgewählt hat, kann er jetzt die dazugehörige lineare Liste mit den Guides benutzen, um sofort die Teilbäume mit gültigen Knoten abzuarbeiten. Die anderen beiden linearen Listen mit den Guides wurden zwar vergebens erzeugt und werden verworfen, aber der Geschwindigkeitsvorteil, der sich durch die erste lineare Liste mit den Guides ergibt, rechtfertigt diesen geringfügigen Mehraufwand zum Merken aller Start-Adressen und der Iterationswerte auf jeden Fall.

Die Verarbeitung der nächsten Bedingung erfolgt im Anschluß direkt auf der erzeugten Zwischenergebnismenge. Dazu gibt es weitere Guides eines anderen Typs, die temporär jeweils auf den entsprechenden Anker eines InfoCourse zeigen, der zum Zwischenergebnis gehört. Dadurch ergibt sich dann eine verkürzte Verarbeitung der restliche AND-Kette direkt mit der Zwischenergebnismenge. Die temporären Guide-Datenstrukturen, die von der Komplexität in etwa noch einmal der gezeigten Struktur entsprechen, sollen aber nicht Gegenstand dieser Ausführungen sein.

Zusammenfassend kann noch angemerkt werden, daß es sich bei dieser Art der Optimierung immer um eine exakte Bestimmung des besten Zugriffspfads handelt und nicht um eine Wahrscheinlichkeit mit der ein guter Zugriff erfolgt. Damit unterscheidet sich ein Optimierer, der nach diesem gezeigten Prinzip arbeitet in der Qualität vom heutigen Stand der Technik, was sich letztendlich bei der Performance des Test-Systems auch deutlich zeigt.

Claims

1. Computersystem, aufweisend eine Einrichtung zum Speichern von Daten, wobei die Daten in einzelnen Datenfeldern enthalten sind, welche mittels einer Datenstruktur miteinander verknüpfbar sind, wobei die Datenstruktur eine Ringstruktur aufweist.

2. Datenstruktur, aufweisend Datenfaktor zum Speichern und Abfragen von Daten, wobei die Datenstruktur als Ringstruktur ausgebildet ist.

3. Computerprogramm-Produkt, enthaltend Programmcode zur Speicherung und Abfrage von Daten in einer Datenstruktur nach Anspruch 2.

4. Datenträger mit gespeichertem Programmcode zur Speicherung und Abfrage von Daten in einer Datenstruktur nach Anspruch 2.

5. Computerimplementiertes Verfahren zur Durchführung auf einem Computersystem nach Anspruch 1, aufweisend die Schritte:

a) Abspeichern von Daten in Datenfeldern
b) Abrufen von Daten aus Datenfeldern

wobei die Datenfelder mittels einer Datenstruktur miteinander verknüpft sind und die Datenstruktur als Ringstruktur ausgebildet ist.