- ベストアンサー
第３正規化について
- 第３正規化についての質問なのですが、理解できないので質問させて頂きます。
- "t_携帯"というテーブルがあり、[台数CD]フィールドの扱いがよく理解できなくて困っています。
- Aさんが携帯を１台所持している場合、Aさんは[台数CD]フィールド'1'を持ち、２台所持しているBさんは'1'と'2'を持ち、２台目以降の携帯情報が繰り返しとなるので第１正規化するのは分かるのですが、それ以降の第３正規化までの手順とマスタ分けがよく分かりません。
- matthew5
- お礼率88% (15/17)
- その他(データベース)
- 回答数3
- ありがとう数20
- みんなの回答 （3）
- 専門家の回答
質問者が選んだベストアンサー
＞「主キーにできるならば」というのはどういった意味合いなのでしょうか？ 型名にどういうデータが入るのかわからなかったからです。 私も携帯電話くらいは持っていますが、あまり機種に興味はないので・・・ さすがに同じキャリアでは別々の機種に同じ型名はつけないだろうと思いますが、ドコモとauなど別のキャリアで型名がかぶることがあるかどうかがわからなかったのです。 もし被る可能性があるなら、理屈の上では「社員CD＋型名＋製造番号」では一意にはならなくなるから主キーにはできないということです。（現実には別キャリアで型名が被ることがあっても製造番号まで一致する可能性は極めて低いので問題ないとは思いますが）
その他の回答 (2)
- sppla
- ベストアンサー率51% (185/360)
No1ですが追加です。 私の例では第３正規化の説明のために「（非キー項目の）型番が決まればメーカー名は決まる」という設定にしていますが、ご質問のテーブルでは第３正規化の手順が必要かどうかは分かりません。 「メーカー名」「型名」あたりの検索や集計の用途次第ではコード＋名称として外部のマスタ化した方がいいとは思いますが、単なる参考としてコメント的に扱うならそこまでする必要はないと思います。 また「台数CD」フィールドですが、これには“ある社員の何台目の携帯電話か？”という意味は持たせない方がよいでしょう。ただの同一社員CD内での各携帯を区別する記号的（数字そのものには意味がない）として扱った方がいいです。（レコード追加時は、フィールドサイズが十分あれば現在の最大値＋１を設定するとか、ストアドプロシージャ等で各社員CDでの最小の空き番号を探して設定するとかそんな感じです。もしくは社員CD＋型名＋製造番号を主キーにできるならばそちらがいいかもしれません。） 理由は、複数台の携帯を持っている社員に関しレコードの削除を行う場合に、例えば「台数CD」が３まである社員の１番目のレコードを削除するときに、他のレコードの「台数CD」を２→１、３→２に修正する手間をかけるか？という点です。 各社員の保有携帯台数の把握はSQLでCountを使えばいいでしょう。
補足
spplaさん、早速のご返事ありがとうございます。 先程、最初に頂いた回答に補足をつけさせて頂いたのですが、 "この投稿はサポートで内容を確認中です" となり(何かの番号がひっかかっている？)、表示されていませんでした。 > もしくは社員CD＋型名＋製造番号を主キーにできるならばそちらがいいかもしれません。 この説明ですが、こうするための理由は理解できたのですが、 「主キーにできるならば」というのはどういった意味合いなのでしょうか？
- sppla
- ベストアンサー率51% (185/360)
正規化はテーブルの各項目の意味を正しく把握していないとできませんので、ご質問のテーブルではなく私の方で用意したもので説明させていただきます。 ■テーブル「t_携帯」の項目名および項目内容。 社員CD：携帯を使用する社員の社員番号（各社員に対して一意なコード） 氏名：携帯を使用する社員の氏名。 性別：携帯を使用する社員の性別。 台数CD：各社員の持つ何台目の携帯電話機かを識別する番号。 型番：携帯電話の機種を示す型番。（auだとW62CAとかそういうやつです。） メーカー名：携帯電話機を製造したメーカーの名称。（型番が決まるとメーカー名を決まるものとする。） 製造番号：携帯電話の製造番号。（同一型番内では重複はない。） このテーブルは、社員CD＋台数CDで各レコードを一意に識別できるものとします。（つまり社員CD＋台数CDが主キーです。） ■正規化のおさらい。（おおざっぱに書いています） ・第１正規化：（行と列で表現する）テーブルの形にすること。 ・第２正規化：主キーの一部分に従属する項目を外に切りだす。 ・第３正規化：主キー以外の項目に従属する項目を外に切りだす。 ■以下正規化の説明 ・この例ではテーブルの形になっているのですでに第１正規形である。 ・主キーの一部分（社員CD）が決まれば「氏名」「性別」は決まるので、これらの項目を外部のマスタに持たせることにする。（第２正規化） ・主キー以外の項目である「型番」が決まれば「メーカー名」は決まるので、この項目を外部のマスタに持たせることにする。（第３正規化） ■結果的にできるテーブル 「t_携帯」 社員CD、台数CD、型番、製造番号 「t_社員マスタ」 社員CD、氏名、性別 「t_機種マスタ」 型番、メーカー名 以上です。
補足
spplaさん、早速のご返事ありがとうございます。 詳細に説明して頂き、とても理解することができました。 > このテーブルは、社員CD＋台数CDで各レコードを一意に識別できるものとします。 > （つまり社員CD＋台数CDが主キーです。） この部分は分かりました。 > ■結果的にできるテーブル > 「t_携帯」 > 社員CD、台数CD、型番、製造番号 結果的にできた「t_携帯」に値を入れたとすると 社員CD、台数CD、型番、製造番号 0001、1、W62CA、CA0001 0002、1、W62DA、DA0001 0002、2、W62CA、CA0002 0003、2、W62EA、CE0001 となったとしても(見難くてすいません)、社員CD＋台数CDの二つで 主キーとなるので、DBとしては特に問題はないわけですよね？ というのも、上記のように二つのフィールドを主キーとする概念が初めてでして・・・。 「t_社員マスタ」の主キーである社員CDが「t_携帯」の主キーの一部のみを参照しているので、 台数CDには特に外部参照がかからなくてもよいという解釈で宜しいのでしょうか？
お礼
何度も回答して頂き、ありがとうございました。 おかげさまでかなり理解することができました。 現在、ACCESSで携帯管理ができないかと上司から言われておりまして、 DB・ACCESS初心者ではありますが奮闘している最中です…。 複数台の携帯を所有する社員に関しては、社員CD+製造番号+型名でユニークになりそうなので、なんとか頑張ってみます。 ACCESSの機能であるとか、実際に値を入れたりする段階でたぶんまた分からなくなりそうですが、ご縁がありましたら懲りずに宜しくお願い致します。