iOSのコアデータ。 章番号4。 理論部

ハブラリュディ、こんにちは！

本日、マイケル・プリバートとロバート・ワーナーの本「iOS用のプロコアデータ」に関する実践的な演習で一連の講義を書き始めたいと思います。 各章には、理論的および実用的な部分が含まれます。







内容：

• 章番号1。 はじめに （ 実用的な部分 ）
• 章番号2。 マスターコアデータ （ 実践部 ）
• 章番号3。 データストレージ：SQLiteおよびその他のオプション
• 章番号4。 データモデルの作成
• 第5章。 データオブジェクトの操作
• 第6章 結果セットの処理
• 章番号7。 パフォーマンスとメモリのチューニング
• 第8章。 バージョン管理と移行
• 章番号9。 NSFetchedResultsControllerを使用してテーブルを管理する
• 章番号10。 高度なアプリケーションでコアデータを使用する

エントリー

日常生活や問題の解決に役立つ見事なインターフェイスを備えたユーザーアプリケーションを作成できますが、アプリケーション内のデータを正しく表現しないと、アプリケーションの保守が難しくなり、パフォーマンスが低下し、時間が経つと完全に使用できなくなる可能性があります。 この章では、アプリケーションを台無しにしないようにモデル（データ）を設計する必要がある方法を見ていきます。

データベース設計

アメリカの哲学者ラルフ・ウォルド・エマーソンはかつて言った：「愚かな一貫性は、小さな心のホブゴブリンです」（何かに続いて愚か、これは多くの愚か者です）。 多くの場合、人々はこのことわざを使用して、攻撃から身を守り、詳細について他者からの質問をします。 Core Dataはデータベースではないと定期的に主張しますが、データベースのように扱いますが、この餌に落ちないことを願っています（著者：「何かがアヒルのように歩く場合、それはアヒル、それはアヒルです。」 このセクションでは、アプリケーションのデータ構造を設計する方法を検討し、このプロセスとリレーショナルデータベースの構造を設計するプロセスとの類似点を描くことで、議論だけでなく、最終的な結果にも役立ちます。 もちろん、いくつかの点で類推はありませんが、議論の中でこれらの点を指摘しようとします。



コアデータのエンティティは、リレーショナルデータベースのテーブルと同じように見えます。 属性はテーブルのフィールドであり、関係は主キーと外部キーによる結合であり、エンティティ自体はテーブル内のまさにレコードです。 データモデルがSQLiteタイプのストレージに「重畳」されている場合、Core Dataは上記および第2 /第3章で説明した方法ですべてを実際に実装します。 ただし、データはメモリ、または何らかのファイル（アトミックストレージ）に保存できることを忘れないでください。ここにはテーブルとフィールド、主キー、または外部キーはありません。 Core Dataは、使用されるストレージのタイプからデータ構造を抽象化することで、設計とデータとの相互作用の利便性と汎用性を実現しています。 Core Dataがあなたの心を捕らえ、Core Dataで単一の全体にマージします。CoreDataで力を感じるか、最適でないデータ構造を使用して壊れたトラフになってしまいます。



コアデータの研究を始めたばかりで、最初のデータモデルを作成している初心者は、データベース構造の従来のモデリングで使用していたように、エンティティのプライマリキーを作成して責任を負うことができないことに常にconstantlyします。 Core Dataには自動インクリメントキーはありません。それらはそこでは必要ないからです。 コアデータは、追加された各オブジェクト（管理対象オブジェクト）に対して一意のキーを作成する責任を負います。 主キーは、外部キーも存在しないことを意味しません。CoreDataは、エンティティ自体間の関係を管理し、必要な結合を実行します。 すぐにやめて！ 主キーと外部キーを宣言することに不快感を感じるのをやめてください！



あなたを泥沼に引きずり込むことができる別の場所は、多対多の関係シミュレーションです。 リーグマネージャーアプリケーションでは、プレーヤーが異なるチームに所属できることを想像してください。 その場合、各チームには多くのプレーヤーがいて、各プレーヤーは異なるチームでプレーできます。 従来のリレーショナルデータベースを作成する場合、3つのテーブルがあります。1つはチーム用、もう1つはプレーヤー用、もう1つはどのプレーヤーとチームが属するかを追跡するためです。 同時に、Core Dataでは、プレーヤーとチームの2つのエンティティが同じであり、通常のチェックマークを設定することで多対多の関係が構成されます。 ただし、コアデータでは、「内部」で3つのテーブルZTEAM、ZPLAYER、Z1TEAMSを使用してこれを実装していますが、これらは実装の詳細です。 3番目または4番目のテーブルがあることを知る必要はありません。CoreDataがこれを処理し、より良い結果をもたらします。



ヒント ：データの保管メカニズムではなく、データに注意してください。

リレーショナルデータベースの正規化

リレーショナルデータベースの設計理論は、正規化（正規化プロセス）と呼ばれるデータモデリングプロセスを組み合わせたものです。その目的は、冗長性を削減または完全に排除し、データベース内のデータへの効果的なアクセスを提供することです。

正規化プロセスは5つのレベル（フォーム）で構成され、レベル6で作業が続行されます。 おそらく、最初の5つの形式の定義を好むのは数学者だけであり、おそらく理解できるのは彼らだけです。 これらは次のようになります。

「関係Rは、RにMVDが存在する場合、たとえばA->-> Bの場合にのみ、Rのすべての属性も機能的にAに依存する場合にのみ、4番目の正規形（4NF）になります。 Rの依存関係（FDまたはMVD）のみがK-> Xの形式です（つまり、候補キーKから他の属性Xへの機能的依存関係）。 同等：RがBCNFにあり、RのすべてのMVDが実際にFDである場合、Rは4NFにあります。

（c） www.databasedesign-resource.com/normal-forms.html



すべてのフォームを説明するのに十分なページも、すべての通常のフォームの定義を調べてその本質を説明したいという欲求もありません。 代わりに、このセクションでは、コアデータに関する各標準フォームについて説明し、設計のヒントを提供します。 特定の標準形式に従うには、これに先行するすべての標準形式に従う必要があることに注意してください。



最初の正規形（1NF）に対応するデータベースは、正規化されていると見なされます。 この形式（レベル）の正規化に従うには、データベースの各レコードに同じ数のフィールドが必要です。 Core Dataのコンテキストでは、これは、管理対象オブジェクトに特定の（事前定義された）数の属性が必要であることを意味します。 Core Dataでは異なる数の属性を持つ1つのエンティティを作成できないという事実に基づいて、Core Dataのモデルは自動的に正規化されると結論付けることができます。



2番目の標準形式（2NF）と3番目の標準形式（3NF）は、非キーフィールドとキーフィールドの関係に関連し、非キーフィールドが属するキーフィールドに関する事実である必要があります。 Core Dataのキーは気にしないので、この質問は削除されます。 ただし、エンティティのすべての属性が、他の何かではなく、その特定のエンティティを説明することを確認する必要があります。 たとえば、フォームの色はプレーヤーではなくチームの状態を表すため、PlayerエンティティにはuniformColor属性を設定しないでください。



次の2つの標準形式、4番目の標準形式（4NF）と5番目の標準形式（5NF）は、コアデータの世界で同じ形式と見なすことができます。 それらは、記述されたデータの冗長性を削減または排除し、 複数の値を持つ属性を個別のエンティティに転送し、エンティティ間に多対多の関係を作成するように促します。 4NFコアデータに関しては、フォームには、エンティティが複数の値を持つことができる属性を持つべきではないことが記載されています。 代わりに、これらの属性を別のエンティティに移動し、エンティティ間に多対多の関係を作成する価値があります。 LeagueManagerアプリケーションのチームとプレーヤーを使用したアプリケーションの例を考えてみましょう。 4つの標準形式と5つの標準形式に違反するデータモデルは、追加の属性を持つ1つのエンティティ（チーム）で構成されます-プレーヤー。 次に、各プレーヤーの新しいチームインスタンスを作成します。その結果、余分な（不要な）チームオブジェクトがいくつかあります。 代わりに、LeagueManagerアプリケーションで使用されるデータモデルでは、多対多の関係をチームエンティティと結合するPlayerエンティティが作成されます。



モデリングプロセスでは、これらの単純なルールを忘れないでください。 たとえば、LeagueManagerアプリケーションのデータモデルでは、TeamエンティティのuniformColor属性は正規化する機能を表します。 フォームの色の名前は有限のセットです。つまり、Colorという名前の追加のエンティティを作成できます。これは、name属性を持ち、Teamエンティティとの多対1の関係で接続されます。

Xcodeでモデルデザイナーを使用する

一部の開発者は、デフォルトで提供された開発ツールを使用することに単純に同意します。 他のものは、現在のものがそれらに劣ると思われる場合のみツールを作成します。 他の人は頑固に独自のツールを作成することを主張します。 私たちは自分たちが作ったツールだけを使用する開発者の最後のカテゴリーに分類されます。 私たちは自分たちが作った製品を誇りに思っており、時には小さな勝利と開発時間の節約で幸運を祝います。 ツールの開発に費やした時間は、楽しみのための「遊び時間」のカテゴリに含まれているため、決して考慮しません。 しかし、どんなに驚くかもしれませんが、おそらくXcodeが良い仕事をしているために、Core Dataの独自のモデルデザイナーを書くことはありませんでした。 開発環境への完全な統合。これはおそらくツールを超えることはできないでしょう。 さらに、Xcodeにはグラフィカルデータモデルシミュレータが組み込まれているため、設計がはるかに簡単になります。 前の章では、すでに対処する必要がありました。 このセクションでは、コアデータの仕組みを詳しく見て、よく使用するツールに注目します。



このセクションにはコードは記述されません。 代わりに、データモデラーのユーザーインターフェイスに集中します。 データモデルをプロジェクトに追加するには、メニュー項目を選択します。[ファイル]-> [新規]-> [新規ファイル]を選択し、ウィンドウの左側で[コアデータ]セクションを選択します。 ファイルには、データモデル、マッピングモデル、NSManagedObjectサブクラスの3つのタイプがあります。 マッピングモデルは、あるデータモデルから別のデータモデルへのデータ移行に役立ちます（詳細については、第8章を参照してください）。 データモデルのタイプを選択し、データモデルの名前を指定して保存します。





新しく作成されたモデルファイルXcodeを開くと、ビジュアルモデルエディターで開きます。 多数のボタンとオプションが存在すると、混乱する可能性があります。 次の図は、シミュレーションで使用される要素とその説明を示しています。





モデルエディターを使用すると、エンティティ、プロパティ、関係（関係）、クエリ、およびデータモデル構成を簡単に切り替えることができます。 データモデルを表示するためのオプションを切り替えることも可能です：グラフ形式の表示、またはテーブルビュー。





データモデルを議論することをより面白くするために、League Managerアプリケーションで開発したモデルを開くことを提案します。





ご覧のとおり、デフォルトでは、Xcodeはエンティティを表形式で表示します。 モデルのグラフィカル表現を使用する方が便利な場合は、エディターの右下部分にある「エディタースタイル」の碑文の上にある「グラフビュー」ボタンをクリックする必要があります。





グラフィック表現はデザイナーにとって馴染みのあるものである必要があり、エンティティとエンティティ間の関係を記述する標準的なものです。 チームエンティティからPlayerへの2つの矢印の接続があることにすでに気付いているでしょう。 これは、関係が1対多の関係であるためです。 チームには複数のプレーヤーを含めることができます。 プレイヤーからチームへのフィードバックは1対1の関係であり、それに応じて単一の矢印で示されます。 プレーヤーは1つのチームにのみ所属できます。

モデルのビジュアルデザイナーを使用した経験から、エンティティと属性の編集は表形式ではるかに便利であり、グラフィカルな表現はそれらの間の関係を視覚化するのに適していると確信できます。 ただし、独自のアプローチがある場合があります。

プロパティまたはエンティティを選択すると、それらに関する詳細情報を取得できます。 たとえば、次の図では、Playerエンティティが選択されています。 右上には、Playerエンティティに関する詳細が表示されます。 彼女の名前、NSManagedObjectクラス、抽象クラスではなく、欠落している親クラス。 プロパティを選択すると、パネルの外観が変わり、プロパティのプロパティが表示されます。 電子メール属性を選択すると、パネルの外観は次のように変わります。





+電子メール属性が呼び出されます

+オプションです

+一時的でもインデックス可能でもない

+文字列

+最小長および最大長に制限はありません

+デフォルト値なし

+バインドされた正規表現なし

+ Spotlightによってインデックス化されていないフィールド

+フィールド値は外部レコードに保存されません



Playerエンティティのチームコミュニケーションに切り替えると、パネルが次のように変更されます。





+属性チームと呼ばれる

+最終（関連）エンティティはチームエンティティです

+フィードバックがあり、プレイヤーと呼ばれます

+オプション、ただし一時的ではない

+ 1対多の関係ではない

+最小および最大数は1です

+使用されたNullify削除ルール

+ Spotlightによってインデックス化されていないフィールド

+フィールド値は外部レコードに保存されません



Playerの本質をご覧ください。





エンティティは名前で定義されます。 Core Dataを使用すると、管理対象オブジェクトの代替実装を提供するためにNSManagedObjectから継承できます。 NSManagedObjectクラスのサブクラスを作成し、それを特定のエンティティに関連付ける場合、「Entity」セクションの「Class」フィールドで新しいクラスの名前を指定する必要があります（上の画像）。

属性の表示と編集

Xcodeの「属性」セクションで属性を選択すると、右側のパネルの外観が変わり、選択した属性のすべての情報が表示されます。 次の表に、属性プロパティの名前とその目的を示します。

お名前	説明
お名前	属性名
一時的	Core Dataはこの属性を保存しません。 カスタムタイプまたはカスタムタイプをサポートするには、このタイプのプロパティを2番目の属性と組み合わせて使用​​すると便利です。 カスタムタイプについては、この章の後半で説明します。
オプショナル	オプションの属性はnilです。 オプションの属性は、nil以外の値をとる必要があります。
インデックス付き	インデックス付き属性は検索が高速ですが、より多くのストレージスペースを占有します。
属性タイプ	属性タイプ。 選択したタイプに応じて、特定の検証（検証）フィールドが表示されます。
検証	選択した文字列型の最小長と最大長、または選択した整数型の最小/最大値を設定するために使用します。
最小長	最小長の値のチェックを有効にするチェックボックス
最大長	最大長値のチェックを有効にするチェックボックス
最低	最小値チェックを有効にするチェックボックス
最大	最大値チェックを有効にするチェックボックス
デフォルト値	値が指定されていない場合のこの属性のデフォルト値。
登録 例	データを検証するための正規表現

リンクの表示と編集

属性情報を表示するときと同じように、リンクを選択することでリンクのプロパティを表示できます。



リンクにはいくつかのプロパティがあります。 まず、名前と有限のエンティティ（接続が属するエンティティ）があります。 最後のエンティティは、リンクが指すオブジェクトのタイプを記述します。 Playerエンティティの場合、チーム関係はTeamエンティティを指すことが期待されています。 コアデータアーキテクトは、各リレーションシップで逆の反発、つまり反対方向に向けられたリレーションシップを示すことを強くお勧めします。 たとえば、PlayerエンティティはTeamと接続しているため、実装に基づいて、推奨事項に基づいて、TeamもPlayerと接続する必要があります。 実際に、フィードバックを忘れたり、確立したくない場合は、コンパイラーによって警告が生成されます。 追加の2つのプロパティが属性に使用できます：TransientおよびOptional。 一時リンクは、保存操作中にストレージに保存されません。 チームのコミュニケーションが一時的なタイプの場合、アプリケーションを保存してから再起動すると、プレーヤーが所属するチームに関する情報が失われます。 Playerオブジェクトは保存されますが、Teamオブジェクトとの関連付けは保存されません。 一時的な通信は、パスワードやアプリケーションの操作中に取得した情報から取得したものなど、実行時に値を設定する必要がある場合に役立ちます。 接続がオプションの場合、単にnilに設定できることを意味します。 たとえば、プレーヤーにはチームがない場合があります。



通信の多重度により、ソースオブジェクトが関連付けることができる有限オブジェクトの数（1つまたは多数）が決まります。 デフォルトでは、関係はk-oneです。つまり、ソースオブジェクトは1つの最終にのみ関連付けることができます。 これは、Playerエンティティに対してチームを使用する例の場合のみです。プレーヤーは、チームを1つしか持つことができません。 ただし、チームには多くのプレーヤーを含めることができるため、Teamエンティティ内のプレーヤー関係には多対多の関係があります。 これらの値（多くの側から）は、（NSSet）オブジェクトのセットとして表されます。 通信の多重度は、通信中のエンティティの有限セットのパワーを表す最小値と最大値を変更することでも決定できます。



結論として、Core Dataは、元のオブジェクトを削除するときに最終オブジェクトをどう処理するかを知るために、リンク解除のルールを使用します。 Core Dataがサポートするアンインストールオプションは多数あります。 削除には、アクションなし、無効化、カスケード、拒否などの種類があります。 この章の「構成ルール」セクションでは、削除ルールとその意味について説明します。

クエリをプロパティとして使用する

これまでのところ、本ではすでに属性と関係について何度か言及しています。 エンティティが所有できる3番目のプロパティはクエリ（フェッチ）です。 プロパティとしてのクエリは、他のオブジェクトを参照できるという点で関係に匹敵します。 「接続」タイプのエンティティプロパティが有限オブジェクトを直接参照する場合、「リクエスト」（エンティティプロパティも）は、指定された述語によって選択されたオブジェクトを参照します。 プロパティとしてのリクエストは、iTunesの一種の「スマート」プレイリストであり、ユーザーは音楽ライブラリを指定し、特定の基準に従ってコンテンツをフィルタリングします。 プロパティとしてのクエリは、iTunesの選択と同じようには動作しませんが、最初のリクエストで一度計算されますが、この選択の結果は、 refreshObject:mergeChanges:



メソッドを呼び出して更新する必要があると自分自身が言うまでキャッシュされます。



たとえば、リーグマネージャーアプリケーションでは、名前が「W」で始まるチームのすべてのプレーヤーを返すクエリプロパティを作成できます。 チームエンティティを選択し、[取得したプロパティ]セクションの[+]ボタンをクリックして、新しいリクエストにwPlayersという名前を付けます。 Playerエンティティを最終エンティティ（クエリおよび返されるエンティティのタイプ）として選択します。



「述語」フィールドで、標準のNSPredicate形式を使用してフィルターの基準を指定します（形式とNSPredicateについては、第6章で詳しく説明します）。 この例では、述語はlastName BEGINSWITH "W"



ようになります。



その後、作成した名前クエリは、名前属性と同じPlayerオブジェクトの属性になります。 他の属性と同じ方法で使用できます。 League Manager application:didFinishLaunchingWithOptions:



委任メソッドにコードを追加することにより、追加されたリクエストの正しい動作を確認できapplication:didFinishLaunchingWithOptions:



は、 wPlayer属性を使用します。 以下に示すコードは、すべてのチームを要求し、最初のチーム（存在する場合）を取得し、wPlayer属性で指定された述語に従ってすべてのプレーヤーを選択します。 その後、条件を満たすすべてのプレイヤーがコンソールに表示されます（名前と姓）。

 NSFetchedRequest *fetchRequest = [[NSFetchedRequest alloc] init]; [fetchRequest setEntity:[NSEntityDescription entityForName:@"Team" inManagedObjectContext:self.managedObjectContext]]; NSArray *teams = [self.managedObjectContext executeFetchRequest:fetchRequest error:nil]; if([teams count] > 0){ NSManagedObject *team = [teams objectAtIndex:0]; NSSet *wPlayers = [team valueForKey:@"wPlayers"]; for(NSManagedObject *wPlayer in wPlayers) { NSLog(@"%@ %@", [wPlayer valueForKey:@"firstName"], [wPlayer valueForKey:@"lastName"]); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコードを実行のために実行すると、アプリケーションにすでにあるデータに応じて、およそ次の出力が表示されます。

 2011-07-31 19:08:23.005 League Manager[8039:f203] Dwyane Wade 2011-07-31 19:08:23.006 League Manager[8039:f203] Tyson Warner
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

考慮すべき最後の重要な点は、クエリをXcodeのプロパティとして作成することです。 アプリケーションでNSFe​​tchRequestsを使用するのと同じ方法で、クエリをプロパティとして使用できますが、プロパティとしてのクエリはモデルエディタで事前に定義されている点が異なります。 緑色のフォームカラーを持つすべてのチームを選択するプロパティとして新しいクエリを作成するには、たとえば、[エンティティ]セクションでチームエンティティを選択し、ドロップダウンリストが表示されるまで[エンティティを追加]ボタンを押し、このリストからオプションを選択します「フェッチリクエストの追加」。 このクエリを「GreenTeams」と呼びます。 Xcodeの中央の列には、新しいフィルター条件を追加するための「+」ボタンが表示されます。 [+]ボタンをクリックして、テキストボックスにuniformColor == "Green"と入力します。 すべてが次のようになります。





この方法で作成されたプロパティとしてのリクエストはデータモデルに保存され、 fetchRequestTemplateForName:



NSManagedObjectModelクラスメソッドを使用して取得できます。 application:didFinishLaunchingWithOptions:



コードを追加しapplication:didFinishLaunchingWithOptions:



デリゲートメソッドを使用して、新しく作成されたリクエストの状態を確認します。

 NSFetchRequest *fetchRequest = [self.managedObjectModel fetchRequestForTemplateName:@"GreenTeams"]; NSArray *teams = [self.managedObjectContext executeFetchRequest:fetchRequest error:nil]; for(NSManagedObject *team in teams){ NSLog(@"%@", [team valueForKey:@"name"]); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アプリケーションにあるデータに応じて、おおよそ次の出力が表示されます。

 2011-07-31 19:17:25.598 League Manager[8184:f203] Boston Celtics
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

エンティティ作成

これまでのところ、エンティティの議論に非常に積極的に取り組んできました。 エンティティは、管理対象オブジェクトが持つ属性と関係を記述します。 新しいエンティティを追加するには、「エンティティを追加」という碑文が付いた「+」ボタンをクリックし、名前を指定する必要があります。



デフォルトでは、エンティティオブジェクトのインスタンスはNSManagedObject型で表されますが、プロジェクトのサイズと複雑さが増すにつれて、管理対象オブジェクトを表す独自のクラスを作成する必要が生じる場合があります。 作成する管理対象オブジェクトはNSManagedObjectクラスから継承する必要があります。作成したクラスの名前は、エンティティを編集するときに[クラス]フィールドで指定する必要があります。





この段階では、まだエンティティの継承というトピックに触れていません。 エンティティの継承メカニズムは、作成された属性/メソッドが継承される場合のクラス継承メカニズムに似ています。 たとえば、Personエンティティを作成し、PersonからPlayerエンティティを継承できます。 アプリケーションに他の人の表現（トレーナーなど）がある場合、Coachの本質もPersonから継承できます。 プログラマーがPersonエンティティーのインスタンスを直接作成しないようにしたい場合は、このエンティティーが抽象であることを示す必要があります。 たとえば、dateOfBirthフィールドを持つPersonエンティティを作成し、抽象エンティティとしてマークします。





次の手順では、Playerエンティティを変更します。親（継承）Personエンティティを設定します。 Playerエンティティを選択し、「Parent Entity」というドロップダウンリストで「Person」を選択します。





これで、PlayerOffer属性のdateOfBirthが使用可能になります。

属性を作成する

属性はエンティティを記述します。 エンティティ属性は、エンティティの現在の状態を記述し、さまざまなタイプのデータで表すことができます。 エンティティを選択し、[属性]セクションで[+]をクリックします（新しい属性を追加します。名前を指定することを忘れないでください）。 以下の図は、可能な属性設定を示しています。





この章の前半で、さまざまな属性プロパティについて説明しました。 間違いなく最も重要な属性プロパティはそのタイプです。 デフォルトでは、Core Dataにはいくつかのタイプがあります：







上記のほとんどの型は、Objective-Cのデータ型に直接関連しています。 図から外れている唯一のタイプは、カスタム（プログラマーによって作成された）タイプ用に設計されたTransformableタイプです。 既存のタイプに必要なデータを含めることができない場合は、Transformableタイプを使用することをお勧めします。 例として、再びリーグマネージャーアプリケーションを使用できます。このアプリケーションでは、CGColorRef型で表現できる色を保存する必要があります。 この場合、属性はTransientおよびTransformableである必要があり、同時に、属性を既存の型に変換するCore Dataメカニズムを導入する必要があります。 NSManagedObjectを継承する独自のクラスを作成する場合は、カスタム（カスタム）属性を使用します。

リンクを作成する

正規化プロセスでは、データモデルの複雑さに応じて、多くの場合、複数のエンティティを作成します。 関係により、リーグマネージャーアプリケーションで行われているように、プレーヤーエンティティとチームエンティティを使用して、エンティティを相互に関連付けることができます。 コアデータを使用すると、接続を調整（悔い改め、この言葉が好きです）して、モデル化されたデータ間の関係を最も正確に反映できるようになります。



Xcodeでは、接続を作成するとき、または接続を選択するときに、接続の性質を変更できる一連の設定が表示されます。 たとえば、Playerエンティティでチーム関係を選択すると、おおよそ次の図が表示されます。





フィールドのリスト：

• 名
• 究極の実体
• フィードバック
• 一時的
• オプショナル
• 対多の関係
• 数量（最小および最大）
• 除去ルール

次のセクションでは、これらのフィールドをより詳細に調べ、それらがエンティティのプロパティにどのように影響するか、およびそれらの意味を説明します。

通信の名前（名前）

最初のフィールドNameは、接続に関連するオブジェクトの属性NSManagedObjectの名前になります。 受け入れられた契約によると、名前は小文字（小文字）でなければなりません。 接続が「多」の場合、名前は複数形にする必要があります。 数。 これらはすべて単なる合意であり、モデルをより理解しやすく、読みやすく、保守しやすいものにすることを理解することは価値があります。 リーグマネージャーアプリケーションでは契約に準拠しているため、プレーヤーエンティティの接続はチームと呼ばれます。 本質的に、プレーヤーとのチームコミュニケーションは「プレーヤー」と呼ばれます。

宛先と逆

次のフィールドDestinationは、接続のもう一方の端からのエンティティを定義します。 逆フィールドでは、同じ関係を選択できますが、最終エンティティの側面からのみ選択できます。



InverseフィールドをNo Inverse Relationshipに設定したままにしておくと、一貫性エラーと誤って設定された属性という2つの警告が保証されます。



無視できます。結局、これらは単なるエラーではなく、コンパイラの警告ですが、予期しない結果になる可能性があります。 Core Dataは、双方向通信情報を使用してオブジェクトグラフの一貫性を維持し、やり直し/元に戻す操作を処理します。 Inverseエンティティを指定せずに接続を離れると、Undo / Redo操作を実行するためにオブジェクトグラフの一貫性を維持する責任があります。 Appleのドキュメントは、特に多対多の関係を使用する場合には、これに対して強く助言します。 逆接続を指定しない場合、接続のこちら側の管理対象オブジェクトが変更された場合、接続の反対側の管理対象オブジェクトは変更済みオブジェクトとしてマークされません。

一時的

リンクを「一時的」としてマークすることにより、コアデータに、このリンクをストレージに保存する必要がないことを伝えます。 クロスリンクは引き続きRedo / Undo操作をサポートしますが、アプリケーションを閉じると消えます。 架橋のいくつかの可能な用途を次に示します。

• 一時的であり、現在のアプリケーション起動セッションより長く存在してはならないエンティティ間の関係
• いくつかの外部データソースから取得できる通信情報（別のコアデータストアまたはその他の情報ソース）

ほとんどの場合、接続を永続的に維持する必要があります。

オプショナル

次のフィールド（オプション）は、リンクをnilにできるかどうかを決定するチェックボックスです。 データベースフィールドのNULL値または非NULL値のようなものと考えてください。 チェックボックスが設定されている場合、リンクを指定せずにエンティティを保存できます。 チェックボックスをリセットしてエンティティを保存しようとすると、保存は失敗します。 リーグマネージャーアプリケーションのプレーヤーエンティティで、リセットチェックボックスを使用してチーム接続を終了した場合、各プレーヤーは特定のチームに属している必要があります。 チーム接続をnilで確立し、さらに保存（save：を呼び出す）メソッドを使用すると、「team is required value」というテキストを含むエラーが発生します。

対多の関係

このオプションはチェックボックスでもあります。 チェックボックスが設定されている場合、現在の接続はその端に多くのオブジェクトを示すことができます。そうでない場合は、「1対1」接続を取得します。

数量（最小および最大）

現在のオブジェクトが持つことができる通信側のオブジェクトの数を定義します。 このオプションは、「多対多」の関係が選択されている場合にのみ有効です。

保存中に制限を超えると、「項目が多すぎます」というエラーと、不十分な数である「項目が少なすぎます」が生成されます。

ちなみに、最小値は最大値よりも大きい場合がありますが、検証は実行されないため、一般にコアデータを満たします。 したがって、最小値が最大値よりも大きい場合、オブジェクトグラフを保存しようとしても失敗します。

ルールを削除

削除ルールは、リンクを持つオブジェクトを削除するときにCore Dataが実行する必要があるアクションを決定します。

削除には4つのタイプがあります。

1.カスケード-ソースオブジェクトが削除され、関連する（最終）オブジェクトもすべて削除されます

2.拒否-ソースオブジェクトがいくつかのオブジェクトに関連付けられている場合、削除は行われません

3. Nullify-元のオブジェクトは削除され、関連するすべてのオブジェクトのフィードバックはnilに設定されます。

4.アクションなし-元のオブジェクトは削除されますが、関連するオブジェクトは変更されません



リーグマネージャーアプリケーションでは、プレイヤーコミュニケーションの削除ルールはカスケードです。つまり、チームが削除されると、そのプレイヤーもすべて削除されます。 削除ルールを拒否に変更した場合、チームに少なくとも1人のプレーヤーがいた場合、削除は行われませんでした。 Nullifyで削除ルールを設定すると、すべてのプレーヤーがリポジトリに残りますが、チームへの参照はnullになりますが、チーム自体は削除されます。