webdevqa.jp.net

正規化:「繰り返しグループ」とはどういう意味ですか?

私はさまざまなチュートリアルを読み、正規化のさまざまな例、特に最初の正規形の「繰り返しグループ」の概念を見てきました。それらから私は、繰り返しグループが「種類の」多値属性であることを収集しました(例 here および here )。

しかし、ERM(エンティティリレーションシップモデル)をRDM(リレーショナルデータモデル)にマッピングするプロセス中に、親テーブルの外部キーを含めることで、各多値属性ごとに別のテーブルをすでに作成していますか?参照: this

第二に、それらの「繰り返しグループ」は基本的に同じ行に水平に配置されますか、または同じ列に同じ値が何度も発生する可能性があります(つまり、属性の同じ値) 、繰り返しグループであり、削除する必要がありますか?

enter image description here この例では、値Englishが何度も繰り返されています。これは繰り返しグループですか?サブジェクト名とModule_ID(外部キー)を使用して別のテーブルSUBJECTを作成するためにそれを削除すると、これが取得されます。確かに繰り返しの値は取り除かれますが、これが正しいことかどうかはわかりません。正しいですか? enter image description here

15
Solace

「繰り返しグループ」という用語は、元々、単一のフィールドに繰り返し値の配列を含めることができるCODASYLおよびCOBOLベースの言語の概念を意味していました。 E.F.コッドが彼の最初の正規形を説明したとき、それは彼が繰り返しグループによって意味したものでした。この概念は、最新のリレーショナルまたはSQLベースのDBMSには存在しません。

「繰り返しグループ」という用語も非公式に使用され、繰り返しセットを意味するようにデータベース設計者によって不正確になっている列の、テーブル内の同様の種類の値を含む列のコレクションを意味します。これは、1NFに関して元の意味とは異なります。たとえば、Parent1、Parent2、Child1、Child2、Child3などの名前の列を持つFamiliesというテーブルの場合、Childのコレクション[〜#〜] n [〜#〜 ]列は繰り返しグループと呼ばれることもあり、でなくても1NFに違反していると見なされますコッドが意図した意味での繰り返しグループ。

いわゆる繰り返しグループのこの後者の意味は、各属性が単一値のみである場合、技術的には1NFの違反ではありません。属性自体には繰り返し値が含まれていないため、そのため1NFの違反はありません。このような設計は、テーブルをあらかじめ決められた固定数の値(ファミリーの最大N個の子)に制約するため、およびクエリやその他のビジネスロジックを各列に対して強制的に繰り返すため、しばしばアンチパターンと見なされます。つまり、「 [〜#〜] dry [〜#〜] の設計原則に違反しています。一般に貧弱なデザインと見なされているため、データベース設計者や、場合によっては、この種の繰り返し列を「繰り返しグループ」と呼び、第1正規形の精神に違反するものと見なすこともあります。

この非公式な用語の使い方は、少し恣意的で混乱を招く可能性があるため(列のセットが実際に繰り返しを構成するのはいつですか)、また、より根本的な問題、つまりNull問題の邪魔になるため、少し残念です。すべての正規形は、nullの可能性を許可しない関係に関係しています。テーブルが任意の列でnullを許可する場合、1NFを満たすリレーションスキーマの要件を満たしません。 Familiesテーブルの場合、Child列がnullを許可する場合(N未満の子を持つファミリーを表すため)、Familiesテーブルは1NFを満たしません。正規化の練習では、nullの可能性はしばしば忘れられるか無視されますが、不要なnull許容列の回避は、「繰り返しグループ」と呼ぶかどうかに関係なく、列のセットの繰り返しを避けるための非常に良い理由の1つです。

この記事 も参照してください。

29
nvogel

英語の価値は何度も繰り返されています。これは繰り返しグループですか?

いいえ。SUBJECT_MODULEでの英語の複数の出現は、繰り返しグループではなく、繰り返しグループによって誤って意味されている2つのことのどちらでもありません。また、冗長性や正規化の欠如の証拠でもありません。このような複数の外観は冗長性または正規化に関連している可能性がありますが、冗長性やさまざまなレベルの正規化がない場合は常に表示されます。

SUBJECT_MODULEが「[SUBJECT_NAME]に[MODULE_ID]で識別される[MODULE_NAME]」が含まれる行であり、サブジェクトに複数のモジュールがある可能性がある場合、どこかにmustそのサブジェクトについて複数の言及がある(おそらくその名前を介して) )異なるモジュールの言及(おそらく名前またはIDによる)。これには冗長性は含まれません。

Student Age Subject

Adam    15  Biology
Adam    15  Maths
Alex    14  Maths
Stuart  17  Maths

質問の2番目の " this "リンクからのこの例の冗長性は、Adamが2行で表示されることや、Adamが2行で15で表示されることではありません。テーブルが「[Student]は[Age]歳で[Subject]をとる」という行の場合、Student(例:Adam)は複数の行に表示される可能性がありますただし、常に同じAgeで表示されます (例:15)。しかし、テーブルが「[学生]に[対象]に[年齢]歳の友人がいる」という行であった場合、テーブルはすでに完全に正規化されている可能性があります。

確かに繰り返しの値は取り除かれますが、これが正しいことかどうかはわかりません。

それはあなたのサンプルデータのために行いますが、他のサンプルデータのためではないかもしれません。あなたは私たちに十分に言っていません。 (とにかく、上で述べたように、複数の外観は正規化する必要さえないかもしれません。)

SUBJECT_MODULEに正規化に関連する冗長性があるかどうか、または指定した分解を含む有効な分解があるかどうかは、1NF以上に正規化するために必要な通常の情報に依存します。つまり、列の一部が他の関数であるかどうか(関数の依存関係)、行が "..."と "..."の行でもあるか(結合依存関係)。

可能な分解を与えることにより、「... [Subject_Name] ... [Module_ID] ...」AND「... [Module_Name] ... [Module_ID] ...」である行でもあると述べました分解データの例をいくつか示しました。しかし、分解を追加したので、それがcouldに分解されることがわかっているだけです。そして、分解とデータは、それがすべきであるかどうかを知るにはまだ十分ではありません。

私はさまざまなチュートリアルを読み、正規化のさまざまな例、特に最初の正規形の「繰り返しグループ」の概念を見てきました。

「繰り返しグループ」は、リレーショナルデータベース以前のものであり、リレーショナルテーブル(リレーション)には表示されない可能性があります。それらは、レコードのフィールドのような名前付きの値のセットのようなものですが、完全ではありません。リレーショナルテーブルは常に1NFです。行の各列には、列のタイプの単一の値があります。非リレーショナルデータベースは、テーブルに「正規化」されます。つまり、繰り返しグループを取り除く1NF(「正規化」の第一の意味)です。次に、それらのテーブル/関係は、より高い正規形に「正規化」されます(「正規化」の2番目の意味)。

複数の類似する列を持つリレーショナルテーブル、または複数の類似する部分を持つ列タイプを持つリレーショナルテーブルは、それぞれreminiscent非リレーショナルデータベースに繰り返しグループがあることを示しています。また、繰り返しグループの複数のメンバーと同じように、複数の列とパーツは別々のテーブルの複数の行になるはずです。しかし、これらの問題は、リレーショナルデザインの品質と関係があり、繰り返しグループや正規化(どちらの意味でも)や関係性(つまり1NFである)ではありません。

非リレーショナルデータベース自体も、複数の同様のフィールドや名前付きセット、あるいはフィールドの値の複数の同様の部分で同様の問題を抱えている可能性があることに注意してください。テーブルへの正規化は、繰り返しグループを取り除くときにこれらを取り除きません。

リレーショナルデザインにどのように移行したかに関係なく、それらを削除すると「より良い」デザインになります。これらの設計上の問題が繰り返しグループを連想させるからといって、人々は混乱し、どういうわけかテーブルに繰り返しグループが含まれる可能性があると想像します。そのため、複数の類似した列と複数の類似した部分(または部分)を持つ値は、誤って「繰り返しグループ」と呼ばれます。

この回答は「原子性」 を参照してください。

3
philipxy