Bespoke OLAP: Tailored Data Warehousing

• Bespoke OLAP is a specialized analytical approach that customizes data warehouses, schemas, queries, and visualizations to match user profiles and fixed workloads.
• It integrates personalization methods, from user-driven materialized views to intent-based query models, enhancing both relevance and speed.
• Workload-specific engine synthesis in bespoke OLAP has demonstrated significant performance gains, achieving up to 16× per-query speedup in benchmark tests.

Bespoke OLAP denotes a family of OLAP and data-warehouse approaches that reject the “one fits all” assumption and instead tailor analytical processing to a specific user, profile, analytic intention, data representation, or fixed workload. In the literature, this tailoring appears in several forms: user-profile-driven warehouse summaries implemented as personalized materialized views; schema, query, and visualization adaptation; XML-native and Semantic Web OLAP formalisms; intention-driven analytics that return models and highlights rather than only tuples; interactive worksheet systems that compile direct manipulation into SQL; and fully synthesized “one-size-fits-one” analytical engines specialized to a given workload (Khemiri et al., 2013, Aissi et al., 2012, Vassiliadis et al., 2018, Wehrstein et al., 2 Mar 2026).

1. Conceptual scope and research lines

A central motivation for bespoke OLAP is that multidimensional queries often return huge result sets, large amounts of irrelevant information, or require expensive exploratory navigation. Survey work therefore frames OLAP personalization as a mechanism for “quick access to relevant information by eliminating all irrelevant information tailored to the needs, behaviors and user preferences,” and distinguishes two broad orientations: DW adaptation approaches, which adapt the system to the user, and DW recommendation approaches, which recommend the next OLAP action or query (Aissi et al., 2012). A related survey places these ideas within user-centric data warehouses, defining personalization as system adaptation to a user’s needs, preferences, and characteristics, and recommendation as proactive suggestion of partial or complete analytical queries based on prior behavior, context, or similar users (Ahmed et al., 2011).

Later work broadens this scope beyond classical profile-based personalization. The Intentional Analytics Model redefines OLAP queries around high-level intentions—describe, assess, explain, predict, and suggest—rather than around only roll-up, drill-down, slice, and dice (Vassiliadis et al., 2018). At the systems end of the spectrum, "Bespoke OLAP" defines a workload-specific analytical engine as a “one-size-fits-one” artifact generated from a fixed workload specification and dataset, rather than as a configurable instance of a general-purpose DBMS (Wehrstein et al., 2 Mar 2026). This suggests that bespoke OLAP is not a single architecture but a design stance: specialization replaces universal analytical behavior wherever the workload contract, user model, or representation makes that practical.

2. User-profile-driven warehouse summaries

One of the clearest user-centric forms of bespoke OLAP is the user profile-driven data warehouse summary. In this model, a user profile is not merely an identifier; it is the pair (user identity, user hard preferences), while soft preferences are inferred from the current query. Preferences are qualitative predicates over dimension attributes, such as Car.year > 2007 or Advertisement.region = 'Rhone-Alpes', rather than numeric scoring functions. Formally, a warehouse schema is written as $DW(F, D_1, D_2, \dots, D_n)$, a preference on a dimension is a triple $(Pred, operator, value)$, and the personalized warehouse materialized view is defined as the join of the preference-filtered dimension vectors, conceptually $VDW = \bowtie(Vep1, Vep2, \dots, Vepm)$ (Khemiri et al., 2013).

The architecture is explicitly split into a front-end and a back-end, supported by a user profile database (UP DB) and a user profile materialized view database (UPV DB). The workflow is offline-first. When a beginner user logs in for the first time, or when an existing user changes preferences, the system records the profile in the UP DB and computes that user’s personalized materialized view offline. Later queries are then answered over the personalized view rather than over the whole warehouse. In the motivating car-sales example, predicates such as “year > 2007,” “price < 20000,” “color = black,” and “region = Rhone-Alpes” are first applied to the relevant dimensions, after which the filtered fragments are joined back with the fact table to form a user-specific data warehouse materialized view. The implementation described uses Java in the NetBeans environment on top of SQL Server 2005, and the authors mention the FoodMart warehouse as an example schema (Khemiri et al., 2013).

The intended benefits are improved response time and improved relevance, because much of the filtering is pushed offline into view construction and the online query phase works on a reduced view. The approach is also optional: the interface includes a control for turning personalization on or off, and the paper notes the risk of over-personalization if too much warehouse content is hidden. Its principal limitation is the cost of maintaining one materialized view per user, especially when the user population is large or preferences change frequently; group-based profiles are proposed as a possible mitigation. Survey work places this strategy within schema adaptation and summarizes the same distinction as rigid preferences versus flexible preferences, where the materialized view reflects the rigid ones and the flexible ones are applied at query time (Aissi et al., 2012).

3. Tailored multidimensional models, algebra, and closure

A second line of bespoke OLAP work tailors the multidimensional formalism itself. One paper asks “How deep is the multidimensional ability of each fact table in a data warehouse?” and answers by using combination theory to count possible dimension combinations and report layouts. It states that the minimum number of dimensions is 1, the maximum equals the number of fact-table columns excluding the measure column, and uses the standard combination formula

${}^{n}C_{r} = \frac{n!}{r!(n-r)!}$

together with a deployed formula $n * n-1. C_{r-1}$ to enumerate possible analytical report/graphic combinations. In the three-dimension example with dimensions $A$, $B$, and $C$, the paper presents a total of 12 combinations, emphasizing that meaningful OLAP report layouts follow combination logic rather than pure permutation logic (Warnars, 2010).

A more structural response is the conceptual multidimensional design based on constellations of facts and dimensions. In that model, a constellation schema is

$SOM = (sname, FACT, DIM, Paramsname),$

facts are measurable analysis subjects, dimensions may be shared across several facts, and each dimension may contain multiple hierarchies. The model therefore goes beyond the classic single-fact star schema. The example constellation channalyse contains facts such as SALE and PURCHASE, and dimensions such as SHOP, PAYMENT, SALE_PERSON, DATE, PRODUCT, and STOCK. The associated algebra includes standard operators such as Slice, Dice, RollUp, and DrillDown, but also constellation-specific or restructuring operators such as DRotate, HRotate, FRotate, Switch, Push, Pull, TSplit, and Split. The prototype GEDOOH, implemented in Java (jdk 1.3) on top of Oracle and described as about 8000 lines of Java, provides a graphical interface, an automatic data warehouse generator, an automatic data mart generator, and a query translator that converts multidimensional operators into relational queries (Teste, 2010).

Personalization can also be embedded directly into the multidimensional model. In the annotated-OLAP approach, the personalized constellation is

$$CP = (F; D; Star_{CP}; Preference_{CP}; Annotate_{CP}),$$

and the current OLAP state is captured by an analysis context

$(Pred, operator, value)$0

Preferences may be absolute or contextual, annotations may be global or local, and the recommendation process selects candidate preferences whose preference context is covered by the current analysis context. The resulting recommended contexts are displayed together with the annotations relevant to them, so bespoke OLAP is not only preference-based filtering but also reuse of prior decision-maker expertise (Jerbi et al., 2010).

A further generalization is the hierarchical datacube, which makes hierarchical dimensions first-class rather than implicit. The paper defines the hierarchical cube lattice as

$(Pred, operator, value)$1

introduces a closure operator $(Pred, operator, value)$2, and defines the closed hierarchical datacube as the most concise reduced representation. The main claim is that hierarchically correlated data produce many redundant cube tuples, and that closure eliminates these redundancies while preserving analytical meaning. Reported storage reductions range from 8 to more than 300 times on datasets such as Death, TombNecropolis, Joint_Objects_Tombs (1%), Mushroom (5%), and TombObjects (Nevot et al., 7 Jan 2025).

4. XML and Semantic Web realizations

Bespoke OLAP also appears when the data model itself departs from the relational warehouse. In XML warehousing, the need is for XML-OLAP or XOLAP, because XML data are tree- or graph-structured, can exhibit heterogeneous facts, ragged hierarchies, missing information, and complex measures, and are therefore not adequately served by relationally grounded OLAP alone. One unified XML warehouse architecture adopts one single XML document for facts and one XML document per dimension, together with dw-model.xml for metadata, facts.xml for fact instances, and dimensiona.xml for dimension instances and hierarchy levels. The paper argues that this organization naturally supports constellation schemas, avoids dimension duplication, and simplifies dimension updates (Mahboubi et al., 2017).

For XML-native operator semantics, one line of work expresses nine common OLAP operators in the TAX XML algebra: rotate, switch, push, pull, slice, dice, roll-up, drill-down, and cube. The operators are defined compositionally from TAX primitives such as selection $(Pred, operator, value)$3, projection $(Pred, operator, value)$4, reordering $(Pred, operator, value)$5, copy-and-paste $(Pred, operator, value)$6, grouping $(Pred, operator, value)$7, join $(Pred, operator, value)$8, aggregation $(Pred, operator, value)$9, deletion $VDW = \bowtie(Vep1, Vep2, \dots, Vepm)$0, and insertion $VDW = \bowtie(Vep1, Vep2, \dots, Vepm)$1. The prototype described generates XQuery from the XOLAP algebra and, at the reported stage, supports rotate, slice, and roll-up on the TIMBER XML-native DBMS (0809.2691).

On the Semantic Web, a comparable specialization is achieved by defining OLAP over the cube as the primary conceptual object and then mapping it to QB4OLAP, an extension of the W3C RDF Data Cube Vocabulary. In this framework, a cube instance is a lattice of cuboids, roll-up and drill-down are defined conceptually over cuboids and levels rather than over RDF syntax, and QB4OLAP adds metadata such as qb4o:LevelProperty, qb4o:Hierarchy, qb4o:HierarchyStep, qb4o:RollupProperty, and qb4o:aggregateFunction. SPARQL implementations use an inner SELECT query to compute groupings and aggregates and an outer CONSTRUCT query to materialize the resulting cuboid graph (Etcheverry et al., 2015).

The same Semantic Web line introduces CQL (Cube Query Language) as a simple, high-level query language whose only data type is the cube. CQL queries are translated into SPARQL using QB4OLAP metadata and improved through optimization strategies such as named graphs, replacement of equality FILTERs with basic graph patterns, rewriting of disjunctive filters, and selectivity-aware triple-pattern ordering. In the reported evaluation on SSB-QB4OLAP, the naive translation reaches 69.5 QphH, while the best improved scenario ES11 reaches 721.0 QphH; the paper also reports that even the naive CQL-to-SPARQL translation is about 2x better than SSB-QB at 34.7 QphH (Etcheverry et al., 2017).

5. Intent-driven and interactive bespoke analytics

A different interpretation of bespoke OLAP shifts tailoring from schema or storage to analytical intention. The Intentional Analytics Model (IAM) replaces low-level navigation commands with five intentional operators—describe, assess, explain, predict, and suggest—and redefines the query answer as an enhanced cube

$VDW = \bowtie(Vep1, Vep2, \dots, Vepm)$2

where $VDW = \bowtie(Vep1, Vep2, \dots, Vepm)$3 is a cube, $VDW = \bowtie(Vep1, Vep2, \dots, Vepm)$4 is a set of models, and $VDW = \bowtie(Vep1, Vep2, \dots, Vepm)$5 is a set of highlights. Execution proceeds through data acquisition, model construction, highlight selection, and packaging. A key unifying idea is that all models are annotations of the original data via a bijection between cube cells and model-component elements, and the highlight mechanism uses a subjective interestingness or surprise measure relative to prior visible results. In one example, the paper reports top-5 component average surprise = $VDW = \bowtie(Vep1, Vep2, \dots, Vepm)$6 and outlier component average surprise = $VDW = \bowtie(Vep1, Vep2, \dots, Vepm)$7, so the outlier component is highlighted (Vassiliadis et al., 2018).

Interactive systems can also provide bespoke OLAP by tailoring the query-construction environment rather than the warehouse itself. Sigma Worksheet uses a spreadsheet-like, direct-manipulation interface with levels, columns/formulas, and filters, and compiles user interactions into SQL executed directly on cloud data warehouses. Levels behave like a multidimensional ROLLUP; cross-level formulas support calculations such as percent-of-total; filters include include/exclude lists, ranges, rank limits, text match, and arbitrary Boolean expressions; and the compiler translates the worksheet specification through a calculation graph and Worksheet Algebra into relational operators and SQL. The paper reports that Worksheet can express 20 out of 22 TPC-H queries, with worksheet-generated SQL comparable to reference SQL in 18 of 20 supported queries, an average slowdown of 8.3% slower at SF1000 and 0.4% faster at SF1, and major outliers for Q7 and Q19. Deployment feedback comes from a 100-person survey followed by 70 semi-structured interviews, which found that Worksheet was easier to use and learn and improved user productivity (Gale et al., 2020).

These two lines suggest that bespoke OLAP need not mean only precomputed personalized slices. It can also mean that the system accepts higher-level goals, packages models with data, or provides a direct-manipulation environment that infers query structure dynamically.

6. Workload-specific engine synthesis and execution architecture

The most aggressive interpretation of bespoke OLAP is to specialize not only the query result or interaction model, but the DBMS itself. "Bespoke OLAP" argues that even highly optimized analytical systems pay a structural overhead because they must support arbitrary schemas, arbitrary valid queries, runtime schema interpretation, indirection layers, and fallback code paths. Its answer is a fully autonomous synthesis pipeline that generates a workload-specific engine from a DBMS contract consisting of a workload specification—schema, query templates, and parameter ranges—and a dataset supplied as Parquet files. The pipeline performs storage layout planning first, then generates a functional engine, adds tracing and benchmarking support, and enters a four-round optimization loop consisting of empirical planning with sample cardinalities, self-profiling, expert knowledge injection, and an expert-engineer review. Correctness is established against DuckDB across many parameter instantiations, regressions are rolled back, and no classical optimizer cost model is used; design choices are refined empirically from measured runtimes. The synthesized components span storage and layout, query-support data structures, scan and filter strategies, join operators, aggregation strategies, and low-level code generation, including __restrict aliasing hints, branchless range checks, __builtin_expect, manual loop unrolling, and software prefetching. On TPC-H SF20, the reported runtime is 4.6 s for Bespoke-TPCH versus 54.4 s for DuckDB, or 11.78× speedup; on CEB SF2, it is 2.3 s versus 22.1 s, or 9.76× speedup. The paper also reports 16.40× median per-query speedup on TPC-H, 4.66× on CEB, synthesis costs of $VDW = \bowtie(Vep1, Vep2, \dots, Vepm)$8124.64, and wall-clock synthesis times of 6–12 hours. Its stated constraints are equally explicit: in-memory only, single-threaded, workload-fixed contract, C++ target language, and a fallback engine for unsupported ad hoc queries (Wehrstein et al., 2 Mar 2026).

This engine-synthesis perspective is distinct from, but related to, general-purpose efforts to tighten OLTP–OLAP integration. L-Store, for example, is a single unified engine with a lineage-based storage architecture built from read-optimized base pages and append-only tail pages, a lazy asynchronous merge, and transactionally consistent querying over current and historic data without ETL lag. Its objective is a unified engine for fresh analytics and history retention, rather than a workload-specific one-size-fits-one artifact (Sadoghi et al., 2016). The contrast clarifies an important boundary: some bespoke OLAP research specializes the analytical experience or logical model, while the latest work specializes the execution engine itself.