In their hunt for highlights, i.e., interesting patterns in the data, data analysts have togirsosuupes of related queries andmanually combine their results. To the extent that the analyst's goals are based ointeanntion on what to discover (e.g., contrast a query result to peer ones, verify a pattern to a broader range of data in the data space, etc), the integration oifntentional query operators in analytical engines can enhance the eficiency of these analytical tasks. In this paper, we introduce, with well-defined semantics, tAhNeALYZE operator, a novel cube querying intentional operator that provide3s6a0 view of data. We define the semantics of an ANALYZE query as a tuple of five internal, facilitator cube queries, that (a) report on the specifics of a particular subset of the data space, which is part of the query specification, and to which we refer as thoeriginal query, (b) contrast the result with results from peer-subspaces, osribling queries, and (c) explore the data space in lower levels of granularity via drill-down queries. We introduce formal query semantics for the operator and we theoretically prove that we can obtain the exact same result by merging the facilitator cube queries into a smaller number of queries. This efectively introduces a multi-query optimization (MQO) strategy for executing an ANALYZE query. We propose three alternative algorithms, (a) a simple execution without optimizatioMnisn-(MQO), (b) a total merging of all the facilitator queries to a single onMea(x-MQO), and (c) an intermediate strategyM, id-MQO, that merges only a subset of the facilitator queries. Our experimentation demonstrates that Mid-MQO achieves consistently strong performance across several contexts, Min-MQO always follows it, and Max-MQO excels for queries where the siblings are sizable and significantly overlap.
CEUR Workshop
ISSN1613-0073 the expected results, and also, in our case, (c) optimization strategies for its eficient execution. The simplicity of a hierarchical multidimensional model facilitates a simple query operator that exploits the model’s ability to compute sibling, ancestor, and descendant values at diferent levels of coarseness smoothly. The semantics of an ANALYZE query include five internafla,cilitator cube queries. First, the operator has to deal with the information requested for a very specific subset of the data space that is obtained via (a) a set of filters and (b) a pair of groupers that are used in a GROUP-BY fashion to aggregate a measure. We call this tohreiginal query of the operator as it targets a subset of the data space of interest. Second, we want to contrast the result with similar, peer results. To this end, we use the combination of grouper and filter conditions to obtasiinbling subspaces of the data that query subspaces sharing the same ancestor values with the filters of the original query. Finally, we explore the data space in lower levels of granularity via what wdericlla-ldlown queries (very much in the traditional OLAP sense).
Apart from introducing formal query semantics for the operator, however, we have been able to theoretically prove that we can obtain the exact same result by merging the facilitator cube queries into a smaller number of merged queries that exploit cube usability results to reduce redundant computation. This theoretical result efectively allows us to introducmeualti-query optimization (MQO) strategy that merges several collaborator queries into one or more merged queries, in an attempt to speed up the execution of an ANALYZE query. In fact, we have devised several strategies of Multi-Query Optimization for merging the underlying facilitator queries into one. In the simplest case, no optimization is performed and the five facilitator queries are executed independently: we refer to thiMsains-MQO, as it introduces the least degree of query merging. Second, we follow the theoretical result and merge all the facilitator queries into a single one, a strategy that we cMaalxl-MQO, as it implements the original theoretical result of merging everything. Finally, based on our original experimental observations that identified cases of low performance for the aforementioned strategies, we also introduce an intermediate strMaitde-gy, MQO, that strikes a balance between the two extremes and merges only a subset of the facilitator queries. In all merging strategies, once the results of the merged queries are obtained, they are post-processed, such that the exact facilitator queries are populated correctly.
We have extensively evaluated the performance of each MQO strategy via various query workloads on multiple datasets, to assess both the efect of data size and query selectivity to the execution cost as well as the optimal strategy. Our experiments demonstrate thMatid-MQO is the most eficient algorithm that scales smoothly with data size and selectivity and typically achieves the best performance. Although in many casesMax-MQO has the worst performance, when the sibling queries are sizable and significantly overlap,Max-MQO is the fastest algorithm; we can predict via a decision tree when this is the case. Finally,Min-MQO is never the optimal strategy, although it folloMwisd-MQO fairly closely.
Roadmap. Section 2 reviews related work in exploratory data analysis and pattern discovery. Section 3 introduces the formal modeling background. Secti4onpresents the design and semantics of the ANALYZE operator. Section5 develops our multi-query optimization strategies. Secti6onreports our experimental evaluation. Sectio7nconcludes with a discussion of the findings and future directions. A long version of this paper, with more results, details and proofs, appear9s].at [
Automated EDA. Exploratory Data Analysis (EDA1)0[] allows data analysts to interact with dataset
management tools to gain highlights. The goal of EDA is the production of highlights, in order to find
interesting, surprising and important facts of a data subspace (likely a query result) and present them
using data narration methods1,[
Intentional Model. The Intentional Model6[
Multi-Query Optimization (MQO).[33] establishes the foundational evidence that processing
multiple queries together yields considerable cost reductions compared to independent query execution.
[34] provides one of the first formal treatments of MQO, as the task of generating an optimal execution
strategy for a set of concurrent queries by identifying and exploiting common subexpressions, shared
join paths, and reusable intermediate result3s5.][discusses a comprehensive experimental validation for
Volcano optimizers. 3[
Comparison to the State of the Art. The main contribution of this work is the formal introduction of a novel operator along with its optimization techniques. Although conceptually related, our work here does not pertain to the core of the area of multi-query optimization: our MQO algorithms do not explore alternative query execution plans, but rather exploit theoretical guarantees of correctness. Compared to the most similar line of work31[, 32], we change the query semantics to address eficiency issues (thus we face a new problem), provide formal semantics of an operator and, most importantly, we introduce multi-query optimization strategies for the speed up of query processing. Compared to the rest of the corpus of related literature, to the best of our knowledge, there is no other work with multi-query optimization strategies for a formal, single operator that provi3d6e0s aview of the data with opportunities for optimization exactly due to the integration of various queries.
the formal model of8[] (also used in [39]) for the definition of the multidimensional space, cubes, and cube queries.
Multidimensional space. Data are defined in the context of a multidimensional space. The multidimensional space includes a finite set of dimensions.
A dimension level includes a name and a finite set of values, ( ), as its domain. Following the traditional OLAP terminology, the values that belong to the domains of the levels are calledimension members, or simply members (e.g. the values Paris, Rome, Athens are members of the domain of level , and, subsequently, of dimension ℎ
). A dimension is a non-strict partial order of a finite set olefvels, obligatorily including (a) a most detailed level at the lowest possible level of coarseness and (b) an upper bound, which is called , with a single value ‘All’. To ease notation, unless explicitly mentioned otherwise, in the sequel, we will assume total orders of levels, which means that there is a linear order of the levels starting from the lower level and ending at ALL with a linear chain of precedence.
We can map the members at a lower level of coarseness to values at a higher level of coarseness via an ancestor function level value to a set odfescendant values at a lower level of coarseness and is denoted via the notation ℎ(). The inverse of an ancestor function is not a function, but a mapping of a high ℎ(). For example = Formally, the schema of a cubeℎ() (ℎ)
. See [
, is a tuple, say[ 1. 1, ..., . , 1, ..., ], or simply [ 1, ..., , 1, ..., ], with the combination of the dimension levels (each coming from a diferent dimension) acting as primary key and context for the measurements and a set of measures as placeholders for the (aggregate) measurements.
Queries. A cube query is a cube too, specified by: (a) the detailed cube over which it is imposed, (b) a selection condition that isolates the facts that qualify for further processing, (c) the grouping levels, which determine the coarseness of the result, and (d) an aggregation over some or all measures of the cube that accompanies the grouping levels in the final result. We assume selection conditions, which are conjunctions of atomic filters of the form= or, in genera l ∈ { 1, … , }.
Constraints. In the context of this work, we imply several assumptions that mainly serve the purpose of clarity. First, we work with cube queries that involve a single measure. Second, we assume strictly two aggregator levels for the result, and third, for all atomic filters, we assume that if the dimension with a filter is also a grouper, the atomic filter is expressed in a level greater than or equal to the grouper. Then, we will employ the following query expression: = < 0, , [ , , ] , ( 0) >
In this section, we introduce the ANALYZE operator in terms of semantics, syntax, and execution strategies. 4.1. Syntax & Semantics analyze for group by , as (
operator, as ( with the variables participating in the definition having the obvious semantics already introduced in To complement this SQL-like definition, we will also employ an algebraic representation of the 0, , [ . , . , ], (
0)), or equivalently as: = ⟨ 0, , [ . , . , ], ( 0) ⟩ Assume the setup already discussed in Sectio3n, with a detailed cub e 0 defined over a list of hierarchical dimensions. The syntax of the ANALYZE operator is as follows:
0) as from 0
Semantics. The semantics of the operator involve the introduction of three separate groups of intermediate cube queries, which we call facilitator queries, with each group producing a set of distinct cube query results. Assuming a given ANALYZE query , the query set of. is a triplet of query sets<
, , queries in the three query sets.
> and the result o f , . is a triplet with the results of the respective
The 3 query sets that the operator produces are as follows : (a) is a singleton set, comprising exactly one quer y , to which we will refer atshe original query, that computes the aggregate value for 0 as specified by the variables of the operator. (b ) is a set of sibling queries, whose goal is to compare the behavior of key values in the operator definition against the behavior of their peer values. (c) is a set of drill-down queries, whose goal is to provide more detailed data to the analyst for the values produced by the original query. Figu1rdeemonstrates the queries of the reference example, along with the auxiliary queries that the subsequent MQO algorithms will produce. In the sequel, we present the semantics and rationale of each of these auxiliary, facilitator queries. 4.1.1. Sibling queries Sibling queries aim to compare (a) the diferent slices of the data space that pertain to the original query against (b) their peers, in order to put them in context. By comparing data slices to their peers, the data slices are efectively assessed by the analyst and, thus, contextualized. the aggregation level.
Definition of a convenient variant for the sibling computation . A clear problem here is that if a value used in a selection atom has too many sibling values, this produces a large number of queries, even if we create siblings only for just this dimension. The problem generalizes if we take all selection atoms into consideration. To avoid this complexity, we simplify sibling generation by (i) considering siblings only for the atom s and , and (ii) by merging all sibling slices into one, by slightly adapting Given the original quer y we generate two sibling queries, each for one of the groupers as:
= ⟨ 0, ∧ ∧ □ , [ . , . , ], ( 0) ⟩
= ⟨ 0, ⋆ ∧ ∧ □ , [ . , . ,
= ⟨ 0, ∧ ⋆ ∧ □ , [ . , . , : Apart from contextualizing the result of the original query against its peers, we can also provide further details for the displayed data by drilling into the dimension hierarchies of the produced results. Ideally, this requires drilling into each of the cells of the results of the original query3–2]soene [how this was traditionally done. However, this produces a significantly large number of queries to execute. We adopt a simple solution to this problem by drilling into each of the aggregator levels, by going down one level in their hierarchy. Thus, we produce two drill down queries, each drilling a level down into the detail of one of the grouper dimensions.
Given the original quer y
= ⟨ 0, , [ . , . , we generate two drill-down queries, each for one of the groupers as: 0) ⟩ 0) ⟩
So far, we have seen that the ANALYZE operator is actually a composition of 5 facilitator queries to the underlying database. In this section, we introduce a method that replaces the need of issuing five queries to the database with a merging of (a subset of) them, along with algorithms that exploit this merging.
We base our theoretical construction on the Cube Usability Theor8e,m39[], which states that it is possible to derive the result of a cube query by filtering already accessed data by another cube query and re-aggregate them, if certain conditions are held. all-encompassing quer y is characterized by: (0) the same basic cube and measure aggregation, (1) groupers involving the highest levels of aggregation that are low enough to answer any of the internal queries of the ANALYZE operator, and (2) the broadest possible selection condition to encompass all the detailed tuples needed to answer any internal query. In the rest of this section we will first show that the all-encompassing quer y can answer all the internal queries, and, second, we will accompany the feasibility result with two algorithms that actually compute the answer.
Theorem 5.1 (Multi-Query Usability.)Assume the query:
= ⟨ 0, ∧ ∧ □ , [ . , . , producing five internal queries as prescribed in the definition of the ANALYZE operator. The following all-encompassing query can answer all the internal queries of the ANALYZE operator.
=⟨ 0, ⋆ ∧ ⋆ ∧ □ , [ −1 , −1 , ,
, , , ], (
0)⟩, with ⋆: +1 = +1 ( ) and ⋆ :
The MaxMQO Algorithm describes how to compute all facilitator queries of the ANALYZE operator with a single access to the underlying database. The algorithm takes as input the definition of the original query, which is suficient to determine the entire set of facilitator queries and to produce their results as output.
Step 1.
First, the algorithm constructs five maps, one for each of the queries that determine the ANALYZE operator. Each of these maps will store the result of the respective query. The key of the map is the combination of grouper values (which are pretty much the coordinates of each result cell), and the value is the aggregate measure that pertains to these coordinates.
Step 2. Second, the algorithm constructs and executes the all-encompassing auxiliary q uetrhyat will serve as the basis to compute all the other query results. same. We take advantage of that property to construct a single quqeMrIyD that combines the original and drill-down facilitator queries, without touching the siblings.
The Mid MQO Algorithm launches the two sibling queries along with the mer ge d query. Since the latter pertains to three facilitator queries, we group the tuples on their original and ancestor levels to distribute the result tuples. In that way, we get the tuples that contribute to the original and drill-down queries result in a single access. The rest of the processing is the same as with Max MQO. Compared toqA, qMID returns less detailed tuples and applies less groupers to them, thus reducing the result size.
In this section, we experimentally evaluate the execution time of the proposed algorithms under varying configurations of data and query workloads. In all of our experiments, we use the Delian Cubes system [40], which is a cube query answering engine, within which we have incorporated our algorithms. We have employed MySQL 8.0.34 as the underlying database. For our evaluation, the methods run on a Windows 11 2.50 GHz 14-core processor system with 32GB main memory and 1TB SSD. All the material is found at:https://github.com/DAINTINESS-Group/DelianCubeEngin. e
Experimental Goal and Evaluation Metrics. The main goal of our evaluation is to evaluate the eficiency of the alternative algorithms for executing the ANALYZE operator. Therefore, for all antagonists, we measure thTeotal Execution Time needed to fully compute the answer to an ANALYZE query, as well as its breakdown to diferent facilitators within each algorithm.
Competitor Algorithms. In our experiments, we compare the three diferent algorithms to implement the ANALYZE operator overTotal Execution Time and its breakdown. All algorithms receive as input an ANALYZE query with two groupers, a distributive aggregate function, and at least two selection conditions.Min-MQO is the algorithm that performs the least merging of the operator’s underlying cube queries. Practically, this is the plain simple execution of the operator without any optimization. Max-MQO is the algorithm that performs the maximum merging of the facilitator queries into a single facilitator query with four extra groupers to covesribtlhinegs and drill-down results, substituted selection conditions. The results are post-processed and the tuples are distributed to the correct placeholder with respect to the operator semantMicsid.-MQO is the algorithm that strikes a balance in the middle of the two extremes of full- and no- merging of the facilitator queries into one. Specifically, the algorithm constructs three facilitator queries: (i) tswiboling queries, one for each grouping dimension, and, (ii) a mergeodriginal-n-drill-down multi-query which is a combination of the original anddrill-down queries.
Datasets We have employed the datasets listed below to perform our evaluation. Specifically, these datasets are: (iN)orthwind [41], which is a synthetic dataset that represents the sales and the operations of a food import/export company, (ii)Foodmart, which is a cubefied version of Foodmart [42], which contains synthetic data regarding the sales activity of a retail supermarkept,k(diidi9)9+, which is an upscaled version opfkdd99 [43], a financial dataset that contains data about loans and transactions, for which we have created a fact table that contains 100 million entries, andT,P(iCv)-DS [44], which is an industry standard benchmark designed to evaluate the performance of analytical platforms. We have tested the scalability of our algorithms over three versionTsPCof-DS with scale factor 1, 3.5, and, 35. As Delian Cubes operates over data cubes, we do not directly utilize the raw schema of the datasets, but rather adapt it to a cubefied, clean, star-schema version, in order to support hierarchies and cube queries.
(a) TPC-DS 2M Item Workload (b) TPC-DS 10M Item Workload (c) TPC-DS 100M Item Workload (d) TPC-DS 2M Item Workload Fa- (e) TPC-DS 10M Item Workload cilitator Queries Breakdown Facilitator Queries Breakdown (f) TPC-DS 100M Item Workload
Facilitator Queries Breakdown (g) TPC-DS 2M Time Workload (h) TPC-DS 10M Time Workload (i) TPC-DS 100M Time Workload (j) TPC-DS 2M Time Workload Fa- (k) TPC-DS 10M Time Workload cilitator Queries Breakdown Facilitator Queries Breakdown (l)TPC-DS 100M Time Workload
Facilitator Queries Breakdown (m) Northwind Workload (n) Foodmart Time Workload (o) pkdd99+ Time Workload
To assess the operator with diferent selectivities over the fact tables, for each data set, we use a workload of 10 queries where we (a) vary with the various levels of filters/groupers, and (b) employ one large and one small dimension table. For the TPC-DS dataset, and in order to also evaluate the efect of dimension table size, we use two query workloads, both involving the lDaratgee dimension: (i) a workload using the larTgieme dimension table, and (b) a workload using the small Item dimension table. In all workloads, as the QueryID increases, the selectivi ty oaflso increases in all data sets.
Performance Evaluation. Figures2a, 2b, and2c illustrate theItem query workload execution time across all methods for each TPC-DS dataset size variation. Min-MQO shown as a dark blue line, MidMQO as a blue line, Max-MQO as a light blue line. The dimension tables involved in the workload are theDate dimension (≈80000 tuples) and theItem dimension (≈ 20000 tuples). We observe the following: (i) Regardless of the dataset size, Mid-MQO performs the best, (ii) Max-MQO constantly performs the worst, especially when the selectivity ratio is increasing, and (iii) Min-MQO and Mid-MQO do not difer significantly in their execution time. Figures2d,2e,2f provide the detailed execution time for each facilitator query of the workload’s ANALYZE queries. We observe that the drill-down queries that Mid-MQO does not execute in comparison to Min-MQO, are not as significant for the total execution time. Thus, the diference in performance in Min-MQO and Mid-MQO is relatively small. Max-MQO processes a large number of tuples compared to the other antagonists and, in that context, underperforms constantly. TPC-DS dataset size variation. The dimension tables involved in the workload arDeattheedimension (≈80000 tuples) and theTime dimension (≈ 70000 tuples). We observe the following: (i) In the TPC-DS 2M, Max-MQO outperforms the other algorithms and Min-MQO is the worst performing algorithm in every case, (ii) in the TPC-DS 10M and 100M, in small selectivity ratios, Max-MQO performance is almost stable regarding the selectivity ratio increase, while Min-MQO’s and Mid-MQO’s performance deteriorates as the selectivity ratio increases. Here, due to the large size of both dimension tables, the performance of Max-MQO is stable, as it consistently explores a large subset of the fact table once, and avoids the heavy extra cost of siblings of the other algorithms when the selectivity increases (see
Finally, when comparing the algorithms over the 3 other datasets (Fig2umr,e2n, 2o) we observe: (i) in the Northwind workload that involves two small dimension tab≈l9e0s (tuples and≈9 tuples), Mid-MQO constantly scores wins against the other antagonists, while Max-MQO is underperforming, (ii) in the Foodmart workload that involves unbalanced dimension tab≈l1e0s0(00 tuples and≈1000 tuples), Max-MQO is the fastest algorithm, while Min-MQO is the slowest, (iii) in the pkdd99+ workload that involves one fairly large and one small dimens≈io3n00(00 tuples and≈5000), Mid-MQO outperforms its antagonists in the high selectivity ratios, while Max-MQO performs better in low selectivity ratios.
We have also conducted extensive experiments over the number of atomic filters, the level of groupers etc, not reported here for lack of space, but not significantly afecting performance in the same extent as the selectivity and the data size9][.
Choosing algorithms.
Mid-MQO is a safe choice as a query processing strategy, as it is both stable and wins most of the time. Can we do better than this first result, though? We have analyzed the entire corpus of 70 workloads of the large TPC-DS and pkdd99+ datasets (7 workloads of 10 queries each) to precisely detect when each query processing strategy wins, via easily computable cost measures. Ultimately (Figure3), Max-MQO wins when (a) the siblings touch a fairly large number of fact tuples compared to the all-encompassing query (more than 40%), and, (b) there is a fairly small imbalance between the sibling queries (less than 45%). In all other cases, Mid-MQO wins. The rationale is simple: (1) when is too large compared to the facilitator queries, then, it explores too much of the data space, hence Max-MQO loses; (2) when the siblings are both sizable and imbalanced, they do not significantly overlap, thus Max-MQO, visiting them once, does not save time. The only case where Max-MQO saves time is if sizable siblings overlap (estimated via the imbalance coeficient). Naturally, the exact thresholds are an engineering default, subject to wider evaluation over time, however, the rationale is consistent with the theoretical setup of .
The paper introduces ANALYZE, a novel intentional cube query operator that provides a 360° view of the data by combining original, sibling, and drill-down queries in a single invocation with formal semantics. We have shown that the operator’s internal queries can be safely merged with theoretical correctness guarantees, enabling principled multi-query optimization at the operator level without modifying the underlying query optimizer. We have introduced, implemented in a data analytics system, and extensively evaluated three execution strategies, demonstrating that partial merging (Mid-MQO) delivers robust and scalable performance across workloads, full merging (Max-MQO) is beneficial only when the siblings are sizable and significantly overlap, while the not-optimized strategy (Min-MQO) is consistently suboptimal.
Right now, a plain DBMS would simply execute Min-MQO to process the set of facilitator queries of the operator. A lesson learned here is that the external data analytics ecanngionpetimize query execution outside the DBMS. This is a lesson to be applied to future intentional operators as well (PREDICT, EXPLAIN, etc). Exploiting the formal, algebraic nature of the operator also raises the question of integrating it with cost-based DBMS optimizers or platforms like Apache Spark. Relaxing some of the constraints (e.g., via more groupers, siblings based on user-defined or context-dependent benchmarks [45, 46]) is also open to research.
The research project is implemented in the framework of H.F.R.I call “3rd Call for H.F.R.I.’s Research Projects to Support Faculty Members & Researchers” (H.F.R.I. Project Number: 23640).
D. Gkitsakis helped with early, trial versions of the code.
PLORER: exploring very large data with interactive deep reinforcement learning, in: CIKM ’21: The 30th ACM International Conference on Information and Knowledge Management, Virtual Event, Queensland, Australia, November 1 - 5, 2021, 2021, pp. 4769–4773. [18] D. Shi, X. Xu, F. Sun, Y. Shi, N. Cao, Calliope: Automatic visual data story generation from a spreadsheet, IEEE Trans. Vis. Comput. Graph. 27 (2021) 453–463. [19] T. D. Bie, L. D. Raedt, J. Hernández-Orallo, H. H. Hoos, P. Smyth, C. K. I. Williams, Automating data science, Commun. ACM 65 (2022) 76–87. [20] S. Amer-Yahia, P. Marcel, V. Peralta, Data narration for the people: Challenges and opportunities, in: Proceedings 26th International Conference on Extending Database Technology, EDBT 2023, Ioannina, Greece, March 28-31, 2023, OpenProceedings.org, 2023, pp. 855–858. [21] M. Sun, L. Cai, W. Cui, Y. Wu, Y. Shi, N. Cao, Erato: Cooperative data story editing via fact interpolation, IEEE Trans. Vis. Comput. Graph. 29 (2023) 983–993. [22] H. Li, L. Ying, H. Zhang, Y. Wu, H. Qu, Y. Wang, Notable: On-the-fly assistant for data storytelling in computational notebooks, in: CHI, 2023. [23] P. Ma, R. Ding, S. Wang, S. Han, D. Zhang, Insightpilot: An llm-empowered automated data exploration system, in: EMNLP’2023, 2023. [24] S. Amer-Yahia, Intelligent agents for data exploration, Proc. VLDB Endow. 17 (2024) 4521–4530. [25] J. Xing, X. Wang, H. V. Jagadish, Data-driven insight synthesis for multi-dimensional data, VLDB
Endow. 17 (2024) 1007–1019. [26] T. Lipman, T. Milo, A. Somech, T. Wolfson, O. Zafar, LINX: A language driven generative system for goal-oriented automated data exploration, in: Proceedings 28th International Conference on Extending Database Technology, EDBT 2025, Barcelona, Spain, March 25-28, 2025, OpenProceedings.org, 2025, pp. 270–283. [27] M. Francia, M. Golfarelli, P. Marcel, S. Rizzi, P. Vassiliadis, Suggesting assess queries for interactive analysis of multidimensional data, IEEE Trans. Knowl. Data Eng. 35 (2023) 6421–6434. [28] M. Francia, M. Golfarelli, P. Marcel, S. Rizzi, P. Vassiliadis, Assess queries for interactive analysis of data cubes, in: Proceedings of the 24th International Conference on Extending Database Technology, EDBT 2021, Nicosia, Cyprus, March 23 - 26, 2021, 2021, pp. 121–132. [29] M. Francia, P. Marcel, V. Peralta, S. Rizzi, Enhancing cubes with models to describe multidimensional data, Inf. Syst. Frontiers 24 (2022) 31–48. [30] M. Francia, S. Rizzi, P. Marcel, Explaining cube measures through intentional analytics, Inf. Syst.
121 (2024) 102338. [31] D. Gkesoulis, P. Vassiliadis, Cinecubes: cubes as movie stars with little efort, in: Proceedings of the sixteenth international workshop on Data warehousing and OLAP, DOLAP 2013, San Francisco, CA, USA, October 28, 2013, 2013, pp. 3–10. [32] D. Gkesoulis, P. Vassiliadis, P. Manousis, Cinecubes: Aiding data workers gain insights from OLAP queries, Inf. Syst. 53 (2015) 60–86. [33] T. K. Sellis, Multiple-query optimization, ACM Trans. Database Syst. 13 (1988) 23–52. [34] T. K. Sellis, S. Ghosh, On the multiple-query optimization problem, IEEE Trans. Knowl. Data Eng.
2 (1990) 262–266. [35] P. Roy, S. Sudarshan, Multi-query optimization, in: Encyclopedia of Database Systems, Springer
US, 2009, pp. 1849–1852. [36] M. Hong, M. Riedewald, C. Koch, J. Gehrke, A. J. Demers, Rule-based multi-query optimization, in: EDBT 2009, 12th International Conference on Extending Database Technology, Saint Petersburg, Russia, March 24-26, 2009, Proceedings, 2009, pp. 120–131. [37] W. Le, A. Kementsietsidis, S. Duan, F. Li, Scalable multi-query optimization for SPARQL, in: IEEE 28th International Conference on Data Engineering (ICDE 2012), Washington, DC, USA (Arlington, Virginia), 1-5 April, 2012, 2012, pp. 666–677. [38] T. Kathuria, S. Sudarshan, Greedy awakens : Eficient and provable multi-query optimization,
CoRR abs/1512.02568 (2015). [39] P. Vassiliadis, Cube query answering via the results of previous cube queries, in: Proceedings of the 25th International Workshop on Design, Optimization, Languages and Analytical Processing of Big Data (DOLAP) co-located with the 26th International Conference on Extending Database Technology and the 26th International Conference on Database Theory (EDBT/ICDT 2023), Ioannina, Greece, March 28, 2023, CEUR-WS.org, 2023, pp. 71–75. [40] Delian Cubesh,ttps://github.com/DAINTINESS-Group/DelianCubeEngin, e2025. DAINTINESS
GROUP University of Ioannina. [41] Microsoft, Northwind, https://github.com/microsoft/sql-server-samples/tree/master/samples/ databases/northwind-pub,s2023. Accessed: 2025-09-14. [42] J. Hyde, Foodmart,https://github.com/julianhyde/foodmart-data-hsql,d2b025. Accessed: 2025-0724. [43] N. Zhong, Y. Yao, S. Ohsuga, Peculiarity oriented multi-database mining, in: Principles of Data Mining and Knowledge Discovery, Third European Conference, PKDD ’99, Prague, Czech Republic, September 15-18, 1999, Proceedings, volume 1704 oLfecture Notes in Computer Science, Springer, 1999, pp. 136–146. [44] TPC, Tpc-ds, https://www.tpc.org/tpcds/, 2024. Accessed: 2025-06-05. [45] K. Stefanidis, E. Pitoura, P. Vassiliadis, A context-aware preference database system, Int. J.
Pervasive Comput. Commun. 3 (2007) 439–460. [46] P. Mateos, A. Bellogín, A systematic literature review of recent advances on context-aware recommender systems, Artif. Intell. Rev. 58 (2025) 20.