ADF DVT: Using the Tree Map visualization component – to compare relative sizes and distributions
The tree map component is one of those data visualization components that can tell an entire story through a simple picture. But of course that picture is anything but simple. And it is not even just a picture: it supports various forms of interaction such as drill down and popup. I had seen the Tree Map for the first time in demonstrations by Oracle Product Management. It seemed okay, but nothing very spectacular. Now, after having tried out the component for myself as well as studying the documentation, I may have to revise my initial opinion: it is actually a pretty cool and powerful component.
The Tree Map is used to present data values in a way that makes comparison easy, using two dimensions: (relative) size and color. The TreeMap uses containers for nodes with sizes relative to the numerical value associated with the nodes. Each node can have details and the container is presented with enclosed areas for each of the details. The size of these areas is proportional again to the value associated with the child node. All areas can be colored automatically – to create a pretty picture – or can be colored according to rules we can specify in order to have the colors also convey some meaning.
The Tree Map supports drilling down as well as other interactions including popups, context menus and more.
In this article, I will demonstrate the simplest, frankly most boring and probably easiest tree map I can create: one that demonstrates the relative salaries in the well known departments in table EMP. A data bound tree map uses one or more ViewObject usages. When multiple usages are bound in the treemap, then these usages need to be nested.
The Model project in my example is a plain old ADF BC project that uses a JDBC connection to the SCOTT schema. It contains two read only ViewObjects that have been linked using a ViewLink. The first ViewObject returns the identifier, name and average salary of the departments:
The second ViewObject just returns names and salaries of the employees along with their deptno:
The ViewLink that links these ViewObjects is based on the join on deptno.
The Data Model in the Application Module is defined as follows:
The Data Control has the same structure of course:
With this Data Control available, it is dead easy to create the Tree Map that will provide all this insight in the relative salaries in our departments.
Create JSF page SalaryComparison.jspx.
Drag the DepartmentMasters1 collection from the Data Control palette to the new page. Drop it as Tree Map:
The Treemap editor appears, with the collection preselected:
Select the value: the attribute that determines the relative size of the top level containers in the treemap; this is the average salary in the department. The Label is the header shown for the top level containers; it is set to the name of the department.
Next, select the detail collection DepartmentDetails – to configure the second level of containers or areas. This level represents the individual employees and their salaries through squares within the department level container. Select the salary as the attribute providing the value to determine the area size and set the label to ename. Then define a grouping rule to specify that the employee level areas should be colored based Ename which amounts to coloring at random.
Press OK to complete the treemap and run the page.
The treemap appears, and provides us with useful information:
Department ACCOUNTING has by far the highest average salary. Within that Department,it is clear that KING has the by far highest salary. Department OPERATIONS seems very well balanced: all four salaries seem about equal.
After KING, who seems to have the highest overall salary, BLAKE seems a clear runner-up with CLARK the number three in the ranking. A simple SQL query helps to analyze that finding and correct my misinterpretation of the treemap.
So be warned: the sizes of the Department level containers are relative to each other, based on the average salary within the department. The sizes of the employee areas should only be compared to sizes of other employee areas within the same container. Scotty and Jones make more than ADAMS and more still than SMITH. Comparing SCOTTY to Martin or Clark is quite hard.
Edit 04-04-2013: If I use the total sum of all salaries in the department as the value driving the size of the master-regions, the tree map comes out like this:
Now we can use the absolute size of the employee areas to compare their salaries.
In this rendition of the treemap, I have used the job of the employee to determine the color of the area. This means that all employee areas with the same color indicate someone in the same job. Clark and Blake for example must be in the same job (i.e. MANAGER).
- Suggestion for new type of ADF DVT (Data Visualization): the Delta Graph – to visualize relative changes integrated in a table layout
- Creating Multi-Type Node Children and Child Node labels in ADF Faces Tree Component
- Expand tree node all the way down in the ADF Faces Tree Component
- Nice little feature in ADF 11g: 'target data source' attribute on tree binding helps synchronize page with tree node selection
- Live resource bundle entry editing in a generic way through declarative component and UI component tree manipulation
- Exploring Data Visualization with an HTML 5 Canvas based Tag Cloud powered by JSON
- Oracle ADF Virtual Developer Day 2013
- The AMIS Summary of Oracle OpenWorld 2013 is available for download – 60-page white paper
- OOW13: summarizing one week and 2000 sessions in 3 hours and a bit – the yearly AMIS OOW Review session – 10th October
- Case Study: A Case of Fusion Middleware
- Het Oracle OpenWorld Preview Evenement (5 september 2013) – 15 sprekers & sessies
- ADF 12c: Using WebSockets to implement client to client push (in a scalable manner)
- ADF 12c – The Hierarchical Mystery Tour – Treemap, Sunburst, Treetable, Hierarchy Viewer and Thematic Map
- ADF DVT: Sunburst to quickly inspect the hierarchical composition
- JDeveloper 12c & ADF 12c: Launch of the next generation