I am designing a database where I have a doubt. My requirement is to store the subject score for each student. I can achieve in two ways like below.
student_id and each subject as column and store one record for each student.
student_id,subject_name,score as columns and store one record per subject.
I need help in understanding the pros and cons of each implementation type.
Or table for Students:
StudentID - primary key
StudentName
etc.
and one for Subjects:
SubjectID - primary key
SubjectName
etc.
and one for Scores:
SubjectID
StudentID
Score
etc. (might be you want date here)
PrimaryKey (SubjectID, StudentID, SemesterID?)
Think about the last table - it will combine student and subject details given a score for each entity but you may need to add some date here, or exam ID or something else as one student may have score for same subject during the years (for example on math).
I think you're going to need 3 tables:
students
subjects
scores
students and subjects are master tables. They're going to provide student_id and subject_id for scores table as composite key. Here's the relational database design.
The point of seperating them into 3 tables is to avoid data anomalies. There are 3 anomalies:
Insert anomaly
Delete anomaly
Update anomaly
To learn more about data anomalies: https://www.geeksforgeeks.org/anomalies-in-relational-model/
Related
I am actually trying to create a student database and I need my table to be something of this type
In the above picture the date is something like a super-column name to columns-A,B,C,D which are subject names.
My data will be inserted in those A,B,C,D columns.
My final aim is to access attendance in all subjects based on the date.
Something like:-
select 27-01-2020 from 'table-name';
the above query should give me the attendance in all subjects on 27-01-2020 date
Is there any way to create such a table or similar to this one?
Assuming you have a table for the students and a table for the subjects, you could use a third table, representing the attendance of the students to the different subjects.
Such table will have a date, a reference to the subject, a reference to the student and an attendance column, possibly of type boolean, denoting if the student was present during that day at that subject. You may also add a slot, in case there are more than one hour of lecture for a subject on that day (but this is up to you and your needs).
There should also be a uniqueness constraint on the tuple (date, student, subject), so that there cannot be a student present at two different lectures the same day (unless you use the slot, to which the uniqueness constraint should also span).
I have a table like below:
Student:
StudentId FirstName LastName Grade
Course:
CourseId Name Desc
Offering
OfferNum CourseId ProfessorId
Student_Course_Mapping
OfferNum StudentId
I have a constraint which says that student can enrol only in 2
offering for 1 term and year.
For eg: Lets say student john has enrol in Java and Python for Winter
term(January - April) 2020 than he cannot enrol in other courses.
I don't have any front end or anything else to restrict this. I only have been told to work with the database and apply this constraint.
Right now we are entering data manually in this table using SSMS design view.
So is it possible to restrict someone entering such data?
This type of numeric constraint between two tables is not trivial to implement.
Here are four approaches.
(1) Create a table with one row per student, term, and year. Have two columns, one for each course. It is not possible to have more than two with this approach.
(2) Create a user-defined function that calculates the number of courses for a student in a given term and year. Then create a check constraint using this function.
(3) Create a with one per student, term, and year and a count of the courses for the term. Maintain this count using a trigger and place a check constraint on the value.
(4) Maintain all the logic in the "application". This would entail doing all inserts via a stored procedure and having the stored procedure validate the business logic.
In your case, I would probably opt for (2) as the last intrusive solution. If you already had a table with one row per student/term/year, I would suggest (3). It does involve a trigger (argggh!) but it also maintains useful information for other purposes.
Let's assume I am building the backend of a university management software.
I have a users table with the following columns:
id
name
birthday
last_english_grade
last_it_grade
profs table columns:
id
name
birthday
I'd like to have a third table with which I can determine all professors teaching a student.
So I'd like to assign multiple teachers to each student.
Those Professors may change any time.
New students may be added any time too.
What's the best way to achieve this?
The canonical way to do this would be to introduce a third junction table, which exists mainly to relate users to professors:
users_profs (
user_id,
prof_id,
PRIMARY KEY (user_id, prof_id)
)
The primary key of this junction table is the combination of a user and professor ID. Note that this table is fairly lean, and avoids the problem of repeating metadata for a given user or professor. Rather, user/professor information remains in your two original tables, and does not get repeated.
Tables:
Students
Professors
Entries (there’s no physical table intry in the database for entries yet, this table is on the front-end, so it is probably composed from multiple helper tables if we need them. Just need to create valid erd)
Preambula:
One student can have an association to many professors
One professor can have an association to many students
One entry can have 0,1 or more Students or professors in it.
Professor is required to be associated with one or more students
Student is not required to have an association with any professor
It should be more like this (front-end entry table):
Any professor in this table must have an associated name in the table.( For example Wandy is associated to Alex)
It is not required for student (but possible) to have associated professors in this table
One row (for example Linda (Student), Kelly (Professor),Victor (Professor))
Cannot be associated between each other in any manner.
But it is absolutely fine if Linda associated with David.
The problem is that I do not quite understand how one column can have ids of different tables (And those are multiple!) And do not quite understand how to build valid erd for that.
I will answer any additional questions you need. Thanks a lot!
If you simply want an association between Students and Professors - just make a many-to-many relationship in ERD. In logical (relational) schema it will make an intermediate table with foreign keys to Student and Professor tables.
But from your example it looks like you need to design the DB for your "PeopleEntries", which is not straightforward. ERD seems to have the following entities:
Students(ID, name)
Professors(ID,
name)
PeopleEntries(ID, LoveCats,
LoveDogs, LoveAnts)
Relationships (considering people cannot appear in entries more than once):
Students Many - 1 PeopleEntries
Professors Many - 1 PeopleEntries
Students Many - Many Professors
Relational schema would contain tables (foreign keys according to erd relationships):
Students(ID, name, PeopleEntryID FK)
Professors(ID, name, PeopleEntryID
FK)
PeopleEntries(ID, LoveCats, LoveDogs,
LoveAnts)
StudentProfessor(StudentID FK,
ProfessorID FK)
I don't know how to implement the constraint, disallowing association between people from the same entry, on conceptual level (ER-diagram). On physical level you can implement the logic in triggers or update procedures to check this.
As per my quick understanding,
Create a table with following columns
PersonName
Designation
.....
Create one more table
PersonName
LinksTo
In the second table each person entry will have multiple records based on the relation
You want a junction table:
ID StudentID ProfessorID
0 23 34
1 22 34
2 12 33
3 12 34
In the table above, one professor has 3 students, one student has two professors.
StudentID and ProfessorID should together be a unique index to avoid duplicate relationships.
I have a table students with the following fields.
Id,FirstName,SecondName,Photo,Student_ID
I also have a table called class_of_2011 with the fields
Id,FirstName,SecondName,Photo,Student_ID,Subjects
I want to select some specific students from table students and have them in table class_of_2011,but I already have the names in table students.I am thinking the only way to do this is to copy the names i want to the table class_of_2011,but since there will be a class of 2012 and beyond,I feel like I will be simply copying data from one table to the other.
Is repeating myself inevitable in my case?
It looks like this could be normalized easily. Why not have your class_of_ tables simply have a foreign key to the student table's id column?
StudentId,Subjects
In this way, one student record could be associated with several classes, in case someone is on the 5-year plan.
I'm assuming that the Student_ID field in the Students table is their id number or something, and not the primary key of that table.
Students Table
Id,FirstName,SecondName,Photo,Student_ID
Subjects Table
Id,Subject
Student_Subjects Table
Id,Student_Id,Subject_Id,Year
You may then assign a student multiple subjects, for multiple years.
The class_of_2011 table should contain the primary key of the students table and none of the other "repeated" data. All of the other columns you're interested in can then be obtained by joining the two columns together in a query.
I would restructure the data if possible... Something like....
Student Table
ID, Name, Address, other common specific to student
GraduatingClass Table
YearGraduate, StudentID
Enrollment Table
StudentID, ClassID, SemesterID