前回までの数回の記事で、【T字形ER手法】を用いて、ER図を解析しました。
今回は、【T字形ER手法】について、簡単に紹介します。
提唱者
【T字形ER手法】は、株式会社エス・ディ・アイの佐藤正美氏が提唱する
「ビジネス解析技法」です。
システムエンジニア（SE）が、業務の担当者から数時間、ヒアリングしたり、業務フローを
解析したところで、その業務を完全に理解するのは困難な事です。
ヒアリングしないよりは、ヒアリングした方が理解は深まりますが、毎日、
対応されている業務の担当者が断然詳しい訳で、コンサルタントだろうが、
ベテランエンジニアでも、完全に理解は出来ないと思います。
佐藤正美氏は、ビジネスにおいて実際に使用されているデータから、
【T字形ER手法】を利用して、「データそのものに喋らせる」という
ビジネスを逆解析する思想に至ったようです。
コード体系
仕事をしている多くの方は、毎日、たくさんのデータを使われていると思います。
専用のシステムを利用されている方、アプリを利用されている方、Excelのような
表計算ソフトを利用されている方、メールやチャット、SNSを利用されている方など、
データは切っても切れない仲だと思います。
多くのデータは、専用サーバーやクラウド上のデータベース、パソコンやスマホの
ハードウエアに蓄積されます。
データは、一定のルールに従って蓄積されています。
後から検索されたり、内容を表示して読まれたり、更新したり、削除したりもします。
データが紐づけされる場合、直ぐに思いつくのが日時だと思います。
登録日時、更新日時、削除日時、送信日時、受信日時、申請日時、承認日時…
多くの日時が、データに紐づけされていますが、データに紐づく補足内容が多いと、
日時以外に「ある印」が必要になってくると思います。
この「ある印」がコードと言われるもので、コードをネットなどで検索すると、
「情報を効率的に管理・処理するために、モノや情報に割り振られた記号（コード）の体系」
と表現されています。
実際に仕事には、会社コード、部門コード、商品コード、倉庫コード、銘柄コード…
多くのコード体系が有ります。
【T字形ER手法】では、コード体系を中心に解析していきます。
identifier（識別子）
【T字形ER手法】では、identifier（アイデンティファイアー：識別子）という表現が出て来ます。
identifierは、コード体系の中に記述されているコードまたは番号を使います。
システム、アプリ、帳票、データ、ビジネス等を分析する際、下記の表現が出て来たら、
identifierの候補になりますので、ピックアップしてみましょう！！
- ～コード or ～CD 【例】会社コード、部門コード、取引先CD
- ～番号 or ～NO 【例】社員番号、棚番号、請求NO
- ～区分 or ～KB 【例】会員区分、口座区分、配送KB
- ～種別 or ～SB 【例】栄養種別、カラー種別、
identifierは、対象となるモノから付与されて、1つのデータ項目を使って表現されます。
上記のコード体系を例える、会社のidentifierは、「会社コード」なります。
また、社員のidentifierは、「社員番号」となります。
エンティティの分類
【T字形ER手法】では、基本的に「エンティティ」を下記の4つに分類しています。
- リソース（Resource、事物）：マスター系のエンティティになります。ひとつのidentifierと、identifierに対するアトリビュート（名称）が設定されます。
- イベント（Event、事象）：トランザクション系のエンティティになります。ひとつ以上のidentifierと、identifierに対するアトリビュート（名称、タイムスタンプ）が設定されます。
- 対照表（Comparison table）：関係する２つのリソースとリソースを結んだ際に、生成されるエンティティです。また、関係する対照表とリソースや、関係する２つの対照表と対照表を結んだ場合にも、対照表が生成されます。対照表には、双方のidentifierが、参照キーとして挿入されます。identifier＋identifierで、ユニーク（一意性）となり、業務分析した際、identifier＋identifierに対するアトリビュート（名称）が設定されます。対照表は、【T字形ER手法】の最大の特徴になります。
- 対応表（Correspondence table）：「イベント（時系列が早い）：イベント（時系列が遅い）＝複数：1 or 複数：複数」の場合に、対応表が生成されます。「イベント（時系列が早い）：イベント（時系列が遅い）＝1：1 or 1：複数」の場合は、対応表が生成されず、イベント（時系列が遅い）側に、イベント（時系列が早い）のidentifierが、参照キーとして挿入されます。対応表も、【T字形ER手法】の特徴になります。
リソースとイベントの識別方法
リソースとイベントの識別方法ですが、簡易方法として「エンティティ名称」やコード体系の中に
記述されているコードまたは番号を外した「名称」に対して、「○○する」という動詞を付与して、
意味が通じない時は、リソースになります。
逆に「○○する」という動詞を付与して、意味が通じれば、イベントになります。
例えば、「エンティティ名称」が【会社】またはコード体系で【会社番号】だったら、
「会社する（？？）」となり、意味が通じないのでリソースの判断になります。
一方、「エンティティ名称」が【請求】またはコード体系で【請求番号】だったら、
「請求する（！！）」となり、意味が通じるのでイベントの判断になります。
T字形ER図の見方
上記の「サンプルER図」をご覧ください。
【T字形ER手法】は、他のER図と異なり、エンティティ（データ集合）と言われる
ひとつの器の中を【T字形】を利用して、3分割しているのが特徴です。
・上部：エンティティ名称を記載します。
・左下欄：identifierや参照キー等のコードを記載します。（他のER図では上部で設定されるケースが多いです）
・右下欄：attribute（アトリビュート）を記載します。
佐藤正美氏から、直接お聞きしましたが、【T字形】をしたER図は、元々、会計コンサルタント
をされていた経緯で、「貸借対照表」から発想を得て、【T字形】をしたER図を提唱した
との事です。
メーカー（リソース）
「メーカーする（？？）」となり、意味が通じないのでリソースの判断になります。
・上部（エンティティ名称）：メーカー（物理名：makers）
・左下欄（identifier）：メーカーID（物理名：maker_id）
・右下欄（attribute）：メーカー名（物理名：maker_name）、登録日（物理名：created_at）、更新日（物理名：updated_at）
製品（リソース）
「製品する（？？）」となり、意味が通じないのでリソースの判断になります。
・上部（エンティティ名称）：製品（物理名：products）
・左下欄（identifier）：製品ID（物理名：product_id）
・右下欄（attribute）：製品名（物理名：product_name）、製品詳細（物理名：product_detail）、製品原価（物理名：product_price）、製品希望売値（物理名：sell_price）、登録日（物理名：created_at）、更新日（物理名：updated_at）
メーカー．製品（対照表）
２つのメーカー（リソース）と製品（リソース）を結んだ際に、生成されるエンティティ。
「メーカー（リソース）：製品（リソース）＝1：複数（m）」の関係
・上部（エンティティ名称）：メーカー．製品（物理名：maker_products）
・左下欄（参照キー）：メーカーID（maker_id(R)）、製品ID（product_id(R)）
・右下欄（attribute）：登録日（created_at）、更新日（updated_at）
カテゴリー（リソース）
「メーカテゴリーする（？？）」となり、意味が通じないのでリソースの判断になります。
・上部（エンティティ名称）：カテゴリー（物理名：categories）
・左下欄（identifier）：カテゴリーID（物理名：category_id）
・右下欄（attribute）：カテゴリー名（物理名：category_name）、登録日（物理名：created_at）、更新日（物理名：updated_at）
メーカー．製品．カテゴリー（対照表）
メーカー．製品（対照表）とカテゴリー（リソース）を結んだ際に、生成されるエンティティ。
「メーカー．製品（対照表）：カテゴリー（リソース）＝複数（m）：1」の関係
・上部（エンティティ名称）：メーカー．製品．カテゴリー（物理名：maker_product_categories）
・左下欄（参照キー）：メーカーID（maker_id(R)）、製品ID（product_id(R)）、カテゴリーID（category_id(R)）
・右下欄（attribute）：登録日（created_at）、更新日（updated_at）
注文（イベント）
「注文する（！！）」となり、意味が通じるのでイベントの判断になります。
「メーカー．製品．カテゴリー（対照表）：注文（イベント）＝１：複数（m）」の関係
・上部（エンティティ名称）：注文（物理名：orders）
・左下欄（identifier）：注文ID（物理名：order_id）
・左下欄（参照キー）：メーカーID（maker_id(R)）、製品ID（product_id(R)）、カテゴリーID（category_id(R)）
・右下欄（attribute）：注文内容（物理名：order_name）、注文詳細（物理名：order_detail）、注文価格（物理名：order_price）、登録日（物理名：created_at）、更新日（物理名：updated_at）
※注文（イベント）注文の右下欄（attribute）には、注文数、注文合計金額を含めていませんが、
実際の現場で分析する場合は、必要に応じて、右下欄（attribute）に設定して下さい。
まとめ
今回、【T字形ER手法】について、簡単に紹介しました。
データベース（RDBMS）を活用したシステム開発やアプリケーション開発の現場で、必ず役立つ
手法になりますので、この機会に学んでみるのも良いと思います。
詳しくは、下記の書籍を参照頂ければと思います。
是非、現場のER図を元に、【T字形ER手法】で分析してみて下さい。
- イラスト：いらすとや より引用
コメント