Core Data, Part 2: The Data Model

See Part 1 for the start of this series on Core Data.

In the previous article, I talked about the three main elements of Core Data: the Managed Object Model, the Managed Object Context, and the Persistent Storage Coordinator. This article expands on the Managed Object Model, explaining how to easily create the data structures for your Core Data program.

Using the Data UI

Xcode makes it really easy to set up a data structure to use. Once you've created a Core Data project (as discussed in the previous article) all you need to do is click on your .xcdatamodel file, which you'll find in the "Resources" folder of your Groups & Files.

When you click on the file, you'll see a little data editor that features several different elements. Across the top are panels for "Entities" and "Properties". To the right of that is a space for an editing panel that'll be empty until you click on an entity or property. Across the bottom is what looks like a sheet of graph paper; it'll be filled with your interconnected entities when you create them.

The following graphic shows an example of a filled-in data model:

Here's what all the elements are:

Entity. This is an individual data object. In a database it would be a table. In the above example, "Card", "CardText", "CardPics", "CardPower", and "Cardstack" are all entities. To create one you just click the "+" symbol in the entity window. Afterward you'll need to fill it with properties (which includes attributes and relationships).

Property. A property in Core Data is pretty much the same thing as a property in the rest of Objective-C; it's an individual variable within an object (or here, within an entity). There are two types of properties: attributes and relationships. You can create either one by first clicking on an Entity in the entity window, then clicking on the "+" in the property window. You'll be given the option to create an attribute or a relationship.

Attribute. This is a individual variable stored inside an object, which is stored as a sort of property. In a database it'd be a column. Once you've created an attribute (as discussed above, under "property"), you must set its type. This can either be done by clicking in the "Type" column within the property panels or else by clicking generally on the attribute, then filling in data in the editing panel, to the right. Once you've named your attribute and set its type, you're usually done with it ... though some more work is possible.

One of the cool things about Core Data is that you can use it to help manage your variables by setting minimum, maximum, and default values (though these are all optional--unlike the attribute type).

Relationship. A relationship is a connection from one entity to another. It's stored as a type of property. In a database a relationship would be represented by a join from one table to another. The fact that you can just set it up as a relationship in Core Data is another big advantage, because you don't have to worry about giving your tables unique IDs that they can join on, nor do you have to worry about indexing your tables to make their lookups and joins efficient. Instead, you can just deal with the data!

When you create a relationship you'll need to further define it in the editing panel to the right (after you click on the relationship to bring that panel up).

First you must define the Destination. This is the table (entity) that you're joining to.

Then you must define if it is a "To-Many" relationship. If your Entity has a "To-Many" relationship, that means that it's connected with multiple versions of the other entity. For example, imagine that you have three Entities in a model: a magazine Entity, a cover Entity, and a page Entity. Each magazine has a one-to-one relationship with a cover (which doesn't require any additional work: a one-to-one relationship is the default assumption for a relationship) but it has a one-to-many relationship with pages (which requires you to check the "to-many" box).

Usually you'll want to set up a reflective relationship. If one entity links to a second one, the second one should also link to the first. In the above example, the pages should know which magazine they go with. To allow this, set up a relationship in each direction, and then when you're done click on the "inverse" pop-up of one of the two reflective relationships and set it to the other. Where your graph-paper diagram previously showed two arrows, now it should show one (with arrow-heads on each side).

If you look at the graph in the image above, you should now be able to puzzle it out. Each of the five Entities has a number of Attributes and some Relations. The Relations are sometimes one-to-one (with one arrow) and sometimes one-to-many (with two arrows). They're all reflective.

With a good knowledge of these basic ideas in hand, you should now be able to design a data model, just as easily as if you were creating tables in a database.

Creating Entity Classes

With the above methodology, you can create entities that you'll be able to use from within your Objective-C code, accessing and setting properties. However, sometimes you'll want to do more than just read and write data, such as designing special default information, minimums, and maximums that go beyond the simple data that you can enter from the data designer. In order to do this type of work, you'll want to create a class associated with an entity.

To do this, click on an individual entity inside the modeler and then chose "File > New File". You should see as an option for the file type "Managed Object Class". Select that, and you'll be given a list of all your entities. If you click on one, a subclass of NSManagedObject will be created for the entity in question.

The actual use of that new subclass is beyond the scope of at least the next few articles, but keep it in mind when we start talking about the standard stuff that you can have an entity do, as whenever you access an NSManagedObject class that's the exact sort of thing that you can create a special version of.

Next Up: An annoying error.

Comments

[Bob]

Hi,

I have a kind of basic question regarding Core Data and SQLite.

When is the SQLite database created by Core Data?

I have completed the Data Model part as per my needs following your tutorial above. I am using the Windows template with the Core Data templates included in the code.

When I build and run shouldn't the SQLite database appear in my resources folder automatically?? Or does it not work like that?

I've been trying to figure out when/how xcode creates the SQLite database and attach it to my resources folder. Can you give me some guidance? I've spent the last few days trying to figure this out reading countless blogs and forums but I can't get the answer I need.

I can't move forward developing my app without this very crucial step.
Please help! Thanks,

[Shannon Appelcline]

It should be created at run time, and appears out in the directory where your program is dynamically running from (~/Library/Application Support/iPhone Simulator/User/Applications/... when running from the Simulator).

However, worrying about that probably misses out on Core Data's abstraction. Unless you just want to look that your data is being recorded right, you should do all your work through Core Data's functionality.