【読書log】理論から学ぶデータベース実践入門 – リレーショナルモデルによる効率的なSQL：第9章〜第10章

私の備忘録として、勉強になった内容と個人的な感想をまとめています。

あくまでも備忘録なので、詳しく勉強したい方は実際に書籍を手に取ってみてください🙇‍♀️

※イタリック体の文字は私の感想です。

第9章履歴データとうまく付き合う

履歴データはリレーショナルデータベースと相性が悪い。
- 履歴には順序が存在するため。
- クエリの実行日時によって実行結果が変わるため。すなわち、各行の意味が均一ではない、or、実行日時において有効な値と無効な値が存在する、とも言い換えられる。
- etc…

→このほかにも、開始日と終了日を持つテーブルの場合、複数のデータ間で開始日と終了日の整合性が取れないような不適切なデータが存在してしまう可能性がありますね。これで不具合が発生したことがあります・

履歴データの扱いに失敗すると、遅いクエリになってしまう。
- テーブルが大きくなりやすいため。
解決策にはトレードオフがあるので、用途によって使い分ける。
- 現在の値用のリレーションと、過去の値用のリレーションに分割する。
  - 未来の値がある場合は、これらに未来の値用のリレーションが追加される。
- 現在の値用のリレーションと、全ての値用のリレーションを用意する。
- 現在の値用のリレーションと、過去の値用のリレーションに分割した上で、サロゲートキーを利用してすべての値用のリレーションを用意する。

→現在の値用のリレーションのデータはバッチ処理等で変更することになると思いますが、値が定刻に切り替わらないのが最大の難点であると感じます。書籍では要件を調整するように記述されていますが、顧客によっては現実問題は難しそうです（金融系や行政系のシステムなど）。

以下に合致する場合はDB設計を見直す。
- ステータス・フラグ・バージョンを表すカラムが存在する。
- 初期値がNULL（もしくは同等の意味を持つ）のカラムがある。終了日時など要注意。
- 現在時刻と比較をしている。
- ソートして1件を取得したり、最大値や最小値を利用したりという処理がある。

→これらが存在するDB設計は、実際にクエリを書いていて分かりづらいと感じることが多いので、見直す価値は十二分にありそうです。

グラフ理論のグラフは、ノードとエッジと呼ばれる要素で構成されており、ノード同士をエッジで繋ぐことで事象の関連性などを表現できるデータ構造である。
- ネットワーク図、Webページのリンク、ソーシャルネットワーク、などが該当する。

→グラフ理論という単語を耳にしたことはありますが、あまり馴染みがないので興味深いです。昔、東京大学の数学の過去問でこんな感じの問題があった気がします。

グラフの種類
- 単純グラフは、多重辺およびループがないグラフ。
- ツリー構造は、単純グラフの最も単純な構造である。
- 有向グラフは、エッジの接続が一方向のグラフ。
  など

→グラフの理解には、ネットワークスペシャリストで勉強した内容が助けになりそうに感じます。有向グラフは、フローチャートなども該当するのでしょうか？

グラフはリレーショナルモデルではうまく表現できないデータ構造なので、RDBはグラフを扱うのが苦手である。
- 重み付きグラフから最短経路を探索する処理ですら、SQLでは記述が困難である。
- 宣言型言語のSQLではなく手続き型言語を利用する方法や、RDBとグラフDBの併用などで、解消できる場合もある。

→過去に勉強したPL/SQLはこんな場合に力を発揮するはずであるが、いにしえの記憶なので心許なさすぎます。。。

ツリー構造をRDB上で表現する方法として、隣接リストモデル、経路列挙モデル、入れ子集合モデル、クロージャテーブルモデル、などがある。
- これらの中ではクロージャデータモデルが最も相性が良いが、いずれのモデルでもRDBでツリー構造を担保しているわけではないので、アプリケーション側で担保する必要がある。

→入れ子集合モデルは取り扱いが難しそうだが、他のモデルは状況によって取り入れられそうだと感じました。

履歴データに関しては、設計が甘いとデータに不整合が発生して障害の原因になるので、改めて書籍内で記載されている問題が生じないように設計やレビューをしたいです！

グラフ理論には馴染みがなかったのですが、初学者の私にとっては分かりやすい内容で助かりました。詳しい方にとっては、物足りないかもです。。。

Webページのリンクなどは、もしかしたら今後業務で考慮する必要が出てくるかもしれないので、頭の片隅に置いておこうと思いました。

リンク

以上