WO2002075589A2 - Datenbanksystem - Google Patents

Datenbanksystem Download PDF

Info

Publication number
WO2002075589A2
WO2002075589A2 PCT/DE2002/000945 DE0200945W WO02075589A2 WO 2002075589 A2 WO2002075589 A2 WO 2002075589A2 DE 0200945 W DE0200945 W DE 0200945W WO 02075589 A2 WO02075589 A2 WO 02075589A2
Authority
WO
WIPO (PCT)
Prior art keywords
data
entry
database system
column
database
Prior art date
Application number
PCT/DE2002/000945
Other languages
English (en)
French (fr)
Other versions
WO2002075589A3 (de
Inventor
Martin GÖTTMANN
Original Assignee
Bfm Building + Facility Management Gmbh
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 Bfm Building + Facility Management Gmbh filed Critical Bfm Building + Facility Management Gmbh
Priority to EP02729794A priority Critical patent/EP1374100A2/de
Publication of WO2002075589A2 publication Critical patent/WO2002075589A2/de
Publication of WO2002075589A3 publication Critical patent/WO2002075589A3/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/289—Object oriented databases
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/284—Relational databases

Definitions

  • the present invention relates to a database system which is based in particular on a relational database in which a database consisting of a multiplicity of data fields is stored, and a method for storing, changing and displaying the database.
  • the term database is understood to have been published by DTV Verlag in its original meaning as a structured, content-related database, such as addresses, customer or employee data.
  • a database is usually used to refer to the application program that is used to manage the database.
  • the data itself is called the database or database.
  • a so-called database management system accesses this database, displays components of the database, and is able to modify the database and search for components.
  • a database consists of a series of data records, each of which in turn is composed of a series of data fields.
  • each address corresponds to a record and each part of the address corresponds to a field.
  • FIG. 1 shows a conventional data record 100 that comes from an address database.
  • the data record 100 consists of the data fields 110 last name, first name, street, city and telephone.
  • the last name field contains the name Huber
  • the first name field contains Henriette, etc.
  • These data field details 120 are also referred to below as data field contents or merely contents.
  • the structure of the data records is determined when the database is created. To do this, you specify which data fields make up a data record and how much space should be reserved for each data field. The structure of some programs can be changed later. You can insert data fields or enlarge or reduce the space reserved for a data field. Depending on the definition of the database structure, the data for the individual data records are then entered.
  • This type of structured storage of the data means that for each storage or storage of a data record it is assumed that the structure of the data record to be stored or saved corresponds at least to a substructure of the database. However, if a data record is to be saved that does not correspond in its structure to the existing data structures or parts thereof, the database itself must be expanded by the new structural element (field / fields) before the data record can be saved, i.e. columns are added to the table. This can lead to redundancies, since the "old" data records may not have any information regarding the new columns.
  • a special problem is the storage of data records with a new data record structure. This data record structure must be defined by the user. This requires changes in the database management system and in the application programs that work with this database.
  • FIGS. 2 and 3 show examples of such conventional databases displayed in tabular form, FIG. 2 showing a database in which customer addresses are stored, and FIG. 3 a further database in which individual orders are stored and which is related to the customer database are.
  • FIG. 2 there are several vertical ones Records 200 shown.
  • each data record 300 is on its own line, the data of the individual fields are arranged in columns.
  • the meaning of the column is interchanged with that of the row.
  • the conventional database can be searched for individual data records or for those data records that meet one or more criteria.
  • the data records found can be displayed or printed out in list or form form. Only one record is displayed in form mode.
  • the data records can be sorted according to one or more fields for display or printing.
  • a so-called index must be created for the fields to be sorted.
  • the index is usually saved in a separate file and speeds up sorting and
  • Some database programs allow very complex databases to be created that can be used by other users, even though these users do not have the database program at all.
  • Databases that are based on a fixed structure are well suited for managing data that is always the same or at least very similar. They are hardly suitable for managing unstructured data or data with an inhomogeneous structure. Even a database with data of different lengths cannot be created with every data program. Some conventional programs offer so-called memo fields, the lengths of which can usually be several KB. If several fields of this type are required or if structuring is not possible, a text-oriented database program, a so-called full-text database, is required allows unstructured data entry and still enables the selection and linking of data records.
  • An alternative for such tasks are object-oriented databases.
  • An important distinguishing criterion for databases and at the same time decisive for the performance of the program is the database model used, which is also referred to as the data model and defines the relationships of the individual data. Two data models are described in more detail below.
  • the hierarchical data model In such a database, the individual data records are stored in a tree structure, similar to a hierarchical file system. This data model is widely used. If two data are linked, you can assign exactly one data record from the other database to each data record from one database; multiple links existing at the same time are not permitted.
  • the hierarchical data model is difficult to reconcile with typical data structures that occur in practice. For example, the individual employees - broken down by departments and projects - could be stored in a database. In practice, however, it often happens that individual employees work for different departments and on several projects.
  • the basis of this model is a table-like structure. Each row of the table represents a data record, which is also called a tuple; the individual columns contain the data fields.
  • a relationship that is, a relationship, between different databases.
  • a customer database could be linked to a database in which the orders received are stored (see FIGS. 2 and 3), and the address and the respective orders are displayed for each or for selected customers.
  • Such databases are indispensable for more complex applications, for example in order processing in companies. Problems arise when introducing additional data values or
  • An object of the invention is to provide a database system which has no restriction with regard to the content and with regard to extensions of the data structures and the portability to other relational
  • Another task is to completely avoid redundancies.
  • Figure 1 shows a conventional data set from a
  • FIG. 2 shows a conventional tabular database in which customer addresses are stored.
  • FIG. 3 shows a further conventional database in which individual orders are stored and which is related to
  • FIG. 4 shows an embodiment of the present invention.
  • Figure 5 shows a four-column table of values according to the present
  • Figure 6 shows an object table according to the present invention.
  • Figure 7 shows an attribute table according to the present invention.
  • Figure 8 shows a table of contents according to the present invention.
  • Figure 9 shows hierarchically structured local references.
  • Figure 4 illustrates an embodiment of the present invention.
  • a data field of an object In the database system according to the invention, several tables are used to define a data field of an object. Note that this is a data field of an object and not a data field of a data record.
  • an object is equivalent to one or more conventional data records.
  • the conventional data record was characterized in that it corresponded, for example, to a line in a relational (tabular) database base, the number of data fields belonging to the data record being determined by the number of columns in the database.
  • the possible content, the order and the data format of a Data field was determined by the column, the column order and the column unit.
  • a large library wants to store its inventory electronically in the form of a relational database. But not only the books of the library, but also every other object such as chairs, tables, shelves, etc. should be recorded. Contracts that the library has concluded with other libraries on the loan of books are even conceivable as additional items. All of these objects are objects.
  • the objects can be assigned to different object types, which can be created as desired by the user of the database according to the invention. For example, all paperbacks, lexicons, novels, non-fiction books or the like could belong as objects to the object type book. Tables, chairs and shelves could belong to the object type of furniture.
  • the object type furniture can be characterized by properties such as price, width, height, depth or the like.
  • each data record would contain all the properties of all possible objects in the form of a data field, i.e. a column would have to be created in the conventional tabular database for each different object property, this would result in a table of considerable size to lead. This is the only way to ensure that any object, no matter what Object types he heard can be recorded in the database. This also leads to a considerable number of redundancies.
  • Another possibility to solve this problem would be to create different database tables, whereby a separate table would have to be created for each object type.
  • Each conventional data field (i.e. property of an object) is stored in the database according to one embodiment as a row in a four-column so-called value table.
  • the table of values 400 is shown in the middle in FIG.
  • the four columns of the value table 400 are illustrated schematically by the four references WertID 472, txt 463, tag 433 and obj 443.
  • Column 463, designated “txt” references a content table 460, which also has two columns 461 and 462, which are designated "TXT" and "TxtlD”.
  • Column 433 labeled "tag” references an attribute table 430 that has two columns 431 and 432 that are labeled "TAG" and "TagID”.
  • FIG. 5 shows a value table 500 which corresponds in structure to the value table 400 from FIG. 4 in greater detail.
  • the value table 500 is formed from four columns.
  • Column 572 labeled "WertID” contains sequential numbers. The serial numbers uniquely identify a data field, ie each data field is assigned a single number and vice versa.
  • Column 563 designated “txt”, contains content references that can be assigned several times to different data fields and each clearly refer to an entry in content table 460 in FIG. 4. Simply put, there are pointers in the respective fields of this column, that point to the content of the respective data field, such as the first name Max. However, this first name can be assigned to several people who are stored in the database. "Max" could just as well be used as a surname, company name or other name.
  • a column 533 labeled "tag" contains attribute references that can be assigned several times to different data fields and also uniquely refer to an entry in the attribute table 430 in FIG.
  • the fields in the third column are equivalent to pointers that reference data field or object properties (ie, for example, field names 110 of FIG. 1) or attributes.
  • a table of contents is shown in detail in FIG. 8, which will be discussed in more detail later.
  • the attributes of different objects which, however, belong to the same object type, can occur more than once, which means that, figuratively speaking, several pointers from the third column can point to an identical entry in the attribute table.
  • obj contains object references which can be assigned several times to different data fields and each clearly refer to an entry in the object table 440 in FIG. Similar to the two previous columns, the fields of the "obj" column are pointers that point to an object stored in the object table. Again, multiple pointers can point to the same object. This becomes clear when you consider that an object can have several different properties, ie several combinations of one and the same element of the "obj" column 543 with several different elements of the third column "tag" 533 such as book - author, book - Year of publication or similar are conceivable.
  • FIG. 6 shows an object table 640 which contains example values and whose functionality corresponds to the object table 440 of FIG. 4.
  • the object table 640 is constructed in two columns.
  • a first column 641 is labeled "OBJ”.
  • a second column 642 is called "ObjID”.
  • the entries in the object table 640 consist of two entry parts, namely a first entry part corresponding to an element of the first column "OBJ", which represents a reference to another object, and a second entry part belonging to this first entry part corresponding to the "ObjID” column.
  • the functionality of the first entry part, corresponding to column 641 "OBJ" will be discussed in more detail below.
  • the object table 640 not only uniquely identifies an object (in the sense of any object in the example of the library), but also at the same time a reference to a hierarchically arranged one
  • This hierarchically arranged reference system can, for example, be based on a spatial reference system such as the
  • the location reference system could also be the building of the library as such.
  • the building in turn can be divided into individual floors. These floors can be divided into individual rooms. The breakdown just carried out has to the next smaller local area
  • the location references are a hierarchical structure of a location that provides information about the "who” and "where", i.e. which object is in which location.
  • each object has exactly one location reference, i.e. a father to be referred
  • the attribute table 730 contains example entries suitable for FIGS. 5 and 6. Like the object table 640 of FIG. 6, it is also arranged in two columns.
  • the first column 731 is labeled "TAG”.
  • the second column 732 is labeled "TagID”.
  • An entry (i.e. a row) in the attribute table 730 thus consists of two parts.
  • the first entry part TAG is basically divided into three parts, which are separated by a period. These three components designate the first - the already mentioned - object type, the second a data field name and the third an attribute that can be understood as a unit in this context.
  • the data field name corresponds to the field names or column headings.
  • the third component of the first entry part represents a unit size that describes the content of the associated data field in more detail. Possible unit sizes are, for example, "Text”, “Number”, “Currency”, or "Date”.
  • a second entry part TagID belonging to the first entry part corresponds to one of the entries in column 533 of the value table 500 in FIG. 5 and represents the target of the pointer designated there. The TagID changes from the value table 500 in FIG. 5 to the attribute table 730 in FIG referenced.
  • the first entry part of an entry in the attribute table 730 can thus have a structure of the type "object type._object ID ._. ID_" (see also TAG for TagID 362).
  • a content table 860 is shown in FIG. 8, the functionality of which corresponds to the content table 460 of FIG. 4.
  • the content table 860 also has two columns.
  • the first column 861 is labeled "TXT”.
  • the second column 862 is called "TxtlD”.
  • the entries in the content table 860 in FIG. 8 are exemplary and match the entries shown in FIGS. 5, 6 and 7.
  • the content references contained in column 563 of value table 500 in FIG. 5 refer to a second entry part (TxtID) of an entry in content table 860.
  • a first entry part belonging to the second part represents the content of the data field. For example, the data field with the value ID "12" from FIG.
  • FIG. 9 the relationship between the objects in the form of a location reference given in connection with FIG. 6 is once again illustrated by way of example.
  • the location reference organizes information hierarchically according to the location it concerns or where it occurs.
  • a further embodiment of the invention allows the time assignment of objects. For example, one might be interested - to stay in the picture of the example above - where a book XY from the library, which is currently in room Z on the first floor, was previously located before being placed in this room. To do this, it would be necessary to also include temporal information from the value table 500 in FIG can see. This is achieved by defining an additional column that contains time references. Similar to the location references, these time references refer to a time table (not shown). This time table is also created in two columns. The first column again contains references between objects, the second column contains the associated time references (time ID, not shown), to which the time pointers from the further column of the value table point.
  • Object types For example, a paperback ABC - as mentioned at the beginning - belongs to the object type book. No associated object exists yet
  • Databases are subject to freely definable access rights. A distinction is made between the access rights “write &read”,”read” and “no access”. The rights are organized in so-called user groups. A user is always associated with at least one user group. An object or location reference is only then visible to a user group , if the "Write &Read” or "Read” right has been assigned to the object concerned. As soon as one object is open for write access, all others receive read and Authorized users only have the "Read” right during this time. As soon as the write access has ended, the write rights are also available to other users.
  • Search language can be used, for example, SQL (Structured Query Language).
  • the search enables the targeted finding of objects, for example in relation to location.
  • the location reference can be limited by navigating into the desired location reference (as shown for example in FIG. 9).
  • the advanced search also offers the possibility to search for specific information within objects, i.e. for example, to search for a specific property. All properties of the object are shown. If no object is selected in the advanced search, the field entries of all objects are available to refine the search.
  • the database system itself works with indexes of the tables wherever possible, which is favorable for data processing systems.
  • An advantageous aspect is the avoidance of redundancies.
  • Object-oriented data access is possible. No additional tables are created when adding new object types. There are detailed or combined search options up to full-text searches.
  • the data model according to the present invention is based on the standardized, relational database model, which represents considerable advantages with regard to the importability of data, since it can be used independently of the respective software manufacturer. Data export to XML is also possible.
  • Another advantage is that objects can be linked together using a standardized mechanism. It is clear to a person skilled in the field of software engineering that the table of values can be transposed, ie rows can be exchanged with columns and vice versa, without changing the functionality of the invention. The same applies to the structure of the three or further tables.
  • a computer program product can be represented by any suitable storage medium on which the computer program that carries out the method according to the present invention is stored.

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

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

Description

Datenbanksystem
Die vorliegende Erfindung betrifft ein Datenbanksystem, das insbesondere auf einer relationalen Datenbank basiert, bei dem eine Datenbasis, die aus einer Vielzahl von Datenfeldern besteht, gespeichert wird, und ein Verfahren zur Speicherung, Änderung und Anzeige der Datenbasis.
Unter dem Begriff Datenbank versteht man gemäß dem "Computer- Lexikon", 3. Aufl., 1998, S. 196 ff., erschienen im DTV Verlag, in der ursprünglichen Bedeutung einen strukturierten, inhaltlich zusammengehörigen Datenbestand, wie zum Beispiel Adressen, Kunden- oder Mitarbeiterdaten. Meist jedoch wird mit einer Datenbank das Anwendungsprogramm bezeichnet, das zur Verwaltung des Datenbestands dient. Die Daten selbst nennt man Datenbasis oder Datenbestand. Ein sogenanntes Datenbank-Managementsystem greift auf diese Datenbasis zu, zeigt Bestandteile der Datenbasis an, und ist fähig, die Datenbasis zu modifizieren und nach Bestandteilen zu suchen.
Bei bekannten Datenbanksystemen wird dabei die Datenbasis in strukturierter Form abgespeichert, gemäß dem Stand der Technik in Tabellenform. Eine Datenbasis besteht aus einer Reihe von Datensätzen, von denen sich jeder wiederum aus einer Reihe von Datenfeldern zusammensetzt. Bei einer Adreßdatenbank zum Beispiel entspricht jede Adresse einem Datensatz, und jeder Bestandteil der Adresse einem Feld.
In der Figur 1 ist ein herkömmlicher Datensatz 100 dargestellt, der aus einer Adreßdatenbank stammt. Der Datensatz 100 besteht aus den Datenfeldern 110 Nachname, Vorname, Straße, Ort und Telefon. Beim gezeigten Datensatz der Figur 1 enthält das Feld Nachname den Namen Huber, das Feld Vorname die Angabe Henriette usw. Diese Datenfeldangaben 120 werden im nachfolgenden auch als Datenfeldinhalte bzw. lediglich Inhalte bezeichnet. Die Struktur der Datensätze wird beim Anlegen der Datenbasis festgelegt. Dazu gibt man an, aus welchen Datenfeldern sich ein Datensatz zusammensetzt und wieviel Platz für jedes Datenfeld reserviert werden soll. Bei einigen Programmen läßt sich die Struktur nachträglich ändern. So kann man Datenfelder einfügen oder den für ein Datenfeld reservierten Platz vergrößern oder verkleinern. Je nach der Definition der Datenbankstruktur werden dann die Daten für die einzelnen Datensätze eingegeben.
Dies ist jedoch nicht immer so. Diese Art von strukturierter Abspeicherung der Daten bedeutet, daß für jede Ablage bzw. Abspeicherung von einem Datensatz vorausgesetzt wird, daß der Datensatz, der abzulegen bzw. abzuspeichern ist, in seiner Struktur zumindest mit einer Teilstruktur der Datenbank übereinstimmt. Soll aber ein Datensatz abgespeichert werden, der in seiner Struktur nicht den vorhandenen Datenstrukturen bzw. Teilen davon entspricht, so muß die Datenbank selbst um das neue Strukturelement (Feld/Felder) erweitert werden, bevor der Datensatz abgespeichert werden kann, d.h. in der Tabelle werden Spalten hinzugefügt. Dies kann zu Redundanzen führen, da die "alten" Datensätze eventuell keine Informationen bezüglich den neuen Spalten besitzen.
Ein besonderes Problem stellt die Speicherung von Datensätzen mit einer neuen Datensatzstruktur dar. Diese Datensatzstruktur muß vom Anwender definiert werden. Hierfür sind Änderungen im Datenbank-Managementsystem und in den Anwendungsprogrammen, die mit dieser Datenbank arbeiten, nötig.
Zur Anzeige der Daten bieten die meisten Programme einen sogenannten Listenmodus (auch Browse-Modus genannt) und einen Formularmodus. Im Listenmodus werden alle bzw. ausgewählte Datensätze in tabellarischer Form angezeigt. Die Figuren 2 und 3 zeigen Beispiele solcher herkömmlichen tabellarisch angezeigten Datenbanken, wobei in Figur 2 eine Datenbank, in der Kundenadressen gespeichert sind, und in Figur 3 eine weitere Datenbank, in der einzelne Aufträge gespeichert sind, und die in Relation zur Kundendatenbank steht, dargestellt sind. In Figur 2 sind mehrere vertikale Datensätze 200 dargestellt. In Figur 3 steht jeder Datensatz 300 in einer eigenen Zeile, die Daten der einzelnen Felder sind spaltenweise angeordnet. In Figur 2 ist die Bedeutung der Spalte mit der der Zeile vertauscht.
Die herkömmliche Datenbank kann nach einzelnen Datensätzen oder nach solchen Datensätzen durchsucht werden, die einem oder mehreren Kriterien entsprechen. Die Kriterien lassen sich gewöhnlich über Operatoren wie >, <, =, UND (AND), ODER (OR) oder NICHT (NOT) festlegen und miteinander verknüpfen - also zum Beispiel alle mit Namen Müller aus München; alle Müller, die nicht in München wohnen; alle Müller aus München und alle Schmidt aus Hamburg. Die gefundenen Datensätze können angezeigt oder in Listen- oder Formularform ausgedruckt werden. Im Formularmodus wird jeweils nur ein Datensatz angezeigt.
Für die Anzeige bzw. den Ausdruck lassen sich die Datensätze nach einem oder mehreren Feldern sortieren. Bei vielen Programmen muß dazu für die zu sortierenden Felder ein sogenannter Index angelegt werden. Der Index wird meist in einer eigenen Datei gespeichert und beschleunigt Sortier- und
Suchvorgänge.
Einige Datenbankprogramme erlauben es, sehr komplexe Datenbanken zu erstellen, die von anderen Anwendern benutzt werden können, obwohl diese Anwender gar nicht über das Datenbankprogramm verfügen.
Datenbanken, die auf einer festen Struktur basieren, eignen sich gut zur Verwaltung von Daten, die immer gleich oder zumindest sehr ähnlich aufgebaut sind. Zur Verwaltung unstrukturierter Daten oder von Daten mit inhomogener Struktur sind sie kaum geeignet. Bereits eine Datenbank mit Daten unterschiedlicher Länge läßt sich nicht mit jedem Datenprogramm anlegen. Manche herkömmlichen Programme bieten dafür sogenannte Memo-Felder an, deren Längen meist mehrere KByte umfassen darf. Sind mehrere derartige Felder erforderlich oder sollte eine Strukturierung nicht möglich sein, benötigt man ein textorientiertes Datenbankprogramm, eine sogenannte Volltext-Datenbank, das die unstrukturierte Dateneingabe erlaubt und dennoch das Selektieren und Verknüpfen von Datensätzen ermöglicht.
Eine Alternative für derartige Aufgabenstellungen sind objektorientierte Datenbanken. Ein wesentliches Unterscheidungskriterium bei Datenbanken und gleichzeitig ausschlaggebend für die Leistungsfähigkeit des Programms ist das verwendete Datenbankmodell, das auch als Datenmodell bezeichnet wird und die Beziehungen der einzelnen Daten definiert. Im nachfolgenden werden zwei Datenmodelle genauer beschrieben.
Zum einen gibt es das hierarchische Datenmodell. In einer derartigen Datenbank sind die einzelnen Datensätze in einer Baumstruktur gespeichert, ähnlich wie bei einem hierarchischen Dateisystem. Dieses Datenmodell ist weit verbreitet. Werden zwei Daten verknüpft, so kann man jedem Datensatz der einen Datenbank genau einen Datensatz der anderen Datenbank zuordnen; mehrere gleichzeitig bestehende Verknüpfungen sind nicht erlaubt. Das hierarchische Datenmodell ist nur schwer mit typischen in der Praxis vorkommenden Datenstrukturen vereinbar. Beispielsweise könnten in einer Datenbank die einzelnen Mitarbeiter - aufgegliedert nach Abteilungen und Projekten - gespeichert werden. Doch in der Praxis kommt es häufig vor, daß einzelne Mitarbeiter für verschiedene Abteilungen und an mehreren Projekten arbeiten.
Ein weiteres häufig benutztes Datenmodell stellt die relationale Datenbank dar. Grundlage dieses Modells ist eine tabellenartige Struktur. Jede Zeile der Tabelle stellt einen Datensatz dar, der auch Tupel genannt wird; die einzelnen Spalten enthalten die Datenfelder. Bei derartigen Datenbanken kann man eine Beziehung, also eine Relation, zwischen verschiedenen Datenbeständen aufbauen. So könnte zum Beispiel eine Kundendatenbank mit einer Datenbank verknüpft werden, in der die eingegangenen Aufträge gespeichert sind (vgl. Figuren 2 und 3), und für jeden bzw. für ausgewählte Kunden die Adresse und die jeweiligen Aufträge angezeigt werden. Für komplexere Anwendungen, zum Beispiel bei der Auftragsabwicklung in Firmen, sind derartige Datenbanken unerläßlich. Probleme ergeben sich bei der Einführung zusätzlicher Datenwerte oder
Datenobjekte, die umfangreiche Änderungen an der Tabellendefinition erforderlich machen. Die relationale Datenbank führt bei ähnlichen Datenobjekten zu redundanten Inhalten, denen zum Teil durch die Auslagerung und Referenzierung in weiteren Tabellen begegnet wird, ohne diese vollständig zu unterbinden.
Eine Aufgabe der Erfindung ist es, ein Daten banksystem vorzusehen, das keine Beschränkung bezüglich der Inhalte aufweist und im Hinblick auf Erweiterungen der Datenstrukturen und der Übertragbarkeit auf andere relationale
Datenbanksysteme verschiedener Hersteller ohne Änderung der
Tabellendefinitionen erweiterbar ist.
Eine weitere Aufgabe ist es, Redundanzen vollständig zu vermeiden.
Des weiteren soll ein Verfahren vorgesehen werden, das es erlaubt, Operationen in einem Datenbanksystem durchzuführen, das die oben beschriebenen Probleme löst.
Die Lösung der oben beschriebenen Probleme findet sich in den beigefügten Ansprüche wieder, wobei die vorliegende Erfindung durch die unabhängigen Ansprüche definiert wird. Bevorzugte Ausführungsformen werden in den abhängigen Ansprüchen beschrieben.
Die vorliegende Erfindung, deren Merkmale, Verwendungszwecke und
Vorteile werden aus der folgenden Beschreibung der bevorzugten Ausführungsformen, wie sie in den beigefügten Zeichnungen veranschaulicht sind, deutlicher werden.
Figur 1 zeigt einen herkömmlichen Datensatz aus einer
Adreßdatenbank. Figur 2 zeigt eine herkömmliche tabellarische Datenbank, in der Kundenadressen gespeichert sind.
Figur 3 zeigt eine weitere herkömmliche Datenbank, in der einzelne Aufträge gespeichert sind und die eine Relation zur
Kundendatenbank der Figur 2 aufweist.
Figur 4 zeigt eine Ausführungsform der vorliegenden Erfindung.
Figur 5 zeigt eine vierspaltige Wertetabelle gemäß der vorliegenden
Erfindung.
Figur 6 zeigt eine Objekttabelle gemäß der vorliegenden Erfindung.
Figur 7 zeigt eine Attributtabelle gemäß der vorliegenden Erfindung.
Figur 8 zeigt eine Inhaltstabelle gemäß der vorliegenden Erfindung.
Figur 9 zeigt hierarchisch gegliederte Ortsbezüge.
Die Figur 4 veranschaulicht eine Ausführungsform der vorliegenden Erfindung. Im erfindungsgemäßen Datenbanksystem werden mehrere Tabellen zur Festlegung eines Datenfelds eines Objekts verwendet. Man beachte, daß hier von einem Datenfeld eines Objekts und nicht von einem Datenfeld eines Datensatzes gesprochen wird. Im nachfolgenden ist ein Objekt äquivalent zu einem oder mehreren herkömmlichen Datensätzen. Um eine größtmögliche Flexibilität zu erreichen, was die Anzahl und den Inhalt der Datenfelder betrifft, muß man sich von der Vorstellung des herkömmlichen Datensatzes lösen. Der herkömmliche Datensatz war dadurch gekennzeichnet, daß er beispielsweise einer Zeile in einer relationalen (tabellarischen) Datenbankbasis entsprach, wobei die Anzahl der zum Datensatz gehörigen Datenfelder durch die Anzahl der Spalten der Datenbasis bestimmt war. Die möglichen Inhalte, die Reihenfolge und das Datenformat eines Datenfelds war durch die Spalte, die Spaltenreihenfolge und die Spalteneinheit festgelegt. So konnte man beispielsweise in einem Datenfeld, in dem beispielsweise Vornamen abgespeichert wurden, keine Telefonnummer eingeben, da als Eingabe Buchstaben und nicht Ziffern erwartet wurden. Um sich von dieser Vorstellung zu lösen, wird der Begriff Datensatz durch den Begriff Objekt substituiert. Unter einem Objekt ist alles zu verstehen, was im jeweiligen Anwendungsbereich sinnvollerweise in einer Datenbank zu archivieren ist.
Angenommen eine große Bibliothek möchte ihr Inventar in Form einer relationalen Datenbank elektronisch abrufbar abspeichern. Dabei sollen aber nicht nur die Bücher der Bibliothek, sondern auch jede andere Gegenstand wie etwa Stühle, Tische, Regale usw. erfaßt werden. Als weitere Gegenstände sind sogar Verträge denkbar, die die Bibliothek mit anderen Bibliotheken über die Leihe von Büchern getroffen hat. All diese Gegenstände sind Objekte. Die Objekte lassen sich verschiedenen Objekttypen zuordnen, die vom Benutzer der erfindungsgemäßen Datenbank beliebig erstellt werden können. Beispielsweise könnten alle Taschenbücher, Lexika, Romane, Sachbücher oder ähnliches als Objekte zum Objekttyp Buch gehören. Tische, Stühle und Regale könnten zum Objekttyp Möbel gehören.
Es ist leicht verständlich, daß Objekte unterschiedliche Eigenschaften aufweisen. So hat beispielsweise der Objekttyp Buch die Eigenschaften Autor,
Erscheinungsjahr, Verlag usw. Der Objekttyp Möbel dagegen kann sich beispielsweise durch Eigenschaften wie Preis, Breite, Höhe, Tiefe oder ähnliches auszeichnen.
Würde man diese Objekte als Datensätze in eine herkömmliche Tabelle eintragen, wobei jeder Datensatz alle Eigenschaften aller möglichen Objekte in Form eines Datenfeldes beinhalten würde, d.h. für jede unterschiedliche Objekteigenschaft müßte eine Spalte in der herkömmlichen tabellarischen Datenbank erzeugt werden, würde dies zu einer Tabelle erheblicher Größe führen. Nur so wäre gewährleistet, daß ein beliebiger Gegenstand, egal zu welchem Objekttypen er gehört, in der Datenbank aufgenommen werden kann. Dies führt auch zwangsweise zu einer erheblichen Vielzahl von Redundanzen.
Eine andere Möglichkeit, dieses Problem zu lösen, wäre es, verschiedene Datenbanktabellen anzulegen, wobei für jeden Objekttyp eine eigene Tabelle angelegt werden müßte.
Durch die oben beschriebenen erfindungsgemäßen Objekte lassen sich diese Probleme umgehen. Jedes herkömmliche Datenfeld (d.h. Eigenschaft eines Objekts) wird in der erfindungsgemäßen Datenbank gemäß einer Ausführungsform als Zeile in einer vierspaltigen sogenannten Wertetabelle abgespeichert. In der Figur 4 ist die Wertetabelle 400 in der Mitte dargestellt. Die vier Spalten der Wertetabelle 400 sind schematisch durch die vier Referenzen WertlD 472, txt 463, tag 433 und obj 443 veranschaulicht. Die mit "txt" bezeichnete Spalte 463 referenziert auf eine Inhaltstabelle 460, die ebenfalls zwei Spalten 461 und 462 aufweist, die mit "TXT" und "TxtlD" bezeichnet werden. Die mit "tag" bezeichnete Spalte 433 referenziert auf eine Attributtabelle 430, die zwei Spalten 431 und 432 aufweist, die mit "TAG" und "TagID" bezeichnet werden. Die mit "obj" bezeichnete Spalte 443 referenziert auf eine Objekttabelle 440, die zwei Spalten 441 und 442 aufweist, die mit "OBJ" und "ObjID" bezeichnet werden. Die mit "WertlD" bezeichnete Spalte 472 dient zur durchlaufenden Numerierung und ist für die Funktionalität der Datenbank nicht zwingend erforderlich.
In Figur 5 ist eine Wertetabelle 500, die in ihrer Struktur der Wertetabelle 400 der Figur 4 entspricht, in größerem Detail dargestellt. Die Wertetabelle 500 wird aus vier Spalten gebildet. Eine Spalte 572, die mit "WertlD" bezeichnet ist, beinhaltet laufende Nummern. Die laufenden Nummern kennzeichnen ein Datenfeld eineindeutig, d.h. jedem Datenfeld wird eine einzige Nummer zugeordnet und umgekehrt. Die mit "txt" bezeichnete Spalte 563 beinhaltet Inhaltsreferenzen, die mehrfach für verschiedene Datenfelder vergeben sein können und jeweils eindeutig auf einen Eintrag in der Inhaltstabelle 460 der Figur 4 referenzieren. Vereinfacht gesagt, in den jeweiligen Feldern dieser Spalte befinden sich Zeiger, die auf den Inhalt des jeweiligen Datenfelds wie beispielsweise den Vornamen Max zeigen. Dieser Vorname kann jedoch für mehrere Personen, die in der Datenbank abgespeichert sind, vergeben sein. Genauso gut könnte "Max" aber auch als Nachname, Firmenname oder als sonstige Bezeichnung benutzt werden. Somit erklärt sich, daß die Inhaltsreferenzen von verschiedenen Datenfeldern auf einen identischen Eintrag in der Inhaltstabelle verweisen können. Eine mit "tag" bezeichnete Spalte 533 beinhaltet Attributreferenzen, die mehrfach für verschiedene Datenfelder vergeben sein können und ebenfalls eindeutig auf einen Eintrag in der Attributtabelle 430 der Figur 4 referenzieren. Ähnlich wie bei der zweiten Spalte sind die Felder der dritten Spalte äquivalent zu Zeigern, die auf Datenfeld- bzw. Objekteigenschaften (d.h. beispielsweise auf Feldnamen 110 der Figur 1) bzw. -attribute referenzieren. Eine Inhaltstabelle ist im Detail in der Figur 8 dargestellt, auf die später genauer eingegangen werden wird. Jedoch ist klar, daß auch die Attribute von verschiedenen Objekten, die jedoch zum selben Objekttyp gehören, mehrfach auftreten können, wodurch bildhaft gesprochen mehrere Zeiger aus der dritten Spalte auf einen identischen Eintrag in der Attributtabelle zeigen können. Eine mit "obj" bezeichnete Spalte 543 der Wertetabelle 500 in der Figur 5 beinhaltet Objektreferenzen, die mehrfach für verschiedene Datenfelder vergeben sein können und jeweils eindeutig auf einen Eintrag in der Objekttabelle 440 der Figur 4 referenzieren. Ähnlich wie bei den beiden vorangegangenen Spalten stellen die Felder der "obj"-Spalte Zeiger dar, die auf ein in der Objekttabelle gespeichertes Objekt zeigen. Auch hier können mehrere Zeiger auf ein und dasselbe Objekt deuten. Dies wird klar, wenn man bedenkt, daß ein Objekt mehrere verschiedene Eigenschaften haben kann, d.h. mehrere Kombinationen aus ein und demselben Element der Spalte "obj" 543 mit mehreren verschiedenen Elementen der dritten Spalte "tag" 533 wie etwa Buch - Autor, Buch - Erscheinungsjahr oder ähnliches sind vorstellbar.
In den Figuren 6, 7 und 8 sind die in der Figur 4, mit Ausnahme der Wertetabelle 400, dargestellten Tabellen im Detail mit Beispieleinträgen gezeigt. Die Zusammenhänge mit der in der Figur 5 dargestellten Wertetabelle 500 werden nun ausführlich beschrieben werden. In Figur 6 ist eine Objekttabelle 640 gezeigt, die Beispielwerte beinhaltet und in ihrer Funktionalität der Objekttabelle 440 der Figur 4 entspricht. Die Objekttabelle 640 ist zweispaltig aufgebaut. Eine erste Spalte 641 wird mit "OBJ" bezeichnet. Eine zweite Spalte 642 wird mit "ObjID" bezeichnet. Die Einträge der Objekttabelle 640 bestehen aus zwei Eintragungsteilen, nämlich einem ersten Eintragsteil entsprechend einem Element der ersten Spalte "OBJ", der einen Bezug zu einem anderen Objekt darstellt, und aus einem zu diesem ersten Eintragsteil gehörigen zweiten Eintragsteil entsprechend der Spalte "ObjID". Auf den zweiten Eintragsteil des (allgemeinen) Typs "ID" wird aus der "obj"-Spalte der Wertetabelle 500 der Figur 5 verwiesen. Auf die Funktionalität des ersten Eintragsteils, entsprechend der Spalte 641 "OBJ" wird im folgenden näher eingegangen werden.
Über die Objekttabelle 640 wird nicht nur ein Objekt (im Sinne eines beliebigen Gegenstands im Beispiel der Bibliothek) eindeutigt gekennzeichnet, sondern auch gleichzeitig ein Bezug zu einem hierarchisch angeordneten
Bezugssystem hergestellt. Dieses hierarchisch angeordnete Bezugssystem kann beispielsweise auf einem räumlichen Bezugssystem wie etwa den
XYZ-Koordinaten eines Objekts basieren. Im oben genannten Beispiel der Bibliothek könnte das Ortsbezugssystem auch das Gebäude der Bibliothek als solches sein. Das Gebäude wiederum läßt sich untergliedern in einzelne Etagen bzw. Stockwerke. Diese Stockwerke kann man in einzelne Zimmer aufteilen. Die eben durchgeführte Gliederung hat sich jeweils auf die nächstkleinere örtliche
Einheit bezogen. Genausogut ist eine Erweiterung des Bezugssystems denkbar, indem man vom Gebäude zur Stadt, zum Land usw. geht. Die Ortsbezüge sind eine hierarchische Gliederung eines Ortes, der eine Auskunft über das "Wer" und "Wo" gibt, d.h. welches Objekt sich an welchem Ort befindet.
In dem in der Figur 6 dargestellten Beispiel der Objekttabelle 640 gibt es zwei verschiedene Eintragstypen für den ersten Eintragsteil, der einem Element der
Spalte 641 "OBJ" entspricht. Dies ist einmal der Typ "Parent=" und zum anderen der Typ "Ref=". Der Bezugstyp Parent trifft eine Aussage bezüglich der hierarchischen Anordnung der Objekte. Das höchste Objekt in der Objekthierarchie trägt die Objekt-ID "0". Dem sogenannten Ursprungsobjekt mit der ObjID "0" können keine Objekte gleicher hierarchischer Ordnung zugewiesen werden. Der Bezugstyp Parent gibt somit in der Regel Auskunft über die nächsthöhere Hierarchie bezüglich eines Objekts. Beispielsweise ist von einem Buch mit der Objekt-ID "10" bekannt (siehe Figur 6), daß es sich im ersten Geschoß der Bibliothek befinden muß, da der in der Objekttabelle 640 eingetragene Bezug zur Objekt-ID "10" lautet: "Parent = 9". Das bedeutet, es wird auf die Objekt-ID "9" verwiesen, zu der der Bezug "Parent = 0" gehört, d.h. hierin ist die Information zu sehen, daß das Buch sich im ersten Geschoß (Parent=9) der Bibliothek (ObjID "9" - Parent=0) befindet, wenn die Bibliothek als solche den höchsten hierarchischen Bezug, nämlich das Objekt mit der Objekt-ID "0", darstellt.
Die beiden eben genannten Bezugstypen "Parent =" und "Ref =" dienen lediglich der Vereinfachung der optischen Unterscheidung. Man kann diese auch weglassen, wobei jedoch die ihnen zugeordnete Ziffer, sprich die ObjID zwingend erforderlich ist.
Mit anderen Worten, jedes Objekt hat im Falle eines räumlichen Bezugssystems genau einen Ortsbezug, d.h. einen zu referierenden Vater
("Ref = ..."). Allgemein gesprochen gibt es zu einem Objekt einen logischen Bezug, der das Objekt einem logischen Bezugssystem zuordnet. Jedoch wird der
Ortsbezug der Objekte selbst wiederum als Objekt im System gespeichert und besitzt eine Referenz auf seinen "hierarchischen" Vater ("Parent = ..."). Somit entsteht für Ortsobjekte eine einfache verkettete Liste mit anderen Ortsobjekten als
Endknotenpunkte. Objekte auf der ersten Hierarchieebene verweisen auf einen sogenannten virtuellen Vater mit der ID = 0. Jedoch können mehrere Objekte einem Ort zugewiesen werden. Dies geschieht grundsätzlich durch den Bezug vom
Typ "Ref = ...". In der Objekttabelle 640 der Figur 6 sind beispielsweise die drei Objekte mit den Objekt-IDs 26, 28 und 29 dem (Orts-)Objekt mit der Objekt-ID "45" zugewiesen. Das Objekt mit der ID = 45 ist durch den Ortsbezug "Parent = 10" dem
(Orts-)Objekt mit der Objekt-ID "10" unterstellt, welches selbst wiederum dem (Orts- )Objekt 9 unterstellt ist. Das Objekt mit der Objekt-ID "9" ist dann schließlich dem virtuellen Vater mit der ID 0 unterstellt.
Als nächstes wird eine in der Figur 7 dargestellte Attributtabelle 730 im Detail beschrieben werden. Die Attributtabelle 730 enthält zu den Figuren 5 und 6 passende Beispieleinträge. Sie ist gleichfalls wie die Objekttabelle 640 der Figur 6 zweispaltig angeordnet. Die erste Spalte 731 ist mit "TAG" bezeichnet. Die zweite Spalte 732 ist mit "TagID" bezeichnet. Ein Eintrag (d.h. eine Zeile) in der Attributtabelle 730 besteht somit aus zwei Teilen. Der erste Eintragsteil TAG ist grundsätzlich in drei Teile gegliedert, die mit einem Punkt getrennt werden. Diese drei Komponenten bezeichnen zum ersten - den schon oben erwähnten - Objekttyp, zum zweiten einen Datenfeldnamen und zum dritten ein Attribut, das in diesem Zusammenhang als Einheit verstanden werden kann. Der Datenfeldname entspräche in der herkömmlichen Datenbankmodellierung den Feldbezeichnungen bzw. den Spaltenüberschriften. Die dritte Komponente des ersten Eintragsteils stellt eine Einheitengröße dar, die den Inhalt des damit verknüpften Datenfelds näher beschreibt. Mögliche Einheitengrößen sind zum Beispiel "Text", "Zahl", "Währung", oder "Datum". Ein zum ersten Eintragsteil gehöriger zweiter Eintragsteil TagID entspricht einem der Einträge in der Spalte 533 der Wertetabelle 500 der Figur 5 und stellt das Ziel des dort bezeichneten Zeigers dar. Durch die TagID wird von der Wertetabelle 500 der Figur 5 auf die Attributtabelle 730 der Figur 7 referenziert.
Der erste Eintragsteil eines Eintrags in der Attributtabelle 730 kann somit eine Struktur vom Typ "Objekttyp._Objekt-ID._.ID_" auf (siehe auch TAG zu TagID 362) aufweisen.
In Figur 8 ist eine Inhaltstabelle 860 dargestellt, die in ihrer Funktionalität der Inhaltstabelle 460 der Figur 4 entspricht. Die Inhaltstabelle 860 weist ebenfalls zwei Spalten auf. Die erste Spalte 861 wird mit "TXT" bezeichnet. Die zweite Spalte 862 wird mit "TxtlD" bezeichnet. Die Einträge in die Inhaltstabelle 860 in der Figur 8 sind beispielhaft und passen zu den in den Figuren 5, 6 und 7 dargestellten Einträgen. Die in der Spalte 563 der Wertetabelle 500 der Figur 5 enthaltenen Inhaltsreferenzen referenzieren auf einen zweiten Eintragsteil (TxtlD) eines Eintrags der Inhaltstabelle 860. Ein zum zweiten Teil gehöriger erster Eintragsteil stellt den Inhalt des Datenfelds dar. So wird beispielsweise dem Datenfeld mit der Wert-ID "12" aus Figur 5 über die Inhaltsreferenz mit der Text-ID "16" der Inhalt "500 501 02" zugewiesen, was der Bankverbindung einer Firma entspricht, wie man der Attributreferenz mit der Tag-ID "369" aus den Tabellen 5 und 7 entnehmen kann. Die zur Wert-ID "12" gehörige Objekt-ID "3" verweist gemäß der Objekttabelle 640 auf einen Ortsbezug "Ref = 1", womit dieses Objekt dem virtuellen Vater mit der ID = 0 zugewiesen wird, da dem Objekt mit der Objekt-ID "1" der Hierarchiebezug "Parent = 0" zugewiesen ist.
In der Figur 9 ist der im Zusammenhang mit der Figur 6 angeführte Bezug zwischen den Objekten in Form eines Ortsbezugs noch einmal beispielhaft verdeutlicht. Der Ortsbezug gliedert Informationen hierarchisch nach dem Ort, den sie betreffen oder an dem sie auftreten. In der Figur 9 sind links einige Ortsbezüge wie Kunde, Nation, Stadt und Liegenschaft aufgeführt. Man sieht, daß jeder Ortsbezug mehrere untergeordnete Ortsbezüge enthalten kann. Jedem Ort wiederum können mehrere Objekte durch den Bezug des Typs "Ref = ..." zugeordnet werden.
Im nachfolgenden werden einige allgemeinere Aussagen über die Funktionsweise der vorliegenden Erfindung gemacht werden.
Genauso wie die räumliche Zuordnung über die Ortsbezüge für einzelne Objekte möglich ist, erlaubt eine weitere Ausführungsform der Erfindung die zeitliche Zuordnung von Objekten. Beispielsweise könnte man daran interessiert sein - um im Bild des oben genannten Beispiels zu bleiben -, wo sich ein Buch XY der Bibliothek, das sich momentan im Raum Z des ersten Geschosses befindet, vorher befunden hat, bevor es in diesem Raum abgelegt wurde. Dazu wäre es erforderlich, daß man der Wertetabelle 500 der Figur 5 auch zeitliche Informationen entnehmen kann. Dies wird erreicht, indem man eine weitere, zusätzliche Spalte definiert, die Zeitreferenzen beinhaltet. Diese Zeitreferenzen verweisen - ähnlich wie bei den Ortsbezügen - auf eine Zeittabelle (nicht dargestellt). Diese Zeittabelle ist ebenfalls zweispaltig angelegt. Die erste Spalte beinhaltet wiederum Bezüge zwischen Objekten, die zweite Spalte beinhaltet die zugehörigen Zeitreferenzen (Time-ID, nicht dargestellt), auf die die Zeitzeiger aus der weiteren Spalte der Wertetabelle zeigen.
Es versteht sich von selbst, daß es jederzeit möglich ist, ein neues Objekt anzulegen. Dabei werden entsprechend den zu erfassenden Eigenschaften des Objekts eine äquivalente Anzahl von Zeilen in der Wertetabelle 500 der Figur 5 angelegt. Die Datenfelder können jeweils eine laufende Nummer zugeteilt bekommen, die bisher noch nicht vergeben ist. Des weiteren wird dem Objekt eine
Objekt-ID zugewiesen, die für die neu einzutragenden Felder gleich ist, da es sich um ein und dasselbe Objekt handelt. Das Objekt selbst wiederum gehört einem
Objektypen an. Beispielsweise gehört ein Taschenbuch ABC - wie schon eingangs erwähnt - zum Objekttyp Buch. Existiert für ein Objekt noch kein zugehöriger
Objekttyp, so läßt sich dieser auf einfache Art und Weise anlegen, indem man in der Attributtabelle einen Eintrag der Form "neuer Objekttyp. Feldname.Einheit" anlegt. Gleiches gilt für die Eigenschaften des Objekts, die in der eben genannten
Schreibweise dem Feldnamen entsprechen. Somit lassen sich beliebige Objekte mit beliebigen Eigenschaften in die Wertetabelle eintragen, ohne daß dabei
Redundanzen, wie im Stand der Technik, auftreten.
Sämtliche Zugriffe auf Informationen in der erfindungsgemäßen
Datenbank unterliegen frei definierbaren Zugriffsrechten. Es wird zwischen den Zugriffsrechten "Schreiben & Lesen", "Lesen" sowie "kein Zugriff' unterschieden. Die Rechte werden in sogenannten Benutzergruppen organisiert. Ein Benutzer ist immer mindestens einer Benutzergruppe zugehörig. Ein Objekt oder Ortsbezug ist nur dann für eine Benutzergruppe überhaupt sichtbar, wenn für das betreffende Objekt das Recht "Schreiben & Lesen" oder "Lesen" zugeteilt wurde. Sobald ein Objekt für den Schreibzugriff geöffnet ist, erhalten alle anderen lese- und schreibberechtigten Benutzer in dieser Zeit nur das Recht "Lesen". Sobald der Schreibzugriff beendet ist, sind die Schreibrechte auch für andere Benutzer verfügbar.
Des weiteren ist wie bei allen Datenbanken eine Suche möglich. Als
Suchsprache kann beispielsweise SQL (Structured Query Language) benutzt werden. Die Suche ermöglicht das gezielte Finden von Objekten, beispielsweise im Ortsbezug. Der Ortsbezug kann dazu durch Navigieren in den gewünschten Ortsbezug (wie beispielsweise in Figur 9 dargestellt) eingegrenzt werden. Des weiteren läßt sich auch eine erweiterte Suche durchführen. Die erweiterte Suche bietet zusätzlich die Möglichkeit, gezielt Informationen innerhalb von Objekten zu suchen, d.h. beispielsweise nach einer bestimmten Eigenschaft zu suchen. Dazu werden alle Eigenschaften des Objekts dargestellt. Wird kein Objekt ausgewählt bei der erweiterten Suche, so stehen die Feldeinträge aller Objekte zur Verfeinerung der Suche zur Verfügung. Das Datenbanksystem selbst arbeitet wo nur möglich mit Indizes der Tabellen, was für datenverarbeitende Systeme günstig ist.
Abschließend kann gesagt werden, daß durch das erfindungsgemäße Datenbanksystem folgende Vorteile gegenüber dem Stand der Technik erzielt werden.
Ein vorteilhafter Aspekt ist die Vermeidung von Redundanzen. Ein objektorientierter Datenzugriff ist möglich. Es werden keine zusätzlichen Tabellen beim Hinzufügen neuer Objekttypen erzeugt. Es existieren detaillierte bzw. kombinierte Suchmöglichkeiten bis hin zur Volltextsuche. Das Datenmodell gemäß der vorliegenden Erfindung basiert auf dem standardisierten, relationalen Datenbankmodell, was erhebliche Vorteile bezüglich der Importierbarkeit von Daten darstellt, da diese unabhängig vom jeweiligen Softwarehersteller benutzt werden können. Ferner ist der Datenexport nach XML möglich.
Ein weiterer Vorteil ist darin zu sehen, daß Objekte miteinander über einen standardisierten Mechanismus verknüpfbar sind. Für einen Fachmann auf dem Gebiet der Softwaretechnik ist es klar, daß man die Wertetabelle transponieren, d.h. Zeilen mit Spalten vertauschen kann und umgekehrt, ohne die Funktionalität der Erfindung zu verändern. Ähnliches gilt für den Aufbau der drei bzw. weiteren Tabellen.
Ein Computerprogrammprodukt kann durch jedes geeignete Speichermedium dargestellt werden, auf dem das Computerprogramm abgespeichert ist, das das Verfahren gemäß der vorliegenden Erfindung ausführt.
Außerdem ist es für einen Fachmann aus dem vorangegangenen klar, daß verschiedene Ausführungsformen der vorliegenden Erfindung lediglich exemplarisch erklärt wurden und daß diese auf einfache Art und Weise verändert bzw. abgeändert werden können, ohne vom Umfang der vorliegenden Erfindung abzuweichen. Des weiteren ist festzustellen, daß die Elemente der beschriebenen Ausführungsformen sowohl durch Software als auch durch Hardware oder eine Kombination der beiden realisiert werden können.

Claims

Patentansprüche
1. Datenbanksystem, in dem eine Vielzahl von Datensätzen in einem Speicher eines Computers abspeicherbar sind, wobei jeder Datensatz eine beliebige Anzahl von Datenfeldern umfasst, dadurch gekennzeichnet, daß eine Datenbasis des Datenbanksystems eine mehrspaltige Wertetabelle mit einer beliebigen Anzahl von Zeilen, eine Inhaltstabelle zum Speichern von
Datenfeldinhalten, eine Attributtabelle zum Speichern von Datenfeldattributen und eine Objekttabelle zum Speichern von Bezügen zwischen Objekten aufweist, wobei in der Wertetabelle: jede Zeile einem Datenfeld eines Datensatzes entspricht; eine Spalte (txt) Inhaltsreferenzen (TxtlD) beinhaltet, die mehrfach für verschiedene Datenfelder vergeben sein können und jeweils eindeutig auf einen Eintrag (TXT, TxtlD) der Inhaltstabelle referenzieren; eine weitere Spalte (tag) Attributreferenzen (TagID) beinhaltet, die mehrfach für verschiedene Datenfelder vergeben sein können und jeweils eindeutig auf einen Eintrag (TAG, TagID) der Attributtabelle referenzieren; und noch eine weitere Spalte (obj) Objektreferenzen (ObjID) beinhaltet, die mehrfach für verschiedene Datenfelder vergeben sein können, wobei die zu jeweils einer Objektreferenz gehörenden Datenfelder jeweils einen Datensatz bilden und die Objektreferenz (ObjID) jeweils eindeutig auf einen Eintrag (OBJ, ObjID) der
Objekttabelle referenzieren.
2. Datenbanksystem gemäß Anspruch 1 , wobei in der Wertetabelle eine weitere Spalte (WertlD) laufende Nummern beinhaltet, die jeweils genau ein einziges Datenfeld bezeichnen.
3. Datenbanksystem gemäß Anspruch 1 oder 2, dadurch gekennzeichnet, daß die Inhaltstabelle, die Attributtabelle und die Objekttabelle jeweils zweispaltig oder zweizeilig sind.
4. Datenbanksystem gemäß einem der Ansprüche 1 bis 3, wobei die Wertetabelle transponiert ist, und somit vier Zeilen und eine beliebige Anzahl von Spalten aufweist, wobei die Spalten den Datenfeldern entsprechen.
5. Datenbanksystem gemäß einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß der Eintrag (OBJ, ObjID) der Objekttabelle der jeweiligen entsprechenden laufenden Nummer einen Ort zuweist, der ein Element eines hierarchisch angeordneten, räumlichen Bezugssystems ist.
6. Datenbanksystem gemäß einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, daß ein erster Eintragsteil (TXT) eines Eintrags der Inhaltstabelle einen datenformatsunabhängigen Inhalt eines entsprechenden Datenfelds beinhaltet, und ein zu diesem ersten Eintragsteil gehöriger zweiter Eintragsteil (TxtlD) einer der Inhaltsreferenzen (txt) der Wertetabelle entspricht.
7. Datenbanksystem gemäß Anspruch 6, wobei der Inhalt eines Datenfelds als Zeichenkette gespeichert ist.
8. Datenbanksystem gemäß einem der Ansprüche 1 bis 4, wobei ein erster Eintragsteil (TAG) eines Eintrags der Attributtabelle aus drei Komponten besteht, nämlich einem Objekttyp, einem Datenfeldnamen (_ObjektlD_) und einem Attribut (JD_)> ur|d ein zu diesem ersten Eintragsteil gehöriger zweiter Eintragsteil (TagID) einer der Attributreferenzen (tag) der Wertetabelle entspricht.
9. Datenbanksystem gemäß einem der Ansprüche 1 bis 4, wobei ein erster Eintragsteil (OBJ) eines Eintrags der Objekttabelle den Bezug (Ref, Parent) zu einem anderen Objekt darstellt, und ein zu diesem ersten Eintragsteil gehöriger zweiter Eintragsteil (ObjID) einer Objektreferenz (Obj) der Wertetabelle entspricht.
10. Datenbanksystem gemäß den Ansprüchen 4 und 9, wobei der
Bezug eine Information über den Ort eines durch den zweiten Eintragsteil (ObjID) eines Eintrags der Objekttabelle beschriebenen Objekts innerhalb des hierarchisch geordneten, räumlichen Bezugssystems beinhaltet.
11. Datenbanksystem gemäß einem der Ansprüche 6 bis 9, dadurch gekennzeichnet, daß der jeweilige zweite Eintragsteil (TxtlD, TagID, ObjID) der Einträge der Inhalts-, Attribut-, oder Objekttabelle jeweils einmalig ist.
12. Datenbanksystem gemäß Anspruch 11 , wobei der zweite Eintragsteil von einem Typ "ID" ist.
13. Datenbanksystem gemäß einem der vorangegangen Ansprüche, wobei die Einträge in der Wertetabelle jeweils ganzzahlig sind.
14. Datenbanksystem gemäß einem der vorangegangen Ansprüche, wobei die Wertetabelle eine weitere Spalte/Zeile (time) aufweist, die Zeitreferenzen
(TimelD) aufweist, die mehrfach, für verschiedene Datenfelder, vergeben sein können und jeweils eindeutig auf einen Eintrag in einer Zeittabelle referenzieren, wobei die Zeittabelle zweizeilig/zweispaltig ist und zweiteilige Einträge aufweist, die sich aus einem ersten Eintragsteil (Time) und einem zu diesem gehörigen zweiten Eintragsteil (TimelD) zusammensetzt, wodurch ein Bezug zwischen Objekten in Abhängigkeit von der Zeit herstellbar ist.
15. Verfahren zum Durchführen von Operationen in einem Datenbanksystem, in dem eine Vielzahl von Datensätzen in einem Speicher eines Computers abspeicherbar sind, wobei jeder Datensatz eine beliebige Anzahl von
Datenfeldern umfasst, dadurch gekennzeichnet, daß das Durchführen der
Operationen jeweils umfasst zugreifen auf und/oder abspeichern von Daten einer Datenbasis, wobei die Datenbasis des Datenbanksystems eine mehrspaltige Wertetabelle mit einer beliebigen Anzahl von Zeilen, eine Inhaltstabelle zum Speichern von
Datenfeldinhalten, eine Attributtabelle zum Speichern von Datenfeldattributen und eine Objekttabelle zum Speichern von Bezügen zwischen Objekten aufweist, und wobei in der Wertetabelle: jede Zeile einem Datenfeld eines Datensatzes entspricht; eine Spalte (txt) Inhaltsreferenzen (TxtlD) beinhaltet, die mehrfach für verschiedene Datenfelder vergeben sein können und jeweils eindeutig auf einen Eintrag (TXT, TxtlD) der Inhaltstabelle referenzieren; eine weitere Spalte (tag) Attributreferenzen (TagID) beinhaltet, die mehrfach für verschiedene Datenfelder vergeben sein können und jeweils eindeutig auf einen Eintrag (TAG, TagID) der Attributtabelle referenzieren; und noch eine weitere Spalte (obj) Objektreferenzen beinhaltet, die mehrfach für verschiedene Datenfelder vergeben sein können und jeweils eindeutig auf einen Eintrag (OBJ, ObjID) der Objekttabelle referenzieren.
16. Verfahren gemäß Anspruch 15, dadurch gekennzeichnet, daß das Datenbanksystem ferner die Merkmale gemäß einem der Ansprüche 2 bis 14 aufweist.
17. Datenstruktur, die mindestens einen Datensatz aufweist, um das Verfahren gemäß Anspruch 15 oder 16 auszuführen.
18. Computerprogramm, das computerausführbare Instruktionen aufweist, um einen Computer dazu zu veranlassen, ein Verfahren gemäß Anspruch 15 oder 16 auszuführen.
19. Computerprogrammprodukt, das computerausführbare Instruktionen aufweist, um einen Computer dazu zu veranlassen, ein Verfahren gemäß Anspruch 15 oder 16 auszuführen.
PCT/DE2002/000945 2001-03-20 2002-03-15 Datenbanksystem WO2002075589A2 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP02729794A EP1374100A2 (de) 2001-03-20 2002-03-15 Datenbanksystem

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10113515.7 2001-03-20
DE10113515A DE10113515A1 (de) 2001-03-20 2001-03-20 Datenbanksystem

Publications (2)

Publication Number Publication Date
WO2002075589A2 true WO2002075589A2 (de) 2002-09-26
WO2002075589A3 WO2002075589A3 (de) 2003-10-09

Family

ID=7678227

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE2002/000945 WO2002075589A2 (de) 2001-03-20 2002-03-15 Datenbanksystem

Country Status (3)

Country Link
EP (1) EP1374100A2 (de)
DE (1) DE10113515A1 (de)
WO (1) WO2002075589A2 (de)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102005009014A1 (de) * 2005-02-28 2006-09-07 Vodafone Holding Gmbh Verfahren und System zur Verwaltung von Objekten eines mobilen Endgerätes
DE102011087843B4 (de) * 2011-12-06 2013-07-11 Continental Automotive Gmbh Verfahren und System zur Auswahl mindestens eines Datensatzes aus einer relationalen Datenbank

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998001808A1 (de) * 1996-07-08 1998-01-15 Ser Systeme Ag Produkte Und Anwendungen Der Datenverarbeitung Datenbanksystem
US5857195A (en) * 1990-08-31 1999-01-05 Fujitsu Limited Method of developing and modifying self-describing database management system to generate a new database management system from an existing database management system
WO2002103573A1 (en) * 2001-06-14 2002-12-27 Ubs Ag A flexible virtual database system including a hierarchical application parameter repository

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6112209A (en) * 1998-06-17 2000-08-29 Gusack; Mark David Associative database model for electronic-based informational assemblies

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5857195A (en) * 1990-08-31 1999-01-05 Fujitsu Limited Method of developing and modifying self-describing database management system to generate a new database management system from an existing database management system
WO1998001808A1 (de) * 1996-07-08 1998-01-15 Ser Systeme Ag Produkte Und Anwendungen Der Datenverarbeitung Datenbanksystem
WO2002103573A1 (en) * 2001-06-14 2002-12-27 Ubs Ag A flexible virtual database system including a hierarchical application parameter repository

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
BERGAMASCHI S ET AL: "Object Wrapper: an object-oriented interface for relational databases" EUROMICRO 97. NEW FRONTIERS OF INFORMATION TECHNOLOGY., PROCEEDINGS OF THE 23RD EUROMICRO CONFERENCE BUDAPEST, HUNGARY 1-4 SEPT. 1997, LOS ALAMITOS, CA, USA,IEEE COMPUT. SOC, US, 1. September 1997 (1997-09-01), Seiten 41-46, XP010243952 ISBN: 0-8186-8129-2 *
NADKARNI P M: "QAV: QUERYING ENTITY-ATTRIBUTE-VALUE METADATA IN A BIOMEDICAL DATABASE" COMPUTER METHODS AND PROGRAMS IN BIOMEDICINE, ELSEVIER, AMSTERDAM, NL, Bd. 53, Nr. 2, Juni 1997 (1997-06), Seiten 93-103, XP000889755 ISSN: 0169-2607 *

Also Published As

Publication number Publication date
EP1374100A2 (de) 2004-01-02
WO2002075589A3 (de) 2003-10-09
DE10113515A1 (de) 2002-10-02

Similar Documents

Publication Publication Date Title
EP0855062B1 (de) Informationssystem und verfahren zur speicherung von daten in einem informationssystem
EP0910829B1 (de) Datenbanksystem
DE3382808T2 (de) Datenbankzugriffsverfahren mit einem benutzerfreundlichen Menü
DE3688529T2 (de) Verfahren zur Auffrischung von Mehrspaltentabellen in einer relationellen Datenbank mit Mindestinformation.
DE19960043B4 (de) Verfahren zum Navigieren in einer Baumstruktur
DE69400276T2 (de) Zeichensatzsystem für texteingabe
EP0523269A1 (de) Computersystem zur Datenverwaltung
DE102010049891A1 (de) Ersatz von maschinell vorgegebenen Stichworten von Webseiten durch manuelle Eingaben
DE102013015355A1 (de) Nutzergesteuerte Findemaschine
DE19947136A1 (de) Verfahren und Vorrichtung zum Erstellen und Verteilen von Berichten
WO2007137308A1 (de) Verfahren zum steuern eines relationalen datenbanksystems
EP1159689A2 (de) Such- und navigationseinrichtung für hypertext-dokumente
DE19715723A1 (de) Array-Verfahren
EP1941395A1 (de) Verfahren zur steuerung eines relationalen datenbanksystems
EP1502211B1 (de) Verfahren und vorrichtung zur zugriffssteuerung in wissensnetzen
EP1374100A2 (de) Datenbanksystem
EP0856176A1 (de) Datenbankmanagementsystem sowie datenübertragungsverfahren
DE68926119T2 (de) Verfahren zur anzeige oder zum speichern von beziehungsänderungen zwischen objekten in einem datenverarbeitungssystem
DE102010064167A1 (de) Dynamische Berichtserstellung
DE19729911A1 (de) System zur Verbesserung der Organisation von Daten einer Dokumentation
WO2008131465A1 (de) Verfahren zur steurerung eines relationalen datenbanksystems
DE69122324T2 (de) Verfahren und gerät zur graphischen befragung einer datenbank
DE102008062830B3 (de) Vorrichtung und Verfahren zum Speichern, Suchen und Darstellen von Informationen
DE10025219A1 (de) Verfahren, Computerprogrammprodukt und Vorrichtung zum automatischen Verknüpfen von Datensätzen aus zumindest einer Datenquelle sowie System zum Abrufen von verknüpften Datensätzen aus zumindest einer Datenquelle
DE19951756B4 (de) Verfahren zur Datenverwaltung sowie Computerprogramm und -system zu dessen Ausführung

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
WWE Wipo information: entry into national phase

Ref document number: 2002729794

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2002729794

Country of ref document: EP

WWR Wipo information: refused in national office

Ref document number: 2002729794

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 2002729794

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP