I am trying to model a database, I have designed an ED diagram, do I need to add any more tables to meet the requirements below?
An academic staff may teach many courses
A course must be taught by one or more academic staff
Courses and enrollments must be managed by one or more admin staff
A student can enroll in one or more courses
A grade must correspond to an enrollment
A student may have multiple enrollments in the same course
Here is my current design
You are not satisfying the following rules, notice the "or more":
A course must be taught by one or more academic staff
Courses and enrollments must be managed by one or more admin staff
The following depends on whether you have defined a unique key constraint (which is not visible from the graph)
A student may have multiple enrollments in the same course
Related
I am designing a database for school management.
Here instead of a single school, there are multiple schools with their own students, classes, teachers and subjects.
Here is the requirements.
• A school can have many classes
• A class can have many sub classes
• Many Students can belong to a section of a class
• Many Teacher can belong to a section of a class
• Many Subjects can belongs to a section of a class
• School wants to manage classes
• School wants to manage sections
• School wants to manage subjects in a section of a class
• School wants to assign a teacher for a subject in a section of a class
• School can assign a student a section of a class
Also, some school can have classes as named One, Two, Three and Some may have First, Second and Third. Also same for sections or sub classes
For entities School and Teacher things are straight forward. Below is my approach for them.
School
--------------
id
name
...
Teacher
--------------
id
school_id
name
But I am facing problem while mapping classes and sections for a school.
I tried to make two other entities classes and sections and give them a foreign key of the school
SchoolClass
-----------------
school_id
class_name
...
SchoolSection
----------------
school_id
section_name
...
For mapping a school's class to all its section I created a junction table, as it will be many to many relationship.
SchoolClassSection
---------------------------------------------------------
school_class_id
school_section_id
But as I mentioned above I also need to add subjects and teachers to a section of the class so tried something like below.
SchoolClassSections
---------------------------------------------------------
school_class_id
school_section_id
subject_id
teacher_id
But now I ended up having four foreign keys in the junction table.
Is there no issues in having more than two foreign keys in a junciton table?
Also, I need to add students too, but I can't now figure it out How to move further for students relation for classes, sections?
One thing I could thing of like below
student
-----------
school_id
school_class_section_id // but if SchoolClassSections can have subject_id and teacher_id too it will become confusing
No, it is not an "antipattern". There are many examples where a junction table might have more than two foreign keys:
A doctor's appointment might have a doctor, a patient, and a clinic.
A retail order might have a customer, a location, and a payment type.
An online subscription might have a customer id, product, payment type, and source.
Those are just some examples from other domains (and they do not even include a date dimension). It is not uncommon for a table to have multiple foreign keys.
I didn't analyze your schema, due to time constaints here.
But there's no problem from either the relational point of view or the SQL point of view with a table or junction table having more than two foreign keys. In fact, that's pretty common.
Some concepts, especially OO concepts, do not fit well with SQL.
SQL has "only":
1:1 relationships (generally this should not be used)
1:many (implement via a link in one table to the other)
many:many (requires a separate 'junction' table)
In each case "1" can degenerate to "0" and "many" can degenerate to "1" or "0". Usually "0" is not represented explicitly but by the absence of rows.
To create schemas:
Think of what "entity" tables to have. (Student, Class, School, etc.)
Create relations, thinking in terms of 1:many and many:many.
Optionally, establish FOREIGN KEYs for the links. (For referential integrity; implicitly creates an INDEX)
Make sure the appropriate columns are INDEXed. (For performance)
Later...
Write the SELECTs, UPDATEs, etc.
Use those queries to decide whether other indexes are needed.
Your question is mainly about the many:many tables.
The basic many:many table has exactly 2 column (links to two other tables)
The basic has two composite indexes (PRIMARY KEY(a,b) and INDEX(b,a))
Sure, make it many:many:many (Not common, but reasonable)
Add columns for attributes about the relations (also not common, but OK)
Add composite indexes for the queries that depend on those attributes (for performance)
More discussion of many:many: http://mysql.rjweb.org/doc.php/index_cookbook_mysql#many_to_many_mapping_table
I currently am trying to work out how to create a relational database for a University Module Options form. First you enter your student ID, Name, Surname and select your degree programme e.g. Human Resource Management then choose multiple modules through the form using checkboxes until the total credits for each semester for each programme is chosen.
However in choosing multiple modules and in being a relational database design i am unsure of how to store these multiple answers in the Student Options table as shown below.
I currently have the tables of
Table: Student
Field Names:
Student ID (primary key)
Name
Surname
Table: Programme
Programme (primary key)
Semester 1 Credits (different programmes allow different amount of credits )
Semester 2 Credits (different programmes allow different amount of credits )
Table: Module
Module ID (primary key)
Module Name
Credits
Prerequisite
The last table is one i am struggling with as after the modules are chosen from the form they will be stored in this table and currently have this...
Table: Student Options
Student ID (primary key)
Programme (link to programme table)
However i am unsure what fields to have to store them in without being too cluttered and still having a link to the modules table as shown below which are all stored individually.
Does my modules table need to have a relationship link to the student options table to be a relational database ?
How would i store the multiple modules chosen into the student options form?
Thanks
As for your core problem, I think the database design outlined below should be sufficient:
You should not store both, the modules a student selects and the programme he is enrolled in in the same table. Instead do it like outlined above.
The programme a student is enrolled in should just be a foreign key in the student table, therefore giving you a one-to-many-relation (This is a crucial point though, because this means any one student can only be enrolled in one programme! If your database has to be able to have one student be enrolled in more than one programme, you need a many-to-many-relation there too.).
The modules should be related to a student via a middle table (I called it StudentModule in this case), therefore giving you the desired many-to-many-relation. What you now have to do of course is check via code, if the module isn't already selected by the student (as well as all the other small and big details there are...). But this you would have to do with any database design as far as I know.
As you can see, I also inserted a middle table for the module to programme relation. This is because I assume that one module is eligible for multiple programmes. By relating modules to programmes in this way, you can then check for stuff like "can this student elect this module", ...
I have three tables,
student, studentclass , class
student have sid as primary key, class have cid as primary key.
studentclass ties student and class together and has two columns, sid,cid (no special keys).
Is it possible to get rid of studentclass table and use student and class tables only, without creating duplicate entries in student or in class tables?
(class can have multiple students and student can attend multiple classes)
Thanks.
If the business logic states that, one student can attend multiple classes then it is good to have a linking table, StudentClass.
You can think of this as a Many to Many relationship where one student can attend multiple classes and one class can have multiple students.
The studentclass table is required assuming that students attend more than one class.
If they do not you can simply add a classId field into the students table and get rid of the studentclass table.
Without the explicit columns, and having previously written a college registration system many moons ago, here are some of the tables that I had implemented.
Student - obvious, list of students, primary information, etc
ClassCategory - Generic categories... (ENG)English, (MTH)Math, (SCI)Science, etc, not the specific class level, but the categories
ClassCourse - These are the things that would be found in a syllabus.. ENG-101, MTH-210, etc. This would have the common information describing what the class was about, not who was teaching, credit hours, etc but the material covered, maybe any pre-requisites, basic syllabus for someone to review content.
Semester - List of semesters, such as Winter-2013, Spring-2014, etc.
Facility - List of facility locations that a given class would be taught -- could be buildings, campus, etc
Teacher - list of teachers, there contact information, whatever, regardless of specific classes they might teach.
ClassOffering - Here is where all the courses would be, when offered, etc and would have its own PK ID, but also the ClassCourse, Semester offered, Facility, teacher and specific room and times. You could have the same "ENG-101" course offered 5 times in a day for day and evening classes by different teachers and time slots.
StudentClasses - This is what you are currently at. This would have which student and which specific class OFFERING they enrolled in. Additionally, at this record you could have a drop, withdrawn status, etc and what other settings may be specific, such as credits attempted, earned, final grade, date completion, etc... This table would be the basis of computing GPA for a student.
EACH of these tables would have their own respective "PKID" values and each table SHOULD have their own.
Although this is not an obvious complete database, but it hopefully can lead you to a better consideration of what you may need to consider.
Trying to implement an ER model where I have entities:teacher,student,papers and relationship: publishes,advises. Both teacher and student can publish a paper but only a teacher can advise a paper. Should I duplicate publishes relationship for both student and teacher or can I make it look like a three-way relationship with having no relationship between teacher and student?
It sounds like you could model it like:
student(student_id, name, etc)
teacher(teacher_id, name, etc)
paper(paper_id, title, text, etc)
contributor(contributor_id, paper_id, contribution_type, contributor_type)
Where contribution type is an enum(publisher,adviser) and similarly contributor type is an enum(teacher,student)... or booleans is_publisher, is_adviser.
The drawback is that this doesn't permit foreign keys from contributor to student/teacher, and you don't have a rigid constraint from advisers to teachers. A table adviser(teacher_id, paper_id) allows a constraint on the advisers, but still doesn't allow constraints or foreign keys on student ids.
Another options might be to break it up as:
teacher_contribution(teacher_id, paper_id, is_adviser)
student_contribution(student_id, paper_id)
which would allow completely constraining the database to the intended model, but could be more difficult to query in some situations.
Any are acceptable. It depends to some extent on your particular application and how you intend to query the data.
I have the following relationships (Business rules):
User_Company : Many-to-many (multiple companies per user, multiple users per company)
Ownership : One-to-One (For each entry in relationship table, it specifies whether user is an owner or employee. If owner then a percentage must be there)
Company_ownership : One-to-many for company (Recursive relationship), as another company can also be an owner in a company, percentage must be given.
So ownership or a company can be made up of a number of companies and users.
So I have developed the following:
So does there have to be at least 4 tables for this sort of relationship or can it be simplified.
I feel it is quite complicated and would not be intuitive for another developer? How could it be optimized and elegantly arranged?
I think ownership and employment are different concepts, that would be more advised to have them separated.
Think about John who is one of the owners of A company and in the mean time he is the CTO of A.
Company and People can have a base to reduce redundancy of entities.
Based on the suggestions of Thilo
A separate relationship table was created for owners and employees respectively.
Furthermore, the company_ownership and ownership tables were removed as having a company as an owner is solved by adding an owning_user_id and owning_company_id where one will always be null. The percentage figure is added to this relationship table.
See below: