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

DB

システム開発<基本編>データベースの分析

前回の記事(上記)の最後に、ER図のサンプルを用いて、問題提起をしました。

今回の記事では、先ずは、その問題提起を振り返ってみましょう。

サンプルER図(問題提起)

下記のER図のサンプルを見て下さい。

これは、開発現場で多く見掛ける「販売管理システム」のER図の一部です。

全体のER図が描かれていないので、少し判断が難しいかもしれませんが、

  • 【メーカー(エンティティ:makers)】
  • 【製品(エンティティ:products)】
  • 【カテゴリー(エンティティ:categories)】

「リレーションシップ(Relationship:関連)」は、正しいでしょうか?

利用ツール:A5:SQL Mk-2

各エンティティに、「削除日」が含まれていないので正しくない…とか、

【製品(エンティティ:products)】の中に含まれている「製品希望売値」が、

自社の業務には含まれていないので正しくない…とか、

細かな部分について、指摘する問題提起では無いです。

【前提】として、各エンティティ内の「コード」「アトリビュート(属性)」

正しいものとして下さい。

では、ER図のサンプルは、正しいでしょうか?

 

回答

では、ER図のサンプルについて、回答します。

ずばりお答えします

正しいか?と問われるなら、

  • 結論から言いますと、分からない
  • 該当する業務やシステムのデータ、コード体系を分析していないので
  • 結果的に正しいかもしれないし、正しく無いかもしれない

これが率直な回答です。

えっ…と思われるかもしれませんが、それが事実です。

正しいかもしれないし、正しく無いかもしれないのです。

サンプルER図をパッと見て、製品ベンダーが販売している「パッケージソフト」なら、

正しいように思えます。

業務やシステムのデータ、コード体系を分析せずカスタマイズもしないで、

業務自体を「パッケージソフト」に合わせて下さい…と言うことで有れば、

正しいように思えます。

 

また、プログラマーの立場で、サンプルER図から

  • メーカー:①一覧画面(削除機能含む) ②新規登録画面 ③情報更新画面
  • 製品:④一覧画面(削除機能含む) ⑤新規登録画面 ⑥情報更新画面
  • カテゴリー:⑦一覧画面(削除機能含む) ⑧新規登録画面 ⑨情報更新画面
  • 注文:⑩一覧画面(削除機能含む)、⑪新規登録画面 ⑫情報更新画面
  • ⑬メニュー画面

の合計:13画面を開発しようと思えば、出来るとは思います。

 

サンプルER図に、ユーザー(エンティティ:users)】を含めていないので、

ログイン画面、ユーザー登録画面、ユーザー更新・削除画面が無いですよ…

なんて指摘は、論外として下さい。

それなら、サンプルER図は、正しいですよね!!と思われるのでは無いでしょうか?

次の回答の理由を、ご覧下さい。

 

回答の理由

  • 結論から言いますと、分からない
  • 該当する業務やシステムのデータ、コード体系を分析していないので
  • 結果的に正しいかもしれないし、正しく無いかもしれない

これが率直な回答です。

その上で、開発現場で実際にER図を作成された「エンジニア」や「DA(データアナリスト)」、

「DBA(データベースアナリスト)」に問い合わせをします。

開口一番に、

  • このER図、間違っていますよ!!

なんて言ったら、憤慨されて二度と口を聞いてくれないので、注意して下さいね。

 

実際の開発現場で起きた事

実際に、「エンジニア」や「DA(データアナリスト)」、「DBA(データベースアナリスト)」

が作成されたER図で、プログラムを実装している開発現場へ参画した経験が何度も有ります。

システム化を行う業務内容扱うデータについて、キャッチアップする為、大抵、「要件定義書」

「基本設計書」「詳細設計」「システム構成図」等と一緒に、「ER図」「テーブル定義書」

拝見させて頂きました。

ドキュメント類だけでは、当然、業務内容扱うデータをキャッチアップする事は出来ないので、

接触可能な権限の中で、「お客様」「プロジェクトマネージャー」からもヒアリングをしました。

同様に、「ER図」を作成された「エンジニア」や「DA(データアナリスト)」、「DBA(データ

ベースアナリスト)」にもヒアリングをしていて、上記の開口一番のような聞き方はせずに、

  • このER図は、どのよう導かれたのですか?

と、丁寧な問い合わせをさせて頂いたものでした。(事実)

ところがですよ… 何だろうなぁ…

丁寧な問い合わせをさせて頂いたにも拘わらず、多くの現場で返って来る言葉は、

  • 何故、そんな事聞くの?
  • 何年も、この仕事に携わっているから、このER図は間違い無いよ!!
  • データベーススペシャリスト(情報処理技術者)、オラクルマスター(Oracle Master)のゴールドを保有している私が作成したER図なのだから、間違い無い!!
  • 先輩から引き継いで、何十年とメンテナンスをしているER図だから、間違い無いですよ
  • 新参者が!! 協力会社でしょ!! 口を出すな!!
  • 当然、ER図作成ツールを使って導いたので、間違い無いでしょう…
  • 業務の現場から、直接ヒアリングをして、テーブル設計に何十時間も費やしたのだから、間違い無い!!

といった具合で、殆どが感情的な回答でした。

 

私としては、プロジェクトが進行して来て、頑張っているプロジェクトのメンバーに対して、

人格を否定するつもりは全く無くて、どのように業務内容扱うデータを分析されて、

どのように(How ?)「ER図」を作成されたか聞きたかったのですが、何故(Why ?)

この「ER図」を作成されたのか?…と聞きたかった訳では無いのです。

「ER図」を作成された「エンジニア」や「DA(データアナリスト)」、「DBA(データ

ベースアナリスト)」が、

  • 何か聞かれて、まずい事でも有るのかな?
  • ER図の描き方や使用しているツールを、無料(ただ)で教えたく無いのかな?
  • テクニックを盗まれると思っているのかな? テクニックなんて無いと思うけど…
  • エンジニアさんって、口下手(くちべた)な人が多いから、恥ずかしいのかな?
  • 実装漏れが見付かるのが、嫌なのかな?

と、その当時は、現場で推測するような日々でしたね。(笑)

まとめ

今回、サンプルER図の回答と、実際の現場で起きた事を紹介しました。

様々な開発現場に立ち会うと、「あるある」「そうそう」と共感されているエンジニアの方も

いらっしゃると思います。

次回の記事では、サンプルER図を検証して、本来あるべきER 図の導き方について

手法を交えて、紹介したいと思います。

コメント

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