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

net/publication/261446728

Intelligent granulation of machine-generated data

Conference Paper · June 2013

DOI: 10.1109/IFSA-NAFIPS.2013.6608377

CITATIONS READS
3 99

2 authors, including:

Dominik Ślęzak
University of Warsaw
311 PUBLICATIONS   4,331 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

ICRA Project View project

Comparator Networks View project

All content following this page was uploaded by Dominik Ślęzak on 07 May 2015.

The user has requested enhancement of the downloaded file.

 Intelligent Granulation of Machine-generated Data
Dominik Ślȩzak∗† and Marcin Kowalski∗
∗ Institute
of Mathematics, University of Warsaw
ul. Banacha 2, 02-097 Warsaw, Poland
† Infobright Inc.
ul. Krzywickiego 34/219, 02-078 Warsaw, Poland
slezak@infobright.com; mkowal@mimuw.edu.pl

Abstract—We discuss how the specifics of data granu-
lation methodology can influence Infobright’s database
system performance. We put together our two previous
research paths related to machine-generated data sets,
namely, dynamic reorganization of data during load
and efficient handling of alphanumeric columns with
compound values. We emphasize the role of domain
knowledge while tuning data granulation processes.
Index Terms—Analytic Databases, Domain Knowl-
edge, Compound Values, Stream Clustering, Outliers.
I. Introduction
Information granulation is one of fundamental aspects
of granular computing [1], [2]. Granules can correspond to
collections of entities gathered during, e.g., data acquisi-
tion or generation. Such collections may contain elements
arranged together due to, e.g., their adjacency or similar-
ity. Operations on granules, or rather their high-level rep-
resentations, underly many applications of approximate
reasoning and hierarchical concept modeling [3], [4].
Via calculations on granules, one can scale operations
over large and complex data. For instance, in data mining,
there is a popular approach to search for meaningful
clusters basing on statistical summaries of heuristically
pre-computed micro-clusters [5], [6]. There is no guarantee
that clusters obtained by grouping together micro-clusters
with similar representations will reflect all nuances of input
data. Sill, computational savings thanks to operating with
summaries instead of real data are often worth it.
Representations of dynamically assembled granules can
be also useful in database systems aimed at maintaining
the speed of data analysis in the face of massive data
generated by various types of sensors and devices. Follow-
ing the principles of rough sets [7], [8], one can compute
approximate or – if a system is designed to store both
statistical snapshots and original contents of granules –
exact answers to standard SQL queries [9], [10]. Generally,
by scaling computations one may mean both speeding
up typical operations thanks to more intelligent work
with granulated data, as well as introducing approximate
variants of those operations, analogously to the above-
mentioned analysis of micro-cluster representations.
Regardless of whether we consider a database, a data
clustering framework, or any other form of employing
granular computations, their efficiency will depend on the
quality of granules. In [11], [12], we investigated how to
define the quality of granulation for a database system
performing operations with assistance of metadata layer
containing simplified representations of granules resulting
from vertical and horizontal data decompositions. We also
showed how to implement a mechanism of organizing
the incoming tabular data into such blocks of rows that
maximize a quality of their granular representations.
On the other hand, it is not so obvious how to translate
the quality of granules into the quality of the whole system.
If the goal is to improve database performance, we can
judge a given granular environment by its ability to reduce
computational effort related to accessing detailed granule
contents instead of working only with their high-level
representations. However, it may significantly depend on
domain knowledge about, e.g., specific types of analytic
SQL statements that end users may wish to execute.
Domain knowledge is useful also within single granules.
Information granulation is usually assumed to involve nu-
meric content but this is not a case for analytic databases
storing machine-generated data. In [13], [14], we focused
on data sets with varchar columns corresponding to sub-
collections of values fitting different structural patterns
identified by data providers, representing web addresses,
online transactions and so on. We designed new methods
of creating structure-based statistics for such granules.
The primary objective of this paper is to put together
our methods of utilizing domain knowledge to better
annotate such internally compound granules with our pre-
viously developed methods of controlling a flow of loaded
rows, in order to provide a more complete framework for
handling massive amounts of machine-generated data.
The paper is organized as follows: In Section II, we recall
Infobright’s system architecture, which is an example of a
more general approach to granular computational scala-
bility. In Section III, we illustrate how domain knowledge
about data content and end user activities can shape the
principles of data granulation optimization. In Section IV,
we revisit our previous algorithmic framework for on-load
data granulation with respect to three types of outliers
usually occurring in machine-generated data. In Section
V, we outline the related work in the areas of databases
and data mining. Section VI concludes our research.

Fig. 1. Loading and querying in Infobright database system. Data
is partitioned onto row packs, each consisting of 216 rows. Values of
each of data columns are stored separately, in data packs. Row packs
are labeled with rough values providing high-level information about
data packs. This leads to a layer of granulated information systems
where objects correspond to row packs and attributes correspond to
rough values. Rough values and compressed data packs are stored on
disk. When querying, applicable rough values are put into memory.
Query performance depends on the efficiency of rough values in
minimizing the access to data packs stored on disk. In case of, e.g.,
data filtering, rough values are applied to quickly exclude data packs
that do not satisfy a given SQL condition. Only not excluded packs
need to be decompressed and examined value by value.
II. Infobright – A Granular Database System
The approach presented in this section is an example of
a general strategy of scaling computations on large data
sets. Following the principles of rough sets and granular
computing [1], [8], this methodology can be expressed by
the four following steps: 1) Decompose data onto granules;
2) Create statistical snapshots for each of granules; 3)
Do approximate computations on snapshots; 4) Whenever
there is no other choice, access some of granules.
Infobright’s engine is entirely based on the above strat-
egy, in combination with the principles of columnar data
stores [15], [16], adaptive data compression [17], [18], and
pipelined query processing [19], [20]. Figure 1 outlines a
scheme of decomposing data onto so called data packs and
producing their high-level representations, called rough
values. It also illustrates a simple way of employing rough
values in query execution, analogous to some other cases
of using statistics over partitioned data [21], [22].
There are many ways of using rough values in database
operations [9], [23]. Figure 2 shows importance of interac-
tions between layers of approximate computing with rough
values and exact computing with data pack contents. In
case of queries involving many columns, it is important
that we know which rough values describe the same blocks
of rows, called row packs. This is helpful when resolving,
e.g., multidimensional ad-hoc filters. On the other hand,
it becomes a challenge when attempting to organize rows
Fig. 2. SELECT MAX(A) FROM T WHERE B>15; [10]. Min/max rough
values for numeric data columns A and B in table T are presented at
the left side. Data packs are classified into three categories: Irrelevant
(I) with no elements relevant for further execution; Relevant (R) with
all elements relevant for further execution; Suspect (S) that cannot be
classified as neither R nor I. The R/I/S areas correspond to the rough
set positive, negative and boundary regions. The first execution stage
classifies data packs into R/I/S regions with respect to condition
B>15. The second stage employs the third row pack to approximate
the result as MAX(A) ≥ 18. Hence, all row packs except the first and
the third ones become unnecessary to complete the task. At the third
stage, approximation is changed to MAX(A) ≥ X, where X depends on
the result of exact (E) processing of the first row pack. If X ≥ 22,
then there is no need to access the third row pack.
into row packs in a way that would improve rough value
descriptions for many columns in the same time.
Infobright’s rough values can be treated as a metadata
layer. Besides min/max statistics displayed above, they
may contain, e.g., a sum of numeric values or total length
of string values, a number of NULL values and so on [9],
[14]. The efficiency of rough values can be measured in
two ways. First of all, overall size of statistics maintained
within rough values needs to be far smaller than the size of
underlying data. Secondly, rough values should be able to
prevent accessing data regions that would be unnecessary
to answer to a given query when having a direct access to
each of single data elements. In other words, there should
be a low risk of occurrence of so called false suspects, which
are data packs classified as suspects that turn out to be
fully relevant or irrelevant after accessing them.
The remaining metadata layers are responsible for ac-
cessing and interpreting contents of data packs and rough
values. They may contain, e.g., dictionary structures for
columns with relatively small number of unique values or
already-mentioned domain-specific descriptions of values
of long varchar data columns. All such kinds of metadata
require to be consistently taken into account while parsing,
granulating and compressing newly loaded data.
Metadata needs to be considered also while design-
ing and interpreting rough values. However, we assume
that rough values’ functionality, such as ability to iden-
tify rough-set-inspired regions as illustrated by Figure 2,
should remain the same for all kinds of internal structures
and high-level descriptions used for data packs.

Fig. 3. Infobright’s granulation parameters [24]. Granularity controls
the amount of rows in every row pack (216 by default). Finer gran-
ularity yields higher rough value precision and more selective data
accessibility but also increases overall metadata size. Origin reflects
scenarios where data is acquired from different sources by data load
processors, which parse, granulate and compress data locally, and
send assembled data packs and their corresponding rough values to
the main database server. In such a case, row packs gathered in the
main server are homogeneous with respect to attributes denoting
data origin. Quality stands for the on-load row reorganization proce-
dures aimed at improvement of row packs with respect to precision
of rough values over some selected data columns.
III. Importance of Domain Knowledge
Employing domain knowledge is crucial at each step
of the computational strategy outlined in Section II. For
instance, when creating granules, one needs to develop
fast decomposition methods assuring reasonable granular
quality, with respect to dynamically changing criteria. As
another example, we need to guarantee that snapshots of
granules are small but also informative enough, where a
criterion of being informative is again subject to specifics
of information needed in expected data operations.
In case of Infobright, informativeness corresponds to
how precisely rough values describe data packs. Indeed,
more precise descriptions quickly lead to better computa-
tion approximations. Figure 3 illustrates factors that can
influence rough value precision, with one of them referring
to on-load row reorganization developed in [11], [12].
Row reorganization means that row packs are formed
by not necessarily consecutive rows. Besides some obvious
computational complexity challenges addressed in the next
section, the two remaining questions are how to make a
transition from precision of single rough values to precision
of row packs represented by rough values corresponding to
multiple data columns, and how to mathematically grasp
rough value precision for various data content types.
Let us give just a few examples. For numeric columns,
rough value precision can be inversely proportional to
differences between max and min shown in Figure 2. For
so called low cardinality columns, it may be inversely
proportional to a number of distinct values in a data pack,
which corresponds to generalized decision functions used
Fig. 4. Utilizing knowledge about attribute values [13]. Rules
stored in structure dictionary enable to parse values onto smaller
particles. Match table keeps information which rules were triggered
for which values. Structure sub-collections contain values matched by
the same rule. Each sub-collection is handled independently, within a
single data pack. Outlier sub-collection contains items that were not
matched by any rule. For example, Table T includes varchar column
MaybeURL. Structure dictionary for MaybeURL contains a rule defining
how strings representing URL addresses are usually composed. Match
table contains the following codes: 1 if a value is recognized as
URL; 0 for NULL values; -1 for unrecognized values. Sub-collections of
URL addresses are then decomposed with respect to their substrings
representing scheme, hierarchical part and so on. Such substrings
are often easier to represent at the level of rough values.
in rough sets [7], [24]. However, a general task of expressing
rough value precision is certainly far more difficult.
In [13], [14], we investigated how knowledge about data
origin may assist in seeking for optimal storage and repre-
sentation of machine-generated columns with compound
values. Figure 4 illustrates how so called domain rules
can help in internal decompositions of alphanumeric val-
ues onto their smaller pieces grouped into sub-collections
within a data pack. Each sub-collection can be represented
by a more informative snapshot component, although
some of values may not follow discovered or predefined
rules, which could decrease rough value precision.
Another problem is how to create row packs with precise
rough values for multiple columns. Usually, rows are nat-
urally organized with respect to columns correlated with
specifics of data generation. Rough values for such columns
are often far more precise than for others. If, according to
domain knowledge, a task is to reorganize rows to improve
rough values for some of those other columns, then we need
to be prepared for losing their precision elsewhere.
There are many ways to evaluate row packs with respect
to rough values of their corresponding data packs [11], [12].
For example, for ad-hoc query scenarios, one may reorga-
nize newly loaded rows in order to improve rough values
over arbitrary columns, but with a penalty subject to too
significant loss of precision for other columns, compared to
previously loaded data. In other cases, following an idea
to rank columns due to their expected role in queries [25],
[26], one might consider row pack quality in terms of a
weighted average precision of involved rough values.
 OLD BUFFER CONTENT NEW BUFFER CONTENT
+------+------+------+ +------+------+------+
| A | B | C | | A | B | C |
+------+------+------+ +------+------+------+
1 | ’?’ | 3 | 1 | 1 | ’?’ | 3 | 1 |
+------+------+------+ +------+------+------+
2 | ’4’ | NULL | 2 | 2 | ’4’ | NULL | 2 |
3 | ’1’ | NULL | 4 | 3 | ’1’ | NULL | 4 |
+------+------+------+ 5 | NULL | 1500 | 3 |
| | | | +------+------+------+
+------+------+------+ | | | |
4 | ’4’ | 5 | 3 | +------+------+------+
+------+------+------+ 4 | ’4’ | 5 | 3 |
Fig. 5. A flow of loaded rows. Parser identifies of particular data +------+------+------+
columns and checks them against available domain rules (see Section A ROW TO BE ADDED
III). Granulator organizes parsed rows into row packets, which are +------+------+------+
then used to assemble row packs sent to loader for rough value 5 | NULL | 1500 | 3 |
calculation and data pack compression. A new row pack is pushed +------+------+------+
to loader once granulator is ready to assembly it according to its
constraints. Alternatively, loader might request granulator for a
new row pack once it has finished processing a previous portion of Fig. 6. An example of the process of adding rows to a row buffer.
data. All considered modules rely on metadata layers discussed in Consider a data table with a varchar column A and integer columns
Section II. Granulator’s historical metadata summarizes rough value B and C. Note that most of values of A are integers as well, which may
precisions of already loaded data packs for particular data columns, be represented by a simple domain rule [13], [14]. All three types of
which may influence strategies of evaluating row packets and final outliers considered in Section IV are present. The buffers contains
row packs. For instance, optimization with respect to columns whose four row packets, aimed at gathering rows with outliers on A, B and
rough values are especially difficult to improve because of specifics C, as well as rows with no outliers at all. A row to be added has a
of a loaded data stream can gradually become less important even if NULL outlier on A and so called out-of-range outlier on B. The process
they were initially prioritized by domain experts. needs to heuristically decide which row packet the new row should
join. According to simple evaluation based on min and max values
over numeric columns [11], [12], it is added to row packet collecting
outliers for B, as it does not decrease rough value precision for C. On
IV. Dynamic Granulation of Complex Data the other hand, it would severely decrease rough value precision for
C when added to row packet gathering outliers on A.
Data granulation algorithms should work over a stream
of loaded data with no need of re-accessing already pro-
cessed granules. It is in analogy to data clustering and
micro-clustering techniques relying on in-memory struc- structural outliers discussed in Section III. NULL values can
tures, which receive new elements and dynamically re- be treated as outliers too. Although there is no problem
organize them into final result components [5], [27]. As with handling NULL values at data storage level [13], [17],
displayed in Figure 5, such a repackaging stage should be their occurrence may block some benefits of computations
located between modules responsible for parsing incoming over high-level representations of data packs.
rows and compressing the resulting row packs. In order to better handle rows with outlier values, let
In [11], [12], we considered data granulator with a very us redefine the objectives of Infobright’s data granulation
simple buffer structure containing packets interpreted as process by means of the two following levels: 1) Organize
incomplete row packs. For each new entry, a choice of row rows into row packs in such a way that percentage of data
packet was based on simulating a decrease of weighted packs including outliers is minimal; 2) Additionally, max-
rough value precision of particular packets that would imize rough value precisions computed for sub-collections
result from adding the considered row. Every time 216 rows of non-outlier values within each of data packs.
were collected in one of row packets, its contents were sent Figure 6 outlines a simple way of choosing a packet for
to further stages in order to finalize next row pack, making each new row. Assuming specified packets responsible for
space for receiving more data from the parser. gathering rows with outliers over each single data column,
If a new row could not match any packet without too the remaining question is how to deal with rows with
drastic decrease of rough value precisions in comparison multiple outliers. For this particular case, we can follow
to the history of previous matches, it was moved to a the same heuristic approach as proposed in [11], [12], now
trash packet producing row packs of lower quality. Such restricted to sub-collections of non-outlier values.
an approach turned out to be useful for handling data Figure 7 shows a mechanism of selecting rows from one
fluctuations, noises and outliers [28], [29]. However, some or many data packets in order to assembly row packs
issues may occur with a growing intensity and variety of according to the above objectives. Such mechanism should
outliers. If there are too many cases of values forcing their also simulate a quality of buffer content after removing
corresponding rows to be sent to trash, an average quality selected rows, i.e., its expected ability to form good row
of produced row packs becomes insufficient. packs in next iterations. Moreover, it requires introducing
In case of machine-generated data sets, besides out-of- more advanced data structures within each of data pack-
range values not fitting column distributions, there are also ets, to retrieve their specific fragments efficiently.

Fig. 7. Row pack production. Buffer is being filled with newly parsed
rows until it reaches its maximum capacity (e.g.: 218 rows) or loaded
data stream is finished. In both cases, a procedure of forming a new
row pack is launched. A heuristic algorithm decides which rows, and
from which row packets, are going to be used. Selected rows are
deleted from their packets and sent to loader. One can consider the
following examples of heuristic rules for a task of locating outliers
in possibly minimum number of produced data packs: 1) If there
is a row packet with more than 216 rows having outlier values on
one of columns, then take a subset of 216 rows with possibly highest
precision of rough values over other columns; 2) Else, compose row
pack from a subset of rows taken from multiple row packets, trying
to maximize a number of columns with no outliers.
V. Related Work
In analytic databases, various forms of summaries are
commonly used at the level of query optimization [25],
[30]. However, their utilization during query execution is
usually restricted to simple operations aimed at avoiding
accessing irrelevant data while resolving WHERE conditions
[18], [21]. Operations on data summaries are more popular
in the area of granular computing [1], [4]. However, granu-
lar computation models usually do not assume iterative
work with both high-level representations and original
data. With this respect, Infobright’s approach to dynamic
enhancement of SQL execution is quite unique.
A need for processing massive machine-generated data
sets is well-recognized, with respect to both their size and
mixed content [6], [29]. However, it is usually assumed that
values of particular columns follow unique generic types.
For practical reasons, allowing collections of compound
alphanumeric values to get internally decomposed on more
homogeneous sub-granules is worth considering.
In both above cases, it is crucial to take an advantage
of available knowledge about data sources and analytical
Fig. 8. Comparison of data sorting and granulation [12]. All three
data tables contain the same rows. For simplicity, each of row packs
in the last table contains only two elements. Two first tables show
that sorting with respect to particular columns destroys rough values
of others. Last table shows that more thoughtful granulation provides
better balance between precisions of rough values corresponding to
different columns. Rough values get more precise whenever data
pack elements become even slightly more homogeneous, at least for
some columns on some row packs. Comparing to classical clustering
criteria in data mining, value ranges of row packs can intersect with
each other. Comparing to other techniques of database tuning, the
proposed granulation objectives are less rigorous, with reorganization
of already loaded content (subject to evolving data regularities or end
user expectations) treated as optional rather than compulsory.
goals. At the system design level, it requires a distinction
between data providers, who have domain expertise that
they usually want to share, and end users, who do not
need to be aware how such expertise influences internal
computations [14], [31]. There is significant research how
to adaptively translate feedback from both data providers
and end users into logical and physical specifications of
database models [32], [33]. However, there are no interfaces
letting domain experts share their knowledge without a
need of mastering database administration tools.
There are many techniques that can be applied to
improve machine-generated data layout. For instance, one
might sort rows with respect to columns expected to occur
most frequently in SQL statements, creating multiple data
projections ordered in different ways and, while querying,
choosing those optimally fitting particular data operations
[16], [26]. However, sorting may not be so beneficial for
long varchar columns. Moreover, it is often better to
avoid such restrictive data organization, which comes at
significant computational cost (see also Figure 8).
The presented data granulation framework has some
obvious analogies to stream clustering [5], [27]. In data
mining, clustering is understood as approximately orga-
nizing rows into practically meaningful groups [34], [35].
Although our criteria for putting rows into row packs are
different, it is still a good example of adopting data mining
principles in order to improve database internals.
Last but not least, it is important to refer to rich liter-
ature on handling outliers in data clustering and stream
analysis [28], [36]. Although our way of understanding out-
liers is not so standard, the proposed strategy of locating
them in minimum number of data packs while maximiz-
ing rough value precision over other columns could be
regarded as a kind of outlier-robust micro-clustering.
 VI. Conclusions
We discussed various aspects of intelligent data granula-
tion within Infobright’s framework for database analytics.
We focused on dynamic organization of tabular data rows
into row packs whose summaries would be most efficient
while assisting standard SQL operations with fast granular
calculations. We noted that for machine-generated data
sets usefulness of such summaries depends primarily on
ability to isolate some specific types of outliers from more
regular content during the data load process.
Actually, such a kind of granulation may be considered
not only for newly loaded entries. In applications related
to machine-generated data processing, there is often a
need to produce and transmit huge query results obtained
as partial aggregations or projections of original content.
Appropriate dynamic granulation of query outputs may
be highly beneficial both with respect to their compres-
sion and representation. For such scenarios, in our future
research, we are going to take an advantage of metadata
describing query inputs, which was unavailable in case of
an on-load organization of brand new data.
The proposed framework is also worth extending toward
more compound types of data columns, with values fitting
different patterns or regularities for different rows. Such
internally heterogeneous columns can occur in data sets
resulting from, e.g., integration or tokenization of original
sources. It is then important to locate values of such
different kinds in possibly separate data packs, which is
obviously not an easy task when optimizing row packs with
respect to multiple columns in the same time.
References
[1] W. Pedrycz, Granular Computing – Analysis and Design of
Intelligent Systems. CRC Press, 2013.
[2] L. A. Zadeh, Computing with Words – Principal Concepts and
Ideas, ser. Studies in Fuzziness and Soft Computing. Springer,
2012, vol. 277.
[3] S. K. Pal, L. Polkowski, and A. Skowron, Eds., Rough-neuro-
computing: Techniques for Computing with Words. Springer,
2003.
[4] W. Pedrycz, A. Skowron, and V. Kreinovich, Eds., Handbook of
Granular Computing. Wiley-Interscience, 2008.
[5] C. C. Aggarwal, Ed., Data Streams: Models and Algorithms.
Springer, 2007.
[6] U. Fayyad, P. Bradley, and C. Reina, “A Scalable System for
Clustering of Large Databases having Mixed Data Attributes,”
US Patent 6,581,058 B1, 2003.
[7] Z. Pawlak and A. Skowron, “Rudiments of Rough Sets,” Inf.
Sci., vol. 177, no. 1, pp. 3–27, 2007.
[8] ——, “Rough Sets: Some Extensions,” Inf. Sci., vol. 177, no. 1,
pp. 28–40, 2007.
[9] D. Ślȩzak and V. Eastwood, “Data Warehouse Technology by
Infobright,” in SIGMOD, 2009, pp. 841–846.
[10] D. Ślȩzak, J. Wróblewski, V. Eastwood, and P. Synak, “Bright-
house: An Analytic Data Warehouse for Ad-hoc Queries,” Proc.
VLDB Endow., vol. 1, no. 2, pp. 1337–1345, 2008.
[11] D. Ślȩzak and M. Kowalski, “Intelligent Data Granulation on
Load: Improving Infobright’s Knowledge Grid,” in FGIT, 2009,
pp. 12–25.
[12] D. Ślȩzak, M. Kowalski, V. Eastwood, and J. Wróblewski,
“Methods and Systems for Database Organization,” US Patent
8,266,147 B2, 2012.
View publication stats
[13] M. Kowalski, D. Ślȩzak, G. Toppin, and A. Wojna, “Injecting
Domain Knowledge into RDBMS – Compression of Alphanu-
meric Data Attributes,” in ISMIS, 2011, pp. 386–395.
[14] D. Ślȩzak, G. Toppin, M. Kowalski, and A. Wojna, “System and
Method for Managing Metadata in a Relational Database,” US
Patent Application 2011/0307472 A1, 2011.
[15] S. Idreos, F. Groffen, N. Nes, S. Manegold, K. S. Mullender,
and M. L. Kersten, “MonetDB: Two Decades of Research in
Column-oriented Database Architectures,” IEEE Data Eng.
Bull., vol. 35, no. 1, pp. 40–45, 2012.
[16] M. Stonebraker, D. Abadi, A. Batkin, X. Chen, M. Cherniack,
M. Ferreira, E. Lau, A. Lin, S. Madden, E. O’Neil, P. O’Neil,
A. Rasin, N. Tran, and S. Zdonik, “CStore: A Column Oriented
DBMS,” in VLDB, 2005, pp. 553–564.
[17] C. Apanowicz, V. Eastwood, D. Ślȩzak, P. Synak, A. Wojna,
M. Wojnarski, and J. Wróblewski, “Method and System for
Data Compression in a Relational Database,” US Patent Ap-
plication, 2008/0071818 A1, 2008.
[18] P. White and C. French, “Database System with Methodology
for Storing a Database Table by Vertically Partitioning all
Columns of the Table,” US Patent 5,794,229, 1998.
[19] A. Ailamaki, D. J. DeWitt, and M. D. Hill, “Data Page Layouts
for Relational Databases on Deep Memory Hierarchies,” VLDB
J., vol. 11, no. 3, pp. 198–215, 2002.
[20] M. Zukowski and P. A. Boncz, “Vectorwise: Beyond Column
Stores,” IEEE Data Eng. Bull., vol. 35, no. 1, pp. 21–27, 2012.
[21] R. Grondin, E. Fadeitchev, and V. Zarouba, “Searchable
Archive,” US Patent 7,243,110, 2007.
[22] J. K. Metzger, B. M. Zane, and F. D. Hinshaw, “Limiting Scans
of Loosely Ordered and/or Grouped Relations Using Nearly
Ordered Maps,” US Patent 6,973,452, 2005.
[23] P. Synak, “Rough Set Approach to Optimisation of Subquery
Execution in Infobright Data Warehouse,” in SCKT (PRICAI
Workshop), 2008.
[24] D. Ślȩzak, P. Synak, A. Wojna, and J. Wróblewski, “Two
Database-related Interpretations of Rough Approximations:
Data Organization and Query Execution,” Fundamenta Infor-
maticae, 2013.
[25] N. Bruno, S. Chaudhuri, and L. Gravano, “STHoles: A Multidi-
mensional Workload-Aware Histogram,” in SIGMOD, 2001, pp.
211–222.
[26] A. Rasin, S. Zdonik, O. Trajman, and S. Lawande, “Au-
tomatic Vertical-Database Design,” WO Patent Application,
2008/016877 A3, 2008.
[27] M. Charikar, C. Chekuri, T. Feder, and R. Motwani, “Incre-
mental Clustering and Dynamic Information Retrieval,” SIAM
J. Comput., vol. 33, no. 6, pp. 1417–1440, 2004.
[28] C. C. Aggarwal, Outlier Analysis. Springer, 2013.
[29] A. Deligiannakis, Y. Kotidis, V. Vassalos, V. Stoumpos, and
A. Delis, “Another Outlier Bites the Dust: Computing Mean-
ingful Aggregates in Sensor Networks,” in ICDE, 2009, pp. 988–
999.
[30] B. J. Oommen and L. G. Rueda, “The Efficiency of Histogram-
like Techniques for Database Query Optimization,” Comput. J.,
vol. 45, no. 5, pp. 494–510, 2002.
[31] L. T. Moss and S. Atre, Business Intelligence Roadmap: The
Complete Project Lifecycle for Decision-support Applications.
Addison-Wesley, 2003.
[32] S. Chaudhuri and V. R. Narasayya, “Self-Tuning Database
Systems: A Decade of Progress,” in VLDB, 2007, pp. 3–14.
[33] S. Idreos, “Cracking Big Data,” ERCIM News, vol. 2012, no. 89,
2012.
[34] G. Peters, F. Crespo, P. Lingras, and R. Weber, “Soft Clustering
– Fuzzy and Rough Approaches and Their Extensions and
Derivatives,” Int. J. Approx. Reasoning, vol. 54, no. 2, pp. 307–
322, 2013.
[35] A. K. Jain, M. N. Murty, and P. J. Flynn, “Data Clustering: A
Review,” ACM Comput. Surv., vol. 31, no. 3, pp. 264–323, 1999.
[36] C. Böhm, C. Faloutsos, and C. Plant, “Outlier-robust Clustering
using Independent Components,” in SIGMOD, 2008, pp. 185–
198.