I have 3 entities: Tutors, Students, Courses
Tutors teach many courses
Students can be assigned to many courses that are taught by many tutors
Tutors and students need to be able to log into the system
I would like to represent this design using the following tables:
users
- id
- username
- password
- first_name
- last_name
- email
- password
- phone
- role_id (Student or Tutor or Admin)
- created
- modified
roles (Student, Tutor)
- id
- name
- created
- modified
courses (The courses that Tutors can teach and that Students can be assigned to)
- id
- name
- created
- modified
users_courses
- id
- user_id
- course_id
- created
- modified
The problem I have with the above design (users_courses table) is that, let's say we have Tutor A and Tutor B that teach Math. If student X is registered to that math course we can't know if student X is being tutored by Tutor A or Tutor B.
I would really like to be able to use a single users table to keep all the users to make things simple.
Any advice please?
The problem is that you want to handle students and teachers differently (students enroll in a course taught by a specific teacher) but you modeled them the same (they're just users).
Instead of roles, create subtypes of users. Create tables for teachers and students - you can reuse the primary keys from users, but you'll be able to handle subtype-specific attributes and relationships.
While it's possible to get away with only those entity sets, I suggest you add the concept of a section as well. It has different names in different systems or parts of the world, but most school systems I've seen have something like it to represent a partition of a course's students with an associated teacher.
users
- id PK
- username
- password
- first_name
- last_name
- email
- password
- phone
- created
- modified
students
- user_id PK FK
teachers
- user_id PK FK
courses
- id PK
- name
- created
- modified
sections
- section_id PK
- teacher_id FK
- course_id FK
- created
- modified
students_sections
- student_id PK FK
- section_id PK FK
- created
- modified
In a real world system, you'll also need to take time into account - students and teachers normally attend different courses in different years or semesters.
I would simply add the “tutor” to the courses table since it’s essential element for a course to know whose is teaching it/tutor.
Then use either the users table or user_courses to join/match and pull the info you want.
**Courses**
- id
- name
-tutorID
- created
- modified
Related
I am trying to register some users with basic details like username/email, password and their respective hobbies like reading, sports, dance etc and later on display users with similar hobbies. The current schema looks something like this.
Users
- id
- email
- password
- country
- hobbies_id
hobbies
- id
- user_id
- sports(values true/false)
- reading(values true/false)
- dance(values true/false)
Each hobby is placed as a column in hobbies table.
What will be the most optimized schema if I increase the number of hobbies from 3 to 20?
Also, can someone help me with a query to select users with similar hobbies/hobby? For example, if John likes reading and sports, and Kim likes sports and dance then they have sports as a common hobby.
Thanks in advance.
Following up on comments by #Madhur Bhaiya, I would adress this with 3 tables:
users
- id
- email
- password
- country
hobbies
- id
- name (sports, reading, dance, ...)
user_hobbies
- user_id
- hobbie_id
The users table is the master table for users (one record per user).
The hobbies table is the master table for hobbies (one record per hobby). When new hobbies are created, you do not need to create new columns, just add new rows.
The user_hobbies table maps users to hobbies: it contains one record for each user_id/hobbie_id tuple.
we can do with two solution ::
#GMB's solution
removed hobby table and save hobby data into user table only, in json data-type.
For this, I would recommend looking into Database Normalization. This issue should be solved by implementing the Third Normal Form (TNF). For this, you should remove hobby_id from the users table and remove user_id from the hobbies table. A normalized example of one solution to this problem would be to create a new table that uses user_id and hobby_id as a Composite Key. See below:
users:
- id
- email
- password
- country
user_hobby:
- user_id
- hobby_id
hobbies:
- id
- description
- type
In this situation, the user_hobby table would have a many to many relationship between users and hobbies. If a user has multiple hobbies, they will have multiple hobbies linked to their id in the user_hobby table, but each user and hobby should be listed only once in their respective tables.
I want to create a form for dataentry in access. I am confused about defining the tables. I have a Student table, which includes information about student first name, last name, etc.
I have information about technical skills which has different groups (6 groups) programming, languages,banking, etc. Each group has different parts: for example, Programming has 4 parts JAVA, PHP, C, Python.
Languages also have different parts English, German, Spanish, French
Banking has these parts: Risk Management, Project Management
Each student has different skills; first student knows Java, php, German, Project Management
How many tables should I define and how go I relate them to the main Student table?
I would go with the following structure:
tblStudent
ID (PK)
FirstName
LastName
tblStudent_Skill
Student_ID (PK)(FK)
Skill_ID (PK)(FK)
tblSkill
ID (PK)
SkillName
SkillType_ID (FK)
tblSkillType
ID (PK)
SkillTypeName
tblStudent - only information relating to this specific person, name, address, phone, etc.
tblStudent_Skill - linking table to deal with many-many relationship between tblStudent and tblSkill.
tblSkill - specific skills, for example PHP, English, Python, Maths, etc.
tblSkillType - category list for Skills, for example programming, languages,banking, etc.
Im making a system for a school and I have this mySQL tables. The names are self explanatory:
student: id name course_id
course: id name
subject: id name
subject_course: id subject_id course_id
grade: id type grade
grade_type: id name
I need to check if every student of a certain course has a grade of type X on every subject that is related with that course.
Let's say grade_type = 'written test'. So I need to check if every student of 1st grade has a grade on the written test on EVERY subject related to first grade (example: math, spanish, history, etc). If yes, I do some stuff. If not, another.
Is there a query that can check that? I was thinking on check student by student but I think is less efficient.
This schema doesn't seem to make sense.
Why would course_id be field on student table? My guess is you need a student_course table to represent a many-to-many relationship between students and courses here.
Also, the grade_type table seems kind of trivial and extra overhead with little value. Could type not just be an enum on grade table?
Considering this ER diagram
we have Students who are admitted to participate in an Exam, and each Exam can be split up into multiple Runs (for example, to split up large groups across multiple rooms or to have two Runs for the same Exam in direct succession).
Is it possible to ensure (via database constraints) that Students participate only in Runs that belong to Exams they are admitted to?
I couldn't find a way on my own and also don't know how to phrase this for an internet search.
You have these tables and columns:
exam: id, name
student: id, name
run: id, exam_id (foreign key to exam.id), when (timestamp), room
You need a new intersection table to keep track of what exam is being taken by which student:
int_exam_to_student: exam_id, student_id - both foreign keys
Now, you can query this to determine what runs a student is allowed to be in:
select run.* from run join int_exam_to_student i on (run.exam_id = i.exam_id) where i.student_id = 123;
I am new to database structure and design. Currently, I am in the process of creating a course catalog that will match course description according to course name and date. I have sketched one table describing the courses, which include course_code, name and every other relevant information. Then I sketched another table linking those courses to when they will be taught.
I am missing classes that are classified as all_year. Also I am missing a way how to label the courses under a major. Since hypothetically a course can belong to several majors, putting the data from one into the other would force you to duplicate data. Any ideas how I would implement this two things to my tables design? Or suggestion in how to restructure my design. If possible please show me a query to execute in my phpmyadmin DB.
Example of table courses
id serial
course_code text
description text
Example of table course_dates
id serial
course_id serial
year date
semester
Example of table majors
major_id int
course_id int
So a populated database could contain the following:
Table courses
id course_code description
1 INF1000 "Basic programming"
2 INF1001 "More basic programming"
Table course_dates (0 for spring 1 for fall)
id course_id year semester
1 1 2012 0
2 1 2013 1
3 2 2013 1
To link courses to majors - this is a one to many relationship (one course to many majors) - you want to use a linking table that has this type of structure:
table courses_majors
major_id int
course_id int
Remember to index this table as well - its very important. Then you can populate it and have one course even go to many majors and many course to one major (many to many relationship).
Then you can run a join on the tables across this table:
select * from courses left join courses_majors on courses.id = courses_majors.course_id left join majors on courses_majors.majors_id = majors.id
Of course you can add a where clause, etc.
The other way is to create a table of majors:
majors
id int
name varchar
Then add a major_id to your courses table - this will just give you a one to one relationship from courses to majors, but many courses can join a major.
As for Yearly, I would just add a field in the database to account for this, probably a tiny int and just make it 0 or 1.