[インタビュー] 要件を受け取った後、どのように合理的なデータベース モデルを設定しましたか?

以前テクニカルディレクターと面談した際にこの質問に遭遇し、その時は「WBS分解をどうするか」「概要設計をどうするか」などの質問に答えてもらい、難しすぎると思いました。しかし実際には、面接官は「データベース モデルの適切な設定」についてだけ聞きたかったのです。

「仕方がありませんでした。当時は経験も浅​​く、面接の機会があれば、自分の知っていることをすべて話したいと思っていました。とにかく、話すことが少ないよりは、たくさん話したほうが良いのです。私の技術的なスキルやスキルが気に入らない人がいたらどうしますか?」私の他の能力の方が好きです...

トピックに戻って、「データベース モデルの適切な設定」に関する質問にもう一度答えてみましょう。

データベース モデリングは、高品質のモデルを設計するためにビジネスの理解、データの特性、データベース理論の組み合わせを必要とする包括的なプロセスです。次の6つのことを行う必要があると思います。

  1. タイトルに「要件を把握した上で」とあるのは前提条件を整理するためですが、ここで隠れているのは「要件を検討しました」ということで、設計者としてはビジネス要件の内容を十分に理解していることになります。この方法によってのみ、エンティティを正しく識別し、異なるタイプを区別することができます。
  2. エンティティを識別した後は、エンティティの属性を自然に定義できます。属性を設定するときは、データ型、長さ、許可される null、デフォルト値などの制約を指定する必要があります。
  3. 実体だけでは不十分で、この世界のあらゆるものにはさまざまな「関係性」が存在します。エンティティの関係を設計するときは、1 対 1、1 対多、または多対多のさまざまなカーディナリティを考慮し、関係のオプション性と依存性を考慮する必要があります。これはすべて、「ビジネス ニーズを完全に理解する」ことに関係します。 .」切り離せない。
  4. 後で標準化された設計を実行するときに、冗長なデータの生成を避けるために、機能の依存関係と結合主キーを特定することも必要です。ただし、これは実際の状況と組み合わせる必要があり、部分的なデータの冗長化によってパフォーマンスのボトルネックの問題が解決できる場合でも、データの冗長化は依然として必要です。最終的には、これは依然としてビジネス ニーズに依存します。
  5. 物理モデルを設計する際には、主キーインデックスクエリを使用してみたり、結合インデックスフィールドの順序とSQL実行メカニズムの関係に注意したりするなど、クエリと操作の特性に基づいて適切なインデックスとストレージ構造を選択する必要があります。 OLAP (オンライン分析)、処理) および OLTP (オンライン トランザクション処理) タイプのアプリケーションなどのデータベース エンジン。
  6. データのセキュリティを確保するためのアクセス許可とセキュリティ ポリシーを設計します。たとえば、一部のプロジェクトで読み取りと書き込みの分離が必要な場合、ライブラリの書き込み時に root アカウントを直接使用しないことをお勧めします。また、「書き込み可能な」ユーザーは自分のスキーマ コンテンツのみを取得できます。 、「読み取り可能」ユーザーである一方で、「ユーザーは「読み取り専用」機能のみを開くことができます。2 人の「読み取り可能および書き込み可能」ユーザーには、過剰なアクセス許可を避けるために異なる許可制限を設定する必要があります。

上記 6 点のうち、最初の 4 点はデータ概念モデリングに関するものですが、このデータ概念モデリングは論理設計に属するものであり、現時点では具体的な実装技術を検討する必要はありません。その目的は、ビジネス要件を正確に反映する概念モデルを作成し、その後の物理実装の基礎を築くことであり、これはデータベース モデル全体の設計の中核でもあります。

データベース モデルが形成された後、それは直接開発には投入されませんが、結果が期待どおりであることを確認するために検証する必要があります。これには、フィードバックを得るためにビジネス チームとのより多くのコミュニケーションとディスカッションが必要です (このステップでは、プロジェクト マネージャーまたはプロダクト マネージャーを協力させる必要があり、全員が一貫して理解していることを確認するために、2 人のマネージャーが主導権を持ってこれを行う必要があります)それ以外の場合は、確認のためにビジネス スタッフに会うだけです。アカウントを受け入れない場合、2 人のマネージャーに対峙するのはさらに面倒になります)。以下の5点にまとめます。

  1. ビジネス担当者とエンティティと属性を確認して、重要な情報が見逃されないようにします。
  2. エンティティ間の関係をチェックし、関係の定義がビジネス ロジックに準拠していることを確認します。
  3. サンプル データを挿入して、モデルが予想されるさまざまな状況に対応できるかどうかをテストします。
  4. 関連するクエリを作成して必要なデータ結果セットを取得できるかどうかを確認します。
  5. モデルがビジネス ニーズを満たし、合理的に設計されていることが検証結果で示されるまで、モデルを繰り返し調整します。

ここまでで、データベース モデルの設計は完了しました。

おすすめ

転載: blog.csdn.net/kida_yuan/article/details/132710726