See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/264791578

Custom Visualization Charts for Cancer Research in SAP Lumira

Article · April 2014

CITATIONS READS
0 1,076

1 author:

Gerardo Navarro S
Hasso Plattner Institute
1 PUBLICATION   0 CITATIONS   

SEE PROFILE

All content following this page was uploaded by Gerardo Navarro S on 18 August 2014.

The user has requested enhancement of the downloaded file.

Custom Visualization Charts for Cancer Research in
SAP Lumira
Gerardo Navarro Suarez
Hasso Plattner Institute
August–Bebel–Str. 88
14482 Potsdam, Germany
gerardo.navarro-suarez@student.hpi.uni-potsdam.de
Abstract—Cancer researchers investigate on the best treat-
ment for certain cancer types. After conducting xenograft ex-
periments and collecting additional information, they are faced
with a large amount of data. In order to identify patterns more
easily, they summarize the conducted data in visual charts. This
is a manual and tedious work with only minimal tool support. In
order to fill this gap, we leverage and tailor existing visualization
tools to meet the needs of cancer researchers. In this work, we
focus on the design, development and integration of custom chart
extensions into the SAP Lumira visualization tool. Thereby, we
achieve the goal of providing an interactive and exploratory way
for cancer researchers to discover insights within their data.
Keywords—SAP Lumira, Clustered Heat Map
I. I NTRODUCTION
In the last decade, faster sequencing and decoding of the
human genome opened up new areas in medical research as
it is now possible to dig deeper into certain diseases. Fur-
thermore, this additional data source revealed lots of potential
for personalized medicine, because it allows to treat patients
specifically based on their individual DNA or disposition [1].
Given this large amount of diagnostic data, it is clear that
researchers need technical help to exploit all information inside
the data – especially in the context of cancer research and
treatment. Some data analysis tasks are already supported by
applications using in-memory technology, e.g. alignment and
variant calling [1].
Besides that, we extend the existing capabilities to the area
of drug response analysis focused on cancer researchers. In
our project scenario, cancer researchers investigate on the best
treatment for certain cancer types looking into DNA level, such
as head and neck cancer. As part of their research, they collect
meta data and tumor samples from patients and conduct many
xenograft experiments which produce a large amount of data.
This data is edited, enhanced and analyzed in a manual
and tedious process by researchers taking from several days
up to weeks. As part of the Analyze Genomes Project (AGP),
we provide a cloud service that automates parts of this manual
work [1]. Scientists upload the conducted tumor-specific data
to the online service that processes the data and calculates
additional information [2]. To get a deeper understanding of
their data, researchers initiate data analyzing algorithms to find
relevant dependencies within the tumor data or to classify the
tumor data with machine learning approaches [3], [4].
Finally, researchers want to summarize the data in visual
charts, because a graphical representation of raw data is
easier to understand by people in general [5]. Additionally,
it allows them to identify patterns more easily inside their
data. Nowadays, the creation of such charts is a manual and
inefficient task, as there is little tool support. In addition, the
created charts are static visualizations, disallowing researchers
to interact and engage with their data freely. We see the
need to tackle this problem by exploiting existing visualization
tools. As a goal, we envision a tool providing interactive data
exploration capabilities to cancer researchers. Researchers can
engage with the data via the visualization and eventually gain
new insights.
Given there are many Business Intelligence (BI) tools that
focus on data visualization, it is not necessary to develop a
new solution from the ground up, but rather adjust existing BI
tools to our use case. This makes it also possible to deliver
the visualization tool to the researchers within the time frame
of the project. SAP Lumira is such a BI tool that allows
cancer researchers to access their data sources, transform the
data, and eventually visualize data graphically. As a result,
the rich set of visualization charts enables users with a basic
technical understanding to explore their data freely and quickly
discover valuable insights within these charts, without having
to write scripts and SQL queries. Unfortunately, Lumira’s
visualization chart portfolio misses some chart types that are
specifically used in the context of cancer research, such as a
normalized stacked bar chart. Fortunately, SAP Lumira allows
the definition and implementation of custom visualization
charts as so-called chart extensions.
The contribution presented in this paper focuses on the
design, development and integration of custom chart extensions
into SAP Lumira to achieve the goal of providing an interactive
and exploratory way for cancer researchers to discover insights
within their data, like a clustered heat map shown in Fig. 1.
The remainder of the paper is structured as follows: In
Sect. II, our work goes deeper into visualizations in the clinical
context as part of the related work. Section III present basic
background information to SAP Lumira. In Sect. IV, we go
deeper into the design of the new visualization charts and
explain the details of implementing custom chart extensions for
SAP Lumira. We evaluate and compare the developed charts
in Sect. V. Our work concludes with an outlook in Sect. VI.
II. R ELATED W ORK
Before starting to work on specific visualizations in SAP
Lumira, it is important understand what graphical representa-
Fig. 1. Clustered heat map that shows the #Mutation count for a subset of genes and tumor samples. This SAP Lumira chart extension uses hierarchical
clustering to sort and rearrange its cells. Through this, it is easier to understand the data and to detect insightful pattern, e.g. genes ATM and TP53 are relevant
across all samples.
tions are currently used for clinical data and what visualization
type would be helpful to cancer researchers. Stengel et al. and
Snyder emphasize that the main goal of any visualization is
to effectively communicate the information contained in the
data in a non-distorting manner [5], [6]. As a result of this,
the choice for a certain visualization depends on the specific
data set that researchers wish to present. However, both books
state that certain diagram types are more suited in the clinical
context and therefore used more frequently, e.g. column bar
charts, box plots and scatter plots.
Clinical research usually deals with a large amount of
cross-referenced data that finally needs to be visualized in a
comprehensive way and to point out the main findings within
the large data set. For this situation, heat maps proved to be
the most effective way of displaying high-dimensional array
data, particularly suitable for gene expression array data [7].
Especially in our scenario with cancer researcher, the heat map
visualization is often used by cancer researchers, in order to
explore certain aspects across all their conducted tumor data,
such as researchers investigating the effectiveness of drugs
across a large set of tumors. The full potential of heat maps
is revealed when the data is sorted or clustered. A sorted or
clustered heat map ensures that similar data points are arranged
close together, e.g. similar genes are located close to each
other which makes it easier to identify patterns across the large
data set. The sorting is often achieved by applying hierarchical
clustering methods separately on rows and columns of the heat
map [8]. It is a more generic clustering approach that does not
require specific knowledge about the data. Additionally, there
are partitional clustering methods that map the data points to
a known number of clusters, like K-means clustering. This
is achieved by repeatedly assigning all samples to one of K
clusters based on which cluster centroid is closest [9].
Examples for the usage of (clustered) heat maps, bar charts,
box plots and combinations of different other visualizations in
the clinical context can be found in various papers [6] [8].
Most papers also include unique and custom charts tailored to
their respective data set because these unique charts emphasize
certain aspects of the data in a better way than standard
visualization chart types. These unique charts are not supported
by SAP Lumira. Hence, it is important to identify and prioritize
the visualizations that are not supported.
III. SAP L UMIRA OVERVIEW
SAP Lumira is a new self-service BI solution from SAP.
The solution allows analysts, decision makers, and now cancer
researchers to access one or multiple data sources, transform
the data and eventually visualize data graphically. As a result,
the rich set of visualizations enables users with a basic
technical understanding to engage with their data and quickly
discover valuable insights, without having to write scripts and
SQL queries [10].
A. Integrating into SAP Lumira
SAP Lumira as a visualization tool is a good starting point
for our scenario because of its rich feature set and easy-to-
use interface for non-technical persons. The researchers would
have three possibilities to interact with SAP Lumira:
1) SAP Lumira Desktop is a desktop program installed on
Windows machines and enable users to prepare data from
multiple sources, compose visualizations and share the
defined visualizations with other contributors.
2) SAP Lumira Cloud is an online platform providing a similar
feature set as the Lumira Desktop, but makes it available
for mobile devices and browsers.
3) SAP Lumira Server is a UI5 HANA-based XS application
that will run on-premise with similar mobile web access and
user experience to Lumira Cloud, but specifically targeted
to integrate well with the deployed SAP HANA repository
[11], [12].
Amongst the three presented solutions, SAP Lumira Desk-
top allowed faster development and deployment of custom
charts, because of the following reasons:
• Lumira Desktop includes a software development kit
(SDK) that provides stable API interfaces and utilities,
streamlines the development steps, and makes it easier
to implement custom visualizations as compact bundles
[13].
• During our project, SAP Lumira Server was still in devel-
opment and therefore only available as a developer release
with no SDK or extension mechanism in-place, unstable
interfaces and no detailed documentation. Furthermore,
working with the developer release of Lumira Server
involved a large amount of reverse engineering and trial-
and-error debugging that lead to laborious and inefficient
development with lots of effort.
• Developing custom visualization charts with Lumira SDK
makes it easier to port and deploy the custom charts
to Lumira Server once a similar extension mechanism
is established. An extension mechanism for visualization
charts is planned to be included in post Q2 releases of
Lumira Server.
B. Building custom visualizations in SAP Lumira
SAP Lumira offers a variety of visualizations out of the
box that can definitely be of use in clinical publications [10].
However, as it is impossible for Lumira to cover all possible
visualization chart types. Therefore, the development team
of Lumira Desktop introduced an SDK, which provides an
extension framework with an associated API that lets you
develop your own chart, and integrate it with SAP Lumira
[13]. The SDK includes the so called VizPacker utility, a web
client that helps to create the directory structure and the bundle
needed to develop a visualization extension.
The development of custom visualization with the SDK
uses exclusively JavaScript as a programming language and
takes advantage of two main libraries:
• SAP CVOM (Common Visual Object Modeler), also re-
ferred to as SAP HTML5 Visualization, is a visualization
and charting engine designed to work with HTML5 tech-
nology to create different visualizations. CVOM provides
utility classes to register and build own visualizations
in SAP Lumira and other SAP products utilizing other
auxiliary libraries in the back, e.g. jquery and requirejs.
• D3.js is a JavaScript library for manipulating HTML
documents. It allows you to bind arbitrary data to the
Document Object Model (DOM), and then apply data-
driven transformations to the DOM. This approach makes
it easy to create visualizations in a fast and lean way
depending on the available data.
The documentation for the Lumira SDK is limited to a
handbook and blog entries from the community [13], [14]. Un-
fortunately, there is little documentation and insights available
Fig. 2. The development process for creating custom visualization chart
extensions in SAP Lumira.
regarding how a lean and efficient development process can
look like for SAP Lumira chart extensions. In order to share
our experiences and fill this gap, we present the structured
development process we used and refined throughout our
project. Figure 2 illustrates the process broken down into the
following steps:
1) Design and define the requirements for your new visu-
alization. What is the input – dimensions and measures
[10], [15]? What should be visualized and how? At this
point, a well-considered definition of required dimensions
and measures is crucial. This avoids tedious refactoring
later in the development / implementation phase.
2) Setup the development and test environment using the
VizPacker utility. The VizPacker is able to automatically
generate the test environment which consists of an HTML
website, the necessary files and JavaScript libraries in-
cluding your chart extension bundle. As part of the setup,
it is essential to construct and integrate the appropriate
test data set into the test environment as defined earlier.
As a best practice, we recommend to extract a real test
data set directly from SAP Lumira using its debugging
capabilities [13, p. 12].
3) Develop the chart extension bundle. Start by completing
the declaration of necessary dimension and measures in
the feed definition that is needed to bind data to chart [15,
p. 111] [13]. Continue working on the rendering code for
the chart extension with D3.js – start by creating a pre-
liminary version with static data and enhance your chart
extension iteratively by including the real data and other
visualization parameters given by the SDK, e.g. width
and color palette. Finally, test your chart extension in the
HTML test environment and browser before deploying it
to SAP Lumira Desktop.
4) Deploy your custom chart extension to to SAP Lumira. In
case of the Lumira Desktop, this is done by copying your
bundle to a certain directory on the Windows file system
[13, p. 9]. When Lumira Desktop starts, it will look for
new chart extensions and dynamically load them into the
runtime.
5) Validate and test the chart extension in SAP Lumira. Are
all requirements fulfilled? What can be refined? What
about performance? These new requirements are the input
 for the next development cycle.
The main characteristic of the proposed development pro-
cess is that the chart extension implementation happens mainly
outside of SAP Lumira Desktop, because the Lumira Desktop
does not support ad-hoc reloading of bundles containing the
chart extension [13, p. 24]. Therefore, you are forced to
develop new visualization charts in a separate environment
using tools like the VizPacker contained in the Lumira SDK.
There are many helpful examples for custom visualizations
available on the web, such as flag bar chart for showing the top
three Olympic Medal winners fir 2004 and 2008 [14], [15].
IV. I MPLEMENTATION IN SAP L UMIRA
Having decided to build the custom visualizations inside
SAP Lumira Desktop, our next step was to identify the
necessary visualization types that need to be provided. In
order to discover relevant but missing visualization types in
Lumira Desktop, we evaluated the visualization charts used
in cancer research papers and tried to find the right chart
type in SAP Lumira Desktop for each of the visualizations
[16], [17]. During this process, we focused on identifying
reusable visualization charts. As stated before, many papers
often contain unique, custom visualizations that are tailored
to the specific data from the published research. Although
these graphical representations are comprehensive and valid,
we decided to disregard these visualizations as it is hard to
reuse them in other clinical papers and contexts.
As a result of this evaluation, we discovered that Stransky
et al. includes normalized stacked bar charts where each stack
in the bar represents the ratio relative to the total amount
of the bar [16]. Although Lumira Desktop supports stacked
bar charts, it is not able to normalized the bars as it is
required in the paper. Another non-supported visualization
type is the clustered heat map used in many papers including
[17]. In order to have the biggest impact with our custom
visualizations, we decided to implement normalized stack bar
chart and clustered heat map, as these chart types are slight
modifications of standard visualization types and continuously
used in the clinical context and publications.
The next sections present the approach, implementation
details and integration into SAP Lumira for each of the
missing chart types. In addition we analyze the complexity
of the rendering code and demonstrate some drawbacks of the
implemented chart extensions.
A. Normalized Stacked Bar Chart
A normalized stacked bar chart, also referred to as a stacked
percentage column chart, is a slight variation of the commonly
used bar chart. Bar charts are very useful, because they are
easy to understand, and their visual structure matches the
internal structure of data in many cases. But in cases with
more complex data, it is necessary to switch to some variations
in order to better visualize and indicate relationships inside
the structure of a data set. For example, stacked bar charts
can show a grouped structure in the data and a hierarchy
inside the data up to one level deep. This is particularly useful
when showing and comparing the totals of all bars because
they visually aggregate all of the categories in a bar. For the
purpose of visual comparison, normalized stacked bar charts
hide the total quantities of each bar by normalizing and using
percentages which makes it easier to see the relative difference
between quantities in each bar, like in Fig. 3.
As described before, the first part of the implementation is
defining the input needed for the chart extension - dimensions
and measures. For the normalized stacked bar chart extension,
we defined two dimensions (Entity and Stacked Entity) and
a measure (Stacked Measure), as seen in Lst. 1. This way,
Lumira knows the input that is expected by the chart extension,
waits for the user to select desired data sets and combines the
data sets to a cross-table data format. In case of Fig. 3, we
selected the TUMOR NAME and GENE NAME as dimension
and #Mutations as only measure leading to cross-table data
input similar to a matrix with the dimensions as axes and the
measure as the concrete value of the matrix cell.
1 chart_definition.addFeed({ "type": "Dimension",
2 "id": "viz.ext.hig.module.snst.plot.DS1",
3 "name": "Entity", "aaIndex": 1
4 "min": 1, "max": 1
5 });
6
7 chart_definition.addFeed({"type": "Dimension",
8 "id": "viz.ext.hig.module.snst.plot.DS2",
9 "name": "Stacked Entity", "aaIndex": 2
10 "min": 1, "max": 1
11 });
12
13 chart_definition.addFeed({ "type": "Measure",
14 "id": "viz.ext.hig.module.snst.plot.MS1",
15 "name": "Stacked Measure", "mgIndex": 1
16 "min": 1, "max": Infinity
17 });
Listing 1. Code snippet from the feed definition for the normalized
stacked bar chart. Each feed has an ID, name, a type – either Dimension
or Measure – and an index that allows to find the specific data feed within
a given data structure. There are also many more additional parameters
and setting, such as max and min.
The data input given as a data matrix is traversed com-
pletely and afterwards sorted by the Stacked Entity dimension.
Afterwards the stacked bar chart, axes, tool-tip, legend and
other elements are rendered.
The complexity of the rendering code can be described as
O(n · m + n · m · log(m)) ⊆ O(n · m · log(m)) with n being the
number of Entity dimension values and m being the number
of Stacked Entity dimension values.
A commonly known drawback of (normalized) stacked
bar charts is that too many categories add more visual noise
making it hard to detect patterns in the data. A possible
improvement for this chart extension could be to limit the
number of categories inside each bar and consolidate the
smaller stacks (e.g. less than 2%) into one ”Other” stack if
necessary.
B. Clustered Heat Map using Sorted Neighborhood Method
As discussed before, clustered heat maps are a very useful
visualization, since they allow to identify patterns more easily
within a large interconnected data set. There are many ap-
proaches to cluster heat maps. We decided to develop 1) An
own approach inspired by the Sorted Neighborhood Method
(SNM) shown in Fig. 4, and 2) A hierarchical clustering
Fig. 3. Normalized Stacked Bar Chart with TUMOR NAME as Entity dimension, GENE NAME as Stacked Entity dimension and #Mutations as the only
measure in order to show the relative breakdown of the DNA mutation counts for affected genes in tumor samples. It is interesting that almost 50 percent of
the mutations across all tumor samples belong to the genes ATM and TP53.
approach presented in Sect. IV-C. This gives us the possibil-
ity to compare and evaluate different characteristics of both
approaches, e.g. quality of clustered result and runtime.
In this section, we present an approach for clustering a heap
map that follows the idea of SNM. SNM is an approach from
the field of duplicate detection and record linkage providing
a parallelizable and efficient way to find duplicates in large
data sets [18]. SNM consists of 1) Defining sorting keys for
each data record consisting of relevant fields, 2) Sorting data
records using the predefined key, and 3) Merging data records
within a fixed size windows that moves through the sorted
records.
Before going into SNM, it is important to mention that the
chart extension receives a data matrix from SAP Lumira that
represent the heat map values. Therefore, the feed definition
for this clustered heat maps is based on Lst. 1.
We adapted SNM for our scenario to cluster a heat map
horizontally and vertically. This is necessary in order to have
a consistent clustering of the whole heat map on a row and
column level. The SNM approach is illustrated in Fig. 5 and
can be summarized in the following steps that are executed for
rows and columns of the data matrix individually:
1) Defining and calculating the sorting key as the sum of
the values for each row and column. Other sorting keys
are possible but need to be evaluated, e.g. average, min
/ max delta and entropy. At the same time calculate
∆row min max , the range between the highest and lowest
row / column sum value, as defined in Eq. 2.
2) Sorting rows and columns based on the sorting key. This
will naturally rearrange higher values in the data matrix to
the matrix’s upper left corner and the lower values to the
lower right corner. After this step, the sorted heat map will
be easier to understand and to detect interesting findings in
the data.
3) Merging similar rows and columns by comparing the row
value sum (row sumi ) with the value sum of the previous
row (row sumi−1 ), as defined in Eq. 1 – for columns
respectively. row sumi is the sum of all values in the
matrix row i and consequently row sums is the set of all
row value sums. Rows i and i−1 are considered to be in one
cluster if their absolute difference is smaller than a certain
fraction X of the calculated ∆row min max . X is a user-
defined threshold between 0 and 1. In combination with the
∆row min max , it indicates how much the rows can differ
until they are considered to considered to be dissimilar.
In case that the difference of the two value sums is greater
than the threshold, we insert a cluster break. A cluster break
means that the compared rows / columns belong to different
clusters and therefore should be visually separated. Other
clustering approaches also use a threshold [19].
|row sumi − row sumi−1 | < ∆min max · X (1)
∆row = max(row sums) − min(row sums) (2)
min max
After applying the adjusted SNM row-wise and column-
wise to the data matrix input, the heat map is rendered. The
identified cluster breaks from the last step are used to create
small gaps in order to visualize the clusters within the heat
map, as seen in Fig. 4 and Fig. 5.
Eq. 3 shows the complexity of the rendering code that can
be broken down into the complexity for: 1) Applying SNM to
n row value sums and m column value sums. O(n · log(n) +
k ·n) ⊆ O(n·log(n)) is the complexity of SNM with a sliding
Fig. 4. Heat map shows the #Mutation count for a subset of genes and tumor samples clustered with the Sorted Neighborhood Method (SNM). In this example
the user defined X = 0.25 as the threshold. The drawback of SNM is also obvious in this example when there are significant differences between two rows,
such as row TP53 and APC and KRAS. This leads to clusters with one element which is usually not desirable.
Fig. 5. SNM approach with concrete heat map (data matrix) example. Step 1
shows calculated rows sums used as the sorting key. After sorting the data
matrix in Step 2, the cluster breaks are included when the sliding window
moves across the dimensions in Step 3. For the specific data matrix example,
Eq. 2 returns ∆row min max = 21 − 9 = 12 and X = 0.25 which means
that a cluster break is included when the difference between two row sums is
greater than or equal to 3 = 12 · 0.25 – for columns respectively.
window size k of 1 when applied to all rows of the data matrix
[18] – for O(m · log(m)) respectively. 2) Constructing the
data structure and rendering the final heat map. This can be
done in O(n · m) as the matrix of rows and columns has to
be traversed completely. The overall asymptotic complexity of
the algorithm is bound to O(n·m) which is necessary in order
to construct the data structure and render the complete matrix
as a heat map.
O(n · log(n) + m · log(m) + n · m) ⊆ O(n · m) (3)
C. Clustered Heat Map using Hierarchical Clustering
SAP Lumira is a general purpose tool for creating vi-
sualizations from any kind of structured data input. If we
want to provide clustered heat maps as seen in Fig. 1, we
need to use generic clustering algorithms that do not require
specific knowledge about the data. Hierarchical clustering is
a clustering method that builds a hierarchy of clusters from
the given data by iteratively merging the closest data points to
one cluster (agglomerative hierarchical clustering). In order to
identify the clusters that should be combined, the clustering
algorithm needs a measure of dissimilarity between sets of
observations. For hierarchical clustering, the measure is formed
by combining an appropriate metric for distance calculation
between data points and a linkage criterion for calculating the
distance between merged data points [9].
The correct definition of data points is crucial to every
clustering algorithm, because the distance functions for the
data points are key for applying clustering methods to any do-
main. Especially when applying clustering to a heat map (data
matrix), it is important to have a clear definition of the data
point that should be clustered, as the integrity and consistency
of the heat map cannot be destroyed. It is inappropriate to
use the single heat map cell values as data points, because
the clustering result does not consider the position (row and
column) of the data point within the heat map. It is hard to
exploit this clustering result in order to rearrange the heat map
consistently.
As a result, we decided to cluster rows and columns of
the heat map individually by using row and column vectors. A
row vector is a m-dimensional vector where m is the number
of columns – and vice versa for column vectors. Having all
row and column vectors, it is possible to cluster one dimension
and leverage the output of the clustering in order to rearrange
and split the heat map along this dimension accordingly. We
used primarily the Euclidean distance function to calculate the
distance between the vectors. Single linkage was used as the
linkage criteria.
The result of any hierarchical clustering is a dendrogram, a
binary tree with data points as leaves. It represents the clustered
data points and the nested clusters at certain similarity levels,
as shown in Fig. 6. The dendrogram is used to rearrange /
reorder the heat map and identify the right position to split
the heat map. For example, rearranging rows in the heat map
according to the clustering result can be done by traversing the
dendrogram tree and leveraging the order of the leaves which
are by our definition the row vector. Due to this, similar rows
will be side by side or at least close to each other.
Fig. 6. Dendrogram tree as the result of applying hierarchical clustering to
the row vectors in Fig. 1. Traversing the tree retrieves the order of the rows
based on its similarity and the cluster breaks. Cluster breaks are the turning
points in the tree that split up into two clusters, denoted as the black nodes.
Identifying an appropriate position to include a gap in the
heat map is difficult, because there is no specific information
about the data and users’ expectations regarding clusters have
to be anticipated. There is no single approach for this problem,
as it highly depends on the given data set [19]. However, there
are approaches trying to identify and extract clusters from
dendrograms without any specific knowledge about the data
[19]. We want to pursue the same goal, but with a different
approach.
Our implementation extracts cluster breaks from the den-
drogram tree through the search for turning point nodes. A
turning point node in a dendrogram tree is a node that has two
non-leaf nodes as children, denoted as black nodes in Fig. 1.
Such a node splits up the remainder of the tree in two areas
that contain similar data points, i.e. row and column vectors.
These areas can be seen as clusters and the black nodes as
cluster breaks. The turning points and cluster breaks can be
identified by doing an in-order traversal. The result of this
traversal is an ordered list containing the rows / columns and
cluster breaks, as shown in the bottom of Fig. 1. This list is
used to add small gaps when rendering the heat map, see Fig.
1.
Implementing a hierarchical clustering algorithm in SAP
Lumira can be done in many ways. It was clear for us to exploit
existing algorithm implementations provided as a library, but
there are a few options from an infrastructure point of view
that needed to be considered:
• Including clustering information in data sets retrieved
by SAP Lumira. The clustering algorithm could be per-
formed periodically on the data stored in HANA using
its Predictive Analysis Library (PAL) [20]. Once a data
set is requested by Lumira, the response can be enhanced
with pre-calculated clustering information that could be
used directly to render the heat map. A drawback is that
users are limited to data sets that have been clustered
beforehand.
• Separate, auxiliary request in HANA database. Once the
user selects the data sets to visualize, SAP Lumira makes
a separate request to the HANA XS Engine and asks to
cluster the selected data set on the fly [12]. Finally, the
heat map is rendered based on the clustering result. This
seems to be the worst option in terms of network overhead
and ad-hoc clustering as PAL requires setup time [20].
• Using existing JavaScript clustering libraries when ren-
dering the heat map inside SAP Lumira. Although clus-
tering can be a resource intensive task, we believe that
it can be performed on the client-side, because you can
assume that the amount of data is somehow limited by
the amount of information a user is able to comprehend.
So there will not be a useful heat map with over a million
cells that would require powerful infrastructure. The data
amount that need to be clustered is relatively small and
therefore manageable. Doing the clustering inside SAP
Lumira avoids additional communication with the HANA
data store and it performs better than the other options
considering the limited data set, although this still needs
proper benchmarking.
Although it affects the responsiveness when calculating
and rendering the clustered heat map inside SAP Lumira, we
decided to implement the last option using clusterfck.js, a light
weight clustering library with limited feature set [21].
Analyzing the runtime complexity of the rendering code
in Eq. 4, it can be broken down into the complexity of:
1) Applying hierarchical clustering to n row vectors and m
column vectors. O(n2 ) is the runtime complexity of hierar-
chical clustering, because we used Euclidean distance metric
and Single Linkage criteria in our implementation. Using
other distance or linkage functions can increase the runtime
complexity to O(n3 ). 2) Traversing the dendrogram tree for
both clustering results. An in-order traversal can be done in
O(n) where n is the number of leaves which are row or column
vectors. 3) Constructing the data structure and rendering the
final heat map can be done in O(n · m) as the matrix of rows
and columns has to be traversed completely. This breakdown
leads to the following Eq. 4, which is bound by O(n2 + m2 ).
O((n2 + m2 ) + (n + m) + (n · m)) ⊆ O(n2 + m2 ) (4)
V. E VALUATION
In this section, we present an evaluation of the chart
extensions presented in this work. This evaluation focuses
on comparing the two presented approaches in terms of the
runtime complexity of the rendering code and the results on a
qualitative basis.
Assessing the runtime complexity is a good indicator of
performance behavior of the implementation when data are
scaled up. Although we do not assume that the visualizations
will have to deal with a large amount of data, it is still
necessary to analyze the complexity to avoid unresponsive
user interfaces. Eq. 3 shows the complexity for the heat map
with SNM. The complexity for the hierarchically clustered heat
map is shown before in Eq. 4. Comparing the complexities,
we noticed that both approaches belong to the same quadratic
complexity class. However, the breakdown of each runtime
complexity reveals that the SNM approach for clustering will
be faster, because the asymptotic complexity is bound by the
rendering of the heat map, i.e. O(n · m). The hierarchical
clustering approach is bound to the runtime of the hierarchical
clustering algorithms applied to rows and columns of the heat
map, i.e. O(n2 + m2 ).
Looking at both clustering results, we are pleased with
the quality of the clustering considering the fact that both
approaches work without additional knowledge about the data.
The readability and comprehensibility of the heat map im-
proved. However, the hierarchically clustered heat map seems
to produce better results in general than the heat map clustered
with SNM. The reason for this is that clusters are identified
directly from the result of the hierarchical clustering algorithm
that continuously merges data points to clusters. On the other
side, we observed that SNM reacts sensitively to significant
differences between row and column data, leading to clusters
consisting of one element, as shown in Fig. 4. Furthermore, the
SNM approach disregards slowly increasing row value sums
which can result non-discovered clusters.
As a result, we can say that clustered heat map using a
hierarchical clustering algorithm produces a clearer and more
reliable clustering result. Considering the rather small amount
of data passed to the clustered heat map, it will not have a
significant impact on the runtime performance.
In order to discover further potential for optimization and
reveal the benefit of clustered heat maps for cancer researchers,
it is necessary to extend the evaluation and conduct bench-
marks assessing other criteria, such as user experience and
space complexity.
VI. C ONCLUSION AND O UTLOOK
In the given work, we presented the need for cancer re-
searchers to have an interactive visualization of their conducted
data in order to explore and discover patterns and insights
in their data. For this goal, we exploited and adjusted the
capabilities of SAP Lumira, an existing data visualization
tool to fit the needs of cancer researchers. This required
the design of new visualization charts that were missing:
1) Normalized Stacked Bar Chart, 2) Clustered Heat Map with
Sorted Neighborhood Method, and 3) Clustered Heat Map with
hierarchical clustering. For each visualization we explained
the design and shared insights, implementation details and
considerations from the integration of chart extensions in SAP
Lumira. Finally, we compared both approaches for clustered
heat map approach and concluded that hierarchical clustering
leads to better and more reliable clustering results.
Concerning future work, we will focus on a scientific eval-
uation of the developed visualization chart including perfor-
mance and a qualitative benchmark. As part of the qualitative
benchmark, it is required to reengage and conduct user studies
View publication stats
with the cancer researchers focused on the comprehensibility
and usefulness of two clustered heat map approaches. The
resulting feedback will help to refine the chart extensions in
SAP Lumira. Simultaneously, we will continue developing new
chart extensions that are necessary in the context of cancer
research and treatment, such as a combination of clustered
heat map and dendrogram [7], [17].
R EFERENCES
[1] M.-P. Schapranow and H. Plattner, “HIG – An In-memory Database
Platform Enabling Real-time Analyses of Genome Data,” in Proceed-
ings of the International Conference on Big Data, 2013, pp. 691–696.
[2] S. Aechtner, “An Algorithm to Calculate Functional Changes in the
DNA Utilizing In-Memory Technology,” 2014.
[3] T. Schubotz, “Drug Response Analysis by Association Rule Mining
based on Genetic Changes in Genome Data,” 2014.
[4] D. Petrick, “Drug Response Classification and Prediction for Tumor
Data with Support Vector Machines,” 2014.
[5] D. Stengel, M. Bhandari, and B. Hanson, Statistik und Aufbereitung
klinischer Daten. Georg Thieme Verlag, 2011.
[6] T. Snyder, “Data Visualization for Clinical Trials Data Management and
Operations,” in A Picture is Worth a Thousand Tables. Springer, 2012,
pp. 359–372.
[7] M. B. Eisen, P. T. Spellman, P. O. Brown, and other, “Cluster Analysis
and Display of Genome-wide Expression Patterns,” Proceedings of the
National Academy of Sciences, vol. 95, no. 25, pp. 14 863–14 868, 1998.
[8] B. A. Teicher, Tumor Models in Cancer Research. Springer, 2002,
vol. 10.
[9] A. K. Jain, M. N. Murty, and P. J. Flynn, “Data Clustering: a Review,”
ACM computing surveys (CSUR), vol. 31, no. 3, pp. 264–323, 1999.
[10] SAP AG. (2014, Mar.) SAP Lumira User Guide 1.15. [Online].
Available: http://help.sap.com/businessobject/product guides/vi01/en/
lum 115 user en.pdf1
[11] ——. (2014, Mar.) SAP Lumira Server User Guide 1.15. [Online].
Available: http://help.sap.com/businessobject/product guides/vi01/
en/lumS115 user en.pdf,http://help.sap.com/businessobject/product
guides/vi01/en/lumS115 install en.pdf1
[12] ——. (2014, Mar.) SAP HANA Developer Guide. [Online]. Available:
http://help.sap.com/hana/SAP HANA Developer Guide en.pdf1
[13] ——. (2014, Feb.) SAP Lumira SDK Getting Started Guide 1.14.
[Online]. Available: http://help.sap.com/businessobject/product guides/
vi01/en/lum 114 vp en.pdf1
[14] ——. (2014, Feb.) SAP Lumira Community. [Online]. Available:
http://scn.sap.com/community/lumira1
[15] ——. (2014, Mar.) SAP Lumira User Guide 1.11. [Online].
Available: http://help.sap.com/businessobject/product guides/vi01/en/
vi1 0 11 user en.pdf1
[16] N. Stransky, A. M. Egloff, A. D. Tward et al., “The Mutational
Landscape of Head and Neck Squamous Cell Carcinoma,” Science, vol.
333, no. 6046, pp. 1157–1160, 2011.
[17] C. C. Whiteford, S. Bilke, B. T. Greer et al., “Credentialing Preclinical
Pediatric Xenograft Models using Gene Expression and Tissue Microar-
ray Analysis,” Cancer research, vol. 67, no. 1, pp. 32–40, 2007.
[18] M. A. Hernández and S. J. Stolfo, “The merge / purge problem for large
databases,” in ACM SIGMOD Record, vol. 24, no. 2. ACM, 1995, pp.
127–138.
[19] J. Sander, X. Qin, Z. Lu, N. Niu, and A. Kovarsky, “Automatic
Extraction of Clusters from Hierarchical Clustering Representations,”
in Advances in Knowledge Discovery and Data Mining. Springer,
2003, pp. 75–87.
[20] SAP AG. (2014, Mar.) SAP HANA Predictive Analysis Library (PAL).
[Online]. Available: http://help.sap.com/hana/SAP HANA Predictive
Analysis Library PAL en.pdf1
[21] (2012) Clusterfck: A Clustering Analysis Library in JavaScript.
[Online]. Available: https://github.com/harthur/clusterfck1
1 All online references checked on Mar. 31, 2014