データベース設計の例を探すのに適した場所-ベストプラクティス
私は、会社のために多くの情報を保存するためのデータベースを設計する仕事を与えられました。タスクはかなり大きく、ユーザーが何かを実行できるはずの複数のモジュールが含まれているため、このための優れたデータモデルを設計することを心配しています。設計が不適切なデータベースになってしまいたくありません。
契約/請求/注文などのデータベース構造のいくつかの適切な例を使用して、それらを1つのNiceリレーショナルデータベースに結合したいと思います。これに関するいくつかの例を手伝ってくれるリソースはありますか？
正規化について質問がまったくなくなるまで、正規化について読み始める前に。あなたが学校でこれをしただけなら、あなたはおそらくまだそれについて十分に知らないでしょう。
各モジュールの要件を注意深く収集します。あなたは知る必要があります：
ビジネスルール（アプリケーションに固有であり、ソースに関係なくすべてのレコードに適用する必要があるため、データベースに適用する必要があります）、
法的または規制上の懸念（たとえばHIPAAまたはSarbanes-Oxley要件）のセキュリティ（データを暗号化する必要がありますか？）
どのようなデータを保存する必要があり、その理由（このデータは他の場所で利用できますか）
どのデータに1行のデータしかなく、どのデータに複数の行が必要ですか？
各テーブルの行の一意性をどのように強制するつもりですか？自然キーがありますか、それとも代理キーが必要ですか（ほとんどすべての場合に代理キーを提案します）？
レプリケーションが必要ですか？
監査が必要ですか？
データはどのようにデータベースに入力されますか？一度に1つのレコードから（または複数のアプリケーションから）アプリケーションから取得されるのでしょうか、それともETLツールまたは別のデータベースからの一括挿入から取得されるものもあります。
誰がいつレコードを入力したかを知る必要がありますか（エンタープライズシステムではこれが必要になる可能性が高いです）。
どのような種類のルックアップテーブルが必要ですか？ルックアップテーブルを使用してユーザーを値に制限できる場合、データ入力ははるかに正確になります。
どのような種類のデータ検証が必要ですか？
システムにはおよそいくつのレコードがありますか？テストデータを作成するための大きさを知るためのアイデアが必要です。
データをどのようにクエリしますか？ストアドプロシージャ、ORM、または動的クエリを使用しますか？
デザインで覚えておくべきいくつかの非常に基本的なこと。データに適したデータ型を選択してください。計算する予定の日付や数値を文字列フィールドに保存しないでください。先行ゼロが必要になる可能性があるため、数学の候補ではない番号（部品番号、郵便番号、電話番号など）を文字列データとして保存してください。 1つのフィールドに複数の情報を格納しないでください。したがって、コンマで連結されたリストはなく（これらは関連テーブルの必要性を示します）、電話1、電話2、電話3のようなことをしていることに気付いた場合は、すぐに停止して関連テーブルを設計してください。データ整合性の目的で外部キーを使用してください。
設計全体を通して、データの整合性を考慮してください。整合性のないデータは無意味で役に立たない。パフォーマンスのために設計を行います。これはデータベース設計において重要であり、時期尚早の最適化ではありません。データベースは簡単にリファクタリングされないため、パフォーマンス方程式の最も重要な部分を最初に正しく取得することが重要です。実際、すべてのデータベースは、データの整合性、パフォーマンス、およびセキュリティのために設計する必要があります。
複数の結合があることを恐れないでください。適切にインデックス付けされていれば、問題なく機能します。すべてをエンティティ値型テーブルに入れようとしないでください。これらはできるだけ控えめに使用してください。データセットの処理の観点から考えることを学ぶようにしてください。それはあなたの設計に役立ちます。データベースは、セットで物事を行うように最適化されています。
まだまだありますが、これで消化を開始できます。
Barry Williamsは、あらゆる種類のアプリケーション向けに約600のデータモデルのライブラリを公開しています。ほぼ確実に、すべてのサブシステムに「10のスターター」を提供します。このライブラリへのアクセスは無料なので チェックしてください 。
これはあなたの組織が望んでいる大きな「エンタープライズ」アプリケーションのように思えます。あなたはデータベースの初心者のようです。可能であれば、単一のサブシステム（たとえば、Orders）から始めて、それを機能させる必要があります。データベーステーブルが構築されるだけでなく、そのためのスケルトンフロントエンドもあります。それで十分になったら、Billingなどの関連する別のサブシステムを追加します。あなたは広大なモンスターになってしまうことを望まない。
また、適切なデータモデリングツールがあることを確認してください。 SQL Power Architect は無料のツールとしては十分です。
データモデルリソースブック。
http://www.Amazon.com/Data-Model-Resource-Book-Vol/dp/0471380237/ref=dp_cp_ob_b_title_
重いものですが、全体的に非常にうまくいきます。全部で3巻...
一般的な構造全体で非常によくできていますが、すべてをカバーしているため、簡単ではありません;）ただし、常に良い出発点です。
ここで懸念事項を分けておくようにしてください。ユーザーがデータベースを更新できることは、より「アプリケーション設計」の問題です。データベースの設計を正しく行うことができれば、それはそのための素晴らしいフロントエンドを開発する場合になるはずです。
最初に確認するのは 正規化 です。これは、テーブルから冗長データを削除するプロセスです。これにより、データベースを整理し、ニーズに関連する情報のみを保存できます。
データベースはモデルであってはなりません。作業セッション間の情報を保存するために使用されます。
アプリケーションはデータモデルに基づいて構築するのではなく、ビジネスロジックに従う優れたオブジェクト指向モデルに基づいて構築する必要があります。
オブジェクトモデルが完成したら、それに伴うすべてのデータベース設計を使用して、オブジェクトモデルを保存およびロードする方法を検討します。
（しかし、どうやらあなたの会社はあなたにデータベースを設計したいだけですか？アプリケーションではありませんか？）