私はデータベース設計に興味があり、現在は対応する文献を読んでいます。 この本を通して、私は私に不確かさを感じさせる奇妙な例に直面しています。 我々は複合主キー（StudentID、活動を）持っている。この表には関係主キーと多値属性を持つ表を設計するにはどうすればよいですか？
があります。今、私たちはSTUDENT_ACTIVITYを見ている場合
、：著者は他の二つのリレーションにこの関係を分割することを提案して、 - しかし、ActivityFeeは、テーブルのキー（> ActivityFee活動）に部分的に依存していますアクティビティは外部キーになり、リレーションにはまだ複合プライマリキーがあります。
列全体が複合主キーを定義するテーブルがあります。それは問題ありませんか？
そうでない場合は、どうすればよいですか？
可能性のあるデータの異常を排除するために、複数値の属性（ここでのアクティビティ）を処理する良い方法はありますか？
複合候補キーに問題はありません。 （候補キーに関して言及していない場合、つまり、候補キーが1つしかない場合以外のプライマリキーについて話している場合は、新しい参照を取得してください）。
あなたは良いデザインと悪いデザインを教えてください。関係について気づいたすべての不動産について、「悪い」と心配する必要はありません。現在取り組んでいる「良い」の種類は、「標準化」によって与えられたものです。
"アクティビティ"は "複数値属性"ではありません。 「多値」属性は、非リレーショナル概念です。この用語は、何らかの形で（決して説明されていない）「行」ごとに複数の項目を持つ非リレーショナル「表」の「属性」、または「行」に複数の項目が含まれているリレーショナル表の列（決して説明されていない）複数の類似部分（set、list、bag、tableなど）を持つ値は、文字列&の数値、または複数の値を持つリレーショナル表の列何らかの形で（決して説明されていない）異なる部分（レコード、タプルなど）は、例えば日付には適用されません。 （時には、似たような名前と値を持つ複数の属性を意味するために誤って適用されることもありますが、元の名前ごとに1つの属性で置き換えてください）。同様に誤用/濫用された用語の反意語として使用される。"atomic"。
同じ値（または値）のサブブロウが列またはテーブルに複数回表示されることは、それ自体が良いことも悪いこともありません。繰り返しますが、あなたのリファレンスは良いデザインが何かを教えてくれます。
複合キーのみで構成される表は、ビジネス要件に一致する場合は完全です。
アクティビティは複数値属性ではありません。各タプルのアクティビティには1つの値があります。