System and method for configuring, sequencing and viewing joins in a query

[0002] 1. Technical Field

[0003] The present invention is directed to the field of database queries. More specifically, the invention provides a system and method for configuring, sequencing and viewing joins in a database query.

[0004] 2. Description of the Related Art

[0005] In today's information economy, companies increasingly rely on information systems to remain competitive. Foremost among these information systems are database management systems that utilize relational databases. These systems are generally referred to as relational database management systems. Relational databases organize data records into a multitude of interconnected tables. Each table consists of rows and columns of data from the data records stored in the database. The rows of data are also known as tuples.

[0006] A relational database management system typically includes software for searching and retrieving data records from the relational database. The most common means for accomplishing this search and retrieval task is the Structured Query Language (SQL). SQL provides a software framework for logically structuring complex conditional expressions (i.e., relationships) for querying a database. SQL includes many different types of logical constructs, including the WHERE clause, the SELECT statement, the HAVING clause, and the ON clause. A WHERE clause is typically structured as follows: WHERE (variable 1 <operator> condition 1) link (variable 2 <operator> condition 2). The WHERE clause returns data records from the database that meet the two conditional expressions (variable 1 <operator> condition 2) link (variable 2 <operator> condition 2), depending on the type of link. Two common forms of link operators for conditional expressions are the “AND” link and the “OR” link.

[0007] The SQL ON clause typically forms part of the SQL SELECT statement, and it is used to define a set of relationships (conditional expressions) that are associated with joining two or more tables. In SQL syntax, a join may be defined as a relational operation that allows a program to retrieve data from two or more tables based on matching column values. IBM Dictionary of Computing, 10th Edition, p. 365. The SQL join operation combines the data rows (or tuples) from two or more tables into a result set according to the relationships expressed in the ON clause, and also according to the type of join. The result set is a data table that includes the merged data rows from the two or more tables operated on by the join that meet the relationships set in the ON clause.

[0008] In an SQL statement that includes more than one join operation, there are two types of result sets, a final result set and one or more intermediate result sets. The final result set is the final table that is generated from the tables being joined after all the join operations are executed. The intermediate result set is the intermediate table that is generated from just two of the tables (or one table and another intermediate result set) being joined in one of the join operations. As discussed below, certain types of joins, such as the outer join, internally produce intermediate result sets.

[0009] A generic SQL statement for generating a result set from a join operation may be expressed as follows:

[0010] SELECT [Cols] from [Table 1] join type [Table 2] ON {CONDITION =<relationship 1 > operator <relationship 2> operator <relationship N> }.

[0011] Here, Table 1 and Table 2 are the two tables operated on by the join. There are several different types of join that can be used to merge data from tables. The most common join types include the inner join, the left outer join, the right outer join, and the full outer join.

[0012] The condition of the ON clause includes one or more relationships coupled together by one or more operators. For example, relationship 1 could be “Table1.column1 =Table2.column1” and relationship 2 could be “Table1.column2 =Table2.column2.” The operator that couples relationship 1 to relationship 2 could be the AND operator, or it could be some other type of logical operator. In this example, the condition of the join is met when the data entry in the first column of the first table is equal to the data entry in the first column of the second table and where the data entry in the second column of the first table is equal to the data entry in the second column of the second table.

[0013] An inner join of two tables returns only the rows in each table that meet the condition in the ON clause—i.e., the matching rows. In the left, right and full outer joins, however, rows in one of the tables may be returned into the result set even though there are no matching rows in the other table (or intermediate result set). In a left outer join the left table is preserved, meaning that all of the matching and non-matching rows from the left table are returned into the result set. For the right table in the left outer join, only the matching rows are returned, similar to the inner join. Likewise, in a right outer join the right table is preserved, so that all of the matching and non-matching rows from the right table are returned into the result set and only the matching rows from the left table are returned. The syntax left versus right in a join operation is determined by the placement of the table in the SQL statement. In the example above, Table1 is the left table and Table2 is the right table. A full outer join combines the rows that are returned from both a left and a right outer join.

[0014] Graphical interfaces for visually depicting tables and their relationships are known in this field. These graphical interfaces generally depict the tables as boxes. The boxes may include the title of the table and a listing of the various column variables. Relationships between the tables are then depicted as lines that connect a column variable in one table to a column variable in another table. Numerous relationships may be depicted between the tables, and thus there is often more than one line connecting the tables together. In order to set the join type between two tables, a user typically selects one of the column relationships (i.e., picks a line that connects the tables) and then sets the joint type based on the selected relationship.

[0015] In a query tool that only permits inner joins, these known interfaces provide some utility. In a tool that enables more complex join operations, however, such as the various forms of outer joins discussed above, these known interfaces suffer from two significant problems. The first problem relates to the ambiguity created when there is more than one relationship between the tables and the user selects one of the relationships and sets the join type to an outer join. The problem here is how to configure the other non-selected relationship(s) that connect the two tables. One way to configure these other relationships is to assume that they represent AND conditions to the relationship that was set to an outer join. But another way is to configure these other relationships as separate joins. This outer join ambiguity problem inherently results from setting the join type based upon one of the column relationships.

[0016] The second problem with these known interfaces and tools relates to properly sequencing the order in which the tables are joined. Like the first problem, this second problem does not typically apply to a tool that only permits inner joins. For the more complex tool, however, which permits various forms of outer joins, the issue of proper table sequence is important. The final result set of a query may change depending upon the order (sequence) of the tables in the generated SQL when there are one or more outer joins. This occurs because the outer join operation internally produces an intermediate result set, which is then joined with subsequent tables in the join. Thus, changing the sequencing of the tables can change the query results when outer joins are involved. Known query tools and interfaces do not address this problem in any significant manner. Instead, these tools simply assume that the user has ordered the tables properly when the tables are selected during the process of building the query. This assumption, however, is often incorrect, and can lead to improper query results.

[0017] A system and method for configuring, sequencing and viewing joins in a query is provided. The system includes an advanced joins viewer that may be invoked from an SQL Query Tool. A graphical user interface associated with the advanced joins viewer displays a sequenced vertical tile list of each table and each intermediate result set in a particular query.

[0018] Through this interface, a user may re-sequence the ordering of the tables and thus reconfigure the intermediate result sets that are generated by the query. The advanced joins viewer enables the independent configuration of the join type and the join relationships for each of the intermediate result sets. An automatic sequencing algorithm is also provided for configuring the ordering of the tables such that the query produces valid SQL.

[0019] According to one aspect of the invention, a system for configuring, sequencing and displaying joins in a query is provided. The system is software based, and includes a sequence display window for depicting the sequence in which a plurality of tables are joined in the query, and for selecting an intermediate result set comprising two or more of the depicted tables; and a join configuration and display window for displaying the selected intermediate result set, including a table display for depicting the tables associated with the intermediate result set, a join type selector for configuring the type of join for the intermediate result set, and a relationships display window for depicting one or more relationships between the tables in the intermediate result set.

[0020] According to another aspect of the invention, a software tool is provided for creating SQL queries. The software tool includes a graphical user interface for selecting tables and for defining relationships between the tables, and an advanced joins viewer for depicting one or more intermediate result sets comprising two or more of the selected tables, and for configuring the joins between the tables independently of any defined relationships.

[0021] Still another aspect of the invention provides a method of configuring joins in an SQL query, comprising the steps of: (a) adding two or more tables to the query; (b) setting column relationships between the two or more tables; (c) selecting an intermediate result set from the two or more tables added to the query; (d) displaying the join type and column relationships for the selected intermediate result set; and (e) configuring the join type for the intermediate result set independently of the column relationships.

[0022] Another aspect of the invention provides a method of configuring joins in a database management system, comprising the steps of: (i) selecting a plurality of tables from a relational database; (ii) setting a plurality of relationships between the plurality of tables; (iii) displaying a sequenced listing of the selected tables; (iv) selecting an intermediate result set comprising two or more of the selected tables; (v) displaying a plurality of join types for the intermediate result set; and (vi) selecting a join type for the intermediate result set independently from the plurality of relationships.

[0023] Yet another aspect of the invention provides a method of automatically sequencing tables joined in an SQL query, comprising the steps of: (a) providing a join object for each table, wherein the join object includes a table relationships list that sets forth related tables; (b) providing a first list of the tables in the SQL query; (c) moving a first table from the first list into a second list and deleting the first table from the first list; (d) determining whether the first table has a related table in its table relationships list, and, if so, then moving the related table from the first list to the second list and deleting the related table from the first list; (e) repeating step (d) until a selected table has no related table in its table relationships list; (f) fetching a second table from the first list; (g) determining whether the second table has a related table in its table relationships list that has been moved to the second list, and, if so, then moving the related table from the first list to the second list and deleting the related table from the first list; and (h) repeating steps (d) through (g) until there are no tables remaining in the first list.

[0024] Another aspect of the invention provides a computer-implemented process for sequencing and configuring joins in an SQL query, comprising the steps of: (i) graphically building an SQL query having a plurality of tables, wherein the tables are related by a plurality of table relationships; (ii) automatically sequencing the tables in order to generate a valid SQL query; (iii) graphically depicting the sequencing of the tables as a plurality of intermediate result sets; (iv) selecting one of the intermediate result sets; and (v) configuring the join type for the selected intermediate result set independently from the plurality of table relationships.

[0025] Still another aspect of the invention provides a method of visually depicting and modifying the sequence of joins in a query, comprising the steps of: (a) generating a sequence display window comprising a plurality of tiles, wherein each tile corresponds to a table in the query that is joined to some other table; (b) ordering the tiles in a particular sequence; (c) selecting one of the tiles to be re-ordered in the sequence; (d) graphically moving the selected tile from a first position in the sequence to a second position in the sequence; and (e) re-ordering the tiles so that the selected tile is depicted in the second position in the sequence.

[0026] It should be noted that these are just some of the many aspects of the present invention. Other aspects not specified will become apparent upon reading the detailed description of the preferred embodiment set forth below.

[0027] FIG. 1 is a graphical user interface of an SQL Query Tool for creating and manipulating SQL queries;

[0028] FIG. 2 is a graphical user interface of an advanced joins viewer associated with the SQL Query Tool for configuring, sequencing and viewing joins according to the present invention, showing the join type and join relationships of the tables involved in a join between a table and an intermediate result set formed by two other tables;

[0029] FIG. 3 is another depiction of the advanced joins viewer shown in FIG. 2, showing the join type and join relationships of the tables involved in a join between two tables;

[0030] FIG. 4A is a partial depiction of the advanced joins viewer showing the process of manually re-sequencing tables in the query;

[0031] FIG. 4B is another depiction of the advanced joins viewer shown in FIG. 2, in which a new intermediate result set is displayed following the manual re-sequencing of the tables depicted in FIG. 4A;

[0032] FIG. 5 is a generic depiction of the sequence display window of the advanced joins viewer shown in FIG. 2;

[0033] FIG. 6 is a flowchart showing the preferred method of creating and manipulating queries using the SQL Query Tool;

[0034] FIG. 7 is a flowchart showing the preferred method of configuring, sequencing and displaying joins using the advanced joins viewer of the present invention;

[0035] FIG. 8 is a flowchart showing the preferred method of automatically sequencing the tables in the query; and

[0036] FIG. 9 is a preferred join object for use with the automatic sequencing method described in FIG. 8.

[0037] Turning now to the drawings, FIG. 1 sets forth a graphical user interface 10 of an SQL Query Tool 10 for creating and manipulating SQL queries. The SQL Query Tool 10 is preferably implemented as a software program that is part of a comprehensive data mining application for use in data analysis and search and retrieval operations on a relational database. An example of such a data mining application is Enterprise Miner, which is available from SAS Institute, of Cary, N.C. Alternatively, however, the SQL Query Tool 10 may be a stand-alone software application, a downloadable applet, or some other form of software-based application. This software may be embodied in a tangible medium, or product, such as a magnetic medium, or an optical medium such as a CD-ROM.

[0038] Several graphical user interface elements are included in the preferred SQL Query Tool 10, such as a menu bar 12, an icon bar 14, a plurality of SQL operator tabs 18A-18E, a table selection window 20, a tables and relations window 22, and a data item editing window 24. The menu bar 12 and the icon bar 14 (which are also referred to as toolbars) are well-known graphical elements in the field of windows interfaces. The menu bar 12 provides a hierarchical drop-down list of the features and functions of the Tool 10. The icon bar 14 is similar in nature to the menu bar 12, except that instead of a hierarchical drop-down list, the icon bar 14 displays an icon associated with commonly-used features and functions of the Tool 10. One of the functions of the SQL Query Tool 10 that is preferably represented in both the menu bar 12 and the icon bar is the advanced joins viewer (described in more detail below.) The advanced joins viewer icon selection is shown as icon 16.

[0039] The remaining graphical elements shown in FIG. 1 are more specific to the functionality of the SQL Query Tool 10. Displayed just below the icon bar 16 is a set of Query Operation tabs, including a query tab 18A, a data filters tab 188B, a group filters tab 18C, a results tab 18D, and an SQL tab 18E. Together, these tabs provide a set of functions for creating and manipulating SQL queries. The query tab 18A is selected in FIG. 1, and displays the additional windows 20, 22, 24 for visually building an SQL statement by forming relationships between a plurality of tables from the relational database. The data filters tab 18B is used to build a graphical representation of a data filter query using the SQL WHERE clause, as described in more detail in co-pending patent application Ser. No. 09/585,079, U.S. Pat. No. 6,470,335 entitled “System and Method for Optimizing the Structure and Display of Complex Data Filters, ” the disclosure of which is hereby incorporated into this application by reference. The group filters tab 18C is used to build a data filter using the SQL HAVING clause. The results tab 18D displays the final result set that is returned from the relational database in response to the query. And the SQL tab 18E is selected in order to automatically generate the textual SQL query based on the visual representations constructed using the query, data filters and group filters tabs 18A, 18B, and 18C.

[0040] The query tab 18A displays several windows 20, 22, 24 for visually building an SQL SELECT statement, including a table selection window 20, a tables and relations window 22, and a relationship editing window 24. (Although the term “window” is used to describe these graphical elements, one of ordinary skill in the art would understand that these “windows” would not necessarily take up the entire display screen and could alternatively be termed “subwindows,” “frames,” or “panes.”) In the table selection window 20, a hierarchical display of the tables included in a particular relational database is set forth. For example, in FIG. 1, a database named “SAMPLES” is shown, which includes several tables, such as a “CUSTOMER” table, an “EMPLOYEE” table, and an “ORDERS” table, as well as many other tables. A user of the Query Tool 10 can add a table to the SQL SELECT statement under construction by selecting the name of the table, such as EMPLOYEE, from the table selection window 20. This selection step is typically accomplished by “clicking” the text “EMPLOYEE” in the selection window 20 using a pointer device, such as a mouse.

[0041] When the user “clicks” the EMPLOYEE entry in the window 20, a corresponding box 30A is displayed in the tables and relations window 22 that depicts the selected table. The depiction of the selected table 30A includes a title, such as EMPLOYEE, and also includes the column names 32 that comprise the table. By selecting several tables 30A, 30B, 30C, the user of the tool 10 can create a complex SELECT statement including multiple tables.

[0042] Having selected the tables 30A, 30B, 30C using the window 20, the user then adds relationships 34A, 34B, 34C, 34D between the tables using the tables and relations window 22.

[0043] Here, the user sets a relationship by connecting a column in one table with a column in another table. This relationship setting step is preferably accomplished by selecting (or “clicking”) on one of the columns in one of the tables and “dragging” that column on top of a column in another table using the pointing device. Alternatively, the relationship setting step may be accomplished through a menu bar 12 selection, through an icon 14 selection, though a context menu selection, or automatically via algorithms or through associated metadata. A context menu selection is a pop-up menu that is displayed when the user selects a particular table in the tables and relations window 22 and then “right clicks” using the pointing device. In any case, a user selects two columns that will take part in the relationship, and the Tool 10 then displays a graphical line 34A, 34B, 34C, 34D that connects the selected columns.

[0044] In the example shown in FIG. 1, a user has selected three tables, EMPLOYEE, CUSTOMER, and ORDERS. The tables are displayed left-to-right in the order in which they were selected by the user. Thus, EMPLOYEE was selected first, CUSTOMER second, and ORDERS third. The user has then created four illustrative relationships between the three tables. Each of these relationships is depicted by a line 34A, 34B, 34C, 34D, which connects the relevant columns in each table. Thus, relationship 34A is between column empcity of table EMPLOYEE and column custcity of table CUSTOMER, relationship 34B is between column empname of table EMPLOYEE and column custname of table CUSTOMER, relationship 34C is between column custnum of table CUSTOMER and column ordemum of table ORDERS, and relationship 34D is between custcity of table CUSTOMER and column shipto of table ORDERS.

[0045] Having established these relationships between the tables, the user must then configure the type of join that will operate on the rows in each table. As described above, in presently known interfaces for configuring joins between tables in a relational database, a user would typically select one of the relationships 34A, 34B, 34C, 34D, and then set the join type between the two tables based on the selected relationship. This would be accomplished by “clicking” on the relationship line and then either opening a context window or making a menu bar or icon bar selection that would allow the user to input the join type. This methodology, however, creates an ambiguous situation with respect to interpreting the non-selected relationship(s).

[0046] For example, the user could select the relationship 34B and set the join type to a left outer join. The ambiguity now created is how to interpret the other relationship 34A, either as a separate inner join or as an AND condition to the relationship 34B. If the other relationship 34A is a separate inner join, then the following SQL would be generated by the SQL Query Tool 10 for the first two tables:

[0047] SELECT*FROM EMPLOYEE LEFT JOIN CUSTOMER ON

[0048] EMPLOYEE.empname=CUSTOMER.custname INNER JOIN CUSTOMER as CUSTOMER1 ON EMPLOYEE.empcity=CUSTOMER1.custcity

[0049] In this SQL, an alias table, CUSTOMER1, was generated because the relationship 34B is being interpreted as a separate join operation.

[0050] But if the software tool 10 interpreted the other relationship 34A is an AND relationship to the selected relationship 34B, then the following SQL would be generated:

[0051] SELECT*FROM EMPLOYEE LEFT JOIN CUSTOMER ON

[0052] EMPLOYEE.empname=CUSTOMER.custname AND EMPLOYEE.empcity=CUSTOMER1.custcity

[0053] Thus, allowing the user to set the join type based on one of the join relationships, as is done in presently known query tools, leads to the problem of how to interpret the non-selected relationships, either as AND conditions to the one join that was set, or as additional joins.

[0054] Another problem that is not addressed by presently known query tools relates to the ordering or sequencing of the tables 30A, 30B, 30C in the SQL query. In the example shown in FIG. 1, the user selected the tables in the order EMPLOYEE, CUSTOMER, and then ORDERS. Thus, the tables EMPLOYEE and CUSTOMER are joined first and create an intermediate result set that is then joined to the ORDERS table. However, the user may have intended to structure the query so that the CUSTOMER-ORDERS intermediate result set was generated first, and then this result set was joined with the EMPLOYEE table in order to generate the final result set. Presently known query tools do not provide any mechanism for dealing with this problem, other than to start over and build the query again by selecting the tables in their proper order. In addition, the presently known query tools do not provide a mechanism for automatically sequencing the tables in order to generate valid SQL.

[0055] Because of these problems, the present invention provides a separate advanced joins viewer (as described in more detail below) that enables the graphical re-sequencing of the table order and thus the reconfiguring of the intermediate result sets that are generated by the query. An automatic sequencing algorithm is also provided for configuring the ordering of the tables so that the query produces valid SQL. The advanced joins viewer also enables the independent configuration of the join type and the join relationships for each of the intermediate result sets, thus solving the ambiguity problem.

[0056] FIG. 2 is a graphical user interface of an advanced joins viewer 40 associated with the SQL Query Tool 10 for configuring, sequencing and viewing joins according to the present invention, showing the join type and join relationships of the tables involved in a join between a table and an intermediate result set formed by two other tables. The advanced joins viewer 40 may be activated from the SQL Query Tool interface 10 in several ways, such as by: (1) selecting a text entry from the menu bar 12; (2) selecting the advanced joins viewer icon 16 from the icon bar 14; or (3) selecting a table or relationship in the tables and relations window 22 and then selecting the advanced joins viewer entry from a pop-up context menu. Once selected, the advanced joins viewer 40 interface shown in FIG. 2 is displayed to the user.

[0057] The advanced joins viewer 40 includes two primary interface windows, a sequence display window 42, and an intermediate result set join display window 44. The sequence display window 42 displays a sequenced vertical tile list of each table and each associated intermediate result set in a particular query. The vertical tile list is preferably ordered from top to bottom.

[0058] Preferably, the table sequence is initially determined automatically using the automatic sequencing algorithm of the present invention, which is described in more detail below with reference to FIGS. 8 and 9. Using this algorithm, the default sequencing is such that each successive table in the vertical tile list has a relationship with one or more prior tables in the list. The intermediate result set join display window 44 displays join information for a particular intermediate result set, including the join type and the join relationships, and also enables the user to set the join type for the intermediate result set independently of the join relationships.

[0059] The advanced joins viewer 40 provides several features, including: (1) displays the joined tables in result set order in a vertical tile list; (2) allows users to alter (or re-sequence) the join order by selecting and graphically moving tables to a different location in the vertical tile list; (3) allows users to select a particular intermediate result set from the vertical tile list and then display the details of that result set, including the specific tables that comprise the result set, the join type of the result set, and the join relationships that define the result set; and (4) allows users to set and/or edit the join type and edit the join relationships.

[0060] FIG. 5 is a generic depiction of the sequence display window 42 of the advanced joins viewer shown in FIG. 2. In this depiction, the first two tables to be joined are shown as the inner-most tables 80, 82, and the intermediate result set that is generated by joining these first two tables is shown as the box 90 that surrounds the two tables 80, 82. The next table 84 is then joined to the intermediate result set 90 of the first two tables 80, 82, and results in the intermediate result set that is depicted by the box 92. In similar fashion, the next two tables 86, 88 are joined to the intermediate result sets 92, 94, and ultimately generate the result set depicted by box 96. Although five tables are shown in this generic depiction, the number of tables that are displayed in the sequence display window 42 is only dependant on the number of tables that are selected by the user from the SQL Query Tool 10 interface.

[0061] A user can select a particular intermediate result set by “clicking” on one of the tables 80, 82, 84, 86, 88. For example, if the user wanted to display information regarding the intermediate result set 90 that is generated from the join of tables 1 and 2, then the user can select either of these tables using a pointing device. If the user then wanted to display the intermediate result set 92, the user would select the third table 84, and so forth for the other result sets 94, 96.

[0062] The information depicted in the intermediate result set join display window 44 depends on which intermediate result set is selected by the user when interacting with the sequence display window 42. Consider, for example, the interface shown in FIG. 2. The tables and relationships depicted in this figure (as well as the remaining figures) correspond to the tables shown in FIG. 1. Here, the sequence display window 42 depicts the ordering of the three tables, EMPLOYEE, CUSTOMER, and ORDERS in a vertical tile list. The innermost tiles in the list 46A, 46B represent the tables EMPLOYEE 46A and CUSTOMER 46B. These two tables are joined into the intermediate result set depicted by the box 48. This intermediate result set 48 is then joined to the ORDERS table 46C, which generates the final result set, which is depicted by the box 50.

[0063] In FIG. 2, the ORDERS table 46C has been selected. This selection causes the intermediate result set join display window 44 to display information regarding the result set 50, which results from the join between ORDERS 46C and the intermediate result set 48 that includes the join between EMPLOYEE 46A and CUSTOMER 46B. The intermediate result set join display window 44 preferably includes three elements: (1) a table display 52, 54, 56; (2) a join type display/selection window 58; and (3) a relationships display/editing window 60. The table display graphically depicts the two sides of the result set join, and also indicates the type of join 56, 58A, 58B.

[0064] FIG. 2 shows the intermediate result set 48 (EMPLOYEE joined with CUSTOMER) depicted on one side of the join 52, and the selected table 46C (ORDERS) depicted on the other side of the join 54. Between the two sides of the join is a graphical depiction of the join type. This graphical depiction includes a line 56 that is terminated at either end by a pair of join indicators 58A, 58B.

[0065] The join indicators 58A, 58B indicate the type of join that is currently selected for the displayed result set. If the join indicators are both solid, then the join is an inner join. If the left join indicator is empty but the right join indicator is solid, then the join is a left outerjoin. If the left join indicator is solid but the right join indicator is empty, then the join is a right outer join. And if both join indicators are empty, then the join is a full outer join. The join shown in FIG. 2 is an inner join.

[0066] The join type display/selection window 58 displays the currently selected join type for the selected result set, and also enables the user to select a different join type. This join type selection step is independent from any of the join relationships shown in the relationships window 60, and thus avoids the join ambiguity problem noted above. The four types of joins, inner, left outer, right outer, and full outer are shown as textual and graphical depictions in the join type display selection window 58.

[0067] The top selection in the window 58 is for an inner join, which only returns matching rows from both sides of the join to the result table. The inner join is graphically depicted by a line terminated at both ends with a solid join indicator 58A, 58B. The next selection down from the inner join is the left outer join, which return's all of the rows from the preserved table (in this case the intermediate result set formed by the join between the EMPLOYEE and CUSTOMER tables) and only the matching rows from the non-preserved table (ORDERS). The left outer join is graphically depicted by a line terminated at the left side with an empty join indicator and at the right side with a solid join indicator. The next selection down from the left outer join is the right outer join. The right outer join returns all of the rows from the preserved table (in this case the ORDERS table) and only the matching rows from the non-preserved table (in this case the intermediate result set formed by the join between the EMPLOYEE and CUSTOMER tables.) The right outer join is graphically depicted by a line terminated at the left side with a solid join indicator and at the right side with an empty join indicator. The final selection shown in the window 58 is the full outer join, which is a combination of the left and right outer joins. The full outer join is graphically depicted by a line terminated on both sides with empty join indicators. Although the preferred embodiment of the invention utilizes the inner join and these three types of outer joins, it should be understood that any other types of joins could also be utilized with the invention.

[0068] Each of the four join types shown in the join type display/selection window 58 includes a selector button, preferably a radio button, for choosing the join type. The user can select one of these selector buttons in order to change the join type for the selected intermediate result set. This join type selection step is independent of any of the join relationships.

[0069] The relationships display/editing window 60 shows the current relationships between the ORDERS table 54 on one side of the join and the intermediate result set 48 generated by the join between the EMPLOYEE and CUSTOMERS tables on the other side of the join. These join relationships can be edited 62 or deleted 66, or another join relationship can be added 64 to those that are already displayed through the window 60.

[0070] FIG. 3 is another depiction of the advanced joins viewer shown in FIG. 2, showing the join type and join relationships of the tables involved in a join between two tables. In this figure, the user has selected the CUSTOMERS table depiction 46B from the tile list, which then causes the display of the join type and relationships between the CUSTOMERS table and the EMPLOYEE table. Here, the join type is set to a left outer join, and the two relationships are depicted in the relationships display/editing window 60.

[0071] Suppose now that the user is not satisfied with the sequencing of the tables shown in the sequence display window 42, and wants to re-order the tables so that the CUSTOMER table is after the EMPLOYEE and ORDERS tables in the sequence. Conventional query tool interfaces do not provide any means for accomplishing this re-ordering step other than by manually re-inputting the entire query.

[0072] FIG. 4A is a partial depiction of the advanced joins viewer showing the process of manually re-sequencing the tables in the query. Here, if the user wants to re-sequence the tables, then the user selects the table to re-sequence by “clicking” on the table with the selection button of a pointing device. Then, while holding down the selection button on the pointing device, the user can drag and drop the selected table to a position in the vertical tile list of the sequence display window 42 that corresponds to the desired ordering. As shown in FIG. 4A, the user has re-sequenced the tables so that the CUSTOMER table 46B is after the ORDERS table 46C by dragging and dropping the CUSTOMER table tile 46B to a position after the ORDERS table tile 46C in the display. Preferably, and as described in more detail below, prior to accepting a new sequence order, the advanced joins viewer 40 will determine if the new sequence is valid, and if not, then it will give the user the option of executing the automatic sequencing algorithm of the present invention in order to ensure a valid SQL query.

[0073] FIG. 4B is another depiction of the advanced joins viewer shown in FIG. 2 in which a new intermediate result set is displayed following the manual re-sequencing of the tables depicted in FIG. 4A.

[0074] FIG. 6 is a flowchart showing a preferred method of creating and manipulating queries using the SQL Query Tool 10 shown in FIG. 1. The method begins at step 100, where the SQL Query Tool 10 is executed. At step 102, the graphical user interface shown in FIG. 1 is displayed to the user. Several functions are accessible from this interface, including: (1) select query tab (step 108); (2) select advanced joins viewer (step 106); (3) save query (step 110); (4) select SQL tab (step 112); (5) define relationships (step 114); and (6) select other tabs (step 104).

[0075] The select query tab 18A shown in FIG. 1 is selected (step 108) in order to create a query. From this interface (FIG. 1), the user can display a list of tables associated with a particular relational database at step 120, and then add one or more tables to the query (step 122). As each table is added to the query, the interface tool 10 preferably depicts an image of the table including the various column variables. If there are more tables to add at step 124, then control loops back to step 122 until the user has selected all of the tables for the particular query. At step 126, the user then sets the column relationships between the selected tables. After a column relationship is set, the method preferably executes the auto sequencing algorithm at step 128 (described in more detail below with reference to FIGS. 8 and 9). If the user desires to set more column relationships at step 130, then control reverts to steps 126 and 128 until all of the column relationships for the query are set, and, preferably, the tables have been sequenced in their proper order using the auto sequencing algorithm.

[0076] Step 106 (select advanced joins viewer) is typically selected by a user after (or during) the process shown in steps 108-130. Once selected, the steps shown in FIG. 7 are preferably executed for configuring, sequencing and viewing the join relationships between the selected tables.

[0077] At step 110, the user can save a query for later use or modification. At step 114, the user can define (or re-define) one or more of the relationships that are set in step 126. At steps 112-118, the user can generate and display the textual SQL statement associated with the query that is graphically constructed using the select query tab 18A and the advanced joins viewer 40. And at step 104 the user can select various other tabs of the graphical user interface shown in FIG. 1 in order to execute the other SQL functions described above.

[0078] FIG. 7 is a flowchart showing the preferred method of configuring, sequencing and displaying joins using the advanced joins viewer of the present invention. At step 140, the advanced joins viewer graphical interface shown in FIG. 2, for example, is displayed to the user. As described above, the advanced joins viewer interface includes a sequence display window 42, and an intermediate result set join display window 44. The sequence display window 42 sets forth a sequenced vertical tile list of the tables and the intermediate results sets that form the query. The intermediate result set join display window 44 includes a table display, a join type display/editing window, and a relationships display/editing window. Using the intermediate result set join display window 44, the user can readily appreciate the relationships and ordering between and among the tables that generate a particular intermediate result set, and the user can set the join type independently of any of the individual relationships.

[0079] At step 142, the user selects a particular intermediate result set by selecting one of the table tiles displayed in the sequence display window 42. From here, the user may re-order the sequence in which tables are joined (step 156) by graphically moving a particular tile to another position in the vertical tile list. Preferably, after the user has re-sequenced the tables, the method checks to determine if the new sequence will generate a valid SQL statement, and if the new sequence does not generate valid SQL, then the method prompts the user to execute the automatic sequencing algorithm at step 128, which then re-sequences the tables in order to generate valid SQL.

[0080] At step 144, the advanced joins viewer 40 displays the intermediate result set and the join type and join relationships in the intermediate result set join display window 44. From this step, the user can then set the join type (step 146), which is done independently of any of the join relationships, the user can edit the displayed relationships (step 148), the user can insert a new relationship (step 150), or the user can delete one of the relationships (step 152). If there are more operations to execute on this particular query, then control passes from step 154 back to step 142, where the user can continue to operate on the currently selected intermediate result set, or the user can select another result set.

[0081] FIG. 8 is a flowchart showing the preferred method of automatically sequencing tables in the query. For each table that participates in a join, the method of the present invention preferably stores a join object. The join object is a collection of information about each table in the join, and, as shown in FIG. 9, the join object preferably includes: (i) the table to be joined (176); (ii) one or more join relationships (178); (iii) the join type (180); and (iv) the table relationships (182).

[0082] The join relationships (178) represent the column-specific criteria that are set forth in the ON clause for determining what rows should be returned into the intermediate result set. The table relationships (182) represent a list of tables that have join relationships with the table represented by the join object. And the join type (180) is either an inner join, or one of the three types of outer join (Left, Right, or Full). The default join type is inner, which can be changed in the advanced join viewer 40, as shown and described above.

[0083] Preferably, there are two contexts in which the automatic sequencing algorithm described in FIG. 8 is executed. The first context is when a user adds (or deletes) a table to the query. The reason that the automatic sequencer is executed in this context is that the order of the joins in SQL syntax should be specified such that each successive table in the join has a relationship with a table that has already been specified in the generated SQL.

[0084] For example, consider a query involving three tables, CUSTOMERS, ORDERS and EMPLOYEE. The CUSTOMERS table has a relationship with the ORDERS table, and the ORDERS table has a relationship with the EMPLOYEE table. Now suppose that a user added the tables in the order CUSTOMERS, EMPLOYEE, and ORDERS. The join objects will be added in the order that the user specified the three tables. However, because EMPLOYEE does not have any relationships with CUSTOMERS, the order of the tables must be altered so that EMPLOYEE follows a table with which it has a relationship.

[0085] The automatic sequencing algorithm shown in FIG. 8 ensures that the tables are properly ordered using the rule that each successive table in the join should have a relationship with a table that has already been specified. Thus, each time a relationship line is added between the tables in a query, the sequencer is preferably executed in order to create a default ordering that generates valid SQL. When the advanced joins viewer is invoked, the default ordering is displayed in the sequence display window 42.

[0086] The other context in which the automatic sequencing algorithm is executed is within the advanced joins viewer 40 when the user has manually re-sequenced the tables, but the resulting sequence does not generate valid SQL. Here, if a user dragged and dropped a table to a new location in the vertical tile list in the sequence display window 42 such that one or more of the intermediate result sets no longer had any relationships, then query tool software would alert the user to the error and prompt the user to execute the sequencer. If the user responds affirmatively, then the automatic sequencer is executed, thus restoring a correct order. Otherwise the user must re-order (drag and drop) the tables until a valid result set ordering is achieved.

[0087] Turning back to FIG. 8, the preferred automatic sequencing algorithm is set forth. The algorithm maintains two lists of join objects. One list is the input “raw” list, which reflects the order in which the tables were selected and displayed in the SQL Query Tool 10, or which were the result of the last automatic (or manual) ordering from interactions with the sequence display window 42. The other list is the final “ordered” list that produces valid SQL syntax. As the algorithm is traversed, tables are populated into the “ordered” list and deleted from the “raw” list. After each table is analyzed accordingly, and moved into the “ordered” list, the “ordered” list is then written into the “raw” list, resulting in a properly-sequenced listing of the tables. In each join object, one of the items that is stored is the list of all tables that have a relationship to the current table, referred to as the table relationship list 182. Thus, by definition, any join object whose table matches one of the tables in the current join object's table relationship list 182 will produce valid SQL syntax when it becomes the next join object in the ordered list.

[0088] The preferred sequencing algorithm begins at step 160, where the first join object contained in the “raw” list is fetched and stored in the “ordered” list, and it is then deleted from the “raw” list. Step 162 determines if there are more join objects in the “raw” list. If there are none, then the sequencing algorithm is done, and the process exits at 168. If, however, there are more objects in the “raw” list, then control passes to step 166.

[0089] At step 166, the algorithm examines the table relationship entry 182 for the current join object that was fetched in step 160 or 170. If a new table relationship is found in the table relationship entry 182 for this join object, then control passes to step 164. A new table relationship is a table that has not already been added to the “ordered” list. At step 164, the algorithm then fetches the join object for the new table relationship from the “raw” list, adds that join object to the “ordered” list, and deletes it from the “raw” list. Control passes back to steps 162, 164 and 166, which are repeated until a join object is encountered with no new table relationship entries.

[0090] At this point, control passes to step 170, where the next join object is fetched from the “raw” list. Step 172 determines whether the join object fetched in step 170 has a table relationship to any join object that is already on the “ordered” list. If so, then control passes to step 164, and the join object from step 170 is added to the “ordered” list and deleted from the “raw” list. If, however, the join object fetched in step 170 does not have any table relationships, then control passes back to step 170 and the next join object is fetched for analysis. These steps 162-172 are repeated until all of the join objects have been moved from the “raw” list to the “ordered” list, at which point the sequencing is complete, and the “ordered” list is written back as the “raw” list, but now in proper table sequence.

[0091] The preferred embodiment described with reference to the drawing figures is presented only to demonstrate an example of the invention. Additional, and/or alternative, embodiments of the invention would be apparent to one of ordinary skill in the art upon reading this disclosure.