[go: up one dir, main page]

WO2008131465A1 - Verfahren zur steurerung eines relationalen datenbanksystems - Google Patents

Verfahren zur steurerung eines relationalen datenbanksystems Download PDF

Info

Publication number
WO2008131465A1
WO2008131465A1 PCT/AT2007/000195 AT2007000195W WO2008131465A1 WO 2008131465 A1 WO2008131465 A1 WO 2008131465A1 AT 2007000195 W AT2007000195 W AT 2007000195W WO 2008131465 A1 WO2008131465 A1 WO 2008131465A1
Authority
WO
WIPO (PCT)
Prior art keywords
decision
companies
sql statement
statement
superordinate
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.)
Ceased
Application number
PCT/AT2007/000195
Other languages
English (en)
French (fr)
Inventor
Matthias MÖSTL
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.)
Mediareif Mostl & Reif Kommunikations- und Informationstechnologien Oeg
Original Assignee
Mediareif Mostl & Reif Kommunikations- und Informationstechnologien Oeg
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 Mediareif Mostl & Reif Kommunikations- und Informationstechnologien Oeg filed Critical Mediareif Mostl & Reif Kommunikations- und Informationstechnologien Oeg
Priority to PCT/AT2007/000195 priority Critical patent/WO2008131465A1/de
Publication of WO2008131465A1 publication Critical patent/WO2008131465A1/de
Anticipated expiration legal-status Critical
Ceased 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/24—Querying
    • G06F16/245—Query processing
    • G06F16/2453—Query optimisation
    • G06F16/24534—Query rewriting; Transformation
    • G06F16/24539—Query rewriting; Transformation using cached or materialised query results
    • 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/24—Querying
    • G06F16/242—Query formulation
    • G06F16/2433—Query languages
    • 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/24—Querying
    • G06F16/245—Query processing
    • G06F16/2452—Query translation
    • G06F16/24524—Access plan code generation and invalidation; Reuse of access plans
    • 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/24—Querying
    • G06F16/245—Query processing
    • G06F16/2452—Query translation
    • G06F16/24526—Internal representations for queries
    • 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/24—Querying
    • G06F16/245—Query processing
    • G06F16/2453—Query optimisation
    • G06F16/24534—Query rewriting; Transformation

Definitions

  • the invention relates to a method for controlling a relational database system by executing a database query in a relational database containing as associated data structure a plurality of data tables linked by relations as well as a table of relations, using a database language.
  • the starting point for the invention is the occurrence in practice of similar requests to a relational database. Despite the apparent relationship similar
  • a further object of the invention is to enable the non-specialist to easily and intuitively formulate statements which are subsequently automatically converted into statements that are sometimes very complex and even difficult to formulate for the person skilled in the art.
  • the object of the invention is to achieve the greatest possible independence from formulated statements and underlying data structures by means of a short notation, which focuses on the nature of a problem. According to the invention, this is achieved in a method mentioned in the introduction by comprising the following steps:
  • Value fields is defined and each has at least one decision path
  • each decision path at least one of the decision positions can always be reached, which specifies by means of an associated flag that it contains at least one table field which is unambiguously assignable to one of the data tables, possibly by means of supplementary specification of a data table name, to the specific underlying data structure,
  • Creating a user SQL statement by a user in a formulating step in which at least one of the table-superordinate value fields is selected from the set of table-superordinate value fields by the user and optionally with parameters, in at least one of the processing areas in at least one of the hierarchy levels, but independent of the data tables used in the user SQL statement, used in the formulation of the user SQL statement, and in which, where appropriate, relationship-based operations are not included
  • one or more table-superordinated value fields are created by the user as required, the inner, directed decision graph of the same depending on the existing tables and queries of the given data structure.
  • a semi-automated creation of the table-superordinated value fields can be provided.
  • table-superordinate value field in the context of the present application, an element is understood which is treated as a table field or as a table in the specification of SQL statements, thus to be treated as such in the statements for the user.
  • a value or a set of values can be expected from each table-superordinate value field at the respective position of the statement.
  • tablette superordinate refers to the independence of the value fields from the defined tables and queries in the respective data structure
  • table parent value fields sometimes return one or more tables after their call, which are not in any relational relationship specified by a user in the statement to the tables or queries associated with them according to an SQL statement, a completion of the missing relational operations is under Application preferably a table of relations and gradually described method in these cases necessary.
  • the table of relations contains at least all relationships between all the tables and queries of the respective underlying data structure, and it can also contain freely generated relations.
  • a directed decision graph of a table-superordinated value field denotes a directed graph according to the prior art, the nodes of the graph representing decision positions.
  • a decision path denotes a possible path by the directed decision graph from a first reachable decision position within it to a last decision position defined. The sum of all decision paths thus gives rise to all possibilities of traversing a decision graph from first decision positions to last decision positions, the superimposition of these different pass possibilities over the decision paths is graphically represented such that branch points arise at certain points of the resulting decision graph.
  • the statement resolution step which calls and uses all table-superordinated value fields used in a statement with parameters specified according to the statement
  • the decision paths that are affected by the given parameters and their pre-definable evaluation are displayed in each table-superordinate value field until the end of the table-superordinate value field Value field tracked.
  • all decision positions are collected and returned as a result, which by means of an associated flag determine that they contain at least one table field that can be uniquely assigned to a table or set of the concrete underlying data structure, as well as all results of those Decision items on which a table-superordinate value field with specified parameters is traversed.
  • the result of the passage of a table-superordinate value field is created either as a criterion, grouping, additional quantity and / or lower hierarchy level - SUB-SELECT etc.
  • the query language SQL consists of predefined processing areas and processing sequences, such as SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT, UNION.
  • Table superordinate value fields can sometimes be used in more than one processing area of a specified SQL statement.
  • the main element of an SQL query is formed by relationship-based operations, such as projection, join, or selection, or set-based operations, such as set union, set intersection, or set difference.
  • relationship-based operations such as projection, join, or selection
  • set-based operations such as set union, set intersection, or set difference.
  • the invention relates to relational database systems that allow access to the data stored in a database using a database language.
  • the widely used database language SQL is used, but the invention is not limited to the use thereof.
  • the main tasks of a database system are attaching, modifying, deleting, and managing data and providing it through database queries.
  • a relational database system which comprises a computer system with a relational database, a data processing unit and a memory, wherein the data processing unit operates according to the inventive method.
  • a computer program may be stored on a computer-readable medium, such as a floppy disk, CD or DVD, having computer program code means, upon loading the computer program, a computer through the program for carrying out the method of producing a data carrier or electronic carrier signal according to the invention is caused.
  • a computer program product which has a computer program on an electronic carrier signal in which, after the computer program has been loaded, a computer is caused by the program for carrying out the method according to the invention.
  • the invention relates to a computer program having instructions that are set up for carrying out the method according to the invention.
  • the invention relates to a computer program product which has a computer-readable medium with computer program code means, in which, after loading the computer program, a computer is caused by the program for carrying out the method according to the invention.
  • the invention also relates to a computer program product which has a computer program on an electronic carrier signal, in which, in each case after loading the computer program, a computer is caused by the program for carrying out the method according to the invention.
  • 1 is a schematic representation of hierarchy levels within an SQL statement in the form of an ordered tree for the application of an embodiment of the method according to the invention to a query example; 2 shows a schematic representation of Hierarcliiecut within an SQL statement in the form of an ordered tree for the application of an embodiment of the method according to the invention to a further query example; 3 shows a schematic representation of an SQL RTN according to the prior art; 4, 5, 6 each show a schematic representation of tabular value fields according to the invention with their inner directed decision graphs and their decision positions.
  • relations-related operations all the required relations of a particular statement are referred to collectively as relations-related operations.
  • each relational database there is an associated data structure in the form of a plurality of data tables linked by relations. These are understood to mean data organized in columns and rows, as given below by way of example in Tables 1 to 10.
  • the term "row relation” is understood to mean in each case the rows of a table, that is to say, for example, Table 1 companies (company ID, name, street, postcode, city, country, employees, supervisor) and for table 2 departments (department ID, company no "Relationships", however, the connections between each two data tables on each at least one key field, eg 1: 1, 1: n, n: m - 1: n applies to: Companies (Firmald) ⁇ -> Departments (CompanyNr).
  • the Firmald column in the Companies table (Table 1) is a primary key for which there can be any number of values in the Departments table (Table 2) in the CompanyNr column.
  • each data structure there is a table of relations in which all the data structures associated with the queried database are contained, as well as optionally freely generated relations.
  • Sales of certain items in a given period Sales of certain groups of items in a given period
  • Each of these sales or count values to be calculated can be formulated via a particular query by a user in SQL. This effort must be provided by the user for each sales query. For all these cases, the SQL queries look fundamentally different and must be reformulated depending on the case. This is possible for the normal user sometimes only with great time and effort. Especially if the underlying data structure, for example due to a Enlargement of the system, all requests must be redesigned.
  • a table-superordinate value field and thus also the specifically used table superordinate value field "turnover" in a user SQL statement can be used independently of the data tables and the processing areas defined in this user SQL statement in respective hierarchy levels.
  • a concrete question may be:
  • the application of the statement resolution step will be shown later in the description to show the focus in this part of the introduction on the basic advantages of the simple, short and data structure independent notation by formulation of user SQL statements according to the invention.
  • the used table-superordinate value field returns the turnover taking into account the parameters specified in each case, but at the positions used after the resolution step and the completion of the relationship-related operations in the completion step, the turnover per data set company is calculated taking into account the relation-related operations.
  • Another specific question posed by a user may be:
  • a simple user SQL statement is specified, which contains the table-superordinate value field turnover with a parameter, whereby the value of this value field delivers the turnover per contact person per company through the statement resolution step and after completing the relationship-related operations in the completion step.
  • the inner, directed decision graph of the table-superordinate value field is, according to the underlying data structure, taken into account by the optional parameter "gross "extended by at least one further decision position.
  • table-superordinate value field SalesBrutto can contain the same optional parameters as the table-superordinate value field Sales, whereby the inner, directed decision graph of the table-superordinate value field
  • SalesBrutto contains only one decision item. This one decision item in the table-superordinate value field SalesBrutto calls the table-superordinate value field Sales with all its optional parameters, with the parameter "Gross" as
  • table-superordinate value fields such as these three table-superordinate value fields:
  • these table-superordinate value fields use the same parameters as the table-superordinate value field Sales and set these as parameters for their single decision position, which contains the table-superordinate value field Sales.
  • the advantage of using table-superordinate value fields at decision positions of an inner, directed decision graph of another table-superordinated value field is that a change of the inner, directed decision graph of the inserted table-superordinate value field does not influence the table-superordinated value field containing this table-superordinate value field at at least one of its decision positions.
  • Another example is to supply all the columns of the table companies, the number of events of the last 3 years and the turnover of the last 3 years of the companies that booked more than 10 events in 2006 and more than 1000 euros in 2006:
  • the following user SQL statement presents this question:
  • This example shows the multiple usage of two different table-superordinate value fields, each with different processing areas.
  • the application of the statement resolution step as well as the application of the completion step will be shown later in the description in detail for a variety of examples.
  • An RTN is the abbreviation for the well-known term "recursive transition network.”
  • An RTN defines the expressive power of a language in which syntactically formable options are defined in it.An extension of the RTN of a language leads to a stronger expressiveness of the same.
  • First-to-fourth-generation languages, including SQL, are turing-complete, meaning a language's increased expressiveness means that complex questions can be defined more easily and more accurately, especially by a non-specialist given statements.
  • Each request request is from a fixed predetermined sequence of compulsory sequentially arranged processing areas 340, 341, 342, 343, 344, 345 with keywords 20, 321, 322, 323, 324, 325, 326, 327, 328, 329, 330, 331
  • decision positions 310, 311, 312, 313 - for the sake of simplicity only for the introductory keywords 324, 326, 328, 330 of the processing areas 342, 343, 344 and 345 - a very specific selection of keywords can be made to receive the desired inquiry result.
  • a particular grouping of keywords each form a processing area, eg, FROM (keywords 322, 323), WHERE (keywords 324, 325), GROUP BY (keywords 326, 327), etc., each processing area performing a set processing function associated with it, eg, forming FROM Cartesian products with the possibility of special JOINs.
  • SQL and related query languages are relatively limited and there are a number of queries which can only be described in a very cumbersome and tedious manner with the given processing areas in the given processing order and therefore become more complex and complex slower access plan is generated than actually required.
  • Table-higher value fields are created in a preset step.
  • the definition of table-superordinate value fields with possibly optional parameters as well as their inner, directed decision graph can be done, for example, in a system table, in a text or XML file.
  • the table-superordinated value fields are preferably read into the memory once prior to the analysis of SQL statements, so that they can be accessed quickly at any time.
  • table-superimposed value fields are created by means of the introductory string "Define ConnectionField” followed by a freely selectable name corresponding to the function of this field.
  • the name of the table-superordinate value field is followed by an open parenthesis and a list of the optional parameters Listing is terminated with a closed parenthesis
  • the end of a table-superordinate value field is identified in the description by means of the string “End Define”, which concludes a table-superordinate value field.
  • the inner, directed decision graph of a table-superordinate value field is defined within the introductory string and the string terminating this table-superordinate value field.
  • each decision path at least one decision position can always be reached, which specifies by means of an associated flag that it contains at least one table field which is unambiguously assignable to one of the data tables, possibly by means of supplementary specification of a data table name, of the specific underlying data structure.
  • a table-superordinate value field is created whose inner, directed decision graph has a single decision path with only one decision position.
  • a decision position is reached which, regardless of a given data structure, reaches a table field.
  • This decision position also contains a processing function and the specification of the data table to which the table field used refers.
  • a first table-superordinate value field is created, which is added to the entirety of the table-superordinate value fields and, for the sake of simplicity, contains no optional parameters: Define ConnectionField Count () Count (Distinct Fi ⁇ nen.FirmalD) End Define
  • the inner directional decision graph which exists on the single decision path 1051, becomes a table-superordinate value field 1001 is shown in FIG.
  • the decision position 1101 contains a value which, upon reaching this decision position 1101, is added to the result of the passage of the table-superordinate value field 1001.
  • the inner, directed decision graph of this table-superordinate value field has no influence on the use in a user SQL statement, so for a different data structure a table-like value field of the same name can be created, which has the following inner, directed decision graphs with possibly only one Decision position contains:
  • FIG. 5 shows the inner, directed decision path 1051 and its decision position 1101 of the table-superordinated value field 1001 adapted for another data structure.
  • At least one data table to be reached is defined, in concrete terms, the data table companies or table_companies. On the basis of a specified statement, it is searched from which data table or set of these at least one table to be reached is to be reached.
  • SELECT Count Distinct Company.CompanyID AS Number of companies or SELECT Count (Table_Firmen.PK_Firma) AS Number of companies
  • SELECT Count Distinct Company.CompanyID AS Number of Companies FROM Companies or SELECT Count (Distinct Table_Firmen.PK_Firma) AS Number of Companies FROM Table_Companies
  • This final statement contains all the necessary relationship-based operations and can thus be parsed by a SQL engine.
  • all SQL statements are user SQL statements in which at least one of the table-superordinate value fields from the entirety of the table-superordinate value fields is selected by the user and optionally with parameters, in at least one of the processing areas in at least one of the hierarchy levels, but independent of the User SQL statement used in the formulation of the user SQL statement, and in which, where appropriate, relationship-based operations are not included.
  • This transient SQL statement like all subsequent transient SQL statements as well, can be augmented with the necessary relational operations as shown below.
  • the following final SQL statement is generated and passed to an SQL processing engine for analysis, optimization, and execution:
  • the converted transitional SQL statement automatically creates the following new and final SQL statement into which the relationship-related operations are already inserted by means of the procedures shown below:
  • the converted transitional SQL statement automatically creates the following new and final SQL statement into which the relationship-related operations are already inserted by means of the methods shown below:
  • the principle shown above can also be used to omit the GROUP BY processing area in the user SQL statement, since an identical statement can be generated in this case.
  • the transitional SQL statement automatically converted in the statement resolution step is as follows:
  • This transient SQL statement contains all the necessary relationship-based operations, so the final SQL statement in this case equals the transient SQL statement.
  • An algorithm can detect that there is an aggregate function in the SQL processing area WHERE, which is why this processing information is moved to the HAVING processing area and the final SQL statement therefore has the following syntax, which is extended by the missing relationship-based operations:
  • a table-superordinate value field can also be set in the FROM processing area of a user SQL statement, which creates a separate quantity for this table-superordinate value field in the FROM processing area:
  • Processing range FROM is used and can generate a corresponding, simple final SQL statement:
  • An advanced RTN based on which SQL statements can be created, can transform the following question into a state-of-the-art SQL statement: First, a simple table-superordinate value field is created, which returns the revenue in each case in connection with the tables used in an SQL statement:
  • the table-superordinate value field Umatz_Ge Scheme which is specified in the processing area SELECT of the user SQL statement, refers to the individual data records of the Cartesian product, ie the total turnover per company and contact person is calculated using this table-superordinate value field.
  • a simple algorithm recognizes that the result of the table-superordinate value field Sales_Total () at the two positions used in the respective processing areas in the user SQL statement contains at least - in the specific case exactly - a data table which is not stored in the user SQL Statement specified in the data tables or Cartesian products of the respective hierarchy level.
  • an intermediate set or a SUB-SELECT is formed in the resolution step for the conversion of this user SQL statement into the transitional SQL statement.
  • This final SQL statement is passed to a SQL engine which analyzes, optimizes and calculates this state-of-the-art statement.
  • a simple algorithm recognizes that, in the processing area WHERE, a table is connected to a table-superordinate value field via a point, and therefore this information must be transferred to the processing area FROM.
  • This table-superordinate value field 1002 is shown in FIG.
  • This table-superordinated value field 1002 has an inner, directed decision graph 1051, from which, depending on the evaluation of the parameters 1102, partial decision paths are traversed, whereby when passing through this table-superordinate value field 1002, each time results in a tracked decision path.
  • the product-formation processing area which contains the data tables to be used in the respective hierarchy level and describes the formation of a Cartesian product for them, is defined as an optional decision path only, and in those cases where this product-building processing area is not specified in the user SQL statement, it is automatically created in a later step and, for example, by means of a table of relations, determines all the data tables needed to resolve the user's SQL statement be inserted in this processing area and
  • the SQL RTN can be extended to extend those decision positions in the RTN of SQL to which a table name can be specified independently of the processing areas, such that instead of a table name, a table-superordinate value field is allowed at those decision locations, with a table-topping Value field does not necessarily have to follow further decision positions, and the user SQL statements concerned by this RTN extension are first transformed in the resolution step into a transitional SQL statement and subsequently into a final SQL statement
  • the following simple user SQL statement shows two table-superordinated value fields, which are specified in each case at a decision position in the user SQL statement on which a data table name is also permitted:
  • RTN of SQL to which a table field name can be specified independently of the processing areas, are extended in such a way that instead of a
  • Table field name a table-superordinate value field is permitted at these decision positions, whereby the table-superordinate value field does not necessarily require more
  • User SQL statements in the resolution step are first converted into a transient SQL statement and subsequently into a final SQL statement, and
  • table-superordinate value field is inserted in the statement resolution step in a directly subordinate hierarchy level containing this table-superordinate value field.
  • the user SQL statement shows two table-superordinated value fields, which are used at decision positions in the SQL RTN, to which a table field name is also permitted.
  • This user SQL statement returns the company name, department name, and revenue per department, with results sorted by company sales.
  • the SQL RTN can also be extended by extending those decision positions in the RTN of SQL to which a table name can be specified independently of the processing areas such that these table names optionally have a connection character, preferably a period followed by a table, a table field, a table-superordinate value field, a comparison operation, or an aggregate function.
  • the following example shows a user SQL statement in which an aggregate function, a table name with a following aggregate function and a table name with a table-superordinate value field.
  • This user SQL statement is converted into this final SQL statement in the following statement analysis step and then in the completion step:
  • the SQL RTN can also be extended such that those decision positions in the RTN of SQL to which a table field name can be specified independently of the processing areas are extended in such a way that optionally a connection character, preferably A point followed by a table, a table field, a table-top value field, a comparison operation, or an aggregate function is allowed.
  • AVG Firmen.PLZ.AniereKontaktpersonen ()
  • AVG Companies.PLZ.Abricen.Count
  • the SQL RTN can also be extended by expanding those decision positions at which a table-superordinate value field can be specified independently of the processing areas in such a way that a connection character, preferably a point, is optionally added to these table-superordinate value fields.
  • a connection character preferably a point
  • the Supervisor table field in the Firms table will not be included as a text field but as a numeric field and contain a relation to a separate table, such as the Employees table ,
  • the text field Maintainer in the Company table is converted to the Number field MaintainerNo and another table Employee (employee), Last name, First name, ...) is created, which contains the following relation to the Company table:
  • this user SQL statement is converted into:
  • this automatically generated SQL statement will be augmented by the relational operations, as shown later in the application. This results in the following final SQL statement for the currently underlying data structure:
  • This statement given by a user, is automatically converted into the following statement via a table of relations after the statement resolution step and the completion of missing relationship-related operations, for example, as shown below:
  • ConnectionField companies NumberContact Persons () Count (Distinct Contacts.ContactID) End Define
  • ConnectionField Company_GetPLZsOfOrt (OfOrt) SELECT Location_PLZ.PLZ WHERE LocationJPLZ.loc IN (Param: OfOrt) End Define
  • ConnectionField Company_GetOrtOfPLZ (OfPLZ) SELECT Location_PLZ.Location WHERE Location_PLZ .PLZ IN (ParamOfPLZ) End Define
  • an additional table-superordinate value field Firmen.Ort can be created which calls the table-related value field GetOrtOfPLZ () at its single decision position of its inner, directed decision graph and the PLZ as parameter the current company hands over:
  • the inner, directed decision graph of the table superordinate value field FirmenMitParametern () can be changed as follows, without already existing SQL statements using this table-top value field in at least one of its processing areas need to change:
  • Equivalent can be the inner, directed decision graph of the table-superordinate value field Companies. Have the following single decision position in its single decision path:
  • table-superordinated value fields are superior to all tables present in a data structure. This means that all tables and all sets can access each table-superordinate value field from the set of table-superordinate value fields and use it in SQL statements.
  • ConnectionField Number of events time period, supervisor, ActEventStatus
  • Param Period THEN Events.
  • V ADatum Param: Period IF Param: Supervisor THEN Company Supervisor IN (Param: Supervisor) IF Param: Act EventStatus THEN
  • Last (auxiliary status code) Param: AktVerwegungStatus END IF
  • the table-superordinate value field returns in its result processing information which relates to the table Events.
  • the table-superordinate value field is inserted, for example, as a SUB-SELECT:
  • the following step in which it is determined that the relationship-related operations are incomplete in this automatically generated statement, completes this example by the relation-related operations according to the method shown below.
  • the final statement is not shown due to its immense length. Only the first analysis step is shown, in which the algorithm recognizes that the table Articles is used in the first hierarchy level and the tables Events, Employees in the second and third hierarchy levels (the two SUB-SELECTS Müller 2006 and Müller2005) and companies are present.
  • the relational connections between these tables are automatically inserted taking into account the respective hierarchy levels by means of the method shown below, whereby a final, optimizable and processable SQL statement that can be analyzed by a SQL engine is automatically made available.
  • This user SQL statement is converted into the following final SQL statement by means of the resolution step and the completion step:
  • Sub_Ort_PLZ.Location WHERE Sub_Firmen.PLZ Sub_Ort_PLZ.PLZ GROUP BY Sub_Ort_PLZ.Location HAVING Count (*)> 100)
  • This statement is automatically updated in a subsequent step around the missing relation-related operations automatically, for example by means of a table of relations and following the procedure shown below, resulting in this new, definitive SQL statement:
  • the algorithm which automatically inserts the relationship-related operations in a new, final SQL statement, taking into account the hierarchy levels and the table of relations, is given the information by the information "Sub_" & table name
  • ConnectionField sales (period, seller, net) IF Param: Room THEN
  • VADatum Param: Period END IF
  • statement resolution step is further applied, resulting in a final processable SQL statement according to the prior art.
  • This statement resolution step as well as the subsequent step, in which the relationship-related operations are inserted in a new statement, has already been shown many times and is therefore no longer executed here.
  • the following example shows the number of contact persons per location by abstracting the contact's data tables as a table-topped value field for the aggregated Company.Order table field.
  • This statement will be changed after applying the resolution step in subsequent SQL statement, which contains no relation-related operations, and extended in a further step to the missing relationship-related operations.
  • the resolution of the table-superordinate value field Companies. Place is not shown in this step to focus the example.
  • Event.VADatum Param: Minimum_Turn_Time END IF END IF
  • a decision position is reached in each of the five defined decision paths, which contains at least one table field that can be uniquely assigned to a table.
  • the processing command DISTINCT often follows the keyword COUNT in the examples shown. This processing command can always be inserted and the need for it can be determined by a subsequent SQL optimizer. Likewise, it can be automatically recognized that the processing command DISTINCT in combination with the processing command COUNT is only required if in a hierarchy level the processing function COUNT is to be applied to a table of the defined quantity, which table is not the last level in this hierarchy level.
  • This user-created statement is automatically converted as follows:
  • processing function Count in combination with the table companies does not refer to the last level of the defined quantity, ie the Cartesian product of the two tables companies and departments. It is also recognized that the
  • Processing function Count in combination with the table Departments refers to last level of the defined quantity. Accordingly, the keyword DISTINCT is only inserted in combination with COUNT companies.FirmalD.
  • Table superordinate value fields are also very suitable for use in a graphical user interface. If a table is selected, the totality of all existing table-superordinate value fields can also be displayed for selection. Likewise, those table-superordinate value fields whose names are made up of a table name, a dot, and a table-field-naming name can be displayed as table fields of a respective table.
  • Table superordinate value fields have the same meaning for the use of all relational data structures and SQL dialects, such as OLAP, Geo-SQL, T-SQL, etc. Similarly, the method according to the invention can be applied to all other other request languages such as e.g. OQL be used.
  • ad 1) specify processing functions and data tables and their columns to which the processing functions are to be applied and the order and hierarchy level with which the processing is to be performed.
  • This request contains only the tables without relations to which processing functions are to be applied. This provides independence from any data structure and at the same time results in a shortening of the spelling and thus an increase in clarity.
  • otherwise usual Cartesian product formations which are restricted by relations, away, because in the statement all information is present, which can be used in combination with the table of relations for the determination of an access path of the respective data structure, so given on the one hand independence of the concrete data structure and on the other hand the input of the request for the user is shortened and limited only to the essentials, which in turn increases the clarity.
  • the query results in a natural order of the data tables used as well as hierarchy levels, which, using the table of relations (Table 11), result in sub-access paths for the generation of an SQL query. Statements are determined for the respective data structure.
  • the above-mentioned order and the hierarchical levels of the data tables used are preferably represented in the form of an ordered tree 7 (FIG. 1) containing a root 10 and nodes 11, 12, 13 and 14, the node 14 being a subnode to the node 13 ,
  • the root 10 of the ordered tree 7 contains as information field 21 all names of the data tables only of the higher-level request, for example in the form of a list or an array, conveniently in the order given in the statement, optionally without duplicate data table names.
  • the information field 21 includes the data table COMPANIES (Table 1).
  • Subordinate queries (SUBSELECT) and their subordinate subqueries (SUBSELECT in SUBSELECT) 3 are subordinate to the root 10 and are entered as nodes 11, 12, 13, 14 in the tree structure.
  • the information fields 22, 23, 24, 25 of the nodes 11, 12, 13, 14 contain the sub-queries assigned names of the data tables that were specified in the respective SUBSELECT, also in the form of a list or an array.
  • node 13 For node 13, these are the data tables EVENTS (Table 5), DEPARTMENTS (Table 2) and EVENTS (Table 5) in information field 24.
  • the SUBSELECT of node 13 contains, according to the question, another SUBSELECT by node 14, which in its turn Information field the data tables INVOICE POSITIONS (Table 9) and
  • This tree 7 is traversed in a preorder pass: node 10, node 11, node 12, node 13 and node 14.
  • the access path determination which specifies an access order to the database concretely, by using the table of relations between each two consecutive selected data tables, a partial access path based on the is calculated between the successive data tables existing relations, and composed of all calculated partial access paths of the access path.
  • Example B Based on the access paths determined with the table of relations given above (Table 11), it is now possible to use relationship-oriented operations in the database statement specified in accordance with the invention (Example B), whereby the following SQL statement emerges (the operations used are in italics) which of each one SQL standard supporting database system can be processed. A possible form of calculation will be explained below.
  • the notation according to the invention and the generated notation can be adopted and a recalculation is omitted. This is only done when the data structure changes or at the same or the statement itself. As a result, the very short period of time for the conversion falls into place
  • the access path refers step by step to the data tables. These references are followed step by step to access the database.
  • a root of the ordered tree includes, for example: A, C, F, B. Sub-paths thus arise
  • Subpath AC A B C
  • Subpath CF C D E
  • Subpath FB F E D C B
  • Root (node) 101 with information field 201 which contains C 5 A 5 D node 102 with information field 202, which contains G 5 E node 103 with information field 203, which contains F, I, G node 104 with information field 204, which K 3 H 3 K 5 B contains node 105 with information field 205, which contains G 5 D.
  • the table of relations belonging to the selected data structure simplifies the representation by connecting alphabetically successive data tables in each case by a common relation field, thus A ⁇ -> B 5 B ⁇ -> C 5 C ⁇ -> D,
  • the ordered tree created for a particular query is traversed in a so-called preorder order by traversing all other nodes 102, 103, 104, 105 corresponding to the hierarchy levels, starting from a first node, the root 101 of the ordered tree 107.
  • FIG. 2 shows a tree representation of a request that is not specified in more detail.
  • the root 101 (top node) contains a list or array or the like in the information field 201. all of the data table names contained in the hierarchical level 1 of the higher-level request, wherein in the query not specified-as described above-only the data tables to which processing functions are applied are given.
  • the order of the given data tables is C, A, D.
  • a node 102, 103, 105 has been created for each subquery of the superordinate request, which contains as information field 202, 203, 205 the data table names used in this subquery as list, array or the like.
  • the order is for 102 eg G 5 E, for 103 eg F 5 I 5 G etc
  • the hierarchy level 1.2.1 represents the subquery to subquery 1.2 (node 103), which in turn contains as information field 204 the data table names K 5 H 5 K, B used therefor.
  • the list of data tables is e.g. In the information field 201, the data tables C, A, D are traversed, and for each two consecutive data tables in the list, the partial access paths are calculated, as already described above, multiple passes are eliminated to unnecessary product formations, which result in a false product , to avoid.
  • the next node in the preorder sequence is searched for. Between the first data table of the list of the information field of this next node and the last data table of the list of the information field of its direct predecessor, the sub-access path is determined, then the list of this next node is traversed to the last data table as described above. For example,
  • Node 104 Passing the List of Data Tables in Information Field 204: K, H, K, B
  • next node is node 105, but its direct predecessor is node 101, therefore the connection between G (node 105) and D (node 101) is searched for and the sub-access path computed. Thereafter, the passage of the data tables G, D in the information field 205 in the node 105 of the tree 107th
  • duplicate sub-paths are removed, discarding any duplicate or multiple data table names and relations for the particular node or any of its predecessors, up to and including the root.
  • the table of relations (Table 12) in e.g. read in a graph, wherein the edges of the graph also each contain the relations conditions to determine using the graph theory connections between two data tables on the relations.
  • C ⁇ A results as a path between C and A as a result of e.g. shortest route calculation following list:
  • a -> D is the path A, B 5 C, D
  • This one is at the end of the list of the current node, here the root, arrived.
  • the next step is to determine if there are any previous nodes. In the case of the root this is by definition not true.
  • Next node 103, predecessor node 101 first data table current node and last data table predecessor node

Landscapes

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

Abstract

Verfahren zur Steuerung eines relationalen Datenbanksystems durch Ausführung einer Datenbankanfrage in einer relationalen Datenbank, welches die folgenden Schritte umfasst: Erstellen zumindest eines tabellenübergeordneten Wertefeldes, einen inneren, gerichteten Entscheidungsgraphen enthaltend, in einem Voreinstellungsschritt, Erstellen eines Anwender-SQL-Statements in einem Formulierungsschritt, in welchem zumindest eines der tabellenübergeordneten Wertefelder verwendet wird Ausführen eines nachfolgenden, automatischen Statement-Auflösungsschritts, in dem ein neues Übergangs-SQL-Statement dadurch erstellt wird, dass sämtliche im Anwender-SQL-Statement eingesetzten tabellenübergeordneten Wertefelder gegebenenfalls unter Berücksichtigung der mitgegebenen Parameter aufgerufen und durchlaufen werden und das Ergebnis dieser Durchläufe anstelle des jeweils verwendeten tabellenübergeordneten Wertefeld in das ursprünglich angegebene SQL-Statement eingesetzt wird Automatisches Vervollständigen des Übergangs-SQL-Statements durch Hinzufügen gegebenenfalls fehlender und/oder unvollständiger relationenbezogener Operationen in einem Vervollständigungsschritt, wodurch ein endgültiges SQL-Statement erzeugt wird, das von jeder, den SQL-Standard unterstützenden Engine analysiert, optimiert und verarbeitet werden kann.

Description

Verfahren zur Steuerung eines relationalen Datenbanksystems
Die Erfindung betrifft ein Verfahren zur Steuerung eines relationalen Datenbanksystems durch Ausführung einer Datenbankanfrage in einer relationalen Datenbank, welche als zugeordnete Datenstruktur eine Vielzahl durch Relationen miteinander verbundene Datentabellen sowie eine Tabelle der Relationen enthält, unter Verwendung einer Datenbanksprache.
Der Ausgangspunkt für die Erfindung ist das in der Praxis vorkommende Auftreten ähnlicher Anfragen an eine relationale Datenbank. Trotz der ersichtlichen Verwandtschaft ähnlicher
Fragestellungen sind bisher mit unter stark von einander abweichende, lange und unübersichtliche SQL-Statements notwendig. Insbesondere für den Nicht-Fachmann ist deren
Anwendung mitunter sehr schwierig. Das redundante Teilformulieren ähnlicher Bereiche ist bei leichten Änderungen der Datenstruktur besonders nachteilig. Auch wenn ähnliche Anfragen erfordert sind, welche weitere Berücksichtigungen bzw. veränderte Antworten liefern sollen, müssen jeweils aufwendig gänzlich neue Statements erzeugt werden.
Ausgehend davon ist es ein Ziel der Erfindung, ein oben genanntes Verfahren anzugeben, welches bei ungefähr ähnlicher Fragestellung in verschiedenen Statements eine Vereinheitlichung der Abfragestatements ermöglicht und damit eine deutliche Verringerung der erforderlichen Anfragezeilen erzielt. Dies erhöht auch die Übersichtlichkeit und nachfolgende Veränderbarkeit insbesondere durch Dritte der von Anwendern formulierten Statements wesentlich.
Weiteres Ziel der Erfindung ist es, dem Nicht-Fachmann die einfache und intuitive Formulierung von Statements zu ermöglichen, welche nachfolgend automatisch in mitunter sehr komplexe und sogar für den Fachmann nicht ohne Mühe formulierbare Statements umgewandelt werden.
Ebenfalls ist es Ziel der Erfindung, mittels kurzer Schreibweise, welche den Fokus auf das Wesen einer Fragestellung richtet, eine höchstmögliche Unabhängigkeit von formulierten Statements und zugrunde liegenden Datenstrukturen zu erreichen. Erfindungsgemäß wird dies bei einem eingangs genannten Verfahren dadurch gelöst, dass es die folgenden Schritte umfasst:
Erstellen zumindest eines tabellenübergeordneten Wertefeldes, gegebenenfalls optionale Parameter enthaltend, in einem Voreinstellungsschritt, wobei das oder die erstellten tabellenübergeordneten Wertefelder zu einer Gesamtheit von tabellenübergeordneten
Wertefeldern zusammengefasst werden, und wobei jedes der erstellten tabellenübergeordneten Wertefelder einen inneren, gerichteten Entscheidungsgraphen aufweist, der unabhängig von den inneren, gerichteten Entscheidungsgraphen der anderen erstellten tabellenübergeordneten Wertefelder der Gesamtheit der tabellenübergeordneten
Wertefelder definiert ist und jeweils zumindest einen Entscheidungspfad aufweist,
wobei für jedes tabellenübergeordnete Wertefeld die erforderlichen Entscheidungspfade und deren jeweilige Entscheidungspositionen durch die vorbestimmbare Auswertung der dem jeweiligen tabellenübergeordneten Wertefeld zugehörigen optionalen Parameter und/oder von vorgegebenen Funktionen bestimmt werden,
und wobei in jedem Entscheidungspfad immer zumindest eine der Entscheidungspositionen erreichbar ist, welche mittels eines zugehörigen Kennzeichens festlegt, dass diese zumindest ein Tabellenfeld enthält, das eindeutig einer der Datentabellen, gegebenenfalls mittels ergänzender Angabe eines Datentabellennamens, der konkret zugrunde liegenden Datenstruktur zuordenbar ist,
Erstellen eines Anwender-SQL-Statements durch einen Anwender in einem Formulierungsschritt, in welchem zumindest eines der tabellenübergeordneten Wertefelder aus der Gesamtheit der tabellenübergeordneten Wertefelder von dem Anwender ausgewählt und gegebenenfalls mit Parametern, in zumindest einem der Verarbeitungsbereiche in zumindest einer der Hierarchiestufen, aber unabhängig von den im Anwender-SQL-Statement verwendeten Datentabellen, bei der Formulierung des Anwender-SQL-Statements eingesetzt wird, und in welchem gegebenenfalls relationenbezogene Operationen nicht enthalten sind
Ausführen eines nachfolgenden, automatischen Statement-Auflösungsschritts, in dem ein neues Übergangs-SQL-Statement dadurch erstellt wird, dass sämtliche im Anwender- SQL-Statement eingesetzten tabellenübergeordneten Wertefelder gegebenenfalls unter Berücksichtigung der mitgegebenen Parameter aufgerufen und durchlaufen werden und das Ergebnis dieser Durchläufe anstelle des jeweils verwendeten tabellenübergeordneten Wertefeld in das ursprünglich angegebene SQL-Statement eingesetzt wird,
wobei die inneren, gerichteten Entscheidungsgraphen der im angegebenen Anwender-SQL- Statement enthaltenen tabellenübergeordneten Wertefelder erst bei Ausführung des Statement-Auflösungsschritt in Abhängigkeit von den Verarbeitungsbereichen, in denen sie jeweils verwendet werden, für die Verarbeitung herangezogen werden,
wobei bei Aufruf der tabellenübergeordneten Wertefelder dem sich jeweils über die Auswertung der mitgegebenen Parameter aus dem Anwender-SQL-Statement und/oder der Funktionen ergebenden Entscheidungspfad des inneren, gerichteten Entscheidungsgraphen desselben bis zum Ende gefolgt wird,
und als Ergebnis eines Aufrufes und Durchlaufens der tabellenübergeordneten Wertefelder die Werte all jener erreichten Entscheidungspositionen zurückgeliefert werden, welche mittels des jeweils zugehörigen Kennzeichens festlegen, dass diese zumindest ein Tabellenfeld, das eindeutig einer der Datentabellen der konkret zugrunde liegenden Datenstruktur zuordenbar ist, enthalten, sowie alle Ergebnisse jener erreichten Entscheidungspositionen, an denen ein tabellenübergeordnetes Wertefeld mit mitgegebenen Parametern durchlaufen wird,
und somit ein Übergangs-SQL-Statement zur Verfügung steht, welches gegebenenfalls unvollständige relationenbezogene Operationen enthält
- Automatisches Vervollständigen des Übergangs-SQL-Statements durch Hinzufügen gegebenenfalls fehlender und/oder unvollständiger relationenbezogener Operationen in einem Vervollständigungsschritt, wodurch ein endgültiges SQL-Statement erzeugt wird, das von jeder, den SQL-Standard unterstützenden Engine analysiert, optimiert und verarbeitet werden kann.
In dem erfmdungsgemäßen Voreinstellungsschritt werden vom Anwender je nach Bedarf ein oder mehrere tabellenübergeordnete Wertefelder erstellt, wobei der innere, gerichtete Entscheidungsgraph derselben sich nach den vorhandenen Tabellen und Abfragen der gegebenen Datenstruktur richtet. Ein halb-automatisiertes Erstellen der tabellenübergeordneten Wertefelder kann dabei vorgesehen sein.
Als tabellenübergeordnetes Wertefeld wird im Rahmen der gegenständlichen Anmeldung ein Element verstanden, welches in der Angabe von SQL-Statements gleich wie ein Tabellenfeld oder wie eine Tabelle behandelt wird, somit für den Anwender wie solche in den Statements zu behandeln sind. Somit ist von jedem tabellenübergeordneten Wertefeld aus Sicht des Anwenders an der jeweiligen Stelle des Statements ein Wert bzw. eine Wertemenge zu erwarten.
Das Attribut „tabellenübergeordnet" bezieht sich auf die Unabhängigkeit der Wertefelder von den definierten Tabellen und Abfragen in der jeweiligen Datenstruktur. Somit ergibt sich ein fundamentales Prinzip der Erfindung, wonach jedes erstellte tabellenübergeordnete Wertefeld als zusätzliches Tabellenfeld für jede vorhandene oder hinzukommende Tabelle bzw. Abfrage fungiert.
Da tabellenübergeordnete Wertefelder nach ihrem Aufruf mitunter eine oder mehrere Tabellen zurückliefern, welche in keiner von einem Anwender im Statement angegebenen relationalen Beziehung zu der bzw. den ihnen laut einem SQL-Statement zugeordneten Tabellen bzw. Abfragen stehen, ist eine Vervollständigung der fehlenden relationenbezogenen Operationen unter Anwendung vorzugsweise einer Tabelle der Relationen und nach und nach unten beschriebenen Verfahren in diesen Fällen notwendig.
In der Tabelle der Relationen sind zumindest alle Beziehungen zwischen sämtlichen Tabellen und Abfragen der jeweils zugrunde liegenden zugeordneten Datenstruktur enthalten und es können weiters frei generierte Relationen enthalten sein.
In der Praxis ist es sinnvoll, die vorhandene Tabelle der Relationen nach dem Stand der Technik als Tabelle der Relationen heranzuziehen, da diese Tabelle der Relationen die zugrunde liegende Datenstruktur in jedem Fall vollständig abbildet.
Unter einem gerichteten Entscheidungsgraphen eines tabellenübergeordneten Wertefeldes wird ein gerichteter Graph nach Stand der Technik bezeichnet, wobei die Knoten des Graphen Entscheidungspositionen darstellen. Ein Entscheidungspfad bezeichnet einen möglichen Weg durch den gerichteten Entscheidungsgraphen von einer innerhalb desselben als erste erreichbare Entscheidungsposition bis zu einer als letzte definierten Entscheidungsposition. Die Summe aller Entscheidungspfade ergeben daher alle Möglichkeiten, einen Entscheidungsgraphen von ersten Entscheidungspositionen bis zu letzten Entscheidungspositionen zu durchlaufen, die Überlagerung dieser verschiedenen Durchlaufmöglichkeiten über die Entscheidungspfade wird graphisch so dargestellt, dass sich an bestimmten Punkten des daraus resultierenden Entscheidungsgraphen Abzweigstellen ergeben.
Zur Kennzeichnung einer Entscheidungsposition, welche eine Aufteilung in mehrere Entscheidungspfade durch die vorbestimmbare Auswertung von zugehörigen Parametern und/oder Funktionen vorschreibt, werden vorzugsweise zumindest die Schlüsselworte IF ... THEN ... und SELECT CASE ... mit der in Programmiersprachen üblichen Deutung verwendet.
Um zu kennzeichnen, dass der Wert eines Parameters entweder für einen Vergleich, für eine Berechnung, eine Prüfung auf Existenz oder als konstanter Wert herangezogen werden soll, ist eine Kennzeichnung dafür sinnvoll. In der Beschreibung erfolgt dies durch die einem Parameter vorgestellte Zeichenfolge „PARAM:"
Weiters werden in der Beschreibung jene Entscheidungspositionen, welche kein spezielles Kennzeichen vorangestellt haben, als bei einem Aufruf und Durchlauf des zugehörigen tabellenübergeordneten Wertefeldes zu sammelnde Entscheidungspositionen angenommen. Dies kann über auch mittels eines eigens dafür vorgesehenem Kennzeichen erfolgen.
Bei Anwendung des Statement-Auflösungsschritt, welcher alle in einem Statement verwendeten tabellenübergeordneten Wertefelder mit jeweils laut Statement mitgegebenen Parametern aufruft und durchläuft, werden in jedem tabellenübergeordneten Wertefeld die Entscheidungspfade, die aufgrund der gegebenen Parameter und deren vorbestimmbarer Auswertung betroffen sind, bis zum Ende des tabellenübergeordneten Wertefeldes verfolgt. In diesem Durchlauf werden alle Entscheidungspositionen gesammelt und als Ergebnis zurückgeliefert, welche mittels eines zugehörigen Kennzeichens festlegen, dass diese zumindest ein Tabellenfeld, das eindeutig einer Tabelle oder Menge der konkret zugrunde liegenden Datenstruktur zuordenbar ist, enthalten, sowie alle Ergebnisse jener erreichten Entscheidungspositionen, an denen ein tabellenübergeordnetes Wertefeld mit mitgegebenen Parametern durchlaufen wird.
Unter Berücksichtigung der Verarbeitungsbereiche und der zugeordneten Tabellen und/oder Tabellenfelder wird das Ergebnis des Durchlaufes eines tabellenübergeordneten Wertefeldes entweder als Kriterium, Gruppierung, zusätzliche Menge und/oder tiefere Hierarchiestufe - SUB-SELECT usw. angelegt.
Die Anfragesprache SQL besteht aus vorgegebenen Verarbeitungsbereichen und Verarbeitungsreihenfolgen, wie SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT, UNION. Tabellenübergeordnete Wertefelder können, mitunter auch mehrfach, in einem oder mehreren Verarbeitungsbereichen eines angegebenen SQL- Statements verwendet werden.
Das Hauptelement einer SQL-Abfrage wird in vielen Fällen durch relationenbezogene Operationen, wie Projektion, Verbund (Join) oder Selektion oder mengenorientierte Operationen, wie Mengenvereinigung, Mengenschnitt oder Mengendifferenz gebildet. Dabei kommt praktisch immer zumindest die Bildung eines kartesischen Produktes von Datentabellen und Einschränkungen unter Zuhilfenahme der Relationenangabe zur Anwendung.
Die Erfindung bezieht sich dabei auf relationale Datenbanksysteme, die unter Verwendung einer Datenbanksprache einen Zugriff auf die in einer Datenbank gespeicherten Daten ermöglichen. In den gezeigten Ausführungsbeispielen wird die weit verbreitete Datenbanksprache SQL verwendet, die Erfindung ist aber nicht auf die Verwendung derselben beschränkt. Die Hauptaufgaben eines Datenbanksystems sind das Anfügen, Ändern, Löschen und Verwalten von Daten und das Bereitstellen derselben durch Datenbankabfragen.
Alle Ausführungsformen des erfindungsgemäßen Verfahrens eignen sich in gleichem Maße auch zur programmtechnischen Einrichtung eines relationalen Datenbanksystems, welches ein Computersystem mit einer relationalen Datenbank, eine Datenverarbeitungseinheit und einen Speicher umfasst, wobei die Datenverarbeitungseinheit nach dem erfindungsgemäßen Verfahren arbeitet. Ein solches Computerprogramm kann auf einem computerlesbaren Medium, wie etwa eine Diskette, CD oder DVD, wobei es Computerprogamm-Code-Mittel aufweist, bei dem nach Laden des Computerprogramms ein Computer durch das Programm zur Durchführung des Verfahrens zur Erzeugung eines erfindungsgemäßen Datenträgers oder elektronischen Trägersignals veranlaßt wird. Es kann aber etwa auch als Computeφrogrammprodukt, welches ein Computerprogramm auf einem elektronischen Trägersignal aufweist, bei dem jeweils nach Laden des Computerprogramms ein Computer durch das Programm zur Durchführung des erfindungsgemäßen Verfahrens veranlaßt wird, vorliegen.
Die erfindungsgemäße Aufgabenstellung wird somit auch durch einen Datenträger, oder in äquivalenter Weise durch ein elektronisches Trägersignal zum Einlesen in ein relationales Datenbanksystem gemäß den Merkmalen des Anspruches 16 gelöst.
Ferner betrifft die Erfindung ein Computerprogramm, das Instruktionen aufweist, die zur Durchführung des erfindungsgemäßen Verfahrens eingerichtet sind.
Weiters betrifft die Erfindung ein Compuerprogrammprodukt, welches ein computerlesbares Medium mit Computerprogramm-Code-Mitteln aufweist, bei dem jeweils nach Laden des Computerprogramms ein Computer durch das Programm zur Durchführung des erfindungsgemäßen Verfahrens veranlasst wird.
Die Erfindung betrifft schließlich auch ein Computeφrogrammprodukt, welches ein Computerprogramm auf einem elektronischen Trägersignal aufweist, bei dem jeweils nach Laden des Computerprogramms ein Computer durch das Programm zur Durchführung des erfindungsgemäßen Verfahrens veranlasst wird.
Nachfolgend wird die Erfindung anhand der in den Zeichnungen erläuterten Ausführungsformen und anhand von weiteren Ausführungsbeispielen eingehend beschrieben.
Fig, .1 eine schematische Darstellung von Hierarchiestufen innerhalb eines SQL-Statements in Form eines geordneten Baumes für die Anwendung einer Ausfuhrungsform des erfindungsgemäßen Verfahrens auf ein Anfragebeispiel; Fig.2 eine schematische Darstellung von Hierarcliiestufen innerhalb eines SQL-Statements in Form eines geordneten Baumes für die Anwendung einer Ausführungsform des erfindungsgemäßen Verfahrens auf ein weiteres Anfragebeispiel; Fig. 3 zeigt eine schematische Darstellung eines SQL-RTNs gemäß Stand der Technik; Fig. 4, 5, 6 zeigen jeweils eine schematische Darstellung von erfindungsgemäßen tabellenübergeordneten Wertefeldern mit deren inneren gerichteten Entscheidungsgraphen und deren Entscheidungspostionen.
Im nachfolgend angegebenen Beispiel A wird der Einfluss der Datenstruktur auf die Formulierung der Abfrage verdeutlicht.
Beispiel A:
Ausgabe aller Firmen aus Wien, sortiert nach Firmennamen, deren Abteilungen und deren Kontaktpersonen
Datenstruktur 1:
Relationen: Firmen <-> Abteilungen <-> Kontaktpersonen
SELECT Firmen.*, Abteilungen.*, Kontaktpersonen.* Verarbeitungsfunktion
FROM Firmen, Abteilungen, Kontaktpersonen kart. Produkt; Relationenangabe
WHERE (Firmen. FirmalD = Abteilungen. FirmaNr) Relationenangabe AND (Abteilungen.AbteilungID = Kontaktpersonen.AbteilungNr) Relationenangabe
AND (Firmen.Ort = „Wien") Verarbeitungsfunktion
ORDER BY Firmen. Name Verarbeitungsfunktion
Datenstruktur 2:
Relationen: Firmen <-> Geschäftsbereich <-> Abteilungen <-> Kontaktpersonen
SELECT Firmen.*, Abteilungen.*, Kontaktpersonen.* Verarbeitungsfunktion
FROM Firmen, Geschäftsbereich, Abteilungen, Kontaktpersonen kart. Produkt;
Relationenangabe
WHERE ( Firmen. FID = Geschäftsbereich. FNr) Relationenangabe
AND (Geschäftsbereich. BereichID = Abteilungen. BereichNr) Relationenangabe AND (Abteilungen. AID = Kontaktpersonen. ANr) Relationenangabe
ORDER BY Firmen. Name Verarbeitungsfunktion Wie zu ersehen ist, liegen je nach Datenstruktur jeweils Relationen vor, die für jede Datenbankanweisung (Statement) immer wieder neu angegeben werden müssen, wodurch sich eine Abhängigkeit von der Datenstruktur ergibt.
In der Beschreibung werden nachfolgend alle benötigten Relationenangaben eines jeweiligen Statements zusammenfassend als relationenbezogene Operationen bezeichnet.
In jeder relationalen Datenbank existiert eine zugeordnete Datenstruktur in Form einer Vielzahl durch Relationen miteinander verbundenen Datentabellen. Darunter werden in Spalten und Zeilen organisierte Daten verstanden, wie sie nachfolgend beispielhaft in den Tabellen 1 bis 10 angegeben sind.
Im Rahmen der Beschreibung wird unter dem Begriff „Zeilenrelation" jeweils die Zeilen einer Tabelle verstanden, also für z.B. Tabelle 1 Firmen(FirmaID, Name, Straße, PLZ, Ort, Land, AnzMitarbeiter, Betreuer) und für Tabelle 2 Abteilungen (AbteilungID, FirmaNr, Abteilungsname). Als „Relationen" werden hingegen die Verbindungen zwischen jeweils zwei Datentabellen über jeweils zumindest ein Schlüsselfeld, also z.B. 1:1, 1 :n, n:m - 1 :n gilt für: Firmen (Firmald) <-> Abteilungen (FirmaNr) bezeichnet. Die Spalte Firmald in der Tabelle Firmen (Tabelle 1) ist ein Primärschlüssel, für den es in der Tabelle Abteilungen (Tabelle 2) in der Spalte FirmaNr beliebig viele Werte geben kann.
Figure imgf000011_0001
Figure imgf000012_0001
Figure imgf000012_0002
Figure imgf000013_0001
Figure imgf000013_0002
Figure imgf000014_0001
Figure imgf000014_0002
Figure imgf000015_0001
Figure imgf000015_0002
Figure imgf000016_0001
Für jede Datenstruktur ist eine Tabelle der Relationen vorhanden, in der alle der abgefragten Datenbank zugeordneten Datenstruktur entsprechenden Relationen sowie gegebenenfalls frei generierte Relationen enthalten sind.
Figure imgf000016_0002
In der Praxis werden von Anwendern viele Anfragen beispielsweise zum Thema Umsatz gestellt, welche zwar ähnlich sind, aber im SQL-Standard mitunter jeweils sehr unterschiedlich zu formulieren sind:
Bezogen auf die gezeigten Tabellen Tabelle 1 bis Tabelle 10 sind folgende Fragestellungen in zumindest einem der Verarbeitungsbereiche von SQL denkbar:
Umsatz einer Firma insgesamt
Umsatz einer Firma in einem bestimmten Zeitraum Umsatz einer Firma bei bestimmten Artikeln
Umsatz aller Firmen von einem bestimmten Betreuer
Umsatz aller Firmen in bestimmten Orten
Umsatz je Kontaktperson einer Firma
Umsatz bestimmter Artikel in einem bestimmten Zeitraum Umsatz bestimmter Artikelgruppen in einem bestimmten Zeitraum
Umsatz bestimmter Artikel je Firma
Umsatz sämtlicher Veranstaltungen in einem bestimmten Zeitraum
Kombination dieser Kriterien
Unterscheidung: Umsatz netto oder brutto
Unterscheidung: Umsatz bei Ausländischen Firmen ohne MwSt
Gleiche Fragestellungen könnten auch für die Anzahl der Veranstaltungen, Anzahl der stornierten Veranstaltungen, Anzahl der unterschiedlichen Artikel usw. gestellt werden. Diese angefragten Werte können jeweils ebenfalls je Ort, je Firma, je Mitarbeiter, je Artikelgruppe usw. sowie in Kombination mehrerer dieser Anzahl- und Summenfelder gestellt werden.
Jeder dieser zu berechnenden Umsatz- oder Anzahlswerte kann über eine bestimmte Abfrage von einem Anwender in SQL formuliert werden. Dieser Aufwand muss vom Anwender für jede Umsatzabfrage erbracht werden. Für alle diese Fälle schauen die SQL-Anfragen prinzipiell unterschiedlich aus und müssen je nach Fall neu formuliert werden. Dies ist für den normalen Anwender mitunter nur mit großem Zeitaufwand und viel Mühe möglich. Besonders, wenn die dahinter liegende Datenstruktur beispielsweise aufgrund einer Erweiterung des Systems verändert werden muss, müssen sämtliche Anfragen neu gestaltet werden.
Insbesondere, wenn komplexere Verknüpfungen gefragt sind, wird eine Formulierung in SQL auch für den Fachmann sehr schwierig. Eine Konvertierung bereits vorhandener Anfragen auf andere Datenstrukturen ist ebenfalls nur mit einer Umstellung sämtlicher betroffener SQL- Statements möglich.
Diese Problematik kann durch Anwendung des erfϊndungsgemäßen Verfahrens weitgehend gelöst werden, wie es die weiter unten gezeigten Teil-Fragestellungen in Übersichtsform darstellen: Es wird ein tabellenübergeordnetes Wertefeld mit Parametern erstellt, im konkreten Fall das tabellenübergeordnete Wertefeld „Umsatz", welches zumindest die jeweils optionalen Parameter Zeitraum, Artikelgruppe, Betreuer, Ort, und GroupBy enthält. Der innere, gerichtete Entscheidungsgraph eines tabellenübergeordneten Wertefeldes ist für die Verwendung in Anwender-SQL-Statements nicht von Relevanz und wird je nach gegebener Datenstruktur definiert. Deswegen wird auf eine Darstellung des inneren, gerichteten Entscheidungsgraphen für die gegebene Datenstruktur, welche sich aus den Tabellen 1 bis 10 und den in der Tabelle der Relationen gespeicherten Relationen zwischen jeweils zwei Tabellen über jeweils zumindest ein Schlüsselfeld ergibt, an dieser Stelle verzichtet.
Es wird gezeigt, dass ein tabellenübergeordnetes Wertefeld und somit auch das konkret verwendete tabellenübergeordnete Wertefeld „Umsatz" in einem Anwender-SQL-Statement unabhängig von den in diesem Anwender-SQL-Statement in jeweiligen Hierarchiestufen definierten Datentabellen und den Verarbeitungsbereichen verwendet werden kann.
Es wird nachstehend die einfache Formulierung von angegebenen Teil-Fragestellungen gezeigt, welche nach dem Statement- Auflösungsschritt in jeweils mitunter gänzlich unterschiedliche Übergangs-SQL-Statements und nachfolgend in endgültige SQL-Statements umgewandelt werden. Durch die Verwendung der tabellenübergeordneten Wertefelder bleibt das Anwender-SQL-Statement einerseits sehr kurz, übersichtlich und leicht änderbar, anderseits ist eine größtmögliche Unabhängigkeit des Anwender-SQL-Statments von einer Datenstruktur gegeben.
Umsatz einer Firma insgesamt Firmen.UmsatzQ Umsatz einer Firma in einem bestimmten Zeitraum (Jahr 2006)
Firmen.Umsatz(Zeitraum=2006) Umsatz einer Firma bei bestimmten Artikelgrappen Fimen.UmsatzfArtikelgruppe="Speisen")
Umsatz aller Firmen von einem bestimmten Betreuer
Firmen.UmsatzfBetreuer="Meier") Umsatz aller Firmen in bestimmten Orten
Firnien.Umsatz(Ort="Wien,St.PöIten") Umsatz j e Kontaktperson einer Firma
Firmen.Umsatz(GroupBy="Kontaktρersonen"') Umsatz bestimmter Artikel in einem bestimmten Zeitraum
Artikel.UmsatzfZeitraum=2006)
Umsatz bestimmter Artikelgruppen in einem bestimmten Zeitraum Artikel.Artikelgruppe.UmsatzCZeitraum^OOό)
Umsatz bestimmter Artikel je Firma
Artikel.Umsatz(GroupBv="Firma") Umsatz sämtlicher Veranstaltungen in einem bestimmten Zeitraum
Veranstaltungen. UmsatzCZeitraum^OOθ)
Eine konkrete Fragestellung kann lauten:
Alle Firmen und deren Umsatz je Artikelgruppe als Spalten im SELECT- Verarbeitungsbereich im Jahr 2006, deren Umsatz in der Artikelgruppe „Speisen" zumindest 1000 Euro im Jahr 2006 betragen hat:
Diese wird im folgenden Anwender-SQL-Statement angegeben, welches zwei mal das tabellenübergeordnete Wertefeld Umsatz mit jeweils zwei unterschiedlich angegebenen Parametern verwendet und welches keine vollständigen relationenbezogenen Operationen enthält:
Beispiel:
SELECT Firmen.Umsatz(GroupBy=" Artikelgruppe", Zeitraum=2006)
WHERE Firmen.Umsatz(Zeitraum=2006, Artikelgruppe="Speisen")> 1000 Die Anwendung des Statement-Auflösungsschrittes wird später in der Beschreibung gezeigt, um den Fokus in diesem Teil der Einleitung auf die grundsätzlichen Vorteile der einfachen, kurzen und Datenstruktur unabhängigen Schreibweise durch Formulierung von erfindungsgemäßen Anwender-SQL-Statements zu zeigen. Das verwendete tabellenübergeordnete Wertefeld liefert den Umsatz unter Berücksichtigung der jeweils angegebenen Parameter, aber an beiden eingesetzten Positionen wird nach dem Auflösungsschritt und der Vervollständigung der relationenbezogenen Operationen im Veivollständigungsschritt der Umsatz je Datensatz Firma unter Berücksichtigung der relationenbezogenen Operationen berechnet.
Eine weitere konkrete Fragestellung eines Anwenders kann lauten:
Umsatz je Jahr als Spalte im SELECT- Verarbeitungsbereich aller Kontaktpersonen in der
Firma „Bauer GmbH"
Es wird ein einfaches Anwender-SQL-Statement angegeben, welches das tabellenübergeordnete Wertefeld Umsatz mit einem Parameter enthält, wobei der Wert dieses Wertefeldes durch den Statement-Auflösungsschritt und nach der Vervollständigung der relationenbezogenen Operationen im Vervollständigungsschritt den Umsatz je Kontaktperson je Firma liefert.
Beispiel:
SELECT Kontaktpersonen.Nachname , Umsatz(GroupBy=Year(Veranstaltungen. VADatum))
WHERE Firmen.Name ="Bauer GmBH"
GROUP BY Kontaktpersonen.Nachname
Soll der Umsatz Brutto geliefert werden, so kann dies beispielsweise mittels eines weiteren optionalen Parameters „Brutto" für das tabellenübergeordnete Wertefeld Umsatz erfolgen. Der innere, gerichtete Entscheidungsgraph des tabellenübergeordneten Wertefeldes wird, entsprechend der zugrunde liegen Datenstruktur, um die Berücksichtigung des optionalen Parameters „Brutto" mittels zumindest einer weiteren Entscheidungsposition erweitert.
Somit kann in Anwender-SQL-Statements einfach zwischen dem Brutto-Umsatz und dem Netto-Umsatz gewählt werden, wobei ebenfalls über den inneren, gerichteten Entscheidungsgraphen des tabellenübergeordneten Wertefeldes Umsatz definiert wird, welcher dieser beiden Umsatzwerte in den Fällen ausgegeben wird, in denen kein Parameter „Brutto" vorhanden ist. Im konkreten wird bei fehlendem Parameter „Brutto" im inneren, gerichteten Entscheidungsgraphen vorgeschrieben, dass die Entscheidungsposition erreicht wird, welche die notwendige Verarbeitungsinformation und das bzw. die notwendigen Tabellenfelder enthält, um den Netto-Umsatz je nach gewünschter Definition abhängig oder unabhängig von den anderen, optional mitzugebenden Parametern zu berechnen.
Somit kann folgendes tabellenübergeordnetes Wertefeld unabhängig von Datentabellen, welche in einem Teil-Anwender-SQL-Statement verwendet werden, einfach den Brutto- Umsatz und den Netto-Umsatz j eweils für das Jahr 2006 liefern:
Umsatz(Zeitraum=2006, Brutto), Umsatz(Zeitraum-2006)
Ebenso kann ein neues tabellenübergeordnetes Wertefeld „UmsatzBrutto" im Voreinstellungsschritt erstellt werden, womit Umsatz Brutto und Umsatz Netto jeweils für die Artikelgruppe „Speisen" in einem Teil-Anwender-SQL-Statement wie folgt erfragt werden kann:
UmsatzBrutto(ArtikelGruppe="Speisen"), Umsatz(Artikelgruppe="Speisen")
Die Existenz des tabellenübergeordneten Wertefeldes UmsatzBrutto schließt die Existenz
oder Verwendung des tabellenübergeordneten Wertefeldes Umsatz mit dem Parameter
„Brutto" keineswegs aus. Es kann sogar das tabellenübergeordnete Wertefeld UmsatzBrutto die gleichen optionalen Parameter wie das tabellenübergeordnete Wertefeld Umsatz enthalten, wobei der innere, gerichtete Entscheidungsgraph des tabellenübergeordneten Wertefeldes
UmsatzBrutto nur eine Entscheidungsposition enthält. Diese eine Entscheidungsposition im tabellenübergeordneten Wertefeld UmsatzBrutto ruft das tabellenübergeordnete Wertefeld Umsatz mit sämtlichen seiner optionalen Parameter auf, wobei der Parameter „Brutto" als
Konstante mitgegeben wird. Es ist somit vorgesehen, dass auch alle anderen erstellten tabellenübergeordneten Wertefelder an beliebigen Entscheidungspositionen von inneren, gerichteten Entscheidungsgraphen von tabellenübergeordneten Wertefeldern eingesetzt und bei Erreichen dieser Entscheidungspositionen aufgerufen und durchlaufen werden können. Der Wert jener Entscheidungspositionen, in welche ein tabellenübergeordnetes Wertefeld mit vorgegebenen Parametern eingesetzt wurde, entspricht dem Ergebnis des Durchlaufes des eingesetzten tabellenübergeordneten Wertefeldes. Somit können auch beliebig oftmalige, endliche Verschachtelungen von tabellenübergeordneten Wertefeldern vorgenommen werden.
Auf gleiche Weise können sehr einfach weitere ähnliche, tabellenübergeordnete Wertefelder erstellt werden, so zum Beispiel diese drei tabellenübergeordneten Wertefelder:
UmsatzAktuellesJahr UmsatzVorjahr UmsatzLetzteDrei Jahre
Diese tabellenübergeordneten Wertefelder verwenden, wie oben beschrieben, die gleichen Parameter wie das tabellenübergeordnete Wertefeld Umsatz und setzen diese als Parameter für ihre jeweils einzige Entscheidungsposition ein, welche das tabellenübergeordnete Wertefeld Umsatz enthält. Dem eingesetzten tabellenübergeordneten Wertefeld werden alle optionalen Parameter mitgegeben, einzig der Parameter Zeitraum ist konstant und je dieser tabellenübergeordneten Wertefelder beispielsweise: Date.Year, Date.Year-1, >=Date-Year-3.
Der Vorteil der Verwendung von tabellenübergeordneten Wertefeldern an Entscheidungspositionen eines inneren, gerichteten Entscheidungsgraphen eines anderen tabellenübergeordneten Wertefeldes ist, dass eine Änderung des inneren, gerichteten Entscheidungsgraphen des eingesetzten tabellenübergeordneten Wertefeldes keinen Einfluss auf das dieses tabellenübergeordnete Wertefeld an zumindest einer seiner Entscheidungspositionen enthaltenden tabellenübergeordneten Wertefeld ausübt.
Ein weiteres Beispiel soll alle Spalten der Tabelle Firmen, die Anzahl der Veranstaltungen der letzten 3 Jahre und den Umsatz der letzen 3 Jahre jener Firmen liefern, die im Jahr 2006 mehr als 10 Veranstaltungen gebucht und im Jahr 2006 mehr als 1000 Euro Umsatz haben: Folgendes Anwender-SQL-Statement stellt diese Fragestellung dar:
Beispiel:
SELECT Firmen.*, AnzahlVeranstaltungen(>=Date.Year-3)3 Umsatz(Zeitraurn>=Date.Year-3)
WHERE (ArizahlVeranstaltungen(Zeitraum=2006) > 10) AND (Umsatz(Zeitraum=2006)>1000)
Die Konstante Date. Year liefert das aktuelle Jahr zurück.
In diesem Beispiel wird die mehrfache Verwendung von zwei unterschiedlichen tabellenübergeordneten Wertefeldern mit jeweils unterschiedlichen Verarbeitungsbereichen gezeigt. Die Anwendung des Statement-Auflösungsschritts sowie die Anwendung des Vervollständigungsschrittes werden später in der Beschreibung ausführlich für eine Vielzahl an Beispielen gezeigt.
Um die Verwendung von tabellenübergeordneten Wertefeldern zu standardisieren, ist eine Erweiterung des RTN von SQL sinnvoll. Diese Erweiterung wird weiter unten in der Beschreibung im Detail gezeigt, soll aber hier vorab kurz beschrieben werden:
Ein RTN ist die Abkürzung für den bekannten Begriff „rekursives Übergangsnetzwerk". Mittels eines RTN wird die Ausdruckskraft einer Sprache festgelegt, in dem syntaktisch formulierbare Möglichkeiten in demselben festgelegt werden. Eine Erweiterung des RTN einer Sprache führt zu einer stärkeren Ausdruckskraft derselben. Da EDV-Sprachen der ersten bis vierten Generation, also auch SQL, turing-vollständig sind, bedeutet eine höhere Ausdruckskraft einer Sprache, dass komplexe Fragestellungen einfacher und zielgenauer - insbesondere durch einen Nicht-Fachmann - definiert werden können. Des Weiteren erhöht ein erweitertes RTN die Übersichtlichkeit von angegebenen Statements.
Fig.3 zeigt einen vereinfachten Entscheidungsgraphen nach dem Stand der Technik für die SELECT- Anweisung der Anfragesprache SQL, aus dem schematisch die Struktur des RTN für SQL ersichtlich wird. Jedes Anfragestatement wird aus einer fix vorgegebenen Abfolge von zwingend aufeinander folgend angeordneten Verarbeitungsbereichen 340, 341, 342, 343, 344, 345 mit Schlüsselworten 20, 321, 322, 323, 324, 325, 326, 327, 328, 329, 330, 331 gebildet, wobei an Entscheidungspositionen 310, 311, 312, 313 - der Einfachheit halber nur für die einleitenden Schlüsselworte 324, 326, 328, 330 der Verarbeitungsbereiche 342, 343, 344 und 345 gezeigt - eine ganz bestimmte Auswahl an Schlüsselworten getroffen werden kann, um das gewünschte Anfrageergebnis zu erhalten. Eine bestimmte Gruppierung von Schlüsselworten bildet jeweils einen Verarbeitungsbereich, z.B. FROM (Schlüsselworte 322, 323), WHERE (Schlüsselworte 324, 325), GROUP BY (Schlüsselworte 326, 327) usw., wobei jeder Verarbeitungsbereich eine ihm zugeordnete Mengenverarbeitungsfunktion ausführt, z.B. FROM bildet kartesische Produkte mit der Möglichkeit spezieller JOINs.
Nach jedem einleitenden Schlüsselwort 320, 322, 324, 326, 328, 330 können weitere Schlüsselworte folgen, die in Fig.l aus Gründen der Übersichtlichkeit nicht gezeigt sind. So kann z.B. nach dem Schlüsselwort 324 „WHERE" die Schlüsselworte „(", „NOT", ein Tabellenname, ein Tabellenfeldname, definierte Funktionen usw. direkt folgen. Ein SUBSELECT, also die rekursive Anwendung des RTN immer beginnend bei SELECT (Schlüsselwort 320) z.B. durch „(" kann an vorgegebenen Entscheidungspositionen auftreten. Somit kann an diesen Stellen jeweils immer nur das gesamte RTN als eine Einheit rekursiv eingesetzt werden.
Trotz der Vielzahl an möglichen auswählbaren Schlüsselworten besteht für SQL und verwandte Anfragesprachen eine relativ starke Eingeschränktheit und es gibt eine Reihe von Anfragen, welche sich mit den vorgegebenen Verarbeitungsbereichen in der vorgegebenen Verarbeitungsreihenfolge nur sehr umständlich und langwierig umschreiben lassen und daher aus dieser Beschreibung ein komplexerer und langsamerer Zugriffsplan generiert wird als tatsächlich erforderlich.
In der Formulierung dieser Fragestellungen kann auf die Gesamtheit von definierten tabellenübergeordneten Wertefeldern zugegriffen werden, welche in einem vorzugsweise erweiterten RTN, welches der Anfragesprache SQL zugrunde liegt, an genau jenen Entscheidungspositionen zugelassen werden, an welchen eine Tabelle oder ein Tabellenfeld erlaubt ist. Ebenso ist es im erweiterten RTN von SQL möglich, dass jenen Entscheidungspositionen, die eine Tabelle oder ein Tabellenfeld vorschreiben, optional eine verbindende Entscheidungsposition folgt, welches zum Beispiel das Schlüsselwort „." vorschreibt, aufweiche wiederum zwingend eine Entscheidungsposition, welche eine Tabelle, ein Tabellenfeld oder tabellenübergeordnetes Wertefeld vorschreibt folgt. Detailreiche Darstellungen eines erweiterten RTN von SQL werden in der Beschreibung weiter unten gezeigt.
Eine konkrete Implementierung von tabellenübergeordneten Wertefeldern sowie die Auflösung von Anwender-SQL-Statements, in welchen diese Verwendung finden, wird aus Gründen der Übersichtlichkeit zuerst für einfache tabellenübergeordnete Wertefelder gezeigt.
Tabellenübergeordnete Wertefelder werden in einem Voreinstellungsschritt erstellt. Die Definition von tabellenübergeordneten Wertefeldern mit gegebenenfalls optionalen Parametern sowie deren innerer, gerichteter Entscheidungsgraph können beispielsweise in einer System-Tabelle, in einer Text- oder XML-Datei erfolgen. Die tabellenübergeordneten Wertefelder werden vorzugsweise vor der Analyse von SQL-Statements einmalig in den Speicher eingelesen, um sie jederzeit schnell im Zugriff zu haben.
In der gegenständlichen Anmeldung erfolgt die Erstellung von tabellenübergeordneten Wertefeldern mittels der einleitenden Zeichenfolge „Define ConnectionField" gefolgt von einem frei wählbaren, der Funktion dieses Feldes entsprechenden Namen. Auf den Namen des tabellenübergeordneten Wertefeldes folgen eine geöffnete Klammer und eine Auflistung der jeweils optionalen Parameter. Diese Auflistung wird mit einer geschlossenen Klammer beendet. Das Ende eines tabellenübergeordneten Wertefeldes wird in der Beschreibung mittels der Zeichenfolge „End Define" gekennzeichnet, womit ein tabellenübergeordnetes Wertefeld abgeschlossen wird.
Der innere, gerichtete Entscheidungsgraph eines tabellenübergeordneten Wertefeldes wird innerhalb der einleitenden Zeichenfolge und der dieses tabellenübergeordnete Wertefeld abschließenden Zeichenfolge definiert.
Der Fachmann kann aber auch eine andere Form der Angabe und Beschreibung der tabellenübergeordneten Wertefelder wählen. Die Anwendung des Voreinstellungsschrittes folgt erfindungsgemäß nachfolgendem Verfahren:
Erstellen zumindest eines tabellenübergeordneten Wertefeldes, gegebenenfalls optionale Parameter enthaltend, in einem Voreinstellungsschritt, wobei das oder die erstellten tabellenübergeordneten Wertefelder zu einer Gesamtheit von tabellenübergeordneten Wertefeldern zusammengefasst werden, und wobei jedes der erstellten tabellenübergeordneten Wertefelder einen inneren, gerichteten Entscheidungsgraphen aufweist, der unabhängig von den inneren, gerichteten Entscheidungsgraphen der anderen erstellten tabellenübergeordneten Wertefelder der Gesamtheit der tabellenübergeordneten Wertefelder definiert ist und jeweils zumindest einen Entscheidungspfad aufweist,
wobei für jedes tabellenübergeordnete Wertefeld die erforderlichen Entscheidungspfade und deren jeweilige Entscheidungspositionen durch die vorbestimmbare Auswertung der dem jeweiligen tabellenübergeordneten Wertefeld zugehörigen optionalen Parameter und/oder von vorgegebenen Funktionen bestimmt werden,
und wobei in jedem Entscheidungspfad immer zumindest eine Entscheidungsposition erreichbar ist, welche mittels eines zugehörigen Kennzeichens festlegt, dass diese zumindest ein Tabellenfeld enthält, das eindeutig einer der Datentabellen, gegebenenfalls mittels ergänzender Angabe eines Datentabellennamens, der konkret zugrunde liegenden Datenstruktur zuordenbar ist.
Nachfolgend wird ein tabellenübergeordnetes Wertefeld erstellt, dessen innerer, gerichteter Entscheidungsgraph einen einzigen Entscheidungspfad mit nur einer Entscheidungsposition aufweist. In diesem einzigen Entscheidungspfad wird eine Entscheidungsposition erreicht, welche, unabhängig von einer gegebenen Datenstruktur, ein Tabellenfeld erreicht. Diese Entscheidungsposition enthält ebenfalls eine Verarbeitungsfunktion sowie die Angabe jener Datentabelle, auf die sich das verwendete Tabellenfeld bezieht.
Somit wird ein erstes tabellenübergeordnetes Wertefeld erstellt, welches der Gesamtheit der tabellenübergeordneten Wertefelder hinzugefügt wird, und der Einfachheit halber keine optionalen Parameter enthält: Define ConnectionField AnzahlFirmen() Count (Distinct Fiπnen.FirmalD) End Define
Der innere, gerichtete Entscheidungsgraph, welcher auf dem einzigen Entscheidungpfad 1051 besteht, wird für ein tabellenübergeordnetes Wertefeld 1001 wird in FIG 4 gezeigt.
Die Entscheidungsposition 1101 enthält einen Wert, welcher bei Erreichen dieser Entscheidungsposition 1101 dem Ergebnis des Durchlaufes des tabellenübergeordneten Wertefeldes 1001 hinzugefügt wird.
Zu beachten ist, dass der innere, gerichtete Entscheidungsgraph dieses tabellenübergeordneten Wertefeldes keinen Einfluss auf die Verwendung in einem Anwender-SQL-Statement hat, so kann für eine andere Datenstruktur ein gleichnamiges tabellenübergeordnetes Wertefeld erstellt werden, welches folgenden inneren, gerichteten Entscheidungsgraphen mit ebenenfalls nur einer Entscheidungsposition enthält:
Define ConnectionField AnzahlFirmen() Count (Distinct Table_Firmen.PK_Firma)
End Define
Figur 5 zeigt den für eine andere Datenstruktur angepassten inneren, gerichteten Entscheidungspfad 1051 und dessen Entscheidungsposition 1101 des tabellenübergeordneten Wertefeldes 1001.
Vermittels eines tabellenübergeordneten Wertefeldes wird zumindest eine zu erreichende Datentabelle, im konkreten die Datentabelle Firmen bzw. Table_Firmen, festgelegt. Anhand eines angegebenen Statements wird gesucht, von welcher Datentabelle oder Menge aus diese zumindest eine zu erreichende Tabelle erreicht werden soll.
Folgende Fragestellung verwendet das tabellenübergeordnete Wertefeld AnzahlFirmenO, um die Fragestellung: Wie viele Datensätze „Firmen" gibt es in der entsprechenden Datentabelle? Es wird ein Anwender-SQL-Statement erstellt, um diese Fragestellung zu formulieren:
Beispiel :
SELECT AnzahlFirmenO
Bei der Analyse dieses Statements wird im Statement-Auflösungsschritt festgestellt, dass das tabellenübergeordnete Wertefeld AnzahlFirmenO verwendet wird. Der Durchlauf dieses tabellenübergeordneten Wertefeldes liefert - je nach für die vorhandene Datenstruktur definierten inneren, gerichteten Entscheidungsgraphen - folgende Verarbeitungsinformation:
Count (Distinct Firmen.FiraiaID) bzw.
Count (Distinct Table_Firmen.PK_Firma)
Es wird nun ein neues Übergangs-SQL-Statement erstellt, indem das Ergebnis des eingesetzten tabellenübergeordneten Wertefeldes AnzahlFirmenO durch Aufrufen und Durchlaufen desselben berechnet und im ursprünglichen Anwender-SQL-Statement mit diesem ersetzt wird:
SELECT Count (Distinct Firma.FirmaID) AS AnzahlFirmen bzw. SELECT Count (Table_Firmen.PK_Firma) AS AnzahlFirmen
Die Information „AS AnzahlFirmen" wird beispielsweise automatisch angefügt, da das an dieser Stelle eingesetzte tabellenübergeordnete Wertefeld diesen Namen trägt und kein AS auf dieses tabellenübergeordnete Wertefeld folgt.
Soll das tabellenübergeordnete Wertefeld AnzahlFirmen einen anderen Spaltennamen aufweisen, z.B. „InsgesamteAnzahlFirmen", so ist vom Anwender die folgende Schreibweise im Anwender-SQL-Statement zu wählen:
SELECT AnzahlFirmenO AS msgesamteAnzahlFirmen Dieses neue Übergangs-SQL-Statement enthält keine relationenbezogenen Operationen, weshalb diese, z.B. mittels der Tabelle der Relationen und mit dem weiter unten in der Beschreibung gezeigten Verfahren ermittelt und eingesetzt werden müssen. Somit wird im Vervollständigungsschritt ein endgültiges SQL-Statement erstellt, welches dem Stand der Technik entspricht und alle relationenbezogenen Operationen enthält und nun von jeder den SQL-Standard unterstützenden Engine analysiert, optimiert und verarbeitet werden kann:
SELECT Count (Distinct Firma.FirmaID) AS AnzahlFirmen FROM Firmen bzw. SELECT Count (Distinct Table_Firmen.PK_Firma) AS AnzahlFirmen FROM Table_Firmen
Dieses endgültige Statement enthält alle notwendigen relationenbezogenen Operationen und kann somit von einer SQL-Engine analysiert werden.
Jedenfalls ist es auch möglich, sämtliche relationenbezogene Operationen bereits in einem Anwender-SQL-Statement anzugeben, welches tabellenübergeordnete Wertefelder enthält:
SELECT AnzahlFirmenO FROM Firmen
Ein Algorithmus stellt fest, dass in diesem Anwender-SQL-Statement bereits sämtliche rβlationenbezogenen Operationen angegeben sind, daher fällt der Schritt der Vervollständigung aller benötigen relationenbezogenen Operationen aus und das Übergangs- SQL-Statement entspricht dem endgültigen SQL-Statement. Dies ist aber insofern nachteilig, als dass sich dieses Anwender-SQL-Statement somit genau auf eine konkrete Datenstruktur bezieht.
Für die folgenden Beispiele wird auf die parallele Umwandlung für zwei oder mehrere Datenstrukturen, welche aufgrund unterschiedlicher innerer Entscheidungspfade von tabellenübergeordneten Wertefeldern und einer unterschiedlich befüllten Tabelle der Relationen automatisch vorgenommen wird, verzichtet, da sie immer dem gleichen Prinzip folgt und somit für den Fachmann verständlich ist.
Des Weiteren wird festgelegt, dass sämtliche Beispiele, welche direkt einer vorhergehenden umgangssprachlich formulierten Fragestellung folgen, in einem Formulierungsschritt erzeugte Anwender-SQL-Statements sind. Weiters sind alle SQL-Statements Anwender-SQL- Statements, in welchen zumindest eines der tabellenübergeordneten Wertefelder aus der Gesamtheit der tabellenübergeordneten Wertefelder von dem Anwender ausgewählt und gegebenenfalls mit Parametern, in zumindest einem der Verarbeitungsbereiche in zumindest einer der Hierarchiestufen, aber unabhängig von den im Anwender-SQL-Statement verwendeten Datentabellen, bei der Formulierung des Anwender-SQL-Statements eingesetzt wird, und in welchem gegebenenfalls relationenbezogene Operationen nicht enthalten sind.
Ebenso werden SQL-Statements, in welchen tabellenübergeordnete Wertefelder im Aufiösungsschritt bereits verfahrensgemäß Aufgerufen und Durchlaufen wurden und welche keine bzw. nur unvollständige relationenbezogene Operationen enthalten, in der gegenständlichen Anmeldung als Übergangs-SQL-Statements definiert.
Somit sind all jene SQL-Statement, welche kein ein tabellenübergeordnetes Wertefeld und vollständige relationenbezogene Operationen enthalten, endgültige SQL-Statments, welche von einer SQL-Engine nach dem Stand der Technik analysiert, optimiert und verarbeitet werden können. In diesem Zusammenhang sei angemerkt, dass es nicht Ziel der Erfindung ist, die Erstellung eines optimierten Zugriffsplans auf Basis eines endgültigen SQL-Statement, der konkreten, mit Indexes und Statistiken versehenen Datenstruktur sowie unter Berücksichtung von vorhandenen Arbeitsspeicher usw... auszuführen. Die Aufgabe der Erfindung besteht hingegen darin, Übersichtlichkeit, kurze Schreibweise und Unabhängigkeit von zugrunde liegenden Datenstrukturen von Anwender-SQL-Statements zu ermöglichen sowie die anzuwendenden Schritte bereitzustellen, um ein automatisch endgültiges SQL- Statement ausgehend von einen Anwender-SQL-Statement zu erhalten.
Eine unter Anwendung des erfindungsgemäßen Verfahren formulierbare Fragestellung ist: Es sollen die Anzahl Firmen je Ort berechnet und angezeigt werden:
Beispiel : SELECT Firmen.Ort, AnzahlFiπnen() AS AnzahlFirmen GROUP BY Firmen.Ort Nach Ersetzen des tabellenübergeordneten Wertefeldes AnzahlFirmen() mit dem Ergebnis seines Durchlaufs im Anwender-SQL-Statement wird folgendes neues Übergangs-SQL- Statement ohne relationenbezogene Operationen erstellt:
SELECT Firmen.Ort, Count (Distinct Firmen.FirmalD) AS AnzahlFirmen GROUP BY Firmen.Ort
Dieses Übergangs-SQL-Statement kann, wie alle nachfolgenden Übergangs-SQL-Statements ebenso, nach dem unten gezeigten Verfahren um die notwendigen relationenbezogenen Operationen erweitert werden. Somit wird folgendes endgültiges SQL-Statement erzeugt und einer SQL-Verarbeitungsengine zur Analyse, Optimierung und Ausführung übergeben:
SELECT Firmen. Ort, Count (Distinct Firmen.FirmalD) GROUP BY Firmen.Ort
Eine noch kürzere und für den Nicht-Fachmann intuitive Schreibweise für ein Anwender- SQL-Statement ist ebenfalls möglich und fuhrt zum gleichen, endgültigen SQL-Statement:
SELECT Firmen.Ort, AnzahlFirmen()
Dieses Statement wird im Auflösungsschritt in folgendes Übergangs-SQL-Statement umgewandelt:
SELECT FirmenOrt, Count (Distinct Firmen.FirmalD) AS AnzahlFirmen
Die Analyse dieses Statements ergibt, dass die Aggregatsfunktion Count anzuwenden ist, wobei das Statement das Tabellenfeld Ort einschließt, welches nicht Teil einer Aggregatsfunktion ist.
Somit kann mittels eines einfachen Algorithmus dem Anwender beispielsweise die Frage gestellt werden, ob
- aus der Tabelle Firmen die Spalte Ort und daneben die insgesamte Anzahl Firmen gezeigt werden soll,
- je Ort die Anzahl Firmen gezeigt werden soll Im ERSTEN Fall wird aus dem umgewandelten Übergangs-SQL-Statement automatisch folgendes neues und endgültiges SQL-Statement, in welches die relationenbezogenen Operationen bereits mittels unten gezeigten Verfahren eingefügt sind, erstellt:
SELECT Firmen.Ort, (SELECT Anzahl(Firmen.FirmaΙD) FROM Firmen) AS AnzahlFirmen FROM Firmen;
Im ZWEITEN, wahrscheinlicheren Fall wird aus dem umgewandelten Übergangs-SQL- Statement automatisch folgendes neues und endgültiges SQL-Statement, in welches die relationenbezogenen Operationen bereits mittels unten gezeigten Verfahren eingefügt sind, erstellt:
SELECT Firmen. Ort, Count (Distinct Firmen.FirmalD) AS AnzahlFirmen FROM Firmen
GROUP BY Firmen.Ort;
Es wird nun ein weiteres tabellenübergeordnetes Wertefeld definiert und der Gesamtheit der von einander unabhängigen, tabellenübergeordneten Wertefelder angefügt:
Define ConnectionField FirmenAusWien() (Firmen.Ort="Wien")
End Define
Nun wird ein Beispiel gezeigt, welches zwei unterschiedliche, von einander unabhängige tabellenübergeordnete Wertefelder (AnzahlFirmen, FirmenAusWien) in zwei unterschiedlichen Verarbeitungsbereichen (SELECT, WHERE) eines SQL-Statements verwendet:
Zeige von allen Firmen aus Wien je Postleitzahl die Anzahl Firmen:
Beispiel:
SELECT Firmen.PLZ, AnzahlFirmen() WHERE FirmenPLZAusWienO GROUP BY Firmen.PLZ
Nach oben gezeigten Prinzip kann auch der GROUP BY- Verarbeitungsbereich im Anwender- SQL-Statement weggelassen werden, da in diesem Fall ein identes Statement generiert werden kann.
Dieses Statement wird aufgrund der Ergebnisse des Durchlaufs der tabellenübergeordneten Wertefeldern im Statement-Auflösungsschritt in folgendes Übergangs-SQL-Statement umgewandelt:
SELECT Firmen.PLZ, Count (Distinct Firmen.FirmalD) WHERE Firmen.Ort="Wien" GROUP BY Firmen.PLZ
Nach dem automatischen Einfügen der relationenbezogenen Operationen in das Übergangs- SQL-Statement wird folgendes endgültiges SQL-Statement erstellt:
SELECT Firmen.PLZ, Count(Distinct Firmen.FirmaID) FROM Firmen
WHERE Firmen.Ort="Wien" GROUP BY Firmen.PLZ
Ein weites, einfaches Anwender-SQL-Statement zeigt die Verwendung des tabellenübergeordneten Wertefeldes FirmenAusWien im Verarbeitungsbereich SELECT:
Beispiel:
SELECT Firmen.Firmennarne, Firmen. Ort, FirmenAusWien() FROM Firmen
Ein einfacher Algorithmus kann erkennen, dass das ConnectionField FirmenAusWien() im SQL-Verarbeitungsbereich SELECT angegeben ist und dass dieses tabellenübergeordnete Wertefeld je Datensatz Firma das boolesche Ergebnis WHERE Firmen. Ort=" Wien" liefert. Somit wird als Ergebnis in der Spalte FirmenAusWien ein Boolean-Wert zurückgeliefert, der besagt, ob die jeweils aktuelle Firma aus Wien ist oder nicht:
Das im Statement-Auflösungsschritt automatisch umwandelte Übergangs-SQL-Statement lautet wie folgt:
SELECT Firmen.Firmenname, Firmen. Ort, Firaιen.Ort="Wien" AS FirmenAusWien FROM Firmen
Dieses Übergangs-SQL-Statement enthält alle notwendigen relationenbezogenen Operationen, weshalb das endgültige SQL-Statement in diesem Fall dem Übergangs-SQL- Statement entspricht.
Es wird ein Beispiel gezeigt, aus welchem ersichtlich ist, dass die Verarbeitungsinformation im endgültigen SQL-Statement gegenüber der ursprünglichen Formulierung im Anwender- SQL-Statement verschoben und geändert werden muss:
Gefragt sind alle Orte, in denen es mehr als 100 Firmen mit mehr als jeweils 10 Mitarbeitern gibt, sowie die insgesamte Anzahl der Firmen in diesem Ort, also unabhängig von der Mitarbeiteranzahl :
Beispiel:
SELECT Firmen.0rt, AnzahlFirmen() FROM Firmen
WHERE AnzahlFirmen0>100 AND Firmen. AnzahlMitarbeiter >= 10 GROUP BY FirmenOrt
Nach Einsetzten der Ergebnisse der tabellenübergeordneten Wertefelder wird folgendes, weiter zu analysierendes Übergangs-SQL-Statement gebildet:
SELECT FirmenOrt, ( SELECT Count (Distinct Firmen. FirmalD) ) AS AnzahlFirmen FROM Firmen WHERE Count (Distinct Firmen.FirmaID)>100 AND Firmen. AnzahlMitarbeiter >= 10 GROUP BY Firmen.Ort
Ein Algorithmus kann erkennen, dass eine Aggregatsfunktion im S QL- Verarbeitungsbereich WHERE vorliegt, weshalb diese Verarbeitungsinformation in den HAVING- Verarbeitungsbereich verschoben wird und das endgültige SQL-Statement daher folgende Syntax aufweist, welches um die fehlenden relationenbezogenen Operationen erweitert ist:
SELECT Firmen.Ort, ( SELECT Count (Distinct Sub_Firmen.FirmaID)
FROM Firmen AS SubJFirmen WHERE Firmen.Ort= Sub_Firmen.Ort ) AS AnzahlFirmen FROM Firmen WHERE Firmen.AnzahlMitarbeiter >= 10 GROUP BY Firmen.Ort HAVING Count(Distinct Firmen.FirmaID)>100
Die kürzeste Schreibweise für dieses Anwender-SQL-Statement lautet:
SELECT Firmen.Ort, AnzahlFirmen()
WHERE AnzahlFirmen()>100 AND Firmen. AnzahlMitarbeiter >= 10
und wird nach dem beschriebenen Verfahren in das oben gezeigte, endgültige SQL-Statement umgewandelt. Für die folgenden Beispiele werden die unterschiedlich kurzen Schreibweisen von SQL-Statements nicht mehr immer gezeigt, das sie immer dem gleichen Prinzip folgen.
Ein tabellenübergeordnetes Wertefeld kann auch in den FROM- Verarbeitungsbereich eines Anwender-SQL-Statements gesetzt werden, wodurch für dieses tabellenübergeordnete Wertefeld im FROM-Verarbeitungsbereich eine eigene Menge gebildet wird:
Alle Firmen aus Wien und deren Kontaktpersonen: Beispiel:
SELECT Firmen.*, Kontaktpersonen.*
FROM FirmenAusWien() AS Firmen, Abteilungen, Kontaktpersonen WHERE (Firmen.FirmaID=Abteilungen.FirmaNr) AND (Abteilungen.AbteilunglD^Kontaktpersonen.AbteilungNr)
Ein einfacher Algorithmus kann erkennen, dass ein tabellenübergeordnetes Wertefeld im
Verarbeitungsbereich FROM verwendet wird und kann ein entsprechendes, einfaches endgültiges SQL-Statement erzeugen:
SELECT Firmen.*, Kontaktpersonen.*
FROM ( SELECT Firmen.* FROM Firmen WHERE Firmen.Ort="Wien") ) AS Firmen, Abteilungen, Kontaktpersonen
WHERE (Firmen.FirmaID=Abteilungen.FirmaNr) AND (Abteilungen. AbteilungID=Kontaktpersonen.AbteilungNr)
Die kürzeste Schreibweise für dieses Anwender-SQL-Statement ohne relationenbezogene Operationen, welche in einem der nachfolgenden Schritte nach dem Statement- Auflösungsschritt automatisch eingefügt werden, wie unten in der Beschreibung gezeigt beispielsweise vermittels einer Tabelle der Relationen, wird für das gleiche Beispiel gezeigt:
SELECT Firmen.*, Kontaktpersonen.* FROM FirmenAusWien() AS Firmen
Die relationenbezogenen Operationen werden nach dem unten gezeigten Verfahren in das vom Anwender angegebene Anwender-SQL-Statement eingefügt und ergeben das oben gezeigte endgültige SQL-Statement.
Ein erweitertes RTN, auf dessen Grundlage SQL-Statements erstellt werden können, kann folgende Fragestellung in ein SQL-Statement nach dem Stand der Technik umwandeln: Zuerst wird ein einfaches tabellenübergeordnetes Wertefeld erstellt, welches den Umsatz jeweils im Zusammenhang mit den in einem SQL-Statement verwendeten Tabellen liefert:
Defme ConnectionField Umsatz_Gesamt () Sum (Rechnungspositionen.Positionsbetrag)
End Defϊne
Es folgt nun ein Beispiel, welches ein fundamentales Grundprinzip und somit einen der größten Vorteile der tabellenübergeordneten Tabellenfelder zeigt:
Alle Firmen und deren Kontaktpersonen sowie der Umsatz je Kontaktperson von jenen Firmen, bei denen im Jahr 2006 einen Umsatz von mehr als 1000 Euro erzielt wurde.
Beispiel: SELECT Firmen. * , Kontaktpersonen. * , Umsatz_Gesamt() FROM Firmen.Umsatz_Gesamt()>1000 AS Firmen
Durch die Angabe Firmen.Umsatz GesamtQ im Verarbeitungsbereich FROM des Anwender- SQL-Statements wird festgelegt, dass dieses tabellenübergeordnete Wertefeld für die jeweils aktuelle Firma und nicht je Datensatz des kartesischen Produktes, welches sich nach der Vervollständigung der relationenbezogenen Operationen des Statements ergibt, berechnet und auswertet werden soll.
Das tabellenübergeordnete Wertefeld Umatz_Gesamt, welches im Verarbeitungsbereich SELECT des Anwender-SQL-Statements angegeben ist, bezieht sich auf die einzelnen Datensätze des kartesischen Produktes, es wird also mittels diesen tabellenübergeordneten Wertefeldes der gesamte Umsatz je Firma und Kontaktperson berechnet.
Ein einfacher Algorithmus erkennt, dass Ergebnis des tabellenübergeordneten Wertefeldes Umsatz_Gesamt() an den beiden verwendeten Positionen in den jeweiligen Verarbeitungsbereichen im Anwender-SQL-Statement jeweils zumindest - im konkreten Fall genau - eine Datentabelle enthält, welche jeweils nicht in der im Anwender-SQL-Statement angegebenen Datentabellen oder kartesischen Produkten der jeweiligen Hierarchiestufe enthalten sind. Somit wird für die Umwandlung dieses Anwender-SQL-Statements in das Übergangs-SQL- Statement im Auflösungsschritt jeweils entweder eine Zwischenmenge oder ein SUB- SELECT gebildet.
Die Auflösung dieses Statements ergibt somit folgendes Übergangs-SQL-Statement:
SELECT
Firmen.*, Kontaktpersonen.*, ( SELECT Sum (Rechnungspositionen.Positionsbetrag ) AS Umsatz_Gesamt
FROM ( SELECT Firmen.*
WHERE (SELECT Sum (Rechnungsρositionen.Positionsbetrag ) ) > 1000
Dieses Übergangs-SQL-Statement wird nach dem unten gezeigten Verfahren um relationenbezogenen Operationen erweitert und ergibt folgendes endgültiges SQL-Statement:
SELECT Firmen.*, Kontaktpersonen.*
( SELECT Sum (Rechnungspositionen.Positionsbetrag) FROM Veranstaltungen, Rechnungen, Rechnungspositionen
WHERE (Kontak1personen.KontaktpersonID=Veranstaltungen.KontaktpersonNr) AND (yeranstaltungen.VeranstaltungID=Rechnungen.VeranstaltungNr) AND (Rechnungen.RechnungID=Rechnungspositionen.RechnungNr) ) AS Umsatz_Gesamt FROM ( SELECT Firmen. *
WHERE ( SELECT Sum (Rechnungspositionen.Positionsbetrag ) WHERE (Firmen.FirmaID=Abteilungen.FirmaNr) AND (Abteilungen.AbteilungID=Kontaktpersonen.AbteilungNr) AND (Kontaktpersonen. KontaktpersonID=Veranstaltungen.KontaktpersonNr) AND ( Veranstaltungen. VeranstaltungID=Rechnungen.VeranstaltungNr)
AND (Rechnungen.RechnungID=Rechnungspositionen.RechnungNr) ) > 1000 ) AS Firmen, Abteilungen, Kontaktpersonen WHERE (Firmen.FirmaID=Abteilungen.FirmaNr) AND (Abteilungen.AbteilungID=Kontaktpersonen.AbteilungNr)
Dieses endgültige SQL-Statement wird einer SQL-Engine übergeben, welche dieses Statement nach dem Stand der Technik analysiert, optimiert und berechnet.
Es sei nochmals angemerkt, dass der Vorteil der tabellenübergeordneten Wertefelder besonders in der kurzen, für den Nicht-Fachmann einfach verständlichen Schreibweise und in der Unabhängigkeit eines Statements von der zugrunde liegenden Datenstruktur liegt. So würde für gleiches oben gezeigtes Bespiel so wie alle anderen Anwender-SQL-Statements für eine andere zugrunde liegende Datenstruktur, für welche die tabellenübergeordneten Wertefelder einen entsprechend anderen inneren, gerichteten Entscheidungsgraphen aufweisen und welcher eine der zugrunde liegenden Datenstruktur entsprechend andere Tabelle der Relationen zugrunde liegt, jeweils ein mitunter gänzlich anderes, endgültiges SQL-Statement generiert werden. Dies geschieht aber automatisch sowohl im Statement- Auflösungsschritt als auch im Vervollständiungsschritt und insbesondere ohne Veränderung jenes vom Anwender angegebenen Anwender-SQL-Statements, welches tabellenübergeordnete Wertefelder und unvollständige bzw. keine relationenbezogenen Operationen enthält.
Die Formulierung des obigen Beispiels kann gleichwertig auch mit folgender Schreibweise dargestellt werden, welche ebenfalls auf gleiche Weise in ein endgültiges SQL-Statement umgewandelt wird:
SELECT Firmen.*, Kontaktpersonen.*, Umsatz_Gesamt() WHERE Firmen.Umsatz_Gesamt()> 1000
In diesem Fall erkennt ein einfacher Algorithmus, dass im Verarbeitungsbereich WHERE eine Tabelle über einen Punkt mit einem tabellenübergeordneten Wertefeld verbunden ist und diese Information daher in den Verarbeitungsbereich FROM übernommen werden muss.
Es wird ein weiteres tabellenübergeordnetes Wertefeld mit optionalen Parametern angelegt:
Define ConnectionField FirmenMitParametern( Betreuer, Ort, PLZ5 CountResults ) IF Param:Betreuer THEN Firmen.Betreuer IN (Param:Betreuer) IF Param:Ort THEN Firmen.Ort IN ( Param:Ort ) IF Param:PLZ THEN Firmen.PLZ IN (Param:PLZ) IF Param:CountResults THEN Count(Distinct Firmen.FirmaID)
ELSE
Finnen.* - END IF End Define
Dieses tabellenübergeordnete Wertefeld 1002 ist in Fig. 6 gezeigt. Dieses tabellenübergeordnete Wertefeld 1002 hat einen inneren, gerichteten Entscheidungsgraphen 1051, aus welchem je nach der Auswertung der Parameter 1102 Teil-Entscheidungspfade durchlaufen werden, wodurch sie bei Durchlaufen dieses tabellenübergeordneten Wertefeldes 1002 j eweils ein verfolgter Entscheidungspfad ergibt.
Als Ergebnis dieses tabellenübergeordneten Wertefeldes werden alle aufgrund der Auswertung, also aufgrund des Aufrufens und Durchlaufens, der in einem konkreten Fall angegebenen Parameter erreichten Entscheidungspositionen 1101 als Teil des Statement- Auflösungsschritt zurückgeliefert.
Mit der Gesamtheit der tabellenübergeordneten Wertefelder sind nun folgende Anwender- SQL-Statements möglich:
Fragestellung: Liefere alle Firmen aus dem Ort Wien, deren Betreuer entweder Müller, Meier oder Steiner ist.
Beispiel:
SELECT Firmen.* FROM FirmenMitParamtern( Betreuer="Müller,Meier,Steiner", Ort="Wien")
Dieses Statement wird umgewandelt in:
SELECT Firmen.* FROM
( SELECT Firmen.*
WHERE Firmen.Betreuer IN („Müller","Meier","Steiner")
AND Firmen.Qrt IN ("Wien")
)
Fragestellung: Zeige alle Orte und je Ort als Spalte die Anzahl Firmen, deren Betreuer Müller ist und als weitere Spalte die Anzahl Firmen, deren Betreuer Meier ist.
Beispiel :
SELECT Firmen. Ort,
,. FirmenMitParametern ( Betreuer="Müller", CountResults ) AS AnzMueller,
FirmenMitParametern ( Betreuer="Meier", CountResults ) AS AnzMeier FROM Firmen
GROUP BY FirmenOrt
In diesem Fall wird erkannt, dass in den tabellenübergeordneten Wertefeldem jeweils eine Aggregatsfunktion verwendet wird, und im angegebenen SQL-Statement ein GROUP BY angewandt wird. Entsprechend wird in der einzigen Hierarchiestufe des angegebenen Statements als Tabelle die aggregierte Menge FirmenOrt herangezogen. Diese wird nun mit sämtlichen im Ergebnis der beiden verwendeten tabellenübergeordneten Wertefelder vorhandenen Tabellen, im konkreten mit der Tabelle Firmen, verglichen. Es wird festgestellt, dass die Tabelle Firmen nicht in der einzigen Hierarchiestufe des angegebenen Statements vorhanden ist und demnach werden automatisch zwei SUB-SELECTs angelegt, welche jeweils eine Verbindung zu der ihnen übergeordneten Hierarchiestufe über das Tabellenfeld Firmen.Ort aufweisen. Wird ein SUB-SELECT automatisch eingefügt, können sämtliche in diesem SUB-SELECT verwendeten Tabellen mittels AS-Parameter den Namen „Sub__" plus den Tabellennamen bekommen. Somit ist eine Unterscheidung zwischen den Tabellen der Hierarchiestufen und den Tabellen der SUB-SELECTs gewährleistet.
Somit wird dieses Statement automatisch umgewandelt in:
SELECT FirmenOrt, ( SELECT Count (Distinct Sub_Firmen.FirmaID) FROM Firmen AS Sub_Firmen WHERE Sub_Firmen.Betreuer IN („Müller") AND (Sub_Firmen.Ort=Firmen.Ort) ) AS AnzMueller,
( SELECT Count (Distinct Sub_Firmen.FirmaID) FROM Firmen AS SubJFirmen WHERE Sub_Firmen.Betreuer IN („Meier") AND (Sub__Firmen.Ort=Firmen.Ort) ) AS AnzMeier
FROM Firmen GROUP BY Firmen.Ort
Die kürzeste Schreibweise für dieses Statement würde mit der Verwendung von tabellenübergeordneten Wertefeldern folgendermaßen lauten:
SELECT Firmen.Ort,
FirmenMitParametern ( Betreuer="Müller", CountResults ) AS AnzMueller, FirmenMitParametern ( Betreuer="Meier", CountResults ) AS AnzMeier
Wie im oberen Bereich der Beschreibung erwähnt, kann die Notwendigkeit des Verarbeitungsbereichs FROM für die Tabelle Firmen und des Verarbeitungsbereichs GROUP BY für das Tabellenfeld Firmen.Ort mittels eines einfachen Algorithmus erkannt und entsprechend automatisch angefügt werden.
Mittels einer Erweiterung des zugrunde liegenden RTN, welches dem RTN von SQL entspricht, kann die Verwendung der tabellenübergeordneten Wertefelder noch ausgebaut werden.
Dies geschieht dadurch, dass im RTN von SQL der Produktbildungs- Verarbeitungsbereich, der die in der jeweiligen Hierarchiestufe zu verwendenden Datentabellen enthält und die Bildung eines kartesischen Produktes für dieselben beschreibt, nur als optionaler Entscheidungspfad definiert ist, und in jenen Fällen, in denen dieser Produktbildungs- Verarbeitungsbereich im Anwender- SQL-Statement nicht angegeben ist, dieser in einem späteren Schritt automatisch erstellt wird und, beispielsweise mittels einer Tabelle der Relationen, sämtliche zur Auflösung des Anwender-SQL-Statements benötigten Datentabellen ermittelt in diesem Verarbeitungsbereich und eingefügt werden,
und die relationenbezogenen Operationen, welche zwischen den eingefügten Datentabellen unter der Berücksichtigung der Hierarchiestufe vorhanden sind, automatisch in den Kriterien- Verarbeitungsbereich (WHERE) des Übergangs-SQL-Statement und somit auch in das endgültigen SQL-Statements eingefügt werden.
Um dies zu zeigen, wird nur ein einfaches Anwender-SQL-Statement erstellt, für welches der Statement- Auflösungsschritt und die der Vervollständigungsschritt nicht gezeigt wird:
SELECT Abteilungen.*, Abteilungen.AnzaHKontaktpersonen() WHERE Firmen.PLZ=1010
Ebenso kann das SQL-RTN erweitert werden, dass jene Entscheidungspositionen im RTN von SQL, an welchen ein Tabellenname unabhängig von den Verarbeitungsbereichen angegeben werden kann, derart erweitert werden, dass anstatt eines Tabellennamens ein tabellenübergeordnetes Wertefeld an diesen Entscheidungspositionen zugelassen wird, wobei auf ein tabellenübergeordnetes Wertefeld nicht zwingend weitere Entscheidungspositionen folgen müssen, und die von dieser RTN-Erweiterung betroffenen Anwender-SQL-Statements im Auflösungs-Schritt zuerst in ein Übergangs-SQL-Statement und nachfolgend in ein endgültiges SQL-Statement umgewandelt werden
Folgendes einfaches Anwender-SQL- Statement zeigt zwei tabellenübergeordnete Wertefelder, welche jeweils an einer Entscheidungsposition im Anwender-SQL-Statement angegeben sind, an der ebenfalls ein Datentabellenname zulässig ist:
SELECT Firmen.*, UmsatzO FROM FirmenAusWienO Das SQL-RTN kann auch dadurch erweitert werden, dass jene Entscheidungspositionen im
RTN von SQL, an welchen ein Tabellenfeldname unabhängig von den Verarbeitungsbereichen angegeben werden kann, derart erweitert werden, dass anstatt eines
Tabellenfeldnamens ein tabellenübergeordnetes Wertefeld an diesen Entscheidungspositionen zugelassen wird, wobei auf das tabellenübergeordnete Wertefeld nicht zwingend weitere
Entscheidungspositionen folgen müssen, und die von dieser RTN-Erweiterung betroffenen
Anwender-SQL-Statements im Auflösungs-Schritt zuerst in ein Übergangs-SQL-Statement und nachfolgend in ein endgültiges SQL-Statement umgewandelt werden und
wobei das tabellenübergeordnete Wertefeld im Statement-Auflösungsschritt in einer, der dieses tabellenübergeordnete Wertefeld enthaltenden, direkt untergeordneten Hierarchiestufe, eingefügt wird.
Das Anwender-SQL-Statement zeigt zwei tabellenübergeordnete Wertefelder, welche an Entscheidungspositionen im SQL-RTN eingesetzt sind, an welcher ebenfalls ein Tabellenfeldname zulässig ist.
SELECT Firmen.Name, Abteilungen.Abteilungsname, Abteilungen.Umsatz() ORDER BY Firmen.Umsatz()
Dieses Anwender-SQL-Statement liefert den Firmennamen, den Abteilungsnamen und den Umsatz je Abteilung, wobei die Ergebnisse nach dem Firmenumsatz sortiert sind.
Weiters kann das SQL-RTN kann auch dadurch erweitert werden, dass jene Entscheidungspositionen im RTN von SQL, an welchen ein Tabellenname unabhängig von den Verarbeitungsbereichen angegeben werden kann, derart erweitert werden, dass auf diese Tabellennamen optional ein Verbindungszeichen, vorzugsweise ein Punkt, gefolgt von einer Tabelle, einem Tabellenfeld, einem tabellenübergeordneten Wertefeld, einer Vergleichsoperation, oder einer Aggregatsfunktion zugelassen wird.
Nachfolgendes Beispiel zeigt an Anwender-SQL-Statement, in welchem auf eine Tabellen- Entscheidungsposition jeweils einmal eine Aggregatsfunktion, ein Tabellenname mit einer nachfolgenden Aggregatsfunktion und ein Tabellenname mit einem tabellenübergeordneten Wertefeld folgen.
SELECT Firmen.Count, Firrnen.Abteilungen.Count,
Firmen.AnzahlKontaktpersonenO FROM Firmen.PLZ
Dieses Anwender-SQL-Statement wird im nachfolgenden Statement-Analyseschritt und danach im Vervollständigungsschritt in dieses endgültige SQL-Statement umgewandet:
SELECT Firmen.PLZ, Count(Distinct Firmen. FirmalD) AS Count_Firmen, Count (Distinct Abteilungen. AbteilungID) AS Count_Abteilungen, Count (Distinct Kontaktpersonen.KontaktpersonID) AS AnzahlKontaktpersonen FROM Firmen, Abteilungen, Kontaktpersonen
WHERE (Firmen.FirmaID=Abteilungen.FirmaNr)
AND (Abteilungen.AbteilungID=Kontaktpersonen.AbteilungNr)
GROUP BY Firmen.PLZ
Gemäß einer weiteren Variante des erfindungsgemäßen Verfahrens kann das SQL-RTN auch dadurch erweitert werden, dass jene Entscheidungspositionen im RTN von SQL, an welchen ein Tabellenfeldname unabhängig von den Verarbeitungsbereichen angegeben werden kann, derart erweitert werden, dass auf diese Tabellenfeldnamen optional ein Verbindungszeichen, vorzugsweise ein Punkt, gefolgt von einer Tabelle, einem Tabellenfeld, einem tabellenübergeordneten Wertefeld, einer Vergleichsoperation oder einer Aggregatsfunktion zugelassen wird.
Im nachfolgenden Anwender-SQL-Statement folgt der Entscheidungsposition Tabellenfeld „PLZ" jeweils eine Aggregatsfunktion, ein tabellenübergeordnetes Wertefeld und eine Tabelle, aufweiche eine Aggregatsfunktion folgt.
SELECT Firmen.PLZ.Count,
AVG ( Firmen.PLZ.AnzahlKontaktpersonen() ), AVG (Firmen.PLZ.Abteilungen.Count)
Im Statement-Auflösungsschritt und im nachfolgenden Vervollständigungsschritt wird folgendes endgültiges SQL-Statement automatisch erzeugt:
SELECT Count (Distinct Firmen.PLZ) AS Count_Firmen_PLZ, AVG (Firmen_PLZ_AnzahlKontaktpersonen) AS
AVG_Firmen_PLZ_AnzahlKontaktpersonen, AVG (Count_Firmen_PLZ_Abteilungen) AS
AVG_Count_Firmen_PLZ_Abteilungen FROM (
SELECT Firmen.PLZ
( SELECT Count (Distinct Kontaktpersonen.KontaktpersonID) FROM Firmen, Abteilungen, Kontaktpersonen
WHERE Firmen.FirmaID=Abteilungen.FirmaNr AND Abteilungen.AbteilungID=Kontaktpersonen.AbteilungNr ) AS Firmen_PLZ_AnzahlKontaktpersonen, ( SELECT Count (Distinct Abteilungen. AbteilungID) FROM Firmen, Abteilungen
WHERE Firmen.FirmaID=Abteilungen.FirmaNr ) AS Count_Firmen_PLZ_Abteilungen FROM Firmen
)
Gemäß einer weiteren Variante des erfindungsgemäßen Verfahrens kann das SQL-RTN auch dadurch erweitert werden, dass jene Entscheidungspositionen, an welchen ein tabellenübergeordnetes Wertefeld unabhängig von den Verarbeitungsbereichen angegeben werden kann, derart erweitert, dass auf diese tabellenübergeordneten Wertefelder optional ein Verbindungszeichen, vorzugsweise ein Punkt, gefolgt von einer Tabelle, einem Tabellenfeld, einem tabellenübergeordneten Wertefeld, einer Vergleichsoperation oder einer Aggregatsfunktion zugelassen wird,
wobei nachfolgenden Vergleichsoperationen als zusätzliche Parameter für das jeweilige tabellenübergeordnete Wertefeld angenommen werden, und wobei sämtliche anderen mit dieser Entscheidungsposition in Verbindung stehenden Entscheidungspositionen mit dem Statement- Auflösungsschritt verarbeitet werden.
Ein Beispiel soll die sich dadurch neu ergebenden Möglichkeiten bei der Formulierung eines Anwender-SQL-Statements zeigen: In diesem Beispiel folgt beide Male eine Vergleichsoperation aus die beiden tabellenübergeordneten Wertefelder. Dem entsprechend werden diese im Statement-Auflösungsschritt als weitere Parameter der tabellenübergeordneten Wertefelder herangezogen und entsprechend aufgelöst.
SELECT Firmen.*
WHERE FirmenAusWien().AnzMitarbeiter>5
AND AnzahlKontaktρersonen().Nachname="Müller">l 0
Folgendes endgültiges SQL-Statement wird automatisch nach dem Auflösungsschritt und dem Vervollständigungsschritt erzeugt:
SELECT Firmen.* FROM Firmen WHERE Firmen.PLZ IN (
SELECT Ort_PLZ.PLZ FROM Ort_PLZ WHERE Ort_PLZ.Ort="Wien") AND Firmen.AnzMitarbeiter>5 AND ( SELECT Count (Distinct Kontaktpersonen.KontaktpersonID ) FROM Abteilungen, Kontaktpersonen WHERE Firmen.FirmaID=Abteilungen.FirmaNr
AND Abteilungen.AbteilungID=Kontaktpersonen.AbteilungNr AND Kontaktpersonen.Nachname="Müller" ) > 10
Ausgehend von diesem erweiterten RTN können folgende Fragestellung einfach formuliert werden: Alle Finnen, aus Orten in denen es mehr als 100 Firmen gibt:
SELECT Firmen.* FROM Firmen
WHERE Firmen.Ort.AnzahlFirmen()>100
Über die Analyse vermittels des erweiterten RTN kann erkannt werden, dass die Anfrage endgültig folgendermaßen automatisch als endgültiges SQL-Statement formuliert werden soll:
SELECT Firmen.* FROM ( SELECT Firmen.Ort FROM Firmen GROUP BY FirmenOrt HAVING Count (Distinct Firmen.FirmalD) > 100)
AS Firmen_Ort, Firmen WHERE (Firmen.Ort=Firmen_Ort.Ort)
Eine gleichwertige, ebenfalls automatische Umwandlungsmöglichkeit für dieses Anwender- SQl-Statement ist das folgende endgültige Anwender-SQL-Statement:
SELECT Firmen.* FROM Firmen WHERE (FirmenOrt IN
( SELECT FirmenOrt FROM Firmen GROUP BY FirmenOrt
HAVING Count (Distinct Firmen.FirmaID)>100) )
Die Erzeugung eines derartigen SQL-Statements aus dem angegebenen SQL-Statement in dem weiter oben gezeigten Beispiel kann auf mehrere Arten erfolgen und ist für den Fachmann ohne weiters möglich, weswegen hier auf einen konkreten, einfachen Algorithmus verzichtet wird.
Eine weitere Fragestellung soll das automatische Anfügen eines neuen Verarbeitungsbereiches unter Verwendung des erweiterten SQL-RTNs zeigen:
Alle Firmen, deren Betreuer Müller heißt:
Beispiel:
SELECT FirmenMitParametern ( Betreuer="Müller").*
Es wird mittels eines einfachen Algorithmus erkannt, dass alle Firmen, deren Betreuer „Müller" ist, ausgegeben werden sollen, weshalb automatisch ein WHERE- Verarbeitungsbereich eingefügt wird.
Somit lautet das automatisch umgewandelte Statement wie folgt:
SELECT Firmen.* FROM Firmen
WEHRE Firmen.Betreuer IN („Müller")
In der Praxis wird in einer relationalen Datenbank, welche den Codd' sehen Normalformen folgt, das Tabellenfeld Betreuer in der Tabelle Firmen nicht als Text-Feld sondern als Zahlenfeld enthalten sein und eine Relation zu einer eigenen Tabelle, so zum Beispiel der Tabelle Mitarbeiter, enthalten.
So wird das Textfeld Betreuer in der Tabelle Firmen beispielsweise in das Zahlenfeld BetreuerNr umgewandelt und es wird eine weitere Tabelle Mitarbeiter (Mitarbeitern), Nachname, Vorname, ...) angelegt, welche folgende Relation zu der Tabelle Firmen enthält:
Mitarbeiter (Mitarbeiterin) -> Firmen(BetreuerNr) Dieser Sachverhalt lässt sich, besonders nach dem die Datenstruktur verändert bzw. erweitert wird und somit eine Mehrzahl von bereits erstellten SQL-Statements betroffen ist, vermittels eines weiteren tabellenübergeordneten Wertefeldes einfach darstellen:
Define ConnectionField FirmenBetreutVon ( Betreuer ) WHERE Firmen.BetreuerNr IN ( SELECT MitarbeiterID WHERE Nachname IN (Param: Betreuer )
) End Define
Es ist auch möglich, ein tabellenübergeordnetes Wertefeld Firmen.Betreuer zu erstellen, welches nur einen Entscheidungspfad mit nur einer Entscheidungsposition in seinem inneren, gerichteten Entscheidungsgraphen enthält:
Define ConnectionField Firmen.Betreuer() SELECT Mitarbeiter .Nachname WHERE Mitarbeiter.MitarbeiterID =Firmen.BetreuerNr
End Define
Somit kann folgende Fragestellung analysiert und umgewandelt werden:
Alle Kontaktpersonen jener Firmen, deren Betreuer entweder Müller oder Meier sind:
Beispiel :
SELECT Kontaktpersonen.*
WHERE Firmen.Betreuer IN („Müller","Meier")
Im Statement-Auflösungsschritt wird dieses Anwender-SQL-Statement umgewandelt in:
SELECT Kontaktpersonen.* WHERE (
SELECT Mitarbeiter.Nachname
WHERE Mitarbeiter.MitarbeiterID=Firmen.BetreuerNr ) IN („Müller'Y'Meier")
In einem nächsten Vervollständigungsschritt wird dieses automatisch erzeugte SQL- Statement um die relationenbezogenen Operationen erweitern, wie es weiter unten in der Anmeldung gezeigt wird. Somit ergibt sich für die aktuell zugrunde liegende Datenstruktur folgendes endgültiges SQL-Statement:
SELECT Kontaktpersonen.* FROM Firmen, Abteilungen, Kontaktpersonen WHERE (
SELECT Mitarbeiter.Nachname FROM Mitarbeiter
WHERE Mitarbeiter.MitarbeiterID=Firmen.BetreuerNr ) IN („Müller'Y'Meier") AND (Firmen.FirmaID=Abteilungen.FirmaNr)
AND (Abteilungen.AbteilungID=Kontaktpersonen.AbteilungNr)
Es kann auch ein tabellenübergeordnetes Wertefeld Mitarbeiter_GetIDOfName() mit dem Parameter „Nachname" erstellt werden, welches als Entscheidungsposition im tabellenübergeordneten Wertefeld FirmenBetreutVon() verwendet wird:
Define ConnectionField Mitarbeiter_GetIDOfName (Nachname) SELECT Mitarbeiter.MitarbeiterID
WHERE Mitarbeiter.Nachname IN (Param: Nachname ) ) End Define
Define ConnectionField FirmenBetreutVon ( Betreuer ) Firmen.BetreuerNr IN ( Mitarbeiter_GetIDOfName (Param:Betreuer ) )
End Defme
Es kann auch ein tabellenübergeordnetes Wertefeld Firmen.Betreuer erstellt werden, womit keine Veränderung an bereits erstellten SQL-Statements vorgenommen werden muss: Define ConnectionField Firmen.Betreuer() SELECT Mitarbeiter .Nachname WHERE Mitarbeiter.MitarbeitβrID=Firmen.BetreuerNr End Define
Sollen nun alle Firmen und deren Betreuer gezeigt werden, kann dies mittels folgender Formulierung abgefragt werden:
Beispiel:
SELECT Firmen.Firmenname, Firmen.Betreuer
Dieses von einem Anwender angegebene Statement wird nach dem Statement- Auflösungsschritt und der Vervollständigung von fehlenden relationenbezogenen Operationen beispielsweise nach unten gezeigten Verfahren über eine Tabelle der Relationen automatisch in das folgende Statement umgewandelt:
SELECT Firmen.Firrnenname,
( SELECT Mitarbeiter.Nachname FROM Mitarbeiter
WHERE Mitarbeiter.MitarbeiterID=Firmen.BetreuerNr) AS Firmen.Betreuer FROM Firmen
Ist im SELECT- Verarbeitungsbereich ein „*" angegeben, also eine Information, welche besagt, dass alle Tabellenfelder einer bestimmten Tabelle angezeigt werden sollen, wird definiert, dass alle tabellenübergeordneten Wertefelder, welche den Namen dieser Tabelle gefolgt von einem Punkt und einem Tabellenfeldnamen enthalten, ebenfalls in diese *- Position aufgenommen werden:
Um dies zu zeigen, wird ein weiteres tabellenübergeordnetes Wertefeld angelegt:
Define ConnectionField Firmen. AnzahlKontaktpersonen() Count (Distinct Kontaktpersonen.KontaktpersonID) End Define
Somit wird folgendes, von einem Anwender angegebenes Statement, dessen automatische Umwandlung in einen endgültigen SQL-Code nicht gezeigt wird, in folgendes Statement übergeführt:
Beispiel:
SELECT Firmen.* FROM Firmen
Wird automatisch übergeführt in und von dieser Basis aus weiter analysiert:
SELECT Firmen.FirmaID, Firmen.Name, Firmen. Strasse, Firmen.PLZ, Firmen.Land, Firmen.AnzahlMitarbeiter, Firmen.Betreuer, Firmen.AnzahlKontaktpersonen FROM Finnen
Ebenso lassen sich alle Kontaktpersonen, deren Firmen von den Mitarbeitern Müller und Meier betreuet werden, wie folgt ermitteln:
Beispiel:
SELECT Kontaktpersonen.*
WHERE FirmenBetreutVon („Müller,Meier")
Dieses Statement ergibt nach der erfindungsgemäßen Analyse und Umwandlung folgendes endgültiges Statement, welches dem ident oben einem bereits oben gezeigten, endgültigen Statement ist:
SELECT Firmen.* FROM Firmen, Abteilungen, Kontaktpersonen WHERE Firmen.BetreuerNr DSf (
SELECT Mitarbeitern)
FROM Mitarbeiter
WHERE Nachname IN („Müller'Y'Meier") )
AND (Fiπnen.FiπnaID=Abteilungen.FirmaNr) AND (Abteilungen.AbteilungID=Kontaktpersonen.AbteilungNr)
Ahnliches kann für das Feld Ort gelten, wenn davon ausgegangen wird, dass das Feld Ort in einer eigenen Tabelle, beispielsweise in der Tabelle Ort_PLZ, steht, in welcher aller PLZ's und die zugehörigen Orte stehen:
Define ConnectionField Firmen_GetPLZsOfOrt( OfOrt ) SELECT Ort_PLZ.PLZ WHERE OrtJPLZ.Ort IN ( Param:OfOrt ) End Define
In diesem Zusammenhang wird auch ein weiteres tabellenübergeordnetes Wertefeld erstellt:
Define ConnectionField Firmen_GetOrtOfPLZ( OfPLZ ) SELECT Ort_PLZ.Ort WHERE Ort_PLZ .PLZ IN ( ParamOfPLZ ) End Define
Um keine Umformulierung von vorhanden S QL- Statements aufgrund der geänderten Datenstruktur vornehmen zu müssen, kann ein zusätzliches tabellenübergeordnetes Wertefeld Firmen.Ort erstellt werden, welches and seiner einzigen Entscheidungsposition seines inneren, gerichteten Entscheidungsgraphen das tabellenübergeordnete Wertefeld GetOrtOfPLZ() aufruft und als Parameter die PLZ der jeweils aktuellen Firma übergibt:
Define ConnectionField Firmen. Ort()
GetOrtOfPLZ (Firmen.PLZ) End Define
Somit kann der innere, gerichtete Entscheidungsgraph des tabellenübergeordneten Wertefeldes FirmenMitParametern() folgendermaßen umgeändert werden, ohne bereits vorhandene SQL-Statements, die dieses tabellenübergeordnete Wertefeld in zumindest einem ihrer Verarbeitungsbereiche verwenden, verändern zu müssen:
Defme ConnectionField FirmenMitParametern( Betreuer, Ort, PLZ, CountResults ) IF ParamrBetreuer THEN FirmenBetreutVon (Param:Betreuer)
IF Param:Ort THEN Firmen.PLZ IN Firmen_GetPLZsOfOrt ( Param:Ort ) IF Param:PLZ THEN Firmen.PLZ IN (ParanrPLZ) IF Param:CountResults THEN
SELECT Count (Distinct Firmen.FirmalD) ELSE
SELECT Firmen.* END IF End Defme
Dem zufolge ergibt das folgende SQL-Statement, welches vorstehend in der Beschreibung bereits als Beispiel angegeben wurde, folgendes endgültiges SQL-Statement:
Beispiel : SELECT FirmenOrt,
FirmenMitParametern ( Betreuer="Müller", CountResults ) AS AnzMueller, FirmenMitParametern ( Betreuer="Meier", CountResults ) AS AnzMeier
Dieses Statement wird automatisch aufgrund der vorhandenen tabellenübergeordneten Wertefelder in einem Statement-Auflösungsschritt und nach der Vervollständigung der fehlenden relationenbezogenen Operationen umgewandelt in:
SELECT
( SELECT Count (Distinct Firmen.FirmaID) FROM Firmen WHERE Firmen.BetreuerNr IN
(SELECT MitarbeiterID FROM Mitarbeiter WHERE Nachname IN („Müller")) AS AnzMueller,
( SELECT Count(Distinct Firmen.FirmalD) FROM Firmen WHERE Firmen.BetreuerNr IN (SELECT Mitarbeitern) FROM Mitarbeiter WHERE Nachname IN („Meier")) AS AnzMeier, FROM Firmen
GROUP BY ( SELECT OrtJPLZ.Ort FROM Ort_PLZ
WHERE (Ort_PLZ.PLZ IN ( Firmen.PLZ ) )
Gleichwertig kann der innere, gerichtete Entscheidungsgraph des tabellenübergeordneten Wertefeldes Firmen. Ort folgende einzige Entscheidungsposition in seinem einzigen Entscheidungspfad aufweisen:
Define ConnectionField Firmen. Ort()
SELECT Ort_PLZ.Ort WHERE (Ort_PLZ.PLZ = Firmen. PLZ)
End Define
Wie bereits beschrieben, sind tabellenübergeordnete Wertefelder allen in einer Datenstruktur vorhandenen Tabellen übergeordnet. Dies bedeutet, dass sämtliche Tabellen und sämtliche Mengen auf jedes tabellenübergeordnete Wertefeld aus der Gesamtheit der tabellenübergeordneten Wertefelder zugreifen und in SQL-Statements verwenden können.
Um dies konkret mit einem einfachen Beispiel zu zeigen, wird folgendes tabellenübergeordnetes Wertefeld erstellt:
Define ConnectionField AnzahlVeranstaltungen(Zeitraum, Betreuer,AktVeranstaltungStatus) IF Param:Zeitraum THEN Veranstaltungen. V ADatum=Param:Zeitraum IF Param:Betreuer THEN Firmen.Betreuer IN (Param:Betreuer) IF Param:AktVeranstaltungStatus THEN
Last(ZustatzStatiArten.Bezeichnung)=Param:AktVeranstaltungStatus END IF
Count (Distinct Veranstaltungen.VeranstaltungID) End Define Somit ist die Angabe des folgenden Statements durch einen Anwender möglich, welches die Frage beantwortet, auf wie vielen unterschiedlichen Veranstaltungen um Jahr 2006 ein jeweiliger Artikel verkauft wurde:
SELECT Artikel.*, AnzahlVeranstaltungen(Zeitraum=2006)
Wie bereits beschrieben, stellt ein Algorithmus fest, dass in der Hierarchiestufe des Verarbeitungsbereichs, in welchem das tabellenübergeordnete Wertefeld verwendet wird, die einzig die Tabelle Artikel angegeben ist. Das tabellenübergeordnete Wertefeld liefert in seinem Ergebnis eine Verarbeitungsinformation, welche sich auf die Tabelle Veranstaltungen bezieht, zurück. Demnach wird das tabellenübergeordnete Wertefeld also beispielsweise als SUB-SELECT eingefügt:
Somit wird dieses von einem Anwender erstellte Statement in einem Statement- Auflösungsschritt in folgendes Statement umgewandelt in:
SELECT Artikel.*,
( SELECT Count (Distinct Veranstaltungen. VeranstaltungID) WHERE Veranstaltungen. VADatum BETWEEN #01.01.2006# AND #31.12.2006#
)
AS AnzahlVeranstaltungen
Im Statement-Auflösungsschritt kann erkannt werden, dass der Parameter Zeitraum den Wert 2006 enthält und dass dieser Wert kein Datum sondern ein Jahr darstellt. Entsprechend die Entscheidungsposition Veranstaltungen. VADatum=2006 umgewandelt werden in Veranstatlungen. V ADatum BETWEEN #01.01.2006# AND #31.12.2006# in diesen Wert als Teil des Ergebnisses des Durchlaufes von AnzahlVeranstaltungen liefern.
Ein einfacher Algorithmus kann erkennen, dass relationenbezogene Operationen zwischen der Tabelle Artikel und der Tabelle Veranstaltungen fehlen. Diese können mithilfe einer Tabelle der Relationen in einem neuen Statement eingefügt werden, womit sich folgendes endgültiges Statement ergibt: SELECT Artikel.*,
( SELECT Count (Distinct Veranstaltungen. VeranstaltungID) FROM Rechnungspositionen, Rechnungen, Veranstaltungen WHERE Artikel.ArtikellD^Rechnungspositionen.ArtikelNr AND Rechnungspositionen.RechnungNr=rRechnungen.RechnungID
AND Veranstaltungen.RechnungNr^Rechnungen.RechnunglD AND Veranstaltungen. VADatum BETWEEN
#01.01.2006# AND #31.12.2006# ) AS AnzahlVeranstaltungen FROM Artikel
Ebenso kann auch das folgende Statement einfach von einem Anwender formuliert werden, um folgende Frage zu stellen:
SELECT Artikel.*,
AnzahlVeranstaltungen(Zeitraum=2006,Betreuer="Müller") AS Müller2006 AnzahlVeranstaltungen(Zeitraum=2005,Betreuer="Müller") AS Müller2005
Nach dem Statement- Auflösungsschritt ergibt sich automatisch das folgende Statement:
SELECT Artikel.*,
( SELECT Count (Distinct Veranstaltungen. VeranstaltungID) WHERE Veranstaltungen. VADatum BETWEEN #01.01.2006# AND #31.12.2006# AND ( SELECT Mitarbeiter.Nachname WHERE Mitarbeiter.MitarbeiterID =Firmen.BetreuerNr )
= „Müller" )
)
AS Müller2006,
( SELECT Count (Distinct Veranstaltungen. VeranstaltungID) WHERE Veranstaltungen. VADatum BETWEEN #01.01.2005# AND #31.12.2005#
AND ( SELECT Mitarbeiter.Nachname
WHERE Mitarbeiter.MitarbeiterID =Firmen.BetreuerNr ) = „Müller" ) ) AS Müller2005
Der nun nachfolgende Schritt, in welchem festgestellt wird, dass in diesem automatisch erzeugten Statement die relationenbezogenen Operationen unvollständig sind, vervollständigt dieses Beispiel um die relationenbezogenen Operationen nach dem unten gezeigten Verfahren. Das endgültige Statement wird aufgrund seiner immensen Länge nicht gezeigt. Es wird nur der erste Analyse-Schritt gezeigt, in welchem der Algorithmus erkennt, dass in der ersten Hierarchiestufe die Tabelle Artikel verwendet wird und in der jeweils zweiten und dritten Hierarchiestufe (die beiden SUB-SELECTS Müller 2006 und Müller2005) die Tabellen Veranstaltungen, Mitarbeiter und Firmen vorhanden sind. Die relationalen Verbindungen zwischen diesen Tabellen werden automatisch unter Berücksichtigung der jeweiligen Hierarchiestufen mittels des unten gezeigten Verfahrens eingefugt, womit ein endgültiges, von einer SQL-Engine analysierbares, optimierbares und verarbeitbares SQL- Statement automatisch zur Verfügung gestellt wird.
Ein Anfrage-SQL-Statement, welches die Datentabelle Kontaktpersonen als tabellenübergeordnetes Wertefeld mit dem Parameter Nachname="Müller" und dem gewünschten Ergebnis die Verarbemmgsfunktion Count liefert ist folgendes:
SELECT Firmen.Firmenname, Firmen.Kontaktpersonen.Nachname="Müller".Count
Dieses Anwender-SQL-Satement wird mittels des Auflösungsschritts und des Vervollständigungsschrittes in folgendes endgültiges SQL-Statement umgewandelt:
SELECT Firmen.Firmenname, Firmen.Kontaktpersonen.Count
SELECT Firmen.Firmenname, (SELECT Count(*) FROM Kontaktpersonen) FROM Firmen
Weitere Beispiele, welche tabellenübergeordnete Wertefelder in komplexen Kombinationen enthalten:
Alle Firmen aus Orten, in denen es mehr als 100 Firmen gibt und alle Firmen, in deren PLZ es mehr als 10 Firmen gibt. Dieses Statement kann vermittels des erweiterten SQL-RTN folgendermaßen einfach angegeben und automatisch aufgelöst und in ein gültiges SQL-Statement nach dem Stand der Technik umgewandelt werden:
Beispiel:
SELECT Firmen.*
WHERE (Firmen.Ort.AnzahlFirmen()>100) OR (Firmen.PLZ.AnzahlFirmen()>10)
Im Statement-Auflösungsschritt wird folgendes Statement ohne relationenbezogene Operationen automatisch generiert:
SELECT Firmen.* WHERE ( (Firmen.PLZ IN (
SELECT Ort_PLZ WHERE Ort_PLZ.Ort IN (
SELECT Sub_Ort_PLZ.Ort WHERE Sub_Firmen.PLZ=Sub_Ort_PLZ.PLZ GROUP BY Sub_Ort_PLZ.Ort HAVING Count(*) > 100 )
)
OR (Firmen.PLZ IN (
SELECT Sub_Firmen.PLZ
GROUP BY Sub_Firmen.PLZ HAVING Count(*) > 10
)
Dieses Statement wird in einem nachfolgenden Schritt um die fehlenden relationenbezogenen Operationen automatisch zum Beispiels vermittels einer Tabelle der Relationen und nach dem unten gezeigten Verfahren automatisch ergänzt, wodurch sich dieses neue, endgültige SQL- Statement ergibt:
SELECT Firmen.* FROM Firmen WHERE ( (Firmen.PLZ IN ( SELECT Ort_PLZ FROM Ort_PLZ WHERE Ort_PLZ.Ort IN (
SELECT Sub_Ort_PLZ.Ort FROM Firmen AS Sub_Firmen, Ort__PLZ AS Sub_Ort_PLZ
WHERE Sub_Firmen.PLZ=Sub_Ort_PLZ.PLZ
GROUP BY Sub_Ort_PLZ.Ort
HAVING Count(*) > 100
) )
OR (Firmen.PLZ IN (
SELECT Sub_Firmen.PLZ FROM Firmen AS SubJFirmen GROUP BY Sub_Firmen.PLZ HAVING Count(*) > 10
)
Der Algorithmus, welcher die relationenbezogenen Operationen unter Berücksichtigung der Hierarchiestufen und der Tabelle der Relationen automatisch in einem neuen, endgültigen SQL-Statement einfügt, bekommt durch die Information „Sub_" & Tabellenname die
Information mitgeliefert, dass diese Tabelle, obwohl sie in der übergeordneten Hierarchiestufe bereits verwendet wird, keine Relationen zu der übergeordneten Hierarchiestufe herstellen darf.
Eine weitere Anwendungsform der erfindungsgemäßen tabellenübergeordneten Wertefelder mittels des erweiterten SQL-RTN ist, Tabellen, welche beispielsweise mittels eines Punkt auf eine Tabelle oder ein Tabellenfeld folgen, als tabellenübergeordneten Wertefeld zu abstrahieren und dieses entsprechend in einem Statement-Auflösungsschritt umzuwandeln:
Um dies anhand von Beispielen zu verdeutlichen, wird ein weiteres tabellenübergeordnetes Wertefeld definiert und somit der Gesamtheit der tabellenübergeordneten Wertefelder hinzugefügt:
Define ConnectionField Umsatz(Zeitraum, Verkaeufer, Netto) IF Param:Zetiraum THEN
Veranstaltungen. VADatum = Param:Zeitraum END IF
IF Param:Verkaeufer THEN Firmen.Betreuer IN (Param: Verkaeufer)
END IF IF ParamNetto THEN
SUM (Rechnungspositionen.Betrag) ELSE SUM (Rechnungspositionen.Betrag* Artikel.MwSt)
END IF End Define
Hiermit ist die folgende Fragestellung einfach zu beschreiben: Alle Firmen, deren Umsatz je Kontaktperson im Jahr 2006 mehr als 1000 Euro betragen hat.
Beispiel:
SELECT Firmen.*
WHERE ALL Firmen.Kontaktpersonen.Umsatz(Zeitraum=2006) > 1000
Dieses Statement kann mittels eines einfachen Algorithmus in einem Statement-Auflösungs- Teilschritt, welcher gezeigt wird, um die Übersicht zu wahren und den Focus auf das wesentliche zu richten, umgewandelt werden in:
SELECT Firmen.*
WHERE ( SELECT Count(Kontaktpersonen.KontaktρersonΙD) )
( SELECT Count (Kontaktpersonen.KontaktpersonID) WHERE Umsatz(Zeitraum=2006)>l 000
)
Ausgehend von diesem Statement wird der Statement- Auflösungsschritt weiter angewandet, wodurch sich ein endgültig verarbeitbares SQL-Statement nach dem Stand der Technik ergibt. Dieser Statement-Auflösungsschritt sowie der nachfolgende Schritt, in welchem die relationenbezogenen Operationen in einem neuen Statement eingefugt werden, wurde bereits vielfach gezeigt und wird daher an dieser Stelle nicht mehr ausgeführt.
Äquivalent können auch alle Firmen gezeigt werden, bei welchen zumindest eine Kontaktperson einen Umsatz von mehr als 1000 Euro im Jahr 2006 erzielt wurde:
Beispiel: SELECT Firmen.*
WHERE ANY Firmen.Kontaktpersonen.Umsatz(Zeitraum=2006) > 1000
Dieses Statement wird in einem Statement-Teilauflösungsschritt automatisch umgewandelt in: SELECT Firmen.* WHERE
( SELECT Count (Kontaktpersonen.KontaktpersonlD) WHERE Umsatz(Zeitraum=2006)>1000
) > 1
Dem gleichen Prinzip folgend kann auch eine Fragestellung, die alle Firmen, in denen zumindest zwei Kontaktpersonen oder alle bis auf zumindest eine Kontaktperson im Jahr 2006 einen Umsatz von mindestens 1000 Euro erreicht haben, zeigen soll, einfach von einem Anwender formuliert werden:
Beispiel :
SELECT Firmen.*
WHERE ANY (>=2) Firmen.Kontaktρersonen.Umsatz(Zeitraum=2006) > 1000
Beispiel: SELECT Firmen.*
WHERE ALL (<1) Firmen.Kontaktpersonen.Umsatz(Zeitraum=2006) > 1000 Nachfolgendes Beispiel liefert die Anzahl Kontaktpersonen je Ort, indem die Datentabellen Kontaktpersonen als tabellenübergeordnetes Wertefeld für das aggregierte Tabellenfeld Firmen.Ort abstrahiert wird.
Beispiel:
SELECT Firmen. Ort.Kontaktpersonen.Count
Dieses Statement erkennt in einem ersten Schritt die Gruppierung nach dem Tabellenfeld Firmen. Ort gefordert ist. Gleichermaßen wird die Tabelle Kontaktpersonen mit dem Parameter .Count als tabellenübergeordnetes Wertefeld erkannt und entsprechend aufgelöst:
SELECT Firmen.Ort,
( SELECT Count(Kontaktpersonen.* ) ) AS KontaktpersonenCount
Das nun zur Verfügung stehende Statement wird nun um die fehlenden relationenbezogenen Operationen für die jeweilige Datenstruktur vervollständigt und ergibt somit folgendes endgültiges Statement:
SELECT Firmen.Ort, ( SELECT Count(Kontaktρersonen.*)
FROM Sub_Firmen, Abteilungen, Kontaktpersonen WHERE (Firmen.Ort=Sub_Firmen.Ort)
AND (Sub_Firmen.FirmaID=Abteilungen.FirmaNr) AND (Abteilungen.AbteilungID=Kontaktpersonen.AbteilungNr) FROM Firmen
GROUP BY FirmenOrt
Entsprechend sind auch sämtliche Kombinationen der gezeigten tabellenübergeordneten Wertefelder möglich:
SELECT Firmen.* WHERE (Firmen.Ort.Firmen.Count>100) AND Firmen.Kontaktpersonen.Abteilungname="Marketing".Count
Soll der Umsatz von jeden Orten gezeigt werden, in denen je Kontaktpersonen der Firma im Jahr 2006 im Schnitt 1000 Euro Umsatz erzielt wurde, so ist dies folgender maßen zu beschreiben:
Beispiel : SELECT Firmen.Ort, Unsatz()
WHERE AVG (Firmen.OitKontaMpersonen.Umsatz(Zei1xaum=2006) )>1000
Dieses Statement wird nach der Anwendung des Auflösungsschrittes in nachfolgendes SQL- Statement, welche keine relationenbezogenen Operationen enthält, umgewandet und in einem weiteren Schritt um die fehlenden relationenbezogenen Operationen erweitert. Die Auflösung des tabellenübergeordneten Wertefeldes Firmen. Ort wird nicht in diesem Schritt gezeigt, um den Focus des Beispiels auf das Wesentliche zu richten.
SELECT Firmen.Ort, (Sum (Rechnungspositionen.Positionsbetrag) ) AS Umsatz WHERE AVG (
SELECT SUM (Rechnungspositionen.Positionsbetrag)
WHERE Veranstaltungen. VADatum BETWEEN #01.01.2006# AND #31.12.2006#
GROUP BY Veranstaltungen.KontaktpersonNr
) > 1000 GROUP BY Firmen.Ort
Es wird erkannt, dass eine Verbindung von der Gruppierung Firmen.Ort zu der Tabelle Kontaktpersonen hergestellt werden soll und von der Tabelle Kontaktpersonen aus die Summe des Tabellenfeldes Rechnungen.Rechnungsposition berechnet werden soll. Durch den dem tabellenübergeordneten Wertefeld Umsatz() mitgegebenen Parameter Zeitraum=2006 wird ebenfalls erkannt, dass ein Kriterium Veranstaltungen.V ADatum BETWEEN #01.01.2006# AND #31.12.2006# einzufügen ist. Die Gruppierung nach dem Feld Veranstaltungeii.KontaktpersonNr wird dadurch automatisch erkannt, dass, beispielsweise anhand einer Tabelle der Relationen, die Verbindung der Tabelle Kontaktpersonen zu der Tabelle Veranstaltungen über die beiden Schlüsselfelder Kontaktpersonen.KontaktpersonID und Veranstaltungen.KontaktpersonNr zu generieren ist. Weiters erkennt ein einfacher Algorithmus, dass das Ergebnis des automatisch eingefügten SUB-SELECTS SELECT Sum (Rechnungspositionen.PositionsbetraR) ... im in der Hierarchiestufe übergeordneten Statement mittels AVG je Ort berechnet werden soll.
Somit ergibt sich nach der vollständigen Auflösung des übergeordneten Wertefeldes Firmen. Ort und der automatischen Vervollständigung des Statements um die fehlenden relationenbezogenen Operationen das folgende endgültige, dem SQL-Standard entsprechende Statement:
SELECT
( SELECT Ort_PLZ.Ort FROM Ort_PLZ WHERE Firmen.PLZ=Ort_PLZ.PLZ ) AS Ort,
( SELECT Sum (Rechnungspositionen.Positionsbetrag) FROM Veranstaltungen, Rechnungen, Rechnungspositionen WHERE Kontaktpersonen.KontaktpersonID=Veranstaltungen.KontaktpersonNr
AND Veranstaltungen. VeranstaltungID=Rechnungen.VeranstaltungNr AND Rechnungen.RechnungID=Rechnungspositionen.RechnungNr
GROUP BY Veranstaltungen.KontaktpersonNr ) AS AVG_Kontaktperson_Umsatz FROM Firmen, Abteilungen, Kontaktpersonen WHERE Firmen.FirmaID=Abteilungen.FirmaNr AND Abteilungen.AbteilungID=Kontaktpersonen.AbteilungNr
GROUP BY
( SELECT Ort_PLZ.Ort FROM Ort_PLZ WHERE Firmen.PLZ=Ort_PLZ.PLZ ) HAVING AVG (
SELECT SUM (Rechnungspositionen.Positionsbetrag) FROM Veranstaltungen, Rechnungen, Rechnungspositionen
WHERE Kontaktpersonen.KontaktpersonID:=Veranstaltungen.KontaktpersonNr AND Veranstaltungen. VeranstaltungID:=Rechnungen.VeranstaltungNr AND Rechnungen.RechnungID=Rechnungspositionen.RechnungNr AND Veranstaltungen. VADatum BETWEEN #01.01.2006# AND #31.12.2006# GROUP BY Veranstaltungen.KontaktpersonNr ) > 1000
Da im Verarbeitungsbereich WHERE des vorhandenen SQL-Statements eine Verarbeitungsfunktion (AVG) enthalten ist, wird erkannt, dass diese Verarbeitungsfunktion in den HA VING- Verarbeitungsbereich verschoben werden muss.
Es sei wiederholt, dass es der Vorteil der tabellenübergeordneten Wertefelder, insbesondere in Kombination mit der automatischen Vervollständigung von relationenbezogenen Operationen, einerseits eine wesentlich kürzere und vor allem einfachere Schreibweise ermöglicht und ebenfalls auch eine bestmögliche Unabhängigkeit von der zugrunde liegenden Datenstruktur ermöglicht. Somit würde dieses, wie sämtliche andere gezeigten Beispiele auch, aufgrund anderer innerer gerichteter Entscheidungsgraphen von tabellenübergeordneten Wertefeldern und/oder aufgrund einer unterschiedlich befüllten Tabelle der Relationen ein anderes, auf die jeweilige Datenstruktur angepasstes, endgültiges SQL-Statement automatisch ergeben.
Ein konkretes, aufgrund der insgesamten Länge desselben nicht aufgelöstes und um relationenbezogene Operationen vervollständigtes Beispiel lautet wie folgt:
Liefere folgende Informationen je Ort:
- Durchschnittsumsatz des Verkäufers Müller in diesem Ort
- Durchschnittsumsatz des Verkäufers Müller aller PLZ's in diesem Ort - Durchschnittsumsatz des Verkäufers Müller aller Firmen in diesem Ort
- Durchschnittsumsatz des Verkäufers Müller aller Abteilungen in diesem Ort
- Durchschnittsumsatz des Verkäufers Müller aller Kontaktpersonen in diesem Ort
- Durchschnittsumsatz des Verkäufers Müller aller Veranstaltungen in diesem Ort
- Anzahl der Veranstaltungen im Jahr 2006 in diesem Ort - Durchschnittliche Anzahl der Veranstaltungen im Jahr 2006 aller PLZ dieses Ortes
- Durchschnittliche Anzahl der Veranstaltungen im Jahr 2006 aller Firmen dieses Ortes
Beispiel :
SELECT Firmen.Ort, AVG ( Umsatz(Verkaeufer="Müller") ) AS AVG_Ort Firmen.PLZ.AVG ( Umsatz(Verkaeufer="Müller") ) AS AVG_PLZ Firmen. AVG ( Umsatz(Verkaeufer="Müller") ) AS AVG_Firma AbteilungenΛVG ( Umsatz(Verkaeufer=="Müller") ) AS AVG_Abteilung Kontaktpersonen.AVG (Umsatz(Verkaeufer="Müller") ) AS AVG_Kontaktperson
Veranstaltungen.AVG ( Umsatz(Verkäufer="Müller") ) AS AVG_Veranstaltung AnzahlVeranstaltungen (Zeitraum=2006) AS Ort_AnzVA_2006 AVG (Firmen.PLZ.AnzahlVeranstaltungen (Zeitraum=2006) ) AS PLZ_AnzVA_2006 AVG (Firmen.AnzahlVeranstaltungen (Zeitraum=2006) ) AS Firma_AnzVA_2006
Um nochmals die Unabhängigkeit der tabellenübergeordneten Wertefelder von den in einem Anwender-SQL-Statement angegebenen Tabellen zu zeigen, wird ein einfaches Anwender- SQL-Statement erzeugt: Dieses Statement liefert den insgesamten Umsatz je Artikel und den Umsatz j e Artikel im Jahr 2005.
SELECT Artikel.*, Umsatz(), Umsatz(Zeitraum=2005)
Es lassen sich einfach durch die Verkettung mittels Punkt ebenfalls Parameter zu einem tabellenübergeordneten Wertefeld mitgeben, wie das nachfolgende Beispiel verdeutlichen soll:
Liefere die Anzahl aller Firmen, die im Land Österreich liegen, in den Orten „St. Polten", die Anzahl aller Firmen in den PLZs 1010 bis 1090, die Anzahl aller Firmen mit einem Umsatz von über 1000 Euro im Jahr 2006 und die Anzahl aller Firmen mit mehr als fünf Kontaktpersonen:
SELECT AnzahlFirmen().Ort = „St. Polten" AS AnzFirmen StPoelten,
AnzahlFirmen().PLZ BETWEEN 1010 AND 1090 AS AnzFirmen_1010_1090, AnzahlFirmen().Umsatz(Zeitraum=2006)>l 000 AS AnzFirmen_Umsatz2006,
AnzahlFirmen().Kontaktpersonen.Count>5 AS AnzFirmen_MitKontaktpersonen
WHERE FirmenXand = „A" Der automatische erste Teil des Auflösungsschrittes dieses Beispiels ergibt folgendes SQL- Statement, welches in einem weiteren Schritt um die fehlenden relationenbezogenen Operationen erweitert wird:
SELECT
(SELECT Count (Distinct Firmen.FirmalD) WHERE Firmen.Ort="St.Pölten) AND
Firmen.Land="A") AS AnFirmen__StPoelten (SELECT Count (Distinct Firmen.FirmalD) WHERE Firmen.PLZ BETWEEN 1010
AND 1090 AND Firmen.Land="A") AS AnzFirmen_1010 AND 1090 (SELECT Count (Distinct Firmen.FirmalD) WHERE
Firmen.Umsatz(Zeitraum=2006)>1000 AND Firmen.Land="A") AS An2Firmen_Umsatz2006 (SELECT Count (Distinct Firmen.FirmalD)
WHERE ( SELECT Count(Kontaktpersonen.*) ) > 5 ) AND Firmen.Land="A" ) AS AnzFirmen_MitKontaktρersonen
Um den Focus auf das Wesentliche dieses Beispiels zu richten, wird, wie erwähnt, nur der erste Teil des Auflösungsschrittes gezeigt, die automatische Auflösung weiterer tabellenübergeordneter Wertefelder sowie die Vervollständigung der fehlenden relationenbezogenen Operationen erfolgt nach den gezeigten Verfahren und wird daher nicht im Detail ausgeführt und gezeigt.
Das automatische Anfügen des Kriteriums Firmen.Land="A" in dieses der ersten Hierarchie- Stufe untergeordnete Statement kann mittels eines einfachen Algorithmus erkannt und automatisch durchgeführt werden. Dies geschieht, um die Erzeugung eines gleichwertigen, aber um ein vielfaches komplexen SQL-Statements, welche jeweils eine Verbindung aller SUB-SELECTs zu der obersten Hierarchiestufe, in welche alle Firmen, deren Land den Wert „A" beinhaltet, zu umgehen.
Sollen alle Kontaktpersonen jener Firmen aus Wien ermittelt werden, in denen mehr als 100 Mitarbeiter beschäftigt sind, lässt sich dies einfach zum Beispiel mittels folgender Schreibweise formulieren: Beispiel:
SELECT Kontaktpersonen.*
WHERE FimienAusWien().AnzMitabeiter >100
Wird endgültig umgewandelt in
SELECT Kontaktpersonen.* FROM Firmen, Abteilungen, Kontaktpersonen WHERE (Firmen.Ort="Wien") AND (Firmen.AnzMitabeiter>100) AND (Firmen.FirmaID=Abteilungen.FirmaNr)
AND (Abteilungen.AbteilungID=Kontaktpersonen.FirmaNr)
Zwei ebenfalls mögliche, gleichwerte Schreibweisen sind:
SELECT Kontaktpersonen.* FROM FirmenAusWienO WHERE Firmen.AnzahlMitarbeiter>100
Bzw.
SELECT Kontaktpersonen.*
WHERE FirmenAusWienO AND Firmen. AnzahlMitarbeiter> 100
Um die Verkettung von zwei aufeinander folgenden tabellenübergeordneten Wertefeldern und deren Auflösung mittels eines einfachen Beispiels zu zeigen, wird ein neues, einfaches tabellenübergeordnetes Wertefeld angelegt:
Define ConnectionField AnzahlKontaktpersonen (Mindestumsatz, Mindestumsatz_Zeitraum) IF Param:Mindestumsatz THEN
Sum(Rechnungspositionen.Positionsbetrag)>=Param:Mindestumsatz IF Param:Mindestumsatz_Zeitraum THEN
Veranstalümgen.VADatum=Param:Mindesturnsatz_Zeitraum END IF END IF
Count(Distinct Kontaktpersonen.KontaktpersonID) End Define
Im inneren, gerichteten Entscheidungsgraphen dieses tabellenübergeordneten Wertefeldes wird in jedem Fall eine Entscheidungsposition erreicht, welche unter anderem ein Tabellenfeld, das eindeutig einer Tabelle aus der gegebenen Datenstruktur zuordenbar ist, enthält: Count(Distinct Kontaktpersonen.KontaktpersonID)
Somit lassen sich einfach alle Firmen aus Wien zeigen, in denen es in allen Abteilungen mehr als fünf Kontaktpersonen gibt, die im Jahr 2006 einen Mindestumsatz von 1000 Euro gebraucht haben, in dem von einem Anwender folgendes einfaches Statement erstellt wird:
Beispiel : SELECT Firmen.*
WHERE FirmenAusWien(). AnzahlKontaktpersonen(Mindestumsatz=l 000, Mindestumsatz_Zeitraum=2006)>5
Nach dem Auflösungsschritt wird aufgrund des erweiterten RTNs erkannt, dass folgendes SQL-Statement, welches in einem nachfolgenden Schritt um die relationenbezogenen Operationen erweitert wird, generiert werden soll:
SELECT Firmen.* FROM Firmen WHERE Firmen.PLZ IN (SELECT Ort_PLZ.PLZ WHERE Ort_PLZ.Ort="Wien") AND ( SELECT Count (Distinct Kontaktpersonen.KontaktpersonID) WHERE ( SELECT Sum(Rechnungspositionen.Positionsbetrag)
WHERE (Veranstaltungen. VADatum BETWEEN #01.01.2006# AND #31.12.2006#) >= 1000 ) >5
Nach der Vervollständigung der relationenbezogenen Operationen folgendes SQL-Statement erstellt, welches von einer SQL-Engine nach dem Stand der Technik analysiert, optimiert und verarbeitet werden kann: SELECT Firmen.* FROM Firmen WHERE Firmen.PLZ IN (SELECT Ort_PLZ.PLZ FROM Ort_PLZ WHERE Ort_PLZ.Ort="Wien")
AND ( SELECT Count(Kontaktpersonen.KontaktρersonID) FROM Abteilungen, Kontaktpersonen WHERE Firmen.FirmaID=Abteilungen.FirmaNr AND Abteilungen.AbteilungID=Kontaktpersonen.AbteilungNr AND (SELECT Sum(Rechnungspositionen.Positionsbetrag)
FROM Veranstaltungen, Rechnungen, Rechnungspositionen WHERE Kontaktpersonen.KontaktpersonID= Veranstaltungen,KontaktpersonNr AND Veranstaltungen. VeranstaltungID= RechnungenVeranstaltungNr
AND Rechnungen.RechnungID= Rechnungspositionen.RechnungNr AND Veranstaltungen. V ADatum BETWEEN #01.01.2006# AND #31.12.2006# ) >= 1000
) > 10
Folgendes Beispiel soll die einfache Schreibweise folgender Fragestellung zeigen:
ALLE Firmen, deren Umsatz in den Jahren 2005, 2005 und 2006 und die Anzahl Veranstaltungen im Jahr 2006 als Spalten aus Orten mit mehr als 100 Firmen, deren Umsatz in Jahr 2006 im Vergleich zum Jahr 2005 um mindestens 20% gestiegen ist:
SELECT Firmen.*,
Umsatz (ZeitraunrfOO^, Umsatz (Zeitraum=2005), Umatz (Zeitraum=2006), AnzahlVeranstaltungen(Zeitraum=2006) WHERE Ort.AnzahlFirmen() > 100
AND Umsatz(Zeitraum-2006)>=Umsatz(Zeitraum=2005)* 1.2 Tabellenübergeordnete Wertefelder können auch mehrere Entscheidungspfade ausgehend von einer Entscheidungsposition erstellen. Dies geschieht beispielsweise entweder mittels einer IF-THEN-ELSE-Verschachtelung oder mittels eines SELECT-CASE an einer Entscheidungsposition:
Defme ConnectionField Firmen.MitarbeiterIDOfVerkaufsgebiet()
SELECT GASE TRUE: CASE Firmen.LANDo"A"
SELECT MitarbeiterID WHERE Mitarbeiter.Nachname="Steiner" GASE Firmen.Ort="Salzburg":
SELECT MitarbeiterID WHERE Mitarbeiter.Nachname="Meier" GASE Firmen.PLZ BETWEEN 1010 AND 2300: SELECT MitarbeiterID WHERE Mitarbeiter.Nachnarne="Müller"
CASE Firmen.Umsatz(Date.Year-l)>1000:
SELECT MitarbeiterID WHERE Mitarbeiter.Nachname="Hansen" CASE ELSE:
SELECT MitarbeiterID WHERE Mitarbeiter.Nachname- 'Taurer" END SELECT
END Defme
In diesem inneren, gerichteten Entscheidungsgraphen wird in jedem der fünf definierten Entscheidungspfade jeweils eine Entscheidungsposition erreicht, welche zumindest eine Tabellenfeld, das eindeutig einer Tabelle zuordenbar ist, enthält.
Mittels dieses tabellenübergeordneten Wertefeldes lassen sich alle Artikel und deren verkaufe Anzahl je betreuenden Verkäufe des zugeordneten Verkaufsgebietes leicht ermitteln:
SELECT Artikel.*, Count (Distinct Artikel. ArtikellD), Firmen.Betreuer GROUP BY Firmen.MitarbeiterIDOfVerkaufsgebiet Eine Umwandlung dieses Statements erfolgt mittels der Schritte des erfinungsgemäßen Verfahrens durch den Auflösungsschritt und die Vervollständigung der relationenbezogenen Operationen und wird nicht mehr gezeigt.
Der Verarbeitungsbefehl DISTINCT folgt in den gezeigten Beispielen oftmals auf das Schlüsselwort COUNT. Dieser Verarbeitungsbefehl kann immer eingefügt werden und die Notwendigkeit desselben kann ein nachfolgender SQL-Optimizer feststellen. Ebenso kann automatisch erkannt werden, dass der Verarbeitungsbefehl DISTINCT in Kombinationen mit dem Verarbeitungsbefehl COUNT nur dann in benötigt wird, wenn in einer Hierarchiestufe die Verarbeitungsfunktion COUNT auf eine Tabelle der definierten Menge angewandet werden soll, welche Tabelle nicht die letzte Ebene in dieser Hierarchiestufe darstellt.
Um dies zu verdeutlichen, wird folgendes, einfaches Beispiel gezeigt:
SELECT Firmen. Count, Firmen. Abteilungen. Count
Dieses von einem Anwender erstellte Statement wird automatisch umgewandelt wie folgt:
SELECT Count (Distinct Firmen.FirmaID), Count ( Abteilungen. AbteilungID ) FROM Firmen, Abteilungen
WHERE (Firmen.FirmaID=Abteilungen.FirmaNr)
Es wird erkannt, dass die Verarbeitungsfunktion Count in Kombination mit der Tabelle Firmen sich nicht auf die letzte Ebene der definierten Menge, also des kartesischen Produktes der beiden Tabellen Firmen und Abteilungen, bezieht. Ebenso wird erkannt, dass die
Verarbeitungsfunktion Count in Kombination mit der Tabelle Abteilungen sich auf letzte Ebene der definierten Menge bezieht. Entsprechend wird das Schlüsselwort DISTINCT nur in Kombination mit COUNT Firmen.FirmalD eingefügt.
Es sei angemerkt, dass die beiden Begriffe „relationenbezogen" und „relationenorientiert" in der Beschreibung die idente Bedeutung haben. Tabellenübergeordnete Wertefelder eignen sich ebenfalls sehr gut für die Verwendung in einer graphischen Oberfläche. Wird eine Tabelle ausgewählt, kann ebenfalls die Gesamtheit aller vorhandenen tabellenübergeordneten Wertefelder zur Auswahl angezeigt werden. Ebenso können jene tabellenübergeordneten Wertefelder, dessen Namen sich aus einem Tabellennamen, einem Punkt und einem Tabellenfeld-bezeichnenden Namen zusammensetzten, als Tabellenfelder einer jeweiligen Tabelle angezeigt werden.
Tabellenübergeordnete Wertefelder eigenen sich unveränderter Weise für die Verwendung von sämtlichen relationalen Datenstrukturen und SQL-Dialekten, so zum Beispiel OLAP, Geo-SQL, T-SQL usw. Genauso kann das erfindungsgemäße Verfahren bei anderen sämtlichen anderen Anfragesprachen wie z.B. OQL verwendet werden.
Die Angabe von () auf bei jenen tabellenübergeordneten Wertefeldern, welche keine Parameter enthalten, ist nicht zwingend erforderlich, wird aber an einigen Stellen aus Gründen der Übersicht verwendet.
Nachfolgend wird ein Verfahren gezeigt, welches der Vervollständigungsschritt anwenden kann, um fehlende relationenbezogene Operationen in den Übergangs-SQL-Statements automatisch zu vervollständigen und somit ein endgültiges SQL-Statement zu erhalten:
In der vorgenannten Datenstruktur der Datentabellen 1 bis 10 (Tabelle 1 bis 10) läßt sich z.B. die folgende Aufgabe formulieren, aus der ersichtlich ist, welch komplexe Fragestellungen mit dem erfindungsgemäßen Verfahren bewältigt werden können. Im nachfolgenden Beispiel wird auf diese Datenstruktur Bezug genommen.
Beispiel B:
Alle Firmen und deren diesjähriger Veranstaltungsgesamtumsatz anzeigen, aber nur für jene, mit denen heuer zumindest zehn Kontakte geführt wurden und in Marketingabteilungen heuer zumindest drei Veranstaltungen mit über 50 EURO an Umsatz für Speisen und Getränke gebucht wurden. Beim erfindungsgemäßen Verfahren werden im wesentlichen die folgenden Schritte ausgeführt.
1) Angeben einer abarbeitbaren Datenbankanweisung ohne relationenbezogene Operationen 2) Ermitteln eines Zugriffspfades
Dies erfolgt im einzelnen wie folgt:
ad 1) Verarbeitungsfunktionen und Datentabellen und deren Spalten angeben, auf die die Verarbeitungsfunktionen angewandt werden sollen und die Reihenfolge sowie die Hierarchiestufe, mit der die Abarbeitung zu erfolgen hat.
SELECT Verarbeitungsfunktion
Firmen Datentabelle, auf die Verarbeitungsfunktion angewandt werden soll Alle Spalten (.*)... Spalten, auf die Verarbeitungsfunktion angewandt werden soll
Alle Spalten der Tabelle „Firmen" angeben
Für jede selektierte Firma die Summe aller Positionsbeträge aus der zugehörigen Spalte der Tabelle „Rechnungspositionen" bestimmen unter der Einschränkung des Veranstaltungsjahres (heuer).
Erfindungsgemäßes Erstellen der Datenbankanweisung führt daher zu:
SELECT Firmen.*, (SELECT SUM (Rechnungspositionen.Positionsbetrag)
WHERE (Veranstaltungen. VADatum=date.year) ) WHERE (SELECT COUNT(Kontakte.*)
WHERE (Kontakte.Kontaktdatum=date.year) )> = 10 AND (SELECT COUNT(Veranstaltungen.*)
WHERE (Abteilungen.Abteilungsname= „Marketing") AND (SELECT SUM (Rechnungspositionen.Positionsbetrag)
WHERE (Zusatzrechnungspositionennamen.Positionsname IN ("Speisen", "Getränke")) ) >50
AND (Veranstaltungen. VADatum = date.year ) ) >=3
[„Date.year" ersetzt dabei BETWEEN 01.01. aktuelles Jahr AND 31.12.aktuelles Jahr]
In dieser Anfrage sind nur die Tabellen ohne Relationen enthalten, auf welche Verarbeitungsfunktionen angewandt werden sollen. Damit liegt Unabhängigkeit von jedweder Datenstruktur vor und es ergibt sich zugleich eine Verkürzung der Schreibweise und somit eine Erhöhung der Übersichtlichkeit. So fallen z.B. sonst übliche kartesische Produktbildungen, welche durch Relationen eingeschränkt sind, weg, weil im Statement alle Informationen vorhanden sind, die in Kombination mit der Tabelle der Relationen für die Ermittlung eines Zugriffspfades der jeweiligen Datenstruktur verwertet werden können, sodaß zum einen Unabhängigkeit von der konkreten Datenstruktur gegeben ist und zum anderen die Eingabe der Anfrage für den Anwender verkürzt und sich nur auf das Wesentliche beschränkt, was wiederum die Übersichtlichkeit erhöht.
ad 2) Aufgrund der Fragestellung ergibt sich in der Anfrage (Statement) bedingt durch die auszuführenden Unterabfragen (SUBSELECT) eine natürliche Reihenfolge der verwendeten Datentabellen sowie Hierarchiestufen, aus denen unter Zuhilfenahme der Tabelle der Relationen (Tabelle 11) Teilzugriffspfade für die Generierung eines SQL-Statements für die jeweilige Datenstruktur ermittelt werden.
Die oben genannten Reihenfolge und die Hierarchiestufen der verwendeten Datentabellen werden vorzugsweise in Form eines geordneten Baumes 7 (Fig.1 ) dargestellt, der eine Wurzel 10 und Knoten 11, 12, 13 und 14 enthält, wobei der Knoten 14 ein Unterknoten zum Knoten 13 ist.
Die Wurzel 10 des geordneten Baumes 7 enthält als Informationsfeld 21 alle Namen der Datentabellen nur der übergeordneten Anfrage z.B. in Form einer Liste oder eines Arrays, und zwar praktischerweise in der im Statement angegebenen Reihenfolge, optional ohne doppelte Datentabellen-Namen. Für die Wurzel 10 beinhaltet das Informationsfeld 21 die Datentabelle FIRMEN (Tabelle 1). Der Wurzel 10 untergeordnet sind Unterabfragen (SUBSELECT) und deren untergeordnete Unterabfragen (SUBSELECT im SUBSELECT)3 die als Knoten 11, 12, 13, 14 in die Baumstruktur eingetragen sind. Die Informationsfelder 22, 23, 24, 25 der Knoten 11, 12, 13, 14 enthalten die den Unterabfragen zugeordneten Namen der Datentabellen, die im jeweiligen SUBSELECT angegeben wurden, ebenfalls z.B. in Form einer Liste oder eines Arrays. Für den Knoten 13 sind dies die Datentabellen VERANSTALTUNGEN (Tabelle 5), ABTEILUNGEN (Tabelle 2) und VERANSTALTUNGEN (Tabelle 5) im Informationsfeld 24. Das SUBSELECT des Knotens 13 enthält gemäß der Fragestellung ein weiteres SUBSELECT durch den Knoten 14, der seinerseits in seinem Informationsfeld die Datentabellen RECHNUNGSPOSITIONEN (Tabelle 9) und
ZUSATZRECHNUNGSPOSITIONENNAMEN (Tabelle 10) beinhaltet.
Dieser Baum 7 wird in einem Preorder-Durchlauf durchlaufen: Knoten 10, Knoten 11, Knoten 12, Knoten 13 und Knoten 14.
Als Hierarchiestufen lassen sich die nachfolgend angegebenen darstellen.
Stufe 1 Firmen
Wurzel 10, Übergeordnete Abfrage
Stufe 1.1 Rechnungspositionen, Veranstaltungen
Knoten 11, Unteranfrage im SELECT-Teil der Hauptanfrage
Stufe 1.2 Kontakte, Kontakte Knoten 12, Unteranfrage im WHERE-Teil der Hauptanfrage
Stufe 1.3 Veranstaltungen, Abteilungen, Veranstaltungen
Knoten 13, Unteranfrage AND-Teil der Hauptanfrage
Stufe 1.3.1 Rechnungspositionen, ZusatzRechnungspositionsnamen
Knoten 14, Unteranfrage in der Unteranfrage AND
Nunmehr erfolgt die Zugriffspfadermittlung, die eine Zugriffsreihenfolge auf die Datenbank konkret vorgibt, indem über die Tabelle der Relationen zwischen jeweils zwei aufeinanderfolgenden, ausgewählten Datentabellen ein Teilzugriffspfad auf Basis der zwischen den aufeinanderfolgenden Datentabellen vorhandenen Relationen berechnet wird, und aus allen errechneten Teilzugriffspfaden der Zugriffspfad zusammengesetzt wird.
Dabei zu berücksichtigen ist, daß durch den Wegfall jeglicher Produktbeschreibungen im Statement (FROM-Teil) die angegebene Datentabellen-Reihenfolge mit Verarbeitungsfunktionen ein doppeltes oder mehrfaches Durchlaufen von Teilzugriffspfaden ergeben kann, woraus bei der kartesischen Produktbildung gleiche Datentabellen fälschlicherweise mehrfach einbezogen würden, was ein falsches Anfrageergebnis zur Folge hätte.
Anhand des mit der oben angegebenen Tabelle der Relationen (Tabelle 11) ermittelten Zugriffspfades können nun relationenorientierte Operationen in die erfindungsgemäß (Beispiel B) angegebene Datenbankanweisung eingesetzt werden, wodurch folgendes SQL- Statement herauskommt, (die eingesetzten Operationen sind kursiv gesetzt) welches von jedem den SQL-Standard unterstützenden Datenbanksystem verarbeitet werden kann. Eine mögliche Form der Berechnung wird anschließend erläutert.
SELECT Firmen.*,
(SELECT SUM (Rechnungspositionen.Positionsbetrag) FROM Abteilungen, Kontaktpersonen, Veranstaltungen, Rechnungen, Rechnungspositionen
WHERE (Firmen.FirtnaID=Abteilungen.FirmaNr) AND (Abteilungen.AbteilungID=Kontaktpersonen.AbteilungNr) AND (Kontaktpersonen.KontaktpersonID=Veranstaltungen.KontaktpersonNr) AND (Veranstaltungen. VeranstaltungID=Rechnungen. VeranstaltungNr) AND (Rechnungen.RechmιngID=Rechnungspositionen.RechnungNr)
AND (Veranstaltungen. VADaturn=Date.Year)
)
FROMFirmen
WHERE (SELECT Count(Kontakte.*) FROM Abteilungen, Kontaktpersonen, Kontakte
WHERE (Firmen.FirmaID=Abteilungen.FirnιaNr) AND (Abteilungen.AbteilungID=Kontaktpersonen.AbteilungNr) AND (Kontaktpersonen.KontaktpersonID=Kontakte.KontaktpersonNr) AND (Kontakte.Kontaktdatum = Date. Year) ) >= 10
AND (SELECT Count(Veranstatungen.*) FROM Abteilungen, Kontaktpersonen, Veranstaltungen WHERE (Firmen.FirmaID=Abteilungen.FirmaNr) AND (Abteilungen. AbteilungID=Kontaktpersonen.AbteilungNr) AND (Kontaktpersonen.KontaktpersonID=Veranstaltungen.KontaktpersonNr) 5 AND (Abteilungen.Abteilungsname="Marketing")
AND (SELECT Sum(Rechnungspositionen.Positionsbetrag)
FROM Rechnungen, Rechnungspositionen, ZusatzRechnungspostionenNamen WHERE (Veranstaltungen. VeranstaltungID=Rechnungen. VeranstaltungNr) AND (Rechnungen.RechnungID=Rechnungspositionen.RechnungNr)
10 AND(Rechnungspositionen.PositionNr=ZusatzRechnungspostionenNamen.PositionID)
AND (ZusatzRechnungspostionenNamen.Positionsname
IN („Speisen'7'Getränke") ) ) > 50)
AND (Veranstaltungen. VADatunτ=date.year) 15 ) >= 3
Aus der Länge des auf diese Weise gewonnenen Statements im Vergleich zu dem in Schritt 1) erstellten ist klar zu ersehen, welche Vorteile hinsichtlich Kürze und Übersichtlichkeit aber insbesondere Unabhängigkeit von der Datenstruktur erzielt werden können.
20
Wird das Statement als Anfrage gespeichert, so kann die erfindungsgemäße Schreibweise und die generierte Schreibweise übernommen werden und eine Neuberechnung fallt weg. Eine solche wird nur bei Änderungen der Datenstruktur oder an derselben bzw. am Statement selbst durchgeführt. Dadurch fallt die sehr geringe Zeitspanne für die Umwandlung in ein
£5 SQL-Statement weg. Weitere Optimierungen liegen im Bereich des Fachwissens.
Eine andere Möglichkeit wäre, daß der ermittelte Zugriffspfad in der Datenbankanweisung separiert angegeben wird, der schrittweise auf die Datentabellen verweist, und zum Zugriff auf die Datenbank diesen Verweisen auf die Datentabellen schrittweise gefolgt wird. So 30 ergibt sich z.B.
WAY Firmen
-> Abteilungen WHERE (Firmen.FirmaID=Abteilungen.FirmaNr) -> Kontaktpersonen WHERE (Abteilungen.AbteilungID≡Kontaktpersonen.AbteilungNr) 35 -> Veranstaltungen
WHERE (Kontaktpersonen.KontaktpersonID=Veranstaltungen.KontaktpersonNr)
-> Rechnungen WHERE (Veranstaltungen. VeranstaltungID=Rechnungen. VeranstaltungNr) -> Rechnungspositionen
WHERE (Rechnungen.RechnungID=Rechnungspositionen.RechnungNr) -> ZusatzRechnungspostionenNamen
WHERE (Rechnungspositionen.PositioιiNr=ZusatzRechnungspostionenNamen.PositionID) Kontaktpersonen -> Kontakte
WHERE (Kontaktpersonen.KontaktpersonID=Kontakte.KontaktpersonNr) SELECT Firmen.*,
(SELECT SUM (Rechnungspositionen.Positionsbetrag) WHERE (Veranstaltungen. VADatum=date.year) ) WHERE (SELECT COUNT(Kontakte. *)
WHERE (Kontakte.Kontaktdatum=date.year) )> = 10 AND (SELECT COUNT(Veranstaltungen.*)
WHERE (Abteilungen.Abteilungsname= „Marketing") AND (SELECT SUM (Rechnungspositionen.Positionsbetrag)
WHERE (Zusatzrechnungspositionennamen.Positionsname IN ("Speisen", "Getränke")) ) >50
AND (Veranstaltungen. VADatum = date.year ) ) >=3
Dadurch fallt die Eingliederung in das Statement weg, der Zugriffspfad verweist schrittweise auf die Datentabellen. Diesen Verweisen wird zum Zugriff auf die Datenbank schrittweise gefolgt.
Ein möglicher Algorithmus zur Ermittlung des Zugriffspfades unter Zuhilfenahme des geordneten Baumes, wie er in Fig.l angegeben ist, wird - um das Verständnis zu erleichtern und nicht von Tabellennamen usw. abzulenken - nachfolgend anhand einer einfachen Datenstruktur gezeigt. Dabei ist hervorzuheben, daß dieser angegebene Algorithmus nur einer von vielen ist, die für die Berechnung angewandt werden können.
Generell werden bei der Ermittlung des Gesamtzugriffspfades doppelt angegebene Teilpfade gestrichen.
Z.B. Datentabellen A, B, C, D, E, F, G, H Inforaiationsfeld einer Wurzel des geordneten Baumes beinhaltet z.B. : A, C, F, B. Als Teilpfade ergeben sich somit
Teilpfad AC: A B C Teilpfad CF: C D E F Teilpfad FB: F E D C B
Unbereinigter Gesamtpfad daher: A B C D E F E D C B Wie ersichtlich ist E D C B doppelt angegeben und daher zu streichen Richtiger Gesamtpfad somit: A B C D E F
Unter der Annahme einer konkret vorliegenden Baumdarstellung, wie sie in Fig.2 gezeigt ist, wird nunmehr eine von vielen Möglichkeiten angegeben, wie die Zugriffspfadberechnung gemäß erfindungsgemäßem Verfahren und Übersetzung in ein SQL-Statement durch Anwendung folgender Schritte durchgeführt werden kann.
Es liegen Datentabellen A, B, C, D3 E, in einer Datenstruktur vor.
Aus der der Darstellung in Fig.2 zugrunde liegenden Anfrage, die der besseren Übersichtlichkeit wegen nicht angegeben ist, ergibt sich folgende Baumstruktur.
Wurzel (Knoten) 101 mit Informationsfeld 201, welches C5A5D enthält Knoten 102 mit Informationsfeld 202,welches G5E enthält Knoten 103 mit Informationsfeld 203,welches F,I,G enthält Knoten 104 mit Informationsfeld 204, welches K3H3K5B enthält Knoten 105 mit Informationsfeld 205, welches G5D enthält
Die der gewählten Datenstruktur zugehörige Tabelle der Relationen verbindet dabei zur einfacheren Darstellung vereinfacht jeweils alphabetisch aufeinanderfolgende Datentabellen durch jeweils ein gemeinsames Relationenfeld, somit A<->B5 B <-> C5 C<->D,
Folgende Relationenfelder werden, wie aus Tabelle 12 (Tabelle der Relationen) hervorgeht, angenommen. Tabelle A Spalten a, zl
Tabelle B Spalten b, al
Tabelle C Spalten c, bl
Tabelle D Spalten d, cl
Figure imgf000083_0001
Der für eine bestimmte Anfrage erstellte geordnete Baum wird in einer sogenannten Preorder- Reihenfolge durchlaufen, indem ausgehend von einem ersten Knoten, der Wurzel 101 des geordneten Baumes 107 sämtliche weitere Knoten 102, 103, 104, 105 entsprechend der Hierarchiestufen durchlaufen werden.
Stufe 1 C1 A1 D
Wurzel (Knoten) 101
Stufe 1.1 E1G Knoten 102
Stufe 1.2 F1I1G Knoten 103
Stufe 1.2.1 K,H,K,B Knoten 104
Stufe 1.3 G1D Wie erwähnt, ist in Fig.2 eine Baumdarstellung einer nicht naher angegebenen Anfrage abgebildet. Die Wurzel 101 (oberster Knoten) enthält im Informationsfeld 201 eine Liste oder einen Array od.dgl. aller in der Hierarchiestufe 1 der übergeordneten Anfrage enthaltenen Datentabellen-Namen, wobei in der nicht angegebenen Anfrage - wie oben beschrieben - nur die Datentabellen genannt wurden, auf die Verarbeitungsfunktionen angewandt werden. Die Reihenfolge der angegebenen Datentabellen ist dabei C, A, D.
In der darauffolgenden Hierarchiestufe 1.1 ist für jede Unteranfrage der übergeordneten Anfrage jeweils ein Knoten 102, 103, 105 angelegt worden, der als Informationsfeld 202, 203, 205 die in dieser Unteranfrage verwendeten Datentabellen-Namen als Liste, Array od. dgl. beinhaltet. Die Reihenfolge ist für 102 z.B. G5E, für 103 z.B. F5I5G u.s.w.
Die Hierarchiestufe 1.2.1 stellt die Unteranfrage zur Unteranfrage 1.2 (Knoten 103) dar, die wiederum als Informationsfeld 204 die dafür verwendeten Datentabellen-Namen K5 H5 K, B enthält.
Innerhalb eines Knotens, wobei in der Wurzel 101 begonnen wird, ist jeweils die Liste der Datentabellen z.B. im Informationsfeld 201 die Datentabellen C, A, D zu durchlaufen und es werden für jeweils zwei in der Liste aufeinanderfolgende Datentabellen die Teilzugriffspfade berechnet, wobei, wie bereits vorstehend beschrieben, mehrfache Durchläufe eliminiert werden, um unnötige Produktbildungen, welche ein falsches Produkt zur Folge haben, zu vermeiden.
Dabei ist zu beachten: Ein Knoten, der direkt unter einem anderen Knoten liegt, heißt (direkter) Nachfolger dieses Knotens. Umgekehrt heißt dieser andere Knoten direkter Vorgänger.
Wurde die Liste des Informationsfeldes eines Knotens komplett durchlaufen, wird der in der Preorder-Reihenfolge nächste Knoten gesucht. Zwischen der ersten Datentabelle der Liste des Informationsfeldes dieses nächsten Knotens und der letzten Datentabelle der Liste des Informationsfeldes seines direkten Vorgängers wird der Teilzugriffspfad ermittelt, danach wird die Liste dieses nächsten Knotens bis zur letzten Datentabelle, wie vorstehend beschrieben durchlaufen. Z.B.
Knoten 104: Durchlauf der Liste der Datentabellen im Informationsfeld 204: K, H, K, B
Preorder-mäßig nächster Knoten ist der Knoten 105, dessen direkter Vorgänger aber ist Knoten 101, daher wird die Verbindung zwischen G (Knoten 105) und D (Knoten 101) gesucht und der Teilzugriffspfad errechnet. Danach erfolgt der Durchlauf der Datentabellen G, D im Informationsfeld 205 im Knoten 105 des Baumes 107.
Nach oder während des Durchlaufs eines jeden Knotens werden wie bereits erwähnt doppelte Teilzugriffspfade entfernt, dabei werden alle doppelten oder mehrfachen Datentabellen- Namen und Relationsangaben für den jeweiligen Knoten oder einer seiner Vorgänger bis einschließlich Wurzel verworfen.
Für die Berechnung jedes einzelnen Teilzugriffspfades wird z.B. wie folgt vorgegangen.
Zunächst wird die Tabelle der Relationen (Tabelle 12) in z.B. einen Graphen eingelesen, wobei die Kanten des Graphen jeweils auch die Relationen-Bedingungen enthalten, um unter Zuhilfenahme der Graphentheorie Verbindungen zwischen jeweils zwei Datentabellen über die Relationen zu ermitteln.
Für Stufe 1 ergibt sich daher im ersten Schritt C -> A als Pfad zwischen C und A als Ergebnis der z.B. kürzesten Weg-Berechnung folgende Liste:
Tabellen Relationen-Bedingungen
C B bl b B A al a
Darauffolgend A -> D ist der Pfad A, B5 C, D
Tabellen Relationen-Bedingungen A B a al
B C b bl
C D C cl
Damit ist die Liste des Informationsfeldes 201 des ersten Knoten 101 durchlaufen, jetzt erfolgt die Bereinigung wertgleicher Zeilen, das Ergebnis wird in einen String umgewandelt und in das SQL-Statement an richtiger Stelle eingefügt. (NACH DEM SELECT und VOR DEM WHERE)
Für Stufe 1 ergibt sich folgender String: FROM A5 B5 C5 D WHERE (A.a = B.al) AND (B.b = CbI) AND (Cc = D.cl)
Damit ist man an das Ende der Liste des aktuellen Knotens, hier die Wurzel, angelangt. Als nächster Schritt wird festgestellt, ob es Vorgängerknoten gibt. Im Fall der Wurzel trifft dies definitionsgemäß nicht zu.
Zusammenfassend werden daher folgende Schritte ausgeführt: Informationsfeld 201 von Knoten 101
C -> A
A -> D
Ergibt: FROM A, B, C, D WHERE (A.a = B.al) AND (B.b = CbI) AJVD (Cc = D.cl) Nächster Knoten: 102, Vorgänger-Knoten 101 erstes Datentabelle aktueller Knoten und letzte Datentabelle Vorgänger-Knoten
D -> G
Durchlaufen der Liste
G -> E Ergibt: FROM E, F, G WHERE (D.d = E.dl) AND (E.e = F.el) AND (F.f = G.fl)
Nächster Knoten: 103, Vorgänger-Knoten 101 erstes Datentabelle aktueller Knoten und letzte Datentabelle Vorgänger-Knoten
D -> F Durchlaufen der Liste
F -> I
I -> G
Ergibt: FROM E, F, G, H, I WHERE (D.d=E.dl) AND (E.tHF.el) AND (F.f=G.fl) A]VfD (G.g=H.gl) AND (H.h=I.hl) Nächster Knoten: 104, Vorgänger-Knoten 103 erstes Datentabelle aktueller Knoten und letzte Datentabelle Vorgänger-Knoten
G -> K
Durchlaufen der Liste
K -> H H -> K
K -> B
Ergibt: FROM J5 K WHERE (Li = J.il) AND (J.j = K.jl) Nächster Knoten: 105, Vorgänger-Knoten 101 erstes Datentabelle aktueller Knoten und letzte Datentabelle Vorgänger-Knoten
D -> G
Durchlaufen der Liste
G -> D
Ergibt: FROM E, F, G
WHERE (D.d = E.dl) AND (E.e = F.el) AND (F.f = G.fl)

Claims

P A T E N T A N S P R Ü C H E
1. Verfahren zur Steuerung eines relationalen Datenbanksystems durch Ausführung einer Datenbankanfrage in einer relationalen Datenbank, welche als zugeordnete Datenstruktur eine Vielzahl durch Relationen miteinander verbundene Datentabellen, sowie eine Tabelle der Relationen enthält, unter Verwendung einer Datenbanksprache,
dadurch gekennzeichnet, daß es die folgenden Schritte umfasst:
Erstellen zumindest eines tabellenübergeordneten Wertefeldes, gegebenenfalls optionale Parameter enthaltend, in einem Voreinstellungsschritt, wobei das oder die erstellten tabellenübergeordneten Wertefelder zu einer Gesamtheit von tabellenübergeordneten Wertefeldern zusammengefasst werden, und wobei jedes der erstellten tabellenübergeordneten Wertefelder einen inneren, gerichteten Entscheidungsgraphen aufweist, der unabhängig von den inneren, gerichteten Entscheidungsgraphen der anderen erstellten tabellenübergeordneten Wertefelder der Gesamtheit der tabellenübergeordneten Wertefelder definiert ist und jeweils zumindest einen Entscheidungspfad aufweist,
wobei für jedes tabellenübergeordnete Wertefeld die erforderlichen Entscheidungspfade und deren jeweilige Entscheidungspositionen durch die vorbestimmbare Auswertung der dem jeweiligen tabellenübergeordneten Wertefeld zugehörigen optionalen Parameter und/oder von vorgegebenen Funktionen bestimmt werden,
und wobei in jedem Entscheidungspfad immer zumindest eine der Entscheidungspositionen erreichbar ist, welche mittels eines zugehörigen Kennzeichens festlegt, dass diese zumindest ein Tabellenfeld enthält, das eindeutig einer der Datentabellen, gegebenenfalls mittels ergänzender Angabe eines Datentabellennamens, der konkret zugrunde liegenden Datenstruktur zuordenbar ist,
Erstellen eines Anwender-SQL-Statements durch einen Anwender in einem Formulierungsschritt, in welchem zumindest eines der tabellenübergeordneten Wertefelder aus der Gesamtheit der tabellenübergeordneten Wertefelder von dem Anwender ausgewählt und gegebenenfalls mit Parametern, in zumindest einem der Verarbeitungsbereiche in zumindest einer der Hierarchiestufen, aber unabhängig von den im Anwender-SQL-Statement verwendeten Datentabellen, bei der Formulierung des Anwender-SQL-Statements eingesetzt wird, und in welchem gegebenenfalls relationenbezogene Operationen nicht enthalten sind
- Ausführen eines nachfolgenden, automatischen Statement-Auflösungsschritts, in dem ein neues Übergangs-SQL-Statement dadurch erstellt wird, dass sämtliche im Anwender- SQL-Statement eingesetzten tabellenübergeordneten Wertefelder gegebenenfalls unter Berücksichtigung der mitgegebenen Parameter aufgerufen und durchlaufen werden und das Ergebnis dieser Durchläufe anstelle des jeweils verwendeten tabellenübergeordneten Wertefeld in das ursprünglich angegebene SQL-Statement eingesetzt wird,
wobei die inneren, gerichteten Entscheidungsgraphen der im angegebenen Anwender-SQL- Statement enthaltenen tabellenübergeordneten Wertefelder erst bei Ausführung des Statement-Auflösungsschritt in Abhängigkeit von den Verarbeitungsbereichen, in denen sie jeweils verwendet werden, für die Verarbeitung herangezogen werden,
wobei bei Aufruf der tabellenübergeordneten Wertefelder dem sich jeweils über die Auswertung der mitgegebenen Parameter aus dem Anwender-SQL-Statement und/oder der Funktionen ergebenden Entscheidungspfad des inneren, gerichteten Entscheidungsgraphen desselben bis zum Ende gefolgt wird,
und als Ergebnis eines Aufrufes und Durchlaufens der tabellenübergeordneten Wertefelder die Werte all jener erreichten Entscheidungspositionen zurückgeliefert werden, welche mittels des jeweils zugehörigen Kennzeichens festlegen, dass diese zumindest ein Tabellenfeld, das eindeutig einer der Datentabellen der konkret zugrunde liegenden Datenstruktur zuordenbar ist, enthalten, sowie alle Ergebnisse jener erreichten Entscheidungspositionen, an denen ein tabellenübergeordnetes Wertefeld mit mitgegebenen Parametern durchlaufen wird,
und somit ein Übergangs-SQL-Statement zur Verfügung steht, welches gegebenenfalls unvollständige relationenbezogene Operationen enthält
Automatisches Vervollständigen des Übergangs-SQL-Statements durch Hinzufügen gegebenenfalls fehlender und/oder unvollständiger relationenbezogener Operationen in einem Vervollständigungsschritt, wodurch ein endgültiges SQL-Statement erzeugt wird, das von jeder, den SQL-Standard unterstützenden Engine analysiert, optimiert und verarbeitet werden kann.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass bei Durchlaufen der inneren, gerichteten Entscheidungsgraphen der tabellenübergeordneten Wertefelder im Auflösungsschritt Entscheidungspositionen entlang der Entscheidungspfade erreicht werden, wobei jede Entscheidungsposition in Abhängigkeit von dem zugehörigen Kennzeichen entweder
- vermittels einer vorbestimmbaren Auswertung der zugehörigen Parameter und/oder von Funktionen jeweils von einander unabhängige Entscheidungspfade mit jeweils zumindest einer Entscheidungsposition festlegt, wobei kein Ergebnis zurückgeliefert wird, oder
- zumindest ein Tabellenfeld enthält, das eindeutig einer der Datentabellen, gegebenenfalls mittels ergänzender Angabe eines Datentabellennamens, der konkret zugrunde liegenden Datenstruktur zuordenbar ist, und diese Entscheidungsposition als Ergebnis die gesamte, an dieser Stelle angegebene Zeichenfolge enthält,
- oder das Aufrufen und Durchlaufen eines tabellenübergeordneten Wertefeldes mit konkreten Parametern aus der Gesamtheit der tabellenübergeordneten Wertefelder vorschreibt und diese Entscheidungsposition somit das Ergebnis des Durchlaufes des tabellenübergeordneten Wertefeldes enthält.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass jene Entscheidungspositionen in den Entscheidungspfaden der tabellenübergeordneten Wertefelder, welche mittels zugehörigen Kennzeichen zumindest ein Tabellenfeld enthalten, das eindeutig einer der Datentabellen der konkret zugrunde liegenden Datenstruktur zuordenbar ist, ferner eine Zeichenfolge enthalten, welche zumindest teilweise dem SQL- RTN entspricht, sodass dem SQL-RTN an beliebiger Stelle einfach oder mehrfach zumindest über Teilstrecken gefolgt wird.
4. Verfahren nach Anspruch 1, 2 oder 3, dadurch gekennzeichnet, dass als einer der Parameter für ein tabellenübergeordnetes Wertefeld sowohl bei Verwendung in einem Anwender-SQL-Statement als auch bei Einsetzen in eine der Entscheidungspositionen der Entscheidungspfade eines der tabellenübergeordneten Wertefelder zumindest entweder eine Zahl, eine Variable, ein Text, eine Funktion, eine Tabelle, ein Tabellenfeld und/oder eines der tabellenübergeordneten Wertefelder aus der Gesamtheit der tabellenübergeordneten Wertefelder als Parametertypen oder eine Auflistung zulässiger Parametertypen übergeben wird.
5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass in einem Hierarchiestufen-Analyse-Schritt als Teil des Statement-Auflösungsschrittes für jedes im Anwender-Statement angegebene tabellenübergeordnetes Wertefeld folgende Schritte ausgeführt werden:
Feststellen der Hierarchiestufe und deren gegebenenfalls übergeordnete Hierarchiestufen, in welcher das jeweilige tabellenübergeordnete Wertefeld im Anwender-SQL-Statement verwendet wird
- Auswählen jener im Anwender-SQL-Statement verwendeten Datentabellen, welche sich in der festgestellten und in der ihr übergeordneten Hierarchiestufe befinden und Speichern derselben als Analyse-Hierarchiestufen-Tabellenmenge
- Auswählen aller Datentabellen aus dem Ergebnis, welches bei Aufrufen und Durchlaufen des jeweiligen tabellenübergeordneten Wertefeldes mit den laut
Anwender-SQL-Statement gegebenenfalls mitgegebenen Parametern geliefert wird und Speichern derselben als Analyse-Ergebnis-Tabellenmenge
- Feststellen, ob in der Analyse-Ergebnis-Tabellenmenge zumindest eine Datentabelle vorhanden ist, welche nicht in der Analyse-Hierarchiestufen-Tabellenmenge vorkommt und, sofern dies der Fall ist:
- Einfügen des Ergebnisses des Aufrufens und Durchlaufens des tabellenübergeordneten Wertefeldes in eine der festgestellten Hierarchiestufe untergeordneten Hierarchiestufe im Übergangs-SQL-Statement.
6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass in jenen Hierarchiestufen, in welchen nach zumindest einem Tabellenfeldwert gruppiert wird, nur jene Tabellenfelder als Datentabellen ausgewählt werden, auf welche die Gruppierung angewandt wird.
7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass im RTN von SQL der Produktbildungs- Verarbeitungsbereich, der die in der jeweiligen Hierarchiestufe zu verwendenden Datentabellen enthält und die Bildung eines kartesischen Produktes für dieselben beschreibt, nur als optionaler Entscheidungspfad definiert ist,
und in jenen Fällen, in denen dieser Produktbildungs- Verarbeitungsbereich im Anwender- SQL-Statement nicht angegeben ist, dieser in einem späteren Schritt automatisch erstellt wird und, beispielsweise mittels einer Tabelle der Relationen, sämtliche zur Auflösung des Anwender-SQL-Statements benötigten Datentabellen ermittelt in diesem Verarbeitungsbereich und eingefügt werden,
und die relationenbezogenen Operationen, welche zwischen den eingefügten Datentabellen unter der Berücksichtigung der Hierarchiestufe vorhanden sind, automatisch in den Kriterien- Verarbeitungsbereich (WHERE) des Übergangs-SQL-Statement und somit auch in das endgültigen SQL-Statements eingefügt werden.
8. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass jene Entscheidungspositionen im RTN von SQL, an welchen ein Tabellenname unabhängig von den Verarbeitungsbereichen angegeben werden kann, derart erweitert werden, dass anstatt eines Tabellennamens ein tabellenübergeordnetes Wertefeld an diesen Entscheidungspositionen zugelassen wird, wobei auf ein tabellenübergeordnetes Wertefeld nicht zwingend weitere Entscheidungspositionen folgen müssen, und die von dieser RTN- Erweiterung betroffenen Anwender-SQL-Statements im Auflösungs-Schritt zuerst in ein Übergangs-SQL-Statement und nachfolgend in ein endgültiges SQL-Statement umgewandelt werden
9. Verfahren nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass jene Entscheidungspositionen im RTN von SQL, an welchen ein Tabellenfeldname unabhängig von den Verarbeitungsbereichen angegeben werden kann, derart erweitert werden, dass anstatt eines Tabellenfeldnamens ein tabellenübergeordnetes Wertefeld an diesen Entscheidungspositionen zugelassen wird, wobei auf das tabellenübergeordnete Wertefeld nicht zwingend weitere Entscheidungspositionen folgen müssen, und die von dieser RTN- Erweiterung betroffenen Anwender-SQL-Statements im Auflösungs-Schritt zuerst in ein Übergangs-SQL-Statement und nachfolgend in ein endgültiges SQL-Statement umgewandelt werden und
wobei das tabellenübergeordnete Wertefeld im Statement-Auflösungsschritt in einer, der dieses tabellenübergeordnete Wertefeld enthaltenden, direkt untergeordneten Hierarchiestufe, eingefügt wird.
10. Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass jene Entscheidungspositionen im RTN von SQL, an welchen ein Tabellenname unabhängig von den Verarbeitungsbereichen angegeben werden kann, derart erweitert werden, dass auf diese Tabellennamen optional ein Verbindungszeichen, vorzugsweise ein Punkt, gefolgt von einer Tabelle, einem Tabellenfeld, einem tabellenübergeordneten Wertefeld, einer Vergleichsoperation, oder einer Aggregatsfunktion zugelassen wird.
11. Verfahren nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, dass jene Entscheidungspositionen im RTN von SQL, an welchen ein Tabellenfeldname unabhängig von den Verarbeitungsbereichen angegeben werden kann, derart erweitert werden, dass auf diese Tabellenfeldnamen optional ein Verbindungszeichen, vorzugsweise ein Punkt, gefolgt von einer Tabelle, einem Tabellenfeld, einem tabellenübergeordneten Wertefeld, einer Vergleichsoperation oder einer Aggregatsfunktion zugelassen wird.
12. Verfahren nach einem der Ansprüche 1 bis 11, dadurch gekennzeichnet, dass jene Entscheidungspositionen, an welchen ein tabellenübergeordnetes Wertefeld unabhängig von den Verarbeitungsbereichen angegeben werden kann, derart erweitert, dass auf diese tabellenübergeordneten Wertefelder optional ein Verbindungszeichen, vorzugsweise ein Punkt, gefolgt von einer Tabelle, einem Tabellenfeld, einem tabellenübergeordneten Wertefeld, einer Vergleichsoperation oder einer Aggregatsfunktion zugelassen wird,
wobei nachfolgenden Vergleichsoperationen als zusätzliche Parameter für das jeweilige tabellenübergeordnete Wertefeld angenommen werden, und wobei
sämtliche anderen mit dieser Entscheidungsposition in Verbindung stehenden Entscheidungspositionen mit dem Statement- Auflösungsschritt verarbeitet werden.
13. Verfahren nach einem der Ansprüche 1 bis 12, dadurch gekennzeichnet, dass das Übergangs-SQL-Statement in Form einer Datenbankanweisung ohne relationenbezogene Operationen vorliegt, in der nur jene Verarbeitungsfunktionen, nur jene Datentabellen und deren Spalten aus der Vielzahl der über die Relationen miteinander verbundenen Datentabellen enthalten sind, auf die entsprechend der Fragestellung des Anwenders Verarbeitungsfunktionen angewandt werden, und in der die Reihenfolge sowie die Hierarchiestufe, mit der die Abarbeitung zu erfolgen hat, angegeben sind,
und in einem Relationen-Vervollständigungsschritt, welcher auf das Übergangs-SQL- Statement angewandt wird und welcher dem Auflösungsschritt folgt, ein Zugriffspfad ermittelt wird, der eine Zugriffsreihenfolge auf die Datenbank konkret vorgibt, indem über die
Tabelle der Relationen zwischen jeweils zwei aufeinander folgenden, ausgewählten
Datentabellen ein Teilzugriffspfad auf Basis der zwischen den aufeinander folgenden
Datentabellen vorhandenen Relationen berechnet wird, und aus allen errechneten Teilzugriffspfaden der Zugriffspfad zusammengesetzt wird.
14. Verfahren nach Anspruch 13, dadurch gekennzeichnet, dass zur Ermittlung der Teilzugriffspfade die Tabelle der Relationen in einen auf der Graphentheorie basierenden Graphen eingelesen und unter Zuhilfenahme des gebildeten Graphen die Teilzugriffspfade berechnet werden.
15. Relationales Datenbanksystem, welches ein Computersystem mit einer relationalen Datenbank, eine Datenverarbeitungseinheit und einen Speicher umfaßt, wobei die Datenverarbeitungseinheit nach dem Verfahren nach einem der Ansprüche 1 bis 14 arbeitet.
16. Datenträger mit einer mit in einer Datenbanksprache angegebenen Datenbankanweisung zur Steuerung und zum Einlesen in ein relationales Datenbanksystem nach Anspruch 15, dadurch gekennzeichnet, dass die auf dem Datenträger vorliegende Datenbankanweisung erstellt ist, indem folgende Schritte ausgeführt wurden:
Erstellen zumindest eines tabellenübergeordneten Wertefeldes, gegebenenfalls optionale Parameter enthaltend, in einem Voreinstellungsschritt, wobei das oder die erstellten tabellenübergeordneten Wertefelder zu einer Gesamtheit von tabellenübergeordneten Wertefeldern zusammengefasst werden, und wobei jedes der erstellten tabellenübergeordneten Wertefelder einen inneren, gerichteten Entscheidungsgraphen aufweist, der unabhängig von den inneren, gerichteten Entscheidungsgraphen der anderen erstellten tabellenübergeordneten Wertefelder der Gesamtheit der tabellenübergeordneten Wertefelder definiert ist und jeweils zumindest einen Entscheidungspfad aufweist,
wobei für jedes tabellenübergeordnete Wertefeld die erforderlichen Entscheidungspfade und deren jeweilige Entscheidungspositionen durch die vorbestimmbare Auswertung der dem jeweiligen tabellenübergeordneten Wertefeld zugehörigen optionalen Parameter und/oder von vorgegebenen Funktionen bestimmt werden,
und wobei in jedem Entscheidungspfad immer zumindest eine der Entscheidungspositionen erreichbar ist, welche mittels eines zugehörigen Kennzeichens festlegt, dass diese zumindest ein Tabellenfeld enthält, das eindeutig einer der Datentabellen, gegebenenfalls mittels ergänzender Angabe eines Datentabellennamens, der konkret zugrunde liegenden Datenstruktur zuordenbar ist,
Erstellen eines Anwender-SQL-Statements durch einen Anwender in einem Formulierungsschritt, in welchem zumindest eines der tabellenübergeordneten Wertefelder aus der Gesamtheit der tabellenübergeordneten Wertefelder von dem Anwender ausgewählt und gegebenenfalls mit Parametern, in zumindest einem der Verarbeitungsbereiche in zumindest einer der Hierarchiestufen, aber unabhängig von den im Anwender-SQL-Statement verwendeten Datentabellen, bei der Formulierung des Anwender-SQL-Statements eingesetzt wird, und in welchem gegebenenfalls relationenbezogene Operationen nicht enthalten sind
- Ausführen eines nachfolgenden, automatischen Statement-Auflösungsschritts, in dem ein neues Übergangs-SQL-Statement dadurch erstellt wird, dass sämtliche im Anwender- SQL-Statement eingesetzten tabellenübergeordneten Wertefelder gegebenenfalls unter Berücksichtigung der mitgegebenen Parameter aufgerufen und durchlaufen werden und das Ergebnis dieser Durchläufe anstelle des jeweils verwendeten tabellenübergeordneten Wertefeld in das ursprünglich angegebene SQL-Statement eingesetzt wird,
wobei die inneren, gerichteten Entscheidungsgraphen der im angegebenen Anwender-SQL- Statement enthaltenen tabellenübergeordneten Wertefelder erst bei Ausführung des Statement-Auflösungsschritt in Abhängigkeit von den Verarbeitungsbereichen, in denen sie jeweils verwendet werden, für die Verarbeitung herangezogen werden,
wobei bei Aufruf der tabellenübergeordneten Wertefelder dem sich jeweils über die Auswertung der mitgegebenen Parameter aus dem Anwender-SQL-Statement und/oder der Funktionen ergebenden Entscheidungspfad des inneren, gerichteten Entscheidungsgraphen desselben bis zum Ende gefolgt wird,
und als Ergebnis eines Aufrufes und Durchlaufens der tabellenübergeordneten Wertefelder die Werte all jener erreichten Entscheidungspositionen zurückgeliefert werden, welche mittels des jeweils zugehörigen Kennzeichens festlegen, dass diese zumindest ein Tabellenfeld, das eindeutig einer der Datentabellen der konkret zugrunde liegenden Datenstruktur zuordenbar ist, enthalten, sowie alle Ergebnisse jener erreichten Entscheidungspositionen, an denen ein tabellenübergeordnetes Wertefeld mit mitgegebenen Parametern durchlaufen wird,
und somit ein Übergangs-SQL-Statement zur Verfügung steht, welches gegebenenfalls unvollständige relationenbezogene Operationen enthält,
Automatisches Vervollständigen des Übergangs-SQL-Statements durch Hinzufügen gegebenenfalls fehlender und/oder unvollständiger relationenbezogener Operationen in einem
Vervollständigungsschritt, wodurch ein endgültiges SQL-Statement erzeugt wird, das von jeder, den SQL-Standard unterstützenden Engine analysiert, optimiert und verarbeitet werden kann.
17. Computeφrogramm, das Instruktionen aufweist, die zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 15 eingerichtet ist.
18. Computerprogrammprodukt, welches ein computerlesbares Medium mit Computerprogramm-Code-Mitteln aufweist, bei dem jeweils nach dem Laden des Computerprogramms ein Computer durch das Programm zur Durchführung des Verfahren nach einem der Ansprüche 1 bis 15 veranlasst wird.
19. Computerprogrammprodukt, welches ein Computerprogramm auf einem elektronischen Trägersignal aufweist, bei dem jeweils nach Laden des Computerprogramms ein Computer durch das Programm zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 15 veranlasst wird.
PCT/AT2007/000195 2007-04-27 2007-04-27 Verfahren zur steurerung eines relationalen datenbanksystems Ceased WO2008131465A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/AT2007/000195 WO2008131465A1 (de) 2007-04-27 2007-04-27 Verfahren zur steurerung eines relationalen datenbanksystems

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/AT2007/000195 WO2008131465A1 (de) 2007-04-27 2007-04-27 Verfahren zur steurerung eines relationalen datenbanksystems

Publications (1)

Publication Number Publication Date
WO2008131465A1 true WO2008131465A1 (de) 2008-11-06

Family

ID=38121941

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/AT2007/000195 Ceased WO2008131465A1 (de) 2007-04-27 2007-04-27 Verfahren zur steurerung eines relationalen datenbanksystems

Country Status (1)

Country Link
WO (1) WO2008131465A1 (de)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110222128A (zh) * 2019-06-12 2019-09-10 浪潮软件集团有限公司 一种生成数据预置sql的方法及装置
CN114397967A (zh) * 2022-01-07 2022-04-26 山东浪潮科学研究院有限公司 一种数据库的辅助输入关键字自动联想方法
CN114397966A (zh) * 2022-01-06 2022-04-26 山东浪潮科学研究院有限公司 一种数据库的关键字纠错提示方法及装置
CN114548794A (zh) * 2022-02-25 2022-05-27 首约科技(北京)有限公司 一种基于动调的提高表处理速度的方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1995006292A1 (en) * 1993-08-25 1995-03-02 Asymetrix Corporation Method and apparatus for the modeling and query of database structures using natural language-like constructs
US5987455A (en) * 1997-06-30 1999-11-16 International Business Machines Corporation Intelligent compilation of procedural functions for query processing systems
WO2000063798A1 (en) * 1999-04-16 2000-10-26 Targit A/S A method and an apparatus for the processing of queries to a database
US20040073539A1 (en) * 2002-10-10 2004-04-15 International Business Machines Corporation Query abstraction high level parameters for reuse and trend analysis
EP1585036A2 (de) * 2004-04-08 2005-10-12 International Business Machines Corporation Verwaltung parametrisierter Datenbankabfragen

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1995006292A1 (en) * 1993-08-25 1995-03-02 Asymetrix Corporation Method and apparatus for the modeling and query of database structures using natural language-like constructs
US5987455A (en) * 1997-06-30 1999-11-16 International Business Machines Corporation Intelligent compilation of procedural functions for query processing systems
WO2000063798A1 (en) * 1999-04-16 2000-10-26 Targit A/S A method and an apparatus for the processing of queries to a database
US20040073539A1 (en) * 2002-10-10 2004-04-15 International Business Machines Corporation Query abstraction high level parameters for reuse and trend analysis
EP1585036A2 (de) * 2004-04-08 2005-10-12 International Business Machines Corporation Verwaltung parametrisierter Datenbankabfragen

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
JARKE M ED - KERSCHBERG L UNIVERSITY OF SOUTH CAROLINA: "EXTERNAL SEMANTIC QUERY SIMPLIFICATION: A GRAPH-THEORETIC APPROACH AND ITS IMPLEMENTATION IN PROLOG", EXPERT DATABASE SYSTEMS. KIAWAH ISLAND, SOUTH CAROLINA, OCT. 24 - 27, 1984, PROCEEDINGS OF THE INTERNATIONAL WORKSHOP ON EXPERT DATABASE SYSTEMS, MENLO PARK, CA., BENJAMIN/CUMMINGS, US, vol. WORKSHOP 1, October 1984 (1984-10-01), pages 675 - 692, XP000745618 *
MITSCHANG B ET AL: "SQL/XNF-Processing composite objects as abstractions over relational data", PROCEEDINGS OF THE INTERNATIONAL CONFERENCE ON DATA ENGINEERING. VIENNA, APR. 19 - 23, 1993, LOS ALAMITOS, IEEE COMP. SOC. PRESS, US, vol. CONF. 9, 19 April 1993 (1993-04-19), pages 272 - 282, XP010095515, ISBN: 0-8186-3570-3 *
STONEBRAKER M ET AL: "EXTENDING A DATABASE SYSTEM WITH PROCEDURES", ACM TRANSACTIONS ON DATABASE SYSTEMS, ACM, NEW YORK, NY, US, vol. 12, no. 3, September 1987 (1987-09-01), pages 350 - 376, XP000718766, ISSN: 0362-5915 *
YANNAKOUDAKIS E J ET AL: "A DOMAIN-ORIENTED APPROACH TO IMPROVE THE USER-FRIENDLINESS OF SQL", COMPUTER STANDARDS AND INTERFACES, ELSEVIER SEQUOIA. LAUSANNE, CH, vol. 9, no. 2, January 1989 (1989-01-01), pages 127 - 141, XP000083601, ISSN: 0920-5489 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110222128A (zh) * 2019-06-12 2019-09-10 浪潮软件集团有限公司 一种生成数据预置sql的方法及装置
CN110222128B (zh) * 2019-06-12 2022-10-14 浪潮软件集团有限公司 一种生成数据预置sql的方法及装置
CN114397966A (zh) * 2022-01-06 2022-04-26 山东浪潮科学研究院有限公司 一种数据库的关键字纠错提示方法及装置
CN114397967A (zh) * 2022-01-07 2022-04-26 山东浪潮科学研究院有限公司 一种数据库的辅助输入关键字自动联想方法
CN114548794A (zh) * 2022-02-25 2022-05-27 首约科技(北京)有限公司 一种基于动调的提高表处理速度的方法

Similar Documents

Publication Publication Date Title
DE69602364T2 (de) Rechnersystem um semantische objektmodelle von existierenden relationellen datenbanksystemen herzustellen
DE3855706T2 (de) Automatisierte Rechnung von Materialien
DE69424586T2 (de) Verfahren und System zum formulieren interaktiver Abfragen
DE69418474T2 (de) Semantisches objektmodellierungssystem und verfahren um relationelle datenbankschemata herzustellen
DE10028688B4 (de) Methode, System und Programm für eine Verbindungsoperation in einer mehrspaltigen Tabelle sowie in Satellitentabellen mit doppelten Werten
DE69509118T2 (de) Implementierungsunabhängige erweiterbare abfragearchitektur für systeme zur informationswiederauffindung
DE60002876T2 (de) Darstellung, verwaltung und synthese von technischen inhalten
DE69408337T2 (de) Steuersystem einer relationellen datenbank gemäss einer objekt-orientierten logik, die die zugriffe auf die datenbank verringert, und entsprechendes verfahren
DE60004385T2 (de) Verfahren und systeme um olap hierarchien zusammenfassbar zu machen
DE60208778T2 (de) Datenstruktur für informationssysteme
DE69904588T2 (de) Datenbankzugangswerkzeug
DE3688529T2 (de) Verfahren zur Auffrischung von Mehrspaltentabellen in einer relationellen Datenbank mit Mindestinformation.
DE69232542T2 (de) Definitionsänderungssprache für ein Datenbankrechnersystem
EP0910829B1 (de) Datenbanksystem
DE60130475T2 (de) Durchführung von kalkulationen eines tabellenkalkulationstyps in einem datenbanksystem
US5761654A (en) Memory structure and method for tuning a database statement using a join-tree data structure representation, including selectivity factors, of a master table and detail table
DE69514123T2 (de) Datenbanksuchsystem
EP0855062B1 (de) Informationssystem und verfahren zur speicherung von daten in einem informationssystem
DE69533193T2 (de) Paralleles verarbeitungssystem zum durchlaufen einer datenbank
DE10103574A1 (de) Aggregierte Prädikate und Suche in einem Datenbankverwaltungssystem
DE60300984T2 (de) Methode und Computersystem für die Optimierung eines Boolschen Ausdrucks für Anfragebearbeitung
DE10056763B4 (de) Generieren von Einschränkungsabfragen mit Hilfe von Tensordarstellungen
DE102004043788A1 (de) Programm Generator
EP2021952A1 (de) Verfahren zum steuern eines relationalen datenbanksystems
DE102012100113A1 (de) Verfahren, Software und Computersystem zur Handhabung von angesammelten Daten

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07718411

Country of ref document: EP

Kind code of ref document: A1

DPE2 Request for preliminary examination filed before expiration of 19th month from priority date (pct application filed from 20040101)
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 07718411

Country of ref document: EP

Kind code of ref document: A1