Advanced Search

Log In | Not a Member?

Contact ADC

オブジェクトグラフを変更するときは、参照整合性を維持することが重要です。Core Data では、参照整合性エラーを引き起こさずに、管理対象オブジェクト間の関係を簡単に変更することができます。このような動作の多くは、管理対象オブジェクトモデルに指定されている関係記述から派生します。

このセクションの内容：

モデルの関係定義
関係の操作
受信済みプロパティ

モデルの関係定義

管理対象オブジェクトモデルにおいて関係を作成するのは簡単ですが、適切に指定する必要がある関係の側面がいくつかあります。最も明かな特性は関係の名前、デスティネーションエンティティ、および濃度（対一関係なのか、対多関係なのか）です。しかし、オブジェクトグラフの整合性に関する最も重要な特性は、逆関係と削除ルールです。グラフの妥当性は、オプショナリティと最大および最小カウントに関する設定の影響を受けます。

関係の基礎

デスティネーションエンティティでは、デスティネーションにあるオブジェクトのエンティティまたは親エンティティを指定します。関係は均質である必要はありません。Employee エンティティに 2 つのサブエンティティ、たとえば Manager と Flunky がある場合、部署の従業員は Employee（Employee は抽象エンティティでないと仮定）、Manager、Flunky、またはそれらの組み合わせで構成することができます。

関係を単純に対一または対多として指定できます。また、デスティネーションとするオブジェクトの数に上限と下限を設定することもできます。下限がゼロである必要はありません。部署の従業員数を 3 〜 40 人の範囲に限定したければそのようにすることができます。

また、関係をオプションとするか必須とするかを指定します。関係がオプションでない場合は、関係が有効であるためには、関係のデスティネーションとなるオブジェクトが存在しなければなりません。濃度とオプショナリティは、関係の直交するプロパティであることに留意してください。上限または下限を指定している場合でも、関係をオプションとして指定できます。つまり、デスティネーションとなるオブジェクトは存在しなくてもよいが、存在する場合は、オブジェクトの数が指定した範囲内である必要があることを指定できます。

逆関係

ほとんどの関係は本質的に双方向です。Department がそこで働いている Employees と対多関係にある場合、Employee の Department に対する逆関係があります。大きな例外は、弱い単方向の関係を示す受信済みプロパティです。この関係では、デスティネーションからソースへの関係がありません（「受信済みプロパティ」を参照）。

一般に、関係は双方向でモデル化すべきです。また、逆関係を適切に指定することも重要です。変更が行われた場合に、Core Data はその情報を使用して、オブジェクトグラフをどのように変更するかを決定します。たとえば、従業員を別の部署に異動する場合は、従業員の部署関係を更新し、元の部署の従業員関係から当該従業員を取り除き、新しい部署の従業員関係に追加する必要があります。逆関係を適切に指定しておけば、Core Data では、関係の一方の側を変更したとき、オブジェクトグラフの整合性を維持するために、その変更に応じて他方の側もすべて更新されます。

必ずしも関係を双方向でモデル化する必要はありません。場合によっては、そうしない方が良いこともあります。たとえば、対多関係に非常に多数のデスティネーションオブジェクトがあり、関係を渡り歩く可能性が極めて低い場合などです（関係のデスティネーションとなる多数のオブジェクトで不必要にフォールトを起こしたくありません）。しかし、双方向にしない場合は、オブジェクトグラフの整合性を確保するために追加の作業が必要なこともあります。通常、意味があるのは単方向の対一関係をモデル化する場合のみです。

関係削除ルール

関係の削除ルールでは、ソースオブジェクトの削除が行われようとしたときにどうするかを指定します。前文の「ソースオブジェクトの削除が行われようとしたとき・・・」というフレーズに注意してください。関係の削除ルールを Deny（拒否）に設定すると、ソースオブジェクトが削除されない可能性があります。また、部署の従業員関係、およびさまざまな削除ルールの影響についても考えてください。

Deny（拒否）

関係のデスティネーションに少なくとも 1 つのオブジェクトが存在すれば、ソースオブジェクトを削除することはできません。たとえば、ある部署を取り除く場合は、当該部署の全従業員をまず他の部署に異動しないと（あるいは解雇しないと）、その部署を削除できません。

Nullify（無効にする）

デスティネーションとするオブジェクトの逆関係をヌルに設定します。たとえば、部署を削除するときに、現在のメンバ全員の部署をヌルに設定します。これが意味をなすのは、従業員に対する部署関係がオプションである場合、または次の保存操作の前に各従業員に新しい部署を設定する場合だけです。

Cascade（カスケード）

関係のデスティネーションにあるオブジェクトを削除します。たとえば、部署を削除するときに、当該部署の全従業員を解雇します。

No Action（アクションなし）

関係のデスティネーションとなるオブジェクトに何もしません。たとえば、部署を削除するときに、従業員が当該部署に所属していると信じていても、全従業員をそのままにしておきます。

これらのルールのうち、最初の 3 つがさまざまな状況で役に立つことは明かです。関係を問わず、ビジネスロジックに応じて最も適切なルールを選択するのは開発者次第です。No Action ルールを使用すると、オブジェクトグラフが矛盾した状態（従業員が削除された部署への関係を持っているなど）になる可能性があるため、No Action ルールを使用する理由はわかりにくいかもしれません。

No Action を使用する場合、オブジェクトグラフの整合性を維持するのは開発者次第です。逆関係を意味のある値に設定する責任は開発者にあります。これが有効なのは、対多関係があり、そのデスティネーションに多数のオブジェクトが存在する状況です。

関係の操作

一般に、関係をプログラムで操作するのは簡単です。Core Data がオブジェクトグラフの整合性を管理してくれるため、関係の一端を変更するだけで、他の側面はすべて管理されます。

対一関係

対一関係は、単純な属性と同じ方法で操作します。関係に対するカスタムのアクセサメソッドを定義した場合は、次の例に示すように、そのメソッドを呼び出して、新しいデスティネーションオブジェクトを引数として直接渡すことができます。

Employee *anEmployee = ...;  // これが設定されていると仮定する

Department *aDepartment = ...;  // これが設定されていると仮定する

[anEmployee setDepartment:aDepartment];

また、キー値コーディングも使用できます。カスタムクラスとカスタムのアクセサメソッドを定義してもしなくても、これは機能します。

[anEmployee setValue:aDepartment forKey:@"department"];

対多関係

対多関係の全体を、次の例に示すように、カスタムのアクセサメソッドまたは（こちらの方が可能性が高いですが）キー値コーディングを使用して対一関係と同じ方法で操作することができます。

[aDepartment setValue:setOfEmployees forKey:@"employees"];

しかし、通常は、関係全体を設定するのではなく、要素を 1 つずつ追加または取り除くことになります。その場合は、mutableSetValueForKey: を使用します。これは、関係を変化させ、適切なキー値監視通知を送るプロキシオブジェクトを返します。

NSMutableSet *employees = [aDepartment mutableSetValueForKey:@"employees"];

[employees addObject:aNewEmployee];

[employees removeObject:aFiredEmployee];

通常は、対多関係に独自のコレクションアクセサメソッドを実装するべき理由はほとんどありません。実装する場合は、『NSManagedObject』の「Subclasing Note」で説明しているように、関連する KVO 通知メソッドを呼び出す必要があります。

受信済みプロパティ

受信済みプロパティは弱い単方向の関係を表します。受信済みプロパティの代表的な例は iTunes のプレイリストです。曲は自身がどのプレイリストに属しているかを知りません。さらに、プレイリストの曲が別のユーザに属しているために、当該ユーザが接続している場合にのみ表示されるということもあります。Core Data では、受信済みプロパティはデスティネーションエンティティの受信要求によって指定されます。従業員および部署ドメインでは、部署の受信済みプロパティを「最近の被雇用者」とすることが考えられます（従業員は最近の被雇用者への逆関係がありません）。デスティネーションエンティティは Employee ですが、関係自体は動的であるため、定期的に再計算して最新の状態を確保する必要があります。そのためにはソースオブジェクトを再フォールトさせます。

Did this document help you? Yes: Tell us what works for you. It’s good, but: Report typos, inaccuracies, and so forth. It wasn’t helpful: Tell us what would have helped.

	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