1

正規化のいくつかの例を読んでいますが、理解できないものに出くわしました。

例の Web サイトは次のとおりです: http://cisnet.baruch.cuny.edu/holowczak/classes/3400/normalization/#allinone

わからない部分は「第三正規形」

私の頭の中では、推移的な依存関係がEMPLOYEE_OFFICE_PHONE (Name, Office, Floor, Phone)次のようName->->Office|Floorに見えます。Name->->Office|Phone

著者は、表EMPLOYEE_OFFICE_PHONE (Name, Office, Floor, Phone)をEMPLOYEE_OFFICE (Name, Office, Floor)とに分割します。EMPLOYEE_PHONE (Office, Phone)

最初の私の判断から、私はまだ推移的な依存関係を見ているName->->Office|Floorので、なぜそれが 3NF にあるのかわかりません。に推移的な依存関係があると述べたのは間違っていましたName->->Office|Floorか?

推移性の理由: 機能依存関係のリストは次のとおりです。

  1. 名前 -> オフィス
  2. 名前 -> フロア
  3. 名前 -> 電話番号
  4. オフィス -> 電話
  5. オフィス -> フロア (これは間違っていますか? また、その理由は?

ありがとうございます。

4

3 に答える 3

1

5) ここでネーミングスキームを仮定します ... オフィス 4xx は 4 階にある必要があります ... 5xx は 5 階にある必要があります ... そのようなスキームが存在する場合、依存関係を持つことができます ... これが続く限り仕様の一部ではありません...いいえ。5はゲーム外です...

于 2011-05-31T20:17:42.557 に答える
0 
1. Name -> Office
2. Name -> Floor
3. Name -> Phone
4. Office -> Phone
5. Office -> Floor (Is this the incorrect one? and why?

（1）あなたと著者、そして私は、Name->Officeに同意します。

（2）あなたと作者は、Name->Floorに同意します。これはサンプルデータのみに基づいて当てはまりますが、Office->Floorにも当てはまります。「オフィスが空の場合でも、そのオフィスが何階にあるかはわかりますか？」という質問をして、この種の問題を調査します。（はい）

これらのことは、推移的な依存関係、[名前]-> [Office]、および[Office]->[Floor]があることを示しています。だから私はあなたとこれについての作者に同意しません。

（3）「名前」->「電話」と言います。著者はOffice->Phoneと言います。著者はまた、「各オフィスには正確に1つの電話番号がある」と述べています。つまり、Officeの値が1つだとすると、Phoneの値は1つだけです。そして、Nameに1つの値が与えられると、Phoneには1つだけの値がわかります。「別のオフィスに引っ越した場合、私の電話番号は私をフォローしますか？」と尋ねることで、この問題を調査します。含まれている場合は、[名前]->[電話]を選択します。そうでない場合は、[Office]->[電話]を選択します。

ここにはその質問に答えるのに十分な情報がありません。私はこれら2つの方法のそれぞれで機能するオフィスで働いていたので、実際の経験もあまり役に立ちません。この場合、正規化の例についてはあまりよく考えられていないと思いますが、著者の側に立つ必要があります。

（4）これは実際には上記の（3）の単なる拡張です。

（5）上記（2）を参照してください。これは命名スキームとは何の関係もありません。また、5xxの番号が付けられたオフィスが5階にあると想定する必要はありません。関連する唯一の質問は次のとおりです。Officeに1つの値がある場合、Floorには1つだけの値がありますか？（はい）「1つのオフィスを複数のフロアに配置できますか？」と尋ねることで、この問題を調査することができます。（現実の世界では、それはリモートで可能です。しかし、サンプルデータはその可能性をサポートしていません。）

サンプルデータのみに基づくいくつかの追加のFD。

Phone->Office
Phone->Floor
Office->Name
于 2011-06-01T01:10:21.720 に答える