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

はじめに

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

※前回記事はこちら

第8章の目次

論理設計のグレーノウハウ
８ー１　違法スレスレの「ライン上」に位置する設計
８ー２　代理キー　〜主キーが役に立たない時
８ー３　列持ちテーブル
８ー４　アドホックな集計キー
８ー５　多段ビュー
８ー６　データクレンジングの重要性

習得したこと

⚫︎グレーノウハウとは
アンチパターンとははっきり断定することこそできないものの、無神経に使うと開発や運用に支障をきたす設計のこと。
アンチパターン以上に広く利用されている。

⚫︎主キーが決められない、または主キーとして不十分なケース
パターン①そもそも入力データに主キーにできるような一意キーが存在しない。
パターン②一意キーはあるが、サイクリックに使いまわされる。
パターン③一意キーはあるが、途中で指す対象が変化する。

⚫︎代理キー（surrofate key）による解決
人工的なキーをシステム側で付与してやることで、自然キーを主キーに選んだ場合に発生する不都合を解消することができる。

正し一般的な原則としては、極力代理キーの使用は避けて、自然キーによる解決を図るべき。
理由：代理キーがそもそも論理的には不要なキーのため、論理モデルをわかりにくくしてしまう。

代理キーに求められる要件は、基本的に一意性のみ。
キーの値自身に意味が求められることは、ほとんどない。
システム側の裁量で体系を決めることができるという自由度の高さが、代理キーの便利さの一つでもある。

⚫︎自然キーによる解決
パターン①はそもそも主キーが存在しないので、DB側で打つ手なし。
パターン②と③は解決可能。履歴管理のための時間を表す列を追加する方法がある。
タイムスタンプとインターバルの二種類が存在する。

⚫︎タイムスタンプ
ある「時点」を意味するもの。
データの形式が単純なので利用する際も、SQLの条件が簡単になるなど、シンプルなのが利点。
ただし、レコード数が増える。

⚫︎インターバル
データの有効な「期間」を表す方法。
「開始年度」と「終了年度」という二つの時間列を持つことで、データの有効期間を示している。
全体としてはレコード数を少なく抑えられる。
一方で、SQLで必ず範囲指定の条件を入れる必要があるため、SQLが少し複雑になる。

⚫︎オートナンバリング
代理キーを実装する際、しばしば利用される方法が「オートナンバリング」。
１レコードに一位な整数値を自動的に割り振る方法。

⚫︎列持ちテーブル
JavaやCなどでデータを配列に保持するが、それをテーブルの「列」を使って模したのが列持ちテーブル。
正規化とかスカラ値を知らない人でも、テーブルを見れば子1、子2、子3の各列が配列を示していることがわかる。

正し欠点もある
①列の増減が難しい
②無用のNULLを使わなくてはならない

※ミックさんは、
列持ちテーブルはアンチパターンともされているが、
利点もあるため、そこまで厳しく使用を制限する必要はないのではと考えている。

⚫︎行持ちテーブル
列持ちテーブルより欠点の少ない定石。

列持ち↔︎行持ち二つのテーブルは、SQLによって簡単に変換が可能。

⚫︎アドホックとは
アドホック（ad hoc）は、「特定の目的のための」「限定目的の」などといった意味。

⚫︎多段ビュー
保存がきく上に、開ければ常に新鮮なデータを取り出せる「クエリの缶詰」みたいなもの。

・ビューへのアクセスは「2段階」で行われる。
ビューは実データを保持しないという点で、物理的にはSELECT文が書かれたファイルにすぎない。

・ビューはどうやってデータを取ってきているか
SELECT文を実行して、オリジナルのテーブルにアクセスしている。2段階のSQLが実行されているようなイメージ。

・DBMSは可能な限りSELECT文をマージして、効率のいい形で実行しようとする。
が、①＋②で生まれる③のSELECTを実行することによって、
普通のテーブルへのSELECTより複雑で高コストな処理になってしまう。

・ビューの使用は、原則として１段にとどめておくようにする。

・Keep It Simple, Stupid.（単純にしておけ、このバカ）

・マテリアライズドビューに関しては
多段で構築しても、SELECTのパフォーマンスが悪化するということはない。
マテリアライズビューが、実データを保持するから。
テーブルのある瞬間における断面を実装した機能であるため、ビューとは少し異なる。

⚫︎マテリアライズドビューがパフォーマンス面で有利な理由
①実データを保持するので、通常のビューと異なり、アクセス時にビュー定義のSELECT文が実行されない。
②主キーをはじめとしてインデックスを使用することができる

⚫︎マテリアライズドビューの欠点
①リフレッシュの管理が必要である
②普通のテーブルと同様にストレージ容量を消費する

→通常のテーブルでデータマートを作る場合と同じ。
何事も、いいことばかりでない（トレードオフの原則）。

⚫︎データクレンジング
データベースを構築するにあたって、それまで業務で利用されていたデータをデータベースに登録できる状態にすることを指す。
（通常の業務データは、掃除が必要な「汚い」状態ということ。）
データベースの論理設計に取り掛かる前に、入力データのフォーマットが適切なものか調査し、
必要であればデータそのものの変更やフォーマット変換が必要。

⚫︎代表的なデータクレンジングの内容
①一意キーの特定
②名寄せ

・一意キーの存在しないデータは、アンチパターン「不適切なキー」をもたらす。
・名寄せをサボると、アンチパターン「ダブルマスタ」を生み出す

感想

第8章では、グレーゾーンにあるグレーノウハウを学びました。
これは、アンチパターンまではいかない設計方法ですが、
多用しすぎてアンチパターンよりタチが悪い場合もあるそう・・。

解決策も複数あるも、やはりトレードオフの原則で、いい面があれば悪い面も存在する。
Kissの原則（Keep It Simple, Stupid.）は衝撃w
やりすぎは良くないということも、改めて習得。

業務ではビューの部分について、
私はビューを作成することでSELECTのパフォーマンスが良くなると思っていたので、
まさか2段階でクエリを実行しているなんて・・
どこかで、ビューを使用した方が早くなるって書いてたような。

SELECT文が何度も出てくるSQLを簡素化し、メンテナンスしやすくしてくれます。
また機密情報を特定権限を持つユーザにだけ表示したい場合もビューのアクセス制御により、
開示情報をコントロールすることができます。
それにより情報漏洩リスクを最小に抑えることができます。

※参考

あれ、早くなるなんてこと、そんなことどこにも書いてませんでした。💦笑
もう一度、Postgresの本を読んでみます。（多分あの本で見たようなという記憶がある）

そしてマテリアライズドビューについても知見が広がりました。
でもまだ、実データ保持してるなら、元々のテーブルは不要なのでは？みたいな疑問もあります。

勉強不足です・・
調べてみます。

次は第9章！なんと最終章！
駆け足で読み進めましたが、演習問題とかはざっくりしか見ていないので、一通り読んだら解いてみます。

関連

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