Skip to main content

エンティティの洗い出し

データベースの設計は、お客様の業務をしっかり分析し、記録、管理したい情報を明確にしていくことから始まる。

エンティティ​

エンティティとは？​

実態を持ったデータの集合体のこと。
箱みたいな入れ物と思ってくれるといい。
RDB的視点では、「テーブル」のこと。

エンティティには、同じような意味を持つデータ(属性)を入れる。

  • 例）社員というエンティティ(テーブル)を持つなら・・・
    • 社員番号
    • 社員名
    • 入社年月日
    • 住所
    • 電話番号
    • etc...

以上のように、エンティティ名(上の例でいえば社員)に関係するデータを入れる。

属性​

属性とは？​

エンティティに入れるデータのことを「属性」と呼ぶ。
RDB的視点では、「カラム」のこと。

エンティティに入れるデータ(属性)を見つける。​

データを見つけるためには、エンティティに記録・保存したい情報があること。
逆に保存したくないものは入れない。

エンティティに入れるデータの候補を見つけ出すためには、まずエンティティ名を決める。名前を決めることで、どんなデータがエンティティに入るか明確になる。エンティティ名を決めるためには、以下による情報整理を行う。

  • 「モノ(主語、名詞)」に関すること(リソース(資源)系エンティティ)
    • 誰が(Who)
      • 社員、組織
    • 誰に(Whom)
      • お客様、利用者
    • 何を(What)
      • 商品
    • どこ(Where)
      • 地域
  • 「出来事(動詞)」に関すること(イベント系エンティティ)
    • どのように(How)
      • 仕入、出荷

上記の例をつなげると、
「社員が・お客様に・商品を・地域へ・出荷する」
という感じで意味が通るようになる。

この時点で意味が通らない場合は、
まだ全体が把握できず見落としている部分があるはずなので、
見直しが必要となる。

エンティティ名を見つけた後は、
それぞれのエンティティに入れるためのデータを決めなければならない。
データを決めるためには以下による情報整理を行う。

  • データの候補
    • いつ(When)
    • どれくらい(How many)
    • いくら(How much)
    • なぜ(Why)

すべてのデータを洗い出すには時間がかかるため、
積極的にお客様と打ち合わせを行って、
データがどのエンティティに入るかを明確にしていかなければならない。

もし、入れるデータの分類に困るものがあれば、
一番似合いそうな、それっぽいエンティティに入れておき、
あとから適切な場所に入れ直すというのもありだ。

DB設計の手順​

記録、保存したい情報を効率よく洗い出すためのポイント。

ブロック分け​

ブロック分けとは、
チーム内で統一した切り口にそろえつつ、
ある程度のまとまりに分けること(ブロック化)すること。

ブロック分けをする理由は、
いきなり全体を見てやろうとすると混乱して
何から手を付けていいのかわからなくなるから。

例えば、部門を切り口にすると、
営業、経理、開発、保守・・・などといった形になる。

ブロック分けができたら、
今度はその部門で何をやっているかを、
「イベント系エンティティの抽出」で確認する。

イベント系エンティティの抽出​

イベント系エンティティの特徴は以下のようものが言える

  • 動詞であるもの
  • 「いつ(When)」が属性で設定できるもの

例として以下のようなものがある

  • 商品とお金が動く、「売上」や「仕入」という動きがある部分
  • 「いつ」というのは、「履歴」や「予定」などを扱う部分

こういったイベント系を抽出するためには、情報収集が不可欠となる！
「どんなことやっているんですか？」と聞いたり、
「実際に業務で使っている帳票(伝票)を見せてください。」など、
イベント系から攻めていくとやりたいことが浮き彫りになり、
DB設計の確実性が高まる。

ただ、初めは微細なところに注目せず、ざっくりと大きなエンティティを作ることを意識して欲しい。

[補足]複雑なビジネスルール​

複雑なビジネスルールの意味はそのまま、仕事のルールが複雑であるということ。

例えば、「単価」。
実は一言で「単価」といっても様々な分類に分けられる。
標準単価、得意先別単価、仕入先別単価、期間別単価などなど、
「単価」にはいくつも種類があるのだ。

このように、いくつも単価があることはお客様は分かるが、 データベースを設計する側は分からない。 こういった「単価」という言葉に隠れた見えない部分をお客様から絞り出し、 絞り出した項目を記録するような仕組みにしなければならない。

もちろん、複雑であれば複雑であるほど、
DB設計も複雑になるが、
データはDB上で表現されるべきものなので、
残さないといけないものは必ず入れるようにしなければならない。

だが、複雑になるからと思って単純にすると、
今度はプログラムのほうが複雑になって負担をかけてしまう。

システムはデータベースとプログラムの両方があって成り立つ。
難しいことではあるが、問題を先送りせず、 データベースでやれることはデータベースで行うように心がけてほしい。

まとめ​

お客様の仕事内容が複雑で、 DB設計が複雑になることがあっても、
しっかりお客様から項目の洗い出しを行って、
データとして管理しなければならないものは迷わずデータベースで管理しよう！