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

はじめに

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

※前回記事はこちら

第7章の目次

論理設計のアンチパターン
７ー１　論理設計の「やってはいけない」
７ー２　非スカラ値（第1正規形未満）
７ー３　ダブルミーニング
７ー４　単一参照テーブル
７ー５　テーブル分割
７ー６　不適切なキー
７ー７　ダブルマスタ
７ー８　ゾンビマートと多段マート

習得したこと

⚫︎非スカラ値
意味的に分割できる限り、なるべく分割して保持する、という基本方針が良いと考えている。(鈴木健二」ではなく「鈴木」と「健二」に分働して保持する、ということ)

理由は、分割したものを後で結合することは簡単にできるのに対し、結合された状態のものを後から分割するのは比較的難しいから

⚫︎ダブルミーニング
その列が何のデータを格納しているのか、判別できない。
ダブルミーニングの列は、運用途中で意味が変わってしまうため、「体重」とか「年齢」といった固定的な列名をつけることができないから。

テーブルや列の意味は、一度決めたら容易に変更してはならないものである、というのがリレーショナルデータベースの世界における取り決め。

⚫︎単一参照テーブル
あらゆるタイプのマスタテーブルを、一つのテーブルに放り込んでごった煮にしたもの
(テーブル全体が、あるときは「会社」、あるときは「性別」へと七変化する…)

⚫︎テーブル分割
① 水平分割:レコード単位
② 垂直分割:列単位

⚫︎集約（垂直分割の代替）
①列の絞り込み
データマート(Data Mart)もしくはマートとも呼ぶ。
オリジナルのテーブルを意味的に破壊することなく、パフォーマンスも向上させられるので、実際の開発においてもよく利用されている。

問題はマートの更新タイミング。
多くの場合、マートの更新は1日1回～数回程度の頻度で一括更新（バッチ更新）されている。
しかしこの場合、オリジナルのテーブルとマートのデータ不合の期間が長くなるため、機能的に問題がないか、要件と照らし合わせながら使重に換計する必要がある。

②サマリテーブル
集約関数によってレコードを集約した状態で保持する。

⚫︎不適切なキー
・主キー、外部キーなどデータベースの機能で設定されるもの
・テーブルの結合条件で使用される列（結合キー）

これらに明らかに使ってはいけないデータ型は
可変長文字列（VARCHAR）。
理由①可変長文字列の列は、キーが満たすべき条件である不変性（Stability）を備えていない
理由②固定長文字列（CHAR）との混同

キーは永遠に不変！

同じコード体系を示すキーのデータ型は（特に外部キーによる参照が行なわれる場合）同じもので揃えておくことが望ましい。

⚫︎ダブルマスタ
同じ役割を果たすはずのマスタテーブルが二つ存在するようなケース。
ダブルマスタはシステム統廃合で起きることが多い。

⚫︎ゾンビマート
データマートというのがわりとユーザーからのアドホックな要請に基づいて気軽に作られがちで、もう不要になったのに設計書が残っていないため誰も怖くて削除できなくなるとか、同じようなテーブル定義なのに以前作ったマートの設計書が残っていないためまた似たようなマートが作られるということが積み重なっていったときが問題。
中には数年間誰もアクセスしないのに詳細が不明なため怖くて削除できないという最悪の状況に陥っているケースもある。
こうした幽霊のようなマートをゾンビマートと呼ぶ。

⚫︎多段マート
マートからカスケードしてマートを作ること。
欠点はデータソースを追いにくいため、ファクトからどのようなデータを取り出してきているのか不明瞭になることと、一体いつ時点のデータ断面なのかもわかりにくくなること

⚫︎アンチパターンのどこが悪いのか
・可読性
・設計変更のむずかしさ
・データ構造がコードを決めるのであって、その逆ではない

感想

いやあ、、アンチパターン面白い。。
正直わたしは今勤めている会社がエンジニアとして初めて勤めている会社なのですが・・・
読んでて明らかにヤバそうなダブルミーニングとか非スカラ値は
まだこの会社ではみたことないです。笑（もしかしたらどれか、あるのかも）
というか、会社ではドキュメント型DBなのでまた違うアンチパターンが存在しそうですが。。

もちろん正規形を守ることはとっても大事だと前回学びましたが、
やっぱりパフォーマンスも大事・・ってことで、
マートを使用することも多いのだそうですね。
ただたくさん作りすぎるのはNG、というか、
なんでそのマートを作成したいのか、
作成するときは設計書も必ず作成しないと、不要になった時に消せない・・
結果不要なものが増え、パフォーマンスも低くなってしまうという。。
まさにゾンビ化😭

最後のコラムではなんでアンチパターンがダメなのか、という理由も説明してくださってます。
まさにこのDB設計は、プログラムの心臓的存在なので、
設計に携わる際は、アンチパターンになっていないか、
自分自身も良く考える必要がありますが、他の人が作成するものに関しても
その会社のプログラムの成功に関わる大事な部分なため、慎重になる必要がありますね。

関連

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