LGP modeling (1)
• Graph modeling diverges from traditional relational modeling
• Once the domain has been captured
• Relational: definition of schemas
Copyright By PowCoder代写加微信 assignmentchef
• Graph: enrich the domain with information needed by applications (entities as nodes, roles as labels, connections to neighboring entities as relationships , attributes as properties)
• Two main goals
• data-centric designàcorrect labels an properties to nodes
• semantic contextànamed and directed relationships between nodes
LGP modeling (2)
• Graphs are naturally addic1ve
• New kinds of rela1onships, nodes, labels, and subgraphs can be added to an exis1ng structure without impac1ng exis1ng queries and applica1on func1onali1es
• Structures and schemas can emerge incrementally with the understanding of the problem space
• Data are connected as the domain dictates
LGP modeling (3)
• Applica’on needs always in mind
• Example:
AS A reader who likes a book, I WANT to know which books other readers who like the same book have liked, SO THAT I can find other books to read.
LGP modeling (4)
• There is not a unique set of rules, but generally
• En55es of interest: nodes (can be labeled and grouped)
• Connec5ons between en55es and seman5c context of each en5ty: rela5onships
• They give structure to the domain
• Clarifica5on of the seman5cs of a rela5onship: direc5on and proper5es of the rela5onship
• For bidirec5onal rela5onships, a rela5onship exists for each direc5on
• En5ty aCributes and metadata: node proper5es
• Timestamps, version numbers…
• Strength, weight, or quality of a rela5onship and metadata: rela5onship proper5es
Granularity of relationships
• Relationships can be defined at different granularity levels
• Example: relationships between a user, her delivery address and her billing
address can be represented via • Two relationships only
• One relationship address specified by properties only • Both solutions
Emerging facts
• When two or more domain en..es interact for a period of .me, a fact can emerge
• It is possible to represent it as a separate node with connec.ons to each of the en..es engaged in that fact
• The addi.onal node can represent the result of the interac.on among the en..es
Analyzing LPGs
• Graph analy*cs: use of any graph-based approach to analyze connected data
• Graph algorithms use the rela*onships between nodes to infer the organiza*on and dynamics of complex systems
• Pa=ern–based querying is used for local data analysis • Rela*onships in a graph naturally form paths
• Querying or traversing the graph involves following paths
Pattern-based queries: Cypher (1)
• Declara’ve query language for graphs
• Idea: query for pa7ers represen’ng what should be returned
(emil)<-[:KNOWS]-(jim)-[:KNOWS]->(ian)-[:KNOWS]->(emil)
• This pattern describes in ASCII a path that connects nodes • Basic pattern idea: (node)-[relationship]->(node) •emil,jimandianareuse asidentifiers
Pa#ern-based queries: Cypher (2)
• Declara’ve query language for graphs
• Idea: query for pa7ers represen’ng what should be returned
(emil:Person {name:’Emil’})
<-[:KNOWS]- (jim:Person {name:’Jim’})-[:KNOWS]->(ian:Person {name:’Ian’}) -[:KNOWS]->(emil)
• Iden’fiers now bounded to graph data through their • Name property
• personlabel
Pattern-based queries: Cypher (3)
• A Cypher query
• Anchors one or more parts of a pa3ern to specific loca7ons in a graph using
predicates
• Flexes the unanchored parts around to find local matches
• The anchor points in the real graph are determined based on the labels and property predicates in the query.
• Metainforma7on about exis7ng indexes, constraints, and predicates can be used
• A Cypher query is composed of clauses
Pattern-based queries: Cypher (4)
• The match clause represents nodes and relationships we are interested into
• specification by example
MATCH (a:Person{name:’Jim’})-[:KNOWS]->(b)-[:KNOWS]->(c), (a)-[:KNOWS]->(c)
RETURN b, c
• Nodes are represented with parenthesis
• Node labels prefixed by colon
• Rela:onships are represented with arrows
• Rela:onship names prefixed by colon and within squared brackets • Key-value pair proper:es are specified within curly brackets
Pattern-based queries: Cypher (5)
• WHERE: specifies filter for pa.ern matching results
• CREATE [UNIQUE]: creates of nodes and rela5onships
• MERGE: returns a pa.ern or adds it to the graph it does not exist
• DELETE: removes nodes, rela5onships, proper5es
• SET: sets property values
• FOREACH: executes an update opera5on for all provided elements • UNION: merges results from queries
Pattern-based queries: Cypher (examples – 1)
(shakespeare:Author {firstname:’William’, lastname:’Shakespeare’}),
(juliusCaesar:Play {title:’ ’}),
(shakespeare)-[:WROTE_PLAY{year:1599}]-> (juliusCaesar),
Pattern-based queries: Cypher (examples – 2)
• MATCH (n) RETURN n
• MATCH (p:Play) RETURN p
• MATCH (p:Play) RETURN p.title
• MATCH (a:Author)-[w:WROTE_PLAY]-> (p:Play{title:” “})
• MATCH (a:Author)-[w:WROTE_PLAY]->(p:Play) WHERE p.title = ” ”
RETURN a,w,p
RETURN a,w,p
(theater:Venue {name:”Theatre Royal”}), (newcastle:City {name:”Newcastle”}), (bard:Author {lastname:”Shakespeare”}), (newcastle)<-[:STREET|CITY*1..2]-(theater)<-[:VENUE]-()-[:PERFORMANCE_OF]->() -[:PRODUCTION_OF]->(play)<-[:WROTE_PLAY] -(bard) RETURN DISTINCT play.title AS playGraph algorithms• Besides pa(ern-based local queries, graphs can be analyzed for more general analysis• Examples:• Pathfinding• Community detecAon • Centrality• To this end, graph DBMSs can be equipped with libraries that support advanced analyAcs, typically based on graph theory• BFS, DFS, single source/all sources shortest path, minimum cost spanning tree, random walksNeo4J: Transactions• Transac’ons are supported by Neo4j• Writes occur within a transac’on context, write locks on any nodes and rela’onshipsinvolved in the transac’on• On successful comple’on of a transac’on, changes are flushed to disk and the write locks released• On failure, writes are discarded and the write locks releasedàconsistent state of graph• If two transac’ons aCempt to write same graph elements concurrently, Neo4j detect a poten’al deadlock and serialize the transac’ons• Writes within a single transac’onal context are not visible to other transac’ons • Neo4j is ACID-compliant Graph databases: use casesSuitable for:• Rou/ng, dispatch, and loca/on-based services• Financial services, fraud detec/on• Social domains• Recommenda/on engines• Contact tracingNot suitable for:• Whenever the graph model does not represent well the data• Resource Description Framework• Goal: provide a framework for describing resources• Main elements:• Resources to be describedàanything that can have a unique identifier (URI) • Properties associated with resources• Classes used to bucket resources• RDF data composed as triples
RDF (example)
• Alice is a person
• Alice’s userID is 123 • Alice …
• Bob likes likes
• RDF can be serialized in different ways
• Examples: RDF/XML, RDF/ JSON, Turtle, N-Triples
[Legend: subject, predicate, object]
© 2014 European Commission
RDF characteris-cs
• Nodes do not have a structure • They are either literals or URIs
• Data are broken into atomic triples
• Cannot model the same rela
Reviews
There are no reviews yet.