I'm working on a system to manage students attendance in class. I created two tables: student (student_id,name,mail..) and course (course_id, name, lecturer...). now my question is how should i keep record of which students taking which courses?
should i create another table for each course with this structure:
course_id,lecturer,student_1,students_2,student_3...
or maybe there is a better solution for creating this relation?
tx
UPDATE: i should have mentioned that student can take several courses
Since there is a many to many relations between your tables(every student can take many courses,each course can be taken by multiple students) you need an intermediary table which hold the primary key of both table.
coursestudent(course_id,student_id)
with FOREIGN KEYs to the respective tables.
Depends, if a student can have multiple courses and a course belongs to multilple students you want to make a table that contains id, course_id(FOREIGN KEY) and student_id(FOREIGN KEY).
If a student can have only one course, but a course can be followed by multiple students you probably want to add course_id to student as foreign key.
You need two tables,
students (student_id, studentName, student.....)
courses (course_id, student_id, courseName, course....)
Here, student is related to course(s) by student_id along with course_id in courses table.
EDIT:
course_id student_id courseName
c12 s34 DB
c12 s35 DB
c43 s86 OS
c65 s45 PHP
c57 s86 OS
... ... ...
... ... ...
... ... ...
Related
I have two tables
student(sid,sname,sage,sgender,semail)
Course(cid,cname,credit)
where one student can enroll for only 1 course and in one course there can be many students.
so should I use the foreign key in the course table or creating a new table for enrollment.
Is this approach depends on the situation or others?
Based on your current scenario, you should create foreign key in your students table similar like s_cid.
But rather I suggest create separate table for enrollment, thinking of possible future requirement change where student can attend multiple courses. So you would have enrollment table with id, sid, cid columns.
I'm trying to improve the database design of my web system. Basically I have some doubts about a table that I have where I store the data of all my users, like FirstName, LastName, etc. This table stores the same data for all my different users, on this case for Students, Profesors and two more type of roles. Right now I have it as one single table call it PERSON. There I have all the relations of my foreign keys, even between "Persons" when a Student have a Profesor as Tutor. But I use some colums only when the Person is a Student, fields Enrolled or PaidUp for example and I keep it as null when is other type of role.
Now, my question is what are the cons and pros to divide the table Person, and create subclasses and store only the foreign key where I need it. Should I keep the single table and use "where" to filter my query, or do I normalize the table in several
tables doing a join on Person when I need the general data?
A person is a person and should have its own table. A student or professor is a role played by a person. A person can play many roles. I was a student at my university, then I later taught there.
A student is enrolled in a class, so have an tacit relationship with a professor in that way. You could also track relationships explicitly, as below
Read up on Table Inheritance too
You design should look like this:
PERSON
id
name
dob
...
PERSON_ROLE
person_id references PERSON(id)
type {student, prof, etc}
student_number (nullable)
salary (nullable)
...
PERSON_RELATIONSHIPS
from_person_id references PERSON(id)
to_person_id references PERSON(id)
type {tutorOf, studentOf, ...}
...
I have this problem:
I have a "school" database and need to reference the Teachers table with the Subject table.
Teachers will instruct more than one subject. And here is the problem.
Teachers table:
id_Teacher <- PK
id_Subject
id_Course
name
surname
address
etc.
Subject table:
id_Subject <- PK
name
I always worked with 1 value on foreign key. ex:
SELECT * FROM Teachers WHERE id_Subject = 1
but now I don't really know what I have to do.
What I think you're trying to describe is called a "many to many" relationship. It requires an intermediary table to connect the entity tables, and in many cases the intermediary table becomes a business entity in and of itself.
Consider for example:
Teachers
----------
ID
Name
etc.
Subjects
----------
ID
Name
etc.
TeacherSubjects
----------
ID
TeacherID (FK to Teachers)
SubjectID (FK to Subjects)
The relationship between the Teachers and the Subjects itself becomes a place to potentially store data. Thinking about the subject domain (a school), the TeacherSubjects table sounds like it might be a Classes table waiting to happen. Where you could put information about a given instance of a class, which is a business entity that has a teacher and a subject.
You say "Teachers will instruct more than one subject." From this I understand that a teacher may instruct multiple subjects. Then, it is wrong for a teacher to have an id_Subject, because that would mean that a teacher can only teach one subject.
If you make the subject contain an id_Teacher, then each subject will refer to a teacher, and therefore it will be possible to make multiple subjects have the same teacher. Which is the same as saying that a single teacher will teach multiple subjects.
If, on the other hand, you need to have not only one teacher teaching multiple subjects, but also a subject being taught by multiple teachers, (many-to-many relationship,) then clearly, you cannot put id_Teacher in subject, because this forces a single subject to be taught by only one teacher. In that case neither your teacher row can have an id_Subject, nor your subject row can have an id_Teacher. Instead, you will need an extra table, say "TeachersSubjects", where each row will have an id_Subject and an id_Teacher, essentially listing all the possible combinations of teachers and subjects.
I think it is relation many-to-many, teacher can has multiple subjects, and subject can have multiple teachers, you need additional table.
Given two relations:
Students = (St-Id, Name, Address, CourseNo, Cgpa)
Courses = (CourseN0, CourseName, Credits)
where primary keys are St-Id and CourseNo. CourseNo in Students relation is a foreign key references Courses relation.
Assume the following queries are frequent:
Question: What are the courses (CourseNo and CourseName) studied by each student?
SELECT Students.Name, Courses.CourseName, Course.CourseNO
FROM Students
INNER JOIN Courses
ON Students.CourseNo=Course.CourseNo;
Is that the right query by using join operation?
It's a a primary index because of course number. Can we consider it as rule to say courseNo is a primary index? It's also clustering? What is the difference between clustering and primary index?
Question: What is the Cgpa for each student?
Answer : Select Cgpa and name from students
I agree with simon at rcl, your design only allows one course per student. Try to put an intersection table between student and courses.
Students = (St-Id, Name, Address, Cgpa)
Courses = (CourseN0, CourseName, Credits)
StudentCourse = (St-Id, CourseN0)
If the table has a primary key, then the clustered index is the same as the primary key. If it doesn't have a primary key, InnoDB will create a clustered index on its own. The rules it uses to decide how to do this are described here.
Your syntax is not quite right. To select multiple columns from the table, you separate them with comma, not and. So it should be:
SELECT name, cpga FROM student
Also, if St-id is the primary key of Students then a student can only have one course. You design looks a bit lacking there.
SELECT
name
,cgpa
FROM
students
WHERE
1=1
try this
I have a problem in logical design of a SQL Server database.
Still I can not distinct which relation has to be one-to-many and which one has to be many-to-many.
Someone told me if both entity tables are independent, they can have a many-to-many relation, else they will have one-to-many.
But now I am working on a project that collects personal information of the employees, in one part there is a table known as JobStatus which is for the personnel's current job. This table has a relationship with Person (table) that is many-to-many, of course there is a junction table between them.
I made this type of relation because one job position's name is assigned to several persons and with different performance.
For instance :
Person A ----->Operator
Person B------>Operator and so on...
And in other side there are some cases that a person has two Job position, I mean he is either a director and a teacher .
For instance :
Person C ------>Director & Teacher
So would you please guide me in this ambiguous logical mean?
Based on the project you described, I would create three tables: employeeTable, jobType, and jobAssignment. Give each employee a unique id (a primary key) and give each job a unique id (primary key) and let the jobAssignment table be the glue that links the employeeTable with the jobAssignment table. The jobAssignment table would have an index on the employeeID and jobID.
jobAssignment
---------------
employeeID (indexed)
jobID (indexed)
employeeTable
---------------
employeeID (primary key)
employeeName
jobType
---------------
jobID (primary key)
jobName
jobDescription
That way, you can keep track of the employees and their respective jobs in the jobAssignment table no matter how many job descriptions are assigned to each employee.
Simply put, you would recognize a many to many when either table can not have the PK from the other table as its foreign key
Taking a Student and Course table
Student can take many courses
Courses can belong to more than one Students
Putting a FK of course (CourseID) on student will restrict the Student to ONE course
Putting a FK of student (StudentID) on course will restrict the course to ONE student
To solve this, a third table StudentCourse will have the StudentID and the CourseID, therefore making either table independent.
That is Many to Many.
For one to many, that happens when you can easily put the ID of one table as the FK of the other.
In your case, Two Employees can be Operator at the same time and an Employee can be an Operator and Teacher - that design is MANY to MANY. You are right