正規化されたテーブルでは、列の数を減らす必要があり、参照フィールドをできるだけ多く持つことができます。それは正しいアプローチですか?列の数と適切な正規化プロセスの間に関係はありますか?
5 に答える
列の数と適切な正規化プロセスの間に関係はありますか?
要するに、いいえ。3NF 正規化テーブルには、必要な数の列があります。
テーブル内のデータは、キー、キー全体、およびキー以外には依存していません (Codd を助けてください)。
(一部の) 非正規化が実際にパフォーマンスを向上させる状況があり、これを行う必要がある場合の唯一の実際の尺度は、それをテストすることです。
テーブル内の膨大な数の列を気にするのではなく、正規化の原則に従う必要があります。ビジネス要件は、エンティティ、その属性、およびそれらの関係を駆動し、絶対的な数は「正しい」ものではありません。
テーブルのフィールドが多すぎると感じた場合に使用できるアプローチを次に示します。例:-
CREATE TABLE Person
Person_ID int not null primary key,
Forename nvarchar(50) not null,
Surname nvarchar(50) not null,
Username varchar(20) null,
PasswordHash varchar(50) null
このテーブルは人を表していますが、明らかにすべての人がユーザーである必要はないため、Username フィールドと PasswordHash フィールドは null 可能です。ただし、ユーザー数よりも 1 桁または 2 桁多くの人がいる可能性があります。
このような場合、Person テーブルと 1 対 1 の関係を持つ Username フィールドと PasswordHash フィールドを保持する User テーブルを作成できます。
このアプローチを一般化するには、一緒に null であるか、一緒に値を持ち、null である可能性が非常に高い null 許容フィールドのセットを探します。これは、抽出できる別のテーブルがあることを示しています。
編集
Stephanie (コメントを参照) のおかげで、この手法は明らかに「垂直パーティショニング」と呼ばれています。
私は@ocdecioに同意しますが、同じデータストレージ要件を考えると、正規化されたデータベースは通常、そうでないデータベースよりもテーブルあたりの列が少なく、テーブルが多いことにも気づきます。コードの匂いと同様に、データベースの匂いは、かなり大きなアプリケーションの場合、比較的少数のテーブルになります。これは、おそらくデータが通常の形式ではないことを示しています。必要に応じて正規化ルールを適用すると、この「におい」が緩和されます。
各列には、主キーとの直接的かつ排他的な関係が必要です。モデルを単純化するためにできることは限られている属性の多い項目がある場合。複数のテーブルに分割しようとすると、非生産的で無意味になります。