Core Data and Swift: Data Model

Introduction

In the first article of this series, we learned about the Core Data stack, the heart of a Core Data application. We explored the managed object context, the persistent store coordinator, and the managed object model.

This article focuses on the data model of a Core Data application. We zoom in on Xcode's data model editor and we take a look at entities, attributes, and relationships.

Prerequisites

What I cover in this series on Core Data is applicable to iOS 7+ and OS X 10.10+, but the focus will be on iOS. In this series, I will work with Xcode 7.1 and Swift 2.1. If you prefer Objective-C, then I recommend readingmy earlier series on the Core Data framework.

1.Data Model Editor

Start by downloading the project from theprevious tutorialor clone the repository fromGitHub. Open the project in Xcode and, in theProject Navigator, search forCore_Data.xcdatamodeld. Xcode automatically shows the data model editor when the project's data model is selected.

2.Entities

Before we explore the editor's user interface, we need to create an entity to work with. At the bottom of the data model editor, click theAdd Entitybutton. This will add an entity with nameEntity. It will show up in theEntitiessection on the left of the data model editor. Change the entity's name toPersonby double-clicking it in theEntitiessection.

"What is an entity?" you may be wondering. To bring back the database analogy, an entity is comparable to a table in a database. When you select thePersonentity, you see that an entity can have attributes, relationships, and fetched properties. Don't worry about fetched properties for now, they're a more advanced feature of the framework.

3.Attributes

Give thePersonentity an attribute by clicking the plus button at the bottom of theAttributestable. Double-click the attribute's name and set it tofirst. From theTypedrop-down menu, selectString. If we compare this to a table in a database, thePersontable now has a columnfirstof typeString.

Even though I don't want to confuse you by comparing entities with tables of a database, it makes it easier to understand what entities and attributes are. In fact, if you use a SQLite database as the backing store of your application, Core Data will create a table for you to store the data of thePersonentity.However, this is something we don't have to and should not need to worry about. Remember that Core Data is not a database.

The same goes for relationships. How Core Data keeps track of relationships is something we don't need to worry about. In fact, Core Data makes sure relationships are only loaded when the application needs them. This is something we'll revisit later in this series.

Add two more attributes to thePersonentity,lastof typeStringandageof typeInteger16. The type you choose for numbers is not important at this point. It tells Core Data how it should structure the persistent store and optimize it for performance.

Attribute Options

The attribute of an entity can be configured through theData Model Inspector.Select thefirstattribute of thePersonentity and open the inspectoron the right. The Data Model Inspector lets you configure the selected attribute. At this point, we're only interested in a few settings,Optional,Attribute Type, andDefault Value.

Optional

Marking an attribute as optional means that the attribute can be empty or left blank for a record. In our example, however, we want to make sure everyPersonrecord has a firstname. With thefirstattribute selected, uncheckOptionalto mark it as required. New attributes are optional by default.

Marking an attribute as required has consequences though. If we save aPersonrecord without a valid first name, Core Data will throw an error. This means that we need to make sure that the record'sfirstattribute is set before saving it.

Attribute Type

The attribute type is important for several reasons. It tells Core Data in what format it should save the attribute and it will also return the attribute's data to us in the specified format. Each attribute type has a different set of configuration options. Change the attribute type of thefirstattribute toDateto see the configuration options for an attribute of typeDate.

Default Value

Several attribute types, such asStringandDate, have aDefault Valuefield you can set. This is convenient, for example, if an attribute is required and you want to ensure the attribute for a record has a valid value when it's inserted in the database.

Note that the default value is only used when a new record is created. If an existingPersonrecord, for example, is updated by setting thefirstattribute tonil, then Core Data won't populate thefirstattribute with the default value. Instead Core data will throw an error, because we marked thefirstattribute as required.

4.Relationships

Core Data really shines when you start working with relationships between entities. Let's see how this works by adding a second entity namedAddress. TheAddressentity has four attributes of typeString,street,number,city, andcountry.

Relationships between entities have a number of defining characteristics, the name, the destination, the cardinality of the relationship, the inverse relationship, and the relationship's delete rule.

Let's explore relationships in more detail by creating a relationship between thePersonandAddressentities.

Name, Destination, and Optionality

Create a relationship by selecting thePersonentity and clicking the plus button at the bottom of theRelationshipstable. Name the relationshipaddressand set theDestinationto theAddressentity. This indicates that each person record can be associated with an address record.

As with attributes, relationships are optional by default. This means that no validation error will be thrown if a person record has no relationship with an address record. Let's change this by unchecking theOptionalcheckbox in theData Model Inspectoron the right.

Inverse Relationship

At the moment, the person can have a relationship with an address record. However, if the person has an address record associated with it, the address record does not know about the person record, because the relationship is one-way at the moment—fromPersontoAddress. Most relationships in Core Data, however, are two-way, both entities know about the relationship.

Let's create the inverse relationship from theAddressentity to thePersonentity by selecting theAddressentity and creating a relationship namedpersonwith thePersonentity as its destination.

Even though we created the inverse relationship betweenAddressandPerson, Xcode gives us a few warnings telling usPerson.addressshould have an inverseandAddress.person should have an inverse. Did we do something wrong?

Core Data isn't clever enough to know which relationship is the inverse relationship of which relationship. This is easy to fix though. Select thePersonentity and set theInverseof theaddressrelationship toperson, thepersonrelationship. If you now select theAddressentity, you'll see that the inverse of theaddressrelationship has already been set to thepersonrelationship.

Data Model Graph

When the data model gains in complexity, relationships can become confusing and unclear. Xcode has your back covered though. Thedata model editor has two styles,tableandgraph. In the bottom right of the editor, you should see a toggle, Editor Style,that lets you switch between the two styles. Click the button on the right to switch to the graph style.

The graph style shows you the object graph we've created so far. It shows us the entities we've created, their attributes, and their relationships. One of the most useful features, however, is the visual representation of the relationships between the entities of the data model. A line with an arrow at each end connectsPersonandAddress, symbolizing their two-way relationship.

To-Many Relationships

The relationships we've created so far areto-one relationships, a person can have one address and vice versa. However, it's possible that several people live at the same address. How would we include this extra information in the data model?

A relationship's cardinality specifies if it's a to-one or to-many relationship. Let's change thepersonrelationship of theAddressentity to make it a to-many relationship. Select thepersonrelationship of theAddressentity, change its name topersonsto reflect the to-many relationship, and set the relationshipTypetoTo Manyin the inspector on the right.

The name of the relationship isn't important, but it shows that it's a to-many relationship. Notice that the data model graph updates automatically. The relationship endpoint to thePersonentity has two arrows to symbolize the to-many nature of the relationship.

Many-To-Many Relationships

Wait a minute. Isn't it possible that a person is associated with more than one address? A person can have a work address and a home address. Right? Core Data solves this by creating amany-to-manyrelationship. Select theaddressrelationship of thePersonentity, change its name toaddresses, and set the relationshipTypetoTo Many. The data model graph shows the updated relationship as a line with two arrows on both ends.

Reflexive Relationships

The way Core Data implements relationships is very flexible. The destination entity of a relationship can even be the same as the source entity. This is known as areflexiverelationship. It's also possible to have multiple relationships of the same type with different names. A person, for example, can have a mother and a father. Both relationships are reflexive with the only difference being the name of the relationship.

Delete Rules

What happens when the record on one end of the relationship is deleted? If you were to think about Core Data as a database, then the answer would be obvious. Core Data, however, isn't a database.

Assume you have anAccountentity with a to-many relationship to aUserentity. In other words, an account can have many users and each user belongs to one account. What happens when you delete a user? What happens when you delete an account? In Core Data, each relationship has a delete rule that makes it clear what happens in these situations.

Delete rules make sure you don't have to worry about explicitly updating the persistent store when a record is deleted. Core Data takes care of this to ensure the object graph remains in a consistent state.

Select theaddressesrelationship of thePersonentity and open the inspector on the right. TheDelete Rulemenu has four options,No Action,Nullify,Cascade, andDeny.

No Action

If you selectNo Action, Core Data doesn't update or notify the source record of the relationship. This means that the source record of the relationship still thinks it has a relationship with the record that was deleted. This is rarely what you want.

Nullify

This option sets the destination of the relationship to null when the destination record is deleted. This is the default delete rule of a relationship. You could apply this delete rule if, for example, a relationship is optional.

Cascade

If the relationship fromPersontoAddressis set toCascade, deleting a person record will also delete any address records that are associated with the person record. This is useful, for example, if a relationship is required and the record cannot or shouldn't exist without the relationship. A user, for example, shouldn't exist if it's not associated with an account.

Deny

In a sense,Denyis the inverse ofCascade. For example, if we have anAccountentity that has a to-many relationship with aUserentity with its delete rule set toDeny, an account record can only be deleted if it has no user records associated with it. This ensures that no user records exist without an account record.

Conclusion

In this tutorial, we've taken a closer look at the data model used by a Core Data application. You should now be familiar with entities, attributes, and relationships, and you should be able to create them using Xcode's data model editor.

Core Data is very good at managing relationships and Xcode's data model editor makes it easy to create and manage relationships between entities. Relationships between entities are powerful and easy to configure. Delete rules ensure that the object graph Core Data manages remains healthy and in a consistent state.

In the next article, we get our hands dirty and start working with Core Data. You'll learn how to create, read, update, and delete records, and become familiar withNSManagedObjectandNSFetchRequest.