I am working on a project where I am using core data, but bit confused how to use it corectly.
I have two entities students and college
students has one-to-one relationship to college. That is every student will have one college.
college has one-to-many relationship to student. that is college can have lot's of students.
However, in my app I am letting the user to add the student first without any college info. So I am keeping the relationship to college optional. In a 2nd view, I let the user update the college information of a student.
Now I am while adding a new student I am just updating the basic field related to student (firs name, last name, age, etc.). Now in 2nd view while updating college info I am not sure what is the correct way to do it considering the relationship.
The first view pass the student object to 2nd view and I am updating it as follows:
College* college = (College*)[NSEntityDescription insertNewObjectForEntityForName:#"College" inManagedObjectContext:self.managedObjectContext];
college.name = #"name"
college.address = #"address"
[college addStudentObject:self.student];
Am I doing it correctly?
what should be the correct way:
Adding the college object in 2nd view and connecting the entity by adding the student object in the student relation of a college?
Retrieving the student object first then getting the empty college object from the college relation. Then updating the college object with data and then save the context.
I am not sure if the 2nd option make any sense but in case of first option, if I add a new college, the new college get connected with the student but the old college remain in the database as redundant data.
In this scenario, I would probably create another entity, StudentEnrollment with one to one relationship to both student and college. It would probably make it easier to manage student's courses, grades, etc as well as transfers to another college.
Related
I am learning about ER modelling about Database systems. My problem is that there is a entity called books,enitity named user and I want to create a borrows relationship between user and book with attribute issue date. I modelled it as described but it was pointed that borrows cannot be a relationship because a same user can borrow a book twice. Can anybody explain me what this is as I am using issue data as an attribute so records in borrows relationship would not collide as I will use PK as userid,bookid and issue date. How can I model this accurately? I am a little confused in this.
In the ER model, entity relations consist of attributes of a single entity set, in which the PK identifies only one entity set. Relationship relations have a composite PK that represents two or more entity sets.
Your question uses a composite PK that represents two entity sets (userid and bookid) and a value set (issue date). Strictly speaking, it's neither an entity relation nor a relationship relation. It's a combination of a relationship relation (two entity keys) and a weak entity set (issue date functions similar to a weak key). If we want to be creative, we might call it a weak relationship.
If I was forced to draw an ER diagram for this, I might present it like this:
The ER model isn't a complete logical model (unlike the relational model) and there are some situations which aren't handled well or at all. This is one of those situations.
As per description, User and Book are the entities.
One user can borrow an instance of book.
Similary, one user can borrow multiple instances of book, whether It can be same
instance or various instances.
So every transaction between the User and Book has the Issue Date.
Neither the user nor the book has the Issue Date.
Here, the relationship between User and Book are Many to Many.
The Bridge table is Transaction. We can name it as Borrow also as per your interest.
Now, The user has one to many transactions.
Every Book has one to many transactions.
Every transaction is a combination of a User and Book.
Note: Since every user can have the same book multiple times and at the same day. So we can have a composite primary key of user_id, book_id and Issue_timestamp as there is a chance of redundancy in the Issue Date in the same combination.
So I have this small problem, I am trying to make an ER Diagram and I have a student. For the student entity it says:
Record which school a student is in. A student must be attending one school. All schools contain at least one student.
You are to record the following information schools: their names(must be unique), # of students attending, and the principal name.
When I read this, it seems like "school" is a composite attribute or an entirely separate entity. Since it says "A student must be attending one school. All schools contain at least one student" should I make it an entity because I can't think of how to show this relationship via a composite attribute.
As I see it, school is a separate entity. A composite attribute would be something like a 'name' which consists of a 'first name' and a 'last name'. The school only consists of school and student only consists of student in your example.
I'm a bit confused on what a many to many relationship is. I'm wondering if the following is a many to many relationship:
A student at a school has many clubs. A club at a school has many students. Let's say that the student has many attributes: firstname, lastname, phone, age, email, etc. A club only has one attribute: a name.
When I make a new club, I want to be able to give the club a name and one or more students. Upon making the club, I want that club to be associated with those students and those students to be associated with that club.
When I make a new student, I want to be able to give the student a firstname, last name, etc, and one or more clubs. Upon making the student, I want that student to be associated with those clubs and those clubs to be associated with that student.
I also want to display a club's students and a student's clubs on their show pages.
I've read that a many to many relationship is when you have a join table that lets you access common attributes of the resulting students and clubs, but there are no common attributes in my case.
Do I have a many to many relationship here? If so, do I use a HABTM or has_many, through relationship?
Actually yes you DO have common attributes.
You stated yourself that a Student has many Clubs
And a Club has many Students.
What is in common? Students and Clubs.
What now follows is to define what a Student and a Club actually are, which you already did.
A Student is a combination of firstname, last name, etc... What you have not specified is what makes a Student UNIQUE. A club also must be defined as to what will make it UNIQUE. While for academic purposes, you could say the name is what makes it unique, in real live, that would probably not be the best solution.
Usually for performance purposes, each student is given a unique Autoincrement ID (which is a number).
Same thing can be done with the Club.
You create a 3rd table which is what creates the Many to Many relation.
In that 3rd table, you have 2 columns. One with the Unique Index for the Student, and the other column with the Unique Index for the Club. You simply add an entry on that table in which you wish to relate a student to a club.
Since you can have many students assigned to the same club, and you can have many clubs assigned to the same student, you have a many to many relation.
Edit: As mentioned in another answer, your 3rd table should also declare the combined indexes as unique, so that you don't add the same entry multiple times.
You have a many to many
Create an id for each table that is unique for that table typically an auto incrementing int.
Then a third table that is a junction/intersect table call it X.
Put a row in X with the student id and club id if the student has the club and vice versa. It would have a unique composite key in table X across both id's in it.
The composite would guarantee no duplicate rows in X
Yes indeed there is a many-to-many relationship here, use HABTM. Also, why do you say that there are no attributes in common? Club names and student names are definitely common attributes in this case.
I am new to core data just started learning the new ideas in core data.
I have core data database which has three entity Student,Department and an entity for Mapping Student and department.Let name it as StudentDepartment
Student will have all student details with a primary key studentID
Department will have department details with a primary key departmentID
StudentDepartment will have studentID and DepartmentID as foreign key.
Multiple student can be enrolled in a department and a same student can be enrolled to multiple department.
How to create this schema in core data.
If am deleting a studentID in student table subsequent row should be deleted in StudentDepartment table. Similarly if am deleting departmentID in department table subsequent rows should be deleted in StudentDepartment.How to make this relationship by using core data.
Please provide me a xcmodel.
CoreData isn't a database, it's an object store that happens to (sometimes) be implemented on top of a relational database.
The practical result of that is that you really don't need to explicitly create a separate table for relationship mapping. Instead you create your two entities and then create a relationship between the two. From your description, it sounds like you want a many-to-many relationship between the two. At an implementation level, core data will magically create the needed relationship table.
Additionally, you can establish a delete-rule for each side of the relationship that mandates what to do when an item is deleted. Pin this case, you'll want to set the delete rule for both to nullify, which will break the relationship when either end is deleted.
A design question which I need help with. It's best described with an example.
Using the following Domain models:
- Student
- Enrollment
- Course
Where Student and Course have a many to many relationship to each other, achieved by the Enrollment table, i.e. Enrollment has a StudentID (FK) and CourseID (FK).
Both the Student and Course classes each have a Navigation Property, i.e. an ICollection of the other.
I'm using View models, and would like simple CRUD functionality, to add, edit, delete students and courses. The View models are very similar to their associated Domain models.
To display the student's details is simple enough, but when it comes to displaying the student's course details, which of the below designs would be the best approach?
In the Student View model, declare an ICollection of the Enrollment Domain Model?
Then in the view the enrollment details are accessible.
I feel as if this undoes what the View model is trying to achieve, and that is to have an abstraction layer from the domain model. Using this design, the Enrollment Domain model is accessible from the View, via the Student View Model.
Create a View model for the Enrollment class.
This will be identical to it's Domain model. Doesn't do anything else other that hold the Domain model's values from the View Model. Has to be mapped via AutoMapper. Not sure what to make of this option, feel's inefficient.
First of all, Enrollment should not be a domain model. Enrollment is just a database table which specifies a many-to-many relationship from Students to Courses.
My suggestion is to create a List of Courses in the Student domain model, and use NHibernate or Fluent NHibernate to map the Student and Course, then create a many-to-many relationship from the mapping, and you can simply retrieve the Courses from a Student instance.
Also, you can use cascading operations more freely when using a mapping instead of writing some SQL statements in your code.