13

第 1 正規形に従うために避けるべきことの 1 つは、グループの繰り返しです。代わりに：

    CustID  Name  Address       Phone1      Phone2       Phone3

     102    Jerry  234 East..   555-2342   555-9854     555-2986

2 つ目の電話番号テーブルを作成してから、結合すると次のようになります。

CustID  Name     Address       Phone

102 Jerry    234 East..   555-2342
102 Jerry    234 East..   555-9854
102 Jerry    234 East..   555-2986

場合によっては、もう少しあいまいで、列ヘッダーのグループがいつ修飾されるかを判断するのが難しい場合があります。たとえば、現時点で、すべてのハードウェアで 2 つのテストを実行しているとします。そして、最初の DB 設計では、最も水平的なアプローチが得られます。

デザイン1

SN     Test1_Max   Test1_Min    Test1_Mean  Test2_Max   Test2_Min    Test2_Mean
2093      23          2            15         54          -24           45

明らかに、これは反復グループであり、("Parts" と "Tests" の間の結合で) 次のように簡単に表すことができます。

デザイン 2

SN     Test      Max    Min    Mean     
2093    1        23     2      15       
2093    2        54     -24     45

ただし、さらに垂直に進むこともできます。

デザイン3

SN     Test    Statistic    Value
2093    1        Max          23
2093    1        Min          2
2093    1        Mean         15       
2093    2        Max          54
2093    2        Min         -24
2093    2        Mean         45

設計 3 は必要ですか? どのように垂直にするかをどのように決定しますか? 設計 2 と設計 3 の長所と短所は何ですか? 実際にテーブル構造を変更せずに新しい統計を簡単に追加できるため、設計 3 には利点があり、両方とも SQL で簡単に選択または結合できるようです。

しかし、垂直になればなるほど良いと言う前に、もっとあいまいな場合があります。お気に入り：

デザイン 4

SN      AverageCurrent (mA)    BatteryCapacity (mA)  
2093          200                    540

代わりに次のようになります。

デザイン 5

SN      mA_Measuremnt       Value
2093    AverageCurrent      200 
2093    BatteryCapacity     540

両方の属性は同じドメイン (mA) にありますが、コンポーネントに関しては非常に異なるものを表しています。この場合、厳密には繰り返しグループではないため、デザイン 4 の方が優れていますか? 私が探しているのは、それをより多くのテーブルに分割して、より垂直にする時期を知るためのいくつかの基準だと思います。

この途方もなく長い質問を要約すると、繰り返しグループがまったく同じドメインであり、まったく同じ意味を持つ場合にのみ、繰り返しグループを削除して正規化する必要がありますか? . その場合、実際には電話の例と、おそらく設計 1 の 2 つのテストだけがこの基準を満たしています。デザイン 3 とデザイン 5 にはデザイン上の利点があるように見えますが、デザイン 3 の統計は厳密に言えば異なる意味を持ち、AverageCurrent と BatteryCapacity はデザイン 5 では明らかに異なる意味を持ちます。

4

8 に答える 8

7

設計 2 と設計 4 は、結果が常に存在するとは限らない (設計 1 の NULL とも呼ばれる) 場合に最適な方法です。それらが常に使用される場合は、最初のデザインで問題ありません。

SQL でのグループの繰り返しは、たとえば Phone_Number に "123-444-4444,123-333-3334" などの追加値が詰め込まれた列がある場合に実際に発生すると思います。

いずれにせよ、後の設計は最適ではありません。それを最終レベルに進めて、「1 つの真のルックアップ テーブル」http://www.dbazine.com/ofinterest/oi-articles/celko22またはエンティティ属性値http: //tonyandrews.blogspot.com/2004/10/otlt-and-eav-two-big-design-mistakes.html

http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:10678084117056

いずれにせよ、ほとんどの場合、それは悪いことです。それらは共通のデータ型/ドメインを共有する場合がありますが、意味は異なります。したがって、それらは個別の属性のままにする必要があります (maxtemp、mintemp など)。

于 2009-06-04T15:42:54.003 に答える
1

私は 1NF を「繰り返しグループがない」のではなく、「すべての行は同じ長さでなければならない」と考えています (そして教えられました)。そのビューを使用すると、次のことから少し簡単に決定を下すことができます。

設計 1 では、両方のテストが常に存在しますか? もしそうなら、それは本当に繰り返しグループではありません。すべての平均は常に計画 2 に存在しますか? 特定の行に多く (または少なく) ありますか?

設計 4 では、両方の値が常に存在しますか? もしそうなら、それは結構です。そうでない場合は、デザイン 5 を使用する必要があります。

于 2009-06-04T15:43:39.477 に答える
1

設計は、ユース ケース シナリオと予想されるクエリの種類によって決定する必要があります。多くの読み取り、書き込み、または多くの更新を行う予定ですか? 受験者のテスト データ全体を取得したいですか、それとも最高のテストか何かだけを取得したいですか。最も頻繁に実行するクエリは何ですか?

デザイン1

SN     Test1_Max   Test1_Min    Test1_Mean  Test2_Max   Test2_Min    Test2_Mean
2093      23          2            15         54          -24           45

性能的にはこれが一番です。JOIN は必要ありません。フィールドの数が決定論的で恣意的ではない場合 (たとえば、各人が持つテスト スコアは最大で 2 つ)、1 人に 3 つ以上のテスト スコアを関連付けることを決定した場合は、より厳密ではありますが、これはより適切です。SNuniqueは行ごとにここにあるため、データベース エンジンは一致を見つけるとすぐに戻ることができ、これがパフォーマンスが向上するもう 1 つの理由です。

デザイン 2

SN     Test      Max    Min    Mean     
2093    1        23     2      15       
2093    2        54     -24     45

これはSN 2093、プロファイルに N 個のテストを含めることができる場合に便利です。同様に、テスト数が 10m の場合も、この設計は 30 列よりも優れています。各クエリと比較は非常に重くなります。2093これは、アプリケーションが学生にとって最高のパフォーマンスのテストを取得するクエリを必要とする場合や、テストのスコアに関する分析とレポートを行いたい場合にも役立ちます。これは、以前のものよりもわずかに遅いですが、より柔軟です。おそらくテストの統計に興味があり、学生はそれぞれ2つ以上のテストを受ける可能性があるという予感があるので、私はこれを好みます.

デザイン3

SN     Test    Statistic    Value
2093    1        Max          23
2093    1        Min          2
2093    1        Mean         15       
2093    2        Max          54
2093    2        Min         -24
2093    2        Mean         45

これは、クエリが何よりも値に関心がある場合に役立ちます。たとえば、80 より大きい値の数に関心がある場合、これは高速です。あなたのシナリオでは、これは意味がありません。あまりにも多くの自己結合を行うことになります。読み込みが遅くなります！SN 2093ただし、 andの最大スコアをすばやく更新できるため、書き込みはおそらく高速になりますTest 2(文字列の比較にはコストがかかる可能性があるため、Statistic 列が文字列ではなく列挙型であると仮定します)。

デザイン 4

SN      AverageCurrent (mA)    BatteryCapacity (mA)  
2093          200                    540

デザイン 5

SN      mA_Measuremnt       Value
2093    AverageCurrent      200 
2093    BatteryCapacity     540

同じ引数が適用されます。それは、読み取りまたは書き込みのどちらを最適化するかによって異なりますか? たとえば、Web アプリケーションの場合、問題なく使用できる場合は、デザイン 1 を好みます。たとえば、通常、ユーザーが持つ電話番号は最大で 3 つだけであることがわかっているため、それぞれをユーザー列内のフィールドにして、 JOIN は避けてください。書き込みでは一部のフィールドを null に設定する必要がありますが、読み取りは高速です。

于 2009-06-04T16:02:51.830 に答える
1

グループの繰り返しに関するルールは次のとおりです。機能的に依存しているのは何ですか?

統計値が SN、テスト、および統計名に機能的に依存している場合、3 つのキー要素と 1 つの値要素があります。 ( SN, Test, Statistic -> Value )

この特定のケース -- 集計データ (平均、合計、最小、最大) -- では、アトミック オブジェクトを扱っているのではなく、集計を扱っているため、あいまいさがあります。厳密に言えば、集計を保存するのではなく、計算する必要があります。(はい、それが非現実的であることはわかっていますが、それがリレーショナル理論です。)

他のケースでは、繰り返しグループのキーと値は通常明らかです。ただし、この場合、派生データを保存しているため、暗い境界にいます。

例として、データ ウェアハウスの設計に従って、より実用的なテストを見つけます。

もう一方のキーでスライス アンド ダイスしますか?

統計的事実は、3 つの次元 (SN、検定、統計) で囲まれた点と考えてください。これは有効ですか？(要約データでは、多くの場合あいまいです。)

代わりに、保持すべき詳細データを見てみましょう: SN、テスト、スコア。明らかに 2 つのディメンション (SN、テスト) と、これら 2 つのディメンションの交点に 1 つのメジャー (スコア) があります。いずれかのディメンション (SN またはテスト) を使用して、この詳細データから任意の数の統計を導き出すことができます。

バッテリの例では、より一般的なリレーショナル データベースではなく、EAV データベースとして作成することをお勧めします。測定値 (AvergaeCurrent と BatteryCapacity) から、Entity-Attribute-Valueデータベース設計を使用する十分な理由が得られます。

すべての関係設計は、より長い関係と EAV トリプルの間の緊張であることに注意してください。すべてを属性キーとして常にラベル付けし、EAV 設計を使用できるため、「これがキーかどうか」と「これが列かどうか」のバランスを取る必要があります。

于 2009-06-04T15:55:34.267 に答える
0

可変長の場合は、繰り返しグループを別々のテーブルにのみ移動することをお勧めします。Phone1、Phone2、Phone3 しかない場合は、それらを分離する必要はありません。それ以外の場合、繰り返しの数が異なる場合は、別のテーブルの方が優れたデザインです。

また、まったく同じドメインと意味の概念は、抽象化のレベルに依存するため、あまり直感的ではありません. Phone1 は Phone2 とまったく同じではありませんが、どちらも電話番号です。テーブル AddressDetails を作成し、そこに電話番号を移動することもできます。名前、通り、市区町村も同様です。これらはすべて住所の詳細です。一般的なキーと値のペアと専用の列の間の方法を見つける必要があります。

于 2009-06-04T15:44:45.267 に答える
0

「テスト」が最大値、最小値、平均値しか持たないことが確実な場合 -> 設計 2 を使用します。ただし、将来新しい「統計値」が存在する可能性がある場合は、デザイン3を使用。

への答え:

繰り返しグループがまったく同じドメインであり、まったく同じ意味を持つ場合にのみ、繰り返しグループを削除して正規化する必要がありますか?

多くの本では、これらの正規形は厳密に定義されているように見えますが、そうではありません。自分のアプリケーションで何が最善の解決策であるかを確認する必要があります... 過度に正規化することは、常に最善の解決策とは限りません。特に、常にすべてのデータを結合し直すことがわかっている場合はなおさらです。

于 2009-06-04T15:36:11.163 に答える
0

CustID に PK がある場合、設計 1 は実際には 1NF にあります。PK 以外に依存するデータがない場合、3NF にある可能性があります。たとえば、Phone1 は他の CustID に対して繰り返されません。

解決しようとしているビジネス ケースがなければ、モデルを決定することはできません。したがって、設計 1 は完全に有効な論理モデルである可能性があります。

于 2009-06-04T15:51:37.713 に答える