システム開発<基本編>サンプルER図の解析

DB

前回の記事を、簡単に振り返ってみます。

サンプル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図で

お絵描きした「製品エンティティ」を指している事が分かります。

今では、ChatGPTGeminiPerplexity AI 等のAIツールでも、サンプルER図のような

ER図を生成する事は可能です。

しかし、お客様の業務やデータ、コード体系の分析を反映させたER図を生成させるには、

相当な学習データを与える必要が有ります。

お客様へ価値有るシステムを提供するには、ツールに頼るだけで良いかどうか、再度、

検討してみる機会かもしれません。

 

まとめ

今回、サンプルER図に対して、【T字形ER手法】を用いて、逆解析を試みました。

現場で「ER図」を作成された経験の有る「エンジニア」や「DA(データアナリスト)」、

「DBA(データベースアナリスト)」の方々に、今一度、問い合わせをしてみたいと思います。

お客様に確認していませんが、サンプルER図(4つのテーブルとリレーションシップ)だけでも、

3つのビジネスの可能性が有りました。

本当に、コード体系やデータベースについて、分析が出来ているのか、またはお客様に確認が

漏れている可能性も有りますので、訴求してみるのも手かと思います。

また、既存のシステムへの変更は、手間とコストが必要となり、安定運用されているところに、

敢えて手を加えるのは、リスクも伴いますので、他の仕様変更や業界対応等で修正が必要な時に、

確認してみる手段でも良いと思います。

既存システムとは別に、新規のシステム構築やアプリケーション開発を手掛けるので有れば、

【正規化】【T字形ER手法】を学び、試みるのも良いと思います。

また、シニアエンジニアや若手エンジニアで、これからデータベースを覚える方々は、

是非、【正規化】【T字形ER手法】を学ぶ事をお勧めします。

 

 

コメント

タイトルとURLをコピーしました