The Managed Object Model is a detailed outline of an application's data types. A Core Data application has at least one Model, and multiple Models can be merged together at runtime. You'll usually want to use Xcode 2.0's visual modeling tool, but you can also create Models in code.

The Model is made up of Entities, which have Properties. Entities are connected to each other by Relationships. Entities are connected to tables and columns in a SQLite database, or fields in an XML file.

The Entity is the most basic building block of a Managed Object Model. It's a description of something you want to store, such as an author or a mailbox. The Entity defines what will be managed by Core Data, not necessarily how it's managed.

If you're a Cocoa programmer, you're used to creating a custom class with instance variables for each data type. With Core Data, you create an Entity with Properties, and map it to a class.

By default, each Entity is mapped to NSManagedObject. It uses the Entity to manage data without custom instances variables and accessors. Entities can be mapped to different classes, but all data classes must inherit from NSManagedObject.

Since the description of data is separate from a class implementation, you can assign multiple Entities to the same class, reducing the overall amount of code in a project. In a sense, each Entity is a different role played by NSManagedObject.

An Entity can be abstract, in which case it is never directly attached to a managed object. An Entity can also inherit Properties from a parent. For example, a SmartMailbox might be a sub-Entity of Mailbox.

A Property is a quality of an Entity. For example, an Author Entity might have name, email and posts Properties.

Each Property is created as a column in a SQLite store, or a field in an XML file.

Property names are used as KVC keys for Managed Objects. For example, you can set the value of an email Property like this:

A Property can be optional. If the user doesn't enter a value for a required Property, the application displays a customizable error. Keep in mind that this also applies if you create or change a Managed Object in code.

If a Property is transient, Core Data won't store it in the data file. This is useful for calculated values, or session-specific information.

There are three kinds of Properties: Attribute, Relationship, and Fetched Property. Most Core Data applications will likely need to use each in some way.

Attribute

An Attribute stores a basic value, such as an NSString, NSNumber or NSDate. Attributes can have default values, and can be automatically validated using length limits and regular expressions. You have to choose a type for most Attributes. Only transient attributes can have an "undefined" type, which means you can use any object as the value.

Relationship

A Relationship is link to one or more specific objects. A to-one relationship links to a single object, whereas a to-many Relationship links to multiple objects. You can set upper and lower limits on the number of objects in a to-many Relationship.

Most Relationships have a mirrored inverse relationship. For example, a Post has a to-one Relationship to its Author, and each Author has an inverse to-many Relationship to all of its Posts.

Fetched Property

Fetched Properties are similar to Relationships, but the objects returned from a Fetched Property are based on a search Predicate. For example, one Fetched Property on Author might be called "unpublishedPosts". The Predicate would be formatted as "published == 0".

Using iTunes as an example, a smart playlist would be equivalent to a Fetched Property, and a normal playlist would be a Relationship.

Since the list of objects is dynamic, you can't use -setValue:forKey: on a Fetched Property.

A Managed Object represents one record in a data file. Each Managed Object "hosts" an Entity which gives it the properties of a certain kind of data.

For example, an "Author object" might just be an instance of NSManagedObject with the Author Entity attached to it. The stock class is quite capable, so you can often use it as is.

Each Managed Object "belongs" to a Managed Object Context. Each object has a unique ID, represented by an instance of NSManagedObjectID. You can use a Managed Object ID to retrieve an object from a Context.

Getting and setting values on Managed Objects is a lot like setting values in an NSDictionary. You just use -valueForKey: and -setValue:forKey:, which fits nicely with Cocoa Bindings and the key-value protocols. Custom subclasses of NSManagedObject should use these KVC messages when possible.

Managed Objects have no actual order in the Context or in Relationships. In fact, the "native" collection class for Core Data is NSSet. You can order the results of Fetch Request using NSSortDescriptors, but the sorting is not saved to the data store.

The Managed Object Context is the "director" of a Core Data application. The Context orchestrates or is involved in practically everything that happens with application data at runtime. In fact, the Context does a lot of work the "MyController" class would typically do.

When a new Managed Object is created, it's inserted into the Context. At that point, the Context starts tracking the object, observing any changes that take place. The Context can then perform undo operations, or talk to the Persistent Store Coordinator to save changes to a data file.

You usually bind controller classes like NSArrayController and NSTreeController to a Context. This enables the controllers to dynamically fetch and create Managed Objects, as well as add and remove objects from Relationships.

Even single-document Core Data applications might store and load data from different locations on disk. The Persistent Store Coordinator handles management of actual data files on disk.

It can add and remove data files on the fly, and project multiple data files as a single storage location. In Core Data, individual data files are called Persistent Stores.

The Managed Object Context can handle data persistence transparently, so only more advanced applications need interact directly with the Coordinator.

A multi-document Core Data application uses NSPersistentDocument, which is a subclass of the traditional NSDocument class. In many cases, you don't need to customize this class at all for your application. The default implementation simply reads the Info.plist file to determine the store type.

A Fetch Request is a self-contained query which is sent to the Managed Object Context. The Context evaluates the request and returns the results in the form of an NSArray.

The only thing a Fetch Request must have is an Entity. If you send a fetch request to the Context with only an Entity, you'll get an array of all known instances of that Entity.

You can supply a Predicate if you want to only return instances that match certain criteria.

Fetch Requests can be reused, so keep commonly-used requests in a dictionary instead of creating a new instance each time. This also makes it easier to tweak application behavior later.

Predicates are used to specify search criteria, and are made up of expressions and nested predicates.

Predicates are used throughout Core Data, but NSPredicate is actually defined in the Foundation framework, and can be used in a number of different ways. For example, Predicates are used to construct Spotlight queries and to sort arrays.

You can either create Predicates using a specialized query language, or you can assemble trees of NSExpressions and NSPredicate objects. Xcode 2.0's visual modeling tool also includes a Predicate editor.

Predicates understand the concept of substitution variables, so you can create a query at any point and easily fill in values at runtime.

Specialized Predicates

A Compound Predicate is the equivalent of AND/OR statements in a SQL database. It effectively combines two nested Predicates into a single master Predicate. For example, a rules-based email filtering system could evaluate multiple rules by inserting multiple Predicates into a single Compound Predicate.

A Comparison Predicate evalatues two NSExpressions with an operator, and returns a result. For example, a Comparison Predicate could be used to find all Authors who posted after April 29.

An Expression is a building block of a Predicate. It represents a value that is used when the parent Predicate is evaluated. Like NSPredicate, NSExpression is a part of the Foundation framework.

An Expression might contain a constant value like 1.68, or it could reference a predefined function (like avg or max), a variable name, or an object key path. A Predicate formatted as "creationDate > YESTERDAY" contains two Expressions: creationDate and YESTERDAY.

In-depth explanations of Predicates and Expressions are beyond the scope of this particular tutorial.