共同作業者は、データベースにシリアル化された一連のデータを格納することは1NFに違反しないと主張しています

Question

1NFはフィールドをアトミ​​ックにする必要があります。つまり、単一の値のみを表す必要があります。

彼は、データが検索可能であるか、または読み取り可能であることを期待していないため、通常の形式に違反しておらず、その値が単一のオブジェクトを表していると、彼は言います。

彼は正しいですか？

Answer 1

"アトミック"を定義します。

最近の理論の進歩は、（典型的に理解されるように）1NFの定義が依存する「原子性」という概念が漠然としていることを示しています。

たとえば、マップ上の座標は、「アトミック」値ですか？通常、そのような値は明白に見える 'X'と 'Y'成分を持ち、それらの成分の値はあなたの「原子」値から引き出されます。何かが他の何かから引き出されることができれば、「何か他のもの」は通常の意味で「原子的」である（すなわち、それ以上分解できない）と主張する疑いがある。

「地図上の座標」タイプの値を使用していますが、その理由は1NFに違反していますか？その位置を維持することは難しい。

このような理由から、CSVのリストを保持する単一の文字列では、は正式にはに違反します。つまり、実際にこのようにデータベースを設計することは非常に良い考えです。ほとんどの場合、そうではありません。しかし正式に言えば、それは1NF（またはそれが残っているもの）に違反しません。

Answer 2

問題が単一値は、多くの場合、実際に（例えば、varcharは多くchar値とすることができ、浮動小数点数は、2つの別々の数値であることができる）状況に応じて別の値に分解することができることです。シリアライズされたデータがテーブルによって表される関係に関係しない場合、はとなり、1NFとみなされます。

Addressフィールドには、通りの名前と総称ContactInfoテーブルで都市を含めることができますが、フィールドには、通りの名前、都市、ZIPなどのために別の属性を持っているでしょうAddresses表で原子は考えられません

Answer 3

文字列は単一の値です。小さな文字列に分割できるという事実が、あなたが1NFに違反していることを意味するものではありません。多くの情報を文字列にエンコードしている場合、DBMSの機能を最大限に活用していない可能性があります（つまり、データをクエリして制約を適用する機能）が、別の質問です。

Answer 4

はい、あなたの牛orkerは正しいです。

現在の知恵は、単一の値が任意に複雑である可能性があるということです。テーブルでもあります。 （Chris Dateの書籍では、「関係値付き属性」を参照してください。）日付とタイムスタンプは単一の値ですが、どちらも内部構造を持っています。

しかし、型がない場合

は内部構造、DBMSを持っているいずれかのその内部構造を無視したり、その内部構造を操作する関数を提供しています（ SELECT CURRENT_TIMESTAMPがあればSQLがするように）（SQLがするようであれば、あなた SELECT EXTRACT(YEAR FROM CURRENT_TIMESTAMP））。

重要な点は、ユーザーが内部構造の内容を操作するための手続き型コードを記述する必要がないことです。 dbmsがこれらの関数を提供するか、新しい型を作成するデータベース設計者がこれらの関数を提供します。