What is an example of an inverse relationship in Apple's Core Data framework?
(Better late than never)
When you have 2 or more entities then you can have a relationship. Say for example , there are 2 entities: Book and Publisher. We have a very simple relationship between them as:
Every book has a publisher and a publisher may publish many book.
(In coredata , relationship is not an entity like in RDBMS. Infact relationship is a part of 1 entity. Relationship between A and B in coredata means , A store the reference of another entity. So, when the managed object is created from the entity A,then relationship will become a property of any object created from entity A.)
In the above example, book to publisher is one-to-one relationship and from publisher-to-book is one-to-many. That means book and publisher has two way relationship no matter it's 1-to-1 or 1-to-many , this bidirectional relation is set to inverse in coredata.This kind of relation is known as inverse relation. If you set the book as a inverse to publisher then automatically publisher becomes inverse of book.
It's not technically essential but highly recommended by apple.If one is changed another is affected. What this let us do is keep the object graph more controlled and consistent.Most relationships are bidirectional like this.
Source: Lynda.com
There's one simple explanation: http://brandontreb.com/core-data-quicktip-inverse-relationships/
Definition from Google:
"in·verse
ˈinvərs,inˈvərs
adjective
1.
opposite or contrary in position, direction, order, or effect.
"the well-observed inverse relationship between disability and social contact"
noun
noun: inverse; plural noun: inverses
1.
something that is the opposite or reverse of something else.
"his approach is the inverse of most research""
What you are looking for from Apple:
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CoreData/TroubleshootingCoreData.html#//apple_ref/doc/uid/TP40001075-CH26-SW1
"Core Data uses inverse relationships to maintain referential integrity within the data model. If no inverse relationship exists and an object is deleted, you will be required to clean up that relationship manually."
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CoreData/HowManagedObjectsarerelated.html
"Inverse Relationships
Most object relationships are inherently bidirectional. If a Department has a to-many relationship to the Employees who work in a Department, there is an inverse relationship from an Employee to the Department that is to-one. The major exception is a fetched property, which represents a weak one-way relationship—there is no relationship from the destination to the source. See Weak Relationships (Fetched Properties).
It is highly recommended that you model relationships in both directions, and specify the inverse relationships appropriately. Core Data uses this information to ensure the consistency of the object graph if a change is made (see Manipulating Relationships and Object Graph Integrity)."
A great example is the second answer here and it should be upvoted:
Does every Core Data Relationship have to have an Inverse?
Try this (First google result for 'Core Data relationship tutorial iphone') :
http://www.raywenderlich.com/934/core-data-tutorial-getting-started
Related
I want to model an airport and a city and would like to choose the appropriate decomposition relationship between the two but I cant seem to make up my mind which one to choose as they both have different relationships.
A City can exist on its own and does not require an airport hence I would say that City-Airport link is an aggregation however...
An Airport requires a City and will not exists without one making it a Composition relationship.
Is it possible to have two relationships? One which is City -> Airport and the other being Airport -> City it does feel strange however since a Composition to me feels like a relationship which should be honoured by two people and not just one.
It's a widespread misunderstanding that the relationships between classes are primarily either "aggregations" or "compositions". I think this unfortunate tradition has been extablished in the C++ community.
Rather, the most important kind of relationships between classes are "associations", as they are called in UML class models/diagrams. So, if you want to model the relationship between Cityand Airport, you probably want to choose a one-to-many association (since a city may have more than one airport, but any airport is assigned to a city).
In UML, both aggregations and compositions are special cases of associations, used for expressing a part-whole relationship between the instances of both classes. Since an airport is not really a part of a city, but just related to it, there is neither a Composition nor an Aggregation between Cityand Airport, but just a plain Association.
In many cases, where we may wonder if an association is a composition, it is safer to model it as a plain association.
The only good reason for modeling an association as a composition is when the instances of the component type are "weak entities" not having their own identity (object ID). But airports do have their own ID, so there is no need, and no gain, to model them as components of a city.
Let's say you have a many to many relationship between two entities and you use MagicalRecord to manually tie them together.
IE: A Vet has many Pets and a Pet has many Pets
In the code, do you need to add the entity on both sides of the relationship;
ie:
[vet1 addPetObject:cust1Pet1];
[vet1 addPetObject:cust1Pet2];
[vet1 addPetObject:cust1Pet3];
[cust1Pet1 addVetObject:vet1];
[cust1Pet2 addVetObject:vet1];
So, do I need to add the pet object to the vet, and then add the vet to the relevant pet object -- or will Core data / Magical record handle this relationship and tie them on both sides by itself?
Many thanks.
If the relationships are defined as inverse relationships of each other in the Core Data
model inspector then you need only set one of them. Core Data will automatically update
the inverse relationship. (This is in fact unrelated to MagicalRecord.)
I have a Proffesor table in a database. I would like to create an UML diagram for the code-behind part.
The class structure would be:
- a Proffesor class that maps the information from the database table (id, first name, etc)
- a ProffesorDAL class which connects to the DB and queries it in order to add,remove,update Proffesor instances
- 3 forms which add/delete/update proffesors, by accesing the ProffesorDAL class
I thought that the forms-ProffesorDAL relationship is a composition relationship. Is this correct?
How about the ProffesorDAL-Proffesor relationship, could it be aggregation or is it just association? What's the best UML relationship for the forms-Proffesor relationship?
Thanks!
I'd start by assuming association and from there to analyse and design if there should be a stronger relation between the two.
My question goes "Does it own it". Example I'd say a Car owns 4 wheels (among a long list of other items).
In my standard design I have a BLL between my UI and DAL. I start by assuming a loose association between my three, later I reach the conclusion that the BLL and DAL are somewhat closely connected and could benefit from a strong tie.
As for the Professor class, I assume this to be a Model class. Model classes I only have a loose connection / knowledge to - meaning they appears only as parameters (association). My DALs do not have a strong connection with my Model classes (aggregation). They are but Message bringers, complex ints and bools.
The UML Aggregation relationship is almost worthless - it creates far more confusion than value. It has only one useful property, namely that if used in a recursive relationship, the resulting object structure is acyclic.
It's really not worth getting hung up about. My advice would be to use a simple binary association and concentrate on getting the cardinality right. That's a lot more useful and valuable.
hth.
I want to understand the difference between composition and aggregation relationship.
Does anyone know a site that explains the UML class diagrams for all relationships?
Composition and aggregation have to do with cascading delete behavior.
Do the child objects have a life of their own beyond the parent? If yes, you need aggregation.
If the parent is deleted, do the children need to be deleted as well? If yes, you need composition.
So let's say you have a model where there's a School class, a Building class, and a Student class. A School has a one-to-many relationship with Building and a one-to-many relationship with Student.
The School-to-Building relationship is an example of composition. If you close the School, you might decide to bulldoze the buildings.
The School-to-Student relationship is aggregation. If you close the school, you certainly won't decide to murder all the Students.
You can read what Uncle Bob Martin has to say about it here.
The difference lies in the lifetime of the parts of an object.
If the parts can live independently from the parent, then you have an aggregation.
If the parts's lifetime are controlled by the parent it is a composition.
The composition can be seen as a special case of an aggregation.
According to The UML User Guide (glossary):
composition: A form of aggregation with strong ownership and coincident lifetime of the parts by the whole
Both aggregation and composition represent "has a" relationships. The difference between the two is that composition refers to exclusive ownership. For instance, a transaction "has a" transaction ID number, and that transaction is the only transaction that has that transaction ID number, the ID number is exclusive to the transaction. A transaction also "has a" transaction date, but many transaction might also have that same transaction date. Since the transaction date can be shared among multiple transactions it is not exclusive.
When you are drawing these two relationship types on a UML class diagram a composition relationship would be represented with a filled in diamond where a aggregation relationship would be represented by a diamond which is not filled in.
The book Introduction to Java Programming covers this subject in great detail.
I have a 1-to-many relationship in a Core Data graph, and I'm trying to understand the difference between using a CoreDataGeneratedAccessors method and a simple assignment to alter a relationship. For example, the Core Data Programming Guide has a department and employee example. In that example they use the CoreDataGeneratedAccessors to hire and fire employees:
[aDepartment addEmployeesObject:newEmployee];
[aDepartment removeEmployeesObject:firedEmployee];
They don't define an inverse relationship, but say "department" is the inverse relationship to "employees". Should the following then accomplish the same thing?
newEmployee.department = aDepartment
firedEmployee.department = nil;
According to the Manipulating Relationships and Object Graph Integrity section of the Core Data Programming Guide, the later examples should automatically fix all relationships to maintain graph consistency. If that's the case, is there any reason to use the CoreDataGeneratedAccessors when an inverse relationship exists? Does using the CoreDataGeneratedAccessors maintain graph consistency on inverse relationships?
They don't define an inverse
relationship, but say "department" is
the inverse relationship to
"employees". Should the following then
accomplish the same thing?
Both operations have the same result no matter which end of the relationship (with inverse) you modify.
If that's the case, is there any reason to use the CoreDataGeneratedAccessors when an inverse relationship exists? Does using the CoreDataGeneratedAccessors maintain graph consistency on inverse relationships?
Consistency is not an issue with both methods.
For performance reasons it is very important to modify large relationships with apropriate methods.
Solution 1 (firing all employees of a department)
for (Employee* employee in aDepartment.employees)
{
employee.department = nil
}
Solution 2
aDepartment.employees = nil;
The first solution would trigger an update of a (table-)view after each operation while the second would result in exactly one update of all views.
This can be a big difference if you handle a a large amount of objects.
If you need more in depth information, I think similar topics have already been discussed on SO.