問題タブ [database-normalization]

これがばかげた質問である場合はお詫びします。

私は役に立たない答えを高低で検索しました。

最小限のカバーを計算する方法を知っています。

つまり、各機能依存関係が RHS で 1 つの属性のみを持つようにし、すべての FD を調べてそれぞれの閉鎖を計算し、削除できるものがあるかどうかを確認して (再び閉鎖を計算することによって)、余分な/冗長な lhs 属性を削除します。

「正規」カバーは同じことを表す別の言葉ですか?

以下の表があり、2NFに変換することになっています。

私が行ったところ、これに対する答えがあります：

スキル：従業員、スキル

場所：従業員、現在の勤務地

私はこれが^上記^で間違っていると感じています。

また、誰かが1NF、2NF、3NFの違いを説明できますか。私は1が最初に来ることを知っています、そしてあなたはそれをすべて小さなテーブルに分割しなければなりません、しかし私がよりよく理解するのを助けるために本当に良い説明が欲しいです。ありがとう

私はジュニアです。開発者（5か月の仕事）、およびデータの正規化について質問があります。さて、私が理解しているように、データの正規化の背後にある一般的な原則は、データの冗長性が最小限に抑えられたRDBMSを作成することです。私のプロジェクトでは、DB担当者の1人がDBを作成しました。50以上のテーブルがあり、DB内のテーブルは通常、非常に断片化されています。テーブルには2つまたは3つの列があり、それだけです。さて、SQLクエリを書くことになると、各クエリはいくつかの異なるテーブルをくまなく調べてそれらを結合する必要があるため、それはちょっとした面倒になりました。これはデータの正規化の副作用なのだろうか？それとも、これは何か他のものを指しているのでしょうか？

私にとって最も簡単なことは、作成する必要のあるクエリに基づいてテーブルを作成することです。これにより、多くの冗長データを含むDBが作成されますが、満足のいくメディアがあるかどうか知りたいと思いました。

追記のように、自分の仕事について泣き言を言っているように出くわしたくはありませんが、これについてもっと知りたいと思っています。私の職場環境は最も友好的ではないので、同僚とこの質問をすることに抵抗があります。しかし、私はより経験豊富な人々からの考え、本、チュートリアルまたは意見をいただければ幸いです。

ありがとう。

各ユーザーが経費を入力して自分のカテゴリに分類できる経費追跡アプリケーションを作成したいと考えています。私が使用するモデル定義は次のとおりです。

各カテゴリはユーザーに関連付ける必要があります。これにより、各ユーザーが経費を入力する際に​​選択する独自のカテゴリを表示できるようになります。同様の理由で、各経費レコードはユーザーに関連付ける必要があります。しかし、Expense の定義では、User モデルへの 2 つの参照があります。1 つは「user」フィールドから直接、もう 1 つはユーザー参照を持つ「category」フィールドからです。

このような複数の参照は悪いことだと思います。これをモデル化するより良い方法はありますか？カテゴリ参照からユーザーを特定できることは理解していますが、それは遠回しな方法に思えます。

次の関係を満たすテーブルがあります。

これを第2正規形に分解する必要があるので、{AB->HI}, {D->FG}, {E->MN}独立したテーブルに分けます。しかし、どう{J->KL}ですか？これをどのように正規化する必要がありますか？

DBの考え方をいくつか行い、リンクテーブルなどの基本的なテーブルを用意します。リンクは、アカウント オブジェクト/レコードを指す外部キーを持つことができます。lookupsただし、単純化と抽象化 (たとえば、リンクをコンテンツベースのリソースとして扱う) のために、一般的なルックアップ テーブル (たとえば、 、notaccount_linksまたはと呼ばれる) を介してリンクをアカウントに割り当てると考えましたlink_accounts。

リンクは1 つのアカウントにのみ割り当てることができますが (常に 1 つのアカウントに割り当てる必要があります)、inner-me はその外部キーを作成したいと考えています。

しかし、私はオブジェクト/データリソースを抽象化し、そのコンテキストを分離するという概念が本当に好きです (たとえば、アカウントやユーザーなどに割り当てられます)。

誰かがemを持っていれば、いくつかの考えをいただければ幸いです:)

スキーマ:

リンク:

ルックアップ:

オンラインストアを構築しています。ストアには複数のカテゴリ (~10) があり、カテゴリには複数の製品 (それぞれ~10) があり、製品には多くのサブ製品 (それぞれ 20 以上) があります。

これは私が立ち往生している部分です：

サブ製品には、詳細の列がいくつかあります。製品には 10 個のヘッダーもあります。

これは製品の外観です。

http://www.ampedwebdesign.com/bear/new2/public/products/images/straightpins.jpg

ヘッダーは背景が暗いセルで、サブプロダクトは行です。

これは私のヘッダークラ​​スの一部です:

商品ビューは商品クラスを呼び出して画像を表示します。次に、製品ビューはヘッダー クラスを呼び出して、product_id によってヘッダーを返します。次に、製品ビューはサブ製品クラスを呼び出して、product_id によってサブ製品を返します。次に、製品ビューはサブ製品クラスを呼び出して、サブ製品の詳細を foreach ループで返します。

より良い方法があることがわかっている場合、このようなコードを書くのは嫌いです。私はそれを見つける方法がわかりません。

My DB テーブル: 製品、サブ製品、カテゴリ、ヘッダー

私の質問は次のとおりです。

1）主キーである関係R(A,B,C)があり、に依存していると仮定できますか？いいえと言いますが、念のためお願いします。ABF = {}CAB

2）私は、、、と言っているのと同じことを当然のことと思っAB -> CDEています。私は正しいですか？AB -> CAB -> DAB -> EAB -> CEAB -> D

3）を使用R(A,B,C,D)してAB、を主キーにしF = {AB->C}ます。これは入ってい2NFますか？D主キーは言うまでもなく、他の属性に依存しないので、私はノーと言います！

4）私は

KL主キーであること

R2NFまたはにあり3NFます。両方とも（間接的ではありますが）主キー全体PにN依存します。中にいるだけで十分2NFですか？もしそうなら、リレーションの非プライム属性間に依存関係があってはならないので、そうRではないと思いますよね？3NF3NF

ありがとう