Patent Application
20240411785
The invention relates to a method for processing database data in a distributed object database system according to the preamble of Patent claim 1.
The invention further relates to a device for processing database data in an object database system according to the preamble of Patent claim 8.
The invention relates to a modular object database for holistic, object-oriented business modeling, in which business data and processes of all types are represented separately in key and value objects, wherein the attributes and methods of the objects are likewise stored separately from one another, and the database management system itself is implemented as objects of the object database, as a result of which simpler handling of the object database and substantially improved data security is achieved overall.
The topics of business modeling, databases and data security addressed below are very complex topics, so only individual aspects and examples can be dealt with in the section on the prior art, though these are selected to illustrate the current state. The examples used below constitute only a small selection and make no claim to completeness. The designations and names used below serve to provide a better understanding and can be substituted by any other designations and names, in particular in the case of those designations which belong to the proposed object database, such as, for example, ‘business object
The term business modeling is frequently used as a synonym for business process modeling and is not to be confused with the term business model. In the following, business modeling goes beyond pure process modeling insofar as data and process modeling are considered together. For simplicity, the term enterprise includes any kind of company, firm, trade, administrative body, educational establishment, institution, organization, association, private individual etc.
The current state of business modeling is best reflected in internationally recognized standards such as, for example, ISO 9001 and IATF 16949, based thereon, for the automobile industry. ISO 9001 applies not only to manufacturing companies, but also to enterprises that provide any type of service. Certification of an enterprise according to ISO 9001 is intended to give customers, suppliers or other stakeholders the confidence that a company operates with high, standardized quality criteria. For this purpose, enterprise goals are to be defined, for example, in the areas of customer focus, supplier relations and leadership for the purpose of checking target attainment and pursuing continuous improvement. For this purpose, the ISO requests a process-oriented approach, which means that an enterprise must define a complete process landscape and structure.
In such process-oriented business modeling, procedures and their associated responsibilities are paramount, while data only function as parameters. Processes are often stored in their own databases, where they are generally only documented and can be called as information and but not run in an automated manner. Data flows are thus often difficult to track and automation is often very complex because the data are stored in different databases, such as, for example, in product data management systems, product requirement systems, standards information systems, personnel databases and project management systems.
Because of the different databases, it is very complex to link data or information to one another, such as, for example, link a drawing in a factory standard, stored as a document in a standard database, with the geometry of a component of a product which is stored in a product data database or, furthermore, automatically add the drawing to the component. In addition to the exemplarily mentioned individual databases, there are monolithic systems which cover entire subject areas, such as product lifecycle management systems (PLM). The various aspects of the PLM are based on a common database so that links between the data can be produced more easily, for example between the product requirements and the product data. Changes to the database are, however, associated with considerable effort.
Various methods are available for describing the process structures. Flowcharts are a visual representation of processes which are modelled by methods such as EPC (event-driven process chain) or BPMN (business process model and notification, a standardized description language). A frequently used type of visualization of processes is the swim lane diagram. For each area of responsibility or actor in a process, there is a row or column in which the process steps are shown for which the actor has responsibility. Arrows indicate the process flow, and the responsibilities are clearly shown visually by the transition from one process step in one lane to another in another lane. This type of representation makes it clear that in process-oriented business modeling one of the aims is to describe which role in the enterprise has to perform what and when. Various roles in an enterprise are responsible for the creation and execution of the processes; generally, it is not provided that data are able to autonomously control and execute processes.
Requirements for knowledge management are also to be found In the 2015 revision to ISO 9001, since this issue is becoming increasingly important in enterprises. Even if the value of knowledge cannot be specifically quantified, knowledge is an important capital for enterprises. Protecting knowledge is of great importance, because not everyone is allowed to access knowledge in its entirety. The aim of knowledge management is to make the correct information available in an enterprise at the correct time and the correct location. Various categories specify knowledge: implicit versus explicit, individual versus organizational and external versus internal. While explicit knowledge can be well documented, such as in manuals, standards, processes, rules, etc., implicit knowledge is difficult to capture because it is based on experience, skills, etc., making it individual knowledge, or it is present in data sets where it has to be obtained only by analyses. Knowledge can be documented in a wide variety of ways, as described above or even in large knowledge databases, which provide vast amounts of information and have not proven effective, or in the form of rules. Rules are often formulated as conditional sentences: if a condition is met, then make a certain decision or respond with an action. Rules can assist, for example, in analyzing data sets. If B is a child of A and A is female, then A is a mother of B. In this way, mothers can be found in the database without the need for ‘mother’ itself to be in the data set. And they can trigger actions: If product A has component B as a constituent, then add standard geometry C to component B. Business rule management systems (BRMS) allow enterprises to have rules defined by experts, which are implemented either by IT experts or automatically in software. Rules are an important form of expression for self-operating knowledge. The problem here is that rules must access data which are stored in different database systems, so access is possible only using interfaces which are complex to implement.
For storing data which arise in an enterprise—as described above, processes are generally also merely data-relational databases are usually used. They store data in the form of relational tables which include specific data and also keys to rows in other tables, the relations. The database management system (DBMS) is responsible for access to specific data in the tables, and, inter alia, provides data operations and ensures data integrity. The DBMS processes commands that are programmed in the Structured Query Language (SQL) and can thus create structures and store or read data. It is only with difficulty that complex data structures can be mapped onto the flat relational table structures. Likewise, complex table structures can only be changed and expanded with considerable effort.
Compared to relational databases, object-oriented databases (OODB) are rarely encountered. An OODB allows objects with their properties (attributes) and behaviors (methods) to be created as a structure or schema of data and allows values to be stored as their instances. The attributes themselves can consist of other objects. Here, too, a database management system controls the corresponding data processing steps, in this case the object-oriented database management system (OODBMS). In contrast to the relational methods, the object-oriented approach supports a simpler representation of complex data structures. Conversely, object-oriented databases have a disadvantage when it comes to the processing of large quantities of data because, for example, the access paths are more complex as a result of mechanisms such as inheritance, etc.
In principle, all real and virtual things and subjects which belong to a specific class with defined, identical properties, i.e. everything which makes up an enterprise, can be represented as objects: for example, a product with its sub-assemblies, a service, a product requirement, the customer, an offer, a standard, an organizational unit and training. The examples show that an object can have a more or less complex structure and can be composed structurally of other objects. For example, a customer can include a company with company name and address, a contact partner with their contact data, queries, orders, deliveries, etc., which can also be represented as objects (
An object database is known from DE 10 2010 010 035 A1, in which the objects each consist of units with attributes and methods. Object templates are used to create new objects. For this purpose, existing objects and associated relationships are copied and stored.
Furthermore, there are also the so-called NoSQL (often meaning “not only SQL”) databases. Key-value databases belong to this group. As the name implies, there are unique keys to which one or more values are assigned. The data are not accessed via relations, but instead only via the keys. Access via the values is thus not possible unless an additional back entry with the value-key relationship is created. Key-value databases do not work like the relational databases with fixed schemas and are well suited for distribution, but are not suitable for every application such as, for example, for the Semantic Web.
The Semantic Web is based on graph databases, which also belong to NoSQL applications. They represent structures by connecting nodes (entities) to edges (relations) and defining these graphs, for example with triples. Graph databases show advantages with respect to multi-layered networked data, such as in social networks: Man1 knows Woman1; Man knows Woman2; Woman1 knows Woman3. By means of traversing in the graph network, the second-degree contacts of Man1, for example, can be determined very efficiently: Woman3. Graph databases do not require a fixed schema, so they are very easily expandable. The property graph model provides for expansion. The nodes receive additional properties as key value pairs. This could be the age of the persons in the above-mentioned contact network.
If a data set is stored on only one server in a database, it is known as unique data. This computer is located in one location of an enterprise, and all requests from other locations are made to this one database, which can lead to performance problems in enterprises which operate internationally. This can be redressed by distributed databases. In this case, the data set can be distributed redundantly as replica on a plurality of servers at different locations, but increased demands are made on data consistency. Another possibility of distributing databases is provided by partitioned data storage. In horizontal fragmentation, the data records are not redundant on different servers, but only the data necessary in each case for a location are stored at the location. In the case of vertical fragmentation, the logically coherent data for a location are distributed, for example in the case of a personnel database the wages in the personnel department and the contact data at the production site. The patent specification EP 13 89 5720.4 proposes a methodology for a dynamically scalable relational database for a distributed heterogeneous platform with an agenda server and supervisor process module. These relate to data management, with the data itself also being stored in relational databases. Object-oriented databases store the data in more or less large databases, depending on requirements, and can also be fragmented if required. Object-oriented relationships, however, do not make distribution simpler. In this case also, fragmentation is referred to when logically coherent objects are distributed. The objects to be stored individually would render the OODBMS inoperably complex to manage.
As the examples show, enterprises store considerable amounts of data from a wide range of areas. In the course of developing new digital business models, the type and quantity of captured and stored data to be protected increases rapidly. Personal data are of particular significance. Thus, Section 1 of the German Federal Data Protection Act (BDSG) regulates the protection of the individual with respect to the handling of their personal data. In addition to these legal requirements, enterprises have a vested interest in protecting all other data from unauthorized access; this is because there is a lot contained in databases, perhaps even the entirety of an enterprise's knowledge: innovative products, efficient production processes, business processes, factory standards and working instructions, which describe special knowledge, etc. The protection of data against unauthorized access is of vital necessity for an enterprise.
The topic of data security is very complex and, therefore, reference is made here to the IT Baseline Protection Catalogs (IT-Grundschutz-Kataloge) of the German Federal Office for Information Security (BSI). Another example is the EU General Data Protection Regulation (GDPR), which is effective from May 2018. In this way, personal data belong to the user and not to the Internet service involved in data processing. In order to implement the provisions, an enterprise is granted a transition period of two years to take appropriate measures, such as, for example, adapting databases and establishing data protection processes. Despite security measures such as, for example, multi-factor authentication and cryptographic methods, there are still recurring incidents of unauthorized persons gaining access to confidential data. If, by a cyber-attack, access is gained to unique data records in a database, all stored data including their structures are available to the attacker. If there is unauthorized access to partitioned data, not all data records are surrendered in an unprotected manner, but only those stored on the relevant server.
The object of the invention is to propose a database methodology for holistic business modeling with all business data and processes of an enterprise which allows data including their structures to be more easily defined, expanded and changed and which is organized such that a scalable security concept with accompanying increased security for the database is ensured.
In order to achieve the object, the invention has the features of claim 1 and claim 8.
In principle, the object-oriented approach for the database is chosen because this methodology allows a simpler, intuitive definition of the data structures. All business data and processes in an enterprise can already be regarded per se as objects and can therefore easily be transferred into the object structure of the proposed object database as business objects (BOs). The term business object (BO) is an arbitrarily chosen name for differentiating from the usual objects in object databases. The proposed methodology is referred to as Semantic Business Modeling (SBM). An example is shown in
While conventional databases store several objects together in a database with keys, values and methods, SBM offers possibilities for partitioning, specifically fragmenting, the objects into key and value objects and separately storing attributes and methods. Furthermore, in contrast to conventional methods, the database functionality is fragmented in that it is itself held as objects in the object database and is implemented via assigned services as methods, as a result of which objects can operate according to different database principles. The executable code is additionally stored separately from the methods. This methodology, in principle, enables autonomously acting objects. SBM enables new, scalable storage structures for an object database, and a significant gain in data security can be noted in particular because the fragmented database functionality is distributed among a plurality of specially secured storage sites.
The key BO keys (key objects), which have a light background in
The allocation, i.e. the distribution of the BOs among different storage sites, can be stored in an ‘allocation’ BO. It does not contain any specific values, but instead also only keys. The access paths to the individual BOs are expediently divided into a plurality of structured BOs, such as domain name, server name, etc. If the ‘allocation’ BO is stored separately from other BOs, this further increases data security.
While the key BOs only contain references, special BOs store the specific values such as the postal code (‘postal code’ BO) and the forename (‘personal name’ BO), for example, in
Special value BOs can also contain formulas instead of specific values. The same methods as those described for the key BOs apply to the storage of the value BOs. The special value BOs are derived in the object-oriented sense from a base object, the ‘base value’ BO, which includes the attributes and methods that are valid for all special value BOs. In addition to the hardware distribution of the BOs, the content division into keys and specific data brings the further following advantages:
The generation of BOs including the definition of their structural relationships is possible with SBM using natural language sentences with a subject, predicate and sentence object. Sentence expansions with an adverb, adjectives and/or other grammar building blocks are possible. The ‘structure semantics’ BO (structure semantics object) is itself composed of the ‘subject’, ‘predicate’ and ‘sentence object’ BOs. Their specific values can be found in the ‘dictionary’ BO. Thus, the definition of the BO structures is itself treated as a BO, and so that stated above for BOs applies here also.
Not only simple relationships such as ‘has as component’ are possible, but also other, more complex structures such as ‘is special’, for example, in order to enable inheritance between two BOs. The complete structure of a BO for resolving the keys into values such as ‘customer’, for example, in
Until now, the focus has been on the handling of attributes and not on that of methods in the object-oriented sense. In SBM methodology, attributes of BOs are in turn BOs which are created with the ‘structure semantics’ BO, and methods are services which are entered in the BO ‘structure semantics’ BO (service semantics object).
The services are also defined using natural language sentences, consisting of a subject, a predicate and a sentence object, with the latter being optional. Semantic expansions with other grammar objects are possible. A service (the predicate) is assigned to a BO (the subject in the sentence), for example ‘create’ ‘offer’ or ‘specify’ ‘product’ (
The ‘process’ BO determines the specific process steps for the service assignments in the ‘service semantics’ BO. The structure of the ‘process’ BO consists of a ‘service semantics’ BO, which represents the calling service, and a ‘process step’ BO, which in turn includes a ‘start state’ BO, a further ‘service semantics’ BO, the service or delegate to be executed and an ‘end state’ BO. BOs can have any start and end states; they indicate which state a BO has, for example the ‘development’ state of a product which is currently being specified. If a service is requested and said service is to be found in the ‘process’ BO as a calling service, the associated process step is carried out by setting the associated start state of a BO and starting the associated delegate, which can also include creating a task for an employee. The delegate itself can also be a calling service in another process so that it is automatically started. If the service to be executed is completed, the end state is set. If the end state is simultaneously also a start state of another process, the new process is automatically started, as a result of which sequential processes are possible. The states do not need to be assigned to the same BO which is responsible for the calling service; this also applies to the service to be executed. Any process sequences can thus be established and completed. The ‘process’ BO can obtain further BOs as attributes, such as process managers, etc. with the aid of the ‘structure semantics’ BO. The above-mentioned with respect to BOs applies for the ‘process’ BO, including the subordinate BOs. This type of process definition, including the service definition, has the following advantages:
In principle, the ‘action’ BO is structured in the same way as the ‘process’ BO with the one difference that the delegate does not define a service but includes the name of an executable software module. The same principles apply to the procedure, except that, instead of a service, a software module is started via its name in order to carry out specific actions. The software modules are created as BOs in the object database and can be stored in a plurality of libraries distributed at a plurality of storage sites. The above-mentioned with respect to BOs applies for the ‘action’ BO, including the subordinate BOs. In addition to the already mentioned advantages for the ‘process’ BO, the actions offer further advantages:
Generally, certain roles and thus responsibilities are assigned to employees of an enterprise. Different roles are generally also subject to different data protection provisions. Therefore, permission concepts control specifically what and what not an employee with a particular role is allowed to see in terms of data. The permissions of individual roles are defined in the ‘permission’ BO, wherein one or more other BOs including the permission, such as read, change, etc., is/are assigned to a ‘role’ BO. Access to individual BOs or to whole BO hierarchies can thus be permitted. If necessary, access to individual instances of a BO can also be restricted. BOs can be assigned to specific contexts via a ‘context’ BO, such as shopping, personnel, development, etc., for example. In this way, permissions can also be defined for whole contexts without assigning individual BOs. By changing the context, the above-mentioned multilingual functionality can also be easily implemented. The above-mentioned with respect to BOs applies for the ‘permission’ BO, including the subordinate BOs. This type of permission concept has the following advantages:
Knowledge management is more efficient and more effective when not only information is provided, but when the knowledge itself assumes an active role and itself knows where it needs to be applied. Since process management is always part of knowledge management, the ‘service’, ‘process’ and ‘action’ BOs are already part of the active knowledge. The ‘rule’ BO supports decisions and services by storing rules which are semantically defined with natural language sentences as in the case of the ‘structure semantics’ BO. In the condition part, reference is made to the attributes of BOs or to their states, with it being possible to logically link several conditions to one another. The consequence part contains services or describes new relationships which do not necessarily have to reference BOs. In addition to the possibility of representing knowledge in rules, other BOs are conceivable which can store and allow knowledge to be handled in other representations. The above-mentioned with respect to BOs applies for the ‘rule’ BO, including the subordinate BOs. This manner of managing knowledge has the following advantages:
Clients communicate with the database via instances of the BO ‘dispatcher’. The dispatcher knows which other BOs provide it with services, processes and actions in order to provide the requested information. It asks, for example, the ‘allocation’ BO where the data are to be found, the ‘permission’ BO whether access is permitted and corresponding ‘cluster’ BOs which are to provide it with values. Its own methods are also defined and controlled via the ‘service’, ‘process’ and ‘action’ BOs. The above-mentioned with respect to BOs applies for the dispatcher BO, including the subordinate BOs. This type of data access has the following advantages:
While the key BOs are table-oriented and thus are rather less suitable for networked data, the ‘base graph’ BO provides attributes and methods which are necessary for BOs operating according to the graph principle and can be inherited by this BO. To give just one example, a ‘contacts’ BO can be created. This includes the above-mentioned example as 3 instances: ‘Man1’ ‘knows’ ‘Woman1’; Man1 ‘knows’ Woman2; ‘Woman1’ ‘knows’ ‘Woman3’. Further instances can be: ‘Woman1’ ‘is married to’ ‘Man3’; ‘Man3’ ‘is the father of’ ‘Woman2’. The methods provide, for example, traversal algorithms via the ‘action’ BO. Any other BOs can be defined which operate according to the graph principle. The above-mentioned with respect to BOs applies for the ‘base graph’ BO and BOs derived therefrom, including the subordinate BOs. The possibility of using graph principles has the following advantages:
Exemplary embodiments of the object database are shown in the figures.
| Number | Date | Country | Kind |
|---|---|---|---|
| 10 2018 110 441.3 | May 2018 | DE | national |
| 10 2018 111 867.8 | May 2018 | DE | national |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 17051784 | Oct 2020 | US |
| Child | 18806163 | US |
