正規化：年などの静的な数値を独自のテーブルに分割することは準拠と見なされますか？

他のデータベース設計者と正規化について興味深い議論をしています。この例では、GameTitlesテーブルがあり、各レコードにはゲームがリリースされた年が含まれている必要があります。彼は、2NFはすべてを正規化することを義務付けているので、準拠するには、GameTitlesテーブルによって参照される独自のプライマリキーを持つYearYフィールドをReleaseYearsテーブルに分割する必要があると言います。GameTitlesテーブル自体のフィールドとして残す必要があると言います。

これに対する私の主張は、年はその性質上静的な単なる非プリミティブ数値であるということです（つまり、2011は常に2011です）。このため、独自の識別子として機能し、それが何であるかを参照する必要はありません。また、テーブルを参照するためだけに新しい年をテーブルに追加する必要があるため、追加のメンテナンスも導入されます。テーブルに長い年数を事前に入力すると、それらへの参照をまったく持たない可能性のある追加のレコードがあります。これにより、余分なテーブル、レコードのオーバーヘッド、および年自体の追加の主キーがあるため、データベースサイズも増加します。GameTitlesテーブルのフィールドとして年を保持すると、この追加のメンテナンスとオーバーヘッドがすべてなくなります。

これについての考え？

編集： StackOverflowでこれを投稿することを意味します。誰かがこれを削除するか、注意を喚起するために投票できますか？

他のデータベース設計者は単に間違っていますが、あなたの推論も間違っています。単一の候補キー「game_title」を持つこのテーブルから開始すると仮定します。

Table: game_titles

game_title                      year_first_released
--
The first game                  1998
The second game                 1999
Best game: the third one        2001
The fourth game                 2003
Forty-two, the end of games     2011

これらの質問を自問して、2NFであるかどうかを評価します。

Q：まず、1NFですか？

A：はい、そうです。

Q：主要な属性（候補キーの一部である属性）とは何ですか？

A：「game_title」は唯一の主要な属性です。

Q：非プライム属性とは何ですか？

A：「year_first_released」が唯一のものです。

Q：「year_first_released」は、機能的に「game_title」全体に依存していますか、それとも一部にのみ依存していますか？

A：唯一の候補キーである「game_title」は単一の列です。部品さえありません。そのため、「year_first_released」は「game_title」全体に機能的に依存しています。

ほら。2NFが見つかりました。

最初に1NFかどうかを尋ねてから、この質問に答えることで、いくつかの正式な用語をカットできます。

Q：複合候補キーはありますか？

A：いいえ。

ほら。再び2NFが見つかりました。

定義により、テーブルが2NFに違反するには、複数の列を持つ少なくとも1つの候補キーが必要です。

友人の意見を拒否する理由は次のとおりです。

• 年は単なる非プリミティブ数値です。
• 1年はその性質上、静的です。
• 年は独自の識別子として機能します。
• 年の表には、追加のメンテナンスが導入されています。
• 年の表には、参照されない余分な行がある場合があります。
• 年の表により、データベースのサイズが増加します。

これらの理由のいずれも、テーブルが2NFにあるかどうかとはまったく関係がありません。

データベースの設計では、メンテナンスの問題、データベースのサイズ、参照されていない行、範囲の制約などを考慮することは間違っていません。これらのことを正規化と呼ぶのは間違っています。

ああ、そして私が上で提供したその2列のテーブル-それは5NFにあります。

属性に対して個別のテーブルを作成することは、正規化とは関係ありません。2NF、3NF、BCNF、4NF、5NFはすべて、非キー依存関係の排除に関係しています。新しいテーブルから単一の属性を削除して外部キー属性に置き換えると、テーブル内の依存関係は論理的に以前と同じになります。したがって、テーブルの改訂版はそれ以上またはそれ以下に正規化されます。前だった。

私の観点からは、「リリース年」が暦年ではなく、たとえば複数の暦年にまたがる会計年度（10月から10月など）の場合にのみ、別の年表が意味をなします。

そのテーブルは、会計年度の定義（実際の開始日と終了日）を保持します。

http://en.wikipedia.org/wiki/Second_normal_formから：

1NFテーブルは、候補キーKおよび候補キーの構成要素ではない属性Aが与えられた場合にのみ、Aがその一部ではなくK全体に依存する場合にのみ2NFになります。

あなたは年が候補キーの一部であるかどうかを示しませんでしたが、どちらの場合も年に関する限り2NFが満たされるので、私はそれが重要であると確信していません。

実用的なレベルでは、あなたがリストしたすべての理由で年を分けることは悪い考えです。

個別のテーブルに対する引数は、そのサイズのため、または未使用の行があるため嫌いです。この表に1000年を入れても、サイズは無視できます。

そうは言っても、テーブルはまったく必要ないと思います。その年に別のテーブルを用意する意味は何ですか？このデータはすでにメインテーブルにあり、2つ目のテーブルを作成しても何も保存されません。

引数は、各行が日を表し、他の属性（曜日、UTCオフセット、休日かどうかなど）を持つことができるカレンダーテーブルでは異なる場合があります。

しかし、1年だけですか？いや、私はまったく利点がありません...そして、他の人が指摘したように、なぜ彼らはそれがより正規化されていると思うのか彼らに尋ねますか？または彼らは何を得るのですか？次のようなクエリを作成しようとしている場合

WHERE othertable.year = 2011

の代わりに

WHERE dt >= 20110101 AND dt < 20120101

次に、後者の方がパフォーマンス（dtがインデックス付けされていると仮定）とストレージの方がはるかに優れていることを説得します。コーディングの単純さが最重要である場合、永続化された計算列は別のテーブルよりも優れていると言えます。

「年」は必ずしも原始的な値ではないかもしれないという点を除いて、私はCatcallの答えに完全に同意します。

同じ設計を維持しながら、リリースが許可されている年のみを年とすることにします。このような方法では、プリミティブな数値ではなく、それらのサブセットを扱います。そのようなサブセットにはプリミティブな実装がないため、独自の（別のテーブル？）を実行して参照する必要があります（FKを使用）。このように、私たちはまだ何年も話していますが、概念的に意味が変わったため、それらを別の方法で管理する必要があります。ただし、それらはまだ「リリース年」ですが、ドメイン知識のある人にとって何を意味するかという点で概念的に異なります。

この特定のケースでは、Catcallの答えは正しいと再度言いますが、それを指摘したかっただけです。（申し訳ありませんが、コメントするのに十分な担当者がまだいません。）