読書メモ：データ指向アプリケーションデザイン(3)

book development ddia

www.oreilly.co.jp

目次

2章データモデルとクエリ言語

リレーショナルモデル、ドキュメントモデル、グラフモデルそれぞれの成り立ちや特徴を説明していくチャプター。

2.1 リレーショナルモデルとドキュメントモデル

リレーショナルモデルは1970年生まれでいまだに現役なモデル。

ネットワークモデルや階層モデル、オブジェクトデータベースや XML データベースなど、さまざまなデータモデル・データベース技術との生存競争にさらされながら今に至る。

2.1.1 NoSQL の誕生

2010年代に登場したリレーショナルモデルの対抗馬としての 概念。

リレーショナルデータベースに対応できない要求やユースケースを実現するために考案された？

おかげで現代では適材適所にするのが当たり前になっている。

2.1.2 オブジェクトとリレーショナルのミスマッチ

広く使われているオブジェクト指向言語とリレーショナルモデルの間でモデルを変換するのが大変だったという話。

Java の Hibernate とか Ruby の ActiveRecord とかそういう。

LinkedIn のプロフィール(のデータモデル)はリレーショナルモデルよりドキュメントモデルのほうがきれいに表現できる。

やろうと思えばできるけど大変だよね、どうにかしたいよね、という話。

2.1.3 多対一と多対多の関係

  • リレーショナルデータベースは結合が得意
    • データモデルを正規化して別のエンティティになったデータをIDで参照するのが基本的な設計哲学
    • 正規化できないデータモデルの扱いは苦手
  • ドキュメントデータベースは結合が得意ではない
    • 別のエンティティだとしてもドキュメントへ埋め込む形で複製を持つようにするのが基本的な設計哲学
    • 同じエンティティの複製があちこちにできるため、更新が大変になる

2.1.4 ドキュメントデータベースは歴史を繰り返すのか？

  • 結局ドキュメントモデルの界隈でも多対他の関係をどのように表現するのか議論し始めている
  • 過去にいろいろなモデルが提案されてきた
    • 階層モデル
    • ネットワークモデル
    • リレーショナルモデル
2.1.4.1 ネットワークモデル
  • CODASYL モデル
  • 要するに一般化した階層モデル
2.1.4.2 リレーショナルモデル

はい

2.1.4.3 ドキュメントデータベースから見たデータモデル
  • ドキュメントに他のドキュメントを埋め込む構造は階層モデルと同じ
  • 多対1や多対多の関係はIDによる参照で表現する

2.1.5 今日のリレーショナルデータベースとドキュメントデータベース

  • リレーショナルデータベースとドキュメントデータベースの得意なところ
    • リレーショナルデータベース
      • 結合
      • 多対1の表現
      • 多対多の表現
    • ドキュメントデータベース
2.1.5.1 アプリケーションのコードをシンプルにしてくれるデータモデルは？

ケースバイケース。

  • アプリケーションのデータ構造によって変わってくる
    • オブジェクトがツリー構造になっているとかならドキュメントモデル
    • データ間の関連がたくさんあるならリレーショナルモデル、あるいはグラフモデル
2.1.5.2 ドキュメントモデルにおけるスキーマの柔軟性
  • ただしスキーマレスではない
    • 概念としてのスキーマは存在するけど、データベースが強制しないだけ
  • スキーマオンリード、という設計
    • データの読み取り時にデータ構造を解釈する
  • スキーマオンライト
    • リレーショナルデータベースがやっていること
    • データの書き込み時にデータ構造を解釈する
2.1.5.3 クエリのためのデータローカリティ(局所性)

読み取り効率の話なので詳しくは3章で。

2.1.5.4 ドキュメントおよびリレーショナルデータベースの融合
  • リレーショナルデータベースが XML や JSON などのドキュメントモデルに対応し始めている
  • ドキュメントデータベースが結合処理に対応し始めている

2.2 データのためのクエリ言語

  • 1970年に登場した SQL は関係代数の構造に忠実な新しい宣言型クエリ言語だった

2.2.1 Web上での宣言的クエリ

具体例。 CSS Selector や XPath や DOM のパースとかそういう。

2.2.2 MapReduce でのクエリ

具体例。 以下略。

2.3 グラフ型のデータモデル

データ構造を頂点と辺で表現する汎用的なデータモデル。

2.3.1 プロパティグラフ

あるエンティティ(頂点)の構造を任意のフィールド(プロパティ,これも頂点)への関連として表現する。

値の形式を自由に定義できるので極めて汎用的。

2.3.2 Cypherクエリ言語

Neo4J で利用できるクエリ言語。

人、生誕地、現住所が登録されたデータベースに対して次のようなクエリをどのように記述するか説明されていた。

  • すべての人々をスキャンして生誕地と住所を確認し、条件を満たす人々だけを返す
  • 2つのLocation から全ての場所(州、地方、市など)をスキャンして(WITH_IN)、BORN_IN と LIVES_IN の始点となっている人々だけを返す

2.3.3 SQLでのグラフクエリ

前節で Cypher で実装したクエリを SQL で頑張る例。

事前にどれだけ再帰結合すればいいかわからないと実装できないのでだいぶ苦戦する。

2.3.4 トリプルストアとSPARQL

  • SPARQL はトリプルストアのためのクエリ言語
  • トリプルストアはすべての情報を「主語」「述語」「目的語」の組(トリプル)で表現する
    • プロパティグラフモデルと同じ概念を表現できる
    • RDF で利用しているデータモデル
2.3.4.1 セマンティックWeb

ティム・バーナーズ・リーの提唱したプロジェクト。

2.3.4.2 RDF データモデル

セマンティックWebのコンテンツに追加するメタ情報のためのモデル。

RSS は RDF のサブセット。

2.3.4.3 SPARQL クエリ言語
  • トリプルストアのためのクエリ言語
  • W3C で標準化されている

2.3.5 礎となったもの：Datalog

  • 1980 年代から研究されていた元祖クエリ言語的な言語
  • Prolog の派生言語
  • Datomic とかでも利用できるし、他にもいろいろなデータベースが実装してる