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.
Related
I have two tables matches and tournaments with below structure,
MATCH
MATCH_ID
PLAYER_ID_1
PLAYER_ID_2
RESULT
TOURNAMENT_ID
and
TOURNAMENT
TOURNAMENT_ID
NAME
OTHER_DETAILS
with one tournament will have multiple matches
and a match may or may not have tournament id
use Cases:
retrieve all matches
retrieve all matches by tournaments
Is it good to have tournament id in match table? Or should I create a separate joining table for tournament and match mapping? Which will have good performance when the volume increases?
TOURNAMENT_ID has a 1:M relationship to MATCH. It seems to be a straightforward foreign key. The standard way of implementing foreign keys - even optional foreign keys - is a column on the child table with a foreign key constraint. This would support both your use cases.
A separate table would normally be a head scratcher. I say "normally" because there are schools of thought which abominate NULL columns in databases; either for practical reasons - NULLs can do weird things to our code and need wrangling - and academic reasons - NULL is contrary to Relational Algebra. So, if you have a data model which forbids the use of nulls you will need a TOURNAMENT_MATCH table to hold Matches which are part of a Tournament. It also would be likely to perform slightly worse than a foreign key column on MATCH, but unless you have a vast amount of data you won't notice the difference.
There is a use case for join tables (also known as junction or intersection tables) and that is implementing many-to-many relationships. Suppose we add a third table to the mix, PLAYER. A Player can participate in many Tournaments and a Tournament has many Players. Classic M:N relationship. So we can resolve it with a join table REGISTERED_PLAYER. which as a compound key of (TOURNAMENT_ID,PLAYER_ID) and the appropriate foreign keys to TOURNAMENT and PLAYER.
For the sake of completeness I will mention Link tables from Data Vault modelling. This is an interesting modelling technique for Data Warehouses, where - gross simplification alert - tables are defined as Hubs (business and technical keys) and Satellites (immutable attribute records). This approach allows for the capture of data changes over time. Foreign key relationships between Hubs are implemented through Link tables, to support changing relationships over time.
There are several benefits to Data Vault for wrangling large amounts of data in a time-sensitive fashion but an easy-to-understand physical data model isn't one of them. Anyway, find out more.
The simple rule: for one-to-many mapping always prefer a foreign key association to a join table association.
It is hard to control a join table using a standard #OneToMany Hibernate mapping — you can't just delete rows from a join table, or add an additional row. You will need to use list on the Tournament side to do things like that. Another option is to use an additional entity for a join table.
Note: Match can has a tournaments list too, but looks like Tournament is the owner of the association.
A few opinions have been offered in other answers, here is mine.
You do NOT want a separate join table, you would only need that if a Match can be in multiple Tournaments. In your example, just use a foreign key.
The only other suggestion is that if the Match is not part of a Tournament then it is not actually "unknown" which is the meaning of NULL, it is actually something else like "Individual Match". So consider adding a row to your Tournament table, maybe using a known key like 0 or -1, and using that for matches that are not part of a tournament.
I'm creating a database for personnel records and trying to ease record creation for the user and avoid a kludgy solution. The tables are:
people:
people_id,
person_name,
person_category_id
person_category:
person_category_id,
person type
document_requirement:
document_requirement_id,
document_requirement_name,
person_category_id,
document_section_id
document_section:
document_section_id,
document_section
I've created an append query (inner join) that populates a table caLLed document_repository which contains all of the required documents for all of the people. (I use a primary key composed of people_ID & document_id to avoid duplicates when the append query runs.) Here is the document_repository table.
document_respository:
document_repository_id,
people_id,
person category_id,
document_id,
document_section_id,
document_attachment
I'd like to be able to allow the user to create a document requirement that is applicable to multiple person categories. I understand I should avoid multi field values, which doesn't work anyway with inner joins. For example, if people categories include doctors and nurses, I'd like to be able to create a new document requirement that applies to both people categories (e.g., doctors and nurses), without having to create two separate document requirements.
More information needed?
Suggestions on design changes and/or queries?
Thanks!
snapshot of tables and relationships
What you describe is a many to many relationship. Each document requirement can be applicable to multiple person categories and different document requirements can be applicable to the same person category.
To have a many to many relationship between two entities (tables) in your database, you need another table to relate them. This additional table contains the primary key of both tables and each record in this table represents a link between the two entities.
Your naming is different between your text and your diagram, but I'll assume you want to have document_requirement records that can link to zero or more person_category records.
You need a table which for example could be called document_requirement_person_category and contains the following fields:
document_requirement_id - foreign key referencing PK of document_requirement
person_category_id - foreign key referencing PK of person_category
You then add a record to this link table for each person category that relates to each document requirement.
Edit: BTW, (if I'm reading your schema correctly), you already have a many to many relationship in your schema: document_repository allows a relationship between multiple people and a document requirement as well as multiple document requirements and a person. That's a many to many relationship.
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.
The following is an Entity Relationship of a a Baseball League.
I'm having a bit of confusion understanding Relations and Attributes of Relations.
An description of the diagram follows:
According to the description, Participates is a Relation and Performance is an Attribute (complex) of Participates.
Questions:
How do Participates Map to actual tables in a database?
Would there be a Participates table with the fields that define Performance?
{Hitting(AtBat#, Inning#, HitType, Runs, RunsBattedIn,
StolenBases)}, {Pitching(Inning#, Hits, Runs, EarnedRuns, StrikeOuts, Walks, Outs, Balks, WildPitches)}, {Defense(Inning{FieldingRecord(Position,
PutOuts, Assists, Errors)})}
Similarly are Plays_For, Away_Team and Home_Team also tables.
As you create tables in a database (say MySql) how are Relations differentiated from Entities / Objects like Player, Team and Game.
Thanks for your help.
Question 1: Participates would be an actual table with foreign key columns for Player and Game as well as the column(s) for Performance. All M-N relationships need to be modelled in a separate table.
Question 2: To keep it as a semi-decent relational DB you would have to separate all the info into separate columns so that each column would only hold one singular data. If you didn't separate the data you would break the first normal form and would probably run into problems later in the design.
Question 3: As these three are 1-N you could also implement them with columns on the N-side. In the Game table for example you could have two foreign keys to Team table as well as all the data about the relationships in columns. For claritys sake you could make those relationships as separate tables also. As a sidenote: are you sure Player-Team is a 1-N-relationship so that a if a player changes teams the history-info about the StartDate and EndDate of the previous team is immediately lost?
Question 4: They are all treated absolutely the same - no differentiation.
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.