はじめに
ユーザーデータを利用するアプリケーションの実装や、収集したデータの分析など様々な場面でデータベースが活用されています。
この記事ではそういったデータベースの実装に欠かせないデータモデリングについて解説します。
データモデリングとは
データモデリングとは一言で言うなら“データベース同士の関係を図に落とし込むこと”です。
たとえば社内の重要文書をどのように管理するか議論をする際、社内の重要文書がいまどこにあるのか、誰が管理しているのかなどを適当な白紙に書き出して図示することがあると思います。
この作業も広い意味ではデータモデリングといえますが、今回解説するのは、特にDWH（データウェアハウス、詳しくはこちらをご覧ください）を利用するような大規模なデータベースをアプリケーションやデータ分析基盤の上でどのように運用すればいいか設計するという狭義のデータモデリングです。
このとき最終的なゴールは
- データベース同士がどのような関係にあるかが明確
- 各データベースがどのような情報を保持しているのかが明確
- 各データベースに求められる要件や実装すべき範囲が明確
- 効率よくデータを運用できるよう各データベースの配置が最適化されている
これらを満たした図を作成し、メタデータ（データを管理するためのデータ）として保管することです。
データモデリングの手順
はじめに
上記のゴールが達成されているのであれば、データモデリングの具体的な過程はそれほど問題ではありません。しかし、データマネジメントの世界で広く知られるDMBOK（Data Management Body of Knowledgeの略称。現在第２版まで出版されており、日本語版も存在）に定められるデータモデリングの手順が一般的かつ信頼度の高い手法であるため、本記事でもそれを手順として解説します。
ER図とは？
データモデリングでモデル図の作成に用いられるのがER図です。ER図とはシステムにおけるデータ保持する実体としての「モノ」や「コト」をE：エンティティ、エンティティ同士の関係をR：リレーションとして図にしたものになります。（ER図にはいくつか記法が存在しますが、今回はシンプルな記法を使用します。）
概念モデルの実装
DMBOKではデータモデリングを３つの段階に分け、抽象的なモデルからより具体的なモデルへと段階を踏んでいきます。第一段階となる概念モデルでは、実際のデータベースの実装はあまり考慮せず、システムの運用上重要なエンティティは何か、そしてそのエンティティ同士のリレーションはどのようであるかをざっくりと記述します。
ただしこのときシステムに必要なエンティティを極力漏らさず記述することが必要です。先の段階に進んだあとに重要なエンティティの記述漏れが発覚すると、場合によっては再度概念モデルの構築に立ち返る必要が生じるからです。
今回はごく簡単な例として営業データの分析を行う際データモデリングを行います。
まず初めに行われるアクションを文章で書き出してみましょう。
「営業部門の社員が顧客に商品の営業活動をし、その結果を営業部門のレポートに送って分析する」
このときひとまず思いつくエンティティは
- 営業部門
- 社員
- 顧客
- 商品
といったところでしょうか。
営業部門の管理下に営業データを送るデータベースのエンティティが必要です。その他、これらのエンティティ同士のリレーションを記述して整理します。
概念モデルとしてはこの程度で十分ですので次のステップに進みます。
論理モデルの実装
論理モデルでは概念モデルに対してデータの流れを意識しながら各エンティティが持つべき情報（アトリビュートといいます）を追記していきます。
最終的に営業データベースが必要とする情報から逆算して考えていきましょう。営業データの分析に必要なのは
- 誰が＝どの社員が
- いつ
- 誰に＝どの顧客に
- 何を＝どの商品を
- いくつ
- どうやって
売ったかです。まず営業データベースが必要とするこれらのアトリビュートを営業データベースに追記します。
これらのアトリビュートは、どのエンティティが保持する情報でしょうか。これを考え、さらに各エンティティに情報を追記していきます。
しかしこのER図では営業データベースのアトリビュートのうち、「いつ」「いくつ」「どうやって」の情報を持つエンティティが存在しません。
再度概念モデルに立ち返り、これらのアトリビュートを持つエンティティを追記する必要が生じたため、新たに「営業」「発注」のエンティティをER図に追記し、アトリビュートを持たせます。
このようになります。
物理モデルの実装
最後に物理モデルを実装します。物理モデルの段階では必要となるデータをどのような名前・形式で管理すればよいのか、どのツールに登録すればよいのかなどを実際に使用するツールやDWHの性質、実装予定のシステムを踏まえ決めていきます。最終的に物理モデルの図は実際のDWH内部の構造と同様になります。
例えば顧客エンティティが持つ「誰に売ったか」というデータはどのように管理すればよいでしょうか。顧客一人一人の氏名を手入力で管理するのは現実的ではありません。同じ名前の顧客でも打ち間違いや表記ゆれによって別の顧客として扱われる可能性があるためです。また例えばGoogle BigQueryというDWHではテーブルのカラム名に日本語は使用できないため「氏名」というカラム名は使用できません。
このように実際の運用を見据えた改善をしていきます。
今回の物理モデルでは、社員が取り扱うデータは代表的なSaaSサービスのひとつであるSalesforce上で、営業データベースはGoogle BigQueryでそれぞれ管理し、カラム名についてもサービスを跨いでも一義で管理できるようにします。
今回はデータモデリングの手順をざっくりと把握することを目的としているため、営業データの分析に必要な情報のみを図に表示していますが、実際の業務では営業データベース以外のエンティティはそれぞれ多くのアトリビュートを保持しており、また他の様々なシステムと複雑な関係にあります。
データモデリングのメリット
概念、論理、物理の３つのモデルを経てER図を作成しました。
この作業から大きく３つのメリットが得られます。
データベース実装の指針になる
実務のデータベース実装では、データベースの数と保持するデータの量も膨大で、かつそれぞれのデータベースが複雑に関係するなかで運用上もっとも効率の良いデータベース配置を行うことが求められます。したがって初期の設計段階できちんとデータベース配置の設計図を作っておくことが必要となりますが、データモデリングはまさにこの設計図を書き起こす作業といえます。
例えばあるデータベースにのみ処理が集中する設計になるため処理のパフォーマンスに注意する必要があるなど、実装段階でネックとなりそうな点を事前に把握しておくことも可能です。
データベースの維持改修が容易に
データベース間の関係を一度図示しておくと、そのデータベースに携わるチームのメンバーに対しても認識の共有が可能になります。上で述べたような運用上のリスクに対して共通の認識が持てるほか、そのデータベースの属人化、レガシー化が防止でき、データベースのメンテナスも容易になります。
またシステムへの新機能追加など既存のデータベースを改修をする機会は多く考えられますが、他のデータベースへの影響を最小限にする改修には事前のデータモデリングが重要です。
データベースの改善に役立つ
管理の行き届いていないデータベースが乱立しているという状況で、各データベースの配置を最適化する際にもやはりデータモデリングは有効です。この場合、まず現在のデータベース同士の関係を書き起こしたデータモデルと、要件から逆算して作成した理想のデータモデルとをそれぞれ作成し、２つを比較しながら改善していくことで効率よく最適化を行うことが出来ます。
まとめ
DMBOKを参考にデータモデリングの手順とメリットについてざっくりと解説しました。
データベースの実装・維持改修と長期に渡ってメリットがあるため、ぜひ取り入れてみてください。
一方で「改善どころかそもそも既存のデータベースのモデリングすら難しい」「モデリングしてみたけどデータの加工処理が複雑すぎて結局そのモデルが実現できない」「複雑なSQLは書けるが実行の順番はモデルを目で追って確認していて非効率」などデータモデリングを活かすにはまだまだハードルが高いのも事実です。
そこで弊社が提供するtrocco®はdbt連携機能をリリースしました。
dbtには「各データベースに対するSQLからデータベース間の依存関係を自動で抽出してドキュメント化する」「その依存関係を踏まえて加工処理を適切な順番で実行する」などの機能があります。また簡単なSQL文でより柔軟なデータの加工処理が可能です。
これらの機能を活かすことで、「専門的なデータエンジニアリングの知識や、分析基盤のメンテナンスコストなしに簡単にデータ分析基盤が構築できる」というtrocco®のメリットを活かしつつ、データの統合先となるDWH上では、dbtがデータベース運用の最適化を助けるという体制が可能となりました。
社内のデータ活用の際には、ぜひtrocco®をご検討ください。
trocco®では、クレジットカード不要のフリープランや無料の製品資料を提供しております。ぜひこの機会にお試しください。
