T字形ER データベース設計技法

見た目は確かに教科書っぽい感じがします。「データベース設計技法」とタイトルにあるので、論理設計もしくは物理設計に関する書籍かと思うかもしれません。しかし本書は、教科書でもないし、DB設計の技術書でもありませんでした。

本書は、「ビジネスドメインの解析手法」を学ぶものです。T字形ER手法という考え方を用いて、ビジネスの現場をモデル化する手法を学べます。ページ数も140ページ少々と少なく、見開きでひとつのタイトルを解説しているため、とてもわかりやすく理解しやすいです。

T字形ER手法では、テーブルを「リソース」と「イベント」という区別で扱います。概念の違いですので、物理設計には関係ありませんが、ビジネス解析(要求分析)の段階では、とても重要になってきます。

オブジェクト指向設計に通じるところもあり、本書で説明している概念を理解すると、ビジネスドメインでのデータの見方というのがしっくり来ると思います。業務アプリケーション開発者は一通り読んでおくと、設計時や開発時に参考になると思います。

解説

T字形ER手法では、「コード体系」を非常に重要な概念として扱います。Identifier、Resource と Event の区別、コード体系、サブセット、みなしエンティティの 5つのキーワードを理解するだけで、ビジネスモデリングに非常に効果的に働くと思います。

見開き構成になっていて、左で文章による解説、右で図を使った解説を行っており、とても理解しやすくなっています。紙質など、教科書っぽいところもありますが、それほど硬い文章ではありません。多少難しい言葉や聴きなれない言葉もありますが、内容の理解は容易だと思います。

分析・設計を行う開発者は、一度読むことをお勧めする良書です。後半、哲学的な話も出てきますが、そこを除いても120%おつりがくると思います。かなりお勧めします。

覚書き

T字形ER手法とは

「T字形ER手法」とは、「ビジネス解析技法」であり、データ設計技法ではない。業務で使われている「コード体系」をグループ化しながらビジネスを逆解析する技法である。

T字形ER手法では、データの集合を形成する元となるものが「コード体系」ということになる。

参考：Ｔ字形ＥＲ手法の概念

Identifier と Master-Key の違い

Identifier はデータ集合(エンティティ)を生成する判断基準となる。逆に、エンティティとは、Identifier を付与された、一つ一つの違いが認識できるものということになる。

マスターキーとはプライマリー・キーと呼ばれる、データアクセス用のキーであり、ビジネスにおいてのコード体系を表していないため、Identifier とは別のものと考える。データベース上においては、プライマリーキーは重複は許されないものとして扱われるが、Identifier は重複することがある。(例：ある契約において、営業所毎に契約番号が1から振られる場合、契約番号がIdentifier であるが、データベース上においては、営業所コードと契約番号でマスターキーとなる。)

本書

Identifier はけっして複合キーでは表されない。複合キーとして Identifier を表現する場合は、「結合ファイルまたは、ビュー」ということになる。

みなしエンティティというものがある。コード体系が存在しないが、エンティティとみなせるもののこと。　たとえば、従業員というエンティティの属性に「前会社名称」というものがあるとする。前会社名称というのは、前会社というエンティティの属性にするべきであるが、前会社コードのようなコード体系はない。こういう場合に、みなしエンティティとして、「従業員.前会社名称」のようなエンティティを導出する。

みなしエンティティは、エンティティの純度を高める上に、ゼロの多重度を利用することでヌル値を回避するサブセットとしても使える。

本書

エンティティ名の付け方

T字形ER手法では「コード体系」を主眼においてエンティティを見つける。コード体系において「○○番号」や「○○コード」とよばれるものから「番号」、「コード」を取り除いた○○の部分がエンティティ名となる。(例：「受注番号」 -> 「受注」)

「番号」、「コード」を取り除いたあとに、「○○書」、「○○伝票」などという言葉になった場合、「書」、「伝票」を取り除く。(例：「請求書番号」 -> 「請求書」 -> 「請求」)

コード体系に表現されていないコードを勝手に使ってはいけない。

Resource (リソース) と Event (イベント) の違い

リソースは、事やモノに区別されるもの。イベントは、事象や履歴、事実などのこと。

Event であるかは、タイムスタンプを設定できるかどうかによる。タイムスタンプが設定できるのであれば、それは履歴や事実を表すことができる。

Resource は非常に重要な概念である。Resource と Event を比べて、Resourceの数のが多ければ、Resourceを元に Event を構築することが可能になる。

Resource と Event の関係は3つのパターンになる。

Resource - Resource
　Resource - Resource の関係は、「対照表(関係テーブル)」を用いて表現する。
Resource - Event
　Event のほうに、Resource の参照キーを定義する。
Event - Event
　Event の並び順は、ビジネス上の時系列にそって並べる。このとき、「1 : 1」、「1 : 多」であれば、時系列の遅い Event に参照キーを定義する(後ろのEvent)。「多 : 1」、「多 : 多」の場合は、「対応表」を用いる(対応表と対照表は同じようなもの)。

対照表(関連テーブル)は実質的には Event として扱われる。例えば、顧客 (Resource) と銀行 (Resource) と口座 (Resource) の対照表(関連テーブル)は 口座開設という Event と取れる。

方式の対照表

T字形ER手法では、3つ以上のエンティティを一度に接続する対照表(関連テーブル)は認めていない。上記の例の場合だと、顧客と銀行と口座を一度に接続することは認められていない。これは、ビジネス解析が難しくなるという理由からである。T字形ER手法では、2つのエンティティのみを接続する Binary 方式だけを認めている。

では、上記の場合どうするのかと言うと、顧客と銀行への対照表(顧客.銀行.対照表)を導出したあとで、顧客.銀行.対照表と口座との対照表を導出する。対照表とエンティティを接続した対照表を導出することは、T字形ER手法では推奨される手法の一つなのだ。

本書