1. Introduction and motivation
the context of complex application domains, data-driven
analysis is poorly feasible since the data collection
proThe growing availability of data combined to advances cess could become a too wide task. In the context of
in computational algorithms and statistical modelling is agro-ecology for instance, social, economic, agronomic,
profoundly changing the practice of research on complex and meteorological data can be relevant in theory, but
phenomena. Business Intelligence (BI) tools play a key collecting them all in advance might be an overwhelming
role in this evolution by enabling the exploration of huge task. Solving this problem requires flexible BI tools that
volumes of data. They benefit from a growing demand allow researchers to incorporate new data on-demand,
for these tools in new fields such as agro-ecology. The whenever they need to test their hypotheses.
purpose of agro-ecology is to develop new farming prac- In the Big Data era, traditional database systems have
tices that respect the environment while maintaining evolved into complex data platforms supporting
end-toproductivity and biodiversity [
1
]. Agro-ecology involves end data-intensive needs, such as storage, computation,
governmental, economic, social, and environmental data and analysis of NoSQL data with heterogeneous
strucand actors. Traditionally, research in agroecology used tures. In particular, DBMSs that can handle diferent
the so-called “hypothesis-driven” process, which consists kinds of data, such as polyglot databases [
3
], have been
in eliciting all the data needed to challenge a testable hy- introduced to better deal with the diferent V features that
pothesis at design time. When some data are not available characterize Big Data, in particular Variety. In the same
(for any reason), then they are excluded from the ana- direction, multi-model databases (MMDBs) have been
relytical process. Recently, with the advent of Big Data, cently proposed to natively support storing and querying
“data-driven” analysis [
2
] has been emerging as an alterna- data in diferent models (graph-based, document-based,
tive that allows deriving knowledge from data that were relational, etc.), which are often schemaless [
4
].
not identified or available at design time. However, in Data Warehouses (DW) also belong to this picture.
ToDataPlat’23: 2nd International Workshop on Data Platform Design, gether with OLAP systems, they are widely recognized
Management, and Optimization, March 28, 2023, Ioannina, Greece as main citizens of BI, as they enable interactive analyses
* Corresponding author. of huge multidimensional cubes. While cubes are
tradi$ fagnine-alassane.coulibaly@inrae.fr (F. A. Coulibaly); tionally stored in relational databases, NoSQL databases
sandro.bimonte@inrae.fr (S. Bimonte); stefano.rizzi@unibo.it are now used as well to this purpose. MMDBs have been
(fSre.dReirzizci.)f;asbyrlev@iei.nmraalee.mfrb(Fic.-Fmaabhree)r@inrae.fr (S. Malembic-Maher); also found to represent a suitable solution to enhance
0000-0003-1727-6954 (S. Bimonte); 0000-0002-4617-217X lfexibility in DWs; in fact, some very recent works
inves(S. Rizzi) tigate the usage of MMDBs for storing multidimensional
© 2023 Copyright for this paper by its authors. Use permitted under Creative Commons License data [
5, 6, 7
]. We presented in [
5
] an extension of the
clasCPWrEooUrckReshdoinpgs IhStpN:/c1e6u1r3-w-0s.o7r3g ACttEribUutRion W4.0oInrtekrnsahtioonpal (PCCroBYce4.0e).dings (CEUR-WS.org)
data
collected at
design time
DW
OLAP
data
collected at
design time
(MM)
DW
OLAP
n& .l
g p
ise im
d
time
time
data
collected at additional
design time data
sical, relational star schema with factual and dimensional
data stored via the document-based, graph-based, and
key-value models, and we discussed the corresponding
design guidelines in [
7
]. We claimed that multi-model
DWs (MMDWs) simplify the Extraction, Transformation,
and Loading (ETL) process, preserve the performances
of OLAP queries, and encourage flexibility,
extensibility, and evolvability. We proposed a UML profile for
designing multidimensional models supporting variety
in [
6
]; this profile supports type variability, complex
objects, and extensibility for both dimensional and factual
data. Specifically, extensibility refers to the possibility of
adding new multidimensional elements to the MMDW
that were unavailable or unknown at design time, so they
can be used for future OLAP analysis. Such extensibility
feature appears to be crucial when analyzing complex
phenomena, as previously said for agro-ecology.
Figure 1 depicts two possible scenarios to provide
extensibility in a DW. In the first one, following a classical
schema-on-write approach where all source data are put
into multidimensional form following a schema agreed
at design time, the DW cannot be extended on-demand;
thus, design and implementation must be redone in order
data
collected at additional
design time data
DW'
OLAP (MM) DW' OLAP
to include additional data. This is impractical and
timeconsuming; in fact, a user-driven integration of new data
in the DW should be easy and fast, requiring no
intervention by designers and IT people. Thus, we envision a
second scenario where a MMDW is used for storage and a
schema on-read approach —which leaves data unchanged
in their structure until they are accessed by the user [
8
]—
is followed for OLAP queries. Here, decision-makers can
launch OLAP queries over new multidimensional data
on-the-fly, so no design and implementation iteration is
required.
In this vision paper we investigate the schema-on-read
scenario to extensible DWs by proposing an architecture
to support it (Section 3) and discussing the main open
issues associated (Section 4), using as a running example
a real agro-ecological case study taken from the BEYOND
project (Section 2). The paper is concluded by Section 5.
2. Case study
The BEYOND project (https://www6.inrae.fr/beyond/)
aims at developing new indicators of plant disease risks in
order to improve monitoring and prophylaxis strategies.
A specific goal of this project is the monitoring of
lfavescence dorée , an highly contagious quarantine
disease threatening European vineyards [
9
]. Annual
vineyard surveys inform the infectious status of plants. These
historical data are gathered and analyzed using a DW
in order to (i) understand the spatial and temporal
dynamics of the disease, (ii) investigate the field and
landscape factors that can (un)foster its propagation [
10
],
(iii) better organize the observations tasks, and (iv)
provide farmers with easily understandable indicators. The
conceptual schema of the INFECTION multidimensional
cube used to this end is shown in Figure 2 by means
of the V-ICSOLAP profile [
6
]. It presents two
measures, namely, the surface area surveyed (areaInHa)
and the number of plants infected by flavescence dorée
(numberInfectedWines), and four dimensions: a spatial
Plot dimension, the temporal one, the winegrower one,
and the team of professional organizations in charge of
the detection of flavescence dorée .
The INFECTION cube has been designed taking into
account both the requirements expressed by
stakeholders and researchers and the available data. It presents
two main issues. First of all, additional data are needed:
the current dimensions and measures cannot be used to
deeply understand the factors underlying disease spread.
Thus, the multidimensional schema shows some extensi
bility points, i.e., parts of the schema where we expect that
additional data will be available (the fact can be extended
in terms of measures and dimensions, and new levels can
be added to both the plot and the team dimensions; see
the Extensibility properties in red in Figure 2). Secondly,
In this section we describe the architecture we envision for extensible DW. As shown in Figure 3, it is composed of the following layers:
Data lake, where all data ingested are stored in their
native formats (relational, document, graph, etc.). This
layer is used to feed the next layer and can be defined as
a data lake [
11
] since it will allow users to explore the
source data as well as to extract/store the additional data
to be loaded on-demand in the next layer.
Multi-model data warehouse, in charge of storing
the warehoused data. An MMDW is used here because,
as argued in [
6
], the extensibility points of the
multidimensional schema can be easily implemented using the
schemaless data structures allowed by MMDWs. As a
result, when new data are fed to these points, no efort to
adapt the DW schema is required for their inclusion in
the data involved are too complex to be seamlessly inte- the decision-making process, and the efort for evolving
grated into a classical relational DW. On the one hand, the ETL is small. This layer is also in charge of hosting
they come with variability; indeed, attributes names and the additional data that the user selects from the source
types can change over time while maintaining the same layer to discover new multidimensional elements and
meaning (e.g., measure numberInfectedWines can also be enhance the decision-making process.
called numberInfectedPlants, in green), the same for data OLAP, where users not only formulate
multidimenstructures. On the other hand, these data follow diferent sional queries and visualize the results, but can also select
models (documents for spatial data, relational tables for additional data to be loaded and drive the process that
contaminated plants campaigns, graphs for winegrowers, discovers new multidimensional elements.
etc.), as in level Geo of the plot dimensions (in blue). In our case study, the fact table in the MMDW layer is
fed, via ETL, from a JSON collection stored in the data
lake layer and including measurements of the number
3. Envisioned architecture of infected wines. Assume that, starting from today, the
JSON documents sent from some plots will also include
some additional fields storing variables measured by
sensors (e.g. automatic detection of the insect vector of
lfavescence dorée phytoplasma, Scaphoideus titanus). The
fact has been defined as extensible, thus, the fact table
comes with a JSON attribute that can store these new
measures, with no efort to evolve the ETL process. Now,
assume that a new table storing additional geographical
data, e.g., the department each city belongs to, is loaded
in the data lake. Should decision makers be interested in
analyzing infection data by departments, they could (i)
select this table to be loaded in the MMDW and (ii) use
the many-to-one relationship between cities and
departments to extend the plot hierarchy on the fly.
We close this section by remarking that our architec
ture cannot be classified as a data lakehouse [
12
], because
L
T
E
g
n
i
d
a
o
L
Warehoused data
Additional data
s
e
i
r
e
u
Q
a
t
a
D
Data lake OLAP
it physically stores multidimensional data to be used for most existing works on schema inference from
schemaOLAP rather than letting OLAP queries by directly writ- less data (e.g., [
19, 20
]) output distinct attributes in
presten on source data; indeed, this has been shown to entail ence of variability, which would not make this variability
a smaller efort when writing queries as well as better transparent to users querying the DW. Type variability
query performances [
5
]. brings an additional problem, since measures are
commonly identified with numerical attributes. Thus, to
enable multidimensional elements to be correctly
rec4. Open issues ognized when extending a cube, variability-aware
approaches to properly infer schemata from schemaless
In this section we discuss the main research issues to be data should be devised.
addressed to implement the approach proposed.
Complex multidimensional elements. Big Data sources
Cross-model data-driven multidimensional modeling. can include complex data such as streams, trajectories,
Data-driven methodologies for multidimensional design graphs, spatiotemporal data, etc. The possibility of
definare usually based on the discovery of functional depen- ing measures as complex objects has been considered in
dencies (FDs) in the source data to identify measures and [
21
], which also proposes a relational implementation
dimension levels. The approaches proposed so far oper- for them, while in [
6
] a UML profile to model them at the
ate on source data fitting a single model. When source conceptual level has been presented. However, how to
data are relational, the proposed algorithms detect ex- recognize and design these complex measures —as well
act FDs based on primary and foreign keys coded in the as complex dimensions and levels— starting from data
relational schema [
13
]. When source data are JSON docu- sources is still an open question.
ments, some methods have been devised to complement Multi-model design. Storing warehoused data in an
exact FDs coded in the document schema with approxi- MMDB gives rise to further questions: Can diferent
modmate FDs [
14
] detected by parsing the data [
15
]. Other
works investigate how to enable OLAP querying over els be mixed to store warehoused data? Which factors
imgraph databases [
16
]. Recently, some works have intro- pact the choice of the best model to be used for each piece of
duced formal models to give a unified representation of data? Which are the benefits of using an MMDW instead
the schema of multi-model databases [
17, 18
], but they do sowfaerssinagreleg-mivoedneilni
m[7p]l,ewmheincthaptiroonv?idSeosmsoemperegliumidienlainryesatnonot address the discovery of multidimensional schemata design an MMDW that ensures a good trade-of between
from these unified models. Overall, to enable on-the- features such as querying performance, storage space,
lfy extensions of cubes, there is a need for new algo- ETL complexity, and evolvability. However, a complete
rithms capable of discovering exact/approximate FDs in set of best practices for multi-model design has not been
multi-model databases by chasing cross-model references. devised yet.
These algorithms should be incremental, since extensions OLAP tools. The existing OLAP clients are able to
are created starting from the multidimensional schema connect to warehoused data stored in relational form,
of the existing cube. Clearly, consistently with what typically using star/snowflake schemata. A first issue
existing work proposes in schema-on-read approaches, here is related to creating clients that can transparently
they should also take into account the requirements of query DWs under diferent models while fully
supportdecision-makers. ing the OLAP paradigm. Secondly, clients must be able
Variability. Schemaless models inherently support to properly deal with variability (e.g., as suggested in
variability in data types, names, and structures. However, [
22
]) and complex multidimensional elements. Another
challenge is how to ensure that the process of extending
the cubes on-the-fly based on the user’s requirements
is smooth and efective, and at the same time eficient
enough to be compatible with interactive analyses.