I have the following tables:
Student(Student_ID(PK), FName, LName,...)
Subject_details(Subject_code(PK), Subject_Name)
Subjects_Enrolled(Student_ID,Subject_Code)
My question is:
Can i have table as the one below
Marks_Details(Student_ID,Subject_Code,Marks_Obtained)
Does that table break any rule of database or anything as such? My requirement is to have a table that maps the marks obtained by a student in a particular subject and this is what I've come up with. Is it correct or is there any other approach to do the same?
Please let me the know the reason if you're going to downvote.
Thanks.
That data model looks fine. Your simply setting up a Many To Many relationship with some additional information (marks) contained in each record.
One suggestion would be to rename the Subject_Details table to Subject. I think this verbiage makes the relationship more clear.
Another suggestion would be to rename Subjects_Enrolled to Enrollment and just add the Marks_Obtained column to this table. This would eliminate the need for Marks_Details since the two tables basically contain the same information. Why store and maintain this data twice? The idea would be to insert a record into Enrollment when a student enrolls within a course and then to update the Marks_Obtained column at a later date when the course is completed.
Your idea doesn't "break any rule of database". I'd actually say it's pretty much the standard way of storing this data.
I would recommend to give the Marks_Details table a separate primary key, and maybe a date field. If a student wants to retake the subject, do you want the new data to override the old, or do you want to keep it both? It's up to you really.
Related
I am trying to figure out what the best way to design this database would be. Currently what I have works, but it requires me to hard-code values where I would like it to be dynamic in the future.
Here is my current database design:
As you can see, for both the Qualities and the PressSettingsSet tables, there are many columns that are hard-coded such as BlownInsert, Blowout, Temperature1, Temperature2, etc.
What I am trying to accomplish is to have these be dynamic. Each job will have these same settings, but I would like to allow the users to define these settings. Would it be best to create a table with just a name field and have a one-to-one relationship to another table with a value for the field and a relation to the Job Number?
I hope this makes sense, any help is appreciated. I can make a database diagram of how I think it should work if that is more helpful to what I am trying to convey. I think that what I have in mind will work, but it just seems like it will be creating a lot of extra rows in the database, so I wanted to see if there is possibly a better way.
Would it be best to create a table with just a name field and have a one-to-one relationship to another table with a value for the field and a relation to the Job Number?
That would be the simplest - you could expand that by adding data-effective fields or de-normalize it by putting it all in one table (with just a name and value field).
Are the values for the settings different per job? If so then yes a "key" table" with the name ans a one-to-many relationship to the value per job would be best.
Let's say I have two Tables, called Person, and Couple, where each Couple record stores a pair of Person id's (also assume that each person is bound to at most another different person).
I am planning to support a lot of queries where I will ask for Person records that are not married yet. Do you guys think it's worthwhile to add a 'partnerId' field to Person? (It would be set to null if that person is not married yet)
I am hesitant to do this because the partnerId field is something that is computable - just go through the Couple table to find out. The performance cost for creating new couple will also increase because I have to do this extra book keeping.
I hope that it doesn't sound like I am asking two different questions here, but I felt that this is relevant. Is it a good/common idea to include extra fields that are redundant (computable/inferable by joining with other tables), but will make your query a lot easier to write and faster?
Thanks!
A better option is to keep the data normalized, and utilize a view (indexed, if supported by your rdbms). This gets you the convenience of dealing with all the relevant fields in one place, without denormalizing your data.
Note: Even if a database doesn't support indexed views, you'll likely still be better off with a view as the indexes on the underlying tables can be utilized.
Is there always a zero to one relationship between Person and Couples? i.e. a person can have zero or one partner? If so then your Couple table is actually redundant, and your new field is a better approach.
The only reason to split Couple off to another table is if one Person can have many partners.
When someone gets a partner you either write one record to the Couple table or update one record in the Person table. I argue that your Couple table is redundant here. You haven't indicated that there is any extra info on the Couple record besides the link, and it appears that there is only ever zero or one Couple record for every Person record.
How about one table?
-- This is psuedo-code, the syntax is not correct, but it should
-- be clear what it's doing
CREATE TABLE Person
(
PersonId int not null
primary key
,PartnerId int null
foreign key references Person (PersonId)
)
With this,
Everyone on the system has a row and a PersonId
If you have a partner, they are listed in the PartnerId column
Unnormalized data is always bad. Denormalized data, now, that can be beneficial under very specific circumstances. The best advice I ever heard on this subject it to first fully normalize your data, assess performance/goals/objectives, and then carefully denormalize only if it's demonstrably worth the extra overhead.
I agree with Nick. Also consider the need for history of the couples. You could use row versioning in the same table, but this doesn't work very well for application databases, works best in a in a DW scenario. A history table in theory would duplicate all the data in the table, not just the relationship. A secondary table would give you this flexibility to add additional information about the relationship including StartDate and EndDate.
Good Day!
First of all I am new to making database so I am really hoping the pros out there could enlighten me. I am currently working on a student grading database. Each student has 10 subjects (math, science, etc). Each subject has 4 grading periods.Now this is the case.
I am using MS Access 2013
Let's just take one subject: Mathematics. I have 5 tables:
1. student_profile
2. math_1st_grading
3. math_2nd_grading
4. math_3rd_grading
5. math_4th_grading
Each of the tables above contain a field: Student Name.
I have a form for the student_profile table. What i want to do is when i enter data into the Student Name using the form, the Student Name fields for all the math grading tables will be updated.
I was thinking of making an update query for each of the math tables and run them simultaneously using a macro. But I don't know how to do that. It's just an idea for me.
Ive also read ideas like making an "after update" even in the form but i don't know much about macros and expression builders.
Please help me with this. Maybe i do not really know much about normalizing my tables please give some solutions for this.
Your response is much appreciated. Thank you
This is a bad database design. Look at what entities you are talking about: students, subjects and grading periods. So it is very likely you need exactly these tables.
student (student_id, firstname, lastname, entrydate, ...)
subject (subject_id, name)
grading (grading_id, name)
Then you combine these in a table to get to each student's subjects and gradings:
student_subject (student_id, subject_id, grading_id, result)
So when a student's name changes you only have to update one record in your database. When a subject gets added, simply insert one more record into your subject table. And so on.
This is however just an example. With this design you would be able to let students have different subjects for instance. If this is not desired, another model might be better. But it should give you the idea. First think of the entities you are dealing with, then think about how they are related.
So I am pretty new to SQL and databases in general(only designed a very simple one for a minimal site), and I'm trying to work out the best way to design some models for a heavily DB driven site. So take for example, a user uploaded gallery. I have a gallery table with sensible columns like date uploaded, name, etc., and galleries can belong to one category, of which there will not be that many (at most like 6). Should I have the category be a column of the gallery table? Or have a separate table for categories and have a many to one relationship between the category and gallery tables? I would like to do things in my views like sorting all galleries in a category by date uploaded, is there a performance/convenience difference between these? Having the category be a column of the Gallery table certainly seems easier to deal with than me, but I'm not sure what is the best practice. Thanks.
First of all, you need to understand the conceptual difference.
As a rule of thumb, you are safe to consider the following equivalence:
Table ~~~ Entity
Column ~~~ Attribute
So, when you need to add a new piece of data, in relation to an Entity (an existing Table), the question you can ask yourself is:
Is this piece of data an attribute of the entity?
If the answer is yes, then you need a new column.
For instance, say you have a table describing the Student entity:
Table Student:
[PK] Id
[FK] IdClass
Name
Surname
Say you want to also add the GPA of each student. This is obviously an attribute of the student, so you can add the GPA column in the Student table.
If however you wish to define the Department for each Student, you will see that the department is not an attribute of a Student. The Department is an entity, it exists and has its own attributes outside the scope of the student.
Therefore, the attribute of the student is the affiliation to a certain Department, but not the department itself.
So, you will create a new Department table, and use the Department.Id as a FK in the Students table.
I hope this helps. Cheers.
If you have a one to many relationship between categories and galleries, you want category to be a separate table.
When in doubt use a separate table.
It does not have such a big impact on speed and you will gain more control.
I am working on a project where there are several types of users (students and teachers). Currently to store the user's information, two tables are used. The users table stores the information that all users have in common. The teachers table stores information that only teachers have with a foreign key relating it to the users table.
users table
id
name
email
34 other fields
teachers table
id
user_id
subject
17 other fields
In the rest of the database, there are no references to teachers.id. All other tables who need to relate to a user use users.id. Since a user will only have one corresponding entry in the teachers table, should I just move the fields from the teachers table into the users table and leave them blank for users who aren't teachers?
e.g.
users
id
name
email
subject
51 other fields
Is this too many fields for one table? Will this impede performance?
I think this design is fine, assuming that most of the time you only need the user data, and that you know when you need to show the teacher-specific fields.
In addition, you get only teachers just by doing a JOIN, which might come in handy.
Tomorrow you might have another kind of user who is not a teacher, and you'll be glad of the separation.
Edited to add: yes, this is an inheritance pattern, but since he didn't say what language he was using I didn't want to muddy the waters...
In the rest of the database, there are no references to teachers.id. All other tables who need to relate to a user
use users.id.
I would expect relating to the teacher_id for classes/sections...
Since a user will only have one corresponding entry in the teachers table, should I just move the fields from the teachers table into the users table and leave them blank for users who aren't teachers?
Are you modelling a system for a high school, or post-secondary? Reason I ask is because in post-secondary, a user can be both a teacher and a student... in numerous subjects.
I would think it fine provided neither you or anyone else succumbs to the temptation to reuse 'empty' columns for other purposes.
By this I mean, there will in your new table be columns that are only populated for teachers. Someone may decide that there is another value they need to store for non-teachers, and use one of the teacher's columns to hold it, because after all it'll never be needed for this non-teacher, and that way we don't need to change the table, and pretty soon your code fills up with things testing row types to find what each column holds.
I've seen this done on several systems (for instance, when loaning a library book, if the loan is a long loan the due date holds the date the book is expected back. but if it's a short loan the due date holds the time it's expected back, and woe betide anyone who doesn't somehow know that).
It's not too many fields for one table (although without any details it does seem kind of suspicious). And worrying about performance at this stage is premature.
You're probably dealing with very few rows and a very small amount of data. You concerns should be 1) getting the job done 2) designing it correctly 3) performance, in that order.
It's really not that big of a deal (at this stage/scale).
I would not stuff all fields in one table. Student to teacher ratio is high, so for 100 teachers there may be 10000 students with NULLs in those 17 fields.
Usually, a model would look close to this:
I your case, there are no specific fields for students, so you can omit the Student table, so the model would look like this
Note that for inheritance modeling, the Teacher table has UserID, same as the User table; contrast that to your example which has an Id for the Teacher table and then a separate user_id.
it won't really hurt the performance, but the other programmers might hurt you if you won't redisign it :) (55 fielded tables ??)