需要の分析
まず、データベース設計、設計プロセスのデータベースを通じて、明確な需要を持っているが、常に実体の整合性、参照整合性の整合性、ドメインの完全性、ユーザ定義（ビジネスルール結合を含め、最終検査データの整合性制約に設計から注意を払う必要があります）
ソース
データベースを設計する前に、要件は三つの主要な発生源があり、データベース内のデータのニーズの理解に基づいて、含まれている必要があり、データベースの設計からデータを抽出するために文書化し始めます。
まず：インポートするシステム初期化データ
第二：ユーザーデータを格納します
第三：これら二つのデータのうち、ソフトウェアによって処理新しいデータ
データ居場所
データベース内の出力データは、2つの主な目的地があります。
まず：システムデータとして、
第二：ユーザーへの通信
知識を学んだ後、CDMの設計を開始
ソースによると、私は、対応するエンティティをデザイン
まず：インポートするシステム初期化データ
ソフトウェア・インターフェース・エンティティ
テンプレートの実体
役割実体
ユーザー権限エンティティ
移行エクステントエンティティ
第二：ユーザーデータを格納します
ユーザエンティティ
写真の実体
移行絵エンティティ
第三：これら二つのデータのうち、ソフトウェアによって処理新しいデータ
1.ユーザーと写真のコレクションとの間の関係の定義
2.ユーザは、テンプレート、画像、画像の移動との間の物理的な履歴を定義します
物理的なデザイン分野
主な設計は、ストレージの面で画像を反映：画像が比較的大きいので画像、テンプレート、移行画像、統合ストレージ・ストレージ・パスは、対応するように、データベースに直接格納することができません
他のデータ形式を統一するために、一意に識別するための各非エンティティ関係に番号を追加します。一貫した長さ、データの送信及び処理を容易にします。
- キャリブレーション
エンティティを対応する設計が完了した後、主に思考次の2つの側面のために、CDMの検証を行いました
データは完了です
いいえ、標準のチェックにつながった不確実な需要の多くの場所があるので確認することで、私は、データが完全であるかどうかを判断することはできません。
データの冗長性かどうか
チェックすることで、私の理解では、CDMの設計は、データの冗長性の場合が存在しません
概要
概要：黄浩平
まず、このデータベースの設計を通じて、主に以下の教訓を得ています
1.あなたがソフトウェアツールを使用すると、さらに奇妙なエラーが発生しないよう、多くの時間を節約なる、学習のチュートリアルに進みます。
2.需要がプロジェクトの要件は結果を生じなかった設計から、データベース設計の故障につながることができ、データベースを設計するのではなく、決定されていません。
CDM、PDMおよびデータ・ディクショナリを描画するためのデータベース設計の必要性のために
第二に、準備完了
主に設計プロセスのモデリングソフトウェア、完全なモデリングを把握することができない知識の欠如につながりませんオンラインビデオチュートリアル、CDMの設計の包括的な研究を通して。ビデオチュートリアルから、私は、ツールの主な役割のPowerDesignerのCDM部分、機能を対応する各タブのことを学んだし、不必要な多くのミスを避けるために。例えば：
1.CDM PDMとは異なり、異なるエンティティで同じフィールドを持っていないだろう、主外部キー関係は、PDMで表現します
あなたがテーブル内のフィールドを追加したい場合は2は私の理解では、実際のデータベースのテーブルに相当多くの関係は、エンティティが関連付けボックスを通じて関係の代わりに、CDMにおけるリレーショナルテーブルを置き換えるために使用すべきではありません
3. DOはマルチとしてエンティティの自動的に対応するマスターキーPDM、多くの関係を転送する際に、多くの関係に依存して関連して同じフィールド内の他のエンティティで発生し、そしてそのようなデータによって表されるべきではありませんエンティティへの外部キー。
intentifyフィルを留意すべき設計4. CDM、CDMの一次識別子をindentify、複数の識別子が付加されてもよい、他のものは二次識別子です。
実際にはない学習システムによって学習されていない、多くの考慮事項があります。
概要：張丁
それは、最初のデータベースのために用意し、実際に私たちが実際には、多くの実験的なデータベースによると、小型の実験の多くが点在し、この大きな課題であるので、私たちの経験が一定量になっているものの、いくつかのデータベースの経験を書くことについての最近の話データベースは、最初の表に書かれていても利用できるいくつかの経験豊富な指導は、データ型と関連するインフラストラクチャエンティティ厳格でないデータベースの実際の準備の後ろに教師を指導する時から、学校のカリキュラムの初めに基礎の一部から、増加OK、我々はテーブルの数を準備しているテーブルの数を制限することが少なすぎるだろう、いくつかのテーブルは非常に不合理ですが、またそれは、基本的なソフトウェアであるためではない、それは、そのようなユーザが入力画像を高めるためにできるように、いくつかの関連する拡張性を必要とします等の数、我々は不利に時間のユーザ入力の量を制限するが、実際に拡大し始めている。その後、関連する論評の実際の内容を考慮の欠如は、履歴データの保存は、私たちが始めたとき、例えば、データとともに保存されているすべての画像は、単に関連するフィールドコールを設定します しかし、過去のデータが実際に少ない呼び出しで、追加格納するテーブルを設定する必要があり、新しいデータは、この通話中に影響されることはありません、と意識のツールの関連するコンテンツ不十分な利用の設計に問題がある、いくつかの機能もあります後に、知っているインターネット検索は、例えば、テーブルクロスの位置を再配置、データベースの異なる部分を分割し、収穫のデータベースに書き込まれたファイルを、書くことができます。
データベースの設計は、データベース設計の品質が直接アイデアや設計プロセスにおける経験のいくつかについて話をここでは、ポストコード開発の進捗に影響を与え、プロジェクトの基礎となるものです。
概要：ドンJunhong
1.まず、我々は需要に応じて分析したところ、私たちはテーブルの上に設計されたテーブルを、まとめどのくらい必要な、実際には、だけではなく、テーブルの表面上のエンティティのみを考慮する必要があり、また、いくつかによると、考慮すべきプロジェクトの基本的な目的を理解する必要がありますユーザーには見えないかもしれテーブルの種類、表現の具体的な形式はありませんが、非常に不必要な作業の数を減らすことができ、そして、私たちはのいくつかの機能でプロジェクトの設計を支援するためにデータベース2.特定の設計、私は思いますニーズ分析は、状況に応じて、同じ、同じプロジェクトを要求することができる、異なる設計思想の下で、まったく同じ要件必要とすることはできません行われるべきであるデータベースの設計3.を、私たちはテーブル間の関係を明確にすべきツールは、当社の使用を容易にするため、これらの関係、及び第一、第二および第三のパラダイムによると、同時にデータベースを標準化するために、当社のデータベースの使用を容易にするために、我々としても、いくつかのビュー、ストアドプロシージャ、トリガなどを追加することを検討することができますが、時間が枯渇を呼び出したときにも考慮する必要があります
概要：南京路
1は、チームでは、私は個人的なもののみの行にのみ給油時間の必要性の機能を達成することができる、コミュニケーションの重要性を認めるが、我々はチームで調整して交換が必要になります。
図2は、データベース設計とデータベースエンティティは少し、ゆっくりエンティティとエンティティ間のリンクを決定するフィールドからの需要を決定する必要があり、それだけで本当ににゆっくりと慎重に作業を作業の家を構築するプロセスであります完全;私たちは、同じ経験を持っていたし、私たちは今、それをピットで1歩を踏み出すためので、我々は非常に迅速に仕事を得ることができることを判断成熟場合。
3、データベースのためのプロジェクトのニーズはゴブリンの疲れている、あなたがストップをスイングさせ;による複数のデータベースへの需要の変化になるように、複数のリワーク、あまりにも疲れました。
4、データベースの設計が決めて、これらは本当に難しく、合理的かつ実用的です。データベースは、標準的な答えはありませんので、唯一のより良い、より実用的かつ容易に維持します。多くの人々のビルド知恵に比較的優れたデータベースのニーズので、
概要：江海で
データベースの設計は、データベース設計の品質が直接アイデアや設計プロセスにおける経験のいくつかについて話をここでは、ポストコード開発の進捗に影響を与え、プロジェクトの基礎となるものです。
ニーズを特定します確かに慎重に、その後明確な要件とハンズオンを分析することが、データベースの分析が不十分または不正確なデザインが遅く変更を繰り返し何度も、時間のかかる事前に設計されたデータベースが必要になり始めました必要があります。
1。エンティティの決定：最初は、少なくとも15個のテーブルを持っているために私たちを必要とし、そのプロセスの初期ハッシュテーブルは非常に困難であり、教師との最終確認は10個のテーブルに減らすことができるので、最初は、実体を議論する会議です。
2。確認表を作成します。ここで注意すべきテーブルの一般的な設計は、リレーショナル・データベースの「関係」は、多くの多くまたは多くの1つ、1に本物の1を区別する前に、分析の間の関係に注意を払うべきであるということです。
3。フィールド決定：解析が設定されているなどのデータ型、プライマリ外部キー、インデックス、フィールドが空であることができるかどうかなど、テーブルに優れたフィールドを決定するために、このステップは前のステップとデータベース設計の考慮の三のパラダイムと組み合わせることができます。