注
このテーマは議論されており、このスレッドは他のスレッドで参照されているため、合理的な扱いをしました。ご容赦ください。私の意図は、単にラベルに基づいた単純な決定ではなく、情報に基づいた決定を下せるように、理解を提供することです。あなたがそれを強烈に感じるならば、あなたの暇な時にそれをチャンクで読んでください。お腹が空いたときに戻ってきてください。前ではありません。
正確には、EAVについて、「悪い」とは何ですか？
1はじめに
3NFが適切に行われた場合と不適切に行われた場合との間に違いがあるのと同様に、EAVが適切に行われた場合と不適切に行われた場合には違いがあります。私たちの技術的な仕事では、何が機能し、何が機能しないかを正確に把握する必要があります。何がうまく機能し、何がうまく機能しないかについて。包括的な声明は危険であり、人々に誤った情報を提供するため、関係する問題の進展と普遍的な理解を妨げます。
私は、熟練していない労働者による不十分な実施と、基準への準拠のレベルを誤って伝えることを除いて、何にも賛成でも反対でもありません。そして、私が誤解を感じるところでは、ここで、私はそれに対処しようとします。
正規化も誤解されることが多いので、それについて一言。ウィキペディアやその他の無料の情報源は、実際には完全に無意味な「定義」を投稿しています。これは、学術的根拠がなく、非標準に準拠した製品を検証するためのベンダーの偏見があります。彼の12のルールを公開したコッドがあります。私は最低5NFを実装しますが、これはほとんどの要件に十分すぎるため、それをベースラインとして使用します。簡単に言えば、第3正規形が読者に理解されていると仮定します（少なくともその定義は混乱していません）...
25番目の通常の形式
2.1定義
5番目の通常の形式は次のように定義されます。
- すべての列は主キーと1：1の関係にありますが、
- 他の列、テーブル、または他のテーブルにはありません
- 結果は、どこにも重複する列はありません。更新の異常はありません（列が更新されたときに、その重複が正しく更新されるようにするためのトリガーや複雑なコードは必要ありません）。
- （a）影響する行が少なくなり、（b）ロックが減少するため同時実行性が向上するため、パフォーマンスが向上します。
私は、データベースが特定のNFに正規化されているかどうかではないことを区別します。データベースは単純に正規化されています。各テーブルは特定のNFに正規化されています。一部のテーブルは1NFのみを必要とし、他のテーブルは3NFを必要とし、さらに他のテーブルは5NFを必要とします。
2.2パフォーマンス
正規化はパフォーマンスを提供しないと人々が考え、「パフォーマンスのために非正規化」する必要があった時期がありました。神話が暴かれたことを神に感謝し、今日のほとんどのIT専門家は、正規化されたデータベースのパフォーマンスが優れていることを認識しています。データベースベンダーは、非正規化されたファイルシステムではなく、正規化されたデータベースを最適化します。「非正規化」された真実は、データベースが最初から正規化されておらず（そしてパフォーマンスが悪い）、正規化されておらず、パフォーマンスを向上させるためにさらにスクランブリングを行ったということです。非正規化されるためには、最初に忠実に正規化される必要があり、それは決して起こりませんでした。私はそのような「パフォーマンスのために非正規化された」データベースのスコアを書き直し、忠実な正規化だけを提供しました。それらは少なくとも10倍、100倍も高速に実行されました。さらに、必要なディスク容量はごくわずかでした。非常に歩行者であるため、書面での運動を保証します。
2.3制限
制限、またはむしろ5NFの完全な範囲は次のとおりです。
- オプションの値を処理せず、Nullを使用する必要があります（多くの設計者はNullを許可せず、代替を使用しますが、適切かつ一貫して実装されていない場合、これには制限があります）
- 列を追加または変更するには、引き続きDDLを変更する必要があります（実装後に最初に識別されなかった列を追加するための要件がますます増えています。変更管理は面倒です）
- 正規化（重複や混乱した関係の排除）、ピボット（行のレポート、または列として表される行の要約の生成）、必要に応じた「列アクセス」などの複雑なクエリにより、最高レベルのパフォーマンスを提供します。データウェアハウスの操作は困難であり、それらの操作だけではうまく機能しません。これは、使用可能なSQLスキルレベルのみによるものであり、エンジンによるものではありません。
36番目の通常の形式
3.1定義
6番目の通常の形式は次のように定義されます。
- 関係（行）は主キーに加えて最大で1つの属性（列）です
これは、実行できる正規化がこれ以上ないため、究極のNFである既約正規形として知られています。それは90年代半ばに学界で議論されましたが、2003年にのみ正式に宣言されました。関係、関係者、「関係」などを混乱させることによって、関係モデルの形式を否定するのが好きな人のために。正式には、上記の定義は、原子関係と呼ばれることもある既約関係を識別するため、ベッドに置かれます。
3.2プログレッション
6NFが提供する（5NFが提供しない）増分は次のとおりです。
- オプション値の正式なサポート、したがってヌル問題の排除
- 副作用は、DDLを変更せずに列を追加できることです（後で詳しく説明します）
- 楽なピボット
- シンプルで直接的な柱状アクセス
- これにより、（バニラ形式ではなく）この部門でさらに高いレベルのパフォーマンスが可能になります
私（および他の人）が20年前に拡張5NFテーブルを明示的にピボット用に提供していたとしましょう。これにより、（a）単純なSQLを使用でき、（b）非常に高いパフォーマンスを提供できます。業界の巨人が私たちがしていることを正式に定義したことを知って良かったです。一晩で、私の5NFテーブルは私が指を離さずに6NFに名前が変更されました。次に、必要な場所でのみこれを実行しました。ここでも、6NFに正規化されたのはデータベースではなく、テーブルでした。
3.3SQLの制限
これは面倒な言語であり、特に再結合であり、適度に複雑なことを行うと非常に面倒になります。（これは、ほとんどのコーダーがサブクエリを理解または使用しないという別の問題です。）5NFに必要な構造をサポートしますが、それはただのことです。堅牢で安定した実装のためには、追加のカタログテーブルで部分的に構成される可能性のある追加の標準を実装する必要があります。SQLの「使用期限」は、90年代初頭までに十分かつ真に経過していました。6NFテーブルはまったくサポートされておらず、必死に交換する必要があります。しかし、それが私たちが持っているすべてなので、私たちはそれに対処する必要があります。
標準と追加のカタログテーブルを実装していた私たちにとって、6NF構造を標準にサポートするために必要な機能を提供するためにカタログを拡張することは、深刻な努力ではありませんでした。必須/オプション; 表示形式; など。SQLカタログと結合された、本質的に完全なMetaDataカタログ。
各NFには以前の各NFが含まれているため、6NFには5NFが含まれていることに注意してください。6NFを提供するために5NFを壊したのではなく、5NFからの進行を提供しました。SQLが不足している場合は、カタログを提供しました。これが意味するのは、外部キーなどの基本的な制約です。SQL宣言型参照整合性を介して提供されたバリュードメイン。データ型; チェック; 5NFレベルのルールはそのままで、これらの制約は覆されませんでした。標準に準拠した5NFデータベースの高品質と高性能は、6NFを導入しても決して低下しませんでした。
3.4カタログ
ユーザー（任意のレポートツール）と開発者を、5NFから6NFへのジャンプに対処する必要から保護することが重要です（アプリコーディングオタクになるのは彼らの仕事であり、データベースオタクになるのは私の仕事です）。5NFでも、それは常に私にとっての設計目標でした。最小限のデータディレクトリを備えた適切に正規化されたデータベースは、実際には非常に使いやすく、それをあきらめる方法はありませんでした。通常のメンテナンスと拡張により、6NF構造は時間の経過とともに変化し、データベースの新しいバージョンが定期的に公開されることに注意してください。間違いなく、6NFテーブルから5NF行を構築するために必要なSQL（5NFではすでに面倒）はさらに面倒です。ありがたいことに、それは完全に不要です。
完全な6NF-DDL-that-SQL-does-not-provideを特定したカタログがすでにあるので、必要に応じて、カタログを読み取るための小さなユーティリティを作成しました。
- 6NFテーブルDDLを生成します。
- 6NFテーブルの5NFビューを生成します。これにより、ユーザーは幸いにも彼らに気付かずにいることができ、5NFで持っていたのと同じ機能とパフォーマンスをユーザーに与えることができました。
- 6NF構造に対して動作するために必要な完全なSQL（テンプレートではなく、個別に用意されています）を生成し、コーダーが使用します。それらは、他の方法で要求される退屈な繰り返しから解放され、アプリのロジックに自由に集中できます。
5NFに存在する複雑さが解消され、5NFで拡張されたピボットの場合と同様に、非常に簡単に作成できるようになったため、ピボット用のユーティリティは作成しませんでした。その上、ほとんどのレポートツールはピボットを提供するので、クライアントに出荷する前にサーバーで実行する必要がある統計の大量の攪拌を含む機能を提供するだけで済みます。
3.5パフォーマンス
誰もが耐えるべき十字架を持っています。私はたまたまパフォーマンスに夢中になっています。私の5NFデータベースは良好に機能したので、本番環境に何かを配置する前に、必要以上に多くのベンチマークを実行したことを保証します。6NFデータベースは、5NFデータベースとまったく同じように機能しましたが、良くも悪くもありません。これは当然のことです。「複雑な」6NFSQLが実行するのは、5NF SQLが実行しない唯一のことであり、はるかに多くの結合とサブクエリを実行することです。
あなたは神話を調べなければなりません。
- 問題のベンチマークを行った（つまり、クエリの実行プランを調べた）人なら誰でも、Joins Cost Nothingはコンパイル時の解決策であり、実行時には効果がないことを知っているでしょう。
- はい、もちろん、結合されたテーブルの数。結合されるテーブルのサイズ。インデックスを使用できるかどうか。結合されているキーの配布。など、すべてが何かを要します。
- しかし、参加自体には費用はかかりません。
- 正規化されていないデータベースの5つの（大きい）テーブルに対するクエリは、正規化されている場合の同じデータベース内の10の（小さい）テーブルに対する同等のクエリよりもはるかに低速です。重要なのは、4つも9つの結合も費用がかからないということです。彼らはパフォーマンスの問題を理解していません。各Joinで選択されたセットは、その中に含まれています。
3.6メリット
無制限の柱状アクセス。これが6NFが本当に際立っているところです。まっすぐな列型アクセスは非常に高速であったため、特殊なDW構造から速度を取得するためにデータをデータウェアハウスにエクスポートする必要はありませんでした。
いくつかのDWについての私の調査では、完全ではありませんが、6NFが行うのとまったく同じように、行ではなく列ごとにデータを一貫して格納することが示されています。私は保守的であるため、6NFがDWを置き換えることを宣言するつもりはありませんが、私の場合は、DWの必要性を排除しました。
明らかにはるかに高速に実行された5NFでは利用できなかった6NFで利用可能な機能（例：ピボット）を比較することは公平ではありません。
これは私たちの最初の真の6NFデータベースであり（完全なカタログなどを備えています。必要な場合にのみ拡張された常に5NFであるのに対し、後で6NFであることが判明しました）、顧客は非常に満足しています。もちろん、納品後しばらくの間パフォーマンスを監視しており、次の6NFプロジェクトではさらに高速な柱状アクセス方法を特定しました。それは、私がそれを行うとき、DW市場に少しの競争をもたらすかもしれません。お客様の準備ができておらず、壊れていないものは修理いたしません。
3.7正確には、6NFについて、「悪い」とは何ですか？
誰もが同じように形式的、構造的、そして標準を順守して仕事に取り組むわけではないことに注意してください。したがって、私たちのプロジェクトから、すべての6NFデータベースが適切に機能し、保守が容易であると結論付けるのはばかげています。（他の実装を見て）すべての6NFデータベースのパフォーマンスが悪く、保守が難しいと結論付けるのも同じようにばかげています。災害。いつものように、どんな技術的な努力でも、結果として生じるパフォーマンスとメンテナンスの容易さは、関連するスキルセットに加えて、形式、構造、および標準への準拠に厳密に依存します。
3.8可用性
自分自身を暴露したり、「公開された参照」などの標準的な商慣行の境界を超えて何かを求めたりしないでください。顧客はオーストラリアの銀行であり、実装全体は機密情報です。しかし、私は訪問の見通しを自由に取ることができます。シドニーのオフィスでドキュメントを表示することもできます（コピーはできません）。方法論（公に利用可能な6NF教育を超えた構造と標準）とユーティリティは、当社独自の知的財産であり、割り当てに利用できます。この段階では、（a）プロジェクトの成功を合理的に保証する必要があり（評判を傷つけないため）、（b）成功したプロジェクトが1つでは不十分であるため、割り当ての一部としてのみ販売しています。それを「市場に出す準備ができている」として分類する成熟度。
私は、実際にIP（ドキュメント）を公開することなく、質問に答え、6NFカタログに関する有益な情報、機能するものと機能しないものに関するアドバイスなどを提供し続けることを嬉しく思います。また、適格なベンチマークを実行できることをうれしく思います。
4エンティティ属性値
開示：経験。私はこれらのいくつか、主に病院と医療システムを検査しました。私はそれらのうちの2つに修正割り当てを実行しました。海外のプロバイダーによる最初の配信は、素晴らしいものではありませんが、かなり適切でしたが、ローカルのプロバイダーによって実装された拡張機能は混乱していました。しかし、人々がこのサイトにreEAVについて投稿した災害はほとんどありません。数ヶ月の激しい作業でそれらはうまく修正されました。
4.1それは何ですか
私が取り組んできたEAVの実装は、第6正規形のサブセットにすぎないことは明らかでした。EAVを実装する人は、6NFの機能の一部（たとえば、DDLを変更せずに列を追加する機能）が必要なためにそうしますが、真の6NFを実装するための学術的知識、またはそれを実装および管理するための標準と構造を持っていません。安全に。元のプロバイダーでさえ、6NFについて、またはEAVが6NFのサブセットであることを知りませんでしたが、私が彼らに指摘したとき、彼らはすぐに同意しました。EAV、そして実際には6NFを効率的かつ効果的に提供するために必要な構造（カタログ、ビュー、自動コード生成）はEAVコミュニティで正式に識別されておらず、ほとんどの実装に欠けているため、EAVをろくでなしの息子第六正規形。
4.2 EAVについて、正確には「悪い」とは何ですか？
このスレッドや他のスレッドのコメントを見ると、そうです、EAVがうまくいかなかったのは惨事です。さらに重要なのは、（a）5NFで提供されるパフォーマンスが失われるほど悪い（6NFを忘れる）こと、および（b）複雑さからの通常の分離が実装されていないことです（コーダーとユーザーは面倒なナビゲーションを使用するように「強制」されます）。また、カタログを実装していなければ、あらゆる種類の予防可能なエラーを防ぐことはできません。
これはすべて、悪い（EAVまたはその他の）実装に当てはまる可能性がありますが、6NFまたはEAVとは何の関係もありません。私が取り組んだ2つのプロジェクトは、非常に適切なパフォーマンス（確かに、改善される可能性がありますが、EAVによるパフォーマンスの低下はありませんでした）と、複雑さの分離が良好でした。もちろん、それらは私の5NFデータベースや私の本当の6NFデータベースの品質やパフォーマンスにはほど遠いものでしたが、EAVコミュニティ内に投稿された問題の理解のレベルを考えると、十分に公平でした。これらは災害ではなく、これらのページでEAVであると主張されている標準以下のナンセンスです。
5つのヌル
ヌル問題と呼ばれるよく知られた文書化された問題があります。それだけでエッセイに値する。この投稿では、次のように言うだけで十分です。
- 問題は、実際にはオプションの値または欠落している値です。ここで考慮すべきことは、NullとNullable列がないようなテーブル設計です。
- 欠落値を除外するためにNulls/No Nulls / 6NFを使用するかどうかに関係なく、そのためにコーディングする必要があるため、実際には問題ではありません。問題は、欠落している値を処理することです。これは回避できません。
- もちろん、ヌルの問題を排除する純粋な6NFを除いて
- 欠落値を処理するためのコーディングは残ります
- ヌルはパフォーマンスにとって悪いニュースであり、私たちの多くは数十年前にデータベースでヌルを許可しないことを決定しました（渡されたパラメーターと結果セットのヌルは、欠落している値を示すために問題ありません）
- これは、欠落値を示す一連のNull置換とブール列を意味します
- ヌルを指定すると、固定されたlen列が変数lenになります。トラバーサルまたはダイブ中に、すべてのインデックスエントリにアクセスするたびに少しの「アンパック」を実行する必要があるため、可変len列をインデックスで使用しないでください。
6ポジション
私はEAVや6NFの支持者ではなく、品質と基準の支持者です。私の立場は：
常に、あらゆる方法で、あなたが知っている最高水準であなたがしていることは何でもしなさい。
リレーショナルデータベース（私にとっては5NF）の場合、第3正規形への正規化は最小限です。DataTypes、宣言型参照整合性、トランザクション、正規化はすべてデータベースの重要な要件です。それらが欠落している場合、それはデータベースではありません。
- 「パフォーマンスのために非正規化」する必要がある場合は、深刻な正規化エラーが発生し、設計は正規化されていません。限目。逆に、「非正規化」しないでください。正規化と正規化を学習してください。
余分な作業をする必要はありません。5NFで要件を満たすことができる場合は、それ以上実装しないでください。オプションの値、またはDDLを変更せずに列を追加する機能、またはNull問題を完全に排除する機能が必要な場合は、それらを必要とするテーブルにのみ6NFを実装してください。
これを行う場合、SQLが6NFの適切なサポートを提供しないという事実だけのために、以下を実装する必要があります。
- シンプルで効果的なカタログ（列の取り違えやデータの整合性の喪失は単純に受け入れられません）
- VIEWSを介した6NFテーブルへの5NFアクセスにより、ユーザー（および開発者）を障害のある（「複雑な」ではない）SQLから分離します。
- ユーティリティを作成または購入して、面倒なSQLを生成して6NFテーブルから5NF行を作成し、同じものを作成しないようにします。
- 測定、監視、診断、および改善します。パフォーマンスに問題がある場合は、（a）正規化エラーまたは（b）コーディングエラーのいずれかが発生しています。限目。いくつかの手順をバックアップして修正します。
EAVを使用する場合は、6NFであることが認識され、上記のように適切に実装されます。そうすれば、プロジェクトは成功し、保証されます。そうでない場合は、犬の朝食が保証されます。
6.1フリーランチのようなものはありません
その格言は言及されていますが、実際には誤用されています。それが実際に深く適用される方法は上記のとおりです。6NF/EAVの利点が必要な場合は、それを取得するために必要な作業（カタログ、標準）も進んで行う方がよいでしょう。もちろん、当然の結果として、あなたが仕事をしなければ、あなたは利益を得ることができません。データ型の「喪失」はありません。値ドメイン; 外部キー; チェック; ルール。パフォーマンスに関しては、6NF / EAVにはパフォーマンスのペナルティはありませんが、標準以下の作業には常にかなりのパフォーマンスのペナルティがあります。
7特定の質問
ついに。上記のコンテキストを十分に考慮し、それが小さなチームによる小さなプロジェクトであることを考えると、疑問の余地はありません。
EAV（またはそのことについては6NF）を使用しないでください
NullまたはNullable列を使用しないでください（パフォーマンスを低下させたい場合を除く）
一般的な支払い列には単一の支払いテーブルを使用してください
各PaymentTypeの子テーブルには、それぞれ特定の列があります
すべて完全に型キャストされ、制約されています。
この「別のrow_id」ビジネスとは何ですか？鹿なのかワシなのかを確認せずに、動くものすべてにIDを付ける人がいるのはなぜですか。いいえ 。子供は扶養されている子供です。関係は1：1です。子のPKは、共通の支払いテーブルである親のPKです。これは通常のスーパータイプ-サブタイプクラスターであり、差別化要因はPaymentTypeCodeです。サブタイプとスーパータイプはリレーショナルモデルの通常の部分であり、データベースや優れたモデリングツールで完全に対応されています。
確かに、リレーショナルデータベースの知識がない人は、30年後にそれを発明したと考えており、面白い新しい名前を付けています。さらに悪いことに、彼らは故意にそれを再ラベル付けし、それを自分のものとして主張します。少しの教育と専門家としてのプライドを持った貧しい人々が無知や詐欺を暴露するまで。どれかはわかりませんが、そのうちの1つです。確認しやすい事実を述べているだけです。
A.コメントへの回答
A.1アトリビューション
「私はRMに忠実である」と述べ、「業界の巨人」に言及して、IT専門家はそれが何を意味するのかを理解していると思いました。謙虚な謝罪。
- 私には個人的または私的なまたは特別な定義はありません。以下の定義（命令など）に関するすべてのステートメント：
- 正規化、
- 通常の形式、および
- リレーショナルモデル。
。
EFCoddおよびCJDateによる多くの元のテキストを参照してください（Webでは無料で入手できません）
。
最新のものは、CJ Date、Hugh Darwen、NikosALorentzosによるTemporalDataとRelationalModel
です。
そしてそれらのテキストだけ
です。
「私は巨人の肩の上に立っています」
。
- 上記の本質、本文、実装に関するすべてのステートメント（主観的、一人称など）は経験に基づいています。上記の原則と概念を、アメリカとオーストラリアの大手金融機関で32年以上にわたり、商業組織（サラリーコンサルタントまたはコンサルタント会社の運営）として実施しています。
- これには、標準以下または非リレーショナルの実装を修正または置換する多数の大規模な割り当てが含まれます。
。
- 6番目の通常の形式に対するヌルの問題タイトルに関連する無料で入手可能なホワイトペーパー（ヌルの問題だけを定義する
ものではありません）は、 http ：//www.dcs.warwick.ac.uk/~にあります。 hugh / TTM/Missing-info-without-nulls.pdf。
。
6NFの「一言で言えば」定義（他のNFで経験した人にとって意味がある）は、p6にあります。
A.2証拠の裏付け
冒頭で述べたように、この投稿の目的は、コミュニティへのサービスとして、このコミュニティに蔓延している誤った情報に対抗することです。
特定の声明が特定された場合、上記の原則の実施に関してなされた証拠を裏付ける声明を提供することができます。そして、この投稿が応答である他の人によって投稿された誤ったステートメントと同じ程度に、同様に証明されます。パンの戦いがある場合は、競技場が水平であることを確認しましょう
これが私がすぐに手を置くことができるいくつかのドキュメントです。
a。大銀行
これは、この投稿で明示的に理由が示され、目標が実現されたため、最良の例です。彼らはSybaseIQ（DW製品）の予算を持っていましたが、プロジェクトが終了したときのレポートは非常に速かったので、必要ありませんでした。貿易分析統計は、上記の6NFであることが判明した私の5NFとピボット拡張でした。コメントで尋ねられたすべての質問は、次の点を除いて、ドキュメントで回答されていると思います。-
行数：
-古いデータベースは不明ですが、他の統計から推定できます
-新しいデータベース= 100Mを超える20テーブル、4テーブルを超える10B。
b。小規模金融機関パートA
パートB-肉
パートC-参照図
パートD-付録、前後のインデックスの監査（インデックスごとに1行）
4つのドキュメントに注意してください。詳細なインデックスの変更を検査したい人のためだけの4番目。彼らは、地元のサプライヤーが廃業したために変更できなかったサードパーティのアプリに加えて、変更できるが変更したくない120％の拡張機能を実行していました。新しいバージョンのSybaseにアップグレードしたために呼び出されました。これは、はるかに高速で、さまざまなパフォーマンスのしきい値をシフトし、デッドロックをほとんど発生させませんでした。ここでは、サーバー内のすべてを完全に正規化しました。デッドロックを解消することを目的とした（事前に保証された）dbモデル（申し訳ありませんが、ここでは説明しません。「非正規化」の問題について議論する人々は、これについてピンク色になります）。これには、別の投稿の主題である「パフォーマンスのためにテーブルをアーカイブデータベースに分割する」の逆転が含まれていました（はい、新しい単一のテーブルは、2つのこぼれたテーブルよりも高速に実行されました）。この演習は、MS SQLServer[リライトバージョンを挿入]にも適用されます。
c。イェールニューヘブン病院
それは彼らの教育病院であるイェール医科大学です。何年も彼らをサポートしてきました。Sybase上のサードパーティアプリ。統計の問題は、指定されたテスト時間にのみスナップショットを収集していた時間の80％ですが、一貫性のある履歴がないため、新しい一貫性のある統計と比較する「前のイメージ」がありません。同じグラフでUnixとSybaseの内部統計を自動化された方法で取得できる他の共同経営者を私は知りません。これで、ネットワークがしきい値になります（読者は、それが良いことだと理解していると信じてください）。
そもそも何か、それは公開のためにクリアされました。OK、「「非正規化」によってパフォーマンスが向上する」などの概念を裏付ける証拠をいくつか用意しましょう。あなたの番です。