どうも、近々引っ越しを考えていたのに在宅勤務が始まって引っ越す意味がなくなった人です

今日は「本当にあったやらかしDB設計④【テストチューニング】」に続いてびっくりしたことを紹介します

#第三正規化病
「正規化は第三正規化までやればいい！」と誰かが言ってたらしいです
僕の周りにはR無しRDBを見ても何も思わないような人ばっかりなので直接聞いたことはないですが…ｗ

しかし、第三正規化まですればいい、というのは嘘です
必要に応じて更に正規化を行う必要があります
ほとんどの場合、更に正規化をしたほうが良いです

※詳細について知りたい方は、是非SQLアンチパターンの付録としてついてきている「正規化のルール」を見てください

###何が悪いの？？
正規化という考え方に縛られてはいけません
一番重要なのはデータの不整合を防ぎつつ、データの冗長性も減らすことです

###問題
第三正規化までやればいい！、という考えに縛られていると、冗長なデータが生まれ、それが元になってデータの不整合が発生する可能性があります
データの不整合が起こると、ありもしないデータが存在していることになったり、存在しているはずのデータが紛失したりします
恐ろしいですね

###原因
なぜ、第三正規化までやればいい！なんて言葉がまかり通っているのか、ちょっと考えてみました

正規化を勉強するのがめんどくさい

正規化を勉強するのは意外と面倒です
正規化は複数の種類があり、正規化のレベルが上がっていくごとに段々複雑になっていきます
第三正規化までやればいい！みたいなことを言っておけば、確かに学習コストがその分下がるかもしれません(それだと正規化を勉強している意味がない気がしますが)
ただし、実は言うほど複雑ではありません

正規化のルールは、難解なものでも複雑なものでもありません。
正規化のルールは冗長性を減らし、データの整合性を保つために用いられる、ごく常識的な技法なのです。

SQLアンチパターンより

テーブル設計をするときの目安が欲しかった

テーブル設計に不慣れな人は意外にも多いです
不慣れな人は基準を欲しがります
そこに、第三正規化までやればいい！と言われて信じ込んでしまうと第三正規化病に罹ります
重要なのはデータの不整合を起こさないことです

###解決方法
第三正規化病に罹らないようにするためにはいくつか予防策があります

######初心者向けの教材を信じない
初心者向けの教材は理解させることに重点を置くため、適度に嘘をつきます
初心者向けの教材を理解した後にはもっとレベルの高い教材にチャレンジしてみてください

######参照整合性を考える
同じ意味を持ったカラムが複数のテーブルに存在している場合は、必ず外部キー制約を使って参照整合性を確保してください

かんたんなやり方は、参照整合性をカラムごとにチェックすることです
同じ意味を持ったカラムがひとつのテーブルにしかない場合は、ユニークキー制約やチェックキー制約など、他の制約を利用することも考えるべきです

僕の経験上、制約の必要が無いカラムはほとんどありません

制約が付いていないカラムがあったら、本当にそれで良いのか議論するべきです
大抵の場合は制約を付けるべきです

#####冗長なデータが生まれないようにする
冗長なデータがあるとボリュームを食う上、データの不整合が発生する可能性があります
履歴テーブル(ログテーブル)と呼ばれるようなものは僕もよく使いたくなってしまいますが、冗長なデータがめちゃくちゃ生まれますｗ
とある時点でのデータを参照するのには役立ちますが、このような使い方をするのは分析用DBであり、処理用DBでは使うべきではないと考えています
T字形ER手法というやり方もあるのですが、今はあまり理解していないのでまた後程…w(とりあえず本は注文した)

2020/08/19追記
T字形ER手法についてまとめました
下記記事を参照してください
T字形ER手法って何？？？

#まとめ

第三正規化までやればいい！は嘘
データの不整合を許すな
冗長なデータがあると金かかるよ

データの不整合を許容する理由は分析系DB以外には絶対にありません
根拠の無い嘘に騙されないでください
第三正規化病は、データの不整合を許容するために使う方便です

しかし、正規化は基本となる手法をまとめたとても役に立つものです
正しく正規化を理解することで良いテーブル設計ができるような手助けをしてくれます

是非、最高の正規化をしてください

本当にあったやらかしDB設計シリーズ一覧