DOCSLIB.ORG

Cypher-Based Graph Pattern Matching in Gradoop

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Cypher-Based Graph Pattern Matching in Gradoop Cypher-based Graph Paern Matching in Gradoop Martin Junghanns Max Kießling Alex Averbuch University of Leipzig & ScaDS Dresden/Leipzig University of Leipzig & Neo Technology Neo Technology [email protected] [email protected] [email protected] Andre´ Petermann Erhard Rahm University of Leipzig & ScaDS Dresden/Leipzig University of Leipzig & ScaDS Dresden/Leipzig [email protected] [email protected] ABSTRACT In consequence, valuable insights may remain hidden as analysts Graph paern matching is an important and challenging operation are restrained either by limited scalability of graph databases or on graph data. Typical use cases are related to graph analytics. missing functionality of graph processing systems. In particular, Since analysts are oen non-programmers, a graph system will we see a need to extend graph processing by query capabilities only gain acceptance, if there is a comprehensible way to declare that show the same expressiveness as those of graph database paern matching queries. However, respective query languages systems. is motivated us to add the paern matching core of are currently only supported by graph databases but not by dis- Neo4j’s declarative graph query language Cypher1 to Gradoop, a tributed graph processing systems. To enable paern matching on distributed open-source framework for graph analytics and process- a large scale, we implemented the declarative graph query language ing [12]. Our query engine is fully integrated and paern matching Cypher within the distributed graph analysis platform Gradoop. can be used in combination with other analytical graph operators Using LDBC graph data, we show that our query engine is scalable provided by the framework. Gradoop is based on the dataow for operational as well as analytical workloads. e implementation framework Apache Flink [3] which scales out computation across is open-source and easy to extend for further research. multiple machines. In short, our contributions are: (1) We provide the rst implemen- CCS CONCEPTS tation of the Cypher query language based on a distributed dataow •Computing methodologies ! Distributed algorithms; system, (2) we implemented a modular query engine which is the •Information systems ! Graph-based data models; foundation for our ongoing research on graph paern matching in KEYWORDS distributed environments and (3) we present results of scalability Cypher, Graph Paern Matching, Apache Flink, Gradoop experiments based on the LDBC social network. We provide the source code as part of the Gradoop framework under an open 2 1 INTRODUCTION source license . Graph paern matching is the problem of nding all subgraphs e remainder of this paper is organized as follows: In Section of a data graph that match a given paern or query graph. It has 2 we provide prelimiaries on the graph data model, graph paern manifold applications in research and industry, e.g., in social net- matching and Cypher. Section 3 describes the implementation work analysis, life sciences or business intelligence. An established of our query engine while Section 4 presents evaluation results. solution to manage and query graph data is using a graph database Finally, we briey discuss related work and give an outlook on our system such as Neo4j [18]. ese systems provide exible data ongoing research. models to t dierent application domains and oer declarative 2 BACKGROUND graph query languages to enable non-programmers to express a We rst introduce the graph data model of Gradoop. Aerwards, query without a deeper understanding of the underlying system. In we specify the formal semantics of graph paern matching and contrast, graph processing systems focus on large-scale applications outline the core features of the Cypher graph query language. with very large amounts of graph data and high computational requirements for graph analysis and mining [13]. In such cases, 2.1 Extended Property Graph Model parallel and distributed execution on many processors became an e Property Graph Model [16] is a widely accepted graph data established solution. However, expressing graph algorithms in such model used by many graph database systems [2]. A property graph systems requires a profound knowledge of the underlying frame- is a directed, labeled and aributed multigraph. Vertex and edge works and programming APIs. Moreover, support for graph paern semantics are expressed using type labels (e.g., Person or knows). matching is still limited [6]. Aributes have the form of key-value pairs (e.g., name:Alice or classYear:2015) and are referred to as properties. Properties are Permission to make digital or hard copies of all or part of this work for personal or set at the instance level without an upfront schema denition. e classroom use is granted without fee provided that copies are not made or distributed Extended Property Graph Model adds support for graph collections for prot or commercial advantage and that copies bear this notice and the full citation containing multiple, possibly overlapping property graphs, which on the rst page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permied. To copy otherwise, or republish, are referred to as logical graphs [12]. Like vertices and edges, logical to post on servers or to redistribute to lists, requires prior specic permission and/or a graphs have a type label and an arbitrary number of properties. fee. Request permissions from [email protected]. GRADES’17, Chicago, IL, USA © 2017 ACM. 978-1-4503-5038-9/17/05...$15.00 1hps://neo4j.com/developer/cypher-query-language/ DOI: hp://dx.doi.org/10.1145/3078447.3078450 2hp://www.gradoop.com GRADES’17, May 19, 2017, Chicago, IL, USA Martin Junghanns, Max Kießling, Alex Averbuch, Andre´ Petermann, and Erhard Rahm L = f100g V = Figure 1: Extended Property Graph with , Denition 2.2. (ery graph). Let G be a data graph. A tuple f10; 20; ::; 50g, E = f1; 2; ::; 8g, T = fCommunity; Person;knows; :::g, Q = (Vq; Eq;s; t;θv ;θe ) is a query graph of query vertices Vq and K = farea;name;classYear; :::g and A = fLeipzig; Alice; 2014; :::g. query edges Eq . θv : V (G) ! ftrue; f alseg and θe : E(G) ! ftrue; f alseg are predicate functions dened on type labels and properties of data vertices and edges. Denition 2.3. (Homomorphism/Isomorphism). A graph G0 = (V 0; E0) will be a subgraph of a (logical) graph G = (V ; E), denoted by G0 v G, i V 0 ⊆ V and E0 ⊆ E with 8e 2 E0 : s(e); t (e) 2 V 0. Given a query graph Q and a subgraph G0, G0 will match Q by homomorphism, denoted by Q ∼ G0, if there are two mappings 0 0 fv : Vq ! V and fe : Eq ! E , such that 8vq 2 Vq : θv (fv (vq )) 0 and 8e 2 Eq : (fv (s(eq )); fv (t (eq ))) 2 E ^ θe (fe (eq )). If fv and 0 fe are bijective, then G matches Q by isomorphism, denoted by Q ' G0. If G0 matches Q, then Q will be embedded in G0. An embedding is represented by a tuple (fv ; fe )G0 . Based on the previous denitions, we are now able to dene a Denition 2.1. (Extended Property Graph Model.) A tuple new EPGM operator for graph paern matching: G = (L;V ; E;l;s; t;T;τ; K; A;κ) represents an extended property graph. L is a set of graphs (graph identiers), V is a set of vertices Denition 2.4. (Graph pattern matching). Given a logical (vertex identiers) and E is a set of edges (edge identiers). Graph (data) graph G and a query graph Q, the graph paern matching containment is represented by the mapping l : V [ E ! P(L) n ; operator returns a collection of new logical graphs GQ , such that 0 0 0 0 whereas the mappings s : E ! V / t : E ! V determine a source G 2 GQ , G v G ^ Q ∼ G (or Q ' G for isomorphism). Note, and a target vertex for every edge. An edge is directed from source that the resulting logical graphs are added to the set of all graphs, 8 2 G 2 to target. A logical graph Gi = (Vi ; Ei ) (i 2 L) represents a subset of i.e., Gi Q : i L. vertices Vi ⊆ V and a subset of edges Ei ⊆ E such that 8v 2 Vi : i 2 2.3 Cypher ery Language l (v) and 8e 2 Ei : s(e); t (e) 2 Vi ^ i 2 l (e). T is a set of type labels For the paern matching operator, it is necessary to declare a query and τ : L [ V [ E ! T assigns a label to a graph, vertex or edge. graph Q. For this purpose, we adopt core features of Cypher, the Similarly, properties are dened by a set of property keys K, a set graph query language of Neo4j. Since Cypher is designed on top of of property values A and a mapping κ : (L [ V [ E) × K ! A [ fεg, the property graph model, it can also be used to express a query on a where ε is returned if the element has no value for a given key. A logical graph. Furthermore, there is an ongoing eort to standardize graph collection G = fG1;G2; :::;Gn g is a set of logical graphs. Cypher as a graph query language within the openCypher3 project. Figure 1 shows an example social network represented by a single Having the social network of Figure 1 in mind, we give an exam- logical graph containing persons, universities and cities as well as ple for searching pairs of persons who study at the University of their mutual relations. e EPGM further denes a set of operators Leipzig, have dierent genders and know each other either directly to analyze logical graphs and graph collections [12].
Load more

Recommended publications
  • Empirical Study on the Usage of Graph Query Languages in Open Source Java Projects
    Empirical Study on the Usage of Graph Query Languages in Open Source Java Projects Philipp Seifer Johannes Härtel Martin Leinberger University of Koblenz-Landau University of Koblenz-Landau University of Koblenz-Landau Software Languages Team Software Languages Team Institute WeST Koblenz, Germany Koblenz, Germany Koblenz, Germany [email protected] [email protected] [email protected] Ralf Lämmel Steffen Staab University of Koblenz-Landau University of Koblenz-Landau Software Languages Team Koblenz, Germany Koblenz, Germany University of Southampton [email protected] Southampton, United Kingdom [email protected] Abstract including project and domain specific ones. Common applica- Graph data models are interesting in various domains, in tion domains are management systems and data visualization part because of the intuitiveness and flexibility they offer tools. compared to relational models. Specialized query languages, CCS Concepts • General and reference → Empirical such as Cypher for property graphs or SPARQL for RDF, studies; • Information systems → Query languages; • facilitate their use. In this paper, we present an empirical Software and its engineering → Software libraries and study on the usage of graph-based query languages in open- repositories. source Java projects on GitHub. We investigate the usage of SPARQL, Cypher, Gremlin and GraphQL in terms of popular- Keywords Empirical Study, GitHub, Graphs, Query Lan- ity and their development over time. We select repositories guages, SPARQL, Cypher, Gremlin, GraphQL based on dependencies related to these technologies and ACM Reference Format: employ various popularity and source-code based filters and Philipp Seifer, Johannes Härtel, Martin Leinberger, Ralf Lämmel, ranking features for a targeted selection of projects.
    [Show full text]
  • A Comparison Between Cypher and Conjunctive Queries
    A comparison between Cypher and conjunctive queries Jaime Castro and Adri´anSoto Pontificia Universidad Cat´olicade Chile, Santiago, Chile 1 Introduction Graph databases are one of the most popular type of NoSQL databases [2]. Those databases are specially useful to store data with many relations among the entities, like social networks, provenance datasets or any kind of linked data. One way to store graphs is property graphs, which is a type of graph where nodes and edges can have attributes [1]. A popular graph database system is Neo4j [4]. Neo4j is used in production by many companies, like Cisco, Walmart and Ebay [4]. The data model is like a property graph but with small differences. Its query language is Cypher. The expressive power is not known because currently Cypher does not have a for- mal definition. Although there is not a standard for querying graph databases, this paper proposes a comparison between Cypher, because of the popularity of Neo4j, and conjunctive queries which are arguably the most popular language used for pattern matching. 1.1 Preliminaries Graph Databases. Graphs can be used to store data. The nodes represent objects in a domain of interest and edges represent relationships between these objects. We assume familiarity with property graphs [1]. Neo4j graphs are stored as property graphs, but the nodes can have zero or more labels, and edges have exactly one type (and not a label). Now we present the model we work with. A Neo4j graph G is a tuple (V; E; ρ, Λ, τ; Σ) where: 1. V is a finite set of nodes, and E is a finite set of edges such that V \ E = ;.
    [Show full text]
  • Introduction to Graph Database with Cypher & Neo4j
    Introduction to Graph Database with Cypher & Neo4j Zeyuan Hu April. 19th 2021 Austin, TX History • Lots of logical data models have been proposed in the history of DBMS • Hierarchical (IMS), Network (CODASYL), Relational, etc • What Goes Around Comes Around • Graph database uses data models that are “spiritual successors” of Network data model that is popular in 1970’s. • CODASYL = Committee on Data Systems Languages Supplier (sno, sname, scity) Supply (qty, price) Part (pno, pname, psize, pcolor) supplies supplied_by Edge-labelled Graph • We assign labels to edges that indicate the different types of relationships between nodes • Nodes = {Steve Carell, The Office, B.J. Novak} • Edges = {(Steve Carell, acts_in, The Office), (B.J. Novak, produces, The Office), (B.J. Novak, acts_in, The Office)} • Basis of Resource Description Framework (RDF) aka. “Triplestore” The Property Graph Model • Extends Edge-labelled Graph with labels • Both edges and nodes can be labelled with a set of property-value pairs attributes directly to each edge or node. • The Office crew graph • Node �" has node label Person with attributes: <name, Steve Carell>, <gender, male> • Edge �" has edge label acts_in with attributes: <role, Michael G. Scott>, <ref, WiKipedia> Property Graph v.s. Edge-labelled Graph • Having node labels as part of the model can offer a more direct abstraction that is easier for users to query and understand • Steve Carell and B.J. Novak can be labelled as Person • Suitable for scenarios where various new types of meta-information may regularly
    [Show full text]
  • Handling Scalable Approximate Queries Over Nosql Graph Databases: Cypherf and the Fuzzy4s Framework
    Castelltort, A. , & Martin, T. (2017). Handling scalable approximate queries over NoSQL graph databases: Cypherf and the Fuzzy4S framework. Fuzzy Sets and Systems. https://doi.org/10.1016/j.fss.2017.08.002 Peer reviewed version License (if available): CC BY-NC-ND Link to published version (if available): 10.1016/j.fss.2017.08.002 Link to publication record in Explore Bristol Research PDF-document This is the author accepted manuscript (AAM). The final published version (version of record) is available online via Elsevier at https://www.sciencedirect.com/science/article/pii/S0165011417303093?via%3Dihub . Please refer to any applicable terms of use of the publisher. University of Bristol - Explore Bristol Research General rights This document is made available in accordance with publisher policies. Please cite only the published version using the reference above. Full terms of use are available: http://www.bristol.ac.uk/pure/about/ebr-terms *Manuscript 1 2 3 4 5 6 7 8 9 Handling Scalable Approximate Queries over NoSQL 10 Graph Databases: Cypherf and the Fuzzy4S Framework 11 12 13 Arnaud Castelltort1, Trevor Martin2 14 1 LIRMM, CNRS-University of Montpellier, France 15 2Department of Engineering Mathematics, University of Bristol, UK 16 17 18 19 20 21 Abstract 22 23 NoSQL databases are currently often considered for Big Data solutions as they 24 25 offer efficient solutions for volume and velocity issues and can manage some of 26 complex data (e.g., documents, graphs). Fuzzy approaches are yet often not 27 28 efficient on such frameworks. Thus this article introduces a novel approach to 29 30 define and run approximate queries over NoSQL graph databases using Scala 31 by proposing the Fuzzy4S framework and the Cypherf fuzzy declarative query 32 33 language.
    [Show full text]
  • Evaluating a Graph Query Language for Human-Robot Interaction Data in Smart Environments
    Evaluating a Graph Query Language for Human-Robot Interaction Data in Smart Environments Norman K¨oster1, Sebastian Wrede12, and Philipp Cimiano1 1 Cluster of Excellence Center in Cognitive Interactive Technology (CITEC) 2 Research Institute for Cognition and Robotics (CoR-Lab), Bielefeld University, Bielefeld Germany fnkoester,swrede,[email protected], Abstract. Solutions for efficient querying of long-term human-robot in- teraction data require in-depth knowledge of the involved domains and represents a very difficult and error prone task due to the inherent (sys- tem) complexity. Developers require detailed knowledge with respect to the different underlying data schemata, semantic mappings, and most im- portantly the query language used by the storage system (e.g. SPARQL, SQL, or general purpose language interfaces/APIs). While for instance database developers are familiar with technical aspects of query lan- guages, application developers typically lack the specific knowledge to efficiently work with complex database management systems. Addressing this gap, in this paper we describe a model-driven software development based approach to create a long term storage system to be employed in the domain of embodied interaction in smart environments (EISE). The targeted EISE scenario features a smart environment (i.e. smart home) in which multiple agents (a mobile autonomous robot and two virtual agents) interact with humans to support them in daily activities. To support this we created a language using Jetbrains MPS to model the high level EISE domain w.r.t. the occurring interactions as a graph com- posed of nodes and their according relationships. Further, we reused and improved capabilities of a previously created language to represent the graph query language Cypher.
    [Show full text]
  • Graphql API Backed by a Graph Database
    Graphs All The Way Down Building A GraphQL API Backed By A Graph Database William Lyon @lyonwj lyonwj.com William Lyon Developer Relations Engineer @neo4j [email protected] @lyonwj lyonwj.com Agenda • Graph databases - Neo4j • Intro to GraphQL • Why I’m excited about GraphQL + Graph Databases • neo4j-graphql neo4j.com/developer Neo4j Graph Database https://offshoreleaks.icij.org/pages/database http://www.opencypher.org/ https://arxiv.org/pdf/1004.1001.pdf neo4jsandbox.com http://graphql.org/ GraphQL • “A query language for your API” • Developed by Facebook iOS team for iOS app • Reduce number of round trip requests in face of low latency • Declarative, state what fields you want • Alternative to REST • Self documenting (schema and types) • Limited support for “queries” • Logic is implemented in server GraphQL • “A query language for your API, and a server-side runtime for executing queries by using a type system you define for your data” • “GraphQL isn't tied to any specific database or storage engine” • “A GraphQL service is created by defining types and fields on those types, then providing functions for each field on each type” http://graphql.org/learn/ GraphQL Adoption GraphQL GraphQL Query Result https://github.com/johnymontana/neo4j-datasets/tree/master/yelp/src/graphql Ecosystem • Tools • GraphQL Clients • Graphiql • Most popular is Apollo-client • Apollo optics • Also Relay (Relay Modern recently released at F8) • Dataloader • Apollo-client also has iOS, Android clients • Lokka (js) • Frontend frameworks • Dominated by React (Fiber
    [Show full text]
  • Usporedba Jezika Za Graf Baze Podataka
    SVEUČILIŠTE U ZAGREBU FAKULTET ORGANIZACIJE I INFORMATIKE V A R A Ž D I N Martina Šestak USPOREDBA JEZIKA ZA GRAF BAZE PODATAKA DIPLOMSKI RAD Varaždin, 2016. SVEUČILIŠTE U ZAGREBU FAKULTET ORGANIZACIJE I INFORMATIKE V A R A Ž D I N Martina Šestak Matični broj: 43591/14-R Studij: Informacijsko i programsko inženjerstvo USPOREDBA JEZIKA ZA GRAF BAZE PODATAKA DIPLOMSKI RAD Mentor: Izv. prof. dr. sc. Kornelije Rabuzin Varaždin, 2016. Sadržaj 1. Uvod .................................................................................................................................... 3 2. Relacijske baze podataka .................................................................................................... 4 2.1. Relacijski model podataka .............................................................................................. 4 2.2. Relacijsko procesiranje ................................................................................................... 5 2.3. Upitni jezici za relacijske baze podataka ........................................................................ 6 2.3.1. ISBL upitni jezik ..................................................................................................... 7 2.3.2. QUEL jezik .............................................................................................................. 7 2.3.3. QBE upitni jezik ...................................................................................................... 8 2.3.4. PIQUE upitni jezik .................................................................................................
    [Show full text]
  • NOSQL, Graph Databases & Cypher
    NOSQL, graph databases & Cypher Advances in Data Management, 2018 Dr. Petra Selmer Engineer at Neo4j and member of the openCypher Language Group 1 About me Member of the Cypher Language Group Design new features for Cypher Manage the openCypher project Engineer at Neo4j Work on the Cypher Features Team Maintainer of the Cypher chapter in the Neo4j Developer Manual PhD in flexible querying of graph-structured data (Birkbeck, University of London) 2 Agenda The wider landscape NOSQL in brief Introduction to property graph databases (in particular Neo4j) The Cypher query language Evolving Cypher 3 Preamble The area is HUGE The area is ever-changing! 4 The wider landscape: 2012 Matthew Aslett, The 451 Group 5 The wider landscape: 2016 Matthew Aslett, The 451 Group 6 The wider landscape Several dimensions in one picture: Relational vs. Non-relational Analytic (batch, offline) vs. Operational (transactional, real-time) Increasingly difficult to categorise these data stores: Everyone is now trying fiercely to integrate features from databases found in other spaces. The emergence of “multi-model” data stores: One may start with one data model and add other models as new requirements emerge. 7 A brief tour of NOSQL 8 NOSQL: non-relational NOSQL: “Not Only SQL”, not “No SQL” Basically means “not relational” – however this also doesn't quite apply, because graph data stores are very relational; they just track different forms of relationships than a traditional RDBMS. A more precise definition would be the union of different data management systems differing from Codd’s classic relational model 9 NOSQL: non-relational The name is not a really good one, because some of these support SQL and SQL is really orthogonal to the capabilities of these systems.
    [Show full text]
  • Big Data and Nosql Very Short History of Dbmss
    Big Data and NoSQL Very short history of DBMSs • The seventies: – IMS – end of the sixties, built for the Apollo program (today: Version 15) and IDS (then IDMS), hierarchical and network DBMSs, navigational • The eighties – for twenty years: – Relational DBMSs – The nineties: client/server computing, three tiers, thin clients Object Oriented Databased • In the nineties, Object Oriented databases were proposed to overcome the impedence mismatch • They influenced Relational Databases, and disappeared Big Data • Mid 2000s, Big Data: – Volume: • DBMSs do not scale enough for some applications – Velocity: • Computational speed • Development velocity: – DBMS require upfront schema design and data cleaning – Variety: • Schemas conflict with variety BigData platforms • The google stack: – Hardware: each Google Modular Data Center houses 1.000 Linux servers with AC and disks – GFS: distributed and redundant FS – MapReduce – BigTable, on top of GFS • Hadoop – open source – HDFS, Hadoop MapReduce – HBase – SQL on Hadoop: Apache Hive, IBM Jaql, Apache Pig, Cloudera Impala NoSQL • Giving up something to get something more • Giving up: – ACID transactions, to gain distribution – Upfront schema, to gain • Velocity • Variety – First normal form, to reduce the need for joins • Different from NewSQL Types of NoSQL systems • Key-value stores (Amazon Dynamo, Riak, Voldemort…) • Document databases: – XML databases: MarkLogic, eXist – JSON databases: • CouchDB, Membase, Couchbase • MongoDB • Sparse table databases: – HBase • Graph databases: – Neo4j NewSQL
    [Show full text]
  • A Natural Language Interface for Querying Graph Databases Christina
    A Natural Language Interface for Querying Graph Databases by Christina Sun S.B., Computer Science and Engineering Massachusetts Institute of Technology, 2017 Submitted to the Department of Electrical Engineering and Computer Science in Partial Fulfillment of the Requirements for the Degree of Master of Engineering in Computer Science and Engineering at the MASSACHUSETTS INSTITUTE OF TECHNOLOGY June 2018 c Massachusetts Institute of Technology 2018. All rights reserved. Author............................................................. Department of Electrical Engineering and Computer Science May 25, 2018 Certified by . Sanjeev Mohindra Assistant Group Leader, Intelligence and Decision Technologies, MIT Lincoln Laboratory Thesis Supervisor Accepted by. Katrina LaCurts Chair, Master of Engineering Thesis Committee 2 A Natural Language Interface for Querying Graph Databases by Christina Sun Submitted to the Department of Electrical Engineering and Computer Science on May 25, 2018, in Partial Fulfillment of the Requirements for the Degree of Master of Engineering in Computer Science and Engineering Abstract An increasing amount of knowledge in the world is stored in graph databases. However, most people have limited or no understanding of database schemas and query languages. Providing a tool that translates natural language queries into structured queries allows peo- ple without this technical knowledge or specific domain expertise to retrieve information that was previously inaccessible. Many existing natural language interfaces to databases (NLIDB) propose solutions that may not generalize well to multiple domains and may re- quire excessive feature engineering, manual customization, or large amounts of annotated training data. We present a method for constructing subgraph queries which can repre- sent a graph of activities, events, persons, behaviors, and relations, for search against a graph database containing information from a variety of data sources.
    [Show full text]
  • Kyle Rainville Littleton Coin Company What Is Neo4j?
    Kyle Rainville Littleton Coin Company What is Neo4j? • Graph Database (GDBMS) • Open source NoSQL DB – provides ACID-compliant transactional backend • Most popular graph database • Implemented in Java • Accessible from software using the Cypher query language Neo4j and IBM i • Unfortunately, Neo4j, at this point in time cannot run on IBM i natively • Neo4j can run on Linux on POWER The Property Graph Model Properties { key: value • Nodes } – Labels Node Relationship {:Type} Node • Relationships :LABEL :LABEL – Types Properties { key: value • Properties } Nodes • Nodes, in graph database terms, commonly represent entities • The most basic of graphs is one single node • The above is not very meaningful but graphs can quickly develop meaning Relationships • Explicitly connects nodes to each other • Allows for the finding of related data • Always have a type, start and end node, and direction • Broken relationships are disallowed – guarantees source and target • Self-referencing relationships are allowed • Allows nodes to be organized into compound entities Properties • Named values, similar to key-value pairs • Nodes and Relationships both have properties • Supported property value types: – Numeric – String – Boolean – *null is not valid (null can be modeled by the absence of a property key) Property Value Types Labels • Labels allow nodes to be grouped into sets • Nodes may have multiple labels • Labels can be indexed to allow for faster finding • Label indexes optimized for speed – Allow for index free adjacency :Actor :Movie :Director
    [Show full text]
  • Certified Graph View Maintenance with Regular Datalog Angela Bonifati, Stefania Dumbrava, Emilio Jesús Gallego Arias
    Certified Graph View Maintenance with Regular Datalog Angela Bonifati, Stefania Dumbrava, Emilio Jesús Gallego Arias To cite this version: Angela Bonifati, Stefania Dumbrava, Emilio Jesús Gallego Arias. Certified Graph View Mainte- nance with Regular Datalog. Theory and Practice of Logic Programming, Cambridge University Press (CUP), 2018, 34th International Conference on Logic Programming, 18 (3-4), pp.372-389. 10.1017/S1471068418000224. hal-01932818 HAL Id: hal-01932818 https://hal.archives-ouvertes.fr/hal-01932818 Submitted on 23 Nov 2018 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Under consideration for publication in Theory and Practice of Logic Programming 1 Certified Graph View Maintenance with Regular Datalog Angela Bonifati, Stefania Dumbrava LIRIS, Université Lyon 1, France Emilio Jesús Gallego Arias MINES ParisTech, PSL Research University, France submitted 1 January 2003; revised 1 January 2003; accepted 1 January 2003 Abstract We employ the Coq proof assistant to develop a mechanically-certified framework for evaluating graph queries and incrementally maintaining materialized graph instances, also called views. The language we use for defining queries and views is Regular Datalog (RD) – a notable fragment of non-recursive Datalog that can express complex navigational queries, with transitive closure as native operator.
    [Show full text]