im new to mysql, and my first project would be to create a database of students-classes scenario.
i have decided to make a table "students" then thought each student could possibly be a member of one or more classes, so in my mind there would be a column in the students table that says "classes" now what data type would be appropriate for that? a class would consist of a string for name, then schedule (MTh, 10:30-11:30). Or should i instead just make a "classes" table then one of the columns would contain all the names of the students that belong to that class, then what data type should be used for a long "list"-like strings?
Each class can have many students, and each student can have many classes. Therefore your dilemma is whether to record the students in the classes table, or the classes in the students table.
In a relational database, you should have three tables:
one table for students;
one table for classes;
one table that has the pairings: one row each for one student being a member of one class.
It's far more flexible and general-purpose to do it this way.
See also my answer to Is storing a delimited list in a database column really that bad?
Related
I have the below UML class diagram with Abstract Class, and sub-Classes that extends from it. and i want to make an ER diagram using this class diagram.
My question is how can i represent the Abstract class in ER diagram ? as a Table ? or should i just ignore it ?
Thank you.
There are basically three choices to translate generalization into a database model
1. One table per concrete class
Create tables Admin, Teacher and Student. Each of these table contain columns for all of the attributes and relations of User
Pro
All fields of a concrete subclass are in the same table, so no join needed to get all Student data
Easy data validation constraints (such as mandatory fields for Student)
Con
All fields of User are duplicated in each subclass table
Foreign keys to User have to be split into three FK fields. One for Admin, one for Teacher and one for Student.
2. On table for whole generalization set
In this case you just have one table call User that contains all fields of User + all fields of all sub-classes of User
Pro
All fields are in the same table, so no join needed to get all User data
No splitting of FK's to User
Con
There are a bunch of fields that are never used. All fields specific for Student and Teacher are never filled in for Admins and vice versa
Data validation such as mandatory fields for a concrete class such as Student become rather complex as it is no longer a simple Not Null constraint.
3. One table per concrete class, and one for the superclass
In this case you create tables for each of the concrete sub-classes and you create a table for the class User. Each of the concrete sub-class tables has a mandatory FK to User
Pro
Most normalized schema: No repeated fields for the attributes of user, and no unused fields.
No splitting of FK's to User
Easy data validation constraints (such as mandatory fields for Student)
Con
You have to query two tables if you want all data of a Student
Complex validation rules to make sure each User record has exactly one Admin, Teacher or Student record.
Which one of these options you choose depends on a number of things such as the number of sub-classes, the number of attributes in either subclass or superclass, the number of FK's to the superclass, and probably a few other things I didn't think about.
Suppose I have a table called "student" with a single column "name". And I want to store a second attribute called "group". "group" will be a value calculated from the name, and different names can be in the same group. So each name has a group and a group can have many names. This could be easily modeled in a normalised schema by creating a second table called "group" and adding a fk column to "student" that points to "group". However, suppose now that I can only calculate a student's group some time after they have registered. So I need to be able to enter a student without knowing their group. With this schema, I'll either have to use null fk's, or not add the student.
Apologies if I'm missing the obvious, I'm somewhat new to normalisation. What I have considered is using an associative table with a fk for group and a fk for student. This would allow me to enter students without knowing their groups and then linking them to their groups via the associative table at a later stage. But from what I've read on associative tables, you're meant to use them for deconstructing many-to-many relationships. And this is a one-to-many relationship. So I'm confused. Is there a standard way of normalising such a many-to-one relationship where the value can only be calculated later?
A pretty common way to solve this is just to have a "no group" record in the groups table. All students start off mapped to that record and then you update the foreign key when they are assigned to a group.
I'm currently working on a project, the admin of the application must be able to add/edit these information.
Class(className)
Teacher(teacherName,teacherInfo,teacherPicture,teacherEmail)
Practice(practiceName,practiceDate,practiceDescription,practiceDocs)
I tried making 3 tables of which the class would be the relational table containing the keys of teacher and practice, but that way I can't add only the subject without teachers and practices or add a Teacher and then afterwards assign him a class, or remove him from a class. So my question is how would I go about doing this or if you could point me to some good read for this problem.
If I understood it right, you have a practices table, a teachers table and a classes table, with relation fields put directly on those tables.
For you to be able to create teachers, classes and practices individually, you must take that relationship fields out and put the relations into separate tables.
So, instead of having, for example, a classes table with a teacher field, have a classes table without any field related to the teacher and another separate table classes_teachers where you'd have a unique identifier for the association, the id of the teacher and the id of the class.
The type of relationship your current schema provides is called a 1 by n relationship.
The kind of relationship you need is a n by n relationship.
This question already has answers here:
Should junction tables have more than one primary keys from another identifying table?
(4 answers)
Closed 7 years ago.
I have two tables that I need to connect: discipline and class.
It will be a N:N relation, so I'll create a new table class_discipline.
Does my pivot table class_discipline may have more fields than just the Ids of the two tables ? Is it a good practice ?
If yes, is there some kind of rule that I should follow to do such a thing ?
Let me explain the situation: I'll import some data from an excel file, I can't change the data of this file (My university provides it).
And this file have some data that does not fit neither on discipline or class tables. So I guess I should insert this "extra data" into the pivot table.
Your table class_discipline can have as many columns as you want.
Generally any column in that junction table represents an attribute of the relationship. In this case if a relationship between class ad discipline needs any specification then yes, use more columns.
Example:
Assume you have tables students and courses. And to define who is enrolled in which course, you will create student_course table containing only student_id and course_id. But if you want to know when a student enrolled, you need to save this information somewhere (it's not an attribute of a student nor course). That's the time for adding new column into student_course table.
Good or bad practice?
Using additional columns in a junction table for attributes of the relationship is a good practice normally. However you need to keep in mind that you lose the column values if the relationship is removed.
Additional comments:
If you are using such structure in an application or via ORM, note that plain N:N relationship is a field of a class. Once you need more attributes of the relationship you need to have a separate class.
I have two type of user in my master table Doctor and Hospital both user has common fields like Name,Address,Contacts etc.
But there are some different fields which is connected by foreign key to this table
Like for Doctor it has
one to one relation with specialization and department table
and for Hospital
has one to one with service and one to many with facilities table
Now my question is What should be the database schema for this type of relation, At present I made separate table for both Doctor and Hospital but the fields like Name,Contact and Adreess repeating in both table.
It sounds like Doctor and Hospital are both subclasses of some superclass, and the fields that repeat in both of them are attributes of that superclass. Do some google searches with either of these two search terms: "Generalization/Specialization" or "Class Table Inheritance". That second term will show you some specific designs for implementing subtypes or subclasses in relational tables.
You might want to ask the question of in the Database Administrators area. There is a tag called "subtypes" over there with one question in it. It's asking the same thing you are, in a different case.