データ・モデル

論理データ・モデル とは、包括的なビジネス情報要件を正確で一貫性のある形式で文書化するプロセスです

組織のニーズを満たすデータベースを正しく設計して、インプリメントするには、論理データ・モデルが必要です。 データをモデリングするアナリストは、データ項目とそのデータ項目に影響するビジネス・ルールを定義します。 データ・モデリング確認のプロセスで、ビジネス・データは、組織が理解して慎重に管理する必要がある不可欠の資産であることを認識します。

製造会社がデータ・モデルに表現する必要のある、以下のビジネス・ファクトを取り上げます。

  • 顧客購入製品
  • 製品のパーツ構成
  • サプライヤー製造パーツ
  • ウェアハウス保管パーツ
  • サプライヤーから倉庫、さらに製造会社へ運輸車両がパーツを移動

これらはすべて、製造会社の論理データ・モデルに組み込む必要のあるビジネス・ファクトです。 会社の内外の多くの人々は、これらのファクトに基づく情報に依存します。 多くのレポートに、このファクトに関するデータが記載されます。

製造会社だけでなく、どの会社もデータ・モデリングのタスクの効果が得られます。 意思決定者、顧客、サプライヤーなどに情報を提供するデータベース・システムは、適切なデータ・モデルを基盤としている場合には、さらに有効です。

データ・モデリング過程の概要

お客様は、どのようにしてデータ・モデルを構築するか、迷うことがあるでしょう。 データ・アナリストは、さまざまな方法でデータ・モデリングのタスクを実行できます。 (このデータ・モデリング過程の前提として、データ・アナリストがこのステップを行いますが、一部の会社ではこの作業に組織の中の別の要員を割り当てます。) データ・アナリストの多くは、以下の手順に従います。

  1. 重要なユーザー・ビューをビルドする。

    アナリストが論理データ・モデルの構築を開始するには、単一のビジネス・アクティビティーまたは機能を慎重に調査します。 アナリストは、ユーザー・ビュー を作成します。このビューは、ビジネス・アクティビティーで必要とする重要な情報のモデルまたは表現です。 (後の段階で、アナリストは個々のユーザー・ビューを他のすべてのユーザー・ビューと結合して、統合論理データ・モデルにします。) データ・モデル・プロセスのこの初期の段階は、ほとんど対話式です。 データ・アナリストは、モデリングするビジネスのすべての領域を完全に理解することはできないので、実際のユーザーと密接に協力して作業します。 アナリストとユーザーは共同して、主要エンティティー (関係する重要なオブジェクト) を定義し、このエンティティー間の一般的な関係を判別します。

  2. ユーザー・ビューにキーとなるビジネス・ルールを追加する。

    次に、アナリストは詳細な情報項目と最も重要なビジネス・ルールを追加します。 キー・ビジネス・ルールは、データの挿入、更新、および削除操作に影響します。

    例えば、ビジネス・ルールでは、顧客エンティティーにはそれぞれ、少なくとも 1 つのユニーク ID が必要である場合があります。 別の顧客 ID と一致する顧客 ID を挿入または更新することは無効です。 データ・モデルでは、ユニーク ID は主キーと呼ばれます。
  3. ユーザー・ビューに詳細情報を追加して、そのビューを検証する。

    アナリストがユーザーと一緒に作業してキー・エンティティーと関係を定義後、それよりは重要でない他の記述詳細情報を追加します。 この記述詳細情報 (属性 と呼ばれる) をエンティティーに関連付けます。

    例えば、顧客エンティティーには関連電話番号がある可能性があります。 電話番号は、顧客エンティティーの非キー属性です。

    アナリストは、開発済みのすべてのユーザー・ビューの妥当性検証も行います。 ビューを検証するために、アナリストは正規化プロセスとプロセス・モデルを使用します。 プロセス・モデル を使って、ビジネスでデータを使用する方法を詳細に文書化します。 これらのテーマに関しては、他の資料にあるプロセス・モデルとデータ・モデルの詳細を読んでください。

  4. 属性に影響する追加ビジネス・ルールを判別する。

    次に、アナリストはデータ・ドリブンのビジネス・ルールを明確にします。 データ・ドリブン・ビジネス・ルール は、特定のデータ値に対する制約です。 この制約は、具体的な処理要件に関係なく、満足しなければなりません。 アナリストはデータ設計段階 (アプリケーション設計段階ではなく) でこれらの制約を定義します。 データ・ドリブン・ビジネス・ルールを定義する利点は、多くのアプリケーション・プログラマーがこのビジネス・ルールを実施するためのコードを作成する必要がないことです。

    例えば、あるビジネス・ルールで、顧客エンティティーに電話番号または住所、あるいはその両方のいずれかがあることが要求されるとします。 このルールがデータ自体に適用されない場合、プログラマーは、このいずれかの属性が存在することを検証するアプリケーションを、開発、テスト、および保守する必要があります。

    データ・ドリブン・ビジネス要件はデータと直接関係しているので、プログラマーは余計な作業から解放されます。

  5. ユーザー・ビューを統合する。

    データ・モデルのこの最終段階では、アナリストは作成済みの各ユーザー・ビューを、統合化された論理データ・モデルに結合します。 他のデータ・モデルがその組織に既に存在している場合、アナリストは既存のデータ・モデルを新規のデータ・モデルに統合化します。 この段階で、アナリストはまた、データ・モデルを柔軟にして、現行ビジネス環境と、考えられる将来の変更に対応できるようにできます。

    例えば、小売会社は 1 つの国で営業していて、ビジネス・プランに他の国への展開が含まれていると想定します。 このプランを認識すると、アナリストは、他の国への展開に対応するのに十分な柔軟性のあるモデルを構築できます。

論理データ・モデルの推奨事項

アナリストは、適切なデータ・モデルを構築するために、適切に計画された方法論に従ってください。この方法論は以下のとおりです。

  • できる限りユーザーと対話しながら作業する。
  • ダイアグラムを使用して、できるだけ多くの論理データ・モデルを表現する。
  • データ・ディクショナリー を作成して、論理データ・モデル・ダイアグラムを補完する。 (データ・ディクショナリーとは、組織のアプリケーション・プログラム、データベース、論理データ・モデル、ユーザー、および許可に関する情報のリポジトリーです。 データ・ディクショナリーには、手動と自動があります。)

データ・モデル: 一部の実際的な例

データ・モデル作業を行うには、エンティティー、つまり関係する重要なオブジェクトの定義から開始します。 エンティティーとは、情報を保管する対象のものです。 例えば、組織で働いているすべての人に関する情報を保管する必要があるので、従業員に対して、 EMPLOYEE と呼ばれるエンティティーを定義することがあります。 また、部門に対して、DEPARTMENT と呼ばれるエンティティーを定義することもあります。

次に、エンティティーに主キーを定義します。 主キーとは、エンティティーのユニーク ID です。 EMPLOYEE エンティティーの場合、多くの情報を保管する必要があることも考えられます。 しかし、この情報のほとんど (性別、誕生日、住所、入社日など) は、主キーに選択するには適切ではありません。 この場合は、固有の従業員 ID、つまり番号 (EMPLOYEE_NUMBER) を主キーとして選択します。 DEPARTMENT エンティティーの場合は、固有の部門番号 (DEPARTMENT_NUMBER) を主キーとして使用します。

エンティティーとその主キーを決定後、エンティティー間に存在する関係を定義できます。 関係は、主キーに基づきます。 EMPLOYEE に 1 つのエンティティーと DEPARTMENT に別のエンティティーがある場合、従業員は部門に割り当てられているという関係が存在します。

エンティティー、その主キー、およびその関係を定義後、エンティティーの追加属性を定義できます。 EMPLOYEE エンティティーの場合は、以下の追加属性を定義することがあります。

  • 生年月日
  • 入社日
  • ホーム・アドレス (Home address)
  • オフィスの電話番号
  • 性別
  • 再開

属性の定義方法の詳細は、この説明の中で後述されています。

最後に、データを正規化します。