In orientDB, we have links and edges to connect vertices.
I can't find out what the cons/pros of each of them on the orientdb documentation.
Forum Example - three entities involved: Author, Message, Forum.
An author writes a message in a forum.
- Option one: message is an edge between Author and Forum vertices
- Option two: Message has a link to Author and another link to Forum
In other words, what strategy to choose and why?
Edges are all about connecting vertices.
Links are all about relations between other classes.
Two classes may not be associated at all, like a class Oceans and a class Person. But you can have their vertices associated by an Edge named Sailed that may have a property named withShipName`.
So you made a Person vertex called Jack Sparrow, and a Ocean vertex named Atlantic. Then you create an their edge relationship sailed which you can connect like:
Jack Sparrow sailed.withShipName= Black Pearl the Atlantic.
But if you have another Person vertex, like Red riding hood, you don't want to have a link in their vertex properties relating her with an Ocean class.
However, you may want to have a linklist or linkmap linking the class Ocean with class OpticalActiveWaterConstituents, that have vertices to Chorophyll, Suspended Particles, Coloured Dissolved Organic Matter, etc... that are available in all Oceans with different concentrations.
You can refer to this post for the differences between Edges vs LinkList vs Linkmap.
Hope this help to clarify the subject ;)
If you don't have properties on your arch you can use a link, instead if you have it use edges.
Related
Benjamin, thanks for your reply. I really appreciate your answer because you know how desperate one gets when one has no idea what to try.
I did it using the suggestion to select the nodes and right-click, create collection. I must be forgetting something because it didn't work for me.
COLLECTION DEFINITION
Let's see if I'm understanding, in the Anylogic example, they use it to create pedestrians on the train platform, at the 32 doors.
I want to use that tool to avoid having to make a programming line for each room (cr) to evacuate pedestrians to a safe point.
I include the screenshot of the PedSource. I'm looking at what the light bulb has... so I should start with self or ped. But, the Anylogic model has no self and no ped. Any additional ideas?
New PedSource
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
I have been studying several of Anylogic's examples. In this case, the "Subway Platform".
SUBWAY PLATFORM LOGIC
Anylogic uses a collection of doors to simulate the train doors where pedestrians will appear, using target lines. In the PedSource, they describe it as Target Line: doors1.get(index)
SP PEDSOURCE
I want to achieve the same thing using nodes. My collection is called cr_Ele and I have written in the Ped Source > Node: cr_Ele.get(index).
My COLLECTION OF NODES
MY PEDSOURCE
Running it gives me the following error, "index cannot be resolved to a variable". Does anyone have any idea what might be causing the error?
This is my first question on this platform, I hope I did it right!
great question, well done :)
The problem is that your collection is defined as a group of Object elements, see your "Element class" entry. Compare to what AnyLogic did: Their element class is set to "Other" specifying the actual type:
You can do the same thing. Easiest is to select several of your nodes, right-click, select "Create collection". This will give you this collection:
Alternatively, you can use code-complete and learn the object types from the API.
Now, you can access individual PolygonalNode elements from your collection using `myCollection.get(0)´ (or any other index)
How do we know if an edge is an out() going or in() coming in a graph database like OrientDB? I know that edges serve as links between vertexes (which is the same as a relationship between tables in RDMS), but how do we determine the direction. For example, I have some vertexes for Lecturer and courses, here, I want to have one (1) Lecturer to many Courses i.e. one-to-many relationship. So what is the direction of the edge between a lecturer and Courses, is it in() coming to the lecturer or out() going from a lecturer I mean how do I write the query using "select in() from lecturer" or select out() from lecturer? Thanks.
The direction of an edge is purely related to the domain and does not impact the traversal performance (ie. starting from a vertex, you can traverse incoming edges with the exact same performance as outgoing edges).
The important thing is to define the edge "name" in a meaningful way, so that the edge direction is clear.
I'll try to clarify with an example
Suppose you have two vertex classes: Person and Car.
Suppose you want to create a relationship within the two, to represent ownership (ie. a Person owns a Car).
Consider these two ways to represent the relationship:
Person -Owns-> Car
and
Person <-BelongsTo- Car
As you can see, both are clear and represent the domain very well.
Of course you have infinite alternatives to choose the edge name (btw, verbs are typically a very good choice), so you could choose something like "Ownership". This would be a definitely bad choice as it would not make the direction clear, eg.
is it
Person -Ownership-> Car
or is it
Person <-Ownership- Car
Imagine having to do a query on this schema after a few months you don't use it, with tens of relationships that are not semantically clear. You see the problem...
In the end, it's just a matter of how clear the model is. It's a human problem, not a technical problem.
I hope it helps
Undirected vs Directed edge
Undirected:
A -(Edge) - B
A can traverse to B, and B can traverse to A
Pros: Simple when working with undirected (symmetric) or bidirectional relationships.
Example: "A friend_of B" ⇔ "B friend_of A"
Cons: Does not carry directional info.
Directed Edge
A -(Edge) -> B
A can traverse to B, but B cannot traverse to A
Pros: Saves memory and correctly describes a direction-restricted relationship
Example: "A parent_of B" ⇏ "B parent_of A"
Cons: Can not traverse back from target to source.
Regarding Your Question - If it was me, I would choose undirected for your use case because most likely I would want to go both directions.
Here's an example to set up my question. I have a model which contains 'boxes', and they have a REST endpoint:
/boxes,
/boxes/{boxId}
This model also contains 'nodes':
/nodes,
/nodes/{nodeId}
Nodes can sit on the borders of boxes, and this is a many-to-many type of relationship. Having one node sit on multiple borders is a way to indicate that those borders (partially) overlap, but nodes also have other purposes.
I'm trying to determine how to model this in an non-surprising, RESTful way. I can see a couple of ways to do this. But I'm not sure which I should use:
Model /borders as a fully fledged entity type with its own endpoint. Have boxes reference four borders (top, bottom, left, right). Have borders reference a list of nodes. Have nodes reference a list of borders.
Model /boxNodeRelationships with its own endpoint, and have each such relationship point to a box, a node, and contain a 'border' field (an enum with four options).
Both are similar, and rather 'heavy' for their purpose. The alternative is to be a bit more ad-hoc:
Give boxes a list of { border, node } objects. Give nodes a list of { box, border } objects. These objects would be returned from GET calls and expected from POST/PUT calls, but would not be fully fledged types with an endpoint.
I'd like to know how a RESTifarian would solve this, as well as hear some pros / cons of these approaches. I'd also like to know if there are other approaches that are fundamentally different.
I would create 3 entities:
Box
Border
Node
And the relationships:
A Box can have n Borders
A Border can have n Nodes
So you could address them:
To get the first node: /boxes/1/borders/1/nodes/1
You could have some logic:
if /boxes/1/borders contain /nodes/1 and /boxes/2/borders contain /borders/1 then they intersect
And so on.
I am using TitanGraphDB + Cassandra.I am starting Titan as follows
cd titan-cassandra-0.3.1
bin/titan.sh config/titan-server-rexster.xml config/titan-server-cassandra.properties
I have a Rexster shell that I can use to communicate to Titan+Cassandra above.
cd rexster-console-2.3.0
bin/rexster-console.sh
I am attempting to model a network topology using Titan Graph DB.I want to program the Titan Graph DB from my python program.I am using bulbs package for that.
I create three types of vertices
- switch
- port
- device
I use the following functions to create unique vertices if it doesn't already exist.
self.g.vertices.index.get_unique( "dpid", dpid_str)
self.g.vertices.index.get_unique( "port_id", port_id_str)
self.g.vertices.index.get_unique( "dl_addr", dl_addr_str)
I create edges between related vertices as follows.
self.g.edges.create(switch_vertex,"out",port_vertex)
However if this function is called twice it is creating a duplicate of the edges already present.Is there a function analogous to get_or_create() for edges so that I can avoid duplication.?
In general, graphs permit duplicate edges between vertices because the definition of a duplicate edge is ambiguous and application specific.
For example, is the edge a duplicate based on its label, direction, or some combination of properties?
However, Titan 0.5 introduced a Multiplicity.SIMPLE constraint that enables you to define unique edges between a pair of vertices.
See Matthias's Titan 0.5 announcement:
https://groups.google.com/d/topic/aureliusgraphs/cNb4fKoe95M/discussion
This new feature is not yet documented, but the Titan team is in the process of updating the docs for Titan 0.5 so it will be documented soon.
Watch the Type Definition Overview page for updates:
https://github.com/thinkaurelius/titan/wiki/Type-Definition-Overview
Also see the section on cardinality constraints:
https://github.com/thinkaurelius/titan/wiki/Type-Definition-Overview#cardinality-constraints
i need some help with designing iphone's core data object model context. I've started making a golf scorecard application using XCode 4, and the way I want the application behave is...
-User can add players (with first/last name, initials)
-User can add courses (with name, address details, holes with par/lenght)
-Play a round so that in on top of scorecard tableview (hole view) I want to have fixed section that will not scroll, and that will show current score for each player on a round in addition to the best score ever on that same course.
-On hole view, in section header, I want to show like "Hole 11: Par 3 / 150 m" and on each row I want to show buttons to add strokes, and the best score ever on that particular hole.
-When managing players, adding/deleting, user can also browse the rounds that player has ever played.
What is the best approach to design entities? I already got some consultation and he suggested that I should have it like this:
PLAYER:
- first_name
- last_name
- initials
- ROUND:*
-- date
-- COURSE
-- SCORE
COURSE:
- name
- address
- hole 1 (par/length)
- hole 2...18
SCORE:
- hole 1
- hole 2...18
SCORECARD: (will only be temporary object, to be deleted when round is complete)
- PLAYER*
* = multiple objects
Is this a good design? I somehow feel that I should have a permanent SCORECARD objects that will hold PLAYER objects, one COURSE object and 18 holes attributes that will get values like "3:3:5:4" (score for each player, colon being seperator).
I hope this is not too messy posting, and please, forgive my english.
I would consider extrapolating the hole attributes to be an entity. Attributes would be "par" and "length". Then, have a relationship so that a course entity has many holes. Each hole conversely belongs to a specific course.
The data modeller in XCode is really good for visually creating entities and the relationships between them. I'd recommend experimenting until you feel that you have a good model. Think also about how you will use the model in your code. For example, what sort of look ups will you do?
For more detailed study it's worth getting a good book on object modelling. I used Larman's "Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development".