前回の記事を、簡単に振り返ってみます。
サンプル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手法】を学ぶ事をお勧めします。
- イラスト:いらすとや より引用
コメント