DE19627472A1 - Datenbanksystem - Google Patents

Datenbanksystem

Info

Publication number
DE19627472A1
DE19627472A1 DE19627472A DE19627472A DE19627472A1 DE 19627472 A1 DE19627472 A1 DE 19627472A1 DE 19627472 A DE19627472 A DE 19627472A DE 19627472 A DE19627472 A DE 19627472A DE 19627472 A1 DE19627472 A1 DE 19627472A1
Authority
DE
Germany
Prior art keywords
data
field
record
database
stored
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE19627472A
Other languages
English (en)
Inventor
Gert J Reinhardt
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
SER SYSTEMS AG, 53577 NEUSTADT, DE
Original Assignee
SER SYSTEME AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by SER SYSTEME AG filed Critical SER SYSTEME AG
Priority to DE19627472A priority Critical patent/DE19627472A1/de
Priority to AU35386/97A priority patent/AU3538697A/en
Priority to DE59711376T priority patent/DE59711376D1/de
Priority to EP97931718A priority patent/EP0910829B1/de
Priority to US09/214,682 priority patent/US6772164B2/en
Priority to PCT/DE1997/001441 priority patent/WO1998001808A1/de
Publication of DE19627472A1 publication Critical patent/DE19627472A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22Indexing; Data structures therefor; Storage structures
    • G06F16/221Column-oriented storage; Management thereof
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99931Database or file accessing
    • Y10S707/99932Access augmentation or optimizing
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99941Database schema or data structure
    • Y10S707/99942Manipulating data structure, e.g. compression, compaction, compilation
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99941Database schema or data structure
    • Y10S707/99943Generating database or data structure, e.g. via user interface

Description

Die Erfindung betrifft ein Datenbanksystem, insbesondere ein Datenbanksystem, bei dem eine Datenbasis, die aus einer Vielzahl von Datensätzen besteht, gespeichert wird, ein Verfahren zur Speicherung, Änderung und Anzeige der Datenbasis, sowie ein Verfahren zur Suche in der bzw. zum Zugriff auf die Datenbasis.
Ein Datenbanksystem besteht in der Regel aus einem Datenbestand der sogenannten Datenbasis, die in einem maschinenlesbaren Speicher abgespeichert wird, sowie aus einem EDV-System, auf dem eines oder mehrere Anwendungsprogramme ablaufen, um über ein Kontrollprogramm, das sogenannte Datenbank-Management-System, auf die Datenbasis zuzugreifen, Bestandteile der Datenbasis anzuzeigen, nach Bestandteilen zu suchen, sowie um die Datenbasis zu modifizieren, neue Daten einzugeben, usw.
Die Interpretation der Daten in der Datenbasis erfolgt über die Metadaten, "Daten über die Daten", die das Datenbank-Management-System gesondert benötigt bzw. abspeichert. Die Metadaten sind also Beschreibungsdaten zu den Feldern des Datensatzes und aller sonstiger Attribute des Datenbanksystems.
Bei bekannten Datenbanksystemen wird dabei die Datenbasis in strukturierter Form abgespeichert, gemäß dem Stand der Technik in Tabellenform. Die Datenbasis besteht dabei aus einzelnen Datensätzen, die wiederum aus einzelnen Datenfeldern bestehen. Speicherung in strukturierter Form ist immer dann gegeben, wenn sich die Informationen in Datensätze bestehend aus mehreren Feldern unterteilen lassen, wobei die Bedeutung des n-ten Feldes in jedem Datensatz identisch ist. Die Inhalte der Felder können unterschiedlich sein.
Ein Beispiel für einen Teil einer solchen strukturierten Datenbasis in Tabellenform ist in Fig. 2 dargestellt.
Die einzelnen Datensätze sind die Zeilen der Tabellen, in denen jeweils in einzelnen Datenfeldern Informationen über Beleg-Nr., Datum, Vorname Nachname, und Belegart enthalten sind. Das letzte Feld jedes Datensatzes enthält eine Satz-Nr., d. h. eine Identifikationsnummer zur eindeutigen Identifikation des Datensatzes. Alle Datensätze weisen nicht nur die gleiche Anzahl von Datenfeldern auf; die Datenfelder jedes Datensatzes lassen sich auch in eine allen Datensätzen gemeinsame Struktur einordnen.
So enthält jeder Datensatz ein Feld mit der Deskription bzw. Bezeichnung Beleg-Nr., eines mit dem Datum, eines mit dem Vornamen, etc. Die individuellen Datensätze sind in einer Tabelle zusammengefaßt, deren Spalten durch eine gemeinsame Deskription ihres Inhalts gekennzeichnet sind. Die Struktur der Tabelle ist also vorgegeben, und zwar durch die Deskriptionen, die im Tabellenkopf der Tabelle aus Fig. 2 vorhanden sind. Die Felder des Tabellenkopfes enthalten weitere nicht dargestellte Informationen über den Inhalt der einzelnen Spalten der Tabelle, sogenannte Metadaten für die jeweiligen Felder der Datensätze der Tabelle. Grundsätzlich werden bei herkömmlichen Datenbanksystemen Daten der Datenbasis in derart strukturierter Form abgespeichert, d. h. es wird eine Tabellenstruktur vorgegeben, der die abzuspeichernden Datensätze bezüglich Feldanzahl und Deskription des Feldinhalts, aber auch bezüglich des Datentyps bzw. der Datenstruktur des Feldinhalts, entsprechen müssen.
Durch die vorgegebenen Struktur, mit der die Daten abgespeichert werden, ist es bei herkömmlichen Datenbanksystemen im Falle einer Struktur gemäß Fig. 2 nicht ohne weiteres möglich, zusätzliche Informationen, die nicht dieser Struktur entsprechen, abzuspeichern. Sollen z. B. für lediglich einzelne Datensätze zusätzliche Informationen abgespeichert werden, so muß die Struktur der gesamten abgespeicherten Daten geändert werden. Ein Beispiel hierfür ist in Fig. 3 dargestellt.
Zur zusätzlichen Abspeicherung eines Abteilungskennzeichens muß selbst wenn diese Information lediglich für einzelne Datensätze abgespeichert werden soll, eine zusätzliche Spalte "Abteilung" in die Tabelle eingefügt werden.
Bei herkömmlichen Datenbanksystemen wird also eine Struktur vorgegeben, an die die einzelnen Datensätze gebunden sind, und die individuellen Datensätze werden dann zu einer Tabelle wie in Fig. 2 oder in Fig. 3 gezeigt zusammengefaßt. Die Feldinhalte der einzelnen Datensätze sind damit durch die Gesamtstruktur der Tabelle, die aus den Datensätzen gebildet wird, bezüglich ihrer Deskription, aber auch bezüglich ihres Datenformats vorgegeben. Die Inhalte der einzelnen Felder der Datensätze können bezüglich ihrer Deskription, ihres Datenformats, also bezüglich ihrer Metadaten, nur durch eine Änderung der Struktur der Gesamttabelle geändert werden. Eine solche Änderung in der Struktur der Gesamttabelle, etwa die Änderung der Tabelle aus Fig. 2 in die aus Fig. 3, beeinflußt jedoch die Struktur sämtlicher auch der bereits vorhandenen Datensätze.
Die zu einer Tabelle zusammengefaßten Datensätze werden als Datenbanktabelle bezeichnet, die Summe der Metadaten aller Datenbanktabellen der Datenbasis, die im einzelnen unterschiedlich sein können, bilden das sogenannte Datenmodell des Datenbanksystems.
Diese Art von strukturierter Abspeicherung der Daten bedeutet, daß für jede Ablage von Datensätzen vorausgesetzt wird, daß die Datensätze, die abzulegen bzw. abzuspeichern sind, in der Struktur zumindest mit einer Teilstruktur der Datenbank übereinstimmen.
Soll also ein Datensatz abgespeichert werden, der in der Struktur nicht den vorhandenen Datenstrukturen bzw. Teilen davon entspricht, so muß die Datenbank um das neue Strukturelement (Feld/Felder) erweitert werden, bevor der Datensatz gespeichert werden kann.
Die aus diesen Tabellen resultierende Datenstruktur wird nicht nur in der Datenbasis gebildet, sondern auch im Datenbank-Management-System und in den Anwendungsprogrammen abgebildet. Daraus resultieren folgende grundsätzliche Probleme.
Änderungsanforderungen bezüglich der Datenstrukturänderungen kommen von den Anwendern und werden damit zuerst an die Anwendungs-Software gestellt. Daraus ergibt sich jedoch dann auch eine Änderung des Datenmodells der Datenbank. Des weiteren müssen die Änderungen der Anforderungen vom Anwender definiert werden und haben bei der Realisierung Änderungen im Datenbank-Management-System zur Folge, da dieses an die Struktur der Datenbasis angepaßt werden muß. Dadurch degenerieren die Datenstrukturen im Lauf der Zeit. Z.B. kann es vorkommen, daß beim Einfügen neuer Spalten nicht alle Felder der Spalte beschrieben werden, wodurch letztlich einige Felder der Gesamttabelle, die aus den einzelnen Datensätzen gebildet wird leer bleiben.
Ein besonderes Problem stellt die Speicherung von Datensätzen mit einer neuen Datensatz-Struktur dar. Diese Datensatz-Struktur muß vom Anwender definiert werden. Auch hierfür sind Änderungen im Datenbank-Management- System und in den Anwendungsprogrammen nötig.
Aus der strukturierten Speicherung der Daten in Tabellenform ergibt sich also ein hoher Aufwand für den Systemadministrator als Resultat der Anforderungen, die von den Anwendern der Datenbank gestellt werden. Die Struktur der Datenbasis muß ständig geändert und angepaßt werden.
Bei herkömmlichen Datenbanksystemen sind die Datensätze in Tabellenform geordnet. Ein Datensatz selbst besteht dabei aus mehreren Datenfeldern. Jedes Datenfeld besteht aus einem Deskriptor und einem Feldwert (Feldinhalt). Der Deskriptor beschreibt hierbei den Feldwert. Der Deskriptor beschreibt die Felder nach der Art bzw. der Bedeutung ihres Feldwertes. So haben z. B. alle Datenfelder, deren Feldinhalt aus einer Körpergröße besteht, denselben Deskriptor. Aus diesen strukturierten Datensätzen wird dann die in Tabellenform strukturierte Datenbasis modelliert. Diese herkömmliche Vorgehensweise setzt gesicherte oder hypothetische Informationen über die Struktur der zu speichernden Datensätze voraus. Diese Informationen werden benötigt, um das Datenmodell zu definieren, das die Speicherung aller Datensätze ermöglicht, die aufgrund der vorliegenden Informationen potentiell gespeichert werden müssen. Es werden dann zur Speicherung der in der Regel inhomogenen Gesamtmenge aller erwartenden Datensätze Datenbanktabellen definiert, wobei jede Datenbanktabelle nur Datensätze gleicher Struktur speichert. Die Summe aller Definitionen aller benötigten Datenbanktabellen bildet das abstrakte Datenmodell des Datenbanksystems.
Es versteht sich, daß das Datenmodell jeder Datenbanktabelle alle Datenfelder aller potentiell in dieser Datenbanktabelle zu speichernden Datensätze insbesondere hinsichtlich ihres Datenformats berücksichtigen muß. Hierzu werden für jeden potentiell in einem Datensatz vorkommenden Deskriptor die Attribute beschrieben. Attribute beschreiben dabei das Datenformat und die Verwendung (z. B. "Indizierung" oder "keine Indizierung") des Feldwertes. Damit ist die so definierte Datenbanktabelle in der Lage, Datensätze zu speichern, die der vordefinierten Struktur entsprechen. Dieses Datenmodell kann dann visualisiert werden, indem jeder Spalte der Datenbanktabelle ein Deskriptor zugeordnet wird. Ein Datensatz entspricht dann einer Zeile in dieser Datenbanktabelle. In jeder Spalte wird der dem Deskriptor zugeordnete Feldwert eingetragen, sofern der Datensatz einen entsprechenden Feldwert enthält. Nicht in jedem Datensatz muß notwendigerweise für jeden Deskriptor ein Feldwert existieren. Dies führt dann zu leer bleibenden Datenfeldern in der Datenbanktabelle.
Diese Speicherung von Datensätzen in einem so aufgebauten Datenbanksystem hat den Nachteil, daß zunächst ein Datenmodell definiert werden muß, das jeden potentiell in einem Datensatz vorkommenden Deskriptor sowie dessen Datenformat berücksichtigt. Ein solches Datenmodell kann jedoch nur erstellt werden, wenn vollständige und korrekte Informationen über die Struktur der erwarteten Datensätze vorliegen. Diese Vorbedingung kann nur selten erfüllt werden.
Die bei einer Problemanalyse erhobenen Informationen können in der Regel die tatsächlich zu speichernden Datensätze nicht vollständig beschreiben. Durch die Definition eines Datenmodells muß abstrahiert werden, d. h. es werden vereinfachende Annahmen getroffen, die möglicherweise zu einem unvollständigen Datenmodell führen. Dieses unvollständige Datenmodell muß dann unter Umständen später modifiziert, erweitert, vereinfacht oder auf eine sonstige Weise geändert werden. Weiterhin werden bei einer Problemanalyse nicht notwendigerweise alle das Datenmodell beeinflussenden Aspekte erfaßt. Auch hierdurch entsteht ein unvollständiges Datenmodell.
Eine weitere Ursache für ein unvollständiges Datenmodell betrifft die notwendigerweise statische Natur des Datenmodells selbst. Liegen zu einem bestimmten Zeitpunkt vollständige Informationen über die Struktur der zu erwartenden Datensätze vor, dann kann ein vollständiges Datenmodell entwickelt werden. Häufig ändern sich jedoch die dem Datenmodell zugrundeliegenden Informationen im Laufe der Zeit, wodurch dann wieder ein unvollständiges Datenmodell entsteht.
Die sich aus einem unvollständigen Datenmodell ergebenden Systemmängel resultieren in Änderungsanforderungen der Anwender. Diese Änderungsanforderungen der Anwender haben dann eine vom Systemadministrator/programmierer zu leistende Nachbesserung des Datenmodells zur Folge. Dieses nachgebesserte Datenmodell ist dann unter Umständen wieder unvollständig, so daß wieder nachgebessert werden muß.
Ein bisher verfolgter Ansatz, den sich ergebenden Aufwand zu minimieren, ist die Einführung einer möglichst komfortablen und mächtigen Entwicklungsumgebung (z. B. 4GL-Sprache). Änderungen im Datenbank- Management-System können dann mit geringem Aufwand durchgeführt werden.
Das grundsätzliche Problem der bisherigen Lösungsansätze bleibt jedoch gleich: Es muß ein statisches Datenmodell definiert werden, das im Laufe der Zeit durch sich immer wiederholende Änderungen an die Anforderungen der Anwender angepaßt werden muß. Diese sich wiederholenden Änderungen führen langfristig zu einer Degeneration des Datenmodells und sind vom Standpunkt der Systempflege aus betrachtet zwar automatisierbar, jedoch nicht geeignet, das Problem an sich zu beheben.
Es ist daher eine Aufgabe der vorliegenden Erfindung, ein Verfahren zu schaffen, mit dem die Daten der Datenbasis optimal gespeichert werden können. Weiterhin soll auf diese Datenbasis schnell zugegriffen werden können, und die Daten der Datenbasis sollen angezeigt und gegebenenfalls auf einfache und flexible Art und Weise modifiziert werden können.
Der Kern der Erfindung besteht nun darin, daß bei der Speicherung einer Datenbasis auf die Bildung eines strukturierten Datenmodells für die Datenbasis verzichtet wird, und daß statt dessen die Datenbasis auf eine Art und Weise abgespeichert wird, die die Definition eines Datenmodells für den Zweck der Speicherung in dem Datenbanksystem nicht mehr erfordert. Weder manuell, noch durch einen automatisch ablaufenden Algorithmus werden Datenmodelle für das Datenbanksystem erstellt.
Dies geschieht dadurch, daß bei jeder Speicherung eines Datensatzes vollständige Informationen über die Struktur des Datensatzes mit dem Datensatz zusammen abgespeichert werden. Das heißt, jeder Datensatz enthält zusätzlich zu den Nutzdaten eine vollständige Beschreibung der Struktur des Datensatzes. Damit wird die Speicherung des Datensatzes unabhängig von einem übergeordneten Datenmodell, da der Datensatz nicht an die Struktur eines bestehenden bzw. vorgegebenen Datenmodells angepaßt sein muß. Jeder Datensatz enthält seine vollständigen Metadaten, die eine vollständige Beschreibung des Datensatzes beinhalten. Dadurch entfallen die Beschränkungen, die sich dadurch ergeben, daß beim herkömmlichen Datenbanksystem gleichartige Datensätze zu Tabellen zusammengefaßt werden wodurch dann ein Datenmodell vorgegeben wurde, an das neu einzugebende Datensätze angepaßt sein müssen. Jeder Datensatz ist bezüglich seiner Struktur völlig unabhängig von den anderen abgespeicherten Datensätzen und die Definition eines übergeordneten Datenmodells entfällt damit.
Das Fehlen eines übergeordneten Datenmodells, bei dem mehrere Datensätze gleicher Struktur zusammengefaßt sind, führt dazu, daß der Verwaltungsaufwand für die abgespeicherten Daten deutlich reduziert wird. So muß das Datenbank-Management-System nicht ein übergeordnetes Datenmodell abbilden und muß dementsprechend nicht an ein geändertes übergeordnetes Datenmodell angepaßt werden, falls Änderungen bzw. neue Abspeicherungen neuer Strukturen vorgenommen wurden. Bei der erfindungsgemäßen Datenbank gibt es keine übergeordnete Struktur mit mehreren zusammengefaßten Datensätzen, sondern lediglich eine Minimalstruktur, die aus dem individuellen Datensatz selbst besteht, der gleichzeitig eine vollständige Beschreibung (Metadaten) dieses Datensatzes bzw. seiner Struktur enthält. Jeder Datensatz besteht aus einer beliebigen Anzahl von Feldern, wobei nun allerdings im Gegensatz zur herkömmlichen Datenbank jedes Feld eines Datensatzes der erfindungsgemäßen Datenbank zusätzlich zu den ggf. mehreren Feldinhalten eine vollständige Beschreibung der Feldinhalte (Metadaten) enthält.
Jedes Feld kann mehrere Feldinhalte aufweisen, wobei dann die Feldbeschreibung sämtliche Feldinhalte hinsichtlich ihres Formats vollständig beschreibt. Insbesondere kann ein erster Feldinhalt aus Nutzdaten bestehen, während ein zweiter Feldinhalt desselben Feldes aus einem Deskriptor besteht, der die Nutzdaten hinsichtlich ihrer Bedeutung kennzeichnet. Die Feldbeschreibung enthält dann die Attribute sowohl für die Nutzdaten als auch für den Deskriptor, also für beide Feldinhalte. Die Attribute beschreiben dabei die einzelnen Feldinhalte bezüglich ihrer Datenstruktur, d. h. z. B. bezüglich ihres Datentyps und ihrer Länge in Bytes. Sie können auch festlegen, ob es sich um einen Deskriptor oder um Nutzdaten handelt. Grundsätzlich ist die Anzahl der Feldinhalte eines Feldes beliebig, entscheidend ist die Tatsache, daß die Feldbeschreibung die Attribute für alle Feldinhalte enthält. Welcher von ggf. mehreren Feldinhalten nun letzlich aus Nutzdaten besteht und welcher aus einem Deskriptor für einen bzw. mehrere aus Nutzdaten bestehende Feldinhalte, kann dabei ebenfalls in der Beschreibung festgelegt werden. Diese Frage kann jedoch auch einfach durch Konvention bezüglich der Reihenfolge festgelegt werden, etwa in der Art, daß jeder zweite Feldinhalt immer aus einem Deskriptor für den vor ihm angeordneten Feldinhalt besteht.
Es versteht sich, daß einzelne Feldinhalte auch leer bleiben können obwohl sie in der Feldbeschreibung als Teil des Feldes definiert sind. Grundsätzlich sind bei der vorliegenden Erfindung die Feldinhalte eines Feldes bezüglich ihrer Anzahl, noch bezüglich ihres Formats durch eine übergeordnete Struktur festgelegt. Format und Anzahl der Feldinhalte wie auch die Frage, ob es sich bei den Feldinhalten um Nutzdaten oder um Deskriptoren handelt, können für jedes Feld jedes Datensatzes in beliebiger Weise frei gewählt werden, da die Feldbeschreibung das Feld bezüglich dieser Festlegungen durch die in der Feldbeschreibung enthaltenen Attribute vollständig beschreibt. Damit ergibt sich eine Symmetrie oder Dualität zwischen Deskriptoren und Nutzdaten beim Aufbau eines Datenfeldes und somit auch beim Aufbau eines Datensatzes. Diese Dualität oder Symmetrie kann sich fortsetzen, indem Nutzdaten und Deskriptoren auch in der weiteren Verarbeitung der Datensätze bzw. der einzelnen Datenfelder, d. h. bei der Indizierung von, bei der Suche nach, beim Zugriff auf Felder oder Datensätze, bei der Präsentation und bei der Modifikation von Feldern oder Datensätzen gleich behandelt werden können. In diese Gleichbehandlung können selbst Teile der Feldbeschreibung miteinbezogen werden, die dann in ähnlicher Weise wie die Feldinhalte verarbeitet werden.
Bei der erfindungsgemäßen Datenbank gibt es keine übergeordnete Struktur zur Speicherung gleichartiger Datensätze, sondern lediglich eine nicht weiter zu vereinfachende Minimalstruktur zur Speicherung der Felder, bestehend aus den Metadaten des Feldes und aus den Feldinhalten, die jeweils Nutzdaten oder Deskriptoren sein können. Jeder Datensatz besteht aus einer beliebigen Anzahl von Feldern. Die Deskriptoren der Felder eines Datensatzes müssen nicht notwendigerweise eindeutig sein. Mehrfachnennungen können in der erfindungsgemäßen Datenbank einfach abgebildet werden, indem mehrere Felder mit gleichem Deskriptor in einem Datensatz gespeichert werden.
Ein Deskriptor gibt einem zugehörigen, aus Nutzdaten bestehenden Feldinhalt eine semantische Bedeutung, d. h. er kennzeichnet den aus Nutzdaten bestehenden Feldinhalt hinsichtlich seiner Bedeutung. Bei der erfindungsgemäßen Datenbank wird jedoch der aus einem Deskriptor bestehende Feldinhalt im Prinzip genauso behandelt wie der aus Nutzdaten bestehende Feldinhalt, d. h. beide können aus beliebigen Bitfolgen beliebigen Formats bestehen, da ihr Format bzw. ihre Struktur in der jeweiligen Feldbeschreibung definiert ist. Für das erfindungsgemäße Datenbanksystem spielt es bei der Verarbeitung von Feldinhalten zunächst keine Rolle, ob es sich bei dem Feldinhalt um Nutzdaten, etwa um eine Bitfolge zur Darstellung eines Bildes, oder um einen Deskriptor handelt, welcher die Bitfolge zur Darstellung eines Bildes hinsichtlich ihrer Bedeutung als "Bild" kennzeichnet. Sowohl der Nutzdatenwert als auch der Deskriptor können im Prinzip aus beliebigen Bitfolgen bestehen. Erst wenn die Daten dem Benutzer angezeigt werden sollen, muß das Anwendungsprogramm zwischen Deskriptor und Nutzdatenwert unterscheiden, damit der Benutzer erkennt, ob es sich um einen reinen Nutzdatenwert handelt, oder um Informationen, welche einen Nutzdatenwert (bzw. eine Nutzdatenbitfolge) hinsichtlich ihrer Bedeutung kennzeichnen. Es ist deshalb zwar erforderlich, daß auf irgendeine Weise festgelegt wird, ob es sich bei einem Feldinhalt um reine Nutzdaten oder um einen Deskriptor handelt, abgesehen von dieser Festlegung ist jedoch jeder Feldinhalt in seiner Struktur beliebig und muß lediglich durch die Feldbeschreibung in ausreichender Weise definiert werden.
Bei der Verarbeitung der erfindungsgemäß abgespeicherten Datensätze ist es also weitgehend gleichgültig, ob es sich bei den zu verarbeitenden Feldinhalten um Nutzdaten handelt, oder um Deskriptoren, welche andere Feldinhalte hinsichtlich ihrer Bedeutung kennzeichnen. Alle Feldinhalte können bei dem erfindungsgemäßen Datenbanksystem im wesentlichen gleich verarbeitet werden, und insbesondere auf gleiche Weise indiziert werden.
Auch hierarchische Strukturen in einem Datensatz können abgebildet werden, indem in einem Datensatz sowohl Felder als auch Subdatensätze eingestellt werden. Die Subdatensätze können ihrerseits wieder aus Feldern und weiteren Subdatensätzen bestehen. Auf der untersten Hierarchieebene besteht jedoch ein Subdatensatz ausschließlich aus Feldern. Damit besteht ein hierarchischer Datensatz letztendlich nur aus Feldern, die in der nicht weiter zu vereinfachenden Minimalstruktur (der erfindungsgemäßen Datenbank) gespeichert werden können.
Die Speicherung der in einem Datensatz enthaltenen Felder erfolgt für die zum Index gehörenden Felder zweifach. Zunächst wird der Datensatz als Ganzes in einem strukturlosen Speicher (dem Datensatzbereich) unter einer eindeutigen Datensatznummer gespeichert. Ein im Datensatzbereich gespeicherter Datensatz enthält damit sowohl die Metadaten als auch die Feldinhalte, welche Nutzdaten, Deskriptoren, oder Deskriptoren von Deskriptoren sein können. Alle oder ausgewählte Felder werden zusätzlich in einem der universellen Minimalstruktur entsprechenden Speicher (Indexbereich) gespeichert. Die Minimalstruktur besteht aus dem Deskriptor, dem Nutzdatenwert, der Satz-Nr. (über die der gesamte Datensatz referierbar ist, bzw. die Felder mit gleicher Satz-Nr. im Index zusammengeführt werden können), sowie einem Kennzeichen für den Zugriffsschutz (UIP genannt).
Der Indexbereich dient hierbei als Zugriffspfad auf den Datensatzbereich, indem der vollständige Datensatz gespeichert ist. Im Indexbereich müssen deshalb nicht notwendigerweise alle Informationen gespeichert werden, sondern nur die Informationen, die für den Zugriff auf den Datensatzbereich erforderlich sind. Insbesondere müssen nicht alle im Deskriptor enthaltenen Informationen in den Indexbereich eingestellt werden.
Um einen schnellen Zugriff auf den Datenbereich zu ermöglichen, ist der Indexbereich meist nach dem Nutzdatenwert sortiert. Es können jedoch zusätzliche Sortierungen sinnvoll sein, etwa nach Teilen des Deskriptors. Die erfindungsgemäße Datenbank ermöglicht dem entsprechend nicht nur einen Zugriff über die Nutzdatenwerte, sondern auch über die Deskriptoren auf die Datensätze.
Die in der universellen Minimalstruktur eines Feldes enthaltene Dualität von Nutzdatenwert und Deskriptor wird damit auch für den Zugriff auf die gespeicherten Datensätze genutzt.
In einer weiteren speziellen Ausführungsform kann die aus Datensatzbereich und Indexbereich bestehende Datenbasis in Unterdatenbestände aufgeteilt werden, um die Verwaltung des gegebenenfalls sehr großen Datenbestandes zu vereinfachen. Eine solche Aufteilung kann aufgrund des Feldinhaltes spezieller Felder erfolgen.
In einer weiteren speziellen Ausführungsform erfolgt die Unterteilung der Datenbasis gemäß dem Erstellungszeitpunkt eines Datensatzes. Damit kann eine zeitlich endlos wachsende Datenbasis realisiert werden.
In einer weiteren speziellen Ausführungsform enthält die Feldbeschreibung Informationen über den Datentyp, die Länge der Daten sowie darüber, ob es sich bei dem betreffenden Feldinhalt um Nutzdaten oder um einen Deskriptor handelt. Die dabei pro Feld abgespeicherten Attribute beziehen sich sowohl auf die Feldinhalte bestehend aus Nutzdaten als auch auf die aus Deskriptoren bestehenden Feldinhalte. Damit ist es insbesondere möglich, daß die Felddeskriptionen auch wie Nutzdaten interpretiert werden können. Dieser Datensatz wird dann als Ganzes unter einer Datensatznummer in einem Speicher abgespeichert, wobei die Datensatznummer ein ausgezeichneter Feldinhalt eines Feldes des Datensatzes ist, und dieser Feldinhalt dadurch ausgezeichnet ist, daß die Deskription "Datensatznummer" nur für ein einziges Feld in dem Datensatz vorkommt.
Die Feldbeschreibung kann gegebenenfalls noch weitere Informationen enthalten, etwa über den Schutzstatus sowohl der Nutzdaten als auch der Deskriptoren, d. h. über die Zugriffsrechte auf diese Daten. Die Nutzdaten der einzelnen Felder der Datensätze werden dann zusammen mit der Datensatznummer und dem jeweiligen Deskriptor, gegebenenfalls noch mit weiteren zusätzlichen Informationen wie dem Schutzstatus als Tupel in einer einzigen logischen Liste gespeichert. Diese logische Liste wird nach mindestens einem Kriterium sortiert und dient dann als Gesamt-Index für den Zugriff auf die Sätze der Datenbank. Dieser Gesamt-Index wird dabei über mindestens die aus Nutzdaten bestehenden Feldinhalte, gegebenenfalls zusätzlich über die Deskriptoren indiziert. Über diesen einfach oder zweifach indizierten Gesamt-Index wird dann der Zugriff auf bzw. die Suche nach einzelnen Nutzdaten bzw. Deskriptoren ermöglicht. Die einfache oder zweifache Indizierung der Liste kann auch für weitere Informationen erweitert werden, indem Teile der Feldbeschreibungen (z. B. der Datentyp) auch indiziert werden, so daß dieser auch als direktes Zugriffskriterium zur Verfügung steht. Die Abspeicherung von Informationen über den Schutzstatus einzelner Felder (UIP User Information Protection) ermöglicht dabei den Schutz einzelner Felder (Nutzdaten und Deskriptor) vor dem Zugriff durch nicht zugriffsberechtigte Benutzer bereits auf der Feld- bzw. Deskriptor-Ebene.
In einer weiteren speziellen Ausführungsform kann der indizierte Gesamt-Index in Teil-Indices aufgeteilt werden. Dadurch wird eine Aufteilung des gegebenenfalls sehr großen Datenbestandes in leichter zu verwaltende Unterdatenbestände möglich, die eine externe Bezeichnung erhalten können.
In einer weiteren speziellen Ausführungsform erfolgt die Unterteilung des Gesamt-Index in Teil-Indices gemäß dem Zeitraum der Erstellung und/oder Nutzung durch den Anwender, die gegebenenfalls in den Informationen über den Schutzstatus als Teil der Feldbeschreibung mit abgespeichert wird.
Durch das Indizieren nicht nur der aus Nutzdaten bestehenden Feldinhalte, sondern gegebenenfalls auch der Deskriptoren und/oder Teilen der Feldbeschreibung in der linearen Liste ermöglicht die erfindungsgemäße Datenbank die Präsentation der und den Zugriff auf bzw. die Suche nach den Feldbeschreibungen auf dieselbe Weise wie für die Nutzdaten und die Deskriptoren.
Erfindungsgemäß wird also jeder Datensatz einzeln zusammen mit Informationen über seine Struktur abgespeichert. Zusätzlich werden ausgezeichnete (ggf. auch alle) Felder des so abgespeicherten Datensatzes in einer Liste indiziert. Es erfolgt also eine teilweise redundante Abspeicherung der Daten, einmal als gesamter strukturierter Datensatz, und ein zweitesmal als einzelne Felder (auszugsweise oder vollständig) in der indizierten Liste. Bei der zweiten Abspeicherung der Felder des Datensatzes in einer Liste kann durch die Feldbeschreibung festgelegt werden, welche Felder, welche Feldinhalte, ggf. auch welche Teile der Feldbeschreibung indiziert werden sollen. Diese Festlegungen sind dabei ebenfalls in der Feldbeschreibung abgespeichert.
Die Tatsache, daß die strukturierten Datensätze ebenfalls abgespeichert werden, heißt jedoch nicht, daß ein Datenmodell gebildet werden muß. Jeder strukturierte Datensatz wird für sich, unabhängig von den zusätzlich in der Datenbasis vorhandenen Datensätzen, abgespeichert. Damit kann jeder Datensatz Felder mit Daten beliebigen Formats enthalten, da er von den anderen Datensätzen unabhängig ist.
Die vorliegende Erfindung wird nachfolgend unter Bezugnahme auf die Zeichnungen anhand von mehreren Ausführungsbeispielen im Detail beschrieben. Es zeigen:
Fig. 1 eine allgemeine Darstellung eines Datenbanksystems;
Fig. 2 eine Datenbanktabelle einer konventionellen Datenbank;
Fig. 3 eine modifizierte Datenbanktabelle einer konventionellen Datenbank;
Fig. 4a einen Datensatz beliebiger Struktur, wie er in einer Datenbank gemäß der vorliegenden Erfindung abgespeichert wird;
Fig. 4b eine Datenbanktabelle beliebiger Struktur, wie sie sich aus den Datensätzen gemäß Fig. 4a ergibt;
Fig. 5a und 5b die Linearisierung einer Datenbanktabelle einer Datenbank gemäß der vorliegenden Erfindung; wobei in Fig. 5a eine Datenbanktabelle und in Fig. 5b ein Gesamt-Index dargestellt sind;
Fig. 6 eine Datenbanktabelle einer konventionellen Datenbank;
Fig. 7 eine Gesamt-Index einer Datenbank gemäß der vorliegenden Erfindung;
Fig. 8 eine Eingabemaske zur Durchführung einer Recherche in einer Datenbank gemäß der vorliegenden Erfindung;
Fig. 9 ein Resultat einer Recherche in einer Datenbank gemäß der vorliegenden Erfindung für eine Suche ohne Angabe eines Deskriptors;
Fig. 10 ein Resultat einer Recherche in einer Datenbank gemäß der vorliegenden Erfindung bei einer Recherche mit Angabe eines Deskriptors;
Fig. 11 die Unterteilung des Gesamt-Index in Teil-Indices.
In Fig. 1 ist ein Datenbanksystem schematisch dargestellt, das mittels einer EDV-Anlage 100 realisiert ist. Hierzu ist in einem maschinenlesbaren Speicher 110 eine Datenbasis 120, in der die Daten abgelegt werden, abgespeichert, und verschiedene Anwendungsprogramme 140 können über ein Kontrollprogramm 130, das Datenbank-Management-System, auf die Datenbasis 120 zugreifen. Das Kontrollprogramm 130 und die Anwendungsprogramme 140 laufen dabei auf einer oder mehreren EDV-Anlagen 100 ab. Das Auffinden, Speichern, Modifizieren und Suchen von Daten der Datenbasis geschieht dabei durch die Anwendungsprogramme 140 über das Kontrollprogramm 130. Der Benutzer kann mittels eines Eingabegeräts 150 oder eines Ausgabegeräts 160 auf die Daten zugreifen, Daten eingeben oder die Ausgabe von Daten veranlassen. Die eigentliche Datenbank besteht dabei aus der Datenbasis 120 und dem Datenbank-Management-System 130. Ein übergeordnetes Datenmodell 170 ist durch Metadaten vorgegeben und gibt eine Struktur für die in der Datenbasis abgespeicherten Daten vor.
Die Daten der Datenbasis sind in Datensätze untergliedert, wobei die einzelnen Datensätze jeweils aus einer beliebigen Anzahl von Feldern bestehen. In dieser Form werden die Datensätze in dem Speicher 110 abgespeichert, der ein beliebiger maschinenlesbarer Speicher sein kann.
Erfindungsgemäß wird in einem ersten Ausführungsbeispiel jeder Datensatz in einer Form, wie sie in Fig. 4a dargestellt ist, abgespeichert.
Jeder abgespeicherte oder abzuspeichernde Datensatz 400 besteht dabei aus einer beliebigen Anzahl von Feldern Feld 1, Feld 2, . . . , Feld n, die mit 410 gekennzeichnet sind und jeweils in einen Deskriptor als Feldinhalt 410a, eine Feldbeschreibung 410b, die Attribute enthalten kann, und einen Feldinhalt 410c als Nutzdaten unterteilt sind. Die Feldbeschreibung 410b enthält Informationen über den Datentyp, die Länge der Daten und gegebenenfalls die UIP (User Information Protection). Damit ist jeder Datensatz 400 durch die mit ihm bzw. mit jedem Feld 410 abgespeicherte Beschreibung vollständig definiert und von den anderen abgespeicherten bzw. abzuspeichernden Datensätzen in seiner Struktur völlig unabhängig. Im Extremfall kann somit jeder Satz der in der Datenbank abgespeicherten Datensätze unterschiedlich lang sein und unterschiedliche Feldbeschreibungen/Deskriptoren haben. So kann z. B. ein Datensatz als Nutzdaten des Feldes 2 Bilddaten enthalten, welche durch die Feldbeschreibung und den Deskriptor des Feldes 2 aus Fig. 4a genauer definiert werden, während ein anderen Datensatz im Feld 2 z. B. Textdaten, Zahlenangaben, oder ähnliches als Nutzdaten enthalten kann, was ebenfalls wiederum durch die Feldbeschreibung und ggf. den Deskriptor des entsprechenden Feldes 2 definiert ist und durch den Deskriptor hinsichtlich der Bedeutung beschrieben wird. Es entfällt damit ein übergeordnetes Datenmodell, bei dem Datensätze gleicher Struktur zusammengefaßt werden.
Entscheidend ist, daß sowohl der als Deskriptor dienende Feldinhalt 410a als auch der aus Nutzdaten bestehende Feldinhalt 410c nicht durch eine übergeordnete Struktur festgelegt wird, sondern lediglich durch die Attribute, die in der Feldbeschreibung 410b enthalten sind. Daraus ergibt sich eine gewisse Dualität zwischen Feldinhalten mit Deskriptorcharakter und aus Nutzdaten bestehenden Feldinhalten, d. h. bei der weiteren Behandlung der so abgespeicherten Feldinhalte können Deskriptor und Nutzdaten völlig gleich behandelt werden. Dies ist insbesondere wichtig, wenn die derart abgespeicherten Datensätze indiziert werden, um eine Liste aus Suchbegriffen zu erstellen. Die Dualität bzw. Äquivalenz der Feldinhalte, unabhängig davon, ob es sich um Deskriptoren oder um Nutzdaten handelt, führt dazu, daß bei der späteren Indizierung der einzelnen Felder von Datensätzen nicht nur über die Nutzdaten, sondern auch über die Deskriptoren indiziert werden kann.
Es versteht sich, daß bei entsprechender Feldbeschreibung der Feldinhalt 410c selbst wiederum ein Datensatz sein kann, oder aber auch ein Zeiger auf einen Datensatz. Im Prinzip kann auch ein sonstiges sogenanntes BLOB (Binary Large Object) als Nutzdaten oder als Deskriptor abgespeichert werden, das dann durch die entsprechende Feldbeschreibung bezüglich seines Formats und gegebenenfalls bezüglich seiner Eigenschaft als Deskriptor oder Nutzdaten definiert ist.
Der so aufgebaute Datensatz 400 wird dann unter einer eindeutigen Datensatznummer in einem maschinenlesbaren Speicher abgespeichert. Die Datensatznummer ist beispielsweise der Feldinhalt 410b eines ausgezeichneten Feldes, das dadurch ausgezeichnet ist, daß lediglich für ein Feld des Datensatzes der Deskriptor auf "Datensatznummer" lautet.
In der beschriebenen Form, bestehend aus Beschreibung und Inhalt wird also jeder Datensatz abgespeichert und ist anhand seiner eindeutigen Datensatznummer identifizierbar. In diesem Aufbau tritt er auch dem Benutzer bei einem Aufruf wieder entgegen, vorausgesetzt der- Benutzer hat das Zugriffsrecht für alle Felder des Datensatzes.
Durch die beschriebene Abspeicherung jedes Datensatzes, zusammen mit seiner Beschreibung, ergibt sie bei der erfindungsgemäßen Datenbank somit keine Datenbanktabelle vorgegebener Struktur wie bei herkömmlichen Datenbanken, sondern die Summe aller abgespeicherten Datensätze ergibt bei der erfindungsgemäßen Datenbank eine Datenbanktabelle beliebiger Struktur, wie sie in Fig. 4b mit drei beliebig langen Datensätzen 400 angedeutet ist. Insbesondere kann jedes Feld auch eine beliebige Anzahl von Feldinhalten aufweisen.
Die Feldbeschreibung 410b enthält dabei verschiedene Attribute, im ersten Ausführungsbeispiel neben Informationen über Datentyp und Länge der Feldinhalte, sowie der Bezeichnung der Feldinhalte (Nutzdaten oder Deskriptor), auch Informationen über den Schutzstatus, den Ersteller des Feldes, das Datum des Kreierens des Feldes und das Datum der letzten Referenz auf das Feld sowie weitere optionale Informationen (UIP User Information Protection) des Feldes, d. h. insbesondere über die Zugriffsberechtigung auf das Feld für die Benutzer. Diese Informationen in der Feldbeschreibung können sich auch jeweils auf individuelle Feldinhalte beziehen. Insbesondere können auch Informationen in der Feldbeschreibung darüber gespeichert werden, ob das betreffende Feld oder auch einzelne Feldinhalte des betreffenden Feldes bei einer Indizierung indiziert werden sollen. Darin wird gespeichert, ob überhaupt, und wenn ja für wen, eine Zugriffsberechtigung auf die Nutzdaten und/oder den Deskriptor besteht. Die UlP kann auch Informationen darüber enthalten, ob überhaupt das Feld als Ganzes bei einem Zugriff auf den Datensatz nach außen hin für bestimmte Benutzer in Erscheinung treten soll, d. h. ob ein bestimmter Benutzer überhaupt erkennen kann, daß ein solches Feld existiert. Wird z. B. in der UIP ein bestimmtes Feld als lediglich für bestimmte Nutzer erkennbar beschrieben, so können andere Benutzer bei einem Zugriff auf den Datensatz gar nicht erkennen, daß der Datensatz ein solches Feld enthält. Selbstverständlich kann die UIP solche Zugriffsinformationen auch für Nutzdaten und Deskriptor getrennt speichern, so daß z. B. zwar erkannt werden kann, daß der Deskriptor existiert, jedoch auf die Nutzdaten nicht zugegriffen werden kann. Die Feldbeschreibung kann auch Angaben darüber enthalten, ob ein Feld bei der Bildung eines Index indiziert werden soll oder nicht. Auch kann festgelegt werden, welche Feldinhalte und ggf. welche Teile der Feldbeschreibung indiziert werden sollen.
Neben diesen Informationen über Zugriffsberechtigungen können in der Feldbeschreibung 410b bzw. der UIP auch beliebige weitere Informationen gespeichert werden, die entweder den Datensatz als Ganzes oder den Inhalt einzelner Felder betreffen, z. B. Informationen über Zugriffszeiten oder Zugriffshäufigkeiten auf den Datensatz als Ganzes oder auf Teile des Datensatzes, auf einzelne Felder oder einzelne Feldinhalte. Allgemein kann die UIP beliebige Verwaltungsinformationen zum Feld enthalten. Es können beispielsweise auch Informationen über das Datum bzw. die Zeit der Herstellung einzelner Felder oder einzelner Feldinhalte, oder auch des ganzen Datensatzes abgespeichert werden.
Entscheidend ist, daß der Datensatz eine in sich selbst geschlossene und von anderen Datensätzen unabhängige Struktur bildet, die aus Feldern besteht, wobei jedes Feld aus einer vollständigen Beschreibung der Feldinhalte sowie den Feldinhalten besteht, wobei die Feldinhalte aus Nutzdaten oder aus Deskriptoren der Nutzdaten bestehen können.
Die aus solchen beliebig strukturierten Datensätzen zusammengesetzte Datenbanktabelle (siehe Fig. 4b) beliebiger Struktur wird nun linearisiert.
Linearisierung heißt dabei erneutes Abspeichern der einzelnen als Index-Felder ausgezeichneten Felder, bzw. der Feldinhalte und/oder gegebenenfalls von Teilen der Feldbeschreibung mit der jeweils gemeinsamen Satz-Nr., um so eine Liste von Zugriffsbegriffen zu erhalten, nach denen eingeordnet und gesucht werden kann. Dabei werden die Feldinhalte der einzelnen Felder und gegebenenfalls Teile der Feldbeschreibung zusammen mit der Datensatznummer als n-Tupel (minimal n = 4) erneut abgespeichert. Die Gesamtheit dieser n-Tupel bildet dann eine logische Liste aller Zugriffsbegriffe. Entscheidend ist dabei, daß sowohl die Feldinhalte selbst als auch gegebenenfalls Teile der Feldbeschreibung, falls diese bei der Linearisierung verwendet werden sollen, bei dieser Linearisierung gleichbehandelt werden. Das heißt, sowohl der/die Feldinhalte selbst als auch eventuell Teile der Feldbeschreibung können als Suchbegriff in der logischen Liste dienen, indem ein Index über jede der Spalten der n-Tupel gebildet wird.
Dabei werden zu jedem eingetragenen Feldinhalt der logischen Liste ein Deskriptor und die jeweilige Datensatznummer (Satz-Nr.), Informationen bezüglich des Formats sowie die UlP gespeichert. Fig. 5 zeigt eine solche Umwandlung einer Datenbanktabelle 510 (Fig. 5a) in einen Gesamt-Index 520 (Fig. 5b). Der Gesamt- Index wird aus der logischen Liste durch Indizierung über die in der logischen Liste als n-Tupel abgespeicherten Felder erfolgt dabei, wie man aus Fig. 5b erkennt, nicht nur über die aus Nutzdaten bestehenden Feldinhalte, sondern auch über die aus Deskriptoren bestehenden Feldinhalte. So tauchen die aus Deskriptoren bestehenden Feldinhalte Beleg-Nr., Datum, etc. ebenfalls als Suchbegriffe im Gesamt-Index auf. Neben diesen Deskriptoren könnten nun auch noch weitere Teile der Feldbeschreibung indiziert werden, die dann ebenfalls im Gesamt-Index als Suchbegriffe oder Zugriffsbegriffe auftauchen würden. So könnte hier beispielsweise auch die Länge der Datensätze als Ganzes als Suchbegriff im Gesamt-Index auftauchen. Im Prinzip kann bei der Indizierung über jeden Teil der Feldbeschreibung indiziert werden, sofern dies gewünscht wird. Dazu werden dann bei der Bildung der logischen Liste die Teile der Feldbeschreibung, über die indiziert werden soll, als Feld des aus einem Datensatz gebildeten n-Tupels abgespeichert.
Die Erstellung des Gesamt-Index wurde hier über den Zwischenschritt der Erstellung einer logischen Liste aus den einzelnen Datensätzen bzw. den einzelnen Felder der Datensätze beschrieben. Der Gesamt-Index kann jedoch auch ohne diesen Zwischenschritt direkt aus beliebig strukturierten Datensätzen gemäß Fig. 4b erstellt werden. Dabei kann die Feldbeschreibung Informationen darüber enthalten, was nun bei der Bildung des Gesamt-Index alles indiziert werden soll. Durch diese Informationen können einzelne Datensätze, einzelne Felder, ja selbst einzelne Feldinhalte von der Indizierung ausgeschlossen werden. Ferner können bei Vorliegen einer entsprechenden Feldbeschreibung wie bereits erwähnt auch Teile dieser Feldbeschreibung bei der Bildung des Gesamt-Index indiziert werden. Damit kann dann selbst nach den in der Feldbeschreibung abgespeicherten Informationen als Suchbegriffe bzw. Informationsbegriffe gesucht werden.
Insbesondere erkennt man jedoch aus Fig. 5b den besonderen Vorteil der Dualität von Deskriptoren und Nutzdaten. Über beide kann bei Bildung des Gesamt-Index indiziert werden, so daß nach beiden gesucht werden kann.
Die Verwendung von Teilen der Feldbeschreibung bei der Bildung des Gesamt-Index, so daß über Teile der Feldbeschreibung indiziert wird, ist zwar in Fig. 5b nicht dargestellt, erfolgt jedoch ganz analog. Dabei ist noch zu erwähnen,daß bei der Bildung des Gesamt-Index nicht notwendigerweise erforderlich ist, daß für jeden Suchbegriff auch ein Deskriptor existiert, der Eintrag in der Spalte Deskriptor für einen Suchbegriff kann durchaus auch leer bleiben.
Auch sind die Informationen der UIP, die in Fig. 5b dargestellt sind, lediglich optional. Erforderlich für die Bildung des Gesamt-Index sind der Suchbegriff, die Datensatz-Nummer und Informationen über das Format bzw. die Struktur der indizierten Suchbegriffe, ggf. auch der Datensatz-Nummer. Bei der Darstellung in Fig. 5b sind diese Informationen in der Spalte UIP enthalten.
Es ist jedoch zu beachten, daß die Datenbanktabelle 510 lediglich zufällig Datensätze gleicher Struktur aufweist. Dies ist bei dem erfindungsgemäßen Datenbanksystem keinesfalls erforderlich, die Datenbanktabelle könnte durchaus Datensätze unterschiedlicher Struktur aufweisen.
In Fig. 5b wird der Gesamt-Index 520 lediglich aus den Feldinhalten (Nutzdaten und Deskriptoren) als Suchbegriffe gebildet. Daneben wird wie schon erwähnt die Satz-Nr. abgespeichert, in Fig. 5b wird noch die UIP in dieser linearen Liste abgespeichert. Die UIP enthält dabei in diesem Beispiel die Informationen über das Format von Suchbegriff, Deskriptor und Satz-Nr.
Die Suche in der Datenbank selbst erfolgt nun über die linearisierte Datenbanktabelle, d. h. über den Gesamt-Index 520. Wie dieser Gesamt-Index letztlich gebildet wird, d. h. was als Suchbegriff verwendbar sein soll, ist dabei den Wünschen des Benutzers freigestellt. Im Prinzip können sowohl der Feldinhalt selbst als auch beliebige Teile der Feldbeschreibung als Suchbegriff verwendet werden. Aufgrund der Gleichbehandlung von Feldbeschreibung und Feldinhalt können dabei im Prinzip alle Elemente der Feldbeschreibung und Feldinhalt, also z. B. auch die Länge der Nutzdaten oder deren Datenformat, als Suchbegriffe in der Liste abgespeichert werden. Ohne weiteres ist es möglich, in der Feldbeschreibung jedes Feldes Informationen darüber abzuspeichern, was nun bei der Erstellung der Liste als Suchbegriff verwendet werden soll. Die Gleichbehandlung von ggf. Teilen der Feldbeschreibung und der Feldinhalte ist dabei so zu verstehen, daß Teile der Feldbeschreibung gleichsam selbst wieder Feldinhalte bilden, die jedoch dann weder Nutzdaten noch Deskriptoren enthalten, sondern eben eine Beschreibung der Deskriptoren bzw. Nutzdaten. Diese Teile der Feldbeschreibung sind sozusagen Quasi-Feldinhalte und können bei der Indizierung, d. h. bei der Bildung des Gesamt-Index, oder aber auch bei Bildung der logischen Liste, wie die eigentlichen Feldinhalte behandelt werden, die aus Deskriptoren oder Nutzdaten bestehen. Diese "Atomisierung" der einzelnen Datenfelder in Feldinhalte bzw. Quasi-Feldinhalte ermöglicht eine wesentlich weitreichendere Verarbeitung der in den einzelnen Datensätzen abgespeicherten Daten als bei herkömmlichen Datenbanken. Sie führt zu einer Aufspaltung nicht nur der einzelnen Datensätze in Felder, sondern auch der einzelnen Felder in Feldinhalte und Feldbeschreibung, wobei die Feldbeschreibung selbst wieder aus Quasi-Feldinhalten bestehen kann. Diese Feldinhalte und Quasi-Feldinhalte werden dann bei der weiteren Verarbeitung völlig gleich behandelt. Erst durch diese Atomisierung wird es möglich, im Prinzip auf alle noch so kleinen Individualbestandteile eines Datensatzes getrennt zuzugreifen, getrennt nach ihnen zu suchen, sie getrennt zu präsentieren, zu modifizieren, etc.
Im Prinzip können dabei alle in der Feldbeschreibung enthaltenen Informationen, etwa über die Länge der Daten oder auch die Verwaltungsinformationen über die Feldinhalte als Ganzes oder auch die individuellen Feldinhalte, die UlP, etc., atomisiert und als Quasi-Feldinhalt behandelt werden. Die Feldbeschreibung könnte dann wiederum Informationen über die einzelnen Quasi-Feldinhalte enthalten, die man als Quasi-Deskriptoren der Quasi-Feldinhalte bezeichnen könnte.
Alle Informationen, die in einem Feld gespeichert sind, also nicht nur die Feldinhalte, sondern auch beliebige Teile der Feldinhalte der Feldbeschreibung können somit, sofern sie selbst wiederum durch Quasi-Deskriptoren oder auch durch eine übergeordnete Konvention definiert sind, in gleicher Weise behandelt und verarbeitet werden. Insbesondere können die derart atomisierten Bestandteile der einzelnen Felder hinsichtlich ihrer Struktur in beliebiger Weise generiert, gespeichert und modifiziert werden, und sie können auch nach Wunsch indiziert und als Suchbegriffe verwendet werden.
Die Bedingung dafür ist lediglich, daß der Datensatz als Ganzes vollständig aus sich heraus ohne Bezugnahme auf andere Datensätze definiert ist, und daß alle Teilbestandteile des Datensatzes, nicht nur die einzelnen Felder, sondern auch alle weiteren kleineren Bestandteile wie Feldinhalte oder auch Quasi-Feldinhalte durch die im Datensatz enthaltenen Daten selbst definiert und vollständig beschrieben sind. Diese vollständige Beschreibung bzw. Definition aller, auch der kleinsten, Bestandteile des Datensatzes geschieht bei der Erstellung des Datensatzes bzw. bei der Eingabe durch den Benutzer. Ist die Definition vollständig erstellt, kann von da ab auf den so vollständig definierten Datensatz und auf alle gemäß der Definition bzw. Beschreibung des Datensatzes festgelegten Bestandteile individuell zugegriffen werden, individuell nach ihnen gesucht werden, etc.
Aufgrund der Möglichkeit, bei der erfindungsgemäßen Datenbank Datensätze beliebiger Struktur abzuspeichern und sie auf beliebige Weise zu "atomisieren", d. h. sie bezüglich ihrer Einzelbestandteile vollständig zu definieren ist die erfindungsgemäße Datenbank in der Lage, nicht nur alle beliebigen zukünftig auftretenden Datenstrukturen in bereits vorhandene Datenbestände zu integrieren, sondern auch beliebige neue Suchkriterien und Suchbegriffe zu erstellen.
Der Gesamt-Index wird ständig aus der unstrukturierten Datenbanktabelle generiert, d. h. er repräsentiert den momentanen Zustand der unstrukturierten Datenbank. Bei Einfügen eines neuen Datensatzes bzw. beim Ändern eines Datensatzes in der unstrukturierten Datenbank wird eine oder mehrere Einträge von Feldern aus dem Datensatz in dem Gesamt-Index erzeugt.
Der in Fig. 5b dargestellte Gesamt-Index 520 enthält neben dem Deskriptor und der Dokumenten-ID auch die Informationen über den Schutzstatus (UIP). Insbesondere sind alle Nutzdaten als Suchbegriffe in der linearen Liste enthalten, zusammen mit den zugehörigen Deskriptoren und der jeweiligen Datensatznummer.
Dadurch ergibt sich für die Suche in der Datenbank eine im Vergleich zu herkömmlichen Datenbanken vergleichsweise einfache Vorgehensweise. Bei herkömmlichen Datenbanken wird vorausgesetzt, daß folgende Informationen bekannt sind: Erstens alle potentiell in Frage kommenden Tabellen und zweitens die Datenstrukturen zu den jeweiligen Tabellen. Wird also nach einem bestimmten Nutzdatenwert gesucht, so muß man den Deskriptor oder zumindest den möglichen Deskriptor des Wertes kennen. Es ist also ein gewisses Wissen über die vorhandenen Datenstrukturen erforderlich, um z. B. nach dem Suchbegriff "Paul" zu suchen. Falls der Suchende nicht weiß, in welchen Spalten der vorhandenen Datenbanktabellen der Feldinhalt abgespeichert sein könnte, wird eine Suche unvollständig bleiben. Insbesondere kann jedoch nicht nach Deskriptoren, die "Paul" lauten, gesucht werden.
Die vergleichsweise komplizierte Suche in einer herkömmlichen Datenbank ergibt sich durch die Tabellenstruktur der Daten in herkömmlichen Datenbanken. Nachfolgend wird zunächst die Suche nach dem Suchbegriff "Paul" in einer herkömmlichen Datenbank beschrieben. Fig. 6 zeigt z. B. die Datenbanktabelle einer herkömmlichen Datenbank mit der Bezeichnung "PersonenInfo".
Bei der Suche muß man bei der herkömmlichen Datenbank zunächst wissen, in welcher Tabelle gesucht werden kann, ferner muß man angeben, in welchen Spalten (Deskriptoren) der Suchbegriff auftreten könnte. Dies geschieht beispielsweise auf folgende Weise:
Select * from Personenlnfo where Vorname = Paul or Nachname = Paul.
Würden weitere Spalten existieren, die potentiell die Information "Paul" enthalten könnten, so müßten diese ebenfalls im Selektionskommando berücksichtigt werden. Die Selektion bei konventionellen Datenbanken setzt also voraus, daß vor der Selektion folgende Informationen bekannt sind:
  • 1. Alle potentiell in Frage kommenden Tabellen.
  • 2. Die Datenstrukturen zu den jeweiligen Tabellen.
Dies ist jedoch nicht immer gewährleistet und schränkt damit die Suchmöglichkeiten stark ein. Soll beispielweise festgestellt werden, welche Datensätze innerhalb einer Datenbank die Information "Paul" enthalten, egal ob als Deskriptor oder als Nutzdatenwert, so ist dies ohne Kenntnis der Tabellen und Datenstrukturen mit konventionellen Datenbanken nicht möglich.
Bei dem erfindungsgemäßen Datenbank-Management-System ist jedoch die Suche wesentlich einfacher. Da jeder Feldinhalt einzeln in Verbindung mit seinem Deskriptor und seiner Datensatz-Nummer in einem einzigen Index 700 abgespeichert ist, wie aus Fig. 7 zu ersehen ist, kann bei der erfindungsgemäßen Datenbank die Suche ganz einfach mit folgendem Kommando durchgeführt werden:
Select * where Paul.
Diese Suche liefert alle Datensätze, bei denen zumindest ein Datenfeld, unabhängig vom Deskriptor, den Feldinhalt Paul enthält. Insbesondere können auch die Datensätze gefunden werden, bei denen "Paul" als Deskriptor auftritt.
Damit ist keine Information über die Struktur einer Tabelle nötig, und keine Information darüber, mit welchem Deskriptor die Information "Paul" zusammen auftreten kann.
Sind solche Informationen jedoch bekannt, so können sie natürlich für die Suche zusätzlich als einschränkendes Kriterium angegeben werden. Ist beispielsweise bekannt, daß es sich bei Paul um einen Vornamen handeln muß, so kann dies bei der Suche wie folgt verwendet werden:
Select * where Vorname = Paul.
Analog können auch weitere zusätzliche Kriterien verwendet werden.
Bei dem Gesamt-Index 700, wie er in Fig. 7 dargestellt ist, erkennt man daß als Suchbegriffe nicht nur die Feldinhalte, sondern auch die Deskriptoren abgespeichert sind. So sind z. B. als Suchbegriffe auch die Datenbeschreibungen "Personenlnfo" abgespeichert, ihr Deskriptor bzw. ihre Bezeichnung lautet dabei natürlich "Tabelle". Ohne weiteres könnte man sich den Gesamt-Index 700 auch verlängert vorstellen, wobei dann z. B. auch der Deskriptor "Tabelle" selbst wieder als Suchbegriff abgespeichert sein könnte. Die UIP ist bei dem Gesamt-Index 700 in Fig. 7 nicht dargestellt. Diese Information ist jedoch auch optional. Erforderlich ist die Abspeicherung eines Suchbegriffs, eines Deskriptors für den Suchbegriff und die Abspeicherung der Datensatznummer, um den zugehörigen Datensatz auffinden zu können. Der Eintrag für den Deskriptor kann jedoch auch leer bleiben.
Damit ergibt sich bei der erfindungsgemäßen Datenbank aufgrund der zweifachen und vergleichsweise unstrukturierten Speicherung der in der Datenbasis enthaltenen Informationen sowohl eine besonders einfache Systempflege als auch besonders einfacher Zugriff auf Daten der Datenbasis.
Dies ergibt sich dadurch, daß bei jeder Speicherung eines Datensatzes das Datenbank-Management-System diesen Datensatz bezüglich seiner Struktur definiert; damit ist dann die so definierte Struktur für das Datenbank-Management System auch in Zukunft im Falle von anderen Datensätzen mit gleicher Struktur lesbar. Es ist jedoch nicht erforderlich, daß das Datenbank-Management-System an eine übergeordnete Tabellenstruktur angepaßt ist, in der mehrere Datensätze in geordneter Weise abgespeichert sind.
Die Definition der Struktur eines neu abzuspeichernden Datensatzes kann dabei vom Benutzer selbst in einfacher Weise vorgenommen werden, so daß eine umfangreiche Systempflege nicht erforderlich ist.
Bei der vorher beschriebenen Erstellung des Gesamt-Index ist es natürlich zweckmäßig, den Gesamt-Index nach dem Suchbegriff zu sortieren, entweder alphabetisch, oder auf eine sonstige Art und Weise, so daß einfacher in der linearen Listen gesucht werden kann und schneller auf die zugehörigen Datensätze zugegriffen werden kann. Bei der Erstellung des Gesamt-Index aus der unstrukturierten Datenbanktabelle werden sinnvollerweise zumindest die Nutzdaten als Suchbegriffe in dem Gesamt-Index abgespeichert, gegebenenfalls wie bereits erwähnt auch die Deskriptoren und/oder Teile der Feldbeschreibung. Bei der Erstellung des Gesamt-Index können durchaus auch einzelne Felder von der Aufnahme in den Gesamt-Index ausgeschlossen werden, entsprechend der in der Feldbeschreibung enthaltenen Informationen. Die tatsächliche Erstellung kann sich also nach in der Feldbeschreibung abgespeicherten Informationen, z. B. nach den in der UIP enthaltenen Informationen, richten.
Nachdem der Gesamt-Index erstellt wurde, kann dieser in Teil-Indices unterteilt werden. Dies erleichtert den Zugriff bzw. die Verwaltung bei sehr großen Datenbeständen, die unter Umständen nur teilweise von Interesse sind. Die Unterteilung ist ferner sinnvoll bei der Implementation in Client-Server-Systemen, wo auf verschiedenen Clients dann unterschiedliche Teile der Gesamtliste geladen werden. So kann dann z. B. auf einem Client der Zugriff bzw. die Suche nach kaufmännischen Daten, wie etwa Rechnungen, auf einem anderen Client die Verwaltung bzw. die Suche nach und der Zugriff auf die organisatorischen Daten wie etwa Lagerhaltung, Bestellung, etc. erfolgen. Fig. 11 zeigt eine solche Unterteilung des Gesamt-Index in Teil-Indices.
Die Unterteilung des Index ist aufgrund der beliebigen Struktur der in der beliebig strukturierten Datenbanktabelle abgespeicherten Daten unter Umständen extrem lang. Deshalb kann auch die Unterteilung in Sub-Indizes bzw. Unterlisten nach verschiedenen logischen und zeitlichen Kriterien aufgeteilt werden (z. B. Zeitspanne, Belegart, Aufbewahrungsfrist, im Falle der Tabelle aus Fig. 5). Ferner kann die Liste auch unter Berücksichtigung von Zugriffszeiten oder Zugfriffshäufigkeiten auf die Daten erstellt werden. Solche Informationen wären dann natürlich auch in der Feldbeschreibung der einzelnen Felder abgespeichert, etwa als Teil der UIP.
Über die Information im UIP, wann welche Suchbegriffe benutzt wurden bzw. wann diese erstmalig angelegt wurden, evtl. im Zusammenhang damit, wer dies getan hat, ist aus dem Gesamt-Index heraus jeweils ein Teil-Index isolierbar/extrahierbar, der für einen bestimmten Anwender/Anwenderkreis die Suchbegriffe und Deskriptoren enthält, die einem ausgewählten Zeitraum über die Tatsache zugeordnet werden können, ob diese Begriffe und Deskriptoren bzw. Feldinhalte in dem angegebenen Zeitraum benutzt wurden/werden, oder darüber ob diese Begriffe in diesem Zeitraum erstellt wurden.
Wird nun der Zeitraum verändert, so kommen neue Begriffe in diesen Teil-Index hinzu bzw. andere verlassen den Teil-Index, da sie nicht mehr zu der Menge der in dem Zeitraum benutzten oder erstellten Begriffe gehören.
Versteht man nun eine Maske für die Dateneingabe bzw. Datenrepräsentation als Menge von Tupeln aus Deskriptoren und Nutzdaten, die zu den Deskriptoren eingegeben oder angezeigt werden, so können auch die Masken über die Zuordnung der jeweils nach der Zeit benutzten Deskriptoren­ bzw. Nutzdaten verwaltet werden. Die Zugriffsstrukturen, die über die Masken definiert sind, nehmen über die o.g. Tupeln an der zeitlichen Änderung teil, indem die Masken selbst als Datensätze abgespeichert werden. Damit liefern die so abgespeicherten Masken eine Sicht auf einen jeweils zur betreffenden Maske gehörenden bzw. passenden Teilbestand der Daten.
Es lassen sich also durch die Abspeicherung zeitlicher Informationen bezüglich der Suchbegriffe/Deskriptoren in der UIP sowohl die Datensätze selbst als auch die Zugriffsmasken auf die Daten in der zeitlichen Änderung verfolgen. Es kann also ein Zeitraum "von-bis" als zusätzliches einschränkendes Suchkriterium verwendet werden.
Es ist eine Eigenschaft der erfindungsgemäßen Datenbank, daß zu jedem Datensatz eine vollständige Beschreibung des Datensatzes gehört, wobei das System aus der Summe der Datensätze automatisch den Gesamt-Index generiert. Sowohl die Beschreibung des Datensatzes als auch der Datensatz selbst können jederzeit in beliebiger Weise geändert werden. Für jeden Datensatz können also immer die jeweilige Anwendersicht auf diesen Datensatz mit abgespeichert werden, indem entsprechende Informationen in der Feldbeschreibung abgespeichert werden.
Ein Beispiel für eine Eingabemaske, für einen Suchvorgang in einer erfindungsgemäßen Datenbank ist in Fig. 8 dargestellt.
Diese Eingabemaske wird, wenn ein Suchvorgang durchgeführt werden soll, auf einem Bildschirm eines Eingabegeräts angezeigt. Ein Fenster 800 enthält in einer oberen Zeile Icons BA1 bis BAn für Standardfunktionen, etwa zum Aufruf von Standard-Eingabemasken. Mit Hilfe eines linken Scroll-Fensters 610 können Deskriptoren ausgewählt werden, um die Suche einzuschränken. In einem Eingabefenster 620 ("Eingabezeile") wird der eigentliche Suchbegriff eingeben. In einem Scroll-Fenster 630 rechts werden die gefundenen Suchbegriffe aufgelistet. In einem Scroll-Fenster 640 werden die möglichen Deskriptoren für den Fall aufgelistet, daß die Suche nicht zu einem eindeutigen Ergebnis führt. Mit Hilfe eines Scroll-Fensters 650 kann ein Suchzeitraum vorgegeben werden.
Handelt es sich bei dem in der Eingabezeile eingegebenen Begriff um einen Nutzdatenwert, und wird in dem Scroll-Fenster 610 kein Deskriptor als einschränkendes Kriterium ausgewählt, so erscheinen im Fenster 640 die zu diesem Eingabewert gehörenden Deskriptoren, aus denen der Benutzer dann einen zur weiteren Einschränkung der Suche auswählen kann. Handelt es sich jedoch bei dem in der Eingabezeile 620 eingegebenen begriff um einen Deskriptor, so erscheinen im Fenster 650 die möglichen Nutzdatenwerte, die bei verschiedene Datensätzen und evtl. bei verschiedenen Feldern verschiedener Datensätze für diesen Deskriptor gefunden werden. In der Symmetrie dieser Maske gemäß Fig. 8 bezüglich der Suche nach Nutzdatenwerten oder Deskriptoren spiegelt sich die bereits mehrfach erwähnte Dualität von Nutzdatenwerten und zugehörigen Deskriptoren, die daraus resultiert, daß die Feldinhalte bei der Bildung des Gesamt-Index gleich behandelt werden, egal ob es sich um Nutzdaten oder um Deskriptoren handelt.
Ggf. können auch mehrere Begriffe eingegeben werden, nach denen dann gemeinsam gesucht wird. Die daraus resultierende Liste aus Eingabekriterien wird im Fenster 660 angezeigt.
In der Eingabezeile 620 wird also der Suchbegriff "Kar" eingegeben. Für den eingegebenen Suchbegriff "Kar" wurden im vorliegenden Beispiel keine passenden Deskriptoren gefunden, so daß das Fenster 650 leer bleibt. Das Fenster 630 zeigt die gefundenen Nutzdatenwerte (in der Figur etwas inkonsistent als "Feldinhalte" bezeichnet) an. Man sieht, daß keine direkter Treffer erzielt wird, da es keinen Nutzdatenwert "Kar" im Datenbestand gibt. Statt dessen werden in alphabetischer Reihenfolge die ähnlichen Nutzdatenwerte mit gleichen Anfangsbuchstaben angezeigt. Bei der Eingabe kann zusätzlich zum Suchbegriff auch im Fenster 610 ein Deskriptor ausgewählt werden, um die Suche weiter einzuschränken. Wird ein solcher Deskriptor angewählt, so erscheint natürlich in Fenster 640 keine Liste von zum Suchbegriff passenden Deskriptoren.
Wird kein Deskriptor zusätzlich eingegeben, so ergibt sich keine eindeutige Zuordnung, und es erscheint als Resultat beispielsweise ein Fenster auf dem Bildschirm, wie es in Fig. 9 dargestellt ist. Es werden also Datensätze gefunden, bei denen "Karl" als Vorname, Firma oder als Pseudonym auftritt.
Der Suchvorgang ist so gestaltet, daß, wenn keine eindeutige Zuordnung möglich ist, in der Suchmaske (Fig. 8) das Fenster 640 erscheint, welches die Deskriptoren anzeigt, unter denen der Suchbegriff gefunden wurde.
Bei der Suche mit einer Maske gemäß Fig. 8 wird beispielsweise im Falle der unstrukturierten Suche, d. h. wenn kein Deskriptor (Klassifikator) als Zusatzinformation eingeben wird, die Liste der gefundenen möglichen Deskriptoren im Fenster 640 angezeigt. Aus den gefundenen möglichen Deskriptoren kann dann der Benutzer einen auswählen, so daß eine eindeutige Zuordnung erfolgt.
Wird ein zusätzlicher Deskriptor (Klassifikator) miteingegeben, ergibt sich beispielsweise ein Resultat, wie es in Fig. 10 dargestellt ist. Dieses wird dann als Fenster auf dem Bildschirm angezeigt.
Die beschriebene Suche, aber auch die. Abspeicherung eines Datensatzes, und der Zugriff auf einen bestimmten Datensatz, oder auf mehrere Datensätze, stellen jeweils eine bestimmte Anwendersicht der Datenbank dar. Solche Anwendersichten der Datenbank, d. h. die zugehörigen Eingabeformate, Ausgabeformate, etc. sind selbst wiederum Informationen, die als Datensatz in der erfindungsgemäßen Datenbank abgespeichert werden können. Das heißt, die in der Datenbank abgespeicherte Information kann sich auch auf verschiedene Anwendersichten der Datenbank durch verschiedene Benutzer und Benutzergruppen erstrecken, beziehungsweise auf verschiedene Eingabemasken oder Eingabeformate.
Die so als Datensätze abgespeicherten Eingabemasken oder Eingabeformate werden dann wieder linearisiert, so daß nach diesen selbst wiederum gesucht werden kann. Bei den verschiedenen Anwendersichten auf die Datenbank bzw. bei deren Abspeicherung können auch Informationen über die Zeit, wann die Anwendersicht benutzt wurde, mitabgespeichert werden. Mit diesen Informationen kann dann bei geeigneter Indizierung der zeitlichen Informationen bei der Suche ein Suchzeitraum vorgegeben werden, wie er im Fenster 670 von Fig. 8 dargestellt ist.
Bei der Suche werden lediglich die Anwendersichten der Datenbank gefunden, die in den ausgewählten Suchzeitraum fallen.

Claims (20)

1. Verfahren zur Durchführung von Operationen in einem Datenbanksystem, in dem eine Vielzahl von Datensätzen in einem Speicher eines Computers gespeichert werden, dadurch gekennzeichnet, daß
jeder Datensatz aus einer beliebigen Anzahl von Feldern besteht, die jeweils aus einer Feldbeschreibung als Metadaten und einer beliebigen Anzahl von Feldinhalten bestehen, und
daß bei jeder Speicherung eines Datensatzes in einem Speicher eines Computers die Feldinhalte zusammen mit den zugehörigen Metadaten als ein Datensatz abgespeichert werden.
2. Verfahren nach Anspruch 1, wobei jeder Feldinhalt aus Nutzdaten oder einem Deskriptor für einen dem Deskriptor zugeordneten Feldinhalt besteht, wobei die Metadaten eines jeden Datensatzes die Struktur des jeweiligen Datensatzes zumindest bezüglich der Feldinhalte, gegebenenfalls auch bezüglich der Feldbeschreibung oder Teilen der Feldbeschreibung, vollständig definieren und weitere Verwaltungsinformationen über die Feldinhalte enthalten können.
3. Verfahren nach einem der Ansprüche 1 oder 2, gekennzeichnet durch die Verfahrensschritte:
Speichern der Datensätze jeweils unter einer Datensatznummer in einem Speicher,
Bilden eines Gesamt-Index über Feldinhalte von Feldern der abgespeicherten Datensätze, d. h. über aus Nutzdaten -und/oder aus Deskriptoren bestehende Feldinhalte, ggf. zusätzlich über Teile der Feldbeschreibung,
Abspeichern des Gesamt-Index in einem Speicher.
4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß Feldinhalte von Feldern leer bleiben können.
5. Verfahren nach Anspruch 3 oder 4, wobei ein Feld jedes Datensatzes dadurch ausgezeichnet ist, daß es als Feldinhalt eine diesen Datensatz kennzeichnende Datensatznummer enthält, und der Deskriptor lediglich des ausgezeichneten Feldes den betreffenden Feldinhalt als Datensatznummer kennzeichnet.
6. Verfahren nach einem der Ansprüche 3 bis 5, das ferner folgende Schritte umfaßt:
Speichern der aus Nutzdaten bestehenden Feldinhalte von Feldern der abgespeicherten Datensätze zusammen mit den zugehörigen aus Deskriptoren bestehenden Feldinhalten, der Datensatznummer und ggf. mit einem Teil der Feldbeschreibung in einer logischen Liste in einem Speicher als n-Tupel (n = 4 minimal), und
Indizieren der Liste über mindestens die aus Nutzdaten bestehenden Feldinhalte zu einem Gesamt-Index, ggf. zusätzlich über weitere Spalten der n- Tupel, insbesondere die aus Deskriptoren bestehenden Feldinhalte und/oder auch Teile der Feldbeschreibung, wobei die Feldbeschreibung Informationen über den Datentyp des Feldinhalts, über die Länge des Feldinhalts und ggf. Informationen über die Bezeichnung (Nutzdaten oder Deskriptor) des Feldinhalts enthält, und Speichern des Gesamt-Index in einem Speicher.
7. Verfahren nach einem der Ansprüche 3 bis 6, bei dem lediglich entsprechend der Feldbeschreibung ausgezeichnete Feldinhalte und/oder Teile der Feldbeschreibung im Gesamtindex gespeichert werden.
8. Verfahren nach einem der Ansprüche 2 bis 7, bei dem die Feldbeschreibung Informationen über den Schutzstatus des entsprechenden Feldes (UIP User Information Protection) enthält.
9. Verfahren nach einem der vorhergehenden Ansprüche, bei dem der Gesamt-Index in Teil-Indices aufgeteilt wird.
10. Verfahren nach Anspruch 9, bei dem die Unterteilung des Gesamt- Index gemäß dem Zeitraum der Nutzung und/oder der Erstellung der Daten durch den Anwender und gegebenenfalls anwenderspezifisch erfolgt, wobei die Informationen über den Zeitraum und/oder die Erstellung und gegebenenfalls über den Anwender in der Feldbeschreibung (UIP) abgespeichert sind.
11. Verfahren zum Zugriff auf gemäß dem Verfahren nach einem der Ansprüche 1 bis 10 abgespeicherte Daten, dadurch gekennzeichnet, daß es folgenden Schritt enthält:
Absuchen des Gesamt-Index nach vorbestimmten Suchkriterien und Auffinden des zugehörigen Datensatzes.
12. Verfahren zur Änderung gemäß dem Verfahren nach einem der Ansprüche 1 bis 10 abgespeicherter Daten, dadurch gekennzeichnet, daß es die folgenden Schritte enthält:
Suchen des zu verändernden Datensatzes nach vorbestimmten Suchkriterien,
Modifizieren des zu verändernden Datensatzes,
Abspeichern des modifizierten Datensatzes gemäß dem Verfahren nach einem der Ansprüche 1 bis 10.
13. Verfahren zur Anzeige von gemäß dem Verfahren nach einem der Ansprüche 1 bis 10 abgespeicherten Daten, dadurch gekennzeichnet, daß es die folgenden Schritte enthält:
Suchen des anzuzeigenden Datensatzes nach vorbestimmten Suchkriterien,
Anzeige von Feldern des gefundenen Datensatzes auf einem Bildschirm des Computers oder einem Drucker.
14. Verfahren nach Anspruch 13, dadurch gekennzeichnet, daß lediglich die Felder des Datensatzes angezeigt werden, für die gemäß den Informationen der Feldbeschreibung (UIP) eine Anzeige gestattet wird.
15. Verfahren nach einem der vorhergehenden Ansprüche, bei dem Anwendersichten der Datenbank in Form der zur Erstellung, Eingabe, Suche, Modifikation und Anzeige von Daten benutzten Masken gemäß einem der Ansprüche 1 bis 10 abgespeichert werden.
16. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß bei der Indizierung, der Speicherung, der Suche, der Anzeige, der Modifikation und weiteren Verarbeitungsschritten bezüglich der Datensätze als Ganzes oder einzelner Felder die aus Nutzdaten bestehenden Feldinhalte und die aus Deskriptoren bestehenden Feldinhalte, gegebenenfalls auch die aus Quasi- Feldinhalten bestehenden Teile der Feldbeschreibung, auf die im wesentlichen gleiche Weise in einem digitalen Computer verarbeitet und gespeichert werden.
17. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß
die Feldbeschreibung zeitliche Informationen über die Erstellung und/oder den Zugriff auf einzelne Feldinhalte oder Teile der Feldbeschreibung enthält,
die zeitlichen Informationen zur Unterteilung des Gesamt-Index in Teil- Indices verwendet werden, wobei die Teil-Indices die Suchbegriffe und/oder die Deskriptoren enthalten, die bezüglich ihrer Erstellung und/oder ihres Zugriffs in einen vorgegebenen Zeitraum fallen.
18. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die Feldbeschreibung aus Teilbeschreibungen besteht, die als Quasi- Feldinhalte bei der Bildung des Gesamt-Index indiziert werden können.
19. Von einem digitalen Computer lesbarer Datenträger, dadurch gekennzeichnet, daß auf ihm Daten gespeichert sind, die vom Computer lesbar sind und die ihn in die Lage versetzen, ein Verfahren gemäß einem der vorhergehenden Ansprüche auszuführen.
20. Computersystem zur Durchführung von Operationen in einem Datenbanksystem, in dem eine Vielzahl von Datensätzen in einem Speicher eines Computers gespeichert wird, wobei das Computersystem ein Eingabegerät (150), ein Ausgabegerät (160), eine Speichereinheit (110.) mit einer darauf gespeicherten Datenbasis (120), auf die über ein Datenbank-Management-System (130) von Anwendungsprogrammen (140) aus zugegriffen werden kann, sowie eine EDV-Anlage (100) aufweist und so ausgestaltet ist, daß es ein Verfahren gemäß einem der Ansprüche 1 bis 10 ausführen kann.
DE19627472A 1996-07-08 1996-07-08 Datenbanksystem Withdrawn DE19627472A1 (de)

Priority Applications (6)

Application Number Priority Date Filing Date Title
DE19627472A DE19627472A1 (de) 1996-07-08 1996-07-08 Datenbanksystem
AU35386/97A AU3538697A (en) 1996-07-08 1997-07-08 Database system
DE59711376T DE59711376D1 (de) 1996-07-08 1997-07-08 Datenbanksystem
EP97931718A EP0910829B1 (de) 1996-07-08 1997-07-08 Datenbanksystem
US09/214,682 US6772164B2 (en) 1996-07-08 1997-07-08 Database system
PCT/DE1997/001441 WO1998001808A1 (de) 1996-07-08 1997-07-08 Datenbanksystem

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE19627472A DE19627472A1 (de) 1996-07-08 1996-07-08 Datenbanksystem

Publications (1)

Publication Number Publication Date
DE19627472A1 true DE19627472A1 (de) 1998-01-15

Family

ID=7799244

Family Applications (2)

Application Number Title Priority Date Filing Date
DE19627472A Withdrawn DE19627472A1 (de) 1996-07-08 1996-07-08 Datenbanksystem
DE59711376T Expired - Lifetime DE59711376D1 (de) 1996-07-08 1997-07-08 Datenbanksystem

Family Applications After (1)

Application Number Title Priority Date Filing Date
DE59711376T Expired - Lifetime DE59711376D1 (de) 1996-07-08 1997-07-08 Datenbanksystem

Country Status (5)

Country Link
US (1) US6772164B2 (de)
EP (1) EP0910829B1 (de)
AU (1) AU3538697A (de)
DE (2) DE19627472A1 (de)
WO (1) WO1998001808A1 (de)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19951756A1 (de) * 1999-10-27 2001-05-10 Lech Elek Zitaetswerke Ag Verfahren zur Datenverwaltung
DE10001613A1 (de) * 2000-01-17 2001-08-02 Tiscon Ag Science Park Verfahren zur Verwaltung von Datensätzen
US6636600B1 (en) 1999-05-05 2003-10-21 Siemens Aktiengesellschaft Method for finding a contact or for setting up a connection to the contact
WO2020201249A1 (de) * 2019-04-04 2020-10-08 Bundesdruckerei Gmbh Maschinelles lernen auf basis von trigger-definitionen
WO2020201247A1 (de) * 2019-04-04 2020-10-08 Bundesdruckerei Gmbh Automatisiertes maschinelles lernen auf basis gespeicherten daten

Families Citing this family (79)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10839321B2 (en) 1997-01-06 2020-11-17 Jeffrey Eder Automated data storage system
EP1049030A1 (de) 1999-04-28 2000-11-02 SER Systeme AG Produkte und Anwendungen der Datenverarbeitung Methode und Apparat zur Klassifizierung
US8874244B2 (en) * 1999-05-19 2014-10-28 Digimarc Corporation Methods and systems employing digital content
EP1128278B1 (de) * 2000-02-23 2003-09-17 SER Solutions, Inc Methode und Vorrichtung zur Verarbeitung elektronischer Dokumente
WO2001097075A2 (en) * 2000-06-15 2001-12-20 The Trustees Of Columbia University In The City Of New York A method and system for a relational data model for integrated management and analysis of generalized n-dimensional tabular data with multilingual support
US9177828B2 (en) 2011-02-10 2015-11-03 Micron Technology, Inc. External gettering method and device
EP1182577A1 (de) 2000-08-18 2002-02-27 SER Systeme AG Produkte und Anwendungen der Datenverarbeitung Assoziativspeicher
GB2368929B (en) * 2000-10-06 2004-12-01 Andrew Mather An improved system for storing and retrieving data
DE10113515A1 (de) * 2001-03-20 2002-10-02 Bfm Building & Facility Man Gm Datenbanksystem
US7346519B2 (en) * 2001-04-10 2008-03-18 Metropolitan Regional Information Systems, Inc Method and system for MRIS platinum database
US20030065671A1 (en) * 2001-08-23 2003-04-03 Efunds Corporation Method and apparatus for formatting a data grid for the display of a view
ATE537507T1 (de) * 2001-08-27 2011-12-15 Bdgb Entpr Software Sarl Verfahren zum automatischen indizieren von dokumenten
EP1387294A1 (de) * 2002-07-29 2004-02-04 Deutsche Thomson-Brandt Gmbh Ein Datenbankmodel für hierarchische Datenformate
US20050060286A1 (en) * 2003-09-15 2005-03-17 Microsoft Corporation Free text search within a relational database
GB2406660A (en) * 2003-09-30 2005-04-06 Ibm A system for retrieving data from a partially indexed data store
US20050203948A1 (en) * 2004-03-15 2005-09-15 De La Rosa Josep Lluis Method for influencing market decisions of people
US7822749B2 (en) 2005-11-28 2010-10-26 Commvault Systems, Inc. Systems and methods for classifying and transferring information in a storage network
US7668884B2 (en) 2005-11-28 2010-02-23 Commvault Systems, Inc. Systems and methods for classifying and transferring information in a storage network
US20200257596A1 (en) 2005-12-19 2020-08-13 Commvault Systems, Inc. Systems and methods of unified reconstruction in storage systems
US8930496B2 (en) 2005-12-19 2015-01-06 Commvault Systems, Inc. Systems and methods of unified reconstruction in storage systems
US7617206B1 (en) * 2006-04-06 2009-11-10 Unisys Corporation Method for analyzing status of specialized tank files which store and handle large objects
US7870102B2 (en) 2006-07-12 2011-01-11 International Business Machines Corporation Apparatus and method to store and manage information and meta data
US8077059B2 (en) * 2006-07-21 2011-12-13 Eric John Davies Database adapter for relational datasets
US7882077B2 (en) 2006-10-17 2011-02-01 Commvault Systems, Inc. Method and system for offline indexing of content and classifying stored data
US20080120207A1 (en) * 2006-11-21 2008-05-22 Strickland Ronnie D Method and system for electronically managing product inventory using a database
US8370442B2 (en) 2008-08-29 2013-02-05 Commvault Systems, Inc. Method and system for leveraging identified changes to a mail server
US20080228771A1 (en) 2006-12-22 2008-09-18 Commvault Systems, Inc. Method and system for searching stored data
US8296301B2 (en) 2008-01-30 2012-10-23 Commvault Systems, Inc. Systems and methods for probabilistic data classification
US7836174B2 (en) 2008-01-30 2010-11-16 Commvault Systems, Inc. Systems and methods for grid-based data scanning
US9152883B2 (en) 2009-11-02 2015-10-06 Harry Urbschat System and method for increasing the accuracy of optical character recognition (OCR)
US9213756B2 (en) 2009-11-02 2015-12-15 Harry Urbschat System and method of using dynamic variance networks
US9158833B2 (en) 2009-11-02 2015-10-13 Harry Urbschat System and method for obtaining document information
US8321357B2 (en) * 2009-09-30 2012-11-27 Lapir Gennady Method and system for extraction
WO2011082113A1 (en) 2009-12-31 2011-07-07 Commvault Systems, Inc. Asynchronous methods of data classification using change journals and other data structures
US9396283B2 (en) 2010-10-22 2016-07-19 Daniel Paul Miranker System for accessing a relational database using semantic queries
US8719264B2 (en) 2011-03-31 2014-05-06 Commvault Systems, Inc. Creating secondary copies of data based on searches for content
US8892523B2 (en) 2012-06-08 2014-11-18 Commvault Systems, Inc. Auto summarization of content
US8862566B2 (en) * 2012-10-26 2014-10-14 Equifax, Inc. Systems and methods for intelligent parallel searching
US10438013B2 (en) 2016-06-19 2019-10-08 Data.World, Inc. Platform management of integrated access of public and privately-accessible datasets utilizing federated query generation and query schema rewriting optimization
US11042548B2 (en) 2016-06-19 2021-06-22 Data World, Inc. Aggregation of ancillary data associated with source data in a system of networked collaborative datasets
US11042537B2 (en) 2016-06-19 2021-06-22 Data.World, Inc. Link-formative auxiliary queries applied at data ingestion to facilitate data operations in a system of networked collaborative datasets
US11675808B2 (en) 2016-06-19 2023-06-13 Data.World, Inc. Dataset analysis and dataset attribute inferencing to form collaborative datasets
US10324925B2 (en) 2016-06-19 2019-06-18 Data.World, Inc. Query generation for collaborative datasets
US11947554B2 (en) 2016-06-19 2024-04-02 Data.World, Inc. Loading collaborative datasets into data stores for queries via distributed computer networks
US10853376B2 (en) 2016-06-19 2020-12-01 Data.World, Inc. Collaborative dataset consolidation via distributed computer networks
US10353911B2 (en) 2016-06-19 2019-07-16 Data.World, Inc. Computerized tools to discover, form, and analyze dataset interrelations among a system of networked collaborative datasets
US11755602B2 (en) 2016-06-19 2023-09-12 Data.World, Inc. Correlating parallelized data from disparate data sources to aggregate graph data portions to predictively identify entity data
US11468049B2 (en) 2016-06-19 2022-10-11 Data.World, Inc. Data ingestion to generate layered dataset interrelations to form a system of networked collaborative datasets
US10452677B2 (en) 2016-06-19 2019-10-22 Data.World, Inc. Dataset analysis and dataset attribute inferencing to form collaborative datasets
US10645548B2 (en) 2016-06-19 2020-05-05 Data.World, Inc. Computerized tool implementation of layered data files to discover, form, or analyze dataset interrelations of networked collaborative datasets
US11023104B2 (en) * 2016-06-19 2021-06-01 data.world,Inc. Interactive interfaces as computerized tools to present summarization data of dataset attributes for collaborative datasets
US10824637B2 (en) 2017-03-09 2020-11-03 Data.World, Inc. Matching subsets of tabular data arrangements to subsets of graphical data arrangements at ingestion into data driven collaborative datasets
US11042556B2 (en) 2016-06-19 2021-06-22 Data.World, Inc. Localized link formation to perform implicitly federated queries using extended computerized query language syntax
US11036697B2 (en) 2016-06-19 2021-06-15 Data.World, Inc. Transmuting data associations among data arrangements to facilitate data operations in a system of networked collaborative datasets
US10452975B2 (en) 2016-06-19 2019-10-22 Data.World, Inc. Platform management of integrated access of public and privately-accessible datasets utilizing federated query generation and query schema rewriting optimization
US10747774B2 (en) 2016-06-19 2020-08-18 Data.World, Inc. Interactive interfaces to present data arrangement overviews and summarized dataset attributes for collaborative datasets
US11941140B2 (en) 2016-06-19 2024-03-26 Data.World, Inc. Platform management of integrated access of public and privately-accessible datasets utilizing federated query generation and query schema rewriting optimization
US11334625B2 (en) 2016-06-19 2022-05-17 Data.World, Inc. Loading collaborative datasets into data stores for queries via distributed computer networks
US11042560B2 (en) 2016-06-19 2021-06-22 data. world, Inc. Extended computerized query language syntax for analyzing multiple tabular data arrangements in data-driven collaborative projects
US11036716B2 (en) 2016-06-19 2021-06-15 Data World, Inc. Layered data generation and data remediation to facilitate formation of interrelated data in a system of networked collaborative datasets
US10540516B2 (en) 2016-10-13 2020-01-21 Commvault Systems, Inc. Data protection within an unsecured storage environment
US10389810B2 (en) 2016-11-02 2019-08-20 Commvault Systems, Inc. Multi-threaded scanning of distributed file systems
US10922189B2 (en) 2016-11-02 2021-02-16 Commvault Systems, Inc. Historical network data-based scanning thread generation
US10552408B2 (en) * 2016-11-02 2020-02-04 Oracle International Corporation Automatic linearizability checking of operations on concurrent data structures
US11238109B2 (en) 2017-03-09 2022-02-01 Data.World, Inc. Computerized tools configured to determine subsets of graph data arrangements for linking relevant data to enrich datasets associated with a data-driven collaborative dataset platform
US10984041B2 (en) 2017-05-11 2021-04-20 Commvault Systems, Inc. Natural language processing integrated with database and data storage management
US10642886B2 (en) 2018-02-14 2020-05-05 Commvault Systems, Inc. Targeted search of backup data using facial recognition
US10922308B2 (en) 2018-03-20 2021-02-16 Data.World, Inc. Predictive determination of constraint data for application with linked data in graph-based datasets associated with a data-driven collaborative dataset platform
US11243960B2 (en) 2018-03-20 2022-02-08 Data.World, Inc. Content addressable caching and federation in linked data projects in a data-driven collaborative dataset platform using disparate database architectures
US11947529B2 (en) 2018-05-22 2024-04-02 Data.World, Inc. Generating and analyzing a data model to identify relevant data catalog data derived from graph-based data arrangements to perform an action
USD940732S1 (en) 2018-05-22 2022-01-11 Data.World, Inc. Display screen or portion thereof with a graphical user interface
USD940169S1 (en) 2018-05-22 2022-01-04 Data.World, Inc. Display screen or portion thereof with a graphical user interface
US11442988B2 (en) 2018-06-07 2022-09-13 Data.World, Inc. Method and system for editing and maintaining a graph schema
US11159469B2 (en) 2018-09-12 2021-10-26 Commvault Systems, Inc. Using machine learning to modify presentation of mailbox objects
US11200235B1 (en) 2018-10-26 2021-12-14 United Services Automobile Association (Usaa) Method and system for improving performance of an issue management system
DE102019108856A1 (de) * 2019-04-04 2020-10-08 Bundesdruckerei Gmbh Datenbankübergreifender Index auf einem verteilten Datenbanksystem
CN112307012A (zh) * 2019-07-30 2021-02-02 中科云谷科技有限公司 海量工业数据存储和读取方法
US11494417B2 (en) 2020-08-07 2022-11-08 Commvault Systems, Inc. Automated email classification in an information management system
US11947600B2 (en) 2021-11-30 2024-04-02 Data.World, Inc. Content addressable caching and federation in linked data projects in a data-driven collaborative dataset platform using disparate database architectures

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19538448A1 (de) * 1995-10-16 1997-04-17 Hayno Dipl Ing Rustige Datenbankmanagementsystem sowie Datenübertragungsverfahren

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4916605A (en) * 1984-03-27 1990-04-10 International Business Machines Corporation Fast write operations
JPS61204733A (ja) * 1985-03-07 1986-09-10 Oki Electric Ind Co Ltd 視野管理システム
US4918593A (en) * 1987-01-08 1990-04-17 Wang Laboratories, Inc. Relational database system
EP0320266A3 (de) 1987-12-11 1992-03-11 Hewlett-Packard Company Zusammensetzung von Ansichten in einem Datenbankverwaltungssystem
US5918225A (en) * 1993-04-16 1999-06-29 Sybase, Inc. SQL-based database system with improved indexing methodology
US5557970A (en) * 1994-01-10 1996-09-24 The United States Of America As Represented By The Secretary Of The Army Automated thickness measurement system
US5499359A (en) * 1994-01-18 1996-03-12 Borland International, Inc. Methods for improved referential integrity in a relational database management system
US5729730A (en) * 1995-03-28 1998-03-17 Dex Information Systems, Inc. Method and apparatus for improved information storage and retrieval system
US6070160A (en) * 1995-05-19 2000-05-30 Artnet Worldwide Corporation Non-linear database set searching apparatus and method
US5991741A (en) * 1996-02-22 1999-11-23 Fox River Holdings, L.L.C. In$ite: a finance analysis model for education
US5842196A (en) * 1996-04-03 1998-11-24 Sybase, Inc. Database system with improved methods for updating records
US5970490A (en) * 1996-11-05 1999-10-19 Xerox Corporation Integration platform for heterogeneous databases
US6175841B1 (en) * 1997-07-17 2001-01-16 Bookette Software Company Computerized systems for producing on-line instructional materials
US6112049A (en) * 1997-10-21 2000-08-29 The Riverside Publishing Company Computer network based testing system
US6009432A (en) * 1998-07-08 1999-12-28 Required Technologies, Inc. Value-instance-connectivity computer-implemented database
US6181910B1 (en) * 1998-09-03 2001-01-30 David A. Jerrold-Jones Portable automated test scoring system and method
US20030017442A1 (en) * 2001-06-15 2003-01-23 Tudor William P. Standards-based adaptive educational measurement and assessment system and method

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19538448A1 (de) * 1995-10-16 1997-04-17 Hayno Dipl Ing Rustige Datenbankmanagementsystem sowie Datenübertragungsverfahren

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
BERGNER,Klaus, u.a.: Pflegeleicht. In: iX Multiuser Multitasking Magazin, 11/1995, S.172- S.177 *

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6636600B1 (en) 1999-05-05 2003-10-21 Siemens Aktiengesellschaft Method for finding a contact or for setting up a connection to the contact
DE19951756A1 (de) * 1999-10-27 2001-05-10 Lech Elek Zitaetswerke Ag Verfahren zur Datenverwaltung
DE19951756B4 (de) * 1999-10-27 2004-02-12 Lechwerke Ag Verfahren zur Datenverwaltung sowie Computerprogramm und -system zu dessen Ausführung
DE10001613A1 (de) * 2000-01-17 2001-08-02 Tiscon Ag Science Park Verfahren zur Verwaltung von Datensätzen
DE10001613C2 (de) * 2000-01-17 2002-08-14 Tiscon Ag Verfahren sowie Datenverarbeitungsanlage zur Verwaltung von Datensätzen
WO2020201249A1 (de) * 2019-04-04 2020-10-08 Bundesdruckerei Gmbh Maschinelles lernen auf basis von trigger-definitionen
WO2020201247A1 (de) * 2019-04-04 2020-10-08 Bundesdruckerei Gmbh Automatisiertes maschinelles lernen auf basis gespeicherten daten
EP3948578A1 (de) * 2019-04-04 2022-02-09 Bundesdruckerei GmbH Maschinelles lernen auf basis von trigger-definitionen

Also Published As

Publication number Publication date
EP0910829B1 (de) 2004-03-03
DE59711376D1 (de) 2004-04-08
AU3538697A (en) 1998-02-02
US6772164B2 (en) 2004-08-03
US20020133476A1 (en) 2002-09-19
WO1998001808A1 (de) 1998-01-15
EP0910829A1 (de) 1999-04-28

Similar Documents

Publication Publication Date Title
EP0910829B1 (de) Datenbanksystem
EP0855062B1 (de) Informationssystem und verfahren zur speicherung von daten in einem informationssystem
DE69531599T2 (de) Verfahren und Gerät zum Auffinden und Beschaffen personalisierter Informationen
DE60002876T2 (de) Darstellung, verwaltung und synthese von technischen inhalten
DE60121231T2 (de) Datenverarbeitungsverfahren
DE60025778T2 (de) Verfahren zum Speichern und Verwalten von Daten
DE69628374T2 (de) Datenverwaltungssystem
DE3911465A1 (de) Verfahren zur konfiguration technischer systeme aus komponenten
DE60310881T2 (de) Methode und Benutzerschnittstelle für das Bilden einer Darstellung von Daten mit Meta-morphing
EP1276056B1 (de) Verfahren zum Verwalten einer Datenbank
EP1166228B1 (de) Verfahren zur nutzung von fraktalen semantischen netzen für alle arten von datenbank-anwendungen
EP0788632B1 (de) Computergestützte umwandlung von tabellen
WO2000054167A2 (de) Such- und navigationseinrichtung für hypertext-dokumente
DE3629404A1 (de) Benutzerprogrammierbare datenverarbeitungsanlage
EP1224579A2 (de) Verfahren zur behandlung von datenobjekten
DE10057634C2 (de) Verfahren zur Verarbeitung von Text in einer Rechnereinheit und Rechnereinheit
DE19729911A1 (de) System zur Verbesserung der Organisation von Daten einer Dokumentation
EP1431885A2 (de) Verfahren zur Auswahl von Datensätzen
EP1515244A2 (de) Abbildung einer Klassenhierarchie auf ein relationales Datenbanksystem
DE10016337B4 (de) Verfahren und Vorrichtung zur Erzeugung und Verarbeitung von Daten durch einen aktiven Strukturbaum
EP2050022A1 (de) Verfahren zur herstellung skalierbarer bildmatrizen
DE102004043175A1 (de) Grafische Benutzeroberfläche, Computervorrichtung, Verwendung, Verfahren zur Darstellung von Informationen mit einer Benutzeroberfläche, Computerprogramm-Produkt und computerlesbares Medium
EP0572749A1 (de) Datenbank in einer EDV-Anlage
WO2020094175A1 (de) Verfahren und vorrichtung zum speichern von daten und deren beziehungen
WO2004095313A1 (de) Datenverarbeitungssystem für benutzerfreundliche datenbank-recherchen

Legal Events

Date Code Title Description
OM8 Search report available as to paragraph 43 lit. 1 sentence 1 patent law
8127 New person/name/address of the applicant

Owner name: SER SYSTEMS AG, 53577 NEUSTADT, DE

8139 Disposal/non-payment of the annual fee