There is a classic way to create many-to-many relationship by using an association (junction) table.
Also, I am noticing that MS Access has "Allow multiple values" option in table field properties in Lookup tab. Switching this option to "Yes" allows you to point to many records in another table instead of pointing to just one. This effectively creates some form of many-to-many relationship, at least one-way many-to-many relationship. The upside of this approach is that it has zero development overhead, as it works out of the box.
Q1: So what is the catch in this second option? Why would I want to use the classic junction table and not this other approach?
Q2: Is there a way to make "allow multiple values" a true two-way M:M relationship, where I could point at multiple records in another table from either table, not just one?
Related
I have two collections in Directus (data platform that provides many features including REST API over database records). There is option to set relationship between different collections.
I set many-to-many relationship between collectionA and collectionB.
Special system collection (junction table) called collectionA_collectionB was automatically created. Now I can add items from collectionB while editing collectionA items.
But same time I want to add collectionA items while editing collectionB items and I don't find way to add existing junction table. When I add many-to-many relationship between collectionB and collectionA - new junction table is created.
How can I use same junction table to achieve symmetric many-to-many relationship?
From the Directus UI you can delete the relation from CollectionA and also delete the junction table collectionA_collectionB and then create again the M2M to CollectionB but when creating, please click "Continue in Advanced Field Creation Mode" just below the "Save" button you'd like to rush to click otherwise: https://i.imgur.com/7LASmQp.png
Now, click "Relation" from the left menu and under "Corresponding Field" check the "Add M2M" to ColumnB" checkbox: https://i.imgur.com/ptb0aNr.png
If you don't want to delete what's created already (for example, lot of data in the tables already), then I think the only way is to make changes directly to the directus_* tables on the database. I don't know how to do it as I didn't have much data when I had this problem.
I was unable to find a clear answer of how to create an IS_A relationship in Access.
There was the same question here, but without a concise answer:
IS_A relationship primary key validation rules
I have the entity Employee, and two sub-entities Loan_Officer and Branch_Manager. It's a school example of an IS_A relationship really.
I've managed to create A relationship, but there needs to be a constraint that an employee must be either a Loan Officer or a Branch Manager, but can not be both. Now, I can't figure out how to do this, because what ever I do, I can assign the same Employee_ID in both sub-entity tables at once.
I've connected the tables via the PK, as it's shown here:
Now, this table design is just something I've done, in order to be able to connect them via a one-to-one relationship. I had to set the PK of Loan_Officer to "Number" and not "AutoNumber", in order to be able to connect them. The other option is to have a separate PK in Loan_Officer, like "Loan_Officer_ID", and a foreign key, "Employee_ID" in the Loan_Officer table, but the results are again the same (also according to the ER Diagram, the sub-entities don't have a separate PK).
You can't. This is not a feature of the Access database.
You can create CHECK constraints to check for such conditions, but those don't offer features to cascade operations.
See this answer for an example on how to create a CHECK constraint.
There is no such thing as an 'Is A' relationship in databases between tables. This is instead a field in the Employee table or Employee History Table.
The issue of 'can't be both' is a matter of validation logic. Where this validation logic is applied is probably at the form object level (during data entry), not the table level (no data should ever be entered directly into tables by end users).
Look into Access Data Macros . They can be used like SQL triggers firing off when a record is INSERTed, UPDATEed, DELETEed etc.
So I am building out a set of tables in an existing database at the moment, and have run into a weird problem.
First things first, the tables in question are called Organizations, Applications, and PostOrganizationsApplicants.
Organizations is a pre-existing table that is already populated with lots of data in regards to an organization's information which has been filled out in another form on another portal. EDIT: I cannot edit this table.
Applications is a table that records all information that a user inputs in the application form of the website. It is a new table.
PostOrganizationsApplicants is basically a copy of Organizations. This is also a new table.
The process goes:
1. Go to website and choose between two different web forms, Form A pertains to companies who are in the Organizations table, and Form B pertains to companies who are not in that table.
2a. If Form A is chosen, a lot of the fields in the application will be auto-populated because of their previous submission.
2b. If Form B is chosen, the company has to start from scratch and fill out the entire application from scratch.
3. Any Form B applicants must go into the PostOrganizationsApplicants table.
Now I am extremely new to SQL and Database Management so I may sound pretty stupid, but when I am linking the Organizations and PostOrganizationsApplicants tables to the Applications table, FK's for the OrganizationsID column and PostOrganizationsApplicantsID columns will have lots of empty spaces.
Is this good practice? Is there a better way to structure my tables? I've been racking my brain over this and just can't figure out a better way.
No, it's not necessarily bad practice to allow NULL values for foreign key columns.
If an instance of an entity doesn't have a relationship to an instance of another entity, then storing a NULL in the foreign key column is the normative practice.
From your description of the use case, a "Form A" Applications won't be associated with a row in Organizations or a row in PostOrganizationsApplicants.
Getting the cardinality right is what is important. How manyOrganizations can a given Applications be related to? Zero? One? More than One? And vice versa.
If the relationship is many-to-many, then the usual pattern is to introduce a third relationship table.
Less frequently, we will also implement a relationship table for very sparse relationships, when a relationship to another entity is an exception, rather than the rule.
I'm assuming that the OrganizationsID column you are referring to is in the PostOrganizationsApplicants table (which would mean that a PostOrganizationsApplicants can be associated with (at most) one Organizations.
I'm also assuming that PostOrganizationsApplicantsID column is in the Applications table, which means an instance of Applications can be associated with at most one PostOrganizationsApplicants.
Bottomline, have a "zero-or-one to many" relationship is valid, as long as that supports a suitable representation of the business model.
Why not just add a column to the Organizations table that indicates that the Organization is a "Post" type of organization and set it for the Form B type of applicants? - then, all your orgs are in one table - with a single property to indicate where they came from.
If you can add a new record to Organizations (I hope you can) just
create FK from Organizations as PK of PostOrganizationsApplicants. So
if Organizations has corresponding record in PostOrganizationsApplicants - it's "Post"!
Thanks everybody, I think I found the most efficient way to do it inspired by all of your answers.
My solution below, in case anyone else has a similar problem...
Firstly I will make the PK of PostOrganizationsApplicants the FK of Organizations by making a "link" table.
Then I am going to add a column in PostOrganizationsApplicants which will take in a true/false value on whether they completed the form from the other portal or not. Then I will ask a question in the form whether they have already done the other version of the form or not. If the boolean value is true, then I will point those rows to the Organizations table to auto-populate the forms.
Thanks again!
I want to know in what situations we create many to many relation. What is the need of doing such?
A quick search goes a long way. Though the following is for MS Access, the concept is the same for any relational database.
Via: office.microsoft.com - Create a many-to-many relationship:
You have a many-to-many relationship when a single record in one table
can relate to many records in another, and a single record in that
second table can also relate to many records in the first. For
example, say your company has several types of computers and several
technicians, with each technician certified to work on some, but not
all, of the computers. Each technician can be related to more than one
computer, and in turn, each computer can be related to more than one
technician.
To track who can work on a given machine, you create a many-to-many
relationship by adding the primary keys from both sides of the
relationship to a third table, called a junction or link table. In
other words, a many-to-many relationship is really just a pair of
one-to-many relationships.
I have a Users table and a Reviews table. The Reviews Table has ReviewedUserId and ReviewerUserId, both foreign keys that are pointing to the primary key of User table (UserId). When I try to create the second relationship in Access between the User table and Reviews table, it creates a second User table and names in Users_1.
Firstly, is this normal in Access? In SQl Server, I can have two relationships between two tables with no problem.
Secondly, is it possible to rename this alias table so that it doesn't have to be called Users_1?
Thanks.
User_1, User_2 etc is the way Access aliases tables when creating multiple relationships. If you use code to create the relationships, you can choose your own names
Database.CreateRelation Method
But I do not know of any way to change the alias in the relationship window.
Do you have to have referential integrity enforced at the table level? Can you just set up the relationships as a query? I'd guess that you can rename the 'alias' table if you do it via a query. In fact, you could just write the SQL and paste it right into an MS Access query.
I very rarely set up table level relationships in Access nowadays, and I also rarely even link forms through directly to tables or queries any more. I use unbound forms, populate them with code, and use code / DAO to control the updates of the relevant recordsets. All the behaviour of relationships, I then enact using SQL & VB as required.