I have a Firebase database for recording grades of students to exercises. There is a "students" object that holds all student details, and an "exercises" object that holds all exercise details. Now the question is where to put the grade that a certain student scores in a certain exercise?
When a student enters the system, it needs to show the grades of this student to all exercises, so it makes sense to put all grades in the "student" object.
When a lecturer enters the system, it needs to show the grades of all students to a particular exercise, so it makes sense to put all grades in the "exercise" object.
So far, I put the grades in both places, but it lead to bugs, and apparently it is a design bug since the data is duplicated.
In an SQL database, I would just create a separate table called "grades", and have both "student_id" and "exercise_id" as keys in that table. This way it is easy to find all grades either by student_id or by exercise_id.
How can I do this in Firebase?
think i would add all studentIds and excerciseIds into a grades collection, and just have all their grades their, and probaly duplicate extra the data needed from student collection + excercise as you suggest similar to sql approach.
if not that i would probaly checkout support for subcollectin queries as i belive its on the way? that way each excercise could have the student information as subcollection, either way duplicate the data and think like sql views.
Related
I have such entities:
There are teachers, students, languages, courseGroups and a junction table GroupStudent
Every courseGroup can have only one teacher and one language, but every teacher and language can have multiple courses.
Also, there are students. Every student can have a few courses and every course can have a few students.
I'm not sure about this. Is it the right scheme?
Why do I think so?
I have a task. I have to calculate the number of students in every group, who study English.
The problem: I don't know how to find students who study English. It would be easier if student could have only one course. Then I'd have just check all English courses. However, student can have a few courses.
Example: Student Stepan has (CourseGroupid=1) an English course and (CourseGroupid=2) a Spanish course. I have to calculate this student for both groups.
P.S. I'd be very grateful if you'd just hit me is it possible to complete the task with this database or how to remake it :)
Do a DISTINCT select on Students.Id to get every student at max once. Then JOIN GroupStudent, CourseGroups and Languages. Lastly add a WHERE clause on Languages.Name = 'English'. You should be able to figure out the exact SQL on your own
I need to find a way to match records between two tables. The problem is a single identifier that would make the match very simple isn’t available so I need to find a way to make that match based on some other available information in the records.
In an elementary school all registered/existing students have a Student ID. It is unique and makes a perfect primary key. However, any new students entering the school for the coming year do not get a Student ID until they are officially registered.
Before the next school year starts the school invites the new incoming students to be part of a pre-registration assessment program to help determine their current level and needs for the coming school year. It is at this point that as much data about each prospective student is gathered. This information is stored in a separate table from the main student information, mostly because there is no official Student ID. The idea is to merge the pre-registration students and their data into the main student information table(s) once they have an official Student ID assigned to them.
My thinking was to assign these new students a temporary ID just to have a unique identifier for them in case there are name duplications.
My question is how can I match up the temporary ID’s with the real ID’s once the student is assigned one?
Some information that will be gathered in the pre-registration process will include Last Name, First Name, Middle Name, Grade, with Birthday being another possibility (but isn’t included at this time).
Maybe I’m going about this in the wrong way so any suggestions on offer would be greatly appreciated.
It sounds like you are exporting information from the main Student Information System, running additional processing in Microsoft Access, then ultimately merging it back into the main system. This being the case, you will have to work with the limitations in the export and merge features, and building your matching logic around what is available there.
Plan A: Ideally your Excel export would include some type of primary record identifier from the main system, independent of the Student ID that gets assigned later. (It very likely uses a unique ID internally, even if that is not included in the export file.) You would then use this to match to your records in Microsoft Access.
Plan B: If the primary system does not export a unique identifier, then you will need to come up with your best combination of data to uniquely identify the student. How you do this will depend on how many students you are dealing with, and whether the matched data changes in either system. Full name and birthdate is a fairly common way to do this, if that data is complete in the originating system.
With the unique identifier established, I would use two queries in Access. The first would be an update query to assign the Student ID to your Access system as soon as it becomes available in the main system. (Search for matching students that have a Student ID in Excel, but not yet in Access.)
The second query would be an append query to add the new students from the main system into Access. (Where the student in Excel does not match any existing student in Microsoft Access.)
Taking this approach, you would pull the Excel export regularly from the main system and run the above queries to keep your Access system updated. Then when you are ready to merge information back into the main system, you could filter on students in Access that have a Student ID assigned. The actual update of data in the main system might be done through an update query, or perhaps an export from Access that includes the Student ID. (Depending on how your main system merges the incoming data.)
The way I would approach this is to merge both tables into a single table of students. This table would have an AutoNumber ID column that refers to the student or prospective student. Then you would have another column in this table for the StudentID which would be assigned at a later point.
Your forms and reports can then filter the data based on the StudentID field to show you either current or prospective students.
Taking this approach means your student data gets entered into one place, and you don't have to worry about trying to repeat information or merge it later. Since a single record represents a single individual, it makes logical sense to me to use a single table.
I am new to using UML and I am not sure if my diagram is correct. I would like some advice from someone more experienced than me.
The statement of my problema says:
Students study courses and each student can take several courses "studies" each. Any course can have more than one student studying it.
Students, who are identified by a numerical code, have a name, date of birth and one or more nationalities.
A student who studies can receive scholarships.
A Student can recieve more than one scholarship per course. And an
individual scholarship can be given to more than one student. The
scholarships have a numeric code, which identifies them, a name, a
base amount and different conditions to be fulfilled at the time of
the assignment.
My proposal is the following:
What I want is to represent students, grants and the courses the student takes, and I am not sure if I should use an associative relation or a ternary relation.
Can anybody confirm if my proposal UML diagram is the right one?
The only statement directly relating students, courses & grants is the unclear "[a s]tudent can receive more than one grant per course".
It only actually says that each student-course pair can have more than one associated grant. (Maybe the author of the assignment thought that that "per" sentence is saying more than that, but it's not.) It doesn't say of a student whether their grants depend on their courses, and if so how. Your design is best when given a triplet you can't tell anything about any other triplet. The design with Takes(student,course) & Receives(student, course, grant) with th FK (foreign key) {student, course} from Receives to Takes is best when if you know a student & course pair then you know its grants. If grants are given to a student independently of courses then a design with Takes(student,course) & Receives(student,grant) is enough.
Clarify with your instructor.
Almost. The lozenge (or diamond) shaped element is itself an association class which associates all connected classes. What you want it a simple association class between Student and Studies like this:
The Scholarship represents the exams passed by the students in specific studies. The association class relation is indicated by the dashed line linked to the association (which has a m-n multiplicity).
Before you get to any attributes, I don't see a correlation between the nouns in the problem statement and your classes. I would expect to see the following classes:
Student
Course
Nationality
Scholarship
I would also expect to see an association class, called CourseEnrollment, that would have the following italicized properties at the ends of the association:
Student studiedCourse [1..*] Course
Course studyingStudent [1..*] Student
That association class would have yet another association with Scholarship, called ScholarshipAward, that would have the following italicized properties at the ends of the association:
CourseEnrollment awardedScholarship [0..*] Scholarship
Scholarship receivingCourseEnrollment [0..*] CourseEnrollment
With this arrangement, a Scholarship can be awarded to a combination of Student and Course.
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.