達人に学ぶDB設計徹底指南書第2版・読んだまとめpart8

はじめに

本記事では、第9章を読んで得られた学びや感想をまとめました。

※前回記事はこちら

第9章の目次

一歩進んだ論理設計　〜RDBで木構造を扱う
９ー１　リレーショナルデータベースのアキレス腱
９ー２　古くて新しい解法　〜隣接リストモデル
９ー３　閉包テーブルモデル
９ー４　どちらを使うべきか

習得したこと

⚫︎ 木構造の取り扱いについて
・ノード (node)
木の結節点のこと。社員の組織図だと一人一人の社員がノードに相当する。

・ルートノード（root node)
木が始まるトップのノード。社長。根っこという意味。
木は、このルートノードを定義上一つしか持たない。

⚫︎隣接リストモデル
最も古典的なモデル。かつては検索／更新ともに複雑な処理を必要としたが、SQLの進歩により、再帰共通表式を使った柔軟な検索が可能になった。
更新処理も対象のノードに局所化されており、外部キーによる参照整合性制約も付与することができるため、もし使ってるDBMSが再帰共通表式をサポートしていれば、木構造を扱うファーストチョイスのモデルとなる。
まだ大規模な木での再帰計算のパフォーマンス（速度だけでなくリソース消費の観点でも）が未知数なのが懸念点。

●閉包テーブルモデル
すべてのノードについての経路を持つモデル。検索は柔軟で更新もそれはど複雑ではないため、隣接リストモデルが採用できない古いバージョンのDBMSを利用している場合のセカンドチョイスとなる。常に二つのテーブルの同期を取る必要があることと、更新が難しいとは言わないまでもいきさか面倒である点に留意する必要あり。

そもそも、木のような階層構造とフラットな二次元表の相性は元々悪い。

感想

第9章は最後の章だけあって、内容が難しく感じました。
いつ使用するのかがいまいちイメージついていない・・

ただ、本の中で出てきた参照整合性制約にDELETE CSCADEオプションを付ければ良いのではないかという意見に対して、「確かにビジネスロジックとして管理職をクビにすると必ず部下も連座してクビになるという仕様であれば、それでも構わない。」と書かれてあるのは印象的でした。

木構造だから、SQLも複雑で、メンテも大変そう・・みたいな印象。
正直まだ一回読んだだけでは理解できていないです。

以上、第1章から9章まで駆け足で読んできましたが、
データベースの論理設計について、知見がついたのは確かです。
そして設計の段階はそのプログラムの心臓的存在なので、
開発が成功するかどうかはデータベースの設計にかかっている。。
というかなり重要であるということがわかりました。
アンチパターンについても学びました。
メンテしやすい、生涯使えるデータベースの設計を心がけたいと思いました。

以上。

関連

達人に学ぶDB設計徹底指南書第2版・読んだまとめpart1
達人に学ぶDB設計徹底指南書第2版・読んだまとめpart2
達人に学ぶDB設計徹底指南書第2版・読んだまとめpart3
達人に学ぶDB設計徹底指南書第2版・読んだまとめpart4
達人に学ぶDB設計徹底指南書第2版・読んだまとめpart5
達人に学ぶDB設計徹底指南書第2版・読んだまとめpart6
達人に学ぶDB設計徹底指南書第2版・読んだまとめpart7