正規化：データベース設計の基本：別件その１
REV１２
ブログ投稿しています。複数画像付き等最終版は此方から、ご覧ください。
一応、講師が独学で正規化を学んだ時や、現在のインターネット上で散見される説明を参考に前回までの投稿を行いましたが、皆さんは何か違和感を感じられませんでしたでしょうか？
講師は正規化を全て否定しているわけではありません。
正規化の良い所もありますが、先ずは一つ、重要な点が有ります。
前々回の投稿時、正規化を使用する理由にインターネット等で説明されている正規化されていないとデータベースの整合性の問題が出てくるとの説明をしたと思います。
皆さんは、この説明をどう思われるでしょうか？
随分前に講師がWEBシステムを自ら提案し、UIやその背景で蓄積するデータを設計しました。
その際、独学で正規化を学びましたが、違和感が最初から大いにありました。
それは、この正規化を使用する理由が、正規化をしないとデータの整合性が取れなくなる事があるという説明です。
そうです、これは、最初からデータベースが正しく構築できない、即ちWEBシステムにバグが有るという事を想定しているのです。
何故、そう言い切れるかというと、講師はソフトウェアエンジニアでありプログラマーでもあります。
WEBのシステムも結局プログラムの一種であり、作成時に最低限しないといけない作業が有ります。
それは、通常の使用で問題が起きないかを検証するテストプロセスを経るという事です。
その際、通常の使用というのは、前回の投稿時の前提である、住所等を含めたユーザ登録に置き換えて説明します。
考えなければいけないシナリオとして、当然デフォルトで以下のようなものがあり得ます。
登録：所謂、新規のユーザ登録時を指します。画面上で通常は”登録”のボタンを押下すると思います。その際裏では”INSERT”コマンドに連なるSQL文が他の画面選択肢や入力文字列から自動生成され、サーバに向けて実行されます。
変更：住所が変更になった場合や、年齢が上がった場合等必要に応じて、修正が必要になります。その際は”UPDATE”コマンドに続く変更箇所の情報や、変更文字列が自動的に収集・生成され、サーバに向けて発行されます。
削除：登録したユーザが定年退職したり、転職したりした場合、該当ユーザの情報は以降、追加や変更は無い為、ユーザ情報テーブルから該当ユーザＩＤを削除します。削除する範囲はユーザ情報テーブルのみから削除する方法と登録された過去のデータを全て削除するなど、扱っているデータの特性や運用指針などもあり、変わると思いますが、個人情報保護法の関連もあり、全削除の機能は必須だと考えます。
従って、前回投稿で使用した、削除などでデータベースが整合性が取れなくなるという前提はプログラマー的には本来あり得ない想定なのです。
要するに、追加・変更・削除程度のノーマルなシナリオで整合性が取れなくなるデータを作ってしまうWEBシステムというのは不具合が有ると認識されるレベルという事です。
講師にとっては、正規化を知っていようが、正規化を知らなかろうが、追加・変更・削除を実行しただけで内容がおかしくなる・辻褄が合わなくなる様なデータが生成される様なシステムは本来作りませんしリリース・公開しません。
もし、データベースの設計をされる方がプログラマー・ソフトウェアエンジニアで無ければ、この様な観点に気が付かないのかもしれませんが、プログラミングが行える方は、正規化を使用する理由に動作後のデータの整合性が挙げられているときは、違和感を大いに感じて頂きたいと思います。
講師が正規化に？を感じたのは先ずこのポイントが有ります。勿論、違和感を感じたのはこの点だけではありません。
他のポイントについては正規化を実際に行う手順をご説明した段階で、指摘したいと思います。
今回の説明で、皆さんにも、一部の方々が金科玉条の様に扱われている正規化のおかしな点を少しは感じて頂けましたでしょうか？
講師の経験が、皆様のお役に立てれば幸いです。