2

ええと、今日それについて聞いたばかりですが、よくわかりません。そのため、日付列を含むトランザクション テーブルは必要ありません (同じ日に複数のトランザクションが発生する可能性があるため) が、トランザクションと日付列が必要です。日付にはトランザクションへの FK があります。それでは、日付の代わりに FK を繰り返します。

例: ブローカーはいつでも取引を行うことができます。(その後、トランザクションはブローカーと日付の情報を保持する必要があります)。

4

5 に答える 5

1

一般に、スカラー値 (日付、数値など) の正規化はやり過ぎです。値が繰り返されるからといって、値を正規化する必要があるわけではありません。行の主キー (住所など) に直接関連しない繰り返し値のみを正規化の候補にする必要があります。

毎回計算を行うことなく、各日付 (月、四半期など) の異なる表現を追加したい場合、日付を正規化することで私が見ることができる唯一の利点です。それ以外の場合、私の意見では、ドローバックは利点を上回ります。

于 2013-11-14T17:37:21.140 に答える
1

日付テーブルがデータ ウェアハウスの期間テーブルに似ていると仮定すると、おそらく次のような構造になっています。

Field date, datatype date (not datetime) primary key
other fields include fiscal year and holiday information

次に、トランザクション テーブルは次のようになります。

broker_id, foreign key to broker
date, foreign key to date
transaction time
other fields as necessary

あなたの質問は、「ポ​​イントは何ですか？」 でした。この種のデータベース設計により、「会計期間ごとに分類された、過去 5 会計年度のブローカー x の統計を教えてください」などの質問に簡単に答えることができます。

于 2013-11-14T17:34:27.583 に答える
1

チェックアウト：

http://en.wikipedia.org/wiki/Database_normalization#Normal_forms

取引日を正規化する必要はありません。

しかし、トランザクションが顧客に関連付けられており、顧客の詳細も保持する必要があると想像してください。これは、正規化がデータの冗長性を減らすのに役立つケースです。

于 2013-11-14T17:14:10.020 に答える
1

日付属性を別のテーブルに移動して、トランザクション テーブルの外部キーにすることは、「正規化」とは関係ありません。関係の例を考えてみましょう:

T{TransactionId,Date}

と依存

{TransactionId}->{Date}

TransactionId がキーの場合、T は既に第 6 正規形を満たしています。Date を別のテーブルに移動したり、別の属性に置き換えたり、外部キーにしたりしても、T は以前よりも「正規化された」ものにはなりません。

属性値が「繰り返す」かどうかは、正規化には関係ありません。データベーススキーマで満たすことを意味する機能の依存関係と結合の依存関係は何ですか。「データの繰り返し」は、関数の依存関係を説明するために非公式に使用されることがありますが、データが繰り返されるという理由だけで分解が必要であると言うのは単純化されすぎています。

于 2013-11-15T10:35:28.240 に答える