I am trying to understand this diagram and after reading over PowerPoints and the Book I still don't see an answer to my question.
What is the difference between the single line and the double line connecting the relationship to the entities? Thank you.
It signifies total participation of Movie in Acts_In. Also known as existence dependency.
Related
here is my scenario. I have a pre-defined data type structure for books. Just take it as an example for the sake of simplicity. The structure looks like the image below. It's a Labeled Property Graph and the information is self-explained. This data type structure is fixed, I cannot change it. I just use it.
When there is 1 book, let's call it Harry Potter, in the system, it might look like below:
So, the book has its own property (ID, Name,...) and also contains a field type MandatoryData. By looking at this graph, we can know all information about the book.
The problem happens when I have 2 books in the system, which looks like this:
In this case, there is another book called Graph DB, with those information as highlighted.
The problem of this design is: we don't know which information belong to which book. For example, we cannot distinguish the publishedYear anymore.
My question is: how to solve or avoid this problem? Should I create 1 MandatoryData for each book? Could you propose me any design?
I'm using Neo4j and Cypher. Thank you for your help!
UPDATE
From the comments (by #AnhTriet):
Thanks for your suggestion. But I want to have some sort of connection
between those books. If we create new MandatoryData, those books will
be completely separated. (...) I meant, 2 books should point to some
same nodes if they have the same author or published year, right?
After some clarification in the comments, I suggest the creation of a MandatoryData node for each property in the database. Then you will connect a given book to various MandatoryData nodes, depending on the number of properties of the book.
This way two books with the same author will be connected to the same MandatoryData node.
Since you cannot change the data model, I strongly recommend you to create a new MandatoryData node for each new book added to the system.
This way you will be able to get informations about the an specific book with queries like:
// Get the author's name of the book with ID = 1
MATCH (:Book {ID : 1})-->(:MandatoryData)-->(:Author)-->(:Name)-->(v:Value)
RETURN v.value
The model proposed in your question is not viable since has no way to identify the owner of an specific property, as indicated by you.
I came to know that there is Crow's foot ER diagram notation, and got a good quick reference. Have a look at the below diagram:
I did get some clarity on these symbols, however I have difficulty in understanding:
1) Why we have the "connector symbols" on both side of the line?
2) How to interpret them?
Can anyone please help me understand this?
Your reference is somewhat incorrect. The Entity-Relationship model doesn't use Crow's foot. Chen's notation and extensions to that notation can be called ER diagrams.
Your diagram is a generalization of table diagrams, modified to allow many-to-many associations and hide attributes. However, it doesn't represent relationships using their own shapes, and I see no indication of support for ternary or higher relationships. There's also no indication of other ER concepts like weak entities, associative entities, identifying relationships or keys.
Data models that only support binary relationships are usually based on the network data model, not on the Entity-Relationship model. Relationships in the ER model, when physically implemented, are represented by two or more entity columns in the same table, not by any kind of link between tables. In actual table diagrams, many-to-many relationships are represented by their own table, with two one-to-many association lines. In those cases, the cardinality indicators represent the number and optionality of records with matching values for matching PK/FK columns.
The interpretation of the Crow's foot symbols are indicated in the orange column. For more information about modeling with Crow's foot, see Entity Modelling. However, don't confuse this with the Entity-Relationship model as described by Chen, or either of them with the Relational model.
I am an ICS student and I have been given two questions.
1.) List all the Functional Dependencies that hold for the database.
2.) For each relation in your relational schema write down whether the relation is in BCNF or 3NF and if not give a violating FD.
I'm just having problems understanding the relationship between functional dependencies and the ER Diagram. I've watched a few videos online but I'm still getting stuck on how to answer the two above questions and would appreciate some help in finding the right direction.
Below is an ER diagram and I was hoping someone could give some examples on how to start from here.
For each entity set (e.g. Department), each attribute is an FD (e.g. Department Name -> Location).
For each relationship set (e.g. Offers), there's an FD from the combination of keys of "many" entities to each of the keys of "one" entities (e.g. Course_ID -> Department Name)
Using Chen's notation on an entity relationship model, for database design. Is this the correct way to illustrate the following relation. 'Many employees report to one employee':
I think the below image would be more approapraiate
E-R Diagrams
DATA MODEL
STACK SIMILAR QUESTION
You dont need the diamond. You can have the direct relationship. Unless the relationship itself has attributes, the diamond is not used.
I'm struggling with a new application where I have a User model wich has several associations with itself.
For example a user can have students / parents / administrators, but all of those associations are users as well.
My idea was to create a connection model where I specify the associations id's and the association type. Unfortunately I dont know how to implement this.
Any help would be much appreciated.
Thank you!
When a model references itself, it is a self-join. See here. and also google for "self join".
Re: "connection model" needed?
Answer: Rather than "connection model," better terms are "many to many table" or "junction table"
A many to many table is only needed if your data has a many to many relationship. Otherwise, you just need a one to one or many to one relationship.
"A user can have students" The key question is, can one student also have many "users"? If so, then you need a many to many table, otherwise not.
For parents, you could say that a user has exactly zero or one father. If so then a many to many table is not needed.
Edited: Oops, I realize that I no longer know this "cold". I'd have to experiment with sample code to get it right. And unfortunately I don't have the time right now. My apologies.
See Self-Joins doc