問題タブ [database-normalization]

現在、データベースには次のような同じ「基本フィールド」で構成される複数のテーブルがあります。

しかし、私はその基本的なテーブルの複数の特殊化を持っています。たとえば、テーブルには、、などtv_seriesのフィールドがあります。seasonepisodeairingmoviesrelease_datebudget

linkgroups最初はこれは問題ではありませんが、これらの特殊なテーブルへの外部キーで呼び出される 2 番目のテーブルを作成したいと考えています。つまり、何らかの形でそれ自体を正規化する必要があります。

私が聞いたこれを解決する1つの方法は、key-valueペアテーブルで正規化することですが、それは一種の「データベース内のデータベース」スキームであるため、私には方法がありません。特定のキー/フィールドを要求したり、特別なタイプを要求したりする必要はありません。後でデータを取得して注文するのは非常に面倒です。

したがって、複数のテーブル間で主キーを「共有」する方法、またはそれ以上の方法を探しています。一般的なテーブルと複数の特殊なテーブルを使用して正規化する方法です。

リレーショナル データベースの設計には、データベースの正規化または単に正規化という概念があります。これは、列 (​​属性) とテーブル (関係) を編成してデータの冗長性を減らし、データの整合性を向上させるプロセスです。（ウィキペディアに書かれているように）。

ほとんどの記事はやや専門的で理解しにくいため、1NF、2NF、3NF、さらには 3.5NF (Boyce-Codd) の意味について、例に基づいてより理解しやすい説明を誰かに書いてもらいます。

3NF または 4NF であり、ドメイン キーの正規形ではないリレーショナル テーブルの例はありますか?

非キー列の複合キー関数従属性を5番目の通常の形式で表すことは可能ですか？

私は3つのテーブルを持っています、

私が知っているように、5番目の通常の形式では、テーブルを独自の小さなエンティティで表す必要があります。したがって、events_usersテーブルのparticipation_typeを5番目の通常の形式と呼ぶことはできないと思いますか？

誰かが私にもっと良い解決策を提案できますか？

問題は、CodeIgniterのDataMapperライブラリを使用していて、各テーブルが独立して存在する必要がある、つまり5番目の通常の形式であるということです。

関連する従業員 ID で managerid フィールドを更新する必要があります。

DB (MySQL など) のスキーマを設計する場合、テーブルを完全に正規化するかどうかという問題が生じます。

一方では結合 (および外部キー制約など) が非常に遅く、他方では冗長なデータと不整合の可能性があります。

ここで「最後に最適化する」のは正しいアプローチですか? つまり、標準化された DB を作成し、最適な速度向上を達成するために非正規化できるものを確認します。

このアプローチに関する私の懸念は、十分に高速ではない可能性のある DB 設計に落ち着くということですが、その段階で (既存のデータをサポートしながら) スキーマをリファクタリングすることは非常に苦痛です。これが、「適切な」RDBMS プラクティスについて学んだことを一時的にすべて忘れて、「フラット テーブル」アプローチを一度だけ試してみたくなる理由です。

この DB が挿入を多用するという事実は、決定に影響を与えるべきでしょうか?

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

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

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

デザイン1

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

デザイン 2

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

デザイン3

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

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

デザイン 4

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

デザイン 5

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

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

データベースは初めてなので、簡単な質問に腹を立てることはありません。私のグーグルで収集した知識の正規化は、データの冗長性を減らし、パフォーマンスを向上させる限りです。しかし、実際には、マスターテーブルを他の小さなテーブルに分割し、それらの間の関係を適用し、すべての可能なユニオン、サブクエリ、結合などを使用してデータを取得する正確な理由を理解していませんでした。単一のテーブルを作成し、必要に応じてそれらを取得します。私は少し混乱しています。

データベーステーブル(関係)の正規化に関する洗練されたメモをどこで入手できるかについて、誰かが考えを持っていますか?