Sandro Bimonte
email: sandro.bimonte@inrae.fr

Yassine Hifdi
email: hifdiyassine@gmail.com

Mohammed Maliari
email: mohammedmaliari@gmail.com

Patrick Marcel
email: patrick.marcel@univ-tours.fr

Stefano Rizzi
email: stefano.rizzi@unibo.it

To Each His Own: Accommodating Data Variety by a Multimodel Star Schema

Recent approaches adopt multimodel databases (MMDBs) to natively handle the variety issues arising from the increasing amounts of heterogeneous data (structured, semi-structured, graphbased, etc.) made available. However, when it comes to analyzing these data, traditional data warehouses (DWs) and OLAP systems fall short because they rely on relational Database Management Systems (DBMSs) for storage and querying, thus constraining data variety into the rigidity of a structured schema. This paper provides a preliminary investigation of the performance of an MMDB when used to store multidimensional data for OLAP analysis. A multimodel DW would store each of its elements according to its native model; among the benefits we envision for this solution, that of bridging the architectural gap between data lakes and DWs, that of reducing the cost for ETL data transformations, and that of ensuring better flexibility, extensibility, and evolvability thanks to the use of schemaless models. To support our investigation we present an implementation, based on the UniBench benchmark dataset, that extends a star schema with JSON, XML, spatial, and key-value data; we also define a sample OLAP workload and use it to test the performance of our solution and compare it with that of a classical star schema. As expected, the full-relational implementation performs better, but we believe that this gap could be balanced by the benefits of multimodel in dealing with variety. Finally, we give our perspective view of the research on this topic.

INTRODUCTION

Big Data is notoriously characterized by (at least) the 3 V's: volume, velocity, and variety. To handle velocity and volume, some distributed file system-based storage (such as Hadoop) and new Database Management Systems (DBMSs) have been proposed. In particular, four main categories of NoSQL databases have been proposed [START_REF] Atzeni | Uniform access to NoSQL systems[END_REF]: key-value, extensible record, graph-based, and document-based.

Although NoSQL DBMSs have successfully proved to support the volume and velocity features, variety is still a challenge [START_REF] Lu | Multi-model Databases: A New Journey to Handle the Variety of Data[END_REF]. Indeed, several practical applications (e.g. retail, agriculture, etc.) ask for collecting and analyzing data of different types: structured (e.g., relational tables), semi-structured (e.g., XML and JSON), and unstructured (such as text, images, etc.). Using the right DBMS for the right data type is essential to grant good storage and analysis performance. Traditionally, each DBMS has been conceived for handling a specific data type; for example, relational DBMSs for structured data, document-based DBMSs for semi-structured data, etc. Therefore, when an application requires different data types, two solutions are actually possible: (i) integrating all data into a single DBMS, or (ii) using two or more DBMSs together. The former solution presents serious drawbacks: first of all, some types of data cannot be stored and analyzed (e.g., the pure relational model does not support the storage of images, XML, arrays, etc. [START_REF] Shimura | Storage and Retrieval of XML Documents Using Object-Relational Databases[END_REF]); besides, even when data can be converted and stored in the target DBMS, querying performances could be unsatisfactory. The latter approach (known as polyglot persistence [START_REF] Gadepally | The BigDAWG polystore system and architecture[END_REF]) presents important challenges as well, namely, technically managing more DBMSs, complex query languages, inadequate performance optimization, etc. Therefore, Multimodel databases (MMDBs) have recently been proposed to overcome these issues. A MMDB is a DBMS that natively supports different data types under a single query language to grant performance, scalability, and fault tolerance [START_REF] Lu | Multi-model Databases: A New Journey to Handle the Variety of Data[END_REF]. Remarkably, using a single platform for multimodel data promises to deliver several benefits to users besides that of providing a unified query interface; namely, it will simplify query operations, reduce development and maintenance issues, speed up development, and eliminate migration problems [START_REF] Lu | Multi-model Databases: A New Journey to Handle the Variety of Data[END_REF]. Examples of MMDBs are PostgreSQL and ArangoDB. Post-greSQL supports the row-oriented, column-oriented, key-value, and document-oriented data models, offering XML, HSTORE, JSON/JSONB data types for storage. ArangoDB supports the graph-based, key-value, and document-oriented data models.

Handling variety while granting at the same time volume and velocity is even more complex in Data Warehouses (DWs) and OLAP systems. Indeed, warehoused data result from the integration of huge volumes of heterogeneous data, and OLAP requires very good performances for data-intensive analytical queries [START_REF] Kimball | The data warehouse toolkit: the complete guide to dimensional modeling[END_REF]. Traditional DW architectures rely on a single, relational DBMS for storage and querying1 . To offer better support to volume while maintaining velocity, some recent works propose the usage of NoSQL DBMSs; for example, [START_REF] Chevalier | Implementation of Multidimensional Databases with Document-Oriented NoSQL[END_REF] relies on a document-based DBMS, and [START_REF] Boussahoua | Logical Schema for Data Warehouse on Column-Oriented NoSQL Databases[END_REF] on a column-based DBMS. NoSQL proposals for DWs are based on a single data model, and all data are transformed to fit with that model (document, graph, etc.). Overall, although these approaches offer interesting results in terms of volume and velocity, they have been mainly conceived and tested for structured data, without taking into account variety. Furthermore, to facilitate OLAP querying, DWs are normally based on the multidimensional model, which introduces the concepts of facts, dimensions, and measures to analyze data, so source data must be forcibly transformed to fit a multidimensional logical schema following a so-called schema-on-write approach. Since this is not always painless because of the schemaless nature of some source data, some recent work (such as [START_REF] Lamine Chouder | EXODuS: Exploratory OLAP over Document Stores[END_REF]) propose to directly rewrite OLAP queries over document stores that are not organized according to the multidimensional model, following a schema-on-read approach (i.e., the multidimensional schema is not decided at design time and forced in a DW, but decided by each single user at querying time). However, even this approach relies on a single DBMS.

An interesting direction towards a solution for effectively handling the 3 V's in DW and OLAP systems is represented by MMDBs. A multimodel data warehouse (MMDW) can store data according to the multidimensional model and, at the same time, let each of its elements be natively represented through the most appropriate model. Among the benefits we envision for MMDWs, that of bridging the architectural gap between data lakes and DWs, that of reducing the cost for ETL data transformations, and that of ensuring better flexibility, extensibility, and evolvability thanks to the use of schemaless models.

In this paper we conduct a preliminary investigation of the performance of MMDWs to store multidimensional data. To this end we introduce a logical schema for MMDWs and its implementation on PostgreSQL, which gives native multimodel support. Our schema extends the classical star schema introducing semistructured (JSON, XML, and key-value) data in all the multidimensional elements; thus, it goes in the direction of coupling the pros of schema-on-write approaches (mainly, good performances and simple query formulation with no need for query rewriting) with those of schema-on-read approaches (higher flexibility in ad-hoc querying).

Due to the lack of a benchmark for multimodel data warehouse, in this paper we propose our own OLAP workload to evaluate the performance of our proposal, which we also test against a full-relational implementation on PostgreSQL. To the best of our knowledge, no benchmark dataset for DW (either relational or NoSQL) supports variety; thus, for the experiments we use the schema and data provided by UniBench [START_REF] Zhang | UniBench: A Benchmark for Multi-model Database Management Systems[END_REF], a benchmark for MMDBs that well represents variety.

The paper outline is as follows. After discussing the related literature in Section 2, in Section 3 we present the UniBench case study. Sections 4 and 5 introduce our logical schema for MMDWs and the related OLAP workload, respectively. Section 6 shows the results of the experiments we made, while Section 7 presents our vision of future MMDW research. Finally, in Section 8 we draw the conclusions.

RELATED WORK

Some recent work concerns warehousing and OLAP using NoSQL DBMSs of different kinds. In [START_REF] Chevalier | Document-oriented Models for Data Warehouses -NoSQL Document-oriented for Data Warehouses[END_REF], three different logical models are proposed, using 1 or N document collections to store data in document-based DBMSs and highlighting the utility of nested document and array types [START_REF] Chevalier | Document-oriented data warehouses: Models and extended cuboids, extended cuboids in oriented document[END_REF]. The same authors also investigate how to handle complex hierarchies and summarizability issues with document-based DWs [START_REF] Chevalier | Document-Oriented Data Warehouses: Complex Hierarchies and Summarizability[END_REF]. The introduction of spatial data in document-based DWs has been discussed in [START_REF] Ferrahi | Design and Implementation of Falling Star -A Non-Redundant Spatio-Multidimensional Logical Model for Document Stores[END_REF], which proposes a new spatial multidimensional model to avoid redundancy of spatial data and improve performances. A logical model for column-based DWs has been proposed by [START_REF] Boussahoua | Logical Schema for Data Warehouse on Column-Oriented NoSQL Databases[END_REF] and [START_REF] Chevalier | Implementation of Multidimensional Databases in Column-Oriented NoSQL Systems[END_REF] to address volume scalability. In [START_REF] Sellami | Transformation of Data Warehouse Schema to NoSQL Graph Data Base[END_REF], transformation rules for DW implementation in graph-based DBMSs have been proposed for better handling social network data. To the best of our knowledge, only [START_REF] Malki | Benchmarking Big Data OLAP NoSQL Databases[END_REF] presents a benchmark for comparing NoSQL DW proposals; specifically, this benchmark is applied to MongoDB and Hbase. Some works also study the usage of XML DBMSs for warehousing XML data [START_REF] Ouaret | An overview of XML warehouse design approaches and techniques[END_REF]. Although XML DWs represent a first effort towards native storage of semi-structured data, their querying performances do not scale well with size, and compression techniques must be adopted [START_REF] Boukraâ | Efficient Compression and Storage of XML OLAP Cubes[END_REF]. Among all these proposals, it is hard to champion one logical and physical implementation for NoSQL and XML DWs, since no approach clearly outperforms the other on the 3 V's. Moreover, these single-model proposals do not address other issues related to warehousing big data, such as reducing the cost of ETL, evolution and improving flexibility.

Recently, some approaches to execute OLAP queries directly against NoSQL data sources were proposed. In [START_REF] Lamine Chouder | EXODuS: Exploratory OLAP over Document Stores[END_REF], a schemaon-read approach to automatically extract facts and hierarchies from document data stores and trigger OLAP queries is proposed. A similar approach is presented in [START_REF] Gallinucci | Approximate OLAP of document-oriented databases: A variety-aware approach[END_REF]; there, schema variety is explicitly taken into account by choosing not to design a single crisp schema where source fields are either included or absent, but rather to enable an OLAP experience on some sort of "soft" schema where each source field is present to some extent. In the same direction, [START_REF] Dehdouh | Building OLAP Cubes from Columnar NoSQL Data Warehouses[END_REF] proposes a MapReduce-based algorithm to compute OLAP cubes on column stores, while [START_REF] Castelltort | NoSQL Graph-based OLAP Analysis[END_REF] aims at delivering the OLAP experience over a graph-based database.

The approaches mentioned above rely on a single-model database. Conversely, [START_REF] Hamdi | Answering GPSJ Queries in a Polystore: a Dataspace-Based Approach[END_REF] proposes a pay-as-you-go approach which enables OLAP queries against a polystore supporting relational, document, and column data models by hiding heterogeneity behind a dataspace layer. Data integration is carried out on-the-fly using a set of mappings. Even this approach can be classified as schema-on-read; the focus is on query rewriting against heterogeneous databases and not on the performances of the approach.

CASE STUDY: UNIBENCH

UniBench is a benchmark for multimodel databases proposed in [START_REF] Zhang | UniBench: A Benchmark for Multi-model Database Management Systems[END_REF]. It includes a retail dataset composed of relational, XML, JSON, key-value, and graph data as shown in Figure 1, which makes it a good representative for variety. However, UniBench was not conceived for OLAP queries. Since our goal is to handle variety with specific reference to DWs, we had to derive a multidimensional schema from UniBench. This adaptation required some modifications, including the addition of descriptive attributes (e.g., LastName), which allows to better test the effectiveness of the proposed approach; as a consequence, some additional data had to be (randomly) generated. The resulting schema represents the Order fact; as shown in Figure 2 it presents three dimensions:

• A Time dimension with levels Day, Month, and Year.

• A Product dimension with one hierarchy including level

Store and some descriptive attributes (e.g., Vendor). Interestingly, stores are described by a spatial level, Location.

The cloud symbol in the schema denotes that a product can have some additional descriptive attributes not specified at design time. • A Costumer dimension in which two hierarchies are rooted: one with level Gender, one with UsedBrowser. The customer also has some descriptive attributes, e.g., LastName.

Attribute Rating is cross-dimensional, i.e., its value is jointly determined by Product and Customer (a customer can rate several products). The fact has one measure, TotalPrice. Finally, since an order is associated to many products, a manyto-many relationship is set between the fact and the product dimension (non-strict hierarchy). 2

A MULTIMODEL STAR SCHEMA FOR UNIBENCH

In this section we present a MultiModel, MultiDimensional (in short, M 3 D) logical schema for the Order fact introduced above. Essentially, we use a classical star schema with a fact and dimension tables, extended with semi-structured data in JSON and XML form, and with spatial data. Starting from a star schema has several clear advantages: (i) the star schema is supported by all OLAP servers and already in use in a huge number of enterprise DWs; (ii) the best practices for designing a star schema from a conceptual schema are well understood and commonly adopted by practitioners; (iii) fact-dimension relationships are ruled by foreign keys so their consistence is natively checked by the DBMS; (iv) performance optimization of star schema has been long studied and practiced at both the logical (e.g., via view materialization) and the physical (e.g., via indexing) level.

Clearly, several possible alternatives arise for modeling the Order fact with an extended star schema. Defining a set of best practices for designing an M 3 D schema that achieves the best trade-off between the five advantages listed in Section 1 is out of the scope of this paper; so, we opted for designing the schema based on a simple guideline: preserve as much as possible the source data variety, i.e., minimizing the transformations to be applied to UniBench source data. Figure 3 shows the M 3 D schema that results from applying this guideline to the conceptual schema in Figure 2. It can be described as follows:

• The fact table, Fact_Order, has one tuple for each order and references the order customer and date via foreign keys. Each tuple includes a JSON document that stores the totalPrice measure and an array of orderlines, each specifying a product. • The customer dimension table, Dim_Customer, specifies each customer's data in the form of XML documents. • The temporal dimension table, Dim_Date, stores in each tuple a JSON document with the order date; to enable useful aggregations, it also stores the corresponding month and year. • The product dimension table, Dim_Product, for each product stores its location (as a spatial attribute), vendor, and store, as well as a JSON document with the product name (title), price, and image. Each product also has a Feedback attribute that stores all its ratings in key-value form, with the customer code as a key. • As shown in Figure 2, each order refers to several products. To model this non-strict hierarchy, rather than opting for the classical relational solution (a many-to-many bridge table [START_REF] Golfarelli | Data Warehouse Design: Modern Principles and Methodologies[END_REF]), we established a connection between the InfoOrder document stored in the fact table and the Dim_Product dimension table via the asin attribute.

An example of instances of the fact table and of the product dimension table are shown in Figure 4. The cloud symbol in Figure 2 denotes that the product dimension can include some additional attributes not specified at design time (hence, not included in the JSON schema). For instance, some InfoPrdt documents will have an EU attribute precising the category of product according to the EU classification (see Figure 5), while some InfoOrder documents will have a brand attribute.

AN OLAP WORKLOAD FOR UNIBENCH

The workload we introduce to test our M 3 D schema is inspired by that of the classical SSB benchmark [START_REF] O'neil | The Star Schema Benchmark and Augmented Fact Table Indexing[END_REF], itself loosely based on the TPC-H benchmark. The SSB workload is meant to functionally cover the different types of star schema queries while varying fact table selectivity. SSB queries are organized in 4 flights, where each flight is a list of 3 to 4 queries. Query flight 1 has restrictions on only 1 dimension, flight 2 has restrictions on 2 dimensions, flight 3 on 3, and flight 4 represents a what-if sequence of the OLAP type. We adopt the same approach, while at the same time classifying queries according to the usage of relational (R)/non relational (NR) measures, relational/non relational group-by levels, and relational/non relational selection levels. We also add a parameter representing the type of join: relational means a join using two relational attributes, while JSON means a join between a JSON attribute and a relational one. Q10 and Q12 use selection attributes that are not part of the JSON schema (brand and EU, respectively). In Table 1, which presents the workload, "by" introduces a group-by and "for" a selection.

MULTIMODEL VS. FULL-RELATIONAL

In this section we give a preliminary assessment of the effectiveness and efficiency of MMDWs as compared to those of a classical relational implementation.

InfoOrder

{ "$schema": "http://json-schema.org/draft-03/schema#", "id": "#", "type": "object", "properties": { "totalPrice": { "type": "number" }, "orderLine": { "type": "array", "items": { "id": "0", "type": "object", "properties": { "productId": { "type": "string" }, "asin": { "type": "string" }, "title":

{ "type": "string" }}}}}}

InfoPrdt

{ "$schema": "http://json-schema.org/draft-03/schema#", "id": "#", "type": "object", "properties": { "title": { "type": "string" }, "price": { "type": "number" }, "imhUrl": { "type": "string" }}}} Feedback key : id_cust value : rating

Efficiency

We have implemented the M 3 D schema using PostgreSQL with its JSON, XML, key-value, and spatial native storage. Data used to feed dimensions and facts has been extracted from the UniBench benchmark [START_REF] Zhang | UniBench: A Benchmark for Multi-model Database Management Systems[END_REF]. Specifically, we have 745 dates (|Dim_Date|), 9,949 customers (|Dim_Customer|), 10,116 products (|Dim_Product|), and 640,000 orders (|Fact_Order|). All the OLAP queries proposed in Section 5 have been successfully formulated and executed over the M 3 D schema, which confirms the feasibility of using PostgreSQL as a platform for storing and querying MMDWs. Figure 6 shows the SQL formulation of a sample query in PostgreSQL; note that attributes Feedback of type key-value and InfoOrder of type JSON are retrieved as table views to be used for a join or a selection.

In the following, we present some experiments aimed at quantitatively comparing the querying performances of the M 3 D schema and those of a full-relational star schema (from now on, FR). For the FR schema we used two bridge tables as shown in Figure 8. The first one, Bridge_Ord_Prod, stores the manyto-many relationship between an order and its products. The second one, Bridge_Cust_Prod, is necessary to store the Rating cross-dimensional attribute. Noticeably, attributes EU and brand are not included here since, as explained in Section 4, they were not known at design time. Clearly, unless some (costly) evolution of the schema is carried out, these attributes cannot be loaded and they cannot be used for querying. The FR schema is also implemented in PostgreSQL; Figure 7 shows the SQL formulation of query Q2 over the FR schema. A comparison between Figures 6 and7 suggests that the formulation over the M 3 D schema is more complex; however, we wish to emphasize that there is no real difficulty in formulating queries on an MMDW in comparison to a traditional star schema, except that some knowledge of the DBMS-specific operators to manipulate key-value, JSON, and XML types is required.

For both implementations, B+trees have been used to index relational attributes. For the M 3 D schema, some tests were done in order to find the best optimization plan for the workload queries. The results we report below use the following: (i) a Gist index is used on the Feedback hstore attribute; (ii) B+trees and Gin indexes are used on JSON attributes. All tests have been run Table 2 shows the query execution in milliseconds against both implementations. Note that Q10 and Q12 cannot be executed on the FR schema because they use attributes (brand and EU, respectively) that were not known at design time so they are not part of that schema. Not surprisingly, the full-relational implementation outperforms the multimodel implementation over most queries. This can partly be explained by recalling that PostgreSQL was originally born as a relational DBMS, so semistructured and complex data querying is not fully optimized yet.

In particular, PostgreSQL lacks specific optimization structures adapted to XML data, thus, the InfoCust attribute cannot be properly indexed; this impacts queries Q3, Q4, Q6, Q8, and Q10. M 3 D is also penalized by the necessity to have a JSON attribute in the fact table to be joined with a dimension table (namely, InfoOrder).

Additionally, the fact table in M 3 D is quite larger than the one in the FR schema, which results in slower star joins (even using the JSONB type instead of JSON, the improvement is very small). The only case where the multimodel implementation significantly outperforms the full-relational one is Q9; this is due to the use of a bridge table in the relational implementation and specifically to the fact that, despite the presence of indexes, the optimizer uses sequential scan to access the bridge table.

Table 3 shows the storage size of both implementations. Unthe relational implementation is more sober than the multimodel one.

Though devising complete guidelines and best practices for multimodel design is out of the scope of this paper, we observe that:

(1) the relational model is still more efficient, so it should be used, during logical design, for the data sources that can be smoothly transformed into relational form (i.e., those whose transformation does not entail loss of information content and can be accommodated within the time frame of ETL); (2) conversely, the data sources that hardly fit into the fixed structure of a relational schema, e.g., because their schema is not completely known in advance, should be left in their native form.

Effectiveness

In this section we provide a qualitative comparison of the two solutions in terms of effectiveness from three points of view:

• Transformation. The full-relational implementation required all the UniBench data to be translated in relational form according to the star schema in Figure 8. While in the M 3 D schema the dimension and fact tables are fed with JSON data with simple INSERT queries, in the FR schema more steps are required. For instance, just to feed the bridge table using the ETL Talend tool we need (i) a job for reading the JSON collection (tFileInputJSOn); (ii) a loop JSON query to read the array of products of each InfoOrder document; (iii) a job for reading the Dim_Product dimension table; and finally (iv) a join operation. This means that transformations may require a significant time and can be error-prone, so they may be unsuitable in specific settings such as those of real-time DWs. • Flexibility. Differently from the FR schema, the M 3 D one preserves the data variety existing in the data sources. This is particularly relevant for instance in self-service business intelligence scenarios, where data scientist will write ad-hoc queries to satisfy situational analysis needs [START_REF] Abelló | Fusion Cubes: Towards Self-Service Business Intelligence[END_REF]. Besides, mixing different models allows, in an MMDW, to achieve higher flexibility in the modeling solutions taken, for instance when dealing with many-to-many relationships. • Evolution. While the multimodel implementation is partially schemaless, so it inherently supports evolution, the situation with the full-relational implementation is quite different. In fact, even adding a couple of simple levels (as EU and brand in our case study) requires, at the very least, changing the relational schema of one or more tables, editing the ETL procedures, and migrating the data from the old schema to the new one. A more complex evolution, e.g., one involving a new many-to-many relationship, would have even more impact because it would require creating new tables. In case users ask for a full versioning of the schemata, the effort would be greater still. An M 3 D schema represents a good trade-off here because most evolutions can be handled seamlessly with no impact on tables and ETL; clearly, a more invasive evolution (such as adding a new dimension or measure) would still require a change to the relational part of the schema and to the ETL.

A PERSPECTIVE ON MMDW RESEARCH

The experiments we conduct in this work are encouraging enough to set a short-and mid-term perspectives of the research on MMDWs. The advantages we envision for MMDWs can be summarized as follows:

(1) An MMDW will natively and efficiently support OLAP querying over large volumes of multimodel and multidimensional data, thus ensuring support to both volume, velocity, and variety. (2) Storing data in their native model means reducing the data transformations required; hence, the effort for writing (time-consuming and error-prone) ETL procedures will be reduced in MMDWs, and the freshness of data in the DWs will be increased. (3) MMDWs will bridge the architectural gap between data lakes and DWs. A data lake ingests heterogeneouslystructured raw data from various sources and stores them in their native format, enabling their processing according to changing requirements [START_REF] Ravat | Data Lakes: Trends and Perspectives[END_REF]. Differently from DWs, data lakes support storage of any kind of data with low-cost design, provide increasing analysis capabilities, and offer an improvement in data ingestion; however, analysis tasks are more complex and time-consuming since a schema-onread approach must be followed. We believe MMDWs will offer an effective architectural trade-off by enabling both OLAP multidimensional analyses and ad-hoc analytics on the same repository. (4) Schema evolution is a crucial issue in traditional DW architectures, since modifying relational schemata to accommodate new user requirements is a complex and expensive task. MMDWs can store schemaless data, so they will ensure a more effective support to schema evolution [START_REF] Scherzinger | Managing Schema Evolution in NoSQL Data Stores[END_REF]. (5) Again thanks to their support of schemaless data, higher flexibility and extensibility will be granted, which will enhance analysis capabilities thus generating added value for users [START_REF] Berkani | Value-driven Approach for Designing Extended Data Warehouses[END_REF].

(6) More specifically, key-value stores on the one hand, and the array constructs supported by document-based databases on the other, provide an alternative solution to model many-to-many relationships appearing in some multidimensional schemata.

In our short-term research agenda on MMDWs we mainly plan to verify and quantify these benefits via an extensive set of experiments based on a more comprehensive case study. This will require, for instance, to measure the effort for writing ETL procedures to transform all data according to a single model; to assess the increase in querying expressiveness achieved by MMDWs in function of the amount of data variety; to simulate dynamic settings so as to evaluate the saving in dealing with schema evolution. In order to overcome performance limitations described in the previous section, we think also that new experiments are mandatory on another multimodel DBMS such as Oracle, which provides other types of implementation for non relational data, and also distributed storage and computation.

In the mid-term, the preliminary work we presented in this paper opens several research issues:

• Multidimensional design from MMDBs. The existing datadriven approaches to multidimensional design are based on detecting functional dependencies in single-model data sources, namely, relational, XML, linked-open data, JSON [START_REF] Romero | A Survey of Multidimensional Modeling Methodologies[END_REF]. Using a multimodel data source for design requires integrating different techniques into a synergic methodology. • Conceptual models. Existing conceptual models for DWs are mostly aimed at designing multidimensional schemata with fixed structure. To take full advantage of the flexibility ensured by MMDWs, new models capable of coping with schemaless data (as naively done with the cloud symbol in Figure 2) are needed. • Best practices for logical design. In presence of variety, several alternatives emerge for the logical representation of dimensions and facts [START_REF] Ferrahi | A Model & DBMS Independent Benchmark for Data Warehouses[END_REF]. Indeed, some combinations of models may be better than others when coupled with star schemata. A specific set of guidelines for logical design of MMDWs is thus needed to find the best trade-off between performances, fidelity to source schemata, extensibility, and evolvability; this should also include the issues related to view materialization. • OLAP benchmark. Effectively benchmarking MMDBs [START_REF] Lu | Multi-model Databases: A New Journey to Handle the Variety of Data[END_REF] and non relational DBMSs [START_REF] Malki | Benchmarking Big Data OLAP NoSQL Databases[END_REF] is still a challenge. Providing a benchmark for MMDWs is a further challenge, since it requires defining a dataset representative of DW volume and multimodel variety, as well as a full range of representative OLAP queries over this dataset. • Indexing. PostgreSQL offers different types of indexes over MMDBs, e.g., B-trees, hash, GiST (for geo data), GIN (for document and hstore data), etc. Ad hoc indexing strategies will have to be devised, in presence of variety, to cope with the specific features of multidimensional data and OLAP queries. • OLAP tools. Last but not least, more sophisticated OLAP tools are required to let users benefit from the additional flexibility introduced by MMDWs while ensuring good performances. Specifically, there is a need for devising techniques to automatically generate efficient SQL queries over MMDWs from the (MDX-like or graphical) language used by the front-end.

CONCLUSION

Handling big data variety, volume, and velocity is an important challenge for decision-making information systems. On the one hand, data lakes have been proposed to ensure flexible storage of raw data, but at the price of making analyses more complex. On the other hand, classical DW architectures provide an efficient framework for analyzing transformed and integrated data, but they fall short in natively handling data variety. Motivated by the emerging trend of MMDBs, in this work we have investigated the feasibility of a multimodel approach to DW based on an extension of the well-known star schema with schemaless data as dimensions and facts. Our experiments are encouraging as they show that all queries of our multimodel tailored OLAP workload can run over the proposed multimodel star schema in acceptable time compared to a full-relational implementation.

Based on these first results, we have presented many short-and mid-term research perspectives on MMDW.

Figure 1 :

 1 Figure 1: Overview of the UniBench data

Figure 2 :

 2 Figure 2: Multidimensional schema for UniBench (the DFM notation [18] is used)

Figure 3 :Figure 4 :

 34 Figure 3: Multimodel star schema in PostgreSQL (solid and dashed lines represent foreign key relationships and implicit relationships between relational and JSON attributes, respectively; in italics, level properties)

Figure 5 :

 5 Figure 5: An InfoPrdt document including an extraschema attribute, EU

Figure 6 :

 6 Figure 6: SQL formulation of query Q2 in PostgreSQL over the M 3 D schema

Figure 8 :

 8 Figure 8: Full-relational star schema in PostgreSQL

Table 1 :

 1 OLAP queries on the Order fact Rating>4 and o.Id_Date=d.Id_Date and o.Id_Cust=cp.Id_Cust and o.Id_Order=op.Id_Order and cp.Asin=op.Asin group by d.Month

	Query	Measure	Group-by	Selection	Join	Query	Numb. of selections	NR types
	Q0	R	R	R	R	Number of orders by months for given months and years	2	-
	Q1	R	R	R	JSON	Number of orders by months for given stores and years	2	JSON
	Q2	R	R	NR	JSON	Number of orders by months for given years and rating	2	JSON,key-value
	Q3	R	NR	R	R	Number of orders by months, gender for given years	1	XML
	Q4	R	NR	NR	JSON	Number of orders by months, gender for given products	1	JSON,XML
	Q5	NR	R	R	JSON	Total price by year for given stores	1	JSON
	Q6	NR	R	NR	R	Total price by year for given genders	1	JSON,XML
	Q7	NR	NR	R	JSON	Total price by year, gender for given stores and years	2	JSON
	Q8		NR	NR	R	Total price by year of birth for given browsers and genders	2	XML
	Q9	NR	NR	NR	JSON	Total price by date, customer for given months, ratings, stores	3	JSON,key-value
	Q10	NR	NR	NR opt.	R	Total price by date for given months, genders, brands	3	JSON,XML
	Q11	NR	NR	NR	JSON	Total price by date, customer for given months, genders, ratings	3	JSON,XML,key-value
	Q12	NR	NR	NR opt.	JSON	Total price by costumer for given EU values	1	JSON,XML
	Q2:
	select count(distinct o.Id_Order) as NumberOfOrders, d.Month
	from ( select Id_Order, products->>'asin' as Asin
	from Fact_Order o,
	jsonb_array_elements(o.InfoOrder->'orderLine') as products
	) as op, Fact_Order o, Dim_Date d,
	( select skeys(p.Feedback) as Id_Cust, Asin, svals(p.Feedback) as Rating
	from Dim_Product p
	) as cp
	where d.Year='2020' and

Q2: select count(distinct Id_Order) as NumberOfOrders, d.Month from Fact_Order o, Dim_Date d, Bridge_Cust_Prod cp, Bridge_Ord_Prod op where d.Year='2020' and Rating>4 and o.Id_Date=d.Id_Date and o.Id_Cust=cp.Id_Cust and o.Id_Order=op.Id_Order and cp.Asin=op.Asin group by d.Month

  Id_Order) as NumberOfOrders, d.Month from Fact_Order o, Dim_Date d, Bridge_Cust_Prod cp, Bridge_Ord_Prod op where d.Year='2020' and Rating>4 and o.Id_Date=d.Id_Date and o.Id_Cust=cp.Id_Cust and o.Id_Order=op.Id_Order and cp.Asin=op.Asin group by d.Month

	Q2:
	select count(distinct o.Id_Order) as NumberOfOrders, d.Month
	from ( select Id_Order, products->>'asin' as Asin
	from Fact_Order o,
	jsonb_array_elements(o.InfoOrder->'orderLine') as products
	) as op, Fact_Order o, Dim_Date d,
	( select skeys(p.Feedback) as Id_Cust, Asin, svals(p.Feedback) as Rating
	from Dim_Product p
	) as cp
	where d.Year='2020' and Rating>4 and o.Id_Date=d.Id_Date
	and o.Id_Cust=cp.Id_Cust and o.Id_Order=op.Id_Order and cp.Asin=op.Asin
	group by d.Month
	Q2:
	select count(distinct Figure 7: SQL formulation of query Q2 in PostgreSQL over
	the FR schema
			Dim_Date
			<PK> Id_Date : Int
			Date	: Date
	Bridge_Ord_Prod	Month : Date Year : Date
	<PK,FK> Id_Order: String
	<PK,FK> Asin	: String		Dim_Customer
			Fact_Order	<PK> Id_Cust FirstName	: String : String
	Dim_Product <PK> Asin : String Title : String Price : Double ImhUrl : String	<PK> Id_Order : String <FK> Id_Cust : String <FK> Id_Date : Int TotalPrice : Double	LastName Gender Birthday CreationDate : Date : String : String : Date BrowserUsed : String
	Location: Geo
	Store : String Vendor : String	Bridge_Cust_Prod
			<PK,FK> Id_Cust : String
			<PK,FK> Asin	: String
			Rating : Int

Table 2 :

 2 Performance of benchmark queries (in milliseconds)

	Query	M 3 D	FR
	Q0	253	310
	Q1	712	633
	Q2	2509	1161
	Q3	3996	1023
	Q4	1049	175
	Q5	1437	714
	Q6	1034	197
	Q7	1902	711
	Q8	817	131
	Q9	187	732
	Q10	1660	-
	Q11	2726	517
	Q12	1165	-
	on a Core i5 with 4 CPUs @2.3GHz laptop with 16 GB RAM and
	SSD running MacOS Mojave.

Table 3 :

 3 Storage size

	Table	M 3 D	FR
	Fact_Order	603 MB	41 MB
	Dim_Product	4160 kB	3896 kB
	Dim_Customer	3280 kB	824 kB
	Dim_Date	56 kB	40 kB
	Bridge_Ord_Prod	-	55 MB
	Bridge_Cust_Prod	-	9864 kB

More precisely, this is true for so-called ROLAP architectures. In MOLAP architectures, data are stored in multidimensional arrays. Finally, in HOLAP architectures, a MOLAP and a ROLAP systems are coupled.

We have not considered the graph data of UniBench, since the PostgreSQL DBMS used for implementation does not support them natively.

ACKNOWLEDGEMENT

This work was partially supported by the French National Research Agency as part of the "Investissements d'Avenir" through the IDEX-ISITE initiative CAP 20-25 (ANR-16-IDEX-0001), and the project VGI4bio (ANR-17-CE04-0012).


domain: phys chim

text:
Kevin Sartori

Fadi Choueikani

Alexandre Gloter

Sylvie Begin-Colin

Dario Taverna

Benoit P Pichon

Room Temperature Blocked Magnetic Nanoparticles Based on Ferrite Promoted by a Three-Step Thermal Decomposition Process

Exchange coupled nanoparticles that combine hard and soft magnetic phases are very promising to enhance the effective magnetic anisotropy while preserving sizes below 20 nm. However, the core-shell structure is usually insufficient to produce rare earth-free ferro(i)magnetic blocked nanoparticles at room temperature. We report on onion-type magnetic nanoparticles prepared by a three-step seed mediated growth based on the thermal decomposition method. The core@shell@shell structure consists of a core and an external shell of Fe 3-δ O 4 separated by an intermediate Co-doped ferrite shell. The double exchange coupling at both core@shell and shell@ shell interfaces results in such an increased of the magnetic anisotropy energy, that onion-type nanoparticles of 16 nm mainly based on iron oxide are blocked at room temperature. We envision that these results are very appealing for potential applications based on permanent magnets.

H ard-soft coupled magnetic nanoparticles have gained a tremendous amount of interest during the past decade for short-term development of advanced applications related to spintronics (magnetoresistive sensors, magnetic recording, etc.). [START_REF] Loṕez-Ortega | Applications of Exchange Coupled Bi-Magnetic Hard/Soft and Soft/Hard Magnetic Core/Shell Nanoparticles[END_REF] Indeed, they are a potential alternative to produce permanent magnets 2 in order to circumvent supply storage caused by the critical need for rare earth elements in communications and mobility applications. With this purpose, the main goal is to overcome superparamagnetism, which results from size reduction to the nanoscale. 3 A very attractive approach is the design of core-shell nanoparticles that combine hard and soft magnetic phases in direct contact. [START_REF] Nogueś | Exchange Bias in Nanostructures[END_REF] Thanks to the large core-shell interface, exchange coupling between interfacial spins of both phases can be finely modulated by a collection of parameters such as core size and shell thickness, [START_REF] Liu | Systematic Study of Exchange Coupling in Core-Shell Fe3-DO4@CoO Nanoparticles[END_REF][START_REF] Song | Controlled Synthesis and Magnetic Properties of Bimagnetic Spinel Ferrite CoFe 2 O 4 and MnFe 2 O 4 Nanocrystals with Core-Shell Architecture[END_REF] as well as crystal lattices mismatch, defects [START_REF] Chai | One-Pot Synthesis of High-Quality Bimagnetic Core/Shell Nanocrystals with Diverse Exchange Coupling[END_REF] and cationic diffusion. [START_REF] Lopez-Ortega | Strongly Exchange Coupled Inverse Ferrimagnetic Soft/Hard, MnxFe3-XO4/FexMn3-XO4, Core/Shell Heterostructured Nanoparticles[END_REF][START_REF] Skoropata | Magnetism of Iron Oxide Based Core-Shell Nanoparticles from Interface Mixing with Enhanced Spin-Orbit Coupling[END_REF] Therefore, exchange coupling results in the enhancement of thermal stability (higher blocking temperature, T B ) and magnetic stability (higher coercive field, H C ). In this field, iron oxide is certainly the first choice to avoid rare earth components because of its abundance, nontoxicity and low cost. [START_REF] Tartaj | The Iron Oxides Strike Back: From Biomedical Applications to Energy Storage Devices and Photoelectrochemical Water Splitting[END_REF] Indeed, ferr(i)magnetic (F(i)M) ferrites are usually combined with an antiferromagnetic (AFM) phase such as MnO@Mn 3 O 4 , 11 Fe 3-δ O 4 @ CoO, [START_REF] Liu | Systematic Study of Exchange Coupling in Core-Shell Fe3-DO4@CoO Nanoparticles[END_REF][START_REF] Baaziz | High Exchange Bias in Fe3O4@CoO Core Shell Nanoparticles Synthesized by a One-Pot Seed-Mediated Growth Method[END_REF] CoO@CoFe 2 O 4 [START_REF] Lima | Bimagnetic CoO Core/CoFe 2 O 4 Shell Nanoparticles: Synthesis and Magnetic Properties[END_REF] and ZnO@Co x Zn 1-x Fe 2 O 4 . 14 Nevertheless, the AFM order vanishes below the Neél temperature (for instance, T N = 290 K for CoO) which results in the disappearance of the exchange bias coupling. It is an important drawback for the design of room temperature permanent magnets. Recently, the magnetic anisotropy energy of Co@CoO nanoparticles incorporated in a NiO matrix (T N = 520 K) was enhanced above room temperature thanks to proximity effects. [START_REF] De Toro | High Temperature Magnetic Stabilization of Cobalt Nanoparticles by an Antiferromagnetic Proximity Effect[END_REF] However, in this approach, nanoparticles cannot be manipulated as separate building blocks for the production of advanced technological devices. An alternative to AFM components is the design of nanoparticles that combine multiple F(i)M phases. Ferrites (MFe 2 O 4 , with M: Co, Mn, Ni), which exist in several chemical compositions, allow the fine modulation of hardness and softness of the magnetic phases. [START_REF] Song | Controlled Synthesis and Magnetic Properties of Bimagnetic Spinel Ferrite CoFe 2 O 4 and MnFe 2 O 4 Nanocrystals with Core-Shell Architecture[END_REF][START_REF] Daffe | Nanoscale Distribution of Magnetic Anisotropies in Bimagnetic Soft Core-Hard Shell MnFe2O4@CoFe2O4 Nanoparticles[END_REF] For instance, the diffusion of Co 2+ in the surface layer of a Fe 3-δ O 4 core resulted in the formation of a Co-doped ferrite shell which markedly increased of magnetic anisotropy energy. [START_REF] Liu | Systematic Study of Exchange Coupling in Core-Shell Fe3-DO4@CoO Nanoparticles[END_REF][START_REF] Sartori | Strong Interfacial Coupling through Exchange Interactions in Soft/Hard Core-Shell Nanoparticles as Function of Cationic Distribution[END_REF] Furthermore, recent advances in synthesis techniques allowed the production of multiple shell nanoparticles. [START_REF] Salazar-Alvarez | Two-, Three-, and Four-Component Magnetic Multilayer Onion Nanoparticles Based on Iron Oxides and Manganese Oxides[END_REF][START_REF] Krycka | Correlating Material-Specific Layers and Magnetic Distributions within Onion-like Fe3O4/MnO/g-Mn2O3 Core/Shell Nanoparticles[END_REF][START_REF] Gavrilov-Isaac | Synthesis of Trimagnetic Multishell MnFe2O4@ CoFe2O4@NiFe2O4 Nanoparticles[END_REF] Although T B remains below room temperature, onion-type nanoparticles offer the potential to produce permanent magnets.

Here, we report on an original strategy to synthesize oniontype nanoparticles that are ferrimagnetic at room temperature and mainly consist of iron oxide with a mean size that does not exceed 16 nm. These nanoparticles consist of a core@shell@ shell structure, with a intermediate shell which mostly consists in Co-ferrite The significant enhancement of the magnetic properties at room temperature is ascribed to double interfacial exchange coupling at core/shell and shell/shell interfaces.

Nanoparticles were synthesized by a three-step thermal decomposition method. First, Fe 3-δ O 4 nanoparticles (C) were prepared by performing the thermal decomposition of iron stearate in dioctyl ether at 290 °C in the presence of oleic acid. Second, cobalt stearate was decomposed in octadecene at 310 °C in order to grow a CoO shell on the Fe 3-δ O 4 surface (CS). Third, iron stearate was again decomposed in order to grow a second shell of Fe 3-δ O 4 (CSS). Both shells were formed successively through a seed mediated growth by controlling carefully the synthesis conditions. Nanoparticles were isolated after each step in order to avoid any side reactions resulting from the presence of side products and remaining metal stearate.

Transmission electron microscopy (TEM) micrographs show the increase of the mean nanoparticle size after each decomposition step from 10.1 ± 1.1 nm (C), 14.0 ± 1.5 nm (CS) to 15.6 ± 2.3 nm (CSS), respectively (Figure 1a-d). Xray diffraction (XRD) patterns display typical peaks of the spinel structure (Figure 1e). Additional peaks corresponding to the wustite CoO phase were observed in the CS pattern and almost vanished in the CSS pattern. Furthermore, spinel peaks became narrower after each growth step which corresponds to the increase of larger crystal sizes (6.1 ± 0.1 Å (C), 7.9 ± 0.1 Å (CS) and 11.0 ± 0.1 Å (CSS)) and agree with larger nanoparticles. Energy-dispersive X-ray spectroscopy (EDX) analysis performed on several nanoparticles showed the presence of Co with a Fe:Co atomic ratio of 45:55 in CS which increased to 73:27 in CSS, consistent with the growth of a Fe-rich shell.

Furthermore, the scanning transmission electron microscopy electron energy loss spectroscopy (STEM-EELS) elemental mapping recorded at Fe-L and Co-L edges showed that Co is not homogeneously distributed across CSS nanoparticles (Figure 2b,d). This result was confirmed by EELS spectra recorded in different areas (Figure 2d,e) which show different Co content. STEM-EELS analysis on CS also showed that CoO seems to grow preferentially on specific facets of the Fe 3-δ O 4 core and resulted in an irregular shell shape (Figure S1). [START_REF] Liu | Systematic Study of Exchange Coupling in Core-Shell Fe3-DO4@CoO Nanoparticles[END_REF] This is consistent with the more faceted morphology of CS nanoparticles in comparison with C nanoparticles (Figure 1a,b). Nevertheless, the overall amount of CoO-rich phase is much lower in CSS than in CS as shown by XRD. Indeed, the CSS edge (area B) displays a Fe:Co ratio of 2.0 ± 0.3, consistent with a Co-doped ferrite.

STEM high-angle annular dark-field (HAADF) micrographs revealed lattice fringes across CSS (Figure 2a andS2) which agree with the high crystallinity of the spinel structure. A d spacing of 2.423 Å, consistent with the [222] direction and a cell parameter of 8.893 Å, were calculated from fast Fourier transform (FFT) (Figure S3). The doubling of lattice fringes was also observed in Co-rich areas with a d-spacing of 2.461 Å, consistent with the [111] direction of wustite CoO phase. The perfect interpenetration of fringes corresponding to spinel and wustite structures shows the good epitaxial relationship. Indeed, geometric phase analysis revealed a lattice expansion of 1-2% which agrees with the small lattice mismatch of 1.6% when crossing spinel wustite structures.

To confirm these results, we investigated the chemical composition of CSS and site occupancy of Fe and Co cations by performing X-ray magnetic circular dichroism (XMCD) measurements (Figure 3). [START_REF] Ohresser | A Beamline Dedicated to Dichroism Measurements in the 350-2500 EV Energy Range[END_REF] At the Fe-L 2,3 edge, peaks correspond to Fe 2+ and Fe 3+ cations in Oh sites (S1), Fe 3+ in Td sites (S2) and Fe 3+ in Oh sites (S3) of the ferrite spinel structure. The S1+S2/S2+S3 ratio (0.95) is intermediate to Fe 3 O 4 (1.27) and γ-Fe 2 O 3 (0.61). [START_REF] Sartori | Strong Interfacial Coupling through Exchange Interactions in Soft/Hard Core-Shell Nanoparticles as Function of Cationic Distribution[END_REF] It agrees with the low occupancy of Fe 2+ in Oh sites. At the Co-L 2,3 edge, a peak (S4) corresponds to Co 2+ in Oh sites of a Co-ferrite. [START_REF] Daffe | Magnetic Anisotropies and Cationic Distribution in CoFe2O4 Nanoparticles Prepared by Co-Precipitation Route: Influence of Particle Size and Stoichiometry[END_REF] Such an intense peak cannot be ascribed to the CoO AFM phase. Indeed, XMCD being sensitive to the polarization of magnetic moments, spins of Co 2+ which are coupled antiparallel in CoO cannot contribute to the signal.

The magnetic properties of the nanoparticles were studied by SQUID magnetometry. M(H) curves of CSS nanoparticles display a coercive field (H C ) of 500 Oe at 300 K in contrast to C and CS nanoparticles (H C = 0) (Figure 4b). This result was confirmed by M(T) curves (Figure S4) and the corresponding distribution of blocking temperatures (T B ) (Figure 4a), [START_REF] Lavorato | Tuning the Coercivity and Exchange Bias by Controlling the Interface Coupling in Bimagnetic Core/Shell Nanoparticles[END_REF][START_REF] Bruvera | Determination of the Blocking Temperature of Magnetic Nanoparticles: The Good, the Bad, and the Ugly[END_REF] i.e. the temperature below which the magnetic moments of nanoparticles are blocked. T B gradually increases with the formation of shells and clearly raises up above room temperature (340 K) for CSS. This value is much higher than the one of Fe 3-δ O 4 nanoparticles of 15 nm (150 K), [START_REF] Baaziz | Magnetic Iron Oxide Nanoparticles: Reproducible Tuning of the Size and Nanosized-Dependent Composition, Defects, and Spin Canting[END_REF] and is similar to smaller CoFe 2 O 4 nanoparticles of 12 nm. [START_REF] Song | Shape Control and Associated Magnetic Properties of Spinel Cobalt Ferrite Nanocrystals[END_REF] Given the lower Co-ferrite content in CSS and its larger size, it clearly shows that exchange coupling contributes to the enhancement of T B in CSS.

The FC M(H) curve recorded for CSS at 10 K after cooling under a field of 7 T showed a wide-open hysteresis cycle corresponding to H C of 15 000 Oe and a very small shift to negative fields corresponding to an exchange field (H E ) of 500 Oe. In contrast, a very large shift corresponding to H E of 5000 Oe was observed for CS which is ascribed to strong exchange bias coupling at the Fe 3-δ O 4 /CoO interface. [START_REF] Liu | Systematic Study of Exchange Coupling in Core-Shell Fe3-DO4@CoO Nanoparticles[END_REF][START_REF] Baaziz | High Exchange Bias in Fe3O4@CoO Core Shell Nanoparticles Synthesized by a One-Pot Seed-Mediated Growth Method[END_REF] Therefore, we expect that the contribution of this phenomenon to T B enhancement in CSS is negligible. It confirmed that the CoO shell, which is very thin at the surface of the Fe 3-δ O 4 core, mostly vanished in CSS and became Co-ferrite upon the third decomposition step. The smooth profiles of the M(H) curves agree with the strong exchange coupling of soft Fe 3-δ O 4 and hard Co-ferrite phases. It results in the nonsaturation of the M(H) curves in contrast to C which agree with the high magnetic anisotropy of exchange coupled nanoparticles. The magnetization of CSS at 7 T (72 emu/g), which is dramatically higher than that of CS (41 emu/g), also confirmed the transformation of CoO in Co-doped ferrite (M S for CoFe 2 O 4 nanoparticles is about 80 emu/g). [START_REF] Song | Shape Control and Associated Magnetic Properties of Spinel Cobalt Ferrite Nanocrystals[END_REF] It is worth noting that such a M S is even much higher than that of the Fe 3-δ O 4 core (56 emu/g), [START_REF] Baaziz | Magnetic Iron Oxide Nanoparticles: Reproducible Tuning of the Size and Nanosized-Dependent Composition, Defects, and Spin Canting[END_REF] thus increasing the energy product as required for permanent magnets.

In summary, we have reported on the synthesis of magnetic nanoparticles with an onion-type structure produced by a three-step thermal decomposition process. Besides each decomposition step resulted in the increase of the nanoparticle size, this study shows that the third step accelerated the conversion of the CoO in Co-ferrite. This is due to two different mechanisms promoted by the high temperature in the reaction medium: (i) the interdiffusion of Co and Fe cations at the Fe 3-δ O 4 /CoO interface promoted by vacancies at the Fe 3-δ O 4 core surface [START_REF] Lopez-Ortega | Strongly Exchange Coupled Inverse Ferrimagnetic Soft/Hard, MnxFe3-XO4/FexMn3-XO4, Core/Shell Heterostructured Nanoparticles[END_REF][START_REF] Sartori | Strong Interfacial Coupling through Exchange Interactions in Soft/Hard Core-Shell Nanoparticles as Function of Cationic Distribution[END_REF] and (ii) the solvation of CoO in the presence of Fe monomers (resulting from the third decomposition of Fe(Stea) 2 ) which led to Co-ferrite. [START_REF] Sytnyk | Tuning the Magnetic Properties of Metal Oxide Nanocrystal Heterostructures by Cation Exchange[END_REF] According to EDX performed on a large number of CSS nanoparticles, we expect the large amount of Fe monomers during the third decomposition step in comparison to solvated Co monomers to result in the growth of a second layer of Fe 3-δ O 4 after the formation of the CoFe 2 O 4 layer.

Therefore, we expect the CSS nanoparticles to consist of two Fe 3-δ O 4 /Co-doped ferrite and Co-doped ferrite/Fe 3-δ O 4 interfaces which both generate hard-soft exchange coupling. Such a CSS structure resulted in the significant enhancement of T B and H C which was not observed in previous works on trimagnetic type nanoparticles. Therefore, room temperature blocked magnetic nanoparticles mostly based on iron oxide with a size not exceeding 16 nm can be synthesized. Such a strategy opens huge perspectives for the design of rare-earthfree nanoparticles with tunable magnetic properties for a wide range of applications including high density data storage, therapeutics and sensors. Work is in progress to achieve a deeper understanding of the structure of CSS nanoparticles and the structure-property relationship.

Experimental details; TEM-HAADF, STEM-EELS and EELS analysis on CS; STEM and STEM-HAADF on CSS; STEM HAADF and FFT on selected area; details on FC-ZFC measurements; magnetization curve against a magnetic field of C, CS and CSS at 300 and 10 K; table of the magnetic characteristics of C, CS and CSS (PDF)

■ AUTHOR INFORMATION

Figure 1 .

 1 Figure 1. TEM micrographs of (a) C, (b) CS and (c) CSS nanoparticles. (d) Size distributions measured from TEM micrographs. (e) XRD patterns. Black and red bars correspond to the spinel structures (Fe 3 O 4 JCPDS card no. 19-062 and CoFe 2 O 4 JCPDS card no. 22-1086) and the CoO wustite structure (JCPDS card no. 70-2856), respectively.

Figure 2 .

 2 Figure 2. CSS nanoparticles. (a) Dark field STEM-HAADF micrograph. STEM-EELS micrographs : (b) composite image showing the distribution of Fe (red), Co (green) and O (blue) species, (c) Fe map, (d) Co map and (e) EELS spectra corresponding to different areas as selected in panel d.

Figure 3 .

 3 Figure 3. XMCD spectra of CSS nanoaprticles.

Figure 4 .

 4 Figure 4. Magnetic properties of C, CS and CSSC nanoparticles. (a) Distribution of blocking temperatures M(H) curves recorded at (b) 300 K (ZFC) and (c) 10 K (FC under 7 T).

  Corresponding Author *benoit.pichon@ipcms.unistra.fr ORCID Kevin Sartori: 0000-0002-4246-5856 Sylvie Begin-Colin: 0000-0002-2293-2226 Benoit P. Pichon: 0000-0003-3708-6461 Notes The authors declare no competing financial interest. ■ ACKNOWLEDGMENTS K.S. was supported by a Ph.D. grant from the French Agence Nationale de la Recherche (ANR) under the reference ANR-11-LABX-0058-NIE within the Investissement d'Avenir program ANR-10-IDEX-0002-02 and SOLEIL synchrotron/ Laboratoire León Brillouin fellowship. The authors are grateful to SOLEIL synchrotron for providing the access to DEIMOS beamline.