Non-Fiction

　では、エンティティとエンティティの間の関係を設定しよう。まずはAlbumとSongListとの間に関係を設定する。

　Albumエンティティを選択した後、プロパティの追加ボタンをクリックして、「関係を追加」を選ぶ。これで、リストにnewRelationshipという名前で新しい関係が作られる。

　例によって左上の画面で関係の詳細を決めていく。名前、オプション、一時については属性の時と同じだ。SongListに対する関係なので、名前はsongListとしておく。ディスティネーションには関係付けるエンティティを指定する。当然SongListエンティティを選ぶ。
　「逆」は今は選べない状態のはずだ。ここはAlbumからSongListに向かう関係のみが設定されていて、SongListの方からはAlbumに対する関係は設定されていない状態ということだ。これは相手側（この場合はSongListエンティティ）の方に関係を追加すると、選べるようになる。
　「対多関係」にチェックを入れると、エンティティ一つに対して関係する相手が多数あるということになる。一つのアルバムには普通は何曲も入っているものだから、ここはチェックを入れよう。
　「ルールを削除」は英語版での表示はDelete Ruleで「削除のルール」と訳すべきところだ。（しかしひどい訳だな(^^;）エンティティを削除するときにこれに関係しているエンティティとの関係をどうするかを指定するところだ。ここの選択肢、アクションなし(No Action)、無効にする(Nullify)、重ねて表示(Cascade)、拒否(Deny)もなにがなんだか分からない訳なので、ここは英文に当たった方が良い。
　簡単に説明すると以下のような設定らしい。
　No Actionはその名の通り、削除されても何もしない。
　Nullifyはこのエンティティが削除されたら、相手のエンティティ側の関係プロパティを空にする。ただし、相手のエンティティ自体はそのまま残す。たとえば、アルバムの収録曲を削除するケースを考えてみよう。この場合、SongListエンティティが削除されるのだが、このときにAlbumエンティティは削除されたSongListとの関係を切る。が、Albumエンティティ自体は無くならないで残っている。このようなときにはNullifyを選択する。
　Cascadeはこのエンティティが削除されたら、関係している相手のエンティティも一緒に削除する。さっきとは逆にAlbumエンティティが削除された場合を考えてみよう。このときには収録されている曲はすべて削除されるので、このAlbumエンティティと関係しているSongListはエンティティごと削除される。このような場合はCascadeを選択する。ちなみにcascadeの辞書的な意味は、順送りに伝える、順々に並べるといったものだ。（もともとは階段状に連続する滝といった意味からこうなっているらしい。）
　最後のDenyだが、これは関係しているエンティティがまだ存在している時には、削除自体出来ないようにする設定だ。アルバムと収録曲の例で、アルバムを削除したら収録曲が勝手に消えてしまうことがないようにしたい場合、Denyを指定するといい。

　というわけで、この場合の関係は、CascadeかDenyが適切ということになる。ここはCascade(重ねて表示)を選んでおこう。

　さて、同じようにSongListにも関係を追加しよう。SongListにはAlbumとSongへの関係を追加する。Albumエンティティの時と同様にプロパティ画面で関係を追加して、左上の画面で編集する。Albumエンティティへの関係はalbumという名前に、Songエンティティへの関係はsongという名前にする。

　albumのディスティネーションにAlbumを指定すると、今度は「逆」の選択肢にsongListが現れるので、これを選択する。これは先にAlbumエンティティに追加してあったsongListプロパティ（関係）のことだ。SongListの方で「逆」の設定をしておくと、自動的にAlbumエンティティのsongListプロパティの方にも「逆」設定が追加される。ディスティネーションで選ぶのはエンティティだったが、「逆」で選べるのはプロパティであることに注意しよう。

　この手順を繰り返して、エンティティ間の関係を設定していく。今回の設定はここにまとめてある。

　すべての設定が終わると、下の画面にはこのような図が出来ているはずだ。以前にここで書いた下の図と比べてみて欲しい。ここまでで、このプログラムで扱うデータの設計が終わったことになる。この作業はデータモデリングと呼ばれる。