Renzo Angles and Claudio Gutierrez University of Chile ACM Computing Surveys, 2008

1. Survey of Graph Database Models Renzo Angles and Claudio Gutierrez University of Chile ACM Computing Surveys, 2008

2. Introduction • Graph Data Model? • Data and/or the schema are represented by Graphs, or by data structures generalizing the notion of graph • Data Manipulation is expressed by graph-oriented operation • Graph DB-Model? • A model in which the data structures for the schema and/or instances are modeled as a directed, possibly labeled, graph, or generalizations of the graph data structure, where data manipulation is expressed by graph-oriented operations and type constructors, and appropriate integrity constraints can be defined over the graph structure

3. Why a Graph Data Model? • Natural modeling of data • Able to keep all the information about an entity in a single node and showing related information by arcs connected to it • Visible to the user and allows a natural way of handling applications data • Queries can refer directly to this graph structure • Allow users to express a query at a high level of abstraction • A data model where the operations over data are graph transformations • Comparison with other Database models

4. Motivations and Applications • Graph DB are motivated by real-life applications where component interconnectivity is a key feature • Classical App • ‘See’ Data connectivity • Managing Transportation Network • Graphical and Visual interfaces • On-line hypertext • Complex Networks • Social Networks • Information Networks • Biological Networks

5. Data structures • The representation of entities and relations is fundamental to graph DB-models • Graph DB-model is a framework for the presentation of connectivity among entities • Directed/Undirected graphs, Labeled/Unlabeled edges and nodes, Hypergraphs • Representation of Entities : Schema and Instance • Schema graph defines entity types(nodes labeled with type name) and relation(edges labeled with relation names) • Instance graph contains entities (nodes labeled entity type or identifier) and relation(labeled edge according to schema) • Tupleand sets (PaMal, GDM) and n-ary relations (GOAL, GDM)

6. Data structures (cont’d) • Representation of Relations • Attributes • Labeled edges directly related to nodes • In case of GROOVY, attributes are <node,edge,node> triples inside hypernodes • Entities • Most models do not support this feature because relations are represented as simple labeled edges • Standard Abstraction • Is-part-of, is-composed by, n-ary relation • Derivation • ISA, is-of-type • Nested • This feature is naturally supported by using hypergraph structures

7. Integrity Constraints • Schema-Instance Consistency • Entity Type checking • The instance should contain only entities and relations from entity types and relations that were defined in the schema • An entity in the instance may only have those relations or properties defined for its entity type • Type checking constitute • Object Identity and Referential Integrity • Set-based data models such as the relational model are value-based • Object Identity • Every node has its own identifier • Referential Integrity • ‘Only existing entities be referenced’

8. Query and Manipulation Languages • A query language is a collection of operators or inferrencing rules • Existing Query Language • G • Based on regular expressions • Graphical query: set of labeled directed multigraphs • Nodes are variables or constants • Edges can be labeled with regular expressions • G+ • Extension of G • Graphical query • Graph query + summary graph • GraphLog (G-log) • Extension of G+ • Adds negation • Graph pattern = graph query + edge query + summary graph • Includes transitive closure operator

9. GraphLog example • Query A asks for the names of Mary’s grandparents (fixed path query) • Query B asks for the name of the maternal grandmother of Mary (tree-like query) • Query C calculates Mary’s Ancestors (transitive closure)

10. A Genealogy Diagram – an example

11. LDM (Logical Data Model) • The schema uses two basic type nodes for representing data values (N and L), and two nodes (NL and PP) to establish relations among data values in a relational style • The instance is a collection of tables, one for each node of the schema.

12. Hypernode Model • The schema defines a person as a complex object with the properties name and lastname of type string, and parent of type person • The instance shows the relations in the genealogy among different instances of person

13. GROOVY • At the schema level, we model an object PERSON as a hypergraph that relates the attributes NAME, LASTNAME and PARENTS • Value functional dependency NAME,LASTNAME → PARENTS logically represented by the directed hyperedge ({NAME, LASTNAME} {PARENTS})

14. Sematic-XT • This model does not define an schema • In the first level, the graph contains the relations Name and Lastname to identify people (P1, . . . , P6) • In the second level we use the abstraction of Person, to compress the attributes Name and Lastname and represent only the relation Parent between people

15. GGL • Schema and instances are mixed • Packaged graph nodes (Person1, Person2, . . . ) are used to encapsulate information about the graph defining a Person • Relations among these packages are established using edges labeled with parent

16. PaMaL • Schema: basic type (string), class (Person), tuple (X), set (*) nodes for the schema level • Atomic (George, Ana, etc.), instance (P1, P2, etc), tuple and set nodes for the instance level • Note the use of edges ∈ to indicate elements in a set, and the edge typ to indicate the type of class Person (these edges are changed to val in the instance level).

17. GRAM • At the schema level, we use generalized names for definition of entities and relations • At the instance level, we create instance labels (e.g. PERSON 1) to represent entities, and use the edges (defined in the schema) to express relations between data and entities

18. Object Exchange Model (OEM) • Schema and instance are mixed • The data is modeled beginning in a root node &pp, with children person nodes, each of them identified by an Object-ID (e.g. &p2) • These nodes have children that contain data (name and lastname) or references to other nodes (parent)

19. RDF