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
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.
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
Let's say I have three entities:
Projects
Sections
Activities
I wonder if it is possible to enforce the following constraints in my data model:
A project contains zero or more sections
A section belongs to one project
A section contains zero or more activities
An activity belongs to one project or a section within that project
What is the best way to model those constraints, especially the last one?
Those are relationship between the entities. You should create a FOREIGN KEY between the tables to depict that relationship or cardinality.
Like, Section table should have a FK referencing to Project table since there is 1 .. * relationship between those tables.
I am developing my tables for a website that I am working on, and after not doing much SQL in the past couple of years, I am a little bit rusty. I understand the concept of normalization and such, but this is a little bit confusing:
I have a few sections in the website where contacts will be listed, primarily on an Events page and on the website's Contact page. I would have a relation table that would be something like (just as an example) eventlisting hasmany contacts, which is fine because at least I could have a number of contacts attached to an event listing.
Would it be fine to have a table that just has a foreign key that points to my primary contacts table, and use that for listing my primary contacts?
Generally in a one-to-many relationship, it's the "many" that contains the FK. That way many event listings can be mapped to the same contact listing.
So in your case, the contacts table would have a FK to your eventlisting table.
If for some reason you need to have a many-to-many relationship, you'd want to create a join table that both your eventlisting and contacts table would have FKs to.
If an event can only have one primary contact, you can do it in two ways:
Add a primary_contact_id column in the Events table, as a FK to the Contacts table.
Use a relation table Event_Primary_Contacts, containing two FK's: Event_id and Contact_id. These should be a unique key in the table.
You could also add a boolean Primary column to the Event_Contacts table. However, this doesn't allow the DB to implement the constraint that there can be only one primary contact for each event.
I have a parent table called 'Website' which holds records about websites. I have a child table called 'SupportSystem' which holds records about different types of support systems such as email, phone, ticketing, live chat etc. There is an intermediate table 'Website_SupportSystem' which joins these tables in a many-many relationship.
If the SupportSystem for a Website is ticketing, I also want to record the software platform .e.g. WHMCS. My instinct is to create a new lookup table called SupportPlatform and relate this to the existing join table 'Website_SupportSystem' and store the data there. However, then there is no relationship between the SupportSystem and SupportPlatform. If I relate those then I end up with a circular reference.
Can you see what I am doing wrong? What would be the best way to model this data?
You could use super-type/subtype relationship, as shown in the diagram.
SupportSystem table contains columns common to all support systems.
Email, Ticketing, Phone and LiveChat tables have columns specific to each one.
Primary key in the subtype table is also a foreign key to the super-type table.
I would add a new column 'SupportPlatformId" to the "SupportSystem" table which lookup to the table "SupportPlatform", because "SupportSystem" to "SupportPlatform" is probably one-to-one or many-to-one.
Hence: Website -> (via Website_SupportSystem) SupportSystem -> SupportPlatform
Data about a Support Platform should be stored in the SupportPlatform table.
You can add a third foreign key, namely SupportPlatfromID, to the Website_SupportSystem table. If you do this, your intermediate table now records a ternary relationship, of the kind many-to-many-to-many. If this reflects the reality, then so be it.
If you want to relate SupportSystems and SupportPlatforms, just use the intermediate table as an intermediate table in the joins. You can even do a three way join to join all three entities via the intermediate table.
An alternative would be to create another intermediate table, SupportPlatform_SupportSystem, with a pair of foreign keys, namely SupportSystemID and SupportPlatformID. If this reflects the reality better, so be it. Then you can join it all together with a five table join, if needs be.