Before you dive right into the project and add Core Data to it, let's take a look at how Core Data actually works, what it is, and what it isn't. In order to make efficient use of Core Data, it's essential that you know what you're working with.

When you work with Core Data, you're actually utilizing a stack of layers that starts with managed objects and ends with a data store. This is often a SQLite database, but there are different storage options you can use with Core Data, depending on your application needs. Let's take a quick look at the layers involved with Core Data and discuss their roles in an application briefly:

At the top-right of this diagram is the NSManagedObject class. When you use Core Data, this is the object you'll interact with most often since it's the base class for all Core Data models your app contains. For instance, in the app you will build in this chapter, the family member and movie models are subclasses of NSManagedObject.

Each managed object belongs to an NSManagedObjectContext. The managed object context is responsible for communicating with the persistent store coordinator. Often, you'll only need a single managed object context and a single Persistent Store Coordinator. However, it is possible to use multiple persistent store coordinators and multiple managed object contexts. It's even possible to have multiple managed object contexts for the same persistent store coordinator.

A setup with multiple managed object contexts can be particularly useful if you're performing costly operations on your managed objects; for example, if you're importing or synchronizing large amounts of data. Usually, you will stick to using a single managed object context and a single persistent store coordinator because most apps don't need more than one.

The persistent store coordinator is responsible for communicating with the persistent store. In most scenarios, the persistent store uses SQLite as its underlying storage database. However, you can also use other types of storage, such as an in-memory database. An in-memory database is especially useful if you're writing unit tests or if your app has no need for long-term storage. 

If you've worked with MySQL, SQLite, or any other relational database, it is tempting to think of Core Data as a layer on top of a relational database. Although this isn't entirely false since Core Data can use SQLite as its underlying storage, Core Data does not work the same as using SQLite directly; it's an abstraction on top of this.

One example of a difference between SQLite and Core Data is the concept of primary keys. Core Data doesn't allow you to specify your own primary keys. Also, when you define relationships, you don't use foreign keys. Instead, you simply define the relationship and Core Data will figure out how to store this relationship in the underlying database. You will learn more about this later. It's important to know that you should not directly translate your SQL experiences to Core Data. If you do, you will run into issues, simply because Core Data is not SQL. It just so happens that SQLite is one of the ways that data can be stored but the similarities really do end right there.

To recap, all core data apps have a persistent store. This store is backed by an in-memory database or a SQLite database. A persistent store coordinator is responsible for communicating with the persistent store. The object communicating with the persistent store coordinator is the managed object context. An application can have multiple managed object context instances talking to the same persistent store coordinator. The objects that a managed object context retrieves from the persistent store coordinator are managed objects.

Now that you have an overview of the Core Data stack and where all the parts involved with its usage belong, let's add the Core Data stack to the MustC application.