ですが、まず理解する事でこれからの作業が分かりやすくなる(はず？)です!!

ってことで、引き続きデフォルトで作成されたプロジェクトを検証していきます。

前回までのエントリでコードとして書かれている核の部分はある程度理解できたと思うことにして^^;
今回は、
どのように<NSManagedObjectModel>(データの設計図)が作られるのか
を見ていくことにします。

それでは、今まで見てきた『TodoCoreプロジェクト』を開きましょう。

注意：投稿者自身もCoraDataについて勉強中のため、このシリーズには誤りが含まれている可能性があります。もし、間違いに気付かれた方はコメント欄もしくはtwitterなどでご指摘いただけると幸いです<(_ _)>
また、開発環境はXcode3.2.3 iPhone SDK 4です。実機でのテストなどは自己責任でお願いいたします。
　
　
1. データを設計するデータモデリングツール

まず、<グループとファイル>ペインの<Resouces>グループにある<TodoCore.xcdatamodeld>を見てみます。

今以下のように表示されているのが、データモデリングツールと呼ばれるものです。

CoreDataのモデリング、つまりデータの設計は、主にこのViewの中で行われます。

分かりやすくするために、

と呼ぶことにしましょう。
　
　
見て分かる通り、この4つのビューはすべて同じモデルの情報を示しています。
そして、モデリングビューに青い角丸で囲まれた物が<エンティティ>と呼ばれるモデルになっています。

もう少し説明すると<エンティティ>とは、
単一のデータの単位であり、
その中にAttribute(属性)やRelationship(他のエンティティとの関連)を持っています。

つまり、単一のデータの設計図になる物です。
　
　
2. エンティティとNSManagedObjectModelの違い

以前に、

<NSManagedObjectModel>とは、データの設計図のようなもの。

と書きましたが、

<エンティティ>が単一のデータの設計図であるのに対して、<NSManagedObjectModel>は複数の<エンティティ>の集まりやつながりを設計したもの。

と考えると良いのではないかと思います。
(このサンプルではエンティティがひとつしか無いので分かりにくいですが。)

もっと噛み砕いて説明すると、

という事になります。

このモデリングビューで言うと、
<エンティティ>は角丸の中のもので、<NSManagedObjectModel>はこの方眼上のすべて。という事です
　
　
3. モデリングされたデータと実装ファイルのコード

実はこの<Eventエンティティ>は、『Study CoreData 1,2』で登場した”良いヤツ”フェッチリクエストに渡されていた名前(entityForName:)と同じになっています。

NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init];

NSEntityDescription *entity =
　[NSEntityDescription entityForName:@"Event" 
　　　　　　inManagedObjectContext:self.managedObjectContext];

[fetchRequest setEntity:entity];

さらに、そのEventエンティティの中の<Attribute>にある<timeStamp>も
“並び替えの達人”<NSSortDescriptor>に渡されたKeyと同じです。

NSSortDescriptor *sortDescriptor = 
　[[NSSortDescriptor alloc] initWithKey:@"timeStamp" ascending:NO];

ですが、実はこのエンティティの中には実際のデータ(生データ)は何も入っていません。
つまり空っぽの状態ですが、エンティティは『そこにどんなデータが入るのか』を決めているだけのものなので、実際のデータはアプリを操作していく中でユーザーによって決定されていくものになります。
(そして、エンティティの情報を元にデータをオブジェクト化したものが<NSManagedObject>になります。)
　
　
コードを見ていく中ではまだ触れていませんでしたが、このプロジェクトのデフォルトの状態で＋ボタンをタップする度にひとつの<Eventエンティティ>(のデータオブジェクト)が作られて、その属性である<timeStamp>(つまりタップした時間)が記憶され、テーブルビューに新しい順にソートされ表示される…という仕組みになっています。
　
　
…とここまでは何となく分かったのですが、『追加ボタンを押したら押した時間が表示される』機能だけではまともなアプリは作れませんよね。

ってコトで、実際にTodoアプリを作るためのデータを設計していってみるとしましょうか。
　
　
4. 試しに作ってみる。

と、ちょっと待ってくださいっ!!

実は他の.hや.mのファイルと違って、このままこのファイル(TodoCore.xcdatamodeld)に手を加えると、アプリが起動しなくなってしまうんです！

実はシミュレータや実機のアプリを一旦削除した上で再ビルドすれば起動するのですが、それは面倒ですし、もしリリースした後に変更した場合はすべてのユーザーに一旦アプリを削除してもらわないといけなくなってしまいます。
クラウドなどとの同期機能を採用していなければ、それまでユーザーが蓄積したデータも消えてしまいかねません。

それではあまりにもマズいので
このファイルには手を加えずに、データモデルを変更する方法を覚えておきましょう。
　

それが、以下の方法です。

<TodoCore.xcdatamodeld>を選択した状態で、メニューバーの設計から<データモデル><モデルバージョンを追加>を選択します。
つまり、データモデルをバージョンアップさせる方法です。

すると、このように新しいファイルが作られ、古いモデルバージョンには2という数字が付けられます。

ここで注意しておく事は数字が付いているファイルは、数が少ないもの順に古いファイルになる事です。
たとえば、もう一度モデルバージョンを追加すると<TodoCore 3>というファイルが作られますが、それは2よりも新しいファイルになります。
そして、緑色のバッジが付いているファイルが常に現在使用しているファイルとなります。
(<データモデル><現在の設定>を選択すると古いファイルに戻す事も出来ます)

まぁ、とりあえずこれで安心してデータモデルをいじれる状態になりました。
　
　
5. 今度こそモデリングしてみる^^;

まず、現在ある<Eventエンティティ>をどこか端の方にでも、追いやっておいてください。
(捨てないでっ!!)
　
まず、新規エンティティを追加します。
追加するには、エンティティビューの下にある+ボタンをクリックするか、モデリングビュー上で右クリックして<新規エンティティを追加>を選びます。
(この辺りの操作の説明は、何となく分かると思うので端折っていきます)

そして、そのエンティティに<Task>という名前を付けておきます。

次にこの<Task>に必要な属性を5つ加えてみます。

　
すると、以下のようになると思います。

なんだかちょっとTodoアプリっぽくなってきた気がしますね^^
　
　
ただ、このままではそれぞれの属性にどんな型のデータが入るのか分からないので、それぞれの属性のデータ型を指定していきます。
このデータ型を指定する作業は属性ビューでやるのが効率的だと思うのですが、データ型を決めた際に色々と他の詳細設定も出来るようになっています。

ちなみにここで設定できるデータ型は以下のようになります。

　
で、今回は次のように設定してみました。
(特に明記していないものはデフォルトのままです)

　
　
この設定の内容をざっと説明します。

　
と、ここまでで、とりあえずの項目は出来ましたが、なんだか物足りない感じですね〜
やっぱりアプリとして作るには、これでは最低限の最低限すぎる感じなので、あと２つエンティティを加えてみます。
　
　
6. 複数のエンティティを関連づける

新たに加えるエンティティは<Tag>と<Category>です。
　
Tagエンティティは<Task>にタグを付けられるようにするため。
Categoryエンティティは、<Task>を大まかなカテゴリー分け(例えば、仕事のタスク、プライベートのタスクなど)が出来るようにするために使います。

そして、その両方に<name>という文字列型の属性を追加して、
<Task>の<title>属性と同じように、オプションをオフ、最小長を1にしておきます。
　
加えて<Category>の<name>属性のデフォルト値を”No Category”にしてみましょう。

そして、このままでは新たに加えた２つのエンティティは何の役にも立たないので、それぞれを<Task>に関連づける必要があります。
　
　
まず、それぞれのエンティティに関連を追加します。

関連の名前は以下のようにします。

　
この関連名の中で<Task>のcategory以外は複数形になっているので注意してください。
(あと言い忘れましたが、基本的にエンティティ名は頭文字を大文字に、属性や関連などは小文字にするのが一般的なようです。クラス名とオブジェクト名みたいな感じですね。)

次にどういう関連付けをするかを考えてみます。

まず、<Task>と<Tag>の関係は、ひとつのTodoに対して複数のタグを付けられるようにしたいですね。
(これを対多関連(to-Many Relationships)と言います。)
　
またその逆に、あるタグをひとつのTodoにしか付けられないのではちょっと困りますよね。なので、こちらもひとつのタグに対して複数のTodoが関連づけられるようにしたいところです。
つまり双方に対多な関連付け(Many-to-Many Relationships)をする事になります。
　
　
そこで、まず<Tag>エンティティの関連<tasks>を選択して、
ディスティネーション(関連)で<Task>を選択。
逆を<tags>
対多関連をオン
削除ルールを<無効にする>
にします。

すると以下のようになります。

<Task>と<Tag>が矢印で関連づけられてさらに<Tag>から<Task>に向かった矢印は二重になっていますね。
これで<Task>は複数の<Tag>を持てることが分かります。
(“逆”と”削除ルール”については後述します。)
　
　
そして、今度は<Task>から<Tag>への関連も設定するのですが、<Tag>からの設定が既に関連づけられた状態になっています。
ですので、対多関連のみをオンにすれば完了です。

これで双方に対多な関連付けができました！

お次ぎは<Category>と<Task>の関連付けですね。

ひとつの<Task>はひとつの<Category>しか持てないようにしようと思います。
これは、テーブルビューで表示する際にこの<Category>でセクション分けしたいからです。
ひとつの<Task>が複数の<Category>を持てるようにしてしまうと、表示させる際にドコのセクションに表示したら良いのか分からなくなってしまいます。
(先の設定で<Category>の<name>属性のデフォルト値を”No Category”としたのもこのためです。ユーザーがカテゴリを指定しなかった場合は、そのTaskは”No Category”というカテゴリに入れられます。少し変な言い回しですが^^;)

つまり、<Task>から<Category>への関連は単一になります。
逆に、当然ですがひとつの<Category>を複数の<Task>が使えるようにしなければならないのでCategoryからの関連は対多関連(One-to-Many Relationships)にします。
　
　
それでは、以下のように設定してみましょう。

　
で、以下のようになっていればOKです。

ここまでできたところで、データモデリングはひとまず完成としておきましょう。

それと先程説明しなかった<関連>の”逆”と”削除ルール”について書いておきます。
　

　
つまり『逆』を設定すると自分が削除されたときにその逆へ『僕は削除されたよ』と通知します。
『削除ルール』というのが自分が削除されたときの関連先(逆)との関係をどうするかと言う事になります。

そして『削除ルール』の<無効にする>は、
相手側から自分への関連を無効にする。という事です。
　
　
今回の例で説明すると、
Tagが削除された時には、そのタグを設定していたTaskから削除されたTagとの関連をなくす。
『さよならTaskさん…(; ^ ;)/~』
という処理をさせます。

これをしておかないと、データの無くなったTagにTaskがアクセスしようとするコトが出来てしまい、その結果エラーが発生します。
『別れるなんて聞いてないぞ！』
なので、削除された関連は無効にしておくワケですね。
　
　
では、<カスケード>はどういった処理か？
それは、自分自身が削除された時に関連している逆のデータも一緒に削除するって処理です。

まぁ、簡単に言えば
『別れるならあなたを殺して私も死ぬわっ！』『やっ…やめ……』(グサッ)
…ってな感じで^^;
　
　
つまり、今回は<Category>エンティティの関連<tasks>で、逆を<Task>エンティティの関連<category>に設定してあり、
削除ルールが<カスケード>なので、あるカテゴリが削除された場合には、そのカテゴリに属しているTodoはすべて一緒に消されるようになります。

削除ルールには、この２つの他に<アクションなし>(なにもしない)<拒否>(関係をnilにする)という選択肢がありますが、特に今回使った２つ以外の処理が必要になった時に使ってみるくらいの感じで良いと思います。

そしてこの『削除ルール』で注意しておきたいのが、
『自分が』削除されたときの処理というところです。
これを勘違いして『関連先が』削除されたときの処理として設定してしまうと思わぬバグになることがあるようなので、気を付けておきましょう。
(例えるのはやめときます…^^;)
　
　
今回の『Study CoreData』はこの辺りで終了としたいと思いますが、最後にいくつか補足をしておきます。

まず、下の画像を見てください。

エンティティビューに抽象というチェックボックスがありますね。
これは、つまりObjective-Cでいう抽象クラスのような<抽象エンティティ>をつくり、それを継承した<エンティティ>を作る事も出来るというものです。
ほとんど同じ属性を持っているけどちょっとだけ違う別々のエンティティを使う場合などには重宝しそうですね。

次に属性や関連を追加するポップアップの中に、今回使わなかった<取得済みプロパティを追加>と<取得要求を追加>というのがあります。
これは日本語訳されているので気付きづらいですが、

となっています。

フェッチリクエストについては以前調べたので分かると思いますが、データを取得する上での条件をモデルエディタ上でもできるようですね。
　
フェッチドプロパティは述語(NSPredicate)という条件指定を使ってデータを取得するためのプロパティらしいです。
(実は以前に例に挙げたMacのスポットライトは述語な感じです)
この述語というのはフェッチリクエストにも入れられるのですが、以前にも触れたようにフェッチリクエストには述語の他に<エンティティの指定><並べ替えの指定>が含まれています。

まぁ、述語については今回はコード上で行う事にしようと思いますので、興味のある方は調べてみてくださいね。
　
　
そしてエンティティビューにある<クラス>の項目ですが、ここも変更が出来るようになっています。
たとえばNSManagetObjectを拡張したサブクラスなどもエンティティのクラスとして、ここで指定できるというコトのようです。

それと最後にデータの型についてですが、既に用意されている型以外にも<変換可能>(id型)を使って、独自の型(例えばUIImageやUIColorなど)を設定する事も出来ます。
(その際にはNSManagetObjectを継承したサブクラスを用意してデータの変換を実装する必要があります。)
そこら辺はAppleのサンプルコード『iPhoneCoreDataRecipes』などが参考になると思います。
　
　
それでは、今回はこの辺で。

でわ、また明日。
恋人は大切にしましょ〜ね〜(笑)