I'm developing a simple iOS application with the following database setup. There is an Athlete entity which has a many to many relationship with Workout. Workout has a to many relationship with Workout Scores. Athlete<<->>Workout<->>Workout_Scores. I think i've set up my model incorrectly though. I was thinking athletes can share workouts (e.g. multiple athletes have the same workout object), or, an exercise may be exclusive to one person. However, the exercise score is strictly for one athlete, not shared. You can have up to 1 score for each workout. 2 athletes can have the same workout, but their score should be separate. Did I set up my model correctly? Should the score entity be related to athlete, not workout?
It sounds like you want to use Workout_Scores as a sort of join table (although that of terminology isn't appropriate for an object-graph framework like CoreData). Your Workout_Scores entity should have two to-one relationships to Athlete and Workout. Athlete should have a to-many relationship to Workout_Score (an athlete may have many workout scores), and Workout should have a to-many relationship to WorkoutScore (a workout may have many workout scores that originated from a single or from many different athletes).
Here's what I propose for your data model:
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.
In the example of using "intermediate join entity"
To find out who one person’s friends are, you have to aggregate all the friend destinations of the friends relationship, for example:
NSSet *personsFriends = [aPerson valueForKeyPath:#"friends.friend"];
Is above line of code getting a given person's MUTUAL friends? or just ONE-WAY friends, which means only getting "peoples who are treated by this given person as his friends"?
I am not certain, because "To find out who one person’s friends are" sounds like ONE-WAY friendship (that could be why there is a strange relationship befriendedBy represents those who count the source as their friend. FriendInfo represents information about one friendship, “in one direction.” .)
This is a really confusing example. There are two possibilities.
In most cases being "friends" is a mutual thing. In this case you would have a self-referencing many-to-many relationship of a Person, perhaps called friends. The relationship would be mutual.
You seem to be implying that it is possible to add another person as a friend even if that person is does not reciprocate. In order to lift the confusion give this many-to-many relationship another distinct name, e.g. contacts. This would be the Persons that have been added unilaterally. In Core Data, all relationships are best modelled as mutual, so you can use another relationship potentialFriends that is the inverse relationship of contacts. Maybe there are better names, but you get the idea.
The intermediate join entity is only necessary if you want to store additional attribute with a particular relationship, e.g. the date a contact request was made. In this case, you would have the join entity e.g. friendLink, which would have a to-one relationship to two distinct Persons. You can model the state of the link (unilateral or mutual) in this entity.
Below is an illustration of the kind of data I want to save in Core data. Every city has many schools , every school has many grades and every grade has many students and their details.
I have read a couple of things about Core data and have got it up and starting. But I'm not able to understand how to save an array in core data and is it a good way to do that in the similar case of the illustration?
If i want to save for a particular school an array of total students for that particular grade, would it be a good practice? If yes, is the method provided in this link good to follow?
EDIT : All cities, all schools and all students have same attributes. Whereas each grade has different attributes. So if there are data for 10 grades, there may be 10 types of array for grades.
Also, what if i have a one to many relation between school and students? IE depending on my login i decide whether i need to save school and grades or school and students. How would the relationship be now?
You should use core data with one to many relationship. This would be your entity structure.
UPDATE:
In case you have several grades with different attributes, you can define another entity "GradeType", which contains details of each grades
UPDATE 2:
Let me write down considerations in this scenario.
1. A city can have multiple schools in it, but a school can be only in one city (Branches will have different address ;) ).
2. A school may offer multiple subjects. same subject can be taught in multiple cities.
3. A school may contain multiple students while a student can be enrolled only in one school.
4. A student can register for multiple subjects, while same subject can be registered by multiple students.
5. There can be multiple grades possible for a subject.(lets say 4: A, B, C & D). Similarly, many subjects will follow the same grading system.(A in history, B in Geology etc).
6. A student can have multiple grades. However, the number of grades will be equal to number of subject he/she opted for.
Based on above consideration, this would be your dataModel.
Here Grades Entity will have entries like this:
grade A for physics is scored by these students.
grade A for biology is scored by these students.
…
…
grade B for physics is scored by these students.
grade B for biology is scored by these students.
…
… N So on
Let me know if more info needed.
Dont do it the way shown in that link. Create core data entities for each of them (city,school,grade,student). Add relationship between those entities (Eg: City ->> school which means one to many relationships). Check this link http://www.raywenderlich.com/14742/core-data-on-ios-5-tutorial-how-to-work-with-relations-and-predicates. Refer apple document https://developer.apple.com/library/mac/documentation/cocoa/conceptual/coredata/articles/cdRelationships.html as well. Take your time with core data modelling. Hope it helps
I have many questions about how to make relationships N:M in CoreData.
If I have two entities A and B and have a relationship N:M in the entity relationship model has to generate a new table C that will contain the unique id of tables A and B.
Example for the entity relationship:
Now in the database model:
Considering the previous example as would be done by core data?
Or:
The truth is I'm really lost with that of relations in Core Data, any help will be welcome.
Sorry for my English but not very good.
The answer to this is that you have to use "join tables" even in Core Data if you are storing additional information. You do not have to keep track of foreign keys, as this is covered by the relationship.
Typically, standard DB "join tables" have ugly names such as "tableA_tableB". You should strive to find a suitable name to make the concept clear. For example:
Car <<--->> Person
becomes
Car <--->> Rental <<---> Person
Now in entity Rental you can add more information, such as the time. So, for example, if you want to find all persons that rented a car before a certain date (stored as NSDate in the Rental entity), your predicate would be something like this:
[NSPredicate predicateWithFormat:#"ANY rentals.time < %#", cutoffTime]
I am trying to use Core Data to represent a sports league's schedule. Within my model I have an entity called Team and an entity called Game. Each team will have many games. Each game will have two teams, one that is identified as the home team and the other that is identified as the away team.
In my current approach I have defined "homeTeam" and "awayTeam" relationships within the Game entity. Each of those relationships are to-one and have their destinations set to the Team entity. I have also defined a to-many "games" relationship within the Team entity that has its destination set to the Game entity.
The problem with this approach is that I can't set the inverse relationships in any appropriate way. It would require the Team/games relationship to be the inverse of both the Game/homeTeam and the Game/awayTeam relationships, and that isn't allowed (as far as I can tell). I could of course define these as unidirectional relationships but I start getting Xcode warnings and I'm not sure that's a good thing to do here.
I've also considered removing the awayTeam and the homeTeam relationships from the Game entity and replacing it with a teams relationship. That relationship would be many-to-many with Team, with a min and max value of 2. However, the approach doesn't allow me to distinguish between the home team and the away team, which I will need to do in my app.
I'd appreciate any recommendations for the best way to represent these kind of relationships within CoreData. I could no doubt implement this myself using my own DB layer, but I'd rather rely on CoreData than come up with a home-grown solution here.
Here is how I would do it:
Game has two one-to-one relationships, homeTeam and guestTeam.
Team has two one-to-many-relationships, homeGames and outGames. The inverse of homeGames is homeTeam, and the inverse of outGames is guestTeam.
Makes sense?