DRIブログ

3分でわかるデータモデリング

2020/04/28 12:00:00 / by 佐藤 健司

はじめに

今回の「3分間で分かるデータマネジメント」ブログのテーマは「データモデリング」です。

データモデリングはシステム構築やパッケージ導入だけでなく、データマネジメントには欠かせないものであり、今後は当たり前のように必要とされるスキルになってくるはずです。

想定読者層

  • 情報システム構築やパッケージ導入に携わる方(特に、事業会社側情報システム部門の方)
  • デジタルトランスフォーメーションに携わる上で、データから価値を見出したいと考えている方

 

データモデリングとは?

DMBOK2では「データ要件を洗い出し、分析し、取扱スコープを決めるプロセス」と定義しています。更に「データ要件を記述し伝えるためにはデータモデルという様式が用いられ、反復的であり、概念/論理/物理モデルが含まれる。」と記載されています。以上の定義を、もう少し噛み砕いて説明したいと思います。

データモデリングはシステム開発や保守作業の中で最も頻繁に行われますが、業務設計やマスタデータ管理、データガバナンスなどにおいて、組織のデータを理解することを目的に行なわれることも増えています。(この場合には、必ずしもデータベース構築を伴うとは限りません。)

(一般的に)モデルは標準的な記号を使用します。(例:地図/組織図/建物の青写真など)
データモデルには文字ラベル付きのシンボル群が含まれ、データモデラーが把握したデータ要件や定義が表現されます。データモデルはシステム開発・保守や業務設計、マスタデータ管理、データガバナンスに携わる関係者の間で、データ要件を伝える手段として用いられます。

データモデルは、以下のような要素から構成されています。

構成要素

説明

エンティティ

組織の情報収集対象であり、明確なネーミング・意味定義によりビジネス上の価値を持つ。特定のエンティティの値をエンティティインスタンスと呼ぶ。

リレーションシップ

エンティティ間の関連性を表し、一方のエンティティ数ともう一方のエンティティの数(カーディナリティ)と合わせて表現されることが多い。

属性

エンティティの特性や特質を表し、その中でエンティティインスタンスを一意に識別する1つ以上の属性のセットを識別子(またはキー)と呼ぶ。

ドメイン

各属性が取り得る全ての値一式のことであり、様々な方法で定義できる。

表1.データモデル構成要素

 

ドメインは、次のような様々な方法で定義できます。

方法

説明や例

データタイプ型

あてはまる標準的なデータタイプを指定
例)整数型、文字型(30桁)、日付型

データ形式型

郵便番号や電話番号など、パターン(例:郵便番号はxxx-xxxx)を含む

リスト型

有限個の値(及びそれに対応する意味)を持つ

範囲型

同じデータタイプで、最小値と最大値の組合せを1つまたは複数持ち、その間の全ての値を許すドメイン

ルールベース型

ルールに従った値のみを有効とするドメイン

例)売値は仕入値より高くなければならない

表2.ドメイン定義方法

 

データベースを構築する上で三層スキーマアプローチという考え方があり、1975年にANSI/X3/SPARC(米国規格協会の標準計画および要件委員会)から発表されました。

名称

説明

外部スキーマ

利用者視点から定義される。ユーザが利用する画面やレポート上に表れる構造。

RDBではViewに相当する)

概念スキーマ

企業がどう「現実世界」の全体を見ているかという視点で、モデル化される。

内部スキーマ

コンピュータシステムに格納される構造であり、使用される特定技術とデータの効率的な処理の必要性に依存する。

表3.ANSI/X3/SPARC三層スキーマ

 

 

図:ANSI/X3/SPARC三層スキーマ

 

上記の考え方は、概念/論理/物理というデータモデルの詳細レベルに変換されることが多くあります。(概念スキーマと概念モデルを混同することが多いので、注意が必要です。)

詳細レベル

説明

概念モデル

関連する概念の集合体として、データ要件の概要が取り込まれる

(特定の領域や業務機能に関する基本的で重要なビジネスエンティティを含む)

論理モデル

詳細なデータ要件を含み、アプリケーション要件のような特定使用シナリオに適応

物理モデル

詳細な技術的ソリューションを表し、H/W,S/W,N/Wに依存

表4.データモデルの詳細レベル

 

なぜデータモデリングが必要なのか?

DMBOK2ではデータモデルには次のような意義があるとしています。

  • データに関する共通語彙を提供する
  • 組織のデータや情報システムに関しての明示的な知識を捉え文書化する
  • プロジェクトにおいて主なコミュニケーションツールとして使われる
  • アプリケーションをカスタマイズ、統合、リプレースする際の出発点となる

適切なデータモデリングは、アプリケーションが現在あるいは将来の業務要件と整合性を持つようになる、あるいはマスタデータ管理やデータガバナンス・プログラムのような広範囲の取り組みを成功裏に完遂するための基礎がつくられることに繋がります。そのように作られたデータモデルは運用コスト削減や、将来の取り組みへの再利用可能性向上による新たなアプリケーション構築コストの削減に寄与します。

 

データモデリングの進め方

DMBOK2では、計画→構築→レビュー→維持・更新管理 の4つのアクティビティが定義されています。
構築には、フォワードエンジニアリングとリバースエンジニアリングの2通りがあり、リバースエンジニアリングは既存システムのデータ構造を把握して次のアクションを検討するために、フォワードエンジニアリングは新規システムの要件を検討するためによく用いられます。構築の結果、次の成果物を生成致します。

成果物名

定義

ダイヤグラム

データ要件を正確に捉え可視化したもので、詳細レベルや表記法を定める。

定義

エンティティや属性の意味定義は、データモデル精度維持に不可欠である。

問題と未解決疑問

モデリング過程で発生した問題や疑問を、しかるべき責任者やグループに引き渡すために表形式で整理する。

リネージ

データが発生し、時間の経過とともに移動する場所を定義する。

表5.データモデリング成果物

 

データモデリング中にデータリネージを把握することは、次の理由により重要です。

  • データモデラーはデータ要件を深く理解するので、データの発生源決定に最適な立場にいる
  • 発生源を決定することが、データモデルの正確性を検証する上で有効な手段となり得る
1.計画

組織要件の評価や、表5データモデリング成果物の維持・更新方法の決定を行います。

2.構築
 ①フォワードエンジニアリング
 a. 概念データモデリング:取り組むべきスコープとその中で扱う重要な用語を特定します

手順

内容

スキーム/表記法選択

スキーム(リレーショナル,ディメンション,NoSQL)や表記法(TH, IE, IDEF1X)を選択する

初版完成

組織に存在するハイレベルな概念(名詞)やこれらの概念を結ぶ業務

プロセス(動詞)を収集し、関係を整理する

全社共通用語取込

全社で利用する用語や業務ルール間の一貫性を確保する

承認

ベストプラクティスであるか、要件を満たしているかという観点で、モデルが

レビューされたことを確認する

表6.概念データモデリング手順

 

 b. 論理データモデリング:概念モデルのスコープ内で、詳細なデータ要件を文書化します

手順

内容

情報要件分析

・業務プロセス調査による業務情報ニーズを特定する

・業務要件の定義(体系化/文書化)、レビュー、改善、承認、変更管理

既存文書分析

・構築済データモデルが(質の高い状態で)あれば活用する

関連エンティティ追加

・概念データモデルに多対多の関係があれば、関連エンティティを追加し、それを解消する

属性追加

・データ要件詳細化に伴い追加する

ドメイン(定義域)割当

・論理データモデル内の属性に、既述の方法でドメインを割り当てる

キーの割当

・キー(主キー、代替キー)、非キー属性を特定する

表7.論理データモデリング手順

 

 c. 物理データモデリング:特定のアプリケーションでうまく動作するように修正を施します

手順

内容

抽象化の解決

サブタイプの形で抽象化したエンティティを、次の形で見直す

・親エンティティにnull許容属性として取り込む

・親エンティティ属性をサブタイプに取り込む

属性詳細の追加

・物理データタイプや制約(null許容、既定値など)を追加する

参照データオブジェクトの追加

・参照データの扱いを具体化する(コード共有マスタ等)

サロゲートキーの割当

・キーが、複合キーや時間経過とともに変化する可能性のある場合に、

サロゲートキー(業務上非表示で、他との関連無)の採用を検討する

非正規化

・重複ストレージ管理や同期処理のためのコストを上回る効果を得られる場合に、非正規化を検討する

インデックス追加

・頻繁に参照される列(特にキー)を使用して、最も頻繁に実行される

クエリを効率化するインデックスを追加する

パーテーション分割

・特にDWH構築時のファクトテーブルに多数のディメンショナルキーが含まれている場合に、検討する(例:日付キーによる分割)

ビューの作成

以下事項の必要性を吟味して、作成を検討する

・特定データエレメントへのアクセス制御 ・共通の結合条件・フィルタ

表8.物理データモデリング手順

 ②リバースエンジニアリング

フォワードエンジニアリングとは逆の流れで、既存システムのTABLE構造を起点に作成します。

  • 既存システムの理解のために物理データモデルを作成する
  • 既存システムが満たす業務ソリューションを理解するために論理データモデルを作成する
  • 既存システムのスコープと主要な用語を理解するために概念データモデルを作成する

殆どのデータモデリングツールはリバースエンジニアリングをサポートしていますが、要素の読み取り易いモデルのためには、依然としてデータモデラーの存在が必要です。

3.レビュー

他のIT分野と同様にモデルには品質管理が必要ですので、レビューにおいて正確性、完全性、一貫
性などを評価します。

4.維持・更新管理

データモデル構築後、要件や業務プロセスが変更される場合にデータモデルを更新します。
各開発サイクルの終わりに、最新の物理データモデルをリバースエンジニアリングし、論理データモデルと比較するのが望ましいと思われます。

 

おわりに

我々は普段当たり前のように扱ってしまうデータモデル/データモデリングについて、改めて整理してみました。情報系(ディメンショナル)や、NoSQLなどの新たなスキームに対しては、別の機会に触れてみます。

企業のデジタル化を進める上では情報の利活用により新たなビジネスチャンスを得る必要があり、そのためには利活用したい情報・データをしっかりマネジメントし続けることが不可欠です。今後もブログを通して、企業のデジタル化を進めるためのデータマネジメントをわかりやすく伝えていきたいと考えています。

新規CTA

 

Topics: MDM(マスターデータ管理), データモデリング, データアーキテクチャ, 人材育成, データマネジメント

佐藤 健司

Written by 佐藤 健司