new relational discoveries produce a powerful semantic sql

New Relational Discoveries Produce New Generation in SQL Semantic CapabilitiesFour new ANSI SQL relational processing discoveries and their 15 breakthrough capabilities, fundamental principles, and operation are explained in this presentation. These capabilities add powerful new operations while eliminating problem SQL areas. The first discovery supports advanced capabilities through the natural integration of multipath hierarchical processing into the front end of the relational processing. This supports relational processing in a powerful hierarchical multipath nonlinear fashion. This is both relationally sound and hierarchically principled using standard SQL syntax. On top of this SQL hierarchical processing model, a powerful network structure is controlled by dynamically referencing data items across paths. This uses a second powerful processing discovery of inherent LCA processing that naturally determines and processes the semantic meaning across pathways automatically. These capabilities produce an extremely powerful and advanced new generation of SQL semantic operation.

Powerful New SQL Hierarchical Capabilities Can be Utilized TogetherThe 15 new breakthroughs in hierarchical ANSI SQL on this slide are made possible by the new relational processing discoveries. They are extremely powerful and can be used in any combination synergistically increasing their capabilities. This creates new uses and capabilities not previously available or possible. These will cover each of these new capabilities listed on this slide using visual examples. The current bulleted sub topic being shown and described in each following slide will be highlighted and underlined. A colored arrow may also be used to draw attention to active areas in the current slide. The following slides are connected with the main heading or bulleted item being described. Some info may be repeated across slides to establish context.

Defining the SQL Multipath Hierarchical Data ModelStarting with SQL’s new hierarchical data modeling of relational tables on this slide, it is shown how relational tables (or nodes) A, B & C can be dynamically modeled hierarchically using only the SQL Left Join operation. It is used to establish the dynamic hierarchical data modelled roadmap used to control the active query. The introduction of LEFT Joins in the SQL-92 standard enables powerful hierarchical structures to be modeled. Non-hierarchical data modeling will trigger an error condition preventing incorrect hierarchical operation. The inherently supported SQL multipath hierarchically modelled structure naturally enables powerful concurrent multipath hierarchical LCA processing for deriving a solution from multiple paths. This enables SQL to concurrently test data from multiple pathways to naturally produce a powerful semantically meaningful LCA result. The WHERE clause can also be used to reference data items across the data model pathways in a powerful network fashion.

Integrating Hierarchical Processing into Relational ProcessingThis is the 1 st of 4 new relational breakthrough discoveries. SQL’s standard relational processing naturally utilizes the hierarchical processing capabilities of only the SQL-92 Left Outer join where less syntax produces more powerful processing. It preserves data on the left side of the Left Join operation when there are no matching data values on the right side. This makes it operate fully hierarchically. The multiple “ON” clauses replace the older single WHERE clause allowing it to precisely data model hierarchical multipath structures. This data modeling is shown at the green arrow. With the red arrow at the start of the hierarchically modelled structure, nodes A, B, C, D and E are modelled in turn. They each add a path using the ON clauses to precisely connect each node as shown. When the multipath hierarchically modelled SQL at the green arrow is processed, SQL is operating at a greatly increased semantic processing level because the semantics are known from the data modeling already applied.

Hierarchical Processing is Used in Relational ProcessingThe inherent hierarchical processing possible in standard SQL is an important and useful basic discovery. It has shown that powerful hierarchical processing is a subset of relational processing and can be used for complete natural integration. This also allows relational data independence and hierarchical data modeling to naturally combine the advantages of both. The red arrow points to the box that uses only Left outer joins operations to enable powerful hierarchical multipath data modeling and processing. The hierarchical processing follows natural data preservation principles. This adds to the inherent correctness along with relational processing’s powerful mathematical foundation. This produces a new semantic SQL operating at a much higher processing level. It inherently understands hierarchical data modeling and processing that naturally utilize new SQL hierarchical semantics. This also means that there is no new code to support.

SQL Hierarchical Processing Supports Only Structured Data Using SQL to support full multipath hierarchical processing requires limiting the processing to structured data. This makes SQL more powerful and easier to use using only powerful structured processing. This means there are only single paths to each node type in the structure diagram starting from the red arrow. This makes the hierarchical structure unambiguous enabling it to be naturally navigated even with its new more powerful hierarchical structure capability. This natural internal navigation operates by not having to make any navigational path selection decisions. All referenced nodes are accessed using only a single path. This unambiguous automatic navigation of hierarchical structures integrates naturally with relational processing’s standard navigationless access.

SQL Hierarchical Data Modeling Language has PrinciplesSQL’s seamless hierarchical data modeling language and syntax shown at the red arrow is based on well-known hierarchical data preservation principles. A parent node can exist W/O a child, but a child cannot exist W/O a parent and a child can have only one parent. If this is followed, it results in natural correctness. This means SQL hierarchical processing is based on combined relational and hierarchical principles. It still supports both the data independence of relational and the semantics in hierarchical structures. This allows any hierarchical and flat structures to be dynamically modeled together in any way and processed as semantically rich hierarchical structures. Relational processing utilizing dynamic hierarchical processing now becomes extremely powerful and useful for accurate complex processing.

Uses ON Clauses and Not WHERE Clause for Data ModelingStarting at the red arrow, it can be seen how multiple ON clauses are much more precise for data modeling than the older single WHERE clause was. Another reason for this is that the ON clause operates more locally. It only affects the path that it is used on and only from its initial point of use downward. This also increases the preciseness of the data modeling. The WHERE clause is used now only for global operations which can selectively affect any nodes in the entire structure. This is a very powerful operation in its own right. So it should be used only for global hierarchical data filtering and leave the ON clause for more local and precise data modeling operations where it is more useful and flexible. This separation of duties makes each operation more powerful and distinct.

Use the WHERE Clause for Hierarchical Global Data Filtering Unlike the local ON clause, the WHERE clause is global and can specify data anywhere in the structure to be matched. This is shown by preserving data that relies on WHERE C.val=‘C2’ by the red arrow. When the “C2” value matches, the search goes in all directions from ‘C2’ to the SELECTed data types in nodes A, B, C, D and E to retrieve them. Nodes D and E are below node C, root A is above. If a node A data occurrence match is found, the path will deflect naturally and hierarchically filtered down to node B because its parent exists which is standard SQL operation. This is shown in both the flat relational structure and its hierarchical ViewX data structure where the shaded boxes represent the data retrieved. At the blue arrow, it is shown that the relational structure can be automatically converted to its hierarchical internal representation making it easier to utilize. This is achieved by removing replicated data, while preserving duplicate data by using a new duplicate data data-type.

Multipath Concurrent Hierarchical Processing Hierarchical structures are composed of parent nodes and their children in a hierarchical fashion. With this basic hierarchical processing, parents are singular with only one path in and any number of paths out supporting multiple pathways. This makes the multipath structures also unambiguous, allowing it to be accessed schema-free in a navigationless fashion as is standard for SQL. The red arrows in the diagram show examples of multiple hierarchical pathways that will naturally support powerful multipath concurrent hierarchical processing. This advanced multipath processing enables producing a single query result using the natural LCA processing shown.

Multiple Data Occurrence Organization Fully SupportedMultipath hierarchical structures can support the powerful feature of multiple node occurrences. These are shown in the current slide where nodes B, C, D and E each have multiple occurrences. Notice that node occurrences E1 and E2 are located under occurrence C1 while node occurrences E3 and E4 are under node occurrence C2. They are in separate node occurrence groups and cannot be processed together because they have separate parent occurrences C1 and C2. This supports a much higher level of data organization that naturally processes the data occurrences. This enables multiple node occurrences to have their own set of data combinations making their overall operation more flexible and precise.

Multipath Concurrent Processing Greatly Increases AnalyticsThe two different queries at the big green arrow produce the same internal hierarchical processing loops because they use the same structure shown and the same SELECTed multipath locations at nodes B, D and E. This produces results tailored to their different query specifications shown. The multipath hierarchical processing requires very special processing for queries connecting data and generating semantics across pathways. This is known technically and academically as Lowest Common Ancestor (LCA) processing with its new use now naturally performed by SQL multipath hierarchical processing. This concurrent multipath hierarchical processing shown in red can be further enhanced by referencing across active pathways which naturally utilizes LCA processing. This greatly increases the analytical processing capabilities in new, more: meaningful, accurate and powerful ways by utilizing concurrent multiple active and connected pathways that can support powerful network structures.

Inherent Lowest Common Ancestor (LCA) Multipath ProcessingThe 2nd of 4 relational breakthrough discoveries is the very powerful LCA processing engine found operating naturally and inherently in ANSI SQL. Older physical hierarchical structures required a complex search for LCAs. For example, the data references B, D & E shown in red arrows would have required searching upwards from the referenced nodes B, D and E to locate LCA nodes C and then A. But SQL hierarchical LCA processing is occurring inherently in SQL requiring no searching or coding. This natural LCA processing utilizes the relational processing’s Cartesian product’s operation. The generated Cartesian product controlling the search up to the LCAs is shown in red. LCAs are at the connection point where the pathways meet. This natural operation enables LCA’s operation to any nesting level. This natural LCA processing is necessary because its required ability can become too complex or costly to code by hand.

LCA Naturally Determines the Most Meaningful ResultsLCA processing is naturally triggered by a WHERE clause reference to connect multiple pathways shown in red. Both of these queries are shown on this slide at the big green arrow. This produces a combination of values used to test for a matching data combination produced from the inherent Cartesian product shown by the black box. This results in the tightest most limiting range of data references for the active query to derive the most meaningful result using the smallest processing area required. This is naturally correct and takes into account all the different multipath query references. Any number of nodes can be connected across pathways greatly increasing the analytical querying power. This makes concurrent multipath processing with LCA processing very accurate and efficient. The Cartesian product data around an LCA extends to its lowest node references, D and E for node C and then B and C for node A as shown on this slide.

LCA Processing Can Also Include Multiple LCA NestingThis diagram shows how LCA processing in the red circle occurs and nests naturally when multiple LCAs are needed. As few LCAs as necessary will be naturally used across multiple pathways shown in green. Two path references triggers an LCA processing, a third triggers another one and so on from the bottom up. This keeps each LCA processing as small as possible with natural LCA nesting shown by the red upward arrows. This is controlled by the relational Cartesian product processing. When SQL is performing hierarchically, its Cartesian product is naturally performing the required LCA processing, so the operation is transparent occurring naturally. I was not aware of this LCA operation occurring inherently until I realized something had to be naturally causing it because the multipath results were always correct. I found this natural LCA processing in the Cartesian product controlled by the initial hierarchical processing model.

Multipath Hierarchical Structures Can Process NetworksMultipath hierarchical structures use LCA processing to enable nodes in the structure to be connected by referencing their data. For example, node references B and Y by the green arrows are not directly connected, but can be naturally connected at LCA node A by referencing as in “SELECT B.b WHERE Y.y=4” in red. Adding Node Z at the orange arrow, “SELECT B.b WHERE Y.y=Z.z” in red connects all three B, Y, Z nodes. This nests LCA X under LCA A. The bottom left shows the white structure as the underlying hierarchical model boxing-in LCA operation. All 25 connections possible from the 7 nodes are shown in black at bottom left. These can be created by a single WHERE clause reference using AND and OR operations linking them together. This enables all connections to be tested together because every node can directly reference every other node as shown by the black lines over the white lines. This supports an extraordinarily powerful networked data analysis from many concurrent directions.

Operational Overview of Semantic SQL with Concurrent Multipath Networking 1 2 3 3 Hierarchical Data Modeling WHERE Clause Use Networking

Define desired hierarchical data model and multipath processing using input: flat tables, nodes and structure views. Then move to WHERE clause at position 2 to perform WHERE clause.

Dynamically compose and execute WHERE clause to create complex network across data model nodes from position 1. This allows all nodes to be connected in any way at position 2 as shown above.

Networking completes LCA processing at position 3. Then the user can go back to position 2 to specify another query or the user can go back to position 1 to re-specify a new data model and re-start from position 2.

Dynamic Logical Hierarchical Structure JoiningThe red arrow points to hierarchical structure ABC being created in a view. The view is used by referencing its name, ABC. The green arrow points to the structure being defined which is modelled behind the green arrow. Hierarchical physical structures are now back again with the introduction of XML. They are more powerful than before with the discovery of SQL inherent multipath hierarchical processing in relational databases. With logical hierarchical processing, multipath hierarchical structures and views can be hierarchically combined dynamically in any order and then processed. These new powerful logical structures are also very efficient because they are temporary and naturally freed-up after the query completes. This new SQL hierarchical processing can be fully dynamic and logical. This adds significant flexibility increasing analysis.

User Does Not Need to Know the Data Structure to QueryAfter a logical structure is dynamically created, it is processed as a single structure. In addition, hierarchical structures can also be heterogeneously combined from: fixed; dynamic; remote; and view structures which are also processed as a final logical structure. Most importantly, the user does not need to know the structure or have to navigate the heterogeneous multipath structure. This is because all types of hierarchical structures are unambiguous with only a single path to each node. This allows navigationless schema-free navigation regardless of how the final heterogeneous hierarchical structure is composed.

Joining Structures Increases Data Value & Semantics The increasing of hierarchical semantics by dynamically combining structures or parts of structures also results in ever increasing data values. As multipath structures continue to grow downwards shown by the red arrows, they split paths continually increasing the number of paths. As this occurs, the data and implied semantics are shared across more and more paths increasing data value and semantics which are naturally utilized. Hierarchical structures have an inherent capability to create more value than is captured. The sharing of data across paths also increases the number of possible queries. References to multiple paths use powerful LCA processing to utilize this complex concurrent multipath processing further enhancing the semantics. This enables the ability to utilize node data from hierarchically related pathways that always derives meaningful results.

Joining Hierarchical Views Done Same as in Hierarchical Data ModelingThe joining of hierarchical views is also performed in the exact same easy way the hierarchical data model was created shown in the boxes in this slide. This is by using Left joins to hierarchically model structures. In this example, hierarchical views ABC and XYZ are easily hierarchically joined dynamically using Left joins. This is shown in the dynamic SELECT statement at the red arrow. This is also how logical hierarchical views are dynamically combined on the fly. This is performed with a simple SQL SELECT query that models structures and joins views both in the same exact way. This makes them seamless and intuitive operations as shown.

Query Result Saved as a View for Reuse in QueryingThe query result can be saved for reuse in following queries using the SAVE keyword. “SAVE VIEW as XYZ” will save the query as a view with the given name XYZ. “SAVE DATA as XYZ” will save the query as data with the given name XYZ. “SAVE DATA …” will preserve the exact data result and will operate as a view, while “SAVE VIEW…” will save the view which will always produce the most current results of the view. Either one can be used anywhere in a query that a view can be used. As an example, the red arrow points to the combined view syntax of the join of two view structures from a previous join that can be save as DATA or a VIEW.

Data Driven Hierarchical Structure ModelingData driven processing is another very powerful additional use of the ON clause that is not generally realized. It can be used to specify simple to complex variable data-driven building of hierarchical structures. It uses a compound ON clause argument that tests the value of stored data items to control the dynamic data-driven structure generation. This example will only perform the join of XYZ to ABC if the data argument X=4 is also true. This is shown in the SELECT statement directly above the red arrow. This also can allow multiple SELECTs to be used to select a view from a number of many possible views depending on a database data value match. This is a powerful natural selection capability that is available to use when needed.

Structure-Aware Processing Extends Dynamic UsesEnabling SQL to perform more powerful and extended dynamic capabilities is an extremely useful and powerful enhancement for SQL. SQL has always been a dynamic language allowing the SQL to be defined dynamically. But previously it could not use this dynamic capability any further. After SQL had dynamically been specified and executed, it remained static. Dynamic specifying of structures to be joined is possible. But further dynamic operations required metadata knowledge of the completely formed structure that was not previously available. This new extended dynamic level of processing in SQL is now possible using a new Structure-Aware processing.

Structure-Aware Processing for Dynamic StructuresWith Structure-Aware processing shown at the red arrow, SQL processing can be seamlessly extended to the further processing of dynamically created structures. This is where SQL can continue to operate on dynamically fully created structures. This takes into consideration new capabilities requiring knowledge of the dynamically created structures. With this Structure-aware processing, processing can be applied after dynamically created structures are fully created. This extended structure-aware processing can seamlessly support new internal and external operations in SQL.

Data Structure Extraction (DSE) Exposes Metadata 4 UseThe dynamic meta information required for structure-aware processing is derived automatically. With SQL limited to using only the Left join to perform hierarchically, the SQL contains this metadata information. This means the run-time hierarchical SQL Left outer join syntax at the red arrow can be automatically parsed. This is performed by the new Data Structure Extraction (DSE) processor at the green arrow. It will interpret the dynamic hierarchical structure using the DSE process to parse the Left joins and ON clauses to dynamically determine the data structure. This is the 3rd of 4 new breakthrough discoveries. It enables structure-aware processing to greatly extend the dynamic structure processing to unlimited new and previously unavailable capabilities.

This DSE Enables Powerful New Dynamic CapabilitiesThe Data Structure Extraction (DSE) syntax parsing at the red arrow dynamically converts the combined input structure view syntax into metadata representing the combined structure. This is handed off to the Structure-Aware routine pointed to by the green arrow to seamlessly supply all the advanced capabilities requiring this dynamic information. An example use is the further converting of the dynamic or internal hierarchical structure to external formats such as XML formatted output. This requires knowledge of the structure metadata supplied from the Structure-Aware routine. Another example is supporting hierarchical optimization which also requires knowledge of the structure size and structure metadata supplied by the new Structure-Aware routine.

following Slides may Utilize this New Dynamic AbilityThe new capabilities described in the following slides may use the structure-aware capability to support their new capability. These slides may inherently use the structure-aware processing capability to enable advanced new extended dynamic capabilities automatically. The structure-aware capability extracts the final combined metadata structure which is under the red arrow as the result hierarchical structure. The executing SQL can utilize this result for further processing. This DSE final structure information will also be used to transform the final relational structure result to a hierarchical multipath result. This adds considerably to its final flexibility and further use.

Advanced Hierarchical Data Modeling Breakthrough The 4th of 4 breakthrough discoveries is that SQL inherently supports linking hierarchically anywhere below the lower level structure’s root. This can be to any lower level node location to join hierarchical structures. An example is shown at the red arrow node Z location. Before this discovery, hierarchical data modeling had been limited to only linking to the lower structure root entry, node X in this case. Linking directly below the root can be freely performed hierarchically. This is because the root is always the hierarchically data modelled point of entry shown as X next to the green arrow. Linking below the root works in ANSI SQL because the lower structure is fully constructed and self-contained by view materialization before it is linked to. This is described further in the following slides.

Performs Powerful Semantically Accurate MashupsLinking hierarchically directly below the root at the red arrow means that linking to any node below the root is valid. This significantly increases the number of ways hierarchical structures can be linked together. The upper level structure also has no restrictions from where it can be linked from as long as the paths out are hierarchically valid. Creating non-hierarchical structures will terminate the current operation. The newer lower level linking requires no restrictions to joining anywhere in the lower structure enabling a much wider range of valid queries. This operation also supports a very powerful mashup that fully maintains the hierarchical semantics naturally and correctly.

Produces Extremely Precise Semantic MeaningBeing able to Link anywhere below the lower level structure root also allows more precise semantic meaning in the result. In this slide, node C is linked directly to the lower level structure’s node Z which is at the red arrow. The result would be semantically different if it had been linked to node Y at the green arrow. This multiple choice adds considerably more accuracy and preciseness for the query and its processing. This level of automatic hierarchical query preciseness has not been possible before. This precise lower level joining results in the same data modeling which is always to the lower level root shown at the blue arrow. This occurs regardless of which lower level link point was linked to because the root has already been established as node X. This also allows additional and variable data filtering controlled by the choice of different lower level node link points.

Supports Unlimited Linking Below Root Capability Linking below the root of the lower level structure XYZ requires that it to be fully materialized before it is linked to. This will treat the lower structure as a solid fully formed structure in isolation with its own semantics already established. This causes it to always be modelled starting at its root by the red arrow to be semantically accurate while being directly joined to any node in the fully formed lower structure. This enables it to be data filtered starting at this lower node link point node Z at the green arrow. This view materialization in isolation is accomplished by ANSI SQL’s powerful and flexible outer join syntax processing. It is naturally performed as shown in the next slide.

Uses Powerful Little Known Natural SQL View Syntax The SQL in the box shows how SQL’s Left join processing causes a view’s full expansion before joined. This occurs in SQL generation producing multiple “Left Joins” with no intervening ON clauses. This ANSI SQL syntax naturally produces nesting of views on one side, and sequential ON clauses with no intervening “Join” on the other side causing un-nesting. This triggers the full expansion of view XYZ in bold at the blue arrow before it is joined to view ABC. This nesting is natural with view expansion shown at the green arrow pointing to the SQL expanded syntax: “LEFT JOIN X LEFT JOIN Y“and ending with this syntax: “ON X.x=Z.z ON C.c=Z,z. This view expansion occurs naturally in the expanded bold syntax at the blue arrow proving this syntax naturally occurs and executes correctly. This delays joining view XYZ to view ABC until view XYZ is fully expanded. This seamless capability makes views more powerful and easier to use.

Remote Heterogeneous Input Access & ProcessingThe red arrow in this slide points to view XYZ which in this example represents a remote XML view. It is retrieved and heterogeneously combined transparently and seamlessly with the SQL hierarchical ABC view shown by the green arrow. This enables introducing data from remote locations seamlessly such as XML and combining it heterogeneously with SQL source. This is possible and seamless because XML is also hierarchical. The XML definition pointed to by the blue arrow in the lower box requires a more specific hierarchical definition as shown. This is because the XML definition is external and requires additional data specific to XML to be made. The hierarchical structure in the XML definition is defined by the Parent keywords indicated by the double pointed purple arrow. This may require further SQL additions to handle the different types of remote hierarchical databases.

Simple Specifications Naturally Control ProcessingUsing the ANSI SQL SELECT list at the green arrow, only the data items to be retrieved, circled in red (A.a, B.b, D.d), need to be specified. They are specified in any order with no change in result. A change in processing only requires adding or removing data items in the SELECT list. The SELECT’s FROM clause generates the hierarchical data model to be semantically followed and invokes the SQL at the red arrow. This is further processed if multipath concurrent processing is performed using the WHERE clause to make the cross-path connections. This is performed by the inherent relational Cartesian product and its natural LCA processing producing the result shown by the blue arrow. This is how the data SELECT list, FROM clause and WHERE clause naturally controls complex processing easily and accurately.

Hierarchical Optimized Data Access with Node RemovalUsing the SQL hierarchical SELECT list operation at the green arrow, it can be automatically determined which nodes are outside the hierarchical range of the active query. These nodes will not require accessing. They are removed from consideration before query processing starts. This hierarchical optimization is shown in this slide where node E is not referenced and is out of range, so it is not accessed. This is indicated by a slash through node E which is pointed to by the red arrow. This hierarchical optimization can also increase the efficiency and effectiveness of the standard relational optimization that follows. This is because it has reduced the required relational optimization by making it simpler to process and more effective.

Automatic Data Aggregation with Node PromotionWith SQL’s non-procedural SELECT list processing at the green arrow; automatic data aggregation, node promotion and node collection are performed by only specifying which data types are to be retrieved. This is shown in this slide’s result pointed to by the red arrow where node C was compressed out between nodes A and D. This happens because it was not referenced, but it is still required for internal navigation from node A to node D. In relational databases this removal is caused by relational projection. In hierarchical processing, this removal is called node promotion. With node promotion, the remaining output nodes are collected hierarchically together automatically producing a nicely aggregated data result.

Enables Global Views, Easier To Use, Has No OverheadWith hierarchical optimization being automatically performed in each view, hierarchical views become global views by also supporting subsets of the global view. They can handle more than one view cutting down on the number of views necessary. This means a given global view can service more than one query after the view is optimized. This reduces the number of different views necessary, which makes querying much easier, automatic and efficient for the user. With hierarchical optimization always operating, there is no overhead for global views. This is because each query only accesses the data it needs to.

Allows an Infinite Number of Dynamic New CapabilitiesThe natural power of the SQL data SELECT controlling internal processing combined with the addition of structure-aware processing can enable an infinite number of new capabilities. For example, this can support SQL transparent hierarchical XML processing of input and dynamically created output as fully formatted XML. This occurs after the dynamic structure is generated. This has been done and is shown on the following slide. This enables unlimited new capabilities.

New Duplicate Data Type Fixes Replicated Data Problems Joining relational tables usually produces the relational Cartesian product which explodes data inserting replicated data as place holders for missing row matches. This adds severe inefficiencies and can cause problems when removing replicated data when there is duplicate data. This is because the duplicate rows may be removed when they should be preserved. The duplicate data type solution above works seamlessly by supporting both duplicate data and replicated data to tell them apart. This requires internal additions to SQL to keep track and separate real data from duplicate data by tagging it. The duplicate data type also decreases unnecessary data replication further increasing hierarchical optimization already described. This reducing of the replicated data also increases accuracy and correctness.

Hierarchical SQL Transparently Supports XML This slide shows the SQL SELECT statement used to produce the automatically formatted hierarchical XML pointed to by the red arrow. This is possible because SQL hierarchical processing can support dynamic and automatic structured XML formatted I/O. This uses structure-aware processing to know how to format the XML from the final physical hierarchical structure result. The unambiguous multipath structured data also enables navigationless, schema-free XML access. Notice that the node promotion caused the unreferenced Cust and Emp nodes next to the green arrows are correctly sliced out in their dynamically produced XML. This produces a nicely aggregated result. This can support any hierarchical structure such as IBM’s IMS database.

SQL/XML Std Has Hierarchical Inner Join ProblemsSecret agendas and politics kept the Inner join as the default join for the SQL/XML Standard and XQuery. The designers believed this would more easily lead the way from SQL to XML. This was a terrible decision, because the Inner join does not support hierarchical structures like XML. In fact it destroys them turning them into flat structures. The SQL/XML Standard designers wanted to move beyond SQL and replace SQL with XQuery. They thought keeping the Inner join would help transition from SQL to XQuery by keeping the familiar Inner join. I have some knowledge and insight into these problems having been one of the initial members to the SQLX Group working on the SQL/XML Standard. These decisions have caused the problems discussed in the following slides

SQL/XML Std Requires Procedural Code & NavigationThe SQL/XML Standard requires procedural code and user navigation for accessing XML from SQL. This is because it supports semi-structured data requiring user navigation. Semi-structured data requires user navigation because a node type can be located from more than one path, each has a different semantics. The new SQL hierarchical navigationless access uses only structured data with single paths to each node type. It does not need to be user navigated because the structure is unambiguous enabling automatic navigation. For these reasons, the automatic hierarchical SQL XML support is consistently accurate and correct for standard structured SQL and can be seamlessly extended to all other hierarchical languages. On the other hand, the SQL/XML semi-structured Standard with multiple paths to nodes requires user navigation. This is better for understanding and using unstructured data. Both ways have their good and bad points.

SQL/XML Std Doesn’t Support Automatic LCA LogicFinally, there was a failure to support automatic LCA processing by XQuery. Even trying to use a specialized LCA function did not work well and often enough. LCA processing is extremely complex and impractical to code by hand. On the other hand, ANSI SQL can naturally and automatically support full LCA multipath processing. This includes XML keyword search using SQL. This has now been utilized in hierarchical SQL’s newly discovered inherent multipath hierarchical processing capability. This significantly synergizes this combination and integration of relational and hierarchical processing’s new semantic processing capabilities of.

Hierarchical SQL Also Supports Multipath Ordering Rows in ANSI SQL are unordered and flat while XML is ordered and supports multiple path processing. So SQL hierarchical processing does support ordering of multipath processing. Because of this, the XML input order and multipath processing is preserved in SQL hierarchical processing. Notice in the diagram that the Invoice and Eaddr data types are independently ordered on their different paths at the green arrows. Their separate data occurrences are pointed to by the red arrows. This multipath ordering can also be used to perform multipath summaries. The XML query above produces the XML output shown which was produced from the SQL hierarchical processor. It contains the ordering capability. Multipath aggregates and summaries could also be supported in the same way.

Seamless Peer-to-Peer Real-Time Automatic Metadata MaintenancePeer-to-peer processing supports global concurrent multi-path SQL metadata: communication, design and coding. This allows SQL design and coding to be performed collaboratively to build and test SQL in real-time. In the example shown, P1 for peer1 starts this collaborative SQL operation inputting and combining of separate relational tables A, B, C and the fixed hierarchical structure XYZ shown by the green arrows. P1 passes them to separate paths P2 and P3 at the purple arrows for separate processing that builds the SQL in parallel. This proceeds until the two different paths are joined combining the two SQL structures into a single SQL result at P4 by the red arrows. The final SQL source at P4 is shown at the blue arrow. Transparently supporting the entire P-to-P metadata processing automatically is seamlessly performed by the new Automatic Metadata Maintenance. This hides all global metadata processing from the user.

Connecting Unrelated StructuresViews CustView and EmpView from different structures at the blue arrows have no direct relationships in their data values. They can still be related through a simple relational association table that supplies the needed relationships. An advantage of this association table is that M to M relationships like Parts and Suppliers can be defined and used from either direction. This means either suppliers or parts could be on top. M to M relationships are applied as 1 to M relationships on top and the matching M to 1 on the bottom. This also allows for the addition of intersecting data to be stored in the association table that is different for each matching relationship. In this example this is the specific customer/employee associated data combination found in the intersecting data column pointed to by the red dashed arrow.

Advanced Structure Transformations in TestEven with all the relational discoveries and their advance new capabilities already shown, we are still pursuing and researching new advanced capabilities like those shown on this slide. These include dynamic structure transformations that allow dynamically and flexibly changing the data structure as needed. They use different and new relationships to restructure the data. This also includes our powerful new data structure reshaping capability. It uses the existing semantics to reshape the data structure in any way dynamically while preserving the semantics. Each of these restructuring methods has its own specific uses, and both methods can be used together.

New Semantic SQL is More Efficient Standard SQL produces a flat structure with no semantics produced by Cartesian processing keeping it inefficient. Efficiency is the ratio of power supplied to work performed. Increasing work performed without increasing power supplied increases efficiency. The new semantic SQL hierarchical processing significantly increases SQL processing naturally utilizing the Left Join generated semantics producing a higher performance. Besides this powerful semantics usage there are two other areas were semantics come into play increasing efficiency. These are fixed semantics in hierarchical structures and dynamic semantics where hierarchical structures are joined increasing semantics. All of these different semantics can build on each other to support a significantly higher performance multipath engine by increasing efficiency without increasing power supplied used to produce a leap in analytical and complex processing.

Relational Discoveries Proof of Concept All of the new ANSI SQL hierarchical processing capabilities shown have been supported in our functioning prototype shown below. This breakthrough multipath SQL natural hierarchical processor and technology has been implemented and tested. It is operating fully on an integration of relational algebra and hierarchical principles that have been mathematically and logically proven to exist and function together synergistically. This new SQL now includes many capabilities that were outside the current domain of SQL but are now within it because of the native relational hierarchical processing.

One final deeper explanation and proof of LCA operation shown in this presentation that demonstrates and proves how and why it works is my paper: The Power Behind SQL's Inherent Multipath LCA Hierarchical Processing at: http://www.databasejournal.com/features/article.php/3882741/article.htm See the SQL multipath hierarchical processor in action from actual processing output from an earlier version at: http://www.adatinc.com/images/Verifying_SQLfX_Current.pdf

My new book Advanced Standard SQL Dynamic Structured Data Modeling and Hierarchical Processing from Artech House Publishers describes many of the capabilities described in this presentation in more detail. This new book can be found at: http://www.artechhouse.com/Main/Books/Advanced-Standard-SQL-Dynamic-Structured-Data-Mode-2071.aspx

Any company having an interest or use for this powerful new breakthrough and disruptive semantic SQL query technology and product can contact Mike at: [email protected].

mailto:[email protected]

http://www.artechhouse.com/Main/Books/Advanced-Standard-SQL-Dynamic-Structured-Data-Mode-2071.aspx

http://www.artechhouse.com/Main/Books/Advanced-Standard-SQL-Dynamic-Structured-Data-Mode-2071.aspx

http://www.adatinc.com/images/Verifying_SQLfX_Current.pdf

SQL CHALLENGE I will send a copy of my new book: Advanced Standard SQL Dynamic Structured Data Modeling and Hierarchical Processing from Artech House Publishers to the first two people that find an uncorrectable error in the new SQL processing logic (syntax, semantics, operation) I am presenting here. Describe the SQL error found or question you have and specify your email. See this new book at: http://www.artechhouse.com/Main/Books/Advanced-Standard-SQL-Dynamic-Structured-Data-Mode-2071.aspx

new relational discoveries produce a powerful semantic sql

Data & Analytics