正規化：データベース設計の基本：その４
REV１７
ブログ投稿しています。複数画像付き等最終版は此方から、ご覧ください。
基本に立ち返る意味で、正規化の手順を先ず記して、幾つかの正規化手順について纏めて複数回の分けて、ご説明したいと思います。
先ずは正規化の手順ですが、以下の通りと言われています。
第一正規化手順
第二正規化手順
第三正規化手順
ボイスコッド正規化手順
第四正規化手順
第五正規化手順
第六正規化手順
第六正規化手順は正確に存在するかは？です。（説明は無しにするかもしれません）
以下、具体的な正規化手順の説明です。（前回からの続きでボイスコッド正規化手順から説明します）
ボイスコッド正規化手順
ボイスコッド正規化とは第3.5正規化手順ともい言われています。
通常のデータベースであれば第三正規化手順を経た状態で、データベースとして問題無く使用可能と言われています。
ではボイスコッド正規化とはどのようなデータの正規化を考えているのか？
ボイスコッド正規化ではキーから主キーへの主従の従属を排除したものになります。
今回のサンプルデータでは第三正規化手順を経た段階で、全テーブルは以下の通りです。
仕入ID商品ID商品数A0001F000110A0001F000225A0002F000350A0003F0004100
第二正規化後テーブル１
商品ID商品名単価F0001リンゴ250F0002柿150F0003みかん80F0004イチゴ45
第二正規化後テーブル３
仕入ID仕入年月日仕入先IDA00012023/1/5Z0001A00022023/1/6Z0002A00032023/1/9Z0003
第三正規化後テーブル１
仕入先ID仕入先Z0001X商店Z0002Y商店Z0003Z商店
第三正規化後テーブル２
これらテーブルの内、主キーとキーとなるものの組み合わせが有るか確認します。
＊＊＊マスタはIDと＊＊名等の為、キーと主キーの関係は存在しません。
その他のテーブルについては主キーとその他のデータとなっていますが、主キーに対して主従の関係に位置する様なデータは見当たりません。（商品数・仕入年月日・仕入先IDはキーとして存在できるかはデータ特性から？と考えます）
結果、今回のサンプルデータではボイスコッド正規化手順は不要という判断になると思います。
ではボイスコッド正規化が必要なテーブルとは？となりますが、単純に言えば、第三正規化を経ても未だキーと主キーの主従関係、キーー＞主キーの主従関係が成立している様なテーブルデータになります。
以下の病院の診療科外来のサンプルデータの条件として、一人の医師が一つの診療科を担当します。
患者名診療科医師名東京太郎内科多摩一郎東京太郎外科岐阜次郎名古屋太郎内科多摩一郎沖縄次郎外科岐阜次郎大阪次郎消化器科愛知三郎大阪次郎泌尿科神奈川次郎
ボイスコッド正規化サンプル
第三正規化を経て、上記の様なテーブルが生成されたとします。
このテーブルでは主キーとして患者名・診療科を取れますが、医師名も診療科に対して主従関係を持っています。
従って、更にボイスコッド正規化を行うと以下の様な二つのテーブルに分割可能に思えます。（医師名と診療科を分離する必要が有る為）
患者名医師名東京太郎多摩一郎東京太郎岐阜次郎名古屋太郎多摩一郎沖縄次郎岐阜次郎大阪次郎愛知三郎大阪次郎神奈川次郎
ボイスコッド正規化サンプル正規化後１
診療科医師名内科多摩一郎外科岐阜次郎消化器科愛知三郎泌尿科神奈川次郎
ボイスコッド正規化サンプル正規化後２
尚、事前の条件の様に一医師＝一診療科の条件でしたが、病院の規模が大きくなった場合、一診療科＝複数医師になる可能性があり、テーブルの見直しが必要になりそうです。例としてはあまり良いとは言えないかもしれません。
皆さんは、WEBシステムを使われていると思いますが、背後でこの様に設計されたデータが動いているという事になりますが、大変さを少しは感じて頂けましたでしょうか？
講師の経験が、皆様のお役に立てれば幸いです。