第2章 データモデルとクエリ言語
要約
データモデルには様々な種類があり、それぞれが異なる利用方法を提供します。
リレーショナルモデルはSQLデータモデルで知られ、30年以上の歴史があります。ドキュメントモデルはJSON形式で階層構造を持ち、人間には理解しやすいが多対多の関係表現が難しいとされます。グラフモデルは多対多の関係が複雑な場合に有効で、ソーシャルネットワークや不正検出などに利用されます。NoSQLはリレーショナルデータベースの限界に挑戦し、大規模データセットや高いスループットが求められる状況での利用が増えています。
前の章
前の章である第1章 信頼性、スケーラビリティ、メンテナンス性に優れたアプリケーションはこちらです。
データモデル
世の中にはデータモデルにおいて多くの種類があり、それぞれのデータモデルは想定される利用方法を具体化したものになります。高速に行える処理もあれば、パフォーマンスの出ない処理もあったりします。データモデルはソフトウェアにできることとできないことに関して、極めて大きな影響及ぼします。
アプリケーションに適したデータモデルを選択することが重要になります。
リレーショナルモデル
現在最も知られているデータモデルは、おそらくSQLのデータモデルになるでしょう。これはEdgar Coddが提唱したリレーショナルデータモデルにも続いています。
リレーショナルモデルは効率的の実装が難しいのではないかと、当時は疑問視されていましたが、正規的な構造のもとでデータを保存し、クエリを実行する必要がある。人々にとって、リレーショナルデータベース管理システムとSQLを実装するようになりました。これは30年以上使用されている技術になります。
ドキュメントモデル
JSON形式に代表される階層構造をもったデータベースです。
1対多（ツリー構造）だったりレコード同士が関係を持ったりしないのであれば、このドキュメントモデルが適しています。
階層構造を取ることで、人間にとって理解しやすいのですが多対多の関係を表現することができないというデメリットもあります。
ドキュメントデータベースはスキーマレスだと言われますが、これは異なります。暗黙のうちにスキーマがあると想定していますが、データベースがそれを強制しないという意味になります。本書ではスキーマオンリードであり、スキーマオンライトの逆と表現されています。
詳細は下記の記事をご覧ください。
グラフモデル
多対多の関係が非常に多く、データ同士のつながりが複雑になっていくとデータをグラフとしてモデル化する方が自然になってきます。
グラフを使用すると、ソーシャルネットワーク、IoT、ビッグデータ、データウェアハウスの接続とパターン、さらには銀行での不正検出、ソーシャルネットワークでの接続の検出、顧客360などの複数のビジネスユースケースの複雑なトランザクションデータを探索して発見できます。
NoSQL
2010年代に登場して、リレーションモデルの支配を終わらせようとする試みがNoSQLになります。もともとはリレーショナルな分散データベースのミートアップのためだったのですが、後々Not Only SQLとして解釈されるようになりました。
昨今では、クラウドやデータの量が急激に増加したこともあり、巨大なデータセットや書き込みのスループットを含むリレーショナルデータベースで、容易に実現できる以上のスケーラビリティーが求められるようになったことが1つの要因です。
下記のAWSの記事には、RDPとNoSQLの比較が掲載されています。
IDを使うことのメリット
IDを使うことのメリットは、ID自体は人間にとっては何も意味を持たないことから決して変化する必要がないと言うところになります。逆に言うと人間にとって意味のあるものは全て将来どこかで変更しなければならなくなるかもしれないということです。
変更する必要が出てきた場合は それらのコピーも全て更新する必要が出てきてしまいます。これは書き込みのオーバーヘッドを生じさせたり、不整合のリスクを伴う可能性があります。
まとめ
以上、データモデルとクエリ言語について解説しました。
歴史としては、まずデータは1つの大きなツリーとして表現され、階層モデルが使われていました。ただし、これは多対多の関係をうまく表現できなかったということからリレーショナルモデルが考案されました。しかし、リレーショナルモデルもうまく適用できないアプリケーションがあることでNoSQLが作成されました。
クエリ言語に関してはこの章では解説しませんでした。後の章で別途紹介するのでご期待ください。
データモデルとクエリ言語について特に重要な点を解説しました。ただし、非常に量が多いため解説していない部分が多々あります。詳細は本書を手にとってみて下さい。
いいなと思ったら応援しよう！
