Suppose I have a table called "student" with a single column "name". And I want to store a second attribute called "group". "group" will be a value calculated from the name, and different names can be in the same group. So each name has a group and a group can have many names. This could be easily modeled in a normalised schema by creating a second table called "group" and adding a fk column to "student" that points to "group". However, suppose now that I can only calculate a student's group some time after they have registered. So I need to be able to enter a student without knowing their group. With this schema, I'll either have to use null fk's, or not add the student.
Apologies if I'm missing the obvious, I'm somewhat new to normalisation. What I have considered is using an associative table with a fk for group and a fk for student. This would allow me to enter students without knowing their groups and then linking them to their groups via the associative table at a later stage. But from what I've read on associative tables, you're meant to use them for deconstructing many-to-many relationships. And this is a one-to-many relationship. So I'm confused. Is there a standard way of normalising such a many-to-one relationship where the value can only be calculated later?
A pretty common way to solve this is just to have a "no group" record in the groups table. All students start off mapped to that record and then you update the foreign key when they are assigned to a group.
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'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 have hit a road bump where i need to list all the current courses for students and instructors and i have 2 tables one of them is called students and the second one is called courses. I was thinking of creating a field for students called courses and then separating entries with a comma so i can use the WHERE IN clause but creating a table for each student is much easier.
As you have a many-to-many mapping, consider using a linking table with student_id and course_id columns.
I was thinking of creating a field for students called courses and then separating entries with a comma
Bad idea, and you're certainly not the first to have it.
creating a table for each student is much easier
Worse idea, and you're certainly not the first to have it.
Don't create database structures that require you to parse information from disorganized blobs. And definitely don't create database structures that require you to change the structure every time data changes.
What you're describing, the relationship between Student and Course, is called a many-to-many relationship. To achieve it, all you need is a "linking table" between the two entities. Consider something like this:
Student
----------
ID (PK)
Name
Course
----------
ID (PK)
Name
Simple enough representation of those two entities. Now all you need is a third table to connect them in a many-to-many relationship:
StudentCourse
----------
ID (PK)
StudentID (FK)
CourseID (FK)
A few things to note:
The name of the table doesn't have to follow this convention, this is just a common practice. You can call it anything you like. Enrollment might be a good name for this as it grows into its own entity.
This doesn't need its own ID (PK), its primary key could be a composite of the two foreign keys (since each pair thereof should also be unique in this domain).
This can quickly grow into its own entity if it has more data than just the relationship. For example, if there is specific information about a student's enrollment in a course which is specific to the combination of the two, but not specific to either entity itself. A registration number of some kind, a date/time of enrollment, etc. This table would become its own entity alongside the other two and be more than just a structural linking table.
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.
A new requirement has come into an existing application. Current, we have an organization table, and it has a child table CalendarEvents. Now, the request is to allow either the User table, the Organization table, or the Division table own calendar events. I am thinking something needs to change because right now, this would leave me with creating the following table structure:
Organization (organization_id)
User (user_id, organization_id)
Division (division_id),
Calendar (calendar_id, organization_id, user_id, division_id),
CalendarEvents (calendar_event_id, calendar_id)
I am trying to avoid linking Calendar to multiple parents. Is there are better way to do this that I am missing? (An organization/user/division can have multiple calendars, but only one org/user/division can own a calendar)
Thanks for any input.
Since User instances and Organization instances can have their own events, I'd be inclined to make separate tables:
Organization
OrganizationCalendarEvents (with FK to Organization)
User
UserCalendarEvents (with FK to User)
In this way, the two entities can control their own events. In addition, if you keep the structure the same, you could use a single base class in your middle-tier which can load from either table.
If the CalendarEvents for each entity (User, Organization, and Division) are mutually exclusive, I might start out with three identical tables of events: UserCalendarEvents, OrganizationCalendarEvents, and DivisionCalendarEvents.
A better solution, though, may be to define those as three tables of links:
UserCalendarEvents
user_id
calendar_event_id
OrganizationCalendarEvents
organization_id
calendar_event_id
DivisionCalendarEvents
division_id
calendar_event_id
Yes. There is a technique called "morphing" which is appropriate for your case. Your CalendarEvents table should have a field called "owner_type" and another field called "owner_id". "owner_type" would indicate the table to which "owner_id" is a foreign key for the particular row. If owner_type is 1, then owner_id is a user_id; if owner_type is 2, then owner_id is an organization_id. And so forth.
One table column for many fk tables? .
and
multiple tables need one to many relationship .
If you want the DBMS to enforce the integrity rule that any calendar event is always either for an X, or a Y, or a Z (and just one of them), then you'll have to create three tables.
You can always create a view of "all calendar events" by UNIONing them together (after projecting away the owner column, of course). Obviously, that view is not updatable.
If you set up three separate tables with only a "link" to a "shared" events table, you still won't be guarded from having "orphaned" events.