データベース構築とData Oriented Architecture

データベースの設計に焦点を当てます。

データベース構築

データベースを実際に作成してデータを投入する前に、データモデルを作成します。

データモデルの作成には、「ERモデル」を利用することが多いかもしれません。
ERモデルでは、「Entity（実体）」、「Attribute（属性）」、「Relation（関連）」の3点を用いてデータモデルを概念化します。
Entityは顧客や商品、Attributeは顧客名や住所、電話番号など、Relationは従業員が〇〇会社に属するなど、Entity同士の関係を表します。

このデータモデルを作成するステップは次の通りです。

• 必要なデータを集めて整理する

  • 正規化
    データの関係を整理し、繰り返し発生するデータ項目があれば、さらに細かいEntityに分割します。
  • 最適化
    データの重複を排除し、抜け漏れをチェックします。
  • 一般化
    整理されたモデルを、必要に応じて「ビジネスに適した状態」に組み替えます。例えば顧客データを法人、個人で分けるなど。

• データベースに実装できるよう調整する（パフォーマンスの考慮）

  • データの流れの調整
  • インデックスの作成

Data Oriented Architecture

通称DOAは、データを中心に考えた設計を指します。
ビジネス規模の成長や手法の変化が起きても、比較的柔軟に対応できるだけでなく、
データ利用にとって、どのような形で保管することが好ましいかを考えられるようになります。 昨今、ビジネスにおける戦略的なデータ利用が重要視されています。DOAはこうした流れに沿うものです。

DOAに対して、「POA（Process Oriented Approach）」が存在します。
処理を中心に考える設計で、現在の処理要件にマッチするよう設計します。
現在の要件はクリアされますが、将来的な変化やデータ利用には適さない設計になってしまう可能性が高いでしょう。

DOAを先述のデータモデルの作成に当てはめて考えてみます。
まずDOAではなくPOAに従うと、「部分最適」に突き進むことになるでしょう。
現在の、特定のユーザーの処理要求にマッチする設計を志向するからです。

サプライチェーンを例にとってみると、商品コードについて、販売部門では商品につき1つのコードで管理していても、 製造部門では、製造工程の違いによってコードを分けている可能性があります。
また、顧客リレーションにしても、顧客相手の情報を会社と部署を区別していない場合や、会社と部署を分けて管理している場合もあります。
「部分最適」では各利用部門の要求に従って、このような違いをそのままデータモデルに反映してしまいます。これらの差異を吸収するには、インターフェースを通してデータを整形しなければなりません。

また、部分最適による弊害だけではなく、データを活かす視点に立つことも重要です。
経営戦略を後押しするようなデータを取得できるようにする、マーケティングに役立つ粒度でデータを蓄積する、などです。

無駄をなくし、データを活かすためにも、データをどのように、何のために管理したいのか、DOAの視点に立ってデータモデルを設計する必要があります。

“言われた通り”ではもうダメな理由──「データを中心に考える」とは、どういうことか (1/3)：ゼロからのリレーショナルデータベース入門（4） - ＠IT