何年にもわたって、データモデラーおよびデータベースアーキテクトとして働いていた私は、データのモデリングと開発中に従わなければならないいくつかのルールがあることに気づきました。ここでは、役立つことを願っていくつかのヒントを説明します。重要度や一般性の順にリストするのではなく、プロジェクトのライフサイクル中に発生する順序でヒントをリストしました。
1。事前の計画
計画に失敗すると失敗する予定です。
Alan Lakein
私が見た問題の1つは、ソフトウェア開発と同時にデータモデリングが行われる場合です。これは、青写真を完成させる前に基盤を構築するようなものです。以前は、計画は開発を開始する前の明らかなステップのようでした。開発チームは、設計者が設計図なしで建物を建設しないのと同じように、計画なしでデータベースを作成することはありません。
アプリケーション開発では、データの性質を理解することが重要です。
開発者が「コーディングを開始」できるように、計画はしばしば無視されます。プロジェクトが開始され、問題が発生したときに、それらに対処するためのスケジュールに余裕があります。開発者は、後で修正することを目的としてショートカットを使用しますが、これが発生することはめったにありません。
注意深い計画とは、一緒にハッキングされない適切なデータベースを確実に作成する方法です。プロセスに必要なデータに事前に対応するために時間と労力を費やさない場合は、後で、再加工、交換、または廃棄する必要のあるデータベースで料金を支払うことになります。
計画が常に行われるとは限らない場合でも、多くのデータモデラーはこれらのガイドラインに従います。すべての設計ニーズを事前に予測できるわけではありませんが、ほとんどのモデラーは、データとその使用法を理解するために努力する価値があると考えています。分析レポートの作成が必要な場合は、トランザクション処理の設計は必要ありません。
時が変わった;アジャイル手法が普及しているため、データベースチームはデータモデリングへのアプローチを再考する必要があります。アジャイルでは、エンティティ関係図の代わりにユースケースのドメインモデルが使用されます。ただし、計画の必要性は減っていません。データとその機能を理解する必要があります。一般に、最初のいくつかのスプリントはデータ設計に焦点を当てる必要があります。
したがって、データベースモデラーにとって問題となるのはアジャイルではなく、データの性質を理解していない個人です。データベース開発をアプリケーション開発と同じと見なす人もいます。データベースモデリングとソフトウェア開発は異なり、適切な焦点が必要です。
データベースは、ほとんどのソフトウェアアプリケーションの中核です。時間をかけて要件を分析し、データモデルがそれらをどのように満たすかを分析する必要があります。これにより、開発の方向性と方向性が失われる可能性が低くなります。
開発者は、データの重要性と開発プロセスへのデータの貢献を理解する必要があります。私たちは情報化時代に生きています。アプリケーションはデータを表示および操作します。アプリケーションに意味を与えるのは、データに含まれる情報です。
すべての要件やすべての問題を予測することはできませんが、慎重に計画して問題に備えることが重要です。
2。モデルを文書化する
データモデルを作成するとき、すべてが明白に見えます。オブジェクトに名前を付けて、その目的が明確になり、名前を読むだけで誰もがその意味を理解できるようにします。これは本当かもしれませんが、あなたが思うほど明白ではありません。テーブルと列の名前を選択するときは、各オブジェクトの使用法を明確にしてください。時間の経過とともに、オブジェクトの意味はドキュメントなしでは不明確になります。
命名規則を使用することは、効果的なドキュメント化に向けた1つのステップです。将来変更を加える必要がある場合は、既存のドキュメントに感謝します。行った決定と設計を説明する短くて単純なドキュメントは、その時点での設計の選択を説明するのに役立ちます。
新しい管理者がデータベースを管理し、説明のために戻ってくることなく意味を理解できるように、十分なドキュメントが必要です。データモデルと環境が文書化されていない場合、要件の変化に応じてデータモデルを維持または変更することは困難です。
ある程度、ドキュメントはデータモデリングとはほとんど関係がありません。ドキュメントとは、デザインを伝達し、将来的に理解できるようにすることです。
ドキュメントはしばしば後付けです。スケジュールが短い場合、ドキュメントは無視されます。しかし、これは高コストの技術的負債です。開発サイクル中に手抜きをすると、将来、データベースの変更、問題の特定、バグの追跡、およびデータモデルとデータの性質の理解にかかるコストが発生します。
例として、データモデルには、多くの場合、テーブルの主キーまたはキーの名前の一部として「ID」フィールドがあります。これは、TransactionIDのような主キーである可能性があります Transaction テーブル。一部のテーブルでキーの名前の一部として「数値」が使用されている場合は、その理由を文書化することをお勧めします。おそらくReferenceNumber メッセージの主キーの名前として使用されます。これは、ビジネスエリアで参照が呼び出されるためです。たとえば、金融サービスでは、金融メッセージには通常、参照番号が含まれています。
プログラマーが情報にアクセスできるように、テーブル、列、および関係の定義を文書化します。ドキュメントには、データベース構造の期待を説明する必要があります。
Vertabeloツールでは、テーブル、列、参照、代替キーなど、任意のアイテムにコメントをすぐに含めることができます。つまり、ドキュメントは、個別に管理する追加のドキュメントではなく、モデルとともにすぐに保存されます。
ドキュメントが不十分または欠如しているのは、多くの場合、近視眼的な考え方が原因ですが、その重要性を無視しないでください。これはまだ対処すべき問題です。
3。規則に従う
命名規則は、設計時に重要ではないように見える場合があります。実際には、名前はモデルを理解するための洞察を提供します。これらは紹介であり、論理的である必要があります。
一貫性のない命名は目的を果たしません。データにアクセスする必要のある開発者、データベースの管理者、および将来変更を加える必要のあるモデラーを苛立たせるだけです。
一部の人工キーに「ID」が使用されているが、一部のテーブルが異なる命名規則（Numberなど）を使用している場合、開発者、アナリスト、およびDBAは例外を理解するために時間を浪費する可能性があります。命名規則が弱いと、命名に一貫性がないため、開発中にエラーが発生します。
ドキュメントと連携して、命名規則を使用すると、将来、誰かがモデルを理解できるようになります。 「ID」（CustomerIDなど）の使用をランダムに切り替えないでください ）および「番号」（AccountNumber ）テーブルのキーとして。それらが正当化される場合にのみ、規則に例外を設けてください。例外とは何か、および規則が尊重されない理由を文書化します。
同じことが「XRT1」のような不可解な名前にも当てはまります–それは拡張参照テーブルですか？あなたの推測は私のものと同じくらい良いです。デザイナーがなぜそのような不可解な名前を選んだのかを知っていることを願っていますが、データベースにアクセスする次の人がその理由を推測できるとは思えません。
命名規則は個人の選択の問題です。決定に一貫性があり、文書化されていることを確認してください。
データベース設計に命名規則を適用するように説得できた場合は、このテーマに完全に専念している次の記事をお気軽に読んでください。
4。キーについて慎重に考える
主キー、外部キー、人工キーなどのキーは、しばしば論争を引き起こします。テーブルには、各行を識別する主キーが必要です。芸術は、どの列を主キーの一部にするか、どの値を含めるかを決定することです。
適切に正規化するには、各テーブルに識別キーが必要です。一意性を保証する必要があります。ただし、自然キーと主キーは同じである必要はありません。実際、テーブルに自然キーがある限り、そうではない可能性があります。
一部のデータモデラーは、一意性のために人工的なキーを好みます。しかし、一部のモデラーは、データの整合性を確保するために自然キーを好みます。
では、主キーとして自然キーを使用する必要がありますか？自然キーを変更する必要がある場合、1つの課題が発生します。自然キーが多くの列で構成されている場合は、多くの場所で変更を加える必要があります。もう1つの課題は、テーブルの唯一のキーとして人工キーを使用することです。
例として、製品に関する情報を格納するテーブルがある場合があります。テーブルは、シーケンス、製品の短いアルファベット名のコード、製品定義などの人工的なキーを使用して定義できます。人工キーのみで一意性が確保されている場合は、同じ商品コードの行が2行ある可能性があります。これらは2回入力されたものと同じ製品ですか？おそらく、製品コードのキーの方が適切です。
5。整合性チェックを慎重に使用する
データの整合性を確保するには、外部キーと制約が必要です。これらの整合性チェックを使いすぎたり、使いすぎたりしないように注意してください。
ドメインテーブルは、整合性を強化するのに効果的です。ドメインテーブルは、チェックする値が多い場合、またはチェックする値が頻繁に変更される場合にうまく機能します。
1つの問題は、開発者がアプリケーションが整合性をチェックすることを決定することです。ここでの問題は、中央データベースが多くのアプリケーションによってアクセスされる可能性があることです。また、通常、データベース内のデータを保護する必要があります。
可能な値が制限されているか範囲内にある場合は、チェック制約が望ましい場合があります。メッセージが受信または送信のいずれかとして定義されているとしましょう。この場合、外部キーは必要ありません。しかし、有効な通貨のようなものの場合、これらは静的に見えるかもしれませんが、実際には時々変化します。国は通貨同盟に参加し、通貨は変化します。
アプリケーションも整合性チェックを実行する必要がありますが、整合性チェックをアプリケーションだけに依存しないでください。データベースに整合性ルールを定義することで、それらのルールに違反することがなくなります。このようにして、データは常に定義された整合性ルールを満たします。
6。デザインのインデックスを忘れないでください
一部のインデックス設計は、実際の展開および使用中にインデックスが変更される可能性がある場合でも、データベースモデリング中に役立ちます。もちろん、インデックスが少なすぎるのと同じように、インデックスが多すぎる可能性もあります。
インデックス作成は継続的なプロセスです。設計中に、モデルでプロセスを開始します。設計作業は主キーと制約にあります。
データに対するクエリを検討する場合、インデックスは重要です。モデリングするときは、データがどのようにクエリされるかを考慮する必要があります。インデックスを付けすぎないように注意してください。インデックス作成はクエリの最適化を中心に展開します。
7。一般的なルックアップテーブルを避ける
属性ペアの一般的なルックアップテーブルをよく見ました。単一のジェネリックドメインテーブルを定義することは、設計を簡素化するために認識されています。このスタイルのドメインテーブルは、テキストを保持するための抽象的な定義を作成します。 「許可された値」または「有効な値」テーブルと呼ばれると聞きましたが、「MUCK」テーブルという用語は、2006年にこのアンチパターンのために造られました：MassivelyUnifiedCode-Key。
MUCKテーブルには無関係なデータが含まれています。
たとえば、ドメイン、エントリ、および説明を定義するテーブルを作成できます。上記のメッセージの例を振り返ると、2つのエントリは次のようになります。
| ドメイン | エントリ | 説明 |
|---|---|---|
| 1 | 私 | 銀行が受信した受信メッセージ |
| 1 | O | 銀行から送信された送信メッセージ |
次に、別のドメインのエントリを追加します：
| ドメイン | エントリ | 説明 |
|---|---|---|
| 2 | カバー | カバーの支払い |
| 2 | シリアル | シリアル支払い |
| 2 | SSI | 標準決済手順 |
これはただの混乱です。表はどういう意味ですか？
楽しみのために、MUCKテーブル（または、トールキンファンの場合はOTLT、「One True Lookup Table」）の簡単な例をモデル化し、いくつかのコメントを含めました。これはアンチパターンであり、データモデルで使用することはお勧めしません。
MUCKテーブルでは、制約を定義できません。 MUCKは、意味のない多くの行になる可能性があります。フィールドの意味を理解するために別のテーブルにクエリを実行する必要がある場合、これは理想的ではありません。
これらの「何でもあり」のテーブルは、整合性チェックを複雑にしたり、不可能にしたりします。これらのテーブルが作成される理由の1つは、データベース内のいくつかのテーブルが同様の定義を持っているためです。そうすると、データの整合性チェックが不可能になります。また、サイズがかなり大きくなる場合があります。
正規化は、MUCKテーブルから離れる必要があります。単一のテーブルは単一のドメインを表す必要があります。すべてのドメインを表す単一の（MUCK）テーブルではありません。 MUCKテーブルがなくても、外部キー制約を設定できます。
ドメインオブジェクトを単一のテーブルに詰め込むのではなく、個別のテーブルを使用します。これにより、適切な列タイプ、制約、および関係が可能になります。 「許可された値」テーブルは単なる泥だらけであり、データモデルには含まれていません。
8。アーカイブ戦略を定義する
データの保持とアーカイブの適切な戦略なしに作成されたデータベースをよく目にします。アクティブなデータベーステーブルでデータをオンラインで利用できるようになる期間はどれくらいですか？ほとんどのシステムは、データベースにデータを「永久に」保持するように構築されています。ほとんどのシステムでは、これは合理的な長期データ保持戦略ではありません。ある時点で、アクティブなデータをアーカイブする必要があります。
私が提唱するアプローチの1つは、設計上の考慮事項の一部としてデータ保持を含めることです。履歴データの検索を最適化しながら、アクティブなテーブルへの新しい行の挿入を高速に保つために、アクティブなテーブルと履歴テーブルを用意しますか？
これにより、元の設計に加えてデータベースへのアーカイブを再設計する必要がなくなります。
9。早期にテストし、頻繁にテストする
アル・カポネ（または第8代米国大統領の息子であるジョン・ヴァン・ビューレン）を言い換えると、「早くテストし、頻繁にテストする」。このようにして、継続的インテグレーションのパスをたどります。開発の初期段階でテストすることで、時間と費用を節約できます。
開発計画では、テストは常に課題です。多くの場合、アジャイルスプリントの最後にテストフェーズがあり、開発の最後にシステムテストがあります。通常、時間が短くなったときに最初に圧迫されるのはテストです。
データベースのテストでは、本番環境をシミュレートすることを目標にする必要があります。「データベースの1日」です。どのくらいの量が期待できますか？どのようなユーザーインタラクションが発生する可能性がありますか？境界ケースは処理されていますか？
したがって、テスト計画と適切なテストは、データモデリングとデータベース開発の不可欠な部分である必要があります。
結論
これらは、データモデラーを操作してデータモデルをレビューするときに私が見た主な問題です。これらのヒントに注意を払うことで、データベースはより適切に設計され、より堅牢になります。しかし、これらの投資の一部に対する見返りは、必ずしも明白または目に見えるとは限りません。計画、文書化、標準の使用、キーの作成、整合性の確保、インデックス作成の実行、MUCKの回避、戦略の開発、およびテスト！
これらのアクティビティはどれも、膨大な時間はかかりませんが、データモデルの品質に多大な影響を与えることはありません。
これらのヒントについてどう思いますか？