まず、最も重要なことは、ビジネスドメインを学び、理解することです。
1）忙しいウェブサイトのように高いトランザクション率を見ているか、または小さな会社の人事システムのように低い利用率を見ているか
2）セキュリティは大きな問題です-個人情報や財務データを処理していますか。それとも単なる製品カタログですか
3）ユーザーは多くの更新/挿入を実行しますか、それとも主に読み取り専用ですか
4）ユーザー数、使用パターン（ピーク負荷または均等に分散）
5）24時間年中無休、16時間年中無休などのアップタイムが必要ですか。保守のためのダウンタイムがないため、24時間年中無休の方がはるかに困難です。
6）DBはどれくらいの大きさになりますか？それが本当に大きい場合は、それやパーティションを考慮に入れてテーブルを設計する必要があります
7）ホットフェールオーバーを備えたエンタープライズクラスター、または通常のホスティングのみを確認する必要がありますか
8）DBはどのように管理されますか？ほとんどのDBプロジェクトでは、95％の労力がユーザーとそのアプリケーションの開発に費やされ、DB管理者は忘れられます
9）DB管理者、以前から、バックアップ、他のシステムへの変更、他のシステムへの統合、データの読み込みが含まれます
10）実際のところ、データのロードと既存のデータの使用は、それ自体別の大きな問題です。
はじめに
データベースはビジネスプロセス設計の二次的なものであり、直接的かつ単純な方法でビジネスプロセスをクリーンにサポートする必要があります。整形式のクリーンなエンティティモデルから、よりもはるかに多くのメリットを得ることができます。あちこちにインデックス。したがって、プロセスが定義されたら、それを取得して、意味のあるリレーションを使用してできるだけきれいに「エンティティ」に分割します。エンティティがわかると、データベーステーブルに変換されます。
最も重要なことの1つは、過剰な設計をしないことです。
いくつかの歯で答えを出すために、例として「車両」エンティティを取り上げましょう。車両には複数の車輪があります。あなたは、車両に複数の車輪が取り付けられることを知ることを決定する重要な決定をしました。次の2つの選択肢があります。「ホイール」を別個のエンティティにするか、「ホイール」エンティティの「フィールドの数」を整数フィールドにすることができます。
各ホイールに関する多くの変更情報を保存する必要があることを完全に知っている場合は、「ホイール」エンティティを作成します。これで、エンティティ（車とホイール）の間に関係ができました。
そうでない場合は、単純なフィールドで十分です。
データベースを設計するとき、これらの重要な決定を熟慮し、物事をできるだけ簡単にすることは、私にとって断然最も重要なことです。これは、アプリケーションの次のレイヤーを構築するときに、物事が本当に簡単であるか困難であるかの違いを生む可能性があります。
1-一貫性
やがてデータベースは変化し、他の人々はそれを扱う必要があります。自分自身と彼らに好意を払い、基本的なドメインの知識を持つ合理的な人物がテーブルの内容を予測できるような方法で構造が命名されていることを確認してください。時間をかけて、使用するいくつかの基本的な構成（メモ帳のように単純なものにすることもできます）を書き留めます。
例：
- 主キーはすべてIdTableNameで始まります
- テーブル名のケーシングはパスカルです
- 外部キーはすべてTableNameIdです
- 次...
アンダースコアの使用を選択するかどうか（アンダースコアの代わりに他の変換を使用するかどうか）は、使用方法に一貫性があるか、使用しない限り、1日の終わりには関係ありません。
データベースは、データの整合性を守る最後の防衛線です。ストアドプロシージャを介してすべてのデータアクセスを行い、チェック制約、外部キーなどを使用してデータの整合性を適用します。データを正しく入力します。CHAR（5）がより具体的で正確な場合は、VARCHAR（50）を使用しないでください。
他の誰かがそれをシンプルに保つことについて何かを述べました。最後になりましたが、来月必要になると「考える」ため、何かを構築しないでください。状況は急速に変化し、データベースにデータを入力した場合に使用するものではなく、使用する「考えた」ものに対して、目的を果たさないものに対してより多くのメンテナンスを行うことになります。
データベースがモデル化することになっている実世界のエンティティとの忠実度。
個人的には、「データベースデザインfor Mere Mortals」を入手するか借りることをお勧めします。データベースを設計する際に考慮する必要があるものはすべてその本にリストされており、データベースを構築できる非常に体系的で論理的な順序になっています。テーブルと列の定義は面倒ですが、最終的には1分ごとに使用する価値があります。
Googleブックス経由またはAmazon.comのページプレビュー経由で書籍を読むと、最初の章を読むことができると思います。
時間をかけて、またはこのサイトから「ベストプラクティス」として学ぶことができるヒントがいくつかありますが、最初の試行で最初から正しい方法で設計することに勝るものはありません。
あなたのデータを知っています。
また、データベースの用途を理解する必要があります。トランザクション（OLTP）の場合は、できる限り正規化する必要があり、トランザクションをできるだけ早く完了することが目標です。分析やレポート（OLAP）の場合は、集計を実行する多くの場所で非正規化する必要があります。 OLTPデータベースの設計上の考慮事項はOLAPデータベースには適用できません。逆も同様です。
情報要件は最も重要な部分です。
これは、CMSが提供する応答から、「システムの目的を決定する」と言い換えることもできます。
概念的なデータモデリングは、情報要件を収集して提示するための組織化された方法にすぎません。データベースによって格納および提供されるすべての値は属性に接続され、すべての属性はドメインに接続されます。次に、属性はエンティティまたはエンティティ間の関係のいずれかを記述します。主題のエンティティと関係は、データが記述する「現実世界」の概念構造を構成します。概念モデルからERDを構築するのは簡単ですが、面倒です。
その後、DBMSの選択、論理データベースの設計、物理データベースの設計、および構築を行うことができます。各ステップでは、データの独立性により、決定をより可逆的にすることができます。データの独立性は、パフォーマンスの影響を除いて、データベース内の設計決定をカプセル化します。もちろん、ツールを知っている必要があります。
モデルを管理し、それらを図やスクリプトに変換するためのツールがあれば、このプロセスを高速化し、エラーを減らすのに非常に役立ちます。
しかし、情報の要求に重大なエラーや欠落がある場合、巧妙な設計や実装でそれを補うことはできません。
誰がどこで、どのように、何を使って、それを構築して保守するのか。これを行うための、またはそれを実行するための方法、手順、およびプロセスはありますか？確かにビジネスニーズは、実装に依存しないERDでキャプチャする必要があるデータを駆動します。ただし、誰がデータを長期にわたって維持するかについても考慮する必要があります。誰がデータを「所有」するかと同様に。エンティティと属性の定義の所有者。
ポイントの基本セット：
- システムの目的を決定します。
- システムに必要なエンティティを特定します。
- 各エンティティが提供する必要がある情報を特定します。
- エンティティ間の既存の関係を特定する
- ユーザーがデータについて何を知り、何をしたいのか。
- 概念的および論理的なデータベース設計
- 正規化とERD
- 一意の値を持つフィールドを識別します。
- フィールドに適切なデータ型を選択します。
- データベースのリファクタリング。
適切なデータベースは次のように判断できます。
データベースが適切に設計されている場合は、スキーマ以外に何もないことで、ビジネスの動作を理解できるはずです。
つまり、データベースisビジネスです。データベースがビジネスの運営方法を反映していない場合、データベースが間違っているか、ビジネスが間違っています。
データベースはまた、あなたが本当に、本当に前もって釘付けにする必要がある数少ないものの一つです。悪いコードはいつでも修正できますが、まれに悪いスキーマの変更を元に戻すことはできません。正しく実行してください。
- 命名規則：1つのルールセットに固執する
- 正規化：（正規化の範囲）-これは、データエンティティの読み取り数と更新数の比較に依存します。
- リレーショナルインテグリティおよびその他の制約：外部キーの使用を推奨する人もいればそうでない人もいますが、それはあなたの要件と個人の好みに基づいて選択する必要があります。
- データベース図を作成し、可能であれば分析してチームと話し合います。