So I've volunteer to create a Registering system for my local church's education ministry. It should be able to register new students and keep track of their progress. Here are the requirements I've managed to gather:
The educational institution offers several courses.
Courses have a name and description.
Courses are organized in levels. There are several courses per level.
Courses also have requirements (i.e. other courses that need to be taken first).
A student graduates from a level when it has passed all courses of that level.
If a student cannot pass a course, he may repeat it as many times as he wants/needs.
Students can only take one course per semester.
An inactive student is one that isn't enrolled in the current semester.
Teachers will teach only one course per semester. Teachers may teach a different course each semester.
There could be semesters a teacher doesn't teach.
Now, this is my relational model.
![https://dl.dropbox.com/u/10900918/rmodels.jpg][1]
My questions are:
Are there any tables missing?
Looking at the semester + semester_code_description: is this the best way to do this? Under the assumption that a year has 2 semesters and that each semester have the same start and end months (i.e. semester 1: Aug - Dec, semester 2: Jan - May), is semester_code_description table really necessary?
How could I improve the design?
Sorry I didn't include any arrows. The program I'm using is a mess.
Thanks so much for your valuable time in advance.
1) Nice job on your design. I don't see any missing tables - it looks like you covered all of your requirements.
2) The semester_description table makes sense to me, whether or not you need it depends on whether you plan to do anything with that data.
3) The requirement "students can only take one course per semester" would imply that the Has_Taken relationship's primary key should be (student_id, semester_id). As it stands now, I could insert two different courses for the same student and semester. Similarly for the Has_Teached relationship.
Some other thoughts:
The "last_whatever" columns in some of your tables will force some extra processing on your actual application. You will need some mechanism to monitor/update those. Another option would be to derive them from your tables. I can get a student's last_semester by finding the semester with the max year/code.
One last consideration, how stable are these courses/descriptions/levels? I worked at a university for several years and our courses would change on a semester basis, forcing us to save an entire copy of course records for each change because we want a student's record to reflect what they actually took at that time.
Here's a little example in your app. Let's say I graduated level 1. Then a year later, the church adds a new course (Course A) to level 1. I will effectively be un-graduated b/c now there are level 1 courses I don't have (Course A).
This may not matter to you if your courses are pretty stable. Good luck!
Related
I'm very new in designing professional database system and making a School Management System in Laravel. I have issues setting my database. How to enroll a student. To know the problem, you must have to read requirement once.
Every Classroom can have minimum 1 or maximum many Section.
Every Section has many list of Courses and Students enrolled in.
Every Classroom has Teacher
The database I am thinking for this is
Student (many-to-many forming Registration ) Classroom
Classroom (many-to-many forming Class_Section ) Section
Section (many-to-many forming Section_Courses ) Courses
or
Student (many-to-many forming Registration ) Classroom
Classroom {class_id, section_id(FK)} (one-to-many ) Section
Section {section_id, course_id} (one-to-many ) Course
The thing I need is that when enrolling a student, I want to register him in the ClassRoom and in any section of that classroom.
A Student can see all the courses in that section.
This makes clear that registration should have section id as well. But if I make relation of a section with registration. It will show all sections.
Kindly suggest me a possible way of designing this database. I'm stuck up here and can't find a better option for it.
Mainly there are three types of relations. They are,
1. one to one
2. one to many
3. many to many
Think about every relation from both ways. For example, you have said that,"Every Section has many list of Courses." Now think it in reverse. Can a course be offered in more than one section? If yes, then it should be a many to many relation. Otherwise it should be one to many.
Similarly think about classroom and section relationship. You have said, "Every Classroom can have minimum 1 or maximum many Section". Now think about it in reverse. Can a section have more than one classroom? If it can have more than one classroom then you need many to many. Otherwise, one to many will be ok.
The main point is if it is "one to many" from both sides then you need a many to many relation.
About showing only courses for that section; don't worry about it. First design the database. Laravel handles relations extremely well. In fact, eloquent relationship is very powerful tool. You can also use polymorphic relation and intermediary relation. Try to read about it from documentation.
I need to create a data model for an education based application. The question I want to ask is is it better to make one junction table for two tables with many-to-many relation or create one big junction table to deal with all many-to-many relationships?
Say, I have student, tutor, subject, grade tables.
student and tutor are in many-to-many
tutor and subject are in many-to-many
tutor and grade are also in many-to-many
A student can have many tutors for one subject of one grade.
There can be many tutors for one subject of one grade.
A subject of one grade can be taught by many tutors.
Above are just a few examples of the relationships.
My question is how to model these relationships efficiently? Should I have one junction table for each of the relationships or should I combine them into one big bridge table?
So, if I have a class table as well, then from the big bridge table I can get for which class which tutor taught which subject of what grade along with other details of the class.
Let's assume the database is not yet electronic, but a good old filing cabinet instead.
Let's assume the database is for a library, and there are a couple of distinct sorts of "many-to-many info" to be maintained : authors to books (coauthored books have >1 author), readers to books, readers to readers, book availability in possibly multiple site locations of the library, ...
Would you ever think of stashing all those distinct sorts of information in one big filing cabinet ? Imagine what the consequences are for its users ? Sometimes you'll be prohibited to do something "readers to books" merely because someone else is right there doing something "readers to readers". If and when you manage to gain access and it's finally your turn do so something, say "authors to books", your work will be slowed down because all the "readers to books" stuff might come in between and you'll have to spend extra time merely skipping the unneeded stuff. If a "conversion operation" must be performed, say, a new kind of many-to-many stuff is discovered and must be integrated in the single filing cabinet, the entire database is inaccessible while the conversion operation is being performed (people adding filing cards of a color that wasn't yet in use). Etc. etc. . Those undesirable properties carry over almost 1-1 to the electronic equivalent.
As someone else put it : don't be afraid of tables. It's what a DBMS is good at.
EDIT
Brief : just keep it at one table per fact type, and abstain from making (/trying to discover) geeky abstractions like "they're all just properties" / "they're all just some many-to-many-relation" / ... . They're geeky because an end user/business user will not "see" it. And thus there is no business value in making them.
I'm working since few weeks now on a project really interesting but unfortunately with a very complex background.
I already asked 3 questions :
Class Scheduling to Boolean satisfiability [Polynomial-time reduction] Final Part (here)
Class Scheduling to Boolean satisfiability [Polynomial-time reduction] part 2
Class Scheduling to Boolean satisfiability [Polynomial-time reduction]
in both of them, I get my answer (thank you again #Amit) but now arrived the final part, who will make this project useable :)
I for now can manage :
N time-intervals.
C courses.
T teachers.
S rooms.
My constraints are the follow:
2 teachers cannot be in the same room in the same time.
2 courses cannot be in the same room in the same time.
Teachers can teach only specific courses.
Some courses can happen only on specific time-intervals.
So this is for now, my result :
But here comes the final part that I want to add : I want to manage group of students, with the following constraints :
A group has only some courses to do.
2+ groups can be in the same room in the same time only for specific courses (like Magistral course for example)
Again, I success to isolate the constraint, but I have no idea on how to transform this constraint into a "time-intervals should not overlap" constraint.
Thanks in advance,
Best regards,
Since a student can only be in one place at a time:
Lectures for courses attached to the same student group should not overlap in time.
Edit:
There should be no constraint on different student groups overlapping. If you have such a constraint you should remove it!
The constraints are on courses. If you schdeule a lecture for course A, then it may not overlap a lecture for any other course for the student group(s) that attend course A. It may also not overlap any other course held by the same teacher.
So, you have a many-to-many relationship between students and courses and a many-to-many relationship between teachers and courses.
You want to schedule a number of lectures for each course with the constraint that no teacher and no student has overlapping lectures.
Regarding
2+ groups can be in the same room in the same time only for specific courses (like Magistral course for example)
If the groups may not mix, then it is not the same course (even though the subject may be the same). So if two student groups can not mix for Java, then you need to model it as two separate courses, Java group1 and Java group2.
suppose if i need to take different college details and store courses offered by them into databases.Assume number of courses are different for different colleges.how table should be designed to store courses.
here these courses should be able retrieved for further processing
can any one suggest idea for this..
You can start with 2 tables, 1 for Institution (the university/college), and 1 for Course. The Course table should have a foreign key institution_id to the Institution table.
This way you can have as many courses as you want for any college, and looking up courses for a college is as simple as doing a query on institution_id.
Naturally, this is only a start, you will probably have to expand on this. For example, you might want to have another table like College that has a a foreign key to Institution, to model the fact that sometimes universities have many sub-schools within them. You could also have Institution rows reference other Institution rows to model the same thing; what you want to do depends on the details.
My spider sense is tingling, but I've been thinking about it for 2 hours now and I'd like some more feedback from the hivemind.
I'm creating an application for a school. Its supposed to handle students, teachers, courses, honor roles, grades - the works.
I was wondering how to handle the change of years after each year.
Students move up a grade (or don't).
Teachers are assigned to different grades as their homeroom teacher.
Grades are saved for the year.
There's also the matter of auditing. I need to have an easy way to pull up records from last year or the year before. See what teacher gave which course at what grade at what year.
The problem I'm having is how to handle this.
My thought was to create a new clean database for each year as they come along. So at the end of this year, I'd go to the school and create a new database for them named FooSchool2012 and programatically let the end users change the database they want to use via a connection string.
Since I'm using an ORM it's only a matter of changing the connection string as the databases are the same.
But this reeks of bad design and crappy engineering to me.
Usually my gut is right, so hopefully you guys can let me know of some alternatives on how to handle this.
No, I would not create a new table or database for each year. It breaks first normal form. Every table will be a duplicate except for the name. It's a poor design. And a maintenance headache. Who's going to create the new database, load the schema, and then change all the URLs? If you change the schema after a few years, will you have to change all the back editions as well so people can query the historical data?
Nope, not a good design at all.
It's common to move historical information out into reporting/data warehousing databases. But the scheme you're suggesting is reminiscent of old, mainframe, VSAM flat file methodologies. I'd use relational databases the way they were intended to be used.
I'm sure your solution could be made workable, but it does seem a little needlessly complicated. Couldn't you accomplish the same thing in a single database by referencing the school year? You may want to think about which entities make sense to have "effective dates" (i.e., a start and an end time). The 3rd grade teacher may change mid year, for example, but you could handle that with effective dates.
My thought was to create a new clean
database for each year
If you thought about this for two hours, and your best idea was to create a new database for each year, you're the wrong person to design this database.
That's an observation, not a criticism. You just need to learn a lot more of the fundamentals before you tackle a project like this one. You'll just get frustrated, and the school will suffer.
You need to spend A LOT of time on your database design. Think about maintenance in the long run, it needs to be as easy as possible. The best way is to create a relational database, research bridge,validation, and base tables. To answer your question, I would not do a table for every year. The best way is having the student grade data mapped to a specific unique id representing that student's specific course ID.
I would think about creating a table for each of the nouns:
instructor - PK instructorID,instructorName..
(any other 1:1 instructor information)
Student - PK studentID,StudentName..
(any other 1:1 student information)
Course - PK CourseID, CourseName, CourseDescription..
(any other 1:1 course information)
•Teachers are assigned to different grades as their homeroom teacher.
on the 1:1 instructor table you could have a column called HomeroomGrade and then you
update that column with the current grade. If you wanted to keep a history of the grade
you could have the instructor table be a composite key with another column incrementing up
for the current record.
•Students move up a grade (or don't).
You will need another table showing the relationship of students to a unique courses
grades for that year, but first you need to map the instructor to that specific course.
PK InstructorToCourseID
InstructorID - FK
CourseID - FK
Year - FK
then yet another table mapping the unique course to that student with the grade..
PK InstructorToCourseID FK from previous table
PK StudentID - FK from student information table
Grade
Sorry if im general and vague, but this should give you some ideas on the relationships that can be created.