I am currently designing a database in mariaDb that will be used in a Meteor app (woth sequelize orm) for tracking the attendance of students in a school.
I'm not sure is the most effective way as there are few exceptions on my case:
teachers can move and reorganise their schedule as they please, and also because the student pay for each lesson (and certain type of absence), I can't use a "exclusion way" (eg only record absence, so no record = present)
the most important query needed is attendance per student, and I need to have it every time I open my app for every student.
second most important is a monthly attendance per teacher. (This one is needed on demand)
(not db related) I need to track the students presence by groups of 10 (every lessons they have to pay again)
The estimated starting size is 20 teachers, 250 students, 500 attendance/week, (every student has two lessons) 37 weeks,( max size double students and lessons).
Is running 250 queries (find) on a 20000row table time consuming?
Is on student table having a lesson_counter field that is updated every time an attendance is recorded a good idea?
Many thanks!
UPDATE:
there is a possible optimization to be made? This should represent a base for a possible email and invoice system both towards students and teachers
There are many possible improvements to your design. Let me start by answering your specific questions:
Is running 250 queries (find) on a 20000row table time consuming?
No. On modern hardware, querying 20.000 rows is going to be fast. If you have a decent indexing strategy, the queries should return in 10s of milliseconds.
Is on student table having a lesson_counter field that is updated
every time an attendance is recorded a good idea?
No, it's a bad idea - on the assumption that you want a report for each student showing when they attended or missed a lesson, you have to store that data anyway. Keeping a counter is duplicating that information.
I suggest a design like the following.
An "attendance" and "absence" are logically separate things; you can model them in a single table with a flag. I've modeled them separately because I see them as different things in the business domain, with different attributes (absence has a reason code), and potentially different behaviour (for instance, an absence might have a workflow for sending an email). I prefer to have things that are logically separate in separate tables.
Student
-------
student_id
name
...
Lesson
------
lesson_id
subject
teacher_id (if only one teacher can teach a lesson)
....
enrollment
---------
lesson_id
student_id
start_datetime (or you might have the concept of "term")
end_datetime
lesson_session
-------
lesson_session_id
lesson_id
start_datetime
end_datetime
location
teacher_id (in case more than one teacher can teach a lesson)
attendance
--------
lesson_session_id
student_id
absence
------------
lesson_session_id
student_id
reason (or might be a foreign key to reasons table)
Related
I've got a annoying design issue when designing a database and it's models. Essentially, the database got clients and customers which should be able to make appointments with eachother. The clients should have their availability (on a general week basis) stored in the database, and this needs to be added to the appointment model. The solution does not require or want precise hours for the availability, just one value for each day - ranging from "not available", to "maybe available " to "available". The only solution i've come up with so far includes having all 7 days stored in a row for each client, but it looks nasty.
So here's some of what I got so far:
Client model:
ClientId
Service,
Fee
Customer-that-uses-Client model:
CustomerId
ServiceNeed
Availability-model:
ClientID (FK/PK)
Monday, (int)
...
...
Sunday (int)
And finally, appointment model:
AppointmentId
ClientID
CustomerID
StartDate
Hourse
Problem: is there any way i can redesign the avilability model to ... well, need less fields and still get each day stored with a (1-3) value depending on the clients availability ? Would also be really good if the appointment model wouldnt need to reference all that data from the availability model...
Problem
Answering the narrow question is easy. However, noting the Relational Database tag, there are a few problems in your model, that render it somewhat less than Relational.
Eg. the data content in each logical row needs to be unique. (Uniqueness on the Record id, which is physical, system-generated, and not from the data, cannot provide row uniqueness.) The Primary Key must be "made up from the data", which is of course the only way to make the data row unique.
Eg. values such as Day of availability and AvailabilityType are not constrained, and they need to be.
Relational Data Model
With the issues fixed, the answer looks like this:
Notation
All my data models are rendered in IDEF1X, the Standard for modelling Relational databases since 1993.
My IDEF1X Introduction is essential reading for those who are new to the Relational Model or data modelling.
Content
In the Relational Model, there is a large emphasis on constraining the data, such that the database as a whole contains only valid data.
The only solution i've come up with so far includes having all 7 days stored in a row for each client, but it looks nasty.
Yes. What you had was a repeating attribute (they are named Monday..Sunday, which may not look like a repeating attribute, but it is one, no less than a CSV list). That breaks Codd's Second Normal Form.
The solution is to place the single element in a subordinate table ProviderAvailable.
Day of availability and AvailabilityType are now constrained to a set of values.
The rows in Provider (sorry, the use of "Client" in this context grates on me) and Customer are now unique, due to addition of a Name. The users will not use an internal number to identify such entities, they will use a name, usually a ShortName.
Once the model is tightened up, and all the columns are defined, if Name (not a combination of LastName, FirstName, Initial) is unique, you can eliminate the RecordId, and elevate the Name AK to the PK.
Not Modelled
You have not asked, and I have not modelled these items, but I suspect they will come up as you progress in the development.
A Provider (Client) provides 1 Service. There may be more than 1 in future.
A Customer, seeking 1 Service, can make an Appointment with any Provider (who may or may not provide that Service). You may want to constrain each Appointment to a Provider who provides the sought Service.
As per my comment. It depends on how tight you want this Availability/Reservation system to be. Right now, there is nothing to prevent more than one Customer reserving one Provider on a particular Day, ie. a double-booking.
Normalize that availability table: instead of
ClientID (FK/PK)
Monday, (int)
...
...
Sunday (int)
go with
ClientID (PK/FK)
weekday integer value (0-6 or maybe 1-7) (PK)
availability integer value 1-3
This table has a compound primary key, made of (ClientID, weekday) because each client may have either zero or one entry for each of the seven weekdays.
In this table, you might have these rows:
43 2 3 (on Tuesdays = 2, client 43 is Available =3)
43 3 2 (on Wednesdays = 3, client 43 is MaybeAvailable =2)
If the row is missing, it means the client is unavailable. an availability value of 1 also means that.
I'm creating a database to keep track on various statistics on my self and I'm wondering if there's a better way to store multiple entries for a single date.
E.g. from my table I have AllergyMedicine which can track multiple medicines taken on the same date, is there a better way to do this?
Also the tables Food and Allergy seems unnecessary, is there a better way to group tables?
Any suggestions are appreciated!
I find it helps to state the problem in a semi structured way, as below.
The system monitors one or more **persons**.
Each person consumes zero or more **items**. Each consumption has an attribute of date and time.
Items can be **food**, or **medicines**.
Food can be of the types **snack**, **fruit** or **meal**.
A meal has a **type**.
A person may report **symptoms**. Each report will cover a period of time, and be reported at a specific date/time.
Symptoms may be associated with zero or more **allergies**.
I do not believe that "date" is an entity in your schema - it's an attribute of events that occur, e.g. consuming something, or noticing a symptom.
If the statements above are true, the schema might be:
Persons
ID
name
...
FoodItemType
ID
Name
FoodItem
ID
Name
FoodItemTypeID (FK)
Medicine
ID
Name
FoodConsumption
PersonID
FoodID
ConsumptionDateTime
MedicineConsumption
PersonID
MedicineID
ConsumptionDateTime
Symptom
ID
Name
....
SymptomObservation
PersonID
SymptomID
SymptomStartDateTime
SymptomEndDateTime
SymptomReportDateTime
Allergy
ID
Name
AllergySymptom
AllergyID
SymptomID
Of course, if you take more than one medicine on one day, why not isolate that day (=date) in its own table?
So you'll have a table "days" with only dates, that you either prefill (like a calendar) or only fill with those days when you really took that medicine.
That way, you save a lot of space by "centering" the date in one table and relating everything else to it. Which is actually a very precise model of reality.
All your "FoodSnack", "FoodMeal", "AllergyMedicine" etc. with a date in them will become plain N:M mapping tables then.
You could even abstract further, reduce tables and make just three tables:
symptoms
causes
treatment
All of those related to the central "day" table (I wouldn't call it "Date", cause that's a keyword and easily mistaken also), plus related to each other, where applicable.
I have these set of requirement:
For each school, the system needs to keep track of its unique name, address, classification (Value could be Elementary, Middle, or High), and number of students studying in it.
For each School System Employee, we need to keep track of the unique employee number, full name, address, salary, and the school where (s)he works. An individual works only in one school.
For each student, we keep track of the student’s name (at times, we need to refer to student’s first name, middle initial, and last name individually), address (at times, we need to refer to the street address, city, state, and zip code individually), the school (s)he attends, and what grade (s)he is in.
The system sends letters to High School students frequently, and hence, needs to keep track of each High School student along with the year when (s)he enrolled in the High School.
A system-wide list of courses offered is kept. Information about a course consists of its unique number, unique title, and number of credits.
For each school, the information about which courses are taught there is kept.
For each student, we keep a grade report that provides the grade (Value could be A, B, C, D, or F) for the student for a specific course.
The School System owns buses which are identified uniquely by their registration numbers. Some students take them to commute between their home and their school, while others use their personal means to commute. We keep track of which student takes which bus to commute. We also keep track of drivers assigned to buses (a driver is a school system employee who could be assigned to multiple buses, and a bus could have multiple drivers assigned to it – consider this a weekly assignment of buses and drivers).
Here is my attempt at the ER design:
This is my first ER design and i just wanted to know if met all the requirements and if I did it correctly? Any help will be much appreciated! Thanks!
First of all I don't like it to omit columns necessary for forein keys, e.g. a school ID in the employee table. But I don't know enough about ER diagrams to say if that would even be allowed.
The diagram looks fine to me. Some points though:
School names can change. If there is a number system available (such as NCES School ID for USA) I'd make this the PK instead.
Numbers of students must be no column in the school table; the number of students per school is implicitly given by the students related to the school.
I don't like 1:1 relations very much. Student <-> High Schooler is okay, but I'd rather have the enrollment date in the students table.
StudentID alone can't possible the PK for the grades table. It must be StudentID + Course# instead.
The line from student to course is superfluous, because the relation is given by the grades table already (which is a bridge table containing StudentID, Course# and an optional grade).
The course table's PK must not be Course# + Title, because that would mean the same course number would be allowed in combination with different titles. The PK should be the course number alone. As to the relation: I don't know if the same course can be taught at different schools. If so, the relations are correct.
Met. (though I'd break appart address into # StreetAddress, PO Box, city, state zip etc.(assuming US) Though if you want extra credit you could subtype addresses into their own table and simply have the employee, student and school addresses all in one table with a foreign key...
I'd break down Name, address just as habbit always go to
the loweest common denominator: Fname, LName, etc... (for scaling
solutions long term; combining data is easy, breaking it out later
is hard)
Looks good
Doesn't grade define Highschool? a 9th
grader is in highschool right? so why a seperate table?
4.1) now a table which lists what letters were sent to what students might be useful... but they didn't say they needed this so I'd seek clarification on the requirement.
if # is unique title doens't need to be part
of key.
Missing (you need a schoolCourses table)
Missing (I guess could be handled through your grade table though) Id call the table studentcourses and keep grade on the table... then yeah it works.
Associative/Junction table between bus/student and bus/employee
needed
Overall many-to-many need to be resolved as part of modeling. and I agree with Thorsten, I want to see all fields in all tables including the FK's and I've done enough to know the CASE tools allow it.
and while 1-1 relationships look good for 4/5th normal form. they generally are not practical anymore unless the truely represent a separate concept. So I may have a vehicle table for a vehicle database but I may also have a table for car attributes vs motorcycle attributes vs truck vs boat etc... but vehicle is the primary in this case there so little reason to separate out high school I just don't see the long term value of keeping the object separate (but maybe I just lack vision).
You'll learn that in ERD's the cardinality of the relationships between the data is THE MOST IMPORTANT (following datatype/size/scale precsion). Eliminating M-M relationships is a must. and everything really boils down to 1-M or 1-1 when your done.
Not sure what the line between the school/bus implies.... the buses are owned by the whole system... maybe you need a "System" table tie that to the schools and buses to the system. that way if you support multiple school systems you know which buses belong to what system and what schools are in what system...
I am new to MySQL database and I'm collaborating with my former CSCI teacher to make a student database that holds his student grades history. My original idea was to have a Students table (studentID, firstname, lastname, middlename, gender), a Course table (courseID, course_description), a Grades table (studentID, courseID, year, final_grade), and then tables for AssignmentScores, TestScores, QuizScores, and ExerciseScores. Each of these tables would of course have a studentID, courseID, year, and section (code used by the school to define the semester and period) field, along with the scores earned by the students.
The problem with this approach is that in a perfect world, all courses would have the same number of assignments, exercises, tests, and quizes, and they all would have the same point value, however, as we all know, this is not a perfect world. For instance, there are a couple of courses that have assignments labeled 1a, and 1b both worth five points each as opposed to the normal 10 points each for 10 assignments (labeled 1 through 10). This is also the first year he started keeping track of exercises, and all classes do not have the same number of exercises, nor are they always worth the same point value.
In order to allow for flexibility, we decided to make a table containing general course information with a courseID, year, section, type (to designate quiz, assignment, test, or exercise), number (1a, 1b, or 1,2,3 etc...), and a maxpoints field (to hold the max point value per item). We would then also have a table for individual scores which would have basically the same fields but instead of max points there would an earnedpoints field (to hold the students scores on a particular item). He would then of course have to enter every courses details, every year, regardless of if it was different then the previous year's.
For the two courses he is currently teaching, that amounts to 90 rows per table with much of the data seemingly redundant.
Doing it this way seems to have a lot of redundant information, but I don't see any other way that allows for past, present, or future flexibility. One of the reasons I am doing this project is in hopes of using it to show prospective employers and I thought the point of a relational database was to minimize redundant information, and I don't want prospective employers to look at this and say, "what an idiot."
So my question to the stackoverflow community is, "is there a better way to do this?"
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.