I am trying to understand why this statement in the book is wrong: "given a C entity, there is at most one related A entity and at most one related B entity".
Is it that it doesn't apply to a specific kind of relationship??
So, if I have an example of a student who is in attendance to a course with a type of subject. The entities are student, attendance, course and subject. Student makes attendance in a room. Also, a student can make attendance for a subject. Does this example apply to the statement?
Thanks for your time.
The author probably means: in a single relationship instance (e.g., student-Bob/course-ABC/attendance123). So there is a single student, a single course and a single attendance record linked in that instance.
Not across all relationship instances in the class (where student Bob could attend many classes over time).
Related
Second year CS student here.
Questions:
Is the 'Results' Table currently creating a 'common look-up table'?
How do I solve Employment-student relationship?
Database problem:
For each student they would like to know which degree program they were on (a student may have studies for more than one degree but not at the same time); the modules they took and their final results. For their employment they would like to know the type of employment (Full Time or Part Time, Permanent or Fixed Term, Continued Education, Taking gap year); their job title and whether it is considered a ‘Graduate’ role; The name and address of the employer; a contact email for the student, whether we can use that information for publicity purposes and a brief description of their role.
My current design for Database:
Current ERD
Q1.
I noticed when constructing the ERD there was a ternary relationship between Module, Degree and Student and decided to solve this many to many problem by creating a fourth table called results. It has foreign keys from Module, Degree and Student and contains the Result date and Result score for a student in a module on a degree. Considering each student takes several modules there will be a lot of entries, will 'Results' form a common look up table? I heard these were not best practise when constructing a DB. This design also makes it difficult to query which degrees each student has done (each student can take many degrees just not at the same time). I considered creating separate tables for the Student-Module relationship and Student-Degree relationship however you then would not know which module was taken under which degree.
Q2.
I was given this advice by my lecturer:
The relationship between employment and students it not quite clear and would require some explanation. Typically an employment in the real world is between 1 employer and 1 employee only, not multiple employees per employment.
Student-Employment Relationship
Is this a suitable fix? I currently have a foreign key in student which relates to their employment. Am i still able to use this or am i thinking about this relationship all wrong?
The database should support the following queries:
For a particular student their employment details
Details of students for which they do not have Employment records
Details of students who were unintentionally unemployed within 6 months of their graduation
% of students employed within one year of graduating according to class of degree
% of students in a graduate role for a particular year and degree program
All answers are greatly appreciated. Thanks for your time.
I'm trying to figure out how to structure this relationship between student, teacher and classroom.
Each teacher has 1 or more students.
Now considering that,
Students have one or more teachers, but all said teachers must teach from the same classroom.
After tinkering around I have gotten to this stage (http://i.imgur.com/XfLFPtb.png) , but it feels wrong. Or perhaps instead of linking teacher to room, maybe student to room? I'm not sure.
I'm not sure whether it would also cover the case when for example, you might have 3 teachers (can be more, just an example). Where "teacher_1" and "teacher_2" teach "student_1", "teacher_2" and "teacher_3" teach "student_2". Even though they teach from the same room, "teacher_1" and "teacher_3" aren't sharing students.
EDIT:
Each student is taught from the one classroom. i.e students can only be taught from one room.
I could have stated that, but that's what I thought was implied.
You are actually mostly right in your diagram. Basically teachers and students are definitely different tables as you have teacher and student, and they would be linked by a link table called teacher_student with dual primary keys off those tables. In other words, you have what is considered a many-to-many relationship, and using a link table is correct.
One change: you have the primary keys set up as VARCHAR. That is a bit odd. I would use INT for a primary key for both the teacher and student tables, and these would typically be set up as autoincrement.
It's not entirely clear that you need a separate table for classroom if all teachers teach from the same classroom, however if you mean that each teacher teaches all of his or her individual classes from that classroom, then there's another question. If there is a one-to-one relationship between teacher and classroom, you only need to have classroom set up as an extra key on teacher and no need for another table. In other words, your classroom table becomes unnecessary. If teachers share a few classrooms, then you could have a separate table listing the classrooms, and then on teacher you would have a foreign key for classroom_id which would then link to the controlled table of classroom.
Edit:
One last clarification. Teacher and Student tables are essentially correct. just change the variable to INT. teacher_id is the primary key on teacher; student_id is the primary key on student, and both serve both as foreign keys and dual primary keys on teacher_student.
As a suggestion, you may want to consider an entity representing a class or course. One class can have many students. A teacher can teach many classes. A room has many classes. This might help resolve your relationships. (A classroom can only have one class at a time.)
Hope my logic makes sense.
Say I have three entities(or tables): School, Student and Classroom. How do I ensure a Student belongs to a Classroom which belongs to the same School the Student belongs to? Considering a Student may not be part of any Classroom.
I'm facing that problem in many other ways. For example, when I add the entity Teacher. How can I guarantee at database level that a Teacher teaches on a Classroom of the same School the Teacher belongs to? And so on...
I am doing a project which involves a good use of core data. I have been using it since few months now. I have a small problem. I have two different entities a entity named Student and another named Courses. The relationship between Student and Courses is one to many. I am frequently updating the entities from the remote json. So, sometimes there are dangling pointer in the Courses entity which do not have relationship to the Student entity. This type of the entities need to be deleted. How is it better to delete such objects ?
Courses(points to student) <------------- Student ----------------> Course (Points to student)
|
|
|
|
Course (Points to student)
Course(has no pointer to student, no foreign key to relate with student)
Are you sure you need to delete a course when it has no students? Course may be valid though. I think you should nullify the relations, so when you delete a student, all courses pointing to it just would stop referencing that student.
You probably need to check your relationship delete rules so that they should be nullify in my opinion.
The simple way to do this is to create a fetch request and query against Courses. Obviously you need to use a NSPredicate to remove the Courses with no students.
If your Courses has an inverse rel to Student, called coursesToStudent, you could set up the following predicate.
[NSPredicate predicateWithFormat:#"coursesToStudent == nil"];
Here I suppose that Courses has a one-to-one rel with Student.
In this way the fetch request results will have Courses without a student. With the result, call deleteObject and you have done.
For info about setting a fetch request with a predicate see Filter NSFetchedResultsController for nil value?.
About your model I would set up another one. For example use three entities:
Student
Course
Enroll
where
Student
- attributes you want
- toEnroll [one-to-many rel to Enroll with cascade rule]
Course
- attributes you want
- toEnroll [one-to-many rel to Enroll with cascade rule]
Enroll
- attributes you want
- toStudent [one-to-one rel to Student with nullify rule]
- toCourse [one-to-one rel to Course with nullify rule]
Hope that helps.
I wonder what these two words mean.
I encountered them in Doctrine's documentation, but I can't understand what they mean.
This has to do with whether common usage (within the application domain) would attempt to access both sides of the relationship from the other side... Invoices to products would probably be unidirectional, as athough we often want to know what products are on an invoice, it is unlikely that you would want to know all the invoices that contain a given product.
Stores to products on the other hand is bi-directional, as we could easily want to access both all the products at a specific store, or find all the stores that sell a specific product.
Bi-Directional is not limited to where the relationship is a many-to-many relationship. An employee to supervisor relationship could easily be bi-directional, if, in our domain model, an employee object will need to be able to access the employee's supervisor object, and of course, the supervisors object contains a property that lists all his assigned employees.
One to Many Bidirectional:
State and City, where State has collection property of Cities, and City has a State property
Many to Many Unidirectional:
Bus and Rider, where Bus has collection property of Riders, but Rider does not have collection property listing all Buses Rider has ridden in (application does not care).
Many to Many Bidirectional:
Person class, where each person has Friends Property, as Collection of other person objects this person is friends with;
or...
Artist and Album classes, where Artist has Albums collection, and Album has Artists Collection (where album is compilation of tracks from multiple artists)
Example:
We have two tables in database: Student Table, Subject Table
Many-To-Many Bidirectional
You need apply the navigation in the database from the following two directions:
Navigation from Student to Subject
A student can enroll for many subjects in the semester.
Navigation from Subject to Student
A Subject can have many different students enrolled for it.
Many-To-Many Unidirectional
You need apply the navigation in the database from the just one direction:
Navigation from Student to Subject
A student can enroll for many subjects in the semester.