備忘録28〜FileMaker ER図〜正規化・・・

経験も大切という事で・・・一人でもんもんと考えております。月会費管理とかお問い合わせとか色々、周囲で必要そうなものを題材にER図を書いています・・・

データベースの正規化・・・マスターブックを読んでなんとなく理解はしたものの完全ではない。

実際に、ER図を正規化を考慮しながら書く練習をしています。正規化の段階や内容をアウトプットしつつ理解を深めようと思います。

正規化の段階？

マスターブックによると・・・

正規化とは

簡単に言えば、項目を一定のルールに従って整理整頓し、必要に応じてひとかたまりに分け、それ らを関連付けることです。

この作業の目的は、データを効率良く管理できるようにすることです。

大原則があります。この原則に従うと、わかりやすく作業できます。

・ One Fact In One Place（1つの場所に 1つの事実） 

なかなかにムズカシイことをさらっと書いています。

１テーブルに１つのデータと見るべきなのか？

次の段階を見てみよう・・・

段階としては

＜はじめの正規化＞ ・ 繰り返す属性は別のエンティティにする

＜ 2 番目の正規化＞ ・ 主キーに部分的に従属する属性は別のエンティティにする

＜ 3 番目の正規化＞ ・ 主キーに従属しない属性は別のエンティティにする 

はじめの正規化の部分から、順番に見ていく。

はじめの正規化

・ 繰り返す属性は別のエンティティにする

要件定義の時にリストアップした項目を見ながら、繰り返す項目を分離します。

• 保護者氏名
• 郵便番号
• 住所
• 電話番号
• 年会費
• 月会費
• 子供名
• スクールクラス（年齢別のクラス分け）
• 子供生年月日
• 子供年齢

まだ、あるんですが・・・一旦ここまでとして

子供関連（名前・生年月日・年齢）については、兄弟がいる場合も想定すると繰り返す項目になるので

別にすべき項目となります。

子供に紐づくであろう「スクールクラス」も子供関連に加えておきます。

会費部分も年更新と思われる項目と月単位の項目があるので、それぞれで分離します。

多分、これで第１段階はいいと思う・・・不安

2 番目の正規化

主キーに部分的に従属する属性は別のエンティティにする

・・・主キーって

主キー（プライマリキー = primary key）

リレーショナルデータベースでは、テーブルから他のテーブルのある1 つのレコードを識別できるように設計します。

そのために作成されるのが「主キー」です。

Primary Key とも呼ばれます。主キーは1 レコードごとにデータベースが自動採番するユニークな数字にすることをお勧めします。

また、主キーの内容をユーザが変更できないようにします。

なお、主キーは「id」という名前の場合があります。

キーのことを「識別子＝ identifier」と呼ぶことがあるからです。

※ ユニークとは一意、つまり、唯一のという意味です。 

レコードを識別可能にするためのキー（ID）を作れとかいてある。

外部キーなるものも必要だ

外部キー（フォーリンキー = foreign key） 他のテーブルの主キーを保存するためのフィールドをつくります。

「外部キー」と呼びます。 Foreign Key とも呼ばれます。

原則として、外部キーから見た主キーは常に1 つです。

1 対多では「多」側のエンティティに『「1」側の主キーを外部キーとして持つレコード』が作成されることになります。 

会費のところは、まだ固まっていませんが、子供の所属するクラスで月会費が変更になる予定なので一旦この状態です。

保護者に請求するときは、兄弟分合計する必要が出てくると思うので、別で請求用のテーブルが必要なのかも・・・

このような感じで、分離したものに主キーの割り当てを行い、外部キーの設定を行います。

3 番目の正規化

主キーに従属しない属性は別のエンティティにする 

なかなか、ムズカシイですね。

今回のリストアップ分だと・・・・

スクールクラスを別にして、「スクールクラスマスタ」にした方がいいかもしれません。

クラス別の年会費・月会費などをマスターにした方が便利そうです。

やっぱり、請求はまとめた方がいいような気もするので「請求管理」として別にした方が、データ上は正しいのかも・・・

今日のまとめ！

正規化しすぎない・ルールは絶対ではないと、この後に書いてありました。

なんとなく理解はできるんですが、じゃあどこまで別のエンティティにすべきか、これはルールを無視して置いておくとか・・・

考え出すとドツボにハマってしまいます。

それも含めて、経験が必要なのですが・・・