WIP【備忘録】DBの論文を読む : バックグラウンド

データベース

そろそろデータベースに関するちゃんとした基礎知識をつけたいという思いがあるので、Readings in Database Systems, 5th Edition を読んでいこうと思う。
URL: http://www.redbook.io/index.html

この本は、DB に関する古典的な論文から、近年の特に重要な論文まで、章ごとに短い解説とともに紹介されている。

今回は Ch1 バックグラウンド を読む。

紹介された論文

  1. What Goes Around Comes Around. [因果応報] (2005).

    • 約 35 年間の間に提案されてきたデータモデルとそこから得られる教訓について解説されている。

  2. Architecture of a Database System. [データベースのアーキテクチャ] (2007).

    • DB の構成要素と全体像について解説を行っている。

解説を読んだ

かつて XML をリレーショナルエンジンに追加するのが流行りかけていた(?)らしいが、以下の理由でだめだったらしい。

  • XML そのものも、そのためのエンジンの拡張も複雑過ぎた
  • ユースケースが狭かった

その次は JSON が台頭した。
JSON はデータ形式が階層的であったり、Schema on read と相性が良かったりでスパースなデータに非常に適していた。
JSON については本文では以下のように書かれている。

私は、RDBMS が JSON を単なるデータ型（数あるデータ型の中の 1 つ）としてシステムに組み込むことを期待しています。

Readings in Database Systems, 5th Edition

postgre とかは JSON 型があった気がする。
ここらへんの非構造なデータモデルの話は NoSQL, GraphQL とかと関わりがあるのだろうか。

他に言及があるデータモデルは Map-Reduce, BigTable など。
この辺りに関わる HDFS, Spark, Hadoop やデータレイクは Ch5 で詳しく話してくれるっぽい。

論文２は殆どのレガシー DBMS（Oracle、DB2 など）がどのような仕組みで動いているのかを解説している。 また、現在の DBMS の構造はこの論文の説明とは詳細部分は大きく異なるものの、全体的なアーキテクチャは変わらないとしている。
(例えば、昔は行ストアが主流だったが今は列ストアが取って代わっている)
とはいえ、今の日本社会で動いている DB の中には所謂レガシーなものが沢山あるだろうし、学んでおいたほうが良さそうだと私も思う。

参考文献

論文１について

この論文ってデータモデル提案の歴史について書かれたものなんだけど、 そもそもデータモデルの定義をうまく言えなかったので、wiki で調べることか

データモデルは、アプリケーションである設計のための計画として使うソフトウェア工学の抽象モデルの 1 つである。班・要員間の意思疎通のための事業データの文書化、組織化、そして特にデータの格納方法や利用方法のために利用される。

データモデルは、データまたは構造化データの構造を明示的に決める。データモデルの代表的な応用は、データベース・モデル、情報システムの設計、およびデータの交換を可能にすることを含む。通常データモデルは、データモデリング言語によって規定する[3]。 出典 データモデル

ユーザーは実世界のデータを扱うが、そのデータが DB にどの様に格納されるかという低レベルの話は考えたくない。
データモデルを使用することで、(実世界の)高レベルの構成要素を使用してデータを定義することが出来る。
DB の文脈では、私達の世界の情報を DB 上でどの様に表すかという情報だと思って良さそう。

で、この論文は 1960 年~2005 年までにされたデータモデルの提案を以下の年代に分けて夫々解説した後、歴史から得られる教訓をまとめている。

  1. Hierarchical (IMS): late 1960’s and 1970’s
  2. Directed graph (CODASYL): 1970’s
  3. Relational: 1970’s and early 1980’s
  4. Entity-Relationship: 1970’s
  5. Extended Relational: 1980’s
  6. Semantic: late 1970’s and 1980’s
  7. Object-oriented: late 1980’s and early 1990’s
  8. Object-relational: late 1980’s and early 1990’s
  9. Semi-structured (XML): late 1990’s to the present

What Goes Around Comes Around.

こんなに沢山のデータモデルが提案されているとは思わなかった...。 特に耳慣れない Object-relational(OR)という提案は SQL エンジンにユーザ定義の{データ型, 演算子, 関数, アクセスメソッド}を追加した事が特徴的だったらしい。(Postgre が代表的)

個人的には、関係モデルより先に階層型データモデルが提案されたことが意外だった。関係モデルの方が最初に思いつきそうなものだけど...それは私が関係モデルに慣れてるからなだけなのかな。

ER モデルが元々 DB のデータモデルとして提案されたことも初めて知った。 今までクラス図とかスキーマ表現で使われているのは見たことがあったけど、関係モデルとの関係がよりクリアになった気がする。

TODO: XML の感想

ここ最近の NoSQL 等の話題もいつか触れていきたい。

各データモデルに対して説明が程々にあり、読みやすい論文だったと思う。

最後に、論文で載せられている教訓を記載する。

  1. 物理・論理データ独立性はとても望ましい
  2. 木構造データモデルは非常に制限的
  3. 木構造データを論理的に再構成するのが課題になっている
  4. レコード毎(record-at-a-time)の UI ではプログラマは手動でクエリ最適化を行う必要があるが、これは困難であることが多い
  5. 有向グラフは階層モデルよりも柔軟であるが複雑
  6. 有向グラフのロードとリカバリーは階層モデルよりも複雑
  7. データモデルがなんであれ、セット毎の(Set-a-time)言語は良い。物理データ独立性が格段に改善するからだ
  8. 複雑なデータモデルよりも単純なデータモデルのほうが論理データ独立性は高めやすい
  9. 技術的な議論は、たいてい市場の巨象によって解決される。技術とはあまり関係のない理由で決まることが多い
  10. クエリオプティマイザが勝てないのは、最高の record-at-a-time DBMS プログラマだけ
  11. 機能依存性は人間が理解するには難しすぎる。KISS(Keep it Simple Stupid)
  12. 性能や機能面で大きなメリットがない限り、新しい構造は成功しない
  13. パッケージは、ユーザーが "大きな痛み"を感じていないと売れない。
  14. 永続的プログラミング言語は、プログラミング言語コミュニティのサポートがなければ成功しない
  15. OR(Object-Relation)の主な利点は２つ。
    • コードはデータベースの中に入れられること(それによりコードとデータの区別が無くなる)
    • 汎用的な拡張機能により、市場の要求に素早く答えられる
  16. 新技術が広く浸透するには、標準規格(と・または)強く推す推す巨象が必要だ
  17. Shema-later はおそらくニッチな市場
  18. XQuery は構文が違うだけの OR SQL に近い
  19. XML では、企業の内外を問わず、意味論的不均一性を解決できない

What Goes Around Comes Around. 投稿主による翻訳

論文２について

論文２はかなり長いので別記事に移した。

zypressen.hatenadiary.com