This question already has answers here:
Foreign Key to multiple tables
(8 answers)
Closed 2 years ago.
So I have two tables -- Student table and Staff table, I also have an Item table, the plan is for students or staff to take custody of an item, put in another way, for an Item to have a custodian (student or staff). So I created a new table -- Item_Custodian. How do I model a relationship that would enable my Item_Custodian table holds information about an Item and it's custodian be it a student or a staff. Suggestions, tips etc are welcomed. Thanks
I would share three approaches I know for handling such relationships:
Approache 1: Define two separate nullable foreign keys in
Item_Custodian one referencing to Staff and one referencing to
Student resulting in two physical relationships one of which is
always null.
Approach 2: Define two ranges of Ids for Student and
Staff in a way that don't overlap. Then, create only one column in
Item_Custodian and initialize it with either of the two table Ids
resulting in a logical relationship.
Approach 3: Define two columns in Item_Custodian one as a logical foreign key and the other as the type of the first column (i.e. StaffType or StudentType).
In your scenario where there are only two custodians, I personally prefer the first approach for two reasons:
It creates physical relationship between tables
Only one null column does not make a table sparse
Related
I have two tables, tblRecipes and tblChemicals, that are linked in a many to many relationship using a junction table tblRecipesChemicalsLink. I have a bunch of variables for calculations that differ between the same ingredient used in a different recipe. There are also a differing number of those variables between the same ingredients for different recipes:
recipe A: Water: coefficient A = 0,2648; coefficient B = 0,589,
coefficient D =0,1
recipe B: Water: coefficient E = 0,569;
coefficient C = 0,987
I want the database to be flexible in the number of variables that can be associated with the unique combination of recipe and chemical, so I wanted to create a 1-m relationship from the junction table tblRecipesChemicalsLink to a table holding my variables with fields like Value,Name,Description,ID etc. I have not figured out a way to do this succesfully. The junction table in access only lists the individual keys for tblRecipes and tblChemicals, but I would need to link the variable table to the unique combination of those keys. Adding a new ID field to the junction table and adding an ID field as primary key for the Variable table and then linking those only allowed for a many-one relationship between junction and variable table. I would need it to be the other way around. Is there some way to do this in Access? Do I have to somehow write a new custom key and construct it from the primary key values of the tables that are linked by the junction table manually?
I am using ms Access. I am looking for a table with a different coefficient in every ROW linked to the junction table, not different COLUMNS for every class (like in inheritance). The coefficients cannot be assigned to meaningful subtypes in my case.
Do some research on Ternary Relationships. These are relationships of degree three.
Your existing junction table implements a M-M binary relationship. You are going to want an M-M-M relationship. This means that your junction table will consist of not two but three foreign keys. The first two will identify a recipe and a chemical, as they do now. Your new table, (let's call it coefficients) has an ID field, as you have pointed out in your question. A foreign key that references coefficient.id is what you need to add to the junction table.
This means that every Recipe-Chemical pair would need one or more rows in the junction table, one for each coefficient that participates in the recipe for the chemical.
There are more design issues. Your coefficient table is going to have to handle some abstract form of typing unless every coefficient can be specified as a floating point number.
This is really one step towards a star schema design. I have never attempted a start schema design in MS Access, and I don't know what pitfalls you are getting near.
I currently have this table for an online reservation school project:
I was just wondering what if a student decided to reserve two items (uniform), how would I manage to fit it into one reservation number (primary key) if I can only put one item at a time?
You should move the Uniform objects into a separate table which is in relation with the current table so that there will be a single Reservation with multiple Uniforms related to it. The relation between this two tables can be a Foreign Key from the uniform table to the reservation table.
Create Foreign Key Relationships
This question already has answers here:
Should junction tables have more than one primary keys from another identifying table?
(4 answers)
Closed 7 years ago.
I have two tables that I need to connect: discipline and class.
It will be a N:N relation, so I'll create a new table class_discipline.
Does my pivot table class_discipline may have more fields than just the Ids of the two tables ? Is it a good practice ?
If yes, is there some kind of rule that I should follow to do such a thing ?
Let me explain the situation: I'll import some data from an excel file, I can't change the data of this file (My university provides it).
And this file have some data that does not fit neither on discipline or class tables. So I guess I should insert this "extra data" into the pivot table.
Your table class_discipline can have as many columns as you want.
Generally any column in that junction table represents an attribute of the relationship. In this case if a relationship between class ad discipline needs any specification then yes, use more columns.
Example:
Assume you have tables students and courses. And to define who is enrolled in which course, you will create student_course table containing only student_id and course_id. But if you want to know when a student enrolled, you need to save this information somewhere (it's not an attribute of a student nor course). That's the time for adding new column into student_course table.
Good or bad practice?
Using additional columns in a junction table for attributes of the relationship is a good practice normally. However you need to keep in mind that you lose the column values if the relationship is removed.
Additional comments:
If you are using such structure in an application or via ORM, note that plain N:N relationship is a field of a class. Once you need more attributes of the relationship you need to have a separate class.
In a MySQL Database, I have two tables: Users and Items
The idea is that Users can create as many Items as they want, each with unique IDs, and they will be connected so that I can display all of the Items from a particular user.
Which is the better method in terms of performance and clarity? Is there even a real difference?
Each User will contain a column with a list of Item IDs, and the query will retrieve all matching Item rows.
Each Item will contain a column with the User's ID that created it, and the query will call for all Items with a specific User ID.
Let me just clarify why approach 2 is superior...
The approach 1 means you'd be packing several distinct pieces of information within the same database field. That violates the principle of atomicity and therefore the 1NF. As a consequence:
Indexing won't work (bad for performance).
FOREIGN KEYs and type safety won't work (bad for data integrity).
Indeed, the approach 2 is the standard way for representing such "one to many" relationship.
2nd approach is better, because it defines one-to-many relationship on USER to ITEM table.
You can create foreign key on ITEM table on USERID columns which refers to USERID column in USER table.
You can easily join both tables and index also be used for that query.
As long as an item doesn't have multiple owners it's a one to many relationship. This typically gets reduced to the second approach you mention, eg. have a user or created_by column in the Items table.
If a User can have one or more Items but each Item is owned by only a single User, then you have a classic One-To-Many relationship.
The first option, cramming a list of related IDs into a single field, is exactly the wrong way to do it.
Assign a unique identifier field to each table (called the primary key). And add an extra field to the Item table, a foreign key, the id of the User that owns that item.
Like this ERD (entity-relationship diagram)…
You have some learning to do about relational database design and normalization.
I have the following tables created:
Animes(id,title,date), Comics(id,title,date), TVSeries(id,title,season,episode,date)
Some of them have already foreign keys (for one-to-many or many-to-many relations) of directors, genres, articles and so on.
Now i would like to create two more tables Reviews(id,rating,date) and Posts(id,thumbid,articleid,reviewid).
A review is about one Anime and/or Comic TVSerie and vise-versa but properties of a review may be in more than one table. Its the same about a posts.
Is this a typical example of one-to-one relation in separate table or is it more efficient to add more properties to the existing tables?
So more tables and relations or less tables more columns?
Thank you and i hope my question isnt that stupid but im a bit confused.
In my view, It is better to avoid foreign key relationship for one-to-one relationship. It is best suitable for one - many relationships.
I'm not exactly sure what your requirements are, but the choices are as follows:
Have Reviews have 2 columns, either being a foreign key to the applicable table, can be NULL. This is really for when a single review can be about both.
Have a ReviewsComics and ReviewsAnime table. You'd then have all the fields from Reviews in each table (and no Reviews table).
An alternative (2) is to use them in conjunction with a Reviews table, then those 2 tables only has 2 fields which are foreign keys to Reviews and Comics/Anime respectively (thus no direct link between Reviews and Comics/Anime).
Have a base table to which Anime and Comics are linked to 1-to-1 and have reviews link to that table instead.
(Edit) If all the fields are all going to be the same (or similar) for Anime/Comics, you can merge them into a single table and add a type field, indicating Anime/Comics, then the problem goes away. This is similar to the base table option.
EDIT: The 2 reviews tables will probably give the best performance (unless you want to select all reviews for either, often), but with proper indices the performance shouldn't be an issue with any of the above.