はじめに
あけましておめでとうございます。孔子の80代目子孫兼技術4課の孔です。今回のブログはPartiQL入門シリーズ第2回となります。
前回のブログでは、PartiQLがどのようなものなのかを説明しました。引用しますと、「PartiQL は QLDB ドキュメント指向のデータモデルへの SQL 準拠のアクセスをサポートする新しいオープン標準のクエリ言語」でしたね。それでは、前回十分説明ができなかった「ドキュメント指向のデータモデル」とは何かについて今回説明いたします。
ドキュメント指向のデータモデルとは
前回のブログでも少し触れましたが、ドキュメント思考のデータモデルはデータを以下のように保存するモデルを意味します。まずRDBMSのデータモデル（関係モデル）を掲載し、次にドキュメント指向のデータモデルを記載しますので比較してみてください。
関係モデル
(table : hr.employees) Id name title ---- ------------- ---------------- 3 Bob Smith null 4 Susan Smith Dev Mgr 6 Jane Smith Software Eng 2
ドキュメント指向のデータモデル
{ "hr" : { "employees": [ { "id": 3, "name": "Bob Smith", "title": null }, { "id": 4, "name": "Susan Smith", "title": "Dev Mgr" }, { "id": 6, "name": "Jane Smith", "title": "Software Eng 2"} ] } }
RDBMSでいうレコード（一行のデータのこと）を、ドキュメント指向のデータモデルではドキュメントと呼びます。それではこのようなドキュメントのメリットは何があるのか、確認していきましょう。
ドキュメント思考データモデルのメリット
例えば、急にこのような要望が入ったとします。
「次営業マネージャーとして入ってくる社員のMichael Jacksonさん、電話番号も登録したいんだよねー」
さて、もし社員のデータを関係モデルで記載していたら、ちょっと困っちゃいます。なぜなら、こちらはID、名前、職務しか登録できないテーブルなので電話番号は登録できないからです。よって、データベースをアップデートし、電話番号カラムを追加して、Michael Jacksonさんの電話番号を入力するしか方法はありません（既存の社員たちの電話番号フィールドは全部nullになるのはおまけです）
しかし、ドキュメント思考データモデルであれば以下のようにデータを登録するだけです。
{ "hr" : { "employees": [ { "id": 3, "name": "Bob Smith", "title": null }, { "id": 4, "name": "Susan Smith", "title": "Dev Mgr" }, { "id": 6, "name": "Jane Smith", "title": "Software Eng 2"}, { "id": 7, "name": "Michael Jackson", "title": "Sales Mgr", "tel": "012-345-6789"} ] } }
このように、保存するデータ構造をドキュメントごとに自由に定義できるのがドキュメント思考データモデルのメリットとなります。とても便利！もちろん、このようなデータベースを作ることによって、きちんと管理を行わないとデータベースの運用が煩雑になってしまうので、その部分を十分考慮したアプリケーションの作成が必須となります。
ドキュメント思考データモデルはこのような特性から、半構造化されたデータの記録に向いています。例えば、ビックデータがそうですね。いろいろなソースから、どのような属性を持った情報が飛んでくるかわからない、スキーマの定義が非常に難しいビックデータに置いて、ドキュメント指向データベースは強力なデータベースとなります。ユースケースを考えた上で、データの構造化ができるかできないか、パフォーマンスはどうなるか、を考えてドキュメント指向データベースを使用するかどうかを決めればいいかと思います。
最後に
今回はドキュメント思考データモデルについて、少し掘り下げてみました。次回はPartiQLを実際どのように使用すればいいのか、に関してお話しします。
それでは、本年もまたよろしくお願いします！
