I have a table that shows each student's details with their module choices for semester 1 under each student 1.
I want to add the semester 2 module choices as well so they can be seen on the student detail table. Is there a way to do this? When I try to set up the relationships, the student details are shown in the semester 2 options table 2, which is not what I want. I haven't done that much on access so apologies if this is a simple question or if it isn't possible...
You already created relationships. As I understand, you want to see more than one "child" table in table designer. If so, it's not possible.
If you want to select options for different semesters, create a form based on Students table and two subforms for Semester1 and 2.
Also I would recommend to change database structure. You don't need two tables for semester modules. Create just one table with additional field like SemesterNumber and place subforms, based on this table with different criterias for SemesterNumber. And add own primary key for SemesterOptions, do not use StudentID as PK, actually you have one-to-one relationship, I believe you want select more than one module for each student.
In my opinion, you should have more tables, which in end will make it much easier to query data and get reports out of it, as well it will make it easier to create forms for each table to record data.
Here is simple table structure I would do for student/class registration.
You can also link tblSemester table to tblClass, if you like to make a list of classes offered each semester and make it bit more complicated, but with this organization you will be able to get list of all classes for student, or all student for particular class or semester, and with ease add more data later.
Related
I have a class_session table and a teacher profile form. So basically each class_session will be taught by more than 1 teacher at the same time, the structure of the table is like this:
Class_id|Teacher_1|Teacher_2
What I want to do is create a form in the teacher profile to show all the record of the teacher no matter he/she in the Teacher_1 or Teacher_2. So basically I want to see all the classes the teacher was involved.
You should not design your tables the way you did. If you later on decided that a session can be taught by 5 teachers, you will need to add 4 more columns for the teachers, and this is not practical and not a good design.
You should have a table for the sessions and a table for the teachers:
class_session: session_id|session_name|etc...
class_teachers: teacher_id|teacher_name|etc...
Also, you should have a table for which user teaches which session:
sessions_teachers: session_teacher_id|session_id|teacher_id
This way, you can add as many teachers to as many sessions as you need.
Now, in the teacher's form, you need to add a subform bound to a query. That query should fetch the data from the sessions_teachers table inner join the session and teacher tables and should filter out the records for the teacher in question.
I want to create a database for school management system. The database has two tables contain shared fields like Students and Teachers.
For example, Student table has fields(id, name, phone, class), and Teacher table has fields(id, name, phone, department).
Is it better to make: a table called Person which has fields(id, name, phone), Student table has fields(id, person_id, class), and Teacher table has fields(id, person_id, department).
Which of the two ways is better?
Giving a direct answer to this question might be opinion based. There is no generally best strategy to design database.
Theoretical example: if there is a large amount of data you might want to think about performance: what and how you search and joins.
If you search mostly Students and Teachers you might not create Person table and you could search them easily. Then if you would like to search all Persons from db you would need to make two queries and a UNION between those and with fields that are common to both types of Person.
If you search also Persons more frequently then you might create Person table and implement Teacher and Student to have foreign key to Person. Then when searching two last mentioned you would need to make JOIN to Person.
In real life I do not know if in this use case there is really a big difference. More important is that you select some strategy and follow it in your future decisions in order to keep the desing clear.
However there might come situation where it is need to change the selected strategy still. So theoretically.
Related question here
I have a table called Category. It has a one-to-many relationship with another table called Subject. And that has the same relationship to another table called Course. And same to Lesson. All of these have a one-to-many relationship to the next table mentioned.
So a Category has many Subjects which has many Courses which has many Lessons. My database is actually more complicated than that, but I'm keeping it simple in this question.
I've recently been asked to rename the Subject table to Course, and the Course table to Topic. This is the second time I've been asked to do so and this causes a huge re-write of much of the code.
So an idea came up in our meeting, which is to just call the tables FirstTable, SecondTable, etc. But this causes two problems. The first is that it would be confusing to know which table represents which model name, and the second is that if in the future, we add a table in-between, we would have to call it something like TableOnePointFive if it goes in between the first and second table.
Another idea was to make our own names and allow have another table to store their names. But this would cause confusion as the developers would have to look up which table represents which model name.
Is there any way to get around this?
I have the following tree:
courses, that have many groups, each having multiple students.
So the drilled-down tree looks like this: courses -> groups -> students.
I think there are two ways to represent this:
1) students table that has group_id FK to groups; groups table that has course_id FK or:
2) first option plus students table having both group_id and course_id FKs so that I can have more freedom to fetch data without having to JOIN the "parent" table everytime.
One good example is to get all students that are part of a course (whatever the group). In this case, going with only the first option forces me to JOIN the groups table, which is not needed in that scope. So i tend to always choose the second option, even if the "main" table gets a few more columns of FKs.
How do you approach this?
The example gets more complicated if you add a couple more tables at the top of the courses table, like teachers (that teach courses) and schools (that has teachers). If you need to see all the students in a school, you need to join the groups, courses, teachers and schools.
Thank you!
LE: I am excluding many to many relationships from this example, those are treated differently.
LLE: And yes, if it sounds like convenience (aka performance)... it might be true :)
Personally, I try to keep a database as normalized as possible for clarity in the data model. So I would say if every student is going to be linked to the course through a group (no possibility of a student not in a group), than there should not be a relationship directly between students and courses. Don't sacrifice the clarity of your data model for having to write less SQL.
Also, you probably realize this, but you'll need linking tables for any many-to-many relationships. I'm not sure what kind of groups you're talking about, but if they can exist over multiple courses you'll need a Course --> CourseGroup (FK CourseID, FK GroupID) --> Group structure, and if students can belong to multiple groups you'll need Group --> GroupMembership (FK GroupID, FK StudentID)--> Student.
The addition of the course_id into the students table would be considered "denormalization" and is perfectly acceptable for exactly the reason you are trying to solve : "performance".
Denormalization Wiki
In computing, denormalization is the process of attempting to optimize the read performance of a database by adding redundant data or by grouping data
So yeah, your second option is doing just this ... attempting to improve performance by adding redundant data.
When should I put an attribute in a separate table? I mean is I have an attribute but whether I should put this with the rest of the attributes of a table person or whether I should put it in a separate table with person_ID as FK?
Secondly, when does an association class is formed? Can it form between a class and its multivariate attribute? Ex class book has attribute author. An author can write many books and a book can be written by many authors
You should put an attribute in a separate table whenever you expect that one person could have multiple of that attribute. Otherwise, there's not much reason to separate it, and there can be some conceptual overhead in doing so. (It can be very annoying when you have to write a query that retrieves five different attributes of a person, if each attribute is in its own table unnecessarily.)
You should create an association table between two tables whenever the relationship between them is many-to-many. Your author–book example is a good one.
It depends on what that attribute is dependant of. If it's an attribute of that entity you're creating (person) then it should go in the same table, but as you said in the case of a book where 1 book can have many authors and 1 author can write many books, you have to take into consideration the relationship between the entity and the attribute. Is it a 1 to 1 relationship, 1 to many or many to 1, etc.
This being said, if your person can only have 1 value for that attribute and that only 1 person can have that attribute, then it should go in the same table.
You should have an association table in the following situation:
1 person CAN live in more than 1 house at a time, (home and holiday house) but more people CAN also live in those houses.
Obviously, in the example above, we're ignoring the fact that 1 person cannot be in more than 1 place at a time.
As a general rule, the attribute should be dependant on "the key, the whole key and nothing but the key"
UPDATE for what #ruakh said:
It can create overhead if you separate attributes but a tool which you can use to accommodate this overhead is creating Views of the table. I'm not sure what database system you're using but MySQL has this feature. A View is a "virtual" table that you can create using SQL queries on the current database. You can combine multiple tables and you will query that View just as you would do with a normal table.