I need to help to define a relationship in conceptual model for database. I'm doing it in PowerDesiner. I have 3 entities (let's call them A, B and C).
A doesn't have to have B, if A has B then only once.
B has to have at least one A.
B may have C, but doesn't have to.
C have precisely two B.
C has at least one A.
C can have A only if A is part of B, which is in relationship with C (one of the two B to C).
A may have C, but doesn't have to.
It's too complicated for me, I had an idea, but it turned out to be completely wrong. It's only a part of project, but the rest don't affect those 3. I need to do those limits on conceptual level, which is exactly my problem.
My first and propably the best idea was this http://i.snag.gy/Ofdze.jpg but it doesn't include the condition that C can have A only if A is part of B, which is in relationship with C (one of the two B to C)
Then I came up with this http://i.snag.gy/gKNQ9.jpg but as the solution before I think that it doesn't contains the same condition, even worse seems to be really messed up solution.
Ok,
for clarity I will refer to your relation conditions to the # of line you have described it, so Row_1-2 will refer to statements in 1st and 2nd row of your question.
Please, pay attention, there is a logical error in your 5th and 6th statements.
You say C has at least one A and C can have A only if.., the two are not possible toghether.
I will skip the 5th and keep the 6th in my answer.
Let's see, first of all add the relation between A and B
Then select the relation and right click it and select Change to Entity,
you will get:
Pay attention this new entity identifies the relation between A and B, you will need it to fulfill your 6th statement.
Now add relations between C and B and between C and A (through Rel_A-B)
Note, I have adjusted cardinalities in relation between B and C (2,2)
Related
My CouchDB database has 3 types of data: A, B, C.
A has a 'b' attribute being an ID to a B, and a name
B has a 'c' attribute being an ID to a C, and a name
C has a name
for instance:
{ _id:"a1", type:"A", name:"aaaaa", b:"b1" }
{ _id:"b1", type:"B", name:"bbbbb", c:"c1" }
{ _id:"c1", type:"C", name:"ccccc" }
I would like to get in one view query all the As, and retreiving the names of its B, and of its B's C (and for instance, I would like to restrict the result to get only the As of which C's name is "cc").
How can I acheive this?
(to get only A and B, the answer is:
map: function (doc) {
if (doc.type == "A") {
emit([doc._id,0])
emit([doc._id,1], { _id: A.b })
}
}
but I have no clue to extend to 2nd relationship)
I am also interested with the answer in the case we have a 'D' class, and 'E' class etc with more nested relationships.
Many thanks!
In a generic way, in CouchDB it's only possible to traverse a graph one level deep. If you need more levels, using a specialized graph database might be the better approach.
There are several ways to achieve what you want in CouchDB, but you must model your documents according to the use case.
If your "C" type is mostly static, you can embed the name in the document itself. Whenever you modify a C document, just batch-update all documents referring to this C.
In many cases it's not even necessary to have a C type document or a reference from B to C. If C is a tags document, for example, you could just store an array of strings in the B document.
If you need C from A, you can also store a reference to C in A, best accompanied with the name of C cached in A, so you can use the cached value if C has been deleted.
If there are only a few instances of one of the document types, you can also embed them directly. Depending on the use case, you can embed B in A, you can embed all As in an array inside of B, or you can even put everything into one document.
With CouchDB, it makes most sense to think of the frequency and distribution of document updates, instead of normalizing data.
This way of thinking is quite different from what you do with SQL databases, but in the typical read-mostly scenarios we have on the web, it's a better trade-off than expensive read queries to model documents like independent entities.
When I model a CouchDB document, I always think of it as a passport or a business letter. It's a single entity that holds valid, correct and complete information, but it's not strictly guaranteed that I am still as tall as in the passport, that I look exactly as in the picture, that I haven't changed my name, or that I have a different address than the one stated on the business letter.
If you provide more information on what you actually want to do with some examples, I will happily elaborate further!
I have two nodes, A and B,
A talks to B and B talks to A, (A)-[:talksTo]-(B)
A has a sentiment value towards B, and B has a sentiment value towards A.
So there is the problem, I need A to B relationship to store a value that the B to A relationship will also want to store (same key).
So I will try to do queries such as, MATCH (A:person)-[:talksTo]-(B:person) where A.sentiment < -2 return A;
So here A's sentiment toward B will be different the B's sentiment toward A, thus the needed separation.
I have tried to make unique key names to specify direction - but that makes queries difficult unless I can query with a wild card ex: ... where A.Asentiment < -2 would be queried as ... where A.*sentiment < -2
Another way I can think of to do this is make two different graphs, 1) A talks to B graph and B talks to A graph... but this would make queries tricky as I may get back more then one node for single node queries OR if I have to update a single node key:value to something else. I would prefer to have one node name per person.
Any ideas?
I don't know that this is a solution, but I don't think I understand enough so it might be a foil for better understanding:
MATCH (A:Person)-[dir1:talksTo]->(B:Person), (A)<-[dir2:talksTo]-(B)
WHERE dir1.sentiment < 2
RETURN A, B
I apologise for the title, I realise it isn't especially descriptive. I'll try to describe my problem in greater detail.
I have a set of "nodes", for sake of example we'll title them A, B, C, D, and E. These nodes are unique from one another in the sense that they have are "related" to each other, though only to specific nodes. In my real implantation, there could be thousands of nodes and I would like to develop an algorithm which could place them appropriately, regardless of their quantity.
We'll pretend the associations are as follows:
A: B, D
B: A, C, D
C: E
D: A, B
E: C
This format means that A is related to B and D, etc.
My goal is to display these relationships on a 2D plane by drawing each node as a circle, and drawing a line between them. I would like to display them in a "web" type fashion, meaning that the nodes do not overlap whatsoever, and the distance between related nodes is minimized. I would like for the diagram to suggest that by starting at A, for instance, one could travel next to B, then to C, and finally to E.
In a case such as B's, where it itself is related to C while C is not related to B, there does not have to be a distinction to suggest that. That is to say, showing that A:B and B:A can be the same as saying that B:C, despite C is not related to B.
I hope I have made myself clear in what I would like to accomplish. I don't think I'll have very much trouble coding the actual algorithm, I just for the life of me can't think of a way logical way to approach the problem.
Any suggestions at all are greatly appreciated, I don't need pseudocode or step by step instructions, just some advice from some more seasoned programmers who may be able to look at the problem from a different perspective.
Thanks!
Try searching for "force directed graph drawing".
The basic idea is as follows:
Initialize node positions randomly (putting them with equal distances on a circle turned out to be good)
Apply Forces between the nodes:
Nodes push off each other
if they are related, they are additionally pulled towards each other
Repeat step 2 until you have a nice layout.
There is a live example at http://getspringy.com/
lets say i have an entity A and a entity B. The relationship is 1:1. If i delete A then B should also be deleted. I have set this up with a cascade delete rule. Now lets assume i add another entity C which has a relationship 1:1 to B.
I'm not sure how to handle this appropriately. If A and C have the same B should it be the same instance of B? Or should i duplicate the entry ? If it is the same then deleting A can not delete B anymore if C has a reference to it.
Furthermore how can i enforce this 1:1 relationship between A and B ? At the moment when i create the A entity i also create a B entity not checking if it is already in the data base. This does not fail, and causes duplicates of B.
Edit: For a better understanding what i'm trying to achieve:
A must always have a B.
C must also always have a B.
For example lets assume i have an entity Shop (B) and an entity Favorite(A). In the Future i might add another entity which will also use Shop. So if the user creates a Favorite he will give it a name and a Shop. Now if i don't check if this Shop is already in the DB i would create another one. On the other hand if i allow duplicates i can use cascade delete rule and must not be scared that if i delete a Favorite it would leave another Favorite with an empty Shop.
I feel a little lost and i'm not sure whats the best practise in such scenarios. Any help is appreceated.
It depends on what you are trying to do. If a B cannot exist without an A, then the cascade would still apply. However, if C can cause B to still exist, then you should remove the cascade delete.
But this also begs the question as to if any one of them doesn't exist, will the others then not exist. Which may mean that you need to delete both B and C if A gets deleted.
Lets apply this to an example.
A = Body
B = Head
C = Brain
Lets say these are all the things a human needs to be alive. Without a body, the head and brain won't work. This is similarly true for the rest of the parts. So if any of these parts die, the others die.
Ok, now if A and C have the same B, then that should be a unique B, not a duplicate.
Any implementation of CoreData should check for the existence of a entity before creating a new one unless you can guarantee it will only belong to one specific entity. Your A and B must always be unique if you are going to not check for duplicates. There are very few always unique real world values. A specific time would an example of an always unique instance. This second only ever exists right now, and will never exist again, nor has it existed before.
If a new A creates a B, then that is fine. However, if both A and C can have the same B, then you must check for an existing B, otherwise A and C will never be able to share a B. If your A's only have 1 B forever, and nothing else uses B, then you can do this as long as you always create unique A's.
I have a question that concerns multi value dependency. The relation looks like this:
R(A,B) with A -->> B (A multi value determines B)
I've been told that this relation is in 4th normal form, but I don't really se how. I know that if the multi value dependency is trivial, then it doesn't violate the 4th normal form. But is this trivial? It would be trivial if it, for example, looked like this:
{A,B} -->> B
But the first dependency example shouldn't be trivial.
The other rule for 4th NF says that A in this case needs to be a super key of the relation, but it isn't. As far as I can tell, A isn't a super key, since {A,B} is needed to identify a tuple.
So the question is, why is this in 4th normal form? It seems to be violating both of the rules.
I found an answer to this! Seems that the trivial rule has two parts.
A -->> B is trivial if B is a subset of A, OR if A union B is the entire relation.
So that's why the relation is in 4th normal form. A and B is the entire relation in this case!