Testing ANSI SQL Hierarchical Data Modeling and Structure Processing

Transcription

1 Testing ANSI SQL Hierarchical Data Modeling and Structure Processing This document guides you in specifying hierarchical (Left Outer Join hierarchical data modeling) queries on your standard SQL processor that will demonstrate first hand the inherent hierarchical processing capabilities within standard ANSI SQL. These same capabilities are demonstrated and utilized in web site to fully demonstrate integrating XML into SQL. These capabilities include: modeling and processing full multi-leg structures, performing hierarchical joins of multi-leg data structures, hierarchical optimization, full support for multi-leg hierarchical query semantics, advanced hierarchical capabilities such as node promotion and fragment processing, and more. You will also see how the relational row set naturally stores multi-leg variable length structures and how data is preserved hierarchically. 1) The Tables, Structures and Data We will start with two hierarchical structures comprised of the tables shown in Figure 1 below. The SQL that defines these structures is shown below the structures. The dashed lines between the and views and Store table represent relationships that can be used between the views or other tables. The SQL views, table definitions, and data for these examples can be downloaded from the same web page identified above that contains this document and are also listed at the end of this document. The design of these structures assumes all employees are also customers so that employees and customers can share the same ess table. The second use of the table is joined to the table in the view using the alias capability to rename the table to avoid naming conflicts or ambiguities when the View and View are used together. This renaming technique can also be utilized for modeling XML documents when an element is used in more than one location in the structure or when an element is accessed via an IDREF link so that there are two paths leading to the same element. Also notice that the View has an ON clause data filter to remove Dependents that have no medical coverage (see 02 in the Hierarchical Data Tree in Figure 2). This is a fine hierarchical path filter that only affects the location where it is used (same as XPath data filtering). Table Store View View Eaddr CREATE VIEW View AS SELECT * FROM LEFT JOIN ON ID=InvID LEFT JOIN ON ID=ID; Figure 1: Tables, Views and Relationships CREATE VIEW View AS SELECT * FROM LEFT JOIN ON ID=ID AND Code <> N LEFT JOIN E ON ID=EID ;

2 The two structure views above can be combined into a larger structure in more than one way. One way is under the Store table as shown below in Figure 2. Using the SQL alias capability in the View shown and described above in Figure 1, multiple paths to node have been automatically divided into separate paths leading to the and E nodes. This keeps the structure unambiguous. The structure below keeps the View and View sub views separate and independent of each except for their same Store relationship which can be utilized in queries as will be demonstrated. The relational Result Set in all the Figures represent null fields as blank to emphasize the embedded data structure more. Store View Structure Store View View Store View CREATE VIEW StoreView AS SELECT * FROM Store LEFT JOIN View ON StoreID=StoreID LEFT JOIN View ON StoreID=StoreID ; E Hierarchical Data Tree Store , F 02, P Inv01, P , F 02, N Inv02, O Inv03, O 03 E01 E03 Relational Result Set StoreID ID InvID ID ID ID EaddrID Store1 01 Inv Store1 01 Inv Store1 01 Inv Store1 01 Inv Store1 02 Inv Store1 02 Inv Store Store Figure 2: Main View and Data from Store View Copyright 2003 Advanced Data Access Technologies Inc. 2

3 SQL 1.1: SELECT StoreID, ID, InvID, ID, ID, ID, EID FROM StoreView The above SQL 1.1 statement result should be the same as the Relational Result Set in Figure 2. Blank boxes are null values. If the result is the same then the following capabilities have been empirically proven: Based on Figure 2 Results SQL Hierarchical Data Modeling Data Preserved Hierarchically Row Sets Aligned Hierarchically Shared Table or Element ON Clause Path Filtering Views and Embedded View Expansion The SQL Left Outer Join performs hierarchical data modeling of full multi-leg structures as shown by results. Each leg s data occurrences are preserved until each path ends or a missing node data occurrence is encountered. omer 3 has no invoice. Each leg remains aligned, even if they dynamically vary in length. Null values act as placeholders. omer 3 has no invoice. The table is used in more than one location in the hierarchical data structure and can be individually referenced. Supports XPath type data filtering, 02 is filtered out without removing the parent or affecting other legs. Data modeling views have expanded correctly into a unified hierarchical view to produce the results shown. 2) Hierarchical Qualification The following SQL queries will demonstrate the hierarchical query processing of standard SQL on multileg hierarchical structures shown in Figure 1. The SELECT clause identifies the output data, the FROM clause identifies the input tables or nodes, the LEFT JOIN models the data structure, and the optional WHERE clause performs hierarchical data filtering. Multi-leg hierarchical structures have hierarchical semantics associated with them which dictates how the WHERE clause filtering operates on hierarchical structures. Information on these capabilities can be found in the Nonlinear Process page at Compare the output of the following queries in Section 2 to the Relational Result Set in Figure ) First lets look at a simple single leg data qualification. The following example queries demonstrate how data nodes and all their data occurrences located down all paths from a qualified node data occurrence are also qualified, and how the single path data occurrence up the path from a qualified data occurrence is also qualified. Compare the output of the following queries to the Relational Result Set in Figure 2 above. This logic is similar to XPath logic. SQL 2.1.1: SELECT InvID FROM StoreView WHERE StoreID= Store01 The above query returns all invoice IDs ( IDs 1,2,3) under the Store occurrence Store01. All invoice IDs under the qualified ancestor data occurrence Store01 are returned. Copyright 2003 Advanced Data Access Technologies Inc. 3

4 SQL 2.1.2: SELECT InvID FROM StoreView WHERE ID= 01 The above query returns all invoice IDs ( IDs 1,2) under the customer occurrence 01. All invoice IDs under the qualified ancestor data occurrence 01 are returned. If 01 occurred in other stores, their data would also be included. SQL 2.1.3: SELECT ID FROM StoreView WHERE InvID= Inv01 The above query returns the omer ID ( 01 ) associated with invoice Inv01. The omer ID on the path up from the qualified invoice data occurrence Inv01 is returned. 2.2) Lets look at simple multi-leg data qualification. This involves Selecting data from one leg of a hierarchical structure, based on data in another leg of the structure. This is simple multi-leg hierarchical processing but involves complex hierarchical logic involving relating the two legs by their common ancestor node data occurrence. All Selected data under a common ancestor qualifies (same as qualifying down a structure). SQL 2.2.1: SELECT ID FROM StoreView WHERE InvID= Inv02 The above query returns 01 which is related through 01 its common ancestor for value Inv02. Queries across sibling legs are related by their common ancestor data occurrence. SQL 2.2.2: SELECT InvID FROM StoreView WHERE ID= 01 The above query returns invoices ( Inv01 and Inv02 ) under the common ancestor data occurrence 01 for value 01. ALL occurrences are selected under the common ancestor data occurrence. SQL 2.2.3: SELECT ID FROM StoreView WHERE InvID= Inv02 The above query returns all employees ( 01 and 02 ) under the common ancestor data occurrence Store01. This shows that the common ancestor can be anywhere up the structure. SQL 2.2.4: SELECT InvID, ID, StoreID, ID FROM StoreView WHERE InvID= Inv02 With the above query, Inv02 is selected along with 01, Store01 because they are on a selected path up the structure, and on the downside of the common ancestor occurrence of Store01, all loyees ( 01 and 02 ) are selected. SQL 2.2.5: SELECT ID, ID, ID FROM StoreView WHERE InvID= Inv02 This query is similar to the previous query, but removes InvID and StoreID, and adds ID. With this query, 01, 01, and loyess ( 01 and 02 ) are selected. What is new with this query is that we have two lowest common ancestors, Store01 same as last time, but by also selecting ID, 01 is also a second lowest common ancestor and selects All Id s under qualified 01. In this case there is only one 01. Copyright 2003 Advanced Data Access Technologies Inc. 4

5 2.3) Now lets look at complex multi-leg data qualification. So far we have seen simple multi-leg data qualification involving simple qualification tests producing only one lowest common ancestor. But more complex qualification tests are possible (there are no limitations) that will produce more complex hierarchical decision logic and multiple common ancestor logic. Compare the hierarchical common ancestor logic needed to process the following queries to the Hierarchical Data Representation in Figure 2. Notice how the hierarchical related values are duplicated around these common ancestors. SQL 2.3.1: SELECT ID FROM StoreView WHERE InvID= Inv02 AND ID= 01 The above query tests the two sibling legs under the common ancestor node where one of the data combinations does match the test for Inv02 and 01 selecting 01. This demonstrates how the relational Cartesian product can perform these complex multi-leg hierarchical tests one row at a time. SQL 2.3.2: SELECT ID FROM StoreView WHERE InvID= Inv02 AND ID= 02 The above query returns a null result because no data is qualified because while there is an Inv02 and 02 data occurrence they are not related by the same common ancestor data occurrence. SQL 2.3.3: SELECT InvID, ID FROM StoreView WHERE InvID= Inv02 OR ID= 01 OR operations can get tricky. This query returns both invoices ( Inv01 and Inv02 ) and 01. Normally with OR operations, if the first condition is true, the second condition on the right side does not require testing. This is not the case here with hierarchical semantics, if it was the case then Inv01 would not be selected. You might think it should not be selected, but it is selected because the other sibling side test where 01 was tested and selected, qualified both invoices under the common ancestor 01. This result and hierarchical logic can be proven by breaking the query into two queries each with one side of the WHERE clause and unioning the results together. SQL 2.3.4: SELECT StoreID, ID, ID FROM StoreView WHERE InvID= Inv02 AND ID= 02 OR ID= 01 This query demonstrates that complex decision logic can involve more than one instance of common ancestor decision logic. This query first evaluates the AND condition which is false (no common ancestor combination found under a omer node for Inv02 and 02 ) and then evaluates this false condition with the right side of the OR condition under the common ancestor node Store which is true. Based on this, Store01 is selected, all customers ( 01, 02, and 03 ) are selected (because they are sibling side qualified), and only employee 01 was selected (because the sibling side didn t qualify, but 01 did, only qualifying 01 above it). Recap of Hierarchical Query Qualification Hierarchical query qualification must take the hierarchical data and hierarchical structure into consideration when performing data selection even though the user or developer does not usually need to be aware of the exact data structure when specifying the SQL query. The following capabilities that comprise this hierarchical query qualification were tested and proven. Copyright 2003 Advanced Data Access Technologies Inc. 5

6 Single path qualification up the path Single path qualification down the path Multiple path qualification down a path Common parent single leg qualification Common parent AND multi-leg qualification Common parent OR multi-leg qualification Multiple Nested Lowest Common Ancestors All data up the current qualified path data occurrence qualifies All related data occurrences down the path qualify (This involves multiple occurrences) Can break off to multiple paths producing multiple lowest common ancestors All data under the common parent occurrence qualifies where test was on the other leg All data conditional combinations under common parent tested and both must be true. It was proven that Or logic requires both sides tested with common parent hierarchical semantics Each handled in turn automatically, combining to produce the correct hierarchical result It is quite amazing that SQL can perform multi-leg qualification because it requires very complex hierarchical processing semantics and SQL s processing is basically performed a row at a time, but it does work no matter how complex the hierarchical query may be. Copyright 2003 Advanced Data Access Technologies Inc. 6

7 3) Lets Look at a Different Combined View and Some Hierarchical Capabilities. View View E CREATE View InvView AS SELECT.*,.*,.*,.* FROM View LEFT JOIN View ON ID=ID InvView Structure Data Represented as Hierarchical Tree Inv02 Inv01, P Relational Result Set ID ID InvID ID Inv Inv Figure 3 Alternate View and its Data Copyright 2003 Advanced Data Access Technologies Inc. 7

8 The InvView above in Figure 3 demonstrates that hierarchical views can be used to construct different structures. The resulting structure, InvView, is a more tightly integrated structure than the previous combined view, with the View directly linked into the View. The above materialized Relational Result Set in Figure 3 can be produced from the following query: SQL 3.1: SELECT ID, ID, InvID, ID FROM InvView Since this view only needs one address node, the E table in the View is not referenced in the new, InvView, view s SELECT list. Since we do not need or want customer information to be retrieved with this view, omer data is also excluded from the view s SELECT list. This has the effect of not ever having an E or node in the result structure. This causes the and ess nodes to always be promoted around the missing omer node in the result to take its position, preserving the integrity of the result structure. This can be inferred from the Data Represented as a Hierarchical Tree and the Relational Result in Figure 3 above. The InvView is also an example of joining hierarchical structures hierarchically. The omer view is linked under the loyee view. The ON clause allows this join to be linked unambiguously and precisely as required. The result of this structure joining is supported in the query that externalizes the materialized view above. This combined view is also an example where a non selected (non output) node can supply required information. In fact in this example, a non selected node, is the lower level link point node. The path leading to the box containing the E node are both dashed in Figure 3 because it is not selected or on a path to a selected or required node. This means that it does not require accessing. This is because of the way the Left Join preserves data. Most SQL systems are not aware of this hierarchical access optimization. This can be tested by performing the query directly below. If the 01, 01 and 01 information returned is not duplicated twice, than the hierarchical access optimization is working. The fact that the information is not duplicated also means that the result is more semantically correct because the existence of a matching E node should have no effect on the result. SQL 3.2: SELECT ID, ID, ID FROM InvView The above query does not select s from the View. 01 has two invoices which would normally require it to be replicated in the output. Since invoices were not requested, and they are data modeled with a Left Outer Join, their non existence does not effect the result (unlike Inner Joins), so they do not require access. This optimization has important application outside of optimization by making structured views more powerful, useful and easier to use. Recap of Inv Examples Joining hierarchical Structures Hierarchical Optimization Flexible Hierarchical Views Node Promotion Hierarchical structures defined in SQL views can be easily and exactly combined into a larger hierarchical data structure Hierarchical optimization can dynamically optimize queries base on the data required. Views can be reused easily and the hierarchical optimization will always maximize their data access Node promotion automatically occurs when input nodes are not selected for output. This also causes node collection. Copyright 2003 Advanced Data Access Technologies Inc. 8

9 4) Linking Below the Lower Level Root and Miscellaneous Capabilities When joining structures, linking below the root of the lower level structure is sometimes necessary and/or useful. This will cause the lower level structure to be filtered based on the link point s value, similar to linking at the root except filtering a smaller area of the structure. Lower level linking is possible in views because SQL views cause their structure to be materialized before being joined to the upper level structure. This is necessary for logical views which require their original root to materialize the structure. This also means that the original root remains the root for data modeling purposes since the original root in logical and physical structures still has control over what data is in the structure. This does not require that the original root be included in the output structure. An example of linking below the root in a lower level structure is shown below in Figure 4.1 below. View E Ad hoc SQL Request View SELECT Id, ID, ID, InvID, ID FROM View LEFT JOIN View ON EID=ID Data Represented as Hierarchical Tree Result Structure Inv02 Inv01, P Relational Result Set ID ID ID InvID ID Inv Inv Figure 4.1: Linking Below Root Example 1, Root is Selected Copyright 2003 Advanced Data Access Technologies Inc. 9

10 To produce the Relational Result Set above in Figure 4.1, issue the ad hoc statement below. SQL 4.1: SELECT ID, ID, ID, InvID, ID FROM View LEFT JOIN View ON EID=ID If your result matches the Relational Result Set above in Figure 4.1, this proves that this linking below the root feature works as described above. The lower level view is materialized before being linked to the above structure. This occurs because right sided nesting is performed with SQL views because of the way views expand pushing the current ON clause to the right to expand the lower level structure view with its own ON clauses. This right sided nesting places the current structure being built in suspension and starts building the new structure. This is described in the SQL Hierarchical papers in the More on Structures sub page of the Data Structures page at Since this SQL statement was an ad hoc statement it proves that the joining of structures can be performed dynamically. In addition, the previous example in Figure 3 above proved that the joining of structures can be optimized based on the SELECTed items at the time of execution, so this ad hoc joining of structures will also be hierarchically optimized fully. The lower level structure s original root node remains the root node even if the link point is below the root. This is because the original root node still affects what tables (or nodes) are in the structure. For example, in this example, if 01 data occurrence did not exist then this lower level structure occurrence would not exist. The original root node also logically and semantically holds the lower structure together so that if the root is not selected for output, all of the selected lower level items including those that are not directly connected (on the same path) to the link point () are still processed correctly. This is shown in the example below in Figure 4.2, the root is not selected, but the node is. The node is not connected directly to the link point but is related indirectly through the node, a common ancestor. This does not present a problem, because the node is still logically and semantically the root, even if it is not SELECTed as the example below demonstrates. This holds the record together in the Working Structure (set) as shown below in Figure 4.2. Result Structure SELECT ID, ID, InvID, ID FROM View LEFT JOIN View ON EID=ID Working Structure Relational Result Set E ID ID InvID ID Inv Inv Figure 4.2 Linking Below Root Example 2, Root Not Selected Copyright 2003 Advanced Data Access Technologies Inc. 10

11 When you submit the query below, you should get the same result as in the Relational Result Set above in Figure 4.2. The Inventory node along with the ess node is dynamically promoted up under the loyee node. This makes sense logically and semantically because if there was no match for the data occurrence 01 than neither the or ess nodes would have been located. And its output hierarchical structure is still consistent with the previous example in Figure 4.1. SQL 4.2: SELECT ID, ID, InvID, ID FROM View LEFT JOIN View ON EID=ID Lets look at an example of data path filtering based on a data value further up the current data structure path. The query below is filtering the node based on a value from the node up the structure. Since employee 02 is a part time employee (Status= P ), his related customer information is filtered (nulled) out from the Relational Result Set which is indicated below by the shaded area. SQL 4.3: SELECT ID, ID, InvID, ID FROM View LEFT JOIN View ON EID=ID and Status= F Relational Result Set ID ID InvID ID Inv Inv Recap of Linking Below the Root & Misc. Capabilities This section has proved that linking below the root operates logically and hierarchically correctly while following SQL ANSI semantics. It has also proven that the SQL view expansion works for embedded views along with the dynamic joining of hierarchical structures defined in views. Linking below the root Dynamic node promotion Dynamic structure joining Dynamic optimization Filtering up the structure This ability is possible because SQL structure views materialize before being joined. Their SQL semantics also makes sense. Node promotion can be controlled automatically from Ad hoc processing, this also dynamically controls fragment processing The dynamic joining of hierarchical structures can be specified with ad hoc queries Hierarchical optimization operates with ad hoc queries, so that optimum access efficiency is always achieved The ability to filter a path at a lower level based on a data value from a higher level up the path An unselected table (or node) that was included in the FROM clause does not alter the basic structure defined by the FROM clause other than removing these nodes from the Output Structure Definition and Relational Result Set. This is done to properly reflect the effect of the node promotions. While the WHERE clause filters data row occurrences based on data values, the SELECT clause (projection) filters the structure by slicing out unselected columns. These operations occur automatically for logical data Copyright 2003 Advanced Data Access Technologies Inc. 11

12 structures composed of relational tables and define how the comparable filtering should be applied to external physical structures such as XML which are accessed outside of SQL. In Figure 4.2 above, you can notice that and E nodes are present in the Working Structure but not the Relational Result Structure. The Result Structure shown has undergone the corresponding structure filtering (node promotion), as described above, slicing out the E and nodes so that it maps the Result Structure correctly. With this Result Structure, which is meta information derived from the SQL data modeling itself, the Relational Result, which is hierarchically accurate in semantics and data content, can be output as a fully structured XML document with little effort. Copyright 2003 Advanced Data Access Technologies Inc. 12

13 5) Fragments and Transformation Prior examples in this document have shown examples of fragments, but they have been too small to mention. The following example in Figure 5, shows structure fragments being defined and manipulated. A fragment is a piece of a hierarchical structure that can be located below the root and only be part of the structure. SQL handles this naturally and automatically. It is controlled by what data fields are selected which in turn defines what nodes are selected from the structure. The natural operation of node promotion will cause the fragment to become unified enabling it to be joined into the structure being constructed. This is shown below in Figure 5 where the separate fragments are encircled in a dotted circle. StoreView Store SV2 (View) SV1 (View) E SELECT DISTINCT SV1.ID, SV1.ID, SV2.ID, SV2.InvID, SV2.ID FROM StoreView SV1 LEFT JOIN StoreView SV2 ON SV1.ID=SV2.ID E Result Structure ID ID ID InvID ID Inv Inv02 01` Figure 5: Decomposition and Transformation Copyright 2003 Advanced Data Access Technologies Inc. 13

14 Usually only one fragment per structure is accessed, but to prove how this capability can be used to perform structure transformations, it is possible to duplicate the structure input so that it could be separately accessed to retrieve two fragments that can be independently manipulated, thereby transforming the original structure. Type in the below SQL statement from Figure 5 to see the result which should resemble the structure and result in Figure 3. Notice how simple and intuitive this SQL query is to specify and the hierarchical power it demonstrates. The Distinct keyword is used to remove any replicated rows that are a side effect of the input StoreView. SQL 5.1: SELECT DISTINCT SV1.ID, SV1.ID, SV2.ID, SV2.InvID, SV2.ID FROM StoreView SV1 LEFT JOIN StoreView SV2 ON SV1.ID=SV2.ID Decomposition and transformation of logical and physical data structures is possible with standard SQL using a combination of fragment processing and SQL alias processing that allows structure views to be accessed multiple times as shown above in Figure 5. It uses the StoreView view defined in Figure 2 as the single source of two separate fragments (encircled in a dotted circle in Figure 5) that reflect the data that comprises the View and View used in the StoreView. These fragments decompose the StoreView and then remodel it differently to duplicate the data model and data in Figure 3. This remodeling operates by joining the structure fragments based on data value relationships in the structure. While logical structures are free to be modeled in many different ways, physical structures must be modeled reflecting their actual structure. While the StoreView in the above example in Figure 5 is modeling a logical structure, it could just as well be a fixed structure for this example. This example demonstrates that a physical structure can be rearranged by separately selecting small fragments from it which can be independently joined into the main structure (unified view) with the flexibility offered by logical structures. The alias feature gives a new table or view name to an object and in the SELECT list clause you need to use this new object name as a high level prefix for the data items in the different renamed objects to specify which renamed object you a referring to, since they have the same name in both objects. This is shown in Figure 5 above. Recap of Fragments and Transformation Fragments Dynamically created sub structures from physical and logical structures Transformations Dynamic structure reorganization by rearranging fragments Conclusion The result of processing the example SQL statements in this document should have proven and shown how ANSI SQL can perform full hierarchical processing by hierarchically modeling the data structures. It was shown how hierarchical structures could be modeled in SQL views. How the hierarchical modeling ANSI SQL semantics processed the data hierarchically. This involves and showed how the relational row set can contain hierarchical multi-leg structures and how the relational engine processes them and complex hierarchical decision queries. It was shown how query data filtering and selection logic followed hierarchical processing principles. It was also shown that SQL can also naturally and simply perform very advanced hierarchical capabilities being introduced by XML, such as node promotion, fragment processing and structure transformations. What makes these SQL capabilities particularly valuable is that they are performed simply using non procedural ANSI standard SQL. With SQL naturally performing hierarchically, it should be clear that interfacing to XML can now be easily performed at a seamless hierarchical level. Copyright 2003 Advanced Data Access Technologies Inc. 14

15 The following SQL Statements can be Downloaded from the Web Site CREATE TABLE Store ( StoreID Character (7) ); INSERT INTO Store VALUES ( Store01 ) ; CREATE TABLE ( ID Character (7), StoreID Character (7) ); INSERT INTO VALUES ( 01, Store01 ) ; INSERT INTO VALUES ( 02, Store01 ) ; INSERT INTO VALUES ( 03, Store01 ) ; CREATE TABLE ( ID Character (7), StoreID Character (7), ID Character (7), Status Character (1) ); /* F=Full time, P=Part time */ INSERT INTO VALUES ( 01, Store01, 01, F ) ; INSERT INTO VALUES ( 02, Store01, 03, P ) ; CREATE TABLE ( InvID Character (7), InvID Character (7), InvStatus Character (1) ); /* P=Paid, O=Overdue */ INSERT INTO VALUES ( Inv01, 01, P ) ; INSERT INTO VALUES ( Inv02, 01, O ) ; INSERT INTO VALUES ( Inv03, 02, O ) ; CREATE TABLE ( ID Character (7), ID Character (7), State Character (2) ); INSERT INTO VALUES ( 01, 01, CA ) ; INSERT INTO VALUES ( 02, 02, CA ) ; INSERT INTO VALUES ( 03, 03, NV ) ; Copyright 2003 Advanced Data Access Technologies Inc. 15

16 CREATE Table ( ID Character (7), ID Character (7), Code Character (1) ); /* D=Dental, M=Medical, N=None */ INSERT INTO VALUES ( 01, 01, F ) ; INSERT INTO VALUES ( 02, 02, N ) ; CREATE VIEW View AS SELECT * FROM LEFT JOIN ON ID=InvID LEFT JOIN ON ID=ID; CREATE VIEW View AS SELECT.*,.*, E.ID EID, E.ID EID FROM LEFT JOIN ON ID=ID AND Code <> N LEFT JOIN AS E ON ID=E.ID ; CREATE VIEW StoreView AS SELECT * FROM Store LEFT JOIN View ON StoreID=StoreID LEFT JOIN View ON StoreID=StoreID ; CREATE View InvView AS SELECT.*,.*,.*,.* FROM View LEFT JOIN View ON ID=ID; /* SQL Statements from the document text to be run dynamically */ 1.1) SELECT StoreID, ID, InvID, ID, ID, ID, EID FROM StoreView 2.1.1) SELECT InvID FROM StoreView WHERE StoreID= Store ) SELECT InvID FROM StoreView WHERE ID= ) SELECT ID FROM StoreView WHERE InvID= Inv ) SELECT ID FROM StoreView WHERE InvID= Inv ) SELECT InvID FROM StoreView WHERE ID= ) SELECT ID FROM StoreView WHERE InvID= Inv ) SELECT InvID, ID, StoreID, ID FROM StoreView WHERE InvID= Inv : SELECT ID, ID, ID FROM StoreView WHERE InvID= Inv02 Copyright 2003 Advanced Data Access Technologies Inc. 16

17 2.3.1 SELECT ID FROM StoreView WHERE InvID= Inv02 AND ID= ) SELECT ID FROM StoreView WHERE InvID= Inv02 AND ID= ) SELECT InvID, ID FROM StoreView WHERE InvID= Inv02 OR ID= ) SELECT StoreID, ID, ID FROM StoreView WHERE InvID= Inv02 AND ID= 02 OR ID= ) SELECT ID, ID, InvID, ID FROM InvView 3.2) SELECT ID, ID, ID FROM InvView 4.1) SELECT ID, ID, ID, InvID, ID FROM View LEFT JOIN View ON EID=ID 4.2) SELECT ID, ID, InvID, ID FROM View LEFT JOIN View ON EID=ID 4.3) SELECT ID, ID, InvID, ID FROM View LEFT JOIN View ON EID=ID and Status= F 5.1) SELECT DISTINCT SV1.ID, SV1.ID, SV2.ID, SV2.InvID, SV2.ID FROM StoreView SV1 LEFT JOIN StoreView SV2 ON SV1.ID=SV2.ID Copyright 2003 Advanced Data Access Technologies Inc. 17