- ベストアンサー
候補キーの求め方
データベースを独学で勉強しているのですが、 候補キーの求め方がわからなくて迷っています。 リレーションスキーマ(社員名、企画名、タイプ)とあって 関数従属性:社員名→企画名、企画名→タイプ があるとする。 この場合の候補キーは社員名となるらしいのですが理由が分かりません。 上記の2つの関数従属性は自明でなく、 自明でない関数従属性の左辺と右辺の和集合が互いに素でない。 とまではわかるのですが、そこから先がわかりません。 解答よろしくお願いします。
- みんなの回答 (1)
- 専門家の回答
質問者が選んだベストアンサー
>左辺と右辺の和集合が互いに素でない こんなこと考えながら仕事してるプロは まず、いないと思います。 要素のうち、「タイプ」が曖昧ですが、 これは置いておきます。 業務内容から見るに、一つの企画に複数の 社員が従事している(社員は企画に属する) という場合、より小さく(細かく)分類 出来る方が効果的です。 何故かと言うと、企画を限定しても社員が 特定できないのに対し、社員を限定すると、 企画も決まるからです。 以下のデータモデルを想定してみます。 企画A+社員1 企画A+社員2 ここで、「企画A」を指定してもデータは一意に なりません(上の行か下の行かハッキリしない)。 しかし、「社員2」を指定すると、データが一意に なります。 但し、従属性が反対なら企画がキー候補に なります。 実業務では一人が複数の企画に従事したり、 参加/脱退を行うので、社員と企画は別々の テーブルとし、社員、企画、参入/脱退、日付などを 記録したテーブルを設計する方が普通です。