DMBOK で一番読むのを楽しみにしていたのがデータモデルの章だったのですが、いざ読んでみると細かすぎるというか、求めていたものと違う感覚がありました。私がドメイン駆動設計から生成されるモデルの実用性に興味をもっていた時期なので、実践的な内容を求めているだけかもしれませんが…。DMBOK ではデータモデリング・スキームが多数紹介されていたり、データモデリング戦略を立ててモデリングしていきましょう・・・といった内容が書かれており、現職で起きている問題を解決するのには役立たなそうだと感じました。
そんな中で見つけたこのデータ総研さんの記事で合点がいきました：
（EDW報告その2）データモデリングの逆襲 | 株式会社データ総研
データ構造を固めなくてもデータを格納して貯めていけるNoSQLは、Webを中心としたシンプルなビジネスで数多く採用されています。テキストも画像も音声も動画も、なんでも構造を意識せずNoSQLデータベースに格納し、必要なものを必要な時に見つける運用が広まりました。その結果、ER図を中心としたデータモデリングへの関心も下がっていました。
これまでは・・・
上の記事では NoSQL によって構造を気にせずデータを格納できるようになり、データモデリングの需要が減ってきたと書かれています。しかしデータ量が増えてデータ活用のニーズが増えてくると、データ同士の関係性を可視化したデータモデルへの需要が再び高まってきます。以下の一文でも完結に表されています：
20年前は「データの構造設計→格納→活用」の流れで必要だったデータモデリングが、現在では「データの格納→構造の発見→活用」という流れの中で必要とされているのです。
データモデリングが必要な文脈が変わってきた、というんですね。DMBOK はもちろんどちらでも使える内容ですが、やや前者・・・事前にデータ構造を設計してから格納することを前提にしているように見えるので、後者の課題をもつ現職だとどこから手をつけて良いか分からないのだと理解しました。ビッグデータアーキテクチャ では ETL（抽出、変換、ロード）ではなく ELT（抽出、ロードしてから変換）が主流な点からも、まずとにかくデータを格納するようになったという文脈の変化は理解できます。「データレイク」という言葉も文脈の変化を表しているかもしれません。
これは個人的な意見ですが、パブリッククラウドの登場によって多くのユーザが自由にテーブルを作成できる環境になり、データモデリングを今までのように行うことが難しいのではないのでしょうか。その中で dbt や Dataform（Googleにより買収）はデータリネージや変換処理を分かりやすく管理できるツールとして最近脚光を浴びています。こういったツールで実データに紐づく物理・論理レイヤのデータモデルを作成できれば、あとは中央集権的にデータモデラーが概念モデルとしてまとめ上げる流れがあればよさそうです。
dbt も Dataform もまだ利用経験がなく、憶測で書いているところもあるのですが、この辺りの違和感がある方や、DMBOK の解釈が間違っている、などなんでも良いのでご指摘いただけたら嬉しいです。
