2

doctor私のデータベースには、列があるベーステーブルがあります

Name, d_ID, Age, Gender, Contact_NO, Speciality, beg_Date, End_Date

テーブルを正規化したい。私は次のようにdoctorテーブルの依存関係を見つけました：

Name, d_ID ---> Age, gender, Speciality
d_ID----> Name, Contanct_NO, Beg_Date, End_Date

同様の構造を持つベーステーブルがさらにいくつかあります。

{d_ID}クロージャを計算したところ、とである2つの候補キーがあることがわかりました{Name,d_ID}。{d_ID}私は主キーと{Name,d_ID}副キーになることを選択しました。

私の質問は：

  1. 私のテーブルがすでに2NFにあるかどうか知りたいです。そうでない場合は、関係を分解する方法を教えてください。

  2. 、、、などの中間テーブルがpatient_recordあり ます。正規化を他のベーステーブルではなく中間テーブルに対してのみ実行する必要がある場合、混乱が生じます。ベーステーブルには列の一意の識別子しかないため、自動的に2NFに分類されるため、これを信じていますか？doctor idpatient idnurse idbed id (foreign key)

4

2 に答える 2

2

クロージャを計算したところ、{d_ID}と{Name、d_ID}の2つの候補キーがあることがわかりました（間違っている場合は修正してください）。

いいえ。定義上、候補キーは既約です。d_IDが候補キーの場合、{Name、d_ID}は候補キーではありません。{Name、d_ID}は還元可能であるため、候補キーではありません。属性「名前」を削除すると、候補キー（d_ID）が得られます。

1）テーブルがすでに2NFにあるかどうかを知りたい。そうでない場合は、関係を分解する方法を教えてください。

この場合、言うのは本当に難しいです。医師ごとに一意のID番号がありますが、あなたの場合、それは行を識別するためだけに使用され、医師には使用されません。あなたのテーブルはこの種のデータを許可します。

d_ID   Name         Age  Gender  Contact_NO     Speciality   beg_Date    End_Date
--
117    John Smith   45   M       123-456-7890   Cardio       2013-01-01  2015-12-31
199    John Smith   45   M       123-456-7890   Cardio       2013-01-01  2015-12-31
234    John Smith   45   M       123-456-7890   Cardio       2013-01-01  2015-12-31

医者は何人いますか？（私はデータを作成したので、正しい答えを知っているのは私だけです。）2つあります。234は117の偶発的な複製です。199は117とは別の医師です。彼らが両方とも同じ病院の心臓専門医であり、彼らの病院の特権が同じ日に開始および停止するのは偶然の一致です。

これが、行を識別することと医師を識別することの違いです。

それが2NFにあるかどうかは、まだ識別されていない可能性のある他の機能依存性に依存します。これらのいくつかがあるかもしれません。

2）医師ID、患者ID、看護師ID、ベッドID（外部キー）などを含むpatient_recordという中間テーブルがあります。正規化を中間テーブルに対してのみ実行する必要があり、他のベーステーブルに対しては実行する必要がない場合、私は混乱します。

正規化は通常、すべてのテーブルに対して行われます。

ベーステーブルには列の一意の識別子しかないため、自動的に2NFに分類されますか？

いいえ、そうではありません。明確にするために、2NFについて混乱しているデータベースの正規化の学習に対する私の答えを参照してください。

行を識別し、物を識別する

それは微妙な点ですが、それは本当に、本当に重要です。

3つの候補キーを持つ正常に動作するテーブルを見てみましょう。

create table chemical_elements (
  element_name varchar(35) not null unique,
  symbol varchar(3) not null unique,
  atomic_number integer not null unique
);

そのテーブルの3つの属性はすべて宣言されていますnot null unique。これは、候補キーを識別するためのSQLイディオムです。少なくとも1つの候補キーがとして宣言されていないことに不快感を感じる場合は、1primary keyつだけ選択してください。どちらでも構いません。

insert into chemical_elements
(atomic_number, element_name, symbol)
values
(1, 'Hydrogen', 'H'),
(2, 'Helium', 'He'),
(3, 'Lithium', 'Li'),
(4, 'Beryllium', 'Be'),
[snip]
(116, 'Ununhexium', 'Uuh'),
(117, 'Ununseptium', 'Uus'),
(118, 'Ununoctium', 'Uuo');

3つの候補キー（atomic_number、element_name、symbol）はそれぞれ、実世界の要素を明確に識別します。「ベリリウムの原子番号は何ですか？」という質問に対する考えられる答えは1つだけです。

今、医者のテーブルを見てください。「「ジョン・スミス」という名前の医師のID番号は何ですか？」という質問に対する考えられる答えは複数あります。実際、 234と117は同じ人を指しているため、まったく同じ医師に対して複数の可能な答えがあります。

データは両方の医師で同じであるため、これ以上列を含めることは役に立ちません。「名前が「ジョン・スミス」、電話番号が123-456-7890、専門が「カーディオ」である45歳の男性医師のID番号は何ですか」という質問に対する複数の回答を得ることができます。 ？」

この2人の医師の予約をしている人を見つけると、おそらく彼らのID番号が黄色の付箋に書かれていて、モニターに貼り付いていることに気付くでしょう。

  • ブラッド・ピット（！）、ID117のように見えるジョン・スミス博士。
  • 他のジョン・スミス博士、ID199。

各ID番号はデータベース内の行を明確に識別しますが、各ID番号は医師を明確に識別しません。ID 117はジョンスミスという名前の医師を識別しますが、両方のジョンスミスがあなたの前に立っている場合、どちらがID番号117に属しているかを判断することはできません。ブラッド・ピットがどのように見えるかを知っていましたが、その情報はデータベースにありません。）

これはあなたの質問と何の関係がありますか？

正規化は機能依存性に基づいています。「機能依存性」について話すとき、私たちはどのような「機能」について話しているのですか？恒等関数について話している。

于 2013-03-26T02:13:34.900 に答える
1

正規化プロセスは次のとおりです。

  1. 関係のすべての候補キーを特定します。
  2. 関係のすべての機能依存性を識別します。
  3. 関数従属性の決定要因を調べます。決定要因が候補キーでない場合、関係は十分に形成されていません。それから

  4. i）関数従属性の列を独自の新しい関係に配置します。

    ii）関数従属性の決定要因を新しい関係の主キーにします。

    iii）元の関係の外部キーとして行列式のコピーを残します。

  5. 元の関係と新しい関係の間に参照整合性制約を作成します。
于 2013-03-25T09:41:20.740 に答える