前回の記事を、簡単に振り返ってみます。
サンプルER図（問題提起）
下記のER図のサンプルを見て下さい。
これは、開発現場で多く見掛ける「販売管理システム」のER図の一部です。
全体のER図が描かれていないので、少し判断が難しいかもしれませんが、
- 【メーカー（エンティティ：makers）】
- 【製品（エンティティ：products）】
- 【カテゴリー（エンティティ:categories）】
と「リレーションシップ（Relationship：関連）」は、正しいでしょうか？
利用ツール：A5:SQL Mk-2
回答
ずばりお答えします
正しいか？と問われるなら、
- 結論から言いますと、分からない
- 該当する業務やシステムのデータ、コード体系を分析していないので
- 結果的に正しいかもしれないし、正しく無いかもしれない
これが率直な回答です。
回答の理由
- 結論から言いますと、分からない
- 該当する業務やシステムのデータ、コード体系を分析していないので
- 結果的に正しいかもしれないし、正しく無いかもしれない
これが率直な回答です。
その上で、開発現場で実際にER図を作成された「エンジニア」や「DA（データアナリスト）」、
「DBA（データベースアナリスト）」に問い合わせをします。
実際の開発現場で起きた事
- このER図は、どのよう導かれたのですか？
と、丁寧な問い合わせをさせて頂いたものでした。（事実）
ところがですよ… 何だろうなぁ…
丁寧な問い合わせをさせて頂いたにも拘わらず、多くの現場で返って来る言葉は、
- 何故、そんな事聞くの？
- 何年も、この仕事に携わっているから、このER図は間違い無いよ！！
- データベーススペシャリスト（情報処理技術者）、オラクルマスター（Oracle Master）のゴールドを保有している私が作成したER図なのだから、間違い無い！！
- 先輩から引き継いで、何十年とメンテナンスをしているER図だから、間違い無いですよ
- 新参者が！！ 協力会社でしょ！！ 口を出すな！！
- 当然、ER図作成ツールを使って導いたので、間違い無いでしょう…
- 業務の現場から、直接ヒアリングをして、テーブル設計に何十時間も費やしたのだから、間違い無い！！
- 正規化しない方（非正規化）が、レスポンスが良い！！
といった具合で、殆どが感情的な回答でした。
私としては、プロジェクトが進行して来て、頑張っているプロジェクトのメンバーに対して、
人格を否定するつもりは全く無くて、どのように業務内容や扱うデータを分析されて、
どのように（How ?）「ER図」を作成されたか聞きたかったのですが、何故（Why ?）
この「ER図」を作成されたのか？…と聞きたかった訳では無いのです。
「ER図」を作成された「エンジニア」や「DA（データアナリスト）」、「DBA（データ
ベースアナリスト）」が、
- 何か聞かれて、まずい事でも有るのかな？
- ER図の描き方や使用しているツールを、無料（ただ）で教えたく無いのかな？
- テクニックを盗まれると思っているのかな？ テクニックなんて無いと思うけど…
- エンジニアさんって、口下手（くちべた）な人が多いから、恥ずかしいのかな？
- 実装漏れが見付かるのが、嫌なのかな？
と、その当時は、現場で推測するような日々でしたね。（笑）
私の本音
上記が、現場で推測するような日々でしたが、実際のところ、本音は、
- 幼稚園児が、お絵描きしてるんじゃね～よ！！
- 論理的に解説が出来ないって、まともにコード体系やデータ分析してないんじゃんか！！
- メンテナンスに苦慮しているのって、あったり前じゃん！！
- 顧客から、高額な契約金を搾取して、この程度かよ！！
- 正規化しないから、いつまでもレスポンスが悪いんだよ！！
- 怖がって、協力会社に圧力掛けるなって！！ 役割が違うのだから、出来ない部分は、頼ればいいじゃん！！ その為の協力会社なんだから… 元請は、元請の仕事に専念すれば！！
- 何が、データベーススペシャリストだよ！！
てな感じです。
サンプルER図（逆解析）
では、問題提起したサンプルER図を、逆解析して行きたいと思いますが、その前に、少しだけ
データベースの設計手法との出逢いについて、簡単に紹介します。
T字形ER手法との出逢い
私は運が良かったのか、新卒で入社した最初の企業で、3年目くらいの時に最年少で、
自社でサービスしていた【受発注システム再構築プロジェクト】に任命されました。
彼是（かれこれ）、30年程度、昔の話です。
（再構築プロジェクト終了後に、2000年問題の対応に途中参加したのも覚えています。）
このプ再構築ロジェクトで、初めて【T字形ER手法】に出逢いました。
当時は、社内で【受発注システム再構築プロジェクト】の話が進み、部長や課長、先輩が
様々な開発スタイルや設計方法を調査していて、偶然にも【T字形ER手法】を探し当て、
セミナーに参加した後、社内で検討を重ね、最終的に【T字形ER手法】を提唱する
株式会社エス・ディ・アイの佐藤正美氏と契約に至り、コンサルタントとして、
招聘される事になりました。
佐藤正美氏が月に何度か、コンサルタントで来社された際、直接的に指導されたのは、
DA（データアナリスト）、DBA（データベースアナリスト）の担当となる2名の先輩でした。
その為、私達のプログラマーチーム（5名）は、DA/DBAの先輩達が作成されたER図を理解して、
再構築のプログラムを作成していた為、佐藤正美氏とは間接的な接触でした。
佐藤正美氏と直接的に接触が出来たのは、コンサルタントを頂いた企業を退職した後でした。
転職した別企業で、【営業支援システム再構築】をプロジェクト・リーダーとして任命された際、
佐藤正美氏の3～4何番目（？）のお弟子さんと、コンサルタント契約に至り、彼らを通じて、
飲み会の席で、佐藤正美氏と直接的に接触する事が出来ました。
それ以来、開発に携わる際、【T字形ER手法】を取り入れていました。
※【T字形ER手法】ですが、住友電工情報システム株式会社 製品である 楽々Framework の
基本思想となっています。
T字形ER手法の特徴
【T字形ER手法】の特徴は、下記になります。
- ビジネス解析手法（コード体系に準拠）：単なるデータ設計技法ではない
- entity（エンティティ）：管理対象として捕捉する存在で、identifierが付与されている → オブジェクト指向で表すと、class相当になる
- identifier：コード体系において、独立した集合として認知する為に付番された単独の管理番号
- T字形の左辺：主語のidentifierが記述される（xxxxx_id, xxxxx_NO, xxxxx_cd…等）
- T字形の右辺：主語のidentifierに対する、述語のattribute（アトリビュート）が記述される（xxxxx名、xxxxx詳細、xxxxx数、xxxxx金額、登録日、更新日…等）
- resource（リソース）：event以外のentityをresourceとする（一般的には、マスタ系）
- event（イベント）：性質として、「DATE」や「DATETIME」が帰属する（一般的には、トランザクション系）
- 対照表：resourceとresourceを結んだ際に生成される → 「T字形」を形成している最大の特徴であり、一般的には「中間テーブル」とも言われる
- 対応表：「event：event＝複数：1」の場合に、対応表を生成する → 「event：event＝1：1」の場合は、対応表は生成せず、時系列の遅いeventに参照キーを挿入する
詳細は、
を御覧下さい。
【T字形ER手法】については、別の機会に記事にして御紹介します。
サンプルER図を、逆解析
では、問題提起をしたサンプルER図について、逆解析して行きたいと思います。
【T字形ER手法】を用いて、サンプルER図を解析すると、3つのER図を導く事が出来ます。
製品エンティティ（resource）のアトリビュートに製品情報を挿入
先ず、初期の解析段階で、「製品エンティティ」のアトリビュートに、「製品情報」を挿入される
パターンになります。
利用ツール：MODEL-builder version2
赤丸枠で示されているのが、「製品エンティティ」になります。
この場合のビジネスのポイントは、下記になります。
- 業界全体で、製品情報が決められているビジネス
- メーカー毎に、製品IDや製品名を決める事は無い
- 国営企業、自治体、団体企業等が当てはまる場合が有ります
メーカー・製品エンティティの対照表に製品情報を挿入
次の解析で、「メーカーエンティティ」と「製品エンティティ」の「メーカー・製品 対照表」
のアトリビュートに、「製品情報」を挿入されるパターンになります。
利用ツール：MODEL-builder version2
赤丸枠で示されているのが、「メーカー・製品 対照表」になります。
この場合のビジネスのポイントは、下記になります。
- ワンマン社長が統率している企業や、歴史が長い企業が当てはまる場合が有ります
- 「メーカー」と「製品」について管理する事を、第一目的としています
- 後から設置された「マーケティング部」や「情報システム部」「協力会社」等の助言により、後付けで「カテゴリー」を設置したビジネスになります
- メーカー毎に、製品IDや製品名を決める事が出来ます
- 「製品エンティティ」は、発番管理用として利用されます（実装されないケースも有ります）
メーカー・製品・カテゴリエンティティの対照表に製品情報を挿入
3つ目の解析としては、「メーカー・製品 対照表」と「カテゴリーエンティティ」の
「メーカー・製品・カテゴリー 対照表」のアトリビュートに、「製品情報」を挿入するパターン
になります。
利用ツール：MODEL-builder version2
赤丸枠で示されているのが、「メーカー・製品・カテゴリー 対照表」になります。
この場合のビジネスのポイントは、下記になります。
- 「メーカー」と「製品」に加えて、ビジネス当初から「カテゴリー」を意識している企業に多くみられます
- メーカー毎に、製品IDや製品名を決める事が出来ます
- 「対面販売」だけではなく、WEBサイトを利用した「注文システム」を「カテゴリー」別に「製品」を選択させたり、「市場調査」「マーケティング」でデータやシステムを活用する多くのビジネスが当てはまります
- 「製品エンティティ」は、発番管理用として利用されます（実装されないケースも有ります）
解析を終えた上で比較してみたいと思いますが、問題提起したサンプルER図は、3つ目に解析した
「メーカー・製品・カテゴリー 対照表」のアトリビュートに、「製品情報」を挿入するパターン
に類似しています。
実は、【T字形ER手法】で導いた「メーカー・製品・カテゴリー 対照表」が、サンプルER図で
お絵描きした「製品エンティティ」を指している事が分かります。
今では、ChatGPTやGemini、Perplexity AI 等のAIツールでも、サンプルER図のような
ER図を生成する事は可能です。
しかし、お客様の業務やデータ、コード体系の分析を反映させたER図を生成させるには、
相当な学習データを与える必要が有ります。
お客様へ価値有るシステムを提供するには、ツールに頼るだけで良いかどうか、再度、
検討してみる機会かもしれません。
まとめ
今回、サンプルER図に対して、【T字形ER手法】を用いて、逆解析を試みました。
現場で「ER図」を作成された経験の有る「エンジニア」や「DA（データアナリスト）」、
「DBA（データベースアナリスト）」の方々に、今一度、問い合わせをしてみたいと思います。
お客様に確認していませんが、サンプルER図（4つのテーブルとリレーションシップ）だけでも、
3つのビジネスの可能性が有りました。
本当に、コード体系やデータベースについて、分析が出来ているのか、またはお客様に確認が
漏れている可能性も有りますので、訴求してみるのも手かと思います。
また、既存のシステムへの変更は、手間とコストが必要となり、安定運用されているところに、
敢えて手を加えるのは、リスクも伴いますので、他の仕様変更や業界対応等で修正が必要な時に、
確認してみる手段でも良いと思います。
既存システムとは別に、新規のシステム構築やアプリケーション開発を手掛けるので有れば、
【正規化】や【T字形ER手法】を学び、試みるのも良いと思います。
また、シニアエンジニアや若手エンジニアで、これからデータベースを覚える方々は、
是非、【正規化】や【T字形ER手法】を学ぶ事をお勧めします。
- イラスト：いらすとや より引用
コメント