« 「発効日」を主キーに含むデータモデル | トップページ | 総合プログラマではなく専門プログラマになろう »

2018.12.29

NoSQLでもデータモデリングが必要

 東急ハンズでの開発事例で有名になった「ユニケージ手法」のデモを見る機会があった。テキストファイルの集まりとしてデータを保持し、UNIXコマンドとスクリプティングで操作・加工するという独特なスタイルでシステム構築するための手法である。更新処理でのロックがレコード単位ではなくファイル単位といった制約もあるが、RDBと同様のことをやれるし、パフォーマンスや開発効率の高さも多くの事例で証明されている。

 私にとってとくに興味深かったのが、各ファイルのデータレイアウトを設計する過程だ。ユニケージ手法では「データ整理」と呼ばれるのだが、これがデータモデリング以外の何物でもない。「主キー」とか「外部キー」といった用語は使われないが、この作業でデータレイアウトが的確に正規化されなければいけない。これに失敗すれば、RDBを使った場合と同様に更新時異状(アノマリー)が生じる。

 ユニケージ手法は「NoSQL」に分類される技術だが、これを用いて開発されるソフトウエアが業務システムなのであれば、けっきょくデータモデリングが必要になるという話である。ユニケージ手法に限らない。XMLやJSONやkey-valueを使うとしても、またRailsのようにサロゲートキーが強制される環境でも、業務データを扱うのであれば「正規化」および「正規形を意識しながらの正規化崩し」による慎重なデータ設計が求められる。

 言うまでもなく、複雑な構造をとるデータは業務データに限らない。科学計算や一般の統計処理において扱われるデータであっても、一定以上の複雑さを伴うならばデータモデリングが必要だ。流行の「データサイエンティスト」の仕事でも、非構造化データを分析して構造化データとしてまとめる際に、データモデリングをやれるかどうかで成果に差が出る。

 ようするに「扱われるデータの構造が複雑かどうか」の問題なのだが、IT技術者がさまざまな案件をこなす過程で、単純なデータ構造ばかりを扱えるとは限らない。けっきょくのところ、大は小を兼ねるでデータモデリングのスキルは身につけておいたほうがいい。

 データモデリングはRDBやSQLとセットで理解されることが多い。しかしこの技術は本来、E.F.コッド博士や日本の椿正明博士らによって生み出され発展した「データ構造を論理的に捉えるための数学的枠組み」である。RDBやSQLはこの枠組みから派生した技術要素ではあるが、それらを生み出すためだけのものではない。NoSQLだろうが何であろうが、更新時異状を起こさずにデータを維持するために必要な思考の枠組み、それがデータモデリングだ。IT技術者が身につけておいて損はない。

|

« 「発効日」を主キーに含むデータモデル | トップページ | 総合プログラマではなく専門プログラマになろう »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: NoSQLでもデータモデリングが必要:

« 「発効日」を主キーに含むデータモデル | トップページ | 総合プログラマではなく専門プログラマになろう »