I understand that a lookup table is necessary when we are dealing with many-to-many relationship.
But what about one-to-many relationship - do we need a lookup table or a foreign key in one of the tables?
Another question, is one-to-many the same as many-to-one?
You don't need a lookup table for one-to-many relationships, a foreign key column in the "many" table of this relationship will suffice.
One-to-many and many-to-one relationships are structurally the same, just mirror images of each other.
So you might say that a blog post and its comments are in a one-to-many relationship (where the foreign key is on the "many", in this case "comments"). Or you could say that comments and their blog post are in a many-to-one relationship (again, with the foreign key on the "many"). Either way, the db structure is the same, with no lookup table, and with the foreign key column on the "many".
Related
I have seen similar posts and have not found a definitive answer.
I have a series of tables that store data about certain events. Each of these tables have the same structure. Each of these tables has a foreign key constraint for an id showing what item the data is related to.
Each of these tables id structure is also the same CHAR(24). The tables these ids come from must remain separate because they are all completely different.
I am interested in combining all of my data tables into one with a foreign key being constrained to one of 3 tables. So, a row in my data table will have to have an id that is present in one of the three tables. Additionally this foreign key will need the possibility of ON DELETE settings. Is this possible? And to that, is this poor design?
Items A
- id
- ...
Items B
- id
- ...
Items C
- id
- ...
Data
- id FK
No. What you're describing is sometimes called polymorphic-associations but it should be a clue that it's not good design because you can't make a foreign key constraint for it. That is, the FOREIGN KEY syntax only allows you to reference one table, not three.
The only way you could make a real foreign key constraint that performs ON DELETE actions is to make three separate foreign keys:
Data
- idA FK
- idB FK
- idC FK
For a given row in Data, presumably only one of these three foreign keys would be non-NULL. The other two would be NULL. Ensuring this could be done in a trigger or CHECK constraint, or else you would just have to implement it in application logic (i.e. don't insert a row with more than one of these columns non-NULL).
Polymorphic associations, that is storing a single column that may reference one of three different tables, is not a valid relational design.
You can see past answers I've written about polymorphic associations: https://stackoverflow.com/search?q=%5Bpolymorphic-associations%5D+user%3A20860
I have:
Table Review with column item_id (not pk)
Table Product with column id (pk)
Table Business with column id (pk)
Relationships:
Review.item_id references Product.id
Review.item_id references Business.id
These relationships are 1:M
What is the syntax in MySQL for one column field to reference IDs from two different tables?
My research lead me to believe you cannot have one foreign key reference two different tables.
My conclusions so far (based on links provided below):
Use a foreign key without a foreign key constraint
Use field to reference other records, but do not create a foreign key constraint
Polymorphic Associations. The foreign key may reference rows in any of several related tables.
One foreign key can reference only one table
These conclusions seem logical to me, but I can't figure out the syntax.
links:
MYSQL - One Column Referenced to Multiple Table
Is it possible to reference one column as multiple foreign keys?
MySQL - Conditional Foreign Key Constraints
Today I faced something, Someone defined foreign keys as primary keys in Pivot Table! Why is that? Does it effect on performance ? What are the benefits and use cases ? Should we define foreign keys as primary keys in pivot table in order to make them unique ??
Example of my question:
Why should define our many-to-many relationship foreign keys as primary keys ?
This is the proper way to build a junction table, aka bridge table, in a N-M relationship.
Rationale:
each order_id (resp user_id) should refer to a record in master table orders (resp users), so you do want a foreign key on each of these columns to enforce data integrity
each (order_id, user_id) tuple should occur not more than once in the bridge table: this can be enforced by using this columns tuple as a composite primary key, or by setting a unique constraint on it.
Of course, it is also possible to define an indenpendent primary key for the junction table (like an auto-incrementend pk), but that is mostly a matter of taste.
I'm using MySQL 5.7 with WB6.3 for my study project to design the ER diagram.
When I try to create many-to-many relationship. By default MySQL will mark the primary keys of both tables as primary key in the lookup table as well.
Is it really need to have primary keys from both table as primary key in the lookup table as well ?
Please see the table car_item in my diagram below I've removed primary key from both red(idcar,iditem). Please tell me if PK is needed for them
There should be a unique key for (car_idcar, item_list_iditem_list), but it doesn't necessarily have to be the primary key. This way, you ensure that you don't create duplicate relationships between the same rows in the two tables.
A table can only have one primary key, and the car_item table already has primary key id_car_item, so the foreign keys for the relation can't also be a primary key. But there can be an arbitrary number of unique keys.
Some purists might say that if there are two unique keys (a primary key is also a unique key), one of them is redundant. In your case, the id_car_item column may not really be necessary, as it's not common to refer to relations in other tables, the relation table is just used to join the other two tables. But this isn't always the case. For instance, a user table might have a unique username column (since you don't allow multiple users to have the same name), but also a userid primary key that's used as the foreign key in other tables (this allows renaming users without having to update all the foreign keys). Some database designers like to have an auto-increment column in every table, as it's useful as a reference in user interface applications.
It is common practice to have a composite primary key in a table that implements many-to-many. This key should consist of primary keys from both tables on each side of the many-to-many relationship.
Such approach guarantees data consistency and eliminates duplication.
In your case you should define a composite primary key for table car_item that would consist of two fields { car_idcar, item_list_iditem_list }
The column id_car_item is not needed and can be dropped, it was probably added automatically, as many RDBMS add surrogate PK by default.
I am stuck in a problem where i have to find cardinality of a relationship between tables using mysql. Following this post MySQL: How to determine foreign key relationships programmatically?
I have found all tables related to my table and the columns which are foreign key. Now i also want to find the cardinality of relationship i.e. one-to-one, one-to-many or many-to-many. Any ideas or snippets would be highly appreciated
Let us assume that table A has a foreign key f which refers to the primary key k of table B. Then you can learn the following from the schema:
If there is a UNIQUE constraint on A.f, then there can be at most one row in A for every row in B. Note that in the case of multi-column indices, all columns of the unique constraint must be part of the foreign key. You can use SHOW INDEX FROM tablename WHERE Non_unique = 0 to obtain information on the uniqueness constraints of a table.
If A.f is declared NOT NULL, then there will always be at least one row in B for every row in A. You can use SHOW COLUMNS FROM tablename to list the columns and see which of them allow NULL values.
If you interpret “one” as “zero or one”, then you get a one-to-one relation using a unique constraint, and a many-to-one relation (i.e. many rows in A referring to one row in B) without such a unique constraint.
A many-to-many relation would be modeled using a separate table, where each row represents one element of the relation, with many-to-one relations for both foreign keys it contains.