問題タブ [database-normalization]

正規化の利点は何ですか。そして、なぜそれを行うのか。誰か私にそれについて説明できますか???????

まず第一に、私の悪い英語のheheheに申し訳ありませんが、助けが必要です。ミニアマゾンのようなウェブサイトのデータベースを設計したいと思います。このデータベースは、あらゆる種類の製品（TV、車、コンピューター、本、ビデオゲーム、鉛筆、テーブル、ズボンなど）を管理しますが、たとえば、製品の場合、各製品にはいくつかのプロパティ（インデックスが作成される）が必要です。は本であり、プロパティはジャンル、年、著者のようなものになります。製品がテレビの場合、プロパティはサイズ、色、年などになります。また、製品が自動車の場合、プロパティは、たとえば、年、色、モデルなどになります。だから、これは私の考えです：

1. 部門（電子機器、本など）を管理するための1つのテーブル
2. 部門のカテゴリを管理するための1つのテーブルで、このテーブルは前のテーブルの子になります。部門が電子機器の場合、ここにオーディオ、テレビ、ビデオ、ゲームがあります...（各カテゴリは1つの部門に属し、関係は1つの部門から多くのカテゴリに属します）
3. 製品を管理するための1つのテーブル（各製品は1つのカテゴリに属し、関係は多くの製品に対する1つのカテゴリです）
4. プロパティ（年、色、ジャンル、モデルなど）を管理するための1つのテーブル
5. 製品をプロパティに関連付けるための1つのテーブル、このテーブルはProductPropertiesと呼ばれます

これが最善の方法かどうかはわかりません。データベースは巨大になります。MySQLでデータベースを開発します。しかし、これは最善の方法ではないと思います。この記事では、「データベースの抽象化：集約と一般化」http://cs-exhibitions.uni-klu.ac.at/index.php?id=433について説明しています。一般的なオブジェクト（私は思う）ですが、この方法は古い（70年代）です。この記事のhttp://www.simple-talk.com/sql/database-administration/ten-common-database-design-mistakes/のセクション「すべてのドメイン値を保持する1つのテーブル」では、これは間違った方法であると述べています...テーブルProductPropertiesのためにこれをすべて言っていますが、このテーブルを作成するのか、製品の種類ごとに特定のテーブルを作成するのかはわかりません。

何か提案はありますか？それとももっと良いアイデアがありますか？

よろしくお願いします!!!

スタック オーバーフローで正規化が広く議論されていることは知っています。以前の議論の多くを読みました。ただし、いくつか追加の質問があります。

少なくとも 100 個のテーブルを持つレガシー システムで作業しています。データベースには、正規化されていない構造、さまざまな異種データを含むテーブル、およびその他の問題があります。私はそれを改善しようとする任務を与えられました。やり直すことはできませんが、既存のスキーマを変更する必要があります。

これまで、私は常に正規化されたデータベースの設計を試みてきました。今質問。上級開発者は、場合によっては正規化できないことを示唆しています。

1. 時系列データあり。たとえば、製品にリンクする請求書が作成されます。顧客が 1 年後にこの請求書のコピーを要求した場合、元の正確なコピーを作成できなければなりません。製品の価格、名前、または説明が更新された場合はどうなりますか? 年配の男性は、価格やその他の製品情報を請求書テーブルにコピーするよう提案しました。時間の経過に伴う価格の変化を追跡できるように、日付フィールドを持つ productPrice などの別のテーブルを作成する必要があるのではないかと考えています。製品の説明と名前にも同じものが必要でしょうか？複雑そうです。どう思いますか？

2. データベースは会計システムです。私は会計にあまり詳しくありません。現在、いくつかの要約データが取得され、データベースに保存されています。たとえば、年間の総売上。私のシニア アソシエイトは、会計士は、この値を請求書などから実際に計算されたデータと比較して、アプリケーションが正しく機能していることを確信できるようにすることで、物事が正しいことを確認するのが好きだと言いました。

たとえば、合計が同じではないため、誰かが昨年の請求書を誤って削除したかどうかを現時点で判断できると彼は言いました。彼はまた、これらの合計をその場で計算するのは非常に遅くなる可能性があることも指摘しました。もちろん、データは重複してはならず、必要に応じて常に計算する必要があると言いました。私は、これらのレポートを夜間に生成してキャッシュする SQL Reporting Services またはその他のソリューションを使用することを提案しました。とにかく彼は納得していません。これについて何かコメントはありますか？

私はデータベースの設計を決定しようとしています。より具体的には、これはより大きな設計のサブパーツです。基本的に、「ロケーション」があります。各ロケーションには、任意の数のセンサーを関連付けることができ、ロガーを含めることができます（ただし、1つのみ）。

私にはセンサーの測定値があり、ロガーの測定値があります。それぞれが、別々のテーブルを保証するのに十分異なると思います。

センサーの読み取り値が範囲外になると、アラートが生成されます。センサーの読み取り値が範囲外にある間、それらはそのアラートに関連付けられ続けるため、多くの読み取り値を含む1つのアラートになり、後でアラートをグラフ化して傾向などを見つけることができます。

ロガーの測定値と同じです。

このデータを保存するためのこれまでの私の3つのアイデアは次のとおりです。

オプション1：

• 問題：繰り返しテーブルがたくさんあります（それは本当に重要ですか??）

オプション2：

• 問題：「アラートごとに少なくとも1つの読み取り」ルールを適用しません。
• 問題：複数のタイプの読み取りで同じアラートを参照できるようにします。

オプション3：

• 問題：同じアラートを参照するLoggerAlertとSensorAlertを停止するものはありません（オプション2と同じ問題）。
• 問題：データベースをわかりにくくします（スーパーテーブルはOOの概念ではありませんか？データベースは純粋にリレーショナルであることが意図されていますね？）

これまでのところ、オプション1を選択していると思います。これは、テーブルを効果的に繰り返しているにもかかわらず、オプション1が非常にクリーンで、意図が明確であるためです（私は願っています！）。

私が今考えた唯一のわずかな問題は、さまざまなセンサーの読み取り値が1つのアラームに関連付けられる可能性があることです。

上記の選択肢について、人々の意見はどうなっているのだろうか。静かにすることをお勧めする「スーパーテーブル」をよく使用しますが、何らかの理由で正しく感じられません。特に、データの整合性を確保する方法を見ると、ちょっとしたハックのように感じます。リレーショナル設計よりもオブジェクト指向プログラミングに似ているようです。

ありがとう。

編集： 以下の質問のいくつかに答えるのに役立ついくつかのさらなる情報：

ほとんどの場合、データベースは、違いが生じる場合は、アプリケーションサーバーを介してのみ操作されます。

ライブアラートとロガーアラートは通常同じように扱われるため、ロガーアラートとライブアラートを異なる方法で処理するのではなく、ほとんどの場合、すべてのアラートを処理することになります。

ロガーには、ロケーションテーブルに存在するかなり特定の列があります。場所とロガーは1対1のマッピングになるので、別のロガーテーブルを使用しないことにしました。これまでのところ、問題なく機能し、シンプルに保たれているようです。列の例：LoggerRFID（int）、LoggerUpperLimit（float）、LoggerLowerLimit（float）など。ロガーはセンサーであるとほぼ主張できますが、私はその道を進みましたが、あまりうまくいきませんでした。

私はアラートを一般的なものにすることをほぼ受け入れることができますが、回答の1つが言ったように、私はこれについて非常に確信を持って努力しているので、特定のパスを選択する前にできるだけ長く調査を続けます。

マルチプレイヤーをサポートしているかどうか、ジャンル、リリース日など、ゲームに関連するプロパティを格納するデータベースの設定に取り組んでいます。

カテゴリタイプごとに2つの追加テーブル（genres、genres_dataなど）を作成することは、それほど動的ではないようです。私の最初の考えは、2つの方法のいずれかを設定することでした...

骨格情報を含むゲームテーブル、すべてのプロパティを一覧表示するプロパティテーブル、およびゲームに関連するすべてのデータを含む3番目のテーブルを用意します。ここでは、基本的に各プロパティに関連する列のみが使用されます。

または、ゲームテーブルを同じにし、プロパティに列名を含めてから、3番目のテーブルの列を使用します。

この種のシナリオでは、行に関連する5ダースほどのタイプのデータがありますが、各カテゴリに多数のカテゴリとサポートプロパティがある場合の実際的なアプローチは何ですか？（私には）各プロパティタイプまたはカテゴリのテーブルを作成するのは効率的ではないようです。

この前の質問の一種のフォローアップとして: 類似したデータ型を持つさまざまなプロパティの正規化

私は今、このセットアップを作成しました: http://schemabank.com/p/VwWHn

私の質問は、私はこの方法で正しい道を進んでいますか? 私が使用しているセットアップに明らかな間違いがありますか、それとも私が見逃している正規化の概念について何かありますか? 現実世界のシナリオで機能する実用的なアプローチを目指しているので、このデータベースを構成するためのより良い方法があれば、喜んで聞いてください.

Q:

ERDと正規化のトレーニングのためだけに Web サイトや本が欲しいです。データベース設計のスキルを強化し、私が作成した貧弱なデータベース設計を回避するために、多くのサンプル、プラクティス、および推奨される回答を含むケース スタディが必要です。

ノート：概念を説明するのに本は必要ありません。必要なのは、プラクティス、例、および推奨される回答を含むケース スタディです。

前もって感謝します。

これはよくある面接の質問です。面接官が私に 1 つのテーブルを与え、そのテーブルがどの通常の形であるかを教えてくれる面接に直面しました。##NF にある場合は、次の NF に正規化しますか?

私はいつも、これらの通常の形式のデータベースの間で混乱しています。次のインタビューで役立つように、各 NF がテーブルにモデル化される方法の適切な例を使用して、これらの正規形を説明してもらえますか?

これらのどれが Web アプリケーションで使用するのに適しているのか疑問に思っています。ユーザーがサイトに投稿できる Web アプリがあります。投稿には 3 つの異なるタイプがありますが、1 つのテーブルにまとめることができるほど似ています。それでいいの？

この方法でテーブルを正規化できますか? (どちらかの下にタイプを入れます)

表1

表 2

または、1 つのテーブルを使用する方がよいでしょうか?

テーブル

誰かが欠点を指摘できない限り、私は 3 番目の方法に傾いています。

私はそのようなデータのコレクションを持っています

最初に、これを次のように2つのテーブルに正規化しました

パフォーマーを別のテーブルで表現したいと思っていますが、表現方法がわかりません。私が言えることから、次の関係が存在します

• 1 対多: プログラムには多くのパフォーマーを含めることができます。
• 1 対多: 1 人のパフォーマーが多くの番組に出演する可能性があります

これをどのように表現すればよいかわかりませんか？

EDIT ああ、なるほど、たとえば、実際にはこのようなテーブルがあるのでしょうか?