Is it possible to have two entities linking to a weak entity?? If yes, how's the example like.
Yes, there are occasions where it's possible.
e.g.
You have an "Employee" entity, which has the weaker entity "Dependent" which has the weaker entity "Hobby". (Mr. Smith has a son, Daniel, who plays football)
Related
I'm thinking through a domain model, if I want to get the most out of Grakn's reasoner is it better to have more relations or more subtypes?
What should I be thinking about when considering various ways of modelling in Grakn?
When thinking about how to model your domain in Grakn, we suggest focusing on how specific concepts behave in order to decide if you should be using a relation or a subtype.
So you subtype if you think the subtype is really a valid subtype, or use a relation if you think that a role is a better description of the behaviour of that type.
For example, consider person and teacher.
You could subtype teacher from person, but then what happens when a person is both a teacher and a student? In this case person should play the roles teacher and student in a relation instead of using inheritance (subtyping).
I was going over some of the docs here.
I was curious why Grakn opts to indicate relations using noun semantics rather than verb semantics? In most of the other graph work and research I’ve covered, it usually makes sense to think that two entities (nouns) are linked by a verb e.g. person worked at company. Indeed, for a few entities that I am dealing with, it is a bit difficult to reason about the relationships as nouns for example if artist remixed track.
I’m inclined to use verbs as relations but I wonder if that is not how I should be thinking about it in a Grakn setup. Are there eventual difficulties I can expect to face if I decide to use verb semantics?
Typically, graph databases use directed edges to represent binary relations. Under those circumstances it makes sense to use a verb to describe a relation, since verbs often indicate a directional action between a subject and an object.
Grakn is a knowledge graph, which works differently. This is because relations in Grakn act as hyperedges. This means that there can be more than two participants (called roleplayers) in a relation. This is great for flexible modelling, but it can break the verb naming convention.
To work from your example, rather than artist remixed track, we could (very conveniently in this case) use the noun remix as the relation. Taking a guess at the domain model, an artist remixes a track, and as a result they have created a new track. That’s a great opportunity for a ternary (3-way) relation in grakn. The model for that would be as follows:
define
remix sub relation,
relates original-track,
relates remixed-track,
relates remixing-artist;
track sub entity,
plays original-track,
plays remixed-track;
artist sub entity,
plays remixing-artist;
Once the schema above has been defined in Grakn, we can add a remix instance connecting two new tracks and a new artist like so:
insert
$o isa track, has name "Brimful of Asha";
$rt isa track, has name "Brimful of Asha (Norman Cook Remix)";
$a isa artist, has name "Norman Cook";
$r(original-track: $o, remixed-track: $rt, remixing-artist: $a) isa remix;
It has then proved useful to use a noun for the relation because it doesn’t connect any of the 3 roleplayers it can have in a binary way. Instead we have named the concept that sits in-between the two tracks and the artist.
In this way we see that the relation nicely describes the (undirected) link between any pair of the roles:
original-track <-remix-> remixed-track
original-track <-remix-> remixing-artist
remixed-track <-remix-> remixing-artist
We can see that using remixed in place of remix wouldn't work so well, it would try to add direction to these links where there is none.
Grakn's data model can be extended on-the-fly. Therefore even if you start with a binary relation, should you later add more roles, making it ternary or N-ary, verb naming will no longer make sense.
It’s not always easy to name relations with nouns.
My suggestions are:
first try using a past or present participle of a verb (used as an adjective) with a noun. For example the role remixing-artist uses this.
resort to verbs when using nouns is really awkward, and/or if you’re dealing with a relation that you expect always to be binary.
If you must use verbs as relation names, then use the gerund form (which for all practical effects, acts like a noun). e.g.
faceting sub relation,
relates facet-assignment,
relates assigned-facet.
listing sub relation,
relates list-assignment,
relates assigned-list.
I'm coding an application to create surveys with Symfony3 and Doctrine. I would like to understand which is the best way to model the relation between the survey, items, and answers. A survey is composed by multiple items that have peculiar typologies of answer. For instance I could have the following typologies:
AnswerChoice
AnswerText
AnswerRange
etc..
Which is the best way to model this scenario with Doctrine?
I thought 2 possible solutions:
I create a single Answer object including every possible feature of the answers. The Item object should have a one-to-one relationship with this objects.
Pros: I have just one answer object
Cons: Confusing and against the single responsibility principle
I create a generic Item object containing a specific Answer object (AnswerChoice, AnswerText...) in a predefined class property. The Survey object should have a one-to-many relationship with Item that in turn will have a one-to-one relationship with a specific Answer object;
Pros: Nice solution but...
Cons: I need a property for each type of answer!
Could you please help me to choice the best solution? I have the feeling that I'm not facing well this problem. Thanks
It's inheritance. Actually Doctrine handles inheritance pretty well.
There are a few ways of implementing inheritance in Doctrine but I think, that in your case Single Table Inheritance is what you're looking for.
That way you will be able to get a repository for parent (abstract) answer,but you'll get instances of actual child types in return.
I'm using doctrine to my API REST that returns entities with large relations and large info. I'm trying to improve my doctrine queries performance and I have a big question. Is better to write relations with dbal queries or with XToX doctrine relations?
Thanks
My advice use OneToMany, ManyToOne, ManyToMany etc. relations. Cause when you use that relations, everything will be faster on ORM level.
I had to manage relationships between documents over a NoSQL engine (Couchbase), and I figured out this way to solve my problem. Here is my solution and the steps that let me realize it:
https://forums.couchbase.com/t/document-relationships-using-arrays-and-views-passing-though-graph-theory/3281
My questions are:
What do you think about this solution?
Have you ever used something like this? How is it working?
Are there any better ideas? Critical points of this solution should be helpful
Thank you.
Interesting post Matteo. After reading it I realized that you can possibly improve on few aspects:
Consider 1-1 node relationships. In your post you focus on N-N node
relationships (sure one can argue that 1-1 is a subset of
N-N)...however I think there is a potential of having a different (optimized) implememgtaion for 1-1 relationships. for 1-1 I use node key
value as a field in my json doc (e.g. user: {name:string, dob:date,
addressID:string})
Node key design to address relationships: You can encode in the key
value relationship information, e.g. key: "user#11", "user#11#address#123", "address#123#user#11", etc.
Data integrity aspects: Take into consideration missing complex
transactions. i.e. you can't mutate several documents in one
transaction. The design should compensate for that.
I have used similar solution in my model design for Couchbase in the past. Its now in production for several years already and its performing just fine (load is about 250 tps)...I was trying to avoid as much as possible creating complex node relations and ended up having very few 1-1 and 1-N types.
I tested out this solutions and works well. I like the flexibility of the 'always possible' N-N relationships, because you can simply add the relationship document when you need it without changing the application logic. There is a drawback: you need to implement your own application logic constraints to avoid relationships abuse.
I noticed that using arrays there isn't a great advantage compared to JSON objects and sometimes it may be useful to have other relationships data, for example the weight (or cost) of the relationship. So I suggest you to use a relationship document that as it's own type:
{
"type": "relationship",
"documents": ["key1", "key2"],
"all-the-data-you-need": { ... }
}
Looking at the performance there isn't so much difference using objects over arrays.
Hope this helps someone! ;)