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.
Related
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.
I have a simple entity data model where I have two entities and a 1-* relation between them. For simplification purposes let's say Person and Book. (i.e. people have 0 or more books and books must have an owner)
The system works fine and it has data in it.
Now I need to create other entities inherited from Person (i.e. Student, Teacher)
When I create them and update my software accordingly, everything works fine with this new model.
Now I need to migrate the old data (data in Person which is linked to books)
In my data I know which person's are student and which are Teacher and I have additional information on the Students and Teachers that I'll place in the new model.
The question is how do I migrate the data. I cannot add Students and Teachers before I delete the Person instance because that would create duplicate Id in Person. I cannot delete the Person as it creates an error. ("DELETE statement conflicted with REFERENCE constraint")
How do I acheive this data migration.
Thanks
If you really have mapped inheritance you should not delete Person - the Person is either Student or Teacher so you should just add correct columns (in case of TPH) or related tables (in case of TPT) and use existing data without their modification.
This migration must be done in SQL.
I have a requirement like below:
Department -->> ( has many) employees
Employee -->> (can belong to only one department) Department, no employee can exist without any department.
For setting this up, I have setup the model like
Department
relationships
name: employees
destination: Employee
optional:yes
to-many:yes
delete-rule:cascade
inverse-relationship: none
Employee
relationships
name: department
destination: Department
optional:NO
to-many:NO
delete-rule: No action
Should I create a inverse relationship anywhere in this model?
Have I setup delete-rule for department relationship in Employee right?
Is there anything else I should to get this model right?
Thanks
Yes, you should almost always specify the inverse relationship according to apple's documentation. You've got the option of not doing so, but it should rarely be used.
I think there may be situations where your database can become corrupted if you don't create an inverse relationship, but I'm no expert.
Those two relationships should be inverse relationships of each other.
I'm not sure about the delete rule. Sorry.
EDIT: #jrturton's comment suggests your delete rule is fine.
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).
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.