EP4402579A1 - Computerimplementiertes datenbankverfahren, system zur datenverarbeitung, computerprogrammprodukt und computerlesbares speichermedium - Google Patents

Computerimplementiertes datenbankverfahren, system zur datenverarbeitung, computerprogrammprodukt und computerlesbares speichermedium

Info

Publication number
EP4402579A1
EP4402579A1 EP22789206.4A EP22789206A EP4402579A1 EP 4402579 A1 EP4402579 A1 EP 4402579A1 EP 22789206 A EP22789206 A EP 22789206A EP 4402579 A1 EP4402579 A1 EP 4402579A1
Authority
EP
European Patent Office
Prior art keywords
data
dimension
column
stored
database
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
EP22789206.4A
Other languages
English (en)
French (fr)
Inventor
Andreas LAZAR
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.)
Swedex Holding GmbH
Original Assignee
Swedex Holding 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 Swedex Holding GmbH filed Critical Swedex Holding GmbH
Publication of EP4402579A1 publication Critical patent/EP4402579A1/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/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21—Design, administration or maintenance of databases
    • G06F16/211—Schema design and management
    • 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/22—Indexing; Data structures therefor; Storage structures
    • G06F16/221—Column-oriented storage; Management thereof

Definitions

  • the invention relates to a computer-implemented database method.
  • the invention relates to a system for data processing, a computer program product and a computer-readable storage medium.
  • Database methods relating to the storage, management and/or retrieval of data in databases are already known from the prior art. Companies, for example, store information about their customers, cooperation partners, orders, inventory, products offered, order status, etc. in databases.
  • data can be stored in particular in the fields of multi-row and multi-column tables.
  • an identifier assigned to the respective customer e.g. an ID
  • an identifier assigned to the respective customer can be stored in the first column and first name, last name, telephone number, address etc. in the following columns.
  • the attributes ID, first name, surname, ...) and in the lines below in each line the information belonging to a customer. If data about products, inventory, order status, etc. is to be saved, the procedure can be completely analogous.
  • At least one dimension is assigned to the basic data from at least some fields, with the at least one dimension indicating that this basic data is related to one another, in particular through translations into different languages and/or through different representations for different business branches,
  • data sets can be dimensioned efficiently.
  • data records no longer have to be divided into several tables and then reassembled for the query, in particular with JOINs, i.e. (SQL) commands for merging data from different tables.
  • SQL i.e.
  • a table using one or more dimensions can be used according to the invention.
  • a dimension or the dimensions are used according to the invention in order to be able to store information or information under different aspects or in different forms. Different basic data that belong to one dimension can therefore in particular be different forms or aspects of the same information.
  • the numbers 5000, 5001 and 5002 could be assigned as dimension IDs to the three basic data entries "book", “book” and “livre” and stored in the dimension column, whereby this is to be understood purely as an example and of course other numbers, alphanumeric sequences or identifiers of a completely different kind can be used.
  • the only requirement is that the dimension IDs belonging to a dimension differ in order to take into account the different characteristics, for example the different languages.
  • the dimension described as an example, which enables several translations, can be assigned the name "language”.
  • a dimension provided according to the invention can of course also relate to a different relationship between basic data.
  • the database includes or should include basic data for several branches of a company.
  • the “branch office” dimension can also be provided. If there are several branches, it may be the case that the same product is sold by the different branches at different prices, for example in different currencies and/or at different amounts in the same or different currencies.
  • the different prices for the same product can be stored in a table with the “branch” dimension, with the different prices in turn being assigned dimension IDs, which then in turn belong to the “branch” dimension.
  • the meaning of which dimension branch is stored in the data table particularly preferably in a separate row of the data table.
  • a data table for a dimension “Language” with dimension branches “German” and “English” may have two rows containing the words “German” and "English”, respectively. It is then particularly advantageous if a unique ID assigned to the respective row, in particular a MasterRecordID assigned to the row, is used as the dimension ID for the respective dimension branch.
  • the storage according to the invention of related data or data representing different aspects or forms of information in a table and the associated use of the dimension(s) offers considerable advantages.
  • a dynamic script generator can be used.
  • the query can be accelerated many times over. As a result, (computing) time, effort and energy can be saved.
  • the method according to the invention is therefore particularly sustainable.
  • All of the basic data to be stored is advantageously stored in a table, the data table.
  • a plurality of base data from a data column, to which the same dimension is assigned, are expediently stored in adjacent or consecutive fields of the relevant data column.
  • Dimension IDs associated with base data are also conveniently stored in those fields of the dimension column that are in the same rows as the respective base data.
  • one or more data sets are obtained or stored which have a number of different dimensions or dimension branches, which are stored in columns using dimension references.
  • For the dimension data further rows are created in the same table, the data table, which contain dimension data for columns of a dimension.
  • data can in particular be stored, managed and/or retrieved in digital form.
  • Basic data are in particular the data to be stored and managed using the database. This data can be provided, for example, by at least one user of the database, for example using at least one suitable user interface. Customer data as well as product or service and order data of one or more companies are mentioned purely as examples of basic data.
  • additional data is usually stored in the table or tables, which are used, for example, for database-internal data management or queries.
  • additional data are identifiers, i.e. identifiers, called IDs for short, which are assigned to entries in order to make them findable.
  • the fields in the same row remain empty or include empty entries, in particular the specification NULL.
  • the corresponding lines can contain nothing at all or an entry that indicates that there is no data content, with an example being that the expression "NULL" is in the corresponding fields.
  • columns in a row that do not belong to its dimension remain empty or are displayed as empty.
  • the MAX() command is preferably, in a manner known per se, one that outputs the largest value, ie the maximum, of a selected column. If the data query can be done using the MAX() function, query time can be saved to a significant extent, especially when compared to querying data that is distributed across multiple tables and for which the JOIN function must be used.
  • no dimension IDs are stored in the dimension column in the fields in the same row, in particular these remain empty or empty entries, in particular the specification NULL, include.
  • a matching master ID is assigned to a plurality of basic data stored, in particular, in different rows of the data table.
  • the multiple basic data then refer to the master ID or a master record. If this is the case, the master ID is preferably stored in those rows of the data table in which the fields of the basic data concerned are located, but in another column that is not a data column, the master ID column.
  • each row of the data table is assigned an ID, with the IDs of all rows of the data table being different from one another. Then they are unique - at least within the data table. It has proven to be particularly suitable, for example, if consecutive numbers are assigned to the rows of the data table, e.g. ID "1" for the first row, ID "2" for the second row, etc. Of course, you don't have to start with "1", you can any other number can be chosen as the starting point for the first line.
  • IDs which can also be referred to as row IDs, are or are particularly preferably stored in the first column of the data table, which can then also be referred to as the ID column or row ID column.
  • Such row IDs can be globally unique IDs. Such IDs are also referred to as GlIIDs, the abbreviation GIIID standing for Global Unique Identifier. They can also be so-called MasterRecordIDs.
  • a further particularly advantageous embodiment is also characterized in that information about the dimension or, in the case of several, the respective dimension is stored in a further table.
  • a table is referred to here as an object table.
  • the object table then preferably includes an ID column in which an ID belonging to the dimension or dimensions in question is listed.
  • This ID can also be referred to as the parent ID of the dimension or dimensions.
  • the parent dimension ID can also be referred to as the dimension master ID.
  • the dimension master ID there is in particular a unique identifier assigned to the (respective) dimension and the dimension leads to several entries, one for each of the different dimension IDs.
  • an object table can also have a name column in which a name assigned to the dimension or dimensions is listed.
  • dimension names can be language, branch, and/or country.
  • the object table may have an object dimension ID column. Using this field or the fields in this column, it is possible to assign a dimension directly to an object, such as a business object. If this is the case, individual fields do not have to be configured with a dimension, but all fields of the object have a dimension, which is inherited by the object.
  • Objects are preferably stored in the database, with each object having the basic data from one or more fields from one or more data columns in the data table, and each object being assigned an object ID.
  • An object is to be understood, in particular, as a collection of related data that is or is preferably stored in a table format in the database.
  • the database is used by one or more companies, one can also speak of business objects, or BOs for short.
  • a collection of data that belongs to a specific product or a collection of data from a customer account is given purely as an example for an object or business object.
  • a matching master ID is or will be assigned to a number of these rows.
  • multiple rows with a matching MasterRecordID are reported as a related data record.
  • An object can have one record or multiple records.
  • the (respectively) matching master ID is or is then preferably stored in a master ID column of the data table in the relevant rows belonging to the object or data record of the object.
  • the rows of the data table are assigned unique row IDs, e.g. consecutive row IDs, which are preferably located in the first row of the data table or are stored there, it is particularly preferred that the row ID, the in the first row of the respective object or the respective data record, in other words the master row of the respective object or the respective data record lies in another column of the data table in several, namely all rows belonging to the object or the data record is taken over.
  • the object table can also include a column that indicates whether it is a dimension, dimension column. For example, in the dimension column or rows that relate to a dimension, there can be a 1 and in that or those rows that relate to an object, there can be “NULL” to clarify this distinction.
  • An object can have a dimension, and fields in an object can themselves have a dimension.
  • the dimension of an object may also be referred to as the major dimension to distinguish it from the dimensions of fields of the object, which may also be referred to as field dimensions.
  • an object “product” exists or is stored in the database and a product name in two or more different languages and prices for the product from different branches belong to this product and are or are stored in the data table .
  • the "Product” object has two fields in particular, each of which has a dimension, namely the "Language” dimension and the "Branch office” dimension.
  • the product names in the different languages e.g. "book”, “Buch” and “livre”
  • the different prices e.g. 15 euros for a branch in Germany, 19 $ for a branch in the USA, 20 GBP for a branch UK branch and 17 euros for a French branch.
  • an object “product” has or is assigned the dimension “client” in order to take account of a situation with more than one client. It is then expedient to create it individually for each client, such as client A and client B. Then one or more fields of the object can in turn have a dimension, eg a “Price” field has the “Branch” dimension for different branches in different countries, so that the price can be or must be called up in different currencies.
  • the data belonging to an object with a dimension, in particular a field dimension(s), are or are expediently stored in a number of rows in the data table.
  • a first line belongs to it, which in particular contains jointly valid data and which can also be referred to as the master line, as well as underlying, for example immediately underlying, lines , for dimension data.
  • Basic data of the object can be or are stored in the master line, which have no dimensions, preferably all basic data which have no dimensions.
  • the master row and the underlying rows for the dimension data are preferably assigned a common, matching MasterRecordID. This can be the row ID listed in the first row in the data table belonging to the object, the master row. In other words, the row ID or MasterRecordID from the master row is then used for the additional rows with dimension data.
  • dimension or dimensions in turn can or do represent objects. These can also be referred to as dimension objects. For reasons of simplicity, however, reference is made here to objects on the one hand and dimensions on the other.
  • the data column or data columns of the data table preferably each have the name “Data_[number]”, for example “Data_0”, “Data_1”, “Data_2” and “Data_3”. These names are preferably used for data columns provided by default. It is of course also possible that user or customer-specific data columns are or will be provided. Such can be named, for example, "C_Data_[Number]", where the "C” is an abbreviation for "custom”. The prefix "C-" can also be used in other tables to indicate that user or customer-specific objects or data are involved. For example, any user or customer-specific objects in the object table can start with "C_”.
  • a further particularly advantageous embodiment is also distinguished by the fact that information about the structure of the objects is stored in a further table, field table. Then it applies in particular that the field table includes the information in which data column or which data columns of the data table the basic data of the respective object are stored.
  • the field table can then include a column in which the names of those data columns used in the data table are specified, in which basic data for the respective object are stored.
  • This column can be referred to as the field name column.
  • the field names refer to actual fields in the data table.
  • the field table can include a column in which it is specified which type of base data is stored in the data column or columns of the respective object. This column can be referred to as the label column.
  • the field table can include a column in which it is specified whether the basic data belonging to the object in the data columns listed in the field name column each have a dimension or not and preferably which dimension is assigned to them.
  • This column can be called the dimension column.
  • this can be done using the superordinate dimension ID, i.e. the dimension master ID.
  • rows of base data that do not have a dimension assigned may have "NULL" in the dimension column of the field table, or the corresponding fields may remain empty. Lines of basic data to which a dimension is assigned preferably contain the dimension master ID of the corresponding dimension.
  • the field table can also include a column in which the object ID assigned to the respective object is specified. This column can be referred to as the object ID column.
  • Objects can include base data in multiple data columns of the data table. If this is the case, a line in the field table is preferably provided in the field table for each data column in which basic data of the relevant object are stored. The object ID is then preferably stored in each column of the object in the object ID column, ie the same ID several times.
  • the field table can also include other columns.
  • each type of table preferably exists exactly once, in particular exactly one data table and/or exactly one object table and/or exactly one field table.
  • An exception can exist in particular if the procedure is used or implemented decentrally and, for example, there are copies of the respective table type on several servers or there are separate versions or copies of the respective table type for different clients.
  • existing relations between different objects can be stored in a further table, which can be referred to as a relation table.
  • a relation table If a relation table is used, a relation ID and/or a relation type and/or an object ID and/or an object field ID can be stored in it for the respective relation.
  • a separate column can be provided in the relation table for the relation ID and/or the relation type and/or the object ID and/or the object field ID.
  • instances can be stored in a further table, which can be referred to as an instance table.
  • an instance ID and/or an instance name and/or an instance license and/or a secret code can be stored for the respective instance in an instance table.
  • a column in the instance table can be provided for each of these aspects.
  • a number of instances can be provided in particular for the purpose of being able to filter for data from different users of the database, for example different business partners. In other words, the instances can represent main filters in order to output data for different users, such as business partners.
  • the data table can then comprise a column in which instance IDs are or are stored, instance ID column.
  • an API particularly preferably a RESTfuI API, is called up or used to retrieve data from the database.
  • REST stands for "REpresentational State Transfer” and API for "Application Programming Interface”.
  • a further particularly preferred embodiment is characterized in that data is retrieved from the database, in particular from the data table, using a function which in each case supplies the largest of all values stored in a selected column.
  • a function is given, for example, by the MAX() function.
  • a dynamic script is used for retrieving data from the database, in particular the data table.
  • Dynamic script generator can be used for retrieving data from database, especially data table.
  • the method according to the invention can also be realized or implemented as “Software as a Service” (SaaS). In this case, in particular, no local installation of software is required for the implementation or use of the method, but this can take place via web access, eg via a browser or in some other way.
  • SaaS Software as a Service
  • the Internet or a cloud can be used in a manner known per se for an SaaS solution.
  • the subject matter of the invention is also a system for data processing, comprising at least one processor and one or more memory devices, wherein the at least one processor is configured in such a way that it executes the steps of the method according to the invention.
  • the system according to the invention can also be a distributed system with hardware at different locations and suitable networking, for example via the Internet.
  • the invention relates to a computer program product, comprising instructions which, when the program is executed by at least one computer, cause the at least one computer to carry out the steps of the method according to the invention.
  • the invention relates to a computer-readable storage medium, comprising instructions which, when executed by at least one computer, cause the at least one computer to carry out the steps of the method according to the invention.
  • FIG. 1 shows a purely schematic block diagram of a conventional database in which the data is divided into a number of tables in a relational manner
  • FIG. 2 shows a purely schematic block diagram with the steps of an exemplary embodiment of the method according to the invention
  • FIG. 3 shows a database in which basic data are stored in a data table according to an exemplary embodiment of the method according to the invention.
  • FIG. 1 shows a database 1 of a previously known type in a purely schematic representation.
  • Tables 2-11 which - also purely schematically - illustrate how the data storage takes place.
  • the arrow shown between Database 1 and Tables 2-11 is intended to make it clear that the data is or will be stored in Database 1.
  • Objects specifically business objects, are stored in the database, namely accounts, orders, products, order details, order statuses and countries.
  • a table 2-7 had to be created for each of these objects. Some of the tables are connected to one another via relations 12. Translations may also need to be stored in database 1 for some data entries. For example, because several branches of a company from different countries want to use the database 1 or an integrated database 1 is obtained for all these branches.
  • three tables 4, 6 and 7 include fields that require translation. These fields, which have a gray background in Figure 1, are ProductName, Status and CountryName in Tables 4, 6 and 7. In order to be able to support the translation, each translation must have its own Table 8, 9, 11 generated and the translation in the associated 8, 9, 11 are performed. The languages are or will be stored in Table 10.
  • FIG. 2 shows—in a purely schematic block diagram—the steps of the exemplary embodiment of the method.
  • the top of FIG. 3 shows, likewise schematically, a database 13 in which data is stored in a manner according to the invention and from which data is retrieved in a manner according to the invention.
  • a data table 14 shows excerpts of the tables for illustration and these can and generally will include considerably more entries.
  • step S1 basic data is stored in data columns 17 provided for this purpose in the multi-column and multi-row data table 14 (step S1).
  • the data columns 17 are the four right-hand columns of the data table 14. It should be emphasized that, in principle, this can include both fewer and more than four data columns 17.
  • the data table 14 also includes an ID column 18 (first, left column), a master ID column 19 and a dimension column 20.
  • a particularly unique row ID e.g. a globally unique ID, is specified in the ID column 18 .
  • this is a consecutive number with the rows of the data table 14 .
  • only a section of the entire data table 14 is shown in FIG.
  • At least one dimension is assigned to the basic data from at least some fields, with the at least one dimension indicating that this basic data is related to one another (step S2).
  • the basic data to which a dimension is assigned is given by translations of the same expression into different languages.
  • the “language” dimension is therefore assigned to the relevant basic data.
  • the basic data stored in the data columns 17 in the data table 14 are genders or gender information for persons.
  • a "gender” object is stored in the data table.
  • the "Gender” object includes the three options “Male”, “Female” and “Miscellaneous”. Each gender option has a code, which is given by these designations, a type specification, specifically "M", "F” and “D” in the corresponding order, a name and also a salutation.
  • a data record is stored in the data table 14 for each of the three gender options of the object “gender”. For “Male” in the first through third rows shown in Data Table 14, for "Female” in the fourth through sixth, and for "Divers" in the seventh through ninth.
  • the assignment of the respective dimension to the basic data concerned is done by in those rows in which the fields of the basic data concerned are located, in another column that is not a data column and which is used for the assignment of the or of the respective dimension is provided, dimension column 20, to which or the respective dimension belonging dimension IDs are stored, with dimension IDs belonging to the same dimension differ from one another.
  • the dimension IDs are stored in the third column 20 from the left.
  • Basic data is stored here in German and English, so that two different dimension IDs are used for these two different languages.
  • the fact that there are two languages and thus two dimensional branches here is to be understood purely as an example.
  • the “language” dimension could include other languages in addition to German and English, such as three, four, five or even more languages.
  • the dimension ID 410348 is used for the German version and the dimension ID 410350 for the English language is to be understood as an example and other numbers or other alphanumeric identifiers or other types of identifiers can also be used.
  • the entry of these dimension IDs in the corresponding rows indicates that a dimension is assigned to this basic data, in this case the dimension "Language”.
  • the dimension IDs can be found on the second and third rows of each record.
  • the second, fifth and eighth rows from the top of dimension column 20 each contain "NULL", since neither the code nor the type of gender has the dimension "Language” assigned to it.
  • the specification "NULL” in dimension column 20 is found for the object "Gender” in the top row of the three associated data records for the three gender options, i.e. in the first, fourth and seventh rows of data table 14.
  • These rows can also are referred to as master lines of the respective data set.
  • the code and type are listed in these lines, i.e. the basic data without dimensions.
  • a matching master ID is assigned to a plurality of basic data (step S3).
  • the multiple lines then represent a record or belong to a record, with a dimension existing.
  • the master ID is stored in another column that is not a data column, the master ID column 19, in those rows of the data table in which the fields of the basic data concerned are located.
  • a common, matching master ID (MasterRecordld) is assigned to each of the three lines of a data record, which is stored in the MasterRecordld column 19 in the corresponding lines.
  • the common master ID 457465 is assigned to the basic data for the gender option "Male”.
  • the basic data of the gender option "Female” is assigned the common master ID 457502 and the gender option “Diverse” is assigned the master ID 468819.
  • These basic data therefore each refer to one master ID or one master record.
  • this Master ID 457465 of Male matches the ID from the first row of ID column 18 (below the title row).
  • This ID from column 18 is the ID of the public record and the match means that the entries from the three rows of the record, all of which have the 457465 as the master ID in column 19, are effectively one entry or "Record”. You can also say that the master ID of the respective master row is transferred to the rows below for the dimension data.
  • the master ID 457502 of "Female” matches the ID in the fifth row of ID column 18 and the master ID 468819 of "Divers” matches the ID from the eighth row of column 18.
  • This ID too -Numbers are all to be understood purely as examples and could in principle be different.
  • the master IDs represent the dimension IDs assigned to the two languages. As you can see, these, i.e. 410348 and 410350, are used in column 20 with the dimension ID of the three data records of the "Gender" object. This indicates which line concerns or includes data in German and which data in English.
  • the object table 15 includes an ID column 21 in which an ID belonging to the dimension or dimensions in question is listed.
  • the ID 466 is assigned to the object "Gender” and the ID 480 to the dimension "Language”.
  • this ID can also be understood and referred to as the dimension master ID.
  • objects are stored in the database, with each object associated with the base data from one or more fields from one or more data columns of the data table.
  • An object ID is assigned to each object (step S5).
  • information about all objects stored in the data table 14 including all objects representing dimensions that are associated with basic data of the objects are stored in the object table 15 .
  • the object IDs assigned to the objects are stored in the ID column 21 of the object table 15 .
  • the object table 15 further includes an object dimension ID column 24, abbreviated as "BoDimld” in the table.
  • object dimension ID column 24 abbreviated as "BoDimld” in the table.
  • the field table 16 includes the information in which data column 17 or which data columns 17 of the data table 14 the basic data of the respective object are stored.
  • the field table 16 also includes a column in which the names of those data columns 17 used in the data table 14 are specified, in which basic data for the respective object are stored. This column is referred to as field name column 25.
  • the field table 16 also includes a column that specifies which type of base data is stored in the data column or columns of the respective object.
  • This column which includes field names, can also be referred to as the label column 26 or label name column. As you can see, the information code, name, salutation and type can be found here.
  • the field table 16 also has a dimension column 27 which indicates whether the basic data associated with the object is in the dimensions specified in the field name column 25 listed data columns each have a dimension or not.
  • the dimension column 27 also indicates which dimension is assigned. As you can see, it is recorded here that a dimension is assigned to the name and salutation of the object "gender", but not to the code and type. Column 27 below indicates that the dimension object "Language” has no dimension associated with it. It is a dimension and there are "NULL” indications in these two columns of row 27.
  • Field table 16 also includes a column in which the object ID assigned to the respective object is specified, object ID column 28.
  • the unique identity of the respective object is therefore specified here, with the object “gender” having the object ID 466 and the dimension object “Language” has the object ID 480, which is the parent dimension master ID.
  • further columns of the field table 16 are an ID column 29, a field caption name column 30, a field type column 31 and a field size column 32.
  • the code of the respective gender is stored in data column 17 "DATA_2”
  • the name of the respective gender is stored in data column 17 "DATA_1”
  • the salutation for the respective gender is stored in data column 17 "DATA_16” and data column 17 “DATA_15” the gender type, specifically the abbreviations "M”, "F” and "D”.
  • dimension column 27 a dimension is assigned to the name and salutation, namely the one with the dimension master ID 480, i.e. according to the object table the dimension "Language”.
  • Field CaptionNames column 30 contains field names for display.
  • the FieldTypes column 31 here includes the SQL data type of the field.
  • the field size column 32 contains the size of the field for the data type specified in the field type column 31.
  • existing relations between different objects can be stored in a relation table.
  • a relation ID and/or a relation type and/or an object ID and/or an object field ID can then be stored in such a table for the respective relation.
  • an instance table it is also possible for different instances to be stored in an instance table.
  • an instance ID and/or an instance name and/or an instance license and/or a secret code to be saved.
  • multiple instances make it possible to take into account a situation with multiple customers or clients.
  • An instance is then preferably assigned to each customer or client and it is only possible for each customer to call up data from his instance, so that data protection is guaranteed.
  • the same structure is used for all objects when setting the dimension for fields for which dimension values need to be stored, such as gender name, as described above.
  • the storage of related data in a data table 14 and associated use of dimension(s) offers significant advantages.
  • it is not necessary to generate several script queries in order to obtain results from the database 13 and the JOIN function for connecting several tables (cf. FIG. 1) is not ( absolutely necessary.
  • a database 13 with a dynamic infrastructure is obtained.
  • a dynamic script generator can be used and queries for data from the one data table 14 can be done using a MAX() function. The query can therefore be accelerated many times over in relation to previously known relational solutions. As a result, (computing) time, effort and energy can be saved.
  • the method according to the invention is therefore also particularly sustainable.
  • each object has fields that indicate the structure of the object.
  • the data is stored in the data table 14, which specifically includes empty entries or the information "NULL".
  • the MAX() function can be used to get the data for the respective dimension.
  • a public record for storing the public fields of the object and additional dimension entries for each dimension which the object has or whose fields have are stored in the data table 14 for each entry (record).
  • the dimension ID in the public record is NULL and the MasterRecordID of the public record is used as the master record ID for all entries (cf. data table 14, in particular columns 18 and 19).
  • the Parent Dimension ID 100 represents the Language object, which represents a dimension. In this example, if data is stored for the "Item" and two languages exist, three entries are inserted, a public record with the ItemCode, the length and width and two other entries for the ItemName in two different languages.
  • Data can be queried using the MAX() function, which is a function that returns the largest value of a selected column.
  • data table 14 If data are stored for the two different languages and the two countries with the different currencies, one obtains in data table 14, for example:
  • the script query is then:
  • the dimension set is: (200,600) , (200,601)
  • the script query is:
  • a dynamic script can be generated, which is explained below using an exemplary embodiment as an example.
  • Bold field refers to an object, such as a business object ID, so that it is known to which business object the entries belong.
  • the "GetData” procedure can be created.
  • MS4_data there are fields whose names begin with “data_” (data_1, data_2, data_3, .... cf. columns 17 of table 14 in Figure 3) and a mapping is stored between the field names in the business object and the real field column in MS4_data.
  • the ItemCode is mapped to Data_1, the ItemName to Data_2, etc.
  • All fields of a business object can be obtained via e.g.
  • Using the MAX() function saves a significant amount of time when querying. This is particularly so in comparison with queries that require the JOIN function, since the data is not stored in one table but in different tables, as is shown in FIG. 1 by way of example.
  • the database 13 shown schematically in FIG. 3 can include suitable hardware, in particular at least one storage device, or be implemented on such a device. This can be part of an exemplary embodiment of a system for data processing according to the invention. Such a system then also comprises at least one processor which is configured in such a way that it executes the steps of the method according to the invention.
  • a system according to the invention can of course also be a distributed system with hardware at different locations and suitable networking, for example via the Internet.
  • the method according to the invention can also be implemented as “Software-as-a-Service”.

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)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Die Erfindung betrifft ein computerimplementiertes Datenbankverfahren, bei dem - in einer mehrspaltigen und mehrzeiligen Datentabelle (14) einer Datenbank (13) zu speichernde Basisdaten in dafür vorgesehenen Daten-spalten (17) gespeichert werden (S1), - den Basisdaten aus zumindest einigen Feldern wenigstens eine Dimension zugeordnet wird, wobei die wenigstens eine Dimension anzeigt, dass diese Basisdaten miteinander in Beziehung stehen (S2), insbesondere durch Übersetzungen in verschiedene Sprachen und/oder durch verschiedene Darstellungen für unterschiedliche Geschäftsniederlassungen gegeben sind, - wobei die Zuordnung der oder der jeweiligen Dimension zu den oder den jeweils betroffenen Basisdaten erfolgt, indem in denjenigen Zeilen, in denen die Felder der oder der jeweils betroffenen Basisdaten liegen, in einer anderen Spalte, die keine Datenspalte ist und die für die Zuordnung der oder der jeweiligen Dimension vorgesehen ist, Dimensionsspalte (20), zu der oder der jeweiligen Dimension gehörige Dimensions-IDs gespeichert werden, wobei sich Dimensions-IDs, die zur gleichen Dimension gehören, voneinander unterscheiden.

Description

BESCHREIBUNG
Computerimplementiertes Datenbankverfahren, System zur Datenverarbeitung, Computerprogrammprodukt und computerlesbares Speichermedium
Die Erfindung betrifft ein Computerimplementiertes Datenbankverfahren. Darüber hinaus betrifft die Erfindung ein System zur Datenverarbeitung, ein Computerprogrammprodukt und ein computerlesbares Speichermedium.
Datenbankverfahren, die das Speichern, Verwalten und/oder Abrufen von Daten in Datenbanken betreffen, sind aus dem Stand der Technik vorbekannt. Unternehmen beispielsweise speichern in Datenbanken Informationen über Ihre Kunden, Kooperationspartner, Bestellungen, den Bestand, angebotene Produkte, den Bestellstatus etc.
In Datenbanken können Daten insbesondere in den Feldern mehrzeiliger und mehrspaltiger Tabellen abgelegt werden. Rein beispielhaft sei genannt, dass in einer Tabelle die zu den Kunden eines Unternehmens vorhandenen Daten abgelegt sind bzw. werden. Hier kann etwa in der ersten Spalte ein dem jeweiligen Kunden zugeordnete Identifikator, z.B. eine ID, gespeichert werden und in den darauffolgenden Spalten Vorname, Nachname, Telefonnummer, Adresse etc. In der ersten Zeile jeder Spalte können als Überschrift die Attribute (ID, Vorname, Nachname, ...) genannt sein und in den Zeilen darunter in jeder Zeile jeweils die zu einem Kunden gehörigen Angaben. Sollen Daten über Produkte, den Bestand, den Bestellstatus etc. gespeichert werden, kann völlig analog vorgegangen werden. Teilweise besteht Bedarf daran, zu einem oder mehreren Einträgen in dem bzw. den Feldern einer Datenbanktabelle weitere Daten zu speichern, die mit dem bzw. dem jeweiligen Eintrag in Beziehung stehen. Rein beispielhaft sei genannt, dass eine globale bzw. integrierte Datenbank für ein Unternehmen mit mehreren Niederlassungen in verschiedenen Ländern gewünscht ist und die Daten für alle Niederlassungen in geeigneter Form vorliegen sollen. Dann kann es sich ergeben, dass beispielsweise eine Produktbezeichnung nicht nur in einer sondern in mehreren Sprachen abzulegen ist, damit diese in der Datenbank sowohl für eine Niederlassung z.B. in Frankreich auf Französisch als auch für eine Niederlassung z.B. im Vereinigten Königreich in Englisch zur Verfügung steht.
Der Anmelderin ist bekannt, dass hierfür bisher zusätzliche Tabellen angelegt werden, welche die Übersetzungen umfassen. Rein beispielhaft sei genannt, dass in einer Tabelle, welche Daten über die Produkte eines Unternehmens enthält, die Produktbezeichnung „Livre“ in Französischer Sprache gespeichert ist, weil der Mutterkonzern seinen Sitz in Frankreich hat. Soll eine englischsprachige Tochter die Datenbank gleichermaßen bequem nutzen können, wird zur Hinterlegung der englischen Übersetzung „Book“ der Produktbezeichnung eine separate Tabelle angelegt, die in Bezug zu der ursprünglichen, französischsprachigen Tabelle gesetzt wird.
Diese Lösung ist statisch. Es müssen für jedes Projekt, welches beispielsweise mehrere verschiedensprachige Niederlassungen abdeckt, eine spezifische Datenbank und diverse Tabellen angelegt und die Bezüge der Tabellen (auch Relationen bzw. „relations“ genannt) angelegt werden. Es ist auch erforderlich, eine spezifische Abfrage, z.B. SQL-Skript-Abfrage, zu kreieren, da die Übersetzungstabellennamen und Feldnamen nicht übereinstimmen. Wenn ein Projekt für ein Unternehmen mehrere Niederlassungen abdecken soll, und alle Daten für alle Niederlassungen in einer Datenbank abzulegen, um ein integriertes System zu erhalten, besteht neben der Statik die Problematik, dass die Datenbank vergleichsweise komplex wird und vergleichsweise viele Abfragen (Englisch: queries) benötigt, um das gewünschte Ergebnis zu erhalten. Die Abfragezeit kann daher hoch ausfallen.
Ausgehend davon ist es eine Aufgabe der vorliegenden Erfindung, ein computerimplementiertes Datenbankverfahren anzugeben, das sich durch eine hohe Effizienz auszeichnet, mit dem eine vergleichsweise geringe Komplexität einhergeht und welches es ermöglicht, dass mit der Abfrage von gespeicherten Daten ein moderater Aufwand einhergeht.
Diese Aufgabe wird gelöst durch ein computerimplementiertes Datenbankverfahren, bei dem
- in einer mehrspaltigen und mehrzeiligen Datentabelle einer Datenbank zu speichernde Basisdaten in dafür vorgesehenen Datenspalten gespeichert werden,
- den Basisdaten aus zumindest einigen Feldern wenigstens eine Dimension zugeordnet wird, wobei die wenigstens eine Dimension anzeigt, dass diese Basisdaten miteinander in Beziehung stehen, insbesondere durch Übersetzungen in verschiedene Sprachen und/oder durch verschiedene Darstellungen für unterschiedliche Geschäftsniederlassungen gegeben sind,
- wobei die Zuordnung der oder der jeweiligen Dimension zu den oder den jeweils betroffenen Basisdaten erfolgt, indem in denjenigen Zeilen, in denen die Felder der oder der jeweils betroffenen Basisdaten liegen, in einer anderen Spalte, die keine Datenspalte ist und die für die Zuord- nung der oder der jeweiligen Dimension vorgesehen ist, Dimensionsspalte, zu der oder der jeweiligen Dimension gehörige Dimensions-IDs gespeichert werden, wobei sich Dimensions-IDs, die zur gleichen Dimension gehören, voneinander unterscheiden.
Gemäß der vorliegenden Erfindung kann mit anderen Worten eine effiziente Dimensionierung von Datensätzen erfolgen. Datensätze müssen, um sie zu einem bestimmten Datensatz in Relation zu setzen, nicht mehr in mehrere Tabellen aufgeteilt und für die Abfrage dann wieder, insbesondere mit JOINs, also (SQL-)Befehlen zur Zusammenführung von Daten aus verschiedenen Tabellen, zusammengefügt werden. Anstelle einer relationalen Speicherung (Normalform) kann erfindungsgemäß eine Tabelle unter Nutzung einer oder auch mehrerer Dimensionen verwendet werden.
Man könnte auch sagen, eine Dimension bzw. die Dimensionen werden erfindungsgemäß genutzt, um Informationen bzw. eine Information jeweils unter verschiedenen Aspekten oder in verschiedenen Ausprägungen speichern zu können. Verschiedene Basisdaten, die zu einer Dimension gehören, können also insbesondere verschiedene Ausprägungen bzw. Aspekte der gleichen Information sein.
Als Beispiel für Basisdaten mit einer gemeinsame Dimension sei genannt, dass diese durch Übersetzungen eines Ausdrucks in verschiedene Sprachen gegeben sind, etwa Übersetzungen der Bezeichnung eines Produktes in verschiedene Sprachen, wie „book“, „Buch „und „livre“. Jeder dieser drei Basisdateneinträge wird in der gleichen Tabelle, der Datentabelle gespeichert und jedem dieser drei Basisdateneinträge wird eine Dimensions-ID zugeordnet und in dem entsprechenden Feld der Dimensionsspalte gespeichert. Die drei Dimensions-IDs, die diesen drei unterschiedlichen Übersetzungen zugeordnet sind, unterscheiden sich dabei voneinander. Dimensions-IDs können in an sich bekannterWeise beispielsweise durch Zahlen oder auch alphanumerische Folgen gegeben sein. Den drei Basisdateneinträgen „book“, „Buch „und „livre“ könnten etwa die Zahlen 5000, 5001 und 5002 als Dimensions-IDs zugeordnet und in der Dimensionspalte gespeichert werden, wobei dies rein beispielhaft zu verstehen ist und natürlich auch andere Zahlen, alphanumerische Folgen oder Kennungen ganz anderer Art genutzt werden können. Voraussetzung ist lediglich, dass sich die zu einer Dimension gehörigen Dimensions-IDs unterscheiden, um der unterschiedlichen Ausprägung, beispielsweise den unterschiedlichen Sprachen, Rechnung zu tragen. Der beispielhaft beschriebenen Dimension, die mehrere Übersetzungen ermöglicht, kann etwa der Name „Sprache“ zugeordnet werden.
Neben dem Aspekt von Übersetzungen in verschiedene Sprachen kann eine erfindungsgemäß vorgesehene Dimension natürlich auch eine andere Beziehung von Basisdaten zueinander betreffen. Rein beispielhaft sei genannt, dass die Datenbank Basisdaten für mehrere Niederlassungen eines Unternehmens umfasst bzw. umfassen soll. Dann kann alternativ oder zusätzlich zu der Dimension „Sprache“ beispielsweise auch die Dimension “Niederlassung“ vorgesehen werden. Existieren mehrere Niederlassungen, kann es etwa sein, dass das gleiche Produkt von den verschiedenen Niederlassungen zu unterschiedlichen Preisen vertrieben wird, etwa in verschiedenen Währungen und/oder zu verschiedenen Beträgen der gleichen oder auch verschiedenen Währungen. Die unterschiedlichen Preise für das gleiche Produkt können erfindungsgemäß in einer Tabelle mit der Dimension „Niederlassung“ gespeichert werden, wobei den verschiedenen Preisen wiederum Dimensions-IDs zugeordnet werden, die dann ihrerseits zu der Dimension „Niederlassung“ gehören. Als weiteres Beispiel für eine Dimension sei „Land“ genannt, wenn zu verschiedenen Ländern gehörige Basisdaten zu speichern sind. Die verschiedenen Aspekte bzw. Ausprägungen einer Dimension, z.B. die verschiedenen Übersetzungen im Falle der Dimension „Sprache“ bzw. die verschiedenen Preise der Dimension „Niederlassung“, können auch als Dimensionszweige aufgefasst und bezeichnet werden. Dann kann man auch sagen, dass jedem Dimensionszweig eine eigene Dimensions-ID zugeordnet ist.
In bevorzugter Weiterbildung gilt, dass in der Datentabelle gespeichert ist bzw. wird, welche Bedeutung welcher Dimensionszweig hat, dies besonders bevorzugt jeweils in einer eigenen Zeile der Datentabelle. Z.B. kann eine Datentabelle für eine Dimension „Sprache“ mit den Dimensionszweigen „Deutsch“ und „Englisch“ zwei Zeilen aufweisen, welche die jeweilige Angabe „Deutsch“ und „Englisch“ umfassen. Dann ist es besonders vorteilhaft, wenn eine der jeweiligen Zeile zugeordnete eindeutige ID, insbesondere eine der Zeile zugeordnete MasterRecordID als die Dimensions-ID für den jeweiligen Dimensionszweig genutzt wird.
Die erfindungsgemäße Speicherung miteinander in Beziehung stehender bzw. verschiedene Aspekte oder Ausprägung einer Information darstellender Daten in einer Tabelle und die zugehörige Nutzung der Dimension(en) bietet erhebliche Vorteile. Wird die gleiche Tabelle genutzt, ist es insbesondere nicht erforderlich, mehrere Skriptanfragen (englisch: script queries) zu erzeugen, um Ergebnisse von der Datenbank zu erhalten. Es kann ein dynamischer Skriptgenerator genutzt werden. Die Abfrage kann um ein Vielfaches beschleunigt werden. Im Ergebnis können (Rechen-)Zeit, Aufwand und auch Energie eingespart werden. Das erfindungsgemäße Verfahren ist daher besonders nachhaltig.
Vorteilhafter Weise werden alle zu speichernden Basisdaten in einer Tabelle, der Datentabelle, gespeichert. Mehreren Basisdaten aus einer Datenspalte, denen die gleiche Dimension zugeordnet ist, werden zweckmäßiger Weise in benachbarten bzw. aufeinanderfolgenden Feldern der betreffenden Datenspalte gespeichert. Zu Basisdaten gehörige Dimensions-IDs werden ferner zweckmäßiger Weise in denjenigen Feldern der Dimensionsspalte gespeichert werden, die in den gleichen Zeilen liegen wie die jeweiligen Basisdaten.
Man kann auch sagen, dass erfindungsgemäß einer oder mehrere Datensätze erhalten bzw. gespeichert werden, die mehrere unterschiedliche Dimensionen bzw. Dimensionszweige besitzen, die anhand von Dimensionsreferenzen in Spalten abgelegt werden. Für die Dimensionsdaten werden dabei weitere Zeilen in der gleichen Tabelle, der Datentabelle, gebildet, welche Dimensionsdaten zu Spalten einer Dimension enthalten.
Im Rahmen des erfindungsgemäßen Datenbankverfahrens kann insbesondere ein Speichern, Verwalten und/oder Abrufen von Daten in digitaler Form erfolgen.
Basisdaten sind insbesondere die mittels der Datenbank zu speichernden und zu verwaltenden Daten. Diese Daten könne z.B. von wenigstens einem Nutzer der Datenbank bereitgestellt werden, etwa unter Verwendung wenigstens einer geeigneten Benutzerschnittstelle. Rein beispielhaft für Basisdaten seien Kundendaten sowie Produkt- bzw. Dienstleistungs- und Bestelldaten eines o- der mehrerer Unternehmen genannt.
Neben den Basisdaten werden in der Regel zusätzlichen Daten in der bzw. den Tabellen abgelegt, die beispielsweise für die datenbankinterne Datenverwaltung bzw. -abfrage genutzt werden. Als Beispiel für zusätzliche Daten seien Kennungen, also Identifikatoren, kurz IDs genannt, die Einträgen zugeordnet werden, um diese auffindbar zu machen.
In besonders zweckmäßiger Ausgestaltung gilt, dass für Datenspalten-Felder mit Basisdaten, denen eine Dimension zugeordnet ist, jeweils gilt, dass in anderen Datenspalten, die für Basisdaten vorgesehen sind, denen diese Dimension nicht zugeordnet ist, die Felder in der gleichen Zeile leer bleiben oder Leereinträge, insbesondere die Angabe NULL, umfassen. In den entsprechenden Zeilen kann gar nichts stehen oder ein Eintrag, der anzeigt, dass kein Dateninhalt vorliegt, wobei beispielhaft genannt sei, dass der Ausdruck „NULL“ in den entsprechenden Feldern steht. Mit anderen Worten bleiben Spalten einer Zeile, die nicht zu ihrer Dimension gehören, leer bzw. werden als leer dargestellt. Dies macht es insbesondere möglich, Daten anschließend über die Funktion MAX() zu verbinden bzw. abzufragen. Bei dem Befehl MAX() handelt es sich bevorzugt in an sich bekannterWeise um einen solchen, der den größten Wert, also das Maximum, einer ausgewählten Spalte ausgibt. Kann die Datenabfrage unter Verwendung der MAX()-Funktion erfolgen, kann in erheblichem Maße Abfragezeit eingespart werden, dies insbesondere im Vergleich mit Abfragen von Daten, die auf mehrere Tabellen verteilt sind, und für welche die JOIN-Funktion genutzt werden muss.
In weiterer vorteilhafter Ausgestaltung gilt für Datenspalten-Felder mit Basisdaten, denen keine Dimension zugeordnet ist jeweils, dass in der Dimensionsspalte in den Feldern in der jeweils gleichen Zeile keine Dimensions-IDs gespeichert werden, diese insbesondere leer bleiben oder Leereinträge, insbesondere die Angabe NULL, umfassen. So kann auf besonders geeignete Weise zwischen Basisdaten mit und Basisdaten ohne Dimension unterschieden werden. Als besonders zweckmäßig hat sich ferner erwiesen, wenn mehreren insbesondere in verschiedenen Zeilen der Datentabelle gespeicherten Basisdaten eine übereinstimmende Master-ID zugeordnet wird. Man kann auch sagen, dass die mehreren Basisdaten dann auf die Master-ID bzw. einen MasterRe- cord verweisen. Ist dies der Fall, wird die Master-ID bevorzugt in denjenigen Zeilen der Datentabelle, in denen die Felder der oder der jeweils betroffenen Basisdaten liegen, jedoch in einer anderen Spalte, die keine Datenspalte ist, Master-ID-Spalte, gespeichert.
Besonders bevorzugt gilt, dass jeder Zeile der Datentabelle eine ID zugeordnet ist, wobei sich die IDs aller Zeilen der Datentabelle voneinander unterscheide. Dann sind sie - zumindest innerhalb der Datentabelle - eindeutig. Als besonders geeignet hat sich beispielsweise erwiesen, wenn den Zeilen der Datentabelle fortlaufende Nummern zugeordnet werden, z.B. der ersten Zeile die ID „1“, der zweiten Zeile die ID „2“ usw. Natürlich muss nicht mit „1“ begonnen werden, sondern kann jede andere Zahl als Startpunkt für die erste Zeile gewählt werden. Solche IDs, die auch als Zeilen-IDs bezeichnet werden können, sind bzw. werden besonders bevorzugt in der ersten Spalte der Datentabelle gespeichert, die dann auch als ID-Spalte bzw. zeilen-ID- Spalte bezeichnet werden kann.
Es kann sich bei solchen Zeilen-IDs um global eindeutige IDs handeln. Solche IDs werden auch als GlIIDs bezeichnet, wobei die Abkürzung GIIID für Global Unique Identifier steht. Es kann sich auch um sogenannte MasterRe- cordlDs handeln.
Es sei angemerkt, dass unter dem Begriff der Spalten einer Tabelle mitunter die in vertikaler Richtung benachbarten Felder und unter dem Begriff der Zeilen einer Tabelle die in horizontaler Richtung benachbarten Felder zusammengefasst werden. Diese Einschränkung gilt vorliegend nicht. Vielmehr kann die Orientierung auch vertauscht sein. Mit anderen Worten kann es sich, wenn vorliegend von den Spalten einer Tabelle, beispielsweise Datentabelle, die Rede ist, auch um horizontal orientierte Spalten handeln, während dann die Zeilen vertikal orientiert sind. Für die Speicherung ist dies völlig unerheblich. Es gibt keine „Vorzugsorientierung“. Wenn vorliegend von Spalten einerseits und Zeilen andererseits die Rede ist, ist dies aber zweckmäßiger Weise derart zu verstehen, dass sich deren Orientierung unterscheidet, also entweder die Spalten vertikal sind, während sich die Zeilen horizontal orientieren, oder aber die Spalten horizontal und die Zeilen vertikal orientiert sind.
Eine weitere besonders vorteilhafte Ausgestaltung zeichnet sich ferner dadurch aus, dass Informationen über die bzw. im Falle mehrere die jeweilige Dimension in einer weiteren Tabelle gespeichert werden. Eine solche Tabelle wird vorliegend als Objekttabelle bezeichnet. Die Objekttabelle umfasst dann bevorzugt eine ID-Spalte, in welcher eine zu der oder der jeweiligen Dimension gehörige ID aufgeführt ist. Diese ID kann auch als übergeordnete ID der bzw. der jeweiligen Dimension bezeichnet werden. Übergeordnet, da für jede Dimension noch die mehreren, voneinander verschiedenen Dimension-IDs existieren. Man kann die übergeordnete Dimensions-ID auch als Dimensions-Mas- ter-ID bezeichnen. Dann liegt mit der Dimensions-Master-ID insbesondere eine eindeutige, der (jeweiligen) Dimension zugeordnete Kennung vor und die Dimension führt zu mehreren Einträgen, jeweils einem für die verschiedenen Dimension-IDs.
Ist eine Objekttabelle vorhanden, kann diese ferner eine Namensspalte aufweisen, in welcher ein der oder der jeweiligen Dimension zugeordneter Name aufgeführt ist. Die Dimensionsnamen können beispielsweise, wie vorstehend bereits erwähnt, „Sprache“, „Niederlassung“ und/oder „Land“ lauten. In diesem Falle ist direkt ersichtlich, welche Aspekte die jeweilige Dimension betrifft. Weiter bevorzugt kann gelten, dass die Objekttabelle eine Objekt-Dimensions- ID-Spalte aufweist. Über dieses Feld bzw. die Felder dieser Spalte ist es möglich, einem Objekt, etwa Business Objekt, direkt eine Dimension zuzuweisen. Wenn dies der Fall ist, müssen nicht einzelne Felder mit einer Dimension konfiguriert werden, sondern alle Felder des Objektes haben eine Dimension, welche vom Objekt geerbt wird.
Es können auch noch weitere Spalten in der Objekttabelle vorhanden sein, z.B. solche, welche Berechtigungen und/oder Instanzen, etwa für mehrere Kunden, und/oder Erstellungs- bzw. Updatezeiten und dergleichen betreffen.
In der Datenbank werden bevorzugt Objekte gespeichert, wobei zu jedem Objekt die Basisdaten aus einem oder mehreren Feldern aus einer oder mehreren Datenspalten der Datentabelle gehören, und wobei jedem Objekt eine Ob- jekt-ID zugeordnet wird.
Unter einem Objekt ist insbesondere eine Sammlung von zusammenhängenden Daten zu verstehen, die bevorzugt in einem Tabellenformat in der Datenbank gespeichert sind bzw. werden. Insbesondere für den Fall, dass die Datenbank von einem oder mehreren Unternehmen genutzt wird, kann man auch von Business-Objekten, abgekürzt BOs, sprechen. Rein Beispielhaft für ein Objekt bzw. Business-Objekt sei eine Sammlung von Daten genannt, die zu einem bestimmten Produkt gehören oder auch eine Sammlung von Daten eines Kundenaccounts.
Wenn für wenigstens ein Objekt Daten in mehreren Zeilen in der Datentabelle gespeichert sind bzw. werden, gilt weiter bevorzugt, dass mehreren dieser Zeilen eine übereinstimmende Master-ID zugeordnet ist bzw. wird. Mehrere Zeilen mit einer übereinstimmenden MasterRecordID werden insbesondere als ein zusammengehöriger Datensatz aufgefasst. Zu einem Objekt kann ein Datensatz gehören oder können mehrere Datensätze gehören.
Die (jeweils) übereinstimmende Master-ID ist oder wird dann bevorzugt in einer Master-ID-Spalte der Datentabelle in den betreffenden, zu dem Objekt bzw. Datensatz des Objektes gehörigen Zeilen gespeichert.
Wenn den Zeilen der Datentabelle eindeutige Zeilen-IDs, z.B. fortlaufende Zei- len-IDs zugeordnet sind bzw. werden, die sich bevorzugt in der ersten Zeile der Datentabelle befinden bzw. dort gespeichert werden, gilt besonders bevorzugt, dass die Zeilen-ID, die in der ersten Zeile des jeweiligen Objektes bzw. des jeweiligen Datensatzes, mit anderen Worten der Master-Zeile des jeweiligen Objektes bzw. des jeweiligen Datensatzes liegt, in einer anderen Spalte der Datentabelle in mehreren, nämlichen allen zu dem Objekt bzw. dem Datensatz gehörigen Zeilen übernommen wird.
Als besonders vorteilhaft und übersichtlich hat es sich ferner erwiesen, wenn Informationen über alle in der Datentabelle gespeicherten Objekte und alle Dimensionen, die Basisdaten der Objekte zugeordnet sind, in der Objekttabelle gespeichert werden. Bevorzugt werden die den Objekten zugeordneten Ob- jekt-IDs in der ID-Spalte der Objekttabelle gespeichert. Alternativ oder zusätzlich ist in der Objekttabelle für jedes Objekt und jede Dimension eine Zeile vorgesehen. Die Objekttabelle kann auch eine Spalte umfassen, in welcher angegeben ist, ob es sich um eine Dimension handelt, Dimensionsspalte. Beispielsweise kann in der- oder denjenigen Zeilen der Dimensionsspalte, die eine Dimension betreffen, eine 1 stehen und in der- oder denjenigen Zeilen, die eine Objekt betreffen, jeweils „NULL“, um diese Unterscheidung zu verdeutlichen. Ein Objekt kann eine Dimension haben und Felder in einem Objekt können ihrerseits eine Dimension haben. Die Dimension eines Objektes kann auch als Hauptdimension bezeichnet werden, um sie von den Dimensionen von Feldern des Objektes, die auch als Felddimensionen bezeichnet werden können, zu unterscheiden.
Rein beispielhaft sei genannt, dass in der Datenbank ein Objekt „Produkt“ vorhanden ist bzw. gespeichert wird und zu diesem Produkt ein Produktname in zwei oder mehr verschiedenen Sprachen und Preise für das Produkt von verschiedenen Niederlassungen gehören und in der Datentabelle gespeichert sind bzw. werden. In diesem Falle hat das Objekt „Produkt“ dann insbesondere zwei Felder, die jeweils eine Dimension haben, nämlich die Dimension „Sprache“ bzw. die Dimension „Niederlassung“. Es umfasst als Basisdateneinträge die Produktbezeichnungen in den verschiedenen Sprachen, z.B. „book“, „Buch“ und „livre“ und die verschiedenen Preise, z.B. 15 Euro für eine Niederlassung in Deutschland, 19 $ für eine Niederlassung in den USA, 20 GBP für eine Niederlassung im Vereinigten Königreich und 17 Euro für eine französische Niederlassung.
Rein beispielhaft für eine Dimension eines Objektes sei ferner genannt, dass ein Objekt „Produkt“ die Dimension „Mandant“ hat bzw. zugeordnet bekommt, um einer Situation mit mehr als einem Mandanten Rechnung zu tragen. Dann wird es zweckmäßigerWeise für jeden Mandanten, etwa Mandant A und Mandant B, einzeln angelegt. Dann kann eines oder können mehrere Felder des Objektes ihrerseits eine Dimension haben, z.B. ein Feld „Preis“ die Dimension „Niederlassung“ für verschiedene Niederlassungen in verschiedenen Ländern, so dass der Preis in verschiedenen Währungen abrufbar ist bzw. sein muss. Die zu einem Objekt mit Dimension, insbesondere Felddimension(en) gehörenden Daten sind bzw. werden zweckmäßiger Weise jeweils in mehreren Zeilen der Datentabelle gespeichert. Bevorzugt gilt für jedes Objekt mit (Feld-)Di- mension(en), dass zu diesem eine erste Zeile gehört, welche insbesondere gemeinsam gültigen Daten enthält, und welche auch als Master-Zeile bezeichnet werden kann, sowie darunterliegende, beispielsweise unmittelbar darunterliegende Zeilen, für Dimensionsdaten. In der Master-Zeile können Basisdaten des Objektes gespeichert sein bzw. werden, die keine Dimension haben, bevorzugt alle Basisdaten, die keine Dimension haben. Der Master-Zeile und den darunterliegenden Zeilen für die Dimensionsdaten ist bevorzugt eine gemeinsame, übereinstimmende MasterRecordID zugeordnet. Bei dieser kann es sich um diejenige Zeilen-ID handeln, die in der ersten zu dem Objekt gehörende Zeile in der Datentabelle, der Master-Zeile, aufgeführt ist. Dann wird mit anderen Worten die Zeilen-ID bzw. MasterRecordID aus der Master-Zeile für die zusätzlichen Zeilen mit Dimensionsdaten übernommen.
Der Vollständigkeit halber sei angemerkt, dass die Dimension bzw. Dimensionen ihrerseits Objekte darstellen können bzw. darstellen. Man kann diese auch als Dimensionsobjekten bezeichnen. Aus Gründen der Einfachheit wird vorliegend jedoch von Objekten einerseits und Dimensionen andererseits gesprochen.
Die Datenspalte bzw. Datenspalten der Datentabelle tragen bevorzugt jeweils den Namen ,,Data_[Nummer]“, beispielsweise „Data_0“, „Data_1“, „Data_2“ und „Data_3“. Diese Namen werden bevorzugt für standardmäßig vorgesehene Datenspalten genutzt. Es ist natürlich auch möglich, das Benutzer- bzw. Kunden-spezifische Datenspalten vorgesehen sind bzw. werden. Solche können beispielsweise mit ,,C_Data_[Nummer]“ bezeichnet werden, wobei das „C“ als Abkürzung für „custom“ steht. Das Präfix „C-„ kann auch in anderen Tabellen genutzt werden, um kenntlich zu machen, dass es sich um Benutzer- bzw. Kunden-spezifische Objekte bzw. Daten handelt. Beispielsweise können ggf. in der Objekttabelle vorhandenen Benutzer- bzw. Kunden-spezifische Objekte mit „C_“ beginnen.
Eine weitere besonders vorteilhafte Ausgestaltung zeichnet sich ferner dadurch aus, dass Informationen über die Struktur der Objekte in einer weiteren Tabelle, Feldtabelle, gespeichert werden. Dann gilt insbesondere, dass die Feldtabelle die Information umfasst, in welcher Datenspalte oder welchen Datenspalten der Datentabelle die Basisdaten des jeweiligen Objektes gespeichert werden.
Die Feldtabelle kann dann eine Spalte umfassen, in welcher die in der Datentabelle verwendeten Namen derjenigen Datenspalten angegeben sind, in welchen Basisdaten zu dem jeweiligen Objekt gespeichert werden. Diese Spalte kann als Feldnamenspalte bezeichnet werden. In der Feldtabelle verweisen die Feldnamen mit anderen Worten auf echte Felder in der Datentabelle.
Auch ist es möglich, dass die Feldtabelle eine Spalte umfasst, in der angegeben ist, Basisdaten welcher Art in der oder den Datenspalten des jeweiligen Objektes gespeichert werden. Diese Spalte kann als Labelspalte bezeichnet werden.
Alternativ oder zusätzlich kann die Feldtabelle eine Spalte umfassen, in der angegeben ist, ob die zu dem Objekt gehörigen Basisdaten in den in der Feldnamenspalte aufgeführten Datenspalten jeweils eine Dimension haben oder nicht und bevorzugt welche Dimension diesen zugeordnet ist. Diese Spalte kann als Dimensionsspalte bezeichnet werden. Dies kann insbesondere unter Nutzung der übergeordneten Dimensions-ID, also der Dimensions-Master-ID erfolgen. In Zeilen von Basisdaten, denen keine Dimension zugeordnet ist kann beispielsweise „NULL“ in der Dimensionsspalte der Feldtabelle stehen oder die entsprechenden Felder können leer bleiben. In Zeilen von Basisdaten, denen eine Dimension zugeordnet ist steht bevorzugter Weise jeweils die Dimensions-Master-ID der entsprechenden Dimension.
Die Feldtabelle kann ferner eine Spalte umfassen, in welcher die dem jeweiligen Objekt zugeordnete Objekt-ID angegeben ist. Diese Spalte kann als Ob- jekt-ID-Spalte bezeichnet werden.
Objekte können Basisdaten in mehreren Datenspalten der Datentabelle umfassen. Ist diese der Fall, ist in der Feldtabelle bevorzugt für jede Datenspalte, in denen Basisdaten des betreffenden Objektes gespeichert sind, eine Zeile in der Feldtabelle vorgesehen. In der Objekt-ID-Spalte wird dann bevorzugt in jeder Spalte des Objektes die Objekt-ID gespeichert, also mehrmals die gleiche ID. Die Feldtabelle kann auch noch weitere Spalten umfassen.
Es können auch noch weitere Tabellen vorgesehen sein. Bevorzugt gibt es jedoch jede Art von Tabelle genau ein Mal, insbesondere genau eine Datentabelle und/oder genau eine Objekttabelle und/oder genau eine Feldtabelle. Eine Ausnahme kann insbesondere bestehen, wenn das Verfahren dezentral genutzt wird bzw. implementiert ist und z.B. auf mehreren Servern Kopien der jeweiligen Tabellenart liegen oder für verschiedene Mandanten jeweils eigene Versionen bzw. Kopien der jeweiligen Tabellenart existieren.
Beispielsweise können in einer weiteren Tabelle, die als Relationstabelle bezeichnet werden kann, zwischen verschiedenen Objekten bestehende Relationen gespeichert werden. Wird eine Relationstabelle genutzt, können in dieser für die jeweilige Relation eine Relations-ID und/oder ein Relationstyp und/oder eine Objekt-ID und/oder eine Objekt-Feld-ID gespeichert werden. Es kann für die Relations-ID und/oder den Relationstyp und/oder die Objekt-ID und/oder die Objekt-Feld-ID jeweils eine eigene Spalte in der Relationstabelle vorgesehen sein. Auch kann es zweckmäßiger Weise wenigstens eine Spalte geben, in welcher die Information enthalten ist bzw. abgelegt wird, welches Objekt zu welchem eine Relation hat.
Alternativ oder zusätzlich können in einer weiteren Tabelle, die als Instanzentabelle bezeichnet werden kann, verschiedene Instanzen gespeichert werden. In einer Instanzentabelle kann für die jeweilige Instanz beispielsweise eine In- stanz-ID und/oder ein Instanzname und/oder eine Instanzlizenz und/oder ein geheimer Code gespeichert werden. Auch hier kann für jeden dieser Aspekte eine Spalte in der Instanzentabelle vorgesehen sein. Mehrere Instanzen können insbesondere zu dem Zweck vorgesehen sein, nach Daten verschiedener Nutzer der Datenbank, etwa verschiedener Geschäftspartner, filtern zu können. Die Instanzen können mit anderen Worten Hauptfilter darstellen, um Daten für verschiedene Nutzer, etwa Geschäftspartner, auszugeben.
Die Datentabelle kann dann eine Spalte umfassen, in welcher Instanz-IDs abgelegt sind bzw. werden, Instanz-ID-Spalte.
Es sei betont, dass es, was die Schritte des erfindungsgemäßen Verfahrens angeht, nicht auf die Reihenfolge ankommt. Die Speicherung von Daten in der Datentabelle und insbesondere der Objekttabelle sowie Feldtabelle und ggf. vorhandenen weiteren Tabellen kann vielmehr in beliebiger Reihenfolge erfolgen. Daten können etwa zuerst in der Datentabelle, dann in der Objekt- und dann der Feldtabelle gespeichert werden oder auch in einer beliebigen anderen Reihenfolge.
Auch kommt es nicht darauf an, ob in der Datentabelle erst Basisdaten und dann zugehörige Dimensions-IDs abgelegt werden oder umgekehrt.
Für den Abruf von Daten aus der Datenbank wird insbesondere eine API, besonders bevorzugt eine RESTfuI API aufgerufen bzw. genutzt. REST steht dabei in hinlänglich vorbekannter Weise für „REpresentational State Transfer“ und API für „Application Programming Interface“.
Eine weitere besonders bevorzugte Ausführungsform zeichnet sich dadurch aus, dass das Abrufen von Daten aus der Datenbank, insbesondere aus der Datentabelle, unter Nutzung einer Funktion erfolgt, welche jeweils den größten aller in einer ausgewählten Spalte gespeicherten Werte liefert. Eine solche Funktion ist beispielsweise durch die MAX()-Funktion gegeben.
Insbesondere das gezielte Vorsehen von Leereinträgen bzw. den Einträgen „NULL“ in Feldern der einen, alle Daten umfassenden Datentabelle macht dies möglich. Durch die Nutzung der MAX()-Funktion kann eine erhebliche Zeitersparnis erzielt werden, dies insbesondere im Vergleich mit Abfragen von Daten, die auf mehrere Tabellen verteilt sind, und für welche daher die JOIN- Funktion erforderlich ist.
In weiterer vorteilhafter Ausgestaltung ist ferner vorgesehen, dass ein dynamisches Skript für das Abrufen von Daten aus der Datenbank, insbesondere der Datentabelle, genutzt wird. Es kann dynamischer Skriptgenerator für das Abrufen von Daten aus der Datenbank, insbesondere der Datentabelle, genutzt werden. Das erfindungsgemäße Verfahren kann auch als „Software as a Service“ (SaaS) realisiert bzw. implementiert sein. Dann ist insbesondere keine lokale Installation einer Software für die Durchführung bzw. Nutzung des Verfahrens erforderlich, sondern dies kann über einen Webzugriff, z.B. über einen Browser oder aus andere Weise, erfolgen. Für eine SaaS-Lösung kann in an sich bekannter Weise das Internet bzw. eine Cloud genutzt werden.
Man kann in diesem Fall auch von einer „Datenbank-als-Dienst“ sprechen.
Gegenstand der Erfindung ist auch ein System zur Datenverarbeitung, umfassend wenigstens einen Prozessor und eine oder mehrere Speichervorrichtungen, wobei der wenigstens eine Prozessor so konfiguriert ist, dass er die Schritte des erfindungsgemäßen Verfahrens ausführt.
Das erfindungsgemäße System kann auch ein verteiltes System mit Hardware an verschiedenen Standorten und geeigneter Vernetzung, etwa via Internet, sein.
Darüber hinaus betrifft die Erfindung ein Computerprogrammprodukt, umfassend Befehle, die bei der Ausführung des Programms durch wenigstens einen Computer den wenigstens einen Computer veranlassen, die Schritte des erfindungsgemäßen Verfahrens auszuführen.
Schließlich betrifft die Erfindung ein computerlesbares Speichermedium, umfassend Befehle, die bei der Ausführung durch wenigstens einen Computer den wenigstens einen Computer veranlassen, die Schritte des erfindungsgemäßen Verfahrens auszuführen. Hinsichtlich der Ausgestaltungen der Erfindung wird auch auf die Unteransprüche sowie auf die nachfolgende Beschreibung von Ausführungsbeispielen unter Bezugnahme auf die beiliegende Zeichnung verwiesen.
In der Zeichnung zeigt:
Figur 1 ein rein schematisches Blockbild einer konventionellen Datenbank, in der die Daten relational in mehrere Tabellen aufgeteilt sind;
Figur 2 ein rein schematisches Blockbild mit den Schritten eines Ausführungsbeispiels des erfindungsgemäßen Verfahrens;
Figur 3 eine Datenbank, in der Basisdaten gemäß einem Ausführungsbeispiel des erfindungsgemäßen Verfahrens in einer Datentabelle gespeichert werden.
Die Figur 1 zeigt im oberen Bereich eine Datenbank 1 vorbekannter Art in rein schematischer Darstellung. Darunter sind mehrere Tabellen 2-11 gezeigt, welche - ebenfalls rein schematisch - veranschaulichen, wie die Datenspeicherung erfolgt. Der zwischen der Datenbank 1 und den Tabellen 2-11 gezeigte Pfeil soll verdeutlichen, dass die Daten in der Datenbank 1 abgelegt sind bzw. werden.
In der Datenbank sind Objekte, konkret Business-Objekte gespeichert, nämlich Accounts, Bestellungen, Produkte, Bestelldetails, Bestellstati und Länder. Für jedes dieser Objekte musste eine Tabelle 2-7 erzeugt werden. Über Relationen 12 sind die Tabellen teilweise miteinander in Verbindung gesetzt. Es kann erforderlich sein, dass für einige Dateneinträge auch Übersetzungen in der Datenbank 1 gespeichert werden müssen. Dies etwa, weil mehrere Niederlassungen eines Unternehmens aus verschiedenen Ländern die Datenbank 1 nutzen möchten bzw. eine integrierte Datenbank 1 für alle diese Niederlassungen erhalten wird.
In dem in Figur 1 gezeigten Beispiel umfassen drei Tabellen 4, 6 und 7 Felder, die eine Übersetzung benötigen. Bei diesen Feldern, die in Figur 1 grau hinterlegt sind, handelt es sich um ProduktName, Status und LänderName in Tabelle 4, 6, bzw. 7. Um die Übersetzung unterstützen zu können, muss nach dem vorbekannten, relationalen Prinzip für jede Übersetzung eine eigene Tabelle 8, 9, 11 erzeugt und die Übersetzung in den zugeordneten 8, 9, 11 geführt werden. Die Sprachen sind bzw. werden in der Tabelle 10 hinterlegt.
Zu der Tabelle 4 „Produkte“ erhält man die mit dieser über eine Relation 12 verbundene Tabelle 9 „Produktübersetzungen“, zu der Tabelle 6 „BestellSta- tus“ erhält man die mit dieser über eine Relation 12 verbundene Tabelle 11 „Bestellstatusübersetzungen“ und für die Tabelle 7 „Länder“ die über eine Relation 12 mit dieser verknüpfte Tabelle 8 „Länderübersetzungen“
Diese Lösung ist statisch. Das bedeutet für jedes Projekt muss eine spezifische Datenbank 1 mit zugehörigen Tabellen 2-11 erzeugt werden und dann müssen Relationen 12 für die Übersetzungen angelegt und spezifische SQL- Skript-Anfragen für jede Übersetzungstabelle 8, 9, 11 erzeugt werden, da die Übersetzungstabellennamen und die Feldnamen nicht gleich sind. Es muss insbesondere mit JOIN-Befehlen gearbeitet werden, welche vergleichsweise zeitaufwändig sind, so dass sich die Abfragen langsam gestalten. Wenn beispielsweise ein Projekt mehrere Niederlassungen umfasst und alle diese in einer Datenbank 1 integriert werden sollen, wird die Datenbank 1 vergleichsweise komplex und benötigt mehr und zeitaufwändige Abfragen um die gewünschten Ergebnisse zu erhalten.
Auch ist es erforderlich, die Namen der jeweils zusätzliche, in Relation stehenden Tabellen zu kennen. Wenn z.B. ein Produktname in mehreren Sprachen in einer zusätzlichen Tabelle mit dem Namen „Produktübersetzung“ abgelegt wird, muss dieser Name bekannt sein.
Diese Nachteile können unter Nutzung des erfindungsgemäßen computerimplementiertes Verfahren zum Speichern von Daten in einer Datenbank, von dem im Folgenden ein Ausführungsbeispiel beschrieben wird, vermieden werden.
Die Figur 2 zeigt - in rein schematischer Blockdarstellung - die Schritte des Ausführungsbeispiels des Verfahrens. In der Figur 3 oben ist, ebenfalls schematisch, eine Datenbank 13 gezeigt, in welcher auf erfindungsgemäße Weise Daten gespeichert und aus welcher auf erfindungsgemäße Weise Daten abgerufen werden. Darunter ist sind Beispiele einer Datentabelle 14, einer Objekttabelle 15 und einer Feldtabelle 16 gezeigt. Es sei angemerkt, dass die stark vereinfachte Figur 3 die Tabellen zur Veranschaulichung jeweils nur auszugsweise zeigt und diese erheblich mehr Einträge umfassen können und in der Regel umfassen werden.
Im Rahmen des Datenbankverfahrens werden in der mehrspaltigen und mehrzeiligen Datentabelle 14 Basisdaten in dafür vorgesehenen Datenspalten 17 gespeichert (Schritt S1). Bei dem Beispiel aus Figur 3 sind die Datenspalten 17 die vier rechten Spalten der Datentabelle 14. Es sei betont, dass diese prinzipiell sowohl weniger als auch mehr als vier Datenspalten 17 umfassen kann. Neben den Datenspalten 17 umfasst die Datentabelle 14 noch eine ID-Spalte 18 (erste, linke Spalte), eine Master-ID-Spalte 19 und eine Dimensionsspalte 20.
In der ID-Spalte 18 ist eine insbesondere eindeutige Zeilen-ID, z.B. eine global eindeutige ID, angegeben. Es handelt sich hier konkret um eine mit den Zeilen der Datentabelle 14 fortlaufende Nummer. Wie angemerkt ist in Figur 3 aus Gründen der vereinfachten Darstellung nur ein Ausschnitt der gesamten Datentabelle 14 gezeigt, weshalb hier „Sprünge“ hinsichtlich dieser ID existieren, z.B. von 457467 zu 457502 usw.
Den Basisdaten aus zumindest einigen Feldern wird wenigstens eine Dimension zugeordnet, wobei die wenigstens eine Dimension anzeigt, dass diese Basisdaten miteinander in Beziehung stehen (Schritt S2). Im vorliegenden Falle sind die Basisdaten, denen eine Dimension zugeordnet ist bzw. wird, durch Übersetzungen des gleichen Ausdrucks in verschiedene Sprachen gegeben. Den betreffenden Basisdaten ist daher die Dimension „Sprache“ zugeordnet.
Bei dem gezeigten Ausführungsbeispiel sind die in der Datentabelle 14 in den Datenspalten 17 gespeicherten Basisdaten Geschlechter bzw. Geschlechtsangaben für Personen. Es ist bzw. wird mit anderen Worten ein Objekt „Geschlecht“ in der Datentabelle gespeichert. Konkret umfasst das Objekt „Geschlecht“ die drei Optionen „Male“, „Female“ und „Divers“. Zu jeder Geschlechtsoption gehört ein Code, der jeweils durch diese Bezeichnungen gegeben ist, eine Typenangabe, konkret „M“, „F“ und „D“ in entsprechender Reihenfolge, ein Name und auch eine Anrede. Für jede der drei Geschlechtsoptionen des Objektes „Geschlecht“ ist jeweils ein Datensatz in der Datentabelle 14 gespeichert. Für „Male“ in der ersten bis dritten der gezeigten Zeilen der Datentabelle 14, für „Female“ in der vierten bis sechsten und für „Divers“ in der siebten bis neunten.
Eine Dimension ist bei dem dargestellten Ausführungsbeispiel dem Namen und der Anrede zugeordnet. Dies, da diese beiden Angaben, etwa für anderssprachige Niederlassungen, eine Übersetzung erfordern.
Die Zuordnung der oder der jeweiligen Dimension zu den oder den jeweils betroffenen Basisdaten erfolgt dabei, indem in denjenigen Zeilen, in denen die Felder der oder der jeweils betroffenen Basisdaten liegen, in einer anderen Spalte, die keine Datenspalte ist und die für die Zuordnung der oder der jeweiligen Dimension vorgesehen ist, Dimensionsspalte 20, zu der oder der jeweiligen Dimension gehörige Dimensions-IDs gespeichert werden, wobei sich Di- mensions-IDs, die zur gleichen Dimension gehören, voneinander unterscheiden.
Bei dem Beispiel gemäß Figur 3 werden die Dimensions-IDs in der dritten Spalte 20 von links gespeichert. Hier werden Basisdaten in deutscher und englischer Sprache gespeichert, so dass zwei verschiedene Dimensions-IDs für diese beiden verschiedenen Sprachen Verwendung finden. Man könnte auch sagen, es existieren zwei Dimensionszweige, nämlich Deutsch und Englisch. Dass hier zwei Sprachen und somit zwei Dimensionszweige vorhanden sind, ist dabei rein beispielhaft zu verstehen. Natürlich könnte die Dimension „Sprache“ neben Deutsch und Englisch noch weitere Sprachen umfassen, etwa drei, vier, fünf oder auch mehr Sprachen.
Für die deutsche Version kommt vorliegend die Dimensions-ID 410348 und für die englische Sprache die Dimensions-ID 410350 zum Einsatz, wobei dies rein beispielhaft zu verstehen ist und auch andere Zahlen oder andere alphanumerische Kennungen oder Kennungen anderer Art zum Einsatz kommen können. Der Eintrag dieser Dimensions-IDs in den entsprechenden Zeilen zeigt an, dass diesen Basisdaten eine Dimension zugeordnet ist, vorliegend die Dimension „Sprache“. Die Dimensions-IDs finden sich in der zweiten und dritten Zeile jedes Datensatzes.
In der Datentabelle 14 sind folgende, in Figur 3 in den unteren beiden Zeilen dargestellten Daten zu der „Sprache“ abgelegt:
Für das Geschlecht „Male“ sind die entsprechenden Felder in der Figur 3 beispielhaft hellgrau hinterlegt und zwar sowohl die Datenspaltenfelder mit den Übersetzungen „Männlich“ und „Male“ sowie „Herr“ und „Mr.“ als auch die zugehörigen Felder der Dimensionsspalte 20 in den gleichen Zeilen.
Wie man erkennt, gilt für Datenspalten-Felder mit Basisdaten, denen eine Dimension zugeordnet ist jeweils, dass in anderen Datenspalten, die für Basisdaten vorgesehen sind, denen diese Dimension nicht zugeordnet ist, die Felder in der gleichen Zeile leer bleiben bzw. Leereinträge, hier konkret die Angabe „NULL“ umfassen. Hier gilt beispielsweise, dass die in den gleichen Zeilen liegenden Felder der linken und rechten Datenspalte 17, welche den Namen „Data_2“ und „Data_15“ tragen, einen Leereintrag „NULL“ aufweisen, also ohne Dateninhalt sind. Für das Geschlecht „Female“ und das Geschlecht „Divers“ gilt dies völlig analog. Es gilt ferner, dass für Datenspalten-Felder mit Basisdaten, denen keine Dimension zugeordnet ist in der Dimensionsspalte 20 in den Feldern in der jeweils gleichen Zeile keine Dimensions-IDs gespeichert werden, diese insbesondere leer bleiben bzw. mit einem Leereintrag versehen werden. So steht in der zweiten, fünften und achten Zeile von oben von der Dimensionsspalte 20 jeweils „NULL“, da weder dem Code noch dem Typ der Geschlechter jeweils die Dimension „Sprache“ zugeordnet ist. Die Angabe „NULL“ in der Dimensionsspalte 20 findet sich bei dem Objekt „Geschlecht“ jeweils in der obersten Zeile der drei zugehörigen Datensätze für die drei Geschlechtsoptionen, also in der ersten, der vierten und siebten dargestellten Zeile der Datentabelle 14. Dies Zeilen können auch als Master-Zeilen des jeweiligen Datensatzes bezeichnet werden. In diesen Zeilen sind der Code und Typ aufgeführt, also die Basisdaten ohne Dimension.
Darüber hinaus gilt, dass jeweils mehreren Basisdaten eine übereinstimmende Master-ID zugeordnet wird (Schritt S3). Die mehreren Zeilen stellen dann einen Record dar bzw. gehören zu einem Record, wobei eine Dimension existiert. Die Master-ID wird dabei in denjenigen Zeilen der Datentabelle, in denen die Felder der oder der jeweils betroffenen Basisdaten liegen, in einer anderen Spalte, die keine Datenspalte ist, der Master-ID-Spalte 19, gespeichert.
Konkret wird jeweils den drei Zeilen eines Datensatzes eine gemeinsame, übereinstimmende Master-ID (MasterRecordld) zugeordnet, die in der Master- Recordld-Spalte 19 jeweils in den entsprechenden Zeilen gespeichert wird.
Vorliegend ist den Basisdaten für die Geschlechtsoption „Male“ die gemeinsame Master-ID 457465 zugeordnet. In analoger Weise ist den Basisdaten der Geschlechtsoption „Female“ die gemeinsame Master-ID 457502 und der Geschlechtsoption „Divers“ die Master-ID 468819 zugeordnet. In allen drei Zeilen, welche Basisdaten für „Male“ umfassen ist daher in der Master-ID-Spalte 19 die ID 457465 und in den drei Zeilen mit Basisdaten für „Female“ die 457502 und in den drei Zeilen für „Divers“ die 468819 eingetragen. Diese Basisdaten verweisen also jeweils auf die eine Master-ID bzw. den einen Masterrecord. Wie man sieht, stimmt diese Master-ID 457465 von „Male“ mit der ID aus der ersten Zeile der ID-Spalte 18 (unter der Titelzeile) überein. Bei dieser ID aus Spalte 18 handelt es sich um die ID des Public Record und die Übereinstimmung bedeutet, dass die Einträge aus den drei Zeilen des Datensatzes, die alle die 457465 als Master-ID in Spalte 19 aufweisen, praktisch einen Eintrag bzw. einen „Record“ bilden. Man kann auch sagen, dass die Master-ID der jeweiligen Master-Zeile in darunterliegende Zeilen für die Dimensionsdaten übernommen wird.
Die Master-ID 457502 von „Female“ stimmt in analoger Weise mit der ID in der fünften Zeile der ID-Spalte 18 überein und die Master-ID 468819 von „Divers“ mit der ID aus der achten Zeile der Spalte 18. Auch diese ID-Zahlen sind dabei allesamt rein beispielhaft zu verstehen und könnten prinzipiell anders lauten.
Die beiden letzten Zeilen des in Figur 3 dargestellten Ausschnitts der Datentabelle 14, welche zu den Master-IDs 410348 bzw. 410350 gehören, umfassen, wie oben schon angemerkt, ein Mapping der einzelnen Sprachen der Dimension „Sprache“, also Deutsch bzw. Englisch, und diesen Master-IDs. Die Master-IDs stellen die den beiden Sprachen zugeordneten Dimensions-IDs dar. Wie man erkennt, werden diese, also 410348 und 410350, in der Spalte 20 mit der Dimensions-ID der drei Datensätze des Objektes „Geschlecht“ genutzt. Hierdurch wird angegeben, welche Zeile Daten in deutscher und welche Daten in englischer Sprache betrifft bzw. umfasst.
Informationen über die Dimension werden ferner in einerweiteren Tabelle, der Objekttabelle 15, gespeichert (Schritt S4). Es sei angemerkt, dass natürlich mehrere Dimensionen vorhanden sein können, wobei dann bevorzugt Informationen über alle Dimensionen in der Objekttabelle 15 gespeichert werden. Die Objekttabelle 15 umfasst bei dem gezeigten Beispiel eine ID-Spalte 21 , in welcher eine zu der oder der jeweiligen Dimension gehörige ID aufgeführt ist. Wie man erkennt, ist dem Objekt „Geschlecht“ vorliegend die ID 466 und der Dimension „Sprache“ die ID 480 zugeordnet. Diese ID kann - in Abgrenzung zu den Dimensions-IDs 410348 und 410350 für die beiden Sprachen DE und EN - auch als Dimensions-Master-ID aufgefasst und bezeichnet werden.
Die Objekttabelle 15 weist ferner eine Namensspalte 22 auf, in welcher ein der oder der jeweiligen Dimension zugeordneter Name aufgeführt ist.
Wie vorstehend dargelegt, werden Objekte in der Datenbank gespeichert, wobei zu jedem Objekt die Basisdaten aus einem oder mehreren Feldern aus einer oder mehreren Datenspalten der Datentabelle gehören. Jedem Objekt wird dabei eine Objekt-ID zugeordnet (Schritt S5).
Vorliegend werden Informationen über alle in der Datentabelle 14 gespeicherten Objekte einschließlich aller Dimensionen darstellenden Objekte, die Basisdaten der Objekte zugeordnet sind, in der Objekttabelle 15 gespeichert. Die den Objekten zugeordneten Objekt-IDs werden dabei in der ID-Spalte 21 der Objekttabelle 15 gespeichert. Es ist ferner in der Objekttabelle 15 für jedes Objekt und jede Dimension eine Zeile vorgesehen und die Objekttabelle 15 umfasst eine Spalte, in welcher angegeben ist, ob es sich um eine Dimension handelt, Dimensionsspalte 23.
Die Information, ob es sich um eine Dimension handelt oder nicht wird wie folgt hinterlegt. In der Dimensionsspalte 23 wird für Dimensionen eine 1 eingetragen und für Objekte „NULL“. In der oberen Zeile mit dem Objekt „Geschlecht“ steht daher „NULL“ in der Dimensionsspalte 23 und in der unteren Zeile für die Dimension „Sprache“ eine 1. Dieses Feld ist hellgrau hinterlegt, um den Zusammenhang mit der Dimension aus der Datentabelle 14 zu verdeutlichen.
Bei dem dargestellten Beispiel umfasst die Objekttabelle 15 ferner eine Objekt- Dimensions-ID-Spalte 24, welche in der Tabelle abgekürzt als „BoDimld“ bezeichnet ist. Über dieses Feld bzw. die Felder dieser Spalte 24 ist es möglich, einem Objekt, etwa Business Objekt, direkt eine Dimension zuzuweisen. Wenn dies der Fall ist, müssen nicht einzelne Felder mit einer Dimension konfiguriert werden. sondern alle Felder des Objektes haben eine Dimension, welche vom Objekt geerbt wird.
Es werden ferner Informationen über die Struktur der Objekte in einerweiteren Tabelle, der Feldtabelle 16, gespeichert (Schritt S6). Die Feldtabelle 16 umfasst bei dem gezeigten Beispiel die Information, in welcher Datenspalte 17 oder welchen Datenspalten 17 der Datentabelle 14 die Basisdaten des jeweiligen Objektes gespeichert werden.
Die Feldtabelle 16 umfasst ferner eine Spalte, in welcher die in der Datentabelle 14 verwendeten Namen derjenigen Datenspalten 17 angegeben sind, in welchen Basisdaten zu dem jeweiligen Objekt gespeichert werden. Diese Spalte wird als Feldnamenspalte 25 bezeichnet.
Die Feldtabelle 16 umfasst darüber hinaus eine Spalte, in der angegeben ist, Basisdaten welcher Art in der oder den Datenspalten des jeweiligen Objektes gespeichert werden. Diese Spalte, welche Feldnamen umfasst, kann auch als Labelspalte 26 bzw. Labelnamenspalte bezeichnet werden. Wie man erkennt, finden sich hier die Angaben Code, Name, Anrede und Typ.
Die Feldtabelle 16 weist auch eine Dimensionsspalte 27 auf, in der angegeben ist, ob die zu dem Objekt gehörigen Basisdaten in den in der Feldnamenspalte 25 aufgeführten Datenspalten jeweils eine Dimension haben oder nicht. Vorliegend ist in der Dimensionsspalte 27 auch angegeben, welche Dimension zugeordnet ist. Wie man erkennt, ist hier festgehalten, dass dem Namen und der Anrede des Objektes „Geschlecht“ eine Dimension zugeordnet ist, dem Code und Typ hingegen nicht. In der Spalte 27 unten ist für das Dimensionsobjekt „Sprache“ angegeben, dass diesem keine Dimension zugeordnet ist. Es ist eine Dimension und es finden sich Angaben „NULL“ in diesen beiden Spalten der Zeile 27.
Weiterhin umfasst die Feldtabelle 16 eine Spalte, in welcher die dem jeweiligen Objekt zugeordnete Objekt-ID angegeben ist, Objekt-ID-Spalte 28. Hier ist also die eindeutige Identität des jeweiligen Objektes angegeben, wobei das Objekt „Geschlecht“ die Objekt-ID 466 und das Dimensionsobjekt „Sprache“ die Objekt-ID 480 hat, welche die übergeordnete Dimensions-Master-ID ist.
Weitere Spalten der Feldtabelle 16 sind vorliegend eine ID-Spalte 29, eine FeldCaptionNamen-Spalte 30, eine FeldTypen-Spalte 31 und eine Feldgrö- ßen-Spalte 32.
In der ID-Spalte 29 ist, wie in der ID-Spalte 18 der Datentabelle 14, eine ID angegeben. Die IDs sind in der Feldtabelle 16 ebenfalls fortlaufend und können als Zeilen-IDs aufgefasst und bezeichnet werden. Da in Figur 3 nur ein Ausschnitt der Feldtabelle 16 gezeigt ist, konkret nur diejenigen Bereiche, welche die beiden Objekte „Geschlecht“ und „Sprache“ betreffen, sind die IDs hier nicht alle fortlaufend, sondern gibt es einen „Sprung“ von 2216 auf 2747.
In dem dargestellten Ausschnitt finden sich in der Objekt-ID-Spalte 28 daher ausschließlich die dem Objekt „Geschlecht“ zugeordnete ID 466 und die dem Objekt „Sprache“ zugeordnete ID 480 (vgl. auch die Spalte 21 der Objekttabelle 15). Der Feldspalte 25 kann man entnehmen, dass die Datenspalten 17 „DATA_2“, „DATA_1“, „DATA_16“ und „DATA_15“ Basisdaten des Objektes „Geschlecht“ mit der Objekt-ID 466 aufweisen. In der neben der Feldspalte 25 liegenden Labelspalte 26 ist - jeweils in entsprechenden Zeilen - angegeben, Basisdaten welcher Art in der jeweiligen Datenspalte gemäß Spalte 25 des jeweiligen Objektes gespeichert werden. Wie man sieht, ist in der Datenspalte 17 „DATA_2“ der Code des jeweiligen Geschlechts gespeichert, in der Datenspalte 17 „DATA_1“ der Name des jeweiligen Geschlechts, in der Datenspalte 17 „DATA_16“ die Anrede für das jeweilige Geschlecht und in der Datenspalte 17 „DATA_15“ der Geschlechts-Typ, konkret die Kürzel „M“, „F“ und „D“. Dem Namen und der Anrede ist gemäß der Dimensionsspalte 27 eine Dimension zugeordnet und zwar diejenige mit der Dimensions-Master-ID 480, also gemäß der Objekttabelle die Dimension „Sprache“.
In der FeldCaptionNamen-Spalte 30 sind Feldnamen für die Anzeige enthalten. Die FeldTypen-Spalte 31 umfasst hier den SQL-Datentyp des Feldes. Die Feldgrößen-Spalte 32 enthält die Größe des Feldes für den in der FeldTypen- Spalte 31 genannten Datentyp.
Es können noch weitere Tabellen vorhanden sein und in diesen Daten gespeichert werden.
So können beispielsweise in einer Relationstabelle zwischen verschiedenen Objekten bestehende Relationen gespeichert werden. In einer solchen Tabelle können dann beispielsweise für die jeweilige Relation eine Relations-ID und/oder ein Relationstyp und/oder eine Objekt-ID und/oder eine Objekt-Feld-ID gespeichert werden.
Auch ist es möglich, dass in einer Instanzentabelle verschiedene Instanzen gespeichert werden. Hier können beispielsweise für die jeweilige Instanz eine Instanz-ID und/oder ein Instanzname und/oder eine Instanzlizenz und/oder ein geheimer Code gespeichert werden. Über mehrere Instanzen wird es insbesondere möglich, einer Situation mit mehreren Kunden bzw. Mandanten Rechnung zu tragen. Dann wird bevorzugt jedem Kunden bzw. Mandanten eine Instanz zugeordnet und es ist jedem Kunden nur möglich, Daten seiner Instanz abzurufen, so dass der Datenschutz gewährleistet ist.
Wenn man das Ergebnis für das Geschlecht „Male“ abruft, kann man je nachdem, welche Abfrage für die Dimension genutzt wird, einen oder zwei Einträge erhalten, im Falle zweier beider Sprachen:
Wenn man das Geschlecht (als Ganzes) und die Sprache Deutsch abfragt, sieht das Ergebnis im json-Format als Ausgabe einer RESTfuI API wie folgt aus:
{
"items": [
{
"data": {
"code": "Male",
"CreatedBy": "admin@ms360base.de",
"CreatedDate": "2021-02-12T12:24:57.503+01 :00",
"Dimension": {
"Sprache": {
"Bold": 480,
"IsDefault": true,
"SpracheCode": "de-DE", "SpracheName": "Deutsch", "MasterRecordID": 410348
}
}.
"Dimensions": "410348",
"MasterRecordID": 457465,
"MS_Bold": 466,
"MS_ProduktNummer": 10,
"MS_RecordLevel": 1 ,
"name": "Männlich",
"Anrede": "Herr",
"Type ": "M",
"Updatedby": "admin@ms360base.de",
"UpdatedDate": "2021-02-12T12:28:27.303+01 :00"
}
}.
{
"data": {
"code":
"CreatedBy": "admin@ms360base.de",
"CreatedDate": "2021-02-12T12:30:05.537+01 :00",
"Dimension": {
"Sprache": {
"Bold": 480,
"IsDefault": true,
"SpracheCode": "de-DE",
"SpracheName": "Deutsch", "MasterRecordID": 410348
}
}. "Dimensions": "410348",
"MasterRecordID": 457502,
"MS_Bold": 466,
"MS_ProduktNummer": 10,
"MS_RecordLevel": 1 ,
"name": "Weiblich",
"Anrede": "Frau",
"Type ": "F",
"Updatedby": null,
"UpdatedDate": null
}
}.
{
"data": {
"code": "Divers",
"CreatedBy": "admin@ms360base.de",
"CreatedDate": "2021-02-25T11 :16:04.49+01 :00",
"Dimension": {
"Sprache": {
"Bold": 480,
"IsDefault": true,
"SpracheCode": "de-DE",
"SpracheName": "Deutsch", "MasterRecordID": 410348
}
}.
"Dimensions": "410348",
"MasterRecordID": 468819,
"MS_Bold": 466,
"MS_ProduktNummer": 10, "MS_Recordl_evel": 1 ,
"name": "Divers",
"Anrede":
"Type ": "D",
"Updatedby": null,
"UpdatedDate": null
}
}
]
}
Für den Fall, dass die englische Sprache angefragt wird, sieht das Ergebnis wie folgt aus:
{
"items": [
{
"data": {
"code": "Male",
"CreatedBy": "admin@ms360base.de",
"CreatedDate": "2021-02-12T12:24:57.52+01 :00",
"Dimension": {
"Sprache": {
"Bold": 480,
"IsDefault": false,
"SpracheCode": "en-US",
"SpracheName": null,
"MasterRecordID": 410350
}
}. "Dimensions": "410350",
"MasterRecordID": 457465,
"MS_Bold": 466,
"MS_ProduktNummer": 10,
"MS_RecordLevel": 1 ,
"name": "Male",
"Anrede": "Mr.",
"Type ": "M",
"Updatedby": "admin@ms360base.de",
"UpdatedDate": "2021-02-12T12:28:27.32+01 :00"
}
}.
{
"data": {
"code":
"CreatedBy": "admin@ms360base.de",
"CreatedDate": "2021-02-12T12:30:05.537+01 :00",
"Dimension": {
"Sprache": {
"Bold": 480,
"IsDefault": false,
"SpracheCode": "en-US",
"SpracheName": null, "MasterRecordID": 410350
}
}.
"Dimensions": "410350",
"MasterRecordID": 457502,
"MS_Bold": 466,
"MS_ProduktNummer": 10, "MS_Recordl_evel": 1 ,
"name": "Woman",
"Anrede": "Mrs.",
"Type ": "F",
"Updatedby": null,
"UpdatedDate": null
}
}.
{
"data": {
"code": "Divers",
"CreatedBy": "admin@ms360base.de",
"CreatedDate": "2021-02-25T11 :16:04.49+01 :00",
"Dimension": {
"Sprache": {
"Bold": 480,
"IsDefault": false,
"SpracheCode": "en-US",
"SpracheName": null,
"MasterRecordID": 410350
}
}.
"Dimensions": "410350",
"MasterRecordID": 468819,
"MS_Bold": 466,
"MS_ProduktNummer": 10,
"MS_RecordLevel": 1 ,
"name": "Divers",
"Anrede":
"Type": "D", "Updatedby": null, "UpdatedDate": null
}
}
]
}
Es sei betont, dass es nicht auf die Reihenfolge der vorstehend beschriebenen Schritte ankommt. So ist es beispielsweise möglich, jedoch nicht nötig, dass erst die Speicherung von Basisdaten in der Datentabelle 14 erfolgt und im Anschluss Einträge in der Objekt- 15 und/oder Feldtabelle 16 vorgenommen werden. Die umgekehrte Reihenfolge kommt gleichermaßen in Frage. Es können mit anderen Worten auch erst die Informationen über die Dimensi- one(n)/Ojekt(e) und deren Struktur abgelegt werden und dann die Speicherung der Daten in der Datentabelle 14 erfolgen. Im laufenden Betrieb wird sich der Inhalt einer Datenbank ohnehin steig verändern, etwa weil neue Kunden, Produkte etc. hinzukommen oder bestehende wegfallen. Auch hier spielt es dann keine Rolle, in welcher Reihenfolge die Schritte des erfindungsgemäßen Verfahrens durchgeführt werden.
Auch kommt es nicht darauf an, ob in der Datentabelle 14 erst Basisdaten und dann zugehörige Dimensions-IDs abgelegt werden oder umgekehrt.
Bevorzugt wird für alle Objekte die gleiche Struktur benutzt, wenn die Dimension für Felder gesetzt wird, für welche Dimensionswerte gespeichert werden müssen, wie beispielsweise der Name des Geschlechtes, wie oben beschrieben. Die Speicherung miteinander in Beziehung stehender Daten in einer Datentabelle 14 und zugehörige Nutzung von Dimension(en) bietet erhebliche Vorteile. Wird die gleiche Datentabelle 14 genutzt, ist es insbesondere nicht erforderlich, mehrere Skriptanfragen (englisch: script queries) zu erzeugen, um Ergebnisse von der Datenbank 13 zu erhalten und die JOIN-Funktion zum Verbinden mehrere Tabellen (vgl. Figur 1) ist nicht (zwingend) erforderlich. Man erhält eine Datenbank 13 mit dynamischer Infrastruktur. Es kann ein dynamischer Skriptgenerator genutzt werden und Abfragen von Daten aus der einen Datentabelle 14 können unter Verwendung einer MAX()-Funktion erfolgen. Die Abfrage kann daher gegenüber vorbekannten relationalen Lösungen um ein Vielfaches beschleunigt werden. Im Ergebnis können (Rechen-)Zeit, Aufwand und auch Energie eingespart werden. Das erfindungsgemäße Verfahren ist daher auch besonders nachhaltig.
Im Folgenden wird rein beispielhaft erläutert, wie die Datenabfrage erfolgen kann.
Wie vorstehend beschrieben, hat jedes Objekt Felder, welche die Objektstruktur angeben. Die Daten sind in der Datentabelle 14 gespeichert, die gezielt Leereinträge bzw. die Angaben „NULL“ umfasst. Um die Daten für die jeweilige Dimension zu erhalten, kann die MAX()-Funktion genutzt werden. In der Datentabelle 14 sind für jeden Eintrag (englisch: record) ein Public Record zum Speichern der Public Fields des Objektes und zusätzlich Dimensionseinträge für jede Dimension, welche das Objekt hat bzw. dessen Felder haben, gespeichert.
Die Dimensions-ID im Public Record ist, wie beschrieben, NULL und als MasterRecordID für alle Einträge wird die MasterRecordID des Public Record übernommen (vgl. die Datentabelle 14, insbesondere die Spalte 18 und 19). Aus Gründen der Vereinfachung wird nun von folgendem Objekt „Item“ ausgegangen: Hier steht die übergeordnete Dimensions-ID 100 für das eine Dimension darstellende Objekt „Sprache“. In diesem Beispiel werden, wenn Daten für das „Item“ gespeichert werden, und zwei Sprachen existieren, drei Einträge eingefügt, ein Public Record mit dem ItemCode, der Länge und Breite sowie zwei weitere Einträge für den ItemName in zwei verschiedenen Sprachen.
Wenn man von einer Objekt-ID (Bold) 101 ausgeht und z.B. für Deutsch die Dimensions-ID 200 und für Englisch die Dimensions-ID 201 annimmt, erhält man als Eintrag in der Datentabelle 14 für dieses Beispiel:
(vgl. zur Struktur mit der Tabelle 14 in Figur 3) Daten können über die MAX()-Funktion abgefragt werden, bei der es sich um eine Funktion handelt, welche den größten Wert einer ausgewählten Spalte liefert.
Um das Ergebnis für die deutsche Sprache zu erhalten, kann folgendes SQL- Script für das Beispiel genutzt werden:
Select max(MasterRecordld) as MasterRecordld, max(Data_1) as Item- Code, max(Data_2) as ltemName,max(Data_3) as Length max(Data_4) as Width from Ms4_data where Bold=101 and (Dimen- sionld =200 or Dimensionld is null) group by MasterRecordld
Als Ergebnis erhält man:
Wenn man Daten für beide Sprachen abrufen möchte, wird ein solches Skript für jede der beiden Sprachen genutzt und über die Funktion UNION verbunden:
Select max(MasterRecordld) as MasterRecordld, max(Data_1) as Item- Code, max(Data_2) as ltemName,max(Data_3) as Length max(Data_4) as Width from Ms4_data where Bold=101 and (Dimensionld =200 or Dimensionld is null) group by MasterRecordld
UNION ALL
Select max(MasterRecordld) as MasterRecordld, max(Data_1) as Item- Code, max(Data_2) as ltemName,max(Data_3) as Length max(Data_4) as Width from Ms4_data where Bold=101 and (Dimen- sionld =201 or Dimensionld is null) group by MasterRecordld
Als Ergebnis erhält man:
Natürlich ist es auch möglich, dass in einem Eintrag in der Datentabelle 14 zwei Felder vorhanden sind, die jeweils eine Dimension haben. Z.B. kann man für das vorstehende Beispiel des „Items“ zusätzlich zu dem Namen in verschiedenen Sprachen einen Preis für verschiedene Länder mit verschiedenen Währungen benötigen.
Wenn man z.B. als übergeordnete Dimensions-Master-ID (Bold) für das Land 102 annimmt und für Deutschland die Dimensions-ID 600 und die USA die Dimensions-ID 601 , ergibt sich:
Wenn Daten für die beiden verschiedenen Sprachen und die beiden Länder mit den verschiedenen Währungen gespeichert werden, erhält man in der Datentabelle 14 z.B.:
(vgl. zur Struktur mit der Tabelle 14 in Figur 3)
Wenn eine Abfrage für alle Dimensionen gewünscht ist, gilt folgendes. Da zwei Eintragsdimensionen für die Sprache und zwei Eintragsdimensionen für die Länder existieren, existieren vier Einträge:
Sprache Deutsch, Preis für Deutschland (in €)
Sprache Deutsch, Preis für die USA (in $)
Sprache Englisch, Preis für Deutschland (in €)
Sprache Englisch, Preis für die USA (in $)
Bevor das Skript für alle Dimensionen angegeben wird, wird zunächst das Skript für nur eine Dimension erläutert, beispielhaft für: die deutsche Sprache mit der RecordlD=200 und das Land Deutschland mit der RecordlD=600.
Die Skript-Abfrage lautet dann:
Select max(MasterRecordld) as MasterRecordld,max(Data_1) as Item- Code, max(Data_2) as ltemName,max(Data_3) as Length max(Data_4) as Width, max(Data_5) as Price from Ms4_data where Bold=101 and (dimensioned in (200,600) or dimensioned is null) group by MasterRecordld
Und das Abfrage-Ergebnis:
Wenn die Daten für die Sprache Deutsch und alle Länder gewünscht sind, gilt: die deutsche Sprache mit der RecordlD=200, das Land Deutschland mit der RecordlD=600, das Land USA mit der RecordlD=601
Um hier die Daten zu erhalten, werden die Daten für jeden Dimensionssatz abgefragt und die Ergebnisse mit UNION vereint:
Der Dimensionssatz ist: (200,600) , (200,601)
Die Skriptabfrage lautet:
Select max(MasterRecordld) as MasterRecordld, max(Data_1) as Item- Code, max(Data_2) as ltemName,max(Data_3) as Length max(Data_4) as Width, max(Data_5) as Price from Ms4_data where Bold=101 and (dimensioned in (200,600) or dimensioned is null) group by MasterRecordld
UNION ALL Select max(MasterRecordld) as MasterRecordld,max(Data_1) as Item- Code, max(Data_2) as ltemName,max(Data_3) as Length max(Data_4) as Width, max(Data_5) as Price from Ms4_data where Bold=101 and (dimensioned in (200,601) or dimensioned is null) group by MasterRecordld
Als Ergebnis erhält man:
Es kann ein dynamisches Skript generiert werden, was im Folgenden anhand eines Ausführungsbeispiels exemplarisch erläutert wird.
Es wird davon ausgegangen, dass eine Datentabelle mit dem Namen „MS4_data“ existiert, in welcher alle Einträgen von Daten enthalten sind. Eine solche Datentabelle ist durch die in Figur 3 auszugsweise dargestellte Tabelle 14 gegeben.
Es existiert ein Feld Bold (vgl. Tabelle 16, Spalte 28), dass auf eine Objekt-, etwa Business-Objekt-ID, verweist, so dass bekannt ist, zu welchem Business Objekt die Einträge gehören.
Es wird, wie vorstehend, von einem Business Objekt „Item“ mit der Objekt-ID (Bold) 101 und einem weiteren Business Objekt „account“ mit der Bold 102 ausgegangen. Wenn alle Einträge für das Objekt „Item“ gewünscht sind, wird ein Skript wie folgt benötigt:
Select * from ms4_data where Bold=101 Für das Business Objekt “Account”:
Select * from ms4_data where Bold=102
Es kann dynamisch gestaltet werden, insbesondere, um in SQL eine Prozedur zu schaffen und den Business Objekt Namen als Parameter übergeben und alle Einträge für dieses Business Objekt erhalten zu können.
Es kann die Prozedur „GetData“ erstellt werden.
Create Procedure GetData
@BoName nvarchar(200)
As
Declare Bold int;
Select @Bold=ID from MS4_BObject where BObjectName=@BoName If @Bold is null
THROW 60000, 'Business object name is not valid', 1 ;
Select * from MS4_Data where Bold=@Bold
Dann kann man dies über
Exec GetData 'Item' oder
Exec GetData 'Account' laufen lassen.
Dann existiert eine Prozedur, über die man Daten mit dem Business Objekt Namen erhalten kann. In der Datentabelle 14 „MS4_data“ existieren Felder, deren Namen mit „data_“ beginnen (data_1 , data_2, data_3, .... vgl. Spalten 17 von Tabelle 14 in Figur 3) und es ist ein Mapping gespeichert zwischen dem FeldNamen im Business Objekt und der echten Feldspalte in MS4_data.
In diesem Beispiel ist der ItemCode zu Data_1 gemapped, der ItemName zu Data_2 usw.
Man kann die dynamische Prozedur anpassen, um den Business Objekt FeldCaptionNamen für jedes Business Objekt zu erhalten. Hierfür kann folgendes Skript erstellt werden:
Select data_1 as itemcode, data_2 as itemname from ms4_data where boid=101
Da der FeldCaptionName für jedes Objekt verschieden und zu verschiedenen echten feldern in der datentabelle 14 „MS4_data“ gemapped ist, ist ein dynamische Lösung zweckmäßig.
Alle Felder eines Business Objektes erhält man z.B. über
Select feldcaptionname from ms4_field where boid=101 Das Ergebnis ist:
Es wird der Feldname benötigt, um ein Skript wie folgt auszusuchen und zu generieren: max(Data_1) as Itemcode. Hierfür kann man das Skript anpassen zu: Select 'Max('+fieldname+ ') as '+ fieldcaptionname from ms4_field where boid=101
Das Ergebnis ist:
Im nächsten Schritt kann man diese Zeilen zusammenfügen und mit einem Komma (,) trennen, dann kann folgender Code genutzt werden: SELECT STUFF((SELECT ','+'Max('+fieldname+ ') as '+ fieldcaptionname from MS4_Field where BOID=101 FOR XML PATH("), TYPE).value('.', 'NVARCHAR(MAX)'),1 ,0,")
Das Ergebnis ist:
,Max(Data_1) as ItemCode, Max(Data_2) as ltemName,Max(Data_3) as Länge, Max(Data_4) as Breite
Nun kann man die dynamische Prozedur GetData ändern:
Create Procedure GetData
@BoName nvarchar(200), ©Dimension nvarchar(1000)
As
Declare Bold int;
Select @Bold=ID from MS4_B0bject where BObjectName=@BoName If @Bold is null
THROW 60000, 'Business object name is not valid', 1 ;
Declare ©fields nvarchar(max), ©script nvarchar(max)
Set @fields= STUFF((SELECT ','+'Max('+fieldname+ ') as '+ fieldcaptionname from MS4_Field where BOID=101 FOR XML PATH("), TYPE).value('.', 'NVARCHAR(MAX)'),1 ,0,")
Set @script='SELECT Max(MasterRecordlD) as MasterRecor- dld'+@fields+' from MS_Data where Boid=@Bold and (Dimension in (select value from string_split(@dimension, ',')) or Dimensionld is null) group by MasterRecordld'
EXECUTE sp_executesql ©script , N'@Bold int , ©Dimension nvar- char(1000)' , ©Bold =@Bold,@dimension=@dimension
Und über Exec GetData 'Item', '200,201'
Or
Exec GetData 'Account', '200,201' laufen lassen.
Die Nutzung der MAX()-Funktion ermöglicht eine erhebliche Zeitersparnis bei der Abfrage. Dies insbesondere im Vergleich mit Abfragen, welche die JOIN- Funktion erfordern, da die Daten nicht in einer sondern verschiedenen Tabellen gespeichert sind, wie es beispielhaft in Figur 1 dargestellt ist.
Die in Figur 3 schematisch dargestellte Datenbank 13 kann geeignete Hardware, insbesondere wenigstens eine Speichervorrichtung umfassen bzw. auf einer solchen implementiert sein. Diese kann Teil eines Ausführungsbeispiels eines erfindungsgemäßen Systems zur Datenverarbeitung sein. Ein solches System umfasst dann auch wenigstens einen Prozessor, der so konfiguriert ist, dass er die Schritte des erfindungsgemäßen Verfahrens ausführt. Ein erfindungsgemäßes System kann natürlich auch ein verteiltes System mit Hardware an verschiedenen Standorten und geeigneter Vernetzung, etwa via Internet, sein.
Das erfindungsgemäße Verfahren kann auch als „Software-as-a-Service“ realisiert werden.

Claims

ANSPRÜCHE
1. Computerimplementiertes Datenbankverfahren, bei dem
- in einer mehrspaltigen und mehrzeiligen Datentabelle (14) einer Datenbank (13) zu speichernde Basisdaten in dafür vorgesehenen Datenspalten (17) gespeichert werden (S1),
- den Basisdaten aus zumindest einigen Feldern wenigstens eine Dimension zugeordnet wird, wobei die wenigstens eine Dimension anzeigt, dass diese Basisdaten miteinander in Beziehung stehen (S2), insbesondere durch Übersetzungen in verschiedene Sprachen und/oder durch verschiedene Darstellungen für unterschiedliche Geschäftsniederlassungen gegeben sind,
- wobei die Zuordnung der oder der jeweiligen Dimension zu den oder den jeweils betroffenen Basisdaten erfolgt, indem in denjenigen Zeilen, in denen die Felder der oder der jeweils betroffenen Basisdaten liegen, in einer anderen Spalte, die keine Datenspalte ist und die für die Zuordnung der oder der jeweiligen Dimension vorgesehen ist, Dimensionsspalte (20), zu der oder der jeweiligen Dimension gehörige Dimensions- IDs gespeichert werden, wobei sich Dimensions-IDs, die zur gleichen Dimension gehören, voneinander unterscheiden.
2. Datenbankverfahren nach Anspruch 1 , dadurch gekennzeichnet, dass alle zu speichernden Basisdaten in einer Tabelle, der Datentabelle (14), gespeichert werden.
3. Datenbankverfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass für Datenspalten-Felder mit Basisdaten, denen eine Dimension zugeordnet ist, jeweils gilt, dass in anderen Datenspalten (17), die für Basisdaten vorgesehen sind, denen diese Dimension nicht zugeordnet ist, die Felder in der gleichen Zeile leer bleiben oder Leereinträge, insbesondere die Angabe NULL, umfassen, und/oder dass für Datenspalten-Felder mit Basisdaten, denen keine Dimension zugeordnet ist jeweils gilt, dass in der Dimensionsspalte (20) in den Feldern in der jeweils gleichen Zeile keine Dimen- sions-IDs gespeichert werden, diese insbesondere leer bleiben oder Leereinträge, insbesondere die Angabe NULL, umfassen.
4. Datenbankverfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass mehreren Basisdaten eine übereinstimmende Master-ID zugeordnet wird, bevorzugt, wobei die Master-ID in denjenigen Zeilen der Datentabelle (14), in denen die Felder der oder der jeweils betroffenen Basisdaten liegen, in einer anderen Spalte, die keine Datenspalte ist, Master- ID-Spalte (19), gespeichert wird.
5. Datenbankverfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass Informationen über die wenigstens eine Dimension in einerweiteren Tabelle, Objekttabelle (15), gespeichert werden, insbesondere, wobei die Objekttabelle (15) eine ID-Spalte (21) umfasst, in welcher eine zu der oder der jeweiligen Dimension gehörige ID aufgeführt ist, und die Objekttabelle (15) eine Namensspalte (22) aufweist, in welcher ein der o- der der jeweiligen Dimension zugeordneter Name aufgeführt ist.
6. Datenbankverfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass Objekte in der Datenbank (13) gespeichert werden, wobei zu jedem Objekt die Basisdaten aus einem oder mehreren Feldern aus einer oder mehreren Datenspalten (17) der Datentabelle (14) gehören, und wobei jedem Objekt eine Objekt-ID zugeordnet wird., bevorzugt, wobei für wenigstens ein Objekt Daten in mehreren Zeilen in der Datentabelle gespeichert werden, insbesondere, wobei mehreren Zeilen dieses Objektes eine übereinstimmende Master-ID zugeordnet wird, bevorzugt, wobei die übereinstimmende Master-ID in einer Master-ID-Spalte der Datentabelle in den entsprechenden Zeilen gespeichert wird.
7. Datenbankverfahren nach Anspruch 5 und 6, dadurch gekennzeichnet, dass Informationen über alle in der Datentabelle (14) gespeicherten Objekte und alle Dimensionen, die Basisdaten der Objekte zugeordnet sind, in der Objekttabelle (15) gespeichert werden, bevorzugt, wobei die den Objekten zugeordneten Objekt-IDs in der ID-Spalte (21) der Objekttabelle (15) gespeichert werden, und/oder in der Objekttabelle (15) für jedes Objekt und jede Dimension eine Zeile vorgesehen ist, und/oder die Objekttabelle (15) eine Spalte umfasst, in welcher angegeben ist, ob es sich um eine Dimension handelt, Dimensionsspalte (23).
8. Datenbankverfahren nach einem der Ansprüche 6 oder 7, dadurch gekennzeichnet, dass Informationen über die Struktur der Objekte in einer weiteren Tabelle, Feldtabelle (16), gespeichert werden, bevorzugt, wobei die Feldtabelle (16) die Information umfasst, in welcher Datenspalte (17) oder welchen Datenspalten (17) der Datentabelle (14) die Basisdaten des jeweiligen Objektes gespeichert werden.
9. Datenbankverfahren nach Anspruch 8, dadurch gekennzeichnet, dass die Feldtabelle (16) eine Spalte umfasst, in welcher die in der Datentabelle (14) verwendeten Namen derjenigen Datenspalten (17) angegeben sind, in welchen Basisdaten zu dem jeweiligen Objekt gespeichert werden, Feldnamenspalte (25), und/oder dass die Feldtabelle (16) eine Spalte umfasst, in der angegeben ist, Basisdaten welcher Art in der oder den Datenspalten des jeweiligen Objektes gespeichert werden, Labelspalte (26), und/oder dass die Feldtabelle (16) eine Spalte umfasst, in der angegeben ist, ob die zu dem Objekt gehörigen Basisdaten in den in der Feldnamenspalte (25) aufgeführten Datenspalten (17) jeweils eine Dimension haben oder nicht und bevorzugt welche Dimension zugeordnet ist, Dimensionsspalte (27), und/oder dass die Feldtabelle (16) eine Spalte umfasst, in welcher die dem jeweiligen Objekt zugeordnete Objekt-ID angegeben ist, Objekt-ID-Spalte (28).
10. Datenbankverfahren nach einem der Ansprüche 6 bis 9, dadurch gekennzeichnet, dass in einer weiteren Tabelle, Relationstabelle, zwischen verschiedenen Objekten bestehende Relationen gespeichert werden, bevorzugt, wobei in der Relationstabelle für die jeweilige Relation eine Relations-ID und/oder ein Relationstyp und/oder eine Objekt-ID und/oder eine Objekt-Feld- ID gespeichert werden.
11. Datenbankverfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass in einer weiteren Tabelle, Instanzentabelle, verschiedene Instanzen gespeichert werden, bevorzugt, wobei in der Instanzentabelle für die jeweilige Instanz eine Instanz-ID und/oder ein Instanzname und/oder eine Instanzlizenz und/oder ein geheimer Code gespeichert werden.
12. Datenbankverfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass Daten aus der Datenbank (13), insbesondere aus der Datentabelle (14), abgerufen werden, bevorzugt mittels einer API, besonders bevorzugt RESTfuI API.
13. Datenbankverfahren nach Anspruch 12, dadurch gekennzeichnet, dass das Abrufen von Daten aus der Datenbank, insbesondere aus der Datentabelle (14), unter Nutzung einer Funktion erfolgt, welche jeweils den größten aller in einer ausgewählten Spalte gespeicherten Werte liefert.
14. Datenbankverfahren nach Anspruch 12 oder 13, dadurch gekennzeichnet, dass ein dynamisches Skript und/oder ein dynamischer Skriptgenerator für das Abrufen von Daten aus der Datenbank (13), insbesondere der Datentabelle (14), genutzt wird.
15. System zur Datenverarbeitung, umfassend wenigstens einen Prozes- sor und eine oder mehrere Speichervorrichtungen, wobei der wenigstens eine
Prozessor so konfiguriert ist, dass er die Schritte des Verfahrens nach einem der vorhergehenden Ansprüche ausführt.
16. Computerprogrammprodukt, umfassend Befehle, die bei der Ausfüh- rung des Programms durch wenigstens einen Computer den wenigstens einen
Computer veranlassen, die Schritte des Verfahrens nach einem der Ansprüche 1 bis 14 auszuführen.
17. Computerlesbares Speichermedium, umfassend Befehle, die bei der Ausführung durch wenigstens einen Computer den wenigstens einen Computer veranlassen, die Schritte des Verfahrens nach einem der Ansprüche 1 bis
14 auszuführen.
EP22789206.4A 2021-09-16 2022-09-16 Computerimplementiertes datenbankverfahren, system zur datenverarbeitung, computerprogrammprodukt und computerlesbares speichermedium Pending EP4402579A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102021123997.4A DE102021123997A1 (de) 2021-09-16 2021-09-16 Computerimplementiertes Datenbankverfahren, System zur Datenverarbeitung, Computerprogrammprodukt und computerlesbares Speichermedium
PCT/EP2022/075744 WO2023041692A1 (de) 2021-09-16 2022-09-16 Computerimplementiertes datenbankverfahren, system zur datenverarbeitung, computerprogrammprodukt und computerlesbares speichermedium

Publications (1)

Publication Number Publication Date
EP4402579A1 true EP4402579A1 (de) 2024-07-24

Family

ID=83690442

Family Applications (1)

Application Number Title Priority Date Filing Date
EP22789206.4A Pending EP4402579A1 (de) 2021-09-16 2022-09-16 Computerimplementiertes datenbankverfahren, system zur datenverarbeitung, computerprogrammprodukt und computerlesbares speichermedium

Country Status (4)

Country Link
US (1) US20250124007A1 (de)
EP (1) EP4402579A1 (de)
DE (1) DE102021123997A1 (de)
WO (1) WO2023041692A1 (de)

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7634482B2 (en) 2003-07-11 2009-12-15 Global Ids Inc. System and method for data integration using multi-dimensional, associative unique identifiers
US7769729B2 (en) 2007-05-21 2010-08-03 Sap Ag Block compression of tables with repeated values
US10565229B2 (en) 2018-05-24 2020-02-18 People.ai, Inc. Systems and methods for matching electronic activities directly to record objects of systems of record
US8521758B2 (en) 2010-01-15 2013-08-27 Salesforce.Com, Inc. System and method of matching and merging records
CN102314424B (zh) 2010-07-01 2017-03-01 商业对象软件有限公司 文件的基于维度的关系图示
US9146955B2 (en) 2012-12-18 2015-09-29 Sap Se In-memory, columnar database multidimensional analytical view integration

Also Published As

Publication number Publication date
WO2023041692A1 (de) 2023-03-23
US20250124007A1 (en) 2025-04-17
DE102021123997A1 (de) 2023-03-16

Similar Documents

Publication Publication Date Title
EP0910829B1 (de) Datenbanksystem
DE3855706T2 (de) Automatisierte Rechnung von Materialien
DE69906488T2 (de) Verfahren zur Synchronisierung eines Datenbankschemas mit seiner Darstellung in einem objekt-orientierten Repository
DE69229056T2 (de) Offene verzeichnis-datenbankansichten
DE69229453T2 (de) Verfahren und Anordnung zum Zugriff auf eine relationelle Datenbank, ohne eine objektorientierte Umgebung verlassen zu müssen
DE69602827T2 (de) Verfahren zum erstellen einer telekommunikationsnetzwerkdatenbasis
DE19538240A1 (de) Informationssystem und Verfahren zur Speicherung von Daten in einem Informationssystem
DE69719641T2 (de) Ein Verfahren, um Informationen auf Bildschirmgeräten in verschiedenen Grössen zu präsentieren
EP1798672A1 (de) Computer-implementiertes System zur Erzeugung, Bearbeitung und Verwaltung von strukturierten Datensätzen
DE69517887T2 (de) Verfahren und System zum Herstellen von Verbindungen in einem Datenbanksystem
DE202014010948U1 (de) Nicht-kollaborative Filter in einem kollaborativen Dokument
EP4402579A1 (de) Computerimplementiertes datenbankverfahren, system zur datenverarbeitung, computerprogrammprodukt und computerlesbares speichermedium
EP3776257B1 (de) Objektdatenbank zur geschäftsmodellierung mit verbesserter datensicherheit
DE102021124001A1 (de) Computerimplementiertes Datenbankverfahren, System zur Datenverarbeitung, Computerprogrammprodukt und computerlesbares Speichermedium
DE102010064167A1 (de) Dynamische Berichtserstellung
WO2006103177A1 (de) Verfahren zum anordnen von objektdaten in elektronischen karten
HESSE Importsubstitution und Entwicklungspolitik
WO2008131465A1 (de) Verfahren zur steurerung eines relationalen datenbanksystems
Baecker Die Spencer-Brown-Transformation
DE602005002846T2 (de) Verfahren zur Datenverarbeitung und assoziiertes Softwareprogramm
EP1285315B1 (de) Informationsverarbeitungssystem und verfahren zu dessen betrieb
DE602004001762T2 (de) Verfahren und computersystem zur datenzuweisung
EP3441919A1 (de) Verfahren zum austausch von daten zwischen engineering-tools eines engineering-systems sowie engineering-system zur durchführung des verfahrens
EP1139243A1 (de) Abrechnungs- und Kundenverwaltungssystem
DE10343328A1 (de) Verfahren zum Abbilden eines hierarchischen technischen Systems in eine relationale Datenbank

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: 20240313

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)