dataesr/scientific-paragraphs-categorization huggingface dataset:
Experiment procedures CsChrimson  (Klapoetke et al. , 2014)  was expressed under the control of driver lines targeting candidate valence-conveying neurons. These driver lines were classified based on expression pattern and previous functional data and are known to drive expression in larvae. Optogenetic activation of neurons (US) was paired with odour presentation (CS) to induce olfactory memory (Figure  4A ). For each driver line, data was acquired from at least two separate crosses. Classical conditioning followed a procedure similar to those described in Gerber and Hendel  (2006) , Saumweber et al. (2011) and Eschbach et al. (2020b). Approximately 40 third-instar larvae were transferred onto a 4% agarose petri dish. Larvae were presented with an odour (1:10 4 ethyl acetate in ddH 2 O) pipetted onto two pieces of filter paper attached to the lid of the dish.
Data analysis All data was manually entered into MATLAB and analysed using custom software. For each experiment, a performance index (PI) was calculated as follows: PIs take values between -1 and +1, where a positive PI reflects appetitive learning and a negative PI reflects aversive learning. Mean and standard error were calculated for each condition. Statistical differences between two groups were tested using a two-sided Mann-Whitney U test with Bonferroni correction. Significance compared to zero was tested with a two-sided Wilcoxon signed-rank test with Bonferroni correction. A simplified example is shown using a 10 x 10 pixel box containing a small object. a. The object (black) was detected against the background (white) using binary thresholding. Edge pixels were detected by combining the results of vertical and horizontal image convolution with a 2 x 1 XOR kernel using an OR operator.
Acknowledgments We thank  Dr. Chris McRaven  for design and technical assistance with the thermogenetic laser light source;  Howard Hughes Medical Institute (HHMI) Janelia FlyCore and FlyLight teams  for assistance with fly crosses, fly food, and confocal imaging;  Gates Cambridge Trust, Cambridge Trust ,  HHMI Janelia Visiting Scientist Program, University of Cambridge Trinity College, HHMI Janelia ,  European Research Council ,  Wellcome Trust , and  Medical Research Council  for funding.
Nowadays, the data used for decision-making come from a wide variety of sources which are difficult to manage using relational databases. To address this problem, many researchers have turned to Not only SQL (NoSQL) databases to provide scalability and flexibility for On-Line Analytical Processing (OLAP) systems. In this paper, we propose a set of formal rules to convert a multidimensional data model into a graph data model (MDM2G). These rules allow conventional star and snowflake schemas to fit into NoSQL graph databases. We apply the proposed rules to implement star-like and snowflake-like graph data warehouses. We compare their performances to similar relational ones focusing on the data model, dimensionality, and size. The experimental results show large differences between relational and graph implementations of a data warehouse.
As defined in  [2] , a data warehouse is a ''subject-oriented, integrated, time-variant and non-volatile collection of data in support of The associate editor coordinating the review of this manuscript and approving it for publication was Genoveffa Tortora. management's decision-making process and business intelligence''. Generally, a data warehouse is designed using a multidimensional data model that provides an understandable business view of the database  [3]. The implementation of a data warehouse involves applying a specific approach to convert its conceptual multidimensional data model into a target logic model  [4]. Several approaches have been proposed  [3] ,  [5] -  [7] , the most popular being Relational Online Analytical Processing (R-OLAP) which converts the conceptual multidimensional model into a relational one  [8]  using a star schema or a snowflake schema.
In the context of relational databases, the snowflake schema is known for being less efficient than the star schema due to the high cost of join operators  [9]. Undeniably, relational database management systems (RDBMS) have dominated the database management landscape since the 1970s mainly for storing and retrieving structured data. However, despite their maturity, the relational databases are currently facing many challenges as they were designed neither to provide good scalability and deal efficiently with a huge amount of data  [10] , nor to cope with unstructured data  [11]. Hence, to meet these needs, a new range of database management systems labeled as NoSQL (Not Only SQL), not based on relational models, has arisen. NoSQL systems have been mainly introduced to integrate large, unstructured and complex data generated from multiple sources such as social networks, interconnected devices, and sensors in order to make better decisions.
Generally, NoSQL databases are defined through a set of features which are mainly flexibility, high availability, scalability, and low-cost requirements  [12] ,  [13]. NoSQL systems are commonly classified into four main types depending on their logical model: key-value oriented stores, column-oriented stores, documentoriented stores, and graph-oriented stores  [14] -  [16]. The emergence of NoSQL systems has enriched the database management landscape. Consequently, the choice of which database to use has become harder than before. Over the last few years, many insightful research works have studied the effectiveness of using NoSQL systems to implement big data warehouses  [17] ,  [18]. Three major categories of approaches have been considered: column-based approaches, document-based approaches, and graph-based approaches.
These approaches allow transforming the conceptual multidimensional model of a data warehouse to a target NoSQL logical model using a set of transformation rules. Most of the proposed approaches focused on column-oriented  [19] -  [26]  and document-oriented  [27] -  [29]  NoSQL models. Some of them provided a performance evaluation based on some criteria such as read latency  [19] ,  [27]  and write latency  [27] ,  [28]. However, only few and recent studies considered the NoSQL graph-oriented model. They focused either on the performances of graph versus relational databases under various uses  [30] ,  [31] , or on designing graph data warehouses and defining graph OLAP operators (G-OLAP)  [32] -  [35]. However, to the best of our knowledge, the respective performances of graph implementations of normalized (snowflake) versus denormalized (star) data warehouses have not been evaluated yet.
In this paper, we present a new approach to convert a multidimensional data model to a graph database (MDM2G) which encompasses a set of transformation rules to convert star and snowflake relational multidimensional models to star-like and snowflake-like graph data models. We provide a formal definition for each model and we evaluate their performance to figure out whether a snowflake-like model would be highly time-consuming in the context of a graph database as it is in a relational database. In addition, we compare the performance of graph data warehouses to analogous relational star and snowflake logical models to determine whether a graph data warehouse could be more efficient than a relational one. Our motivation for investigating a graph database is its performance when dealing with connected data compared to relational databases and other NoSQL logical models  [36].
In fact, the join mechanism of relational databases is time consuming. Also, column-oriented and document-oriented databases lack relationships and require adapting their models to store and query complex data. On the contrary, graph databases store physical relationships that facilitate graph traversals between entities. The remaining of the paper is organized as follows: section 2 gives an overview of the proposed approaches in the literature for implementing NoSQL data warehouses; section 3 describes our approach which enables modeling data warehouses using graphs; section 4 details our experiments; section 5 reports and analyses our results. Our conclusions and research perspectives are presented in section 6.
One distinguishes between the parameters which are attributes defining the levels of granularity and the weak attributes which are informational attributes related to the parameters. These different levels make it possible to respond to different queries, depending on the analytical needs. A hierarchy allows ordering the parameters of a dimension according to their level of granularity or detail. Three approaches were proposed to build logical models suitable for a data warehouse: R-OLAP (Relational OLAP)  [3] ,  [5] , M-OLAP (Multidimensional OLAP)  [6]  and H-OLAP (Hybrid OLAP)  [7]  approaches. R-OLAP is the oldest and predominant storage strategy. It makes it possible to transform the concepts of fact and dimension of a multidimensional conceptual model into relational tables. Three multidimensional designs have been defined in this approach to simulate a multidimensional structure in a relational database, namely: star, snowflake, and constellation schema  [37] ,  [38].
A star schema includes a central fact table and many dimensions tables. This model represents the dimensions in a denormalized way. Each dimension table is joined to the fact table using its primary key, transformed in foreign key in the fact table. However, the dimensions are not joined together. A snowflake schema is an extension of the star schema in which some dimensions are hierarchical. It consists of keeping the same fact table and normalizing the dimension tables into sub-dimensions in order to allow a more explicit representation of the hierarchy. So, the dimensions are described through a succession of tables using foreign keys. A constellation schema involves several star schemas. Therefore, it contains many tables of fact and dimensions which could be shared or not. Obviously, a snowflake data model is more complex than a star data model.
In most cases, this complexity impacts the performance of the data warehouse as more join operations are required to answer queries. Since the arrival of NoSQL systems, many researchers have compared it to relational systems based on different requirements such as scalability  [10] ,  [30] ,  [38] ,  [39]. Further research works have focused on proposing approaches to allow data migration from relational databases to column NoSQL stores  [40] , document NoSQL stores  [41] -  [43]  or graph NoSQL stores  [30] ,  [44] ,  [45]. Recently, using NoSQL database management systems to implement big data warehouses able to gather voluminous and heterogeneous data to take better decisions have attracted researchers and organization. When looking at all the proposed approaches, three major categories can be identified: column-based approaches, document-based approaches, and graph-based approaches.
A. COLUMN-BASED APPROACHES These approaches allow data warehouses to be implemented under column-oriented NoSQL systems. In  [20] ,  [24]  authors have proposed a set of transformation rules to convert facts, measures, dimensions, and attributes to columnar concepts. More precisely, facts and dimensions are transformed into column families where measures and attributes are stored in columns. These studies considered the case of a star schema and did not consider hierarchies. In  [19] , the authors proposed three methods to enable the implementation of the columnar data warehouse. The first method allows the storage of facts and dimensions in the same column family. The second method stores facts and dimensions separately. Each fact table is transformed into a column family that contains measures as columns.
C. GRAPH-BASED APPROACHES Graph databases are composed of nodes and edges tagged with labels. Both nodes and edges can store properties by means of key/value pairs. In order to implement a graph data warehouse,  [32]  proposed to transform facts into nodes. The measures of each fact are stored as properties in the same node. Also, dimensions are transformed into nodes. There are two types of relations between nodes. The first type of relationship is labeled FACT which links fact to dimensions. The second type is labeled HIER which links the attributes of dimensions. This work focused on adapting Cypher query language to support OLAP operators mainly Slice, Dice and Roll up ones. Some experimental tests have been conducted to validate the proposed approach. However, the authors considered only the case of snowflake schema and did not study the effectiveness of the graph data warehouse especially when queries get more complex or the database gets larger.
In  [33] ,  [34] , the authors provide formal transformation rules to convert a multidimensional conceptual model into NoSQL graph-oriented model. Yet, the proposed data warehouses were not evaluated. The performances of relational versus graph databases were evaluated in  [30] ,  [31]  but not from an OLAP perspective with respect to normalized versus denormalized schemas. In the absence of performance evaluation of graph data warehouses and with increasing interests to graphs as a native tool to answer complex queries, we provide in this paper a new approach to convert a multidimensional data model to graph database (MDM2G) that we evaluate based on two metrics: write latency and read latency.
III. PROPOSED APPROACH: MULTIDIMENSIONAL DATA MODEL TO GRAPH DATABASE (MDM2G) The R-OLAP approach allows transforming the multidimensional data model of a data warehouse into relational logical models in the form of star or snowflake schemas. These relational logical models are automatically generated from conceptual models by applying a set of rules  [49]. Using these transformation rules in the context of big data has  VOLUME 10, 2022  many weaknesses ascribed to the limitations of the relational data model mainly when queries require multiple complex aggregations. To address this problem, we propose converting the multidimensional data model of a data warehouse to a graph database (MDM2G) by mapping the concepts of the multidimensional data model (facts, dimensions, etc. ) into graph concepts.
B. PROPERTY GRAPH DATA MODEL The target model of our transformation rules is a property graph model. Graph data models have arisen since the eighties, but their popularity gradually decreased with the emergence of other data models, especially the geographical, spatial, semi-structured and XML  [51]. Recently, graph databases have regained the attention of both academics and business entities due to the ever-increasing need to store, process, manage and analyze graph-like structures such as social networks  [52] ,  [53] , biological networks  [54] -  [56] , and document networks  [57] ,  [58]. Indeed, graph databases are considered as one of the most useful structures and natural ways for modeling interactions between the objects of a network  [9]. Many graph database management systems are available today such as Neo4j  [36]  and GraphDB  [59].
A database schema as well as instances in this model are a labeled directed graph, where the nodes represent objects and edges represent the connections between them. Whereas relational databases require expensive join operations to answer complex queries, graph databases consider the relationships between entities as important as the entities themselves  [60]  which facilitates the navigation between entities. From a conceptual view, there are two graph data models: the property graph (PG) allowing both nodes (vertices) and edges to have any number of arbitrary properties and the Resource Description Framework (RDF) originally designed to represent information about resources on the World Wide Web. The most used model is the property graph model  [36]. Informally, a PG is a directed labeled graph where data is represented by means of nodes, edges, and properties (key-value pairs).
C. MDM2G: STAR-LIKE SCHEMA In the context of relational databases, the star design transforms each fact of the multidimensional conceptual model to a relational fact table. The fact table contains measures as columns. In addition, each dimension is converted to a denormalized dimension table which contains all the attributes (parameters and weak attributes) as columns. Each instance of fact and dimension tables is stored in a specific row. In the same way, we use the previously mentioned definitions of multidimensional model and property graph concepts to propose our transformation rules which define a star-like graph schema. Transformation 1: Each multidimensional data model MDM(F MDM , D MDM , Star MDM ) is transformed into a multidimensional graph data model MGD(N MGD , E MGD , ρ MGD , λ MGD , σ MGD ) where: • N MGD ={n 1 ,.
Hence, hierarchies are not taken into consideration, • An edge is defined between each source fact node N F i and target parameter nodesN D i using the the function ρ MGD. This rule creates for each dimension as many nodes as its instances. The figure  1  illustrates the transformation of dimensions and their attributes. In our example, the dimension ''Customer'' is transformed into a set of nodes having the same label ''Customer''. All the attributes which give details about customers are transformed into properties in the ''Customer'' nodes. In this transformation, all the nodes of the dimensions are directly linked to the fact nodes using edges. Hence, the star-like schema allows querying the multidimensional graph data model using one-level graph traversals. In this case, the depth, which is the number of paths between a fact node and a dimension node, is equal to one.
D. MDM2G: SNOWFLAKE-LIKE SCHEMA In contrast to the star data model where all the parameters are grouped in a single denormalized dimension table, the snowflake data model allows representing hierarchies using several sub-dimensions which are smaller and normalized relational tables. Hence, we propose a snowflake-like multidimensional schema based on graph databases. We keep the first two transformation rules mentioned above and we add two other rules which allow representing hierarchies in graph databases as follows: Transformation 4: Each dimension D i (Name D i , A D i , H D i ) ∈ D MDM is transformed into a set of dimension nodes defined by (Name D i MGD , A D i MGD , H D i MGD ) where: • Name D i MGD is the name of the dimension D i associated with the function λ MGD as a label to the dimension nodes N D i , • A D i MGD is a set parameters and weak attributes of the dimension D i.
IV. EXPERIMENTS Our experiments have mostly three goals. The first one is to validate our approach by applying the proposed transformation rules to implement a star-like and snowflake-like data warehouses. The second goal is to compare the performance of the proposed graph data warehouses to analogous relational data warehouses implemented using the traditional R-OLAP approach: Intra-Model comparison. The third goal is to evaluate the effectiveness of the star and snowflake data designs in the context of graph warehouses to find out whether a snowflake-like graph data model would be less efficient than a star-like data model: Inter-Model comparison. Our comparison is made while taking into account the data model, data dimensionality and data size. To achieve the above-mentioned goals, we use Neo4j (version 3.
5. 0), a graph database written in Java. It is queried through the cypher query language. We use Neo4j to write our transformation rules and implement the starlike and snowflake-like graph data warehouses. To compare these latter to relational data warehouses, we use MariaDB (version 10. 1. 38) as a relational database. These data warehouses were deployed under a virtual machine with 32 GB of RAM and 8TB disk. The virtual machine runs under the 64-bit Ubuntu-18. 04. 01 LTS operating system. No index was added, in any DBMS, because we assume filtering can concern all columns in an OLAP context, where the users make new queries regularly. The caches were cleared before each query in order to make sure the run time corresponds to the first time a query is asked. In an OLAP context, the users run new queries rather than repeating the same ones.
The TPC-DS data generator named DSDGEN generates for each entity (fact or dimension) a separate data file. These data files scale by means of scale factors (SF) that represent the data size in Gigabyte. In this work, we generated data according to four different scale factors SF1, SF3, SF5 and SF7 which are respectively 1GB, 3GB, 5GB, and 7GB. Whereas the fact table scales linearly with the scale factor, the non-static dimension tables scale sub-linearly. However, the data in static dimension tables such as date and time dimensions are loaded once and are not updated during the data maintenance phase  [63]. Table  1  shows the number of rows generated for each table of the chosen snowflake schema.
B. DATA MODEL As mentioned earlier, TPC-DS involves multiple snowflake schemas. In the chosen snowflake schema, data related to customers are hierarchically decomposed into different tables related with one-to-many relationships. In order to compare the performance of the snowflake design to the star design in the context of a graph data warehouse, we denormalized the dimension customer and its related tables using many left-joins to obtain a large table named ''Customer_Details'' which contains all the details about customers (customer demographics, household demographics, income band and customer address). In addition, we slightly modified the data model of TPC-DS to get pure snowflake and star designs as shown in Figure  3. More precisely, we deleted the columns that reference customer address, customer demographics and household demographics in the table Store_Sales.
C. QUERIES TPC-DS query generator QGEN allows generating queries according to different templates. In our experiments, we selected nine different queries that belong to the chosen snowflake (store sales channel). Theses nine queries can be grouped into three main categories as presented in Table  2. The first category is made up of five non-hierarchical queries that do not involve hierarchies. Therefore, it is obvious that the customer table is not used in these queries. More precisely, all the tables queried are directly related to the fact table Store_Sales. For instance, the query Q3, cf. Table  3 , computes the total rebate amount per item brand of the manufacturer 427 for all sales that took place in November. From a relational database perspective, this query requires different joins to get data from the tables item, Store_Sales and date_dim.
However, in a graph database all these joins are replaced with relationships. In the same category, we also distinguish the query Q28 which is not only non-hierarchical but also flat since only the fact table is used in this query and no dimension is queried. As shown in Table  4 , Q28 calculates the average list price, the number of list prices and the number of distinct list prices of six different sales buckets of the store sales channel. Each bucket is defined by a range of distinct items and information about list price, coupon amount and wholesale cost. The non-hierarchical category of queries is used to compare performance of graph versus relational model since their star and snowflakes variants are identical. The second category consists of 2 hierarchical queries which are executed to answer complex questions.