A managed object is associated with an entity description (an instance of NSEntityDescription) that provides metadata about the object and with a managed object context that tracks changes to the object graph. The object metadata includes the name of the entity that the object represents and the names of its attributes and relationships.

In a given managed object context, a managed object provides a representation of a record in a persistent store. In a given context, for a given record in a persistent store, there can be only one corresponding managed object, but there may be multiple contexts, each containing a separate managed object representing that record. Put another way, there is a to-one relationship between a managed object and the data record it represents, but a to-many relationship between the record and corresponding managed objects.

Relationship Definitions in the Managed Object Model

There are a number of things you have to decide when you create a relationship. What is the destination entity? Is the relationship a to-one or a to-many? Is the relationship optional? If it’s a to-many, are there maximum or minimum numbers of objects that can be in the relationship? What should happen when the source object is deleted?

In an object model relationship, you have a source entity (for example, Department) and a destination entity (for example, Employee). You define a relationship between a source entity and a destination entity in the Relationship pane of the Data Model inspector for the source entity, Relationship pane in the Data Model inspector.

Figure 12-1Relationship pane in the Data Model inspector

Manipulating Relationships and Object Graph Integrity

When you modify an object graph, it is important to maintain referential integrity. Core Data makes it easy for you to alter relationships between managed objects without causing referential integrity errors. Much of this behavior derives from the relationship descriptions specified in the managed object model.

When you need to change a relationship, Core Data takes care of the object graph consistency maintenance for you, so you need to change only one end of a relationship. This feature applies to to-one, to-many, and many-to-many relationships. Consider the following examples.

An employee’s relationship to a manager implies an inverse relationship between a manager and the manager’s employees. If a new employee is assigned to a particular manager, it is important that the manager be made aware of this responsibility. The new employee must be added to the manager’s list of reports. Similarly, if an employee is transferred from one department to another, a number of modifications must be made, as illustrated in Figure 12-2. The employee’s new department is set, the employee is removed from the previous department’s list of employees, and the employee is added to the new department’s list of employees.

Figure 12-2Inverse relationship maintaining integrity

Without the Core Data framework, you must write several lines of code to ensure that the consistency of the object graph is maintained. Moreover you must be familiar with the implementation of the Department class to know whether or not the inverse relationship should be set from the employee to the new department. This may change as the application evolves. Using the Core Data framework, all this can be accomplished with a single line of code:

Objective-C

1. anEmployee.department = newDepartment;

Swift

1. anEmployee.department = newDepartment

Alternatively, you can use:

Objective-C

1. [[newDepartment mutableSetValueForKey:@"employees"] addObject:mo];

Swift

1. newDepartment.mutableSetValueForKey("employees").addObject(employee)

Both of these have the same net effect: by referencing the application’s managed object model, the framework automatically determines from the current state of the object graph which relationships must be established and which must be broken.

Many-to-Many Relationships

You define a many-to-many relationship using two to-many relationships. The first to-many relationship goes from the first entity (the source entity) to the second entity (the destination). The second to-many relationship goes from the second entity (the original destination entity) to the first entity (the original source entity). You then set each to be the inverse of the other. (If you have a background in database management and this causes you concern, don't worry: if you use an SQLite store, Core Data automatically creates the intermediate join table for you.)

This relationship configuration works even for relationships where an entity has a relationship back to itself (often called reflexive relationships). For example, if an employee can have more than one manager (and a manager can have more than one direct report), you can define a to-many relationship directReports from the Employee entity to itself that is the inverse of another to-many relationship, managers, again from the Employee entity back to itself. This is illustrated in Figure 12-3.

Figure 12-3Example of a reflexive many-to-many relationship

Modeling a Relationship Based on Its Semantics

Consider the semantics of the relationship and how it should be modeled. A common example of a relationship that is initially modeled as a many-to-many relationship that’s the inverse of itself is "friends." Although you are your cousin’s cousin whether the cousin likes it or not, it’s not necessarily the case that you are your friend’s friend. For this sort of relationship, use an intermediate (join) entity. An advantage of the intermediate entity is that you can also use it to add more information to the relationship. For example, a FriendInfo entity might include some indication of the strength of the friendship with a ranking attribute, as shown in Figure 12-4.

Figure 12-4A model illustrating a friends relationship using FriendInfo as an intermediate entity

In this example, Person has two to-many relationships to FriendInfo: friends represents the source person’s friends, and befriendedBy represents those who count the source as their friend. FriendInfo represents information about one friendship, in one direction. A given instance notes who the source is and one person the source considers to be their friend. If the feeling is mutual, there is a corresponding instance where source and friend are swapped. There are several other considerations when dealing with this sort of model:

• To establish a friendship from one person to another, you have to create an instance of FriendInfo. If both people like each other, you have to create two instances of FriendInfo.

• To break a friendship, you must delete the appropriate instance of FriendInfo.

• The delete rule from Person to FriendInfo should be Cascade. That is, if a person is removed from the store, the FriendInfo instance becomes invalid, so it must also be removed.

  As a corollary, the relationships from FriendInfo to Person must not be optional—an instance of FriendInfo is invalid if the source or friend is null.

• To find out who one person’s friends are, you have to aggregate all the friend destinations of the friends relationship, for example:

  Objective-C

  1. NSSet *personsFriends = [aPerson valueForKeyPath:@"friends.friend"];

  Swift

  1. let personsFriends = aPerson.valueForKeyPath("friends.friend")

• To find out who considers a given person to be their friend, you have to aggregate all the source destinations of the befriendedBy relationship, for example:

  Objective-C

  1. NSSet *befriendedByPerson = [aPerson valueForKeyPath:@"befriendedBy.source"];

  Swift

  1. let befriendedByPerson = aPerson.valueForKeyPath("befriendedBy.source")

Cross-Store Relationships Not Supported

Be careful not to create relationships from instances in one persistent store to instances in another persistent store because this is not supported by Core Data. If you need to create a relationship between entities in different stores, you typically use fetched properties. See the next section.

Weak Relationships (Fetched Properties)

Fetched properties represent weak, one-way relationships. In the employees and departments domain, a fetched property of a department might be Recent Hires. Employees do not have an inverse to the Recent Hires relationship. In general, fetched properties are best suited to modeling cross-store relationships, loosely coupled relationships, and similar transient groupings.

A fetched property is like a relationship, but it differs in several important ways:

• Rather than being a direct relationship, a fetched property's value is calculated using a fetch request. (The fetch request typically uses a predicate to constrain the result.)

• A fetched property is represented by an array (NSArray), not a set (NSSet). The fetch request associated with the property can have a sort ordering, and thus the fetched property may be ordered.

• A fetched property is evaluated lazily and is subsequently cached.

Figure 12-5Adding a fetched property to an entity

In some respects you can think of a fetched property as being similar to a smart playlist, but with the important constraint that it is not dynamic. If objects in the destination entity are changed, you must reevaluate the fetched property to ensure it is up to date. You use refreshObject:mergeChanges: to manually refresh the properties—this causes the fetch request associated with this property to be executed again when the object fault is next fired.

You can use two special variables in the predicate of a fetched property, $FETCH_SOURCE and $FETCHED_PROPERTY. The source refers to the specific managed object that has this property, and you can create key paths that originate with that source, for example, university.name LIKE [c] $FETCH_SOURCE.searchTerm. The $FETCHED_PROPERTY is the entity's fetched property description. The property description has a userInfo dictionary that you can populate with whatever key-value pairs you want. You can therefore change some expressions within a fetched property's predicate or any object to which that object is related.

To understand how the variables work, consider a fetched property with a destination entity Author and a predicate of the form, (university.name LIKE [c] $FETCH_SOURCE.searchTerm) AND (favoriteColor LIKE [c] $FETCHED_PROPERTY.userInfo.color). If the source object had an attribute searchTerm equal to Cambridge, and the fetched property had a user info dictionary with a key color and value Green, the resulting predicate would be (university.name LIKE [c] "Cambridge") AND (favoriteColor LIKE [c] "Green"). The fetched property would match any Authors at Cambridge whose favorite color is green. If you changed the value of searchTerm in the source object to Durham, the predicate would be (university.name LIKE [c] "Durham") AND (favoriteColor LIKE [c] "Green").

The most significant constraint for fetched properties is that you cannot use substitutions to change the structure of the predicate—for example, you cannot change a LIKE predicate to a compound predicate, nor can you change the operator (in this example, LIKE [c]).