WO1997015015A2 - Informationssystem und verfahren zur speicherung von daten in einem informationssystem - Google Patents

Informationssystem und verfahren zur speicherung von daten in einem informationssystem Download PDF

Info

Publication number
WO1997015015A2
WO1997015015A2 PCT/DE1996/001719 DE9601719W WO9715015A2 WO 1997015015 A2 WO1997015015 A2 WO 1997015015A2 DE 9601719 W DE9601719 W DE 9601719W WO 9715015 A2 WO9715015 A2 WO 9715015A2
Authority
WO
WIPO (PCT)
Prior art keywords
objects
relationships
database
features
memory
Prior art date
Application number
PCT/DE1996/001719
Other languages
English (en)
French (fr)
Other versions
WO1997015015A3 (de
Inventor
Annette Brückner
Original Assignee
Brueckner Annette
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 Brueckner Annette filed Critical Brueckner Annette
Priority to AU10919/97A priority Critical patent/AU1091997A/en
Priority to US09/051,394 priority patent/US6208992B1/en
Priority to EP96941572A priority patent/EP0855062B1/de
Priority to AT96941572T priority patent/ATE202646T1/de
Priority to DE59607181T priority patent/DE59607181D1/de
Publication of WO1997015015A2 publication Critical patent/WO1997015015A2/de
Publication of WO1997015015A3 publication Critical patent/WO1997015015A3/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/284—Relational databases
    • G06F16/288—Entity relationship models
    • Y—GENERAL 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
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99941—Database schema or data structure
    • Y10S707/99944—Object-oriented database structure
    • Y10S707/99945—Object-oriented database structure processing

Definitions

  • the invention relates to an information system, a method for storing data from a database on a memory of an information system, the database being accessible by means of a program running in an EDP system, and a data structure.
  • An information system is to be understood as a system for recording / entering, storing, processing / linking, displaying, recovering / evaluating and outputting information or data.
  • Such a system consists of an EDP system, a database system, database management system, and application and evaluation programs that can access the information system, as well as input and output devices.
  • the database consists of a database in which the data are stored and management programs that store, process, evaluate and retrieve the data in accordance with the specified descriptions.
  • REPLACEMENT BUTT (RULE 26)
  • the quality of a database depends largely on the quality of the data modeling and the resulting logical and physical data structures. Effective data modeling has therefore been an important goal of database development and research for many years.
  • External data structure model a view of the data, description of the data structure and the necessary processing and processing rules from the point of view and according to the requirements of a user or programmer (according to Thomas A. Bruce, “Designing Quality Databases with IDEF1X Information Models ", Dorset House Publishing, 1992, p. 532).
  • the data structures and the access and processing applications in the conceptual data structure model are from a specific task in a project, e.g. Creation of a merchandise management system, derived, and for the identification or description of the objects to be processed, the specific business activities and the predictable data to be processed during implementation are used ("business rules").
  • a separate table is defined in the physical data structure model for each essential object (see p. 280ff.). These objects are stored together with their most important characteristics in differently structured tables. So there are at least as many object tables as there are objects. This creates object tables that have different structures due to different object characteristics or different relationships between objects. For each table there must be table-specific input, access, change and delete algorithms.
  • REPLACEMENT BUTT (RULE 26) An expansion of the business activity or the need to add additional data afterwards means a change or expansion of all data structure models. This is always associated with a redesign of the (physical and logical) database structure, i.e. with corresponding modeling and restructuring efforts, as well as with a mostly very complex and costly change of the application programs by programming experts, insofar as the external view and changed processing and processing rules are affected. Every small change in the logical and physical data structure requires a change in the access and processing algorithms.
  • a data exchange between differently structured information systems is, if at all, only possible on the basis of the "lowest common denominator", ie the few data that generally match, but only if data for the description of similar objects, characteristics and relationships are identical are structured.
  • REPLACEMENT BUTT (RULE 26) The same applies to relationships between objects; these can only be linked to the extent that the relationships between the objects were defined when the database structure was created.
  • the object of the invention is to provide an information system, a method for storing data and a data structure which avoid the disadvantages of the prior art
  • REPLACEMENT BUTT (RULE 26) and enable any, even retrospective, expandability of the information system or the database.
  • Another object of the invention is to enable an optimal and maximum possibility of combining the stored data.
  • Another object of the invention is to enable access to information systems of different contents and for different tasks ("business rules") with uniform access and transaction algorithms.
  • Another object of the invention is to design the data structure so that access algorithms can be used independently of the physical data structure.
  • Another object of the invention is to enable effective use of the physical memory.
  • the invention provides a universal physical structure of a data model, which makes it possible (in a so-called 'subsystem', see below) to record / enter, store, process and evaluate any and any number of objects of different object types to link any and any number of characteristics (attributes) and thus to identify or describe them, to connect / link any objects of any type with any other objects of any type and to assign any and any number of characteristics to these object links in order to use them to link the objects to identify or describe.
  • REPLACEMENT BUTT (RULE 26)
  • the invention ensures that such objects can also be recorded, described / identified, related and evaluated in a database system, or their characteristics and / or relationships and / or characteristics of the relationships when structuring the data model or creating the Database was not yet predictable or known. This means that the information system can be expanded at any time, even retrospectively.
  • the invention avoids the disadvantage of the prior art, which in particular consists in the specific coordination of the data structure with the specific tasks and is accompanied by complex, task-specific implementations of the input / acquisition, processing - / Evaluation, transaction and output algorithms.
  • This makes it possible to access information systems with different contents and for different tasks with uniform access and transaction algorithms.
  • the access and transaction algorithms are independent of the data structure, since you do not have to know which table contains specific content. You just have to know which element it is.
  • the invention enables effective use of the physical memory, since, in contrast to known systems, only the memory areas (table fields or columns) that are actually used are “occupied”.
  • the invention enables different or subsequently changing logical approaches (corresponding to the external or conceptual data structure model) to be implemented by the subsequent modification of processing and processing algorithms at the application program level, without thereby changing the basic transaction and access algorithms to the physical data structure should be.
  • REPLACEMENT BUTT (RULE 26)
  • object classes whereby a separate subsystem is introduced for each object class.
  • An essential feature of the invention is that all subsystems have completely identical physical data structures and can therefore be processed with the same transaction algorithms at the system level for input, processing and evaluation, modification, output and deletion.
  • the invention relates to an information system and in particular to a method for the input, storage, processing, evaluation, display and output of information about
  • Each of these basic elements is stored in its own, physically delimited memory area (e.g. its own table in a relational database).
  • Objects are images of an object of perception, recognition and thinking, that is to say they represent images of concrete or abstract objects. Objects are not the objects themselves, but represent them.
  • the invention offers the possibility of combining objects into logical object types.
  • object type is understood to mean a group of objects of the same type (e.g. people, vehicles, book titles) or generally objects that are to be compared with other objects of the same object type with regard to their characteristics and / or their relationships.
  • the list of object types to be processed can be saved in a thesaurus list of object types ("type list"). This list can be adapted and changed by the operator of the information system at any time. Neither programming effort nor a change of the data structure is necessary for this.
  • REPLACEMENT BUTT (RULE 26) for objects is not limited by the method.
  • the access and processing algorithms therefore only have to be defined once for access to an object, ie an entry in the objects table, and they can be applied uniformly to all objects.
  • each feature consists of two components:
  • the meaning of the feature indicates the meaning in which the term of the feature should be understood in the later processing, evaluation and output. It is an assessment of the concept of characteristics by the person recording them.
  • the features are stored in a separate basic table of the features.
  • the invention also makes it possible to relate any objects of any type to one another, thereby entering, storing, processing and evaluating temporal or spatial relationships, dependencies, causalities, interactions and any other relationships between objects. Relationships between objects are stored in a separate basic table for relationships. The method does not limit the number of entries in this basic table.
  • the invention makes it possible to assign any and any number of identifying and descriptive features to each object. It creates a connection between the object key and the feature key in a separate connection table, the number of entries in this table not being limited by the method.
  • the invention makes it possible to assign any and any number of identifying and descriptive features to any relationship between objects. It creates a connection between the relationship key and the feature key in a separate connection table, the number of entries in this table not being limited by the method.
  • the invention summarizes all object types that are subject to the same organizational, IT, data protection or other processing rules ("business rules") in a logical object class. Objects that belong together in this way, characteristics of objects, Relationships between objects and characteristics of object relationships of an object class are stored in a 'subsystem'.
  • the physical data structure of all subsystems is identical; therefore, the same transaction and access algorithms can be used for each subsystem.
  • Different processing rules e.g. for data protection, monitoring and - protocols
  • are implemented in specific processing algorithms and such changes to the processing rules can be made once and at a central location without having to change the physical data structure.
  • connection table between these subsystems, the keys of the objects from both subsystems being used as foreign keys in the connection table.
  • connection tables between subsystems are also subject to uniform and centrally defined access and processing algorithms.
  • the method limits the number of subsystems within an overall system just as little as the number of necessary connection tables between subsystems whose objects are related to one another.
  • REPLACEMENT BUTT (RULE 26) Identification within the database carries every entry of each basic element table with a unique, eg numerical, key.
  • each element entry is supplemented by a (usually) textual identifier for the element (e.g. name of the object) or identifier of the relationship (e.g. "is father of").
  • This identifier serves as a symbolic representative of the element during input and output.
  • a basic table can contain other fields, but this is irrelevant for the procedure.
  • Connection tables are used to save the connections or relationships between basic elements. Each entry of a basic element table transfers its uniquely identifying key field to the connection table. An entry in the connection table thus consists (at least) of the pair of the key of the entry from one and the key of the entry from the other basic table.
  • the keys adopted from the basic element tables do not necessarily together form the uniquely identifying key of an entry in the connection table. Rather, the procedure also opens up the possibility of an entry of
  • REPLACEMENT BUTT (RULE 26) Assign a unique key to the connection table. This makes it possible for the same entries from basic tables to be linked together several times in a connection table (for example, A is the owner of vehicle B; A is the owner of vehicle B).
  • entity 2 inherits its key as a foreign key to entity 1; in each element of entity 1 it refers to each of the N connected elements from entity 2.
  • N connections between an entity 1 and an entity 2 N connections between an entity 1 and an entity 2, a separate connection table is generated according to the prior art. It contains the minimum entries for each connection the key of the connected element from entity 1 and the key of the connected element from entity 2.
  • connections between basic elements are stored exclusively in separate connection tables, irrespective of how many entries of one entity should or may be connected to how many other entries of another entity.
  • connection tables between connected entities instead of an extension of the entities themselves (as is necessary in the prior art for 1: 1 or 1: N connections) also ensures that uniform, centrally defined access and processing algorithms can be applied regardless of the actual number of connections between two entities. Necessary restrictions on the connection options, e.g. for organizational reasons, can be implemented by application programs that are "above" the centrally defined access and processing algorithms.
  • connection table can be supplemented with additional fields. Additional fields can be used in particular to identify the entry to the user when it is entered and output (A "is the father of" B), but also to save information about the date on which the entry was created or changed the entry is to be deleted or via the person who entered / last edited the entry.
  • connection table can also be used to evaluate the assignment made, e.g. regarding
  • the invention thus makes it possible to store information of different truth or relevance content in one and the same information system and yet to distinguish them from one another on the basis of evaluations made.
  • Information systems based on the present invention can therefore be used to develop hypotheses, as well as simulations and scenarios and to compare these with facts.
  • the basic table of relationships between objects has a dual role: it represents a basic table and is treated like a basic table. At the same time, it represents a connection table in the sense that it stores the connection of two objects (of the same subsystem). This table thus combines the advantages of both table variants:
  • connection table it offers the advantage that any objects can be related to any other objects without the need for additional table structures.
  • FIG. 1 shows a schematic illustration of an information system
  • FIG. 2 shows the structure of an entry in a basic table for objects according to a first exemplary embodiment of the invention
  • FIG. 4 shows the structure of an entry in a basic table for relationships according to the first exemplary embodiment of the invention
  • FIG. 5 shows the structure of an entry in a basic table for features according to the first exemplary embodiment of the invention
  • FIG. 6 shows the structure of an entry in a thesaurus list for feature terms according to a further exemplary embodiment of the invention.
  • FIG. 8 shows a diagram of the representation and storage of the connections between two basic elements (object and feature);
  • FIG. 9 shows a diagram of the representation and storage of the connection between basic documents and administration objects according to a further exemplary embodiment of the invention.
  • REPLACEMENT BUTT (RULE 26) 10 shows an overall representation of the data structure according to the invention for a subsystem
  • FIG 11 shows an overall representation of the data structure according to the invention with three subsystems.
  • FIG. 1 shows a schematic illustration of an information system 100, which consists of an EDP system 110 and a memory 120.
  • a database system 130 consisting of a database management system 140 and a database 150, and application programs 160 are stored in the memory 120, which can be any machine-readable memory, and are used in a known manner in the central unit of the computer system 110 loaded and can access the database system 130.
  • external users can access the information system 100 or the database system 130 in a known manner via corresponding application programs.
  • the information system also has input devices 180 and output devices 190, via which data or information can be input or output into the information system.
  • client / server architectures external users can access information system 100 or database system 130 via application programs 181 that run on input devices 180 or application programs 191 that run on output devices 190.
  • REPLACEMENT BUTT (RULE 26) 3. Additional features for describing and / or identifying objects and / or relationships.
  • each basic element is stored in a physically or logically delimited memory area on the memory 120 and that this memory area has the same structure for the storage of each individual element.
  • these storage areas represent e.g. own tables.
  • Objects are images of an object (s) of perception, recognition and thinking, that is to say they represent images of concrete or abstract objects.
  • objects of the same type or to be compared with one another can be combined to form logical object types.
  • Fleming, von Halle manual starting on p. 88, a procedure is described on how to sufficiently identify and record the necessary object types during the design of a database structure model. This procedure can be adopted for the present method in order to identify the necessary object types.
  • REPLACEMENT BUTT (RULE 26) in a police information system: persons non-natural legal entities
  • the list of object types to be processed is stored in a thesaurus list for object types ("type list"), which will be described in more detail later.
  • type list a thesaurus list for object types
  • This list can be changed and expanded at any time by the operator of the information system. This does not require programming, nor does it require a change in the database structure.
  • groups of object types to be processed in the same way can be combined to form an object class and processed and processed in a separate subsystem.
  • all objects that can belong to any object type are stored in one and only one basic table for objects.
  • FIG. 2 shows the structure of an entry in a basic table for objects.
  • An object is represented by the entries in a row in the table.
  • An object is identified by a unique key. This key is stored in a separate key field 210 of the line.
  • An object is identified by an identifier 220. This identifier represents the object; it has the task of naming the object when it is first entered, and is used during processing, but especially when it is output to the user, to identify the object.
  • REPLACEMENT BUTT (RULE 26) It is necessary to differentiate between objects of different types in order to be able to enter, process, save and output objects of the same type in the same way. For this purpose, a separate type identifier 230 is introduced for the object type. As a foreign key, it refers to the type list ", which is described in more detail below with reference to FIG. 3.
  • the entry for an object can be expanded by additional fields 240, etc. if this appears necessary in individual cases for organizational reasons, security requirements or other reasons.
  • the list of object types to be processed is saved in a thesaurus list for object types ("type list"). This list can be changed and expanded by the operator of the information system at any time. This does not require programming, nor does it require a change in the database structure.
  • the structure of the thesaurus list for object types is shown in FIG. 3.
  • the individual fields have the following meaning:
  • the type key 310 is a unique key, usually an artificial key, which identifies the object type within the system.
  • the type key 310 from the thesaurus list of the object types shown in FIG. 3 is transferred as a foreign key 230 into the basic table of objects shown in FIG. 2. It identifies the type of object to which each entry (line) in the basic table of objects belongs.
  • the type identifier (language 1) 320 is a suitably long and suitably formatted field according to the specific requirements of the operator for storing the name of the object type. This is used to name the object type in applications and when outputting information.
  • the foreign language type identifiers can be stored in further fields 330 etc. in order to enable "flying" switching between two or more application languages.
  • the thesaurus list of object types can be expanded by additional fields 340 etc. if this appears necessary in individual cases for organizational reasons, security requirements or other reasons.
  • this table stores the following details in the fields in an entry (row):
  • the key can be formed as a unique artificial key, e.g. numeric key, or as a composite key from the key of object 1 and object 2, provided that this ensures uniqueness;
  • REPLACEMENT BUTT (RULE 26) - information about the processing or availability status of the relationship
  • Each characteristic consists of two components: a characteristic term and an identifier for the meaning of the characteristic.
  • a feature term is any storage and processable term that is used as a (symbolic) term for the content of the feature. It can be:
  • each feature term is provided with an identifier for the feature meaning.
  • the meaning identifier indicates the meaning in which the feature term is to be understood in the later processing, evaluation and output. It is an evaluation of the meaning by the person who made it.
  • the structure of an entry in the basic table for features is shown in FIG. 5.
  • the entry (line) for a characteristic (pair) consists of at least the following fields:
  • the key can consist of an artificial key (e.g. numerical identifier in a database system).
  • the key can also consist of the pair of characteristic term / meaning identifier itself, which can only occur once in any case according to the system of the present system.
  • Characteristic term 520 a long and suitably formatted field suitable for the specific requirements of the operator for the inclusion of the characteristic terms or a key reference to the
  • REPLACEMENT BUTT (RULE 26) Term of the feature, if the assignment of feature terms is supported by a thesaurus.
  • Meaning identifier for feature terms 530 a long and suitably formatted field suitable for the specific requirements of the operator for the inclusion of the meaning identifier or a key reference to the meaning identifier, provided that the assignment of the meaning identifier is supported by a thesaurus becomes.
  • the selection and assignment of feature terms can be supported by a thesaurus (controlled vocabulary).
  • Thesaurus support can refer to individual or all terms to be used.
  • the thesaurus of the feature terms is a thesaurus list to be defined and expanded by the operator of the information system, in which the permissible terms for the features of objects and / or relationships are specified.
  • REPLACEMENT BUTT (RULE 26) Department names in a personnel information system Vehicle or weapon brands in a police information system
  • an entry (line) of the thesaurus list consists of the fields shown in FIG. 6, which have the following meaning:
  • - Key field 610 of the feature term a unique key, in particular also artificial key for the term, which is used as a reference for the term (foreign key, if this term is used in field 520 in the table of features .
  • - Concept of the feature (language 1) 620 is a long and suitably formatted field suitable for the specific requirements of the operator for the storage of an understandable, usually textual description of the feature (e.g. (for federal states : Bavaria, Baden-paper, Brandenburg, ...)
  • REPLACEMENT BUTT (RULE 26)
  • foreign language feature terms can be stored in further fields 630 etc. in order to enable "flying" switching between two or more application languages.
  • the selection and assignment of the meaning identifiers can be supported by a thesaurus in a further exemplary embodiment of the invention.
  • This is a thesaurus list to be defined and expanded by the operator of the information system, in which the permissible meaning identifiers for the characteristics of objects and relationships are specified.
  • First name first name further first name
  • an entry (line) of the thesaurus list consists of the fields shown in FIG. 7, which have the following meaning:
  • identifier 710 a unique key for the identifier, which is used as a reference for the identifier (foreign key), if this identifier is used in the table of characteristics.
  • This key can be structured in hierarchical classification and notation. An example of this can be:
  • REPLACEMENT BUTT (RULE 26)
  • the hierarchical classification and corresponding notation can be used when evaluating characteristics to search with generic terms, whereby detailed sub-terms can also be included.
  • Identifier for the characteristic meaning 720 a textual description of the meaning of the characteristic (e.g. "family name”, “place of birth”, “vehicle manufacturer”, etc.) that is understandable for the person collecting, processing and evaluating the information.
  • identifier in another language / languages 730 etc.
  • the term identifier can be specified in additional fields in one or more other languages or code forms. This enables the "flying" switch from one language to another or to other meaning variants without changing the actual information content (clearly identified by the key in 710) of the meaning identifier.
  • the entry (line) for a meaning identifier can be expanded to include additional fields 740 etc. if this appears necessary in individual cases for organizational reasons, security requirements or other reasons.
  • Another essential feature of the invention is the basic elements of the three element types listed (objects, relationships between the objects and features for describing and / or identifying objects and / or the relationship) or the basic elements and thesaurus lists assigned to them to be able to relate to one another at will. These relationships are delineated in physically or logically,
  • REPLACEMENT BUTT (RULE 26) own storage areas, eg stored in database tables, there is a uniformly structured storage area for the connection between two basic elements. In the case of databases, this is the "link table”.
  • connection table 800 The diagram of the representation and storage of the connection between two basic elements is shown in FIG. 8.
  • the connection between objects corresponding to FIG. 2 and features corresponding to FIG. 5 is shown as an example in a connection table 800.
  • Each object 200 is identified by a unique object key 210/820.
  • the feature (descriptive or identifying) 500 is identified by its feature key 510/830.
  • the key of the object 210/820 is combined with the key of the feature 510/830, which is related to this object 210, in one entry (line).
  • the connection between relationships and characteristics is established in a similar way.
  • the relationship 400 is uniquely identified according to FIG. 4 by its relationship key 410.
  • the (descriptive or identifying) feature 500 is identified by its unique feature key 510.
  • the key of the relationship 410 is combined in an entry (row) with the key of the feature 510, which is related to the relationship .
  • the invention makes it possible to connect any number of elements of a basic element table with any number of elements of another basic element table or thesaurus list (M: N connections).
  • M N connections
  • a separate key 810 can be kept in the connection tables, which uniquely identifies an entry in the connection table 800.
  • connection tables in further fields 840 etc. can also contain information that describes and evaluates the connection itself in more detail. This includes, for example, information about when this connection was relevant ("When did a user borrow a book from the library?"). This can also include information about the relevance and truthfulness of a connection. In a police information system, for example, testimonies can be weighted and evaluated.
  • Such basic documents are e.g. Documents with texts and graphics, sound, film, photo or video documents and other electronically storable basic documents.
  • the invention enables such basic documents to be recorded electronically (direct recording or scanning of paper documents) and stored within the database system.
  • REPLACEMENT BUTT (RULE 26) An essential characteristic of basic documents is first of all that they or their content should not be processed and processed in terms of information technology by the invention shown. Wherever this is necessary to prove the source of information, they merely serve as evidence / reference to the (eg court-relevant) source of information.
  • Each basic document is therefore accompanied in the present invention by an administration object, with the help of which the operator-specific administrative information about the basic document itself is stored and managed.
  • FIG. 9 shows the connection between basic documents and the administration objects, with the help of which basic documents are managed, can be identified and described by any features and can be placed in any relationship.
  • Each basic document consists of the actual document in storage field 912 and a key field 911, which acts as a unique key for this document field.
  • 920 denotes a logical or physical memory area that represents the administration object of the assigned basic document.
  • the structure and function of the fields of element 920 correspond to the structure and fields that are illustrated in FIG. 2.
  • connection between basic documents and administrative objects that manage and describe them is taken over by a memory area 930, in whose field 931 the key field of the basic document from 910 and in its key field 932 the key field 921 of the administrative object from 920 are transferred as foreign keys.
  • references to the basic documents containing the information can also be stored, which in turn cannot be stored electronically; be it because of organizational, IT-related or other reasons, or because the basic documents are not suitable due to their material nature to be stored electronically (e.g. track recorders in a police information system).
  • the key reference 911 is not a system-internal reference, but can be replaced by a reference to a storage location of the basic document that is outside the system.
  • This data structure model 1000 is also referred to as a "subsystem”.
  • objects 1020 are related to one another, which are stored in 1010. 10, the keys 1021 and 1022 of interconnected objects are combined in the relationship table 1010.
  • connection table 1050 key 1031 of a feature 1030 is merged with key 1012 of a relationship between objects from 1010 via connection table 1050.
  • REPLACEMENT BUTT (RULE 26)
  • the assignment of individual or all feature terms can be supported by a thesaurus of feature terms 1060.
  • the assignment of individual or all feature meanings can be supported by a thesaurus of the feature meanings 1070.
  • object class a group of object types
  • These general processing criteria can be based on organizational considerations, IT specifications (e.g. storage on different media), security or security requirements (e.g. storage of personal data) and others.
  • each object class is processed and processed in its own subsystem
  • the overall representation of the data structure model in FIG. 11 shows, by way of example, three subsystems 1110, 1120 and 1130, which are each constructed analogously to the subsystem shown in FIG. 10.
  • connection tables 1140, 1150, 1160 For the connection of two object classes or subsystems, the basic object elements 1111, 1121 and 1131 are connected to one another by connection tables 1140, 1150, 1160.
  • connection tables between subsystems correspond to the structure of the connection tables between basic element tables within a subsystem described in FIG. 4.
  • connection table of two object classes contains the connection between an object, e.g. 1111 from an object class or a subsystem, e.g. 1110, with an object, e.g. 1121, from an object class or a subsystem 1120.
  • object e.g. 1111 from an object class or a subsystem, e.g. 1110
  • object e.g. 1121
  • the keys (1111 or 1121) of the connected objects are usually stored in a connection table, e.g. 1140, saved.
  • connection table e.g. 1140
  • object classes or subsystems see FIG. 4
  • the number of subsystems is not limited by the invention. It is defined by the number of object classes that are subject to different processing rules. Likewise, the number of subsystems, which are connected in pairs to other subsystems, is not limited by the invention.
  • REPLACEMENT BUTT (RULE 26) oriented and has defined the rules for the design accordingly, it is essential for the invention that the business activity and data content of the operator of the information system to be created are first ignored.

Abstract

Bei einem Verfahren zur Speicherung von Daten einer Datenbasis auf einem Speicher eines Informationssystems, wobei auf die Datenbasis mittels eines in einem EDV-System ablaufenden Programms zugegriffen werden kann, wird die Datenstruktur der in der Datenbasis gespeicherten Daten durch die folgenden Verfahrensschritte aufgebaut: Speichern einer Vielzahl von Objekten, die Abbilder von konkreten oder abstrakten Gegenständen darstellen, in einem ersten Bereich des Speichers; Speichern einer Vielzahl von Beziehungen zwischen den Objekten in einem zweiten Bereich des Speichers; Speichern einer Vielzahl von Merkmalen zur Beschreibung der Objekte und der Beziehungen zwischen den Objekten in einem dritten und vierten Bereich des Speichers; Speichern einer Vielzahl von Verbindungen zwischen den Objekten und den Merkmalen in einem fünften Bereich des Speichers; und Speichern einer Vielzahl von Verbindungen zwischen den Beziehungen und den Merkmalen ein einem sechsten Bereich des Speichers, wobei die sechs Bereiche jeweils physikalisch oder logisch abgegrenzte Speicherbereiche darstellen. Die Erfindung betrifft auch die entsprechende Datenstruktur sowie ein Informationssystem.

Description

Informationssystem und Verfahren zur Speicherung von Daten in einem Informationssystem
Die Erfindung betrifft ein Informationssystem, ein Verfahren zur Speicherung von Daten einer Datenbasis auf einem Speicher eines Informationssystems, wobei auf die Datenbasis mittels eines in einem EDV-System ablaufenden Programms zugegriffen werden kann, sowie eine Datenstruktur.
Unter Informationssystem soll ein System zur Erfassung/Eingabe, Speicherung, Verarbeitung/Verknüpfung, Darstellung, Wiedergewinnung/Auswer¬ tung und Ausgabe von Informationen bzw. Daten verstanden werden. Ein derartiges System besteht aus einer EDV-Anlage, einem Datenbanksystem, Datenbank-Management-System, sowie Anwendungs- und Auswertungs¬ programmen, die auf das Informationssystem zugreifen können, sowie Ein- und Ausgabegeräten.
Unter einem Datenbanksystem, oder kurz Datenbank, soll entsprechend Duden, Informatik, 1993, 157 ff, ein System zur Beschreibung, Speicherung und Wiedergewinnung von umfangreichen Datenmengen verstanden werden, das von mehreren Anwendungsprogrammen benutzt werden kann. Dabei besteht die Datenbank aus einer Datenbasis, in der die Daten abgelegt werden, und Managementprogrammen, die die Daten entsprechend den vorgegebenen Beschreibungen abspeichern, verarbeiten, auswerten und wiederauffinden.
Unter Datenmodellierung soll nach Candace C. Fleming, Barbara von Halle, Ηandbook of Relational Data Base Design", 1989, Addison-Wesley Publishing Company, S. 11 ein Verfahren für den Entwurf von (inhaltlich) richtigen, konsistenten, von mehreren gleichzeitig nutzbaren und flexiblen Datenbanken unter Verwendung beliebiger Datenbank-Technologien verstanden werden.
ERSATZBUTT (REGEL 26) Die Güte einer Datenbank hängt wesentlich von der Qualität der Datenmodellierung und den daraus entstehenden logischen und physikalischen Datenstrukturen ab. Effektive Datenmodellierung ist daher seit vielen Jahren ein wichtiges Ziel der Entwicklung und Forschung im Datenbank-Bereich.
1977 entwickelte z.B. das American National Standards Institute (ANSI) (ANSI/X3/SPARC Committee) Anforderungen an effektive Datenbanksysteme. Diese Anforderungen unterscheiden die folgenden drei Entwurfs-Schritte für die Modellierung von Daten in einem Datenbanksystem (Fleming, v. Halle, Seite 18ff):
(1 ) Externes Datenstrukturmodell (engl.: "extemal Schema"): eine Betrachtungsweise der Daten, Beschreibung der Datenstruktur und der notwendigen Be- und Verarbeitungsregeln aus der Sicht und entsprechend den Anforderungen eines Anwenders oder Programmierers (nach Thomas A. Bruce, "Designing Quality Databases with IDEF1X Information Models", Dorset House Publishing, 1992, S. 532).
(2) Internes oder physikalisches Datenstrukturmodell (engl.: "intemal Schema", "physical model"): eine Anordnung der Daten in einem physikalischen Datenstrukturmodell entsprechend der internen (physikalischen) Zugriffslogik des Datenbank-Managemensystems, z.B. in relationalen, sequentiellen, hierarchischen oder anders strukturierten Datenbank-Systemen (Bruce, S. 543).
In einem physikalischen Datenstrukturmodell werden bei bekannten Datenmodellierungs-Lösungen sogenannte Objekte oder Entitäten (englisch "entities"), die Personen, Sachen, Lokalitäten u. dgl. sein können, Merkmale (auch Eigenschaften, charakterisierende Größen oder Attribute genannt) der Objekte und der Beziehungen (englisch "relationships") der Objekte untereinander beschrieben. Alle Informationen einer Datenbank, also sowohl die Objekte als auch ihre Beziehungen, als auch die Merkmale von Objekten und/oder Beziehungen werden z.B. in einer relationalen Datenbank durch Tabellen dargestellt.
ERSATZBUTT (REGEL 26) O 97/15015 PO7DE96/01719
- 3
(3) Konzeptionelles Datenstrukturmodell (engl.: "conceptual Schema"): ein integrierter Blick auf die Daten, die im gesamten geschäftlichen Umfeld benötigt und verarbeitet werden, unabhängig von deren physikalischer Anordnung und Speicherung (wie im physikalischen Datenstrukturmodell dargestellt) und unabhängig von deren Betrachtung durch Anwender und/oder Programmierer (wie im externen Datenstrukturmodell dargestellt) (Bruce, S. 529).
Bei bekannten Datenmodellierungs-Lösungen sind die Datenstrukturen und die Zugriffs- und Verarbeitungsanwendungen im konzeptionellen Datenstrukturmodell von einer konkret gestellten Aufgabe in einem Projekt, z.B. Erstellung eines Warenwirtschaftssystems, abgeleitet, und zur Identifizierung oder Beschreibung der zu verarbeitenden Objekte werden die konkreten Geschäftstätigkeiten und die bei der Implementierung vorhersehbaren, zu verarbeitenden Daten herangezogen (engl.: "business rules").
Unter Beachtung der Anforderungen an die Vorgehensweise bei der Datenmodellierung ist es daher notwendig, für den Entwurf eines Datenbanksystems mindestens die oben genannten drei unterschiedlichen logischen (externes und konzeptionelles Datenstrukturmodell) bzw. physikalischen Datenstrukturmodelle zu entwickeln.
Dies ist z.B. bei Fleming, von Halle S. 20 ff. beschrieben. Dabei wird im physikalischen Datenstrukturmodell für jedes wesentliche Objekt eine eigene Tabelle definiert (vgl. S. 280ff.). Diese Objekte werden zusammen mit ihren wichtigsten Merkmalen in unterschiedlich strukturierten Tabellen gespeichert. Es gibt also mindestens so viele Objekt-Tabellen wie es Objekte gibt. Damit entstehen Objekt-Tabellen, die aufgrund unterschiedlicher Objekt-Merkmale bzw. unterschiedlicher Beziehungen zwischen Objekten unterschiedliche Strukturen aufweisen. Für jede Tabelle muß es tabellenspezifische Eingabe-, Zugriffs-, Veränderungs- und Lösch-Algorithmen geben.
ERSATZBUTT (REGEL 26) Eine Erweiterung der Geschäftstätigkeit bzw. die Notwendigkeit, nachträglich weitere Daten hinzuzunehmen, bedeutet eine Veränderung bzw. Erweiterung aller Datenstrukturmodelle. Dies ist immer mit einem Redesign der (physikalischen und logischen) Datenbankstruktur, also mit entsprechendem Modellierungs- und Restrukturierungsaufwand verbunden, sowie mit einer meist sehr aufwendigen und kostenintensiven Veränderung der Anwendungsprogramme durch Programmier-Fachleute verbunden, soweit die externe Betrachtungsweise und veränderte Be- und Verarbeitungsregeln betroffen sind. Jede kleine Veränderung an der logischen und physikalen Datenstruktur bedingt eine Veränderung der Zugriffs- und Verarbeitungsalgorithmen.
Die Realisierungszeiten für solche nachträglichen Veränderungen entsprechen in keinster Weise den notwendigen operativen Anforderungen an die Verfügbarkeit der Informationen.
Ein Datenaustausch zwischen unterschiedlich strukturierten Informationssystemen ist, wenn überhaupt, nur auf der Basis des "kleinsten gemeinsamen Nenners", also der wenigen in der Regel übereinstimmenden Daten möglich, auch dies jedoch nur dann, wenn Daten zur Beschreibung von gleichartigen Objekten, Merkmalen und Beziehungen gleichartig strukturiert sind.
Beim Stand der Technik können nur solche Merkmale überhaupt gespeichert werden, deren Bedeutung - durch Definition des entsprechenden Feldes (= "Spalte") in der entsprechenden Objekte-Tabelle - vorgegeben ist. Dabei sind die Merkmale fest verbunden mit bestimmten Objekt-Typen, da die Merkmale nur in den Feldern der Tabelle ("Spalten") für einen bestimmten Objekt-Typ gespeichert werden können. Bereits bei der Anlage der Datenstruktur muß vorgesehen und vollständig implementiert werden, was später gespeichert werden kann. Informationsinhalte mit wechselnden, bzw. mit nicht vorhersehbaren Datenstrukturen können nicht oder nur rudimentär unterstützt werden.
ERSATZBUTT (REGEL 26) Ähnliches gilt auch für Beziehungen zwischen Objekten; diese können nur in dem Umfang miteinander verbunden werden, in dem bei der Anlage der Datenbankstruktur die Beziehungen zwischen den Objekten definiert wurden.
Beim Stand der Technik sind die Merkmale fest verbunden mit bestimmten Beziehungen, da die Merkmale nur in den "Feldern" der Tabelle (= "Spalten") für eine bestimmte Beziehung gespeichert werden können.
Unterschiedliche Verarbeitungsregeln für Objekte, die sich aufgrund organisatorischer, DV-technischer oder sicherheitstechnischer Vorgaben ergeben, werden in Bezug auf jede einzelne Objekt- bzw. Beziehungs-Tabelle angewendet. Dies hat zur Folge, daß der Aufwand für die Implementierung dieser Regel und die Überwachung ihrer korrekten Funktionalität mindestens linear mit der Anzahl der Tabellen ansteigt.
Beim Stand der Technik wird die Entwicklung von Informationssystemen bzw. von Datenstrukturmodelien und daraus abgeleiteten DV-Anwendungen für die Erfassung/Eingabe, Speicherung, Verarbeitung, Auswertung und Ausgabe von Informationen hochgradig aufgabenspezifisch definiert und gelöst. Dies geht zurück auf die die geltende tehrmeinung über das Design von Datenbanken, wie sie z.B. in dem Handbuch von Fleming und von Halle beschrieben ist, sowie auf die Anforderungsprofile (Ausschreibung von Software-Erstellungsaufträgen, Vorgabe entsprechender Pflichtenhefte) von Infoπnationssystem-Betreibem.
Derart spezifisch strukturierte Informationssysteme verursachen jedoch hohe Kosten für Entwicklung, Redesign, Programmierung, Wartung und Pflege.
Demgegenüber besteht die Aufgabe der Erfindung darin, ein Informationssystem, ein Verfahren zur Speicherung von Daten und eine Datenstruktur zu schaffen, die die Nachteile des Standes der Technik vermeiden
ERSATZBUTT (REGEL 26) und eine beliebige, auch nachträgliche Erweiterbarkeit des Informationssystems bzw. der Datenbasis ermöglichen.
Eine weitere Aufgabe der Erfindung besteht darin, eine optimale und maximale Kombinationsmöglichkeit der gespeicherten Daten zu ermöglichen.
Eine weitere Aufgabe der Erfindung besteht darin, den Zugriff auf Informationssysteme unterschiedlicher Inhalte und für unterschiedliche Aufgaben ("business rules") mit einheitlichen Zugriffs- und Transaktionsalgorithmen zu ermöglichen.
Eine weitere Aufgabe der Erfindung besteht darin, die Datenstruktur so zu gestalten, daß Zugriffsalgorithmen unabhängig von der physikalischen Datenstruktur verwendet werden können.
Eine weitere Aufgabe der Erfindung besteht darin, eine effektive Nutzung des physikalischen Speichers zu ermöglichen.
Die Erfindung ist in den Patentansprüchen näher beschrieben.
Die Erfindung liefert eine universelle physikalische Struktur eines Datenmodells, das es ermöglicht, (in einem sogenannten 'Teilsystem", siehe unten) beliebige und beliebig viele Objekte unterschiedlichen Objekt-Typs zu erfassen/einzugeben, zu speichern, zu verarbeiten und auszuwerten, diese Objekte mit beliebigen und beliebig vielen Merkmaien (Attributen) zu verknüpfen und damit zu identifizieren oder zu beschreiben, beliebige Objekte beliebigen Typs mit beliebigen anderen Objekten beliebigen Typs zu verbinden/zu verknüpfen und diesen Objekt-Verknüpfungen wiederum beliebige und beliebig viele Merkmale zuzuordnen, um damit die Objektverknüpfungen zu identifizieren oder zu beschreiben.
ERSATZBUTT (REGEL 26) Die Erfindung gewährleistet, daß auch solche Objekte in einem Datenbanksystem erfaßt, beschrieben/identifiziert, in Beziehung gesetzt und ausgewertet werden können, die, bzw. deren Merkmale und/oder Beziehungen und/oder Merkmale der Beziehungen bei der Strukturierung des Datenmodells bzw. Anlage der Datenbank noch nicht vorhersehbar oder bekannt waren. Damit ist eine beliebige, auch nachträgliche Erweiterbarkeit des Informationssystems möglich.
Die Erfindung vermeidet durch die Verwendung eines universellen physikalischen Datenstrukturmodells den Nachteil des Stands der Technik, der insbesondere in der jeweils spezifischen Abstimmung der Datenstruktur auf die konkret gestellten Aufgaben besteht und einhergeht mit aufwendigen, weil aufgabenspezifischen Implementierungen der Eingabe-/Erfassungs-, Verarbei- tungs-/Auswertungs-, Transaktions- und Ausgabealgorithmen. Damit ist ein Zugriff auf Informationssysteme unterschiedlicher Inhalte und für unterschiedliche Aufgaben mit einheitlichen Zugriffs- und Transaktionsalgorithmen möglich. Dabei sind die Zugriffs- und Transaktionsalgorithmen unabhängig von der Datenstruktur, da man nicht wissen muß, in welcher Tabelle ein spezifischer Inhalt steht. Man muß nur wissen, um welches Element es sich handelt.
Zudem wird mit der Erfindung eine effektive Nutzung des physikalischen Speichers ermöglicht, da im Unterschied zu bekannten Systemen nur die Speicherbereiche (Tabellen-Felder bzw. Spalten) "belegt" werden, die tatsächlich benutzt werden.
Die Erfindung ermöglicht unterschiedliche oder sich nachträglich verändernde logische Betrachtungsweisen (entsprechend dem externen bzw. konzeptionellen Datenstrukturmodell) durch die nachträgliche Veränderung von Be- und Verarbeitungsalgorithmen auf der Ebene der Anwendungsprogramme zu implementieren, ohne daß dadurch die grundlegenden Transaktions- und Zugriffsalgorithmen auf die physikalische Datenstruktur verändert werden müßten.
ERSATZBUTT (REGEL 26) Wo, z.B. im Hinblick auf den Zugriffsschutz, aus organisatorischen, geschäftlichen, DV-technischen, anwendungstechnischen oder sonstigen Gründen unterschiedliche "business rules" anzuwenden sind, erlaubt es die Erfindung, solcherart unterschiedlich zu verarbeitende Objekte, ihre Merkmale, Beziehungen und Merkmale von Beziehungen zu sogenannten "Objektklassen" zusammenzufassen, wobei für jede Objektklasse ein eigenes Teilsystem eingeführt wird. Wesentliches Merkmal der Erfindung ist es jedoch, daß alle Teilsysteme vollkommen identische physikalische Datenstrukturen aufweisen und daher mit den gleichen Transaktionsalgorithmen auf systemnaher Ebene für die Eingabe, Verarbeitung und Auswertung, Veränderung, Ausgabe und das Löschen bearbeitet werden können. Demgegenüber werden unterschiedliche Verarbeitungsregeln im obigen Sinne zwischen unterschiedlichen Objektklassen (= Teilsystemen) auf höherer Implementierungsebene, z.B. durch Programme des Datenbank-Managementsystems oder durch Anwendungsprogramme, realisiert.
Die Erfindung betrifft ein Informationssystem und insbesondere ein Verfahren für die Eingabe, Speicherung, Verarbeitung, Auswertung, Darstellung und Ausgabe von Informationen über
- die Existenz oder angenommene Existenz von beliebigen Objekten,
- die beschreibenden und/oder identifizierenden Merkmale von Objekten,
- die Beziehungen beliebiger Art und Anzahl zwischen Objekten beliebigen Typs und beliebiger Anzahl,
- über die beschreibenden und/oder identifizierenden Merkmale von Beziehungen zwischen Objekten
auf dafür geeigneten Speicher- und Verarbeitungssystemen (z.B. relationalen Datenbanksystemen - RDBMS). Die Erfindung geht davon aus, daß sämtliche Informationsinhalte auf die folgenden drei Grundelemente zurückgeführt werden können:
- Objekte,
- Merkmale und
- Beziehungen zwischen Objekten.
Jedes dieser Grundelemente wird in einem eigenen, physikalisch abgegrenzten Speicherbereich (z.B. einer eigenen Tabelle in einer relationalen Datenbank) gespeichert.
Objekte sind Abbilder eines Gegenstands des Wahrnehmens, Erkennens und Denkens, stellen also Abbilder von konkreten oder abstrakten Gegenständen dar. Objekte sind nicht die Gegenstände selbst, sondern stehen stellvertretend für diese.
Die Erfindung bietet die Möglichkeit, Objekte zu logischen Objekt-Typen zusammenzufassen. Dabei wird als "Objekt-Typ" eine Gruppe von gleichartigen Objekten verstanden (z.B. Personen, KFZ's, Buchtitel) bzw. generell von Objekten, die mit anderen Objekten des gleichen Objekt-Typs hinsichtlich ihrer Merkmale und/oder ihrer Beziehungen verglichen werden sollen.
Die Liste der zu verarbeitenden Objekt-Typen kann in einer Thesaurus- Liste der Objekt-Typen ("Typenliste") gespeichert werden. Diese Liste kann jederzeit vom Betreiber des Informationssystems angepaßt und verändert werden. Dazu ist weder Programmieraufwand erforderlich, noch eine Veränderung der Datenstruktur.
Mit der Erfindung ist es möglich, beliebige Objekte, die zu beliebigen Objekt-Typen gehören können, in einer einheitlichen Struktur in einer einzigen Grundtabelle für Objekte zu speichern. Die Anzahl der Objekte in der Grundtabelle
ERSATZBUTT (REGEL 26) für Objekte ist durch das Verfahren nicht beschränkt. Damit müssen für den Zugriff auf ein Objekt, d.h. einen Eintrag in der Objekte-Tabelle, die Zugriffs- und Verarbeitungsalgorithmen nur einmal definiert werden und sie können einheitlich auf sämtliche Objekte angewendet werden.
Merkmale sind identifizierende und/oder beschreibende Eigenschaften von Objekten bzw. von Beziehungen zwischen Objekten.
Erfindungsgemäß besteht jedes Merkmal aus zwei Bestandteilen:
- einem Merkmals-Begriff, der als Bezeichnung für den Inhalt des Merkmals verwendet wird und
- einer Merkmals-Bedeutung.
Da gleiche Merkmals-Begriffe in unterschiedlicher Bedeutung verwendet werden können ("Kiefer" = Gesichtsknochen, "Kiefer" = Nadelbaum) wird jedem Merkmals-Begriff seine Bedeutung mit einem Bedeutungs-Kennzeichen angefügt.
Die Merkmals-Bedeutung gibt an, in welcher Bedeutung der Merkmals-Begriff bei der späteren Verarbeitung, Auswertung und Ausgabe zu verstehen sein soll. Er ist eine Bewertung des Merkmals- Begriffs durch den Erfasser.
Erfindungsgemäß werden die Merkmale in einer eigenen Grundtabelle der Merkmale gespeichert.
Jedes Merkmal, bestehend aus Merkmals-Begriff und Merkmals- Bedeutung, wird in der Grundtabelle der Merkmale genau einmal gespeichert, wobei die Anzahl der Merkmale unbeschränkt ist. Die Vielfältigkeit der Merkmals-
ERSATZBUTT (REGEL 26) Begriffe bzw. der Merkmals-Bedeutungen ist ebenso unbeschränkt wie die Kombinationsmöglichkeiten aus Begriff und Bedeutung.
Die Erfassung und Vergabe von Begriffen wie auch die Erfassung und Vergabe von Merkmals-Bedeutungen kann durch eigene Thesauri kontrolliert werden.
Die Erfindung ermöglicht es außerdem, beliebige Objekte beliebigen Typs miteinander in Beziehung zu setzen, um dadurch zeitliche oder räumliche Beziehungen, Abhängigkeiten, Kausalitäten, Interaktionen und beliebige andere Beziehungen zwischen Objekten einzugeben, zu speichern, zu verarbeiten und auszuwerten. Beziehungen zwischen Objekten werden in einer eigenen Grundtabelle für Beziehungen gespeichert. Die Anzahl der Einträge in dieser Grundtabelle wird durch das Verfahren nicht beschränkt.
Der Erfindung ist es möglich, jedem Objekt beliebige und beliebig viele identifizierende und beschreibende Merkmale zuzuordnen. Sie schafft eine Verbindung zwischen Objekt-Schlüssel und Merkmals-Schlüssel in einer eigenen Verbindungs-Tabelle, wobei die Anzahl der Einträge in dieser Tabelle durch das Verfahren nicht beschränkt wird.
Die Erfindung ermöglicht es, jeder Beziehung zwischen Objekten beliebige und beliebig viele identifizierende und beschreibende Merkmale zuzuordnen. Sie schafft eine Verbindung zwischen Beziehungs-Schlüssel und Merkmals-Schlüssel in einer eigenen Verbindungs-Tabelle, wobei die Anzahl der Einträge in dieser Tabelle durch das Verfahren nicht beschränkt ist.
Die Erfindung faßt sämtliche Objekt-Typen, die den gleichen organisatorischen, DV-technischen, datenschutzrechtlichen oder sonstigen Verarbeitungsregeln ("business rules") unterliegen, in einer logischen Objektklasse zusammen. Solcherart zusammengehörige Objekte, Merkmale von Objekten, Beziehungen zwischen Objekten und Merkmale von Objektbeziehungen einer Objektklasse werden in einem 'Teilsystem" gespeichert. Die physikalische Datenstruktur aller Teilsysteme ist identisch; daher können für jedes Teilsystem die gleichen Transaktions- und Zugriffsalgorithmen verwendet werden. Unterschiedliche Verarbeitungsregeln (z.B. für Datenschutz, -Überwachung und -protokollierung) werden in dafür spezifischen Verarbeitungsalgorithmen implementiert. Derartige Änderungen der Verarbeitungsregeln können einmal und an zentraler Stelle vorgenommen werden, ohne daß die physikalische Datenstruktur verändert werden muß.
Die notwendigen Verbindungen zwischen zwei Teilsystemen werden in einer Verbindungs-Tabelle zwischen diesen Teilsystemen gespeichert, wobei die Schlüssel der Objekte aus beiden Teilsystemen als Fremdschlüssel in der Verbindungs-Tabelle verwendet werden.
Auch die Verbindungs-Tabellen zwischen Teilsystemen unterliegen einheitlichen und an zentraler Stelle definierten Zugriffs- und Verarbeitungs¬ algorithmen.
Die Anzahl der Teilsysteme innerhalb eines Gesamtsystems ist durch das Verfahren ebensowenig beschränkt wie die Anzahl der notwendigen Verbindungs-Tabellen zwischen Teilsystemen, deren Objekte miteinander in Beziehung stehen.
Die oben dargestellten Grundelemente des Verfahrens - Objekte und Merkmale, sowie die Beziehungen zwischen Objekten - können als Entitäten im Sinne des Entity-Relationship-Modells betrachtet werden. Diese Grundelemente/Entitäten werden in den oben erwähnten Grundtabellen gespeichert, wobei ein individuelles Element eines Grundelements durch einen eigenen Eintrag in der zugehörigen Grundtabelle repräsentiert ist. Zur eindeutigen
ERSATZBUTT (REGEL 26) Identifizierung innerhalb der Datenbank trägt jeder Eintrag jeder Grundelemente- Tabelle einen eindeutigen, z.B. numerischen, Schlüssel.
Zur Repräsentierung des Eintrags bei der Erfassung und Ausgabe wird jeder Elemente-Eintrag ergänzt um einen (i.d.R.) textuellen Bezeichner für das Element (z.B. Namen des Objekts) oder Bezeichner der Beziehung (z.B. "ist Vater von"). Dieser Bezeichner dient als symbolischer Stellvertreter des Elements bei der Eingabe und Ausgabe.
Im Falle der Grundtabelle für Merkmale wird dieser textuelle Bezeichner ersetzt durch das Paar aus Merkmals-Begriff und Merkmals-Bedeutung.
Eine Grundtabelle kann weitere Felder enthalten, dies ist jedoch für das Verfahren irrelevant.
Thesaurus-Listen für Merkmals-Begriffe und -Bedeutungen, sowie die Thesaurus-Liste der Objekt-Typen stellen weitere Entitäten dar. Sie werden in Thesaurus-Tabellen gespeichert. Thesaurus-Tabellen werden in gleicher Weise behandelt wie Grundtabellen.
Zum Speichern der Verbindungen bzw. Beziehungen zwischen Grundelementen werden Verbindungs-Tabellen verwendet. Jeder Eintrag einer Grundelemente-Tabelle überträgt sein eindeutig identifizierendes Schlüsselfeld an die Verbindungs-Tabelle. Ein Eintrag in der Verbindungs-Tabelle besteht somit (mindestens) aus dem Paar aus dem Schlüssel des Eintrags aus der einen und dem Schlüssel des Eintrags aus der anderen Grundtabelle.
Die aus den Grundelemente-Tabellen übernommenen Schlüssel (Fremdschlüssel, engl.: "foreign keys") bilden nicht zwangsläufig zusammen den eindeutig identifizierenden Schlüssel eines Eintrags in der Verbindungs-Tabelle. Vielmehr eröffnet das Verfahren auch die Möglichkeit, einem Eintrag der
ERSATZBUTT (REGEL 26) Verbindungs-Tabelle zusätzlich einen eigenen eindeutigen Schlüssel zuzuordnen. Damit wird es möglich, daß in einer Verbindungs-Tabelle die gleichen Einträge aus Grundtabellen mehrfach miteinander verbunden werden (z.B. A ist Halter des Fahrzeugs B; A ist Eigentümer des Fahrzeugs B).
Als wesentliche Alternativen der Verbindung zwischen Grundelementen (engl.: "relationships") sind zu unterscheiden:
1 1
1 N
M N
Nach bisherigem Stand der Technik wurden für diese drei wesentlichen Alternativen der Verbindung zwischen Grundelementen auf Ebene der physikalischen Datenstruktur drei verschiedene Datenstrukturelemente benötigt, um die Schlüssel der verbundenen Elemente zu speichern:
- Bei 1 :1 -Verbindungen zwischen einer Entität 1 und einer Entität 2 vererbt Entität 1 ihren Schlüssel als Fremdschlüssel an Entität 2 und umgekehrt vererbt Entität 2 ihren Schlüssel als Fremdschlüssel an Entität 1. Beide Entitäten müssen somit um ein Feld für den Fremdschlüssel erweitert werden.
- Bei 1 :N-Verbindungen zwischen einer Entität 1 und einer Entität 2 vererbt Entität 2 ihren Schlüssel als Fremdschlüssel an Entität 1 ; er verweist in jedem Element von Entität 1 auf jedes der N verbundenen Elemente aus Entität 2.
- Bei M:N-Verbindungen zwischen einer Entität 1 und einer Entität 2 wird nach dem Stand der Technik eine eigene Verbindungstabelle generiert. Sie enthält als Mindesteinträge für jede Verbindung den Schlüssel des verbundenen Elements aus Entität 1 sowie den Schlüssel des damit verbundenen Elements aus Entität 2.
ERSATZBUTT (REGEL 26) Bei der vorliegenden Erfindung werden dagegen Verbindungen zwischen Grundelementen ausschließlich in eigenen Verbindungs-Tabellen gespeichert und zwar unabhängig davon, wieviele Einträge einer Entität mit wievielen anderen Einträgen einer anderen Entität verbunden werden sollen oder dürfen.
Die stete Verwendung einer eigenen Verbindungs-Tabelle gewährleistet, daß die umfassendste Alternative der Zuordnung (= M : N) dargestellt werden kann und ermöglicht gleichzeitig, daß auch weniger umfassende Alternativen (1 : 1 bzw. 1 : N) in dieser Verbindungs-Tabelle gespeichert werden können.
Die einheitliche Verwendung von Verbindungs-Tabellen zwischen verbundenen Entitäten anstelle einer Erweiterung der Entitäten selbst (wie nach dem Stand der Technik bei 1 :1- bzw. 1 :N-Verbindungen nötig) stellt femer sicher, daß einheitliche, zentral definierte Zugriffs- und Verarbeitungsalgorithmen angewendet werden können - unabhängig von der tatsächlichen Anzahl der Verbindungen zwischen zwei Entitäten. Notwendige Einschränkungen der Verbindungsmöglichkeiten, z.B. aus organisatorischen Gründen, können durch Anwendungsprogramme realisiert werden, die "oberhalb" der zentral definierten Zugriffs- und Verarbeitungsalgorithmen aufsetzen.
Ein Eintrag der Verbindungs-Tabelle kann um weitere Felder ergänzt werden. Weitere Felder können insbesondere verwendet werden, um den Eintrag bei Eingabe und Ausgabe gegenüber dem Anwender zu kennzeichnen (A "ist Vater von" B), aber auch, um Angaben über das Datum zu speichern, an dem der Eintrag angelegt oder verändert wurde, an dem der Eintrag gelöscht werden soll oder über den Erfasser / letzten Bearbeiter des Eintrags.
Weitere Felder in einer Verbindungs-Tabelle können insbesondere auch benutzt werden, um die getroffene Zuordnung näher zu bewerten, z.B. hinsichtlich
ERSÄΓZBUTT (REGEL 26) der zeitlichen Relevanz (Beginn und Ende der Zuordnung zwischen Buchtitel und Ausleiher = Anfang und Ende der Leihfrist), aber auch hinsichtlich der Bewertung der Existenz der Beziehung durch den Erfasser (Beziehung existiert faktisch/fiktiv) oder der Bewertung des Verifizierungsstatus einer Zuordnung (z.B. einer Zeugenaussage in einem polizeilichen Informationssystem).
Die Erfindung ermöglicht es somit, in ein und demselben Informationssystem Informationen unterschiedlichen Wahrheits- oder Relevanzgehaltes zu speichern und aufgrund vorgenommener Bewertungen dennoch voneinander zu unterscheiden. Informationssysteme auf der Grundlage der vorliegenden Erfindung können daher verwendet werden, um Hypothesen, sowie Simulationen und Szenarien zu entwickeln und diese mit Fakten abzugleichen.
Die Grundtabelle der Beziehungen zwischen Objekten nimmt eine Doppelrolle ein: Sie stellt eine Grundtabelle dar und wird behandelt wie eine Grundtabelle. Gleichzeitig stellt sie eine Verbindungs-Tabelle in dem Sinne dar, daß sie die Verbindung von zwei Objekten (des gleichen Teilsystems) speichert. Diese Tabelle vereinigt somit die Vorteile beider Tabellen-Varianten:
Als Grundtabelle stellt sie die Beziehung zwischen Objekten wie ein Objekt selbst dar und ermöglicht es, die Beziehung insbesondere mit beliebigen identifzierenden und beschreibenden Merkmalen zu verknüpfen.
Als Verbindungs-Tabelle eröffnet sie den Vorteil, daß beliebige Objekte mit beliebigen anderen Objekten in Beziehung gesetzt/verbunden werden können, ohne daß es dazu weiterer Tabellen-Strukturen bedarf.
Verbindungs-Tabellen zwischen (den Objekten von) unterschiedlichen Teilsystemen weisen die gleiche Struktur auf wie die Grundtabelle der Beziehungen zwischen Objekten und eröffnen somit die gleichen Vorteile.
ERSATZBUTT (REGEL 26) Ausführungsbeispiele werden anhand der Zeichnungen näher beschrieben. Es zeigen:
Fig. 1 eine schematische Darstellung eines Informationssystems;
Fig. 2 den Aufbau eines Eintrags in einer Grundtabelle für Objekte gemäß einem ersten Ausführungsbeispiel der Erfindung;
Fig. 3 den Aufbau einer Thesaurus-Liste für Objekt-Typen;
Fig. 4 den Aufbau eines Eintrags in einer Grundtabelle für Beziehungen gemäß dem ersten Ausführungsbeispiel der Erfindung;
Fig. 5 den Aufbau eines Eintrags in einer Grundtabelle für Merkmale gemäß dem ersten Ausführungsbeispiel der Erfindung;
Fig. 6 den Aufbau eines Eintrags in einer Thesaurus-Liste für Merkmals- Begriffe gemäß einem weiteren Ausführungsbeispiel der Erfindung;
Fig. 7 den Aufbau eines Eintrags in einer Thesaurus-Liste für Merkmals- Bedeutungen gemäß einem weiteren Ausführungsbeispiel der Erfindung;
Fig. 8 ein Schema der Darstellung und Speicherung der Verbindungen zwischen zwei Grundelementen (Objekt und Merkmal);
Fig. 9 ein Schema der Darstellung und Speicherung der Verbindung zwischen Grundbelegen und Verwaltungs-Objekten gemäß einem weiteren Ausführungsbeispiel der Erfindung;
ERSATZBUTT (REGEL 26) Fig. 10 eine Gesamtdarstellung der erfindungsgemäßen Datenstruktur für ein Teilsystem; und
Fig. 11 eine Gesamtdarstellung der erfindungsgemäßen Datenstruktur mit drei Teilsystemen.
Fig. 1 zeigt eine schematische Darstellung eines Informationssystems 100, das aus einer EDV-Anlage 110 und einem Speicher 120 besteht. Auf dem Speicher 120, der irgendein maschinen-lesbarer Speicher sein kann, sind ein Datenbanksystem 130, bestehend aus einem Datenbank-Management-System 140 und einer Datenbasis 150, sowie Anwendungsprogramme 160 gespeichert, die in bekannter Weise in die Zentraleinheit der EDV-Anlage 110 geladen werden und auf das Datenbanksystem 130 zugreifen können. Außerdem können in bekannter Weise externe Benutzer über entsprechende Anwendungsprogramme auf das Informationssystem 100 bzw. das Datenbanksystem 130 zugreifen.
Das Informationssystem weist weiterhin Eingabegeräte 180 und Ausgabegeräte 190 auf, über die Daten bzw. Informationen in das Informationssystem eingegeben bzw. davon ausgegeben werden können.
In sogenannten Client-/Server-Architekturen können externe Benutzer über Anwendungsprogramme 181 , die auf den Eingabegeräten 180 ablaufen, bzw. Anwendungsprogramme 191 , die auf den Ausgabegeräten 190 ablaufen, auf das Informationssystem 100 bzw. das Datenbanksystem 130 zugreifen.
Erfindungsgemäß werden sämtliche verarbeitbaren Daten bzw. Informationen auf drei Grundelemente zurückgeführt:
1. Objekte
2. Beziehungen zwischen den Objekten und
ERSATZBUTT (REGEL 26) 3. Merkmale zur Beschreibung und/oder Identifizierung von Objekten und/oder Beziehungen.
Wesentlich ist dabei, daß jedes Grundelement in einem physikalisch oder logisch abgegrenzten Speicherbereich auf dem Speicher 120 gespeichert wird und dieser Speicherbereich für die Speicherung jedes einzelnen Elements die gleiche Struktur aufweist. Bei einer relationalen Datenbank stellen diese Speicherbereiche z.B. eigene Tabellen dar.
Objekte sind Abbilder eines Gegenstand(s) des Wahmehmens, Erkennens und Denkens, stellen also Abbilder von konkreten oder abstrakten Gegenständen dar.
Erfindungsgemäß können gleichartige oder miteinander zu vergleichende Objekte zu logischen Objekt-Typen zusammengefaßt werden. Im Handbuch von Fleming, von Halle ist ab S. 88 eine Vorgehensweise beschrieben, wie man während des Designs eines Datenbank-Strukturmodells die notwendigen Objekt-Typen hinreichend vollständig identifizieren und erfassen kann. Diese Vorgehensweise kann für das voriiegende Verfahren übernommen werden, um die notwendigen Objekt-Typen zu identifizieren.
Beispiele für Objekt-Typen
in einem Bibliotheksinformationssystem: Personen (Benutzer)
Medien (Titel von Büchern, Schallplatten usw.)
in einem Personalinformationssystem: Personen (Arbeitnehmer)
Organisationseinheiten (Dienststellen, Abteilungen) usw.
ERSATZBUTT (REGEL 26) in einem polizeilichen Informationssystem: Personen nicht-natürliche Rechtspersonen
Fahrzeuge
Waffen, Munition
Objekte (Gebäude) usw.
Die Liste der zu verarbeitenden Objekt-Typen wird in einer Thesaurus- Liste für Objekt-Typen ("Typenliste") gespeichert, was später näher beschrieben wird. Diese Liste kann jederzeit vom Betreiber des Informationssystems verändert und erweitert werden. Dazu ist weder Programmieraufwand erforderlich, noch eine Veränderung der Datenbankstruktur notwendig.
Bei einem weiteren Ausführungsbeispiel der Erfindung können gleichartig zu verarbeitende Gruppen von Objekt-Typen zu einer Objektklasse zusammengefaßt und in einem eigenen Teilsystem be- und verarbeitet werden.
Innerhalb eines Teilsystems werden sämtliche Objekte, die beliebigen Objekt-Typen angehören können, in einer und nur einer Grundtabelle für Objekte gespeichert.
Fig. 2 zeigt den Aufbau eines Eintrags in einer Grundtabelle für Objekte. Dabei ist ein Objekt repräsentiert durch die Einträge in einer Zeile (englisch "row") in der Tabelle.
Ein Objekt wird durch einen eindeutigen Schlüssel identifiziert. Dieser Schlüssel wird in einem eigenen Schlüsselfeld 210 der Zeile hinterlegt. Ein Objekt wird durch einen Bezeichner 220 benannt. Dieser Bezeichner steht stellvertretend für das Objekt; er hat die Aufgabe, das Objekt bei der Ersteingabe zu benennen und er wird bei der Verarbeitung, besonders aber bei der Ausgabe gegenüber dem Anwender verwendet, um das Objekt zu bezeichnen.
ERSATZBUTT (REGEL 26) Es ist notwendig, Objekte unterschiedlichen Typs voneinander zu unterscheiden, um gleichartige Objekte in gleicher Weise eingeben, verarbeiten, speichern und ausgeben zu können. Dazu wird ein eigener Typen-Kennzeichner 230 für den Objekt-Typ eingeführt. Er verweist als Fremdschlüssel auf die Typenliste", die nachfolgend anhand von Fig. 3 näher beschrieben wird.
Der Eintrag für ein Objekt kann um weitere Felder 240 etc. erweitert werden, wenn dies aus organisatorischen Gründen, aufgrund von Sicherheitsanforderungen oder aus sonstigen Gründen im Einzelfall notwendig erscheint.
In möglichen weiteren Feldern können z.B. gespeichert werden:
- Angaben über den Verarbeitungs- oder Verfügbarkeitsstatus des Objekts,
- Angaben über den Ersteller des Objekts,
- Angaben über das Datum der Eingabe/des Anlegens dieses Objekts,
- Zeitpunkt der Existenz des Objekts,
- bewertende Angaben über die Existenz des Objekts (Existenz gesichert / verifiziert / hypothetisch angenommen / usw.)
- usw.
Die Liste der zu verarbeitenden Objekt-Typen wird in einer Thesaurus- Liste für Objekt-Typen ("Typenliste") gespeichert. Diese Liste kann jederzeit vom Betreiber des Informationssystems verändert und erweitert werden. Dazu ist weder Programmieraufwand erforderlich, noch eine Veränderung der Datenbankstruktur notwendig.
Der Aufbau der Thesaurus-Liste für Objekt-Typen ist in Fig. 3 dargestellt. Dabei haben die einzelnen Felder die folgende Bedeutung:
ERSATZBUTT (REGEL 26) - der Typen-Schlüssel 310 ist ein eindeutiger Schlüssel, in der Regel ein Kunstschlüssel, der den Objekt-Typ innerhalb des Systems identifiziert.
Der Typenschlüssel 310 aus der in Fig. 3 dargestellten Thesaurus-Liste der Objekt-Typen wird als Fremdschlüssel 230 in die in Fig. 2 dargestellte Grundtabelle der Objekte übertragen. Er identifiziert den Objekt-Typ, zu dem jeder Eintrag (Zeile) in der Grundtabelle der Objekte gehört.
- der Typen-Bezeichner (Sprache 1 ) 320 ist ein entsprechend den spezifischen Anforderungen des Betreibers geeignet langes und geeignet formatiertes Feld für die Speicherung der Bezeichnung des Objekt-Typs. Dieses wird verwendet, um den Objekt-Typ in Anwendungen und bei der Ausgabe von Informationen zu benennen.
In mehrsprachigen Systemen können die fremdsprachigen Typen- Bezeichner in weiteren Feldern 330 etc. gespeichert werden, um ein "fliegendes" Umschalten zwischen zwei oder mehr Anwendungssprachen zu ermöglichen.
Die Thesaurus-Liste der Objekt-Typen kann erweitert werden um weitere Felder 340 etc., wenn dies aus organisatorischen Gründen, aufgrund von Sicherheitsanforderungen oder aus sonstigen Gründen im Einzelfall notwendig erscheint.
Zwischen Objekten beliebigen Typs können beliebig viele Beziehungen oder Verbindungen (englisch "relationships") bestehen. Sie werden verwendet, um beliebige Beziehungen, Abhängigkeiten, Kausalitäten, Interaktionen usw. zwischen den Objekten einzugeben, zu speichern, zu verarbeiten und auszuwerten.
Solche Beziehungen können z.B. sein:
ERSATZBUTT (REGEL 26) - Verwandtschaftsverhältnisse zwischen Personen,
- Besitzverhältnisse zwischen Personen und Sachen,
- Angaben über den Wohn- oder Aufenthaltsort einer Person,
- Ausleihe eines Titels einer Bibliothek durch den Ausleiher usw.
Die Beziehungen werden in einer eigenen Grundelemente-Tabelle gespeichert. Der Aufbau eines Eintrags in der Grundtabelle für Beziehungen ist in Fig. 4 dargestellt.
Für eine Beziehung zwischen zwei Objekten speichert diese Tabelle in einem Eintrag (Zeile) folgende Details in den Feldern:
- als "Beziehungs-Schlüssel" 410 einen eindeutigen Schlüssel der Beziehung. Der Schlüssel kann gebildet werden als eindeutiger Kunstschlüssel, z.B. numerischer Schlüssel, oder als zusammengesetzter Schlüssel aus dem Schlüssel des Objekts 1 und des Objekts 2, sofern dadurch Eindeutigkeit gewahrt bleibt;
- Schlüssel 420 von Objekt 1 , das von der Beziehung betroffen ist;
- Schlüssel 430 von Objekt 2, das von der Beziehung betroffen ist;
- Bezeichnung der Beziehung 440, gesehen vom Objekt 1 auf das Objekt 2, als optionale Angabe;
- Bezeichnung der Beziehung 450, gesehen vom Objekt 2 auf das Objekt 1 , als optionale Angabe;
- weitere Felder 460 etc.: der Eintrag (Zeile) für eine Beziehung kann erweitert werden um weitere Felder, wenn dies aus organisatorischen Gründen, aufgrund von Sicherheitsanforderungen oder aus sonstigen Gründen im Einzelfall notwendig erscheint.
In möglichen weiteren Feldern können z.B. gespeichert werden:
ERSATZBUTT (REGEL 26) - Angaben über den Verarbeitungs- oder Verfügbarkeitsstatus der Beziehung,
- Angaben über das Datum der Eingabe/des Anlegens dieser Beziehung,
- Angaben über den Ersteller der Beziehung,
- Angaben über den Zeitpunkt oder Zeitraum der Existenz der Beziehung,
- bewertende Angaben über die Existenz der Beziehung (Existenz gesichert / verifiziert / hypothetisch angenommen / usw.)
- usw.
In einem weiteren Ausführungsbeispiel der Erfindung ist es möglich, Bezeichnungen von Beziehungen entsprechend 440 und 450 nicht direkt zu speichern, sondern aus einem Thesaurus der Beziehungs-Bezeichnungen zu versorgen.
Merkmale sind beschreibende oder identifizierende Eigenschaften von Objekten und/oder Beziehungen zwischen Objekten. Jedes Merkmal besteht aus zwei Bestandteilen: einem Merkmals-Begriff und einem Kennzeichner für die Bedeutung des Merkmals.
Ein Merkmals-Begriff ist ein beliebiger Speicher- und verarbeitbarer Begriff, der ais (symbolische) Bezeichnung für den Inhalt des Merkmals verwendet wird. Es kann sich dabei handeln um:
- einen textuellen Begriff einer beliebigen Sprache oder eines Textsymbolvorrats (z.B. groß/klein, rot/blau/grün, München/Köln/Hamburg)
- einen numerischen Wert (z.B. 1.80, 80553, 26.08.1995)
- einen weder textuellen noch numerischen Wert (z.B. Klangmuster, grafisches Muster, Film- oder Videosequenz usw.).
ERSATZBUTT (REGEL 26) Wesentlich für die Wahl des Merkmals-Begriffs im Sinne dieser Definition ist seine Eignung auf die spätere Vergleichbarkeit mit anderen, gleichartigen Begriffen.
Da gleiche Merkmals-Begriffe in unterschiedlicher Bedeutung verwendet werden können (z.B. "Kiefer" gleich "Gesichtsknochen" und "Nadelbaum") wird jeder Merkmals-Begriff mit einem Kennzeichner für die Merkmals-Bedeutung versehen. Der Bedeutungs-Kennzeichner gibt an, in welcher Bedeutung der Merkmals-Begriff bei der späteren Verarbeitung, Auswertung und Ausgabe zu verstehen sein soll. Er ist eine Bewertung der Bedeutung durch den Erfasser.
Jedes Merkmal(spaar) wird in der Grundelemente-Tabelle für Merkmale genau einmal gespeichert. Ein Merkmal "Müller: Familienname" kommt also auch für das Einwohnermelderegister einer Stadt nur einmal vor. Erst seine Anwendung = Verbindung mit dem Objekt (vom Typ Person), das den Familiennamen "Müller" trägt, kommt so oft vor, wie es Müllers gibt.
Der Aufbau eines Eintrags in der Grundtabelle für Merkmale ist in Fig. 5 dargestellt. Der Eintrag (Zeile) für ein Merkmal(spaar) besteht mindestens aus den folgenden Feldern:
- Merkmals-Schlüssel 510: eindeutiger Schlüssel für das Merkmal. Der Schlüssel kann - entsprechend den Anforderungen an die Optimierung des Zugriffs - aus einem Kunstschlüssel bestehen (z.B. numerischer Kennzeichner in einem Datenbanksystem). Der Schlüssel kann auch aus dem Paar Merkmals- Begriff/Bedeutungs-Kennzeichner selbst bestehen, das entsprechend der Anlage des vorliegenden Systems ohnehin nur einmal vorkommen kann.
- Merkmals-Begriff 520: ein entsprechend den spezifischen Anforderungen des Betreibers geeignet langes und geeignet formatiertes Feld für die Aufnahme der Merkmals-Begriffe oder eines Schlüsselverweises auf den
ERSATZBUTT (REGEL 26) Begriff des Merkmals, sofern die Vergabe von Merkmals-Begriffen durch einen Thesaurus unterstützt wird.
- Bedeutungs-Kennzeichner für Merkmals-Begriffe 530: ein entsprechend den spezifischen Anforderungen des Betreibers geeignet langes und geeignet formatiertes Feld für die Aufnahme des Bedeutungs-Kennzeichners oder eines Schlüsselverweises auf den Bedeutungs-Kennzeichner, sofern die Vergabe der Bedeutungs-Kennzeichner durch einen Thesaurus unterstützt wird.
- Der Eintrag (Zeile) für ein Merkmal kann erweitert werden um weitere Felder 540 etc., wenn dies aus DV-technischen, organisatorischen, aufgrund von Sicherheitsanforderungen oder aus sonstigen Gründen im Einzelfall notwendig erscheint.
Um Mehrdeutigkeiten und abweichende Schreibweisen bei an sich gleichen Begriffen zu vermeiden, kann bei einem weiteren Ausführungsbeispiel der Erfindung die Auswahl und Vergabe von Merkmals-Begriffen durch einen Thesaurus unterstützt werden (kontrolliertes Vokabular). Die Thesaurus- Unterstützung kann sich auf einzelne oder alle zu verwendenden Begriffe beziehen. Beim Thesaurus der Merkmals-Begriffe handelt es sich um eine vom Betreiber des Informationssystems selbst zu definierende und zu erweiternde Thesaurus-Liste, in der die zulässigen Begriffe für die Merkmale von Objekten und/oder Beziehungen vorgegeben werden.
Beispiele für einenThesaurus von Merkmals-Begriffen:
Bundesländer in einem Einwohnermeldesystem Bayern
Baden-Württemberg Brandenburg
ERSATZBUTT (REGEL 26) Abteilungsbezeichnungen in einem Personalinformationssystem Fahrzeug- oder Waffenfabrikate in einem polizeilichen Informationssystem
Mit der Vorgabe eines Thesaurus für die Merkmals-Begriffe erreicht ein Betreiber, daß gleichartige Merkmals-Begriffe von unterschiedlichen Anwendern auch gleichartig benutzt werden. Dies verbessert die spätere Vergleichbarkeit von Merkmalen, da die Gefahr reduziert oder ganz ausgeschaltet wird, daß für ein und dasselbe Merkmal unterschiedliche Merkmals-Begriffe oder an sich gleichartige Merkmals-Begriffe in unterschiedlicher (auch fehlerhafter) Schreibweise bei der Eingabe, Auswertung und bei der Ausgabe verwendet werden.
Wenn eine solche Thesaurus-Liste geführt wird, so besteht ein Eintrag (Zeile) der Thesaurus-Liste aus den in Fig. 6 dargestellten Feldern, die die folgende Bedeutung haben:
- Schlüsselfeld 610 des Merkmals-Begriffs: ein eindeutiger Schlüssel, insbesondere auch Kunstschlüssel für den Begriff, der als Referenz für den Begriff verwendet wird (Fremdschlüssel, englisch "foreign key"), wenn dieser Begriff im Feld 520 in der Tabelle der Merkmale verwendet wird.
- Begriff des Merkmals (Sprache 1 ) 620 ist ein entsprechend den spezifischen Anforderungen des Betreibers geeignet langes und geeignet formatiertes Feld für die Speicherung einer für den Erfasser, Verarbeiter und Auswerter der Information verständlichen, in der Regel textuellen Begriffsangabe des Merkmals (z.B. (bei Bundesländern: Bayern, Baden-Württemberg, Brandenburg, ... )
ERSATZBUTT (REGEL 26) In mehrsprachigen Systemen können fremdsprachige Merkmals-Begriffe in weiteren Feldern 630 etc. gespeichert werden, um ein "fliegendes" Umschalten zwischen zwei oder mehreren Anwendungssprachen zu ermöglichen.
In weiteren, optionalen Feldern 640 etc. können weitere Angaben gespeichert werden, wenn dies im Einzelfall notwendig ist. Weitere Felder können z.B. enthalten
- Angaben über die Anzeige-Reihenfolge von Merkmals-Begriffen (z.B. "Bayern", "Baden-Württemberg", "Brandenburg" usw). die zu ein- und derselben Merkmals-Bedeutung gehören,
- Angaben über die Verfügbarkeit oder Benutzbarkeit des Begriffs durch bestimmte Anwender,
usw.
Um Mehrdeutigkeiten bei der Erfassung und der Bedeutungs-Bewertung von Merkmalen zu vermeiden, kann bei einem weiteren Ausführungsbeispiel der Erfindung die Auswahl und Vergabe der Bedeutungs-Kennzeichner durch einen Thesaurus unterstützt werden. Dabei handelt es sich um eine vom Betreiber des Informationssystems selbst zu definierende und zu erweiternde Thesaurus-Liste, in der die zulässigen Bedeutungs-Kennzeichner für die Merkmale von Objekten und Beziehungen vorgegeben werden.
Ein Beispiel für einen einfachen Thesaurus der Merkmals-Bedeutungen könnte sein:
Familienname Künstlername Ordensname Geburtsname
ERSATZBUTT (REGEL 26) Geschiedenenname
Vorname erster Vorname weiterer Vorname
Mit der Vorgabe eines Thesaurus erreicht ein Betreiber, daß gleichartige Bedeutungen von Merkmalen von unterschiedlichen Anwendern auch gleichartig benutzt werden. Dies erhöht die spätere Vergleichbarkeit von Merkmalen, da die Gefahr reduziert oder ganz ausgeschaltet wird, daß für ein und dasselbe Merkmal unterschiedliche Merkmals-Bedeutungen bei der Eingabe, Auswertung und Ausgabe verwendet werden.
Wenn eine solche Thesaurus-Liste geführt wird, so besteht ein Eintrag (Zeile) der Thesaurus-Liste aus den in Fig. 7 dargestellten Feldern, die die folgende Bedeutung haben:
- Schlüsselfeld des Bedeutungs-Kennzeichners 710: ein eindeutiger Schlüssel für den Bezeichner, der als Referenz für den Bezeichner verwendet wird (Fremdschlüssel, engl.: "foreign key"), wenn dieser Bezeichner in der Tabelle der Merkmale verwendet wird. Dieser Schlüssel kann in hierarchischer Klassifikation und Notation aufgebaut werden. Ein Beispiel hierfür kann sein:
I xxxxx Oberbegriff der 1. Ordnung
I I xxxx 1. Unterbegriff zur 1. Ordnung
I I I xxx 1. Unterbegriff zum 1. Unterbegriff der 1. Ordnung usw.
ERSATZBUTT (REGEL 26) Die hierarchische Klassifikation und entsprechende Notation kann bei der Auswertung von Merkmalen dazu verwendet werden, mit Oberbegriffen zu suchen, wobei auch detaillierte Unterbegriffe eingeschlossen werden können.
- Kennzeichner für die Merkmals-Bedeutung 720: eine für den Erfasser, Verarbeiter und Auswerter der Information verständliche, in der Regel textuelle Angabe der Bedeutung des Merkmals (z.B. "Familienname", "Geburtsort", "Kfz-Fabrikat" usw.).
- Kennzeichner in einer weiteren Sprache / weiteren Sprachen 730 etc. In den Fällen, in denen Informationssysteme mehrsprachig geführt werden müssen, kann der Begriff des Bedeutungs- Kennzeichners in weiteren Feldern in einer oder mehreren anderen Sprachen oder Codeformen angegeben werden. Dies ermöglicht die "fliegende" Umschaltung von einer zur anderen Sprache oder zu anderen Bedeutungsvarianten, ohne den eigentlichen Informationsgehalt (eindeutig identifiziert durch den Schlüssel in 710) des Bedeutungs-Kennzeichners zu verändern.
- Der Eintrag (Zeile) für einen Bedeutungs-Kennzeichner kann erweitert werden um weitere Felder 740 etc., wenn dies aus organisatorischen Gründen, aufgrund von Sicherheitsanforderungen oder aus sonstigen Gründen im Einzelfall notwendig erscheint.
Ein weiteres wesentliches Merkmal der Erfindung ist es, die Grundelemente der drei angeführten Elemente-Typen (Objekte, Beziehungen zwischen den Objekten und Merkmale zur Beschreibung und/oder Identifizierung von Objekten und/oder der Beziehung) bzw. die Grundelemente und ihnen zugeordnete Thesaurus-Listen miteinander wahlfrei in Beziehung setzen zu können. Diese Beziehungen werden in physikalisch oder logisch abgegrenzten,
ERSATZBUTT (REGEL 26) eigenen Speicherbereichen, z.B. in Datenbank-Tabellen, gespeichert, jeweils für die Verbindung zwischen zwei Grundelementen existiert ein einheitlich strukturierter Speicherbereich. Bei Datenbanken ist dies die Verbindungs-Tabelle (engl.: "link table").
Das Schema der Darstellung und Speicherung der Verbindung zwischen zwei Grundelementen ist in Fig. 8 dargestellt. Dabei ist beispielhaft die Verbindung zwischen Objekten entsprechend Fig. 2 und Merkmalen entsprechend Fig. 5 in einer Verbindungs-Tabelle 800 dargestellt. Jedes Objekt 200 ist durch einen eindeutigen Objekt-Schlüssel 210/820 identifiziert. Das (beschreibende oder identifizierende) Merkmal 500 ist identifiziert durch seinen Merkmals-Schlüssel 510/830. In der Verbindungs-Tabelle 800 werden jeweils in einem Eintrag (Zeile) der Schlüssel des Objekts 210/820 mit dem Schlüssel des Merkmals 510/830 zusammengeführt, das auf dieses Objekt 210 bezogen wird.
In ähnlicher Weise ist die Verbindung zwischen Beziehungen und Merkmaien aufgebaut. Die Beziehung 400 ist gemäß Fig. 4 durch ihren Beziehungs-Schlüssel 410 eindeutig identifiziert. Das (beschreibende oder identifizierende) Merkmal 500 ist identifiziert durch seinen eindeutigen Merkmals- Schlüssel 510. In der Verbindungs-Tabelle werden jeweils in einem Eintrag (Zeile) der Schlüssel der Beziehung 410 mit dem Schlüssel des Merkmals 510 zusammengeführt, das auf die Beziehung bezogen wird.
Die Verbindung zwischen den Objekten wurde bereits anhand der Grundtabelle der Beziehungen unter Bezugnahme auf Fig. 4 beschrieben.
Die Erfindung ermöglicht es, beliebig viele Elemente einer Grundelemente-Tabelle mit beliebig vielen Elementen einer anderen Grundelemente-Tabelle bzw. Thesaurus-Liste zu verbinden (M:N-Verbindungen). Dazu kann in den Verbindungstabellen ein eigener Schlüssel 810 geführt werden, der einen Eintrag in der Verbindungs-Tabelle 800 eindeutig kennzeichnet.
ERSATZBUTT (REGEL 26) Neben den Schlüssel-Anteilen der verbundenen Elemente können Verbindungs-Tabellen in weiteren Feldern 840 etc. auch Angaben enthalten, die die Verbindung an sich näher beschreiben und bewerten. Dazu zählen z.B. Informationen über den Zeitpunkt, zu dem diese Verbindung relevant war ("Wann hatte ein Benutzer ein Buch aus der Bibliothek entliehen?"). Dazu können auch Informationen über die Relevanz und den Wahrheitsgehalt einer Verbindung zählen. In einem polizeilichen Informationssystem können damit z.B. Zeugenaussagen gewichtet und bewertet werden.
In einem weiteren Ausführungsbeispiel der Erfindung ist es möglich, die die Information enthaltenden Grundbelege als eigene Objekte zu speichern.
Solche Grundbelege sind z.B. Dokumente mit Texten und Grafiken, Ton-, Film-, Foto- oder Videodokumente und andere elektronisch speicherbare Grundbelege.
Die Erfindung ermöglicht es, daß solche Grundbelege elektronisch erfaßt (direkte Erfassung oder Scanning von Papierbelegen) und innerhalb des Datenbanksystems gespeichert werden.
Dabei ist es ausschließlich abhängig von der Leistungsfähigkeit des verwendeten, zugrundeliegenden Datenbank-Management-Systems, welche Grundbeleg-Formate und in welcher Länge die Grundbelege als eigene "Datensätze" innerhalb des Dateπbank-Management-Systems gespeichert werden.
Ebenso ist es ausschließlich abhängig von der Leistungsfähigkeit der Eingabe- und Ausgabegeräte, ob und in welcher Qualität die Grundbelege eingegeben/erfaßt, gespeichert, verarbeitet und ausgegeben werden können.
ERSATZBUTT (REGEL 26) Ein wesentliches Charakteristikum von Grundbelegen ist zunächst, daß sie bzw. ihr Inhalt nicht informationstechnisch durch die dargestellte Erfindung be- und verarbeitet werden sollen. Sie dienen, wo dies zum Nachweis der Quelle einer Information notwendig ist, vielmehr lediglich als Beleg/Beweis und Verweis auf die (z.B. gerichtsrelevante) Quelle der Information.
Jeder Grundbeleg wird daher in der vorliegenden Erfindung begleitet durch ein Verwaltungs-Objekt, mit dessen Hilfe die betreiberspezifisch notwendigen Verwaltungsinformationen über den Grundbeleg selbst gespeichert und verwaltet werden.
Fig. 9 stellt die Verbindung dar zwischen Grundbelegen und den Verwaltungsobjekten, mit deren Hilfe Grundbelege verwaltet, durch beliebige Merkmale identifiziert und beschrieben und in beliebige Beziehungen gesetzt werden können.
Dabei ist mit 910 ein logischer oder physikalischer Speicherbereich gekennzeichnet, in dem die Grundbelege gespeichert werden. Jeder Grundbeleg besteht aus dem eigentlichen Beleg in Speicherfeld 912 und einem Schlüsselfeld 911 , das als eindeutiger Schlüssel für dieses Belegfeld fungiert.
Mit 920 ist ein logischer oder physikalischer Speicherbereich gekennzeichnet, der das Verwaltungs-Objekt des zugeordneten Grundbelegs darstellt. Die Struktur und Funktion der Felder von Element 920 entspricht der Struktur und den Feldern, die in Fig. 2 erläutert sind.
Die Verbindung zwischen Grundbelegen und sie verwaltende und beschreibende Verwaltungs-Objekte übernimmt ein Speicherbereich 930, in dessen Feld 931 das Schlüsselfeld des Grundbelegs aus 910 und in dessen Schlüsselfeld 932 das Schlüsseifeld 921 des Verwaltungs-Objekts aus 920 als Fremdschlüssel übertragen werden.
ERSATZBUTT (REGEL 26) In einem anderen Ausführungsbeispiel der Erfindung können auch solche Verweise auf die Informationen enthaltende Grundbelege gespeichert werden, die ihrerseits nicht elektronisch gespeichert werden können; sei dies, weil organisatorische, DV-technische oder sonstige Gründe entgegenstehen, oder weil die Grundbelege aufgrund ihrer materiellen Beschaffenheit nicht geeignet sind, elektronisch gespeichert zu werden (z.B. Spurenträger in einem polizeilichen Informationssystem).
Die in Fig. 9 gezeigte Verbindung zwischen Grundbelegen und den sie beschreibenden und identifizierenden Verwaltungs-Objekten bleibt davon unberührt. Der Schlüsselverweis 911 ist bei dieser Variante kein systemintemer Verweis, sondern kann ersetzt werden durch den Verweis auf einen außerhalb des Systems liegenden Aufbewahrungsort des Grundbelegs.
Das bisher entwickelte Datenstrukturmodell ist im Überblick in Fig. 10 dargestellt. Dieses Datenstrukturmodell 1000 wird auch als Teilsystem" bezeichnet.
Wie bereits anhand von Fig. 4 beschrieben wurde, stehen die Objekte 1020 miteinander in Beziehungen, die in 1010 gespeichert werden. Gemäß Fig. 10 werden die Schlüssel 1021 und 1022 miteinander verbundener Objekte in der Beziehungs-Tabelle 1010 zusammengeführt.
Gemäß Fig. 9 werden Schlüssel 1021 eines Objekts 1020 und Schlüssel 1031 eines Merkmals 1030 über die Verbindungs-Tabelle 1040 zusammengeführt.
In ähnlicher Weise werden in der Verbindungs-Tabelle 1050 der Schlüssel 1031 eines Merkmals 1030 mit dem Schlüssel 1012 einer Beziehung zwischen Objekten aus 1010 über Verbindungs-Tabelle 1050 zusammengeführt.
ERSATZBUTT (REGEL 26) Um Mehrdeutigkeiten bei der Erfassung und Vergabe von Merkmals- Begriffen zu vermeiden, kann die Vergabe von einzelnen oder allen Merkmals- Begriffen durch einen Thesaurus der Merkmals-Begriffe 1060 unterstützt werden.
Um Mehrdeutigkeiten bei der Erfassung und Vergabe von Merkmals- Bedeutungen zu vermeiden, kann die Vergabe von einzelnen oder allen Merkmals-Bedeutungen durch einen Thesaurus der Merkmals-Bedeutungen 1070 unterstützt werden.
In vielen Informationssystemen ist es notwendig, nicht nur unterschiedliche Objekt-Typen zu unterscheiden, sondern zusätzlich auch noch unterschiedliche Objektklassen, die gleichartig zu verarbeitende Objekt-Typen enthalten.
In einem Bibliotheksverwaltungssystem kann man z.B. unterscheiden zwischen
- den verwalteten Medien (Titeln von Büchern, Schallplatten usw.),
- den Benutzern/Ausleihern der Bibliothek,
- den Anwendern des Bibliotheksverwaltungssystems usw.
In einem Warenwirtschaftssystem kann man z.B. unterscheiden zwischen:
- den verwalteten Handelsartikeln,
- den Lieferanten der Artikel,
- den Kunden für die Artikel und
- möglicherweise den Anwendern des Systems usw.
Wesentliches Kriterium für die Definition einer neuen Objektklasse ist die Notwendigkeit, eine Gruppe von Objekt-Typen (= Objektklasse) nach einheitlichen Kriterien im Informationssystem zu erfassen, zu speichern, zu verarbeiten, auszuwerten und auszugeben, also allgemeine Bearbeitungskriterien für diese Objektklasse zu verwenden. Grundlage dieser allgemeinen Bearbeitungskriterien können organisatorische Überlegungen sein, DV-technische Vorgaben (z.B. Speichern auf unterschiedlichen Medien), sicherungs- bzw. sicherheitstechnische Notwendigkeiten (z.B. Speichern personenbezogener Daten) und andere.
In Fällen, in denen es aufgrund solcher Überlegungen notwendig ist, mehrere Objektklassen zu bilden und miteinander in Interaktion zu setzen, bietet ein weiteres Ausführungsbeispiel der Erfindung folgende Möglichkeit:
- jede Objektklasse wird in einem eigenen Teilsystem be- und verarbeitet;
- die physikalische Datenstruktur der Teilsysteme, die unterschiedliche Objektklassen abbilden, ist gleich, soweit dies die oben beschriebene Grundstruktur eines Teilsystems betrifft. Darüber hinausgehende bzw. klassenspezifische Erweiterungen sind möglich, wie z.B. oben in den an mehreren Stellen erwähnten "weiteren Feldern" beispielhaft dargestellt.
- notwendige Interaktionen zwischen den Objekten aus unterschiedlichen Objektklassen bzw. Teilsystemen werden durch einheitlich strukturierte, be- und verarbeitete Verbindungen zwischen Teilsystemen realisiert, wie es schematisch in Fig. 11 dargestellt ist.
Die Gesamtdarstellung des Datenstrukturmodells in Fig. 11 zeigt beispielhaft drei Teilsysteme 1110, 1120 und 1130, die jeweils analog dem in Fig. 10 dargestellten Teilsystem aufgebaut sind.
ERSATZBUTT (REGEL 26) Für die Verbindung zweier Objektklassen bzw. Teilsysteme werden die Objekt-Grundelemente 1111 , 1121 und 1131 durch Verbindungs-Tabellen 1140, 1150, 1160 miteinander verbunden.
Struktur und Verarbeitung der Verbindungs-Tabellen zwischen Teilsystemen entsprechen der in Fig. 4 beschriebenen Struktur der Verbindungs- Tabellen zwischen Grundelemente-Tabellen innerhalb eines Teilsystems.
Ein Eintrag in der Verbindungs-Tabelle zweier Objektklassen enthält pro Eintrag (Zeile) die Verbindung zwischen einem Objekt, z.B. 1111 aus einer Objektklasse bzw. einem Teilsystem, z.B. 1110, mit einem Objekt, z.B. 1121, aus einer Objektklasse bzw. einem Teilsystem 1120. Für die Verbindung werden in der Regel die Schlüssel (1111 bzw. 1121 ) der verbundenen Objekte in einer Verbindungs-Tabelle, z.B. 1140, gespeichert.
In einer Verbindungstabelle, z.B. 1140, zwischen Objektklassen bzw. Teilsystemen können auch weitere Felder vorgesehen werden (siehe Fig. 4), insbesondere solche Felder, die die in einem Eintrag beschriebene Verbindung näher beschreiben, z.B.
- die zeitliche, räumliche, organisatorische Relevanz definieren,
- die Art der Existenz dieser Verbindung definieren usw.
Die Anzahl der Teilsysteme ist durch die Erfindung nicht beschränkt. Sie definiert sich durch die Anzahl der Objektklassen, die unterschiedlichen Verarbeitungsregeln unterliegen. Ebenso ist die Anzahl der Teilsysteme, die jeweils paarweise mit anderen Teilsystemen verbunden sind, durch die Erfindung nicht beschränkt.
Während man sich beim Stand der Technik an der Geschäftstätigkeit und an den Dateninhalten des Betreibers des zu schaffenden Informationssystems
ERSATZBUTT (REGEL 26) orientiert und die Regeln für das Design entsprechend definiert hat, ist es für die Erfindung wesentlich, daß zunächst die Geschäftstätigkeit und Dateninhalte des Betreibers des zu schaffenden Informationssystems ignoriert werden.
ERSATZBUTT (REGEL 26)

Claims

Patentansprüche
1. Verfahren zur Speicherung von Daten einer Datenbasis auf einem Speicher eines Informationssystems, wobei auf die Datenbasis mittels eines in einem EDV-System ablaufenden Programms zugegriffen werden kann und die Datenstruktur der in der Datenbasis gespeicherten Daten durch die folgenden Verfahrensschritte aufgebaut wird:
Speichern einer Vielzahl von Objekten, die Abbilder von konkreten oder abstrakten Gegenständen darstellen, in einem ersten Bereich des Speichers;
Speichern einer Vielzahl von Beziehungen zwischen den Objekten in einem zweiten Bereich des Speichers;
Speichern einer Vielzahl von Merkmalen zur Beschreibung der Objekte und der Beziehungen zwischen den Objekten in einem dritten und vierten Bereich des Speichers;
Speichern einer Vielzahl von Verbindungen zwischen den Objekten und den Merkmalen in einem fünften Bereich des Speichers; und
Speichern einer Vielzahl von Verbindungen zwischen den Beziehungen und den Merkmalen in einem sechsten Bereich des Speichers, wobei die sechs Bereiche jeweils physikalisch oder logisch abgegrenzte Speicherbereiche darstellen.
2. Verfahren nach Anspruch 1 , bei dem die ersten bis sechsten Speicherbereiche Tabellen einer relationalen Datenbank darstellen.
3. Verfahren nach einem der Ansprüche 1 oder 2, bei dem die Verbindung zwischen zwei Grundelementen (Objekte und Merkmale; Beziehungen und Merkmale) dadurch hergestellt wird, daß jedes Grundelement durch einen Schlüssel identifiziert wird, und die Schlüssel der zu verbindenden Grundelemente in einer Verbindungs-Tabelle gespeichert werden.
ERSATZBUTT (REGEL 26)
4. Verfahren nach einem der Ansprüche 1 bis 3, bei dem die sechs Speicherbereiche ein Teilsystem bilden.
5. Verfahren nach einem der Ansprüche 1 bis 4, bei dem, im Falle von mehreren Bedeutungen von Merkmalen, diese in einem Thesaurus der Merkmals-Bedeutungen in einem siebten Speicherbereich gespeichert werden.
6. Verfahren nach einem der Ansprüche 1 bis 5, bei dem, im Falle von mehreren Merkmals-Begriffen zu einer Merkmals-Bedeutung, einzelne oder alle davon in einem Thesaurus der Merkmals-Begriffe in einem achten Speicherbereich gespeichert werden.
7. Verfahren nach einem der Ansprüche 1 bis 6, bei dem, im Falle von Objekten unterschiedlichen Typs, die Objekt-Typen in einem Thesaurus für Objekt-Typen in einem neunten Speicherbereich gespeichert werden.
8. Verfahren nach einem der Ansprüche 1 bis 7, bei dem die Bezeichnungen von Objekt-Beziehungen in einem Thesaurus für Objekt- Beziehungen in einem zehnten Speicherbereich gespeichert werden.
9. Verfahren nach einem der Ansprüche 1 bis 8, bei dem die die Informationen belegenden Grundbelege ihrerseits als Objekte im Datenbanksystem gespeichert werden.
10. Verfahren nach einem der Ansprüche 1 bis 9, bei dem auf den Aufbewahrungsort der Grundbelege im System mit einem geeigneten, eindeutigen Hinweis verwiesen wird.
11. Verfahren nach einem der Ansprüche 1 bis 10, das die folgenden zusätzlichen Verfahrensschritte aufweist:
ERSATZBUTT (REGEL 26) Zusammenfassen einer Gruppe von Typen von Objekten, die nach einheitlichen Kriterien zu verarbeiten sind, in einer Objektklasse;
Verarbeiten jeder Objektklasse in einem eigenen Teilsystem nach Anspruch 4;
Verbinden der Objektklassen über Schlüssel eines Objekts der zu verbindenden Objektklassen, wobei die Schlüssel in einer Verbindungs-Tabelle (1140, 1150, 1160) gespeichert werden.
12. Datenstruktur einer auf einem Speicher gespeicherten Datenbasis, auf die mittels eines in einem EDV-System ablaufenden Programms zugegriffen werden kann, wobei die Datenstruktur dadurch gebildet wird, daß die Datenbasis dargestellt wird in einer Vielzahl von Objekten, die Abbilder von konkreten oder abstrakten Gegenständen darstellen; einer Vielzahl von Beziehungen zwischen den Objekten; einer Vielzahl von Merkmalen zur Beschreibung der Objekte und der Beziehungen zwischen den Objekten; einer Vielzahl von Verbindungen zwischen den Objekten und den Merkmalen; und einer Vielzahl von Verbindungen zwischen den Beziehungen und den Merkmalen; und diese jeweils in physikalisch oder logisch abgegrenzten Speicherbereichen des Speichers gespeichert sind.
13. Verwendung der Datenstruktur einer Datenbasis nach Anspruch 12 zur Eingabe, Speicherung, Verarbeitung, Auswertung, Darstellung oder Ausgabe von einzelnen oder mehreren Objekten, Beziehungen zwischen Objekten oder Merkmalen von Objekten oder Beziehungen.
14. Verfahren zum Aufbau einer Datenstruktur für eine Datenbasis gemäß Anspruch 12.
ERSATZBUTT (REGEL 26)
15. Informationssystem mit einem Datenverarbeitungssystem, auf dem ein Anwendungsprogramm abläuft, einem Speichersystem und einer Datenbasis, die auf dem Speichersystem gespeichert ist und auf die das Anwendungsprogramm zugreifen kann, wobei die Datenbasis eine Datenstruktur aufweist, die gebildet wird von einer Vielzahl von Objekten, die Abbilder von konkreten oder abstrakten Gegenständen darstellen; einer Vielzahl von Beziehungen zwischen den Objekten; einer Vielzahl von Merkmalen zur Beschreibung der Objekte und der Beziehungen zwischen den Objekten; einer Vielzahl von Verbindungen zwischen den Objekten und den Merkmalen; und einer Vielzahl von Verbindungen zwischen den Beziehungen und den Merkmalen; die jeweils in physikalisch oder logisch abgegrenzten Speicherbereichen gespeichert sind.
16. Computer-lesbarer Speicher zum Speichern von Daten, auf die mittels eines auf einem EDV-System ablaufenden Anwendungsprogramms zugegriffen werden kann, wobei auf dem Speicher eine Datenbasis in einer Datenstruktur gespeichert ist, die gebildet wird von einer Vielzahl von Objekten, die Abbilder von konkreten oder abstrakten Gegenständen darstellen; einer Vielzahl von Beziehungen zwischen den Objekten; einer Vielzahl von Merkmalen zur Beschreibung der Objekte und der Beziehungen zwischen den Objekten; einer Vielzahl von Verbindungen zwischen den Objekten und den Merkmalen; und einer Vielzahl von Verbindungen zwischen den Beziehungen und den Merkmalen;
ERSATZBUTT (REGEL 26) die jeweils in physikalisch oder logisch abgegrenzten Speicherbereichen gespeichert sind.
ERSATZBUTT (REGEL 26)
PCT/DE1996/001719 1995-10-13 1996-09-12 Informationssystem und verfahren zur speicherung von daten in einem informationssystem WO1997015015A2 (de)

Priority Applications (5)

Application Number Priority Date Filing Date Title
AU10919/97A AU1091997A (en) 1995-10-13 1996-09-12 Information system and process for storing data therein
US09/051,394 US6208992B1 (en) 1995-10-13 1996-09-12 Information system and process for storing data therein
EP96941572A EP0855062B1 (de) 1995-10-13 1996-09-12 Informationssystem und verfahren zur speicherung von daten in einem informationssystem
AT96941572T ATE202646T1 (de) 1995-10-13 1996-09-12 Informationssystem und verfahren zur speicherung von daten in einem informationssystem
DE59607181T DE59607181D1 (de) 1995-10-13 1996-09-12 Informationssystem und verfahren zur speicherung von daten in einem informationssystem

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE19538240.4 1995-10-13
DE19538240A DE19538240A1 (de) 1995-10-13 1995-10-13 Informationssystem und Verfahren zur Speicherung von Daten in einem Informationssystem

Publications (2)

Publication Number Publication Date
WO1997015015A2 true WO1997015015A2 (de) 1997-04-24
WO1997015015A3 WO1997015015A3 (de) 1997-05-15

Family

ID=7774829

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE1996/001719 WO1997015015A2 (de) 1995-10-13 1996-09-12 Informationssystem und verfahren zur speicherung von daten in einem informationssystem

Country Status (7)

Country Link
US (1) US6208992B1 (de)
EP (1) EP0855062B1 (de)
AT (1) ATE202646T1 (de)
AU (1) AU1091997A (de)
CA (1) CA2234703A1 (de)
DE (2) DE19538240A1 (de)
WO (1) WO1997015015A2 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000029980A2 (en) * 1998-11-12 2000-05-25 Lazy Software Limited Systems and methods for storing data
NL1024418C2 (nl) * 2003-10-01 2005-04-05 Re Base Group Elektronisch opslag- en toegangssysteem en werkwijze voor de werking daarvan.

Families Citing this family (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6681075B1 (en) * 1998-06-10 2004-01-20 Matsushita Electric Industrial Co., Ltd. Data transmission apparatus and data reception apparatus
DE19843450A1 (de) * 1998-09-22 2000-03-23 Siemens Ag Verfahren und Anordnung zur Ermittlung einer Struktur einer Vielzahl elektronischer Dateien hinsichtlich eines elektronischen Thesaurus
US6735591B2 (en) * 1999-01-26 2004-05-11 Joseph M. Khan Universal information warehouse system and method
DE19955002C2 (de) * 1999-11-16 2002-01-17 Daimler Chrysler Ag Modellierungsverfahren für Informationsmodelle zur konsistenten Repräsentation und/oder Speicherung von Systemelementen hierarchischer Systemstrukturen
US20020091677A1 (en) * 2000-03-20 2002-07-11 Sridhar Mandayam Andampikai Content dereferencing in website development
US7016900B2 (en) * 2000-06-30 2006-03-21 Boris Gelfand Data cells and data cell generations
JP4552296B2 (ja) * 2000-09-08 2010-09-29 ソニー株式会社 情報処理装置および情報処理方法、並びに記録媒体
US7158971B1 (en) 2001-03-07 2007-01-02 Thomas Layne Bascom Method for searching document objects on a network
US7386792B1 (en) 2001-03-07 2008-06-10 Thomas Layne Bascom System and method for collecting, storing, managing and providing categorized information related to a document object
US7197506B2 (en) * 2001-04-06 2007-03-27 Renar Company, Llc Collection management system
CA2353026A1 (en) * 2001-07-13 2003-01-13 Sygenics Inc. Adaptive data architecture
DE10148008A1 (de) * 2001-09-28 2003-04-24 Siemens Ag Verfahren und Anordnung zur Speicherung hierarchisch abhängiger Daten
EP1466270A4 (de) * 2001-12-06 2005-03-23 Univ New York Logikanordnung, datenstruktur, system und verfahren zur multilinearen repräsentation von multimodalen datenensembles zur synthese, erkennung und komprimierung
US20030187826A1 (en) * 2002-03-28 2003-10-02 Ontario Corporation Collection system database architecture
JPWO2004097679A1 (ja) * 2003-04-25 2006-07-13 ヒューレット−パッカード デベロップメント カンパニー エル．ピー． データベース装置及び作成方法、データベース検索装置及び検索方法
US7379925B2 (en) * 2003-07-25 2008-05-27 New York University Logic arrangement, data structure, system and method for multilinear representation of multimodal data ensembles for synthesis, rotation and compression
US8166101B2 (en) * 2003-08-21 2012-04-24 Microsoft Corporation Systems and methods for the implementation of a synchronization schemas for units of information manageable by a hardware/software interface system
US8238696B2 (en) 2003-08-21 2012-08-07 Microsoft Corporation Systems and methods for the implementation of a digital images schema for organizing units of information manageable by a hardware/software interface system
US20050091181A1 (en) * 2003-10-23 2005-04-28 Mckee Timothy P. System and method for the presentation of items stored on a computer
US7730073B2 (en) * 2003-10-23 2010-06-01 Microsoft Corporation System and a method for presenting related items to a user
US7908562B2 (en) * 2003-10-23 2011-03-15 Microsoft Corporation System and a method for presenting items to a user with a contextual presentation
CA2553452A1 (en) * 2004-01-13 2005-07-28 New York University Method, system, storage medium, and data structure for image recognition using multilinear independent component analysis
US20060282470A1 (en) * 2005-06-10 2006-12-14 Hong-Lee Yu Determining compliance of a database architecture to an enterprise data standard
US9792351B2 (en) * 2005-06-10 2017-10-17 International Business Machines Corporation Tolerant and extensible discovery of relationships in data using structural information and data analysis
US8046448B2 (en) * 2005-11-03 2011-10-25 Sony Corporation System and method for information sharing
EP2074531A1 (de) 2006-10-10 2009-07-01 Richard Chappuis Informationsverarbeitungsverfahren
US20110093500A1 (en) * 2009-01-21 2011-04-21 Google Inc. Query Optimization
EP2784699A1 (de) * 2013-03-29 2014-10-01 Pilab S.A. Computerimplementiertes Verfahren zum Speichern unbegrenzter Datenmengen als Mind-Map in relationalen Datenbanksystemen
DE102013206050A1 (de) * 2013-04-05 2014-10-09 Robert Bosch Gmbh Informationssystem und Verfahren zum Auswählen und Wiedergeben von Informationen, insbesondere zm Einsatz im Werkstattbereich
DE102013206559A1 (de) * 2013-04-12 2014-10-16 Robert Bosch Gmbh Informationssystem und verfahren zum aufbau eines informationssystems
US10153056B2 (en) * 2016-05-09 2018-12-11 Bank Of America Corporation System for a geographic location based sharing request network
US10402380B1 (en) 2018-05-09 2019-09-03 Carecloud Corporation Interactive user interface for schema transformation
US20190347341A1 (en) * 2018-05-09 2019-11-14 Carecloud Corporation Method and system for schema transformation

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1989003567A1 (en) * 1987-10-09 1989-04-20 Nucleus International Corporation A relational database using identifiers
WO1995005630A2 (en) * 1993-08-13 1995-02-23 Peoplesoft, Inc. Related base, and preferred language access to a multilingual database

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH021057A (ja) * 1988-01-20 1990-01-05 Ricoh Co Ltd 文書検索装置
US4864497A (en) * 1988-04-13 1989-09-05 Digital Equipment Corporation Method of integrating software application programs using an attributive data model database
JP2556189B2 (ja) * 1990-10-29 1996-11-20 富士ゼロックス株式会社 オブジェクト指向計算機システムにおけるメソッド起動装置
US5615367A (en) * 1993-05-25 1997-03-25 Borland International, Inc. System and methods including automatic linking of tables for improved relational database modeling with interface
DE4331949A1 (de) * 1993-09-21 1995-03-30 Frank Dipl Ing Mueller Datenverarbeitungsanlage und Verfahren zur Organisation von Daten in Datenverarbeitungsanlagen
US5548749A (en) * 1993-10-29 1996-08-20 Wall Data Incorporated Semantic orbject modeling system for creating relational database schemas
US5611076A (en) * 1994-09-21 1997-03-11 Micro Data Base Systems, Inc. Multi-model database management system engine for databases having complex data models

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1989003567A1 (en) * 1987-10-09 1989-04-20 Nucleus International Corporation A relational database using identifiers
WO1995005630A2 (en) * 1993-08-13 1995-02-23 Peoplesoft, Inc. Related base, and preferred language access to a multilingual database

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
IBM TECHNICAL DISCLOSURE BULLETIN, Bd. 29, Nr. 12, Mai 1987, NEW YORK, US, Seiten 5434-5435, XP000039638 ANONYMOUS: "Data Base for Program Design" *
THE FIFTH GENERATION CHALLENGE, ACM '84 ANNUAL CONFERENCE, 8. - 14.Oktober 1984, SAN FRANCISCO, CA, USA, Seiten 102-108, XP002027727 R. P. BRAZILE: "A General Purpose Data Base Design" *

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000029980A2 (en) * 1998-11-12 2000-05-25 Lazy Software Limited Systems and methods for storing data
WO2000029980A3 (en) * 1998-11-12 2000-08-10 Lazy Software Limited Systems and methods for storing data
GB2360108A (en) * 1998-11-12 2001-09-12 Lazy Software Ltd Systems and methods for storing data
GB2360108B (en) * 1998-11-12 2003-09-24 Lazy Software Ltd Systems and methods for storing data
US6735593B1 (en) 1998-11-12 2004-05-11 Simon Guy Williams Systems and methods for storing data
NL1024418C2 (nl) * 2003-10-01 2005-04-05 Re Base Group Elektronisch opslag- en toegangssysteem en werkwijze voor de werking daarvan.

Also Published As

Publication number Publication date
US6208992B1 (en) 2001-03-27
DE19538240A1 (de) 1998-08-06
ATE202646T1 (de) 2001-07-15
EP0855062A2 (de) 1998-07-29
DE59607181D1 (de) 2001-08-02
EP0855062B1 (de) 2001-06-27
WO1997015015A3 (de) 1997-05-15
CA2234703A1 (en) 1997-04-24
AU1091997A (en) 1997-05-07

Similar Documents

Publication Publication Date Title
EP0855062B1 (de) Informationssystem und verfahren zur speicherung von daten in einem informationssystem
EP0910829B1 (de) Datenbanksystem
DE10255128A1 (de) Computer-implementierte PDF-Dokumentenverwaltung
DE69628374T2 (de) Datenverwaltungssystem
EP1166228B1 (de) Verfahren zur nutzung von fraktalen semantischen netzen für alle arten von datenbank-anwendungen
EP1276056B1 (de) Verfahren zum Verwalten einer Datenbank
WO2007137308A1 (de) Verfahren zum steuern eines relationalen datenbanksystems
EP1941395B1 (de) Verfahren zur steuerung eines relationalen datenbanksystems
EP1502211B1 (de) Verfahren und vorrichtung zur zugriffssteuerung in wissensnetzen
EP0856176A1 (de) Datenbankmanagementsystem sowie datenübertragungsverfahren
DE10103845B4 (de) Rechnersystem
EP3776257A1 (de) Objektdatenbank zur geschäftsmodellierung mit verbesserter datensicherheit
DE19729911A1 (de) System zur Verbesserung der Organisation von Daten einer Dokumentation
EP1234231B1 (de) Verfahren zur erzeugung grafischer benutzerschnittstellen für computerprogramme
EP1515244A2 (de) Abbildung einer Klassenhierarchie auf ein relationales Datenbanksystem
EP1374100A2 (de) Datenbanksystem
EP1920362A1 (de) Verfahren zur verarbeitung von daten
EP3877866A1 (de) Verfahren und vorrichtung zum speichern von daten und deren beziehungen
WO2004095313A1 (de) Datenverarbeitungssystem für benutzerfreundliche datenbank-recherchen
DE19914454A1 (de) Rechnergestütztes System und Verfahren zum Aufbauen einer Datenbank
DE10017608B4 (de) Verfahren zur Durchführung von Operationen in einem Datenbanksystem
DE10355607A1 (de) Herstellen von Verknüpfungen zwischen Entitäten
DE10331817A1 (de) Computergestütztes Verfahren zur automatischen Abfrage von Informationen aus als sematisches Netz strukturierten Datenbanken
EP1318462A1 (de) Verfahren zur Verwaltung und Recherche von Daten
EP0521177A1 (de) Schnittstellensteuerung zur Ansteuerung von Datenbanksystemen

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GE HU IL IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK TJ TM TR TT UA UG US UZ VN AM AZ BY KG KZ MD RU TJ TM

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): KE LS MW SD SZ UG AT BE CH DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG

AK Designated states

Kind code of ref document: A3

Designated state(s): AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GE HU IL IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK TJ TM TR TT UA UG US UZ VN AM AZ BY KG KZ MD RU TJ TM

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): KE LS MW SD SZ UG AT BE CH DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG

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

Ref document number: 09051394

Country of ref document: US

ENP Entry into the national phase

Ref document number: 2234703

Country of ref document: CA

Ref country code: CA

Ref document number: 2234703

Kind code of ref document: A

Format of ref document f/p: F

WWE Wipo information: entry into national phase

Ref document number: 1996941572

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWP Wipo information: published in national office

Ref document number: 1996941572

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: JP

Ref document number: 97515398

Format of ref document f/p: F

WWG Wipo information: grant in national office

Ref document number: 1996941572

Country of ref document: EP