I've been trying to create a database following an ER diagram. In my case I have a table 'admin' where it has a relationship with 4 different tables. I've named the relationships for each one of them 'manages'. So the relationship between them would be
'admin' -> manages -> table A
'admin' -> manages -> table B, etc
Is it correct?
I've read different opinions on the internet... Some say yes, some say no. I've asked a teacher of mine and he said each relationship in an ER diagram has to be unique so now I'm confused. Any help please?
Thanks
When modeling, it doesn't have to be unique but, when implementing at the physical level (the database), it must be unique.
At the physical level, these relationships translates into foreign key so, your Admin manages TableA will be named something like FK_Admin_Manages_TableA, your Admin manages TableB will be named FK_Admin_Manages_TableB and so on.
Think of relations in an ER schema as 3 choices:
1:1 -- possible, but usually bad schema design
1:many -- implemented with key of the "1" table in the "many" table
many:many -- requires an extra 'mapping' table between the two other tables
("0:..." is a degenerate cases of the above)
If only one person can admin something, then it is 1:many; if many can manage many, then many:many.
Related
I am trying as an exercise for an exam to transfer a database from the ER model to a relational database.
However, I am very unsure whether my solution makes sense. In particular, the two relationships between location and has makes great problems. I thought I could add one ZipCode as a regular primary key into the table has and a second ZipCode as foreign key. I would be very grateful if someone could help me with this.
My Solution so far:
If you are following Chen ER design with this Chen ER diagram then you need a table for every entity type box and every relationship (association) type diamond and a FK (foreign key) for every participation/role line for a relationship type.
(It is a bad idea to call lines/FKs "relationships" or "associations" in a Chen context because diamonds/tables represent relationship types and lines/FKs represent participations.)
So your Ship tourID would be dropped in favour of relationship/table takes with lines/FKs to Ship & Tour. And you would have two FKs in the has table to Location. It doesn't matter that you need different column names in the relationship table than in the participant table. A FK just says the values in some table & column list appear in some other table & column list. The diagram says the names are start & target; use them.
Don't use a flaccid uninformative name like has. If you picked a better name and/or explained when a triplet of entities satisfied the has relationship then we could know what reasonable designs would be. Eg you may not be using cardinalities correctly. The Chen way is, a number or range tells for some instance of the entity type how many relationship instances it can participate in. Another way is, a number or range tells you for a some combination of entity instances of the other participating entity types how many instances of the line's entity type can participate with it. If the latter has a zero that means a relationship instance can have a NULL. But that can't arise in a Chen design; participating entity instance combinations identify relationship instances and form PKs (primary keys).
However, a Chen design can't express all relational designs. And we can represent the same data as a Chen ER schema by rearranging tables. Eg dropping binary relationship tables that are not many:many and putting FKs (sometimes nullable) into entity tables instead, just as you did with takes, Ship & Tour. Some methods have non-Chen diagrams expressing such designs directly. Others allow it in the move from Chen diagram to schema. You have to ask your teachers whether they care just what variations from the Chen style of ER diagrams and corresponding schemas you are permitted to make.
(It is this dropping in non-Chen methods of explicit 1:many relationships/associations and their representation by FKs that leads to FKs being incorrectly (but commonly) called "relationships" or "associations".)
so I was trying to create an EER diagram from a database model and I wanted to do something similar to this.
Say I have a table named Bag and another one named Address. I already set the PK in Address to be the FK in Bag, when creating the diagram I found that I cannot find the option "many to many" in mySQL workbench.
I wonder what is causing this to happen(maybe I'm doing something wrong but right now I cannot think of any reasonable explanation...)
Hopefully someone can shed some light on this.
Thanks!
Usually many to many relationship would have an additional table to create the relationship -
Address ( table holds addresses )
AddressBag ( tableholds the many to many the bags to addresses relationship with FK to address and FK to bags)
Bag ( table holds the bags )
Many2Many relationship need an additional table to define the relationship between two tables. This table holds the FK to each of the two or more tables. If we want to get the data, just need to select columns by this relationship. Wish this would help you.
I'm finding the best way to convert an eer diagram to the corresponding relational diagram. I have a generalization entity with some specializations which have separate relationships with other entities. The generalization entity has in turn a n-to-m relationsip with an entity. The following drawing clarifies the situation:
Eer diagram with specialization and n-to-m relationship.
As the two specialized entities have separate relationships, I should convert them to two separate tables. Meanwhile, I should create a table modeling the n-to-m relationship which relates the entity 'User' to the entity 'Newsletter' (or better, its specializations). How to cope with this problem? I've not found any useful information.
The only possible solution I thought to was to create two separate tables modeling the n-to-m relationship, one linked to 'User' and 'Programming newsletter' tables, one linked to 'User' and 'Travel newsletter' tables. But I'm looking for opinions for that.
I see no problem. I would implement your diagram using the following tables:
User (nickname PK, name, address)
Newsletter (name PK, supervisor, type)
Subscription (user_nickname PK/FK, newsletter_name PK/FK)
Programming_Newsletter (newsletter_name PK/FK, type FK, language)
Travel_Newsletter (newsletter_name PK/FK, type FK, means_of_transport)
I probably wouldn't use user nicknames / newsletter names as keys since I prefer stable compact identifiers, but that's another topic.
I think there are a couple of ways to go about this.
The simplest one, would be to break the assumption "As the two specialized entities have separate relationships, I should convert them to two separate tables". If you keep your specialisations together in a single table, you can use STI (Single table inheritance) for your generalisation. This approach has a drawback though, which is that your table will have many NULL values for those relationships that do not belong to the concrete specialisation.
The other approach, would be to use CTI (Class Table Inheritance). This approach assumes that there will be a specific table for each specialisation of your generalisation. This would get around the NULL problems, but it can potentially introduce a performance problem due to the fact that your code will need to eagerly join from the generalisation table to the specialisation on almost every single query you make to retrieve them.
I don't quite see the issue in the n-to-m relationship between User and Newsletter. You should be able to have a regular intermediate table that creates the association between the two, since there are no further attributes that complement that relationship.
I'm managing to create my first complicated J2E Solution and in every tutorial I find some sort of intermediary tables usage, like here :
Tables : User, User_Roles, Roles
While logic would simply add a key to user Table referring to it's role on Roles table, why the usage of that intermediary table ?
I thought it's one or two developpers choice, but everywhere I look for a tutorial, I find this sort of sql schema.
Is it better ? Does it help in something particular ? Speed, security ? Cause from a logic point of view, using one table User and a foreign key to Roles is better.
Thank you
This is a common database relationship modeling called M-N (Many To Many). A User can have many Roles, and a Role can be assigned to many Users, so you need the intermediary table. Here's another example: a Teacher can teach many Classes, and each Class can be taught by many teachers (during different semesters, for example). In this case you need a Teacher-Class intermediary table.
A different kind of relationship is 1-N (one to N). A User can have many Telephones, but each Telephone is owned by a single User. In this case, a User's primary key (PK) is exported as a foreign key (FK) into the Telephones table. No need for an intermediary table.
Try to get some professional idea here about which choice is better when creating schema relationships
I roughly find an idea from this post but still try to get more thinkings.
A simple scenario could be like this:
class <--> Student <--> Teacher <--> class
(Assume a teacher can teach multiple classes)
it is a normal scenario with many-to-many relationship in a round. And query can start from any peer to any direction. So what could be a better design?
I know in one to one relationship a mapping table is definitely a waste, but is the mapping table solution ONLY good for many-to-many relationship, like that post mentioned? If we want to extend the many to many relationship with directions. If the relationship is one-direction instead of bidirectional, could the answer be different?
Thanks in advance.
Some simple rules:
For a one-to-one relationship, a foreign key can be held in either of the tables involved in the relationship, referencing the other table.
For a one-to-many relationship, the table on the many side of the relationship should hold the foreign key.
For a many-to-many relationship, you can create an association table (mapping table in your terms), which is a third table that holds foreign keys to both of the tables involved in the many-to-many relationship.
For example, assume we have the tables STUDENT, CLASS, and TEACHER. Generally, there is a many-to-many relationship between STUDENT and CLASS, and a one-to-many from TEACHER to CLASS (assuming a class only has one teacher). So, these tables might look like:
STUDENT: STUDENT_ID, STUDENT_NAME, etc.
CLASS: CLASS_ID, TEACHER_ID (foreign key), CLASS_NAME, etc.
TEACHER: TEACHER_ID, NAME, etc.
STUDENT_CLASS (mapping table): STUDENT_ID (foreign key), CLASS_ID (foreign key), GRADE, etc.
If you have a many-to-many relationship then, yes, you would need a mapping table. There is really no other reasonable way to store information about many-to-many relationships in a relational database (there are, of course, many unreasonable ways to do so).
If you want the relationship to be unidirectional (which seems very odd-- I can't envision a situation where entity A would have a relationship with entity B where B would not have a relationship with A so I would tend to suspect that the data model was incorrect if you wanted to implement something like that), you would still use a mapping table. You would probably add another column to the mapping table that stores the DIRECTION (i.e. either 'A -> B' or 'B -> A').