ER arrows with cross specification in ER diagram - database

A normal entity diagram usually use circles or a straight line to denote a zero or one to many relationship, respectively as in the following image:
However, recently I've seen something new, as in the following image, and was wondering what the cross means:

Related

How to correctly show M:N relationship in conceptual data model?

I usually find everything I need, but there is first time for everything.. :D
I am trying to create a conceptual data model and I dont know how to properly show M:N relationship, which by default should not be included, but still you can assign verbs and directions of abstract entities. So let's say we have "Projects" and we have "Project roles", how do I properly show relationships? Can I have 2 arrows as showed in the picture or do I have to add join table and ?? I can't wrap my head around this..
Thank you so much in advance :)
enter image description here
A conceptual data (or information) model can be created with a suitable modeling language, such as ER diagrams or UML class diagrams. Both languages have a concept and a visual notation for many-to-many associations (or relationship types). Simply follow their definitions. Since there is no standard for ER diagrams, it's easier/preferable to go with UML.
For showing a many-to-many association between two classes (representing entity types), you draw a connection line and annotate it with an asterisk ("*") at both ends.
Notice that a join table is a database implementation, and not a modeling concept.

How can I make the ER diagram of this library?

I've been asked by my teacher to make the ER diagram of a certain library. Here is a very simple and not complete ER diagram only to illustrate my point:
Searching the library's website I found exactly the attributes I need for the customer, for the copies the book etc. However, the book is not the only thing provided by the library. The library provides music-CDs , journals, DVDs and many more leading to 20 different kinds of items in total.
One very ugly solution would be to create a different entity for all these items and connect each one of them with the copy entity. And this seems unavoidable since each item type has different attributes. A book for example has ISBN and a journal the ISSN. Looking at all the attributes of each item the only thing they all have in common is a title.
Is there a better way to do the ER diagram?
unfortunately no, he is asking for an academic solution and the way to represent the mini-world in er is 1 entity type per object. this is my vision to ER diagrams in its simplest academic form.
if you continue to sum entity types together, your entire mini world will be one entity type.

Convert ternary relationship to binary in E/R model

When I am studying the database lecture on E/R model, it illustrates how to convert ternary relationship to binary. One way is using weak entity relationship as follows (each relationship is M:N cardinality):
ternary relationship:
convert the upper relationship with weak relationship
However, in another example:
it states in the lecture slide: "if each technician can be working on several projects and uses the same notebooks on each project, then we can decompose 3-ary relationship into binary relationships"as follows:
which I could not understand. I still kinda confused about when we should use weak entity approach and when we could just simply convert it to binary relationships as the latter one. Thanks!
Your second image illustrates a confusion between conceptual and physical data models, or a confusion between the ER and network data models. The physical implementation of the models in the first two images are the same, what differs is the interpretation of entities and relationships. The entity-relationship model supports ternary relationships, but doesn't support multiple identifying relationships for a single weak entity set. I would advise you to disregard the second image completely.
The third and fourth images illustrate a fourth normal form decomposition using ER notation. This isn't something you can do with any ternary relationship, but rather something you do when 2 or 3 independent relations have been incorrectly combined into one. For more information, I suggest you read up on Fourth Normal Form.

Is there any difference between these two ER designs?

I'm new to database designing.
I'm trying to figure out the difference between the following two ER designs:
Assuming each record in parent tables (State and City) participates in 1:M relationship in both the ER designs, is there any functionality difference that could arise among them? Is there any situation where I might prefer one over another?
In the first case the City determines the State (City_Id->State_Id); in the second it doesn't. That's a significant difference and what matters is which of these designs more accurately describes the reality you are intending to model.
If City_Id->State_Id is correct and if these are supposed to be relational database designs then the Locality relation described by the second diagram would violate 3rd Normal Form (first diagram looks OK).

Draw Many to Many Relationship in ERD

Many to many relationships should have a solid line, strong relationship.
In the given diagram, ther right side sample is surely incorrect, the relationship
line show be solid. However, what is the appropaite relationship for the left side diagram, should it be dashed (weak relationship) or solid?
Many to many relationships should have a solid line, strong relationship.
What notation are you using? Looks like a variant of IE (Information Engineering).
At any rate, I guess this depends on the notation/conventions being used and in this particular case the logical model seems consistent with the physical one, except for the requirement that a Project must be connected to at least one Employee, which cannot be easily1 mapped to the physical database.
In the given diagram, ther right side sample is surely incorrect, the relationship line show be solid.
Not necessarily. There is nothing preventing you from migrating the parent PKs into an alternate key in the junction table and using a surrogate PK. This would make the relationships "non-identifying", warranting the usage of dashed lines.
1 It would require circular deferred FKs.
https://help.drawerd.com/relationship/many-many
With DrawERD: simple web ui can do it.

Resources