Leaving the Inverse field with the value No Inverse Relationship gives you two compiler warnings: consistency error and misconfigured property.
You can ignore these warnings and run your application without specifying an inverse relationship—after all, these are compiler warnings, not compiler errors—but you could face unexpected consequences. Core Data uses bidirectional relationship information to maintain the consistency of the object graph (hence the Consistency Error) and manage undo and redo information. If you leave a relationship without an inverse, you imply that you will take care of the object graph consistency and undo/redo management. The Apple documentation strongly discourages this, however, especially in the case of a to- many relationship. When you don’t specify an inverse relationship, the managed object at the other end of the relationship isn’t marked as changed when the managed object at this end of the relationship changes. Consider the example of a Player object being deleted and having no inverse relationship back to its team. Any optionality rules or delete rules aren’t enforced when the object graph is saved.
stackOverflow:是否一定要inverse,没有inverse,什么情况下会有麻烦
http://stackoverflow.com/questions/764125/does-every-core-data-relationship-have-to-have-an-inverse
The League Manager application, for example, sets the Delete Rule for the “players” relationship in the Team entity to Cascade so that deleting a team would delete all the players related to it. If you set that rule to Deny and a team had any players, trying to delete the team would result in an error on any attempts to save the context with the message “team is not valid.” Setting the Delete Rule to Nullify would preserve the players in the persistent store, though they would no longer belong to any team.
The No Action option represents another way, such as not specifying an inverse relationship, that Core Data allows you to accept responsibility for managing object graph consistency. If you specify this value for the Delete Rule, Core Data allows you to delete the source object but pretends to the destination objects that the source object still exists. For the League Manager application, this would mean disbanding a team but still telling the players to show up for practices and games. You won’t find many compelling reasons to use the No Action setting, except perhaps for performance reasons when you have many destination objects. Chapter 7 discusses performance tuning with Core Data.