Coordinations and Joins

An important advancement in this model is the generalization of coordinations and interactions [NCI02]. A coordination is generalized to any single or compound join association, including one-to-one, one-to-many, and many-to-many associations. Join associations for coordinations are automatically derived and executed from data schemas, eliminating the need for user-defined parameterized queries for joins. Furthermore, interactions are generalized to tuple subset selections, enabling them to act on single or multiple tuples. Chained coordinations cascade across arbitrary associations, beyond the previously limited one-to-one cascading.

Four cases demonstrate how generalized coordinations correspond to various joins in the data schema. These are demonstrated using the example data schema and multiple-view

visualization for website hits shown in Figure 23 and Figure 24.

Figure 23 – An example data schema for a database of hits to our website. “URLs” stores information about pages on our website. “Referrers” stores information about external websites that have links to out website.

“Hits” stores information about each hit, including a reference to the page requested in “URLs” and the external referring site in “Referrers”.

Figure 24 – An example multiple-view visualization constructed with Snap for the database shown in Figure 23. The website map generated from the URLs is shown in the TreeView (top left). Selecting a page in the map displays the page in the web browser (top right), and displays the distribution of hits to that page in the

scatter plot (top center). Selecting pages also highlights referring sites listed in the table view (bottom left). Likewise, selecting referring sites highlights pages linked to, and shows their hits in the plot. Clicking a

referrer shows its page in the other web browser (bottom right).

• Self join: A coordination can be established between two visualization components that

display the same relation. In this case, the coordination corresponds to the implicit one-to- one join association that exists between the relation and itself.

For example, the TreeView visualization component displays the URLs relation, using the URL page pathname attribute to display the tuples as a website tree structure. A web

browser component also displays the URLs relation, using the URL attribute to display actual pages represented by the tuples. The “select” action of the TreeView is coordinated to the “navigate” action of the web browser across the self join. When users select a tuple in the

is used to navigate the web browser to the selected page.

TreeView ← URLs → Web browser

• Single join: A coordination can be established between two components whose relations

have a direct join association in the data schema. The relational model provides two primitive types of direct join associations: one-to-one and one-to-many.

For example, in addition to the TreeView of the URLs relation, the scatter plot displays the Hits relation, showing all hits to the website by date and time. The “select” action of the TreeView is coordinated to the “load” action of the plot, using the direct join association between the URLs and Hits relations. The data schema indicates this is a one-to-many association. Selecting tuples in the TreeView joins those tuples to the Hits relation to find all the hits to the selected pages. The resulting Hits subset is then loaded and displayed in the plot, essentially filtering out hits to any other pages. This enables users to drill down from pages to hits.

TreeView ← URLs ↔ Hits → Scatter plot

• Compound join: A coordination can be established between two components whose relations

have an indirect association via one or more intermediate relations in the data schema. This requires a compound join, concatenating each of the direct joins along the indirect

association path. Compound joins enable more complex associations such as many-to-many.

For example, in addition to the TreeView of the URLs relation, the TableView displays the Referrers relation, showing an alphabetical list of all the websites that link (refer) readers to

The “select” action of the TreeView is coordinated to the “select” action of the TableView, using the compound join from URLs to Hits to Referrers. The concatenation of the one-to- many and many-to-one joins creates a many-to-many join. Selecting tuples in the TreeView joins those tuples to the Hits relation and then to the Referrers relation to identify the

websites that actually sent readers to the selected pages, and then selects them in the

TableView. Since coordinations are bidirectional, the reverse interaction also occurs. This example illustrates brushing-and-linking across a many-to-many association.

TreeView ← URLs ↔ Hits ↔ Referrers → TableView

• Multiple alternative joins: A coordination between two components whose relations have

multiple alternative join associations connecting them requires the selection of one of the join associations for use in the coordination. In the compound join example above, an alternative is the compound join through the Links relation. This alternative would have a different effect. Selecting pages in the TreeView would indicate all the websites in the TableView that have links to those pages, rather than the websites that actually referred readers and generated hits.

TreeView ← URLs ↔ Hits ↔ Referrers → TableView TreeView ← URLs ↔ Links ↔ Referrers → TableView