Operation Graph Database

7/30/2019 Operation Graph Database

1/77

Operations on a Graph Database (Part 1 - Nodes)

Graph databases are still quite unfamiliar to many developers. This is the first post in a seriesdiscussing the operations a graph database makes available to the developer. Just like thereare only so many different things you can do on a relational database (like CREATE TABLE

or INSERT), there are only so many things you can do on a graph database. It is worthlooking at them one at a time, and thats the goal of this series. This first post is on creatingand deleting nodes.

To recap, a graph database contains nodes and edges, orMeshObjectsandRelationships(aswe call them in InfoGrid), orInstancesandLinks(as the UML would call them), orResourcesandTriples(as the semantic web folks would call them), or boxes and arrows (aswe draw them on a white board).

Nodes are those objects in a graph database that can stand on their own, they dont depend on

anything else. Edges are those objects that depend on the existence of (typically two) other

objects, their source and their destination; we think of edges as connecting nodes.

To create a node in a graph database is one of its basic operations. For example, in InfoGrid,you can simply say:

MeshObjectcreateMeshObject()

and voila, you have one. Similarly, you can delete a node by saying:

deleteMeshObject( MeshObject toDelete )

There are few conditions around those operations, such as that you have to have a transactionopen, and that you have to have access rights to actually perform this operation, but that goeswithout saying.

When deleting a node, the graph database may require you to first delete all edges connectedto the node before you get to delete it. Or, it may ripple delete all connected edges as partof the delete operation. There are some differences in the various graph database products onthis; neither will make much of a difference to the developer.

If the graph database enforces a model (aka schema), as some graph databases do, you mayneed to make sure you dont attempt to delete a node in a way that the schema would beviolated. For example, if the schema says an Order must be placed by exactly one

Customer, and you are attempting to delete the node representing the Customer, the graph

database may prevent you from doing that as long as there still are nodes representing Order

7/30/2019 Operation Graph Database

2/77

related to the Customer node. Well discuss schemas and graph databases in more detail in a

later post.

For now, we learned two basic operations on a graph database:

create node

delete node.

Operations on a Graph Database (Part 2 - Edges)

In thefirst postof this series, we looked at creating and deleting Nodes. Today we arelooking at Edges.

Unlike simpler NoSQL data stores like key-value stores, graph databases not only managenodes, but also edges. Edges are things that connect two other data elements, and graphdatastores have them as a basic element managed by the store. Think of them as the line

between two boxes; thats exactly what they are.

Edges often take developers a while to get used to, because there isnt much precedent in the

world of software. Even the so-called relational database doesnt actually haverelationships as a first-class concept: we have to infer them from primary/foreign keydeclarations; and that only works if developers actually declare them, which is not all thatcommon.

Edges dont exist in normal code either. Pretty much all mainstream programming languagesonly have pointers, not relationships aka edges. Edges are bidirectional, managed things,

7/30/2019 Operation Graph Database

3/77

while pointers are one-directional and not managed at all. Lets take an example (using asimplified version of the InfoGrid API, see theFirstStepexample for complete code of abasic URL tagging application):

MeshObject customer = createMeshObject(); // create first node, calledMeshObject in InfoGridMeshObject order = createMeshObject(); // create second nodecustomer.relate( order );

What did we just do?

We created a customer object, and an order object, and then we said the two are related. (Thegraph database makes sure the objects get persisted automatically when the Transaction isclosed; not shown here as we try to stay on topic.)

If we had to do that in straight Java, wed do something like this:

Customer customer = new Customer();Order order = new Order();

customer.addOrder( order );order.setCustomer( customer );

and wed have to write the code to manage the edge ourselves, such as:

class Customer {...private List ordersOfThisCustomer = new ArrayList();

}

class Order {...private Customer customerPlacingThisOrder;

}

The question is: why do we have to do all this work for a simple 1-N relationship betweencustomers and orders? The graph database API is much better: for one, it lets the databaseworry about how and when to save and restore the involved objects. It could, for example, (asInfoGrid does), decide to restore from disk the Customer object but not the Order object forsome time because the application code does not currently need to know the Customers

orders. And referential integrity is always guaranteed. For example:

7/30/2019 Operation Graph Database

4/77

customer.traverseToNeighbors().getSingleMember(); // returns the singleOrder objectorder.traverseToNeighbors().getSingleMember(); // returns the singleCustomer object

// now we delete the edgecustomer.unrelate( order );

customer.traverseToNeighbors().getSingleMember(); // returns nullorder.traverseToNeighbors().getSingleMember(); // returns null

If there is no graph database involved, we need to do it manually, like this:

customer.removeOrder( order );order.setCustomer( null );

and hope that we dont forget one of those calls, because then referential integrity would

be out the window, and the next application crash is a certainty.

Imagine if we wanted to restore the Customer and the Order object at different times fromdisk. Without help from sophisticated run-time infrastructure like a graph database, band-aid-

technologies such as object-relational mapping is most likely going to create a separateinstance for, say, the restored Order object, and code such as List.remove( ) is not going towork because we have two Java objects in memory that represent the same order. (Shudder.)

Of course, code could be written to manage all of this manually, but its much better if the

platform takes care of it.

[The astute reader will notice that the plain Java example has one advantage: it provides typesafety. I'll have to say more about this in an upcoming post about types.]

So: after working with graph databases for a while, many people believe that edges areactually the much more interesting and useful concept than nodes. Just like many datamodelers think that the value of a data model is often more in the way the entities areconnected by relationships than the details of the entities. Automatic management ofrelationships make things simple, and thats what any good database should do. Developers

have enough to worry about, and graph databases provide real help here.

7/30/2019 Operation Graph Database

5/77

Operations on a Graph Database (Part 3 - Types)

We need to talk about properties, but before we can do that, we need to talk about types. In aprevious post we looked at the variousalternatives for typingand their pros and cons. Graphdatabases may take the two following approaches to typing, and anything in between:

No types at all: nodes, edges and properties have no types; anything goes.

Fully typed: nodes, edges and properties are all strongly typed; the graph databaserefuses to perform an operation that is not consistent with the type system.

There are some graph databases on the market that require types for some elements (edges,for example) but dont allow types for others (nodes, or properties), so hybrids are possible.

A totally untyped graph database has it easy: it allows an arbitrary number of properties,distinguished only by name and with arbitrary values. So the operations are:

Defined on Node and/or Edge:

setProperty( String label, Object value ); // returns nothinggetProperty( String label ); // returns the valuegetAllProperties(); // returns a set of all currentproperty labels

A fully typed graph database needs to offer a much larger set of operations. They are:

7/30/2019 Operation Graph Database

6/77

Defined on Node:

bless( NodeType type ); // returns nothingunbless( NodeType type ); // returns nothinggetTypes(); // returns a set of all current NodeTypessetProperty( PropertyType type, Object value ); // returns nothinggetProperty( PropertyType type ); // returns the value of theProperty

Defined on Edge:

bless( EdgeType type ); // returns nothing

unbless( EdgeType type ); // returns nothinggetTypes(); // returns a set of all current EdgeTypessetProperty( PropertyType type, Object value ); // returns nothinggetProperty( PropertyType type ); // returns the value of theProperty

To determine the available properties, one examines the meta-data available in the typesystem:

Defined on NodeType and on EdgeType

getPropertyTypes(); // returns a set of all possible properties definedby the type

The abstract API Im listing here is the general case for a fully dynamically-typedhypothetical graph database. No product that Im aware of implements them all, butInfoGridcomes close. If you read theJavaDoc for MeshObject, for example (MeshObject is

InfoGrids name for Node), you will find all of the above Node operations. The operationsare also there for Relationships (InfoGrids name for Edge) except that for efficiency reasons1) they are defined on MeshObject, and 2) InfoGrid does not support properties on edges.(InfoGrid V1 used to, but we decided to eliminate that support; will talk about that someother time).

If a graph database was fully typed but using a static type system, we obviously could notbless either nodes or edges with new types at run-time as this API defines. (InfoGrid V1 usedto be that way; InfoGrid V2 is fully dynamic).

7/30/2019 Operation Graph Database

7/77

In the next part, well talk about properties then.

Operations on a Graph Database (Part 4 - Properties)

Today were looking at properties. There are a few different philosophies that a graphdatabase might employ.

1. The purists often argue that properties arent needed at all: all properties can be modeled as

edges to separate nodes, each of which represents a value. Thats of course true at some level:instead of a node representing a person, for example, that contains the persons FirstName,

LastName and DateOfBirth, one could create two String nodes and a TimeStamp node, andconnect the with edges representing first name, last name and date of birth.

The non-purists counter that for practical purposes, it is much simpler to think of these data

elements as properties instead of as independent things that are related. For example, it makesdeletion of the Person much simpler (and we dont need to implement cascading delete rules).Also, there are performance tradeoffs: if the three properties are stored with their owningnode, for example, a single read is required to restore from disk the node and all of itsproperties. This would require at least 4 (perhaps 7, depending on how edges are stored in thegraph database) reads if stored independently.

In InfoGrid, we believe in properties. We dont prevent anybody from creating as many edges

as they like, of course, but think that properties definitely have their uses.

2. Properties have to be named in some fashion, and the simplest approachused by anumber of graph database projectsis to give them a String label as a name.Correspondingly, the essence of the property API using Strings as labels would look like this:

public Object getPropertyValue( String name );

public void setPropertyValue( String name, Object value );

7/30/2019 Operation Graph Database

8/77

The advantage of this model is obviously that it is very simple. The disadvantage is that forcomplex schemas or models created by multiple development teams, name conflicts andspelling errors for property names occur more frequently than one would like. At least that is

our experience when building InfoGrid applications, which is why we prefer the nextalternative:

3. Properties are identified by true meta-data objects. We call them PropertyTypes, and theyare part of what developers define when defining an InfoGrid Model. So the InfoGridproperty API looks like this:

public Object getPropertyValue( PropertyType name );

public void setPropertyValue( PropertyType name, Object value );

Well have more to say on the subject of meta-data and Models in a future post.

Finally, we need to discuss what in a graph database can carry properties. Everybody other

than the purists (see above) agree that nodes (called MeshObjects in InfoGrid) can carryproperties. Some graph database projects (like the now-obsolete InfoGrid V1) also allowproperties on edges (called Relationships in InfoGrid). Others (InfoGrid today) do not allowthat.

It may sound peculiar that we had what looks like a more powerful approach in an earlierInfoGrid version but not any more. Here is what we observed in our practice with InfoGrid:

Properties on edges are fairly rare compared to Properties on nodes. Weve beeninvolved in several projects over the years where the Models were substantial and nota single property was found on any edge; nor did anybody ask for one.

If a property is needed on an edge, there is an easy workaround known as associativeentity in data modeling circles: simply create an intermediary node that carries theproperty.

7/30/2019 Operation Graph Database

9/77

The deciding factor was performance: if properties are rarely needed on edges, it ispossible to traverse from one node to a neighbor node in a single step. If propertiesare needed on edges, the edge needs to be represented as a separate object, and a

traversal from one node to its neighbor requires two steps: from the start node to theconnecting edge, and from the edge to the destination node. So not having propertieson edges can improve performance by a 100%. Which is why we got rid of them forInfoGrid V2.

In the next post, we will look at data types for properties.

Operations on a Graph Database (Part 5 - Identifiers)

Well, identifiers arent much of an operation, but there are some operations related to

identifiers, thus the title.

All first-class objects in a graph database typically have a unique identifier. This means nodeshave unique identifiers, and for those graph databases that represent edges as distinct objects(seeprevious discussion on the pros and cons), they have unique identifiers, too.

This means we can ask a node for their identifier, remember the identifier, and later find thenode again by looking it up in the graph database. In InfoGrid, this looks as follows:

MeshObject someNode = ...; // some MeshObject aka Node

MeshObjectIdentifier id = someNode.getIdentifier();

and later we can do this:

7/30/2019 Operation Graph Database

10/77

MeshBase mb = ...; // some MeshBase

MeshObject nodeFoundAgain = mb.findMeshObjectByIdentifier( id );

As you can see, InfoGrid uses an abstract data type called MeshObjectIdentifier, which youcan think of as String for a second. (see below.) In InfoGrid, all identifiers are long-lasting.This means, your object will still have the same MeshObjectIdentifier after you rebooted yourdatabase. This has some advantages, e.g. you can define well-known objects in your graphdatabase to which you can easily return even weeks later.

Other graph databases may use different data types as identifiers (e.g. int or long), but the useof identifiers is common with the above operations. They may or may not be the same afterrebooting of the database.

Why does the type of identifier matter? Well, it depends on the application you have in mind.For InfoGrid applications, we primarily care about web applications, specifically REST-fulweb applications. And so InfoGrid web applications generally use MeshObjectIdentifiers thatidentical to the URLs of the application. Lets make an example:

Assume you have a URL bookmarking application which runs at http://example.com/. Lets

say a user creates tag books, which can be found at URL http://example.com/books/. It

would be most straightforward to create a MeshObject with MeshObjectIdentifierhttp://example.com/books/. Which is exactly what InfoGrid does by default. No impedancemismatch between URLs that the user sees, the objects in the application layer, and thedatabase! This leads to dramatic simplification of development and debugging.

Operations on a Graph Database (Part 6 - Traversals)

Traversals are the most common operations on a graph database. They are just as importantfor graph databases as joins are for relational databases. But of course, they are somethingelse as graphs are not tables.

7/30/2019 Operation Graph Database

11/77

A traversal in a graph database is uniquely described by two data items:

a start node

a specification for the traversal

A traversal always leads to a set of nodes. Depending on the structure of the graph beingtraversed, that set may contain many, one or zero nodes. For example, if we traverse from anode representing a Person to the nodes representing their grandchildren, we may or may notfind any, depending on whether they have any.

From a given node, we can traverse in many different ways (i.e. same node, differenttraversal specifications). Or, given the same traversal specification, we can start withdifferent nodes.

By way of analogy, consider street directions:

start node: my house

traversal specification: first turn left, then go either straight or left.

The result of this particular traversal is a single-element set containing the neighborhoodpark. If you had started at the same node (my house), but gone right first, you would not havearrived at the park. If you had started at a different node (somebody elses house), you may or

may not have arrived at the park. You may not have arrived anywhere (perhaps there is noleft that one can take from certain houses). Or you might have arrived in multiple places (go

7/30/2019 Operation Graph Database

12/77

either straight or left might not take you to the same part regardless which you take, but

taken you into different directions.

Graph database products seem to differ on how to deliver to the developer the set of nodesthat is the result of a traversal. In InfoGrid, all traversals produce a MeshObjectSet, which, asthe name says, is a set of nodes. One can then iterate over that set, for example, subset it,unify it with another or ask how many elements it has. In other products, traversals producean iterator directly which then can be queried for one member of the result set at a time.Regardless of API details, the result of a traversal is always a set (e.g. it cant containduplicates.)

Just like there are many ways of giving directions, traversal specifications can be captured in

many different ways. In InfoGrid, we haveyou guessed itan abstract data type calledTraversalSpecificationand several different classes that implement that type, such as:

traverse by going to all direct neighbor nodes of the start node

go to all neighbor nodes related with a edge of a particular type in a particulardirection (e.g. traverse from employee to their manager(s))

go N steps in sequence, where each step can be any traversal specification

go N steps in parallel, and unify the resulting set

select a subset of the found nodes based on some criteria, etc.

TheFirstStep exampleshows some simple traversals.

7/30/2019 Operation Graph Database

13/77

And just for simplicity, InfoGrid also allows traversals starting from a set of start nodes, notjust one. So we can say things like this:

MeshObject me = ...;MeshObjectSet myParents = me.traverse( childToParents );MeshObjectSet myGrandParents = myParents.traverse( childToParents );

In our experience, working with sets makes complex traversals very easily understandable.

Operations on a Graph Database (Part 7 - Sets)

Sets are a core concept of most databases. For example, any SQL SELECT statement in arelational database produces a set. Sets apply to Graph Databases just as well and are just asuseful:

The most frequently encountered set of nodes in a Graph Database is the result of a traversal.For example, in InfoGrid, all traversal operations result in a set like this:

MeshObject startNode = ...; // some start nodeMeshObjectSet neighborNodes = startNode.traverseToNeighbors();

We might as well have returned an array, or an Iterator over the members of the set, were it

not for the fact that there are well-understood set operations that often make our jobs asdevelopers much simpler: like set unification, intersection and so forth.

For example, in a social bookmarking application we might want to find out which sites bothyou and I have bookmarked. Code might look like this:

MeshObject me = ...; // node representing meMeshObject you = ...; // node representing you

TraversalSpecification ME_TO_BOOKMARKS_SPEC = ...;

7/30/2019 Operation Graph Database

14/77

// how to get from a person to their bookmarks, seepost on traversalsMeshObjectSet myBookmarks = me.traverse( ME_TO_BOOKMARKS_SPEC );MeshObjectSet yourBookmarks = you.traverse( ME_TO_BOOKMARKS_SPEC );

// Bookmarks that you and I shareMeshObjectSet sharedBookmarks = myBookmarks.intersect( yourBookmarks );

Notice how simple this code is to understand? One of the powers of sets. Or, if you knowwhat a minus operation is on a set, this is immediately obvious:

// Bookmarks unique to meMeshObjectSet myUniqueBookmarks = myBookmarks.minus( yourBookmarks );

This is clearly much simpler than writing imperative code which would have lots of loopsand if/then/elses and comparisons and perhaps indexes in it. (And seeing this might put someconcerns to rest that NoSQL databases are primitive because they dont have a SQL -likequery language. Id argue its less the language but the power of sets, and ifyou have setsyou have a lot of power at your fingertips.)

To check out sets in InfoGrid, try packageorg.infogrid.mesh.set . Clearly much more canbe done than we have so far in InfoGrid, but its a very useful start in our experience.

Operations on a Graph Database (Part 8 - Events)

The database industry is not used to databases that can generate events. The closest therelational database has to events are stored procedures, but they never reach out back to theapplication, so their usefulness is limited. But events are quite natural for graph databases.Broadly speaking, they occur in two places:

Events on the graph database itself (example: tell me when a transaction has beencommitted, regardless on which thread)

7/30/2019 Operation Graph Database

15/77

Events on individual objects stored in the graph database (example: tell me whenproperty X on object Y has changed to value Z, or tell me when Node A has a new

Edge)

Events on the GraphDB itself are more useful for administrative and management purposes.For example, an event handler listening to GraphDB events can examine the list of changesthat a Transaction is performing at commit time, and collect statistics (for example).

From an application developers perspective, events on the data are more interesting:

An example may illustrate this. Imagine an application that helps manage an emergency roomin a hospital. The applications object graph contains things such as the doctors on staff, the

patients currently in the emergency room and their status (like arrived, has been triaged,

waiting for doctor, waiting for lab results etc.) Doctors carry pagers. One of the

requirements for application is that the doctor be paged when the status of one of theirassigned patients changes (e.g. from waiting for lab results to waiting for doctor).

With a passive database, i.e. one that cannot generate events, like a typical relationaldatabase, we usually have to write some kind of background task (e.g. a cron job) thatperiodically checks whether certain properties have changed, and then sends the message tothe pager. That is very messy: e.g. how does your cron job know which properties *changed*from one run to the next? Or we have to add the message sending code to every single screenand web service interface in the app that could possibly change the relevant property, whichis just as messy and hard to maintain.

With a GraphDB like InfoGrid, you simply subscribe to events, like this:

MeshObject patientStatus = ...; // the node in the graph representing apatient's statuspatientStatus.addPropertyChangeListener( new PropertyChangeListener() {

public void propertyChanged( PropertyChangeEvent e ) {sendPagerMessage( ... );

});}

The graph database will trigger the event handler whenever a property changed on thatparticular object. Its real simple.

7/30/2019 Operation Graph Database

16/77

Postado por Francisco Gonalves Pereira Neto s04:310 comentriosMarcadores:Banco de Dados de Grafo,Banco de Dados de Rede,Banco de DadosHierrquico

sbado, 24 de abril de 2010PercepoFiguras 3D de Rua

7/30/2019 Operation Graph Database

17/77

7/30/2019 Operation Graph Database

18/77

7/30/2019 Operation Graph Database

19/77

7/30/2019 Operation Graph Database

20/77

7/30/2019 Operation Graph Database

21/77

7/30/2019 Operation Graph Database

22/77

Veja o vdeo dele criando uma de suas obras:CLIQUE AQUI

Postado por Francisco Gonalves Pereira Neto s08:060 comentriosMarcadores:3D,Percepo

Percepo

7/30/2019 Operation Graph Database

23/77

7/30/2019 Operation Graph Database

24/77

7/30/2019 Operation Graph Database

25/77

7/30/2019 Operation Graph Database

26/77

7/30/2019 Operation Graph Database

27/77

7/30/2019 Operation Graph Database

28/77

Postado por Francisco Gonalves Pereira Neto s07:010 comentriosMarcadores:Percepo

PercepoFiguras 3D de Rua

7/30/2019 Operation Graph Database

29/77

7/30/2019 Operation Graph Database

30/77

7/30/2019 Operation Graph Database

31/77

7/30/2019 Operation Graph Database

32/77

7/30/2019 Operation Graph Database

33/77

7/30/2019 Operation Graph Database

34/77

7/30/2019 Operation Graph Database

35/77

7/30/2019 Operation Graph Database

36/77

7/30/2019 Operation Graph Database

37/77

7/30/2019 Operation Graph Database

38/77

7/30/2019 Operation Graph Database

39/77

7/30/2019 Operation Graph Database

40/77

7/30/2019 Operation Graph Database

41/77

7/30/2019 Operation Graph Database

42/77

7/30/2019 Operation Graph Database

43/77

7/30/2019 Operation Graph Database

44/77

7/30/2019 Operation Graph Database

45/77

7/30/2019 Operation Graph Database

46/77

7/30/2019 Operation Graph Database

47/77

7/30/2019 Operation Graph Database

48/77

7/30/2019 Operation Graph Database

49/77

7/30/2019 Operation Graph Database

50/77

7/30/2019 Operation Graph Database

51/77

7/30/2019 Operation Graph Database

52/77

7/30/2019 Operation Graph Database

53/77

7/30/2019 Operation Graph Database

54/77

7/30/2019 Operation Graph Database

55/77

7/30/2019 Operation Graph Database

56/77

7/30/2019 Operation Graph Database

57/77

7/30/2019 Operation Graph Database

58/77

7/30/2019 Operation Graph Database

59/77

7/30/2019 Operation Graph Database

60/77

7/30/2019 Operation Graph Database

61/77

7/30/2019 Operation Graph Database

62/77

Postado por Francisco Gonalves Pereira Neto s06:500 comentriosMarcadores:3D,Iluso de tica,Percepo

Postagens mais antigasIncioAssinar:Postagens (Atom)

Banco de Dados - KM - BRM - BPM - MDA - SOA

Um blog da e-Reality voltado para as tecnologias de Banco de Dados - DB, Gesto de Regrasde Negcio - BRM, Gesto do Conhecimento - KM, Gesto de Processos de Negcio - BPM,Model Driven Architecture - MDA, Service Oriented Architecture - SOA, EnterpriseArchitecture

7/30/2019 Operation Graph Database

63/77

Recent Posts

Marcadores

0FN (1) 1 - PBD Ementa (1) 1.1 - PBD - Material Didtico Complementar (1) 1.2 - Sites de BD (1) 1970 (1) 1976 (1) 1977 (1) 1998 (1) 1FN (1) 2001 (1) 2003 (1) 2005 (1) 2006 (1) 2FN (1) 3D (2) 3FN (1) ABD (1) ABRD (1) Abstrao (6) ACID (1) AD (1) Administrao de Banco de Dados (1) Administrao de Dados (1) Agregao (3)

7/30/2019 Operation Graph Database

64/77

Algoritmo (1) ANSI/SPARC (3) Apostila (1) Aprendizagem Organizacional (1) Argumento (1) Aristteles (1) Arquitetura (3) Arquitetura Empresarial (1) Artefato de Conhecimento (1) Artificial Intelelligence (3) Artigo (6) Assero (1) Associao (1) Atenas (1) Atomicidade (1) Atribuio (1) Atributo (6) Atributo Multi-valorado (1) Auto Relacionamento (2) Balanced Scorecard (1) Banco de Dados (28) Banco de Dados Cliente-Servidor (1) Banco de Dados de Grafo (1) Banco de Dados de Rede (2) Banco de Dados Distribudo (1) Banco de Dados Hierrquico (2) Banco de Dados Relacional (1) BD (21) BD Caracterstica (1) BDCS (1) Benefcio (1) Bertalanffy (1) BI (9) Biblioteca (1) Bing (1) Blog (5) BPEL (3)

BPM (6) BR (6) BRE (3) BRMS (2) BSC (1) Busca (3) Business Intelligence (10) Business Process Management (1) Business Rule Engine (1) Business Rule Management System (1) Business Rules (14) Businnes Process (1) C.J.Date (1)

7/30/2019 Operation Graph Database

65/77

CADIE (2) Capital (1) Capital ambiental (1) Capital de relacionamento (1) Capital Econmico (1) Capital estrutural (1) Capital intelectual (1) Capital Natural (1) Capital Social (1) Capra (1) Caracterstica (2) Cardinalidade (2) Chave (7) Chave Alternada (1) Chave Candidata (1) Chave Estrangeira (1) Chave Primria (1) Chave Secundria (1) Chen (1) Ciclo de Vida (3) Cincia (2) Classe (1) Classificao (3) Cobertura (2) Codd (2) Cognio (5) Colaborao (4) Coleta de Informao (1) Coluna (1) Competence (2) Competncia (3) Completeza (3) Componente (1) Componente Estrutural (1) Comportamento (2) Composio (2) Comunicao (4)

Comunidade (3) Comunidade de Prtica (3) Comunidade Virtual (3) Conceito (10) Conceito Associativo (1) Conceito Construtivo (1) Concept Map (4) Conhecimento (34) Conhecimento Objetivo (1) Conhecimento Organizacional (1) Conhecimento Subjetivo (1) Conhecimento Tcito (2) Consistncia (5)

7/30/2019 Operation Graph Database

66/77

Construtor (1) Construtor Semntico (1) Contedo (2) Cooperao (3) Coordenao (2) Correo (3) Crena (3) criatividade (1) Critrio de Qualidade (9) CSCL (1) CSCW (3) Clculo (1) Clculo dos Predicados (1) Clculo dos Predicados de Primeira Ordem (1) Crebro (2) DA (1) dado (10) Data (7) Data Mart (2) Data Minning (11) Data Warehouse (13) Database (16) Database Design (1) Database Management System (1) Database Marketing (1) Database System (1) DataGramaZero (1) DB (12) DBA (1) DBMS (3) DBS (2) DDL (1) de Negcio (1) Decision Support Systems (5) Decomposio (2) Deduo (1) Definio (3)

Dependncia Funcional (1) DER (12) Descrio (1) Diagrama (6) Diagrama da UML (5) Diagrama de Atividades (1) Diagrama de Classes (3) Diagrama de Entidades e Relacionamentos (6) Diagrama de Objetos (1) Dicionrio (1) DIK (7) DIKC (1) DIKW (5)

7/30/2019 Operation Graph Database

67/77

DM (2) DML (1) Domnio (1) Domnio de Conhecimento (1) Domnio de Discurso (1) Domnio do problema (1) DSS (5) Durabilidade (1) DW (8) e-Book (2) e-Catalog (2) e-Conomy (1) e-Databse (2) e-Enterprise (1) e-Intelligence (1) e-Knowledge (10) e-Library (5) e-Mail (1) e-ncyclopedia (2) e-Org (2) e-Paper (1) e-Reality (2) e-Search (1) e-Site (1) e-Video (1) EAD (1) Edio (1) Educao (1) EI (1) Elemento (3) Elemento Computacional (1) Elemento de Cognio (1) Elemento de Conhecimento (7) Elemento Simblico (1) Elmasri (1) Ementa (6) Empresa (3)

Empresa Virtual (1) Engenharia da Informao (2) Engenharia Ontolgica (1) Enterprise Framework (7) Enterprise Intelligence (1) Entidade (4) Entidade Fraca (1) Entidade-Tipo (9) Entidade-Tipo Agregada (1) Entidade-Tipo Associativa (1) Especializao (2) Esquema (3) Estado (5)

7/30/2019 Operation Graph Database

68/77

Estrutura (4) Exemplo (4) Exerccio (1) Existncia (2) Explicao (2) Expressividade (3) Extenso (2) Facebook (1) Falcia (1) Fato (4) Fato Assertivo (1) Fato Associativo (1) Fato Propositivo (1) Fenmeno (6) Ferramenta (5) Flexibilidade (3) FN (5) Forma Normal (5) Forma Normal Zero (1) Framework (1) Framework de Ngocios (1) Framework Empresarial (1) Fundamentos (3) Fundamentos de BD (9) Fundamentos de PBD (8) Futuro (1) Gartner (1) GC (2) GED (1) Generalizao (3) Gesto (2) Gesto da Inovao (2) Gesto de Processos de Negcio (1) Gesto de Redes (3) Gesto do Conhecimento (19) Gesto Eletrnica de Documentos (1) Gesto Estratgica (1)

Globalizao (2) Glossrio (3) Google (5) Google Docs (1) Google Wave (1) Gramtica (1) Groupware (1) Heuser (2) Hipertexto (1) Homem (1) IA (1) IBM (2) Identificao (5)