Core Data Programming Guide:Core Data Basics

Core Data は 2 つの主要な機能分野、すなわちオブジェクトグラフ管理とオブジェクトの永続性に対処します。オブジェクトグラフ管理には、アンドゥとリドゥ、検証、オブジェクト間の関係の整合性維持が含まれます。オブジェクトの永続性とは、オブジェクトを永続ストア（ディスク上のファイルなど）に保存したり、永続ストアからオブジェクトを取り出すことを意味します。通常は、このような機能をサポートするコードをすべて記述しなければなりません。Core Data Framework は、こうした作業を管理するためのインフラストラクチャを提供します。

このセクションの内容：

はじめに

Core Data はオブジェクトグラフ管理と永続性のためのインフラストラクチャを提供します。本稿ではまず、オブジェクトグラフについて説明し、いくつかの基本用語を紹介します。次に、基本的な Core Data アーキテクチャ、およびこのフレームワークの使用方法について説明します。オブジェクトグラフを管理し、オブジェクトの永続性をサポートするために、Core Data では操作対象のオブジェクトに関するリッチな記述を必要とします。この記述を提供するには、「管理対象オブジェクトモデル」、すなわちアプリケーションで使用するエンティティおよびそれらの関係を記述するスキーマを作成します。管理対象オブジェクトモデルについては最後のセクションで説明します。

オブジェクトグラフ

オブジェクトグラフはオブジェクトのコレクションであり、それらの関係を含みます。Core Data が提供する機能を十分に理解するには、オブジェクトグラフがどういうものであるか、そして特にオブジェクト間の関係がどのように表されるのかを理解することが重要です。

ほとんどのアプリケーションでは、モデルオブジェクト（Model-View-Controller デザインパターンにおける「モデル」）のグラフを管理するという課題に直面します。これらはアプリケーションでデータ（グラフィックオブジェクト、to-do 項目、または従業員オブジェクトなど）を意味します。本書の残りの説明の中で使用する以下の例を考えてみましょう。

この例では、従業員をいくつかのプロパティ（ファーストネーム、ラストネーム、給与、上司および働いている部署との関係を示す属性）を持っている Employee オブジェクトで表しています（プロパティ、属性、および関係の違いを理解するには、『Data Modeling Guide』を参照）。従業員が働いている部署は、名前と予算を示す属性を持っている Department オブジェクトで表しています。

3 つのオブジェクト、すなわち従業員、従業員の上司（従業員でもある）、および従業員の勤務部署で形成されるグループが、図 1 に示すように、小さなオブジェクトグラフを表します。オブジェクトグラフでは、対一関係は対象オブジェクトへの参照で表され、対多関係はコレクションオブジェクトで表されます。コレクションオブジェクトには、そのメンバを構成するオブジェクトへの参照が含まれています。

従業員とその上司および部署との関係に加えて、上司と上司に報告する従業員との間（directReports）、および部署とその部署で働いている従業員との間（employees）にいう逆の関係も考慮する必要があります。この例では、これらの逆関係をモデル化しています。もっとも、関係が一方向にしかナビゲートできない可能性もあります。部署オブジェクトを起点に、そのオブジェクトに関連付けられている従業員を知る必要がなければ、その関係をモデル化する必要はありません。

Core Data フレームワークでは、受信済みプロパティという別の種類の関係（この図には示していない）も定義します。受信済みプロパティは単方向の弱い関係を可能にします。たとえば、あるオブジェクトのプロパティとして表されたダイナミックな iTunes プレイリストがあったとします。曲は特定のプレイリストに「所属」せず、曲を削除したり、リモートサーバがアクセス不能になっても、プレイリストはそのままです。

注：本書では、便宜とわかりやすさのために従業員の例を使用します。この例は、リッチだが容易に理解できる問題領域を提示します。しかし、Core Data フレームワークの有用性はデータベーススタイルのアプリケーションに限られたものではなく、クライアント／サーバ型の動作を想定するものでもありません。このフレームワークは、Sketch のようなベクトルグラフィックアプリケーションや Keynote のようなプレゼンテーションアプリケーションの基礎としても同様に役立ちます。

基本的な Core Data アーキテクチャ

ほとんどのアプリケーションでは、オブジェクトのアーカイブが含まれているファイルを開く手段、および少なくとも 1 つのルートオブジェクトへの参照が必要です。また、すべてのオブジェクトをファイルにアーカイブしたり、アンドゥをサポートしたい場合は、オブジェクトに加えられた変更を追跡する必要もあります。

従業員管理アプリケーションでは、図 2 に示すように、従業員と部署オブジェクトのアーカイブを含むファイルを開く手段、および少なくとも 1 つのルートオブジェクト（全従業員の配列など）への参照が必要です。また、すべての従業員とすべての部署をファイルにアーカイブできる必要もあります。

これらの作業の全部または一部を管理するコードを記述しなければなりません。Cocoa ドキュメントアーキテクチャは、このような負担を軽減するアプリケーション構造と機能を提供しますが、それでもデータのアーカイブとアーカイブ解除をサポートし、モデルオブジェクトを追跡し、アンドゥをサポートするためにアンドゥマネージャと対話するメソッドを記述する必要があります。

図 2：標準の Cocoa ドキュメントアーキテクチャを使用したドキュメント管理

Core Data フレームワークを使用すると、このような機能のほとんどが、主として管理対象オブジェクトコンテキスト（または単に「コンテキスト」）と呼ばれるオブジェクトを通じて自動的に提供されます。管理対象オブジェクトコンテキストは、基礎的なフレームワークオブジェクトのコレクション（永続性スタックと総称）への出入り口として機能し、アプリケーションと外部データストアとの間でオブジェクトを仲介します。図 3 に示すように、スタックの底には永続オブジェクトストアがあります。

Core Data の対象はドキュメントベースのアプリケーションに限られていません。実際、まったくユーザインターフェイスのない Core Data ベースのユーティリティを作成することができます（『Low-Level Core Data Tutorial』を参照）。他のアプリケーションにも同じ原則が当てはまります。

管理対象オブジェクトコンテキスト

管理対象オブジェクトコンテキストは、インテリジェントなスクラッチパッドと考えることができます。永続ストアからオブジェクトを受信するとき、スクラッチパッドにオブジェクトの一時的な複製を持つことになります。それらがスクラッチパッドの中でオブジェクトグラフ（またはオブジェクトグラフのコレクション）を形成します。複製オブジェクトには、自由に変更を加えることができます。ただし、これらの変更を実際に保存しないかぎり、永続ストアは変更されないままです。

Core Data フレームワークに結び付いたオブジェクトを管理対象オブジェクトと呼びます。管理対象オブジェクトはすべて、管理対象オブジェクトコンテキストに登録する必要があります。このコンテキストを使用して、オブジェクトをグラフに追加したり、グラフからオブジェクトを取り除いたりします。コンテキストは、個々のオブジェクトの属性およびオブジェクト間の関係に加えた変更を追跡します。変更を追跡することで、このコンテキストはアンドゥとリドゥをサポートすることができます。また、オブジェクト間の関係を変更した場合に、オブジェクトグラフの整合性を維持できるようにします。

加えた変更を保存することにした場合、このコンテキストが、オブジェクトが有効な状態であることを保証します。オブジェクトが有効な状態になると、変更が永続ストア（または複数のストア）に書き込まれ、作成したオブジェクトに対応する新しいレコードが追加され、削除したオブジェクトのレコードが削除されます。

受信要求(Fetch Request)

管理対象オブジェクトコンテキストを使用してデータを取り出すには、受信要求を作成します。受信要求は、たとえば、「全従業員」、あるいは「マーケティング部門の全従業員を給与の高い順から整列」という具合に、取得したいデータを指定するオブジェクトです。受信要求は 3 つの部分で構成されています。最低限、エンティティの名前を指定する必要があります（暗黙の了解として、一度に受信できるのは 1 タイプのエンティティだけです）。また、図 4 に示すように、オブジェクトが一致しなければならない条件を指定する述部オブジェクト、およびオブジェクトの表示順を指定するソート記述子オブジェクトの配列も含まれることがあります。

受信要求を管理対象オブジェクトコンテキストに送ると、その永続ストアに関連付けられているデータストアから、要求に一致するオブジェクト（ない場合もある）が返されます。管理対象オブジェクトはすべて管理対象オブジェクトコンテキストに登録する必要があるので、受信したオブジェクトは、受信に使用したコンテキストに自動的に登録されます。

フレームワークは可能な限り効率を重んじます。Core Data は要求に応じて動作するため、実際に必要としている以上のオブジェクトを作成することはありません。オブジェクトグラフは、永続ストアのオブジェクトをすべて表す必要はありません。永続ストアを指定するだけでは、データオブジェクトは管理対象オブジェクトコンテキストに移動されません。永続ストアからオブジェクトのサブセットを受信すると、要求したオブジェクトだけが返されます。受信していないオブジェクトへの関係をたどると、オブジェクトは自動的に受信されます。オブジェクトの使用を止めると（すなわち、オブジェクトを保持するようにしていなければ）、その割り当ては解除されます（これはグラフからオブジェクトを削除するのとは異なります）。

永続ストアコーディネータ

前述したように、アプリケーションと外部データストアの間でオブジェクトを仲介するフレームワークオブジェクトのコレクションは、永続性スタックと総称されます。スタックの最上部には管理対象オブジェクトコンテキストがあり、スタックの最下部には永続オブジェクトストアがあります。管理対象オブジェクトコンテキストと永続オブジェクトストアの間には、永続ストアコーディネータがあります。

つまり、実質的には永続ストアコーディネータがスタックを定義します。コーディネータは、管理対象オブジェクトコンテキストに対して、永続ストアのグループが単独の集合ストアとして見えるような切り口を提示するように設計されています。そのため、管理対象オブジェクトコンテキストは、コーディネータが対象とするすべてのデータストアの和集合に基づいてオブジェクトグラフを作成できます。図 5 に示す例では、従業員と部署を 1 つのファイルに保存し、顧客と会社を別のファイルに保存しています。オブジェクトを受信すると、自動的に適切なファイルから取り出され、オブジェクトを保存すると、適切なファイルにアーカイブされます。

永続ストア

永続オブジェクトストアは、1 つのファイルまたは他の外部データストアに関連付けられ、当該ストアのデータと管理対象オブジェクトコンテキスト内の対応するオブジェクトとの間のマッピングについて最終的な責任を負います。通常、永続オブジェクトストアとの唯一の対話は、アプリケーションに関連付ける新しい外部データストアの場所を指定するときです（たとえば、ユーザがドキュメントを開いたり保存するとき）。Core Data フレームワークとの他のほとんどの対話は、管理対象オブジェクトコンテキストを経由します。

なお、ストアにおけるデータの表現方法は、アプリケーションのアーキテクチャとは無関係です。Core Data は複数のファイル形式をネイティブでサポートしています。アプリケーションのニーズに応じて、使用するファイル形式を選択できます。ある段階で異なるファイル形式を選択しても、アプリケーションアーキテクチャは変わりません。

永続ドキュメント

永続性スタックはプログラムの中で作成し、設定することができます。しかし、多くの場合は、ファイルを読み書きできるドキュメントベースのアプリケーションを作成することになるでしょう。NSPersistentDocument クラスは、Core Data フレームワークを簡単に利用できるように設計された NSDocument のサブクラスです。デフォルトで、NSPersistentDocument はすぐに使える固有の永続性スタック（管理対象オブジェクトコンテキストと 1 つの永続オブジェクトストアを含む）を作成します。この場合は、ドキュメントと外部データストアとの間に 1 対 1 のマッピングが成立します。

NSPersistentDocument クラスは、ドキュメントの管理対象オブジェクトコンテキストにアクセスするメソッドを提供し、ファイルを読み書きするための、Core Data フレームワークを使用する標準の NSDocument メソッドを実装します。デフォルトでは、オブジェクトの永続化を処理するためのコードを追加する必要はありません。永続ドキュメントのアンドゥ機能は、管理対象オブジェクトコンテキストと統合されています。

管理対象オブジェクトと管理対象オブジェクトモデル

オブジェクトグラフを管理し、オブジェクトの永続性をサポートするために、Core Data では操作対象のオブジェクトに関するリッチな記述を必要とします。管理対象オブジェクトモデルは、図 6 に示すように、アプリケーションで使用する管理対象オブジェクトまたはエンティティに関する記述を提供するスキーマです。通常は、Xcode のデータモデリングツールを使用して、管理対象オブジェクトモデルを作成します（プログラムの中で実行時にモデルを構築することもできます）。

図 6：2 つのエンティティのある管理対象オブジェクトモデル

このモデルは、エンティティの名前、アプリケーションの中でエンティティを表すクラスの名前（これはエンティティの名前と同じである必要はありません）、およびエンティティの属性と関係など、それぞれがエンティティに関するメタデータを提供するエンティティ記述オブジェクトのコレクションで構成されています。同様に、図 7 に示すように、属性と関係も属性および関係記述オブジェクトで表されます。

管理対象オブジェクトは、NSManagedObject のインスタンスまたは NSManagedObject のサブクラスでなければなりません。NSManagedObject は、管理対象オブジェクトに必要な基本動作をすべて実装します。エンティティのインスタンスである管理対象オブジェクトには、当該エンティティに対応するエンティティ記述への参照があります。当該オブジェクトは、そのオブジェクトが表すエンティティの名前や、エンティティの属性と関係に関する情報など、オブジェクト自身に関するメタデータを発見するためのエンティティ記述を参照します。

NSManagedObject は任意のエンティティを表せます。また、自身の内部ストアにプロパティを保持します。プロパティには、キー値コーディングを使用してアクセスできます。オブジェクトはエンティティ記述を参照して、有効なキーを判断します。追加動作を実装する場合、または Core Data がサポートしていない属性タイプを使用する場合にのみ、NSManagedObject のサブクラスを作成する必要があります（そのため、ソースコードを記述します）。たとえば、プロパティのカスタムアクセサを使用したければ（キー値コーディングに依存しないで、たとえば salary メソッドを呼び出せるように）、Employee エンティティについて NSManagedObject のサブクラスを実装します。同様に、Employee のファーストネームとラストネームを連結したものを返す fullName メソッドを指定する場合も、サブクラスを使用します。Core Data は、数は少ないながらも便利な属性タイプ（NSString、NSNumber、NSData、および NSDate）をネイティブにサポートしています。float を使用して Employee の給与属性を表したい場合、またはカスタムクラスを使用して従業員の写真を表したい場合も、サブクラスを使って行います。

エンティティを表すことのできる NSManagedObject の能力は、別の重要なメリットを提供します。従来の Cocoa アプリケーション開発では、モデルオブジェクトを表すのにオブジェクトクラスを作成する必要があります。それには、クラスとインスタンス変数に加え、しばしば、適切なアクセサメソッドを手作業でコーディングしなければなりません。そうすると、アプリケーションが進化し、クラスおよび変数名が変化した場合には、対応するソースファイルを書き直す必要があります。Core Data フレームワークを使用すれば、具象クラスを手作業でコーディングせずに、多くの場合は単純に NSManagedObjects を使用できます。

アプリケーションコード、そして特に管理対象オブジェクトに関連付けられているアプリケーションロジックでは、データが格納されている永続ストアについて何の想定もするべきではありません。アプリケーションが適切に抽象化されていれば、追加作業なしに、フレームワークに対する今後の強化を活用することができます。たとえば、最初の実装ではローカルファイルシステムからのみレコードを受信できるアプリケーションでも、データの取得先について何の想定もしなければ、将来のある段階で新しい永続ストアがサポートされるようになったら、コードの修正なしに、その新しいタイプを使用できるはずです。




	Get information on Apple products. Visit the Apple Store online or at retail locations. 1-800-MY-APPLE Copyright © 2007 Apple Inc. All rights reserved. \| Terms of use \| Privacy Notice