JBI オンラインスタディR [リレーション]

これは、同じ「購入記録」テーブル内のことです。そのため、同じテーブル同士のリレーションをしてその件数を算出したいと思います。（リレーション以外にも方法はありますが、ここでは自己リレーションでやってみます）

データベース管理のリレーションシップグラフで、基点となるのは購入記録TO ですね。リレーション用 TO として複製するのは同じ購入記録TO になります。

ではこの自己リレーションを使って、ポップオーバーボタンとともにポータルを配置してみます。

ポップオーバーボタンは、ステータスツールバーの「ボタン」にある小さな ▼ をクリックすると切り替えられます。レイアウトには、そうですね、カテゴリフィールドを少し幅を小さくしてスペースを作り、そこに配置します。

ボタン・ポップオーバーボタンはレイアウトに関することなのでここでは詳しくやりませんが、ポップオーバーボタンは吹き出しのようなものを出すことができる機能です。

設定ダイアログの上部にある「■」でアイコンだけをボタンに表示できますが、吹き出しのようなものに取りあえずしておきます。

ポップオーバーを少し拡げておいて良いかも知れません。

そこにポータルを配置します。

ブラウズモードで、ポップオーバーボタンを押してみてください。ポータルに購入記録テーブルの情報が表示されているでしょうか。それはクリックしたレコードのカテゴリと同じレコードになっているでしょうか。

上の図では、クリックしたレコードのポータルには「録音機器」で関連するレコードが9件表示されました。（＊クリックしたレコードも件数に含まれます）

購入記録レコードは82件ありますが、「録音機器」のレコードが9件で合っていることを確認してみてください。（＊ご自身のファイルで件数が異なる場合でも、ポータルの件数と合っていれば問題ありません。）

念のため他のカテゴリを見てみます。「周辺機器」が格納されているレコードは6件ありました。

カテゴリが「周辺機器」になっているレコード（どのレコードでも良いが下の図で言えば ID が 3 と 9 のレコード）のポップオーバーを見てみると、ポータルには6件になっていて合っています。（＊クリックしたレコードも件数に含まれます）

リレーションは通常では他のテーブルのレコードと関連します。自己リレーションの場合は、同じテーブル内のレコードと関連します。

思い切った例えを言うと、学級がA,B,Cと3クラスあったとします。Aクラスに佐藤さんがいて、通常のリレーションはBクラスの佐藤さんやCクラスの佐藤さんと手を繋ぎます。自己リレーションの場合は同じAクラス内にいる佐藤さん同士で手を繋ぎます。

さて、とはいえポータルの場合はパッと見て何件か分かりづらい側面があります。

そこで、計算フィールドを使って件数を計算させ、それをレイアウト上に配置してみます。

データベース管理を開き、「c_同じカテゴリの数」というフィールドを一つ、計算タイプで作成します。

左下の「計算結果」は「数字」にします。

そして関数の「Count」を使ってみますので、右の関数一覧から「Count」を選びます。検索すると早いかもしれません。

真ん中の白い計算エリアに入れるには、「Count ( フィールド {; フィールド...} )」をダブルクリックします。

ポップオーバーボタンは一旦上の方に移動してお役御免にしておきます。代わりに、今作った「c_カテゴリ数カウント」を配置します。

同じカテゴリの数が表示されたでしょうか。

このように、同じテーブル内でリレーションする「自己リレーション」を場面場面で使えるようになると、リレーションのレベルを一段上げることができます。必要に応じて是非トライしてみてください！

唐突ですが、TO ラインの真ん中にある「＝」をダブルクリックしてみてください。（あるいは下部の「テーブル/リレーションシップ」にある鉛筆マークをクリック）

着目したいのは、テーブルとテーブルの間にある「＝」のプルダウンです。

TO 名では「＝」を 「@照合フィールド」で表現していますが、リレーションの8割以上は「＝」です。そのため普段はあまり気にすることはありませんが、場合によってはこの記号を「＝」以外に設定する必要が生じる場合もあります。

使う機会は2割以下なので必ずしも覚える必要はありませんが、ざっと各記号についてご案内します。

これらの記号を使ったリレーションの場合、TO 名を見ただけではどんな記号で繋がったリレーションなのかが分かりません。「購入記録_self@カテゴリ」のように照合フィールドを表現する「@」だけでは「＝」なのか「≠」なのか「x」なのか正確には判別がつかないのです。

そこで、@ の「＝」以外については、@ の代わりに別の表現を使って判別できるようにすしてみます。そうすることでより分かりやすくなるはずです。

これまで照合フィールドは一つだけのパターンで実践してきました。

照合フィールドは１つだけではなく、複数フィールドによるリレーションも要件によっては必要になります。例えば次のようなシチュエーション（目的）を想定して、実践してみましょうか。

【シチュエーション（目的）】

上の自己リレーションでは同じ「カテゴリ」の件数（レコード数）を見たい目的がありました。同じ「カテゴリ」に加えて同じ「購入日」の件数（レコード数）も見たくなったとします。

この場合、「カテゴリ」フィールドに加えて「購入日」フィールドも照合フィールドとし、２つの照合フィールドで設定します。では実践してみます。リレーションが増えるので、下図のように少しスペースを空けます。

ではレイアウトのボディに配置して確認してみます。

場所がないので、購入品あたりを小さくするなどスペースを空けて配置してください。

表示された数値が正しいか、確認してみてください。同じカテゴリで、かつ同じ購入日のレコード数になっているはずです。

このシチュエーションは照合フィールドが２つのパターンでした。

目的によっては３つ、４つになる場合もあります。その場合の TO 名は・・・・・・

これまでは、基点 TO に対して１階層だけのリレーション用 TO を設定してきました。

これらの関係を「親子」で表すことがあります。つまり、基点 TO を「親」、リレーション用 TO を「子」という感じです。

シチュエーション（目的）によっては、「親子孫」の3世代（3階層）や「親子孫ひ孫」の4世代（4階層）になる場合もあります。

初期のデータベース構築では状況的に多くはないので、ここでは詳しくやらずにリレーションのイメージだけ掲載しておきます。

以上、ざっとリレーションが複数になる場合を見てきました。「親子孫」の3世代以上のシチュエーションで、多くは設計や仕様をよく考える必要があります。必要に応じて本実践のほうでご相談・サポートをさせて頂きます。

（次のセクションの『複数が繋がってリレーションがうまくいかない!?　それは「多対多」かも』で少し実践的に触れています。）

このページは以上になります。

ここまでお疲れ様でした！