多くの設計がRDBMSの正規化を無視するのはなぜですか？
意思決定段階では、正規化が最初の検討事項ではなかった多くのデザインを目にしました。
多くの場合、これらのデザインには30列を超える列が含まれており、主なアプローチは「すべてを同じ場所に置くこと」でした。
私が覚えていることによると、正規化は最初の最も重要なことの1つです。
編集：
優れた設計者や専門家が非正規化された設計を選択し、経験のない開発者が反対の設計を選択するのは本当ですか？正規化を念頭に置いて設計を開始することに反対する議論は何ですか？
このQ＆Aスレッドの興味深い点は、実際には3つの質問があることです。誰もが別のものに答えており、ほとんど誰も最初のものに答えていません：
- 一部のデータベースが正規化されていないなのはなぜですか？
- なぜ/いつ正規化データベースを非正規化にする必要がありますか？
- 有害またはそもそも正規化する必要がないのはどのような場合ですか？
アラートの読者は、これらが非常に異なる質問であることに気付くでしょう。私は、あまり詳細を避けながら、それぞれに個別に回答するようにします。 「多すぎる」ということは、これが、正規化に賛成または反対するさまざまな議論のメリットをめぐって長い討論を行う適切な文脈ではないと私が思うことです。私は単にそれらの議論が何であるかを説明し、おそらくいくつかの警告をリストし、それらが出てきた場合に、より具体的な質問に対する哲学を保存します。
また、この回答では"normalization"は"BCNF、3NF、または少なくとも2NF"を意味すると想定しています。これは、設計者が一般的に達成しようとしている正規化のレベルだからです。 4NFや5NFのデザインを見ることはまれです。それらは確かに不可能な目標ではありませんが、ドメインについてかなり多くの知識が必要なrepresentationではなく、関係のsemanticsに関係しています。
したがって、上向きと上向き：
1.野生の一部のデータベースが正規化されていないのはなぜですか？
これに対する答えcouldは「そうであってはならないから」ですが、その仮定をすぐに行うことは、かなりお粗末な探偵の仕事です。何であれ、そうあるべきだと常に考えていたら、社会としてはあまり進歩しません。
そもそもデータベースが正規化されない本当の理由はもっと複雑です。これが私が遭遇した上位5つです。
それを設計した開発者はわからなかったまたはわからなかった正規化する方法。これの強力な証拠は、 すべてにvarchar列を使用する または 意味のないテーブル名と列名のスパゲッティの混乱 のような、他の多くの付随する悪い設計選択の形になります。そして確かに、私はTDWTFの記事と同じくらいひどい「実際の」データベースを見てきました。
それを設計した開発者気にしなかったまたは積極的に原則の正規化に反対。ここでは、コンテキスト分析に基づいて正規化しないように意図的に決定された事例ではなく、正規化が多少なりとも理解されているが、単に無視されたり、習慣から排除されたチームや企業について言及していることに注意してください。繰り返しますが、驚くほど一般的です。
ソフトウェアはBrownfieldプロジェクトとして実行されました。多くの純粋主義者は、正規化されていない技術理由ではなく、この完全に正当なビジネス理由を無視します。場合によっては、新しいデータベースをゼロから実際に設計することができず、既存のレガシースキーマにボルトで固定する必要があり、その時点で正規化しようとすると、多大な労力がかかります。 3NFは1971年まで発明されておらず、一部のシステム（特に財務/会計システム）のルーツはそれよりもはるかに古くなっています。
データベースは元々正規化されていましたが、長期間にわたる小さな変更の蓄積、および/または広く分散したチームが微妙な形式の複製やその他を導入しました元々存在していたあらゆる正規形の違反。言い換えると、正規化の損失は偶然であり、リファクタリングに費やされた時間は少なすぎました。
意図的なビジネス上の決定は、ビジネス分析やデータベース設計に時間を費やすことなく、単に「やり遂げる」ために行われました。これはしばしば偽の経済であり、最終的には 技術的負債 の高まる形になりますが、少なくとも当時知られていた情報に基づいて、時には合理的な決定になります-forたとえば、データベースはプロトタイプとして意図されていたかもしれませんが、時間の制約やビジネス環境の変化により、最終的に本番用に昇格されました。
2.なぜ/いつ、正規化されたデータベースを非正規化する必要がありますか？
この議論は、データベースisが最初に正規化されたときにしばしば発生します。パフォーマンスが悪いか、クエリ（結合）に多くの重複があり、チームは現在のデザインで可能な限り行ったと正しくまたは間違って感じています。正規化改善パフォーマンスほとんどの時間であり、正規化が機能しているように見えるときに過剰な結合を排除するいくつかオプションがあることに注意することが重要ですあなたに対して、それらの多くは単に非正規化されたモデルに変更するよりも侵襲性が低くリスクが高いです：
最も一般的な問題領域をカプセル化するインデックス付きビューを作成します。最新のDBMSは、挿入可能または更新可能にすることができます（例：SQL Server
INSTEAD OFトリガー）。これは、基になるテーブル/インデックスのDMLステートメントにはわずかなコストがかかりますが、失敗することはほとんど不可能であり、維持するコストもほとんどないため、一般的に最初に試すオプションです。もちろん、すべてのクエリをインデックス付きビューに変換できるわけではありません-aggregateクエリが最も厄介です。次の項目に進みます...トリガーによって自動的に更新される非正規化集計テーブルを作成します。これらのテーブルは、正規化されたテーブルに追加で存在し、一種の [〜＃〜] cqrs [〜＃〜] モデルを形成します。最近人気のある別のCQRSモデルは、pub/subを使用してクエリモデルを更新することです。これにより、非同期の利点が得られますが、データが古くなる可能性のある非常にまれなインスタンスには適さない場合があります。
場合によっては、インデックス付きビューが不可能であり、トランザクションレートとデータ量が多すぎて、許容できるパフォーマンスでトリガーを許可できず、クエリは常にリアルタイムデータを返す必要があります。これらの状況はまれです-高周波取引や法執行機関/インテリジェンスデータベースなどに当てはまる可能性があると思いますが、canは存在します。これらの場合、元のテーブルを非正規化する以外に選択肢はありません。
3.そもそも正規化することが有害または不必要なのはどのような場合ですか。
実際、ここにはいくつかの良い例があります：
データベースがレポート/分析にonly使用されている場合。通常、これはOLTPに使用される正規化データベース追加があり、ETLまたはメッセージングを介して分析データベースに定期的に同期されることを意味します。
正規化されたモデルを適用する場合、受信データの不必要に複雑な分析が必要になります。この例としては、いくつかの外部システムまたはデータベースから収集された電話番号を保存する必要があるシステムがあります。あなたはcould通話コードと市外局番を非正規化しますが、さまざまな可能な形式、無効な電話番号、バニティナンバー（1-800-GET-STUFF）をすべて考慮しなければなりません。異なるロケールについて言及します。通常、それは価値があるよりも問題が多く、市外局番自体に特定のビジネスニーズがない限り、電話番号は通常1つのフィールドに入力されます。
リレーショナルデータベースが主に存在し、追加の非リレーショナルデータベースのトランザクションサポートを提供する場合。たとえば、プライマリデータがRedisやMongoDBなどに格納されているときに、リレーショナルデータベースをメッセージキューとして使用したり、トランザクションや佐賀のステータスを追跡したりできます。つまり、データは「制御データ」です。通常、実際には存在しないデータを正規化しても意味はありませんビジネスデータ。
物理データベースを共有するサービス指向アーキテクチャ。これは少し奇妙なことですが、真のSOAでは、サービスがお互いのデータを直接クエリすることが許可されていないため、willはデータを物理的に複製する必要がある場合があります。 happenが同じ物理データベースを共有する場合、データはappear正規化されません-一般に、各サービスが所有するデータis他の緩和要素のいずれかが配置されていない限り、まだ正規化されています。たとえば、BillingサービスはBillエンティティを所有しているかもしれませんが、Accountingサービスはその年の収益に含めるために、Bill DateとAmountを受け取って保存する必要があります。
記載していない理由は他にもあると思います。本質的に私が得ているのは、それらは非常に具体的であり、実際に登場するとかなり明白になるということです。 OLAPデータベースは想定スタースキーマを使用するため、SOAは想定が重複するためなどです。 -単に正規化では機能しない既知のアーキテクチャモデル、その後正規化しない;一般的に言えば、アーキテクチャモデルはデータモデルよりも優先されます。
そして最後の質問に答えるには：
優れたアーキテクトとエキスパートが非正規化されたデザインを選択し、経験のない開発者が反対のデザインを選択するのは本当ですか？正規化を念頭に置いて設計を開始することに反対する議論は何ですか？
いいえ、それは完全であり、完全にBSです。 also B.S.エキスパートは常に正規化設計を選択します。 エキスパートはマントラに従うだけではありません。彼らは研究、分析、議論、明確化、反復を行い、次に、最も意味のあるアプローチを選択します彼らの特定の状況。
3NFまたはBCNFデータベースは、世界中の何万ものプロジェクトで試行され、成功していることが証明されているため、通常は分析に適しています開始点。Cも同様です。つまり、すべての新しいプロジェクトでCを自動的に使用します。実際の状況では、モデルにいくつかの変更を加えるか、別のモデルを完全に使用する必要があります。 inになるまでわかりません。
質問といくつかの回答に組み込まれている仮定は、正規化は同義の優れたデータベース設計であるということです。これは実際にはしばしばそうではありません。データ要素間の関係に関する「ビジネスルール」を実施するためにデータベースに大きく依存している場合、正規化は特定の設計目標セットと要件を達成する1つの方法です。
正規化には、いくつかの重要な利点があります。
- 冗長データの量を最小限に抑えます。
- データベースの組み込み整合性メカニズム（外部キー制約、一意性制約）を活用してデータの整合性を確保できる範囲を最大化します。
- 1行あたりの列数を減らし、IOの効率を向上させる場合があります。幅の広い行の取得には時間がかかります。
とはいえ、非正規化する正当な理由はたくさんあります。
- 特に分析のパフォーマンスは、正規化によって損なわれる可能性があります。リレーショナルデータベースに対する分析では、非正規化 次元モデル が標準的なアプローチです。
- データベース内でデータの整合性を強制することの利点は衰退し始めています。ビジネスルールを適用することが多いオブジェクト指向の中間層に焦点を当てた開発が増えるにつれ、データベースのリレーショナル制約への依存はそれほど重要ではなくなりました。
- 他の人が述べたように、正規化は関連データを取得するために必要なクエリを複雑にします。
正規化が優れたデザインの兆候であることは明らかではありません。場合によっては、正規化は、ストレージスペースが貴重で、ビジネスルールのエンコードの責任の多くがデータベースに存在していた時代の成果物です（2層のクライアントサーバーアプリケーションについて考えてください。ストアドプロシージャ）。多くのプロジェクトは、データベース設計の原則をよく理解していないのではなく、適切なアーキテクチャ上の決定に基づいて正規化から離れているのかもしれません。
上記のコメントで参照されたJeff Atwoodによる記事は、いくつかの優れた詳細な議論を提供します "たぶん正規化は正常ではない" 。
- 多くの開発者は、正規化について、またはデータモデリングやデータベースについて知りません。
- 一部のジョブでは、それは本当に重要ではありません。
- たとえば、特定の難しいワークロードを適切に実行できるようにするなど、正規化を解除するのに本当に良い理由がある場合があります。
- リレーショナルデータベースの概念は、1990年代と2000年代に比べて最近流行が少なくなっています。開発者は、非常に合理的であると主張したとしても、ファッションに影響される傾向があります。味について議論しても意味がない。
歴史的にも、正規化はほぼ宗教的な議論の領域であるので、私はもっともっと言うのをためらいます。
大規模なプロジェクト、特にメインフレームのプロジェクトでは、これは当てはまりません。実際、求人サイトを検索すると、データモデラーの役職がいくつか表示されます。また、単一のテーブルに多くの列があることは、正規化に反しません。それにもかかわらず、あなたの観察はいくつかのプロジェクトに有効です。
データベースの設計は、高品質のシステムを構築するために必要なスキルの1つです。そうは言っても、一部の開発者はデータベース設計について十分に知らなくても、データモデリングとデータベース設計のタスクに割り当てられます。一部のプロジェクトでは、データモデリングをスキップします。多くのプロジェクトに焦点を当てているのは、主にコーディングとフロントエンド設計です。
データベースの設計が悪いもう1つの要因は、第4 NF、第5 NFなどの場合、特に正規化は簡単なトピックではないという事実です。私が見たほとんどの本は、これらの形式を明確に説明できませんでした。通常、悪い例と理論が多すぎます。これにより、トピックの人気が低くなります。
データベース設計のエラーは、探したり、テスト中に発生したりしない限り、発生しにくいものです。データベースの設計品質の基準がないと、エラーが発生しやすくなります。
さらに、一部のプロジェクトは厳密な開発方法論（データベース設計を促進する方法論）に従っていないため、ビジネスアナリスト、開発者、およびDBAの間で責任が混合され、タスクが失われます。開発者はOOとUMLで話しますが、DBAはDDで話し、一部はERDで話します。おそらく多くはUMLまたはOOを取得しません。要するに、知識の不足、明確なリソースの不足、不足データを記述する統一言語の欠如と方法論の欠如は、すべてのせいです。