1)What makes SQL hierarchical processing different 2)What is special about hierarchical structures 3)What are the advantages of hierarchical processing 4)What is full hierarchical processing and querying 5)What are the advantages of full hierarchical processing 6)How can SQL perform hierarchically 7)How does SQL perform data modeling 8)Can SQL views be used with hierarchical processing and joins 9)Is SQL hierarchical processing efficient 10) What makes our SQL hierarchical processing unique 11) How do you specify an SQL hierarchical Query 12) What operational problems does the hierarchical query solve 13) What is total native XML integration by SQL 14) Is SQL hierarchical query different from proprietary XML solutions 15) How is an SQL hierarchical query different than XQuery 16) Is an SQL hierarchical query different than the SQL/XML Standard 17) How does SQL hierarchical query protect my investment 18) What are the benefits of transparent native XML support in SQL 19) Can SQL hierarchical query handle XML advanced capabilities 20) Does the user need to know the data structure 21) Can SQL hierarchical query be used for decision support 22) What are SQL hierarchical query's special uses 23) Are there value added capabilities 24) Is XML updating supported 25) What other benefits are there from hierarchical processing 26) Can SQL hierarchical processing be used in an XML environment 27) Can the relational engine be replace with a hierarchical engine 28) Does SQL native XML integration work with ETL XML integration 29) Why would you buy this product 30) Isn't the Outer Join processing very inefficient 31) Isn't the Outer Join operation difficult to use 32) Is our SQL hierarchical SQL/XML solution standard 33) What is our SQL-based product philosophy 34) What notable findings has our research turned up 35) What is wrong with XML centric support for SQL 36) Why is the SQL/XML integration industry in a mess today 37) Can hierarchical processing increase the value of your data 38) Can SQL process multi-leg queries automatically when XQuery can't 39) Can joins be avoided when accessing physical hierarchical structures 40) How is distributed hierarchical processing automatically performed 41) Can physical structured data be transformed in SQL 42) How are variable structures possible in standard SQL 43) Is full multi-leg hierarchical processing support really necessary 44) How are DTDs and XML Schema used by our SQL/XML support 45) What are all the ways that structures can be built and modified
1) What makes SQL hierarchical processing different
In today's processing environments, XML and relational data will both be common and a database query will often be required to access and process both simultaneously. SQL's hierarchical processing follows ANSI-92 syntax and semantics to integrate relational and XML and relational data.What is really significant and different from any other SQL-based product, is that SQL hierarchical processing integrates XML at a full hierarchical level, automatically preserving and utilizing the hierarchical semantics in the XML data. The query programmer does not even need to be aware that XML is being processed, let alone being processed fully hierarchically along with relational data.
2) What is special about hierarchical structures
Hierarchical structures inherently contain semantic information in the data structure itself pertaining to the relationships between all the data. These relationships being: parents, children, and cousins or more generally, the ascendants, descendents, and relatives. Cousins or relatives are located on different legs and are related by a common ancestor. This total semantic information can be used to nonprocedurally and automatically answer complex questions posed of the data involving any single or multiple legs. This is aided by the fact that hierarchical structures only contain a single path to each data node, making the semantics of the entire structure unambiguous allowing queries to be specified unambiguously and nonprocedurally.
3) What are the advantages of hierarchical processing
The advantage ofhierarchical processing is that the inherent semantics in the hierarchical data can automatically be used in a nonprocedural query language processor to be able to easily specify queries that would otherwise require complex coding with procedural languages. These nonprocedural languages usually can operate dynamically allowing ad hoc querying of complex structures with simple non procedural queries without the user being aware of the structure being processed. These queries can transparently access single paths or even complex combinations of multiple paths of the data structure to automatically process the simplest to the most complex request.
4) What is full hierarchical processing and querying
Full hierarchical processing is the capability to hierarchically process multi-leg structuresproperly filtering the data specified on the WHERE clause and producinga hierarchically preserved result. Hierarchically filtering multi-legged structures can involve selecting data from one leg of the structure based on data in another leg of the structure which involves complex filtering logic. A hierarchically preserved result will normally contain more complete data than a standard relational result since in a hierarchical result, parents do not require children.
5) What are the advantages of hierarchical processing
Most simple query sytems involve data accessing and processing along a single leg which would not include full multi-leg hierarchical processing. But this would usually require defining a separate view for each possible path that requires processing. This is avoided in SQL by defining the entire hierarchical structure once, and every possible single leg or multi-leg query is automatically covered with this single view capability. With SQL's non procedural and navigationless operation, users will expect full hierarchical processing because there is no reason to limit the query to a single leg. Many meaningful queries will involve data items from multiple-legs and with the single view capability, it is a significant and useful benefit with no additional work for the developer. It adds significant value to the data at no cost and is currently not being exploited elsewhere.
6) How can SQL perform hierarchically
SQL is a general purpose database language that operates by following the relational relationships defined between the tables (or nodes) to produce the result represented by the semantics of the relationships specified.If the relationships specified are hierarchical by using the left outer join, the processing is performed hierarchically on hierarchical data structures (hierarchical processing is a valid subset of relational processing). This also assures that the result is logically correct. The left outer join hierarchically models the data processed and specifies the semantics for its processing.
The left outer join also preserves the data hierarchically and can even enable multi-legs of the structure to be of variable length (caused by data preservation). Variable length hierarchical legs are stored in SQL's flat fixed rowsets by padding the missing portions with nulls which are introduced automatically by the left outer join operation. Hierarchical data filteringby the WHERE clause is automatically performed by the relational Cartesian product processing which produces all the valid hierarchical data combinations. Hierarchical node promotion is controlled automatically by the data SELECTed for output. Unselected data is automatically sliced out of the result causing node promotion.
7) How does SQL perform data modeling
SQL performs data modeling of hierarchical structures using the standard SQL left outer join operation. The left outer join preserves the left side over the right side which is hierarchical in nature. Combining these left outer joins allows any multi-leg hierarchical structure to be defined. At each join point the outer join's matching ON clause specifies the join (or link) criteria. When an upper node is joined to more than one lower node, additional legs are created The associated hierarchical semantics of the outer join syntax will cause the relational processing engine to perform hierarchically on the hierarchically modeled structures.
8) Can SQL views be used with hierarchical processing
SQL data modeling of hierarchical structures can be stored in SQL views. These views can model logical relational hierarchical structures as well as physical XML hierarchical structures. In fact, hierarchical views can be embedded or joined to produce larger heterogeneous logical viewsthat can consist of XML and relational data. This offers considerable data structure abstraction for hierarchical data modeling and a seamless heterogeneous unified view.These SQL hierarchical views can be hierarchically optimized, so that a single large hierarchical view can take the place of many specific views greatly increasing the efficiency, ease of use, and flexibility of hierarchical processing.
9) Is SQL hierarchical processing efficient
SQL hierarchical processing is efficient because it is utilizing the inherent hierarchical processing that is possible with ANSI SQL. Powerful hierarchical optimizations are also possible that allows complex hierarchical structures to be accessed very sparingly, which is not the case with standard SQL processing. Normally in SQL, standard join views require all nodes (tables) to be accessed. With SQL hierarchical processing, only the referenced nodes or nodes on the path to referenced nodes need to be accessed. This significantly reduces Cartesian product data explosions. Additionally, joins only need to be performed on logical structures such as relational tables. Physical structures like XML can be efficiently accessed natively and transformed directly to the result rowset that represents the SQL view modeling it without having to simulate expensive join operations. In the future,the ANSI SQL syntax and semantics can directly power a hierarchical data engine (instead of relational engine) which will totally avoid the relational efficiency problems.
10) What makes our SQL hierarchical processing unique
Our SQL hierarchical processing is unique because: it uses ANSI standard SQL to perform XML integration; it can process live native XML; and it also performs complete XML integration where SQL can directly and seamlessly access native XML fields. In addition, our solution supports hierarchicaljoining of structures, full hierarchical structure SQL view support, and XML advanced capabilities (node promotion, fragment processing, structure transformations, duplicate and shared elements, and variable structures). And these are performed naturally in ANSI SQL that are hierarchically standard and follow ANSI SQL semantics.
Most important, is that our SQL hierarchical processing use is not bolted on through the use of functions, but is inherent in ANSI SQL. It supports multiple node types and multiple data occurrences which are both not found in external hierarchical support. XML and other hierarchical structure data sources like IBM's IMS and structured VSAM used by COBOL require the support of multiple node types and multiple data occurrences. External hierarchical support also requires procedural use of its functions while SQL's inherent hierarchical support is automatic and efficient.
11) How do you specify an SQL hierarchical Query
Because hierarchical structures are intuitively descriptive, they are easy to work with using SQL's simple non procedural language consisting primarily of SELECT, FROM, LEFT JOIN, ON and WHERE. Simply SELECT the data items you want selected for output FROM the tables, nodes or views they are located in. If there is more than one table, node or view, use the LEFT JOIN keyword to define how they relate hierarchically and the accompanying ON keyword to specify exactly the link points where they are connected. The WHERE clause can be specified to filter the returned data, The hierarchical semantics of how the filtering is applied to the hierarchical structure being processed is of no concern, just specify your filtering criteria, the hierarchical filtering logic is applied automatically.
12) What operational problems does the hierarchical query solve
Most importantly, the hierarchical query solves the impedance mismatch between relational and hierarchical data that has kept all previous SQL-based XML integrations from succeeding in achieving in 100% integration. The next most significant problem is the inefficiency problem experienced by all SQL-based XML integration solutions when flattening XML data. Our solution avoids these problems and remains ANSI SQL.
13) What is total native XML integration by SQL
Total SQL-based XML integration consists of a number of capabilities. The most important is the dynamic and seamless access of native XML data items from standard SQL. The user does not need to know or care if the data is coming from XML, standard SQL is used and there are no restrictions for native XML. Also important for total native XML integration, is utilizing the hierarchical semantic information associated with the structure of the data.
14) How is hierarchical SQL different from proprietary XML solutions
1) Is ANSI standard,
2) Performs hierarchically,
3) Operates seamlessly and transparently,
4) Is more efficient,
5) Produces accurate hierarchical results that are ANSI standard
15) How is an SQL hierarchical query different than XQuery
1) Is nonprocedural, does not require procedural semantic processing code,
2) Can operate in an ad hoc fasion,
3) Operates hierarcically on entire multi-leg hierarchical structure,
4 Is friendly well known ANSI SQL,
5) Operates seamlessly and transparently
16) How Is SQL hierarchical query different than the SQL/XML standard
1) Publishes XML non procedurally and without XML centric functions,
2) Supports native XML input,
3) Operates on data hierarchically,
4) Operates in an ad hoc fashion,
5) Is seamless and transparent
17) How does SQL hierarchical query protect my investment
SQL hierarchical query is not XML centric it uses its natural hierarchical processing to access XML, no learning curve, and its natural hierarchical processing can still be used on relationaland legacy data to achieve better more efficient and accurate results. If XML changes, ANSI SQL's standard hierarchical operation does not have to change and is still very useful. Advances in XML may be utilized automatically
18) What are the benefits of transparent native XML support in SQL
Besides the advantages that no XML coding, debugging or training is necessary either for XML in general or for the product interface, it also means that that all of SQL's capabilities automatically operate on XML. XML data does not have to be handled separately by special XML centric functions. SQL's full and complete data processing capabilities are available to the XML data. Additionally, with our solution, standard SQL is operating hierarchically so that XML's transparent integration is operating hierarchically across all of SQL's capabilities.
19) Does SQL hierarchical query handle XML advanced capabilities
XML has introduced many previously unconventional hierarchical processing features such as node promotion and fragment processing. Since these are operations that naturally do occur with standard hierarchical processing, SQL hierarchical processing does handle them naturally. XML also has features common in object oriented programming such as variable structures and duplicate node types. These can be handled seamlessly in standard SQL using its standard operations combined with SQL hierarchical query's data modeling ability.
20) Does the user need to know the data structure
Once the hierarchical structures have been defined or transferred into views, the naive user does not need to know the hierarchical data structure. They can enter what fields are to be returned and under what data value criteria. Regardless of the complexity of the multi-leg data structure, the rest is automatically taken care of by SQL because it is a non procedural language powered automatically by the structure semantics. With limited experience, users can also perform hierarchical joining of structures and hierarchical transformations in ANSI SQL.
21) Can SQL hierarchical query be used for decision support
Hierarchical queries can be specified on an ad hoc basis. Because of the non procedural processing of complex multi-leg structures, complex hierarchical semantics correlations between legs of the structures will be performed automatically to assist with decision support based on complex structures that model the problem at hand.With the addition of the powerful hierarchical semantics naturally involved, the value and usefulness of the data is greatly increased inferring enhanced meaning very useful in decision support.
22) What are SQL hierarchical query's special uses
Because standard SQL processing is performing the XML integration automatically and the hierarchical engine can be seamlessly replaced with a hierarchical processing engine, the footprint and efficiency of this SQL processor lends itself well to embedded and mobile uses. And since the data is processed hierarchically, it is excellent for XML and Internet use because it keeps the data at a native, full hierarchical level all the time.
23) Are there value added capabilities
Besides the inherent hierarchical processing, value added hierarchical capabilities will be added to further take advantage of the inherent hierarchical processing. In some cases SQL's syntax will be naturally extended to support new features that will take further advantage of the inherent hierarchical processing. Because any new SQL syntax is working with SQL's natural hierarchical processing, it will be seamless and SQL oriented, not XML centric.
24) Is XML updating supported
XML updating in SQL usually implies updating SQL databases using native XML data. This is easily handled with our XML integration by simply using a sub query to access native XML data that feeds the proper SQL update statement. Navigating to the correct XML hierarchical data node occurrence is performed naturally in the WHERE clause of the sub query.
25) What other benefits are there from hierarchical processing
A huge benefit of this hierarchical processing is that the flat relational data and flattened XML data that has been previously shredded and stored will be reconstituted to its hierarchical level for hierarchical processing. The hierarchical data modeling also increases the speed of development and cuts down on logical errors because the hierarchical semantics are being used automatically to solve the query.
26) Can SQL hierarchical processing be used in an XML environment
Because intuitive nonprocedural XML processing by SQL is extremely powerful and flexible, it has its place in the XML environment too. True nonprocedural multi-leg hierarchical processing is missing from the SQL and XML environments today.
27) Can the relational engine be replaced with a hierarchical engine
The standard relational engine can be considered a black box driven solely by its syntax and semantics input and its defined output.Since standard SQL is performing hierarchical processing exactly following the ANSI SQL syntax and semantics, the relational engine operating hierarchically can be replaced seamlessly and transparently with a hierarchical engine. This solves the memory and processing bottlenecks caused by the relational Cartesian product processing that explodes the data, and also removes the hierarchical processing limitations imposed by flat rowsets.
28) Does SQL native XML integration work with ETL XML integration
The same left outer join data modeling process that makes SQL-based run time XML integration possible can also be used with ETL XML integration to enable the shredded XML data to be reconstituted back to a hierarchical level when processed. The ETL process can automatically generate the required SQL view to accomplish this so that the pre stored and shredded SQL behaves as native XML would when accessed.
29) Why would you buy this product
Why wouldn't you buy it, there is no down side! Its ANSI SQL, seamless, and does not use or require new XML centric syntax requiring no training or risk. It is more efficient because it utilizes inherent SQL hierarchical processing and for the same reason requires a smaller footprint. It actually integrates at a hierarchical level, utilizing the hierarchical semantics-- making the data more valuable. In addition, the well behaved hierarchical data modeled SQL assures that the result is logically correct and accurate. It greatly reduces risk and significantly increases ROI in all categories.
30) Isn't the Outer Join processing very inefficient:
Nothing is further from the truth, in fact inner joins have their own problems with hierarchical processing:
1) Outer joins used in hierarchical processing are not full outer joins (these are the inefficient outer joins).
2) The one sided outer joins used in hierarchical processing do not use the Natural option (another problem area).
3) Hierarchical outer joins do not have to follow the specified join order for outer joins (they are not order dependent), hierarchical structures can be built top-down, bottom-up, width-first or anywhere in between. Inner join optimization can be used in most situations.
4) So it turns out the hierarchical outer join is pretty close in efficiency to the inner join, except the outer join can be hierarchically optimized to only access necessary tables/nodes in a hierarchically modeled structure. This is a very significant optimization for hierarchical processing. Inner joins are always stuck processing all tables in the view.
5) Inner join views may often retrieve data that is then thrown away when a dangling (unmatched) tuple is encountered-- this can be avoided in hierarchical structure processing by top down processing so that there is never any throwaways.
6) This hierarchical optimization is consistent across the entire virtual view consisting of relational and XML data sources and it is backed by ANSI SQL semantics for the one-sided outer join making it a unified view. No other SQL-based solution is this seamless in operation or optimized for hierarchical processing.
7) And lastly, The outer join hierarchical data modeling and structure processing capability does not need to be utilized directly, it can be rewritten dynamically at runtime to use a more efficient processing technique if there was one found. One possibility that will be utilized in the future is the full replacement of the relational engine by a hierarchical engine which can increase efficiency significantly by totally avoiding the Cartesian product bottleneck and the capability to perform large joins by simply linking the structures together.This means that outer joins are transparently performing hierarchical links instead of relational joins.
31) Isn't the Outer Join operation difficult to use
Data modeling utilizing the Outer Join operation is no more difficult than using any data modeling language. The methodology behind this data modeling operation makes its use very logical and easy to use. It is certainly significantly easier to learn and use than a non standard procedural XML centric approach that every other SQL vendor has developed. But most significantly, the data modeling Outer Join views can be automatically generated from meta data sources such as XML DTD or Schema's or even COBOL FD's and used transparently. In conclusion, every SQL based SQL/XML integration solution needs to receive meta information on the hierarchical data structure being processed. With our solution, this is communicated naturally in thestandard ANSI SQL query which also has the significant advantage of being naturally used internally by SQL to perform hierarchically.
32) Is our SQL/XML hierarchical solution standard
No SQL vendor's SQL/XML integration solution is totally standard even when they use one of the SQL/XML standards. The SQL/XML standards are not complete and need to be supplemented by further XML centric operations. Our SQL/XML solution is standard by default, it does not need to use an SQL/XML standard which is also XML centric and it does not need to use supplemental XML centric syntax-- it remains ANSI SQL standard without having to add XML centric syntax or even any additional SQL syntax.
33) What is our SQL-based product philosophy
It seems that the current direction of SQL/XML integration by all SQL vendors is to fully support XML type processing at all costs. This cost is changing SQL into a procedural XML centric language. Our philosophy for XML support in SQL is to keep SQL operating in its pristine natural nonprocedural manner and to process XML in a transparent SQL fashion, not sacrificing SQL's standard operation for XML specific processing. By utilizing ANSI SQL's inherent hierarchical processing capability, it is possible to remain ANSI standard while transparently integrating XML at hierarchical processing levels that greatly exceed current SQL/XML solutions that are XML centric.
We also realize that a complete SQL/XML integration solution requires two related capabilities. Not only the integration of relational and XML data, but also the integration of SQL and XML system capabilities. Our solution integrates hierarchical and relational data at a hierarchical level losing no data quality and utilizing the hierarchical semantics in the XML data. Our SQL and XML system capabilities integration is accomplished by our transparent operation. It enables all capabilities of ANSI SQL to be applied to native XML data while also inherently supporting XML's native hierarchical processing capabilities such as node promotion, fragment processing, structure transformation, and the support of variable structures supported in ANSI SQL.
34) Notable findings our research has turned up
·Hierarchical processing is a valid subset of relational processing
·Full hierarchical data modeling in SQL is possible
·Hierarchical optimizations also apply to relational processing
·WHERE and ON clauses work differently each with their own advantages
·There is an ANSI SQL join execution stacking for structure processing
·Variable structures are possible in ANSI SQL
·Hierarchical structure transformation in SQL is possible
·Linking below the root of the lower joined structure is possible and useful
·The discovery of Lowest Common Ancestor (LCA) processing in SQL
35) What is wrong with XML centric support for SQL
SQL should not be influenced into changing its operating style and ease of use to suit foreign data formats. This is a slippery slope which will undermine SQL's strong points such as its nonprocedural processing and open orthogonal operation (no restrictions). A better approach is to support a general, non specific well grounded operation such as hierarchical processing. In this case, hierarchical processing centric support would automatically include XML support. Fortunately SQL does naturally support hierarchical processing, so there is no need for XML centric operations. Any additional value added hierarchical syntax or semantics would be a natural addition that does not change SQL's natural operation.
36) Why is the SQL/XML integration industry in a mess today
While XML is standardized, its integration into SQL was unchecked for many years after the XML spec came out. By the time the ANSI SQLX Group was formed to explore SQL/XML integration and standardization, most every SQL vendor had implemented their own version of XML support. The SQLX Group was comprised of SQL vendors who already had their own proprietary solutions up and running and were not going to throwaway all the work, expense and branding they had already done on their commercial solutions to work in a different direction toward a standard undifferentiated solution. Can't say as I blame them. This is why the new SQL/XML standards are not a complete solution.
37)Can hierarchical processing increase the value of your data
With XML's vast quantity of hierarchical semantics and SQL's capability to perform multi-leg queries that automatically utilizes the hierarchical semantics, semantically complex SQL queries can be nonprocedurally specified and processed. These are queries that languages such as XQuery require a large quantity of semantics to be procedurally specified making them impractical for common query or ad hoc use. For this reason, SQL nonprocedural multi-leg processing automatically adds significant value to the data by increasing its meaning dynamically.
38) Can SQL process multi-leg queries automatically when XQuery can't
Even though XQuery was designed for hierarchical processing, the automatic hierarchical processing of the language offers no help for correlating the processing of multi-leg queries. This complicated logic is left for the user to specifically specify. An example would be selecting data from one leg of the structure based on data values from another leg of the structure. This requires hierarchical processing logic known as Lowest Common Ancestor (LCA) logic. Interestingly, even though SQL was not designed for hierarchical processing, its inherent hierarchical processing supports LCA logic naturally enabling it to support single and multiple leg queries automatically. This also means that the user does not need to know the data structure
39) Can joins be avoided when accessing physical hierarchical structures
When physical hierarchical structures such as XML are modeled by SQL Left Outer Joins, there is no need to physically join the node segments when they are accessed. The Left Outer Joins act only as metadata describing the structure of the data structure. This allows physical structures to be natively accessed in their own efficient way and directly formed into the desired rowset without performing costly joins.
40) How is distributed hierarchical processing automatically performed
When a given SQL system automatically breaks up the SQL request to send SQL segmentsto different remote locations, the Left Outer Join SQL segments still automatically processes the remote data portion hierarchically at the remote site. And when the hierarchically processed data is returned it is still properly hierarchically mapped as if it had been processed at the local site. This means that the distributed hierarchical processing is automatically performed seamlessly.
41) Can physical structured data be transformed in SQL
When logical or physical data is read into or joined into a relational working set it becomes contiguous and can be selectively accessed efficiently and at a high intuitive level. Using the SQL SELECT clause and SQL's alias capability to distinguish separate segments, the different fragments can be rejoined into a different hierarchical structure. This allows standard SQL to perform hierarchical transformations directly and seamlessly on logical and physical heterogeneous data.
42) How are variable structures possible in standard SQL
The ANSI SQL-92 Outer Join operation introduced the ON clause as a replacement for using the WHERE clause. This enables specifying the join criteria separately for each join operation as it is processed and performed.On clauses are performed as the tables are joined, while the WHERE clause is applied after all the joins are performed. This means that the WHERE clause affects the entire row or structure while the ON clause only affects a portion of the path or row it is used on. This is why the ON clause has the potential to dynamically control the data structure formation in a precise way. This can be based on data values in a higher level of the structure analogous to COBOL's Depending On clause.
43) Is full multi-leg hierarchical processing support really necessary Multi-leg hierarchical processing is known as nonlinear hierarchical processing. The relatively new XML industry having been awayfrom hierarchical processing for thirty years still has a two dimensional relational mindset. It has pretty much overlooked XML’s multi-leg semantics—the semantics that exist between the different legs of the structure. On the face of this semantics is the ability to increase the value of the data by correlating the semantics between legs to solve multi-leg queries. This is a capability that will take a while to appreciate. What is not realized is that nonlinear hierarchical support includes the ability to dynamically and nonprocedurally access any single leg query. This means the user does not need to know the data structure and ad hoc queries are possible. This capability can be immediately appreciated. In order for the user not to know the structure also implies that multi-leg queries most be supported. This makes sense since if the user does not need to know the structure, how do they know if their query accesses one or more legs. So full nonlinear processing is needed for full user friendly access. 44) How are DTDs and XML Schema used by our SQL/XML support Following are philosophy for the support of XML in relational processing, XML integration in SQL does not require an XML metadata definition such as a DTD or Schema. If they are available they can be utilized in two ways. They can still be utilized to verify input XML documents in the XML controlled input process. They can also be utilized to generate the required SQL hierarchical view structure and utilize the rules and limitations that are specified in the DTD or Schema that are supported in the SQL/XML processing.
45) What are all the ways that structures can be created and modified Besides the basic data modeling (7) and the joining (8) of data structures which change data structure, there are three other ways to modify the data structure being processed. These are by using the SELECT operator (45), by data value (42), and by structure transformation (41). The SQL SELECT operator is the most natural; it controls what data is output which also controls the processing that is performed. Only nodes that have data selected are output. Using the ON clause to test data values in the structure can be used to produce variable structures that generate portions of the structure based on data values in the structure. And the last way that structures can be changed is by structure transformation that is possible in SQL.