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.
Related
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 created 3 tables for store users, students and examiners.
Users table contain login details
id
name
email
password
user_type (3 user types: 1 - administrators, 2 - students, 3 - examiners)
user_type_id
If user_type == 2 or 3, then based on that value, user_type_id field get
student id or examiner id, if user_type == 1 then value == 0.
students table contain student details
id
name
age
birthday
examiners table contain examiners details
id
name
age
qualifications
my question is, is it ok to use above way to link users, students and examiners?
If not please suggest a way. Thank you.
First of all: your data model needs some improvements.
You put age attribute and birthday attribute in Student. Adding age in database is incorrect. You should use only birthday. Same problem in Examiners.
The best practice for designing data model for Information Systems with Authentication (and Authorization) is to separate them into 2 modules in Data Model. AA module and Other parts of Information System. This separation has som advantages like extendability of your whole system and usabilty of AA in other systems and etc.
Another improvement is to define a new Entity named UserType and use the foreign key in Users entity.
When you use both Student ID and Examiner ID in one attribute in Users entity, your model is not Normal and you can not set foreign keys.
Secondly: To provide a data model
we have relationships between Users and two other entities (Student and Examiners). Maybe in future other entities added to this list.
We have 2 relationships:
one relation between Users and Student and another relation between User and Examiner
These relationships are one-to-one. For example each Student has one User and each User can be set for only one Student. And similar statement between User and Examine.
In one-to-one relationships we have 2 solutions:
1- pass primary key of Entity at side 1 in 1-1 relationship as foreign key to
Entity of side 2.
2- pass primary key of Entity at side 2 in 1-1 relationship as foreign key to
Entity of side 1.
Both solutions are true and Normal. So we have 2 solutions for this case:
Solution 1: transfer User ID as foreign key to both Student and Examiner. In this solution we can easily find each User ID of specific Student or specific Examiner. But the hard part of this solution is finding a Student or Examiner based on User ID. Answer is: Notice that we have User Type for each User ID. So based on User Type of User ID, we know which table to be search (Student or Examiner).
Solution 2: transfer both Student and Examiner IDs as foreign keys into Users. Meaning that User Entity have 2 foreign key. First for Student ID and Second for Examiner ID. This solution seams so effective. But it conflict Modularity of AA Module (Authentication and Authorization Module). Another problem emerge when the number of other tables (Student, Examiner,...) that have relation with User is HIGH. Anyway, in small Information Systems we can use this solution.
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
... ... ...
... ... ...
... ... ...
Is it possible to have the ID of the next generated row (across 2 tables) be unique?
I have 4 tables:
1 for teachers
1 for students
1 for projects
1 for relations
The relations table has 3 foreign keys.
One refers to teachers IDs, one to students IDs and the other to projects IDs
Since a project can be related to teachers but also students at the same time, how do I make sure that a new created teacher or student won't have an ID already used by the other type of account?
If I can do that, then the relations table would have only 3 columns:
ID, project_ID and related_to(ID)
If not, I would have to add a 4th row indicating the type of account that it relates to (student or teacher).
Thanks for your help!
Regarding the difference between account types:
I have to translate this exact same situation to another project of mine in which the first two tables are completely different. That's why I don't bother to merge the students and teachers tables here.
You do not need to have unique values between the student and teacher tables because the relation table has separate fields for each relationship, so there is no conflict.
However, this is not the right way to do things. You need two relation tables, teacher_project and student_project. Alternatively, depending on the unique data that's different between teachers and students, you could have a single person table and a single relationship, which is probably closer to the real world anyway.
I think you can identify the teachers begin with 1 ,incremental 2; the students begin with 2 ,incremental 2.By this way,odd number refers to teacher while even number refers to student.No conflict will happen.
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