データベース設計にどのように取り組みますか？[閉まっている]

私は主にWeb開発者であり、キックオフしたい個人的なプロジェクトがいくつかあります。

私を悩ませているのは、データベースの設計です。私は学校のdb正規化などを経験しましたが、それは数年前であり、学校を除いてリレーショナルデータベース設計の経験はありませんでした。

それでは、Webアプリの観点からどのようにデータベースにアプローチしますか？どのように始めますか、何に注目していますか？注意すべきフラグは何ですか？

データベース設計に関して私がこれまでに買った最高の本は、Michael Hernandez ISBN：0-201-69471-9によるMere MortalsのDatabase Designでした。Amazonのリスト私は彼が第3版を持っていることに気付きました。

第3版へのリンク

彼は、データベース設計のプロセス全体（最初から最後まで）を説明します。この本から始めることをお勧めします。

グループまたはチャンクで物事を見ることを学ぶ必要があります。データベース設計には、プログラミングと同様に単純な構成要素があります。これらの単純な構成要素を完全に理解すれば、データベース設計に取り組むことができます。

プログラミングには次のものがあります。

• Ifコンストラクト
• If Else Constructs
• Do Whileループ
• ループまで実行
• ケース構成

データベースには次のものがあります。

• データ表
• ルックアップテーブル
• 一対一の関係
• 1対多の関係
• 多対多の関係
• 主キー
• 外部キー

シンプルにするほど、物事は良くなります。データベースは、データを小さな穴に入れる場所にすぎません。これらのキュービックホールとは何か、それらに必要なものを特定することから始めます。

初めて試すときに、完璧なデータベース設計を作成することは決してありません。これは事実です。デザインは、プロセス中にいくつかの改良を経ます。あなたは、データの入力を開始するまで、時には物事は見かけ思えないだろう、とあなたが持っているああヘクタールの瞬間を。

Webは、独自の一連の課題をもたらします。帯域幅の問題。無国籍。開始しても終了しないプロセスからの誤ったデータ。

私はオブジェクト指向プログラミングと（大部分はトランザクションですが、一部はOLAP）データベース設計の両方を行っており、私の環境では、多くのテーマが繰り返されています（少なくともOLTPでは）。

3nf正規化の練習は、単一責任の原則の変形を練習するのに役立ちます。テーブルはシステム内の概念を表す必要があり、概念は相互に関連して、現実を模倣しようとする必要があります。たとえば、顧客が0個以上のアクティビティを持つことができるシステムを構築している場合、顧客テーブルとアクティビティテーブルを作成します。アクティビティテーブルには、Customerテーブルとの外部キー関係があります。ストアドプロシージャを作成するときは、外部結合を使用して顧客とアクティビティを結合するようにします。これは、顧客がアクティビティを0にできるというビジネス要件があるためです。

また、ブリッジ（リンク）テーブルを使用して、拡張性の機会に注意します。たとえば、本に無制限の（可変）数の著者を含めることができるビジネスルールを表現しようとすると、Book Table、Authorテーブル、および両方への外部キー参照を持つブリッジ/リンクテーブルを作成します本と著者。

また、すべてのテーブルでサロゲートキーを使用します（通常はID列を自動インクリメントしますが、おそらくGUID-コード内のGUIDとのトレードオフは、単純な整数よりも多くのメモリスペースを占有することです）。ルックアップ（ブリッジ/リンクテーブルを除く）。デフォルトでは、共通の外部キー列にインデックスを作成し、ストアドプロシージャ/システムクエリを時々確認して、インデックス作成戦略を最適化します。私が使用するもう1つのインデックス作成戦略は、検索列に基づいてコレクションを構築するコード内の場所を探し、適切なインデックスを検索列に追加することです。

まずデータベーススキーマを設計し、次にORMを使用してそこからオブジェクトを作成します。私はそのように少し古い学校です。ORMがインテリジェントで効率的なデータベーススキーマを作成することを信頼していません。それは人間の仕事であり、ソフトウェア設計の技術の一部です。

Bill Karwinの本SQL Antipatternsは、データベースの計画に非常に役立つことがわかりました。最も包括的な点は、データベースがデータの整合性と意味を保護する多くの機会を提供し、さまざまな魅力的な理由でこれらの機能を無視することはデザイナーのよくある間違いであるということです。これらの問題を最初から考慮し、設計全体に通知することは価値があり、後で亀裂を紙で打ち破ろうとすることに勝ちます。

データベースレベルでビジネスロジックと整合性を強化するために、包括的な制約を持つデータベースを使用することを好みます。多くの場合、データベースはアプリケーションであり、データベースにアクセスするものは単なるインターフェイスと見なされます。これにより、他の「インターフェース」の追加がより快適で簡単な体験になり、セキュリティにプラスの利点があります。

また、データベースの構造を変化するエンティティと見なすことも重要です。何かを始める前に、データベースの構造をまとめて封印する必要があると仮定するのではありません。変更を計画し、バージョン管理システムにDBを収容する必要があります。これに関する素晴らしいエッセイがあります。MartinFowler＆Pramod SadalageによるEvolutionary Database Design（および、これについては読んでいませんが、Sadalageによる主題に関する本もあります）。

最後に、ユーザーアカウント/ロール、ハードウェア/場所/ホストの接続などの周辺の問題は重要であり、時々見落とされます。計画する際にもこれらに留意してください。

データベースの設計は、データの使用方法を考慮せずに完全に行うことはできないため、ここに手順の短いリストを示します。

• エンティティ間の関係を捉えた短い文章を書く
• 文を表すエンティティ関係図を描く
• ERダイアグラムから正規化された論理データモデルを作成する
• アプリケーションとエンティティのCRUDマトリックスを作成する
• マトリックスを使用して、各エンティティのライフサイクルのカバレッジを検証します
• 各アプリケーションのサブスキーマを抽出する
• 各メジャー/ CRUD操作のサブスキーマ上のナビゲーションパスを調べます。
• 必要なレポートを検討する
• 上記のすべてに基づいて物理データモデルを設計します。必要に応じてスタースキーマの非正規化、パーティション分割、使用

データベースを正常に設計するには、最初にいくつかのことを考慮する必要があります。

• 保存する必要があるデータと、保存する他のデータとの関連性。このデータは時間とともにどのように変化する必要がありますか？スナップショットを時間内に表示できる必要がありますか（2009年からの順序）、最新のもののみが必要ですか（アクティブユーザーのみ）。
• データが意味のあるものであり、時間の経過とともに意味を維持することをどのように確認できますか（データの整合性）？
• データアクセスが高速であることを確認するにはどうすればよいですか？
• データを安全に保つにはどうすればよいですか？

したがって、データベースの設計を開始する前に、データの整合性を保つために使用されるデータベースの正規化と機能について最初に学習する必要があります。

次に、パフォーマンスチューニングを理解する必要があります。これは時期尚早ではなく、パフォーマンスはほとんどのデータベースの重大な障害ポイントであり、数百万のレコードを取得すると修正するのは非常に困難です。

そして最後に、データを保護する方法、保護する必要のあるデータ、およびデータが悪意を持って変更されないようにするため、または時間と時間をかけて変更を追跡できるようにするために必要な内部制御を理解する必要があります変更が加えられ、以前のバージョンに戻すことができるようになりました。

また、後でリファクタリングする必要があるため、開始する前にデータベースのリファクタリングについて少し読むことも役立ちます。また、できるだけ簡単にリファクタリングできるように設定方法を知っておくと役立ちます。

一般に、データはアプリケーションよりも長年にわたって存続します。データはアプリケーションの中心であり、ほとんど関係のないダムのデータストアと見なされるべきではありません。

一般的に言えば、優れたデータベース設計は優れたデータベース設計です。Webの使用に関するより大きな問題は、データにアクセスし、基本的にWebにはない状態を必要と考えるものを管理する方法です。

それについて考えると、私のアプローチは本当にかなり多くの経験に基づいています...しかし、スキーマまたはオブジェクトから始めるかどうか、あなたは実際に同じことをしようとしています。つまり、データの使用可能なモデルを構築します-プロジェクトは、モデルとスキーマの間のかなり直接的な関係になる可能性があります（すべての場合ではなく、おそらくすべてのテーブル/オブジェクトではありません）。実際には、どこからでも快適に作業して適切なモデルを構築する問題です。

まともなモデルの構築に関しては、@ Timはデータベース用にダウンしており、基本的にオブジェクトモデルの構築はほぼ類似しています-ユニークなもの、階層、多対多の関係などデータベースにアクセスし、良いことをすべて実行してください。

また、スクリプトまたはスクリプトにddlが含まれていることを確認して、スキーマを最初から作成し、変更に応じて更新できるようにします（コード内のddlが推奨される方法です。システムが動作します）。

大きなホワイトボードとさまざまな色のペンから始めます。異なる色は異なることを意味します。そして、私はただ絵を描き始めました。通常、私は黒で明確なもの、青である可能性の高いもの、および緑ではありそうにないものを描きます。赤は重要なメモです。大量に消去して再描画します。クエリを実行し、モデルがそれをサポートしていることを確認する必要があるものについて考えます。そうでない場合は、そうなるまで微調整します。

最終的にモデルが大きくなりすぎる場合は、Visioに移動して、ホワイトボードに戻って作業します。

最後に、拡張ポイントについて考えます。ほとんどの人が犯す最大の間違いは、データベースを設計し、「データベースを使い終わった」と言って先に進むことです。データベースの操作は一度も終わりません。受け取ったすべての変更要求は、そのレベルまでずっと下がっていく可能性があります。それをどのように追加するかを考えてください。どのような種類のリクエストが発生する可能性があるかを考え、それらをフックできるかどうかを確認します。拡張性についてまったく考えない場合は、これらの変更リクエストが発生したときに大きな設計上の負債が発生します。

「SQL then ORM」またはその逆については、あなた次第です。モデルが最初に良い基盤を作ることを確認してください。

最初にオブジェクトを設計してから、ORM（nHibernateなど）を使用してスキーマを作成します。逆を行うよりもはるかに柔軟性があります。

次のステップは、生成されたスキーマの最適化です。

データベーステーブルを最初に設計するプロジェクトを見たのは久しぶりです。

これまでに他のフェローによって明示的に述べられていないものはほとんどありません。

• 専門家がデータベースの設計を行うことをお勧めします。もちろん学ぶことは問題ありませんが、モデリングまたはデータベース設計に精通していない場合は、中規模または大規模モデルを構築することはお勧めしません。この理由は、間違った設計のコストが通常非常に高いためです。

• システムの目的とユーザーの要件をよく理解してください。要件を知らないと、正しいデータモデルを設計できません。

• プログラムで実行するコードと、DBが処理するコードを把握します。これは、データ列のnullではなくnullなどを適切に設定するために必要です。これは、RIを正しく指定するためにも必要です。

• 主キーを適切に決定します。可能な場合は簡単なキーを探してください。

• 他のアプリケーションとの統合ニーズを検討してください。

• ユニバーサルデータモデルの使用を検討し、業界標準の命名とデータ列サイズに従ってください。

• 将来のニーズを考えてください（既知の場合および該当する場合）

• 他の人にモードをレビューしてもらいます。

• モデリングにツールを使用する-ERDツールまたはUMLツールのいずれか。

• 生成されたDDLコードを確認して理解します。当たり前だと思わないでください。