EP3948576A1 - Datenbankübergreifender index auf einem verteilten datenbanksystem - Google Patents

Datenbankübergreifender index auf einem verteilten datenbanksystem

Info

Publication number
EP3948576A1
EP3948576A1 EP20716739.6A EP20716739A EP3948576A1 EP 3948576 A1 EP3948576 A1 EP 3948576A1 EP 20716739 A EP20716739 A EP 20716739A EP 3948576 A1 EP3948576 A1 EP 3948576A1
Authority
EP
European Patent Office
Prior art keywords
data
database
index
additional
tokens
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP20716739.6A
Other languages
English (en)
French (fr)
Inventor
Andreas Wilke
Ilya Komarov
Peter Palm
Manfred Paeschke
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Bundesdruckerei GmbH
Original Assignee
Bundesdruckerei GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bundesdruckerei GmbH filed Critical Bundesdruckerei GmbH
Publication of EP3948576A1 publication Critical patent/EP3948576A1/de
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
    • G06F16/31—Indexing; Data structures therefor; Storage structures
    • G06F16/316—Indexing structures
    • G06F16/319—Inverted lists
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor

Definitions

  • the invention relates to a method, a source computer system and a distributed database system for implementing a cross-database index on a distributed database system.
  • complex distributed systems are emerging, the technical interaction of which raises new technical challenges.
  • corresponding distributed systems generally do not have a shared memory, which makes it difficult to carry out data processing functions.
  • the invention is based on the object of creating an improved method for implementing an index on a distributed database system.
  • Embodiments include a computer-implemented method for implementing a cross-database index on a distributed database system which comprises a plurality of independent individual databases, the individual databases being communicatively connected to one another via a network,
  • the individual databases are each managed by a multi-model database management system, the individual databases each comprising a plurality of database-specific data records which are stored in a document-oriented first data model of the respective individual database, the stored data records each comprising one or more field values - sen, whereby the individual field values of the stored data records are each stored in a field,
  • the individual databases each further comprising a searchable first index which is stored in a second data model of the respective individual database, the index of the respective individual database being a plurality of data records stored in the document-oriented data model of the corresponding individual database comprises generated tokens, the token in the index being linked to one or more pointers to one or more of the data records stored in the document-oriented data model of the corresponding individual database, from whose field values the corresponding token was generated,
  • Embodiments can have the advantage that by creating and sending the supplementary data record, the index of the receive database can be adapted to the changes in the index of the source database. Even though it is a distributed database system with a number of independent individual databases, a cross-database index can be implemented in this way. If all individual databases are configured to act as the source database when an additional data record is received, a uniform cross-database index of the distributed database system can be provided. If all individual databases are configured to receive the corresponding supplementary data records as receive databases, then all Individual databases are provided with an identical cross-database index of the distributed database system. This enables data processing functions to be carried out locally, taking into account all the data made available in the distributed database system.
  • the index does not include the full context information that the underlying data records include. This full context information is not lost, however, but is available to the individual databases individually.
  • the amounts of data that have to be exchanged between the individual databases to implement the cross-database index are reduced and, at the same time, the data in the data records are protected. This protection includes that only the individual, independent single databases have access to the data records stored in their respective first data model. Only this respective individual database therefore has access to the full information content of the corresponding data records.
  • each of the individual databases in its first data model each comprises an independent plurality of data records, which can possibly differ significantly or even completely from data records which are contained in the first data models of other individual data banks are stored.
  • the restricted access protects against unauthorized access to the data by third parties.
  • Embodiments can have the advantage that the data processing functions are each carried out individually for each individual database. For example, each of the individual databases independently indexes data records that it receives. As a result, the data records can be processed in parallel. Thus, the processing of the data can be parallelized and thus accelerated.
  • Embodiments are thus based on a distributed system or database system which comprises a plurality of nodes or computers, each of which makes an individual database available and can communicate with one another via communication interfaces.
  • software i. E. the data processing functions, which can provide a plurality of functionalities, such as algorithms, formulas, models.
  • the data processing function can be limited to indexing received data records and creating or managing an index based thereon. According to further embodiments, however, the data processing function can also include further functionalities, the application of which is reflected in the resulting structure of the index. The data provided by the index can thus be optimized for a variety of purposes.
  • the software can, for example, be software which is installed on the individual nodes of the system, i.e. the individual databases, independently of the other nodes of the distributed system.
  • the distributed system in this case refers to the fact that each of the nodes of the distributed system comprises a complete copy of the index.
  • the resulting index indexes all individual databases of the distributed system, i.e. the index can be a combined overall index which includes all sub-indexes of the individual accounts of the distributed system.
  • a distributed application describes a complex application program which runs on a distributed system, ie on several computers, and under exchanges this information.
  • the corresponding application is distributed through horizontal cuts in the software layer model, so that the task of the overall software can be divided among individual software components in the form of the individual cuts.
  • all components of the application that communicate with one another for this purpose must cooperate in order to fulfill the overall task.
  • the distributed application is mostly transparent to a client, ie the distributed application appears as a uniform application.
  • each individual database carries out a data processing function.
  • This can involve the same data processing function in all individual databases, which is consequently parallelized, or it can be individual database-individual data processing functions, the execution of which is complementary.
  • the creation of an index of different individual databases can differ in terms of the granularity of the tokens added to the index.
  • sensor measured values for example, the exact measured values can be added to the index, a rounded measured value or assignments to a value interval can be added. If the values are from different sensors, there can be different requirements for them, which can be implemented by means of individual database-specific data processing functions.
  • a distributed system is understood to mean a plurality of interacting processes or a plurality of interacting processors executing processes which do not have a common memory, but rather communicate with one another via messages.
  • a distributed system thus enables independent computers or individual databases to be merged, each of which is presented as a single system for the respective user. In the present case, the respective user sees a cross-database index, for example. Only when data records are to be accessed directly that are stored in a data model of another individual database can it can be seen by the user that it is not a single system but rather a distributed system.
  • Embodiments can have the advantage that the functionality of the complete index can be used on each of the nodes or on each of the individual databases without the corresponding nodes including all data records of the entire distributed database system. In this way, an overhead for the operation and storage of the data records for the remaining nodes or individual databases can be avoided on the respective nodes.
  • Embodiments can have the advantage that a complete central storage of all data or a merging of all databases is not necessary at any location so that the entirety of the information of all indexes of all databases can be accessed and evaluated. This avoids a central instance collecting all data that could access all data. In particular, associated security risks can be avoided or minimized.
  • Embodiments can have the advantage that data which are recorded by a node in the distributed network are linked directly to an owner or an identity.
  • the received data records are each assigned directly to the received individual database or to a user of the corresponding individual database as the owner or owner.
  • Embodiments can have the advantage that they enable functionalities of a software component to be operated in a targeted manner on individual network nodes in a distributed system. In this way, the memory and computing requirements on the relevant node can be minimized while the desired functionality is operated. This also makes it possible for relatively inefficient ones, for example in relation to other nodes in the distributed network, to carry out functions locally on site.
  • Embodiments may have the advantage of providing an implementation of an edge computing system.
  • Edge computing describes decentralized data processing at the edge of a network, the so-called edge.
  • Edge computing is in contrast to cloud computing, in which computer applications, data and services are centralized, i.e. from central network node nodes, a plurality of decentralized network nodes are provided for use.
  • edge computing is geared towards processing computer applications, data and services locally, if possible, or at least in the vicinity.
  • This can have the advantage that data streams can be limited to local network areas in a way that conserves resources.
  • resources that are not permanently connected to a network can be used, in particular mobile computer systems, e.g. Controllers, notebooks, smartphones, tablet computers and sensors.
  • Different processes and structures can be used in edge computing, such as sensor networks, mobile data acquisition, mobile signature analysis and / or peer-to-peer and ad hoc networking.
  • Edge computing can have the advantage that it can be used as an architecture concept for the Internet of Things (loT), which links clearly identifiable physical objects, i.e. "things", with a virtual representation or identity in a network structure, e.g. an "Internet” -like structure.
  • LoT Internet of Things
  • Edge computing Services that are provided in the course of edge computing can have the advantage that the data volume to be transmitted and thus the data exchange as well as the transmission paths can be significantly reduced, which means that transmission costs and waiting times can be reduced. As a result, the overall service quality can be improved.
  • edge computing central data centers are not necessary or at most only a small number is necessary, which means that bottleneck effects at such data centers for data transfer can be avoided as well as the associated potential sources of error.
  • the security of the data within the distributed system can also be increased. In particular, this enables potential security threats such as viruses, falsified data and / or hacker attacks to be recognized early and effectively averted.
  • the ability to virtualize extends the scalability within the system, ie the number of edge devices in the network can be easily increased.
  • edge computing real-time requirements in the Internet of Things can be better supported than is generally possible in the course of cloud computing due to the faster data processing.
  • intelligent objects In everyday life, users increasingly surround themselves with electronic devices that have computer functionality and connectivity.
  • One trend is the increasing spread of wearables, i.e. Computer systems which are arranged on the body of the user during use.
  • Another trend is the replacement of everyday objects with “intelligent objects” (also called “smart devices”), which are equipped with information technology and are configured to process information themselves.
  • intelligent objects are equipped with data processing hardware, such as a built-in microcontroller, communication interfaces and / or sensors, so that they can record, store and / or exchange data with one another.
  • data processing hardware such as a built-in microcontroller, communication interfaces and / or sensors, so that they can record, store and / or exchange data with one another.
  • data processing hardware such as a built-in microcontroller, communication interfaces and / or sensors
  • a plurality of data acquisition devices which are arranged in the distributed database system, acquire or generate data locally and transmit these data or supplementary data records based on them to one or more other nodes via a communication interface over the network.
  • the software By reducing the software to its core functionalities, memory requirements and computing capacity can be saved so that the corresponding software can be used effectively and efficiently, for example in loT sensors.
  • Linking the data with an owner or with an identity increases the level of security of the data, as subsequent manipulation of the data by unauthorized persons can be excluded.
  • Embodiments can have the advantage that they can provide an advantageous distributed database system for the Internet of Things.
  • supplementing the index includes:
  • Embodiments can have the advantage that data from additional data records can be efficiently inserted into the existing individual database and in particular into the index.
  • the tokens generated using the additional data record are compared with the index. All tokens that the index does not (yet) include are added to the index as additional tokens. Further the additional tokens are linked with the pointer to the additional data record.
  • the pointers can be used to determine which individual database contains the underlying data or data records.
  • the pointer to the additional data record is added to the index.
  • Embodiments can have the advantage that it can always be ensured that the index has or at least takes into account all tokens comprised by the data records in the database.
  • the supplementary data set is sent from the source database via the network to a predefined first group of one or more individual databases of the plurality of individual databases as receive databases which the second individual database comprises.
  • Embodiments can have the advantage that it can be ensured for a predefined first group that its members each have the complete cross-database index. This can be advantageous, for example, in an asymmetrical system in which there is no need to provide a complete index for one or more of the individual databases. This can be the case, for example, if no or only seldom local searches are carried out on these databases.
  • the corresponding individual database serves primarily as a data store and for parallelizing the creation of the index.
  • the supplementary data set is sent from the source database via the network to all further individual databases comprised of the plurality of individual databases as receive databases.
  • Embodiments can have the advantage that a cross-database index can be implemented on all individual databases.
  • a predefined second group of several individual databases of the plurality of individual databases is configured to function as a source database in each case when additional data records are received.
  • all of the individual databases of the plurality of individual databases are configured to function as a source database in each case when additional data records are received.
  • different degrees of standardization of the individual indexes of the individual databases can be achieved.
  • a sensor is assigned to the source database and the additional data record comprises sensor data recorded by the sensor.
  • the sensor data are indexed immediately after they have been recorded.
  • each individual database of the plurality of individual databases is assigned one or more sensors, from which the respective individual database receives recorded sensor data in the form of additional data records.
  • the data processing function further comprises normalizing the additional tokens in the course of adding to the index of the source database.
  • the normalization fulfills the fifth and / or sixth normal form. Embodiments can have the advantage that redundancies can be avoided.
  • the tokens can be stored in the form of relations or equivalent structures.
  • a relation is a set of tuples.
  • a tuple is a set of attribute values.
  • An attribute describes a data type or a property assigned to one or more data. The number of attributes determines the degree, the number of tuples the cardinality of a relation.
  • a normalization in particular a normalization of a relational data model, is a division of attributes into a plurality of Understand relations according to normalization rules, so that redundancies are reduced or minimized.
  • a relational data model can be implemented, for example, in table-like data structures in which the relations are implemented in the form of tables, the attributes in the form of table columns and the tuples in the form of table rows.
  • a relational data model can be brought into a normal form, for example, in that the relations of the data schema are progressively broken down into simpler relations based on the functional dependencies applicable to the corresponding normal form.
  • Normal form (1 NF), 2nd normal form (2NF), 3rd normal form (3NF), Boyce-Codd normal form (BCNF), 4th normal form (4NF), 5th normal form (5NF), 6th normal form (6NF).
  • the normalization criteria increase from normal form to normal form and each include the normalization criteria of the previous normal forms, i.e.
  • a relation is in the first normal form if each attribute of the relation has an atomic range of values and the relation is free of repeating groups.
  • the term atomic denotes an exclusion of composite, quantity-valued or nested value ranges for the attributes, i.e. relative attribute value ranges, understood. Freedom from repeating groups requires that attributes that contain the same or similar information are swapped out in different relations.
  • a relation is in the second normal form if it fulfills the requirements of the first normal form and no non-primary attribute is functional from a real one Subset of a key candidate depends.
  • a non-primary attribute is an attribute that is not part of a key candidate. This means that each non-primary attribute is dependent on all whole keys and not just on part of a key.
  • Relations in the first normal form, the key candidates of which are not composed but consist of a single attribute, automatically satisfy the second normal form.
  • a key candidate is understood here to be a minimal set of attributes that uniquely identify the tuples of a relation.
  • a relation is in the third normal form if it fulfills the requirements of the second normal form and no non-key attribute depends transitively on a key candidate.
  • An attribute is transitively dependent on a key candidate if the corresponding attribute is dependent on the corresponding key candidate via a further attribute.
  • a relation is in Boyce-Codd normal form if it meets the requirements of the third normal form and every determinant is a super key.
  • a determinant is understood here to be a set of attributes on which other attributes are functionally dependent. A determinant thus describes the dependency between attributes of a relation and specifies which attribute sets determine the value of the other attributes.
  • a super key is a set of attributes in a relation which uniquely identify the tuples in this relation. The attributes of this set therefore always include different values for tuples selected in pairs. The key candidate is therefore a minimal subset of the attributes of a super key, which enables the tuple to be identified.
  • a relation is in the fourth normal form if it meets the requirements of the Boyce-Codd normal form and does not include any nontrivial multivalued dependencies.
  • a relation is in the fifth normal form if it fulfills the requirements of the fourth normal form and does not include any multivalued dependencies that are interdependent.
  • the fifth normal form is thus present if every non-trivial compound dependency is implied by the key candidates.
  • a compound dependency is implied by the key candidates of the output relation if every relation of the set of relations is a super key of the output relation.
  • a relation is in the sixth normal form if it fulfills the requirements of the fifth normal form and does not include any nontrivial union dependencies.
  • a relation is sufficient for a join dependency of a plurality of relations if the relation as the starting relation can be broken down into the corresponding set of relations without loss.
  • the compound dependency is trivial if one of the relations in the set of relations has all the attributes of the initial relation.
  • the data processing function further comprises an assignment of rights for managing and / or processing the data of the additional data record.
  • an owner can be assigned directly to the additional data record in this context. This owner can, for example, be given certain access rights at the same time, which enables him to manage and / or process the data.
  • the first multi-model database management system assigns an owner right with respect to the additional data record and / or the supplementary data record to a first entity assigned to the source database. The corresponding entity is thus established as the owner or owner of the additional data record and / or the supplementary data record.
  • the data are linked directly to an owner or assigned to an owner by the node that acquires or generates the corresponding data.
  • authorization chains are formed with the collected data on the resource-restricted nodes of the distributed system, for example loT sensors, with the recorded or generated data.
  • the authorization chains define access rights for a number of entities.
  • a central database with an authorization concept is not necessary on these systems, since the functionalities of the authorization chains are implemented directly on the individual nodes. As a result, data can be effectively and efficiently linked to an owner even on resource-constrained nodes.
  • Linking the data directly during data generation on the individual resource-restricted nodes of the distributed system with an owner can have the advantage of increasing data security and guaranteeing transparency about the actual owners of the respective data.
  • the first entity is a first user of the source database or a first computer system assigned to the source database. Is it an assigned, e.g. the computer system comprising the source database, this can be of advantage, for example, in applications in the area of the Internet of Things, since each data record recorded by a corresponding sensor system is automatically assigned a unique owner in the course of being entered in the corresponding individual database.
  • access authorization certificates are stored in the source database as part of the additional data record and / or the supplementary data record, the access authorization certificates comprising one or more of the following access authorization certificates:
  • Access credentials can be designed as access certificates. According to embodiments, the access certificates are pure numerical values, not complex x509 certificates. Metadata regarding the validity of the certificates and regarding other aspects can be stored separately from the actual access certificate in an additional ID database of an access management system of the corresponding individual database. Each data record preferably contains in its corresponding fields all access certificates of the user creating this data record or of the entity to which this data record is inertially assigned.
  • a data record DS is created by user U1 and user U1 has exactly 3 types of certificates according to the content of the ID database (a read access certificate “U1 .Z-Zert [R]”, a write access certificate “U1 .Z-Zert [W] "and an index access certificate” U1 .Z-Zert [S] "), copies of exactly these 3 access certificates are created from the ID database during the storage of the data record DS and which are saved in the corresponding fields of the data record DS.
  • the user U1 can also be the corresponding individual database itself or an identity assigned to this individual database. For example, a secret key of an asymmetrical cryptographic key pair assigned to the corresponding individual database can serve as proof of authentication or proof of identity.
  • the identity can also be based on technical characteristics, such as certain voltage or current patterns of the corresponding individual database or of a computer system comprising the corresponding individual database, comparable to biometric features in the case of living people.
  • the individual database and / or components of the same have means for protection against unauthorized manipulation.
  • the means for protection against unauthorized manipulation ensure the trustworthiness of the individual database or its control elements, such as processors, that is to say its function as a “trust anchor”, through technical measures.
  • the individual database comprises components or is implemented on components which are configured by a trustworthy institution, such as, for example, by a trust center (trust service provider), and which are required cryptographic key material were provided.
  • the means for protection against unauthorized manipulation can ensure that security-relevant functionalities of the individual database or of the computer system comprising this individual database are not modified in an unauthorized manner.
  • the means for protecting against unauthorized manipulation are designed as a so-called tamper proof module or trusted platform module (TPM), which is also referred to as a tamper resistant module (TRM).
  • TPM trusted platform module
  • TRM tamper resistant module
  • the TRM checks whether the signature or the signatures are valid. The test can also be based on the technical characteristics mentioned above. If one of the signatures is not valid, the TRM blocks the use of the individual database.
  • TPM includes, for example, microcontrollers according to the TCG specification as in ISO / IEC 1 1889, which add basic security functions to a computer or similar device.
  • the means for protection against unauthorized manipulation contain mechanical means which, for example, are intended to prevent components and / or the entire computer system from being opened, or which, when an attempt is made to intervene, render the corresponding components unusable for example if data is lost and / or data is blocked.
  • mechanical means which, for example, are intended to prevent components and / or the entire computer system from being opened, or which, when an attempt is made to intervene, render the corresponding components unusable for example if data is lost and / or data is blocked.
  • safety-critical parts can be cast in epoxy resin for this purpose, an attempt to remove a relevant component from the epoxy resin leads to the inevitable destruction of this component.
  • the means for protecting against unauthorized manipulation can be designed as a so-called hardware security module (HSM).
  • HSM hardware security module
  • “Z.Zert_U1 [R]” of user U1 and the user certificate of user U2 are saved, thereby forming an authorization chain object. If the user U2 now wants to access the data record DS at a later point in time, the individual database containing the data record DS automatically sends an authorization request to the ID database of the access management system in response to the access request from user U2. This request contains the access rights of the creator U1 stored in the data record DS. The ID database then checks whether a user certificate assigned to the user U2 is stored in the ID database linked to one or more of the access rights of the creator U1 stored in the data record DS. Only if this is the case, and if the user U2 is also the owner of the source database, is he allowed to access the data record.
  • the at least one access certificate which is preferably stored as part of the data record created, comprises several access certificates for other types of access.
  • the multiple access certificates include, for example, a write access certificate Z.Zert_U1 [W] of the creating user and / or a read access certificate Z.Zert_U1 [R] of the creating user and / or an index access certificate Z.Zert_U1 [S] of the creating user.
  • the access management system is a “standard” access management system that is usually installed on a standard computer system.
  • a “standard” access management system can be MySQL, PostGreSQL, Oracle, SAP Hana, etc.
  • other systems designed for the structured storage and retrieval of data are used as access management systems, for example microcontrollers, in whose memory the data records, certificates and authorization chain objects and the program logic described here can be stored.
  • a user certificate is, for example, a certificate that is issued specifically for a particular person by a certification authority (CA).
  • CA certification authority
  • the user certificate is arranged in a testable manner in a certificate chain issued by a certification authority, so it can be tested for example up to the root certificate of the certification authority. This can be advantageous because certification bodies are already widely accepted as independent guarantors of trust and are already used by many existing technical systems to check the authenticity of certain users and user actions.
  • a plurality of user certificates and / or a plurality of access certificates are stored in an ID database of the access management system.
  • the ID databases each contain access authorization chain objects.
  • An authorization chain object is a data object which contains one of the access certificates and one or more of the user certificates (and thereby assigns them to one another).
  • the sequence of the user certificates in the access authorization chain object reproduces the sequence of users who have issued this access certificate for other users whose user certificate is contained in the access authorization chain object.
  • An authorization hierarchy generated in this way comprises one of the access authorization chain objects.
  • each of the individual databases comprises a corresponding ID database which manages the access authorizations to the data records and / or the index of the corresponding individual database.
  • the individual databases or their data models are free of access authorization chain objects and contain only for each data record the access certificates that grant the user who created this data record or to whom this data record is assigned access to this data record.
  • the linking of these access rights of the data set creator with one or more other users in order to grant this access to the data set is not stored in the individual databases or their data models, but in the ID database.
  • the ID database does not contain any reference to individual data records in the individual database or its data models. This can be advantageous since the size and complexity of the individual data records in the individual databases or their data models are limited and logically largely decoupled from the administration of the access rights.
  • the size of the data records is also limited by the fact that the complete chain of authorization transfers is not saved as part of the data records. In particular in the case of a plurality of small data records with an identical authorization structure, this can considerably reduce the storage space required by the database.
  • the ID database of the access management system contains a private signing key.
  • the individual database contains a public signature verification key, which is designed to verify the signatures created with the signature key.
  • the access management system determines whether the user certificate in the ID database is assigned one or more access authorization certificates, a copy of which is stored as part of the data record. If this is the case, this access authorization certificate is signed with the signing key of the ID database and checked with the corresponding signature verification key of the individual database.
  • the credentials are sent to the individual database in signed form.
  • the individual database uses the signature verification key to check whether the signature of the credentials is valid, the establishment of the database connection and data record access being permitted only if the signature is valid.
  • a central ID database is provided for the entire distributed database system.
  • This can be advantageous because it is not necessary because not every single database has to be equipped with program logic for the certificate chain check.
  • the described method or the described database structure can be used to achieve an extensive separation of data management (in individual databases) and the management of access rights (in the ID database).
  • the ID database contains and / or is operatively linked to one or more program modules, for example for certificate chain checking (for example from user certificates to the root certificate from the certification authority issuing the user certificate), for storing changes to the Allocation of certificates and users in a log file and for the dynamic creation of signed credentials, taking into account a documented chronology of the transfer of rights.
  • the individual individual databases only have means for checking whether appropriate authorizations exist for the individual database itself or for the data records contained therein or are operatively linked to them, these means possibly including means for signature checking.
  • each of the data records in the source database contains one or more access certificates of the user creating the data record or of an entity to which the corresponding data record is assigned.
  • the access certificates in the ID database are each assigned one or more user certificates in such a way that the chronological sequence of users who have granted themselves one or more of the access rights of the user creating the data record each represent in the form of a hierarchy is. This assignment can e.g. take place by means of access authorization chain objects.
  • an “access management system” is understood to mean an electronic system for storing and retrieving data.
  • the access management system can be a “classic database management system” (DBMS) (MySQL, PostgreSQL, Oracle, Hana, etc.).
  • DBMS database management system
  • the data is stored in a microcontroller memory are stored and managed by an application program or a chip-based program logic that works as an access management system and is not a classic DBMS.
  • the data are preferably stored consistently and permanently in the access management system, and various application programs and users are efficiently made available in a needs-based form.
  • An access management system can typically contain one or more databases and manage the data records contained therein.
  • an “ID database” is understood to mean a database which contains and manages user-related information such as user certificates and the rights assigned to these users in the form of further certificates (access certificates).
  • an ID database is mainly used to manage the owners assigned to users with regard to user data - and access rights.
  • At least one index access authorization certificate is stored as part of the additional data record and / or the supplementary data record for the first entity.
  • a read access authorization, a write access authorization and an index access authorization are stored as part of the additional data record and / or the supplementary data record for the first entity.
  • an index access credential for the additional data record is also assigned to a second entity assigned to the receive database.
  • the second entity is a second user of the receive database or a second computer system assigned to the receive data.
  • a prerequisite for sending the supplementary data record to the receiving database is a successful check that the second entity is assigned an index access authorization for the supplementary data record. It can thus be ensured that the receive database is actually authorized to access corresponding index information such as the supplementary data record.
  • the data processing function also includes classifying the tokens generated from the additional data record.
  • the source database for the classification comprises a pre-trained learning module for machine learning, the pre-trained learning module comprising a plurality of predetermined trigger definitions which define triggers for assigning tokens to classes of a first group of classes, the first tokens in the index of the source database, which are included in one of the trigger definitions of the source database as a trigger, are each assigned to the corresponding trigger definition, with second tokens in the index of the source database being assigned to one or more classes of the first group of classes ,
  • classifying comprises:
  • the learning module identifies the corresponding token as a trigger
  • the learning module uses the identified triggers to assign one or more second additional tokens to one or more classes of the first group of classes if the corresponding second additional tokens from the additional data set are in combination with one or more of the identified triggers are included in accordance with one of the trigger definitions, the corresponding triggers triggering a corresponding class assignment in accordance with the corresponding trigger definition, the index being supplemented by the first multi-model database management system using the class assignments of the additional tokens.
  • Embodiments can have the advantage that the learning module is a pre-trained learning module.
  • the pre-trained learning module comprises a plurality of inertially provided or defined trigger definitions.
  • the learning module is configured to classify all tokens included in the database or the index using these inertially defined trigger definitions.
  • Embodiments can have the advantage that no coincidence enters the decision-making or classification process. Rather, the classification of tokens is based on the predetermined trigger definitions and can therefore be traced at any time. Even if the learning module advances, for example, on the basis of the classification and learns further patterns and regularities in the course of a learning transfer based thereon, the underlying classification goes back to the predetermined trigger definitions.
  • meta and / or context information on the classified tokens is provided in the form of the classification.
  • This meta and / or context information is identified on the basis of the triggers in accordance with the trigger definitions and assigned to the corresponding tokens in the form of the class assignment.
  • the learning module can be configured to learn further patterns and regularities using this meta and / or context information.
  • Embodiments can have the advantage that the data records received from the source database are all stored in their original form in the document-oriented data model. This ensures that the full information content of these data records is retained.
  • the data comprised by the data records stored in the document-oriented data model are provided in the form of the index.
  • This index comprises the corresponding data of the document-oriented data model in form of tokens.
  • the index includes all of the elementary data elements included in the document-oriented data model in the form of elementary tokens.
  • the index comprises data elements derived from the tokens.
  • the index additionally comprises combinations of the elementary data elements in the form of token combinations comprised by the document-oriented data model. These token combinations each include a combination of a plurality of elementary tokens.
  • the index comprises token combinations up to a predetermined complexity. The complexity of a token combination is defined, for example, by the number and / or type of elementary tokens it comprises.
  • the tokens included in the index can be triggers according to the predetermined trigger definitions, for example. If a corresponding token is generated for the first time, for example in the course of processing an additional data record, it is identified as a trigger using one of the trigger definitions, added to the index and assigned to the corresponding trigger definition. If the learning module recognizes the same token, which the index defines as a trigger, within a further data set, the learning module accesses the trigger definition assigned to triggering in the index and assigns one or more of the following to the corresponding trigger definition Token from a context of the token stored as a trigger in the further data record is assigned one or more classes of the first group of classes.
  • the index comprises a plurality of tokens which are each assigned to one or more classes of the first group of classes.
  • the assignment to the classes provides meta and / or context information on the corresponding tokens.
  • the corresponding meta and / or context information can be used, for example, for processing the corresponding tokens and / or the data records comprising the corresponding tokens in the document-oriented data model.
  • the corresponding meta and / or context information is included in the course a search query to identify relevant tokens and / or data records or in the course of a further method using the index for machine learning.
  • additional patterns and regularities can be learned in the course of a further learning transfer.
  • This further method for machine learning is carried out, for example, by the learning module using the trigger definitions or a further learning module.
  • the further method for machine learning is a KI method that is executed by a KI module.
  • remaining tokens that are assigned neither to the trigger definition nor to one or more classes of the first group of classes are assigned to a collection class in the index of the source database for identifying the corresponding remaining tokens as unknown data
  • the assignment to the trap class excludes an assignment to one of the trigger definitions as well as an assignment to one of the classes of the first group of classes
  • classifying further comprises:
  • the index also includes tokens that do not fall under any of the predetermined trigger definitions. These tokens are neither triggers nor can they be assigned to the trigger classes defined by the trigger definitions. Rather, these tokens are unknown data which cannot be assigned and for which meta or context information is missing. These tokens are assigned to a collection class as unknown data. An assignment to the collection class excludes an assignment to one of the trigger definitions as well as an assignment to one of the classes of the first groups of classes. Embodiments can have the advantage that, on the basis of the token assignments, it can be recognized in a simple form which tokens are unknown data and which tokens are known data, ie triggers or classifiable data, acts.
  • search queries can be defined in such a way that they only take into account known data.
  • Additional learning algorithms can be configured, for example, in such a way that they work exclusively on known data.
  • the use of chance can be used in a decision-making or classification process, even if additional learning algorithms are used.
  • the basis for all learning processes and / or AI processes is provided by the initially defined triggers, which are used to classify the data received from the database.
  • the predetermined trigger definitions offer a basis for monitored learning.
  • Embodiments can furthermore have the advantage that additional data records that are added to the source database are each analyzed to determine which of the data they comprise is known data and which data is unknown data.
  • known data is understood to mean data which are known as triggers, for which meta or context information is available and / or for which meta or context information is derived from the context of the data records using the trigger definitions can.
  • Data that are neither triggers nor data that can be classified using the trigger definitions are unknown data. Unknown data is assigned to the trap class.
  • Embodiments can have the advantage that a database system optimized for machine learning is used.
  • the corresponding database system includes all of the data on which machine learning is based, ie trigger definitions used to classify data as well as the data which are processed using the trigger definitions. This enables continuous learning by the learning module, taking into account all of the data seen by the system or the learning module.
  • the source database saves all data records received in a document-oriented data model.
  • a document-oriented data model means that the data model does not impose any structural requirements on the data to be saved. Rather, the data are stored in documents or data containers in the form in which they are received. In this sense, the data stored in the document-oriented data model are raw data.
  • Raw data means that the data are stored in the form in which they are received, without additional data processing by the database management system, in particular no restructuring of the data.
  • Embodiments can have the advantage that the entire information content of the received data can be (almost) completely retained without the assumptions of the database management system being included. Both the database management system and the learning module can access the original data at any time and take them into account in further processing.
  • An index is generated based on this data pool of raw data provided by the document-based data model. Structural information or contexts of meaning are only extracted from the data sets at this level. This structural information or context is taken into account in the form of class assignments of the indexed data.
  • the data records are broken down to an elementary level by tokenization, which takes into account the elementary components of the data records in the form of tokens.
  • the tokens are assigned by the learning module as a trigger to one of the trigger definitions or classified as using the trigger definitions. All tokens that are neither identified as triggers nor can be classified using one of the trigger definitions, are assigned to the collection class as unknown data.
  • the learning module includes a classifier and is configured to classify the tokens using the predetermined trigger definitions.
  • the corresponding classification can, for example, be part of a pattern recognition in which a feature extraction is implemented by the tokenization. Based on this extraction of features, however, there is no feature reduction in the classic sense, since the complete database is indexed and thus each token is recognized as a trigger or assigned to a class, at least the collection class.
  • each token in the index is linked to one or more pointers that indicate in which data records the corresponding token occurs. This means that the raw data relevant to a token can be accessed at any time and this raw data can be used for evaluation with regard to this token.
  • Embodiments can have the advantage that the use of the structures and regularities determined by the learning module in the data records, which are reflected in the token assignments, is based on the use of the predetermined trigger definitions. Unknown data, on the other hand, are recorded as such and left out until they can also be classified and thus viewed as reliable facts.
  • Such an additional classification can be implemented, for example, by additional trigger definitions.
  • additional trigger definitions can be added to reduce the amount of tokens included in the collection class. The method thus enables learning and / or classification with reservations.
  • Embodiments can therefore have the advantage that they allow the learning module to work on the entire available database.
  • they can have the advantage of continuous learning enable, which takes into account both additional data sets and already saved data sets.
  • Embodiments can therefore have the advantage that they are not restricted to an arbitrary subset being picked from an available total data set in order to train on it. Rather, all of the data contained in the database are processed using the trigger definitions.
  • By adding to the trigger definitions according to embodiments, it can also be achieved that all tokens are either identified as triggers or classified using the (added) trigger definitions. If unknown data is excluded from search queries and / or further learning processes, this exclusion is not arbitrary, but based on the trigger definitions provided.
  • Embodiments can have the advantage that no random initialization is required, as is the case with known self-learning systems, e.g. neural networks. Rather, the initialization is based on the predetermined trigger definitions. Because of the random moment resulting from this random initialization, the decisions / classifications of a corresponding neural network are not transparent and cannot be traced. In contrast, embodiments can have the advantage of being completely deterministic.
  • Embodiments can have the advantage that an already trained system, ie the pre-trained learning module, is retrained or trained further.
  • Trigger definitions can be added, removed or changed. In this way, for example, the classes used in the classification can be added, removed or changed. If trigger definitions are added, removed or changed, then all assignments of tokens based on these to the corresponding trigger definitions or to one of the classes must be adapted accordingly.
  • the learning module implements an algorithm for machine learning, the method not being restricted to a specific algorithm.
  • the machine learning algorithm comprises at least one classification algorithm for classifying tokens.
  • Machine learning can be monitored or unsupervised learning.
  • the machine learning can include a classification and / or a regression analysis.
  • a learning algorithm tries to find a hypothesis or a mapping that assigns the (assumed) output value to each input value. If the output values to be assigned are present in a continuous distribution, the results of which can assume any quantitative values in a given range of values, then this is generally referred to as a regression problem. If, on the other hand, the output values to be assigned are in discrete form or if the values are qualitative, this is generally referred to as a classification problem.
  • the machine learning is based on the classification of the indexed tokens.
  • the learning module comprises an algorithm specially developed for machine learning, such as, for example, without being limited to a density-based multidimensional outlier detection ("local outlier detection"), a Random Forrest algorithm, a neural network, a support vector machine, a naive Bayes classifier or a feedback similar to the feedback of a linear or non-linear controller.
  • a multi-model database is understood here to mean a database which is configured to support a plurality of different data models.
  • a multi-model database is thus configured to store, index and query data in more than one data model.
  • Data models are, for example, relational, column-oriented, document-oriented, graph-based, key-value-based etc.
  • a database model defines the structure in which data is stored in a database system, ie in which form the data is organized, stored and processed.
  • a database is understood to be a (typically large) amount of data that is managed in a computer system by a database management system (DBMS) according to specific criteria. The data is organized in a large number of data sets.
  • DBMS database management system
  • a database management system or DBMS is understood to mean an electronic system for storing and retrieving data.
  • the data are preferably stored consistently and permanently in the DBMS, and various application programs and users are efficiently made available in a needs-based form.
  • a DBMS can typically contain one or more databases and manage the data records contained therein.
  • the DBMS can preferably be a field-oriented DBMS, that is to say a DBMS that is configured to store parts of individual data records, so-called field values, in several different fields.
  • a data record is understood to be a coherent set of data provided to the database system, which is managed by the database management system as a coherent set of data.
  • a data record comprises, for example, a set of content-related data.
  • data sets are stored in the document-oriented data model as coherent data sets.
  • a single data set can refer to a particular physical object, e.g. a natural person or a device. The person can e.g. be an employee, a patient, a customer, etc.
  • the device can be, for example, a production device, a computer device, a computer or network element or a transport device.
  • the corresponding data record can contain a predefined set of attribute values for this person or device (e.g. name or pseudonym, age, height, weight, date of birth, ID numbers, security certificates, authentication codes, biometric data, identifier, date of entry, commissioning date, configuration data , and other).
  • a data record can represent a group of content-related data fields (belonging to an object), e.g. B. Item number, Item size, item color, item name or something similar.
  • the classes' name ', address'and' date of birth 'could form the logical structure of a data record for the object type “person”.
  • data is stored in the form of data records in databases, whereby they are the subject of the processing of computer programs and are generated, read, changed and deleted by these.
  • NoSQL (English for Not only SQL) DBMS is a DBMS that follows a non-relational approach to data storage and does not require any fixed table schemes.
  • the NoSQL DBMSs include in particular document-oriented DBMSs such as Apache Jackrabbit, BaseX, CouchDB, IBM Notes, MongoDB, graph databases such as Neo4j, OrientDB, InfoGrid, HyperGraphDB, Core Data,
  • ACID DBMSs such as MySQL Cluster
  • key-value databases such as Chordless, Google BigTable, GT.M, InterSystems Cache, Membase, Redis, sorted key-value stores, multivalue databases
  • Object databases such as Db4o, ZODB, column-oriented databases and temporal databases such as Cortex DB.
  • An index is a data structure which accelerates a search for certain data values by a database management system.
  • An index consists of a collection of pointers (references) that define an order relation to several “indexed” data values (stored in the index). For example, B + trees are used for this.
  • Each indexed data value is linked with further pointers which refer to data records in which the indexed data value found is contained and which represented the database for creating the index.
  • Database management systems use indices to quickly identify the desired data records in response to a search query by first searching the index along the pointer for a data value which is identical to a reference value contained in the search query.
  • the data values of a field managed by the DBMS would have to be searched sequentially, while a search using the index, for example a B + tree, often only has logarithmic complexity.
  • the index also assigns the indexed data, ie tokens, to classes, as a result of which the corresponding data are linked with meta or context information.
  • This meta or context information can be used in a search and / or in a machine learning process on the data in the database.
  • a field is an area on a logical or physical data carrier which is managed by a DBMS, which is assigned to a predefined field type and which is created and intended for storing a field value of a data record.
  • a field is therefore an element for storing a field value of a data record as defined above. Fields of a data record are managed jointly by a DBMS.
  • a field value is a data value that is part of a data record and is stored in a field of the data record.
  • a field value can consist of a single word, a single number, or a combination of several words and / or numbers and / or other data formats, with different embodiments of the invention varying degrees of flexibility with regard to the type and combinability of data types within of the same field value.
  • a "tokenizer” is a program logic that receives data, for example a field value, as input, analyzes the data, for example to identify delimiters or other decomposition criteria and patterns, and then breaks the data down into one or more tokens as the result of the analysis and returns the tokens. It is also possible that not all data will be returned as tokens. For example, a full text indexer can recognize semantically insignificant stop words and filter them out so that they are not indexed. Alternatively, all data is returned as.
  • To “tokenize” a data value means breaking the data value into several components according to a certain scheme. The components represent the tokens.
  • natural-language texts can be divided up using predefined separators, such as spaces, periods or commas, and the components (words) generated in this way are used as tokens.
  • tokens are all tokens used for indexing. It is also possible that some tokens are not used for indexing (e.g. stop words) or that the tokens are additionally processed prior to indexing (e.g. reducing words to the stem).
  • the search value is preferably processed in the same way by the client computer system or the server computer system to ensure that the search values of the search queries match those in the index contained tokens.
  • a class defines a category or a type to which a token belongs.
  • the class therefore assigns meta or context information to the token, for example in the form of a property.
  • a class can represent a certain attribute of a physical object in the form of a token.
  • data records to be saved that contain employee attributes, which classes such as "Name”, “Pseudonym”, "ID number”, "Access certificate for room R”, “Access certificate for device G”, “Access certificate for building GB”, Represent "age”.
  • Each token can be assigned to one or more classes.
  • combinations of tokens can in turn be assigned to one or more further classes as independent tokens.
  • the data records received are stored using a document-oriented data model. For example, all field values of the stored data records are transferred as tokens into a multi-dimensional key / value store (key / value store) or key-value databases.
  • the tokens are assigned token types and stored in a form that meets the sixth normal form.
  • the transaction time and the validity time of the data records are also stored bit-temporally.
  • the transaction time indicates the point in time at which a change to a data object in the database occurs.
  • the validity period specifies a point in time or period in which a data object is in the modeled Image of the real world has the described state. If both the validity and the transaction time are relevant, one speaks of bitemporal.
  • a key-value data model enables storage, retrieval and management of associative data fields. Values are uniquely identified using a key.
  • a document-oriented data model also known as a document store
  • documents or data containers form the basic unit for storing the data.
  • a document-oriented data model enables document-oriented information, also known as semi-structured data, to be stored, retrieved and managed.
  • Databases based on a document-oriented data model belong to the NoSQL databases and form a sub-class of key-value stores.
  • key-value store the data are viewed as inherently opaque for the database, while a document-oriented database relies on internal structures in the stored documents in order to extract metadata.
  • the semi-structured data model is a database model in which there is no separation between the data and the schema and the scope of the structure used depends on the purpose of the database. Each document within the data model is addressed via a unique identifier.
  • a combination of the different database concepts enables data sets to be saved as documents or containers (document disturb) and additionally in the form of an index, e.g. of a key-value memory to be converted into the 6th normal form.
  • This key-value memory represents the entire data volume in the document memory, while the original data records are retained.
  • selections are carried out exclusively in the key-value memory in the redundancy-free sixth normal form. Only the result is read from the document storage container.
  • a selection right is also implemented on the key-value memory. This means that you can work on the index alone without having to read out the underlying data.
  • the proposed multi-model database thus provides a complete normalization of the entire scope of data in the sixth normal form in addition to a schematic data storage on the basis of a document memory.
  • Embodiments can have the advantage that the index contains data elements of the data records, i.e. Token, included as a key and each of these keys is assigned one or more pointers as values which indicate in which data records and / or fields of the data records the corresponding key, i.e. Token / data value, saved as field value.
  • This index therefore forms all fields of the data records and their contents, i.e. the field values from the entire database with all of the data records it encompasses, so that all queries are handled in the index and the data of the document-oriented data model stored without a schema are only used to output the search results.
  • the small size of the index compared to the schema-less data enables quick queries in any query combination.
  • a computer or computer system is understood here to mean a device which processes data by means of programmable arithmetic rules.
  • a program or program instructions is understood here without restriction to mean any type of computer program which includes machine-readable instructions for controlling a functionality of a computer.
  • a computer or computer system can comprise a communication interface for connection to the network, wherein the network can be a private or public network, in particular the Internet or another communication network. Depending on the embodiment, this connection can also be established via a cellular network.
  • a computer system can be a stationary computer system, such as a personal computer (PC) or a client or server integrated in a client-server environment.
  • a computer system can be, for example, a mobile telecommunication device, in particular a smartphone, a portable computer, such as a laptop PC or palmtop PC, a tablet PC, a personal digital assistant or the like.
  • a corresponding computer system it can also be an object of the Internet of Things (“smart device”), e.g. a so-called “wearable” or
  • wearable computers i.e. portable electronic devices or portable computer systems which are arranged on the body of the user during use.
  • wearables are smartwatches, i.e. Watches with computer functionality and connectivity, activity trackers, i.e. Device for recording and sending fitness and / or health-related data, smart glasses, i.e. Glasses whose insides serve as a screen or items of clothing in which electronic communication aids are incorporated.
  • a computer system can be a computer system of a means of transport, such as a car, airplane, ship or train with an on-board computer.
  • a computer system can be a control computer of a smart home system, an access point or router of a local WLAN network, a multimedia device with computer functionality and connectivity, such as a smart TV, a control system Locking system or a "smart device” or intelligent objects, ie an everyday object with information technology, which receives added value through sensor-based information processing and communication.
  • a multimedia device with computer functionality and connectivity such as a smart TV, a control system Locking system or a "smart device” or intelligent objects, ie an everyday object with information technology, which receives added value through sensor-based information processing and communication.
  • a memory is understood here to mean both volatile and non-volatile electronic memories or digital storage media.
  • a non-volatile memory is understood here to mean an electronic memory for the permanent storage of data.
  • a non-volatile memory can be configured as a non-changeable memory, which is also referred to as read-only memory (ROM), or as a changeable memory, which is also referred to as non-volatile memory (NVM).
  • ROM read-only memory
  • NVM non-volatile memory
  • it can be an EEPROM, for example a Flash EEPROM, referred to as Flash for short.
  • Flash Flash for short.
  • a non-volatile memory is characterized by the fact that the data stored on it are retained even after the power supply has been switched off.
  • a volatile electronic memory is a memory for the temporary storage of data, which is characterized in that all data is lost after the power supply is switched off.
  • this can be a volatile random access memory, which is also referred to as a random access memory (RAM), or a volatile main memory of the processor.
  • RAM random access memory
  • a processor is understood here and in the following to be a logic circuit that is used to execute program instructions.
  • the logic circuit can be implemented on one or more discrete components, in particular on a chip.
  • a processor is understood to mean a microprocessor or a microprocessor system made up of several processor cores and / or several microprocessors.
  • the corresponding additional token is supplemented under its class assignments in the index, and if one of the class assignments of an additional token included in the index is not included in the index supplementing the corresponding class assignment with the corresponding additional token in the index and linking the corresponding additional token in the index with the pointer to the additional data record stored in the document-oriented data model.
  • the corresponding class assignments are added.
  • the pointer to the additional data record is added to the index for these tokens.
  • Embodiments can have the advantage that it can always be ensured that the index has all tokens comprised by the data records of the corresponding individual database.
  • the index includes all class assignments found for all corresponding tokens.
  • each of the tokens of the index is linked with a pointer to all of the data records of the corresponding individual database which contain the corresponding token.
  • an initial set of predetermined trigger definitions is established.
  • data records are received and stored in the document-based data model.
  • the stored data records are tokenized and class assignments are determined for the resulting tokens using the initially defined trigger definitions and an initial index is generated for the resulting tokens.
  • the initial index includes all triggers included in the trigger definitions as tokens.
  • tokens determined as triggers by the trigger definitions are only added to the index on the condition that they are included in one of the data records.
  • Allocation of a token to a class using a predetermined trigger function sets a by the corresponding predetermined trigger Function secured fact. For tokens which are not a trigger and which are not covered by any of the trigger definitions, there is a lack of such factual knowledge. Instead, the corresponding tokens are assigned to the trap class as unknown data. Embodiments can thus have the advantage that, using initially established trigger definitions, new data can be divided into known data, ie triggers or tokens classified using trigger definitions, and unknown data, ie the collection class assigned tokens.
  • the combinations of second additional tokens with one or more of the identified triggers that have triggered a class assignment according to one of the trigger definitions are identified in the index as classified combinations and class assignments are only made for combinations of the second additional tokens and one or more identified triggers, which are not identified as classified combinations.
  • Embodiments can have the advantage that for all token combinations for which a class assignment has already been taken into account or for which a class assignment has already been carried out, are each identified in the index as already classified. It can thus be avoided that the same classifications are carried out again for token combinations which the learning module has already seen and fully taken into account in the course of the classifications.
  • the system can thus be designed to be significantly more efficient.
  • the index includes all token combinations for which a classification has already taken place, ie all token combinations which are to be marked as classified.
  • the corresponding token combinations in the index are each provided with a flag which indicates whether the corresponding token combination is classified token combinations.
  • a comparison with all token combinations marked as already classified takes place first.
  • the classification is not repeated for these token combinations; rather, there is only a link with the pointer to the additional data record.
  • the corresponding pointer is also linked to all of the tokens included in the token combination in the index.
  • the comparison first takes place with the largest, ie most extensive, token combinations of the index. For all token combinations of the additional data record already recognized as classified, only the pointer to the corresponding data record is stored in the source database. According to embodiments, the corresponding pointer is also linked to all of the tokens included in the token combination in the index.
  • a comparison with further token combinations takes place successively, with the size or the scope of the further token combinations used gradually decreasing. According to embodiments, only those further token combinations with a smaller size or scope are taken into account which, as part of a larger or more extensive token combination, a match was not found in the course of the comparison.
  • Embodiments can have the advantage that for extensive token combinations which are recognized as already classified, no additional comparison takes place for sub-combinations comprised by the corresponding token combination. Rather, a corresponding comparison only takes place if the corresponding sub-combination is included in the additional data record as an independent token combination, independent of the corresponding more extensive token combination.
  • the method further comprises:
  • Embodiments can have the advantage that, based on the triggers identified by the initial trigger definitions, additional triggers can be identified in the form of trigger combinations. Based on these identified trigger combinations, combined trigger definitions can be determined from the initial trigger definitions, with which the majority of the predetermined trigger definitions can be expanded.
  • token combinations which are included in the same data record and fall under the combined trigger definition are combined with one another and the resulting combination is identified in the index as a classified combination.
  • Embodiments can have the advantage that on the basis of combined trigger definitions, token combinations in the index can be identified as classified combinations, thereby avoiding unnecessary repetitions of classifications of already classified token combinations.
  • the combination criterion includes a minimum frequency for the corresponding trigger combination to occur in the data records.
  • Embodiments can have the advantage that corresponding trigger combinations are only used to form a combined trigger definition when the corresponding trigger combination occurs in the data records with a minimum frequency. This prevents additional combined trigger definitions from being created due to the accidental occurrence of triggers with different trigger definitions in one and the same data record. Such a random occurrence is from a certain size and / or Complexity of the data sets can be expected without it being possible to draw conclusions about an underlying relationship between the triggers. However, if the corresponding trigger combinations occur more frequently, a connection can be concluded from them.
  • the minimum frequency defines an absolute frequency value of the occurrence in the data records.
  • the corresponding minimum frequency can be a minimum value for the occurrence of the corresponding trigger combination in all data records. The occurrence of the corresponding trigger combination is added up across all data records. If the resulting sum is greater than or equal to the minimum value, this is fulfilled.
  • the minimum frequency can be a minimum value for the occurrence in one of the data records. The occurrence of the corresponding trigger combination is summed up individually for the individual data records. If one of the resulting sums meets the minimum value, the minimum frequency is present.
  • the minimum value must be fulfilled by a predetermined number of data records or a predetermined percentage of the data records.
  • the corresponding predetermined percentage is either a percentage of all data records in the database or all data records which comprise the corresponding trigger combination.
  • the minimum value must be fulfilled by all data records and / or by all data records that include the corresponding trigger combination.
  • the corresponding minimum frequency can be a minimum value for an average frequency of occurrence of the corresponding trigger combination in all data records in the database or in all data records which comprise the corresponding trigger combination.
  • the minimum frequency defines a relative frequency value of the occurrence in the data records.
  • the corresponding minimum frequency is dependent on the number of data records and / or the number of tokens and / or the size of the data comprised by the data records. For example, the frequency value specified by the minimum frequency grows with it the number of data records and / or the number of tokens and / or the size of the data comprised by the data records.
  • the minimum frequency stipulates a relative frequency value of the occurrence in the data records relative to the frequencies of occurrence of one or more of the triggers comprised by the corresponding trigger combination in the data records.
  • the relative frequency value is dependent on the occurrence of the trigger with the highest frequency of an occurrence, the trigger with the lowest frequency of an occurrence and / or an average value of the occurrence of all triggers of the corresponding trigger combination.
  • Embodiments can have the advantage that, when a relative frequency value is taken into account, the frequency of occurrence of one or more of the triggers comprised by the corresponding trigger combination is included in the decision-making process as to whether an additional combined trigger definition is based on the corresponding trigger combination is to be supplemented, is included.
  • the frequency of occurrence of the corresponding triggers can relate to an occurrence of the corresponding triggers in all data records, to an average occurrence in all data records, to a most frequent occurrence in one of the data records and / or relate to a minimal occurrence in one of the data records.
  • Embodiments can have the advantage that the relative frequency value is selected to be higher, the higher the frequencies of occurrence of the one or more corresponding triggers comprised by the trigger combination. It can thus be avoided that a trigger definition is generated on the basis of a trigger combination, the occurrence of which is random, i.e. whose triggers happen to be included in the same data set, without this indicating a connection between the corresponding triggers.
  • the combination criterion includes one or more conditions at relative positions of the triggers of the corresponding trigger combination to one another within one of the data records.
  • Embodiments can use the Have the advantage that a relative position of the triggers of the corresponding trigger combination within the data set is taken into account for the combination criterion.
  • a corresponding relative position of data within data records results from or is dependent on contextual relationships. Corresponding contextual relationships can therefore be read from the relative position.
  • the relative position can be a relative position in a one-dimensional, ie sequential, data structure such as a text or speech file, a two-dimensional data structure such as an image file , or a higher-dimensional, for example three-dimensional or n-dimensional, data structure.
  • the trigger definitions each comprise a definition of a trigger structure which positions relative to one another for one or more triggers included in the corresponding trigger definition and one or more tokens to be assigned to one of the classes according to the corresponding trigger definition specifies.
  • Embodiments can have the advantage that a corresponding trigger definition using one or more triggers defines how one or more tokens are to be classified as a function of a relative position of the corresponding tokens to the corresponding triggers.
  • the corresponding relative position can be a relative position in a one-dimensional, two-dimensional or higher-dimensional, for example three-dimensional or n-dimensional, data space.
  • the stipulations of the relative positions include at least one of the following stipulations: the one or more tokens to be assigned are arranged according to a trigger included in the corresponding trigger definition, the one or more tokens to be assigned are before one of the corresponding triggers -Definition included triggers arranged that have an or Several tokens to be assigned are each arranged between triggers included in the corresponding trigger definition.
  • a trigger can, for example, trigger a classification of preceding data, e.g. "[before1] [Trigger1]”.
  • the occurrence of the trigger “Trigger1” triggers a classification of the preceding data “before1”.
  • the trigger itself is part of the classification, i.e. the combination "[before1] [Trigger1]” is classified.
  • the trigger “Trigger1”, if it is recognized, is assigned as a trigger to the corresponding trigger definition.
  • a trigger can, for example, trigger a classification of subsequent data, e.g. "[Trigger2] [after1]”.
  • the occurrence of the trigger “Trigger2” triggers a classification of the subsequent data “after1”.
  • the trigger itself is part of the classification, i.e. the combination “[Trigger2] [after1]” is classified.
  • the trigger “Trigger2”, when it is recognized, is assigned as a trigger to the corresponding trigger definition.
  • a trigger can, for example, trigger a classification of preceding and following data, e.g. "[before2] [trigger3] [after2]”.
  • the occurrence of the “Trigger3” trigger triggers a classification of the preceding data “before2” and the following data “after2”.
  • the trigger itself is part of the classification, i.e. the combination “[before2] [trigger3] [after2]” is classified.
  • the trigger “Triggers”, if it is recognized, is assigned as a trigger to the corresponding trigger definition.
  • a combination of two or more triggers can, for example, trigger a classification of preceding, following and data arranged between the triggers, eg “[before3] [trigger4] [between1] [trigger5] [after3]”.
  • the combination of the triggers “Trigger4" and “Trigger5” a classification of the preceding data “before3”, the following data “after3” and the data in between “in between 1”.
  • the triggers themselves are part of the classification, ie the entire combination “[before3] [trigger4] [between1] [trigger5] [after3]” is classified.
  • the triggers “Trigger4” and “Trigger5” are assigned as triggers to the corresponding trigger definition when it is recognized.
  • a trigger combination can comprise any number of triggers, e.g. ,, [before4] [trigger6] [between2] [trigger7]
  • a trigger combination of triggers “Trigger6” to “Trigger6 + (N + 1)” triggers a classification of the preceding data “before4”, the following data “after4” and the data in between “between2” to “in between” - between2 + N “.
  • the triggers themselves are part of the classification, i.e.
  • the entire combination is classified “[before4] [trigger6] [between2] [trigger7]
  • a trigger [between2 + N] [trigger6 + (N + 1)] [after4].
  • the formulation "May over” is a first trigger [Trigger1] and with the formulation "and” around a second trigger [Trigger2]
  • the structure thus corresponds to a structure of the form [before] [Trigger1] [between] [Trigger2] [after].
  • previous data [before] classified as an identity, and data in between [in between] and subsequent data [after] are each classified as identities.
  • the formulation "The customer bears the damage" is a trigger.
  • the structure therefore corresponds to the structure [trigger] [after].
  • the subsequent data [after] is classified as a condition.
  • a trigger definition can stipulate that a token which is located within a radius around a specific trigger in an n-dimensional data space is to be assigned to a specific class.
  • a token which is located within a radius around a specific trigger in an n-dimensional data space is to be assigned to a specific class.
  • it can also be decisive for the class assignment in which spatial direction the token is correspondingly rejected by the trigger. This can for example be defined by a vector which defines the relative position of the token to the trigger.
  • a trigger definition can stipulate that a token which is arranged within a plurality of radii around one trigger of a plurality of triggers is to be assigned to a specific class.
  • n-dimensional areas delimited by the individual radii overlap and delimit an n-dimensional or lower-dimensional intersection area in the n-dimensional data space.
  • a token which is part of this n-dimensional or lower-dimensional intersection area is assigned to a certain class, for example.
  • a maximum trigger distance is defined for the triggers in accordance with the trigger definitions, which defines a maximum distance relative to the corresponding trigger to which a trigger effect of the trigger is limited.
  • Embodiments can have the advantage that the corresponding maximum distance is a radius around the corresponding trigger in an n-dimensional data space.
  • the trigger effect is limited to the corresponding maximum trigger distance in front of and behind the corresponding trigger.
  • the trigger effect is limited to a two-dimensional circular area around the corresponding trigger.
  • the trigger effect is limited to a spherical volume around the corresponding trigger.
  • the trigger effect is limited to a volume of an n-dimensional sphere around the corresponding trigger.
  • the maximum distance can depend on the spatial direction and be set to be of different sizes in different spatial directions.
  • the maximum trigger spacing is identical for all triggers. According to embodiments, the maximum trigger spacing is identical for a subset of the triggers. According to embodiments, the maximum trigger spacing is determined individually for each trigger.
  • the corresponding maximum trigger distance can be a distance in a certain unit, depending on the type of data. For example, a sequential sequence in time is a time interval measured in a time unit, such as milliseconds, seconds or minutes.
  • a one-dimensional, two-dimensional or three-dimensional spatial data structure is a spatial distance in a spatial unit, such as millimeters, centimeters, decimeters or meters.
  • the distance can be based on pixels or voxels, for example. A corresponding distance can thus be, for example, a number of pixels or a number of voxels.
  • the distance is a logical distance. This can for example be based on elementary data elements, such as elementary characters.
  • a corresponding distance can be a number of characters, for example.
  • the corresponding distance can be a number of elementary data elements composed of elements, such as a number of words. For example, the number is limited to a certain part of speech.
  • the distance can be limited by logical elements in the data structure, such as a punctuation mark and / or a trigger.
  • the method further comprises:
  • the reclassification by the learning module corresponding to a replacement of the assignment to the collection class with an assignment to the latter includes additional trigger definition, which includes the corresponding token as an additional trigger
  • the learning module uses the additional triggers to reclassify one or more tokens assigned to the collection class in the index to one or more classes of the second group of classes if the corresponding tokens assigned to the collection class are from one of the data records in a combination with one or more of the additional triggers are included and the corresponding additional triggers according to FIG corresponding additional trigger definition triggers a corresponding assignment to the one or more classes of the second group of classes.
  • Embodiments can have the advantage that by adding additional trigger definitions to the learning module, the number of tokens that are assigned to the interception class can be reduced. Additional trigger definitions can be supplemented in a targeted manner in order to reclassify those tokens that are assigned to the trap class. Additional trigger definitions can therefore be supplemented as a function of the data records which the corresponding individual database comprises and the unknown data which they comprise.
  • additional trigger definitions are added until all tokens of the trap class are reclassified.
  • corresponding additional trigger definitions are added according to predefined intervals.
  • Corresponding predefined intervals are defined in time, for example, based on the number of tokens included in the collection class, the amount of data stored in the corresponding individual database and / or the amount of data added to the corresponding individual database since the last addition.
  • the second group comprises classes different from the classes in the first group.
  • Embodiments can have the advantage that additional classes are defined so that those tokens of the collection class can be classified for which the meta or context information corresponding to the classes of the first group cannot be used. Rather, additional meta or context information can be defined and used by the classes of the second group.
  • one or more classes of the second group are each identical to one of the classes of the first group.
  • Embodiments can have the advantage that the additional trigger definitions trigger are provided, which enable an assignment of the tokens of the collection class to classes of the first group of classes.
  • the trigger definitions to be supplemented are each dependent, as supplements, on a trigger definition already included in the learning module.
  • Embodiments can have the advantage that one or more of the supplementary trigger definitions are defined in the form of additions to the trigger definitions already included in the learning module.
  • the corresponding supplementary trigger definitions extend, for example, the trigger effect of already existing trigger definitions.
  • the supplementary trigger definitions form combined trigger definitions with the already existing trigger definitions.
  • the additions are carried out repeatedly following a recursive scheme, the trigger definitions to be added to each recursion level each comprising additions to a trigger definition of a preceding recursion level, so that the recursive additions form tree structures which each have one of the predetermined trigger Include definition as root node.
  • Embodiments can have the advantage that the trigger effect of the existing trigger definitions can be successively expanded by a progressive recursion scheme until all tokens of the collection class are reclassified.
  • the result of the corresponding additions to the already existing trigger functions can be tree structures, for example, which can be followed by a classification of tokens.
  • the additional trigger definitions to be supplemented are received by the learning module.
  • Embodiments can have the advantage that the corresponding trigger definitions can, for example, be provided externally, for example by an administrator. So he has corresponding administrators always have the opportunity to control, correct and add to the classification.
  • an external fine adjustment can optionally or optionally take place, for example by an administrator.
  • additional trigger definitions from the class of the unknown data i.e. the collection class
  • tokens are extracted and assigned to existing classes and / or new classes are generated to which extracted tokens are assigned.
  • an administrator provides additional trigger definitions that are applied to the collection class, analogous to the initial trigger definitions provided.
  • the additional triggers are applied exclusively to the collection class and to data received in the future in accordance with the additional trigger definitions.
  • the use of an additional trigger can be implemented as an IF condition. For example, if another trigger has already been successfully applied to a data record, e.g. a trigger1, and the data record also includes data classified as unknown, where an additional trigger, e.g. a trigger2, applied according to one of the additional trigger definitions.
  • This fine adjustment can be repeated several times as a recursion. For example, the recursion is continued until the interception class no longer includes any tokens, ie no more unknown data exists, or the number of tokens comprised by the interception class reaches and / or falls below a predefined threshold value, ie a predefined maximum number.
  • the corresponding threshold value can be an absolute value which is independent of the number of tokens included in the index and the amount of data included in the corresponding individual database.
  • the corresponding threshold value can be a relative value which is dependent on the number of tokens included in the index and / or the data volume included in the corresponding individual database
  • trigger trees or decision trees can arise after the initially defined triggers or trigger definitions, the number of levels depending on the number of recursions N, eg the number of levels is equal to N + 1.
  • each initial trigger or each initial trigger definition forms a root point of a corresponding trigger tree or decision tree.
  • a decision tree is understood here to mean ordered, directed trees that serve to represent decision rules.
  • a data record includes an initial trigger, which means that part of the tokens in the data record can be classified without all tokens in the data record being able to be classified at the same time, it is checked whether the data record also includes a trigger of the first recursion. If the data record includes a trigger of the first recursion, whereby a further part of the tokens of the data record can be classified without all data of the data record being able to be classified at the same time, it is checked whether the data record also includes a trigger of the second recursion and so on.
  • the additional trigger definitions to be supplemented are created by the learning module, which comprises a statistical model, the statistical model being used for a statistical analysis of the tokens included in the collection classes and their occurrence in the data records, the result of the statistical analysis is used to create the additional trigger definitions to be supplemented.
  • Embodiments can have the advantage that the learning module can independently create supplementary additional trigger definitions. For example, the optional or facultative fine adjustment described above takes place using the statistical model.
  • the statistical model identifies triggers within the unknown data, for example by frequency analyzes and correlation analyzes, which are then applied to the tokens classified as unknown in a manner analogous to the procedure described above.
  • Embodiments can also take a recursive approach using the statistical model.
  • the method further comprises:
  • an administrator can recognize errors in classified classes and correct them if necessary, for example by providing a corrected trigger definition, on the basis of which tokens are reclassified.
  • Embodiments can have the advantage that a correction of trigger definitions is made possible at any point in time during the method. For example, the trigger definitions can be checked after training the learning module. If correction trigger definitions are identified, correspondingly corrected trigger definitions are provided.
  • Embodiments can have the advantage that corrected trigger definitions can also be provided at a later point in time when incorrect classifications are recognized. Administrative intervention in the learning and classification process is therefore possible at any time. This means that errors in the learning system can be corrected without having to convert the entire model.
  • the pointers with which the tokens are stored linked in the index each refer to one or more of the field values in the stored data records.
  • Embodiments can have the advantage that a finer granularity can be achieved when determining the origin of tokens in the data records. Such a finer granularity also enables the relative relationships of the tokens within the data records to be broken down and taken into account in an analysis or other use of the index.
  • the field values of the additional data record include text data, image data, audio data and / or video data.
  • the method can be used, for example, for signal processing, such as 1 D audio recognition, 2D and 3D image processing, or ND data input from N sensors, etc.
  • the method can be used, for example, for an analysis of stream data (bitstream or bit stream).
  • a bit stream also known as a bit stream, here refers to a sequence of bits that represent a flow of information, i.e. a serial or sequential signal.
  • a bit stream is thus a sequence of bits of indefinite length in chronological order.
  • a bit stream for example, represents a data stream divided into logical structures, which is divided into more fundamental small structures such as symbols of a fixed size, i.e. Bits and Bytes, and can be further broken down into blocks and data packets of different protocols and formats.
  • generating the tokens includes applying tokenization logic to the field values of the additional data record, which logic includes a full-text indexer that is configured to break down texts into words and to output the words as tokens.
  • the corresponding text files can be any text.
  • the corresponding text files can be measured value files or algorithms for controlling computers and / or technical systems.
  • the field values of the additional data record include full texts, the full texts including words and / or one or more numbers formed from letters of one or more alphabets.
  • Full-text indexing involves breaking down texts into individual words, with the individual words of a text field then being stored in an index assigned to this field. Full text indexing is only supported if the corresponding field is configured for the selective storage of a certain data type, eg CFIAR, VARCFIAR or TEXT.
  • natural language text in JSON format can be stored in a field.
  • generating the tokens includes applying tokenization logic to the field values of the additional data record, which logic includes a generic tokenizer that is configured to recognize data of different data types in the field values and from these tokens in different data types to create.
  • tokenization logic includes a generic tokenizer that is configured to recognize data of different data types in the field values and from these tokens in different data types to create.
  • Embodiments can have the advantage that effective tokenization can be implemented for different types of data, such as text data, image data, audio data and / or video data.
  • the method further comprises:
  • Embodiments can have the advantage that the index of the source database can also be expanded by supplementary data records from other individual databases.
  • the third individual database is, for example, an individual database which in turn receives supplementary data records from the source database. Changes to the indexes can thus be mutually exchanged between individual databases and uniform copies of a cross-database index can be implemented on a distributed database system, more precisely in the individual databases.
  • the method further comprises:
  • the response comprising at least: an indication of the identified tokens, one or more data records determined by analyzing pointers with which the identified tokens are linked, or one or more references to the specific data records .
  • Embodiments can have the advantage that the index can be used for effective searches.
  • the searches can be limited to information in the index, for example in how many or in which data records a certain search value occurs.
  • an index access Authorization required.
  • a search can also be carried out in this way on the data records of the local individual database, ie the individual database performing the search, although the data records are stored in their original form.
  • a read access authorization is necessary according to the embodiments. In the case of data records which are stored on another individual database, these can be explicitly requested for reading. For this purpose, according to embodiments, read access authorization is again necessary.
  • the learning module can search for patterns and / or regularities within the data records using appropriate search queries.
  • the index stores all tokens generated from the field values of the data records of a corresponding individual database in such a way that the index contains each token only once.
  • Each token contains pointers to one or more of the data records from whose field values it was generated. If an index generated according to the invention is searched for a specific search value and a token stored in the index is identified as the result of the search, which is identical to the search value, then this token uses pointers to refer to all data records that contain this token Contained at least once in at least one of their field values and which were used when the index was created.
  • the data records, which represent a “hit” with regard to the search value can be identified and returned very quickly using the references, without the need for a sequential search across all data records.
  • the search value further comprises a class assignment and the identification of the token within the index further requires that the identified token has the same class assignment.
  • Embodiments can have the advantage that class assignments and thus meta or context information indexed with the class assignments can be taken into account in the search queries.
  • triggers are identified in the index with a flag.
  • the search value further includes an assignment to a trigger definition and / or a flag identifying a trigger, and the identification of the token within the index further requires that the identified token is assigned to the same trigger definition and / or the same Has flag.
  • tokens which are assigned to the trap class are excluded from the search.
  • Embodiments can have the advantage that the resulting search results have a high degree of reliability, since unknown data are excluded from the search.
  • the method further comprises pre-training the learning module.
  • the pre-training includes:
  • the predetermined trigger definitions define initial triggers that are used to structure or classify received data.
  • the initial triggers are specifically defined, i.e. predetermined trigger definitions. If data is loaded, these initial triggers enable an initial classification according to known classes as well as unknown data, which are assigned to the collection class.
  • the pre-training further comprises:
  • data e.g. Text data, audio data, image data, video data or N-dimensional data from N sensors
  • the triggers applied to automatically classify the data. This results in a fragmentation of the data into triggers, known classes, i.e. classes defined by the trigger definitions, and in unknown data.
  • Embodiments can have the advantage that the learning module can be effectively pre-trained in this way on the basis of the predetermined trigger definitions.
  • These predetermined trigger definitions can serve as the basis for obtaining further trigger definitions, for example by combining trigger definitions.
  • trigger definitions For example, there is an automatic learning phase of the database system or the learning module, which includes a combination of the initial triggers.
  • the initially loaded triggers can be combined, as described above, based on the data comprised by the data records, and thus the number of trigger definitions available can be increased.
  • token combinations that have already been classified can be identified. The purpose of this is to ensure that identical data that are later loaded into the source database do not have to be reclassified, but are already marked as "known" in the system.
  • generating one of the additional tokens comprises using one of the field values of the additional data set in its entirety as the corresponding additional token. It is entirely possible that the index also contains tokens from fields to which no tokenization is applied or whose content simply cannot be divided into individual tokens. According to embodiments, generating one of the additional tokens comprises dividing one of the additional field values of the additional data record into a plurality of subfield values and using one of the subfield values as the corresponding additional token. Embodiments can have the advantage that the granularity of the data used or the tokenization can be adapted independently of the granularity of the fields.
  • the index stores all tokens generated from the field values of the stored data records in such a way that the index contains each token exactly once for each of the token assignments of the corresponding token.
  • the tokens, the class assignments and the assignment to the trigger definitions can be stored in the form of relations or equivalent structures.
  • a relation is a set of tuples.
  • a tuple is a set of attribute values.
  • An attribute denotes a data type or a property assigned to one or more data.
  • the number of attributes determines the degree, the number of tuples the cardinality of a relation.
  • the document-based data model used by the multi-model database management system to store the data sets is a NoSQL data model.
  • the DBMS is a NoSQL DBMS. This can be advantageous because it has been found that NoSQL DBMS in particular, which often have a more flexible structure than classic SQL-based DBMSs. Because of the flexibility of their structure, NoSQL DBMSs are particularly suitable for managing and storing data records from which an index can be created in accordance with embodiments of the invention.
  • the index has the structure of a tree, in particular a B + tree.
  • Embodiments can have the advantage that a tree structure, in particular the structure of a B + tree, enables a particularly efficient and fast search for the tokens stored in the index.
  • a B + tree is a data and / or index structure that is an extension of a B-tree.
  • the actual data elements are only stored in the leaf nodes, while the inner nodes only contain keys.
  • several of the data records stored in a document-oriented data model each comprise a different number of fields.
  • Embodiments can have the advantage that data sets of different sizes and structures or granularity can be processed.
  • the fields each have a common, generic data format.
  • Embodiments can have the advantage that since a large number of different data types can be stored in a specific field. A user or an application program who wants to save data records in the source database does not have to worry about the consistency and matching of data types. A high degree of flexibility with regard to the structure and the scope of the data records that can be managed and stored by the multi-model database management system can therefore be offered.
  • the learning module or the machine learning implemented by it is configured for data extraction, consistency checking, image recognition, speech recognition, voice control, device monitoring and / or autonomous device control.
  • This can, for example, already consist in the classification of the tokens, with tokens assigned to the collection class as unknown data being viewed, for example, as an indication of a potential malfunction. For example, this can be based on the index with the tokens and their meta or context information, which serves as the basis for a additional machine learning algorithm applied to it.
  • the collection class is emptied by adding additional trigger definitions so that meta or context information is provided for all tokens of the database system.
  • a data extraction can comprise, for example, a recognition and extraction of a pattern in a text, image, audio or video file.
  • This pattern can, for example, be defined by a trigger definition or it can be recorded in the classified data.
  • a corresponding pattern can be, for example, a predetermined event recorded in the form of sensor values, for example a person in an effective area of a device.
  • a consistency check can include, for example, a consistency check in a text, image, audio or video file. In this case, it is checked, for example, whether the corresponding data include unknown and thus inconsistent data, whether they include data that differ greatly from the rest of the data or whether they include data that are explicitly predefined as inconsistent.
  • a corresponding consistency check can be used, for example, to check for errors in control algorithms of devices, to detect malfunctions using measurement data from a function of a device, or to detect errors in text files, for example in the form of a spell check.
  • Image recognition can be used to recognize objects, events or features in image or video files. For example, context information on what is visually represented is recorded and / or displayed. This can include, for example, a visual representation of information, that is, the addition of images or videos with computer-generated additional information or virtual objects by means of fading in / overlaying. Such a method is generally referred to as augmented reality. Speech recognition can be used to recognize speech in audio files or video files, for example for voice control or for converting speech into text form.
  • Pattern recognition in text, image, audio or video files can be used for device monitoring. In particular, occurring or impending malfunctions can be recognized in this way. This can serve safety and enables predictive maintenance of the corresponding device, since potential problems can be identified at an early stage.
  • a corresponding text file is, for example, a data record with measured sensor values.
  • an autonomous device control can also be implemented, for example an autonomous control of vehicles, robots or industrial plants.
  • a “device” is generally understood here to mean a technical device with sensors for acquiring status data of the device and a device computer system for logging the acquired status data.
  • the device can also exist in the corresponding computer system with sensors.
  • the received data sets are data sets recorded by a device computer system using the sensors.
  • Computer system for machine learning A device comprises, for example, a vehicle, a plant, such as a production plant, a processing plant, a conveyor system, an energy generation system, a heat generation system, a control system, a monitoring system, etc.
  • a “vehicle” is understood here to mean a mobile means of transport. Such a means of transport can be used, for example, to transport goods (freight transport), tools (machines or auxiliary equipment) or people (passenger transport). Vehicles in particular also include motorized means of transport.
  • a vehicle can be, for example, a land vehicle, a watercraft and / or an aircraft.
  • a land vehicle can be, for example: an automobile, such as a passenger car, omnibus or a Lorry, a motor-driven two-wheeler such as a motorcycle, moped, scooter or motor bike, an agricultural tractor, forklift truck, golf cart, truck crane.
  • a land vehicle can also be a rail-bound vehicle.
  • watercraft can be: a ship or boat.
  • an aircraft can be, for example: an airplane or a helicopter.
  • a vehicle is also understood to mean, in particular, a motor vehicle.
  • the device comprises at least one sensor for detecting status data of the device.
  • the state data of the device are received by the device computer system from the at least one sensor.
  • the device comprises a plurality of sensors for acquiring status data of the device.
  • Embodiments can have the advantage that the device's own sensor system can be used to detect the state of the device.
  • the state of the device can be described, for example, through information on parameters of the current performance of the device, such as the mileage of a vehicle, consumption values, performance values, error messages, results of predefined test protocols and / or identifiers of components of the device.
  • Parameters of the current performance of a vehicle can be, for example, engine speed, speed, fuel consumption, exhaust gas values, and transmission gear.
  • a “sensor” is understood here to be an element for recording measurement data.
  • Measurement data are data which physical or chemical properties of a measurement object, such as amount of heat, temperature, humidity, pressure, flow rate, sound field sizes, brightness, acceleration, pH value, ion strength, electrochemical potential, and / or its material properties qualitatively or quantitatively reproduce. Measurement data are recorded using physical or chemical effects and converted into an electronic signal that can be processed further. Furthermore, measurement data can be states and / or Show changes in the state of electronic devices due to external influences and / or as a result of use by a user.
  • Sensors for recording status data in a vehicle can include, for example: crankshaft sensor, camshaft sensor, air mass meter, air temperature sensor, cooling water temperature sensor, throttle valve sensor, knock sensor, transmission sensor, distance sensor, transmission sensor, level sensor, brake wear sensor, axle load sensor, steering angle sensor. These sensors record and monitor the driving behavior of the vehicle. Malfunctions can be recognized and identified from deviations from target values and / or the occurrence of specific patterns. In some cases, specific causes of errors, such as failed vehicle components, can also be identified. Sensors can also query the identifiers of electronic components that are built into the vehicle in order to check their identity.
  • Embodiments include a source computer system for implementing a cross-database index on a distributed database system, which comprises a plurality of computer systems comprising the source computer system, each with an independent individual database, the computer systems with the individual databases being communicatively connected to one another via a network.
  • the computer systems also each include one or more processors, one or more data storage media on which the respective individual database is made available, a communication interface for communication via the network, and a program logic.
  • the individual databases are each managed by a multi-model database management system, the individual databases each comprising a plurality of database-specific data records that are stored in a document-oriented first data model of the respective individual database, the stored data records each having one or more field values include, the individual field values of the stored data records are each stored in a field.
  • the individual databases also each comprise a searchable first index which is stored in a second data model of the respective individual database, the index of the respective individual database comprising a plurality of tokens generated from the field values of the data records stored in the document-oriented data model of the corresponding individual database, the tokens is linked in the index with one or more pointers to one or more of the data records stored in the document-oriented data model of the corresponding individual database, from whose field values the corresponding token was generated.
  • the program logic of the source computer system is configured to perform a method of implementing a cross-database index, the method comprising:
  • the source computer system is configured to carry out one or more of the aforementioned embodiments of the method for implementing a cross-database index on the distributed database system.
  • Embodiments further include a distributed database system for implementing a cross-database index on the distributed database system, which includes one of the plurality of computer systems each with an independent individual database, the computer systems with the individual databases being communicatively connected to one another via a network .
  • the computer systems also each include one or more processors, one or more data storage media on which the respective individual database is made available, a communication interface for communication via the network, and program logic.
  • the individual databases are each managed by a multi-model database management system, the individual databases each comprising a plurality of database-specific data records which are stored in a document-oriented first data model of the respective individual database, the Stored data records each comprise one or more field values, the individual field values of the stored data records each being stored in a field.
  • the individual databases also each comprise a searchable first index which is stored in a second data model of the respective individual database, the index of the respective individual database comprising a plurality of tokens generated from the field values of the data records stored in the document-oriented data model of the corresponding individual database, the tokens is linked in the index with one or more pointers to one or more of the data records stored in the document-oriented data model of the corresponding individual database, from whose field values the corresponding token was generated.
  • the program logic is each configured to execute a method for implementing a cross-database index by the computer system executing the program logic of the plurality of computer systems, which method acts as a source computer system, the method comprising:
  • the distributed database system is configured to carry out one or more of the aforementioned embodiments of the method for implementing a cross-database index on the distributed database system.
  • Figure 1 is a schematic block diagram of an embodiment of a
  • Figures 2 are schematic diagrams of an embodiment of an exemplary distributed database system
  • FIG. 3 shows a schematic diagram of an embodiment of an exemplary distributed database system
  • FIG. 4 shows a schematic flowchart of an exemplary method
  • FIG. 5 shows a schematic flowchart of an exemplary method
  • FIG. 6 shows a schematic flowchart of an exemplary method
  • FIG. 7 shows a schematic flowchart of an exemplary method
  • FIG. 8 shows a schematic block diagram of embodiments of exemplary computer systems
  • FIG. 9 shows a schematic block diagram of an exemplary assignment of rights
  • FIG. 10 shows a schematic block diagram of an exemplary implementation of a system for granting rights
  • Figure 1 1 is a schematic block diagram of an embodiment of a
  • FIG. 12 shows a schematic block diagram of an exemplary data processing by the multi-model database management system
  • FIG. 13 a schematic block diagram of an exemplary data processing by the multi-model database management system
  • FIG. 14 shows a schematic block diagram of embodiments of exemplary computer systems
  • FIG. 15 shows a flow diagram of an embodiment of an exemplary method
  • FIG. 16 shows a flow diagram of an embodiment of an exemplary method
  • FIG. 17 shows a flow diagram of an embodiment of an exemplary method
  • FIG. 18 shows a flow diagram of an embodiment of an exemplary method.
  • FIG. 1 shows a block diagram of an embodiment of an exemplary computer system 100, which comprises an individual database 104 for implementing a cross-database index on a distributed database system 170.
  • the distributed database system 170 comprises a plurality of individual databases 104, which are each implemented on a computer system 100.
  • the computer system 100 further includes a multi-model Database management system (MM-DBMS) 1 18, which manages the, possibly structured, storage of data in the at least one individual database 104 and controls all read and write accesses to the individual database 104.
  • the MM-DBMS 1 18 supports at least two data models 106, 1 10, in which data are stored in the individual database 104.
  • the database model defines the form in which the relevant data is organized, saved and processed.
  • the first data model 106 is a document-based data model in which a plurality of data records DS1, DS2, DS3 are stored. Each data record DS1, DS2, DS3 is saved in a document or a data container. No specific structure is specified for the data records DS1, DS2, DS3 themselves when they are stored by the document-based data model 106.
  • the data records DS1, DS2, DS3 can therefore be stored with the internal structure with which the data records DS1, DS2, DS3 are received from the individual database 104.
  • the data records DS1, DS2, DS3 stored in the document-based data model 106 are raw data.
  • the data records DS1, DS2, DS3 can include, for example, text data, image data, audio data and / or video data.
  • the data records DS1, DS2, DS3 each include at least one field F1, ..., F8, with field values.
  • the data records DS1, DS2, DS3 can already have an internal structure with a plurality of fields F1,..., F8 when they are stored.
  • the corresponding data records DS1, DS2, DS3 then each comprise a plurality of fields F1, ..., F8.
  • the data records DS1, DS2, DS3 do not have any fields even when they are received, they each include, for example, exactly one field in stored form which comprises the entire data volume of the corresponding data record DS1, DS2, DS3.
  • the fields F1, ..., F8 each contain one or more field values.
  • Each of the field values of a data record DS1, DS2, DS3 is stored in a corresponding field, a type of data container.
  • Each field F1, ..., F8 can be assigned to a field type.
  • the fields F1, ..., F8 can be assigned different or all of the same field type.
  • the composition of the field values of the individual data records DS1, DS2, DS3 can vary with regard to their Differentiate between field types.
  • each document comprises a field for each mandatory field type and optionally comprises one or more further fields for optional field types.
  • the data of the data records are then stored in fields of the field type intended for them, ie for example text data in one or more text fields, image data in one or more image fields, audio data in one or more audio fields and / or video data in one or more video fields.
  • the computer system 100 includes a tokenizer 120 for generating tokens 109.
  • the MM-DBMS 118 can also include the tokenizer 122.
  • the computer system 100 for example the MM-DBMS 118, has a built-in program logic or data processing function which is configured to generate an index 112.
  • the corresponding index 112 is provided in a further data model 110 in which the complete data of the data records DS1, DS2, DS3 or a data volume derived from these are stored in a restructured, redundancy-free form.
  • the tokenizer 122 is accessed, which is configured to tokenize the field values of the fields F1,..., F8 of the data records 106 stored in the document-based data model 106.
  • the resulting tokens 109 can also be identical to a field value of a field or a data record if no further breakdown into tokens 109 is possible or useful.
  • the tokenization can also take place in stages, so that an ever finer breakdown takes place.
  • the resulting index 112 can therefore include tokens 109 which are composed of other tokens 109.
  • the program logic or data processing function can be identical on all computer systems 100 or for all individual databases 104 of the distributed database system 170.
  • the program logic or data processing function can be distributed between computer systems 100 or individual databases 104 of the Database system 170 also differentiate, for example depending on the type or the content of the data to be stored by the respective individual database.
  • All or at least most of the field values of all data records DS1, DS2, DS3 of the individual database 104 are preferably tokenized, so that an extensive amount of tokens 109 is created.
  • tokens 109 can include a mixture of numbers, letters, images or image segments, audio files or audio elements or other data structures, in particular sensor data from one or more sensors.
  • Each of the generated tokens 109 is stored in the index 112 linked to a pointer, the pointer pointing to the data record or the field from which the token 109 originates.
  • a non-redundant, unique token set is formed from the set of tokens 109, in which each of the tokens 109 occurs at most once. All tokens 109 of the non-redundant token set are preferably stored in the index 112 in such a way that the tokens 109 are sorted according to a sorting criterion and are stored in sorted form in the index structure.
  • the sorting can for example take place on the basis of the alphabet for alphanumeric data or other sorting criteria adapted to the data.
  • the tokens 109 are stored in the index 112 preferably in sorted form, and are furthermore preferably stored in a tree structure, it is possible very quickly to identify a specific token 109 within the index 112 and then to identify the references
  • a supplementary data record 130 is created, which includes the additions made in the index 112 of the source database 104 and is used to supplement further indices of further individual databases of the distributed database system 170 as receive databases.
  • the supplementary data record 130 created in this way is sent to the receiving databases of the distributed database system 170 via a network using a communication interface 126 of the computer system 100.
  • FIG. 2A shows a diagram of an embodiment of an exemplary distributed database system 170.
  • the distributed database system 170 comprises a plurality of nodes K 1 ,..., K 6 . These nodes K 1 ,..., K 6 are formed by computer systems 100, 200, which each comprise an individual database of the distributed database system. Each of the nodes K 1 , ..., K 6 individually aggregates data D 1 , ..., D 6 and uses them to create an index l 1 , ..., l 6 .
  • the corresponding node K 1 , ..., K 6 creates an additional data record E (I 1 ), which the additions to the index I 1 , and sends this to the further accounts K 2 ,..., K 6 of the distributed database system 170, for example node K 2 .
  • the further nodes K 2 ,..., K 6 of the distributed database system 170 create supplementary data records E (l 2 ) when their index is supplemented, for example I 2 , and send them to the further nodes, such as node K 2 .
  • FIG. 3 shows a plurality of nodes K 1 ,..., K N of a distributed database system 170, each of which includes an individual database 1,..., N.
  • each of the individual databases 1,..., N comprise a complete cross-database index of the distributed database system 170, which includes the information of all individual indices I 1 , ..., I N.
  • FIG. 4 shows a flow chart for adding the indexes.
  • a first node K 1 of the distributed database 170 is provided, which includes a data processing function F 1 .
  • the node K 1 receives data D 1 .
  • An index I 1 is generated from this data D 1 in step c) using the data processing function F 1 or an existing index I 1 is supplemented.
  • the resulting index I 1 or a supplementary data record resulting from the addition of the existing index I 1 is sent from the node K 1 to at least one further node K 2 of the distributed database 170.
  • the further node K 2 also includes data D 2 , from which an index I 2 is generated using the data processing function F 2 .
  • the index I 2 is supplemented by the received index information I 1 of the first node K 1 , so that the resulting index of the node K 1 is a combined index l (l) which contains the index information of both indices I 1 , I 2 of both nodes K 1 , K 2 combined with each other.
  • FIG. 5 shows a flow chart of an exemplary method for implementing a cross-database index on a distributed database system.
  • an additional data record is received as a source database by a first individual database of the distributed database system.
  • This additional data record which for example includes one or more additional field values, is used to supplement the source database.
  • the additional data record is stored by a multi-model database management system of the source database in a document-oriented first data model of the source database.
  • a data processing function of the source database is applied to the additional data record, which includes at least indexing of the additional data record for storage in a second data model of the source database.
  • one or more additional tokens are generated from the additional data set.
  • the index of the source database is generated by the first multi-model database management system using the additional tokens and a pointer to the additional tokens in the document-oriented data model of the source database added. For example, the additional tokens are compared with the index of the source database. If one of the additional tokens is not included in the index of the source database, the corresponding additional token is added to the index of the source database and linked to the pointer to the additional data set stored in the document-oriented data model of the source database. If one of the additional tokens is already included in the index of the source database, the corresponding additional token is linked in the index of the source database with the pointer to the additional data record stored in the document-oriented data model of the source database.
  • a supplementary data record resulting from the application of the data processing function is created.
  • This supplementary data record comprises the additions made to the index of the source database and is used to supplement at least one second index of at least one second individual database of the distributed database system as a receive database.
  • the supplementary data set is sent via a network to the second individual database for integration into the second index of the receive database.
  • FIG. 6 shows a flowchart of an exemplary method for integrating a supplementary data record into the index of a receive database.
  • the receive database receives the supplementary data record from a source database.
  • the supplementary data record includes additions made to the index of the source database.
  • the supplementary data set received is integrated into the index of the receive database.
  • the integration includes adding to the index of the receiving database. For example, tokens of the supplementary data record are compared with the index of the source database.
  • the corresponding token is supplemented in the index of the source database and in the index with a Pointer to the data record stored in a document-oriented data model of the source database from which the corresponding token was generated. If one of the tokens of the supplementary data record is already included in the index of the source database, the corresponding token in the index of the source database is linked to the pointer to the data record stored in a document-oriented data model of the additional source database from which the corresponding token was generated.
  • FIG. 7 shows a flow diagram of an embodiment of an exemplary method for carrying out a search on one of the individual databases.
  • a search query is received that includes a search value.
  • the index is searched for the search value and in block 504 a token is identified within the index which is identical to the search value and / or which falls below the search scope defined by the search value.
  • pointers are analyzed with which the identified token or tokens are associated. In this way, one or more of the data records can be determined which contain one or more field values from which the indexed token was generated.
  • a response to the search query is returned.
  • This response includes, for example: an indication of the identified tokens, one or more specific data records or one or more references to the specific data records by analyzing pointers with which the identified tokens are linked. If, for example, a search is only made for which tokens meet a certain criterion determined by the search value, it is sufficient to return the tokens found without further analysis of pointers or data records. If, according to the search, the data records that comprise the tokens found are also to be identified, the pointers are analyzed, but access to the underlying data records is not necessary. Alternatively, the underlying data records can also be queried according to the search.
  • FIG. 8 shows a schematic block diagram of an embodiment of an exemplary source computer system 100 and an exemplary receiving computer system 200 of a distributed database system 170.
  • Both computer systems 100, 200 each include at least one processor 114, 214 which executes program instructions 116, 216 .
  • the program instructions 1 16, 216 By executing the program instructions 1 16, 216, the method described above for implementing a cross-database index on a distributed database system 170 is implemented, for example.
  • the processors 114, 214 each execute a multi-model database management system 118, 218 and a tokenizer 122.
  • the computer systems 100 each include an individual database 104, 204 in a memory 102, 202, which is managed by the respective multi-model database management system 1 18, 218.
  • the databases 104, 204 each include a first data model 106, 206, for example a document-oriented data model, in which data sets 108, 208 are stored.
  • the databases 104, 204 each include a second data model 110, 210 with an index 112, 212 of all the data stored in the data records 108, 109.
  • the indexes 112, 212 In order to be able to synchronize the indexes 112, 212 for different data records 108, 109 and thus to implement a cross-database index on the distributed database system 170. If, for example, a supplementary data record 130 is generated on the source computer system 100, which supplementary data record includes additions to the index 112.
  • both computer systems 100, 200 each include a communication interface 126, 226 through which they can communicate with one another via a network 180.
  • the source computer system 100 sends the supplementary data record 130 via the network 180 to the receiving computer system 200, which uses the received supplementary data record 130 to synchronize its index 212 with the index 112.
  • FIG. 9 shows a block diagram of the allocation of rights by means of the transmission of access rights via a chain of entities, such as individual databases or their users.
  • a data record 108 with useful data 160 is received by an individual database.
  • access certificates 162, 164, 166 which are assigned to a first entity, are automatically stored in the background in corresponding fields of the data record.
  • the first entity is, for example, the creator of the data record, such as the corresponding individual database or a user of the same.
  • the access certificates 62, 164, 166 are for different types of Configured access to the data record.
  • the access certificate 162 is for read access
  • the access certificate 166 for access to tokens of an index which are generated from the corresponding data record.
  • an index access certificate 166 in an ID database 172 of the further entity which index accesses in relation to assigned to the data record 108 enables. This takes place, for example, in that a link between this certificate 166 and a user certificate 168 of the further entity is stored in the ID database 172, for example within the same access authorization chain object.
  • access rights with regard to the data record 108 can also be assigned to a third entity.
  • the index access certificate 166 is also assigned to this further entity. This is done, for example, by storing a link between this certificate 166 and a user certificate 174 of the third entity in the ID database 172, for example within the same access authorization chain object.
  • the user certificate 174 can either be attached to the user certificate 168 or directly to the index access certificate 166.
  • the chain of user certificates documented in the access authorization chain objects documents the transfer of access rights over a sequence of several users.
  • the sequence can consist of a simple stringing together of user certificates, whereby for example the position of the user certificates represents the time series of transmissions within the chain objects.
  • the chain of user certificates within an authorization chain object can be generated in that the ID database uses the private keys assigned to the individual user certificates so that the last user certificate in the chain is the new one - added new user certificate signed so that a certificate chain check is also possible within the chain of user certificates of the individual authorization chain objects.
  • FIG. 10 shows a block diagram of the distributed database system 170.
  • This includes, for example, a source computer system 100 and a receiving computer system 200.
  • the source computer system 100 sends a supplementary data set 130 to the receiving computer system 200 via a network 180 to supplement one from the receiving database 204 of the receiving computer system 200 include an index so that this is synchronized with an index of the source database 104 of the source computer system 100.
  • the source computer system 100 or a user of the same To access the index of the source database 104, the source computer system 100 or a user of the same must provide evidence of access rights. These are checked, for example, by a comparison with an access authorization chain object stored in the source ID database 172. If the access rights exist, the index can be accessed, for example, and a supplementary data record 130 can be created. So that the receiving computer system 200 is also authorized to supplement the index of the receiving database 204, a corresponding access authorization chain object is generated for this or a user of the same and is transmitted to the source ID database 174. The receiving computer system 200 can thus also prove its access rights. According to embodiments, authorization of the receiving computer system 200 or the receiving database 204 is a necessary prerequisite for sending the supplementary data record 130 with index information to the receiving database 204. According to alternative embodiments, a central ID Database for several or all computer systems 100, 200 of the distributed database system 170 can be provided.
  • FIG. 11 shows a block diagram of an expanded embodiment of the exemplary computer system 100 from FIG. 1, which is configured for machine learning.
  • the computer system 100 from FIG. 11 additionally comprises a learning module 120 for processing the data stored in the individual database 104.
  • the learning module 120 comprises, for example, the tokenizer 120 for generating tokens 109 and also trigger definitions 123, which define triggers for a classification of tokens 109, and / or a classifier 124, which the tokens 109 using the trigger definitions 123 classified.
  • the learning module 120 further comprises a statistical model 125.
  • the statistical model 125 can be configured to record trigger combinations and create combined trigger definitions, create additional trigger definitions and / or correct trigger definitions. Create definition.
  • the MM-DBMS 1 18 can also include the tokenizer 122 and / or access a tokenizer 122 provided by the learning module 120.
  • the trigger definitions 123 can also be stored in the individual database 104.
  • the MM-DBMS 1 18 and / or the learning module 120 have a built-in program logic that is configured to generate an index 1 12.
  • tokens 109 in the index 112 which are included as triggers in one of the trigger definitions 123, are each assigned to the corresponding trigger definition 123. Furthermore, tokens 109 in index 112, which are comprised by one of the data records DS1, DS2, DS3 in a combination with one or more of the identified triggers according to one of the trigger definitions 123, are each assigned to one or more classes. The corresponding class assignments provide meta or context information for the corresponding tokens 109. Finally, the remaining tokens 109 are in the index 1 12, which are neither using the trigger definitions 123 nor identify as trigger, nor assign to a class as, assigned to a collection class to identify as unknown data. An assignment to the collection class excludes an assignment to one of the trigger definitions 123 as well as an assignment to one of the classes in accordance with the trigger definitions 123. The assignments described above take place, for example, using the classifier 124 of the learning module 120.
  • a non-redundant, unique token set is formed from the set of tokens 109, in which each of the tokens 109 occurs only once. Even if a token 109 with a certain value and a certain class assignment occurs several times in the individual database 104 or in the data model 106, it is only stored once with this class assignment in the non-redundant token set and in the index 112, for example.
  • FIG. 12 shows a schematic block diagram of an exemplary data processing by the multi-model database management system and the learning module.
  • This trigger definition 123 defines two triggers, i.e. a first trigger “lives in” and a second trigger “in”.
  • the trigger definition also defines that a token immediately preceding the first trigger is a surname, while a token immediately preceding the surname is a first name.
  • the trigger definition also defines that a token arranged between the two triggers is a street and that a token immediately following the second trigger is a city.
  • Two documents 108 are stored in a document-based data model 106 of a database.
  • Each document 108 each comprises a data record DS1, DS2.
  • the data records DS1, DS2 are each a text file.
  • the first data record DS1 includes, for example, the sentence: "Sample first name_1 sample last name_1 lives in Musterstrasse_1 in Musterstadt_1". This sentence is broken down into tokens 109 by means of a tokenizer: "Sample first name_1", “Sample surname_1", “lives in the", “Sample street_1", “in”, “Sample city_1".
  • the two tokens "lives in” and "in” are identified as triggers according to the trigger definition 123.
  • the remaining tokens 109 are each assigned to the classes 1 1 1 defined by the trigger definition.
  • the tokens identified as triggers like the tokens classified using these triggers, are stored in an index in a second data model 110.
  • the triggers are each assigned to the trigger definition 123 in the form of a trigger assignment 1 17.
  • the remaining tokens 109 are each stored in the form of a class assignment 113, assigned to one of the classes defined by the trigger definition 123.
  • all triggers and classified tokens in the second data model 110 are identified with a pointer 115 to their storage location in the first data model, i.e. DS1, linked.
  • the two tokens "lives in” and "in” are identified as triggers according to the trigger definition 123. Since these two triggers of the trigger definition 123 are already included in the index, they are not stored again in the second data model 110. Only a pointer to the second data record DS2 is added. Using the identified triggers and the trigger definition 123, the remaining tokens 109 of the data record DS2 are each used by the Trigger definition assigned to defined classes 1 1 1.
  • the classified tokens 109 of the data record DS2 are each stored in the form of a class assignment 1 13 assigned to one of the classes defined by the trigger definition 123 and linked with a pointer 1 15 to their storage location in the first data model, ie DS2.
  • All tokens of the second data record DS2 are therefore also stored in a redundancy-free form, each with their class assignments in the second data model 110 linked with a pointer to their storage location in the first data model.
  • FIG. 13 shows a schematic block diagram of an exemplary data processing by the multi-model database management system and the learning module.
  • This trigger definition 123 is used to classify tokens generated from an image file, the image file being broken down into tokens in the form of pixel groups.
  • the trigger definition 123 defines two triggers, i.e. a first trigger in the form of a pixel group with the content “+” and a second trigger in the form of a pixel group with the content “x”.
  • the trigger definition defines that a pixel group which is arranged within a first radius of N pixels around the first trigger and at the same time within a second radius of N pixels around the second trigger is a token of the Class "class" acts.
  • a document 108 is stored in a document-based data model 106 of a database.
  • This document 108 comprises a data record DS.
  • the data record DS is a two-dimensional image file.
  • This image file is broken down into tokens by means of a tokenizer, the tokens each being pixel groups 150.
  • the pixel groups of equal size in Z by Z are broken down.
  • the tokens include, for example, a first Token in the form of a pixel group with the content “x”, a second token in the form of a pixel group with the content “+”, a third token in the form of a pixel group with the content “#” and a fourth token in the form of a pixel group with the content
  • the two tokens “+” and x ” are identified as trigger 121 according to trigger definition 123.
  • the third token “#” is assigned to the class 1 1 1 defined by the trigger definition, since it is in the two-dimensional image file within a first radius 152 of N pixels around the first Trigger “+” and at the same time is arranged within a second radius 154 of N pixels around the second trigger “x”. Since the fourth token does not fall under the trigger definition 123, it is assigned to the trap class as an unknown date.
  • the tokens “+” and “x” identified as triggers 121 are stored in an index in a second data model 110, as are the token “#” classified on the basis of these triggers and the token assigned to the collection class.
  • the triggers “+” and “x” are each assigned to the trigger definition 123 in the form of a trigger assignment 1 17.
  • the token “#” is saved in the form of a class assignment 1 13 assigned to the classes defined by the trigger definition 123.
  • the token is stored in the form of an assignment 1 19 assigned to the collection classes.
  • all triggers and classified tokens in the second data model 110 are identified with a pointer 115 to their storage location in the first data model, i.e. DS, linked.
  • FIG. 14 shows a schematic block diagram of an embodiment of an exemplary source computer system 100 and an exemplary receiving computer system 200 of a distributed database system 170.
  • the embodiment from FIG. 14 largely corresponds to the embodiments from FIG. 8.
  • the two computer systems 100, 200 also have each has a learning module 120, 220 which, in addition to the tokenizer 122, 222, also has trigger definitions 123, 223 for classifying the data by means of a classifier 124, 224 and a statistical model 125, 225.
  • FIG. 15 shows a flow diagram of an embodiment of a further exemplary method for implementing a cross-database index on a distributed database system.
  • a pre-trained learning module for machine learning is provided for a source database of the distributed database system, which learning module comprises a plurality of predetermined trigger definitions. These predetermined trigger definitions define triggers for assigning tokens to classes of a group of classes.
  • the corresponding source database is provided.
  • the source database is managed by a multi-model database management system and comprises a plurality of data records which are stored in a document-oriented data model. These saved records each include one or more fields with field values.
  • the source database provided includes a searchable index of all the data included in the stored data records. This index is stored redundancy-free in a further data model managed by the multi-model database management system.
  • the index comprises a plurality of tokens generated from the field values of the stored data records, which are linked in the index with one or more pointers to one or more of the data records and / or fields stored in the document-oriented data model corresponding token was generated.
  • the first tokens in the index which are included as triggers in one of the trigger definitions, are each assigned to the corresponding trigger definition.
  • Second tokens in the index are each assigned to one or more classes of the group of classes.
  • the remaining tokens in the index are finally assigned to a collection class to identify the corresponding remaining tokens as unknown data.
  • the assignment to the collection class excludes an assignment to one of the trigger definitions as well as an assignment to one of the classes of the first group of classes.
  • an additional data set is received and in block 606 by the multi-model database management system in the document-oriented one Data model of the source database saved.
  • the storage takes place in a document or data container.
  • the additional data record is processed further using a data processing function. This includes:
  • one or more additional tokens are generated from additional field values that the additional data set comprises.
  • one or more first additional tokens are identified as triggers if they are included as triggers by one of the trigger definitions.
  • the remaining additional tokens are classified.
  • the triggers identified in block 610 are used to assign one or more second additional tokens to one or more classes of the group of classes if the corresponding second additional tokens from the additional data record are in combination with one or more - reren of the identified triggers are included in accordance with one of the trigger definitions and the corresponding triggers trigger a corresponding class assignment in accordance with the corresponding trigger definition.
  • the remaining additional tokens, for which no assignment to one of the trigger definitions and no class assignment based on one of the trigger definitions has taken place, are assigned to the collection class in the course of the classification in block 612.
  • the index is generated by the multi-model database management system using the additional tokens from block 608, the class assignments of the additional tokens from block 612 and a pointer to the additional tokens in the document-oriented data model saved data record added. If pointers indicate individual fields of the additional data record, a plurality of pointers is used for a plurality of fields.
  • the addition in block 614 can include a comparison of the additional tokens with the index. If one of the additional tokens is not included in the index, the corresponding additional token is added to its class assignments in the index and linked to the pointer to the additional data record stored in the document-oriented data model. If one of the class assignments of an additional token included in the index is not included in the index, the corresponding class assignment is supplemented with the corresponding additional token in the index and the corresponding one linked additional tokens in the index with the pointer to the additional data set stored in the document-oriented data model. If one of the additional tokens with all of its class assignments is included in the index, the corresponding additional token in the index is linked to the pointer to the additional data record stored in the document-oriented data model.
  • the addition in block 614 can include identifying combinations of second additional tokens with one or more of the identified triggers, which have triggered a class assignment according to one of the trigger definitions, in the index as classified combinations.
  • Class assignments are only carried out for combinations of second additional tokens and one or more identified triggers which are not identified as classified combinations.
  • token combinations are compared with the index. If the index already includes the corresponding token combination and this is marked as classified, there is no new classification for this token combination. Only the corresponding token combination and / or the partial combinations and individual tokens comprised by the corresponding token combination are linked in the index with the pointer to the additional data record stored in the document-oriented data model.
  • a supplementary data record resulting from the application of the data processing function is created.
  • This supplementary data record comprises the additions made to the index of the source database and is used to supplement at least one second index of at least one second individual database of the distributed database system as a receive database.
  • the supplementary data set is sent via a network to the second individual database for integration into the second index of the receive database.
  • FIG. 16 shows a flow diagram of an embodiment of an exemplary method for generating combined trigger definitions.
  • one or more trigger combinations are identified by the learning module, which are each comprised by at least one of the data records and which meet a combination criterion.
  • the trigger definitions of the triggers of the corresponding trigger combinations are combined into one or more additional combined trigger definitions.
  • the plurality of predetermined trigger definitions of the learning module is supplemented by the one or more additional combined trigger definitions.
  • FIG. 17 shows a flow diagram of an embodiment of an exemplary method for supplementing additional trigger definitions.
  • the pre-trained learning module is supplemented by one or more additional trigger definitions.
  • the additional trigger definitions define additional triggers for a replacement of assignments of tokens in the index to the receiving class by assignments to one or more classes of a further group of classes in the course of a reclassification.
  • the additional trigger definitions can be received by the learning module, for example.
  • the corresponding additional trigger definitions are provided by an administrator.
  • the additional trigger definitions to be supplemented are created by the learning module.
  • the learning module includes a statistical model which is used for a statistical analysis of the tokens included in the collection classes and their occurrence in the data records. The result of the statistical analysis is used to create the additional trigger definitions to be added.
  • one or more tokens assigned to the collection class are reclassified in the index, which tokens define the additional trigger definitions as additional triggers.
  • the reclassification by the learning module includes a replacement of the assignment to the collection class by an assignment to the corresponding additional trigger definition, which the corresponding token as includes additional trigger.
  • the additional triggers for reclassifying one or more tokens assigned to the collection class in the index to one or more classes of the further group of classes are used by the learning module if the corresponding tokens assigned to the collection class are from one of the data records in a Combination with one or more of the additional triggers are included and the corresponding additional triggers trigger a corresponding assignment to the one or more classes of the further group of classes in accordance with the corresponding additional trigger definition.
  • the method for adding additional trigger definitions can be carried out repeatedly following a recursive scheme.
  • the trigger definitions to be supplemented for each recursion stage each include supplements to a trigger definition of a preceding recursion stage, so that the recursive supplements form tree structures which each include one of the predetermined trigger definitions as the root node.
  • FIG. 18 shows a flow diagram of an embodiment of an exemplary method for correcting trigger definitions in blocks.
  • a corrected trigger definition for replacing one of the stored trigger definitions of the learning module is received.
  • This corrected trigger definition is provided by an administrator, for example.
  • the corrected trigger definition is created by the learning module using a statistical model.
  • the corresponding stored trigger definition is replaced by the corrected trigger definition.
  • the tokens classified using the corresponding stored trigger definition are reclassified, the reclassification taking place using the corrected trigger definition. List of reference symbols
  • DS1, ..., DS3 data records K 1 , ..., K 6 nodes D 1 , ..., D 6 data

Landscapes

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

Abstract

Die Erfindung betrifft ein computerimplementiertes Verfahren zum Implementieren eines datenbankübergreifenden Index (112, 222) auf einem verteilten Datenbanksystem (170), welches eine Mehrzahl von eigenständigen Einzeldatenbanken (104, 204) umfasst. Die Einzeldatenbanken sind über ein Netzwerk (180) kommunikativ miteinander verbunden. Das Verfahren umfasst ein Anwenden einer Datenverarbeitungsfunktion einer Quelldatenbank (104) auf einen zusätzlichen Datensatz (108), wobei die Datenverarbeitungsfunktion zumindest eine Indexierung des zusätzlichen Datensatzes zum Speichern in der Quelldatenbank umfasst. Ferner wird ein aus dem Anwenden der Datenverarbeitungsfunktion resultierender Ergänzungsdatensatzes (130) erstellt, welcher die in dem Index der Quelldatenbank vorgenommenen Ergänzungen umfasst und zum Ergänzen zumindest eines weiteren Index (212) zumindest einer weiteren Einzeldatenbank des verteilten Datenbanksystems als Empfangsdatenbank (204) dient. Der erstellte Ergänzungsdatensatzes wird über das Netzwerk an die zweite Einzeldatenbank zur Integration in den weiteren Index der Empfangsdatenbank (204) gesendet.

Description

Datenbankübergreifender Index auf einem verteilten Datenbanksystem
B e s c h r e i b u n g
Die Erfindung betrifft ein Verfahren, ein Quellcomputersystem und ein verteiltes Da- tenbanksystem zum Implementieren eines datenbankübergreifenden Index auf ei- nem verteilten Datenbanksystem. Im Zuge der zunehmenden Digitalisierung, Automatisierung und Vernetzung in allen Lebens- und Arbeitsbereichen entstehen komplexe verteilte Systeme, deren techni- sches Zusammenspiel neue technische Herausforderungen aufwirft. So umfassen entsprechende verteilte Systeme im Allgemeinen beispielsweise keinen gemeinsa- men Speicher, was ein Ausführen von Datenverarbeitungsfunktionen erschwert. Der Erfindung liegt die Aufgabe zugrunde, ein verbessertes Verfahren zum Imple- mentieren eines Index auf einem verteilten Datenbanksystem zu schaffen.
Die der Erfindung zugrundeliegende Aufgabe wird jeweils mit den Merkmalen der unabhängigen Patentansprüche gelöst. Ausführungsformen der Erfindung sind in den abhängigen Patentansprüchen angegeben.
Ausführungsformen umfassen ein computerimplementiertes Verfahren zum Imple- mentieren eines datenbankübergreifenden Index auf einem verteilten Datenbank- system, welches eine Mehrzahl von eigenständigen Einzeldatenbanken umfasst, wobei die Einzeldatenbanken über ein Netzwerk kommunikativ miteinander verbun- den sind,
wobei die Einzeldatenbanken jeweils von einem Multi-Modell-Datenbankma- nagementsystem verwaltet werden, wobei die Einzeldatenbanken jeweils eine Mehrzahl datenbankindividueller Datensätze umfassen, welche in einem dokumen- tenorientierten ersten Datenmodell der jeweiligen Einzeldatenbank gespeichert sind, wobei die gespeicherten Datensätze jeweils ein oder mehreren Feldwerte umfas- sen, wobei die einzelnen Feldwerte der gespeicherten Datensätze jeweils in einem Feld gespeichert sind,
wobei die Einzeldatenbanken ferner jeweils einen durchsuchbaren ersten In- dex umfassen, welcher in einem zweiten Datenmodell der jeweiligen Einzeldaten- bank gespeichert ist, wobei der Index der jeweiligen Einzeldatenbank eine Mehrzahl von aus den Feldwerten der in dem dokumentenorientierten Datenmodell der ent- sprechenden Einzeldatenbank gespeicherten Datensätze erzeugten Token umfasst, wobei die Token in dem Index jeweils mit einem oder mehreren Zeigern auf ein oder mehrere der in dem dokumentenorientierten Datenmodell der entsprechenden Ein- zeldatenbank gespeicherten Datensätze verknüpft ist, aus deren Feldwerten das entsprechende Token erzeugt wurde,
wobei das Verfahren umfasst:
• Empfangen eines zusätzlichen Datensatzes durch eine erste Einzeldatenbank als Quelldatenbank zum Ergänzen von Datensätze der Quelldatenbank, • Speichern des zusätzlichen Datensatzes, welcher ein oder mehrere zusätzli- che Feldwerte umfasst, durch ein erstes Multi-Modell-Datenbankmanagement- system der Quelldatenbank in einem dokumentenorientierten ersten Datenmo- dell der Quelldatenbank,
• Anwenden einer Datenverarbeitungsfunktion der Quelldatenbank auf den zu- sätzlichen Datensatz, wobei die Datenverarbeitungsfunktion zumindest eine Indexierung des zusätzlichen Datensatzes zum Speichern in einem zweiten Datenmodell der Quelldatenbank umfasst, wobei die Indexierung umfasst: o Erzeugen von ein oder mehreren zusätzlichen Token aus den zusätzlichen Feldwerten durch die Quelldatenbank,
o Ergänzen des Index der Quelldatenbank durch das erste Multi-Modell-Da- tenbankmanagementsystem unter Verwendung der zusätzlichen Token und eines Zeigers auf den zusätzlichen in dem dokumentenorientierten Datenmodell der Quelldatenbank gespeicherten Datensatz,
• Erstellen eines aus dem Anwenden der Datenverarbeitungsfunktion resultie- renden Ergänzungsdatensatzes, welcher die in dem Index der Quelldatenbank vorgenommenen Ergänzungen umfasst, zum Ergänzen zumindest eines zwei- ten Index zumindest einer zweiten Einzeldatenbank des verteilten Datenbank- systems als Empfangsdatenbank,
• Senden des Ergänzungsdatensatzes über das Netzwerk an die zweite Einzel- datenbank zur Integration in den zweiten Index der Empfangsdatenbank.
Ausführungsformen können den Vorteil haben, dass durch das Erstellen und Sen- den des Ergänzungsdatensatzes der Index der Empfangsdatenbank an die Ände- rungen des Indexes der Quelldatenbank angepasst werden kann. Obwohl es sich also um ein verteiltes Datenbanksystem mit einer Mehrzahl eigenständiger Einzel- datenbanken handelt, kann so ein datenbankübergreifender Index implementiert werden. Sind alle Einzeldatenbanken dazu konfiguriert bei einem Empfang eines zusätzlichen Datensatzes als Quelldatenbank zu fungieren, kann so ein einheitlicher datenbankübergreifenden Index des verteilten Datenbanksystems bereitgestellt wer- den. Sind alle Einzeldatenbanken dazu konfiguriert als Empfangsdatenbanken ent- sprechende Ergänzungsdatensätze zu empfangen, kann auf allen Einzeldatenbanken ein identischer datenbankübergreifender Index des verteilten Datenbanksystems bereitgestellt werden. Dies erlaubt es lokal Datenverarbeitungs- funktionen unter Berücksichtigung aller in dem verteilten Datenbanksystem zur Ver- fügung gestellten Daten auszuführen. Zugleich erhalten aber nicht alle Einzeldaten- banken Zugriff auf alle vorliegenden Daten in dem verteilten Datenbanksystem zur Verfügung gestellten Daten. Vielmehr erfolgt der Zugriff lediglich auf den datenbank- übergreifenden Index. Der Index umfasst dabei aufgrund der Tokenisierung nicht die vollen Kontextinformationen, welche die zugrundeliegenden Datensätze umfas- sen. Diese vollen Kontextinformationen gehen jedoch nicht verloren, sondern ste- hen den Einzeldatenbanken jeweils individuell zur Verfügung. Durch den reduzier- ten sowie komprimierten Informationsgehalt des Index werden einerseits die Daten- mengen, welche zwischen den Einzeldatenbanken zum Implementieren des daten- bankübergreifenden Index auszutauschen sind, reduziert und zugleich werden die Daten der Datensätze geschützt. Dieser Schutz umfasst, dass jeweils nur die indivi- duelle eigenständigen Einzeldatenbanken Zugriff auf die in ihrem jeweiligen ersten Datenmodell gespeicherten Datensätze besitzen. Nur diese jeweilige Einzeldaten- bank hat mithin Zugang zum vollen Informationsgehalt der entsprechenden Datens- ätze. Die weiteren Einzeldatenbanken haben jedoch aufgrund der Zeiger Kenntnis davon, wo Datensätze gespeichert sind, aus welchen die Token de Index erzeugt wurden. Mithin können sie im Bedarfsfall eine Kopie der entsprechenden Datens- ätze anfordern. Die Entscheidung über eine Freigabe eines Datensatzes, d.h. ein Bereitstellen einer Kopie desselben, verbleibt jedoch jeweils bei der entsprechenden Einzeldatenbank, in derem ersten Datenmodell der Datensatz gespeichert ist. Die Verfügungsgewalt liegt somit jeweils bei der Einzeldatenbank. Daher sind die Ein- zeldatenbänke auch in dem Sinne eigenständig, dass jede der Einzeldatenbänke in ihrem ersten Datenmodell jeweils eine eigenständige Mehrzahl von Datensätzen umfasst, welche sich gegebenenfalls erheblich oder sogar vollständig von Datensät- zen unterscheiden kann, welche in den ersten Datenmodellen anderer Einzeldaten- bänke gespeichert sind. Insbesondere schützt der beschränkte Zugriff mithin vor un- berechtigten Zugriffen auf die daten durch Dritte. Ausführungsformen können den Vorteil haben, dass die Datenverarbeitungsfunktio- nen jeweils einzeldatenbank-individuell ausgeführt werden. So indexiert beispiels- weise jede der Einzeldatenbänke jeweils eigenständig Datensätze, welche sie emp- fängt. Im Ergebnis können die Datensätze somit parallel abgearbeitet werden. Somit kann das Verarbeiten der Daten parallelisiert und damit beschleunigt werden.
Ausführungsformen basieren somit auf einem verteilten System bzw. Datenbank- system, welches eine Mehrzahl von Knoten bzw. Computern umfasst, welche je- weils eine Einzeldatenbank zur Verfügung stellen und über Kommunikationsschnitt- stellen miteinander kommunizieren können. Nach Ausführungsformen wird auf dem verteilten System eine Software, d.h. die Datenverarbeitungsfunktionen, ausgeführt, welche eine Mehrzahl von Funktionalitäten, wie etwa Algorithmen, Formeln, Mo- delle, bereitstellen kann.
Nach Ausführungsformen kann sich die Datenverarbeitungsfunktion einem Indexie- ren empfangener Datensätze und einer Erstellung bzw. Verwaltung eines darauf ba- sierenden Index erschöpfen. Nach weiteren Ausführungsformen kann die Datenver- arbeitungsfunktion aber noch weitere Funktionalitäten umfassen, deren Anwendung sich in der resultierenden Struktur des Index wiederfindet. Somit lassen sich die von dem Index bereitgestellten Daten für vielfältige Zwecke optimieren.
Bei der Software kann es sich beispielsweise um eine Software handeln, welche auf den einzelnen Knoten des Systems, d.h. den Einzeldatenbänken, unabhängig von den anderen Knoten des verteilten Systems ausgeführt wird. Das verteilte System bezieht sich in diesem Fall darauf, dass jeder der Knoten des verteilten Systems je- weils eine vollständige Kopie des Index umfasst. Dabei indexiert der resultierende Index alle Einzeldatenbanken des verteilten Systems, d.h. es kann sich bei dem In- dex um einen kombinierten Gesamtindex handeln, welcher alle Teilindexe der ein- zelnen Konten des verteilten Systems umfasst.
Eine verteilte Anwendung bezeichnet ein komplexes Anwendungsprogramm, wel- che auf einem verteilten System, also auf mehreren Computern, abläuft und unter diesen Informationen austauscht. Beispielsweise erfolgt eine Verteilung der entspre- chenden Anwendung durch horizontale Schnitte im Softwareschichtenmodell, so dass die Aufgabe der Gesamtsoftware auf einzelne Softwarekomponenten in Form der einzelnen Schnitte aufgeteilt werden kann. Zur Erfüllung der Gesamtaufgabe ist in diesem Fall eine Mitwirkung aller Komponenten der Anwendung erforderlich, wel- che zu diesem Zweck untereinander kommunizieren. Für einen Client ist die ver- teilte Anwendung zumeist transparent, d.h. die verteilte Anwendung erscheint als eine einheitliche Anwendung.
Nach Ausführungsformen führt jede Einzeldatenbank eine Datenverarbeitungsfunk- tion aus. Hierbei kann es sich bei allen Einzeldatenbanken um die gleiche Datenver- arbeitungsfunktion handeln, welche mithin parallelisiert wird, oder es kann sich um einzeldatenbank-individuelle Datenverarbeitungsfunktionen handeln, deren Ausfüh- rung sich ergänzt. Beispielsweise kann sich die Indexerstellung unterschiedlicher Einzeldatenbanken dahingehend unterscheiden, welche Granularität die in dem In- dex ergänzten Token aufweisen. Bei Sensormesswerten können beispielweise die exakten Messwerte in dem Index ergänzt werden, es kann ein gerundeter Messwert oder es können Zuordnungen zu einem Werteintervall ergänzt werden. Flandelt es sich um Werte unterschiedlicher Sensoren, können an diese unterschiedliche Anfor- derungen bestehen, welche mittels einzeldatenbank-individueller Datenverarbei- tungsfunktionen implementiert werden können.
Unter einem verteilten System wird eine Mehrzahl interagierender Prozesse bzw. eine Mehrzahl von Prozesse ausführenden interagierenden Prozessoren verstan- den, welche über keinen gemeinsamen Speicher verfügen, sondern vielmehr über Nachrichten miteinander kommunizieren. Ein verteiltes System ermöglicht somit ei- nen Zusammenschluss unabhängiger Computer bzw. Einzeldatenbanken, welche sich für den jeweiligen Nutzer jeweils als ein einziges System präsentieren. Im vor- liegenden Fall sieht der jeweilige Nutzer beispielsweise einen datenbankübergrei- fenden Index. Erst wenn auf Datensätze direkt zugegriffen werden soll, welche sich in einem Datenmodell einer anderen Einzeldatenbank gespeichert sind, kann für den Nutzer ersichtlich werden, dass es sich nicht um ein einziges System sondern vielmehr tatsächlich um ein verteiltes System handelt.
Ausführungsformen können den Vorteil haben, dass auf jedem der Knoten bzw. auf jeder der Einzeldatenbänke jeweils die Funktionalität des vollständigen Index ge- nutzt werden kann, ohne dass die entsprechenden Koten alle Datensätze des ge- samten verteilten Datenbanksystems umfassen. Dadurch kann auf den jeweiligen Knoten ein Overhead für den Betrieb und die Speicherung der Datensätze restli- chen Knoten bzw. Einzeldatenbänke vermieden werden.
Ausführungsformen können den Vorteil haben, dass an keinem Ort eine vollstän- dige zentrale Speicherung aller Daten bzw. ein Zusammenführen aller Datenbanken notwendig ist, damit auf die Gesamtheit der Informationen aller Indexe aller Daten- banken zugegriffen werden kann und diese ausgewertet werden können. Somit lässt sich vermeiden, dass von einer zentralen Instanz alle Daten gesammelt wer- den, welche damit Zugriff auf alle Daten gelangen könnte. Insbesondere lassen sich damit verbundene Sicherheitsrisiken vermeiden bzw. minimieren.
Ausführungsformen können den Vorteil haben, dass Daten, welche von einem Kno- ten in dem verteilten Netzwerk erfasst werden, direkt mit einem Besitzer bzw. einer Identität verknüpft werden. So werden die empfangenen Datensätze beispielsweise jeweils direkt der empfangenen Einzeldatenbank oder einem Nutzer der entspre- chenden Einzeldatenbank als Eigner bzw. Besitzer zugeordnet.
Ausführungsformen können den Vorteil haben, dass sie es ermöglichen gezielt Funktionalitäten einer Softwarekomponente auf einzelnen Netzwerkknoten in einem verteilten System zu betreiben. Damit kann der Speicher- und Rechenbedarf auf den betreffenden Knoten minimiert werden, während die gewünschte Funktionalität betrieben wird. Dies ermöglicht es auch verhältnismäßig leistungsschwachen, z.B. im Verhältnis zu weiteren Knoten des verteilten Netzwerks, lokal vor Ort Funktionali- täten auszuführen. Ausführungsformen können den Vorteil haben, dass sie eine Implementierung eines Edge-Computing-Systems bereitstellen.
Edge Computing bezeichnet eine dezentrale Datenverarbeitung am Rand eines Netzwerks, der sogenannten Edge. Das Edge Computing stellt einen Gegensatz zum Cloud Computing dar, bei welchem Computer-Anwendungen, Daten und Dienste zentral, d.h. von zentralen Netzwerkknotennoten, einer Mehrzahl von de- zentralen Netzwerkknoten zur Nutzung bereitgestellt werden.
Demgegenüber ist das Edge Computing darauf ausgerichtet, Computer-Anwendun- gen, Daten und Dienste möglichst vor Ort lokal oder zumindest in der Nähe zu ver- arbeiten. Dies kann den Vorteil haben, dass Datenströme ressourcenschonend auf lokale Netzwerkbereich begrenzen lassen. Hierbei können insbesondere Ressour- cen verwendet werden, welche nicht permanent mit einem Netzwerk verbunden sind, insbesondere mobile Computersysteme, z.B. Controller, Notebooks, Smart- phones, Tabletcomputer und Sensoren. Beim Edge Computing können unterschied- liche Verfahren und Strukturen Anwendung, wie etwa Sensornetze, eine mobile Da- tenerfassung, eine mobile Signaturanalyse und/oder eine Peer-to-Peer- sowie Ad- hoc-Vernetzung. Edge Computing kann den Vorteilhaben, dass es als Architektur- konzept für das Internet der Dinge (loT) verwendet lässt, welches eine Verknüpfung eindeutig identifizierbarer physischer Objekte, d.h.„things“, mit einer virtuellen Re- präsentation bzw. Identität in einer Netzwerkstruktur, z.B. einer„Internet“ -ähnlichen Struktur, herstellt.
Dienste, welche im Zuge des Edge Computing bereitgestellt werden, können den Vorteil haben, dass sich das zu übertragende Datenvolumen und damit der Daten- austausch ebenso wie die Übertragungsstrecken Signifikat reduzieren lassen, wodurch sich Übertragungskosten und Wartezeiten verringern lassen. Im Ergebnis kann so die Servicequalität insgesamt verbessert werden. Beim Edge Computing sind zentrale Rechenzentren nicht oder höchsten in geringer Anzahl notwendig, wodurch sich Flaschenhalseffekte an solchen Rechenzentren für den Datentransfer vermeiden lassen ebenso wie damit verbundene potentielle Fehlerquellen. Indem verschlüsselte Dateien näher an den jeweiligen Datenquellen und/oder Verschlüs- selungsinstanzen verarbeitet werden, lässt sich zudem die Sicherheit der von Daten innerhalb des verteilten Systems erhöhen. Insbesondere können dadurch potentielle Sicherheitsgefahren wie etwa Viren, verfälschte Daten und/oder Hackerangriffe frühzeitig erkannt und wirksam abgewehrt werden. Zudem erweitert die Fähigkeit zur Virtualisierung die Skalierbarkeit innerhalb des Systems, d.h. die Anzahl der Edge-Geräte im Netzwerk lässt sich problemlos steigern. Schließlich können unter Verwendung des Edge Computings infolge der schnelleren Datenverarbeitung Echt- zeit-Anforderungen im Internet der Dinge besser unterstützt als dies im Zuge des Cloud Computings im Allgemeinen möglich ist.
Nutzer umgeben sich im Alltag in immer höherem Maße mit elektronischen Geräten, welche Computerfunktionalität und -konnektivität aufweisen. Ein Trend ist die zu- nehmende Verbreitung von Wearables, d.h. Computersystemen, die während der Anwendung am Körper des Nutzers angeordnet sind. Ein weiterer Trend ist das Er- setzen von Gegenständen des Alltags durch„intelligente Gegenstände“ (auch „smart devices“ genannt), welche informationstechnisch aufgerüstete und dazu kon- figuriert sind selbst Informationen zu verarbeiten. Diese intelligenten Gegenstände sind mit datenverarbeitender Hardware ausgerüstet, wie etwa einem eingebauten Mikrocontroller, Kommunikationsschnittstellen und/oder Sensoren, sodass sie Daten erfassen, speichern und/oder untereinander austauschen können. Ein Schlagwort für diese Entwicklung ist beispielsweise das sogenannte Internet der Dinge (abge- kürzt auch loT von„internet of things“).
Beispielsweise wird eine Mehrzahl von Datenerfassungsvorrichtungen bereitgestellt, welche in dem verteilten Datenbanksystem angeordnet sind, lokal Daten erfassen oder erzeugen und diese Daten bzw. darauf basierende Ergänzungsdatensätze je- weils mittels einer Kommunikationsschnittstelle über das Netzwerk an ein oder meh- rere andere Knoten übertragen. Durch die Reduktion der Software auf Ihre Kernfunktionalitäten können Speicherbe- darf und Rechenkapazität eingespart werden, so dass die entsprechende Software beispielsweise in loT-Sensoren effektiv und effizient eingesetzt werden kann.
Durch eine Verknüpfung der Daten mit jeweils einem Besitzer bzw. mit einer Identi- tät, kann das Sicherheitsniveau der Daten gehoben, da eine nachträgliche Manipu- lation der Daten durch Unberechtigte ausgeschlossen werden kann.
Durch die Verwendung von gezielten Funktionalitäten einer Softwarekomponente, können lokal auf ressourcenbeschränkten Knoten in einem verteilten System Funkti- onalitäten ausgeführt werden, für welche ansonsten die gesamte Software notwen- dig wäre.
Ausführungsformen können den Vorteil haben, dass sie ein vorteilhaftes verteiltes Datenbanksystem für das Internet der Dinge bereitstellen können.
Nach Ausführungsformen umfasst das Ergänzen des Index:
• Abgleichen der zusätzlichen Token mit dem Index der Quelldatenbank,
• falls eines der zusätzlichen Token nicht von dem Index der Quelldatenbank umfasst ist, Ergänzen des entsprechenden zusätzlichen Tokens in dem Index der Quelldatenbank und Verknüpfen des entsprechenden zusätzlichen Tokens in dem Index mit dem Zeiger auf den zusätzlichen in dem dokumentenorien- tierten Datenmodell der Quelldatenbank gespeicherten Datensatz,
• falls eines der zusätzlichen Token von dem Index der Quelldatenbank umfasst ist, Verknüpfen des entsprechenden zusätzlichen Tokens in dem Index der Quelldatenbank mit dem Zeiger auf den zusätzlichen in dem dokumentenori- entierten Datenmodell der Quelldatenbank gespeicherten Datensatz.
Ausführungsformen können den Vorteil haben, dass Daten aus zusätzlichen Da- tensätze effizient in die bestehende Einzeldatenbank und insbesondere in den Index eingefügt werden können. Die unter Verwendung des zusätzlichen Datensatzes er- zeugten Token werden mit dem Index abgeglichen. Alle Token, welche der Index (noch) nicht umfasst, werden in dem Index als zusätzliche Token ergänzt. Ferner werden die zusätzlichen Token jeweils mit dem Zeiger auf den zusätzlichen Daten- satz verknüpft. Somit kann auch bei einer Übertragung der entsprechenden In- dexstrukturen zur Ergänzung eines anderen Index einer anderen Einzeldatenbank anhand der Zeiger nachvollzogen werden, welche Einzeldatenbank die zugrundelie- genden Daten bzw. Datensätze umfasst.
Für solche Token des zusätzlichen Datensatzes, welche der Index bereits umfasst, wird in dem Index jeweils der Zeiger auf den zusätzlichen Datensatz ergänzt.
Ausführungsformen können den Vorteil haben, dass stets sichergestellt werden kann, dass der Index alle von den Datensätzen der Datenbank umfassten Token aufweist oder zumindest berücksichtigt.
Nach Ausführungsformen wird der Ergänzungsdatensatz von der Quelldatenbank über das Netzwerk an eine vordefinierte erste Gruppe von ein oder mehreren Ein- zeldatenbanken der Mehrzahl von Einzeldatenbank als Empfangsdatenbanken ge- sendet, welche die zweite Einzeldatenbank umfasst. Ausführungsformen können den Vorteil haben, dass für vordefinierte erste Gruppe sichergestellt werden kann, dass deren Mitglieder jeweils über den vollständigen datenbankübergreifenden In- dex verfügen. Dies kann beispielsweise in einem asymmetrischen System vorteil- haft sein, in welchem für ein oder mehrere der Einzeldatenbanken keine Notwendig- keit eines Bereitstellens eines vollständigen Index besteht. Dies kann etwa der Fall sein, falls auf diesen Datenbanken keine oder nur selten lokale Suchen ausgeführt werden. In diesem Fall dient die entsprechende Einzeldatenbank in erster Linie als Datenspeicher und zur Parallelisierung der Indexerstellung.
Nach Ausführungsformen wird der Ergänzungsdatensatz von der Quelldatenbank über das Netzwerk an alle weiteren von der Mehrzahl von Einzeldatenbanken um- fassten Einzeldatenbanken als Empfangsdatenbanken gesendet wird. Ausführungs- formen können den Vorteil haben, dass auf allen Einzeldatenbanken jeweils ein da- tenbankübergreifender Index implementiert werden kann. Nach Ausführungsformen ist eine vordefinierte zweite Gruppe von mehreren Einzel- datenbanken der Mehrzahl von Einzeldatenbank dazu konfiguriert, bei Empfang zu- sätzlicher Datensätze jeweils als eine Quelldatenbank zu fungieren. Nach Ausfüh- rungsformen sind alle Einzeldatenbanken der Mehrzahl von Einzeldatenbanken dazu konfiguriert, bei Empfang zusätzlicher Datensätze jeweils als eine Quelldaten- bank zu fungieren. Je nachdem wie viele der Einzeldatenbänke auch als Quellda- tenbänke konfiguriert sind können unterschiedliche Grade an Vereinheitlichung der individuellen Indexe der Einzeldatenbänke erzielt werden.
Nach Ausführungsformen ist der Quelldatenbank ein Sensor zugeordnet und der zu- sätzliche Datensatz umfasst von dem Sensor erfasste Sensordaten. Ausführungs- formen können den Vorteil habe, dass die Sensordaten direkt nach ihrer Erfassung indexiert werden. Nach Ausführungsformen ist jeder Einzeldatenbank der Mehrzahl von Einzeldatenbanken jeweils ein oder mehrere Sensoren zugeordnet sind, von welchen die jeweilige Einzeldatenbank jeweils erfasste Sensordaten in Form zusätz- licher Datensätze empfängt.
Nach Ausführungsformen umfasst die Datenverarbeitungsfunktion ferner ein Nor- malisieren der zusätzlichen Token im Zuge des Ergänzens des Index der Quellda- tenbank. Nach Ausführungsformen erfüllt das Normalisieren die fünfte und/oder sechste Normalform. Ausführungsformen können den Vorteil haben, dass Redun- danzen vermieden werden können.
Nach Ausführungsformen können die Token in Form von Relationen oder äquiva- lenten Strukturen gespeichert sein. Unter einer Relation wird hier im Sinn der relati- onalen Datenbanktheorie eine Menge von Tupel. Ein Tupel ist eine Menge von Attri- butwerten. Ein Attribut bezeichnet einen Datentyp bzw. eine ein oder mehreren Da- ten zugeordnete Eigenschaft. Dabei bestimmt die Anzahl der Attribute den Grad, die Anzahl der Tupel die Kardinalität einer Relation.
Unter einer Normalisierung, insbesondere unter einer Normalisierung eines relatio- nales Datenmodells, wird eine Aufteilung von Attributen in eine Mehrzahl von Relationen gemäß einer Normalisierungsregeln verstanden, sodass Redundanzen reduziert bzw. minimiert werden. Ein relationales Datenmodell lässt sich beispiels- weise in tabellenartigen Datenstrukturen implementieren, in denen die Relationen in Form von Tabellen, die Attribute in Form von Tabellenspalten und die Tupel in Form von Tabellenzeilen realisiert sind.
Datenredundanzen haben die Gefahr, dass es bei Änderungen von Daten, welche mehrfach umfasst sind, zu Inkonsistenzen kommen kann und Anomalien auftreten. Ferner steigt durch Redundanzen unnötiger Weise der Speicherplatzbedarf. Durch eine Normalisierung können solche Redundanzen verringert bzw. minimiert werden. Ein relationales Datenmodell kann beispielsweise in eine Normalform gebracht wer- den, indem die Relationen des Datenschemas fortschreitend anhand der für die ent- sprechende Normalform geltenden funktionalen Abhängigkeiten in einfachere Rela- tionen zerlegt.
Es können beispielsweise folgende Normalformen unterschieden werden: 1 . Nor- malform (1 NF), 2. Normalform (2NF), 3. Normalform (3NF), Boyce-Codd-Normal- form (BCNF), 4. Normalform (4NF), 5. Normalform (5NF), 6. Normalform (6NF).
Die Normalisierungskriterien nehmen dabei von Normalform zu Normalform zu und umfassen jeweils die Normalisierungskriterien der vorhergehenden Normalformen, d.h.
Eine Relation ist in der ersten Normalform, falls jedes Attribut der Relation einen atomaren Wertebereich besitzt und die Relation frei von Wiederholungsgruppen ist. Unter atomar wird hier ein Ausschluss von zusammengesetzten, mengenwertigen oder geschachtelten Wertebereichen für die Attribute, d.h. relationenwertigen Attri- butwertebereichen, verstanden. Eine Freiheit von Wiederholungsgruppen erfordert es, dass Attribute, die gleiche bzw. gleichartige Information enthalten, in unter- schiedliche Relationen ausgelagert werden.
Eine Relation ist in der zweiten Normalform, wenn sie die Anforderungen der ersten Normalform erfüllt und kein Nichtprimärattribut funktional von einer echten Teilmenge eines Schlüsselkandidaten abhängt. Ein Nichtprimärattribut ist ein Attri- but, welches nicht Teil eines Schlüsselkandidaten ist. Das bedeutet, dass jedes Nichtprimärattribut jeweils von allen ganzen Schlüsseln abhängig und nicht nur von einem Teil eines Schlüssels. Relationen in der ersten Normalform, deren Schlüssel- kandidaten nicht zusammengesetzt sind, sondern aus jeweils einem einzelnen Attri- but bestehen, erfüllen mithin automatisch die zweite Normalform. Unter einem Schlüsselkandidaten wird hierbei eine minimale Menge von Attributen verstanden, welche die Tupel einer Relation eindeutig identifiziert.
Eine Relation ist in der dritten Normalform, wenn sie die Anforderungen der zweiten Normalform erfüllt und kein Nichtschlüsselattribut von einem Schlüsselkandidaten transitiv abhängt. Ein Attribut ist von einem Schlüsselkandidaten transitiv abhängig, wenn das entsprechende Attribut von dem entsprechenden Schlüsselkandidaten über ein weiteres Attribut abhängig ist.
Eine Relation ist in der Boyce-Codd-Normalform, wenn sie die Anforderungen der dritten Normalform erfüllt und jede Determinante ein Superschlüssel ist. Unter einer Determinante wird hier eine Attributmenge verstanden, von welcher andere Attribute funktional abhängen sind. Eine Determinante beschreibt somit die Abhängigkeit zwi- schen Attributen einer Relation und legt fest, welche Attributmengen den Wert der übrigen Attribute bestimmen. Ein Superschlüssel ist eine Menge von Attributen in ei- ner Relation, welche die Tupel in dieser Relation eindeutig identifizieren. Mithin um- fassen die Attribute dieser Menge bei paarweise ausgewählten Tupeln immer unter- schiedliche Werte. Schlüsselkandidat ist mithin eine minimale Teilmenge der Attri- bute eines Superschlüssels, welche die Identifizierung der Tupel ermöglicht.
Eine Relation ist in der vierten Normalform, wenn sie die Anforderungen der Boyce- Codd-Normalform erfüllt und keine nichttrivialen mehrwertigen Abhängigkeiten um- fasst.
Eine Relation ist in der fünften Normalform, wenn sie die Anforderungen der vierten Normalform erfüllt und keine mehrwertigen Abhängigkeiten umfasst, die voneinander abhängig sind. Die fünfte Normalform liegt somit vor, falls jeder nichttri- viale Verbund-Abhängigkeit durch die Schlüsselkandidaten impliziert ist. Eine Ver- bund-Abhängigkeit ist durch die Schlüsselkandidaten der Ausgangsrelation impli- ziert, wenn jede Relation der Menge von Relationen ein Superschlüssel der Aus- gangsrelation ist.
Eine Relation ist in der sechsten Normalform, wenn sie die Anforderungen der fünf- ten Normalform erfüllt und keine nichttrivialen Verbund-Abhängigkeiten umfasst.
Eine Relation genügt einer Verbund-Abhängigkeit (join dependency) von einer Mehrzahl von Relationen, falls sich die Relation als Ausgangsrelation verlustlos in die entsprechende Menge von Relationen zerlegen lässt. Die Verbund-Abhängigkeit ist trivial, falls eine der Relationen der Menge von Relationen alle Attribute der Aus- gangsrelation aufweist.
Nach Ausführungsformen umfasst die Datenverarbeitungsfunktion ferner ein Zuwei- sen von Rechten zum Verwalten und/oder Verarbeiten der Daten des zusätzlichen Datensatzes. Insbesondere kann dem zusätzlichen Datensatz in diesem Zuge direkt ein Besitzer zugewiesen werden. Dieser Besitzer kann beispielswiese zugleich mit bestimmten Zugriffsrechten versehen werden, welche ihm ein Verwalten und/oder Verarbeiten der Daten ermöglicht. Nach Ausführungsformen weist das erste Multi- Modell-Datenbankmanagementsystem einer der Quelldatenbank zugeordneten ers- ten Entität ein Eigner-Recht bezüglich des zusätzlichen Datensatz und/oder des Er- gänzungsdatensatzes zu. Somit wird die entsprechende Entität als Eigner bzw. Be- sitzer des zusätzlichen Datensatz und/oder des Ergänzungsdatensatzes festgelegt.
Nach Ausführungsformen werden die Daten direkt durch den die entsprechenden Daten erfassenden bzw. erzeugenden Knoten mit einem Besitzer verknüpft bzw. ei- nem Besitzer zugeordnet.
Nach Ausführungsformen werden mit den erfassten oder erzeugten Daten auf den ressourcenbeschränkten Knoten des verteilten Systems, z.B. loT-Sensoren, Be- rechtigungsketten mit den erhobenen Daten gebildet. Die Berechtigungsketten definieren Zugriffsrechte für eine Reihe von Entitäten. Nach Ausführungsformen sind das auf diesen Systemen keine zentrale Datenbank mit Berechtigungskonzept notwendig, da die Funktionalitäten der Berechtigungsketten direkt auf den einzelnen Knoten implementiert werden. Mithin können selbst auf ressourcenbeschränkten Knoten Daten effektiv und effizient mit einem Besitzer verknüpft werden.
Ein Verknüpfen der Daten direkt bei der Datenerzeugung auf den einzelnen res- sourcenbeschränkten Knoten des verteilten Systems mit einem Besitzer, kann den Vorteil haben, die Datensicherheit zu erhöhen und Transparenz über die tatsächli- chen Besitzer der jeweiligen Daten zu gewährleiten.
Nach Ausführungsformen handelt es sich bei der ersten Entität um einen ersten Nutzer der Quelldatenbank oder ein erstes der Quelldatenbank zugeordnetes Com- putersystem. Handelt es sich um ein zugeordnetes, z.B. die Quelldatenbank umfas- sendes Computersystem, kann dies etwa bei Anwendungen im Bereich des Inter- nets der Dinge von Vorteil sein, da jeder durcheine entsprechende Sensorik erfass- ter Datensatz automatisch im Zuge der Einpflege in die entsprechende Einzeldaten- bank einen eindeutigen Besitzer zugewiesen bekommt.
Nach Ausführungsformen werden als Bestandteil des zusätzlichen Datensatz und/o- der des Ergänzungsdatensatzes Zugriffsberechtigungsnachweise in der Quelldaten- bank gespeichert, wobei die Zugriffsberechtigungsnachweise ein oder mehrere der folgenden Zugriffsberechtigungsnachweise umfassen:
• ein Lesezugriffs-Berechtigungsnachweis, welcher einen lesenden Zugriff auf den Inhalt eines Datensatzes ermöglicht;
• ein Schreibzugriffs- Berechtigungsnachweis, welcher modifizierenden Zugriff auf den Inhalt eines Datensatzes ermöglicht;
• ein Indexzugriffs- Berechtigungsnachweis, welcher Kenntnis der Existenz des Datensatzes in der den Datensatz beinhaltenden Datenbank und einen le- senden Zugriff auf Metadaten des Datensatzes ermöglicht. Zugriffs-Berechtigungsnachweise können als Zugriffs-Zertifikate ausgebildet sein. Nach Ausführungsformen handelt es sich bei den Zugriffs-Zertifikaten um reine Zah- lenwerte, nicht um komplexe x509 Zertifikate. Metadaten bezüglich der Gültigkeit der Zertifikate und bezüglich anderer Aspekte können getrennt von dem eigentli- chen Zugriffs-Zertifikat in einer zusätzlichen ID-Datenbank eines Zugriffsverwal- tungssystems der entsprechenden Einzeldatenbank gespeichert sein. Vorzugsweise enthält jeder Datensatz in seinen entsprechenden Feldern sämtliche Zugriffs-Zertifi- kate des diesen Datensatz erstellenden Nutzers bzw. der Entität, welcher dieser Da- tensatz inertial zugeordnet wird. Wird beispielsweise ein Datensatz DS von Nutzer U1 erstellt und der Nutzer U1 hat gemäß dem Inhalt der ID-Datenbank genau 3 Ty- pen von Zertifikaten (ein Lesezugriffs-Zertifikat„U1 .Z-Zert[R]“, ein Schreibzugriffs- Zertifikat„U1 .Z-Zert[W]“ und ein Indexzugriffs-Zertifikat„U1 .Z-Zert[S]“), so werden Kopien genau dieser 3 Zugriffs-Zertifikate im Zuge der Speicherung des Datensat- zes DS aus der ID-Datenbank erstellt und die in die entsprechenden Felder des Da- tensatzes DS gespeichert. Bei dem Nutzer U1 kann es sich auch um die entspre- chende Einzeldatenbank selbst bzw. einer dieser Einzeldatenbank zugeordneten Identität handeln. Als Authentifizierungsnachweis bzw. Identitätsnachweis kann bei- spielsweise ein geheimer Schlüssel eines der entsprechenden Einzeldatenbank zu- geordneten asymmetrischen kryptographischen Schlüsselpaars dienen. Alternativ kann die Identität auch von technischen Charakteristika, wie etwa bestimmten Spannungs- oder Strommustern der entsprechenden Einzeldatenbank bzw. eines die entsprechende Einzeldatenbank umfassenden Computersystems handeln ver- gleichbar mit biometrischen Merkmalen im Falle lebender Personen.
Nach Ausführungsformen weisen die Einzeldatenbank und/oder Komponenten der- selben Mittel zum Schutz gegen unbefugte Manipulationen auf. Durch die Mittel zum Schutz gegen unbefugte Manipulationen wird durch technische Maßnahmen die Vertrauenswürdigkeit der Einzeldatenbank bzw. von deren Steuerelementen, wie etwa Prozessoren, das heißt seine Funktion als„Vertrauensanker“, gewährleistet. Beispielsweise umfasst die Einzeldatenbank Komponenten bzw. ist auf Komponen- ten implementiert, welche von einer vertrauenswürdigen Institution, wie z.B. durch ein Trust-Center (Trust Service Provider), konfiguriert und mit dem benötigten kryptografischen Schlüsselmaterial versehen wurden. Durch die Mittel zum Schutz gegen unbefugte Manipulationen kann sichergestellt werden, dass sicherheitsrele- vante Funktionalitäten der Einzeldatenbank bzw. des diese Einzeldatenbank umfas- senden Computersystems nicht unerlaubter Weise modifiziert werden.
Nach einer Ausführungsform der Erfindung sind die Mittel zum Schutz gegen unbe- fugte Manipulationen als ein so genanntes Tamper Proof Module oder Trusted Plat- form Module (TPM) ausgebildet, welche auch als Tamper Resistant Module (TRM) bezeichnet werden. Beispielsweise sind zumindest Teile der Einzeldatenbank bzw. des die Einzeldatenbank umfassenden Computersystems signiert, wie z.B. Pro- gram mkomponenten und/oder Hardwarekomponenten, die eine digitale Signatur tragen können. Insbesondere können ein Betriebssystem, Multi-Modell-Datenbank- managementsystem, eine Konfigurationsdatei und/oder ein Massenspeichermedium digital signiert sein. Vor einer Nutzung der Einzeldatenbank prüft das TRM dann, ob die Signatur bzw. die Signaturen, valide sind. Die Prüfung kann sich dabei auch auf die oben erwähnten technischen Charakteristika stützen. Wenn eine der Signaturen nicht valide ist, sperrt das TRM die Nutzung der Einzeldatenbank. Ein TPM umfasst beispielsweise Mikrokontroller nach der TCG-Spezifikation wie in ISO/IEC 1 1889, der einen Computer oder ähnliche Geräte um grundlegende Sicherheitsfunktionen erweitert.
Nach einer Ausführungsform der Erfindung beinhalten die Mittel zum Schutz gegen unbefugte Manipulationen mechanische Mittel, die z.B. das Öffnen von Komponen- ten und/oder des gesamten Computersystems verhindern sollen, oder die bei dem Versuch eines Eingriffs dazu führen, dass die entsprechenden Komponenten un- brauchbar werden, beispielsweise indem ein Datenverlust und/oder eine Datensper- rung eintritt. Beispielsweise können hierzu sicherheitskritische Teile in Epoxidharz eingegossen sein, wobei ein Versuch, eine betreffende Komponente aus dem Epo- xidharz zu entfernen, zu einer unvermeidlichen Zerstörung dieser Komponente führt. Insbesondere können die Mittel zum Schutz gegen unbefugte Manipulationen als ein so genanntes Hardware Security Modul (HSM) ausgebildet sein. Wenn nun der Nutzer U1 der ersten Einzeldatenbank einem anderen Nutzer U2 der- selben Einzeldatenbank oder einer weiteren Einzeldatenbank oder auch einer weite- ren Einzeldatenbank an sich Leserechte bezüglich des Datensatzes DS einräumt, bedeutet dies, dass in der ID-Datenbank des entsprechenden Zugriffsverwaltungs- system eine Verknüpfung bzw. Zuordnung dieses Lesezugriffs-Zertifikat
,,Z.Zert_U1 [R]“ des Nutzers U1 und des Nutzer-Zertifikats des Nutzers U2 gespei- chert wird, wodurch ein Ermächtigungskettenobjekte gebildet wird. Falls der Nutzer U2 nun zu einem späteren Zeitpunkt auf den Datensatz DS zugreifen will, sendet die Einzeldatenban, die den Datensatz DS beinhaltet, in Antwort auf die Zugriffsan- frage des Nutzers U2 automatisch eine Berechtigungsanfrage an die ID-Datenbank des Zugriffsverwaltungssystem. Diese Anfrage beinhaltet die in dem Datensatz DS gespeicherten Zugriffsrechte des Erstellers U1 . Die ID-Datenbank prüft daraufhin, ob ein dem Nutzer U2 zugeordnetes Nutzer-Zertifikat in der ID-Datenbank mit ein oder mehreren der in dem Datensatz DS gespeicherten Zugriffsrechten des Erstel- lers U1 verknüpft gespeichert ist. Nur falls dies der Fall ist, und falls der Nutzer U2 außerdem Eigner der Quelldatenbank ist, darf er auf den Datensatz zugreifen.
Nach Ausführungsformen umfasst das zumindest eine Zugriffs-Zertifikat, dass vor- zugsweise als Bestandteil des erstellten Datensatzes gespeichert ist, mehrere Zu- griffs-Zertifikate für jeweils andere Zugriffsarten. Die mehreren Zugriffs-Zertifikate umfassen zum Beispiel ein Schreibzugriffs-Zertifikat Z.Zert_U1 [W] des erstellenden Nutzers und/oder ein Lesezugriffs-Zertifikat Z.Zert_U1 [R] des erstellenden Nutzers und/oder ein Indexzugriffs-Zertifikat Z.Zert_U1 [S] des erstellenden Nutzers.
Nach Ausführungsformen handelt es sich bei dem Zugriffsverwaltungssystem um ein„Standard“ Zugriffsverwaltungssystem, das üblicherweise auf einem Standard- computersystem installiert ist. Ein„Standard“ Zugriffsverwaltungssystem kann z.B. MySQL, PostGreSQL, Oracle, SAP Hana, etc. sein. Es ist jedoch auch möglich, dass andere Systeme, die zur strukturierten Speicherung und Abfrage von Daten ausgelegt sind, als Zugriffsverwaltungssystem verwendet werden, z.B. Mikrocontrol- ler, in deren Speicher die Datensätze, Zertifikate und Ermächtigungskettenobjekte sowie die hier beschriebene Programmlogik gespeichert sein kann. Nach Ausführungsformen handelt es sich bei einem Nutzer-Zertifikat zum Beispiel ein Zertifikat, das von einer Zertifizierungsstelle (certifying authority - CA) spezifisch für eine bestimmte Person herausgegeben wird. Das Nutzer-Zertifikat ist in eine von einer Zertifizierungsstelle herausgegebene Zertifikatskette prüfbar eingeordnet, es ist also beispielsweise bis zum Root-Zertifikat der Zertifizierungsstelle prüfbar. Dies kann vorteilhaft sein, da Zertifizierungsstellen als unabhängige Vertrauensgaranten auf breiter Basis bereits akzeptiert sind und bereits von vielen bestehenden techni- schen Systemen zur Prüfung der Authentizität bestimmter Nutzer und Nutzeraktio- nen verwendet werden.
Nach Ausführungsformen sind in einer ID-Datenbank des Zugriffsverwaltungssys- tem jeweils eine Mehrzahl von Nutzer-Zertifikaten und/oder eine Mehrzahl von Zu- griffs-Zertifikaten gespeichert. Außerdem beinhalten die ID-Datenbanken jeweils Zu- griffsermächtigungskettenobjekten.
Ein Ermächtigungskettenobjekt, genauer gesagt ein Zugriffsermächtigungskettenob- jekt, ist ein Datenobjekt, welches eines der Zugriffs-Zertifikate und ein oder mehrere der Nutzer-Zertifikate beinhaltet (und dadurch einander zuweist). Die Reihung der Nutzer-Zertifikate in dem Zugriffsermächtigungskettenobjekt gibt die Sequenz der Nutzer, die dieses Zugriffs-Zertifikat für jeweils andere Nutzer, deren Nutzer-Zertifi- kat in dem Zugriffsermächtigungskettenobjekt enthalten ist, ausgestellt haben, wie- der. Eine so erzeugte Berechtigungshierarchie umfasst eines der Zugriffsermächti- gungskettenobjekte.
Nach Ausführungsformen umfasst jede der Einzeldatenbanken jeweils eine entspre- chende ID-Datenbank, welche die Zugriffsberechtigungen auf die Datensätze und/o- der den Index der entsprechenden Einzeldatenbank verwaltet.
Nach Ausführungsformen sind die Einzeldatenbanken bzw. deren Datenmodelle frei von Zugriffsermächtigungskettenobjekten und beinhalten für jeden Datensatz nur die Zugriffs-Zertifikate, die dem Nutzer, welcher diesen Datensatz angelegt hat bzw. welchem dieser Datensatz zugeordnet ist, Zugriff auf diesen Datensatz gewähren.
Die Verknüpfung dieser Zugriffs-Rechte des Datensatzerzeugers mit ein oder meh- reren anderen Nutzern um diesen Zugriff auf den Datensatz zu gewähren ist nicht in der Einzeldatenbanken bzw. deren Datenmodelle gespeichert, sondern in der ID- Datenbank. Umgekehrt enthält die ID-Datenbank keine Referenz auf einzelne Da- tensätze der Einzeldatenbank bzw. deren Datenmodelle. Dies kann vorteilhaft sein, da die Größe und Komplexität der einzelnen Datensätze der Einzeldatenbanken bzw. deren Datenmodelle begrenzt und logisch von der Verwaltung der Zugriffs- rechte weitgehend entkoppelt wird. Die Größe der Datensätze wird also auch dadurch begrenzt, dass nicht die komplette Kette der Berechtigungsübertragungen als Bestandteil der Datensätze gespeichert wird. Insbesondere bei einer Mehrzahl kleiner Datensätze mit identischer Berechtigungsstruktur kann dies den von der Da- tenbank benötigten Speicherplatz erheblich reduzieren.
Nach Ausführungsformen beinhaltet die ID-Datenbank des Zugriffsverwaltungssys- tem einen privaten Signierschlüssel. Die Einzeldatenbank beinhaltet einen öffentli- chen Signaturprüfschlüssel, welcher zur Prüfung der mit dem Signierschlüssel er- stellten Signaturen ausgebildet ist. Im Zuge einer Zugriffsanfrage eines ersten Nut- zers auf einen Datensatz der Einzeldatenbank ermittelt das Zugriffsverwaltungssys- tem, ob dem Nutzer-Zertifikat in der ID-Datenbank eines oder mehrere Zugriffbe- rechtigungsnachweise, die in Kopie als Bestandteil des Datensatzes gespeichert sind, zugeordnet ist. Falls dies der Fall ist, wird dieser Zugriffsberechtigungsnach- weis mit dem Signierschlüssel der ID-Datenbank signiert und mit dem entsprechen- den Signaturprüfschlüssel der Einzeldatenbank geprüft. Der Berechtigungsnachweis wird in signierter Form an die Einzeldatenbank übermittelt. Die Einzeldatenbank prüft mittels des Signaturprüfschlüssels, ob die Signatur des Berechtigungsnachwei- ses valide ist, wobei der Aufbau der Datenbankverbindung und der Datensatzzugriff nur dann gestattet werden, wenn die Signatur valide ist. Beispielsweise wird eine zentrale ID-Datenbank für das gesamte verteilte Daten- banksystem bereitgestellt. Dies kann vorteilhaft sein, da es nicht erforderlich ist, da nicht jede Einzeldatenbank selbst mit Programlogik zur Zertifikatskettenprüfung aus- zustatten. Ganz allgemein kann durch das beschriebene Verfahren bzw. die be- schriebene Datenbankstruktur eine weitgehende Trennung der Datenhaltung (in Einzeldatenbanken) und der Verwaltung von Zugriffsrechten (in der ID-Datenbank) erzielt werden. Die ID-Datenbank enthält und/oder ist operativ gekoppelt an ein oder mehrere Programmmodule zum Beispiel zur Zertifikatskettenprüfung (zum Beispiel von Nutzer-Zertifikaten bis hin zum Root-Zertifikat von der das Nutzer-Zertifikat aus- stellenden Zertifizierungsstelle), zur Speicherung von Änderungen der Zuweisungen von Zertifikaten und Nutzern in einer Log-Datei sowie zur dynamischen Erstellung von signierten Berechtigungsnachweisen unter Berücksichtigung einer dokumentier- ten Chronologie der Übertragung von Rechten. Die individuellen Einzeldatenbanken verfügen dahingegen nach Ausführungsformen nur über Mittel zur Prüfung, ob für die Einzeldatenbank selbst bzw. für die darin enthaltenen Datensätze entspre- chende Berechtigungen vorliegen oder an diese operativ gekoppelt sind, wobei diese Mittel gegebenenfalls Mittel zur Signaturprüfung umfassen.
Nach einer Ausführungsform beinhaltet jeder der Datensätze in der Quelldatenbank ein oder mehrere Zugriffs-Zertifikate des den Datensatz erstellenden Nutzers bzw. einer Entität, welcher der entsprechende Datensatz zugeordnet ist. Den Zugriffs- Zertifikaten in der ID-Datenbank sind jeweils ein oder mehrere Nutzer-Zertifikate so zugeordnet, dass die chronologische Sequenz von Nutzern, die sich ein oder meh- rere der Zugriffsrechte des den Datensatz erstellenden Nutzers eingeräumt haben, jeweils in Form einer Hierarchie repräsentieren ist. Diese Zuordnung kann z.B. mit- tels Zugriffsermächtigungskettenobjekten erfolgen.
Unter einem„Zugriffsverwaltungssystem“ wird im Folgenden ein elektronisches Sys- tem zur Speicherung und Wiedergewinnung von Daten verstanden. Beispielsweise kann es sich bei dem Zugriffsverwaltungssystem um ein„klassisches Datenbank- managementsystem“ (DBMS) handeln (MySQL, PostgreSQL, Oracle, Hana, etc.).
Es ist aber auch möglich, dass die Daten in einem Mikrocontrollerspeicher gespeichert werden und von einem Applikationsprogramm oder einer Chipbasierten Programmlogik verwaltet werden, die als Zugriffsverwaltungssystem arbeitet und kein klassisches DBMS ist. Vorzugsweise werden die Daten in dem Zugriffsverwal- tungssystem widerspruchsfrei und dauerhaft gespeichert und verschieden Anwen- dungsprogrammen und Nutzern in bedarfsgerechter Form effizient zur Verfügung gestellt. Ein Zugriffsverwaltungssystem kann typischerweise ein oder mehrere Da- tenbanken beinhalten und die darin enthaltenen Datensätze verwalten.
Unter einer„ID-Datenbank“ wird im Folgenden eine Datenbank verstanden, welche nutzerbezogene Informationen wie zum Beispiel Nutzer-Zertifikate sowie den diesen Nutzern zugewiesenen Rechte in Form von weiteren Zertifikaten (Zugriffs-Zertifi- kate) enthält und verwaltet. In Abgrenzung zu den Einzeldatenbanken, die auch un- ter dem Begriff„Nutzdaten-Datenbanken“ zusammengefasst werden können und welche vorwiegend der Speicherung von Nutzdaten dienen, dient eine ID- Datenbank vorwiegend der Verwaltung der den Nutzern im Hinblick auf die Nutzda- ten zugewiesenen Eigner- und Zugriffsrechte.
Nach Ausführungsformen werden als Bestandteil des zusätzlichen Datensatzes und/oder des Ergänzungsdatensatzes für die erste Entität zumindest ein Indexzu- griffs-Berechtigungsnachweis gespeichert. Nach Ausführungsformen werden als Bestandteil des zusätzlichen Datensatzes und/oder des Ergänzungsdatensatzes für die erste Entität ein Lesezugriffs-Berechtigungsnachweis, ein Schreibzugriffs-Be- rechtigungsnachweis und ein Indexzugriffs-Berechtigungsnachweis gespeichert.
Nach Ausführungsformen wird ferner einer der Empfangsdatenbank zugeordneten zweiten Entität ein Indexzugriffs-Berechtigungsnachweis für den zusätzlichen Da- tensatz zugeordnet. Dies kann beispielsweise mittels eines zuvor beschriebenen Zugriffsermächtigungskettenobjekts erfolgen. Nach Ausführungsformen handelt es sich bei der zweiten Entität um einen zweiten Nutzer der Empfangsdatenbank oder ein zweites der Empfangsdaten zugeordnetes Computersystem. Nach Ausführungsformen ist eine Voraussetzung für das Senden des Ergänzungs- datensatzes an die Empfangsdatenbank eine erfolgreiche Prüfung, dass der zwei- ten Entität ein Indexzugriffs-Berechtigungsnachweis für den Ergänzungsdatensatz zugeordnet ist. Somit kann sichergestellt werden, dass die Empfangsdatenbank tat- sächlich dazu berechtigt ist auf entsprechende Indexinformationen, wie sie der Er- gänzungsdatensatz umfasst, zuzugreifen.
Nach Ausführungsformen umfasst die Datenverarbeitungsfunktion ferner ein Klassi- fizieren der aus dem zusätzlichen Datensatz erzeugten Token.
Nach Ausführungsformen umfasst die Quelldatenbank für das Klassifizieren ein vor- trainierten Lernmoduls zum maschinellen Lernen, wobei das vortrainierte Lernmodul eine Mehrzahl von vorbestimmten Trigger-Definitionen umfasst, welche Trigger für ein Zuordnen von Token zu Klassen einer ersten Gruppe von Klassen definieren, wobei erste Token in dem Index der Quelldatenbank, welche von einer der Trigger-Definitionen der Quelldatenbank als Trigger umfasst sind, jeweils der ent- sprechen Trigger-Definition zugeordnet sind, wobei zweite Token in dem Index der Quelldatenbank jeweils ein oder mehreren Klassen der ersten Gruppe von Klassen zugeordnet sind,
wobei das Klassifizieren umfasst:
• falls eines oder mehrere erste zusätzliche Token von einer der Trigger-Definiti- onen als Trigger umfasst sind, Identifizieren des entsprechenden Tokens als Trigger durch das Lernmodul,
• Verwenden der identifizierten Trigger zum Zuordnen von ein oder mehreren zweiten zusätzlichen Token zu ein oder mehreren Klassen der ersten Gruppe von Klassen durch das Lernmodul, falls die entsprechenden zweiten zusätzli- chen Token von dem zusätzliche Datensatz in einer Kombination mit ein oder mehreren der identifizierten Trigger gemäß einer der Trigger-Definitionen um- fasst sind, wobei die entsprechenden Trigger gemäß der entsprechenden Trig- ger-Definition eine entsprechende Klassenzuordnung triggern, wobei das Ergänzen des Index durch das erste Multi-Modell-Datenbankmana- gementsystem unter Verwendung der Klassenzuordnungen der zusätzlichen Token erfolgt.
Ausführungsformen können den Vorteil haben, dass es sich bei dem Lernmodul um ein vortrainiertes Lernmodul handelt. Das vortrainierte Lernmodul umfasst eine Mehrzahl inertial zur Verfügung gestellt bzw. festgelegt Trigger-Definitionen. Das Lernmodul ist dazu konfiguriert unter Verwendung dieser inertial festgelegten Trig- ger-Definitionen alle von der Datenbank bzw. dem Index umfassten Token zu klassi- fizieren. Ausführungsformen können den Vorteil haben, dass kein Zufall in den ent- scheidungs- bzw. Klassifizierungsprozess eingeht. Vielmehr beruht das Klassifizie- ren von Token auf den vorbestimmten Trigger-Definitionen und ist somit jederzeit nachvollziehbar. Auch wenn das Lernmodul beispielsweise auf Basis der Klassifizie- rung fortschreitet und im Zuge eines darauf beruhenden Lerntransfers weitere Mus- ter und Gesetzmäßigkeiten erlernt, so geht die zugrundeliegende Klassifizierung zu- rück auf die vorbestimmten Trigger-Definitionen.
Nach Ausführungsformen werden in Form der Klassifizierung Meta- und/oder Kon- textinformationen zu den klassifizierten Token bereitgestellt. Diese Meta- und/oder Kontextinformationen werden anhand der Trigger gemäß den Trigger-Definitionen identifiziert und den entsprechenden Token in Form der Klassenzuordnung zuge- ordnet. Nach Ausführungsformen kann das Lernmodul dazu konfiguriert sein, unter Verwendung dieser Meta- und/oder Kontextinformationen weitere Muster und Ge- setzmäßigkeiten zu erlernen.
Ausführungsformen können den Vorteil haben, dass die von der Quelldatenbank empfangenen Datensätze alle in ihrer ursprünglichen Form in dem dokumentenori- entierten Datenmodell abgespeichert werden. Hierdurch kann sichergestellt werden, dass der volle Informationsgehalt dieser Datensätze erhalten bleibt. Zusätzlich wer- den die von den in dem dokumentenorientierten Datenmodell abgespeicherten Da- tensätzen umfassten Daten in Form des Indexes bereitgestellt. Dieser Index um- fasst die entsprechenden Daten des dokumentenorientierten Datenmodells in Form von Token. Nach Ausführungsformen umfasst der Index alle von dem dokumenten- orientierten Datenmodell umfassten elementaren Datenelemente in Form von ele- mentaren Token. Nach Ausführungsformen umfasst der Index aus den Token abge- leitete Datenelemente. Nach weiteren Ausführungsformen umfasst der Index zu- sätzlich von dem dokumentenorientierten Datenmodell umfasste Kombinationen der elementaren Datenelemente in Form von Token-Kombinationen. Diese Token-Kom- binationen umfassen jeweils eine Kombination einer Mehrzahl von elementaren To- ken. Nach weiteren Ausführungsformen umfasst der Index Token-Kombinationen bis zu einer vorbestimmten Komplexität. Die Komplexität einer Token-Kombination ist beispielsweise definiert durch die Anzahl und/oder Art der von dieser umfassten elementaren Token.
Bei den von dem Index umfassten Token kann es sich beispielsweise um Trigger gemäß den vorbestimmten Trigger-Definitionen handeln. Ein entsprechendes Token wird, wenn es erstmals beispielsweise im Zuge der Verarbeitung eines zusätzlichen Datensatzes erzeugt wird, anhand einer der Trigger-Definitionen als Trigger identifi- ziert, dem Index hinzugefügt und der entsprechenden Trigger-Definition zugeordnet. Erkennt das Lernmodul dasselbe Token, welchen der Index als Trigger definiert, in- nerhalb eines weiteren Datensatzes wieder, so greift das Lernmodul auf die dem Triggern in dem Index zugeordnete Trigger-Definition zurück und ordnet der ent- sprechenden Trigger-Definition folgenden ein oder mehrere Token aus einem Kon- textumfeld des als Trigger gespeicherten Tokens in dem weiteren Datensatz ein o- der mehreren Klassen der ersten Gruppe von Klassen zu.
Ferner umfasst der Index eine Mehrzahl von Token, welche jeweils ein oder mehre- ren Klassen der ersten Gruppe von Klassen zugeordnet sind. Nach Ausführungsfor- men werden durch die Zuordnung zu den Klassen Meta- und/oder Kontextinformati- onen zu den entsprechenden Token bereitgestellt. Die entsprechenden Meta- und/oder Kontextinformationen können beispielsweise für eine Verarbeitung der ent- sprechenden Token und/oder der die entsprechenden Token umfassenden Datens- ätze in dem dokumentenorientierten Datenmodell verwendet werden. Beispiels- weise werden die entsprechenden Meta- und/oder Kontextinformationen im Zuge einer Suchanfrage zur Identifikation relevanter Token und/oder Datensätze verwen- det oder im Zuge eines den Index verwendenden weiteren Verfahrens zum maschi- nellen Lernen. So können unter Verwendung der entsprechenden Meta- und/oder Kontextinformationen im Zuge eines weiteren Lerntransfers zusätzliche Muster und Gesetzmäßigkeiten erlernt werden. Dieses weitere Verfahren zum maschinellen Lernen wird beispielsweise durch das die Trigger-Definitionen verwendende Lern- modul oder ein weitere Lernmodul ausgeführt. Beispielsweise handelt es sich bei dem weiteren Verfahren zum maschinellen Lernen um ein Kl-Verfahren, welches von einem Kl-Modul ausgeführt wird.
Nach Ausführungsformen sind verbleibende Token, welche weder den Trigger-Defi- nition noch ein oder mehreren Klassen der ersten Gruppe von Klassen zugeordnet sind, in dem Index der Quelldatenbank zum Kennzeichnen der entsprechenden ver- bleibenden Token als unbekannte Daten einer Auffangklasse zugeordnet, wobei die Zuordnung zu der Auffangklasse eine Zuordnung zu einer der Trigger-Definitionen ebenso wie eine Zuordnung zu einer der Klassen der ersten Gruppe von Klassen ausschließt,
wobei das Klassifizieren ferner umfasst:
• Zuordnen der verbleibenden zusätzlichen Token, für welche keine Zuordnung zu einer der Trigger-Definitionen und keine Klassenzuordnung aufgrund einer der Trigger-Definitionen erfolgt ist, zu der Auffangklasse.
Der Index umfasst in diesem Fall auch Token, welche unter keine der vorbestimm- ten Trigger-Definitionen fallen. Bei diesen Token handelt es sich weder um Trigger, noch lassen sie sich anhand der von den Trigger-Definitionen definierten Trigger Klassen zuordnen. Vielmehr handelt es sich bei diesen Token um unbekannte Da- ten, welche nicht zuordenbar sind und für welche damit Meta- bzw. Kontextinforma- tionen fehlen. Diese Token werden als unbekannte Daten einer Auffangklasse zuge- ordnet. Dabei schließt eine Zuordnung zu der Auffangklasse eine Zuordnung zu ei- ner der Trigger-Definitionen ebenso wie eine Zuordnung zu einer der Klassen der ersten Gruppen von Klassen aus. Ausführungsformen können den Vorteil haben, dass anhand der Token-Zuordnun- gen in einfacher Form erkannt werden kann, bei welchen Token es sich um unbe- kannte Daten handelt und bei welchen Token es sich um bekannte Daten, d.h. Trig- ger oder klassifizierbare Daten, handelt. Somit können beispielsweise Suchabfragen derart definiert werden, dass sie ausschließlich bekannte Daten berücksichtigen. Zusätzliche Lernalgorithmen können beispielsweise derart konfiguriert werden, dass sie ausschließlich auf bekannten Daten arbeiten. Mithin kann beispielsweise eine Verwendung von Zufall in einem Entscheidungs- bzw. Klassifizierungsprozess ver- wendet, selbst wenn zusätzliche Lernalgorithmen zum Einsatz kommen. Grundlage für alle Lernprozesse und/oder Kl-Prozesse bieten in diesem Fall die initial festge- legten Trigger, anhand derer die von der Datenbank empfangenen Daten klassifi- ziert werden. Nach Ausführungsformen bieten die vorbestimmenden Trigger-Defini- tionen eine Grundlage für ein überwachtes Lernen. Durch die Verwendung der vor- bestimmenden Trigger-Definitionen lassen sich Fehlentwicklungen in selbstkleben- den Systemen und/oder bei der Verarbeitung von Suchanfragen vermeiden, welche die in der Datenbank gespeicherten Daten verwenden.
Ausführungsformen können ferner den Vorteil haben, dass zusätzliche Datensätze, welche der Quelldatenbank hinzugefügt werden, jeweils dahingehend analysiert werden, welche der von ihnen umfassten Daten bekannte Daten sind und welche Daten unbekannte Daten sind. In diesem Kontext werden unter bekannten Daten solche Daten verstanden, welche als Trigger bekannt sind, für welche Meta- bzw. Kontextinformationen vorliegen und/oder für welche Meta- bzw. Kontextinformatio- nen unter Verwendung der Trigger-Definitionen aus dem Kontext der Datensätze abgeleitet werden können. Daten, bei welchen es sich weder um Trigger handelt noch um Daten, welche anhand der Trigger-Definitionen klassifizierbar sind, sind unbekannte Daten. Unbekannte Daten werden der Auffangklasse zugeordnet.
Ausführungsformen können den Vorteil haben, dass ein für das maschinelle Lernen optimiertes Datenbanksystem verwendet wird. Das entsprechende Datenbanksys- tem umfasst alle dem maschinellen Lernen zu Grunde liegenden Daten, d.h. sowohl zum Klassifizieren von Daten verwendete Trigger-Definitionen, als auch die Daten, welche unter Verwendung der Trigger-Definitionen verarbeitet werden. Somit wird ein kontinuierliches Lernen durch das Lernmodul unter Berücksichtigung aller von dem System bzw. dem Lernmodul gesehenen Daten ermöglicht.
Die Quelldatenbank speichert alle empfangenen Datensätze in einem dokumenten- orientierten Datenmodell. Ein dokumentenorientiertes Datenmodell bedeutet, dass das Datenmodell keine strukturellen Vorgaben an die zu speichernden Daten stellt. Vielmehr werden die Daten in Dokumenten bzw. Datencontainern in der Form ge- speichert, in der empfangen werden. In diesem Sinne handelt es sich bei den in dem dokumentenorientierten Datenmodell gespeicherten Daten um Rohdaten. Roh- daten bedeutet, dass die Daten in der Form abgespeichert werden, in der sie emp- fangen werden, ohne eine zusätzliche Datenverarbeitung durch das Datenbankma- nagementsystem, insbesondere keine Umstrukturierung der Daten. Ausführungsfor- men können den Vorteil haben, dass somit der gesamte Informationsgehalt der empfangenen Daten (nahezu) vollständig beibehalten werden kann, ohne dass Vor- annahmen des Datenbankmanagementsystems einfließen. Das Datenbankmanage- mentsystem ebenso wie das Lernmodul können jederzeit auf die ursprünglichen Da- tenbestände zurückgreifen und diese in bei der weiteren Verarbeitung berücksichti- gen.
Basierend auf diesem Datenpool an Rohdaten, welchen das dokumentenbasierte Datenmodell bereitstellt, wird ein Index erzeugt. Erst auf dieser Ebene werden aus den Datensätze strukturelle Information bzw. Sinnzusammenhänge extrahiert. Diese strukturellen Informationen bzw. Sinnzusammenhängen werden in Form von Klas- senzuordnungen der indexierten Daten berücksichtigt.
Hierzu werden die Datensätze durch eine Tokenisierung auf ein elementares Ni- veau heruntergebrochen, welches die elementaren Bestandteile der Datensätze in Form der Token berücksichtigt. Die Token werden durch das Lernmodul als Trigger einer der Trigger-Definitionen zugeordnet oder als unter Verwendung der Trigger- Definitionen klassifiziert. Alle Token, welche weder als Trigger identifiziert werden, noch sich unter Verwendung einer der Trigger-Definitionen klassifiziert lassen, werden als unbekannte Daten der Auffangklasse zugeordnet. Beispielsweise um- fasst das Lernmodul einen Klassifizierer und ist zur Klassifizierung der Token unter Verwendung der vorbestimmten Trigger-Definitionen konfiguriert. Die entspre- chende Klassifikation kann beispielsweise Teil einer Mustererkennung sein, bei wel- cher eine Merkmalsgewinnung durch die Tokenisierung implementiert wird. Basie- rend auf diese Merkmalsgewinnung erfolgt jedoch keine Merkmalsreduktion im klas- sischen Sinne, da der vollständige Datenbestand indexiert wird und somit jedes To- ken als Trigger erkannt oder einer Klasse, zumindest der Auffangklasse, zugeordnet wird.
Zudem ist jedes Token in dem Index mit einem oder mehreren Zeigern verknüpft, welche anzeigen, in welchen Datensätzen das entsprechende Token vorkommt. So- mit kann jederzeit auf die für einen Token relevanten Rohdaten zugegriffen werden und diese Rohdaten können zur Auswertung in Hinblick auf diesen Token herange- zogen werden.
Hierdurch werden die Token-Zuordnungen nach bekannten Daten, welche gesicher- ten Fakten darstellen, und unbekannte Daten differenziert. Ausführungsformen kön- nen den Vorteil haben, dass die Verwendung der von dem Lernmodul bestimmten Strukturen und Gesetzmäßigkeiten in den Datensätzen, welche sich in den Token- Zuordnungen niederschlagen, auf den einer Verwendung der vorbestimmten Trigger Definitionen beruht. Unbekannt Daten werden demgegenüber als solche erfasst und solange außen vorgelassen werden, bis diese ebenfalls klassifiziert und mithin als gesicherte Fakten angesehen werden können. Eine solche zusätzliche Klassifika- tion kann beispielsweise durch zusätzliche Trigger-Definitionen implementiert wer- den. Insbesondere können gezielt zusätzliche Trigger-Definitionen zur Reduktion des von der Auffangklasse umfassten Token-Menge ergänzt werden. Das Verfahren ermöglicht somit ein Lernen und/oder Klassifizieren unter Vorbehalt.
Ausführungsformen können daher den Vorteil haben, dass sie dem Lernmodul er- lauben auf dem gesamten zur Verfügung stehenden Datenbestand zu arbeiten. Ins- besondere können sie den Vorteil haben, ein kontinuierliches Lernen zu ermöglichen, welches sowohl zusätzliche Datensätze als auch bereits gespeicherte Datensätze berücksichtigt. Ausführungsformen können daher den Vorteil haben, dass sie nicht darauf beschränkt sind, dass aus einer zur Verfügung stehenden Ge- samtdatenmenge eine willkürliche Untermenge herausgegriffen wird, um auf dieser zu trainieren. Vielmehr werden alle von der Datenbank umfassten Daten unter Ver- wendung der Trigger-Definitionen verarbeitet. Durch Ergänzungen der Trigger-Defi- nitionen kann nach Ausführungsformen zudem erreicht werden, dass alle Token entweder als Trigger identifiziert oder unter Verwendung der (ergänzten) Trigger- Definitionen klassifiziert werden. Werden unbekannte Daten von Suchanfragen und/oder weiteren Lernprozessen ausgeschlossen, so erfolgt dieser Ausschluss nicht willkürlich, sondern basierend auf den bereitgestellten Trigger-Definitionen.
Ausführungsformen können den Vorteil haben, dass keine zufällige Initialisierung er- forderlich ist, wie etwa bei bekannten selbstlernenden Systemen, z.B. neuronalen Netzwerken. Die Initialisierung beruht vielmehr auf den vorbestimmten Trigger-Defi- nitionen. Durch das aus dieser zufälligen Initialisierung resultierende Zufallsmoment werden die Entscheidungen/Klassifizierungen eines entsprechenden neuronalen Netzes nicht transparent und nicht nachvollziehbar. Demgegenüber können Ausfüh- rungsformen den Vorteil haben, vollständig deterministisch zu sein.
Ausführungsformen können den Vorteil haben, dass ein bereits trainiertes System, d.h. das vortrainierte Lernmodul nachtrainiert bzw. weiter trainiert wird. So können Trigger-Definitionen ergänzt, entfernt oder geändert werden. Dadurch lassen sich beispielsweise auch die bei der Klassifizierung verwendeten Klassen ergänzen, ent- fernen oder ändern. Werden Trigger-Definitionen ergänzt, entfernt oder geändert, so sind alle auf diesen basierenden Zuordnungen von Token zu den entsprechenden Trigger-Definitionen oder zu einer der Klassen entsprechend anzupassen. Durch ein Ergänzen von Trigger-Definitionen können beispielsweise neue Strukturen erfasst werden, welche sich bisher noch nicht gezeigt haben. Dadurch kann insbesondere das Faktenwissen nachträglich erweitert werden, d.h. der Auffangklasse zugeordne- ten Token können andere Klassen zugeordnet werden. Nach Ausführungsformen implementiert das Lernmodul einen Algorithmus zum ma- schinellen Lernen, wobei das Verfahren nicht beschränkt ist auf einen bestimmten Algorithmus. Nach Ausführungsformen umfasst der Algorithmus zum maschinellen Lernen zumindest einen Klassifizierungsalgorithmus zum Klassifizieren von Token. Bei dem maschinellen Lernen kann es sich um ein überwachtes oder ein unüber- wachtes Lernen handeln. Das maschinelle Lernen kann eine Klassifizierung und/o- der eine Regressionsanalyse umfassen. Ein Lernalgorithmus versucht, eine Hypo- these bzw. eine Abbildung zu finden, welche jedem Eingabewert den (vermuteten) Ausgabewert zuordnet. Liegen die zuzuordnenden Ausgabewerte in einer kontinu- ierlichen Verteilung vor, deren Ergebnisse beliebige quantitative Werte eines vorge- gebenen Wertebereiches annehmen kann, wird im Allgemeinen von einem Regres- sionsproblem gesprochen. Liegen die zuzuordnenden Ausgabewerte hingegen in diskreter Form vor bzw. sind die Werte qualitativ, wird im Allgemeinen von einem Klassifikationsproblem gesprochen. Nach Ausführungsformen stützt sich das ma- schinelle Lernen auf die Klassifikation der indexierten Token. Gemäß Ausführungs- formen der Erfindung umfasst das Lernmodul einen speziell für das maschinelle Lernen entwickelten Algorithmus, wie zum Beispiel, ohne darauf beschränkt zu sein, eine dichtenbasierte multidimensionale Ausreißererkennung (engl „local outlier de- tection“), ein Random-Forrest-Algorithmus, ein Neuronales Netz, eine Support-Vek- tor-Maschine, ein Naive-Bayes-Klassifikator oder eine Rückkopplung ähnlich der Rückkopplung eines linearen oder nichtlinearen Reglers.
Unter einer Multi-Modell-Datenbank wird hier eine Datenbank verstanden, welche dazu konfiguriert ist eine Mehrzahl von unterschiedlichen Datenmodellen zu unter- stützen. Eine Multi-Modell-Datenbank ist also dazu konfiguriert Daten in mehr als ei- nem Datenmodell zu speichern, zu indexieren und abzufragen. Datenmodelle sind beispielsweise relational, spaltenorientiert, dokumentenorientiert, graphbasiert, Key- Value-basiert etc. Ein Datenbankmodell legt fest, in welcher Struktur Daten in einem Datenbanksystem gespeichert werden, d.h. in welcher Form die Daten organisiert, gespeichert und bearbeitet werden. Unter einer Datenbank wird im Folgenden eine (typischerweise große) Menge von Daten verstanden, die in einem Computersystem von einem Datenbankmanage- mentsystem (DBMS) nach bestimmten Kriterien verwaltet wird. Die Daten sind da- bei in einer Vielzahl von Datensätzen organisiert. Unter einem Datenbankmanage- mentsystem oder DBMS wird im Folgenden ein elektronisches System zur Speiche- rung und Wiedergewinnung von Daten verstanden. Vorzugsweise werden die Daten in dem DBMS widerspruchsfrei und dauerhaft gespeichert und verschieden Anwen- dungsprogrammen und Nutzern in bedarfsgerechter Form effizient zur Verfügung gestellt. Ein DBMS kann typischerweise ein oder mehrere Datenbanken beinhalten und die darin enthaltenen Datensätze verwalten. Bei dem DBMS kann es sich vor- zugsweise um ein feldorientiertes DBMS handeln, also um ein DBMS, das dazu konfiguriert ist, Teile einzelner Datensätze, sogenannte Feldwerte, in mehreren un- terschiedlichen Feldern zu speichern.
Unter einem Datensatz wird im Folgenden eine dem Datenbanksystem bereitge- stellte zusammenhängende Menge von Daten verstanden, welche von dem Daten- bankmanagementsystem als zusammenhängende Menge von Daten verwaltet wird. Ein Datensatz umfasst beispielsweise eine Menge inhaltlich zusammenhängender Daten. Nach Ausführungsformen werden Datensätze jeweils als zusammenhän- gende Datenmengen in dem dokumentenorientierten Datenmodell gespeichert. Bei- spielsweise kann ein einzelner Datensatz ein bestimmtes physisches Objekt, z.B. eine natürliche Person oder eine Vorrichtung, repräsentieren. Bei der Person kann es sich z.B. um einen Angestellten, einen Patienten, einen Kunden, etc. handeln.
Bei der Vorrichtung kann es sich beispielsweise um eine Produktionsvorrichtung, eine Computervorrichtung, ein Computer- oder Netzwerkelement oder eine Trans- portvorrichtung handeln. Der entsprechende Datensatz kann eine vordefinierte Menge von Attributwerten dieser Person oder Vorrichtung beinhalten (z.B. Name o- der Pseudonym, Alter, Größe, Gewicht, Geburtsdatum, Ausweisnummern, Sicher- heitszertifikate, Authentifizierungscodes, biometrische Daten, Identifikator, Fierstel- lungsdatum, Inbetriebnahmedatum, Konfigurationsdaten, und andere). Beispiels- weise kann ein Datensatz eine Gruppe von inhaltlich zusammenhängenden (zu ei- nem Objekt gehörenden) Datenfeldern repräsentieren, z. B. Artikelnummer, Artikelgröße, Artikelfarbe, Artikelname oder ähnliches. Die Klassen ,Name‘, Ad- resse' und ,Geburtsdatum' könnten z.B. die logische Struktur eines Datensatzes zum Objekttyp„Person“ bilden. In der Datenverarbeitung werden Daten in Form von Datensätzen in Datenbanken gespeichert, wobei sie sind Gegenstand der Verarbei- tung von Computerprogrammen und werden von diesen erzeugt, gelesen, verändert und gelöscht.
Ein„NoSQL“ (englisch für Not only SQL) DBMS ist ein DBMS, welches einem nicht- relationalen Ansatz der Datenspeicherung folgt und keine festgelegten Tabellen- schemata benötigt. Zu den NoSQL DBMSs gehören insbesondere dokumentenori- entierte DBMSs wie Apache Jackrabbit, BaseX, CouchDB, IBM Notes, MongoDB, Graphdatenbanken wie Neo4j, OrientDB, InfoGrid, HyperGraphDB, Core Data,
DEX, AllegroGraph, und 4store, verteilte ACID-DBMSs wie MySQL Cluster, Key-Va- lue-Datenbanken wie Chordless, Google BigTable, GT.M, InterSystems Cache, Membase, Redis, sortierte Key-Value-Speicher, Multivalue-Datenbanken, Obektda- tenbanken wie Db4o, ZODB, spaltenorientierte Datenbanken und temporale Daten- banken wie Cortex DB.
Ein Index ist eine Datenstruktur, welche eine Suche nach bestimmten Datenwerten durch ein Datenbankmanagementsystem beschleunigt. Ein Index besteht aus einer Ansammlung von Zeigern (Verweisen), die eine Ordnungsrelation auf mehrere (in dem Index gespeicherte)„indexierte“ Datenwerte definieren. Beispielsweise werden hierfür B+-Bäume verwendet. Jeder indexierte Datenwert ist mit weiteren Zeigern verknüpft, die auf Datensätze verweisen, in welchen der gefundene indexierte Da- tenwert enthalten ist und welche die Datenbasis für die Erstellung des Index dar- stellten. Datenbankmanagementsysteme verwenden Indizes um als Antwort auf eine Suchanfrage die gewünschten Datensätze schnell zu identifizieren, indem zu- nächst der Index entlang der Zeiger nach einem Datenwert durchsucht wird, wel- cher identisch zu einem in der Suchanfrage enthaltenen Referenzwert ist. Ohne In- dex müssten die von dem DBMS verwalteten Datenwerte eines Feldes sequenziell durchsucht werden, während eine Suche mit Hilfe des Index, z.B. eines B+-Baums, oft nur logarithmische Komplexität hat. Ferner ordnet der Index die indexierten Daten, d.h. Token, Klassen zu, wodurch die entsprechenden Daten mit Meta- bzw. Kontextinformationen verknüpft werden.
Diese Meta- bzw. Kontextinformationen können bei einer Suche und/oder bei einem maschinellen Lernprozess auf den Daten der Datenbank verwendet werden.
Unter einem Feld wird im Folgenden ein Bereich auf einem logischen oder physikali- schen Datenträger bezeichnet, der von einem DBMS verwaltet wird, der einem vor- definierten Feldtyp zugeordnet ist und der zur Speicherung eines Feldwertes eines Datensatzes angelegt und bestimmt ist. Ein Feld ist also ein Element zur Speiche- rung eines Feldwertes eines Datensatzes gemäß obiger Definition. Felder eines Da- tensatzes werden von einem DBMS gemeinsam verwaltet.
Ein Feldwert ist ein Datenwert, der Bestandteil eines Datensatzes ist und in einem Feld des Datensatzes gespeichert ist. Ein Feldwert kann aus einem einzigen Wort, einer einzigen Zahl, oder einer Kombination aus mehreren Wörtern und/oder Zahlen und/oder anderen Datenformaten bestehen, wobei verschiedene Ausführungsfor- men der Erfindung verschiedene Grade an Flexibilität im Hinblick auf die Art und Kombinierbarkeit von Datentypen innerhalb des gleichen Feldwertes umfassen.
Ein„Tokenisierer“ ist eine Programlogik, die Daten, zum Beispiel einen Feldwert, als Input erhält, die Daten analysiert, z.B. um Delimiter oder andere Zerlegungskriterien und Muster zu erkennen und die Daten dann in ein oder mehrere Token als Ergeb- nis der Analyse zerlegt und die Token zurückgibt. Es ist auch möglich, dass nicht alle Daten als Token zurückgegeben werden. Beispielsweise kann ein Volltextindi- zierer semantisch unbedeutende Stoppwörter erkennen und herausfiltern, sodass diese nicht indexiert werden. Alternativ werden alle Daten als zurückgegeben. Einen Datenwert zu„tokenisieren“ bedeutet also, den Datenwert nach einem bestimmten Schema in mehrere Bestandteile zu zerteilen. Die Bestandteile stellen die Token dar. So können z.B. natürlichsprachige Texte an vordefinierten Trennzeichen, z.B. Leerzeichen, Punkten oder Kommata, aufgeteilt werden, die so generierten Be- standteile (Wörter) werden als Token verwendet. Nach Ausführungsformen werden alle Token für die Indexierung verwendet. Es ist auch möglich, dass manche Token nicht für die Indexierung verwendet werden (z.B. Stopwörter) oder die Token vor der Indexierung zusätzlich verarbeitet werden (z.B. Reduzierung von Wörtern auf den Wortstamm). In diesem Fall erfolgt für eine Verarbeitung von Suchanfragen eines Client-Computersystems an ein Server-Computersystem vorzugsweise eine gleich- artige Verarbeitung des Suchwerts durch das Client-Computersystem oder das Ser- ver-Computersystem um sicherzustellen, dass die Suchwerte der Suchanfragen den in dem Index enthaltenen Token entsprechen.
Ein Klasse definiert beispielsweise eine Kategorie bzw. ein Typ, dem ein Token an- gehört. Die Klasse ordnet dem Token mithin Meta- bzw. Kontextinformationen, etwa in Form einer Eigenschaft zu. Beispielsweise kann eine Klasse ein bestimmtes Attri- but eines physischen Objekts in Form eines Token repräsentieren. Beispielsweise können zu speichernde Datensätzen, die Attribute von Angestellten enthalten, wel- che Klassen wie„Name“,„Pseudonym“,„Ausweisnummer“;„Zugriffszertifikat für Raum R“,„Zugriffszertifikat für Gerät G“,„Zugriffszertifikat für Gebäude GB“,„Alter“ repräsentieren. Jedes Token kann ein oder mehreren Klassen zugeordnet sein. Fer- ner können Kombinationen von Token als eigenständige Token wiederum ein oder mehreren weiteren Klassen zugeordnet sein.
Die empfangenen Datensätze werden unter Verwendung eines dokumentorientier- ten Datenmodell abgespeichert. Beispielsweise werden alle Feldwerte der abge- speicherten Datensätze als Token in einen mehrdimensionalen Schlüssel/Wert- Speicher (Key/Value-Store) bzw. Key-Value-Datenbanken übertragen. Dabei wer- den die Token Tokentypen zugeordnet und in einer Form gespeichert, welche die sechste Normalform erfüllt.
Nach Ausführungsformen werden zusätzlich Transaktionszeit und Gültigkeitszeit der Datensätze bitemporal gespeichert. Die Transaktionszeit gibt den Zeitpunkt an, zu dem eine Änderung eines Datenobjekt in der Datenbank erfolgt. Die Gültigkeitszeit gibt einen Zeitpunkt oder Zeitraum an, in dem ein Datenobjekt im modellierten Abbild der realen Welt den beschriebenen Zustand aufweist. Sind sowohl Gültig- keits- als auch Transaktionszeit relevant, spricht man von bitemporal.
Ein Schlüssel-Werte-Datenmodell ermöglicht ein Speichern, Abrufen und Verwalten von assoziativen Datenfeldern. Dabei werden Werte (Value) über einen Schlüssel (Key) eindeutig identifiziert.
In einem dokumentenorientierte Datenmodell, auch bekannt als Dokumentenspei- cher (Document Store), bilden Dokumente bzw. Datencontainer die Grundeinheit zur Speicherung der Daten bilden. Ein dokumentenorientiertes Datenmodell ermög- licht es dokumentenorientierten Informationen, auch bekannt als halbstrukturierte Daten, zu speichern, abzurufen und zu verwalten. Auf einem dokumentenorientier- ten Datenmodell beruhende Datenbanken gehören zu den NoSQL-Datenbanken und bilden eine Unterklasse der Schlüssel-Wert-Speicher (Key-value Stores). In ei- nem Schlüssel-Wert-Speicher werden die Daten als für die Datenbank inhärent un- durchsichtig angesehen, während eine dokumentenorientierte Datenbank auf in- terne Strukturen in den gespeicherten Dokumenten angewiesen ist, um Metadaten zu extrahieren. Das semistrukturierte Datenmodell ist ein Datenbankmodell, bei dem keine Trennung zwischen den Daten und dem Schema besteht und der Umfang der verwendeten Struktur vom Verwendungszweck der Datenbank abhängt. Jedes Do- kument innerhalb des Datenmodells wird über einen eindeutigen Identifikator ange- sprochen.
Eine Kombination der verschiedenen Datenbankkonzepten ermöglicht es Daten- sätze als Dokumente bzw. Container zu speichern (document störe) und zusätzlich in Form eines Index, z.B. eines Schlüssel-Wert-Speichers, in die 6. Normalform zu überführen. Dieser Schlüssel-Wert-Speicher repräsentiert den gesamten Datenum- fang in dem Dokumentenspeicher, während die Originaldatensätze erhalten bleiben.
Nach Ausführungsformen werden Selektionen ausschließlich in dem Schlüssel- Wert-Speicher in der redundanzfreien sechsten Normalform durchgeführt. Erst das Ergebnis wird aus den Containern des Dokumentenspeicher gelesen. Nach Ausführungsformen wird neben Lese- und Schreibrechten in den Datensätzen zu- sätzlich ein Selektionsrecht auf dem Schlüssel-Wert-Speicher implementiert. Somit kann auch auf dem Index alleine gearbeitet werden, ohne die zugrundeliegenden Daten auslesen zu müssen.
Die vorgeschlagene Multi-Modell-Datenbank stellt somit neben einer schemalosen Datenablage auf Basis eines Dokumentenspeichers eine vollständige Normalisie- rung des gesamten Datenumfangs in der sechsten Normalform bereit. Ausführungs- formen können den Vorteil haben, dass der Index Datenelemente der Datensätze, d.h. Token, als Schlüssel umfasst und jedem dieser Schlüssel jeweils ein oder meh- rere Zeiger als Werte zugeordnet sind, welche anzeigen, in welchen Datensätzen und/oder Feldern der Datensätze der entsprechende Schlüssel, d.h. Token/Daten- wert, als Feldwert gespeichert ist.
Dieser Index bildet daher über alle Felder der Datensätze und deren Inhalte, d.h. die Feldwerte, die gesamte Datenbank mit allen von ihr umfassten Datensätze ab, so dass alle Abfragen in dem Index behandelt und die schemalos gespeicherten Daten des dokumentenorientierten Datenmodells nur zur Ausgabe der Suchergebnisse verwendet werden. Die geringe Größe des Index im Vergleich zu den schemalosen Daten ermöglicht schnelle Abfragen in beliebigen Abfragekombinationen.
Unter einem Computer bzw. Computersystem wird hier ein Gerät verstanden, wel- ches mittels programmierbarer Rechenvorschriften Daten verarbeitet. Unter einem Programm bzw. Programminstruktionen wird hier ohne Einschränkung jede Art von Computerprogramm verstanden, welches maschinenlesbare Instruktionen zur Steu- erung einer Funktionalität eines Computers umfasst. Ein Computer bzw. Computer- system kann eine Kommunikationsschnittstelle zur Verbindung mit dem Netzwerk umfassen, wobei es sich bei dem Netzwerk um ein privates oder öffentliches Netz- werk handeln kann, insbesondere das Internet oder ein anderes Kommunikations- netz. Je nach Ausführungsform kann diese Verbindung auch über ein Mobilfunknetz hergestellt werden. Bei einem Computersystem kann es sich um ein stationäres Computersystem, wie beispielsweise einen Personalcomputer (PC) oder einen in einer Client-Server-Um- gebung eingebundenen Client bzw. Server handeln. Ferner kann es sich bei einem Computersystem beispielsweise um ein mobiles Telekommunikationsgerät, insbe- sondere ein Smartphone, einen tragbaren Computer, wie zum Beispiel einen Laptop PC oder Palmtop-PC, ein Tablet PC, einen Personal Digital Assistant oder derglei- chen handeln.
Bei einem entsprechenden Computersystem kann es auch um einen Gegenstand des Internets der Dinge („smart device“), z.B. um ein sog.„wearable“ bzw.
„wearable Computer“ handeln, d.h. tragbare elektronische Geräte bzw. tragbare Computersysteme, welche während der Anwendung am Körper des Nutzers ange- ordnet sind. Beispiele für Wearables sind Smartwatches, d.h. Uhren mit Computer- funktionalität und -konnektivität, Activity Tracker, d.h. Gerät zur Aufzeichnung und Versendung fitness- und/oder gesundheitsrelevanter Daten, Smartglasses, d.h. Bril- len, deren Innenseiten als Bildschirm dienen, oder Kleidungsstücke, in die elektroni- sche Hilfsmittel zur Kommunikation eingearbeitet sind.
Nach weiteren Ausführungsformen kann es sich bei einem Computersystem um ein Computersystem eines Fortbewegungsmittels, wie etwa ein Auto, Flugzeug, Schiff oder Zug mit Bordcomputer, handeln.
Nach weiteren Ausführungsformen kann es sich bei einem Computersystem um ei- nen Steuercomputer eines Smarthome-Systems, ein Access Point oder Router ei- nes lokales WLAN-Netzwerks, ein Multimediagerät mit Computerfunktionalität und - konnektivität, wie etwa ein Smart-TV, ein Steuersystem einer Schließanlage oder ein„smart device“ bzw. intelligenter Gegenstände, d.h. ein informationstechnisch aufgerüstete Alltagsgegenstände, welcher einen Mehrwert durch sensorgestützte Informationsverarbeitung und Kommunikation erhält.
Unter einem Speicher werden hier sowohl flüchtige als auch nicht flüchtige elektro- nische Speicher bzw. digitale Speichermedien verstanden. Unter einem nichtflüchtigen Speicher wird hier ein elektronischer Speicher zur dau- erhaften Speicherung von Daten verstanden. Ein nichtflüchtiger Speicher kann als nichtänderbarer Speicher konfiguriert sein, der auch als Read-Only Memory (ROM) bezeichnet wird, oder als änderbarer Speicher, der auch als Non-Volatile Memory (NVM) bezeichnet wird. Insbesondere kann es sich hierbei um ein EEPROM, bei- spielsweise ein Flash-EEPROM, kurz als Flash bezeichnet, handeln. Ein nichtflüch- tiger Speicher zeichnet sich dadurch aus, dass die darauf gespeicherten Daten auch nach Abschalten der Energieversorgung erhalten bleiben.
Unter einem flüchtigen elektronischen Speicher wird hier ein Speicher zur vorüber- gehenden Speicherung von Daten, welcher dadurch gekennzeichnet ist, dass alle Daten nach dem Abschalten der Energieversorgung verloren gehe. Insbesondere kann es sich hierbei um einen flüchtigen Direktzugriffsspeicher, der auch als Ran- dom-Access Memory (RAM) bezeichnet wird, oder einen flüchtigen Arbeitsspeicher des Prozessors handeln.
Unter einem Prozessor wird hier und im Folgenden eine Logikschaltung verstanden, die zur Ausführung von Programminstruktionen dient. Die Logikschaltung kann auf einem oder mehreren diskreten Bauelementen implementiert sein, insbesondere auf einem Chip. Insbesondere wird unter einem Prozessor ein Mikroprozessor oder ein Mikroprozessorsystem aus mehreren Prozessorkernen und/oder mehreren Mikro- prozessoren verstanden.
Nach Ausführungsformen erfolgt , falls eines der zusätzlichen Token nicht von dem Index umfasst ist, das Ergänzen des entsprechenden zusätzlichen Tokens unter seinen Klassenzuordnungen in dem Index, und, falls eine der Klassenzuordnungen eines von dem Index umfassten zusätzlichen Tokens von dem Index nicht umfasst ist, erfolgt ein Ergänzen der entsprechenden Klassenzuordnung mit dem entspre- chenden zusätzlichen Token in dem Index und Verknüpfen des entsprechenden zu- sätzlichen Tokens in dem Index mit dem Zeiger auf den zusätzlichen in dem doku- mentenorientierten Datenmodell gespeicherten Datensatz. Für solche Token des zusätzlichen Datensatzes, welche der Index bereits umfasst, für welche aber ein oder mehrere unter Verwendung des zusätzlichen Datensatzes ermittelte Klassenzuordnungen von dem Index noch nicht berücksichtigt werden, werden die entsprechenden Klassenzuordnungen ergänzt. Zusätzlich wird in dem Index für diese Token jeweils der Zeiger auf den zusätzlichen Datensatz ergänzt.
Schließlich wird für solche Token des zusätzlichen Datensatzes, welche der Index bereits mit all ihren für den zusätzlichen Datensatz ermittelten Klassenzuordnungen umfasst, lediglich der Zeiger auf den zusätzlichen Datensatz ergänzt.
Ausführungsformen können den Vorteil haben, dass stets sichergestellt werden kann, dass der Index alle von den Datensätzen der entsprechenden Einzeldaten- bank umfassten Token aufweist. Zudem umfasst der Index für alle entsprechenden Token alle aufgefundenen Klassenzuordnungen. Zudem ist jeder der Token des In- dex mit Zeiger auf alle Datensätze der der entsprechenden Einzeldatenbank ver- knüpft, welche das entsprechende Token umfassen.
Beispielsweise wird im Zuge des Vortrainierens des Lernmodus eine initiale Menge von vorbestimmten Trigger-Definitionen festgelegt. Im Zuge eines Erfassens von Daten, werden Datensätze empfangen und in dem dokumentenbasierten Datenmo- dell gespeichert. Die gespeicherten Datensätze werden tokenisiert und für die resul- tierenden Token werden Klassen-Zuordnungen unter Verwendung der initial festge- legten Trigger-Definitionen ermittelt und ein initialer Index für die resultierenden To- ken erzeugt. Nach Ausführungsformen umfasst der initiale Index alle von den Trig- ger-Definitionen umfassten Trigger als Token. Nach alternativen Ausführungsfor- men werden durch die Trigger-Definitionen als Trigger festgelegte Token in dem In- dex nur unter der Voraussetzung ergänzt, dass sie von einem der Datensätze um- fasst sind.
Eine Zuordnung eines Token zu einer Klasse unter Verwendung einer vorbestimm- ten Trigger-Funktion stellt ein durch die entsprechende vorbestimmten Trigger- Funktion gesichertes Faktum dar. Für Token, bei welchen es sich um keinen Trigger handelt und welche von keiner der Trigger-Definitionen erfasst werden, fehlt es an einem solchen Faktenwissen. Die entsprechenden Token werden vielmehr als un- bekannte Daten der Auffangklasse zugeordnet. Ausführungsformen können somit den Vorteil haben, dass unter Verwendung von initial festgelegten Trigger-Definitio- nen neue Daten in bekannte Daten, d.h. Trigger oder unter Verwendung von Trig- ger-Definitionen klassifizierter Token, und unbekannte Daten eingeteilt werden kön- nen, d.h. der Auffangklasse zugeordnete Token.
Nach Ausführungsformen werden die Kombinationen aus zweiten zusätzlichen To- ken mit ein oder mehreren der identifizierten Trigger, welche eine Klassenzuord- nung gemäß einer der Trigger-Definitionen getriggert haben, in dem Index als klas- sifizierte Kombinationen gekennzeichnet und Klassenzuordnungen werden nur für Kombinationen aus zweiten zusätzlichen Token und ein oder mehreren identifizier- ten Triggern ausgeführt, welche nicht als klassifizierte Kombinationen gekennzeich- net sind.
Ausführungsformen können den Vorteil haben, dass für alle Token-Kombinationen, für welche bereits bei einer Klassenzuordnung berücksichtigt wurden bzw. für wel- che bereits eine Klassenzuordnung ausgeführt wurde, in dem Index jeweils als be- reits klassifiziert gekennzeichnet werden. Somit lässt sich vermeiden, dass für To- ken-Kombinationen, welche das Lernmodul bereits zuvor gesehen und im Zuge der Klassifizierungen vollständig berücksichtigt hat, dieselben Klassifizierungen erneut ausgeführt. Somit kann das System deutlich effizienter ausgestaltet werden. Bei- spielsweise umfasst der Index neben elementaren Token alle Token-Kombinatio- nen, für welche bereits eine Klassifizierung erfolgt ist, d.h. alle Token-Kombinatio- nen, welche als klassifiziert zu kennzeichnen sind. Nach Ausführungsformen sind die entsprechenden Token-Kombinationen in dem Index jeweils mit einem Flag ver- sehen, welches anzeigt, ob es sich bei der entsprechenden Token-Kombinationen um klassifizierte Token-Kombinationen handelt. Nach Ausführungsformen erfolgt auf eine Tokenisierung eines zusätzlichen Daten- satzes hin zunächst ein Abgleich mit allen als bereits klassifiziert gekennzeichneten Token-Kombinationen. Für diese Token-Kombinationen wird die Klassifizierung nicht wiederholt, vielmehr erfolgt lediglich eine Verknüpfung mit dem Zeiger auf den zusätzlichen Datensatz. Nach Ausführungsformen wird der entsprechende Zeiger auch mit allen von der Token-Kombination umfassten Token in dem Index ver- knüpft. Nach Ausführungsformen erfolgt der Abgleich zunächst mit den größten, d.h. umfangreichsten, Token-Kombinationen des Index. Für alle bereits als klassifiziert erkannten Token-Kombinationen des zusätzlichen Datensatzes wird lediglich der Zeiger auf den entsprechenden Datensatz in der Quelldatenbank abgespeichert. Nach Ausführungsformen wird der entsprechende Zeiger auch mit allen von der To- ken-Kombination umfassten Token in dem Index verknüpft. Somit kann das Einar- beiten der Daten des zusätzlichen Datensatzes in den Index deutlich beschleunigt werden. Nach Ausführungsformen erfolgt sukzessive ein Abgleich mit weiteren To- ken-Kombination, wobei die Größe bzw. der Umfang der verwendeten weiteren To- ken-Kombinationen sukzessive abnimmt. Nach Ausführungsformen werden nur sol- che weiteren Token-Kombinationen mit geringerer Größe bzw. Umfang berücksich- tigt, welche nicht als Teil einer größeren bzw. umfangreichem Token-Kombinationen eine Übereinstimmung im Zuge des Abgleichs festgestellt wurde. Ausführungsfor- men können den Vorteil haben, dass für umfangreiche Token-Kombinationen, wel- che als bereits klassifiziert erkannt werden, kein zusätzlicher Abgleich für von der entsprechenden Token-Kombination umfasste Unterkombinationen erfolgt. Vielmehr erfolgt ein entsprechender Abgleich lediglich, wenn die entsprechende Unterkombi- nation in dem zusätzlichen Datensatz unabhängige von der entsprechenden um- fangreicheren Token-Kombination als eigenständige Token-Kombination umfasst ist.
Nach Ausführungsformen umfasst das Verfahren ferner:
• Identifizieren von ein oder mehreren Trigger-Kombinationen, welche jeweils von zumindest einem der Datensätzen umfasst sind und ein Kombinationskri- terium erfüllen, • für jede der identifizierten Trigger-Kombinationen Kombinieren der Trigger-De- finitionen der Trigger der entsprechenden Trigger-Kombinationen zu ein oder mehreren zusätzlichen kombinierten Trigger-Definitionen,
• Ergänzen der Mehrzahl von vorbestimmten Trigger-Definitionen des Lernmo- duls durch die ein oder mehreren zusätzlichen kombinierten Trigger-Definitio- nen.
Ausführungsformen können den Vorteil haben, dass basierend auf den von den initi- alen Trigger-Definitionen identifizierten Triggern zusätzliche Trigger in Form von Trigger-Kombinationen identifiziert werden können. Basierend auf diesen identifi- zierten Trigger-Kombinationen können aus den initialen Trigger-Definitionen kombi- nierte Trigger-Definitionen bestimmt werden, mit denen die Mehrzahl der vorbe- stimmten Trigger-Definitionen erweitert werden kann.
Nach Ausführungsformen werden mehrere Token-Kombinationen, welche von dem- selben Datensatz umfasst werden und unter die kombinierte Trigger-Definition fal- len, miteinander kombiniert und die resultierende Kombination in dem Index als eine klassifizierte Kombination gekennzeichnet. Ausführungsformen können den Vorteil haben, dass auch auf Basis kombinierte Trigger-Definitionen Token-Kombinationen im Index als klassifizierte Kombinationen gekennzeichnet und dadurch unnötige Wiederholungen von Klassifizierungen bereits klassifizierter Token-Kombinationen vermieden werden können.
Nach Ausführungsformen umfasst das Kombinationskriterium eine Mindesthäufig- keit für ein Auftreten der entsprechenden Trigger-Kombination in den Datensätzen. Ausführungsformen können den Vorteil haben, dass entsprechende Trigger-Kombi- nationen nur dann herangezogen werden zum Bilden einer kombinierten Trigger- Definition, wenn die entsprechende Trigger-Kombination in den Datensätzen mit ei- ner Mindesthäufigkeit auftreten. Somit kann verhindert werden, dass zusätzliche kombinierte Trigger-Definition gebildet werden aufgrund eines zufälligen Auftretens von Triggern unterschiedlicher Trigger-Definitionen in ein und demselben Daten- satz. Ein solches zufälliges Auftreten ist ab einer bestimmten Größe und/oder Komplexität der Datensätze zu erwarten, ohne dass daraus Rückschlüsse auf einen zugrundeliegenden Zusammenhang zwischen den Triggern geschlossen werden könnte. Treten die entsprechenden Trigger-Kombinationen jedoch häufiger auf, so kann daraus auf einen Zusammenhang geschlossen werden.
Nach Ausführungsformen legt die Mindesthäufigkeit einen absoluten Häufigkeits- wert des Auftretens in den Datensätzen fest. Bei der entsprechenden Mindesthäu- figkeit kann es sich um einen Mindestwert für das Auftreten der entsprechenden Trigger-Kombination in allen Datensätzen handeln. Das Auftreten der entsprechen- den Trigger-Kombination wird über alle Datensätze aufsummiert. Ist die resultie- rende Summe größer oder gleich dem Mindestwert, so ist dieser erfüllt. Ferner kann es sich dabei der Mindesthäufigkeit um eine Mindestwert für das Auftreten in einem der Datensätze handeln. Das Auftreten der entsprechenden Trigger-Kombination wird für die einzelnen Datensätze jeweils individuell aufsummiert. Erfüllt ein der re- sultierenden Summen den Mindestwert, so liegt die Mindesthäufigkeit vor. Nach al- ternativen Ausführungsformen muss der Mindestwert von einer vorbestimmten An- zahl von Datensätzen oder einem vorbestimmten Prozentsatz der Datensätze erfüllt werden. Bei dem entsprechenden vorbestimmten Prozentsatz handelt es sich ent- weder um einen Prozentsatz aller Datensätze der Datenbank oder aller Datensätze, welche die entsprechende Trigger-Kombination umfassen. Nach alternativen Aus- führungsformen muss der Mindestwert von allen Datensätzen erfüllt werden und/o- der von allen Datensätzen, welche die entsprechende Trigger-Kombination umfas- sen. Ferner kann sich bei der entsprechenden Mindesthäufigkeit um einen Mindest- wert für eine Durchschnittshäufigkeit des Auftretens der entsprechenden Trigger- Kombination in allen Datensätzen der Datenbank oder allen Datensätzen, welche die entsprechende Trigger-Kombination umfassen, handeln.
Nach Ausführungsformen legt die Mindesthäufigkeit einen relativen Häufigkeitswert des Auftretens in den Datensätzen fest. Nach Ausführungsformen ist die entspre- chenden Mindesthäufigkeit abhängig von der Anzahl der Datensätze und/oder der Anzahl der Token und/oder der Größe der von den Datensätzen umfassten Daten. Beispielsweise wächst der von der Mindesthäufigkeit festgelegte Häufigkeitswert mit der Anzahl der Datensätze und/oder der Anzahl der Token und/oder der Größe der von den Datensätzen umfassten Daten.
Nach Ausführungsformen legt die Mindesthäufigkeit einen relativen Häufigkeitswert des Auftretens in den Datensätzen fest relativ zu Häufigkeiten des Auftretens von ein oder mehreren der von der entsprechenden Trigger-Kombination umfassten Triggern in den Datensätzen. Beispielsweise ist der relative Häufigkeitswert von dem Auftreten des Triggers mit der höchsten Häufigkeit eines Auftretens, des Trig- ger mit der geringsten Häufigkeit eines Auftretens und/oder einem Durchschnitts- wert des Auftretens aller Trigger der entsprechenden Trigger-Kombination abhän- gig. Ausführungsformen können den Vorteil haben, dass bei einer Berücksichtigung eines relativen Häufigkeitswerts die Häufigkeit des Auftretens von ein oder mehre- ren der von der entsprechenden Trigger-Kombination umfassten Triggern in den Entscheidungsprozess, ob auf Basis der entsprechenden Trigger-Kombination eine zusätzliche kombinierte Trigger-Definition zu ergänzen ist, mit einfließt. Die Häufig- keit des Auftretens der entsprechenden Trigger kann sich wie zuvor im Fall des ab- soluten Häufigkeitswerts auf ein Auftreten der entsprechenden Trigger in allen Da- tensätzen, auf ein durchschnittliches Auftreten in allen Datensätzen, auf ein häufigs- tes Auftreten in einem der Datensätze und/oder auf ein minimales Auftreten in ei- nem der Datensätze beziehen.
Ausführungsformen können den Vorteil haben, dass der relative Häufigkeitswert umso höher gewählt wird, umso höher die Häufigkeiten des Auftretens des ein oder der mehreren entsprechenden von der Trigger-Kombination umfassten Trigger ist. Somit kann vermieden werden, dass eine Trigger-Definition auf der Basis einer Trig- ger-Kombination erzeugt wird, deren Auftreten zufällig ist, d.h. deren Trigger zufällig von demselben Datensatz umfasst sind, ohne dass dies einen Zusammenhang der entsprechenden Trigger anzeigt.
Nach Ausführungsformen umfasst das Kombinationskriterium ein oder mehrere Be- dingungen an relative Positionen der Trigger der entsprechenden Trigger-Kombina- tion zueinander innerhalb eines der Datensätze. Ausführungsformen können den Vorteil haben, dass für das Kombinationskriterium eine relative Position der Trigger der entsprechenden Trigger-Kombination innerhalb des Datensatzes berücksichtigt wird. Eine entsprechende relative Position von Daten innerhalb von Datensätzen re- sultiert aus bzw. ist abhängig von Kontextzusammenhängen. Mithin lassen sich ent- sprechende Kontextzusammenhänge aus der relativen Position ablesen. Abhängig von der Art der von den Datensätzen umfassten Daten kann es sich bei der relati- ven Position um eine relative Position in einer eindimensionalen, d.h. sequenziellen, Datenstruktur, wie beispielsweise einer Text- oder Sprachdatei, einer zweidimensio- nalen Datenstruktur, wie beispielsweise einer Bilddatei, oder einer höher dimensio- nalen, beispielsweise dreidimensionalen oder n-dimensionalen, Datenstruktur han- deln.
Nach Ausführungsformen umfassen die Trigger-Definitionen jeweils eine Definition einer Trigger-Struktur, welche für ein oder mehrere von der entsprechenden Trig- ger-Definition umfasste Trigger und ein oder mehrere gemäß der entsprechenden Trigger-Definition einer der Klassen zuzuordnende Token relative Positionen zuei- nander festlegt.
Ausführungsformen können den Vorteil haben, dass eine entsprechende Trigger- Definition anhand ein oder mehrerer Trigger definiert, wie ein oder mehrere Token zu klassifizieren sind in Abhängigkeit von einer relativen Position der entsprechen- den Token zu den entsprechenden Triggern. Je nach Art der von den Datensätzen umfassten Datenstrukturen kann es sich bei der entsprechenden relativen Position um eine relative Position in einem eindimensionalen, zweidimensionalen oder höher dimensionalen, beispielsweise dreidimensionalen oder n-dimensionalen, Datenraum handeln.
Nach Ausführungsformen umfassen die Festlegungen der relativen Positionen zu- mindest eine der folgenden Festlegungen: die ein oder mehreren zuzuordnenden Token sind nach einem von der entsprechenden Trigger-Definition umfassten Trig- ger angeordnet, die ein oder mehreren zuzuordnenden Token sind vor einem von der entsprechenden Trigger-Definition umfassten Trigger angeordnet, die ein oder mehreren zuzuordnenden Token sind jeweils zwischen von der entsprechenden Trigger-Definition umfassten Triggern angeordnet.
Ein Trigger kann beispielsweise eine Klassifikation vorangehendender Daten trig- gern, z.B.„[davor1 ] [Trigger1 ]“. In diesem Fall triggert das Auftreten des Triggers „Trigger1“ eine Klassifikation der vorangehenden Daten„davor1“. Nach Ausfüh- rungsformen ist der Trigger selbst Bestandteil der Klassifikation, d.h. klassifiziert wird die Kombination„[davor1 ] [Trigger1 ]“. Nach Ausführungsformen wird der Trig- ger„Trigger1“, wenn er erkannt wird, als Trigger der entsprechenden Trigger-Defini- tion zugeordnet.
Ein Trigger kann beispielsweise eine Klassifikation nachfolgender Daten triggern, z.B. ,,[Trigger2] [danach1 ]“. In diesem Fall triggert das Auftreten des Triggers„Trig- ger2“ eine Klassifikation der nachfolgenden Daten„danach1“. Nach Ausführungsfor- men ist der Trigger selbst Bestandteil der Klassifikation, d.h. klassifiziert wird die Kombination ,,[Trigger2] [danach1 ]“. Nach Ausführungsformen wird der Trigger„Trig- ger2“, wenn er erkannt wird, als Trigger der entsprechenden Trigger-Definition zu- geordnet.
Ein Trigger kann beispielsweise eine Klassifikation vorangehender und nachfolgen- der Daten triggern, z.B. ,,[davor2] [Trigger3] [danach2]“. In diesem Fall triggert das Auftreten des Triggers„Trigger3“ eine Klassifikation der vorangehendenden Daten „davor2“ sowie der nachfolgenden Daten„danach2“. Nach Ausführungsformen ist der Trigger selbst Bestandteil der Klassifikation, d.h. klassifiziert wird die Kombina- tion ,,[davor2] [Trigger3] [danach2]“. Nach Ausführungsformen wird der Trigger„Trig- gers“, wenn er erkannt wird, als Trigger der entsprechenden Trigger-Definition zu- geordnet.
Eine Kombination aus zwei oder mehr Trigger kann beispielsweise eine Klassifika- tion vorangehender, nachfolgender sowie zwischen den Triggern angeordneter Da- ten triggern, z.B. ,,[davor3] [Trigger4] [dazwischen1 ] [Trigger5] [danach3]“. In diesem Fall triggert das Auftreten der Kombination aus den Triggern„Trigger4“ und „Trigger5“ eine Klassifikation der vorangehendenden Daten„davor3“, der nachfol- genden Daten„danach3“ sowie der dazwischenstehenden Daten„dazwischen 1“. Nach Ausführungsformen sind die Trigger selbst Bestandteil der Klassifikation, d.h. klassifiziert wird die gesamte Kombination ,,[davor3] [Trigger4] [dazwischen1] [Trig- ger5] [danach3]“. Nach Ausführungsformen werden die Trigger„Trigger4“ und„Trig- ger5“, wenn er erkannt wird, als Trigger der entsprechenden Trigger-Definition zu- geordnet.
Nach Ausführungsformen kann eine Trigger-Kombination eine beliebige Anzahl an Triggern umfassen, z.B. ,,[davor4] [Trigger6] [dazwischen2] [Trigger7] [...] [Trig- ger6+N] [dazwischen2+N] [Trigger6+(N+1 )] [danach4]“. In diesem Fall triggert das Auftreten der Kombination aus den Triggern„Trigger6“ bis„Trigger6+(N+1 )“ eine Klassifikation der vorangehendenden Daten„davor4“, der nachfolgenden Daten„da- nach4“ sowie der dazwischenstehenden Daten„dazwischen2“ bis„dazwi- schen2+N“. Nach Ausführungsformen sind die Trigger selbst Bestandteil der Klassi- fikation, d.h. klassifiziert wird die gesamte Kombination ,,[davor4] [Trigger6] [dazwi- schen2] [Trigger7] [...] [Trigger6+N] [dazwischen2+N] [Trigger6+(N+1 )] [danach4]“. Nach Ausführungsformen werden die Trigger„Trigger6“ bis„Trigger6+(N+1 )“, wenn er erkannt wird, als Trigger der entsprechenden Trigger-Definition zugeordnet.
Im Falle einer Textdatei kann eine beispielhafte Trigger-Definition wie folgt ausse- hen:„[Identität] [Trigger1 = darf über] [Identität] [Trigger2 = und] [Identität]". Bei der Formulierung„darf über" handelt es sich um einen ersten Trigger [Trigger1] und bei der Formulierung„und" um einen zweiten Trigger [Trigger2] Die Struktur entspricht also einer Struktur der Form [davor] [Trigger1 ] [dazwischen] [Trigger2] [danach]. In diesem Fall werden vorangehenden Daten [davor] als eine Identität klassifiziert, ebenso werden dazwischenstehende Daten [dazwischen] sowie nachfolgende Da- ten [danach] jeweils als Identitäten klassifiziert.
Ein weiteres Beispiel ist:„[Trigger = Der Kunde trägt den Schaden,] [Bedingung]".
Bei der Formulierung„Der Kunde trägt den Schaden," handelt es sich um einen Trigger [Trigger]. Die Struktur entspricht mithin der Struktur [Trigger] [danach]. In diesem Fall werden die nachfolgenden Daten [danach] als eine Bedingung klassifi- ziert.
Ein weiteres Beispiel ist:„[Trigger1 = zwischen] [Identität] [Trigger2 = und] [Identi- tät]". Bei der Formulierung„zwischen" handelt es sich um einen ersten Trigger [Trig- gerl ] und bei der Formulierung„und" um einen zweiten Trigger [Trigger2]. Die Struktur entspricht mithin der Form [Trigger1 ] [dazwischen] [Trigger2] [danach]. Um- fasst ein Datensatz beispielsweise die Formulierung:„Die Geschäftsbeziehung zwi- schen dem Kunden und der Bank [...]", so werden die Token„zwischen“ und„und“ als Trigger identifiziert. Anhand dieser Trigger-Kombination werden die dazwischen- stehenden Token„dem Kunden“ als Identität klassifiziert, ebenso wie die nachfol- genden Token„der Bank“. Für die vorangehenden Token„Die Geschäftsbeziehung“ wird durch die Trigger keine Klassifikation getriggert. Mithin werden die vorangehen- den Token als unbekannte Daten der Auffangklasse klassifiziert.
Nach Ausführungsformen kann eine Trigger-Definition festlegen, dass ein Token, welches sich innerhalb eines Radius um einen bestimmten Trigger in einem n-di- mensionalen Datenraum befindet, einer bestimmten Klasse zuzuordnen ist. Nach Ausführungsformen kann neben dem Abstand des Tokens von dem Trigger zudem maßgeblich für die Klassenzuordnung sein, in welcher Raumrichtung der Token von dem Trigger entsprechend beanstandet ist. Dies kann beispielsweise durch einen Vektor definiert werden, welche die relative Position des Tokens zu dem Trigger de- finiert. Nach Ausführungsformen kann eine Trigger-Definition festlegen, dass ein To- ken, welches innerhalb einer Mehrzahl von Radien um jeweils einen Trigger einer Mehrzahl von Trigger angeordnet ist, einer bestimmten Klasse zuzuordnen ist. Hier- bei überschneiden sich die von den einzelnen Radien begrenzten n-dimensionalen Bereiche und begrenzen einen n-dimensionalen oder niedriger dimensionalen Schnittbereich in dem n-dimensionalen Datenraum. Ein Token, welches Bestandteil dieses n-dimensionalen oder niedriger dimensionalen Schnittbereich ist, wird bei- spielsweise einer bestimmten Klasse zugeordnet. Nach Ausführungsformen ist für die Trigger gemäß den Trigger-Definitionen jeweils ein maximaler Trigger-Abstand festgelegt, welcher einen maximalen Abstand relativ zu dem entsprechenden Trigger definiert, auf welche eine Trigger-Wirkung des Trig- gers beschränkt ist.
Ausführungsformen können den Vorteil haben, dass es sich bei dem entsprechen- den maximalen Abstand um einen Radius um den entsprechenden Trigger in einem n-dimensionalen Datenraum handelt. Im Falle eines eindimensionalen Datenraums beschränkt sich die Trigger-Wirkung auf den entsprechenden maximalen Trigger- Abstand vor und hinter dem entsprechenden Trigger. Im Fall eines zweidimensiona- len Datenraums beschränkt sich die Trigger-Wirkung auf eine zweidimensionale Kreisfläche um den entsprechenden Trigger herum. Im Falle eines dreidimensiona- len Datenraums beschränkt sich die Trigger-Wirkung auf ein Kugelvolumen um den entsprechenden Trigger herum. Im Falle eines n-dimensionalen Datenraums be- schränkt sich die Trigger-Wirkung auf ein Volumen einer n-dimensionalen Kugel um den entsprechenden Trigger herum.
Nach Ausführungsformen kann der maximale Abstand von der Raumrichtung ab- hängen und in unterschiedlichen Raumrichtungen unterschiedlich groß festgelegt sein.
Nach Ausführungsformen ist der maximale Trigger-Abstand für alle Trigger iden- tisch. Nach Ausführungsformen ist der maximale Trigger-Abstand für eine Teil- menge der Trigger identisch. Nach Ausführungsformen ist der maximale Trigger-Ab- stand für jeden Trigger jeweils individuell bestimmt. Bei dem entsprechenden maxi- malen Trigger-Abstand kann es sich je nach Art der Daten um einen Abstand in ei- ner bestimmten Einheit handeln. Beispielsweise handelt es sich bei einer zeitlichen sequenziellen Abfolge um einen zeitlichen Abstand gemessen in einer zeitlichen Einheit, wie etwa Millisekunden, Sekunden oder Minuten. Beispielsweise handelt es sich bei einem eindimensionalen, zweidimensionalen oder dreidimensionalen räum- lichen Datenstruktur um einen räumlichen Abstand in einer räumlichen Einheit, wie etwa Millimeter, Zentimeter, Dezimeter oder Meter. Im Falle von Bild- oder Videodaten kann der Abstand beispielsweise auf Pixel oder Voxel beruhen. Somit kann es sich bei einem entsprechenden Abstand beispielsweise um eine Pixelzahl oder eine Voxelzahl handeln.
Nach Ausführungsformen handelt es sich bei dem Abstand um einen logischen Ab- stand. Dieser kann beispielsweise auf elementaren Datenelementen beruhen, wie beispielsweise Elementarzeichen. Somit kann es sich bei einem entsprechenden Abstand beispielsweise um eine Zeichenzahl handeln. Ferner kann es sich bei dem entsprechenden Abstand um eine Anzahl aus elementaren Datenelementen um zu- sammengesetzte Elemente handeln, wie beispielsweise einer Wortanzahl. Bei- spielsweise ist die Anzahl auf eine bestimmte Wortart beschränkt. Ferner kann der Abstand durch logische Elemente in der Datenstruktur begrenzt werden, wie bei- spielsweise ein Interpunktionszeichen und/oder einen Trigger.
Nach Ausführungsformen umfasst das Verfahren ferner:
• Ergänzen des vortrainierten Lernmoduls um ein oder mehrere zusätzliche Trig- ger-Definitionen, welche zusätzliche Trigger für ein Ersetzen von Zuordnungen von Token in dem Index zu der Auffangklasse durch Zuordnungen zu ein oder mehreren Klassen einer zweiten Gruppe von Klassen im Zuge eines Reklassi- fizierens definieren,
• Reklassifizieren von ein oder mehreren der Auffangklasse zugeordneten To- ken in dem Index, welche die zusätzlichen Trigger-Definitionen als zusätzliche Trigger definierten, wobei das Reklassifizieren durch das Lernmodul ein Erset- zen der Zuordnung zu der Auffangklasse durch eine Zuordnung zu der ent- sprechen zusätzlichen Trigger-Definition umfasst, welche das entsprechende Token als zusätzlichen Trigger umfasst,
• Verwenden der zusätzlichen Trigger zum Reklassifizieren von ein oder mehre- ren der Auffangklasse zugeordneten Token in dem Index zu ein oder mehre- ren Klassen der zweiten Gruppe von Klassen durch das Lernmodul, falls die entsprechenden der Auffangklasse zugeordneten Token von einem der Da- tensätze in einer Kombination mit ein oder mehreren der zusätzlichen Triggern umfasst sind und die entsprechenden zusätzlichen Trigger gemäß der entsprechenden zusätzlichen Trigger-Definition eine entsprechende Zuord- nung zu den ein oder mehreren Klassen der zweiten Gruppe von Klassen trig- gern.
Ausführungsformen können den Vorteil haben, dass durch das Ergänzen des Lern- moduls um zusätzliche Trigger-Definitionen die Anzahl der Token, welche der Auf- fangklasse zugeordnet sind, reduziert werden kann. Zusätzliche Trigger-Definitionen können gezielt ergänzt werden, um solche Token zu reklassifizieren, welche der Auffangklasse zugeordnet sind. Mithin kann das Ergänzen zusätzlicher Trigger-Defi- nitionen in Abhängigkeit von den Datensätzen, welche die entsprechende Einzelda- tenbank umfasst, und den von diesen umfassten unbekannten Daten erfolgen.
Beispielsweise werden zusätzliche Trigger-Definitionen ergänzt, bis alle Token der Auffangklasse reklassifiziert sind. Nach Ausführungsformen werden entsprechende zusätzliche Trigger-Definitionen nach vordefinierten Intervallen ergänzt. Entspre- chende vordefinierte Intervalle sind beispielsweise zeitlich definiert, basierend auf der Anzahl der von der Auffangklasse umfassten Token, der in der entsprechenden Einzeldatenbank gespeicherten Datenmenge und/oder der zu der entsprechenden Einzeldatenbank seit der letzten Ergänzung hinzugefügten Datenmenge.
Nach Ausführungsformen umfasst die zweite Gruppe von den Klassen der ersten Gruppe verschiedene Klassen. Ausführungsformen können den Vorteil haben, dass zusätzliche Klassen definiert werden, sodass solche die Token der Auffangklasse klassifiziert werden können, für welche die Meta- bzw. Kontextinformationen ent- sprechend den Klassen der ersten Gruppe nicht anwendbar sind. Vielmehr können durch die Klassen der zweiten Gruppe zusätzliche Meta- bzw. Kontextinformationen definiert und verwendet werden.
Nach Ausführungsformen sind ein oder mehrere Klassen der zweiten Gruppe je- weils identisch mit einer der Klassen der ersten Gruppe. Ausführungsformen kön- nen den Vorteil haben, dass durch die zusätzlichen Trigger-Definitionen Trigger bereitgestellt werden, welche eine Zuordnung der Token der Auffangklasse zu Klas- sen der ersten Gruppe von Klassen ermöglichen.
Nach Ausführungsformen sind die zu ergänzenden Trigger-Definitionen als Ergän- zungen jeweils von einer von dem Lernmodul bereits umfassten Trigger-Definition abhängig. Ausführungsformen können den Vorteil haben, dass ein oder mehrere der ergänzenden Trigger-Definitionen in Form von Ergänzungen zu den bereits um- fassten Trigger-Definitionen des Lernmoduls definiert werden. Die entsprechenden ergänzenden Trigger-Definitionen erweitern beispielsweise die Trigger-Wirkung be- reits bestehender Trigger-Definitionen. Nach Ausführungsformen bilden die ergän- zenden Trigger-Definitionen mit den bereits bestehender Trigger-Definitionen kom- binierte Trigger-Definitionen.
Nach Ausführungsformen werden die Ergänzungen einem rekursiven Schema fol- gend wiederholt ausgeführt, wobei die zu ergänzenden Trigger-Definitionen jeder Rekursionsstufe jeweils Ergänzungen einer Trigger-Definition einer vorangehenden Rekursionsstufe umfassen, sodass die rekursiven Ergänzungen Baumstrukturen bil- den, welche jeweils eine der vorbestimmten Trigger-Definition als Wurzelknoten um- fassen.
Ausführungsformen können den Vorteil haben, dass die Trigger-Wirkung der beste- henden Trigger-Definitionen sukzessive durch ein fortschreitendes Rekursions- schema erweitert werden, bis alle Token der Auffangklasse reklassifiziert sind. Das Ergebnis der entsprechenden Ergänzungen der bereits bestehenden Trigger-Funkti- onen können beispielsweise Baumstrukturen sein, denen folgend eine Klassifikation von Token implementiert werden kann.
Nach Ausführungsformen werden die zu ergänzenden zusätzlichen Trigger-Definiti- onen von dem Lernmodul empfangen. Ausführungsformen können den Vorteil ha- ben, dass die entsprechenden Trigger-Definitionen beispielsweise von außen, etwa durch einen Administrator, bereitgestellt werden können. Mithin hat der entsprechende Administrator stets die Möglichkeit, die Klassifikation zu steuern, zu korrigieren und zu ergänzen.
Nach Ausführungsformen kann erfolgt optional oder fakultativ ein externes Feinjus- tieren, beispielsweise durch einen Administrator, erfolgen. Hierbei werden nach Ausführungsformen unter Verwendung zusätzliche Trigger-Definitionen aus der Klasse der unbekannten Daten, d.h. der Auffangklasse, Token extrahiert und beste- henden Klassen zugeordnet und/oder es werden neue Klassen generiert, denen extrahierte Token zugordnet werden. Ein Administrator stellt beispielsweise für die in der Auffangklasse als unbekannte Daten klassifizierten Token anlog zu den initia- len bereitgestellten Trigger-Definitionen zusätzliche Trigger-Definitionen bereit, wel- che auf die Auffangklasse angewandt werden. Nach Ausführungsformen werden die zusätzlichen Trigger gemäß den zusätzlichen Trigger-Definitionen ausschließlich auf die Auffangklasse angewendet sowie auf zukünftig empfangene Daten. Nach Ausführungsformen kann die Anwendung eines zusätzlichen Triggers als IF- Bedingung realisiert werden. Wurde beispielsweise auf einen Datensatz bereits ein anderer Trigger erfolgreich angewendet, z.B. ein Trigger1 , und der Datensatz um- fasst zudem als unbekannt klassifizierte Daten, wo wird ein zusätzlicher Trigger, z.B. ein Trigger2, gemäß einer der zusätzlichen Trigger-Definitionen angewendete.
Dieses Feinjustieren kann als eine Rekursion mehrmals wiederholt werden. Bei- spielsweise wird die Rekursion solange fortgesetzt, bis Die Auffangklasse keine To- ken mehr umfasst, d.h. keine unbekannten Daten mehr existieren, oder die von der Auffangklasse umfasste Token-Anzahl einen vordefinierten Schwellenwert erreicht und/oder unterschreitet, d.h. eine vordefinierte Maximalzahl. Bei dem entsprechen- den Schwellenwert kann es sich um einen absoluten Wert handeln, welcher von der Anzahl der von dem Index umfassten Token und der von der entsprechenden Ein- zeldatenbank umfassten Datenmenge unabhängig ist. Alternativ kann es sich bei dem entsprechenden Schwellenwert um einen relativen Wert handeln, welcher von der Anzahl der von dem Index umfassten Token und/oder der von der entsprechen- den Einzeldatenbank umfassten Datenmenge abhängig ist Auf diese Weise können Trigger-Bäume bzw. Entscheidungsbäume hinter den initial definierten Trigger bzw. Trigger-Definitionen entstehen, wobei die Anzahl der Ebe- nen von der Anzahl der Rekursionen N abhängt, z.B. ist die Anzahl der Ebenen gleich N+1. Beispielsweise bildet jeder initiale Trigger bzw. jede initiale Trigger-Defi- nitionen einen Wurzelpunkt eines entsprechenden Trigger-Baums bzw. Entschei- dungsbaum. Unter einem Entscheidungsbäumen werden hier geordnete, gerichtete Bäume verstanden, die der Darstellung von Entscheidungsregeln dienen. Umfasst ein Datensatz einen initialen Trigger, wodurch ein Teil der Token des Datensatzes klassifiziert werden kann, ohne dass dadurch zugleich alle Token des Datensatzes klassifiziert werden können, so wird geprüft, ob der Datensatz zudem einen Trigger der ersten Rekursion umfasst. Falls der Datensatz einen Trigger der ersten Re- kursion umfasst, wodurch ein weiterer Teil der Token des Datensatzes klassifiziert werden kann, ohne dass dadurch zugleich alle Daten des Datensatzes klassifiziert werden können, so wird geprüft, ob der Datensatz zudem einen Trigger der zweiten Rekursion umfasst und so fort.
Nach Ausführungsformen werden die zu ergänzenden zusätzlichen Trigger-Definiti- onen von dem Lernmodul erstellt, welches ein statistisches Modell umfasst, wobei das statistische Modell zu einer statistischen Analyse der von der Auffangklassen umfassten Token und deren Vorkommen in den Datensätze verwendet wird, wobei das Ergebnis der statistischen Analyse zum Erstellen der zu ergänzenden zusätzli- chen Trigger-Definitionen verwendet wird.
Ausführungsformen können den Vorteil haben, dass das Lernmodul selbstständig ergänzende zusätzliche Trigger-Definitionen erstellen kann. Beispielsweise erfolgt das zuvor beschriebene optionale oder fakultative Feinjustieren unter Verwendung des statistischen Modells. Durch ein Verwenden eines statistischen Modells kann die zuvor beschriebene menschliche Handlung eines Administrators ersetzt und/o- der verbessert werden. Nach Ausführungsformen identifiziert das statistische Mo- dell, z.B. durch Häufigkeitsanalysen und Korrelationsanalysen, Trigger innerhalb der unbekannten Daten, welche dann analog zu dem zuvor beschriebenen Vorgehen auf die als unbekannt klassifizierten Token angewendet werden. Nach Ausführungsformen kann zudem ein rekursives Vorgehen unter Verwendung des statistischen Modells erfolgen.
Nach Ausführungsformen umfasst das Verfahren ferner:
• Empfang einer korrigierten Trigger-Definition zum Ersetzen einer der gespei- cherten Trigger-Definitionen des Lernmoduls,
• Ersetzen der entsprechenden gespeicherten Trigger-Definition durch die korri- gierte Trigger-Definition,
• Reklassifizieren der unter Verwendung der entsprechenden gespeicherten Trigger-Definition klassifizierten Token, wobei das Reklassifizieren unter Ver- wendung der korrigierten Trigger-Definition erfolgt.
Nach Ausführungsformen kann beispielweise ein Administrator Fehler in klassifizier- ten Klassen erkennen und gegebenenfalls korrigieren, etwa indem er eine korrigier- ten Trigger-Definition, anhand derer ein Reklassifizieren von Token erfolgt. Ausfüh- rungsformen können den Vorteil haben, dass eine Korrektur von Trigger-Definitio- nen zu jedem Zeitpunkt des Verfahrens ermöglicht wird. Beispielsweise kann eine Überprüfung der Trigger-Definitionen nach dem Training des Lernmoduls erfolgen. Werden Korrektur-Trigger-Definitionen identifiziert, so werden entsprechend korri- gierte Trigger-Definitionen bereitgestellt.
Ausführungsformen können den Vorteil haben, dass korrigierte Trigger-Definitionen auch zu einem späteren Zeitpunkt bereitgestellt werden können, wenn Fehlklassifi- kationen erkannt werden. Ein administratives Eingreifen in den Lern- und Klassifizie- rungsprozess ist somit zu jedem Zeitpunkt möglich. Dadurch können Fehler des ler- nenden Systems behoben werden, ohne dass das komplette Modell umgebaut wer- den muss.
Nach Ausführungsformen verweisen die Zeiger, mit denen die Token in dem Index verknüpft gespeichert sind, jeweils auf ein oder mehrere der Feldwerte in den ge- speicherten Datensätze. Ausführungsformen können den Vorteil haben, dass eine feinere Granularität bei der Bestimmung des Ursprungs von Token in den Datensätzen erzielt werden kann. Eine solche feinere Granularität ermöglicht es zudem relative Beziehungen der To- ken innerhalb der Datensätze aufzuschlüsseln und bei einer Analyse oder sonstigen Verwendung des Index zu berücksichtigen.
Nach Ausführungsformen umfassen die Feldwerte des zusätzlichen Datensatzes Textdaten, Bilddaten, Audiodaten und/oder Videodaten. Nach Ausführungsformen ist das Verfahren beispielsweise anwendbar zur Signalverarbeitung, wie etwa 1 D- Audioerkennung, 2D- und 3D-Bildverarbeitung, oder ND-Dateninput von N Senso- ren etc. Ferner ist das Verfahren beispielsweise anwendbar bei einer Analyse von Stream-Daten (Bitstream bzw. Bitstrom). Ein Bitstream, auch als Bitstrom bekannt, bezeichnet hier eine Folge von Bits, die einen Informationsfluss repräsentieren, d.h. ein serielles bzw. sequentielles Signal. Ein Bitstrom ist somit eine Sequenz von Bits von unbestimmter Länge in zeitlicher Abfolge. Ein Bitstrom stellt beispielsweise ei- nen in logische Strukturen gegliedert Datenstromes dar, der sich in grundlegendere Kleinstrukturen wie Symbole fester Größe, d.h. Bits und Bytes, und weiter in Blöcke und Datenpakete unterschiedlicher Protokolle und Formate gliedern kann.
Nach Ausführungsformen umfasst das Erzeugen der Token ein Anwenden einer To- kenisierungslogik auf die Feldwerte des zusätzlichen Datensatzes, welche einen Volltextindizierer umfasst, der dazu konfiguriert ist, Texte in Wörter zu zerlegen und die Wörter als Token auszugeben. Ausführungsformen können den Vorteil haben, dass eine effektive Tokenisierung von Texten bzw. Textdateien implementiert wer- den kann. Bei entsprechenden Textdateien kann es sich um beliebige Texte han- delnden. Beispielsweise kann es sich bei entsprechenden Textdateien um Mess- wertdateien oder Algorithmen zum Steuern von Computern und/oder technischen Anlagen handeln. Nach Ausführungsformen umfassen die Feldwerte des zusätzli- chen Datensatzes Volltexte, wobei die Volltexte aus Buchstaben eines oder mehre- rer Alphabete gebildete Wörter und/oder ein oder mehrere Zahlen umfassen. Eine Volltextindizierung beinhaltet eine Zerlegung von Texten in einzelne Wörter, wobei dann die einzelnen Wörter eines Textfeldes in einem diesem Feld zugeordne- ten Index gespeichert werden. Volltextindexierung wird nur unterstützt, wenn das entsprechende Feld zur selektiven Speicherung eines bestimmten Datentyps, z.B. CFIAR, VARCFIAR oder TEXT, konfiguriert ist. Beispielsweise kann in einem Feld natürlichsprachlicher Text im JSON Format gespeichert sein.
Nach Ausführungsformen umfasst das Erzeugen der Token ein Anwenden einer To- kenisierungslogik auf die Feldwerte des zusätzlichen Datensatzes, welche einen ge- nerischen Tokenisierer umfasst, der dazu konfiguriert ist, in den Feldwerten Daten unterschiedlichen Datentyps zu erkennen und aus diesen Token in unterschiedli- chen Datentypen zu erzeugen. Ausführungsformen können den Vorteil haben, dass eine effektive Tokenisierung für unterschiedliche Datentypen implementiert werden kann, wie etwa Textdaten, Bilddaten, Audiodaten und/oder Videodaten.
Nach Ausführungsformen umfasst das Verfahren ferner:
• Empfangen eines von einer dritten Einzeldatenbank als zusätzlicher Quellda- tenbank erzeugten weiteren Ergänzungsdatensatzes durch die erste Einzelda- tenbank über das Netzwerk, wobei der weitere Ergänzungsdatensatz in einem Index der zusätzlichen Quelldatenbank vorgenommenen Ergänzungen um- fasst,
• Integrieren des weiteren Ergänzungsdatensatzes in den Index der ersten Ein- zeldatenbank, wobei das Integrieren ein Ergänzen des entsprechenden Index umfasst, bei welchem
o ein Abgleichen von Token des weiteren Ergänzungsdatensatzes mit dem Index der Quelldatenbank,
o falls eines der Token des weiteren Ergänzungsdatensatzes nicht von dem Index der Quelldatenbank umfasst ist, Ergänzen des entsprechenden To- kens in dem Index der Quelldatenbank und Verknüpfen des entsprechen- den Tokens in dem Index mit einem Zeiger auf den in einem dokumenten- orientierten Datenmodell der zusätzlichen Quelldatenbank gespeicherten Datensatz, aus welchem das entsprechende Token erzeugt wurde, o falls eines der Token des weiteren Ergänzungsdatensatzes von dem Index der Quelldatenbank umfasst ist, Verknüpfen des entsprechenden Tokens in dem Index der Quelldatenbank mit dem Zeiger auf den in einem doku- mentenorientierten Datenmodell der zusätzlichen Quelldatenbank gespei- cherten Datensatz, aus welchem das entsprechende Token erzeugt wurde.
Ausführungsformen können den Vorteil haben, dass auch der Index der Quelldaten- bank durch Ergänzungsdatensätze anderer Einzeldatenbanken erweitert werden kann. Bei der dritten Einzeldatenbank handelt es sich beispielsweise um eine Ein- zeldatenbank, welche wiederum Ergänzungsdatensätze der Quelldatenbank emp- fängt. Somit können Änderungen der Indexe zwischen Einzeldatenbanken gegen- seitig ausgetaucht und einheitliche Kopien eines datenbankübergreifenden Index auf einem verteilten Datenbanksystem, genauer gesagt in den Einzeldatenbanken implementiert werden.
Nach Ausführungsformen umfasst das Verfahren ferner:
• Empfangen einer Suchanfrage durch erste Einzeldatenbank, wobei die Such- anfrage einen oder mehrere Suchwerte beinhaltet,
• Durchsuchen des Index der ersten Einzeldatenbank nach dem Suchwert,
• Identifizieren ein oder mehrerer Token innerhalb des Index, welche mit einem oder mehreren der Suchwerte übereinstimmen,
• Zurückgeben einer Antwort auf die Suchanfrage, wobei die Antwort zumindest umfasst: eine Angabe über die identifizierten Token, ein oder mehrere durch Analysieren von Zeigern, mit denen die identifizierte Token verknüpft sind, be- stimmten Datensätze oder ein oder mehreren Referenzen auf die bestimmten Datensätze.
Ausführungsformen können den Vorteil haben, dass der Index für effektive Suchen verwendet werden kann. Dabei können sich die Suchen auf Informationen des In- dex beschränken, etwa in wie vielen oder in welchen Datensätzen ein bestimmter Suchwert vorkommt. Hierfür ist nach Ausführungsformen eine Indexzugriffs- Berechtigung notwendig. Ferner kann so auch eine Suche auf den Datensätzen der lokalen, d.h. die Suche ausführenden, Einzeldatenbank erfolgen, obwohl die Da- tensätzen in ihrer ursprünglichen Form gespeichert sind. Hierfür ist nach Ausfüh- rungsformen eine Lesezugriffs-Berechtigung notwendig. Flandelt es sich um Da- tensätze, welche auf einer anderen Einzeldatenbank gespeichert sind, so können diese explizit zum Lesen angefragt werden. Hierfür ist nach Ausführungsformen wiederum eine Lesezugriffs-Berechtigung notwendig.
Im Fall des Lernmoduls, kann dieses beispielsweise unter Verwendung entspre- chender Suchanfragen Muster und/oder Gesetzmäßigkeiten innerhalb der Datens- ätze suchen.
Nach Ausführungsformen speichert der Index sämtliche aus den Feldwerten der Da- tensätze einer entsprechenden Einzeldatenbank erzeugte Token so, dass der Index jedes Token nur einmal enthält. Jedes Token beinhaltet Zeiger auf ein oder mehrere der Datensätze, aus deren Feldwerten es erzeugt wurde. Wenn ein erfindungsge- mäß erzeugter Index also nach einem bestimmten Suchwert durchsucht wird und als Ergebnis der Suche ein in dem Index gespeichertes Token identifiziert wird, wel- ches identisch ist mit dem Suchwert, so verweist dieses Token mittels Zeigern auf sämtliche Datensätze, die dieses Token zumindest einmal in zumindest einem ihrer Feldwerte enthalten und die bei der Erstellung des Index herangezogen wurden. Die Datensätze, die also einen„Treffer“ im Hinblick auf den Suchwert darstellen, können anhand der Verweise sehr schnell identifiziert und zurückgegeben werden, ohne dass ein sequenzieller Suchlauf über sämtliche Datensätze notwendig wäre.
Nach Ausführungsformen umfasst der Suchwert ferner eine Klassenzuordnung und das Identifizieren des Tokens innerhalb des Index erfordert ferner, dass das identifi- zierte Token dieselbe Klassenzuordnung aufweist. Ausführungsformen könne den Vorteil haben, dass Klassenzuordnungen und dadurch mit den Klassenzuordnungen indexierte Meta- bzw. Kontextinformationen in den Suchanfragen berücksichtigt werden können. Nach Ausführungsformen sind Trigger in dem Index mit einem Flag gekennzeichnet. Nach Ausführungsformen umfasst der Suchwert ferner eine Zuordnung zu einer Trigger-Definition und/oder ein einen Trigger kennzeichnendes Flag und das Identi- fizieren des Tokens innerhalb des Index erfordert ferner, dass das identifizierte To- ken derselben Trigger-Definition zugeordnet ist und/oder dasselbe Flag aufweist.
Nach Ausführungsformen werden Token, welche der Auffangklasse zugeordnet sind, von der Suche ausgeschlossen. Ausführungsformen können den Vorteil ha- ben, dass die resultierenden Suchergebnisse ein hohes Maß an Zuverlässigkeit auf- weisen, da unbekannte Daten von der Suche ausgeschlossen sind.
Nach Ausführungsformen umfasst das Verfahren ferner das Vortrainieren des Lern- moduls. Das Vortrainieren umfasst:
• Empfangen der Mehrzahl von vorbestimmten Trigger-Definitionen durch das Lernmodul, welche die Trigger für das Zuordnen von Token zu den Klassen der ersten Gruppe von Klassen definieren,
• Speichern der empfangenen Mehrzahl von vorbestimmten Trigger-Definitionen durch das Lernmodul.
Nach Ausführungsformen werden durch die vorbestimmten Trigger-Definitionen ini- tial Trigger definiert, die dazu verwendet werden empfangene Daten zu strukturieren bzw. klassifizieren. Nach Ausführungsformen werden, bevor Daten in die Quellda- tenbank geladen werden, die initialen Trigger konkret definiert, d.h. vorbestimmten Trigger-Definitionen vorgegeben. Werden Daten geladen, so ermöglichen diese initi- alen Trigger eine erste Klassifizierung nach bekannten Klassen sowie unbekannten Daten, welche der Auffangklasse zugeordnet werden.
Nach Ausführungsformen umfasst das Vortrainieren ferner:
• Extrahieren der Trigger aus der gespeicherten Mehrzahl von vorbestimmten Trigger-Definitionen durch das Lernmodul,
• Zuordnen der initialen Token durch das Lernmodul jeweils zu der Trigger-Defi- nition, welche das entsprechende initiale Token als Trigger umfasst, • Erzeugen des durchsuchbaren Index unter Verwendung der Mehrzahl von initi- alen Token durch das Multi-Modell-Datenbankmanagementsystem in dem wei- teren Datenmodell, wobei der erzeugte Index die initialen Token umfasst, wo- bei jedes der initialen Token in dem Index jeweils eine Zuordnung aufweist zu der Trigger-Definition, welche das entsprechende initiale Token als Trigger umfasst.
Nach der Definition der Trigger, werden Daten, z.B. Textdaten, Audiodaten, Bildda- ten, Videodaten oder N-Dimensionale Daten von N Sensoren, in die Quelldatenbank geladen und die Trigger angewandt, um die Daten automatisch zu klassifizieren. Dadurch entsteht eine Fragmentierung der Daten in Trigger, bekannte Klassen, d.h. durch die Trigger-Definitionen definieret Klassen, und in unbekannte Daten.
Ausführungsformen können den Vorteil haben, dass das Lernmodul auf diese Weise effektiv vortrainiert werden kann auf Basis der vorbestimmten Trigger-Defini- tionen.
Dieses vorbestimmten Trigger-Definitionen können als Grundlage für ein Erlangen weiterer Trigger-Definitionen dienen, etwa durch ein Kombinieren von Trigger-Defi- nitionen. Es erfolgt beispielsweise eine automatische Lernphase des Datenbanksys- tems bzw. des Lernmoduls, welche ein Kombinieren von der initialen Triggern um- fasst. Somit können die initial geladenen Trigger wie zuvor beschrieben basierend auf den von den Datensätzen umfassten Daten kombiniert und damit die Anzahl an zur Verfügung stehenden Trigger-Definitionen erhöht werden. Zudem kann ein Kennzeichnen von bereits klassifizierten Token-Kombination erfolgen. Dies dient dem Zweck, dass identische Daten die später in die Quelldatenbank geladen wer- den, nicht erneut klassifiziert werden müssen, sondern in dem System bereits als „bekannt" markiert sind.
Nach Ausführungsformen umfasst das Erzeugen eines der zusätzlichen Token ein Verwenden eines der Feldwerte des zusätzlichen Datensatzes in seiner Gesamtheit als das entsprechende zusätzliche Token. Es ist durchaus möglich, dass der Index auch Token aus Feldern beinhaltet, auf die keine Tokenisierung angewandt wird bzw. deren Inhalt sich schlichtweg nicht in einzelne Token aufteilen lässt. Nach Aus- führungsformen umfasst das Erzeugen eines der zusätzlichen Token ein Aufteilen eines der zusätzlichen Feldwerte des zusätzlichen Datensatzes in eine Mehrzahl von Teilfeldwerten und eine Verwenden eines der Teilfeldwerte als das entspre- chende zusätzliche Token. Ausführungsformen können den Vorteil haben, dass die Granularität der verwendeten Daten bzw. der Tokenisierung unabhängig von der Granularität der Felder angepasst werden kann.
Nach Ausführungsformen speichert der Index sämtliche aus den Feldwerten der ge- speicherten Datensätze erzeugten Token so, dass der Index jedes Token für jede der Token-Zuordnungen des entsprechenden Tokens genau einmal enthält.
Nach Ausführungsformen können die Token, die Klassen-Zuordnungen und die Zu- ordnung zu den Trigger-Definitionen in Form von Relationen oder äquivalenten Strukturen gespeichert sein. Unter einer Relation wird hier im Sinn der relationalen Datenbanktheorie eine Menge von Tupel. Ein Tupel ist eine Menge von Attributwer- ten. Ein Attribut bezeichnet einen Datentyp bzw. eine ein oder mehreren Daten zu- geordnete Eigenschaft. Dabei bestimmt die Anzahl der Attribute den Grad, die An- zahl der Tupel die Kardinalität einer Relation.
Nach Ausführungsformen handelt es sich zumindest bei dem von dem Multi-Modell- Datenbankmanagementsystem zum Speichern der Datensätze verwendeten doku- mentenbasierten Datenmodellen um ein NoSQL-Datenmodellen. Nach Ausfüh- rungsformen handelt es sich bei dem DBMS um ein NoSQL-DBMS. Dies kann vor- teilhaft sein, dass da sich herausgestellt hat, dass insbesondere NoSQL-DBMS, die oftmals eine flexiblere Struktur aufweisen als klassische SQL-basierte DBMSs. Auf- grund der Flexibilität ihrer Struktur eignen in sich NoSQL-DBMSs also ganz beson- ders für die Verwaltung und Speicherung von Datensätzen, aus welchen ein Index gemäß Ausführungsformen der Erfindung erstellt werden kann. Nach Ausführungsformen weist der Index die Struktur eines Baums auf, insbeson- dere eines B+-Baums. Ausführungsformen können den Vorteil haben, dass eine Baumstruktur insbesondere die Struktur eines B+-Baums, eine besonders effiziente und schnelle Suche nach den in dem Index gespeicherten Token ermöglicht. Unter einem B+-Baum wird eine Daten- und/oder Indexstruktur, welche eine Erweiterung eines B-Baumes darstellt. Bei einem B+-Baum werden die eigentlichen Datenele- mente nur in den Blattknoten gespeichert, während die inneren Knoten lediglich Schlüssel enthalten.
Nach Ausführungsformen umfassen mehrerer der in einem dokumentenorientierten Datenmodell gespeicherten Datensätze jeweils eine unterschiedliche Anzahl an Fel- der. Ausführungsformen können den Vorteil haben, dass Datensätze unterschiedli- cher Größen und Strukturierung bzw. Granularität verarbeitet werden können.
Nach Ausführungsformen weisen die Felder jeweils ein gemeinsames, generisches Datenformat auf. Ausführungsformen können den Vorteil haben, dass, da in einem bestimmten Feld eine große Anzahl an unterschiedlichen Datentypen gespeichert werden können. Ein Nutzer bzw. ein Applikationsprogramm, welches Datensätze in der Quelldatenbank speichern will, muss sich also nicht um die Konsistenz und Pas- sung von Datentypen kümmern. Mithin wird kann ein hoher Grad an Flexibilität be- züglich der Struktur und des Umfangs der Datensätze, die von dem Multi-Modell- Datenbankmanagementsystem verwaltet und gespeichert werden können, geboten werden.
Nach Ausführungsformen ist das Lernmodul bzw. das von diesem implementierte maschinelle Lernen konfiguriert für eine Datenextraktion, Konsistenzprüfung, Bilder- kennung, Spracherkennung, Sprachsteuerung, Vorrichtungsüberwachung und/oder autonome Vorrichtungssteuerung. Dies kann beispielsweise bereits in der Klassifi- zierung der Token bestehen, wobei der Auffangklasse als unbekannte Daten zuge- ordnete Token beispielsweise als ein Hinweis etwa auf eine potentielle Fehlfunktion betrachtet werden. Beispielsweise kann dies auf dem Index mit den Token und de- ren Meta- bzw. Kontextinformationen beruhen, welche als Grundlage für einen darauf angewandten zusätzlichen Algorithmus zum maschinellen Lernen dienen. Nach Ausführungsformen wird hierzu die Auffangklasse durch ein Ergänzen zusätz- licher Trigger-Definitionen geleert, sodass zu allen Token des Datenbanksystems Meta- bzw. Kontextinformationen bereitgestellt werden.
Eine Datenextraktion kann beispielsweise ein Erkennen und Extrahieren eines Mus- ters in einer Text-, Bild-, Audio- oder Videodatei umfassen. Dieses Muster kann bei- spielsweise durch eine Trigger-Definition definiert sein oder in den klassifizierten Daten erfasst werden. Ein entsprechendes Muster kann beispielsweise ein vorbe- stimmtes in Form von Sensorwerten erfasstes Ereignis sein, etwa eine Person in ei- nem Wirkbereich einer Vorrichtung.
Eine Konsistenzprüfung kann beispielsweise eine Konsistenzprüfung in einer Text-, Bild-, Audio- oder Videodatei umfassen. Hierbei wird beispielsweise geprüft, ob die entsprechenden Daten unbekannte und damit inkonsistente Daten umfassen, von den restlichen Daten stark abweichende Daten oder als inkonsistent explizit vordefi- nierte Daten umfassen. Eine entsprechende Konsistenzprüfung kann beispielsweise zur Fehlerprüfung von Steuerungsalgorithmen von Vorrichtungen dienen, zur Fehl- funktionserkennung unter Verwendung von Messdaten einer Funktion einer Vorrich- tung oder zum Erkennen von Fehlern in Textdateien, etwa in Form einer Recht- schreibprüfung.
Eine Bilderkennung kann einem Erkennen von Gegenständen, Ereignissen oder Merkmalen in Bild- oder Videodateien dienen. Beispielsweise werden Kontextinfor- mationen zu dem visuell Dargestellten erfasst und/oder dargestellt. Dies kann bei- spielsweise eine visuelle Darstellung von Informationen, also die Ergänzung von Bil- dern oder Videos mit computergenerierten Zusatzinformationen oder virtuellen Ob- jekten mittels Einblendung/Überlagerung, umfassen. Ein solches Verfahren wird all- gemeine als erweiterter Realität oder Augmented Reality bezeichnet. Eine Spracherkennung kann einem Erkennen von Sprache in Audiodateien oder Vi- deodateien, etwa zur Sprachsteuerung oder zum Überführen von Sprache in Text- form, dienen.
Eine Mustererkennung in Text-, Bild-, Audio- oder Videodatei kann einer Vorrich- tungsüberwachung dienen. Insbesondere können so auftretende oder drohende Fehlfunktionen erkannt werden. Dies kann der Sicherheit dienen und ermöglicht eine vorausschauende Wartung (Predictiv Maintenance) der entsprechenden Vor- richtung, da potentielle Probleme frühzeitig erkannt werden können. Bei einer ent- sprechenden Textdatei handelt es sich beispielswiese um einen Datensatz mit Sen- sormesswerten. Basierend auf einer Vorrichtungsüberwachung kann zudem eine autonome Vorrichtungssteuerung implementiert werden, etwa eine autonome Steu- erung von Fahrzeugen, Robotern oder Industrieanlagen.
Unter einer„Vorrichtung“ wird hier allgemein eine technische Vorrichtung verstan- den mit Sensoren zur Erfassung von Zustandsdaten der Vorrichtung und einem Vor- richtungscomputersystem zum Protokollieren der erfassten Zustandsdaten. Die Vor- richtung kann auch in dem entsprechenden Computersystem mit Sensorik beste- hen. Beispielsweise handelt es sich bei den empfangenen Datensätzen um von ei- ner Vorrichtungscomputersystem unter Verwendung der Sensoren erfasste Daten- sätze. Computersystem zum maschinellen Lernen Eine Vorrichtung umfasst bei- spielsweise ein Fahrzeug, eine Anlage, wie etwa eine Produktionsanlage, eine Ver- arbeitungsanlage, eine Förderanlage, eine Energiegewinnungsanlage, eine Wärme- gewinnungsanlage, eine Steuerungsanlage, eine Überwachungsanlage, etc. sein.
Unter einem„Fahrzeug“ wird hier ein mobiles Verkehrsmittel verstanden. Ein sol- ches Verkehrsmittel kann beispielsweise dem Transport von Gütern (Güterverkehr), von Werkzeugen (Maschinen oder Hilfsmittel) oder Personen (Personenverkehr) dienen. Fahrzeuge umfassen insbesondere auch motorisierte Verkehrsmittel. Bei ei- nem Fahrzeug kann es sich beispielsweise um ein Landfahrzeug, ein Wasserfahr- zeug und/oder ein Luftfahrzeug handeln. Ein Landfahrzeug kann beispielsweise sein: ein Automobil, wie etwa ein Personenkraftwagen, Omnibus oder ein Lastkraftwagen, ein motorbetriebenes Zweirad, wie etwa ein Motorrad, Kleinkraft- rad, Motorroller oder Motorfahrrad, ein landwirtschaftlicher Traktor, Gabelstapler, Golfmobil, Autokran. Darüber hinaus kann es sich bei einem Landfahrzeug auch um ein Schienen gebundenes Fahrzeug handeln. Wasserfahrzeug kann beispielsweise sein: ein Schiff oder Boot. Ferner kann ein Luftfahrzeug beispielsweise sein: ein Flugzeug oder Hubschrauber. Unter einem Fahrzeug wird insbesondere auch ein Kraftfahrzeug verstanden.
Nach Ausführungsformen umfasst die Vorrichtung zumindest einen Sensor zum Er- fassen von Zustandsdaten der Vorrichtung. Die Zustandsdaten der Vorrichtung wer- den durch das Vorrichtungscomputersystem von dem zumindest einen Sensor emp- fangen. Nach Ausführungsformen umfasst die Vorrichtung eine Mehrzahl von Sen- soren zum Erfassen von Zustandsdaten der Vorrichtung. Ausführungsformen kön- nen den Vorteil haben, dass die vorrichtungseigene Sensorik genutzt werden kann, um den Zustand der Vorrichtung zu erfassen. Der Zustand der Vorrichtung kann beispielsweise beschrieben werden durch Angaben zu Kenngrößen des aktuellen Leistungsvermögens der Vorrichtung, wie etwa Kilometerstand bei einem Fahrzeug, Verbrauchswerte, Leistungswerte, Fehlermeldungen, Ergebnisse vordefinierter Prüf- protokolle und/oder Kennungen von Komponenten der Vorrichtung.
Kenngrößen des aktuellen Leistungsvermögens eines Fahrzeugs können zum Bei- spiel Drehzahl, Geschwindigkeit, Kraftstoffverbrauch, Abgaswerte, Getriebegang sein.
Unter einem„Sensor“ wird hier ein Element zum Erfassen von Messdaten verstan- den. Messdaten sind Daten, welche physikalische oder chemische Eigenschaften eines Messobjekts, wie beispielsweise Wärmemenge, Temperatur, Feuchtigkeit, Druck, Durchflussmenge, Schallfeldgrößen, Helligkeit, Beschleunigung, pH-Wert, lo- nenstärke, elektrochemisches Potential, und/oder dessen stoffliche Beschaffenheit qualitativ oder quantitativ wiedergeben. Messdaten werden mittels physikalischer o- der chemischer Effekte erfasst und in ein elektronisch weiterverarbeitbares elektri- sches Signal umgeformt. Ferner können Messdaten Zustände und/oder Zustandsänderung von elektronischen Geräten durch Außeneinflüsse und/oder in Folge einer Benutzung durch einen Nutzer wiedergeben.
Sensoren zum Erfassen von Zustandsdaten in einem Fahrzeug können beispiels- weise umfassen: Kurbelwellensensor, Nockenwellensensor, Luftmassenmesser, Lufttemperatursensor, Kühlwassertemperatursensor, Drosselklappensensor, Klopfsensor, Getriebesensor, Wegstreckensensor, Getriebesensor, Niveausensor, Bremsverschleißsensor, Achslastsensor, Lenkwinkelsensor. Diese Sensoren erfas- sen und überwachen das Fahrverhalten des Fahrzeugs. Aus Abweichungen von Sollwerten und/oder einem Auftreten von bestimmten Mustern lassen sich Fehlfunk- tionen erkennen und identifizieren. Teils lassen sich auch konkrete Fehlerursachen, wie ausgefallene Komponenten des Fahrzeugs, identifizieren. Sensoren können zu- dem auch Kennungen elektronischer Komponenten, die in das Fahrzeug eingebaut sind abfragen, um deren Identität zu prüfen.
Ausführungsformen umfassen ein Quellcomputersystem zum Implementieren eines datenbankübergreifenden Index auf einem verteilten Datenbanksystem, welches eine das Quellcomputersystem umfassende Mehrzahl von Computersystemen mit jeweils einer eigenständigen Einzeldatenbank umfasst, wobei die Computersysteme mit den Einzeldatenbanken über ein Netzwerk kommunikativ miteinander verbunden sind.
Die Computersysteme umfassen ferner jeweils ein oder mehrere Prozessoren, ein oder mehrere Datenspeichermedien, auf welchen die jeweilige Einzeldatenbank be- reitgestellt wird, eine Kommunikationsschnittstelle zur Kommunikation über das Netzwerk sowie eine Programmlogik umfassen.
Die Einzeldatenbanken werden jeweils von einem Multi-Modell-Datenbankmanage- mentsystem verwaltet, wobei die Einzeldatenbanken jeweils eine Mehrzahl daten- bankindividueller Datensätze umfassen, welche in einem dokumentenorientierten ersten Datenmodell der jeweiligen Einzeldatenbank gespeichert sind, wobei die ge- speicherten Datensätze jeweils ein oder mehreren Feldwerte umfassen, wobei die einzelnen Feldwerte der gespeicherten Datensätze jeweils in einem Feld gespei- chert sind.
Die Einzeldatenbanken umfassen ferner jeweils einen durchsuchbaren ersten Index, welcher in einem zweiten Datenmodell der jeweiligen Einzeldatenbank gespeichert ist, wobei der Index der jeweiligen Einzeldatenbank eine Mehrzahl von aus den Feldwerten der in dem dokumentenorientierten Datenmodell der entsprechenden Einzeldatenbank gespeicherten Datensätze erzeugten Token umfasst, wobei die Token in dem Index jeweils mit einem oder mehreren Zeigern auf ein oder mehrere der in dem dokumentenorientierten Datenmodell der entsprechenden Einzeldaten- bank gespeicherten Datensätze verknüpft ist, aus deren Feldwerten das entspre- chende Token erzeugt wurde.
Die Programmlogik des Quellcomputersystems ist zum Ausführen eines Verfahrens zum Implementieren eines datenbankübergreifenden Index konfiguriert, wobei das Verfahren umfasst:
• Empfangen eines zusätzlichen Datensatzes durch die Einzeldatenbank des Quellcomputersystems als Quelldatenbank zum Ergänzen von Datensätze der Quelldatenbank,
• Speichern des zusätzlichen Datensatzes, welcher ein oder mehrere zusätzli- che Feldwerte umfasst, durch ein erstes Multi-Modell-Datenbankmanagement- system der Quelldatenbank in einem dokumentenorientierten ersten Datenmo- dell der Quelldatenbank,
• Anwenden einer Datenverarbeitungsfunktion der Quelldatenbank auf den zu- sätzlichen Datensatz, wobei die Datenverarbeitungsfunktion zumindest eine Indexierung des zusätzlichen Datensatzes zum Speichern in einem zweiten Datenmodell der Quelldatenbank umfasst, wobei die Indexierung umfasst: o Erzeugen von ein oder mehreren zusätzlichen Token aus den zusätzlichen Feldwerten durch die Quelldatenbank,
o Ergänzen des Index der Quelldatenbank durch das erste Multi-Modell-Da- tenbankmanagementsystem unter Verwendung der zusätzlichen Token und eines Zeigers auf den zusätzlichen in dem dokumentenorientierten Datenmodell der Quelldatenbank gespeicherten Datensatz,
• Erstellen eines aus dem Anwenden der Datenverarbeitungsfunktion resultie- renden Ergänzungsdatensatzes, welcher die in dem Index der Quelldatenbank vorgenommenen Ergänzungen umfasst, zum Ergänzen zumindest eines zwei- ten Index zumindest einer weiteren Einzeldatenbank als Empfangsdatenbank, welche ein weiteres Computersystem des Datenbanksystems als Empfangs- computersystem umfassten,
• Senden des Ergänzungsdatensatzes durch das Quellcomputersystem über das Netzwerk an das Empfangscomputersystem zur Integration in den zweiten Index der Empfangsdatenbank.
Nach Ausführungsformen ist das Quellcomputersystem dazu konfiguriert eine oder mehrere der zuvor genannten Ausführungsformen des Verfahrens zum Implemen- tieren eines datenbankübergreifenden Index auf dem verteilten Datenbanksystem auszuführen.
Ausführungsformen umfassen ferner ein verteiltes Datenbanksystem zum Imple- mentieren eines datenbankübergreifenden Index auf dem verteilten Datenbanksys- tem, welches eine das Mehrzahl von Computersystemen mit jeweils einer eigen- ständigen Einzeldatenbank umfasst, wobei die Computersysteme mit den Einzelda- tenbanken über ein Netzwerk kommunikativ miteinander verbunden sind.
Die Computersysteme umfassen ferner jeweils ein oder mehrere Prozessoren, ein oder mehrere Datenspeichermedien, auf welchen die jeweilige Einzeldatenbank be- reitgestellt wird, eine Kommunikationsschnittstelle zur Kommunikation über das Netzwerk sowie eine Programm logik.
Die Einzeldatenbanken werden jeweils von einem Multi-Modell-Datenbankmanage- mentsystem verwaltet, wobei die Einzeldatenbanken jeweils eine Mehrzahl daten- bankindividueller Datensätze umfassen, welche in einem dokumentenorientierten ersten Datenmodell der jeweiligen Einzeldatenbank gespeichert sind, wobei die gespeicherten Datensätze jeweils ein oder mehreren Feldwerte umfassen, wobei die einzelnen Feldwerte der gespeicherten Datensätze jeweils in einem Feld gespei- chert sind.
Die Einzeldatenbanken umfassen ferner jeweils einen durchsuchbaren ersten Index, welcher in einem zweiten Datenmodell der jeweiligen Einzeldatenbank gespeichert ist, wobei der Index der jeweiligen Einzeldatenbank eine Mehrzahl von aus den Feldwerten der in dem dokumentenorientierten Datenmodell der entsprechenden Einzeldatenbank gespeicherten Datensätze erzeugten Token umfasst, wobei die Token in dem Index jeweils mit einem oder mehreren Zeigern auf ein oder mehrere der in dem dokumentenorientierten Datenmodell der entsprechenden Einzeldaten- bank gespeicherten Datensätze verknüpft ist, aus deren Feldwerten das entspre- chende Token erzeugt wurde,.
Die Programmlogik ist jeweils zum Ausführen eines Verfahrens zum Implementieren eines datenbankübergreifenden Index durch das die Programmlogik ausführende Computersystem der Mehrzahl von Computersystemen konfiguriert, welches als ein Quellcomputersystem fungiert, wobei das Verfahren umfasst:
• Empfangen eines zusätzlichen Datensatzes durch die Einzeldatenbank des Quellcomputersystems als Quelldatenbank zum Ergänzen von Datensätze der Quelldatenbank,
• Speichern des zusätzlichen Datensatzes, welcher ein oder mehrere zusätzli- che Feldwerte umfasst, durch ein erstes Multi-Modell-Datenbankmanagement- system der Quelldatenbank in einem dokumentenorientierten ersten Datenmo- dell der Quelldatenbank,
• Anwenden einer Datenverarbeitungsfunktion der Quelldatenbank auf den zu- sätzlichen Datensatz, wobei die Datenverarbeitungsfunktion zumindest eine Indexierung des zusätzlichen Datensatzes zum Speichern in einem zweiten Datenmodell der Quelldatenbank umfasst, wobei die Indexierung umfasst: o Erzeugen von ein oder mehreren zusätzlichen Token aus den zusätzlichen Feldwerten durch die Quelldatenbank, o Ergänzen des Index der Quelldatenbank durch das erste Multi-Modell-Da- tenbankmanagementsystem unter Verwendung der zusätzlichen Token und eines Zeigers auf den zusätzlichen in dem dokumentenorientierten Datenmodell der Quelldatenbank gespeicherten Datensatz,
• Erstellen eines aus dem Anwenden der Datenverarbeitungsfunktion resultie- renden Ergänzungsdatensatzes, welcher die in dem Index der Quelldatenbank vorgenommenen Ergänzungen umfasst, zum Ergänzen zumindest eines zwei- ten Index zumindest einer weiteren Einzeldatenbank als Empfangsdatenbank, welche ein weiteres Computersystem des Datenbanksystems als Empfangs- computersystem umfassten,
• Senden des Ergänzungsdatensatzes durch das Quellcomputersystem über das Netzwerk an das Empfangscomputersystem zur Integration in den zweiten Index der Empfangsdatenbank.
Nach Ausführungsformen ist das verteilte Datenbanksystem dazu konfiguriert eine oder mehrere der zuvor genannten Ausführungsformen des Verfahrens zum Imple- mentieren eines datenbankübergreifenden Index auf dem verteilten Datenbanksys- tem auszuführen.
Im Weiteren werden Ausführungsformen der Erfindung mit Bezugnahme auf die Zeichnungen näher erläutert. Es zeigen:
Figur 1 ein schematisches Blockdiagramm einer Ausführungsform eines
exemplarischen Computersystems,
Figuren 2 schematische Diagramme einer Ausführungsform eines exemplari- schen verteilten Datenbanksystems,
Figur 3 ein schematisches Diagramm einer Ausführungsform eines exemplari- schen verteilten Datenbanksystems,
Figur 4 ein schematisches Flussdiagramm eines exemplarischen Verfahrens, Figur 5 ein schematisches Flussdiagramm eines exemplarischen Verfahrens, Figur 6 ein schematisches Flussdiagramm eines exemplarischen Verfahrens, Figur 7 ein schematisches Flussdiagramm eines exemplarischen Verfahrens, Figur 8 ein schematisches Blockdiagramm von Ausführungsformen exemplari- scher Computersysteme,
Figur 9 ein schematisches Blockdiagramm einer exemplarischen Rechte- vergabe,
Figur 10 ein schematisches Blockdiagramm einer exemplarischen Implementie- rung eines Systems zur Rechtevergabe,
Figur 1 1 ein schematisches Blockdiagramm einer Ausführungsform eines
exemplarischen Computersystems,
Figur 12 ein schematisches Blockdiagramme einer exemplarischen Datenverar- beitung durch das Multi-Modell-Datenbankmanagementsystem,
Figur 13 ein schematisches Blockdiagramme einer exemplarischen Datenverar- beitung durch das Multi-Modell-Datenbankmanagementsystem,
Figur 14 ein schematisches Blockdiagramm von Ausführungsformen exemplari- scher Computersysteme,
Figur 15 ein Flussdiagramm einer Ausführungsform eines exemplarischen Ver- fahrens,
Figur 16 ein Flussdiagramm einer Ausführungsform eines exemplarischen Ver- fahrens,
Figur 17 ein Flussdiagramm einer Ausführungsform eines exemplarischen Ver- fahrens und
Figur 18 ein Flussdiagramm einer Ausführungsform eines exemplarischen Ver- fahrens.
Elemente der nachfolgenden Ausführungsformen, die einander entsprechen, werden mit denselben Bezugszeichen gekennzeichnet.
Figur 1 zeigt ein Blockdiagramm einer Ausführungsform eines exemplarischen Computersystems 100, welches eine Einzeldatenbank 104 zum Implementieren ei- nes datenbankübergreifenden Index auf einem verteilten Datenbanksystem 170 um- fasst. Das verteilte Datenbanksystem 170 umfasst eine Mehrzahl von Einzeldaten- bank 104, welche jeweils auf einem Computersystem 100 implementiert sind. Das Computersystems 100 umfasst ferner ein Multi-Modell- Datenbankmanagementsystem (MM-DBMS) 1 18, welches die, ggf. strukturierte, Speicherung von Daten in der zumindest einen Einzeldatenbank 104 verwaltet und alle lesenden und schreibenden Zugriffe auf die Einzeldatenbank 104 kontrolliert. Die MM-DBMS 1 18 unterstützt zumindest zwei Datenmodelle 106, 1 10, in welchen Daten in der Einzeldatenbank 104 gespeichert werden. Dabei legt das Datenbank- modell fest, in welcher Form die entsprechenden Daten organisiert, gespeichert und bearbeitet werden. Bei einem oder beiden Datenmodellen 106, 1 10 handelt es sich um NoSQL Datenmodelle. In dieser Hinsicht handelt es sich bei dem MM-DBMS 1 18 um ein NoSQL DBMS. Das erste Datenmodell 106 ist ein dokumentenbasiertes Datenmodell, in welchem eine Mehrzahl von Datensätzen DS1 , DS2, DS3 gespei- chert sind. Jeder Datensatz DS1 , DS2, DS3 wird in einem Dokument bzw. einem Datencontainer gespeichert. Den Datensätzen DS1 , DS2, DS3 selbst wird beim Speichern von dem dokumentenbasiertes Datenmodell 106 keine spezifische Struk- tur vorgegeben. Mithin können die Datensätzen DS1 , DS2, DS3 mit der internen Struktur gespeichert werden, mit welcher die Datensätzen DS1 , DS2, DS3 von der Einzeldatenbank 104 empfangen werden. Insofern handelt es sich bei den in dem dokumentenbasiertes Datenmodell 106 gespeicherten Datensätzen DS1 , DS2, DS3 um Rohdaten. Die Datensätze DS1 , DS2, DS3 können beispielsweise Textdaten, Bilddaten, Audiodaten und/oder Videodaten umfassen. Die Datensätze DS1 , DS2, DS3 umfassen jeweils zumindest ein Feld F1 , ... , F8, mit Feldwerten. Die Datens- ätze DS1 , DS2, DS3 können bereits eine innere Struktur mit einer Mehrzahl von Feldern F1 , ... , F8 aufweisen, wenn sie gespeichert werden. Dann umfassen die entsprechenden Datensätze DS1 , DS2, DS3 jeweils eine Mehrzahl von Feld F1 , ... , F8. Weisen die Datensätze DS1 , DS2, DS3 selbst bei ihrem Empfang keine Felder auf, so umfassen sie in gespeicherter Form jeweils beispielsweise genau ein Feld, welches den gesamten Datenumfang des entsprechenden Datensatzes DS1 , DS2, DS3 umfasst. Die Felder F1 , ... , F8 umfassen jeweils ein oder mehrere Feldwerte. Jeder der Feldwerte eines Datensatzes DS1 , DS2, DS3 ist in einem entsprechen- den Feld, einer Art Datencontainer, gespeichert. Jedes Feld F1 , ... , F8 kann einem Feldtyp zugewiesen sein. Dabei können die Felder F1 , ... , F8 unterschiedlichen o- der alle demselben Feldtyp zugewiesen sein. Die Zusammensetzung der Feldwerte der einzelnen Datensätze DS1 , DS2, DS3 kann sich dabei im Hinblick auf deren Feldtypen unterscheiden. Es ist auch möglich das einzelne Datensätze gar keine Felder eines bestimmten Feldtyps beinhalten. In anderen Ausführungsformen (hier nicht gezeigt) können auch mandatorische Feldtypen definiert sein, d.h. dass jedes Dokument ein Feld für jeden mandatorischen Feldtyp umfasst und optional ein oder mehrere weitere Felder für optionale Feldtypen umfasst. Die Daten der Datensätze werden dann in Feldern des für sie vorgesehenen Feldtyps gespeichert, d.h. z.B. Textdaten in einem oder mehreren Textfeldern, Bilddaten in einem oder mehreren Bildfeldern, Audiodaten in einem oder mehreren Audiofeldern und/oder Videodaten in einem oder mehreren Videofeldern.
Ferner umfasst das Computersystem 100 einen Tokenisierer 120 zum Erzeugen von Token 109. Nach alternativen Ausführungsformen kann auch das MM-DBMS 118 den Tokenisierer 122 umfassen.
Das Computersystem 100, z.B. das MM-DBMS 118, verfügt über eine eingebaute Programm logik bzw. Datenverarbeitungsfunktion, welche zur Generierung eines In- dex 112 konfiguriert ist. Der entsprechende Index 112 wird dabei in einem weiteren Datenmodell 110 bereitgestellt, in welchem die vollständigen Daten der Datensätze DS1 , DS2, DS3 oder eine aus diesen abgeleitete Datenmenge in umstrukturierter, redundanzfreier Form gespeichert sind. Zum Erzeugen des Index 112 wird auf den Tokenisierer 122 zugegriffen, welcher dazu konfiguriert ist, die Feldwerte der Fel- dern F1 , ... , F8 der in dem dokumentenbasierten Datenmodell 106 gespeicherten Datensätze 106 zu tokenisieren. Dabei können die resultierenden Token 109 auch mit einem Feldwert eines Feldes bzw. eines Datensatzes identisch sein, falls keine weitere Zerlegung in Token 109 möglich oder sinnvoll ist. Die Tokenisierung kann nach Ausführungsformen auch stufenweise erfolgen, so dass eine immer feinere Zerlegung erfolgt. Mithin kann der resultierende Index 112 in diesem Fall Token 109 umfassen, welche aus anderen Token 109 zusammengesetzt sind. Die Programm- logik bzw. Datenverarbeitungsfunktion kann dabei auf allen Computersystemen 100 bzw. für alle Einzeldatenbanken 104 des verteilten Datenbanksystems 170 identisch sein. Alternativ können sich die Programm logik bzw. Datenverarbeitungsfunktion zwischen Computersystemen 100 bzw. Einzeldatenbanken 104 des verteilten Datenbanksystems 170 auch unterscheiden, beispielsweise in Abhängigkeit von der Art oder dem Inhalt der von der jeweiligen Einzeldatenbank zu speichernden Daten.
Vorzugsweise werden sämtliche oder zumindest die meisten Feldwerte sämtlicher Datensätze DS1 , DS2, DS3 der Einzeldatenbank 104 tokenisiert, sodass eine um- fangreiche Menge an Token 109 entsteht. In Abhängigkeit von der Art der Daten in den einzelnen Feldwerten können die Token 109 eine Mischung aus Zahlen, Buch- stabenwörtern, Bildern oder Bildsegmenten, Audiodateien oder Audioelementen o- der sonstigen Datenstrukturen, insbesondere Sensordaten von ein oder mehreren Sensoren, umfassen. Jedes der erzeugten Token 109 wird in dem Index 1 12 mit ei- nem Zeiger verknüpft gespeichert, wobei der Zeiger auf den Datensatz bzw. das Feld verweist, aus dem das Token 109 entstammt.
Im Zuge der Erzeugung des Index 1 12 wird aus der Menge an Token 109 eine nichtredundante, unique Token-Menge gebildet, in welcher jedes der Token 109 höchstens einmal vorkommt. Vorzugsweise erfolgt die Speicherung aller Token 109 der nichtredundanten Tokenmenge in dem Index 1 12 so, dass die Token 109 nach einem Sortierkriterium sortiert werden und in sortierter Form in der Indexstruktur ge- speichert werden. Die Sortierung kann beispielsweise anhand des Alphabets für al- phanumerische Daten oder sonstiger, an die Daten angepasste Sortierkriterien er- folgen. Da die Token 109 in dem Index 1 12 vorzugsweise in sortierter Form gespei- chert sind, und weiterhin vorzugsweise in einer Baumstruktur gespeichert sind, ist es sehr schnell möglich, ein bestimmtes Token 109 innerhalb des Index 1 12 zu identifizieren und dann die Verweise dieses identifizierten Tokens 109 auf ein oder mehrere Datensätze DS1 , DS2, DS3 zu verwenden, um sehr schnell diejenigen Da- tensätze zu identifizieren, die ein bestimmtes, gesuchtes Token 109 enthalten. Es ist also nicht erforderlich, alle Datensätze DS1 , DS2, DS3 der Einzeldatenbank 104 sequenziell zu durchsuchen.
Empfängt die Einzeldatenbank 104 als Quelldatenbank einen zusätzlichen Daten- satz, z.B. DS3, wird dieser in dem ersten Datenmodell 106 gespeichert, unter Ver- wendung des Tokenisierers tokenisiert und die resultierenden Token werden dazu verwendet den Index 1 12 in dem zweiten Datenmodell 1 10 zu ergänzen. Ferner wird ein Ergänzungsdatensatz 130 erstellt, welcher die in dem Index 1 12 der Quell- datenbank 104 vorgenommenen Ergänzungen umfasst und zum Ergänzen weiterer Indexe weiterer Einzeldatenbanken des verteilten Datenbanksystems 170 als Emp- fangsdatenbanken dient. Der so erstellte Ergänzungsdatensatz 130 wird unter Ver- wendung einer Kommunikationsschnittstelle 126 des Computersystems 100 über ein Netzwerk an die Empfangsdatenbanken des verteilten Datenbanksystems 170 gesendet.
Figur 2A zeigt ein Diagramm einer Ausführungsform eines exemplarischen verteil- ten Datenbanksystems 170. Das verteilte Datenbanksystem 170 umfasst eine Mehr- zahl von Knoten K1, ... , K6. Diese Knoten K1, ... , K6 werden von Computersystemen 100, 200 gebildet, welche jeweils eine Einzeldatenbank des verteilten Datenbank- systems umfassen. Jeder der Knoten K1, ... , K6 aggregiert individuell Daten D1, ... , D6 und erstellt aus diesen einen Index l1, ... , l6. Wird ein Index I1, ... , l6 infolge eines zusätzlichen empfangenen Datensatzes ergänzt, so erstellt der entsprechende Kno- ten K1, ... , K6, z.B. Knoten K1, einen Ergänzungsdatensatz E(I1), welcher die Ergän- zungen des Index I1 umfasst, und sendet diesen an die weiteren Konten K2, ... , K6 des verteilten Datenbanksystems 170, z.B. Knoten K2. Ebenso erstellen auch die weiteren Knoten K2, ... , K6 des verteilten Datenbanksystems 170 bei Ergänzungen ihres Index, z.B. I2, Ergänzungsdatensätze E(l2) und senden diese an die weiteren Knoten, wie etwa Knoten K2. Infolge dieses Austausches von Ergänzungsdaten- sätze E(I1), E(l2) werden alle Index I1, ... , I6 des Datenbanksystems 170 synchroni- siert, so dass sich der in Figur 2B gezeigt Zustand ergibt, in welchem alle Knoten K1, ... , K6 über einen vollständigen datenbankübergreifenden Index l(I1, ... , I6) des verteilten Datenbanksystems 170 verfügen.
In Figur 3 ist eine Mehrzahl von Knoten K1, ... , KN eines verteilten Datenbanksys- tems 170 gezeigt, welche jeweils eine Einzeldatenbank 1 , ... , N, umfassen. Infolge des in den Figuren 2 illustrierten Synchronisationsverfahren, umfassen jede der Ein- zeldatenbank 1 , ... , N einen vollständigen datenbankübergreifenden Index des verteilten Datenbanksystems 170, welcher die Informationen aller Einzelindexe I1, ... , IN umfasst.
Figur 4 zeigt ein Flussdiagramm der Ergänzung der Indexe. In Schritt a) wird ein erster Knoten K1 der verteilten Datenbank 170 bereitgestellt, welcher eine Datenver- arbeitungsfunktion F1 umfasst. In Schritt b) empfängt der Knoten K1 Daten D1. Aus diesen Daten D1 wird in Schritt c) unter Verwendung der Datenverarbeitungsfunk- tion F1 ein Index I1 erzeugt bzw. ein bestehender Index I1 ergänzt. In Schritt d) wird der resultierende Index I1 bzw. ein aus der Ergänzung des bestehenden Index I1 re- sultierender Ergänzungsdatensatz von dem Knoten K1 an zumindest einen weiteren Knoten K2 der verteilten Datenbank 170 gesendet. Der weitere Knoten K2 umfasst ebenfalls Daten D2, aus welchen unter Verwendung der Datenverarbeitungsfunktion F2 ein Index I2 erzeugt wird. Der Index I2 wird um die empfangenen IndexinformationI1 des ersten Knotens K1 ergänzt, so dass der resultierende Index des Knoten K1 ein kombinierter Index l(l) ist, welcher die Indexinformation beider Indexe I1, I2 beider Knoten K1, K2 miteinander kombiniert.
Figur 5 zeigt ein Flussdiagramm eines exemplarischen Verfahrens zum Implemen- tieren eines datenbankübergreifenden Index auf einem verteilten Datenbanksystem. In Block 300 wird ein zusätzlicher Datensatz durch eine erste Einzeldatenbank des verteilten Datenbanksystems als Quelldatenbank empfangen. Dieser zusätzliche Datensatz, welcher beispielsweise ein oder mehrere zusätzliche Feldwerte umfasst, wird zum Ergänzen der Quelldatenbank verwendet. In Block 302 wird der zusätzli- che Datensatz durch ein Multi-Modell-Datenbankmanagementsystem der Quellda- tenbank in einem dokumentenorientierten ersten Datenmodell der Quelldatenbank gespeichert. Zudem wird eine Datenverarbeitungsfunktion der Quelldatenbank auf den zusätzlichen Datensatz angewendet, welche zumindest eine Indexierung des zusätzlichen Datensatzes zum Speichern in einem zweiten Datenmodell der Quell- datenbank umfasst. In Block 304 werden ein oder mehreren zusätzlichen Token aus dem zusätzlichen Datensatz erzeugt. In Block 306 wird der Index der Quelldaten- bank durch das erste Multi-Modell-Datenbankmanagementsystem unter Verwen- dung der zusätzlichen Token und eines Zeigers auf den zusätzlichen in dem dokumentenorientierten Datenmodell der Quelldatenbank gespeicherten Datensatz ergänzt. Hierbei werden beispielsweise die zusätzliche Token mit dem Index der Quelldatenbank abgeglichen. Falls eines der zusätzlichen Token nicht von dem In- dex der Quelldatenbank umfasst ist, wird das entsprechende zusätzliche Token in dem Index der Quelldatenbank ergänzt und mit dem Zeiger auf den zusätzlichen in dem dokumentenorientierten Datenmodell der Quelldatenbank gespeicherten Da- tensatz verknüpft. Falls eines der zusätzlichen Token von dem Index der Quellda- tenbank bereits umfasst ist, wird das entsprechende zusätzliche Tokens in dem In- dex der Quelldatenbank mit dem Zeiger auf den zusätzlichen in dem dokumenten- orientierten Datenmodell der Quelldatenbank gespeicherten Datensatz verknüpft.
In Block 308 wird ein aus dem Anwenden der Datenverarbeitungsfunktion resultie- render Ergänzungsdatensatz erstellt. Dieser Ergänzungsdatensatz umfasst die in dem Index der Quelldatenbank vorgenommenen Ergänzungen und dient zum Er- gänzen zumindest eines zweiten Index zumindest einer zweiten Einzeldatenbank des verteilten Datenbanksystems als Empfangsdatenbank. In Block 310 wird der Er- gänzungsdatensatz über ein Netzwerk an die zweite Einzeldatenbank zur Integra- tion in den zweiten Index der Empfangsdatenbank gesendet.
Figur 6 zeigt ein Flussdiagramm eines exemplarischen Verfahrens zum Integrieren eines Ergänzungsdatensatzes in den Index einer Empfangsdatenbank. In Block 400 empfängt die Empfangsdatenbank den Ergänzungsdatensatz von einer Quelldaten- bank. Der Ergänzungsdatensatz umfasst in den Index der Quelldatenbank vorge- nommene Ergänzungen. In Block 402 wird der empfangene Ergänzungsdatensatz in den Index der Empfangsdatenbank integriert. Das Integrieren umfasst dabei ein Ergänzen des Index der Empfangsdatenbank. Dabei erfolgt beispielsweise ein Ab- gleichen von Token des Ergänzungsdatensatzes mit dem Index der Quelldaten- bank. Falls eines der Token des Ergänzungsdatensatzes nicht von dem Index der Quelldatenbank umfasst ist, wird das entsprechende Tokens in dem Index der Quelldatenbank ergänzt und in dem Index mit einem Zeiger auf den in einem doku- mentenorientierten Datenmodell der Quelldatenbank gespeicherten Datensatz, aus welchem das entsprechende Token erzeugt wurde, verknüpft. Falls eines der Token des Ergänzungsdatensatzes von dem Index der Quelldatenbank bereits umfasst ist, wird das entsprechende Tokens in dem Index der Quelldatenbank mit dem Zeiger auf den in einem dokumentenorientierten Datenmodell der zusätzlichen Quelldaten- bank gespeicherten Datensatz, aus welchem das entsprechende Token erzeugt wurde, verknüpft.
Figur 7 zeigt ein Flussdiagramm einer Ausführungsform eines exemplarischen Ver- fahrens zum Ausführen einer Suche auf einer der Einzeldatenbanken. In Block 500 wird eine Suchanfrage empfangen, die einen Suchwert beinhaltet. Block 502 wird der Index nach dem Suchwert durchsucht und in Block 504 wird ein Token innerhalb des Index identifiziert, welcher identisch mit dem Suchwert ist und/oder welcher un- ter den durch den Suchwert definierten Suchumfang fällt. In Block 506 werden, falls die Suche dies erfordert, Zeiger analysiert, mit denen das oder die identifizierten To- ken verknüpft sind. Dadurch können ein oder mehrere der Datensätze bestimmt werden, welche ein oder mehrere Feldwerte beinhalten, aus welchen das indexierte Token erzeugt wurde. In Block 508 wird eine Antwort auf die Suchanfrage zurückge- geben. Diese Antwort umfasst beispielsweise: eine Angabe über die identifizierten Token, ein oder mehrere durch Analysieren von Zeigern, mit denen die identifizierte Token verknüpft sind, bestimmten Datensätze oder ein oder mehreren Referenzen auf die bestimmten Datensätze. Wird etwa nur danach gesucht welche Token eine bestimmtes durch den Suchwert festgelegte Kriterium erfüllen, reicht es die aufge- fundenen Token zurück zu geben, ohne weitere Analyse von Zeigern oder Datens- ätzen. Sollen gemäß der Suche zudem die Datensätze identifiziert werden, welche die aufgefundenen Token umfassen, werden die Zeiger analysiert, es ist aber kein Zugriff auf die zugrundeliegenden Datensätze notwendig. Alternativ können gemäß der Suche auch die zugrundeliegenden Datensätze mit abgefragt werden.
Figur 8 zeigt ein schematisches Blockdiagramm von Ausführungsform eines exemp- larischen Quellcomputersystems 100 sowie eines exemplarischen Empfangscompu- tersystems 200 eines verteilten Datenbanksystems 170. Beide Computersysteme 100, 200 umfasst jeweils zumindest einen Prozessor 1 14, 214, welcher Program- minstruktionen 1 16, 216 ausführt. Durch das Ausführen der Programminstruktionen 1 16, 216 wird beispielsweise das zuvor beschriebene Verfahren zum Implementie- ren eines datenbankübergreifenden Index auf einem verteilten Datenbanksystem 170 umgesetzt. Beispielsweise führen die Prozessoren 1 14, 214 jeweils eine Multi- Modell-Datenbankmanagementsystem 1 18, 218 sowie einen Tokenisierer 122 aus. Ferner umfassen die Computersysteme 100 jeweils in einem Speicher 102, 202 eine Einzeldatenbank 104, 204, welche von dem jeweiligen Multi-Modell-Daten- bankmanagementsystem 1 18, 218 verwaltet wird. Die Datenbanken 104, 204 um- fassen jeweils ein erstes Datenmodell 106, 206, z.B. ein dokumentenorientiertes Datenmodell, in welchem Datensätze 108, 208 gespeichert werden. Ferner umfas- sen die Datenbanken 104, 204 jeweils ein zweites Datenmodell 1 10, 210 mit einem Index 1 12, 212 aller in den Datensätzen 108, 109 gespeicherten Daten. Um die In- dexe 1 12, 212 bei unterschiedlichen Datensätzen 108, 109 synchronisieren zu kön- nen und so einen datenbankübergreifenden Index auf den verteilten Datenbanksys- tem 170 zu implementieren. Wird beispielsweise auf dem Quellcomputersystem 100 ein Ergänzungsdatensatz 130 erzeugt, welcher Ergänzungen des Index 1 12 um- fasst. Um diese Ergänzungen des Index 1 12 auch dem Empfangscomputersystem zur Verfügung zu stellen zu können, umfassen beide Computersysteme 100, 200 je- weils eine Kommunikationsschnittstelle 126, 226 durch welche sie über ein Netz- werk 180 miteinander kommunizieren können. Das Quellcomputersystem 100 sen- det den Ergänzungsdatensatz 130 über das Netzwerk 180 an das Empfangscompu- tersystem 200, welches unter Verwendung des empfangenen Ergänzungsdatensatz 130 seinen Index 212 mit dem Index 1 12 synchronisiert.
Figur 9 zeigt Blockdiagramm einer Rechtevergabe mittels Übertragung von Zugriffs- Rechten über eine Kette Entitäten, etwa Einzeldatenbanken oder deren Nutzer. Ein Datensatz 108 mit Nutzdaten 160 wird durch eine Einzeldatenbank empfangen. Im Zuge der Erstellung des Datensatz 108 oder der Speicherung in der Einzeldaten- bank werden automatisch im Flintergrund Zugriffs-Zertifikate 162, 164, 166, die ei- ner ersten Entität zugewiesen sind, in entsprechenden Feldern des Datensatzes ge- speichert. Bei der ersten Entität handelt es sich beispielsweise um den Ersteller des Datensatzes, wie etwa die entsprechende Einzeldatenbank oder einen Nutzer der- selben. Die Zugriffs-Zertifikatei 62, 164, 166 sind für unterschiedliche Arten des Zugriffs auf den Datensatz konfiguriert. Das Zugriffs-Zertifikat 162 ist für einen Lese- zugriff, das Zugriffs-Zertifikat 164 für einen Schreibzugriff sowie das Zugriffs-Zertifi- kat 166 für den Zugriff auf Token eines Index, welche aus dem entsprechenden Da- tensatz erzeugt werden.
Sollen einer weiteren Entität ebenfalls Zugriffs-Rechte auf den Index erteilt werden, etwa einer zweiten Einzeldatenbank oder einem Nutzer der zweiten Einzeldaten- bank, wird ein in einer ID-Datenbank 172 der weiteren Entität das Indexzugriffs-Zer- tifikat 166, welches Indexzugriffe in Bezug auf den Datensatz 108 ermöglicht zuge- ordnet. Dies erfolgt beispielsweise, indem eine Verknüpfung dieses Zertifikats 166 mit einem Nutzer-Zertifikat 168 der weiteren Entität in der ID-Datenbank 172 gespei- chert wird, zum Beispiel innerhalb des gleichen Zugriffsermächtigungskettenobjekts.
Auf dieselbe Weise können auch einer dritten Entität Zugriffs-Rechte in Bezug auf den Datensatz 108 zugeordnet werden. Hierzu wird das Indexzugriffs-Zertifikat 166 auch dieser weiteren Entität zugeordnet. Dies erfolgt beispielsweise, indem eine Verknüpfung dieses Zertifikats 166 mit einem Nutzer-Zertifikat 174 der dritten Entität in der ID-Datenbank 172 gespeichert wird, zum Beispiel innerhalb des gleichen Zu- griffsermächtigungskettenobjekts. Hierbei kann das Nutzer-Zertifikat 174 entweder an das Nutzer-Zertifikat 168 oder direkt an das Indexzugriffs-Zertifikat 166 ange- hängt werden.
Soll ein Zugriff auf Token in einem Index erfolgen, welche aus dem Datensatz 108 erzeugt wurde, wird zunächst geprüft, ob ein Besitz des selbst Indexzugriffs-Zertifi- kats 166 oder eines der mit dem Indexzugriffs-Zertifikat 166 verknüpften Nutzerzerti- fikate 168, 174 nachgewiesen werden kann. Falls dies gelingt wird der Zugriff freige- geben, andernfalls wird der Zugriff verwehrt.
Die in den Zugriffsermächtigungskettenobjekten dokumentierte Kette an Nutzer-Zer- tifikaten dokumentiert die Übertragung von Zugriffs-Rechten über eine Sequenz mehrerer Nutzer. Die Sequenz kann aus einer bloßen Aneinanderreihung von Nut- zer-Zertifikaten bestehen, wobei beispielsweise die Position der Nutzer-Zertifikate innerhalb der Kettenobjekte die zeitliche Reihe der Übertragungen repräsentiert. Optional kann nach manchen Ausführungsformen die Kette von Nutzer-Zertifikaten innerhalb eines Ermächtigungskettenobjekten dadurch generiert werden, dass die ID-Datenbank die den einzelnen Nutzer-Zertifikaten zugeordneten privaten Schlüs- sel so verwendet, dass das letzte Nutzer-Zertifikat in der Kette das an dieses neu- angefügte neue Nutzer-Zertifikat signiert, sodass auch innerhalb der Kette der Nut- zer-Zertifikate der einzelnen Ermächtigungskettenobjekte eine Zertifikatskettenprü- fung möglich ist.
Figur 10 zeigt Blockdiagramm des verteilten Datenbankensystems 170. Dieses um- fasst beispielsweise ein Quellcomputersystem 100 und ein Empfangscomputersys- tem 200. Das Quellcomputersystem 100 sendet über ein Netzwerk 180 einen Er- gänzungsdatensatz 130 an das Empfangscomputersystem 200 zum Ergänzen ei- nes von der Empfangsdatenbank 204 des Empfangscomputersystems 200 umfass- ten Index, sodass dieser mit einem Index der Quelldatenbank 104 des Quellcompu- tersystems 100 synchronisiert wird.
Zum Zugriff auf den Index der Quelldatenbank 104 muss das Quellcomputersystem 100 bzw. ein Nutzer desselben Zugriffs-Rechte Nachweisen. Diese werden bei- spielsweise durch einen Abgleich mit einem in der Quell-ID-Datenbank 172 gespei- cherten Zugriffsermächtigungskettenobjekten überprüft. Bestehen die Zugriffs- Rechte, kann beispielsweise auf den Index Zugegriffen werden und es kann der ei- nen Ergänzungsdatensatz 130 erstellt werden. Damit auch das Empfangscomputer- system 200 zum Ergänzen des Index der Empfangsdatenbank 204 ermächtigt wird, wird für diese oder einen Nutzer derselben ein entsprechendes Zugriffsermächti- gungskettenobjekten erzeugt und an die Quell-ID-Datenbank 174 übertragen. Somit kann das auch das Empfangscomputersystem 200 seine Zugriffs-Rechte nachwei- sen. Nach Ausführungsformen ist eine Ermächtigung des Empfangscomputersys- tem 200 bzw. der Empfangsdatenbank 204 eine notwendige Voraussetzung für das Senden des Ergänzungsdatensatz 130 mit Indexinformationen an die Empfangsda- tenbank 204. Nach alternativen Ausführungsformen kann auch eine zentrale ID- Datenbank für mehrere oder alle Computersysteme 100, 200 des verteilten Daten- banksystems 170 vorgesehen sein.
Figur 1 1 zeigt ein Blockdiagramm einer erweiterten Ausführungsform des exemplari- schen Computersystems 100 aus Figur 1 , welches zum maschinellen Lernen konfi- guriert ist. Das Computersystems 100 aus Figur 1 1 umfasst zusätzlich ein Lernmo- dul 120 zum Verarbeiten der in der Einzeldatenbank 104 gespeicherten Daten. Das Lernmodul 120 umfasst beispielsweise den Tokenisierer 120 zum Erzeugen von To- ken 109 und zudem Trigger-Definitionen 123, welche Trigger für eine Klassifizierung von Token 109 definieren, und/oder einen Klassifizierer 124, welcher die Token 109 unter Verwendung der Trigger-Definitionen 123 klassifiziert. Nach Ausführungsfor- men umfasst das Lernmodul 120 ferner ein statistisches Modell 125. Das statisti- sches Modell 125 kann dazu konfiguriert sein, Trigger-Kombinationen zu erfassen und kombinierte Trigger-Definitionen zu erstellen, zusätzliche Trigger-Definitionen zu erstellen und/oder korrigierte Trigger-Definition zu erstellen. Nach alternativen Ausführungsformen kann auch das MM-DBMS 1 18 den Tokenisierer 122 umfassen und/oder auf einen von dem Lernmodul 120 bereitgestellten Tokenisierer 122 zu- greifen. Nach alternativen Ausführungsformen kann können die Trigger-Definitionen 123 auch in der Einzeldatenbank 104 gespeichert sein.
Das MM-DBMS 1 18 und/oder das Lernmodul 120 verfügen dabei über eine einge- baute Program logik, die zur Generierung eines Index 1 12 konfiguriert ist.
Bei der Generierung des Index 1 12 werden Token 109 in dem Index 1 12, welche von einer der Trigger-Definitionen 123 als Trigger umfasst sind, jeweils der entspre- chen Trigger-Definition 123 zugeordnet. Ferner werden Token 109 in dem Index 1 12, welche von einem der Datensätze DS1 , DS2, DS3 in einer Kombination mit ein oder mehreren der identifizierten Trigger gemäß einer der Trigger-Definitionen 123 umfasst sind, jeweils ein oder mehreren Klassen zugeordnet. Die entsprechenden Klassenzuordnungen stellen dabei Meta- bzw. Kontextinformationen für die entspre- chenden Token 109 bereit. Schließlich werden sind die verbliebenen Token 109 in dem Index 1 12, welche sich unter Verwendung der Trigger-Definitionen 123 weder als Trigger identifizieren, noch einer Klasse zuordnen als, zum Kennzeichnen als unbekannte Daten einer Auffangklasse zugeordnet. Dabei schließt eine Zuordnung zu der Auffangklasse eine Zuordnung zu einer der Trigger-Definitionen 123 ebenso wie eine Zuordnung zu einer der Klassen gemäß den Trigger-Definitionen 123 aus. Die zuvor beschriebenen Zuordnungen erfolgen beispielsweise unter Verwendung des Klassifizierers 124 des Lernmoduls 120.
Im Zuge der Erzeugung des Index 112 wird aus der Menge an Token 109 eine nichtredundante, unique Token-Menge gebildet, in welcher jedes der Token 109 nur ein einziges Mal vorkommt. Auch wenn ein Token 109 mit einem bestimmten Wert und einer bestimmten Klassenzuordnung mehrfach in der Einzeldatenbank 104 bzw. in dem Datenmodell 106 vorkommt, wird es beispielsweise nur ein einziges Mal mit dieser Klassenzuordnung in der nichtredundante Token-Menge und in dem Index 112 gespeichert.
Figur 12 zeigt ein schematisches Blockdiagramme einer exemplarischen Datenver- arbeitung durch das Multi-Modell-Datenbankmanagementsystem und das Lernmo- dul. Es wird eine vorbestimmte Trigger-Definition 123 der Form„[Vorname] [Nach- name] [Trigger1 = wohnt in der] [Straße] [Trigger2 = in] [Stadt]“ bereitgestellt. Diese Trigger-Definition 123 definiert zwei Trigger, d.h. einen ersten Trigger„wohnt in der“ und einen zweiten Trigger„in“. Zudem definiert die Trigger-Definition, dass es sich bei einem dem ersten Trigger unmittelbar vorangehenden Token um einen Nachna- men handelt, während es sich bei einem dem Nachnamen unmittelbar vorangehen- den Token um einen Vornamen handelt. Ferner definiert Trigger-Definition, dass es sich bei einem zwischen den beiden Triggern angeordneten Token um eine Straße handelt und dass es sich bei einem dem zweiten Trigger unmittelbar nachfolgenden Token um eine Stadt handelt.
In einem dokumentenbasierten Datenmodell 106 einer Datenbank sind zwei Doku- mente 108 gespeichert. Jedes Dokument 108 umfasst jeweils einen Datensatz DS1 , DS2. Beispielsweise handelt es sich bei den Datensätzen DS1 , DS2 jeweils um eine Textdatei. Der erste Datensatz DS1 umfasst beispielsweise den Satz: „Mustervorname_1 Musternachname_1 wohnt in der Musterstr._1 in Muster- stadt_1“. Dieser Satz wird mittels Tokenisierers in Token 109 zerlegt:„Mustervor- name_1“,„Musternachname_1“,„wohnt in der“,„Musterstr._1“,„in“,„Musterstadt_1“.
Die beiden Token„wohnt in der“ und„in“ werden als Trigger gemäß der Trigger-De- finition 123 identifiziert. Unter Verwendung der identifizierten Trigger sowie der Trig- ger-Definition 123 werden die verbleibenden Token 109 jeweils den von der Trigger- Definition definierten Klassen 1 1 1 zugeordnet. So wird das Token„Mustervor- name_1“ der Klasse„Vorname“, das Token„Musternachname_1“ der Klasse„Nach- name“, das Token„Musterstr._1“ der Klasse„Straße“ und das Token„Muster- stadt_1“ der Klasse„Stadt“ zugeordnet. Die als Trigger identifizierten Token werden ebenso wie die anhand dieser Trigger klassifizierten Token in einem Index in einem zweiten Datenmodell 1 10 gespeichert. Dabei werden die Trigger in Form einer Trig- ger-Zuordnung 1 17 jeweils der Trigger-Definition 123 zugeordnet. Die verbleiben- den Token 109 werden jeweils in Form einer Klassen-Zuordnung 1 13 einer der von der Trigger-Definition 123 definierten Klassen zugeordnet gespeichert. Zudem wer- den alle Trigger und klassifizierten Token in dem zweiten Datenmodell 1 10 mit ei- nem Zeiger 1 15 auf ihren Speicherort in dem ersten Datenmodell, d.h. DS1 , ver- knüpft.
Empfängt die Datenbank einen zweiten Datensatz DS2 der Form:„Mustervor- name_2 Musternachname_2 wohnt in der Musterstr._2 in Musterstadt_2“, so wird dieser Satz mittels Tokenisierers in Token zerlegt:„Mustervorname_2“,„Muster- nachname_2“,„wohnt in der“,„Musterstr._2“,„in“,„Musterstadt_2“ und in redun- danzfreier Form ebenfalls in dem zweiten Datenmodell 1 10 gespeichert.
Die beiden Token„wohnt in der“ und„in“ werden als Trigger gemäß der Trigger-De- finition 123 identifiziert. Da diese beiden Trigger der Trigger-Definition 123 von dem Index bereits umfasst sind, werden diese nicht nochmals in dem zweiten Datenmo- dell 1 10 gespeichert. Es wird lediglich ein Zeiger auf den zweiten Datensatz DS2 er- gänzt. Unter Verwendung der identifizierten Trigger sowie der Trigger-Definition 123 werden die verbleibenden Token 109 des Datensatzes DS2 jeweils den von der Trigger-Definition definierten Klassen 1 1 1 zugeordnet. So wird das Token„Muster- vorname_2“ der Klasse„Vorname“, das Token„Musternachname_2“ der Klasse „Nachname“, das Token„Musterstr._2“ der Klasse„Straße“ und das Token„Muster- stadt_2“ der Klasse„Stadt“ zugeordnet. Die klassifizierten Token 109 des Datensat- zes DS2 werden jeweils in Form einer Klassen-Zuordnung 1 13 einer der von der Trigger-Definition 123 definierten Klassen zugeordnet gespeichert und mit einem Zeiger 1 15 auf ihren Speicherort in dem ersten Datenmodell, d.h. DS2, verknüpft.
Mithin werden alle Token des zweiten Datensatzes DS2 ebenfalls in redundanz- freier Form jeweils mit ihren Klassen-Zuordnungen in dem zweiten Datenmodell 1 10 verknüpft mit einem Zeiger auf ihren Speicherort in dem ersten Datenmodell gespei- chert.
Figur 13 zeigt ein schematisches Blockdiagramme einer exemplarischen Datenver- arbeitung durch das Multi-Modell-Datenbankmanagementsystem und das Lernmo- dul. Es wird eine vorbestimmte Trigger-Definition 123 der Form„[Trigger1 = +, Ra- dius = NP] [Trigger1 = x, Radius = NP] [Klasse]“ bereitgestellt. Diese Trigger-Defini- tion 123 dient dazu aus einer Bilddatei erzeugte Token zu klassifizieren, wobei die Bilddatei in Token in Form von Pixelgruppen zerlegt wird. Die Trigger-Definition 123 definiert zwei Trigger, d.h. einen ersten Trigger in Form einer Pixelgruppe mit dem Inhalt„+“ und einen zweiten Trigger in Form einer Pixelgruppe mit dem Inhalt„x“. Zudem definiert die Trigger-Definition, dass es sich bei einer Pixelgruppe, welche innerhalb eines ersten Radius von N Pixeln um den ersten Trigger und zugleich in- nerhalb eines zweiten Radius von N Pixeln um den zweiten Trigger angeordnet ist, um eine ein Token der der Klasse„Klasse“ handelt.
In einem dokumentenbasierten Datenmodell 106 einer Datenbank ist ein Doku- mente 108 gespeichert. Dieses Dokument 108 umfasst einen Datensatz DS. Bei- spielsweise handelt es sich bei dem Datensatz DS um eine zweidimensionale Bild- datei. Diese Bilddatei wird mittels Tokenisierers in Token zerlegt, wobei es sich bei den Token jeweils um Pixelgruppen 150 handelt. Beispielsweise wird der in Z mal Z gleichgroße Pixelgruppen zerlegt. Die Token umfassen beispielsweise ein erstes Token in Form einer Pixelgruppe mit dem Inhalt„x“, ein zweites Token in Form einer Pixelgruppe mit dem Inhalt„+“, ein drittes Token in Form einer Pixelgruppe mit dem Inhalt„#“ und ein viertes Token in Form einer Pixelgruppe mit dem Inhalt
Die beiden Token„+“ und x“ werden als Trigger 121 gemäß der Trigger-Definition 123 identifiziert. Unter Verwendung der identifizierten Trigger sowie der Trigger-De- finition 123 wird das dritte Token„#“ der von der Trigger-Definition definierten Klasse 1 1 1 zugeordnet, da es in der zweidimensionalen Bilddatei innerhalb eines ersten Radius 152 von N Pixeln um den ersten Trigger„+“ und zugleich innerhalb eines zweiten Radius 154 von N Pixeln um den zweiten Trigger„x“ angeordnet ist. Da das vierte Token nicht unter die Trigger-Definition 123 fällt, wird es als unbe- kanntes Datum der Auffangklasse zugeordnet.
Die als Trigger 121 identifizierten Token„+“ und„x“ werden ebenso wie das anhand dieser Trigger klassifizierte Token„#“ und das der Auffangklasse zugeordnete To- ken in einem Index in einem zweiten Datenmodell 1 10 gespeichert. Dabei wer- den die Trigger„+“ und„x“ in Form einer Trigger-Zuordnung 1 17 jeweils der Trigger- Definition 123 zugeordnet. Das Token„#“ wird in Form einer Klassen-Zuordnung 1 13 der von der Trigger-Definition 123 definierten Klassen zugeordnet gespeichert. Das Token wird in Form einer Zuordnung 1 19 der Auffangklassen zugeordnet ge- speichert. Zudem werden alle Trigger und klassifizierten Token in dem zweiten Da- tenmodell 1 10 mit einem Zeiger 1 15 auf ihren Speicherort in dem ersten Datenmo- dell, d.h. DS, verknüpft.
Figur 14 zeigt ein schematisches Blockdiagramm von Ausführungsform eines exemplarischen Quellcomputersystems 100 sowie eines exemplarischen Empfangs- computersystems 200 eines verteilten Datenbanksystems 170. Die Ausführungs- form aus Figur 14 entsprechen weitgehend den Ausführungsformen aus Figur 8. In Figur 14 weisen die beiden Computersysteme 100, 200 zusätzlich jeweils ein Lern- modul 120, 220 auf, welches neben dem Tokenisierer 122, 222 zusätzlich Trigger- Definitionen 123, 223 zum klassifizieren der Daten mittels eines Klassifizierers 124, 224 sowie ein statistisches Modell 125, 225. Figur 15 zeigt ein Flussdiagramm einer Ausführungsform eines weiteren exemplari- schen Verfahrens zum Implementieren eines datenbankübergreifenden Index auf einem verteilten Datenbanksystem. In Block 600 wird für eine Quelldatenbank des verteilten Datenbanksystems ein vortrainiertes Lernmoduls zum maschinellen Ler- nen bereitgestellt, welches eine Mehrzahl von vorbestimmten Trigger-Definitionen umfasst. Diese vorbestimmten Trigger-Definitionen definieren Trigger für ein Zuord- nen von Token zu Klassen einer Gruppe von Klassen. In Block 602 wird die ent- sprechende Quelldatenbank bereitgestellt. Die Quelldatenbank wird von einem Multi-Modell-Datenbankmanagementsystem verwaltet und umfasst eine Mehrzahl von Datensätze, welche in einem dokumentenorientierten Datenmodell gespeichert sind. Diese gespeicherten Datensätze umfassen jeweils ein oder mehreren Felder mit Feldwerten. Zudem umfasst die bereitgestellte Quelldatenbank einen durch- suchbaren Index aller von den gespeicherten Datensätzen umfassten Daten. Dieser Index wird redundanzfrei in einem weiteren von dem Multi-Modell-Datenbankmana- gementsystem verwalteten Datenmodell gespeichert. Der Index umfasst eine Mehr- zahl von aus den Feldwerten der gespeicherten Datensätze erzeugten Token die in dem Index jeweils mit einem oder mehreren Zeigern auf ein oder mehrere der in dem dokumentenorientierten Datenmodell gespeicherten Datensätze und/oder Fel- der verknüpft sind, aus deren Feldwerten das entsprechende Token erzeugt wurde.
Erste Token in dem Index, welche von einer der Trigger-Definitionen als Trigger um- fasst sind, sind jeweils der entsprechen Trigger-Definition zugeordnet. Zweite Token in dem Index sind jeweils ein oder mehreren Klassen der Gruppe von Klassen zuge- ordnet. Die verbleibenden Token in dem Index sind schließlich zum Kennzeichnen der entsprechenden verbleibenden Token als unbekannte Daten einer Auffang- klasse zugeordnet. Dabei schließt die Zuordnung zu der Auffangklasse eine Zuord- nung zu einer der Trigger-Definitionen ebenso wie eine Zuordnung zu einer der Klassen der ersten Gruppe von Klassen aus.
In Block 604 wird ein zusätzlicher Datensatz empfangen und in Block 606 durch das Multi-Modell-Datenbankmanagementsystem in dem dokumentenorientierten Datenmodell der Quelldatenbank gespeichert. Dabei erfolgt die Speicherung in ei- nem Dokument bzw. Datencontainer. Der zusätzliche Datensatz wird unter Anwen- dung einer Datenverarbeitungsfunktion weiterverarbeitet. Dies umfasst: In Block 608 werden ein oder mehrere zusätzliche Token aus zusätzlichen Feldwerten erzeugt, welche der zusätzliche Datensatz umfasst. In Block 610 werden ein oder mehrere erste zusätzliche Token als Trigger identifiziert, falls diese von einer der Trigger-De- finitionen als Trigger umfasst sind. In Block 612 werden die verbleibenden zusätzli- chen Token klassifiziert. Die in Block 610 identifizierten Trigger werden zum Zuord- nen von ein oder mehreren zweiten zusätzlichen Token zu ein oder mehreren Klas- sen der Gruppe von Klassen verwendet, falls die entsprechenden zweiten zusätzli- chen Token von dem zusätzliche Datensatz in einer Kombination mit ein oder meh- reren der identifizierten Trigger gemäß einer der Trigger-Definitionen umfasst sind und die entsprechenden Trigger gemäß der entsprechenden Trigger-Definition eine entsprechende Klassenzuordnung triggern. Die verbleibenden zusätzlichen Token, für welche keine Zuordnung zu einer der Trigger-Definitionen und keine Klassenzu- ordnung aufgrund einer der Trigger-Definitionen erfolgt ist, werden im Zuge des Klassifizierens in Block 612 der Auffangklasse zugeordnet. Schließlich wird in Block 614 der Index durch das Multi-Modell-Datenbankmanagementsystem unter Verwen- dung der unter Verwendung der zusätzlichen Token aus Block 608, der Klassenzu- ordnungen der zusätzlichen Token aus Block 612 und eines Zeigers auf den zusätz- lichen in dem dokumentenorientierten Datenmodell gespeicherten Datensatz er- gänzt. Falls Zeiger einzelne Felder des zusätzlichen Datensatzes anzeigen, wird bei einer Mehrzahl von Feldern eine Mehrzahl von Zeigern verwendet.
Dabei kann das Ergänzen in Block 614 ein Abgleichen der zusätzlichen Token mit dem Index umfassen. Falls eines der zusätzlichen Token nicht von dem Index um- fasst ist, wird das entsprechende zusätzliche Token unter seinen Klassenzuordnun- gen in dem Index ergänzt und mit dem Zeiger auf den zusätzlichen in dem doku- mentenorientierten Datenmodell gespeicherten Datensatz verknüpft. Falls eine der Klassenzuordnungen eines von dem Index umfassten zusätzlichen Tokens von dem Index nicht umfasst ist, wird die entsprechende Klassenzuordnung mit dem entspre- chenden zusätzlichen Token in dem Index ergänzt und das entsprechende zusätzliche Token in dem Index mit dem Zeiger auf den zusätzlichen in dem doku- mentenorientierten Datenmodell gespeicherten Datensatz verknüpft. Falls eines der zusätzlichen Token mit allen seinen Klassenzuordnungen von dem Index umfasst ist, wird das entsprechende zusätzliche Token in dem Index mit dem Zeiger auf den zusätzlichen in dem dokumentenorientierten Datenmodell gespeicherten Datensatz verknüpft.
Zudem kann das Ergänzen in Block 614 ein Kennzeichnen von Kombinationen aus zweiten zusätzlichen Token mit ein oder mehreren der identifizierten Trigger, welche eine Klassenzuordnung gemäß einer der Trigger-Definitionen getriggert haben, in dem Index als klassifizierte Kombinationen umfassen. Klassenzuordnungen werden nur für Kombinationen aus zweiten zusätzlichen Token und ein oder mehreren iden- tifizierten Triggern ausgeführt, welche nicht als klassifizierte Kombinationen gekenn- zeichnet sind. Somit kann durch das Kennzeichnen vermieden werden, dass für be- reits bekannte und klassifizierte Kombinationen bei einem wiederholten Auftreten in verschiedenen Datensätzen jeweils das Klassifizieren wiederholt wird. Vielmehr er- folgt vor einem Klassifizieren ein Abgleich von Token-Kombinationen mit dem Index. Umfasst der Index die entsprechende Token-Kombination bereits und ist diese als klassifiziert gekennzeichnet, so erfolgt keine erneute Klassifikation für diese Token- Kombination. Es werden lediglich die entsprechende Token-Kombination und/oder die von der entsprechenden Token-Kombination umfassten Teilkombinationen und Einzeltoken in dem Index mit dem Zeiger auf den zusätzlichen in dem dokumenten- orientierten Datenmodell gespeicherten Datensatz verknüpft.
In Block 616 wird ein aus dem Anwenden der Datenverarbeitungsfunktion resultie- render Ergänzungsdatensatz erstellt. Dieser Ergänzungsdatensatz umfasst die in dem Index der Quelldatenbank vorgenommenen Ergänzungen und dient zum Er- gänzen zumindest eines zweiten Index zumindest einer zweiten Einzeldatenbank des verteilten Datenbanksystems als Empfangsdatenbank. In Block 618 wird der Er- gänzungsdatensatz über ein Netzwerk an die zweite Einzeldatenbank zur Integra- tion in den zweiten Index der Empfangsdatenbank gesendet. Figur 16 zeigt ein Flussdiagramm einer Ausführungsform eines exemplarischen Ver- fahrens zum Erzeugen kombinierter Trigger-Definitionen. In Block 700 werden ein oder mehr Trigger-Kombinationen durch das Lernmodul identifiziert, welche jeweils von zumindest einem der Datensätzen umfasst sind und ein Kombinationskriterium erfüllen. In Block 702 werden für jede der in Block 700 identifizierten Trigger-Kombi- nationen die Trigger-Definitionen der Trigger der entsprechenden Trigger-Kombina- tionen zu ein oder mehreren zusätzlichen kombinierten Trigger-Definitionen kombi- niert. In Block 704 wird die Mehrzahl von vorbestimmten Trigger-Definitionen des Lernmoduls durch die ein oder mehreren zusätzlichen kombinierten Trigger-Definiti- onen ergänzt.
Figur 17 zeigt ein Flussdiagramm einer Ausführungsform eines exemplarischen Ver- fahrens zum Ergänzen zusätzlicher Trigger-Definitionen. In Block 800 wird das vor- trainierte Lernmoduls um ein oder mehrere zusätzliche Trigger-Definitionen ergänzt. Die zusätzlichen Trigger-Definitionen definieren zusätzliche Trigger für ein Ersetzen von Zuordnungen von Token in dem Index zu der Auffangklasse durch Zuordnun- gen zu ein oder mehreren Klassen einer weiteren Gruppe von Klassen im Zuge ei- nes Reklassifizierens. Die zusätzlichen Trigger-Definitionen können beispielsweise von dem Lernmodul empfangen werden. Beispielsweise werden die entsprechen- den zusätzlichen Trigger-Definitionen von einem Administrator bereitgestellt. Nach alternativen Ausführungsformen werden die zu ergänzenden zusätzlichen Trigger- Definitionen von dem Lernmodul erstellt. Hierzu umfasst das Lernmodul ein statisti- sches Modell, welches zu einer statistischen Analyse der von der Auffangklassen umfassten Token und deren Vorkommen in den Datensätze verwendet wird. Das Ergebnis der statistischen Analyse wird zum Erstellen der zu ergänzenden zusätzli- chen Trigger-Definitionen verwendet.
In Block 802 werden ein oder mehreren der Auffangklasse zugeordneten Token in dem Index reklassifiziert, welche die zusätzlichen Trigger-Definitionen als zusätzli- che Trigger definierten. Das Reklassifizieren durch das Lernmodul umfasst ein Er- setzen der Zuordnung zu der Auffangklasse durch eine Zuordnung zu der entspre- chen zusätzlichen Trigger-Definition, welche das entsprechende Token als zusätzlichen Trigger umfasst. In Block 804 werden die zusätzliche Trigger zum Re- klassifizieren von ein oder mehreren der Auffangklasse zugeordneten Token in dem Index zu ein oder mehreren Klassen der weiteren Gruppe von Klassen durch das Lernmodul verwendet, falls die entsprechenden der Auffangklasse zugeordneten Token von einem der Datensätze in einer Kombination mit ein oder mehreren der zusätzlichen Triggern umfasst sind und die entsprechenden zusätzlichen Trigger gemäß der entsprechenden zusätzlichen Trigger-Definition eine entsprechende Zu- ordnung zu den ein oder mehreren Klassen der weiteren Gruppe von Klassen trig- gern.
Beispielsweise kann das Verfahrens zum Ergänzen zusätzlicher Trigger-Definitio- nen einem rekursiven Schema folgend wiederholt ausgeführt werden. Die zu ergän- zenden Trigger-Definitionen jeder Rekursionsstufe umfassen jeweils Ergänzungen einer Trigger-Definition einer vorangehenden Rekursionsstufe, sodass die rekursi- ven Ergänzungen Baumstrukturen bilden, welche jeweils eine der vorbestimmten Trigger-Definition als Wurzelknoten umfassen.
Figur 18 zeigt ein Flussdiagramm einer Ausführungsform eines exemplarischen Ver- fahrens zum Korrigieren von Trigger-Definitionen in Block. In Block 900 wird eine korrigierte Trigger-Definition zum Ersetzen einer der gespeicherten Trigger-Definitio- nen des Lernmoduls empfangen. Diese korrigierte Trigger-Definition wird beispiels- weise von einem Administrator bereitgestellt. Nach alternativen Ausführungsformen wird die korrigierte Trigger-Definition von dem Lernmodul unter Verwendung eines statistischen Modells erstellt. In Block 902 wird die entsprechende gespeicherte Trigger-Definition durch die korrigierte Trigger-Definition ersetzt. In Block 904 erfolgt ein Reklassifizieren der unter Verwendung der entsprechenden gespeicherten Trig- ger-Definition klassifizierten Token, wobei das Reklassifizieren unter Verwendung der korrigierten Trigger-Definition erfolgt. Bezugszeichenliste
100 Computersystem
102 Speicher
104 Quelldatenbank
106 erstes Datenmodell
108 Datensätze
109 Token
110 zweites Datenmodell
111 Klasse
112 Index
113 Klassen-Zuordnung
114 Prozessor
115 Zeiger
116 Programminstruktionen
117 Trigger-Zuordnung
118 MM-DBMS
119 Zuordnung zu Auffangklasse
120 Lernmodul
121 Trigger
122 Tokenisierer
123 T rigger-Definitionen
124 Klassifizierer
125 statistische Modell
126 Kommunikationsschnittstelle
130 Ergänzungsdatensatz
150 Pixelgruppe
152 Radius
154 Radius
160 Nutzdaten
162 Zugriffszertifikat
164 Zugriffszertifikat 166 Zugriffszertifikat
168 Nutzer-Zertifikat
170 verteiltes Datenbanksystem
172 ID-Datenbank
174 Nutzer-Zertifikat
176 Nutzer-Zertifikat
200 Computersystem
202 Speicher
204 Empfangsdatenbank
206 erstes Datenmodell
208 Datensätze
209 Token
210 zweites Datenmodell
211 Klasse
212 Index
213 Klassen-Zuordnung
214 Prozessor
215 Zeiger
216 Programminstruktionen
217 Trigger-Zuordnung
218 MM-DBMS
219 Zuordnung zu Auffangklasse
220 Lernmodul
221 Trigger
222 Tokenisierer
223 Trigger-Definitionen
224 Klassifizierer
225 statistische Modell
226 Kommunikationsschnittstelle F1, ... , F8 Felder
DS1 , ... , DS3 Datensätze K1, ... , K6 Knoten D1, ..., D6 Daten
I1, ..., I6 Index
E(I1), E(l2) Ergänzungsdatensatz

Claims

P a t e n t a n s p r ü c h e
1 . Computerimplementiertes Verfahren zum Implementieren eines datenbank- übergreifenden Index (1 12, 222) auf einem verteilten Datenbanksystem (170), wel- ches eine Mehrzahl von eigenständigen Einzeldatenbanken (104, 204) umfasst, wo- bei die Einzeldatenbanken über ein Netzwerk (180) kommunikativ miteinander ver- bunden sind,
wobei die Einzeldatenbanken jeweils von einem Multi-Modell-Datenbankma- nagementsystem (1 18, 218) verwaltet werden, wobei die Einzeldatenbanken jeweils eine Mehrzahl datenbankindividueller Datensätze (108, 208) umfassen, welche in einem dokumentenorientierten ersten Datenmodell (106, 206) der jeweiligen Einzel- datenbank gespeichert sind, wobei die gespeicherten Datensätze jeweils ein oder mehreren Feldwerte umfassen, wobei die einzelnen Feldwerte der gespeicherten Datensätze jeweils in einem Feld (F1 , ... , F8) gespeichert sind,
wobei die Einzeldatenbanken ferner jeweils einen durchsuchbaren ersten In- dex (1 12, 212) umfassen, welcher in einem zweiten Datenmodell (1 10) der jeweili- gen Einzeldatenbank gespeichert ist, wobei der Index der jeweiligen Einzeldaten- bank eine Mehrzahl von aus den Feldwerten der in dem dokumentenorientierten Datenmodell der entsprechenden Einzeldatenbank gespeicherten Datensätze er- zeugten Token (109, 209) umfasst, wobei die Token in dem Index jeweils mit einem oder mehreren Zeigern (1 15, 215) auf ein oder mehrere der in dem dokumentenori- entierten Datenmodell der entsprechenden Einzeldatenbank gespeicherten Datens- ätze verknüpft ist, aus deren Feldwerten das entsprechende Token erzeugt wurde, wobei das Verfahren umfasst:
• Empfangen eines zusätzlichen Datensatzes (108) durch eine erste Einzelda- tenbank als Quelldatenbank (104) zum Ergänzen von Datensätze der Quellda- tenbank,
• Speichern des zusätzlichen Datensatzes, welcher ein oder mehrere zusätzli- che Feldwerte umfasst, durch ein erstes Multi-Modell-Datenbankmanagement- system (1 18) der Quelldatenbank in einem dokumentenorientierten ersten Da- tenmodell (106) der Quelldatenbank, • Anwenden einer Datenverarbeitungsfunktion der Quelldatenbank auf den zu- sätzlichen Datensatz, wobei die Datenverarbeitungsfunktion zumindest eine Indexierung des zusätzlichen Datensatzes zum Speichern in einem zweiten Datenmodell (110) der Quelldatenbank umfasst, wobei die Indexierung um- fasst:
o Erzeugen von ein oder mehreren zusätzlichen Token (109) aus den zu- sätzlichen Feldwerten durch die Quelldatenbank,
o Ergänzen des Index (112) der Quelldatenbank durch das erste Multi-Mo- dell-Datenbankmanagementsystem unter Verwendung der zusätzlichen Token und eines Zeigers (115) auf den zusätzlichen in dem dokumenten- orientierten Datenmodell der Quelldatenbank gespeicherten Datensatz,
• Erstellen eines aus dem Anwenden der Datenverarbeitungsfunktion resultie- renden Ergänzungsdatensatzes (130), welcher die in dem Index der Quellda- tenbank vorgenommenen Ergänzungen umfasst, zum Ergänzen zumindest ei- nes zweiten Index zumindest einer zweiten Einzeldatenbank des verteilten Da- tenbanksystems als Empfangsdatenbank,
• Senden des Ergänzungsdatensatzes über das Netzwerk an die zweite Einzel- datenbank zur Integration in den zweiten Index (212) der Empfangsdatenbank (204).
2. Computerimplementiertes Verfahren nach Anspruch 1 , wobei das Ergänzen des Index umfasst:
• Abgleichen der zusätzlichen Token mit dem Index der Quelldatenbank,
• falls eines der zusätzlichen Token nicht von dem Index der Quelldatenbank umfasst ist, Ergänzen des entsprechenden zusätzlichen Tokens in dem Index der Quelldatenbank und Verknüpfen des entsprechenden zusätzlichen Tokens in dem Index mit dem Zeiger auf den zusätzlichen in dem dokumentenorien- tierten Datenmodell der Quelldatenbank gespeicherten Datensatz,
• falls eines der zusätzlichen Token von dem Index der Quelldatenbank umfasst ist, Verknüpfen des entsprechenden zusätzlichen Tokens in dem Index der Quelldatenbank mit dem Zeiger auf den zusätzlichen in dem dokumentenori- entierten Datenmodell der Quelldatenbank gespeicherten Datensatz.
3. Computerimplementiertes Verfahren nach einem der vorangehenden Ansprü- che, wobei der Ergänzungsdatensatz von der Quelldatenbank über das Netzwerk an eine vordefinierte erste Gruppe von ein oder mehreren Einzeldatenbanken der Mehrzahl von Einzeldatenbank als Empfangsdatenbanken gesendet wird, welche die zweite Einzeldatenbank umfasst.
4. Computerimplementiertes Verfahren nach einem der Ansprüche 1 bis 2, wo- bei der Ergänzungsdatensatz von der Quelldatenbank über das Netzwerk an alle weiteren von der Mehrzahl von Einzeldatenbanken umfassten Einzeldatenbanken als Empfangsdatenbanken gesendet wird.
5. Computerimplementiertes Verfahren nach einem der vorangehenden Ansprü- che, wobei eine vordefinierte zweite Gruppe von mehreren Einzeldatenbanken der Mehrzahl von Einzeldatenbank dazu konfiguriert ist, bei Empfang zusätzlicher Da- tensätze jeweils als eine Quelldatenbank zu fungieren.
6. Computerimplementiertes Verfahren nach einem der Ansprüche 1 bis 4, wo- bei alle Einzeldatenbanken der Mehrzahl von Einzeldatenbanken dazu konfiguriert sind, bei Empfang zusätzlicher Datensätze jeweils als eine Quelldatenbank zu fun- gieren.
7. Computerimplementiertes Verfahren nach einem der vorangehenden Ansprü- che, wobei der Quelldatenbank ein Sensor zugeordnet ist, wobei der zusätzliche Datensatz von dem Sensor erfasste Sensordaten umfasst.
8. Computerimplementiertes Verfahren nach einem der vorangehenden Ansprü- che, wobei jeder Einzeldatenbank der Mehrzahl von Einzeldatenbanken jeweils ein oder mehrere Sensoren zugeordnet sind, von welchen die jeweilige Einzeldaten- bank jeweils erfasste Sensordaten in Form zusätzlicher Datensätze empfängt.
9. Computerimplementiertes Verfahren nach einem der vorangehenden Ansprü- che, wobei die Datenverarbeitungsfunktion ferner ein Normalisieren der zusätzli- chen Token im Zuge des Ergänzens des Index der Quelldatenbank umfasst.
10. Computerimplementiertes Verfahren nach Anspruch 9, wobei das Normalisie- ren die fünfte und/oder sechste Normalform erfüllt.
11. Computerimplementiertes Verfahren nach einem der vorangehenden Ansprü- che, wobei die Datenverarbeitungsfunktion ferner ein Zuweisen von Rechten zum Verwalten und/oder Verarbeiten der Daten des zusätzlichen Datensatzes umfasst.
12. Computerimplementiertes Verfahren nach Anspruch 11 , wobei das erste Multi-Modell-Datenbankmanagementsystem einer der Quelldatenbank zugeordne- ten ersten Entität ein Eigner-Recht bezüglich des zusätzlichen Datensatz und/oder des Ergänzungsdatensatzes zuweist.
13. Computerimplementiertes Verfahren nach Anspruch 12, wobei es sich bei der ersten Entität um einen ersten Nutzer der Quelldatenbank oder ein erstes der Quell- datenbank zugeordnetes Computersystem handelt.
14. Computerimplementiertes Verfahren nach einem der Ansprüche 11 bis 13, wobei als Bestandteil des zusätzlichen Datensatz und/oder des Ergänzungsdaten- satzes Zugriffsberechtigungsnachweise (162, 164, 166) in der Quelldatenbank ge- speichert werden, wobei die Zugriffsberechtigungsnachweise ein oder mehrere der folgenden Zugriffsberechtigungsnachweise umfassen:
• ein Lesezugriffs-Berechtigungsnachweis (162), welcher einen lesenden Zu- griff auf den Inhalt eines Datensatzes ermöglicht;
• ein Schreibzugriffs- Berechtigungsnachweis (164), welcher modifizierenden Zugriff auf den Inhalt eines Datensatzes ermöglicht;
• ein Indexzugriffs- Berechtigungsnachweis (166), welcher Kenntnis der Exis- tenz des Datensatzes in der den Datensatz beinhaltenden Datenbank und ei- nen lesenden Zugriff auf Metadaten des Datensatzes ermöglicht.
15. Computerimplementiertes Verfahren nach Anspruch 14, wobei als Bestand- teil des zusätzlichen Datensatzes und/oder des Ergänzungsdatensatzes für die erste Entität ein Lesezugriffs-Berechtigungsnachweis (162), ein Schreibzugriffs-Be- rechtigungsnachweis (164) und ein Indexzugriffs-Berechtigungsnachweis (166) ge- speichert werden.
16. Computerimplementiertes Verfahren nach einem der Ansprüche 11 bis 15, wobei ferner einer der Empfangsdatenbank zugeordnete zweite Entität ein Indexzu- griffs-Berechtigungsnachweis (166) für den zusätzlichen Datensatz zugeordnet wird.
17. Computerimplementiertes Verfahren nach Anspruch 16, wobei es sich bei der zweiten Entität um einen zweiten Nutzer der Empfangsdatenbank oder ein zweites der Empfangsdaten zugeordnetes Computersystem handelt.
18. Computerimplementiertes Verfahren nach einem der Ansprüche 16 bis 17, wobei eine Voraussetzung für das Senden des Ergänzungsdatensatzes an die Empfangsdatenbank eine erfolgreiche Prüfung ist, dass der zweiten Entität ein In- dexzugriffs-Berechtigungsnachweis für den Ergänzungsdatensatz zugeordnet ist.
19. Computerimplementiertes Verfahren nach einem der vorangehenden Ansprü- che, wobei die Datenverarbeitungsfunktion ferner ein Klassifizieren der aus dem zu- sätzlichen Datensatz erzeugten Token umfasst.
20. Computerimplementiertes Verfahren nach Anspruch 19, wobei die Quellda- tenbank für das Klassifizieren ein vortrainierten Lernmoduls (120) zum maschinellen Lernen umfasst, wobei das vortrainierte Lernmodul eine Mehrzahl von vorbestimm- ten Trigger-Definitionen (123) umfasst, welche Trigger (121 ) für ein Zuordnen von Token zu Klassen einer ersten Gruppe von Klassen definieren,
wobei erste Token in dem Index der Quelldatenbank, welche von einer der Trigger-Definitionen der Quelldatenbank als Trigger umfasst sind, jeweils der ent- sprechen Trigger-Definition zugeordnet sind, wobei zweite Token in dem Index der Quelldatenbank jeweils ein oder mehreren Klassen der ersten Gruppe von Klassen zugeordnet sind,
wobei das Klassifizieren umfasst:
• falls eines oder mehrere erste zusätzliche Token von einer der Trigger-Definiti- onen als Trigger umfasst sind, Identifizieren des entsprechenden Tokens als Trigger durch das Lernmodul,
• Verwenden der identifizierten Trigger zum Zuordnen von ein oder mehreren zweiten zusätzlichen Token zu ein oder mehreren Klassen der ersten Gruppe von Klassen durch das Lernmodul, falls die entsprechenden zweiten zusätzli- chen Token von dem zusätzliche Datensatz in einer Kombination mit ein oder mehreren der identifizierten Trigger gemäß einer der Trigger-Definitionen um- fasst sind, wobei die entsprechenden Trigger gemäß der entsprechenden Trig- ger-Definition eine entsprechende Klassenzuordnung triggern,
wobei das Ergänzen des Index durch das erste Multi-Modell-Datenbankmana- gementsystem unter Verwendung der Klassenzuordnungen der zusätzlichen Token erfolgt.
21. Computerimplementiertes Verfahren nach Anspruch 20, wobei verbleibende Token, welche weder den Trigger-Definition noch ein oder mehreren Klassen der ersten Gruppe von Klassen zugeordnet sind, in dem Index der Quelldatenbank zum Kennzeichnen der entsprechenden verbleibenden Token als unbekannte Daten ei- ner Auffangklasse zugeordnet sind, wobei die Zuordnung zu der Auffangklasse eine Zuordnung zu einer der Trigger-Definitionen ebenso wie eine Zuordnung zu einer der Klassen der ersten Gruppe von Klassen ausschließt,
wobei das Klassifizieren ferner umfasst:
• Zuordnen der verbleibenden zusätzlichen Token, für welche keine Zuordnung zu einer der Trigger-Definitionen und keine Klassenzuordnung aufgrund einer der Trigger-Definitionen erfolgt ist, zu der Auffangklasse.
22. Computerimplementiertes Verfahren nach einem der Ansprüche 20 bis 21 , wobei, falls eines der zusätzlichen Token nicht von dem Index umfasst ist, das Er- gänzen des entsprechenden zusätzlichen Tokens unter seinen Klassenzuordnungen in dem Index erfolgt, und, falls eine der Klassenzuordnungen eines von dem Index umfassten zusätzlichen Tokens von dem Index nicht umfasst ist, ein Ergänzen der entsprechenden Klassenzuordnung mit dem entsprechenden zusätzlichen Token in dem Index und Verknüpfen des entsprechenden zusätzlichen Tokens in dem Index mit dem Zeiger auf den zusätzlichen in dem dokumentenorien- tierten Datenmodell gespeicherten Datensatz erfolgt.
23. Computerimplementiertes Verfahren nach einem der vorangehenden Ansprü- che, wobei die Zeiger, mit denen die Token in dem Index verknüpft gespeichert sind, jeweils auf ein oder mehrere der Feldwerte in den gespeicherten Datensätze verweisen.
24. Computerimplementiertes Verfahren nach einem der vorangehenden Ansprü- che, wobei die Feldwerte des zusätzlichen Datensatzes Textdaten, Bilddaten, Audi- odaten und/oder Videodaten umfassen.
25. Computerimplementiertes Verfahren nach einem der vorangehenden Ansprü- che, wobei das Erzeugen der Token ein Anwenden einer Tokenisierungslogik (122) auf die Feldwerte des zusätzlichen Datensatzes umfasst, welche einen Volltextindi- zierer umfasst, der dazu konfiguriert ist, Texte in Wörter zu zerlegen und die Wörter als Token auszugeben.
26. Computerimplementiertes Verfahren nach einem der Ansprüche 1 bis 24, wo- bei das Erzeugen der Token ein Anwenden einer Tokenisierungslogik (122) auf die Feldwerte des zusätzlichen Datensatzes umfasst, welche einen generischen Toke- nisierer umfasst, der dazu konfiguriert ist, in den Feldwerten Daten unterschiedli- chen Datentyps zu erkennen und aus diesen Token in unterschiedlichen Datenty- pen zu erzeugen.
27. Computerimplementiertes Verfahren nach einem der vorangehenden Ansprü- che, wobei es sich zumindest bei dem von dem Multi-Modell- Datenbankmanagementsystem zum Speichern der Datensätze verwendeten doku- mentenbasierten Datenmodellen um ein NoSQL-Datenmodellen handelt.
28. Computerimplementiertes Verfahren nach einem der vorangehenden Ansprü- che, wobei das maschinelle Lernen konfiguriert ist für eine Datenextraktion, Konsis- tenzprüfung, Bilderkennung, Spracherkennung, Sprachsteuerung, Vorrichtungs- überwachung und/oder autonome Vorrichtungssteuerung.
29. Computerimplementiertes Verfahren nach einem der vorangehenden Ansprü- che, wobei das Verfahren ferner umfasst:
• Empfangen eines von einer dritten Einzeldatenbank als zusätzlicher Quellda- tenbank erzeugten weiteren Ergänzungsdatensatzes durch die erste Einzelda- tenbank über das Netzwerk, wobei der weitere Ergänzungsdatensatz in einem Index der zusätzlichen Quelldatenbank vorgenommenen Ergänzungen um- fasst,
• Integrieren des weiteren Ergänzungsdatensatzes in den Index der ersten Ein- zeldatenbank, wobei das Integrieren ein Ergänzen des entsprechenden Index umfasst, bei welchem
o ein Abgleichen von Token des weiteren Ergänzungsdatensatzes mit dem Index der Quelldatenbank,
o falls eines der Token des weiteren Ergänzungsdatensatzes nicht von dem Index der Quelldatenbank umfasst ist, Ergänzen des entsprechenden To- kens in dem Index der Quelldatenbank und Verknüpfen des entsprechen- den Tokens in dem Index mit einem Zeiger auf den in einem dokumenten- orientierten Datenmodell der zusätzlichen Quelldatenbank gespeicherten Datensatz, aus welchem das entsprechende Token erzeugt wurde, o falls eines der Token des weiteren Ergänzungsdatensatzes von dem Index der Quelldatenbank umfasst ist, Verknüpfen des entsprechenden Tokens in dem Index der Quelldatenbank mit dem Zeiger auf den in einem doku- mentenorientierten Datenmodell der zusätzlichen Quelldatenbank gespei- cherten Datensatz, aus welchem das entsprechende Token erzeugt wurde.
30. Computerimplementiertes Verfahren nach einem der vorangehenden Ansprü- che, wobei das Verfahren ferner umfasst:
• Empfangen einer Suchanfrage durch erste Einzeldatenbank, wobei die Such- anfrage einen oder mehrere Suchwerte beinhaltet,
• Durchsuchen des Index der ersten Einzeldatenbank nach dem Suchwert,
• Identifizieren ein oder mehrerer Token innerhalb des Index, welche mit einem oder mehreren der Suchwerte übereinstimmen,
• Zurückgeben einer Antwort auf die Suchanfrage, wobei die Antwort zumindest umfasst: eine Angabe über die identifizierten Token, ein oder mehrere durch Analysieren von Zeigern, mit denen die identifizierte Token verknüpft sind, be- stimmten Datensätze oder ein oder mehreren Referenzen auf die bestimmten Datensätze.
31. Quellcomputersystem (100) zum Implementieren eines datenbankübergrei- fenden Index (112, 222) auf einem verteilten Datenbanksystem (170), welches eine das Quellcomputersystem umfassende Mehrzahl von Computersystemen (100,
200) mit jeweils einer eigenständigen Einzeldatenbank (104, 204) umfasst, wobei die Computersysteme mit den Einzeldatenbanken über ein Netzwerk (180) kommu- nikativ miteinander verbunden sind,
wobei die Computersysteme ferner jeweils ein oder mehrere Prozessoren (114, 214), ein oder mehrere Datenspeichermedien (102, 202), auf welchen die je- weilige Einzeldatenbank bereitgestellt wird, eine Kommunikationsschnittstelle (126, 226) zur Kommunikation über das Netzwerk sowie eine Programmlogik (116, 216) umfassen,
wobei die Einzeldatenbanken jeweils von einem Multi-Modell-Datenbankma- nagementsystem (118, 218) verwaltet werden, wobei die Einzeldatenbanken jeweils eine Mehrzahl datenbankindividueller Datensätze (108, 208) umfassen, welche in einem dokumentenorientierten ersten Datenmodell (106, 206) der jeweiligen Einzel- datenbank gespeichert sind, wobei die gespeicherten Datensätze jeweils ein oder mehreren Feldwerte umfassen, wobei die einzelnen Feldwerte der gespeicherten Datensätze jeweils in einem Feld (F1 , ... , F8) gespeichert sind, wobei die Einzeldatenbanken ferner jeweils einen durchsuchbaren ersten In- dex (112, 212) umfassen, welcher in einem zweiten Datenmodell (110) der jeweili- gen Einzeldatenbank gespeichert ist, wobei der Index der jeweiligen Einzeldaten- bank eine Mehrzahl von aus den Feldwerten der in dem dokumentenorientierten Datenmodell der entsprechenden Einzeldatenbank gespeicherten Datensätze er- zeugten Token (109, 209) umfasst, wobei die Token in dem Index jeweils mit einem oder mehreren Zeigern (115, 215) auf ein oder mehrere der in dem dokumentenori- entierten Datenmodell der entsprechenden Einzeldatenbank gespeicherten Datens- ätze verknüpft ist, aus deren Feldwerten das entsprechende Token erzeugt wurde, wobei die Programmlogik (116) des Quellcomputersystems zum Ausführen eines Verfahrens zum Implementieren eines datenbankübergreifenden Index konfi- guriert ist, wobei das Verfahren umfasst:
• Empfangen eines zusätzlichen Datensatzes (108) durch eine erste Einzelda- tenbank als Quelldatenbank (104) zum Ergänzen von Datensätze der Quellda- tenbank,
• Speichern des zusätzlichen Datensatzes, welcher ein oder mehrere zusätzli- che Feldwerte umfasst, durch ein erstes Multi-Modell-Datenbankmanagement- system (118) der Quelldatenbank in einem dokumentenorientierten ersten Da- tenmodell (106) der Quelldatenbank,
• Anwenden einer Datenverarbeitungsfunktion der Quelldatenbank auf den zu- sätzlichen Datensatz, wobei die Datenverarbeitungsfunktion zumindest eine Indexierung des zusätzlichen Datensatzes zum Speichern in einem zweiten Datenmodell (110) der Quelldatenbank umfasst, wobei die Indexierung um- fasst:
o Erzeugen von ein oder mehreren zusätzlichen Token (109) aus den zu- sätzlichen Feldwerten durch die Quelldatenbank,
o Ergänzen des Index (112) der Quelldatenbank durch das erste Multi-Mo- dell-Datenbankmanagementsystem unter Verwendung der zusätzlichen Token und eines Zeigers (115) auf den zusätzlichen in dem dokumenten- orientierten Datenmodell der Quelldatenbank gespeicherten Datensatz,
• Erstellen eines aus dem Anwenden der Datenverarbeitungsfunktion resultie- renden Ergänzungsdatensatzes (130), welcher die in dem Index der Quelldatenbank vorgenommenen Ergänzungen umfasst, zum Ergänzen zu- mindest eines zweiten Index zumindest einer zweiten Einzeldatenbank des verteilten Datenbanksystems als Empfangsdatenbank,
• Senden des Ergänzungsdatensatzes über das Netzwerk an die zweite Einzel- datenbank zur Integration in den zweiten Index (212) der Empfangsdatenbank (204).
32. Verteiltes Datenbanksystem (170) zum Implementieren eines datenbanküber- greifenden Index (112, 222) auf dem verteilten Datenbanksystem, welches eine das Mehrzahl von Computersystemen mit jeweils einer eigenständigen Einzeldatenbank umfasst, wobei die Computersysteme mit den Einzeldatenbanken über ein Netz- werk kommunikativ miteinander verbunden sind,
wobei die Computersysteme ferner jeweils ein oder mehrere Prozessoren (114, 214), ein oder mehrere Datenspeichermedien (102, 202), auf welchen die je- weilige Einzeldatenbank bereitgestellt wird, eine Kommunikationsschnittstelle (126, 226) zur Kommunikation über das Netzwerk sowie eine Programmlogik (116, 216) umfassen,
wobei die Einzeldatenbanken jeweils von einem Multi-Modell-Datenbankmana- gementsystem (118, 218) verwaltet werden, wobei die Einzeldatenbanken jeweils eine Mehrzahl datenbankindividueller Datensätze (108, 208) umfassen, welche in einem dokumentenorientierten ersten Datenmodell (106, 206) der jeweiligen Einzel- datenbank gespeichert sind, wobei die gespeicherten Datensätze jeweils ein oder mehreren Feldwerte umfassen, wobei die einzelnen Feldwerte der gespeicherten Datensätze jeweils in einem Feld (F1 , ... , F8) gespeichert sind,
wobei die Einzeldatenbanken ferner jeweils einen durchsuchbaren ersten In- dex (112, 212) umfassen, welcher in einem zweiten Datenmodell (110) der jeweili- gen Einzeldatenbank gespeichert ist, wobei der Index der jeweiligen Einzeldaten- bank eine Mehrzahl von aus den Feldwerten der in dem dokumentenorientierten Datenmodell der entsprechenden Einzeldatenbank gespeicherten Datensätze er- zeugten Token (109, 209) umfasst, wobei die Token in dem Index jeweils mit einem oder mehreren Zeigern (115, 215) auf ein oder mehrere der in dem dokumentenorientierten Datenmodell der entsprechenden Einzeldatenbank gespei- cherten Datensätze verknüpft ist, aus deren Feldwerten das entsprechende Token erzeugt wurde,
wobei die Programmlogik jeweils zum Ausführen eines Verfahrens zum Implemen- tieren eines datenbankübergreifenden Index durch das die Programmlogik ausfüh- rende Computersystem der Mehrzahl von Computersystemen konfiguriert ist, wel- ches als ein Quellcomputersystem (100) fungiert, wobei das Verfahren umfasst:
• Empfangen eines zusätzlichen Datensatzes (108) durch eine erste Einzelda- tenbank als Quelldatenbank (104) zum Ergänzen von Datensätze der Quellda- tenbank,
• Speichern des zusätzlichen Datensatzes, welcher ein oder mehrere zusätzli- che Feldwerte umfasst, durch ein erstes Multi-Modell-Datenbankmanagement- system (118) der Quelldatenbank in einem dokumentenorientierten ersten Da- tenmodell (106) der Quelldatenbank,
• Anwenden einer Datenverarbeitungsfunktion der Quelldatenbank auf den zu- sätzlichen Datensatz, wobei die Datenverarbeitungsfunktion zumindest eine Indexierung des zusätzlichen Datensatzes zum Speichern in einem zweiten Datenmodell (110) der Quelldatenbank umfasst, wobei die Indexierung um- fasst:
o Erzeugen von ein oder mehreren zusätzlichen Token (109) aus den zu- sätzlichen Feldwerten durch die Quelldatenbank,
o Ergänzen des Index (112) der Quelldatenbank durch das erste Multi-Mo- dell-Datenbankmanagementsystem unter Verwendung der zusätzlichen Token und eines Zeigers (115) auf den zusätzlichen in dem dokumenten- orientierten Datenmodell der Quelldatenbank gespeicherten Datensatz,
• Erstellen eines aus dem Anwenden der Datenverarbeitungsfunktion resultie- renden Ergänzungsdatensatzes (130), welcher die in dem Index der Quellda- tenbank vorgenommenen Ergänzungen umfasst, zum Ergänzen zumindest ei- nes zweiten Index zumindest einer zweiten Einzeldatenbank des verteilten Da- tenbanksystems als Empfangsdatenbank, • Senden des Ergänzungsdatensatzes über das Netzwerk an die zweite Einzel- datenbank zur Integration in den zweiten Index (212) der Empfangsdatenbank (204).
EP20716739.6A 2019-04-04 2020-03-31 Datenbankübergreifender index auf einem verteilten datenbanksystem Pending EP3948576A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102019108856.9A DE102019108856A1 (de) 2019-04-04 2019-04-04 Datenbankübergreifender Index auf einem verteilten Datenbanksystem
PCT/EP2020/059041 WO2020201248A1 (de) 2019-04-04 2020-03-31 Datenbankübergreifender index auf einem verteilten datenbanksystem

Publications (1)

Publication Number Publication Date
EP3948576A1 true EP3948576A1 (de) 2022-02-09

Family

ID=70165999

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20716739.6A Pending EP3948576A1 (de) 2019-04-04 2020-03-31 Datenbankübergreifender index auf einem verteilten datenbanksystem

Country Status (3)

Country Link
EP (1) EP3948576A1 (de)
DE (1) DE102019108856A1 (de)
WO (1) WO2020201248A1 (de)

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19627472A1 (de) * 1996-07-08 1998-01-15 Ser Systeme Ag Datenbanksystem
US20090210429A1 (en) * 2008-02-19 2009-08-20 Yahoo! Inc. System and method for asynchronous update of indexes in a distributed database
DE102010043265A1 (de) * 2009-11-06 2011-05-12 Symantec Corporation, Mountain View Systeme und Verfahren zum Verarbeiten und Verwalten von objektbezogenen Daten zur Verwendung durch mehrere Anwendungen
US20130173536A1 (en) * 2008-07-02 2013-07-04 Commvault Systems, Inc. Distributed indexing system for data storage
US20160055143A1 (en) * 2014-08-21 2016-02-25 Dropbox, Inc. Multi-user search system with methodology for bypassing instant indexing
US20160259810A1 (en) * 2015-03-06 2016-09-08 Hewlett-Packard Development Company, L.P. Global file index
DE102016226338A1 (de) * 2016-12-30 2018-07-05 Bundesdruckerei Gmbh Bitsequenzbasiertes Datenklassifikationssystem

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19627472A1 (de) * 1996-07-08 1998-01-15 Ser Systeme Ag Datenbanksystem
US20020133476A1 (en) * 1996-07-08 2002-09-19 Gert J. Reinhardt Database system
US20090210429A1 (en) * 2008-02-19 2009-08-20 Yahoo! Inc. System and method for asynchronous update of indexes in a distributed database
US20130173536A1 (en) * 2008-07-02 2013-07-04 Commvault Systems, Inc. Distributed indexing system for data storage
DE102010043265A1 (de) * 2009-11-06 2011-05-12 Symantec Corporation, Mountain View Systeme und Verfahren zum Verarbeiten und Verwalten von objektbezogenen Daten zur Verwendung durch mehrere Anwendungen
US20160055143A1 (en) * 2014-08-21 2016-02-25 Dropbox, Inc. Multi-user search system with methodology for bypassing instant indexing
US20160259810A1 (en) * 2015-03-06 2016-09-08 Hewlett-Packard Development Company, L.P. Global file index
DE102016226338A1 (de) * 2016-12-30 2018-07-05 Bundesdruckerei Gmbh Bitsequenzbasiertes Datenklassifikationssystem

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
GREENSTEIN B ET AL: "DIFS: a distributed index for features in sensor networks", NEW FRONTIERS IN TELECOMMUNICATIONS : 2003 IEEE INTERNATIONAL CONFERENCE ON COMMUNICATIONS ; ICC 2003 ; 11 - 15 MAY 2003, ANCHORAGE, ALASKA, USA; [IEEE INTERNATIONAL CONFERENCE ON COMMUNICATIONS], IEEE OPERATIONS CENTER, PISCATAWAY, NJ, 1 January 2003 (2003-01-01), pages 163 - 173, XP010642628, ISBN: 978-0-7803-7802-5 *
LOMET D: "Replicated indexes for distributed data", PARALLEL AND DISTRIBUTED INFORMATION SYSTEMS, 1996., FOURTH INTERNATIO NAL CONFERENCE ON MIAMI BEACH, FL, USA 18-20 DEC. 1996, LOS ALAMITOS, CA, USA,IEEE COMPUT. SOC, US, 18 December 1996 (1996-12-18), pages 108 - 119, XP010213181, ISBN: 978-0-8186-7475-4, DOI: 10.1109/PDIS.1996.568673 *
See also references of WO2020201248A1 *

Also Published As

Publication number Publication date
DE102019108856A1 (de) 2020-10-08
WO2020201248A1 (de) 2020-10-08

Similar Documents

Publication Publication Date Title
DE102013209868B4 (de) Abfragen und Integrieren strukturierter und unstrukturierter Daten
EP3948577B1 (de) Automatisiertes maschinelles lernen auf basis gespeicherten daten
DE112011103273B4 (de) Verfahren, Computerprogrammprodukt und Vorrichtung zur Weitergabe von Identitäten über Anwendungsebenen unter Verwendung von kontextabhängiger Zuordnung und gesetzten Werten
DE112020002892T5 (de) Aktives lernen für den datenabgleich
EP1779263A1 (de) Sprach- und textanalysevorrichtung und entsprechendes verfahren
DE112021000689T5 (de) Attestierung von neuronalen abläufen
EP3889806B1 (de) Bitsequenzbasiertes datenklassifikationssystem
WO2021204943A2 (de) Überwachungssystem mit mehrstufiger anfrageprüfung
EP3552140B1 (de) Datenbankindex aus mehreren feldern
EP3552141B1 (de) Server-computersystem zur bereitstellung von datensätzen
DE102024204719A1 (de) System zum Verhindern von Missbrauch großer Basismodelle und ein Verfahren dafür
EP4002145B1 (de) Listenbasierte datenspeicherung zur datensuche
EP4123517A1 (de) Integration verteilter machine-learning modelle
EP3948576A1 (de) Datenbankübergreifender index auf einem verteilten datenbanksystem
DE112021006377T5 (de) Terminieren von abfrageausführungsplänen in einer relationalen datenbank
EP4736401A1 (de) Computerimplementiertes verfahren zur bereitstellung einer, insbesondere zumindest teilweise textbasierten, ausgangssequenz
DE102019108858A1 (de) Maschinelles Lernen auf Basis von Trigger-Definitionen
WO2021204945A1 (de) Mikrocontroller- oder mikroprozessor-basiertes system mit berechtigungsprüfung für anfragen
EP4462315A1 (de) Vorrichtungen und verfahren für föderales rechnen
Hui et al. Analysis of decision tree classification algorithm based on attribute reduction and application in criminal behavior
EP4116858A1 (de) Maschinelles lernen auf basis von datenbankoperationen
CN120610875A (zh) 基于云服务器数据库的安全分析方法、装置、计算机设备
DE102024201985A1 (de) Verfahren zum Verifizieren der Informationssicherheit (Security) und/oder Betriebssicherheit (Safety) eines technischen Systems
DE102022125399A1 (de) Detektieren eines Angriffs auf ein zu schützendes Computersystem
DE202025002939U1 (de) Stärkung menschlicher Innovation und Exzellenz

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20211104

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20230418

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230526

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: BUNDESDRUCKEREI GMBH