LOCATION CORRELATION BETWEEN QUERY SCRIPT AND DATA FLOW

A computerized mechanism to automatically correlate positions of query script to portions of a data flow representation of the query script. When parsing the query script to generate the tokens, at least some of the tokens have an associated script location marker that identifies a location in the query script where the token originated from. The syntax tree of multiple nodes is then formulated, each node comprising one or more of the tokens parsed from the query script. Accordingly, the syntax tree retains the script location markers. A data flow representation of the query script is then formulated into a data flow representation. That data flow representation might, for instance, be based on the syntax tree, but augmented with data types of the various data flows. Nevertheless, the location marker is retained within the data flow representation.

BACKGROUND

Computing systems and associated networks have revolutionized the way human beings work, play, and communicate. Nearly every aspect of our lives is affected in some way by computing systems. More recently cloud computing has enabled users to offload much of the processing, storage, network I/O, memory, and other resource usage to various datacenters. This offloading of hardware capability is often referred to as Infrastructure As A Service (IAAS). Datacenters can also provide Platforms As A Service (PAAS), and even Software As a Service (SAAS). Since the users themselves typically do not have to be concerned about which datacenter or computing system are providing such hardware and software, the user is now able to be less concerned about the location of the hardware that is supporting the service, or how the services are being accessed. To the user, it is as though the user is simply reaching up into the nearest cloud or portion of the sky to obtain the desired computing service. The service seems ever present.

With data now often being moved into the cloud, the ability to store large quantities of data has improved greatly, enabling a technology field often referred to simply as “Big Data”. For instance, big data queries may be processed against very large quantities of data, and those queries are efficiently processed in the cloud computing environment, allowing rapid return of results. Big data queries, like normal database queries, are typically declarative in form and are often referred to as “query script” or “script”. There currently exist a variety of languages in which big data queries may be authored. When queries are processed, they are first parsed into tokens, and then the grammar set appropriate for the script language is then used to construct a syntax tree (also sometimes referred to as an “Abstract Syntax Tree” or AST).

BRIEF SUMMARY

At least one embodiment described herein relates to a computerized mechanism to correlate positions of query script to portions of a data flow representation of the query script. Visualizations of such correlation would allow an author or reviewer of the query script to be able to quickly see what portions of the query script are going to cause what data flows. This gives the viewer and intuitive view on the operation of the query script.

When parsing the query script to generate the tokens, at least some of the tokens have an associated script location marker that identifies a location in the query script where the token originated from. For instance, the script location marker might be a line identifier of the query script. The syntax tree of multiple nodes is then formulated, each node comprising one or more of the tokens parsed from the query script. Accordingly, the syntax tree retains the script location markers. A data flow representation of the query script is then formulated into a data flow representation. That data flow representation might, for instance, be based on the syntax tree, but augmented with data types of the various data flows. Nevertheless, the script location marker is retained within the data flow representation.

Accordingly, when the data flow representation is visualized, each visualized node can be shown with its corresponding script portion emphasized. For instance, the data flow representation might be visualized on one half of a display, and the query script shown on the other half of the display. When a portion of the query script is selected, the corresponding portion of the visualized data flow portion may likewise be emphasized to show this correlation. Likewise, when a portion of the data flow representation is selected, the corresponding portion of the query script may be emphasized to show the correlation. This allows for more intuitive drafting and review of query script through computerized correlation of locations with the query script.

This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

DETAILED DESCRIPTION

At least one embodiment described herein relates to a computerized mechanism to correlate positions of query script to portions of a data flow representation of the query script. Visualizations of such correlation would allow an author or reviewer of the query script to be able to quickly see what portions of the query script are going to cause what data flows. This gives the viewer and intuitive view on the operation of the query script.

When parsing the query script to generate the tokens, at least some of the tokens have an associated script location marker that identifies a location in the query script where the token originated from. For instance, the script location marker might be a line identifier of the query script. The syntax tree of multiple nodes is then formulated, each node comprising one or more of the tokens parsed from the query script. Accordingly, the syntax tree retains the script location markers. A data flow representation of the query script is then formulated into a data flow representation. That data flow representation might, for instance, be based on the syntax tree, but augmented with data types of the various data flows. Nevertheless, the script location marker is retained within the data flow representation.

Accordingly, when the data flow representation is visualized, each visualized node can be shown with its corresponding script portion emphasized. For instance, the data flow representation might be visualized on one half of a display, and the query script shown on the other half of the display. When a portion of the query script is selected, the corresponding portion of the visualized data flow portion may likewise be emphasized to show this correlation. Likewise, when a portion of the data flow representation is selected, the corresponding portion of the query script may be emphasized to show the correlation. This allows for more intuitive drafting and review of query script through computerized correlation of locations with the query script.

Some introductory discussion of a computing system will be described with respect toFIG. 1. Then, the general structure and operation of a mechanism to correlate positions of query script to portions of a data flow representation of the query script will be described with respect toFIGS. 2 through 7. Finally, a specific example user experience will be described with respect to the user interfaces illustrated inFIGS. 8 through 18.

Computing systems are now increasingly taking a wide variety of forms. Computing systems may, for example, be handheld devices, appliances, laptop computers, desktop computers, mainframes, distributed computing systems, datacenters, or even devices that have not conventionally been considered a computing system, such as wearables (e.g., glasses). In this description and in the claims, the term “computing system” is defined broadly as including any device or system (or combination thereof) that includes at least one physical and tangible processor, and a physical and tangible memory capable of having thereon computer-executable instructions that may be executed by a processor. The memory may take any form and may depend on the nature and form of the computing system. A computing system may be distributed over a network environment and may include multiple constituent computing systems.

As illustrated inFIG. 1, in its most basic configuration, a computing system100typically includes at least one hardware processing unit102and memory104. The memory104may be physical system memory, which may be volatile, non-volatile, or some combination of the two. The term “memory” may also be used herein to refer to non-volatile mass storage such as physical storage media. If the computing system is distributed, the processing, memory and/or storage capability may be distributed as well.

The computing system100also has thereon multiple structures often referred to as an “executable component”. For instance, the memory104of the computing system100is illustrated as including executable component106. The term “executable component” is the name for a structure that is well understood to one of ordinary skill in the art in the field of computing as being a structure that can be software, hardware, or a combination thereof. For instance, when implemented in software, one of ordinary skill in the art would understand that the structure of an executable component may include software objects, routines, methods that may be executed on the computing system, whether such an executable component exists in the heap of a computing system, or whether the executable component exists on computer-readable storage media.

The term “executable component” is also well understood by one of ordinary skill as including structures that are implemented exclusively or near-exclusively in hardware, such as within a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or any other specialized circuit. Accordingly, the term “executable component” is a term for a structure that is well understood by those of ordinary skill in the art of computing, whether implemented in software, hardware, or a combination. In this description, the terms “component”, “service”, “engine”, “module”, “evaluator”, “monitor”, “scheduler”, “manager”, “module”, “compiler”, “virtual machine”, “container”, “environment” or the like may also be used. As used in this description and in the case, these terms (whether expressed with or without a modifying clause) are also intended to be synonymous with the term “executable component”, and thus also have a structure that is well understood by those of ordinary skill in the art of computing.

In the description that follows, embodiments are described with reference to acts that are performed by one or more computing systems. If such acts are implemented in software, one or more processors (of the associated computing system that performs the act) direct the operation of the computing system in response to having executed computer-executable instructions that constitute an executable component. For example, such computer-executable instructions may be embodied on one or more computer-readable media that form a computer program product. An example of such an operation involves the manipulation of data.

The computer-executable instructions (and the manipulated data) may be stored in the memory104of the computing system100. Computing system100may also contain communication channels108that allow the computing system100to communicate with other computing systems over, for example, network110.

While not all computing systems require a user interface, in some embodiments, the computing system100includes a user interface112for use in interfacing with a user. The user interface112may include output mechanisms112A as well as input mechanisms112B. The principles described herein are not limited to the precise output mechanisms112A or input mechanisms112B as such will depend on the nature of the device. However, output mechanisms112A might include, for instance, speakers, displays, projectors, tactile output, valves, actuators, holograms, virtual reality environments, and so forth. Examples of input mechanisms112B might include, for instance, microphones, touchscreens, holograms, cameras, keyboards, accelerometers, levers, pedals, buttons, knobs, mouse of other pointer input, sensors of any type, a virtual reality environment, and so forth.

For instance, cloud computing is currently employed in the marketplace so as to offer ubiquitous and convenient on-demand access to the shared pool of configurable computing resources. Furthermore, the shared pool of configurable computing resources can be rapidly provisioned via virtualization and released with low management effort or service provider interaction, and then scaled accordingly.

FIG. 2illustrates a flow200representing a process for correlating query script to portions of a data flow representation of that query script in accordance with the principles described herein. The flow200begins with the accessing of a query script210. The query script210is drafted in accordance with a query language. In some embodiments, the query language is a big data query language. Examples of big data query languages include Hive query language, Spark SQL, BigQuery, although there are numerous other examples of big data query languages. The principles described herein are not limited to any particular big data query language, and are not limited to big data query languages at all. The query script may be visualized (as represented by arrow201A) into a visual representation201B that is output on a display250. For instance, if the process occurs on the computing system100ofFIG. 1, the query script may be visualized on a display represented as one of the output mechanisms102A.

The script query is first parsed (as represented by arrow211) into multiple tokens220. This may be performed by, for instance, the parser of a compiler. In this particular example, the tokens220are shown as including three tokens222A,222B and222C. However, the ellipses222D symbolically represent that the principles described herein is not limited to the number of tokens that query script is parsed into. A typical segment of query script will often have many more than three tokens.

One, some, or all of the tokens may have a corresponding script location marker that identifies what portion of the query script the token is located in or originated from. In this example, all of the tokens222A,222B and222C have a corresponding script location marker223A,223B and223C. For instance, the script location marker might be a line identifier for one or more lines, perhaps in conjunction with a horizontal offset position or range for each line. Accordingly, there is enough information within the script location marker to highlight or otherwise visually emphasize the token itself within with query script.

The collection of tokens220is then formulated (as represented by arrow221) into a syntax tree230comprising multiple nodes, each including one or more tokens. The formulation of tokens into syntax trees are known in the art and thus will not be described in detail herein. However, unlike conventional formulation of syntax trees, some or all of those script location markers remain associated with the tokens when the tokens are included within nodes of the syntax tree. This continued inclusion of the script location markers is represented by the syntax tree230including asterisk232.

The syntax tree230is then evaluated by an evaluator235to thereby generate (as represented by arrow231) a data flow representation240of the syntax tree230. The data flow representation240also continues to include the script location markers for the tokens as represented by the data flow representation240having asterisk241. For instance, the data flow representation240is illustrated inFIG. 2as having the script location markers223A,223B and223C that are associated with the respective tokens222A,222B and222C. Accordingly, the script location markers223A,223B and223C are in the data flow representation240and remain associated with the original tokens222A,222B,222C. This allows positions and/or portions within the data flow representation to be correlated with positions in the query script using the appropriate script location marker.

As represented by arrow202A, a visualization202B of the data flow representation may be presented on the display250. For instance, if the process occurs on the computing system100ofFIG. 1, the data flow visualization202B may be visualized on a display represented as one of the output mechanisms112A.

The visualization202B of the data flow representation is illustrated inFIG. 2as including controls241A,241B and241C that are visually associated with visualizations243A,243B and243C of the respective tokens222A,222B and222C within the visualization201B. Each of the controls241A,241B and241C also has a reference (as represented by corresponding arrows242A,242B and242C) to the respective script location markers223A,223B and223C of the respective tokens222A,222B and222C.

Using this script location marker, when a control is selected in the visualization of the data flow, the appropriate portion (e.g., a token) of the visualization201B of the query script is highlighted. For instance, upon selecting control241A, a visualization243A of the token222A within the visualization201B of the query script210may be visually emphasized as represented by arrow244A. Upon selecting control241B, a visualization243B of the token222B within the visualization201B of the query script210may be visually emphasized as represented by arrow244B. Upon selecting control241C, a visualization243C of the token222C within the visualization201B of the query script210may be visually emphasized as represented by arrow244C.

In addition to representing tokens, the boxes243A,243B and243C within the visualization201B of the query script210may also themselves represent controls visually associated with the tokens. Furthermore, in addition to representing controls, the boxes241A,241B and241C within the visualization202B of the data flow representation240may also themselves represent visualized portions of the data flow representation that corresponding to the respective tokens222A,222B and222C. For instance, upon selecting control243A, a visualization241A of the node222A within the visualization202B of the data flow representation240may be visually emphasized as represented by arrow245A. Upon selecting control243B, a visualization241B of the token222B within the visualization202B of the data flow representation240may be visually emphasized as represented by arrow245B. Upon selecting control243C, a visualization241C of the token222C within the visualization202B of the data flow representation240may be visually emphasized as represented by arrow245C.

The visualization202B of the data flow representation240may also include other controls251A and251B that allow for other types of operations on the visualization202. For instance, as an example only, control251A might filter a view of the visualization to perhaps only a subset of the nodes of the data flow representation, or may perhaps aggregated nodes of the data flow representation. Control252might, for instance, visually emphasize visualized nodes having a particular relationship with a selected visualized node. For instance, the visually emphasized nodes might be the upstream and/or downstream nodes of a selected node of the data flow representation.

FIG. 3Arepresents an example of a syntax tree300A and will be used as an example throughout the remainder of this description. However, the principles described herein apply regardless of the particular structure of the syntax tree300and the precise structure of the syntax tree300will depend on the content of the query script and the query language in which the query script is authored. In this particular syntax tree300, there are five nodes shown including nodes310A,320A,330A,340A and350A. Each node of the syntax tree300A is symbolically illustrated inFIG. 3Aas a circle. Furthermore, there are five relation311A,321A,331A,341A and351A. Each relation of the syntax tree is symbolically illustrated inFIG. 3Aas a dotted line.

FIG. 3Brepresents an example of a data flow representation300B, and is similar to the syntax tree300A ofFIG. 3A. In the illustration ofFIG. 3B, each node of the data flow representation300B is represented as a square, and each flow is represented as an arrow line. In this example, there is one node of the data flow representation300B corresponding to each node of the syntax tree300A. For instance, nodes310A,320A,330A,340A and350A of the syntax tree300A correspond to respective nodes310B,320B,330B,340B and350B of the data flow representation300B. Furthermore, there is one data flow311B,321B,331B,341B and351B for each corresponding link311A,321A,331A,341A and351A of the syntax tree300A.

However, data flows often do not have one to one representations between links in the syntax diagram and data flows, and often there may be one or more nodes of a syntax tree in a single node of a data flow. Accordingly, the similarity in appearance between the syntax tree300A ofFIG. 3Aand the data flow representation300B ofFIG. 3Bis merely for purpose of clarity in explaining the principles described herein.

FIG. 4illustrates a flowchart of a method400for correlating positions of query script to portions of a data flow representation of the query script. The method400might be performed just once with respect to a query script that is not anticipated to change. However, the method400might also be performed whenever a query script changes. Accordingly, the author of a query script might always be able to tell the correlation between the query script they are drafting and a data flow representation, and also be able to understand what portion of the query script corresponds to what portion of the data flow representation, and vice versa. The method400may be performed by, for instance, the computing system100ofFIG. 1.

The method400includes accessing a query script (act401). For instance, inFIG. 2, the query script210is accessed. Again, this accessing might occur often, even perhaps whenever the query script changes in a small way. The query script is also visualized (act410). For instance, if the method400is performed by the computing system100, the query script might be displayed on a display, which is an example of the output mechanisms112A. In addition, a syntax tree is formulated in a manner that retains the script location marker of the tokens within the syntax tree (act420). Furthermore, the data flow representation is created from the syntax tree in a manner that retains the script location marker of the tokens within the data flow representation (act421). Accordingly, positions in the data flow representation are correlated with positions in the query script (act422) using the script location marker for at least some of the tokens included within the nodes in the syntax tree. Furthermore, the data flow representation is visualized (act423). For instance, if the method400is performed by the computing system100, the data flow representation might be displayed on a display, perhaps next to the visualization of the query script.

FIG. 5illustrates a flowchart of an example method500for formulating the syntax tree and represents an example of the act420ofFIG. 4. The method500includes parsing the query script to generate multiple tokens (act510), each of at least some of the tokens having an associated script location marker that identifies a location in the query script from where the token originated. For instance, inFigure 2, the query script210is parsed as represented by arrow211into tokens220having script location markers223A,223B and223C. This may be performed by, for instance, a parser of a compiler, the parser being slightly modified so that when a token is parsed out of the query script, a script location marker is created that identifies the query script location that the token came from, and then the script location marker is associated with the token such that when the token moves or is copied, the script location marker remains associated with the corresponding token.

Next, a syntax tree is formulated having multiple nodes (act520). As previously mentioned, each node of the syntax tree has one or more tokens parsed from the query script. The syntax tree retains the script location markers associated with the tokens, because the syntax tree includes the tokens and the script location markers follow the respective tokens. An example of a syntax tree is an Abstract Syntax Tree (AST).

FIG. 6illustrates a flowchart of an example method600for formulating a data flow representation from a syntax tree and represents an example of the act421ofFIG. 4. The method600may be performed by the evaluator235ofFIG. 2for example, to build the data flow representation240from the syntax tree230. The method600includes first accessing (act610) the syntax tree. For instance, inFIG. 2, the evaluator235access the syntax tree230. Again, an example of the syntax tree230is the syntax tree300A ofFIG. 3A.

The evaluator then evaluates (act620) each of at least some of the nodes of the syntax tree to identify the various data types of the node. For instance, the evaluator635ofFIG. 2evaluates each node of the syntax tree in order to identify the data types of input(s) and output(s) of the node. If the syntax tree230were structured as the syntax tree300A ofFIG. 3A, the evaluator would perform the act620for each of the nodes310A,320A,330A,340A and350A of the syntax tree.FIG. 7illustrates a flowchart of a method700for evaluating a node of the syntax tree and represents one example of how the act620may be performed.FIG. 7will be explained in detail further below.

The evaluator then formulates (act630) a data flow representation based on the syntax tree and augmented with the data types identified in the acts of evaluating. For instance, inFIG. 2, the evaluator235formulates the data flow representation240.

As previously mentioned, in order to generate the data flow representation, the evaluator evaluates (act620) each of at least some of the nodes of the syntax tree.FIG. 7illustrates a flowchart of a method700for evaluating a node of the syntax tree. The goal of the evaluation of each node is to identify a data type of any output(s) from that node.

First, the evaluator identifies (act710) a data type of one or more inputs to the node of the syntax tree. It may be that there are no inputs to the node of the syntax tree. In that case, act710may be skipped. Furthermore, it may be that due to upstream nodes not having been evaluated yet, the data type of one of the input(s) to the node may not yet be identifiable. In that case, the method700is deferred for that particular node of the syntax tree.

Accordingly, the evaluation of nodes is subject to evaluation of an order of dependency of the nodes of the syntax tree. For instance, referring toFIG. 3A, node310A is evaluated so that the data types of the inputs311B to the node320A may be identified. Furthermore, node320A is evaluated prior to nodes330A and340A so that the inputs321B and331B to the respective nodes330A and340A may be identified. Nodes230A and240A are then evaluated so that inputs341B and351B to the node350A may be identified.

Once the input data type of the input(s) (if any) are determined for a given node of the syntax tree, the grammar set of the query script may then be applied to the one or more tokens of the node (act720) to thereby identify (act730) output data types of output(s), if any, of the node of the syntax tree.

The method700ofFIG. 7will now be described with respect to the syntax tree300A ofFIG. 3A. In order to generate the data flow representation300B ofFIG. 3B, the data types of each of the input(s), if any, and the output(s), if any, of the nodes of the syntax tree300A are determined. To do so, the method700is applied to each node of the syntax tree300A beginning at node310A, which is a dependee node for all other nodes of the syntax tree300A.

As for node310A, the data types of the input(s) of the node310A are identified (act710). In the case of node310A, there are no inputs to the node310A. The grammar rules of the query language are then applied (act720) to the token(s) of the node in order to identify (act730) an output data type311B of the node310A. By so doing, node310B having output data flows311B may be formulated (seeFIG. 3B). Node320A is then ready to be evaluated, being a dependent node from node310A, and given that the output data type of the output of its dependee node310A has been determined.

Again, the method700is performed, this time for node320A. As for node320A, the input(s) of the node320A are identified (act710). The input data type of the input of the node320A in this case is the same as the output type of the output311B of the node310B. Accordingly, the input data type can be readily identified. Now, the grammar rules of the query language are applied (act720) to the token(s) of the node320A in order to identify (act730) an output data type321B and331B of the node320A. By so doing, node320B having output data flows321B and331B may be formulated (seeFIG. 3B). Either and both of nodes330A and340are then ready to be evaluated.

When the method700is performed for node330A, the input(s) of the node330A are identified (act710). The input data type of the input of the node330A in this case is the same as the output data type of the output321B of the node320B. Accordingly, the input data type can be readily identified. Now, the grammar rules of the query language are applied (act720) to the token(s) of the node330A in order to identify (act730) an output data type341B of the node330A. By so doing, node330B having output data flow341B may be formulated (seeFIG. 3B).

When the method700is performed for node340A, the input(s) of the node340A are identified (act710). The input data type of the input of the node340A in this case is the same as the output data type of the output331B of the node320B. Accordingly, the input data type can be readily identified. Now, the grammar rules of the query language are applied (act720) to the token(s) of the node340A in order to identify (act730) an output data type351B of the node340A. By so doing, node340B having output data flow341B may be formulated.

The method700may now be performed for node350A. The input types of inputs to the node350A are identified (act710). The input data types of the inputs of the node350A in this case is the same as the output data type of the output341B of the node330B, and the same as the output data type of the output351B of the node340B. There is no need to perform act720and730with respect to node350A since there are no output data flows from the node350A. Accordingly, node350B of the data flow representation300B may be formulated, thereby completing the formulation of the data flow representation300B ofFIG. 3B.

A user experience will now be described with respect to several user interfaces with respect toFIGS. 8 through 18. Each of theFIGS. 8 through 18represents a user interface that may be displayed on a display (e.g., one of the output mechanism112A) of the computing system (e.g., computing system100).

FIG. 8illustrates a user interface in which only the query script is illustrated. Accordingly, the user interface ofFIG. 8represents an example of the visualization201B ofFIG. 2. To switch over to the visualization of the data flow representation, the user might select the “Diagram tab” represented within circle810.FIG. 9illustrates the resulting user interface in this example user experience. Accordingly,FIG. 9represents an example of the visualization202B ofFIG. 2.

Alternatively, in eitherFIG. 8(the query script view) orFIG. 9(the data flow representation view), the user might select the split control820to view the query script and the associated data flow representation side by side.FIG. 10illustrates the resulting user interface showing the script view1010and the data flow representation view1020.

Selecting something in the data flow representation view1020will visually emphasize the relevant script. For instance,FIG. 11is similar toFIG. 10, except that the user has selected the node circled by circle1110. This results in the corresponding token being visually emphasized as represented by circle1120. ThroughoutFIGS. 11 through 18, the selected node in the data flow representation view is represented by the node having rightward leaning hash marking. Otherwise emphasized nodes are represented by the node having dotted fill.

Conversely, selecting (e.g., putting the cursor over) somewhere in the script view will select the corresponding node in the data flow representation view. For instance,FIG. 12is similar toFIG. 10, except that the user has put the cursor at the location represented by circle1210in the script view, causing the corresponding node1220of the data flow representation view to be visually emphasized.

Note that in the views ofFIGS. 11 and 12, where a node of the data flow representation has been selected (either directly as inFIG. 11, or view placing the cursor in the corresponding script portion as inFIG. 12), the upstream and downstream nodes may be visually emphasized. This may be illustrated more clearly inFIG. 13, in which node1310is selected. That causes the corresponding upstream nodes1307,1308and1309, and the corresponding downstream nodes1311and1312to be visually emphasized also.

The user might also choose to show only the related nodes of a given node by interacting with a control associated with that node. For instance, inFIG. 14, the user might open a drop down menu1410and select the “Only related nodes” option1420resulting in the user interface ofFIG. 15. InFIG. 15, only the selected node1310, and its related nodes1307,1308,1309,1311and1312are shown.

As illustrated in the user interface ofFIG. 16, there may be options for showing and hiding properties of the statement within the diagram (as represented within the circle1610). The user can choose how much of the properties, and which properties, to display. In this case, the user has selected to see the schema, the condition, the filter, and the sort properties of the nodes.

Furthermore, whileFIGS. 9 through 16show that the nodes of the data flow representation view represent operations (e.g., statements), and the edges represent data flows (e.g., rowsets), the user can switch this so that the nodes represent data flows and the edges represent operations. For instance, inFIG. 17, the user may interact with a control, such as in the form of a drop down control1710and select the “Rowsets” option1720.FIG. 18represents the resulting user interface with rowsets represented by nodes, and statements represented by edges.

Accordingly, an effective and automated mechanism for correlating query script positions with data flow representation positions has been described, along with various other convenient user experiences. This allows for more efficient drafting of correct and intended query script, and for the efficient evaluation of the same.