Patent Description:
Relational databases managed by relational database management systems (RDBMS) are the most popular way to store structured data. In relational databases, data is organized in the form of tables comprising rows and columns.

A graph is a structure (diagram) comprising entities called vertices (or nodes or points) and edges (or links or relationships), wherein the edges (or links or relationships) are related pairs of vertices. In the Property Graph Model, data is organized as nodes, relationships, and properties, wherein the properties are data values stored on the nodes or relationships. By converting relational data into a property graph, it is possible to explore (traverse) the relationships between the entities (rows) and to analyze the underlying network topology.

Querying graphs on existing relational data is usually done using one of the following three approaches.

According to a first approach illustrated in <FIG>, a graph query engine <NUM> extracts, in response to a graph query <NUM>, relational data directly from a database <NUM>. The graph query engine <NUM> transforms rows of the extracted relational data into vertices and edges of a graph on-the-fly using a conceptual schema mapping <NUM>. The conceptual schema mapping <NUM> defines a relationship between the relational schema, i.e. the structure of the data in the relational database in the form of tables with rows and columns, and the graph schema, i.e. the structure of the data in the graph in the form of vertices, edges and properties. Finally, the graph query engine <NUM> provides query results <NUM> of the graph query <NUM>.

According to a second approach illustrated in <FIG>, an extract-transform-load (ETL) process <NUM> reads relational data from a database <NUM> and, by using a conceptual schema mapping <NUM>, generates and stores inferred vertices and edges into a graph database or graph storage <NUM>. In response to a graph query <NUM>, the graph query engine <NUM> then reads vertices and edges directly from the generated graph stored in the graph storage <NUM> and provides query results <NUM> of the graph query <NUM>.

According to a third approach illustrated in <FIG>, a synchronization engine <NUM> maintains a graph database or graph storage <NUM> that is always updated with the latest changes of the relational data in the database <NUM> by using a conceptual schema mapping <NUM>. In response to a graph query <NUM>, the graph query engine <NUM> reads vertices and edges directly from the graph provided by the graph database <NUM> as in the second approach described above and provides query results <NUM> of the graph query <NUM>.

As will be appreciated, the third approach is more sophisticated and, thus, more difficult to implement than the second approach, while the second approach, in turn, is more sophisticated and, thus, more difficult to implement than the first approach. Moreover, while the first approach is capable of reading, transforming, and querying data on-the-fly, the other two approaches require the materialization of the generated graph data into an extra graph repository <NUM>, <NUM>, which, in practical terms, means a duplication of the data storage capacities.

Similar to the above three approaches, document <CIT> discloses a mapping process that prepares for and executes a graph query against a relational database, wherein a mapping of relational tables to node tables and edge tables that define a graph is received, and based on an execution of a query of the graph, values of desired columns/rows of desired node tables are returned.

Besides, current approaches only employ simple schema mapping with vertices and edges directly mapped in a one-to-one relationship to rows of relational tables. Thus, the above approaches have one or more of the following disadvantages: (i) the relational data has to be duplicated into the graph storage; (ii) the extraction and synchronization (for providing consistency) between relational and graph data takes time and does not allow for real-time processing of the latest updates; and/or (iii) the schema mapping used in current approaches is very simple and often not very useful in practical terms. Moreover, with the current approaches, when designing a database, it is necessary to use and implement simple relational models that can be easily mapped to a graph model, or to prepare sophisticated ETL procedures that are executed periodically to convert relational data into graph entities.

It is an objective of the present disclosure to provide an improved database management system and method.

The foregoing and other objectives are achieved by the subject matter of the independent claims. Further implementation forms are apparent from the dependent claims, the description, and the figures.

According to a first aspect, a database management system for managing a database is provided. The database management system comprises a processor configured to receive a definition of at least one of a graph vertex and a graph edge of data of the database, generate a schema mapping rule, based on the definition of the at least one of the graph vertex and the graph edge of the data of the database, wherein the schema mapping rule defines a correspondence between the data of the database and a graph representation of the data of the database, wherein the graph representation includes the at least one of the graph vertex and the graph edge of the data of the database, and generate, based on the schema mapping rule, a database query for extracting one or more further graph vertices and/or graph edges of the data of the database.

As used herein and as will be described in more detail below, a definition of a graph vertex and/or a graph edge of the data of the database may comprise one or more instructions allowing the database management system to generate one or more graph vertices and/or graph edges from the data of the database.

In a further possible implementation form of the first aspect, the processor is further configured to generate the schema mapping rule as a conjunctive and/or disjunctive combination of one or more predicates.

In a further possible implementation form of the first aspect, the processor is further configured to store the database query in a database catalog of the database.

In a further possible implementation form of the first aspect, the processor of the database management system is further configured to extract the one or more further graph vertices and/or graph edges of the data of the database based on the database query stored in the database catalog. Advantageously, this allows extracting non-explicit information hidden in the relational representation of the data of the database.

In a further possible implementation form of the first aspect, the processor is further configured to provide a programming interface, wherein the programming interface is configured to receive one or more programming instructions for at least one of extracting the data from the database and/or defining the at least one of the graph vertex and the graph edge of the data of the database.

In a further possible implementation form of the first aspect, the one or more programming instructions of the programming interface comprises a first programming instruction (herein referred to as a "MATCH" instruction) for extracting the data from the database or from the graph representation of the data of the database.

In a further possible implementation form of the first aspect, the first programming instruction for extracting data from the database, i.e. the "MATCH" instruction is configured to define the at least one of the graph vertex and the graph edge of the data of the database by recursive reference to the schema mapping rule. In other words, the output of a "MATCH" instruction can be the input of another "MATCH" instruction.

In a further possible implementation form of the first aspect, the one or more programming instructions of the programming interface comprises a second programming instruction (herein referred to as a "COMPARE" instruction) for filtering the data of the database on the basis of one or more comparison predicates.

In a further possible implementation form of the first aspect, the one or more programming instructions of the programming interface comprises a third programming instruction (herein referred to as an "AGGREGATE" instruction) for determining one or more aggregate functions over the data of the database.

In a further possible implementation form of the first aspect, the one or more programming instructions of the programming interface comprises a fourth programming instruction (herein referred to as a "EXCEPT" instruction) for discarding or filtering the data of the database matching one or more criteria.

In a further possible implementation form of the first aspect, the one or more programming instructions of the programming interface comprises a fifth programming instruction (herein referred to as a "EVAL" instruction) for evaluating one or more pre-defined functions or predicates.

In a further possible implementation form of the first aspect, the database management system further comprises the database.

According to a second aspect, a method for managing a database is provided. The method comprises the steps of receiving a definition of at least one of a graph vertex and a graph edge of data of the database, generating a schema mapping rule, based on the definition of the at least one of the graph vertex and the graph edge of the data of the database, wherein the schema mapping rule defines a correspondence between the data of the database and a graph representation of the data of the database, wherein the graph representation includes the at least one of the graph vertex and the graph edge of the data of the database, and generating, based on the schema mapping rule, a database query for extracting one or more further graph vertices and/or graph edges of the data of the database.

In a further possible implementation form of the second aspect, the step of generating the schema mapping rule comprises generating the schema mapping rule as a conjunctive and/or disjunctive combination of one or more predicates.

In a further possible implementation form of the second aspect, the method further comprises the step of storing the database query in a database catalog of the database.

In a further possible implementation form of the second aspect, the method comprises the further step of extracting the one or more further graph vertices and/or graph edges of the data of the database based on the database query stored in the database catalog.

In a further possible implementation form of the second aspect, the method further comprises a step of providing a programming interface, wherein the programming interface is configured to receive one or more programming instructions for defining the at least one of the graph vertex and the graph edge of the data of the database.

The database management method according to the second aspect of the present disclosure can be performed by the database management system according to the first aspect of the present disclosure. Thus, further features of the data management method according to the second aspect of the present disclosure result directly from the functionality of the database management system according to the first aspect of the present disclosure as well as its different implementation forms described above and below.

According to a third aspect, a computer program product storing program code which causes a computer or a processor to perform the method according to the second aspect, when the program code is executed by the computer or the processor, is provided.

As will be described in more detail in the following, embodiments of this disclosure provide a rule-based domain specific language (DSL) for conceptual schema mapping that describes, i.e. defines how to: (i) transform, using plain structured query language (SQL), relational data to graph data (R2G) including direct mapping (e.g. row-to-vertex and row-to-edge), generalizations/specializations, hierarchical, and denormalized relational schemas; and (ii) infer new relationships from existing data, including nested relationships and recursive relationships. Moreover, embodiments of this disclosure provide a rule-based mapping engine for graphs based on logical programming and only five predicate types (operations) that transforms graph queries into relational SQL queries over persistent relational data without a need for redundant graph storage. The DSL may be any declarative programming language that allows the definition of mappings using predicates such as Datalog, or an extension to the SQL Data Definition Language (DDL) as described above.

Embodiments of this disclosure provide, amongst others, the following advantages: (i) there is no need to duplicate relational data as graph data; (ii) relationships are inferred on-the-fly from the most updated data without delays due to the ETL or synchronization process; (iii) a (SQL-like) DSL simplifies the maintenance of the conceptual schema mapping; (iv) more complex mappings than direct table to vertex/edge mappings between relational and graph data can be expressed; (iv) new relationships can be derived from data, including nested and recursive relationships; (v) no substantial changes of the current infrastructure of a RDBMS are needed because standard SQL logic may be used; and (vi) a modular framework is provided that can be integrated into other frameworks, where the source is relational data and the destination is graph data ready for interactive graph queries of rules that specify how to transform relational schemas into graph schemas, and generates the corresponding relational queries (SELECT, VIEW, CTE or UDF), wherein these queries can be stored in the database catalog to be used later by the graph query engine.

In the following, embodiments of the present disclosure are described in more detail with reference to the attached figures and drawings, in which:.

In the following, identical reference signs refer to identical or at least functionally equivalent features.

In the following description, reference is made to the accompanying figures, which form part of the disclosure, and which show, by way of illustration, specific aspects of embodiments of the present disclosure or specific aspects in which embodiments of the present disclosure may be used. It is understood that embodiments of the present disclosure may be used in other aspects and comprise structural or logical changes not depicted in the figures.

For instance, it is to be understood that a disclosure in connection with a described method may also hold true for a corresponding device or system configured to perform the method and vice versa.

<FIG> is a schematic diagram of a possible high-level architecture of a database management system <NUM> according to an embodiment, which is configured to interact with a database <NUM>. As illustrated in <FIG>, the database management system <NUM> may comprise a processor 400a for processing data, a communication interface 400b for exchanging data with the database <NUM>, and a memory 400c for storing data. The processor 400a of the database management system <NUM> may be implemented in hardware and/or software. The hardware may comprise digital circuitry, or both analog and digital circuitry. Digital circuitry may comprise components such as application-specific integrated circuits (ASICs), field-programmable arrays (FPGAs), digital signal processors (DSPs), or general-purpose processors. The memory 400c may store data, such as executable program code which, when executed by the processor 400a, causes the processor 400a to perform the functions, operations and methods described herein, in particular implement one or more software-implemented engines, which will be described in more detail below. The memory 400c may comprise a non-transitory memory portion for storing persistent data and/or a volatile memory portion for storing volatile data.

In the embodiment shown in <FIG>, the database <NUM> is external to the database management system <NUM>. In a further embodiment, the database <NUM> may be embedded within the database management system <NUM>, e.g. within the memory 400c of the database management system <NUM>.

<FIG> is a schematic diagram illustrating further details of the database management system <NUM> of <FIG>. In an embodiment, the database management system <NUM> may be configured to implement, for instance, by means of the processor 400a, one or more of the components illustrated in <FIG> in software, such as a schema mapping engine <NUM>, a RDBMS schema connector <NUM>, a graph query engine <NUM>, and a relational query engine 405c.

The database management system <NUM> shown in <FIG> comprises and/or implements, for instance, by means of the processor 400a, three main components that are integrated into a generic architecture, namely (i) a rule-based DSL (domain-specific language) that allows to specify, i.e. define a conceptual mapping between relational and graph models, (ii) the RDBMS schema connector <NUM> configured to extract and maintain relational and graph catalogs 405a from the RDBMS database <NUM>, and (iii) the schema mapping engine (SME) <NUM> configured to generate relational queries from the DSL specification that will be used by the graph query engine <NUM> to execute a graph query <NUM>. As already described above, in an embodiment, the schema mapping engine <NUM> may be implemented by the processor 400a of the database management system <NUM> shown in <FIG>.

More specifically, the schema mapping engine <NUM> implemented by the processor 400a is configured to generate a schema mapping rule 411b based on a SQL data definition language (DDL) definition <NUM> (referred to as "SQL DDL schema mapping" in <FIG>) of a graph vertex and/or a graph edge of data of the database <NUM>. The schema mapping rule 411b maps data, e.g. tables or rows of the database <NUM>, to a graph representation of the data of the database <NUM>, including a plurality of graph vertices and a plurality of graph edges. Moreover, the schema mapping engine <NUM> is configured to generate, based on the schema mapping rule 411b, a database query 411e used by the relational query engine 405c for extracting one or more graph vertices and/or graph edges <NUM> from the database data 405b. As will be described in more detail below with respect to <FIG>, in the embodiment shown in <FIG>, the schema mapping engine <NUM>, which may be implemented by the processor 400a of the database management system <NUM>, comprises a SQL DDL (data definition language) parser and converter 411a, a schema validator 411c, and a SQL query generator 411d.

The database management system <NUM> shown in <FIG> differs from the conventional database management systems <NUM>, <NUM>, <NUM> shown in <FIG>, <FIG>, and <FIG> in particular with respect to the following aspects. In comparison with the simple conceptual schema mapping implemented by the database management system <NUM> shown in <FIG>, the database management system <NUM> shown in <FIG> allows the definition of complex relationships by generating a SQL query based on definitions specified using extensions to the standard SQL DDL. Moreover, in comparison with the ETL extraction implemented by the database management systems <NUM>, <NUM> of <FIG> and <FIG>, the database management system <NUM> shown in <FIG> does not require storing the inferred vertices and edges in an additional graph storage. This saves storage resources and allows real-time inference that includes the most recent updates in the relational data.

<FIG> illustrates the processing flow for the database management system <NUM> of <FIG>.

In step "<NUM>" <NUM>, a user (database administrator or database programmer) may specify new vertex or edge definitions by means of a SQL DDL schema mapping <NUM> using extensions to the standard SQL language as, for example, the exemplary extension illustrated in <FIG>, which will be described below. The SQL mapping extension illustrated in <FIG> is based on three concepts: (i) references to existing tables into the relational schema as a data source; (ii) references to already defined vertex and edge mappings as a data source; and (iii) predicates that specify how to do the transformation from the referenced sources (tables, vertices and edges) into new vertices or edges.

In step "<NUM>" <NUM>, the SQL DDL parser and converter 411a shown in <FIG> extracts all the definitions from the SQL DDL schema mapping <NUM>, identifies all data sources (tables, vertices or edges) and generates an equivalent rule, namely the schema mapping rule 411b, in a conjunctive form of one or more predicates, similar to the Prolog or Datalog programming languages.

In step "<NUM>" <NUM>, the schema validator 411c shown in <FIG> matches through the RDBMS schema connector <NUM> the data sources with the existing tables and mappings into the database catalog 405a and validates the mapping correctness.

In step "<NUM>" <NUM>, the SQL query generator 411d shown in <FIG> generates a new SQL R2G mapping query (SELECT, VIEW, CTE, or UDF) 411e based on the expected input data sources and the schema mapping rule 411b.

In step "<NUM>" <NUM>, the RDBMS schema connector <NUM> registers the vertex or edge mapping and the SQL R2G mapping query 411e in the database catalog 405a.

In step "<NUM>" <NUM>, the SQL R2G mapping query 411e may be used by the graph query engine <NUM> to execute in the relational query engine 405c a graph query <NUM> that extracts vertices and/or edges on-the-fly from existing data into the database <NUM> and provides a query result <NUM>.

Steps "<NUM>" and "<NUM>" may be implemented using already existing tools for converting graph queries into relational queries.

In an embodiment, the query evaluation of rules as implemented by the database management system <NUM> may be based on first-order logic (predicate logic). In an embodiment, there is a valid result for the rule for each combination of inputs (data sources) that match all the predicates in the rule. In a rule, each predicate has a name and a list of arguments. An argument can be, for instance, a constant value (number, character string, and the like), a variable name (a symbolic name associated with a value) or a predefined enumerated type. If a variable name appears at the same time in two or more predicates, then it may contain the same value for all the predicates at a specific instant of time. In an embodiment, it is further possible to use a union (combination) of one or more disjoint rules in order to express different ways to map one or more sources to the same vertex or edge definition.

<FIG> shows an example of a relational table containing exemplary household registration data. By way of example, the table of <FIG> comprises the following columns: "House", "City", "ID", "Relationship", "Birthday", "Registration start", and "Registration end", wherein each column has eight rows.

<FIG> shows the property graph inferred from the table of <FIG>. As will be appreciated, some relationships are directly extracted from the table (e.g. wife), while others require inference based on nested relationships (e.g. son of wife or sibling). In <FIG>, solid-line relationships are explicit in the data and dotted-line relationships are implicit and must be inferred.

The database management system <NUM> allows implementing mappings between a relational schema and a property graph covering everything from simple scenarios, such as strong (strict) schema, where relations are directly vertices and edges (explicit, e.g. wife), up to free schema or complex use cases, where vertices and edges are derived from existing data using multiple composite or recursive predicates (inferred, e.g. sibling). In an embodiment, the database management system <NUM> implements one or more of the following rules and schemes.

In an embodiment, the database management system <NUM> may implement a strong (strict) schema, where there is a relation for each vertex label and for each edge label. In this case, the relational schema may be normalized in first normal form (1NF) where (i) there is a separate table for each relation, (ii) each set of related data is identified with a primary key, and (iii) each attribute contains only atomic (indivisible) values. Migration of attributes of <NUM>:<NUM> and <NUM>:N relationships are also in 1NF, but, in this case, an edge is defined in the same relation as one of the participating vertices.

In an embodiment, the database management system <NUM> may implement a denormalized relational schema, when, for example, the relational schema is not in second normal form (2NF) (without partial dependencies) or in third normal form (3NF) (without transitive dependencies) because of a performance-oriented design or by constraints imposed by the application. An example is when a single relation contains attributes that should be split into multiple relations.

In an embodiment, the database management system <NUM> may implement object-oriented schemas, such as generalizations or specializations of Enhanced Relational Models (EER), where common characteristics of different entities (specializations or subtypes or subclasses) are stored in a common relation called superclass or supertype. Each subclass contains a reference (sometimes weak) to the superclass and its own attributes. In this kind of mapping, inheritance of attributes appears from the superclass and relationships to superclasses that are extended to all of the subclasses. The mapping also forces each vertex in the subclass to have all the labels of the inheritance hierarchy tree.

In an embodiment, the database management system <NUM> may implement a hierarchical query, which is a form of recursive query that retrieves a hierarchy. It returns the rows of the result set in a hierarchical order based upon data forming a parent-child relationship. Hierarchies in relational data are typically represented by inverted tree structures.

In an embodiment, the database management system <NUM> may implement nested relationships, i.e. relationships that can be derived as a combination of other inferred relationships, in the same way as nested queries. One classical example is relatives or distant relatives such as grandparents or siblings that can be inferred from a simple family tree that only contains direct relative relationships.

<FIG> shows the EER relational schema of a social network that includes generalized vertices, such as "Message", specialized vertices of "Message" as "Post" and "Comment", each with different properties, and relationships to a superclass such as "replyOf" to "Message". Thus, instead of defining graph relationships based only on a strict mapping of the relational schema to the graph schema, with a schema implemented by the database management system <NUM>, new edges can be obtained with the evaluation of one or more graph queries, including recursion.

In an embodiment, the database management system <NUM> may be configured to query and analyze graphs using one or more of the following frameworks: Property Graph Databases (PGDBMS), Graph Analytical Frameworks, RDF/SPARQL, Graph Streaming, and the like. The conversion between relational data and graph data may be done logically, as part of the query process, or physically by duplicating the original relational data into graph vertices and edges. A conceptual schema mapping may be used to define how to convert from relational model to graph, and vice versa.

In an embodiment, the schema mapping engine <NUM> is configured to provide a programming interface, wherein the programming interface is configured to receive one or more programming instructions (also referred to as predicates) for extracting data 405b from the database <NUM> and/or defining a graph vertex and/or a graph edge of the graph representation of the data 405b of the database <NUM>.

In an embodiment, the one or more programming instructions of the programming interface comprises a first programming instruction, herein referred to as a "MATCH" instruction, for extracting data 405b from the database <NUM> or from the graph representation of the data 405b of the database <NUM>. In an embodiment, the "MATCH" instruction for extracting data from the database <NUM> is configured to define a graph vertex and/or a graph edge of the graph representation of the data 405b of the database <NUM> by recursive reference to the schema mapping rule 411b. In an embodiment, the "MATCH" instruction may be defined as follows:.

In an embodiment, the one or more programming instructions of the programming interface comprises a second programming instruction, herein referred to as a "COMPARE" instruction, for filtering data 405b of the database <NUM> on the basis of one or more comparison predicates. In an embodiment, the "COMPARE" instruction may be defined as follows:.

In an embodiment, the one or more programming instructions of the programming interface comprises a third programming instruction, herein referred to as an "AGGREGATE" instruction, for determining one or more aggregate functions over data of the database. In an embodiment, the "AGGREGATE" instruction may be defined as follows:.

In an embodiment, the one or more programming instructions of the programming interface comprises a fourth programming instruction, herein referred to as a "EXCEPT" instruction, for discarding data of the database or data from the graph representation of the data matching one or more criteria. In an embodiment, the "EXCEPT" instruction may be defined as follows:.

In an embodiment, the one or more programming instructions of the programming interface comprises a fifth programming instruction, herein referred to as a "EVAL" instruction, for evaluating one or more pre-defined functions or predicates. In an embodiment, the "EVAL" instruction may be defined as follows:.

Thus, the "MATCH" instruction may be used to define how to access data sources such as a table or an existing vertex and edge mapping. The "COMPARE" instruction may filter data based on comparison predicates such as equality, inequalities or existence into a set of values. The "AGGREGATE" instruction may be used to compute aggregate functions over the data, such as counting occurrences or finding maximum or minimum values. The "EXCEPT" instruction may be used to discard occurrences that do match some criteria. The "EVAL" instruction allows for the evaluation of built-in predicates provided by each specific RDBMS, for example to extract the year from a date. A particular case is recursion that can be achieved by nested rules.

In the following, the above five programming instructions provided by the programming interface of the schema mapping engine <NUM> for extracting data 405b from the database <NUM> and/or defining a graph vertex and/or a graph edge of the graph representation of the data 405b of the database <NUM> will be described in more detail in the context of the examples shown in <FIG>, <FIG>, and <FIG>.

For the relational table shown in <FIG> containing household registration data, the relational schema may be defined as follows:
Household(House VARCHAR, City VARCHAR, ID INT, Relationship VARCHAR, Birthday DATE, Registration_start DATE, Registration_end DATE).

A graph with different vertex and edge mappings may be defined using the programming instructions described above in the following way.

A vertex for each person (simple MATCH) may be defined as follows:
Person(id I, birthday B) :-
MATCH(TABLE, Household, [I:ID, B:Birthday]).

A vertex for each house (a different MATCH to the same table) may be defined as follows: House(house H, city C) :-
MATCH(TABLE, Household, [H:House, C:City]).

An edge for each householder (simple MATCH with filter) may be defined as follows: Householder(id I, house H) :-.

An edge for each wife of a householder (inference) may be defined as follows: Wife(id I, wife W) :-.

An edge for each mother (inference) may be defined as follows:
Mother(id I, mother M) :-.

An edge for each grandmother (nested inference) may be defined as follows: Grandmother(id I, grandmother G) :-.

A vertex for each bachelor householder (no wife, inference) may be defined as follows: Bachelor (id I, city C) :-.

An edge for each family with children (aggregate) may be defined as follows:
Family (id I, wife W, child N) :-.

A vertex for each baby (built-in expression) may be defined as follows:
Baby(mother M, child I) :-.

The following examples show the complete flow of inference of one vertex type and one edge type.

The database management system <NUM> may use an extension of SQL DDL to define how to extract people, houses, and how to link householders with houses and wives with householders from the relational table shown in <FIG> in the following way.

The following examples show the corresponding rules for the vertex and edge.

Finally, the following examples show the final SQL queries that will extract those vertices and edges from the database <NUM>.

In the following, a further example is described, which merges data from two relational tables in order to create vertices that identify "female faculty members older than <NUM> years from Barcelona Universities".

A SQL-like definition of a new vertex (w_faculty) based on two relational data sources (Person and University) with some constraints (gender, age and location) may be defined as follows:.

The schema of the relational data sources may be defined as follows:.

The logical rule that represents the vertex mapping for this example may be defined as follows:
w_faculty(I,N,A) :-.

As already described above, <FIG> and <FIG> illustrate a processing flow implemented by the database management system <NUM>, including the mapping from relational to graph written in the DSL, until the final relational query is generated.

As already described above, the schema mapping engine <NUM> may read a script provided by a database administrator or database programmer, parses and validates its content, and generates an intermediate data structure with the parse tree, for example an Abstract Syntax Tree (AST) or in-memory data structures. As already described above, an exemplary SQL DDL extension that covers all the requirements described above is illustrated in <FIG>. In the following some exemplary mappings using the SQL-like DDL illustrated in <FIG> will be described, namely a very simple (strict vertex or edge) example as well as a more sophisticated example including negation, recursion and aggregates.

The schema mapping engine <NUM> may then extract all the data dependencies from the existing database relational tables or previously defined graph vertex and edge mappings. For example, the relational schema of four tables may be defined as follows:.

The SQL-like script with the definition of two vertex (author, paper) and two edge (authorship, is_coauthor) mappings to those four tables may be defined as follows:.

In step <NUM> of <FIG>, a rule 411b is created with a MATCH predicate for each data source and all the constraints and aggregates are added to the rule as predicates (COMPARE, AGGREGATE, EXCEPT or EVAL). The rules for the two vertices and the two edges for the present example may be defined as follows, wherein each predicate is labelled on the right for the sake of clarity;.

Then, all non-recursive MATCH and EXCEPT instructions to vertices or edges are expanded with their corresponding rule definition, excluding those with type SELF. This expansion is done recursively until all data source references in MATCH and EXCEPT are only to relational tables.

The expansion of predicates C. <NUM> and C. <NUM> in the rule of the new derived edge is_coauthor may be defined as follows, wherein he labels on the right correspond to the same labels above before the expansion:.

After the expansion, all redundant MATCH or EXCEPT instructions may be automatically removed in order to avoid unnecessary redundant data access to the same data sources.

In step <NUM> of <FIG>, all the dependencies to data sources (table, vertex or edge) are validated by the RDBMS Schema Connector <NUM>. Each data source must exist, each column (property) must exist, and each column (property) data type must be correct or there must be a proper way to coerce from the required data type to the column (property) data type.

Finally, step <NUM> of <FIG> only needs to convert each rule into a SQL query (SELECT statement, VIEW, CTE, UDF, or the like). For this step, it is possible to use any known technique for the conversion from logical programs to relational operators such as those used in Datalog. If the rule contains one or more recursive predicates (MATCH of type self), then it will require a recursive CTE, Stored Procedure or UDF. For all the other cases, a single SELECT or VIEW is enough. For multi-rule disjoint definitions (more than one rule for the same vertex or edge mapping), the UNION operator may be used to combine both results.

The final SQL statement for the new derived edge is_coauthor that returns an edge between all female faculty members from the same city, younger than <NUM> years old and that have published at least <NUM> papers together since <NUM> may be defined as follows:.

The following further example includes the negation of a match as a EXCEPT:.

The logical rules that represent the mappings for this example may be defined as follows:.

The following further example illustrates a multi-rule recursive definition based on the vertex and edge mappings introduced in the previous example.

As will be appreciated, all rules for the same mapping should have the same signature (output arguments in number and data type). In this case, the expected SQL query may be a recursive CTE, Stored Procedure or UDF.

Once the SQL query has been created, then the schema mapping engine <NUM> only needs to register it into the catalog 405a of the database <NUM> by calling again to the database <NUM>. Subsequently, the graph query engine <NUM> may use those SQL queries to solve graph queries that include those new vertices and edges.

<FIG> is a flow diagram of a method <NUM> for managing a database <NUM>. The method <NUM> comprises the following steps.

In a step <NUM>, a definition of at least one of a graph vertex and a graph edge of data 405b of the database <NUM> is received. In a step <NUM>, a schema mapping rule 411b is generated based on the received definition of the at least one of the graph vertex and the graph edge of the data 405b of the database <NUM>. The schema mapping rule 411b defines a correspondence between the data 405b of the database <NUM>, e.g. tables or rows of the database <NUM>, and a graph representation of the data 405b of the database <NUM>. The graph representation of the data 405b of the database <NUM> includes the at least one of the graph vertex and the graph edge of the data 405b of the database <NUM>. In a step <NUM>, based on the generated schema mapping rule 411b, a database query 411e is generated for extracting one or more further graph vertices and/or graph edges of the data 405b of the database <NUM>.

The person skilled in the art will understand that the "blocks" ("units") of the various figures (method and apparatus) represent or describe functionalities of embodiments of the present disclosure (rather than necessarily individual "units" in hardware or software) and thus describe equally functions or features of apparatus embodiments as well as method embodiments (unit = step).

In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus, and method may be implemented in other manners. For example, the described embodiment of an apparatus is merely exemplary. For example, the unit division is merely logical function division and may be another division in an actual implementation.

Claim 1:
A database management system (<NUM>) for managing a database (<NUM>), the database management system (<NUM>) comprising a processor (400a, <NUM>) configured to:
receive a definition of at least one of a graph vertex and a graph edge of data (405b) of the database (<NUM>);
generate a schema mapping rule (411b), based on the definition of the at least one of the graph vertex and the graph edge of the data (405b) of the database (<NUM>), wherein the schema mapping rule (411b) defines a correspondence between the data (405b) of the database (<NUM>) and a graph representation of the data (405b) of the database (<NUM>), the graph representation including the at least one of the graph vertex and the graph edge of the data (405b) of the database (<NUM>); and
generate, based on the schema mapping rule (411b), a database query (411e) for extracting one or more further graph vertices and/or graph edges of the data (405b) of the database (<NUM>),
wherein the processor (400a, <NUM>) is further configured to store the database query (411e) in a database catalog (405a) of the database (<NUM>),
wherein the processor (400a, <NUM>) is further configured to extract the one or more further graph vertices and/or graph edges of the data (405b) of the database (<NUM>) based on the database query (411e) stored in the database catalog (405a),
wherein the processor (400a, <NUM>) is further configured to provide a programming interface, wherein the programming interface is configured to receive one or more programming instructions for at least one of extracting the data (405b) from the database (<NUM>) and defining the at least one of the graph vertex and the graph edge of the data (405b) of the database (<NUM>),
wherein the one or more programming instructions of the programming interface comprise a first programming instruction for extracting the data (405b) from the database (<NUM>) or from the graph representation of the data (405b) of the database (<NUM>),
wherein the first programming instruction for extracting the data (405b) from the database (<NUM>) is configured to define the at least one of the graph vertex and the graph edge of the data (405b) of the database (<NUM>) by recursive reference to the schema mapping rule (411b).