How to update same fields but different tables - sql

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.

Related

Many-to-Many-to-Many Relation in SQL?

I am quite new to SQL and I am trying to make a few relations and come across the following.
I have 3 tables
- Persons
- PhoneNumbers
- PhoneNumberCategories
Persons and PhoneNumbers is self explanatory I think and PhoneNumberCategories I use to indicate whether a phonenumber is for the office, home, mobile, fax etc.
Now I made a 4th table to make this many-to-many-to-many relation. This table has 4 columns:
ID
PersonID
PhoneNumberID
PhoneNumberCategoryID
And I have set-up 3 relations here. One for all columns except the ID Column. It seems to work, but it just gives me a strange feeling. Can someone tell me if I am on the wright track or if I am going all wrong about this.
The reason I want this is as follows. Of course I need to link a person to a phone number. However, I may have a phone number that is the general office (This would be the row 'OfficeGeneral') number, and therefore linked to me because I work there. I also have a direct office (And this would be the row 'OfficeDirect') number. This is of course also linked to me. The general number however, is linked to all people in the office as 'OfficeGeneral'. Except for the receptionist, here it would be linked as 'OfficeDirect'. And this is the reason I came up with this many-to-many-to-many relation. I can not find much about it on the web. And that is reason enough to doubt if this is the correct way to go about it. Anyway, this is just an example. I would like to make sure that I am flexible and can catch as many exceptions as possible. I am sure once the database is in use that people will come with situations which I have not anticipated. People are good at that I have learned over the years.
Clarification in Response to Comment Below:
Person can have more than 1 PhoneNumber.
PhoneNumber can have more than 1 Person.
Person with PhoneNumber can have more than 1 PhoneNumberCategory (i.e. Private Phone used for both Phone and Fax.)
Several people can be linked to the same PhoneNumber with different PhoneNumberCategories. (i.e. OfficeMain for me is OfficDirect for receptionist.)
Looking forward to hear from you all.
Your model looks fine. Your description, perhaps, is not.
Person and PhoneNumber have a many to many relationship. This relationship, in turn, is 1-many with PhoneNumberCategory -- unless a given phone number could be in more than one category.
I would expect that Person/PhoneNumber would be declared unique in this table, so a person could only use a particular phone number once. However, that may not be how you are viewing the structure.

Normalizing database tables

I am quiet new in database designing, I am trying one test case to track students.
In below image, student can either be in school or club. For this I have create on LocationId which act as a global id for where ever the student is.
But the problem is I am depending on TypeId to determine if its Club or school.
So in my data access query I have to make cases. Pseudo code is :
if TypeId == 1
search in club for the LocationId and get the clubId.
else if TypeId == 2
search in school for the LocationId and get the schoolId.
How can I get rid of these cases and still be maintaining the normalized rule.
Thanks a lot for reading. Any comments are welcome.
Good day!
This seems to be a case of table inheritance and there is more than one way to solve it. Your solution with LOC_CONTAINER doesn't work (as you have noticed) as it requires outside code to do the checking.
Take a look at this comprehensive answer about inheritance. You could for example unify SCHOOL and CLUB tables into one table called PLACE or alternatively have both SCHOOL and CLUB columns in the table STUDENT with a constraint that one of them has to be NULL.

Is there an appropriate way to show correlation or causation from a SQL query?

I'm curious if there's any way that Microsoft Access or SQL Server can provide a function to show correlation or causation from a SQL Select statement and its results.
This is basically the use case scenario:
Let's say you have two tables, table studentCourseSurveys and table onlineCourseReviews. At the forefront these two tables are mostly unrelated but could be joined based on the course name, for example "ENG 101".
studentCourseSurveys is a table that is intended to hold data that students submit during
their in person course survey at the end of a semester. For example, in the last day of class students receive that form to fill out to rate the instructor based on things such as "exams were related to the actual lecture content", "instructor was on time and prepared", and then at the end they have their short answer opportunities to give additional comments.
onlineCourseReviews is a table that is used by an internal department that conducts content reviews on the online component of courses. For example, this department has individual instructional designers who are assigned different courses in Blackboard to review. They review content, delivery, course structure, and so on and so forth. The course is then given its comments, score, etc.
As already mentioned the tables would be most unrelated. But let's say someone wanted to show a correlation that the results of the online course reviews could somehow indicate that the quality of the overall course was better because of these online reviews, and that this was shown in the responses from the students based on their survey results.(basically, a course that got an online course review score of 10 has course surveys where a great majority of the students rated it as excellent, content was relevant, teacher was prepared, etc, to indicate that an improvement in the online course translated to improvements in the in-person class and overall class quality).
This almost seems like a unique job for a statistician but I'd like to know if it's possible to show this data based on a query in Access or SQL Server. I know that you could just easily join the two tables with a foreign key and then get the results of a survey and online course review in a single statement but that doesn't really say anything. I would think that to show ANY kind of relationship that you need to illustrate a trend over any given period of time.
Thank you.
I would suggest creating a query with three values - course name (e.g., ENG101), the student rating, and the online course rating. In SQL Server you can save the results as a .csv file. Do this, then open it in Excel and use the RSQ function , or R-Squared, to find the correlation coefficient between columns two and three. The closer R-squared is to 1, the closer the two match. 1 mean a perfect correlation. 0 means no relation at all and -1 means related but but in a polar opposite manner.

Trying to map Student with Marks obtained

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.

Adding new fields vs creating separate table

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 ??)