第七回　データベースの重要ポイント「リレーション」

2017.10.25

第六回では、ExcelからFileMakerへの移行について取り上げました。次は、データベースのリレーションについてです。

データベースにおけるリレーション

FileMakerでの業務システムの作り方の出発点として、データベース活用のポイントを解説します。データベースでのデータの持ち方として、顧客名や住所など共通する部分と今日の発注など個別的な部分を分けてテーブルを持つこと、共通するテーブルは一つにすることを解説しました。
今回は、これらのテーブルを関連付けて一つのデータとして活用する「リレーション」の方法を定義し、関連付けをする考え方を、まず一般的なデータベースの概念で説明します。

よくある例として、受注データのように共通部分のと明細部分がある「親子パターン」、共通の顧客マスタを使う「マスタパターン」を取り上げます。

図　データベースにおけるテーブル間のリレーションパターン

（１）親子パターン

一つの受注書に複数商品の発注が含まれるとき、親データ（受注データ）一つに対し、子のデータ（明細データ）が複数になります。
テーブルで管理する場合に、一つの受注で共通な情報（親）として受注番号、受注日、顧客名、合計金額があり、一つの受注で複数発生することがある明細情報として商品名、数量、単価、金額などがあります。

これをデータベース（DB）で定義するときは、受注親テーブルと受注明細テーブルを別々に作ります。受注親テーブルが１個に対して、受注明細テーブルがN個紐づく、1対Nの関連になります（図）。

　
（２）マスタパターン

複数の受注データに入っている顧客名に対して、顧客の住所や電話番号など固定的な情報を顧客マスタで管理するケースです。
受注テーブルの項目には、受注番号、受注日、顧客ID、合計金額などがありますが、顧客IDによって顧客テーブルにある顧客名などを関連づけます。同様に、受注明細データに持っている商品は、商品マスタから出しています。つまり、顧客名や商品名など、固定した情報は一つのテーブルをつくり、その都度情報を関連付けさせるのです。

いずれの場合も、「受注テーブル側」がN個に対して、「顧客マスタ」側が1個紐づく、N対1型のリレーションになります。

（３）リレーションの決まりごと

テーブル間でリレーションを作るときは、各テーブル間で相手がどのレコードなのかを指定する同じ項目を用意して、その項目同士を紐づけます。

図の親子パターンでは、「受注親テーブル」にある「ID」と、「受注明細テーブルにある「受注＿ID」が同じものを指しており、紐づきます。
同じくマスタパターンでは、「受注テーブル」の「顧客＿ID」が「顧客マスタ」の「ID」と紐づきます。

データベースの一つのテーブルでは、テーブル内の全レコードに対して他と違うただ一つの（ユニークな）値を持つ項目を設定します。図では「ID」がそれにあたります。テーブル間のリレーションにおいて、N対1または1対Nの「1」にあたるテーブル側は、ユニークなIDを用いるのが一般的です。「N」側では、他のテーブルに関連付けたい時には、相手のテーブルのレコードを特定できるような項目を持ちます。図1ではそれぞれ「受注_ID」「顧客＿ID」がそれにあたります。

これによってお互いのテーブル間で相手側のレコードの特定ができるようになります。

「受注テーブル」では、リレーションしたIDを通じて「顧客マスタ」に設定されている顧客名を参照して顧客名を表示できます。ただ、商品名なら変わりませんが商品の単価のように時期によって変更があるものは、その時の単価を正しく表示するため、テーブルに表示された金額データを受注明細データに直接取り込むのが望ましい使い方です。

次回は、FileMakerにおけるリレーションの設定について解説します。

（第八回に続く）

→連載トップページに戻る

無料メール会員登録はこちら

送付先等会員情報の変更