I am working on a Class Registration database design. Courses have multiple sections. Each section is offered at a certain time. For example, a section's times are MWF 9-9:50 and another section's time are TTH 2:30-3:45. To handle this requirement, I decided to create a timeslot table and now I would have many-many relationship between section and timeslot
course(id(PK), course_no, credits, title, description)
section(id(PK),section_no,course_id(FK),instructor_id)
timeslot(id(PK),day,start_time,end_time)
section_times(section_id(PK,FK),timeslot_id(PK,FK))
Is this how it should be handled?
Thanks,
Nishant
That looks fine.
Some things you might need to think about:
Some constraints
The classroom assignment might need to be stored and there might be a question of whether the classroom is on a section basis or section_times basis
Are there exceptions (i.e. a holiday on a Thursday or some other kind of exception where just one class is rescheduled) where you want the database to fully represent the real world?
If there are multiple instructors or assistants, you need to refactor that out from the section to a section_instructor table (this turns out to be more important for scheduling the teaching resources than for information for the students)
Related
First off, I did read this post What is a good database design (schema) for a attendance database? but it doesn't fit my needs and I'm struggling to adapt it to my scenario.
I will try to explain in brief.
Let's take a school (sort of):
School has courses with a starting and an ending date
Students can be "subscribed" to multiple courses
A subscription doesn't necessary start from the beginning nor ending at the end of the course.
The student can be attended punctually (independently of the subscription) or transferred punctually in an another course.
I came with this design in mind:
My idea:
When transferring punctually a student, I can change the course_id
I can create an attendee without subscription_id, on demand
My problem:
With this design, It's seems over complicated and to see who's coming to a course, I see only two solutions.
Count the number of subscription, add the number of attendees present, remove the number of attendees absent.
Use a queue worker to create all the attendees and count the number of present attendee.
What would it be the easier way or what better schema could I use?
If I have a list of theatres and in each theatre there are several classes of tickets eg. Rs.120, Rs.100 etc. These classes will apply for morning, noon and night shows. So all the classes of tickets will be available for all the shows(Many to Many Relationship) I need to model this as a database. I have a problem in modelling the classes and show timings. This makes the data base redundant.
Input Excel data
A good rule of thumb, is when you hit redundant data, make a new table.
Here is how I would break it down, though you could break it down further (also see a term normalize):
Tables:
theater_tbl
ticket_tbl
classes_tbl
relate each ticket to a class, and each theater may sell one or more tickets of any given class.
Information like address of theater go with theater_tbl
Ticket pricing would go in the ticket table under the type of ticket, unless I misunderstand what a class of ticket is, then the pricing should go there.
The time of day a ticket relates to should go in the ticket table.
This should get you started. To go further, you could break down show times into another table, and relate classes/tickets to those show times.
Its hard to draw out without a solid example.
I'm creating a messaging system for a e-learning platform and there are some design concerns that I'd like some feedback on.
First of all, it is important for me and my system to be highly modifiable in the future. As such, maintaining a fairly high normalization across my tables is important.
On to how my system will work:
All members (students or teachers) are part of a virtual classroom.
Teachers can create tasks and exercises in these classrooms and assign them to one or multiple students (member_task table not illustrated).
A student can request help for a specific task or exercise by sending a message to the teachers of the classroom.
Messages sent by students are sent to all the teachers. They cannot address a message to a specific teacher.
Messages sent by teachers can be addressed to one or more students.
Students cannot send messages to other students.
Messages behave like chat, meaning that a private conversation starts between a student and all teachers when they send a message.
Here's the ER diagram I made:
So my question is, is this table normalized properly for my purpose? Is there anything that can be done to reduce redundancy of data across my tables? And out of curiosity, is it in BCNF?
Another question: I don't intend to ever implement delete features anywhere in my system. Only "archiving" where said classroom/task/member/message/whatever is simply hidden/deactivated. So is there any reason to actually use FK?
EDIT: Also, a friend brought to my attention that the Conversations table might be redundant, and it kinda feels so. Thoughts?
Thanks.
In response to your emphasis on "modifiability" which I'm taking to mean with respect to application and schema evolution I'm actually going to suggest a fairly extreme solution. Before that some notes some aspects you've mentioned. First, foreign keys represent meaningful constraints in your data. They should always be defined and enforced. Foreign keys are not there just for cascading delete. Second, the Conversations table is arguably redundant. It would make sense if you had a notion of "session" of chat which would correspond to a Conversation. Otherwise, you just have a bunch of messages throughout time. The Conversation table could also enable a many-to-many relation between messages and tasks/exercises if you wanted to have chats that simultaneously covered multiple exercises, for example.
Now for the extreme suggestion. You could use 6NF. In particular, you might look at its incarnation in anchor modeling. The most notable difference in this approach is each attribute is modeled as a different table. 6NF supports temporal databases (supported in anchor modeling via "historized" attributes/ties). This means handling situations like a student being associated to a task now but not later won't cause all their messages to disappear. Most relevant to you, all schema modifications are non-destructive and additive, so no old code breaks when you make a change.
There are downsides. First, it's a bit weird, and in particular anchor modeling (somewhat gratuitously?) introduces a bunch of new terms. Second, it produces weird queries for most relational databases which they may not optimize well. This can sometimes be resolved with materialized views. Third, at the physical level, every attribute is effectively nullable. Finally, the tooling and support, while present, is pretty young. In particular, for MySQL, you may only be "inspired by" what's provided on the anchor modeling site.
As far as the actual database model would go, it would look roughly similar. Anchor modeling uses the term "anchor" for roughly the same thing as an entity, and "tie" for roughly the same thing as a relation. For simplicity, dropping the Conversation relation (and thus directly connecting Message to Task), the image would be similar: you'd have an anchor for Classroom, Member, Message, and Task, and a tie replacing Recipient that you might called ReceivedMessage representing the relation of "member received message message". The attributes on your entities would be attribute nodes. Making the message attribute on the Message anchor historized would allow messages to be edited if desired and support a history of revisions.
One concern I have is that I don't see a Users table which will hold all the students and teachers info (login, email, system id, role, etc) but I assume there is something similar in our system?
Now, looking into the Members table: usually students change classes every semester or so and you don't want last semesters' students to receive new messages. I would suggest the following:
Members
=============
PK member_id
FK class_id
FK user_id
--------------
join_date
leave_date
active
role
The last two fields might be redundant:
active: is an alternative solution if you want to avoid using dates. This will become false when a user stops being member of this class. Since there is not delete feature, the Members entry has to be preserved for archive purposes (and historical log).
role: Depends on how you setup Users table and roles in your system. If a user entry has role field(s) then this is not needed. However, this field allows for the same user to assume different roles in different classes. Example: a 3rd year student, who was a member of this class 2 years ago, is now working as TA/LA (teaching/lab assistant) for the same class. This depends on how the institution works... in my BSc we had the "rule": anyone with grade > 8.5/10 in Java could volunteer to do workshops to other students (using uni's labs). Finally, this field if used as a mask or a constant, allows for roles to be extended (future-proof)
As for FKs I will always suggest using them for data consistency. Things can get really ugly really fast without FKs. The limitations they impose can be worked around and they are usually needed: What is the purpose of archiving a message with sender_id if the sender has been deleted by accident? Also, note that in most systems FKs are indexed which improves the performance of queries/joins.
Hope the above helps and not confuse things :)
I am building a student database for a high school. I have been able to solve most of my problems with the exception of one.
The tables I currently have are for records of the current school term. I am trying to find a way to permanently keep records for the first term, second term, third term and even after the student graduates. Student information will still be stored in the database permanently.
Please can anyone give me an idea of how I should build it?
Add a field "Term", where you write the term, which this record is for.
I think the most logical way is to have Year (calendar year) and Term (semester term: Spring, Summer, Fall) fields associated to each student. This way you could fully distinguish attendance by either calendar year or term. For graduation status you could add either graduation flag or graduation date, or both.
ADDED:
In response to comment below. Yes, I think it does make more sense to track prospective students and enrolled academic students separately. You either can track those in a stand along table or implement additional fields to the existing table. As an example, you could have a field person_status as enrolled, graduated, prospective.
Your ultimate structure really depends on what level of detail you try to achieve.
My question is more of trying to understand what and how I can get something done. Here's the thing:
I got a job to build this application for a school to manage student bio data, work-out and handle student information and basic finance management.
Based on requirements I got from meets with my client, I have an ERD of a proposed MySQL Database with 23 different tables. The one part I would like to understand quickly is displaying data based on school terms. There are 3 terms in a year, each with its own summaries at the end of each term. At the end of 3 terms, a year has gone by and a student is promoted or demoted.
So my question is, how can I render my data to show 3 different terms and also to create a new year working out how to either promote a student or make the student repeat the class its in?
23 different tables? I'd like to see that model.
I don't think you should have one table per term. You'll have to keep adding tables every term, every year.
Sounds like a transcript table should have term and year columns that are incremented or decremented as a student progresses through. It should also have a foreign key relationship with its student: it's a 1:1 between a student and their transcript.
I would have a separate transcript table because I'd prefer keeping it separate from basic personal information about a student. A transcript would refer to the courses taken each term, the grade received for each, and calculate overall progress. If I queried for the transcript for an individual student, I should be able to see every year, every term, every course, every grade in reverse chronological order.