I am trying to create a database schema for creating an online grade report. The report contains the name of the school, the name of the student, the name of the student’s teacher, the number of absent days, the number of tardy days, the student’s current overall grade, and the name of all assignments completed by the student including the date, category, and score for each of those assignments. The following is what I’ve been able to figure out so far. Does anyone have any suggestions about improving this schema?
School (school_id, school_name, course_id)
Course(course_id, course_name, teacher_id, student_id)
Teacher(teacher_id, teacher_name, student_id)
Student(student_id, student_name, grade, absent_days, tardy_days, assignment_id)
Assignment(assignment_id, assignment_name, assignment_date, category, score, course_id)
I suggest you remove the course_id from the school. The student_id from the course & teacher. The assignment_id from the student as described below. In addition I would probably split the assignments into an Assignment and a Mark table.
This results in the schema that a school can have multiple teachers that teach multiple classes that can have multiple assignments. The students belong to a school and can have multiple assignments. This is a pretty simple model and you might consider adding a 'Booking' table in which you store what students have booked what courses. In addition it might be possible that multiple teachers teach a course and teachers work in multiple schools or a course is offered in multiple schools. Just some ideas to think about...
School (school_id, school_name)
Course(course_id, course_name, teacher_id)
Teacher(teacher_id, teacher_name, school_id)
Student(student_id, student_name, absent_days, tardy_days, school_id)
Assignment(assignment_id, assignment_name, assignment_date, category, score, course_id, student_id)
Microsoft provides a sample school database for free. If you find that is helpful:
https://learn.microsoft.com/en-us/ef/ef6/resources/school-database
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 apologies in advance for my English)
I need to make a model of relation.
Normally it a thing we should do in team, but I am stuck to be alone, so I am kind of overwhelm by this
It about a school and it information concerning The Student, The Parents and the Class he want to enroll. Also they keep academic results.
I just can't get an ideal of how I could link them all and avoiding relations problems
http://i.imgur.com/fdwxH8g.jpg
First, I suggest you add a Person table to supertype Parent and Student, and move all the personal and contact information attributes to Person. You're sure to want to add additional information later, and having to duplicate everything for parents, students (and later, teachers and other school staff) gets to be a nuisance.
person (person_id PK, last_name, first_name, sex, birthday, email, address, city, phone_number, cellphone_number)
Next, do you want to record biological parents or caregivers? In schools we normally care about caregivers and their relationship to the student. To record that, you could create a relationship type table:
relationship (relationship_id PK, description)
with entries for father, mother, aunt, grandfather, fostermother, etc. You can then record the relationship between 2 persons like so:
parent (parent_id PK/FK, child_id PK/FK, relationship FK)
If you wanted to record biological parents, you could use:
bioparents (child_id PK/FK, father_id FK, mother_id FK)
with father and mother ids nullable (or decompose into separate tables for father and mother) since we're unlikely to know both parents for all students.
Finally, we get to the business at hand, students. Historical information and alumni are important in schools, so take care to model students over time, not just current students. You need to consider the time resolution for student registrations - are registrations annual, quarterly, or something else? For annual registrations, you could start with:
student (person_id PK/FK, year)
Now, what is a class? Is it something that recurs over time, or are classes with the same name in different years/quarters separate things? Can classes contain learners of different forms/grades/levels, or are they partitions of those? Is a class a grouping of students that attend multiple subjects, or a subject-specific grouping? I'm familiar with two types of classes, which could be called form classes and academic classes, but things may be different in your region of the world.
Using your class table:
class (class_number PK, name, prerequisite, formation_time)
We need to link students to it. If class membership is an annual thing, we can add to the student relation above, e.g.
student (person_id PK/FK, year, class_number FK)
Now, I just made up tables as I went along, but if you want to do this properly, you really should list/model your functional dependencies before you start making up tables. You could look into a formal modeling discipline like Object-Role Modeling, or at least write out simple logical relations in both directions:
a Student has one or more Parents
a Parent has one or more Students
a Class has a Year
a Year has zero or more Classes
a Student has a Class per Year
For non-binary relations, you don't need to write it out in every direction, but you do need to decide which combinations of attributes uniquely determine the others. For example, the combination of Student and Year uniquely determines the Class.
Anyway, that should give you a start.
I have the following statements to create my conceptual model:
EMPLOYEE belongs to one DEPARTMENT;
EMPLOYEE can work in many PROJECTs of his DEPARTMENT;
PROJECT is managed by only one DEPARTMENT;
DEPARTMENT can have many PROJECTs;
So 1 EMPLOYEE can work in N PROJECTs as long as those PROJECTs belongs to his DEPARTMENT. How can i guarantee that the EMPLOYEE and the PROJECT belongs to the same DEPARTMENT using a ternary relationship?
Making some test I found out that using a ternary relantionship I can have an EMPLOYEE in a PROJECT that does not belongs to the same PROJECT
Example:
As shown in the image, the second and third line is allowed, but it is not valid considering that the PROJECT and the EMPLOYEE is from DEPARTMENT 1.
The second line says that the EMPLOYEE is from DEPARTMENT 2 but it's previously define DEPARTMENT 1.
The third line says PROJECT 1 is from DEPARTMENT 2 but it is also defined to be from DEPARTMENT 1 in the first line.
What do i do to solve this problem?
You said EMPLOYEE belongs to one DEPARTMENT and PROJECT is managed by only one DEPARTMENT but didn't model those requirements. Once you do, you can add foreign key constraints to WORK for (EMPLOYEE, DEPARTMENT) as well as (PROJECT, DEPARTMENT).
https://drive.google.com/file/d/0B9mDH6Q_ERUTNWZfaUx3RmpFSWEyOERmRnluaUprbUdUM2hJ/view?usp=sharing
It is the link for the ER diagram which I have drawn. The diagram corresponds to this question
COMPANY has departments
Department has name, number, manager
Manager is an employee
Manager has starting date
Department has several locations
Department controls projects
Project has name, number, location
Employee has name, social security, number, address, salary, sex, birthdate.
Employee is in one department and works strictly on several projects belonging to that department
Hours each employee works on each project
Employee has supervisor
Employee has dependents with name, sex, birthdate, and relationship to employee.
I am trying to model a student database but I am unsure of how to represent the student, assessment taken, and student results. Below is the description of the scenario:
Several students are offering one or more subjects, these subjects have one or more assessments. How would the you represent students, the subject offered, the assessment taken and the results of the assessment taken by the students? I have attached a copy of the design I made so far.
my intension is to design a database where querying of the student,subject,assessment,
and assessment result can be possible and easy.
Full-size image
IMHO you should have a ternary relationship between student, subject and assessment owning the assessment result. This is necessary in the case where a student can have many subject for the same assessment.
Otherwise if an assessment have many subject but only one for a given student you have different choice :
You can keep the ternary.
You can otherwise store the subject id and result in a student - assessment relationship table
or the student id and result in a subject - assessment table.
This should depend on the way you will usually query those tables (all subject for assessment A, all students with subject X for assessment A, all results for subject X for assessment A, etc...
This have several ways to resolve, but why you don't use the Students*---*Subject relationship to associate the assessment to. Because assessment is directly related with this association. So it can't make sense without the relation between a student and a Subject.
You can call the derived table from the has_and_belongs to many relationship between Students and Subject, Assessment with the following fields(There is no place that obey you to call this association student_subjects):
ASSESSMENT
id:PK
student_id:FK
subject_id:FK
assessment_result
created_at, TIMESTAMP
Imagine that the student can make several assessments during their school year, you can save phase 1, phase 2, or Exam1, Exam2, etc... in other field in this table.
The timestamp will provide you a way to know the last result that a student had for a subject.
This is just my point of view, correct me if there is something that i'm not seeing.
I'm trying to achieve 3NF using the data I have but I'm getting confused. These are the tables I have:
FACULTY table DEPARTMENT table STUDSGROUP table STUDENT table
FACULTY_ID DEPARTMENT_ID STUDSGROUP_ID STUDENT_ID
FACULTY_NAME DEPARTMENT_NAME ACADEMIC YEAR STUDENTS_NAME
FACULTY_DEAN HEAD OF DEPARTMENT COURSE/SPECIALITY STUDENTS_GROUP
COURSE/SPECIALITY
DOB/DATE OF BIRTH
I am thinking I can do it like this below, though I think I'm not right.
FACULTY table
FACULTY_ID,PK
DEAN
DEPARTMENT table
DEPARTMENT_ID,PK
FACULTY_ID,fk
DEPARTMENT_NAME
HEAD OF DEPARTMENT
STUDSGROUP table
STUDSGROUP_ID, pk
ACADEMIC YEAR
SPECIALITY
STUDENTS table
STUDENT_ID, pk
FACULTY_NAME,FK
STUDSGROUP_ID,FK
FIRST_NAME
LAST_NAME
DOB
Normalization requires that you know how the various parts of the schema are related. Up to 3NF and BCNF (almost, but not quite the same thing — though you'd be hard-pushed to find a practical example of 3NF that is not also in BCNF), the most important feature is the functional dependency.
Another key point is 'conservation'; you shouldn't lose columns altogether. For example, your original Faculty table has an ID number, a name and a dean. Your revised version is missing the faculty name; that is a bug in your redesign.
You've identified that each department belongs to a faculty, which seems plausible enough.
Your revised Student Groups table seems to be the same as in the original. That's probably OK, though maybe the course/speciality part of that means that a student group is associated with a department, and hence a faculty. If so, then the you might need a courses/specialities table that identifies the course/speciality and the department, leaving the student group to identify a particular year group within the course/speciality.
Your original students table has a course/speciality and also a student group; this leaves open the possibility that the data will say Student X is doing Archaeology in the Students table, but the Student Group indicates that Student X is doing Music. Is that allowed? If not, would you be best served by just having the Student Group in the Students table, leaving that to identify course/speciality, and year, and department, and hence faculty? Your revised schema adds a faculty ID to the students table (but does remove the course/speciality); that still leaves opportunities for conflict within the data.
Do you need a table to identify valid academic years? Possibly not. Should there be a table for staff, so that you can identify deans and department heads. Can the dean of a faculty be a department head? Of departments outside their faculty?