テーブル関連の「排他性」をモデル上で表現する

　どんなに複雑に見えるデータモデルでも、テーブル関連には親子関係、参照関係、派生関係の３種類しかない。ただし、それぞれの関連には排他的なものとそうでないものがある。これを見かけ上区別できるような工夫を紹介しよう。ここらへんを理解しておけば、データモデリングのスキルがワンランクアップする。

　まず、参照関係の例を見よう。あるテーブル(B)に置かれたレコードが、別のテーブル(A)上のレコードに対して対応関係を持つとする。このとき、B上のAへのアクセスキーが、B自身の主キーに包含されていない場合、両者の関係を参照関係という（図１）。この場合、B側のテーブルを「参照元」、A側を「参照先（被参照）」といい、B側のアクセスキーを外部キー（または参照キー）と呼ぶ。

図１

　ここで、BがAの他にA'の間にも参照関係を持つとしよう（図２）。ここで、BがAとの対応を持つときはA'との対応を持たず、A'との対応を持つときはAとの対応を持たない、つまり、BにとってAとA'との参照関係が「排他的」に成立するとしよう。

図２

　図２では見かけから排他性が読み取れない。そこで、図３のように参照元からの複数の参照先に対する関連線の起点を意図的に重ねる。結果的に、BにとってAとA'への対応が「分岐的」であることが示され、排他性を見かけ上区別できるようになる。個々の関連定義が機能的に排他性を意味するわけではないが、見た目でそれを読み取れるのであればデータモデルとしてはより良い。

図３

　具体例を見よう。私が「汎用アクセスキー」と呼ぶモデリングパターンにおいて、その典型例が表れる。図４は売掛増減履歴（売上明細とも呼ばれる）と、売上計上を引き起こす各種のトランザクションとの関係を示すモデルである。各トランザクションは「取引管理№」というセカンダリキーを持っていて、売掛増減履歴はこれを「汎用アクセスキー」としてトランザクションへの参照を行う。ただし売掛増減履歴にとって、「売上の元ネタ」となるトランザクションは、取引区分の値に従って排他的に対応するのである。

図４

　なお、図ではわかりにくいが、関連線の参照先への終端が「十字架」ではなく「オプショナル付の十字架（１件対応するかもしれないし何も対応しないかもしれないことを意味する）」になっている。XEAD Modelerでは、終端部分にマウスカーソルを置くと、上図で示したように参照キーと対応条件とがバルーン表示されるようになっている。

　次に親子関係について見よう。親子関係は多重度の側面においては参照関係と似ているが（いずれも１対Ｎ）、子テーブルの主キーが親テーブルの主キーを包含する点が異なる。このトポロジーの違いは大きい。レコードが追加されてから削除されるまで主キー値の変更が許されないゆえに、子レコードは所属する親レコードを切り替えられない（いっぽう参照元レコードは参照先レコードを切り替えられる）。説明は省くが、この特性はデータ要件の本質的な違いとなって、システム仕様に決定的な影響をもたらす。

図５

　親子関係での排他性についても、図６のように参照関係と同様に表現できる。ただし、形式的には表現可能だが、実際例としてはまれである。

図６

　３つ目の関連である派生関係について見よう。これは、同じ主キーを持つテーブルの間に成立する。とくに、同じ主キーを持つテーブル同士が"[１]対[１または０]"の多重度を持つ場合、これを派生関係と呼ぶ(*1)。このとき、「１」側を「スーパータイプ」、「１または０」側を「サブタイプ」と呼ぶ。図７では、「１または０」として対応しているA'側がサブタイプである。サブタイプにはスーパータイプの「拡張属性」が格納される、という意味合いで理解してもらえばよい。

図７

　典型的な例が「取引先」、「顧客」、「仕入先」との関係である（図８）。多くの取引先は顧客または仕入先としていずれかのレコードのみを伴うが、ある種の取引先は顧客レコードと仕入先レコードを同時に伴う（商社ではそのケースがしばしばある）。つまり、取引先にとって顧客と仕入先は「排他的ではない」のである(*2)。

図８

　図８ではスーパータイプからの複数サブタイプへの起点が重なっているので、見かけ上は排他的な関係と区別がつかない。汎化関係の排他性については他の表記形式を使わざるを得ない。そこで、図９のように関連線を配置する。複数のサブタイプへの「分岐」が強調され、排他性が端的に示される。

図９

　図９は、筆者が仕様と実装を公開している「組立型生産管理システム」の在庫管理方式（在庫推移監視法）の基礎となるモデルだ。「受払予定」はさまざまな入出庫を引き起こすトランザクションを抽象化したテーブルで、これをスーパータイプとし、各トランザクションテーブルがサブタイプとして排他的に関連する。ここでもセカンダリキー（取引管理№）が効果的に使われている。

　じつはこれまでのXEAD Modelerでは、汎化関係については図８の表現しかできなかったため、その排他性をうまく表現できなかった。そこで、図９のような独特な表現向けの描線ロジックを最新版(1.4.7)から組み込んだ。活用してほしい。

*1."[１または０]対[１または０]"であるような関係は、意味のある制約を伴わない偶発的な関係とみなされるため、重要視されない。また、"[１]対[１]"のような関係があるとしたら、２つのテーブルに分かれていることの理由がないので、少なくとも論理レベルのモデリングとしては未完成とみなされる。
*2.３つのテーブルの主キーが異なるように見えるが、仕入先№にも顧客№にも、取引先№と同一のドメイン（変数域）が設定されている。フィールド名が異なるのは見かけだけの問題である。