Abstract:
Disclosed is a system allowing to query data warehouses using SPARQL. An aspect of the system may support the representation of multidimensional data as virtual graphs. Another aspect of the system may provide mapping of SPARQL queries directed against multidimensional data vis-à-vis the graphs to native queries directed against the multidimensional data. Responses from the native queries may then be translated to a SPARQL response format.

Description:
BACKGROUND 
       [0001]    Unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section. 
         [0002]    The development of the Semantic Web has put considerable focus on data and the relationships between data on the Web. In the vision of the Semantic Web, data should be shared and reused across application, enterprise, and community boundaries. Relationships among data on the Web should also be made available to create a Web of Data. In recent years, we have witnessed an explosion in the amount of interrelated data on the Web, also called Linked Data. For example, governments have launched major initiatives to publish a variety of public data in open and reusable formats. There are potential benefits for companies to augment their analytics and reporting tools with these datasets. It can provide them with greater insights. As a result, companies will ultimately make better business decisions and generally gain greater competitive advantage. 
         [0003]    Nowadays, most large companies and governmental organizations rely on massive data warehouses to store the ever increasing volume of enterprise data that they have accumulated over the years. Multidimensional data stores provide indeed greater processing potential and complex data models facilitating advanced analysis. There is much work on mapping relational data to the Semantic Web. They typically reveal the structures encoded in relational databases by exposing their content as RDF Linked Data. By comparison, very little effort has been made to interface multidimensional data to the Semantic Web. Existing efforts either materialize Linked Data into data warehouses, or directly issue queries against triple stores using non-standardized vocabularies. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0004]      FIG. 1  is a high level block diagram of a system in accordance with the present disclosure. 
           [0005]      FIG. 2A  illustrates a workflow for generating a mapping. 
           [0006]      FIG. 2B  illustrates a workflow for processing a SPARQL query in accordance with the present disclosure. 
           [0007]      FIGS. 3A-3H  illustrate an example of processing a query against a multidimensional database according to principles of the present disclosure. 
           [0008]      FIG. 4  shows an illustrative implementation in accordance with the present disclosure. 
       
    
    
     DETAILED DESCRIPTION 
       [0009]    Referring to  FIG. 1 , in accordance with the present disclosure, a query mapping system  100  may provide a client  12  access to a multidimensional database  10  using the SPARQL Protocol and RDF Query Language (SPARQL). The resource description framework (RDF) is a way of expressing the properties of items of data using triples (3-tuple) in the form of subject-predicate-object. Two related items of data may be denoted as the subject and the object. The predicate denotes traits or aspects of the data and expresses a relationship between a subject and an object. For example, the notion “John works in France” may be expressed in RDF by denoting “John” as the subject, denoting “works in” as the predicate, and “France” as the object. 
         [0010]    In some embodiments, the client  12  may be a user accessing web services (e.g., via a web browser) that provide access to the multidimensional database  10  using the query mapping system  100 . The client  12  may input SPARQL queries against the multidimensional database  10 . 
         [0011]    In some embodiments, the multidimensional database  10  may implement a data warehouse for OnLine Analytical Processing (OLAP). A data warehouse is a database that is specialized in storing and analyzing large amounts of data. An enterprise may deploy a data warehouse to store and analyze the vast amounts of data that they accumulate over the years. Typically, data in the data warehouse can come from different operational systems  14  within the enterprise, for example, a Customer Relationship Management (CRM) system, Enterprise Resource Planning (ERP) system(s), etc. The operational systems  14  typically keep only fresh data (e.g., data is collected and replaced daily, monthly, etc.), while the data warehouse collects and accumulates the data from the operational systems as historical data. Data from the different operational systems  14  come in various forms, and so they typically need to be processed before being moved to the warehouse. This process is referred to as Extract, Transform, and Load (ETL) processing. 
         [0012]    The multidimensional database  10  represents data using a dimensional data model, which is characterized by the use of “data cubes” to represent the dimensions of data available to a user. For example, “sales revenue” could be viewed as a function of product model (different product models have different sales prices), geography (sale price may vary according to where the product is sold), time (sale price may depend on when the product is sold, e.g., during the holidays vs. off-holiday sales), and so on. In this case, “sales revenue” is known as the measure attribute of the data cube and the product model, geography, and time are known as the dimension attributes of the data cube. It can be appreciated that a measure may be a function of fewer than three or more than three dimensions, and so the more abstract term of “data hypercube” may be used. There is no formal way of deciding which attributes should be made dimensions and which attributes should be made measures. Such decisions are specific to the data being modeled, who will use the data model, how the data model will be used, and so on, and thus are made during the specification and design phases of the database. 
         [0013]    Dimensions may be associated with hierarchies that specify aggregation levels, and hence granularity in how the data may be viewed. For example, a “date” dimension in a data cube may have the following hierarchy: day→month→quarter→year. Similarly, a “location” dimension in the data cube may have the following hierarchy: city→county→state→country→continent. 
         [0014]    As explained above, the multidimensional database  10  is characterized in that the multidimensional database represents data using a dimensional data model paradigm. In terms of specific embodiments, the multidimensional database  10  may be implemented using any suitable database design. For example, the multidimensional database  10  may be based on the star schema, where the measure attribute may be derived from the fact table component of the star schema and the dimension attributes may be derived from the dimension tables component of the star schema. In other examples, the multidimensional database  10  may be based on the snowflake schema, and so on. The underlying database technology may be any suitable technology. For example, in some embodiments, the multidimensional database  10  may be built on a relational database using Structured Query Language (SQL) as its native query language. In other embodiments, an OLAP type database using the Multidimensional Expressions (MDX) language may be the underlying database technology. In still other embodiments, the underlying database may support several query languages natively. For example, in some embodiments, the multidimensional database  10  may support Structured Query Language (SQL). In other embodiments, the multidimensional database  10  may support both SQL and MDX. 
         [0015]    Continuing with  FIG. 1 , the query mapping system  100  may comprise a mapping generator  102  and a query translator  104 . The mapping generator  102  may automatically extract information from metadata comprising the multidimensional database  10  to create a mapping  106 . The mapping generator  102  may comprise model extractor  122  and a vocabulary mapper  124 . 
         [0016]    The query translator  104  may interpret the mapping  106  to translate SPARQL queries  114   a  received from client  12  into a native query  114   b  that is expressed in the native query language of the multidimensional database  10 . For example, if the underlying database of the multidimensional database  10  is a relational database, then the native query language may be a form of SQL. The query translator  104  may comprise a query parser  142  and a query translation engine  144  to direct a SPARQL query  114   a  received from the client  12  against the multidimensional database  10  in the form of native query  114   b.  The query translator  104  may further comprise a results parser  146  and a results generator  148  to provide responses  116   b  from the multidimensional database  10  and provide them to the client  12  in the form of a SPARQL response  116   a.    
         [0017]    A SPARQL endpoint  112  may provide an interface to the query mapping system  100 . The SPARQL endpoint  112  may receive SPARQL queries  114   a  from the client  12  and provide SPARQL responses  116   a  to the client via the HyperText Transport Protocol (HTTP). In some embodiments, the SPARQL endpoint  112  may enable clients to execute SPARQL queries against an RDF dataset. 
         [0018]    An observation worth noting is that there is no duplication of the actual data that is stored in the multidimensional database  10 . For example, the mapping  106  that is generated using the metadata describes the structure (e.g., table names of fact and dimension tables, data field names, data types, and so on) of the multidimensional database  10 , but does not otherwise include the actual data that are stored by the multidimensional database. As will be explained below, the mapping  106  is used to translate the SPARQL query  114   a  to produce a native query  114   b  that is executed against the multidimensional database  10 . By virtue of generating native query  114   b,  the query mapping system  100  avoids the need to duplicate the data stored in the multidimensional database since the native query is being executed against the multidimensional database itself. 
         [0019]    The discussion will now turn to a description of a workflow in the mapping generator  102  and the query translator  104  in accordance with principles of the present disclosure.  FIGS. 2A and 2B  illustrate workflows in accordance with some embodiments. The workflow will be explained in the context of an illustrative example shown in  FIGS. 3A-3H . 
         [0020]    Referring to  FIG. 3A , an example is based on the Business Intelligence Use Case of the Berlin SPARQL Benchmark (BSBM), expressed as a relational schema. The Business Intelligence Use Case uses a dataset  300  that is built around an e-commerce scenario, where a set of products is offered by different vendors and different consumers have posted reviews about products. The dataset  300  contains information about products, their producers, their reviews, and the corresponding reviewers. 
         [0021]      FIG. 3B  shows a multidimensional database  30  that can be built from the BSBM dataset  300 . The multidimensional database  30  is configured as a star schema and comprises a fact table  32  containing a measure review_nr, and links  32   a  to dimension tables  34 ,  36 . The Product dimension table  34  and Person dimension table  34  are two shared dimensions that consist of a subset of columns of interest from different tables of the dataset  300  and define the join between the tables. It is noted that the dataset  300  is not part of the multidimensional database  30 . The dataset  300  was used merely as a convenient source of data for building the multidimensional database  30  for testing purposes, but is not otherwise an aspect of the present disclosure. 
         [0022]      FIG. 3C  illustrates an example of a query  114   a,  expressed in SPARQL, that the SPARQL client  12  may issue. The query  114   a  may be executed against the multidimensional database  30 , which searches for the top ten most discussed French product types in the U.S. based on the number of reviews in France. 
         [0023]    Referring now to  FIGS. 2A ,  3 A, and  3 B, in some embodiments, the mapping generator  102  may perform in accordance with the following workflow. As there are many implementations of multidimensional databases, a common representation may be used. Accordingly, at block  202 , the model extractor  122  may communicate with the multidimensional database  30  to extract metadata from the multidimensional database and from the dataset  300 , such as names of the columns and their roles as dimension or measure. The metadata may be stored in an internal model  106   a.  The metadata may describe various database objects comprising the multidimensional database  30  and dataset  300 . As explained above, the metadata which describes the multidimensional database  30  should not be confused with the data that is stored in the multidimensional database. The term “metadata”, in the context of the database arts, is a commonly used term in the database arts, and is well understood by those of ordinary skill in the database arts as referring to data that describes the structure and organization of a database such as multidimensional database  30 . For example, the database objects (i.e., structure and organization) of the multidimensional database  30  may include dimensions of a data cube, measures of the data cube, schema names, table names, column names, their attributes (e.g., integer, text, data size, etc.), and so on, depending on the particular implementation of the multidimensional database. In terms of the examples shown in  FIGS. 3A and 3B , the metadata include review_nr, reviewer, product, person_nr, person_country, product_nr, productType, producer, and producer_country. 
         [0024]    At block  204 , the model extractor  122  may build an internal model  106   a  of the multidimensional database  30  using metadata extracted from the multidimensional database. The internal model  106   a  may model data objects comprising the multidimensional database  30 . In an embodiment, for example, the internal model  106   a  may be expressed using RDF to represent the correspondence between database objects comprising the multidimensional database  30  and RDF triples that represent those database objects. The internal model  106   a  may include the following, for example:
       A reference to identify the source of the data (e.g., dataset  300  and multidimensional database  30 ).   A list of measures with their name, URI (built from package name, cube name and column name).   A list of dimensions with their name, URI (built from package name, cube name and column name).       
 
         [0028]    In the example in  FIGS. 3A and 3B , the following metadata may be used:
       Datasetref: BSBM, Q1   Measures: review_nr   Dimensions: person_nr, person_country, product_nr, productType, producer, and producer_country
 
It will be appreciated that the model extractor  122  may be specific to each database implementation, and that each implementation may require its own model extractor.
       
 
         [0032]    In accordance with the present disclosure, the mappings model  106  specifies how the entities of each cube, e.g., axis for dimensions and attributes, and cell type for measures, are mapped to RDF classes and properties. Subsequently, mapping model also specifies how values from the multidimensional dataset, e.g., cube cells, will be mapped to RDF observations by the query translator at query time. Since observations comply to the &lt;subject, predicate, object&gt; triple model, the mapping generator  102  will typically map the fact table values to subjects in the observations, generate predicate mappings with resource as object for proper dimensions, and predicate mappings with literal as object for flattened attributes (in the above example producer_country or person_country). Subsequently, at query time the query translator  104  will produce one observation for each tuple in the fact table, references to other resources for dimensions values (axis position of the cube cell) and literal values for flattened attributes (either of the current fact or of an arbitrary dimension). 
         [0033]    At block  206 , the vocabulary mapper  124  may serialize the internal model  106   a  in a mapping language with a target vocabulary. In some embodiments, the mapping language may be R2RML or D2RQ Mapping Language, for example.  FIG. 3D  illustrates an example showing a portion of an R2RML mapping that may be generated for the query  114   a.  For the multidimensional data itself, the target vocabularies may be the RDF Data Cube Vocabulary (QB), the Open Cube Vocabulary (OC), or QB4OLAP, for example. The result is the mapping  106 , which may be stored in a suitable datastore (not shown) that can be accessed by the query translator  104 .  FIG. 3E  illustrates an example of a portion of mapping  106  generated from the R2RML mapping of  FIG. 3D . As will be explained in connection with  FIG. 2B , the mapping  106  will be used at query time to produce SPARQL results. 
         [0034]    Referring now to FIGS.  2 B and  3 C- 3 H, in some embodiments, the query translator  104  may perform in accordance with the following workflow. At block  212 , the endpoint  112  may receive a query  114   a  from client  12 . As illustrated in  FIG. 1 , the query  114   a  may be expressed in SPARQL, an example of which is shown in  FIG. 3C . 
         [0035]    At block  214 , the query parser  142  may parse the query  114   a  to verify for proper syntax. In an embodiment, for example, the query parser  142  may implement the SPARQL 1.1 syntax. 
         [0036]    If the query  114   a  has proper syntax, then the query parser  142  may pass the query to the translation engine  144 . Thus, at block  216 , the translation engine  144  may use the mapping  106  to translate the query  114   a  to produce a corresponding query  114   b  that is expressed in the native language (e.g., SQL, MDX, etc.) of the multidimensional database  30 .  FIG. 3F  illustrates an example of SQL query  114   b  obtained by translating the SPARQL query  114   a  in accordance with principles of the present disclosure. 
         [0037]    At block  218 , the translation engine  144  may execute the query  114   b  against the multidimensional database  10 , for example, by sending the query  114   b  to the multidimensional database. In accordance with principles of the present disclosure, the SPARQL query  114   a  is not issued on the multidimensional database  30 . In fact, there is no database against which the SPARQL query is executed. Instead, a native query  114   b  that corresponds to the SPARQL query  114   a  is generated and issued on the multidimensional database  10  to obtain the information that is requested in the SPARQL query. 
         [0038]    At block  220 , the multidimensional database  10  may produce a result  116   b  in response to the query  114   b.  A at block  222 , the results parser  146  may receive the result  116   b  and parse the results to identify the syntactic elements in the results  116   b.    FIG. 3F  illustrates an example of results  116   b.    FIG. 3G  illustrates an example of result  116   b.    
         [0039]    At block  224 , the results translator  148  may receive the parsed results from the results parser  220  and translate the parsed results in a SPARQL format to produce SPARQL results  116   a.  For example, the SPARQL results  116   a  may be expressed in a machine-processable format such as an XML-based SPARQL Results Document, using JavaScript Object Notation (JSON), or in a comma-separated values (CSV) format, a tab-separated values (TSV) format, a serialized RDF graph, and so on.  FIG. 3H  illustrates an example of SPARQL results  116   a.    
         [0040]    Referring to  FIG. 4 , an illustrative implementation of the query mapping system  100  may include a computer system  402  having a processing unit  412 , a system memory  414 , and a system bus  411 . The system bus  411  may connect various system components including, but not limited to, the processing unit  412 , the system memory  414 , an internal data storage device  416 , and a communication interface  413 . 
         [0041]    The processing unit  412  may comprise a single-processor configuration, or may be a multi-processor architecture. The system memory  414  may include read-only memory (ROM) and random access memory (RAM). The internal data storage device  416  may be an internal hard disk drive (HDD), a magnetic floppy disk drive (FDD, e.g., to read from or write to a removable diskette), an optical disk drive  1020  (e.g., for reading a CD-ROM disk, or to read from or write to other high capacity optical media such as the DVD, and so on). In a configuration where the computer system  402  is a mobile device, the internal data storage  416  may be a flash drive. 
         [0042]    The internal data storage device  416  and its associated non-transitory computer-readable media provide nonvolatile storage of data, data structures, computer-executable instructions, and so forth. Although the description of computer-readable media above refers to a HDD, a removable magnetic diskette, and a removable optical media such as a CD or DVD, it is noted that other types of media which are readable by a computer, such as zip drives, magnetic cassettes, flash memory cards, cartridges, and the like, may also be used, and further, that any such media may contain computer-executable instructions for performing the methods disclosed herein. 
         [0043]    The system memory  414  and/or the internal data storage device  416  may store a number of program modules, including an operating system  432 , one or more application programs  434 , program data  436 , and other program/system modules  438 . Application program  422  may comprise the mapping generator  102  and application  424  may comprise the query translator  104 . For example, in a specific embodiment, the multidimensional database  10  is the SAP HANA® DB product and objects (e.g., multidimensional models) in the multidimensional database include Attribute Views and Analytic Views, and the query language is SQL. The application program  424  may be implemented in Java, using HANA&#39;s JDBC driver, as well as the HANA Modeler System Developer Kit (SDK). The SDK is a Java library enabling creation and modification of HANA Views. HANA&#39;s Attribute and Analytic Views provide a high-level interface for the data of interest, so the SQL queries to be generated are relatively simple, although the calculations are complex. Indeed, a query of the form SELECT* over an Analytic View reveals that the View can be seen as a simple SQL View, with some limitations but higher performance. The Modeler SDK provides the extraction of the metadata from the multidimensional database  10  needed to create the mapping  106 , namely the names of the virtual columns in the Views, their roles as a dimension or a measure, and so on. 
         [0044]    Access to the computer system  402  may be provided by a suitable input device  444  (e.g., keyboard, mouse, touch pad, etc.) and a suitable output device  446 , (e.g., display screen). In a configuration where the computer system  402  is a mobile device, input and output may be provided by a touch sensitive display. 
         [0045]    The computer system  402  may operate in a networked environment using logical connections via wired and/or wireless communications to one or more remote computers (not shown) over a communication network  452 . The communication network  452  may be a local area network (LAN) and/or larger networks, such as a wide area network (WAN). 
         [0046]    The above description illustrates various embodiments of the present invention along with examples of how aspects of the particular embodiments may be implemented. The above examples should not be deemed to be the only embodiments, and are presented to illustrate the flexibility and advantages of the particular embodiments as defined by the following claims. Based on the above disclosure and the following claims, other arrangements, embodiments, implementations and equivalents may be employed without departing from the scope of the present disclosure as defined by the claims.