0

現在、正規化の学習に問題があります。1NF - 3NF の背後にある基本的な概念は知っていますが、正規化する前に従う必要がある手順をまだ理解していません。

私の理解によれば、最初に を収集base entitiesし、attributes次にrelation among the entitiesを収集する必要がありstart normalizationます。しかし、すべての属性を一度に正規化するのか、それとも何らかの関係を持つエンティティの属性を正規化するのかがわかりません。

店舗例で考えてみます。

store(name, address, contact)
customer(sn, name, address)
item(id, name, price)
transaction(id, date, customer_sn, item_id, quantity, total_price)

私の理解によれば、すべての属性を一度に正規化するかcustomer、 、itemおよびのみの属性を正規化しようとしtransactionます。

私は何かが欠けていることを知っていますが、それを理解することはできません.

どんな助けでも大歓迎です。貴重な時間をありがとう。

4

1 に答える 1

-1

私の理解によると、最初に基本エンティティ、その属性、エンティティ間の関係を収集してから、正規化を開始する必要があります。

いいえ、その必要はありません。実際、正規化を開始する前に、いくつかの基本エンティティを特定することさえ、不可能ではないにしても難しいことがよくあります。

論理レベルでは、必要なすべての属性を収集することから始め、それらを 1 つの大きな関係に配置します。データベース システムに関する事実上すべての教科書に、この小さな例があります。

必要な属性をすべて収集したら、それらの間の依存関係を判別します。

ストアの場合、これらの属性を収集できます。

  • A.店名
  • B.店舗の住所
  • C.アイテムのSKU
  • D.アイテム名
  • E.商品価格
  • F. トランザクションのタイムスタンプ
  • G. 取引タイプ (「購入」、「返品」、「ストア クレジット」など)
  • H. トランザクション レジスタ (トランザクションを実行したマシン)
  • I. トランザクション キャッシャー (どの従業員がトランザクションを実行したか)
  • J.取引アイテムSKU
  • K.お取引商品代金
  • L. 取引アイテムの数量
  • M.取引アイテム内定価格
  • N.お取引商品消費税
  • O.取引合計
  • P.トランザクションの支払いタイプ（現金、小切手、クレジットカード）
  • Q.取引支払金額

その後、これらの機能依存関係が適用されると判断する場合があります。

  • A->B
  • B->A
  • C->D
  • C->E
  • FH->GI
  • FH->O
  • J->K
  • FHJ->L
  • KL->M
  • KL->N
  • M->N

ここから正規化を開始します。1 つのリレーションを分解してより高い正規形にするたびに、別のリレーションが追加されます。別の関係を追加するたびに、正規化のすべての原則をそれに適用します。プロセスは再帰的です。

優れた CASE ツールは、その依存関係のリストに基づいて、考えられるすべての 5NF 分解を生成できます。

その他の設計上の決定も重要ですが、正規化とは関係がない場合があります。

たとえば、1 つの設計プロジェクトで、1 人につき 1 つの電話番号のみを保存することを決定する場合があります。別のプロジェクトでは、各個人に複数の電話番号を保存することを決定する場合があります。そういう判断は大事ですが、ノーマライゼーションとは関係ありません。つまり、1 人につき 1 つの電話番号を保存しても、通常の形式に違反することはなく、 1 人につき複数の電話番号を保存することもできません。

于 2013-01-10T11:15:20.390 に答える