10

ここで私はこれを見つけました：

定義:データベース テーブルの決定要因は、同じ行の他の属性に割り当てられた値を決定するために使用できる任意の属性です。

例:属性 employee_id、first_name、last_name、および date_of_birth を持つテーブルを考えてみましょう。この場合、フィールド employee_id によって残りの 3 つのフィールドが決まります。会社には同じ名字または姓、あるいはその両方の従業員が複数いる可能性があるため、name フィールドは employee_id を決定しません。同様に、複数の従業員が同じ誕生日を共有している可能性があるため、DOB フィールドは employee_id または name フィールドを決定しません。

この定義は候補キーにも当てはまるのではないでしょうか?

4

3 に答える 3

19

私の理解では、テーブルが完全に正規化されていない場合、行列式は候補キーにならない可能性があります。実際、行列式という言葉は、非正規データをより有用な正規化された形式に変換するプロセスを説明するときに使用されます。

次の (明らかに非正規の) テーブルを考えてみましょう。

CREATE TABLE US_Address (
  AddressID int,
  Streetline varchar(80),
  City varchar(80),
  State char(2),
  ZIP char(5),
  StateName varchar(80),
  StateTax DECIMAL(5,2)
)

State は StateName と StateTax の決定要因ですが、行の候補キーではありません。したがって、適切に正規化すると、StateName と StateTax が US_Address テーブルから States テーブルに移動します。

詳しくはこちらをご覧ください。

于 2013-05-23T06:29:55.347 に答える
9

TL;DRいいえ、「行列式」と「候補キー」は同じ概念ではありません。決定要因はFDです。CK はテーブルの CK です。また、CK はそのテーブルの (FD の) 決定要因であるとずさんに言うこともできます。

次のすべての用語/概念は、テーブルの値と変数に対して並行して定義されています。テーブル変数には、特定のビジネス/アプリケーションで発生する可能性のあるすべてのテーブル値が存在する場合、FD (関数の依存関係)、行列式、スーパーキー、CK (候補キー)、または PK (主キー) (変数の意味で) のインスタンスがあります。そのインスタンスがあります（テーブルの意味で）。

列 X と Y のセットの場合、X -> Yと書くことができます。X は決定要素/決定集合であり、Y は機能依存( FD ) X -> Yの/決定された集合であると言います。

Xは機能的に Y を決定し、YはXによって機能的に決定されると言います。 X が Y のスーパーセットである場合、X -> Y は自明であると言います。

Xの各サブ行値が Y の 1 つの特定のサブ行値でのみ表示される場合、X -> Yがテーブル T で成立すると言います。または、X -> Y がTの / 内の FD であると言います。Xが何らかの FD の行列式である場合テーブル T では、X は T の / の行列式であると言います。テーブルのすべての自明な FD がその中に保持されます。

テーブル Tのスーパーキーは、すべての列を機能的に決定する一連の列です。候補キー( CK ) は、それより小さいスーパーキーを含まないスーパーキーです。1 つの CK を主キー( PK ) として選択し、他の CK を代替キー( AKs )と呼ぶことができます。列がCK にある場合、その列は素数です。

行列式はFD の場合もあれば、テーブル (保持する FD) の場合もあることに注意してください。すべての CK は、そのテーブルの決定要因です。(ただし、テーブルでは、列のすべてのセットが決定要因です。それ自体で、自明です。同様に、すべての列です。)

(これらの定義は正規化に依存しません。テーブルの FD と CK は正規化に使用されます。テーブルに保持されている非自明な FD のすべての行列式がスーパーキーである場合、テーブルは BCNF にあります。)

SQL テーブルは関係ではなく、SQL 演算子は関係/数学の対応物ではありません。とりわけ、SQL には重複行、NULL、および一種の 3 値ロジックがあります。しかし、用語を借用してそれらに SQL の意味を与えることはできますが、それらの意味を他の RM 定義または定理に置き換えるだけで、意味のあるまたは真の何かを得ることはできません。したがって、SQL 設計をリレーショナル設計に変換し、リレーショナル概念を適用してから、SQL に戻す必要があります。変換、適用、および元に戻すとどうなるかがわかっているため、特定のことを SQL で直接実行できる特殊なケースがあります。

于 2015-12-10T00:23:09.247 に答える
6
  • 主キーまたは任意の候補キーも決定要因ですが、その逆は当てはまりません。
  • 行列式は、行内の 1 つ以上の属性を一意に決定できます。
  • 候補キーは行全体を一意に決定できます。

hereから例を挙げて、次の列を持つテーブルがあるとします。

顧客番号、名前、住所、クレジット、営業担当者番号、営業担当者名

Sales Rep #が を一意に決定できるとしましょうSales Rep Name。したがって、Sales Rep #はこのテーブルの決定要因ですSales Rep Nameが、このテーブルの候補キーではありません。

于 2015-12-03T06:17:15.583 に答える