Learning iCloud Data Management (2014)

Relationships

Simple two-dimensional tables manage simple sets of data. What makes the relational model so powerful is relationships. A relationship is a declarative statement of how two tables can relate to one another. Instead of a names and addresses table, you might have two tables—a names table and an addresses table. A relationship is defined so that, for example, a name in the names table is related to a row in the addresses table where the name field matches the name in the names table. In modern relational databases, relationships can be complex. In SQL, the most widely used language of relational databases, it is SQL queries that implement relationships. As you will see, in Core Data you can specify relationships in the database schema itself.

This description of relationships is fine as far as it goes. In order to actually use relationships, you need to adhere to some best practices and conventions. Most important, if you relate a name in a names table to a name in an addresses table, precisely how do you do it? Names change for various reasons. What happens to your database?

Records in tables often have a unique identifier, which can be used to retrieve that record. The unique identifier should not only be unique: it also should be meaningless. As soon as meaningful data is used for all or part of an identifier, it is subject to the problems that occur when a supposedly unique identifier changes. Even if you believe you have meaningful data that is unique and will never change, chances are your assumptions are wrong. It is not unheard of for an adult to learn that his or her birthday was actually one day earlier or later than was supposed. You can often spot identifiers that are likely to cause problems. As soon as you spot an identifier such as M-0805-20130224-pink, you should be able to tell that you’re looking at data, not a unique and meaningless identifier.

If you make it a practice to have a unique and meaningless identifier in each record, you can use those identifiers in relationships. The relationship will then be immune to changes in the relationship being changed by data changes. Of course, you do need to decide what the relationship that you desire is. Do you want to relate this object to that object in all cases? Or do you want to relate this object to that object based on a data value (which could be a nonunique name)?

Many database designers make it a practice to include a field in every record for a unique identifier. Sometimes it is called id; sometimes it is called zzID. (The latter convention means that when you look at fields in alphabetical order, maintenance fields such as this one sort at the bottom of the list. Furthermore, using zzID rather than zID means that your unique identifier won’t show up next to a valid field such as zipCode that is not a maintenance field.)

Whatever it is called, your unique and meaningless identifier is also called a key; in fact, it is called a primary key. Any field that is used to retrieve rows from a database table is a key. A primary key is always present and is unique.

When you use this style of database design, it is easy to create a relationship. You relate the primary key in one table (such as names) to a field key in another table (such as addresses). Often, the field that is used in the relationship has a standard name, such as nameID. You relatenameID in addresses to id in names, and the relationship is created. The nameID field in the addresses table is a foreign key: you use it to find which record in the names table you want to find to complete the relationship.

In Core Data, you draw the relationships in the data model editor. Behind the scenes, the primary keys are created and managed for you.

This describes the simplest kind of relationship. A relationship can also have multiple members. For example, one person (a name) can have multiple addresses or telephone numbers. While each name in the names table has a unique value for its primary key, in the addresses table, several rows can have the same value for nameID. That would mean that all of those addresses are related to the same name. This type of relationship is called a one-to-many relationship or a many-to-one relationship, depending on which side you’re looking at.

You can also have many-to-many relationships. Perhaps three members of the same family share two addresses (perhaps one is for weekends and the other for weekdays). In this case, a third table is used to implement the relationship (it’s called a join table). Usually, the join table has two fields (or columns). One is the nameID and the other is the addressID. To find all the addresses for a given name, you retrieve all of the join table records for that name. That will give you all of the addressIDs.

There is much more to relationships, but these basics can get you started with Core Data and iCloud.

Normalizing Data

Relationships are frequently used together with normalization in a database schema. Some people compare normalized data to the old saw, “a place for everything and everything in its place.” The old saw is remarkably applicable to the concept of normalization. For example, if you have a large database, you should be able to find the field in a specific table where a person’s address is stored. There should not be two fields in the database where that data is stored for the same person.

But there is more to normalization than this. There are, in fact, three basic forms of normalization. They are implemented in sequence (in other words, third normal form requires compliance with first and second normal forms), and generally, all three are implemented in well-designed databases.

First Normal Form: Eliminate Repeating Groups

If you have a names table and an addresses table, the relationship between them eliminates a potential normalization problem. In many cases, the first try at a database design might be simply a names table. Within that table, you could have an address for the person. So far, that’s normalized data.

However, if you decide that you want to allow a person to have two addresses (home and work, perhaps), you would add fields such as workAddress and homeAddress. These are both address fields: that’s the repeating group referred to in first normal form. There are many problems with this structure. For starters, if a person has only one address, you’re wasting space for the second address in every record. (Modern databases often have internal code to minimize the waste, but it still is present to one degree or another.) Perhaps more significant is that as soon as you decide you need two addresses, you preclude a third or fourth address.

Thus, the way to achieve first normal form is to split a table into two and use a relationship so that names are in one table and addresses are in a related table.

Second Normal Form: Eliminate Redundant Data

The second normal form is the “place for everything” rule. If you have a names table and an addresses table, you would not store the name in both places . . . usually. Sometimes, normalizing a database involves splitting up tables and using relationships, but sometimes it means modifying the data descriptions themselves.

You might decide not to store a person’s name in both the names and the addresses table, but perhaps you want to store the name to use in the context of an address. For a work address, the name might be Miss Marmelstein, and for a home address it might be Yetta or Tessye. You can make the database compliant with second normal form by changing the name field in the addresses table to something like nameToUseForThisAddress.

Third Normal Form: Eliminate Fields Not Dependent on the Key

The third normal formal is a precise way of saying that you should eliminate fields that can be calculated. For example, if you store a street address, in many environments the postal code is calculable.

Denormalizing Data

Sometimes, you deliberately denormalize data. For purposes of performance, sometimes you want to take a nicely normalized database scheme with separate names and addresses tables and combine them into a nonnormalized table for display purposes.

Understanding How Core Data Works with iCloud

iCloud works differently with Core Data than it does with other technologies. The data is not duplicated on iCloud as well as on the shared devices. Instead, there is a local Core Data store on each device, and the changes made on each device are uploaded to iCloud and then automatically downloaded to each device where they are applied to the local store. This avoids moving large databases back and forth.

Core Data works with a persistent store that is usually a SQLite database. That persistent store can be placed in two types of locations:

Shoebox or central library apps place the database out of user sight. On OS X, they are typically in the user’s /Library/ApplicationSupport/<your app name> directory. A single database stores all of the app’s data on the device. iPhoto is an example.

For document-based apps, the database is part of a document’s package.

iCloud works with shoebox apps on iOS or OS X; it works with document-based apps based on UIManagedDocument in iOS. Apple’s advice on the matter is, “On Mac OS X, there is no built-in support for document-based apps that want to use Core Data with iCloud, and writing such an app will require a non-trivial amount of work.” Accordingly, this book focuses on shoebox apps for both operating systems as well as document-based apps for iOS.

Introducing the Core Data Project

This chapter starts to build the Core Data project. It is the same basic project that has been used in previous chapters, but now it uses Core Data and iCloud syncing. In part because it uses Core Data, it can be much more fleshed out than the previous examples. It does address the same issue. Using this app, you can inspect items in the field, such as swings in a playground or trees in a public garden. You can update their status (OK, needs fixing, needs pruning, and so forth), and you can add notes. This project creates a shoebox app that synchronizes through iCloud with mobile devices and Macs.