データベースモデリングに関するブログ投稿を作成するときは、抽象モデルがほとんどの読者のニーズを満たしていないことを覚悟しておく必要があります。理由は簡単です。実際のデータベースモデルは通常、特定のビジネスおよび開発要件に密接に関連して作成されますが、ブログモデルはそうではありません。
ここ数週間、データベースモデルの作成に関するブログ投稿を書いています。トピックは、単純なオンラインフォーラムを介したデータベースモデリングへの一般的なアプローチから、より複雑なオンライン調査のモデルにまで及びました。
私が作成するデータベースモデルごとに、ビジネスドメインを明確に理解し、モデルの全体像を頭の中で理解するようにしています。
抽象データベース開発の課題
通常、解決策としてアーキテクト 、私は特定のビジネス要件を取り、それらを技術的な側面から作成する必要があるものの技術的な詳細に変換します：翻訳 ビジネス言語から技術言語へ–アルゴリズムを高レベルで設計し、アルゴリズムのデータ要件をモデル化します。
残念ながら、私が職場で作成した実際のデータベースモデルについてブログを書くことはできません。一つには、それらはビジネスドメインに非常に固有であり、もう一つには、私は機密保持契約によって制限されています。ブログでは、純粋に要約を作成します 私が想像するものを除いて、特定のビジネス要件のない概念は、ビジネスドメイン内に存在します。さて、それは問題ありません。私はかなり良い想像力を持っており、私が行っている選択について説明するとき、あなたの要件が異なる可能性があることを頻繁に指摘します。しかし、このブログプロセスにより、このプロセスが実際のプロジェクトでモデルを作成することとどのように異なるかを考えるようになりました。
実際の開発プロセス
実際の状況では、インタラクティブで高レベルのソリューションと技術設計を作成した後、開発チームと緊密に連携します。 モデルが開発ニーズに合うようにする方法。
開発者は、データモデルが正規化されすぎて高性能をサポートできないと不満を言う場合や、特定の領域で追加の正規化を要求する場合があります。代替キーが欠落している場合、開発者はすぐに文句を言い、データベースのパフォーマンステスト中にもそれに気付くでしょう。
保存するデータの最大長と、データの入力および表示用の画面の設計に基づいて、正確なフィールド長を検討します。もちろん、概念データベースモデルの正確なフィールド長は重要ではありません。
テーブルに格納されるデータとアプリケーションによるデータの使用方法の例を検討し、アプリケーションの単体テスト用にテーブルに事前入力するスクリプトを作成します。このようにして、モデルがアプリケーションの制限をサポートしていることを確認するために、コーナーケースをキャッチします。
したがって、基本的には、モデルが妥協にもかかわらず受け入れられるものに進化するまで、反復プロセスを使用して、システムのビジネス要件と非機能要件を実際にサポートするまでモデルをマッサージします。
>私が言ったように、それはアプリケーションコード、ユーザーインターフェイス、およびアプリケーションインターフェイスが開発されている間、何ヶ月にもわたって続く可能性のある非常に反復的なプロセスになります。
意図的なフィードバックの制限
現在のブログの状況では、確かに限られた数の読者がモデルで観察する問題や課題についてフィードバックを提供してくれますが、それは必然的に表面的なものです。読者の誰もがモデルを直接使用してアプリケーションを作成し、実際に機能するものと問題がある場所を発見しているとは思えません。
したがって、「モデルがよく考えられていない」などのコメントはほぼ間違いなく正しいです。一方、「FKが欠落している」というのは非常に正確ですが、外部キーを含めるかどうかを記事のテキストで説明できれば幸いです。
結論
さて、この投稿を読者からのフィードバックに関する苦情やコメントとして読まないでください。反復型開発とのインタラクティブな交換が可能な環境にいない場合、データベースモデルを作成することの難しさを反映しています。開発プロセス。
データベースモデラーが開発プロセスから切り離される状況はおそらく他にもありますが、それがどれほど危険であり、問題が発生しやすいかを理解しました。
決して変更されないデータベースモデルを想像できますか？列を1回調整したり、外部キーを追加したり、新しいテーブルを追加したりすることはありません。正直なところ、そのように想像できる唯一の状況は、データベースを使用するアプリケーションが進化しなくなり、行き止まりに達したときです。つまり、寿命です。