気が狂いそうになり、学んだことをすべて忘れてしまったのかもしれませんが、自分が設計しているデータベース モデルについて多くの疑問を抱いています。
これは私の問題です：
n 列のテーブルがあり、そのうちの 8 つの列には、YES、NO、UNKNOWN の 3 つの値があります。
PK と説明を含む別のテーブルを使用できると考えましたが、1 つのテーブルから同じテーブルに対して 8 つの外部キーを作成できるかどうかはわかりません。
私の質問は：
YES、NO、および UNKNOWN を格納するために 2 つ目のテーブルが必要ですか? 同じテーブルに対して 8 つの外部キーを持つことは可能ですか?
あなたは狂っていません。
ハブとして機能するテーブルで終わるデータをモデル化する方法があり、FK/PK メカニズムを介してこれらのハブを参照する他の多くのテーブルがあります。そのデザインは「スタースキーマ」と呼ばれています。ハブとして機能するテーブルは「ファクト テーブル」と呼ばれます。それらを参照するテーブルは「ディメンション テーブル」と呼ばれます。ディメンション テーブル自体が他のテーブルから参照される「スノーフレーク スキーマ」と呼ばれる別の設計があります。
スターと正規化の両方を備えたスキーマを設計することはできません。これらは 2 つの異なる分野であり、それぞれに最適な適用分野があります。スター スキーマは、データ ウェアハウス、データ マート、およびレポート データベースに適しています。複雑な分析クエリの生成は驚くほど簡単です。スター スキーマの更新は王様の苦痛です。そのため、OLTP を実行している場合は、正規化された設計の方がうまく機能します。
スター スキーマはもともと、いわゆる「多次元モデリング」を SQL データベースの世界に移行する方法として開発されました。多次元モデリングは、Cognos などのデータ キューブなどの構造で使用されます。
ただし、スタースキーマの設計目標は、質問で概説したものとは大きく異なります。
YES、NO、および UNKNOWN を格納するために 2 つ目のテーブルが必要ですか?
あまり。TRUE (または 1 など)、FALSE (または 0)、NULL などの値を持つ、DBMS によって提供される「bool」(または「bit」など) 型を使用しないのはなぜですか?
または、各値が文書化され、すべてのクライアントに「よく知られている」単純な INT を検討してください。または、DBMS がサポートしている場合は ENUM (MySQL)。論理的にブール値または列挙型のものに文字列を使用しないでください。多くの繰り返し文字列でスペースを浪費することになります。
次の場合にのみ、別のテーブルを検討します。
同じテーブルに対して 8 つの外部キーを持つことは可能ですか?
同じテーブルが 8 つの外部キーの親エンドポイントになる可能性があります。同じテーブルが 8 つの FK の子エンドポイントになる可能性もあります (臭いですが)。
はい、可能です。
設計に 8 つの外部キーを含めることは間違いなく可能ですが (ただし、それを許可しない RDBMS が存在する可能性があります)、これを解決策と見なす場合、どの問題ドメインをモデル化しているのか疑問に思います。
外部キーは、参照されるテーブルのレコードに依存するレコードが外部キーを持つテーブルに含まれる関係を表します。2 つのテーブル内のレコード間の 1 対 1 の関係を追跡するために 8 つの参照を持つことは、少し奇妙に思えます。
特に、列は 3 つの値しか持てないためです。それはどのような関係を表すでしょうか。被参照テーブルのレコードはいくつまで指定できますか?
詳細がなければ、あなたのデザインは壊れていると思います。
あなたが説明したように、外部キーを持っていてもまったく問題ありません。それを試してみてください。
もちろん、処理する状態がこれ以上ない場合 (「たぶん」など)、または列挙型をサポートしていない可能性のある別のデータベースに移動する必要がない限り、ENUM ももちろん問題ありません。