知らなきゃ損！ データマネジメントの超基本 データモデリング講座
みなさん、こんにちは！
今回は、データマネジメントの超基本であるデータモデリングについてご紹介します。
できるだけわかりやすい内容にしているつもりなので、これまでITにあまり携わってこなかった人にもご一読いただきたいです。
また、最後に練習問題を用意しているので、是非挑戦してみてください！
データモデリングとは？
データマネジメントの教科書的存在である、DMBOK2によると、データモデリングとは、
データ要件を洗い出し、分析し、取り扱いスコープを決めるプロセスである。
とあります。
これは、”こんなシステムを作りたい！”となった際、その要望を設計図のような形でまとめたり、既に作成しているシステムの設計図を見ながら、システムの改修等をする際は、ここからここまでの範囲で行おうといったあたりづけを行うことが、データモデリングと言えます。
また、データモデリングを行う際は、データモデルという明確にルールが定義された様式を用いて設計図を作成します。
少しわかりにくいなと感じる方は、家を建築することをイメージしていただくと良いかもしれません。
家を建てるときは、設計図を見ながら、こんな間取りにしたいといった、要望を洗い出すと思います。これをシステム構築で実施するのがデータモデリングです。
さらに、建築でも設計図の描き方には明確なルールが存在します。同じように、システムを作る時も、明確なルールに沿って設計図を描きます。この設計図とそのルールがデータモデルと捉えていただくともう少しイメージがつきやすくなるかもしれません。
データモデルの補足情報
※ここは少し細かい情報になるので、この段落はスキップいただいて構いません。
スキーム
データモデルには、様々なスキームと呼ばれるものがあります（リレーショナル、ディメンショナル、オブジェクト指向、ファクトベース、タイムベース、NoSQL）。これは、データベース（≒システム）の仕様と捉えていただいて構わないと想定しています。
詳しい説明はここでは避けますが、このブログでは、最も一般的なスキームであるリレーショナルを想定してご説明しています。
レベル
また、データモデルには概念・論理・物理と呼ばれる3つのレベルがあります。
詳しい説明はこちらも避けますが、イメージとしては、概念レベルは設計図とまではいかないざっくりとした青写真レベルのイメージです。このレベルは、業務的にこうしたいといった要望を絵にしていくとか、このシステムの構造は大体こんな感じだと多くの人と認識合わせをする際に利用されます。
一方、物理レベルは、実際にシステムを構築する際の仕様も含めてかなり詳細な設計図レベルになります。
その中間である論理レベルは、システムの仕様には依らないある程度詳細な設計図レベルになります。システムではなく、業務の意見を詳細に反映したレベルと捉えていただくと良いかもしれません。
まとめると、各レベルの詳細度は以下のようになります。
なお、このブログでは主に概念と論理までのレベルで説明しています。
表現技法
データモデルの表現方法も、いくつかの流派に分かれています。その流派ごとに、表現する際のルールが異なります。それぞれの表現技法に関する言及はしませんが、以下のような様式があるというのは認識おきいただけると良いかなと考えています。
IDEF1X、IE、TH・・・などなど
なお、このブログでは、IDEF1Xの技法をベースに解説します。
データモデリングの意義
DMBOK2によると、データモデリングの意義は以下の通りです。
・データに関する共通語彙を提供する
・組織のデータや情報に関して明示的な知識を捉え文書化する
・プロジェクトにおいて主なコミュニケーションツールとして使われる
・アプリケーションをカスタマイズ、統合、リプレースする際の出発点となる
色々書かれていますが、データモデルを作成することで、絵と言葉を用い表現しながらコミュニケーションをとることができる。また、そうしてできたものをきちんと文書化することに非常に意義があるということです。
なぜかというと、企業が管理するデータや情報について、事業部や組織ごとに異音同義語や、同音異義語が存在します。
例えば、A事業部・B事業部で品目と呼んでいるデータがあるが、A事業部では、原材料を加工した中間品を指している。一方で、B事業部では顧客へ販売する完成品を指す。など
こうした違いを無視したまま、口頭でのコミュニケーションだけでシステムを設計しようとすると、利用者が想像していたデータや情報を管理できていないシステムになるといったことも発生しかねません。それを防ぐために、絵と言葉によってデータモデルを作成しながら、関係者間の認識をすり合わせるというプロセスを経ることが非常に重要です。
また、こうして作成したデータモデルをきちんと文書化しておくことで、次にシステムを改修する際や、既存のシステムをもとにデータ分析のための基盤を作るときなどに、どこから手をつけるべきかといったとっかかりとしても利用できます。
データモデルの文法（基礎編）
続いて、データモデルを作成するために必要なルールについて基本的な部分に絞り、ご紹介します。
エンティティ
エンティティとは、組織が情報を収集する対象のことを指します。わかりにくいと思いますので、もう少し噛み砕くと、従業員や取引先、仕訳、商談など、情報を登録・収集する対象の名詞と捉えていただくと良いかもしれません。
システムエンジニアをされている方であれば、エンティティ≒テーブルと考えると良いでしょう。
リレーションシップ
リレーションとは、エンティティとエンティティの関係性を示します。
例えば、大学の学部と、学生という2つのエンティティがあったとします。
学生はどこかの学部に所属するという関係性があった場合、学部と学生の間に線を引き、両者の関係性を示します。
カーディナリティ（多重度）
カーディナリティとは、リレーションを結ぶエンティティ同士の数の関係性を表します。
カーディナリティは、0、1、多（Nと呼ばれることもある）の３つの組み合わせで、構成されています。以下ではその組み合わせの例をいくつか紹介しています。
※あくまでイメージです。
属性
属性とは、エンティティが管理する項目のことを指します。
Key（キー）
Key（キー）とは、属性のうち、レコードを一意に識別する識別子のことを指します。
これだと何を言っているかわからないかもしれません。
例えば、学生証の学生番号や、社員番号など、エンティティ内で管理するデータの中で、絶対に値の重複がない属性をKeyと言います。
外部Key
Keyの中で、もう一つ覚えておくべきことがこの外部Keyです。
これは、エンティティ間のリレーションを表しています。少し例を持ってご説明しましょう。
以下は、学生・履修登録・授業の3つのエンティティとそのリレーションを表しています。大学で履修登録をする際をイメージしてください。
このように、リレーション先のエンティティにリレーション元のエンティティのKeyを持つことで、Keyに紐づくリレーション元で管理されるレコードの属性を呼び出すイメージです。
最後に：データモデルの練習問題
ここまで、かなり噛み砕いて、データモデルの基本的な文法をお伝えしてきました。最後にもう少しデータモデルのイメージを掴んでもらうため、練習問題をご用意いたしました。
今回は、名刺を題材にしております。以下の画像をご覧いただきながら、これまでご説明した内容も踏まえ、トライしてもらえると嬉しいです！！
答えは次回のブログでご紹介しますので、次回もぜひご覧ください！
