DjangoのWeb開発、動的なWebページ（ユーザーとサイトを入力することができ、出力の相互作用）を開発するために、基本的に終了し、静的なページを開発している、あなたは（静的ページ）層を表示する必要がある - >論理層（機能） - >データ層（データベース）対話。
そしてデータベースで、データベーステーブル、フィールド、関係が明確で直接的なケースであるか、Djangoはデータベースが非常に簡単です作成します。
システム要件の収集、分析、およびデータベーステーブル全体のデータベースを設計、フィールド、関係しかし、もし、それが非常に困難です。（と呼ばれるデータベースの設計/開発）
データベース設計/開発フェーズの段階では、我々はデータベースを設計するための3つのパラダイムを実行する必要があります。
1、データベースの設計3つのパラダイム：
まずパラダイムは、データを分離することはできません。
＃は一つだけの数があるのフィールドとして理解することができ、例えば、フィールドだけでなく、あなたが残しておきたい場合は、次の2つのフィールドが存在して開き、ユーザー名と携帯電話番号を保存することができます。
第二のパラダイムは、各テーブルには、一意の主キーを持っている必要があります。
リレーショナルデータベースは、このようなジョー・スミス以上を有していてもよく、同じ名前の名前として、見つけるために、主キーによって必要とされているので＃、それは主キーとして使用することはできません、使用×××番号を。
第三のパラダイム非プライマリキーのデータテーブルを持っていない可能性があり、依存しています。
＃たとえば、テーブル内の×××「名前」と「電話着信番号、名前、電話番号、居住地域、その四つのフィールドレジデンスシティ、番号×××決定し、我々は名前と電話番号を決定することができるであろう、数「のみ依存。「住まいの州」、「都市生活」これらの二つのフィールド「×××数は」必ずしも実際には依存関係はありません。それは全く問題なかっただろうが、明らかに「生きた都市は」才能の選択の前提の下で例えば、確かに広州市、広東省では、依存があり、「居住地域」です。「住まいの地域は」とても非プライマリキーのデータが依存関係を持っていると呼ばれる主キー、ではありません。したがって、第3正規形の違反は、溶液は、別の部分に「居住地域」、「都市生活」別個の分割となる「生体表面」。
2、データの関係：
私は前に述べたように、リレーショナルデータベースは、2次元のテーブルのリレーションシップの山が、関係は通常、3例がありますがあります。
ワン：テーブルの直接の使用は、他のフィールドは主キーによって異なります。
＃このような学校として、生徒の名前が対応させていただきます
多くの、多くの-へ：内部のマルチで外部キーを参照
＃たとえば、教師は授業だけを教えることができますが、レッスンが教えるより教師できることを前提としています。その後の関係は、多対教師やカリキュラム、カリキュラムと教師の関係は、多くの1つです。
添加されるべきデータベースの設計における場所マルチ人のテーブルの外部キー内部（表教師）、主キー内の人物（カリキュラム）表を引用（コースID）
＃追加の仮定は、たとえば、教師は多くのコースを教えることができ、することができ、コースは唯一のクラスで教師になることができ、その後、教師とカリキュラムの関係は多くなり、多対カリキュラムと教師の関係が変更しました。
データベースの設計、それは人（教師メートル）主キーに外部キーの参照を追加する（カリキュラム）の多者テーブルになり（教師のID、従業員のジョブ番号などであってもよいです）
多くの多くの：このような状況は、2つのテーブル間の直接的な関係を確立することはできません、我々は接続として、空中から真ん中のテーブルを確立する必要があります。
＃例えば、学生がより多くの選択科目よりも、コースは側面の外部キーの導入によって解決することができない多くの関係に多くのに比べて、取るために多くの学生を与えることができます。
あなたは、主キー（シリアル番号/ IDなど）、主キーと外部キー参照の学生の主キーテーブルを作成し、例えば、「登録フォーム」と呼ばれ、カリキュラムを中央のテーブルを作成する必要があります。学生と関連付けるプログラム。
3、データベーステーブルの設計
私たちは、Djangoのウェブサイトのシステム開発の要件を見て：[実践的な演習]のPython + Djangoのウェブ開発シリーズ02 - Djangoの完全な開発環境を展開https://blog.51cto.com/14423403/2418370を
私たちは、学生、教師、カリキュラムのオブジェクトのこれらの三つのカテゴリーがあり、最初のニーズとの関係を分析します。
私たちは、システムは、各学生がそれぞれの教師が2つのコースを教えることができ、各コースは唯一のクラスの教師になることができ、最大2つの選択科目できることを必要とすることを前提としています。そして、このような要求の下で：
1）学生とコースの間の関係は次のとおりです。多くの多くの。
2）教師とカリキュラムの関係は以下のとおりです。多くの1つ。
3）生徒と教師の関係は次のとおりです、もちろんを介してリンクされているは直接関係はありません。
したがって、少なくとも4つのテーブル、学生テーブル、テーブルの教師、カリキュラム、転写産物（学生と中間テーブルのカリキュラム）、しばらく教師テーブル（a）は、主キー、外部キーを参照し、カリキュラム（およびそれ以上）。
そして、フィールドに4つのテーブルを設計し、彼らは私たちのシステム要件を満たすために必要なものについて考えます。（nullでない表現はnullにすることはできません）
| 学生表 | |||
| 学生ID | SNO | 主キー | nullではありません |
| フルネーム | 脱げます | ヌル | |
| 性別 | Sseksh | ヌル | |
| ユーザー名 | susername | ヌル | |
| 年齢 | セージ | ヌル | |
| どこ課 |
sdept | ヌル | |
| 教師テーブル | |||
| 教師の数 | TNO | 主キー | nullではありません |
| 先生の名前 | TNAME | ヌル | |
| 教師のユーザー名 | tusername | ヌル | |
| タイトル | TTITLE | ヌル | |
| カリキュラム | |||
| コース番号 | 誰か |
主キー | nullではありません |
| コース名 | CNAME | ヌル | |
| クレジット | ccredit | ヌル | |
| 授業時間 | CTIME | ヌル | |
| 会場 | cplace | ヌル | |
| いいえ教師 | TNO | 外部キー | nullではありません |
| 結果テーブル | |||
| コース番号 | 誰か | 外部キー | nullではありません |
| 学生ID | SNO | 外部キー | nullではありません |
| 実績 | cscore | ヌル | |
このように、データベースの設計/開発は完了です。どのような関係のパラダイムに基づいて三つの検査、違反がある場合、我々は再び分割違反パラダイムをフィールド、その後、ビューの関係ポイントがテーブルの真ん中を増やす必要があるかどうかに依存する必要があります。（これらは、まだこれらのデータベースのテーブルに戻って、データベースのDjangoのWeb開発の後ろだけの非常にシンプルな場合、この多くの困難よりも、実際の生産システムのデータベース設計/開発、です）