多くのデザインがRDBMSの正規化を無視するのはなぜですか？

意思決定段階では、正規化が最初の考慮事項ではないという多くの設計を見ました。

多くの場合、これらの設計には30を超える列が含まれており、主なアプローチは「すべてを同じ場所に置く」ことでした

私が覚えていることによると、正規化は最初の最も重要なことの1つです。

編集：

優秀なアーキテクトや専門家が非正規化されたデザインを選択し、未経験の開発者が反対を選択するというのは本当ですか？正規化を念頭に置いて設計を開始することに対する議論は何ですか？

このQ＆Aスレッドの興味深い点は、実際には3つの質問があることです。誰もが別の質問に答えましたが、最初の質問にはほとんど誰も答えていません。

1. なぜ一部のデータベースは正規化されていないのですか？
2. なぜ/いつ正規化されたデータベースは非正規化されるべきですか？
3. そもそも正規化することは、どのような状況で有害または不要ですか？

アラートリーダーは、これらが非常に異なる質問であることに気付くでしょう。あまりにも詳細を避けながら、それぞれに個別に答えようとします。「多すぎる」とは、これが、正規化に賛成または反対のさまざまな議論のメリットに関する拡張討論を実施する適切なコンテキストではないと思うことを意味します。これらの引数が何であるかを説明し、いくつかの警告を列挙し、さらに具体的な質問があれば、その哲学を保存します。

また、この回答では、「正規化」は「BCNF、3NF、または少なくとも2NF」を意味すると想定しています。これは、設計者が一般に達成を目指す正規化のレベルだからです。4NFまたは5NFのデザインはほとんど見られません。確かに不可能な目標ではありませんが、彼らは単なる表現ではなく関係のセマンティクスに関心を持っています。これには、ドメインに関するかなり多くの知識が必要です。

したがって、前方および上方：

1.なぜ一部のデータベースは正規化されていないのですか？

これに対する答えは「あるべきではないから」ということかもしれませんが、その仮定を即座に行うことは、かなり気の毒な探偵の仕事です。何であれ、あるべきであるという前提で常に運営していれば、社会としての進歩はあまりありません。

そもそもデータベースが正規化されない本当の理由はもっと複雑です。ここに私が出会ったトップ5があります：

• それを設計し、開発者は知りませんでしたか理解していなかった正規化する方法について説明します。これの強力な証拠は、すべてにvarchar列を使用したり、意味のないテーブルと列名のスパゲッティ混乱を持っているなど、他の多くの付随する悪い設計選択の形になります。確かに、TDWTFの記事にあるものとまったく同じくらい「悪い」データベースを見てきました。

• それを設計した開発者は、原則として気にしないか、正規化に積極的に反対しました。ここで、コンテキスト分析に基づいて正規化しないという意図的な決定が行われた例についてではなく、正規化が多少なりとも理解されているが、単に無視されるか習慣から排除されているチームまたは企業について説明していることに注意してください。繰り返しますが、驚くほど一般的です。

• ソフトウェアは、Brownfieldプロジェクトとして行われました。多くの純粋主義者は、正規化しない技術的な理由ではなく、この完全に合法的なビジネスを無視しています。実際に新しいデータベースを最初から設計できない場合があります。既存のレガシースキーマに固定する必要があり、その時点で正規化しようとすると、非常に多くの苦痛が伴います。3NFは1971年まで発明されませんでした。一部のシステム（特に金融/会計システム）のルーツはそれよりもはるかに古くなっています。

• データベースは元々正規化されていましたが、長期間にわたる小さな変更の蓄積および/または広く分散したチームにより、元々存在していた通常の形式の微妙な形式の複製やその他の違反が導入されました。言い換えれば、正規化の喪失は偶発的であり、リファクタリングに費やす時間が少なすぎます。

• ビジネス分析やデータベース設計に時間を費やすことなく、「やる」ことを意図したビジネス上の意思決定が行われました。これは多くの場合、誤った経済であり、最終的には技術的負債の増大する形になりますが、少なくともその時点で知られている情報に基づいた合理的な決定である場合があります-たとえば、データベースはプロトタイプとして意図されていたが、結局は時間的制約やビジネス環境の変化により、実稼働での使用が促進されています。

2.正規化されたデータベースを非正規化する理由と時期は？

この議論は、データベースが最初に正規化されるときにしばしば起こります。パフォーマンスが低いか、クエリ（結合）に多くの重複があり、チームは、正しいか間違っているかを、現在の設計でできる限り進んだと感じています。正規化はほとんどの場合パフォーマンスを向上させることに注意することが重要です。また、正規化が機能していないように見える場合に過剰な結合を排除するいくつかのオプションがあります。

• 最も一般的な問題領域をカプセル化するインデックス付きビューを作成します。最新のDBMSは、挿入可能または更新可能にすることができます（SQL Server INSTEAD OFトリガーなど）。これは、基礎となるテーブル/インデックスのDMLステートメントに多少のコストがかかりますが、めちゃくちゃにすることはほぼ不可能であり、維持する費用がほとんどないため、一般的に最初に試すべきオプションです。もちろん、すべてのクエリをインデックス付きビューに変換できるわけではありません。集約クエリは最も面倒です。次の項目に進みます...

• トリガーによって自動的に更新される非正規化集計テーブルを作成します。これらのテーブルは、正規化されたテーブルに加えて存在し、一種のCQRSモデルを形成します。最近人気のある別のCQRSモデルは、pub / subを使用してクエリモデルを更新することです。これにより、非同期性の利点が得られますが、データを失効させることができない非常にまれな場合には適しません。

• インデックス付きビューが不可能な場合、トランザクションレートとデータボリュームが高すぎて許容可能なパフォーマンスでトリガーを許可できない場合があり、クエリは常にリアルタイムデータを返す必要があります。これらの状況はまれです-高周波取引や法執行機関/インテリジェンスデータベースなどに適用される可能性があると推測しますが、存在する可能性があります。これらの場合、元のテーブルを非正規化する以外に選択肢はありません。

3.そもそも正規化することは、どのような状況で有害または不必要ですか？

実際、ここにはいくつかの良い例があります。

• データベースがレポート/分析のみに使用されている場合。通常、これは、OLTPに使用される追加の正規化されたデータベースがあることを意味し、ETLまたはメッセージングを介して分析データベースに定期的に同期されます。

• 正規化されたモデルを適用する場合、受信データの不必要に複雑な分析が必要になります。これの例は、いくつかの外部システムまたはデータベースから収集された電話番号を保存する必要があるシステムです。呼び出しコードと市外局番を非正規化することもできますが、異なるロケールは言うまでもなく、さまざまな可能な形式、無効な電話番号、バニティ番号（1-800-GET-STUFF）をすべて考慮する必要があります。通常、それは価値があるよりも面倒であり、電話番号は通常、市外局番の特定のビジネスニーズがない限り、単一のフィールドに押し込まれます。

• リレーショナルデータベースが主に、追加の非リレーショナルデータベースのトランザクションサポートを提供するためにある場合。たとえば、プライマリデータベースがRedisやMongoDBなどに保存されているときに、リレーショナルデータベースをメッセージキューとして使用したり、トランザクションやサガのステータスを追跡したりする場合があります。つまり、データは「制御データ」です。通常、実際にはビジネスデータではないデータを正規化しても意味がありません。

• 物理データベースを共有するサービス指向アーキテクチャ。これは少し奇妙ですが、真のSOAでは、サービスが互いのデータを直接照会することが許可されていないため、データを物理的に複製する必要がある場合があります。彼らがした場合に起こる同じ物理データベースを共有するために、データがします表示される正規化されていない-しかし、一般的に、個々のサービスによって所有データがされ、他の問題を緩和する要素の一つが所定の位置にある場合を除き、まだ正常化しました。たとえば、請求サービスがBillエンティティを所有している場合でも、会計サービスはその年の収益に含めるために請求日と金額を受け取り、保存する必要があります。

リストに載っていない他の理由があると確信しています。私が本質的に得ているのは、それらが非常に具体的であり、実際に出てきたときにかなり明白になるということです。OLAPデータベースがされているはずの使用スタースキーマに、SOAををしているはずあなたは、単に正規で仕事をしないことはよく知られているアーキテクチャモデルで作業している場合など、いくつかの重複を、持っている、あなたは正規化しません。一般的に、アーキテクチャモデルはデータモデルよりも優先されます。

そして最後の質問に答えるために：

優秀なアーキテクトや専門家が非正規化されたデザインを選択し、未経験の開発者が反対を選択するというのは本当ですか？正規化を念頭に置いて設計を開始することに対する議論は何ですか？

いいえ、それは完全で完全なBSです。また、専門家が常に正規化されたデザインを選択するのも BSです。専門家はマントラに従うだけではありません。彼らは調査、分析、議論、明確化、反復し、特定の状況に最も適したアプローチを選択します。

3NFまたはBCNFデータベースは、世界中の何万ものプロジェクトで試行され、成功していることが証明されているため、通常は分析の開始点として適していますが、Cも同様です。新たなプロジェクト。実際の状況では、モデルの変更や、異なるモデルの使用が必要になる場合があります。あなたがしているまで、あなたは知らないでいる状況。

質問に組み込まれた仮定といくつかの答えでは、正規化は同義の優れたデータベース設計であるということです。これは、実際にはそうではないことがよくあります。正規化は、データ要素間の関係について「ビジネスルール」を実施するためにデータベースに大きく依存している場合、特定の一連の設計目標と要件を達成する1つの方法です。

正規化には、いくつかの重要な利点があります。

1. 冗長データの量を最小限にします。
2. データベースの組み込み整合性メカニズム（外部キー制約、一意性制約）を活用してデータの整合性を確保できる範囲を最大化します。
3. 行ごとの列数を減らして、場合によってはIOの効率を上げます。幅の広い行の取得には時間がかかります。

ただし、非正規化する正当な理由はたくさんあります。

1. 特に分析のパフォーマンスは、正規化によって損なわれる可能性があります。リレーショナルデータベースに対する分析では、非正規化ディメンションモデルが標準的なアプローチです。
2. データベース内でデータの整合性を強制する利点は、衰退し始めています。多くの場合、ビジネスルールを施行するオブジェクト指向の中間層に焦点を当てた開発が行われているため、データベース内のリレーショナル制約への依存はそれほど重要ではありません。
3. 他の人が述べたように、正規化は関連データを取得するために必要なクエリを複雑にします。

正規化が優れた設計の兆候であることは明らかではありません。場合によっては、正規化は、ストレージスペースが貴重であり、ビジネスルールをエンコードする責任の多くがデータベースに存在していたときのアーティファクトです（すべてではないにしてもほとんどのビジネスロジックを持つ2層のクライアントサーバーアプリケーションについて考えてください）ストアドプロシージャ）。多くのプロジェクトは、データベース設計の原則を十分に把握しているのではなく、適切なアーキテクチャ上の決定に基づいて正規化から遠ざかっている可能性があります。

上記のコメントで参照されているJeff Atwoodの記事は、いくつかの優れた詳細な議論を提供します- 「たぶん正規化は正常ではない」。

1. 多くの開発者は、正規化について、またはデータモデリングやデータベースについて知らないか、気にしません。
2. いくつかの仕事では、それは本当に重要ではありません。
3. たとえば、特定の困難なワークロードのパフォーマンスを向上させるなど、非正規化を行う正当な理由がある場合があります。
4. リレーショナルデータベースの概念は、1990年代および2000年代に比べて最近ではあまり流行していません。開発者は、非常に合理的であると主張する場合でも、ファッションの影響を受ける傾向があります。味について議論する意味はありません。

正規化は、歴史的にも、宗教的議論に近い領域であるため、さらに多くのことを言うのをためらいます。

大規模なプロジェクト、特にメインフレームのプロジェクトでは、そうではありません。実際、求人サイトを検索すると、データモデラーのポジションがいくつか表示されます。また、1つのテーブルに多数の列を配置しても、正規化に反することはありません。それにもかかわらず、あなたの観察はいくつかのプロジェクトに有効です。

データベース設計は、品質システムを構築するために必要なスキルの1つです。そうは言っても、一部の開発者はデータベース設計について十分に知らず、データモデリングとデータベース設計のタスクに割り当てられます。プロジェクトによっては、データモデリングをスキップすることさえあります。多くのプロジェクトの焦点は、主にコーディングとフロントエンドの設計です。

貧弱なデータベース設計のもう1つの要因は、4番目のNF、5番目のNFなどに関しては、正規化は特に些細なトピックではないという事実です。通常、悪い例と理論が多すぎます。これにより、トピックの人気が低くなります。

データベース設計のエラーは、探したりテスト中に遭遇したりしない限り、発生しにくいものです。データベース設計の品質に関する標準がないと、エラーが発生しやすくなります。

さらに、一部のプロジェクトは厳密な開発方法（データベース設計を促進する方法）に従っていないため、ビジネスアナリスト、開発者、DBAの間で責任が混ざり、タスクが失われます。開発者はOOとUMLで話しますが、DBAはDDで話し、一部はERDで話しますが、おそらく多くはUMLまたはOOを手に入れません。要するに、知識の不足、優れた明確なリソースの不足、データを説明するための統一された言語の不足、および方法論の不足はすべて責任があります。