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.
Related
My database tables:
1.jobs table having fields id,name
2.locations table having fields id,name
Jobs can have more than one location and locations can have more than one jobs.So i added a table job_locations having id,job_id,location_id.
But my doubt is that if i create a table like this, will it effect normalization ?If i need to connect more tables to locations table then DB will have more tables.
(Example : if users table have more than one location and vice versa, i need to create a table as job_users too..)
I have another solution, that is to add location_id in jobs table. So jobs table fields will look like this: id,name,location_id. Then i will store all location ids as array in location_id as string.(But eloquent method will not work here).
which method is better and why?? OR Is there any other solutions?
No it will not affect normalization.
such bridge tables(weak entities) are used to produce 2NF
See for example https://geekyisawesome.blogspot.com/2011/03/database-normalization-1-2-3-nf.html
A Bridge table must be used for such m:n relationship to conform with normalization, as else you would have multiple identical values in a table.
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.
I used the Forward Engineer tool in the MySQL Workbench to generate a database based on the tables I entered. I was able to populate my tables, such as "Villagers," "Fish," and "Items" for the database I am building around the game Stardew Valley. However, when I linked the tables in the ER Diagram it created new tables based on relationships, such as Cooking_Has_Fish because many fish can be used in many recipes and many recipes can use many fish. But, once I populated the Cooking and Fish tables there was nothing in the generated Cooking_Has_Fish table. I am trying to understand how this table functions or how it can be used, or if it needs to be populated and I missed something.
Thanks for reading.
No table ever gets populated on its own, you need to make sure that it gets populated. The third tables created for many-to-many relationships are called associative or junction table and as a minimum contain the primary keys of the 2 tables they join.
If you have a recipe_id identifying recipies and a fish_id identifying fishes, then Cooking_Has_Fish table would have at least a recipe_id and a fish_id field.
If you want to associate fish and chips (with recipe_id 1) with cod (fish_id being 2), then you would do the following insert:
insert into Cooking_Has_Fish (`recipe_id`, `fish_id`) values (1,2)
This means the cod is required for the "fish and chips". You may add additional fields to your association table, such as how much cod you need for the fish and chips.
In summary: you have to populate your association tables based on how you would like to associate your entities (tables) that have many-to-many realationship with each other.
I am creating a DB for my project and I am facing a doubt regarding best practice.
My concrete case is:
I have a table that stores the floors of a building called "floor"
I have a second table that stores the buildings called "building"
I have a third table that stores the relationship between them, called building_x_floor
The problem is this 3rd table.
What should I do?
Have only two columns, one holding a FK to the PK of building and another holding an FK to the PK of floor;
Have the two columns above and a third column with a PK and control consistency with trigger, forbidding to insert a replicated touple of (idbuilding, idfloor)?
My first thought was to use the first option, but I googling around and talking I heard that it is not always the best option.
So I am asking for guidance.
I am Using MySQL 5.6.17
You don't need third table. Because there is one-to-many relationship between building and floor.
So one building has many floors and a floor belongs to one building. Don't get things complicated. Even though you need a table with composite keys, you should be careful. You need to override equals and hashCode methods.
I am still not confortable with that approach. I am not saying it is wrong or innapropriate, very far from that. I am trying to understand how the informations would be organized and how performatic it would be.
If I have a 1:* relationship, like a student may be attending to more than one subject along its university course within a semester I would Have the 3rd table with (semester, idstudent, iddiscipline).
If I try to get rid of the join table my relationship would be made with a FK inside student table or inside subject table. And it does not make sense to do that because student table is a table for a set of information related with registering the info of a person while the discipline table holds the data of a discipline, like content, hours...it is more a parametric table.
So I would need a table for the join.
I have a table called 'notes', on this table I need to track who made that note, but the problem is that the creator of the note can be a user stored in one of three possible tables:
users
leads
managers
I have though of simply create three fields on 'notes' to represent the three possible relations: note.user, note.lead, note.manager
With this approach I would be forced to create three table joins when requesting the notes to gather the creators information, and I don't think that is the way to go, so I would like to hear your ideas or comments and what would be the best approach on this.
For me personally this smells like a design problem on a totally different part of the schema: Are manageers not users? Do leads carry person information?
With any approach that creates a relation between one column and one of three others, you will need three joins for the select. If you can't rectify the underlying problem, I recommend you use
note_type ENUM('users','leads','managers')
as an additional field and
SELECT
...
IFNULL(users.name(IFNULL(managers.name,leads.name))) AS name
..
FROM notes
LEFT JOIN users ON notes.note_type='users' AND users.id=notes.note_source
LEFT JOIN managers ON notes.note_type='managers' AND managers.id=notes.note_source
LEFT JOIN leads ON notes.note_type='leads' AND leads.id=notes.note_source
...
for the query
I think you need to abstract out the concept of a user id, so that it does not depend on their role. The author of a note could then be specified by the user id.
Users could be assigned roles, and maybe more than one.
The correct way to structure this would be to pull all common data out of users, leads, and managers. Unify this data into a "contact" table. Then if you want to get all notes for a given manager:
managers->contacts->notes
for a lead:
leads->contacts->notes
Notice your original post: "the problem is that the creator of the note can be a user stored in one of three possible tables"
From the structure of your sentence you even admit that all these entities have something in common; they are all users. Why not make the DB reflect this?
you have to model a parent table for the three tables you already have. Define a table that depicts generally user, leads and manager tables. Something like "Person". So you have all of the ids of the three tables and any common attributes on the Person table. And when you must define the relationship you put the foreign id "Person_ID" on the note table. And when you model user, leads and manager tables you also put the primary key as a foreign key to the Person table.
So you would have something like this:
Table users:
Users(
person_id primary key
...(attributes of Users)
foreign key person_id references Person.person_id
)
This model i depict is common to any relational model you have to model using parents and childs