How to recognize if a relationship is ternary or an aggregation?
For example: A player gets an award in a match he plays. If the entities are player, match and award, is this a ternary or an aggregation?
The answer was given to me by a lecturer, it's a ternary relationship because there are 3 contributing entities involved.
Aggregation is, on the other hand, where you aggregate two entities into a single entity and create another relationship to support m:m scenarios.
Related
I'm currently ramping up on graph databases and to do that am working through a set of questions to learn Cypher. However, I'm not 100% happy with the design I've chosen since I have to match relationships to nodes to make some of the queries work.
I found Neo4j: Suggestions for ways to model a graph with shared nodes but has a unique path based on some property with some suggestions that are relevant, but they involve copying nodes (repeating them) when in fact they do represent the same thing. That seems like an update issue waiting to happen.
My design currently has
(:Dept {name,floor})-[:SOLD {quantity}]->(:Item {name,type})<-[:SUPPLIES {dept,volume)]-(:Company {name,address})
As you can see, to figure out which department a company supplied an item to, I have to check the :SUPPLIES dept property. This leads to somewhat awkward queries - it feels that way to me, anyway.
I've tried other relationships, like having (:Company)-[:SUPPLIES {item,vol}]->(:Dept) but then the problem just shifts to matching :SUPPLIES relationship properties to :Item nodes.
The types of queries I am building are of the nature: Find departments that sell all of the items they are supplied.
Is there some other way to model this that I am overlooking? Or is this sort of relationship, where a supplier is related to two things, an item and a department, just something that doesn't fit the graph model very well?
You want to store and query a triangular relationship between :Dept, :Item, and :Company. This can't be accomplished by a linear relationship pattern. Comparing IDs of entities is not the Neo4j way, you would neglect the strengths of a graph database.
(Assuming that I understood your use case scenario) I would introduce an additional node of type :SupplyEvent that has relationships to :Dept, :Item, and :Company. You could also split up :SOLD relationship in a similar way, if you want relations between department, item, and, e.g., a customer.
Now, you can query all companies that supplied which items to which departments (without comparing any IDs):
MATCH (company:Company)<-[:SUPPLIED_FROM]-(se:SupplyEvent)-[:SUPPLIED_TO]->(dept:Dept),
(se)-[:SUPPLIED]->(item:Item)
RETURN company, item, dept
I was interested in storing the history of properties which contains two entites - properties and owners. Right now I am not sure what approach to take and needed some help.
I was thinking of creating an associative entity and so this would have its identity a combination of property and owner but the textbook comes up with this solution instead:
Solution
What's the difference between the solution above and an associative entity?
The owns table in the given solution would be called an associative entity set in the network data model. This data model supports only one-to-one and one-to-many binary relationships, and resolves many-to-many binary relationships as well as ternary and higher relationships into an associative entity set with binary one-to-many relationships.
However, in the entity-relationship model, the owns table represents a many-to-many relationship relation. The ER model directly supports many-to-many binary relationships as well as ternary and higher relationships, and uses "associative entities" to refer only to relationships which are the subjects of other relationships.
I'm designing an ER diagram for a social network and recently I got involved in an argument with my colleagues whether this part is right or wrong
ER DIAGRAM PROBLEM
Where Faqet(Pages) is connected with Shfrytezuesi(User) using three actions, pelqen is for storing likes, krijon faqe to know who created the page, and udheheq to store all page admins, so my question is
is this design wrong?
Can two tables be linked with more than one action, this is where I'm not certain
It's perfectly valid to have any number of relationships between any number of entity sets. My only concern with the diagram is that multiple role lines below Shfrytezuesi are merged into one - I recommend keeping them distinct.
Note that in the entity-relationship model, we don't link tables. That idea comes from the old network data model, in which rows represented entities, tables represented entity sets, and links between rows/tables represented relationships.
One disadvantage with that model is that it supports only directed binary relationships - many-to-many binary, ternary and higher relationships and relationships with attributes all required associative entities to be introduced. However, three binary relationships aren't equivalent to a ternary relationship, and not all relationships can be represented in binary data models.
The ER model supports n-ary relationships and attributes on relationships. Entity sets are represented by their primary keys and relationships by combinations of entity keys. Entity sets plus attributes form entity relations, relationship sets plus attributes form entity relations. These relations get mapped to tables. In practice, tables with the same primary keys get combined to reduce the number of tables, which means one-to-one and one-to-many relationships get combined into the relations for one of their associated entity sets.
Regardless of how tables are combined, attributes and relationships are represented by sets of columns. For example, based on your diagram, Pelqen would be represented as (FID PK, SID) (assuming SID is the primary key of Shfrytezuesi). These columns might have different names, e.g. SID might be renamed to AdminSID, especially if the relationship was combined into Faqet. The old network data model would view FID FK -> FID PK as a relationship, which as described above and below is a very limited kind of relationship and not the approach taken by the ER model.
Another disadvantage of the network data model is predetermined access paths, which means we have to navigate from table to table using the predefined relationships. This complicated queries and data processing significantly. This limitation was one of the main drivers for the development of the relational model, to which the ER model maps. The understanding of tables as relations in the RM enables us to construct and navigate arbitrary access paths using joins. So, we do link tables in the RM, but at query time and as needed rather than at design time. The ER model is used for conceptual design only and doesn't describe relationships between tables, only relationships between entity sets.
Now, the ER model isn't a complete and consistent logical model like the RM, but it is a significant improvement over the network data model. An even more rigorous approach than ER would be object-role modeling, but that's a different topic.
how are the two different? Since both of the relationships consist of one set of objects say A which cannot exist independently and another set of objects say B whose existence is necessary for the existence of objects in the set A.
So are the two same or are their some fundamental differences that I am missing out on?
"Composition relationship" isn't a formal relationship type in ER. If I take it to mean a binary relationship (a,b) which is left-total (every a is related to some b) and in which a->b (an a is related to only one b), then an identifying relationship would be a specific kind of composition relationship. An identifying relationship has the form ((x,b),b) in which (x,b)->b. Non-identifying composition relationships would then include cases in which the component set is identified by its own attributes.
I am trying to understand the concept of ER modelling, but I do not yet succeed. I have designed the ER model about movie database, but I do not know wheather it is a good design and how to connect the entities:
between Actor and Film i want to say "actor can play in each film only once" and at the same time "many actors can play in many movies" -- is it 1 to 1 relation or many to many?
and HOW do we need to think about entities ans relations between them? relations to one user, one film, one actor, one director, or in general?
UPDATE: new question : should the relation between Director and Film be 1 to many or many to many? I want to say : "one director can have many films && many directors can have may films" ??
Think about it like this: There are many movies. There are many actors. It makes sense that you would only want to include each actor in a particular movie once, but otherwise you want to be able to "mix and match" the movies and actors to express the relationship.
Looking at your diagram, you don't seem to have any fields which express the relationship between Film and Actor - those lines need to match actual fields. Read up on foreign keys: http://en.wikipedia.org/wiki/Foreign_key
The relationship between Actor and Movie that you want is actually many-to-many. You can express this with a "join table" (you'd need to add this to your diagram).
Something like this would work:
FilmActor
-------
uidFilm
uidActor
And put a unique constraint on those two fields together so it can't be duplicated (i.e. the same Actor can't appear in a Film twice)