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.
Model
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:
ViewController project
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).
