記事「
開発」→「データベーステーブルと
開発の 関係」 →「ユビキタス
ueasleyの データベースの設計」に少し追加したいと思います。
リレーショナルデータベーススキーマを構築できるルールを説明したいと思います。 これらのルールは開発者が直感的なレベルで使用するため、これらのルールを必要とする人はほとんどいませんが、データベーススキーマを構築するプロセスを形式化するからです。
これらの規則は、ERモデル、つまりエンティティ関係モデルに適用されます。
ERモデル
ERモデルは図であり、その構成要素は次のとおりです。
- エンティティは、実オブジェクトまたは仮想オブジェクトであり、その情報はデータベースに保存する必要があります。 ERモデル図では、エンティティは、エンティティの名前を含む長方形として表示されます。
- 接続 -2つの（ほとんどの場合）エンティティ間、または1つの同じエンティティ間（再帰的接続）でダイアグラム上にグラフィカルに表示される関連付け。 接続は、エンティティごとに1つずつ、両端が目立つ菱形で表されます。 この関係の両側で、次のことが確立されます。
- 接続の度合い-このエンティティのインスタンスがいくつ関連付けられているか
- コミュニケーションの義務-このエンティティがコミュニケーションに参加する必要があるかどうか。
例を挙げます。
顧客とその注文に関する情報を保存する必要があります。 チャートを作成する
図1
「ORDER」エンティティの側では、関係が追加の長方形で示されていることに注意してください-これは、「ORDER」の各インスタンスが「CLIENT」エンティティのインスタンスに対応することを意味します（クライアントの場合、順序は不要です）。 「M」の度合いは、エンティティ「CUSTOMER」のインスタンスごとにエンティティ「ORDER」のインスタンスが複数存在する可能性があることを意味します（ただし、逆はできません。各注文には常に1人の顧客しかいないため、「1」
リレーション（通常はデータベース内のテーブルに対応）は、エンティティと混同しないでください。 エンティティは、ERダイアグラムから抽出することにより、関係に変換します。
設計手順
概念設計
すべてのエンティティと関係を含むER図が作成されます。 概念（情報）モデルを取得します。 そのようなモデルは、設計されたデータベースの関係構造に対応しない可能性があることを理解されたい。
注文、顧客、従業員に関する完全な情報を保存する必要があるデータベースを構築するとします。 各注文には、この注文の要素のリスト（いくつかの製品）があり、それぞれの要素は、消費された材料と実行された作業のリストに関連付けられています。
私は次の図を得ました。
図 2
論理設計
予備的な関係のセットは、各関係の主キーの指示とともに構築されます。 属性のリストがコンパイルされ、これらの属性は関係によって配布されます。 すべての関係がNBFIと維持されることが不可欠です。
関係構造への移行（一連の関係の構築）は、次の規則に従って実行されます。
- バイナリ通信の程度が1：1で、両方のエンティティのメンバーシップクラスが必須の場合、必要な関係は1つだけです。 この関係の主キーは、これら2つのエンティティのいずれかのキーになります。 この場合、関係のインスタンス内の各キー値の単一の出現が保証されます。
- バイナリ接続の程度が1：1で、エンティティの1つのクラスがオプションである場合、2つの関係を構築する必要があり、各エンティティに対して1つの関係を選択する必要があります。 メンバーシップクラスがオプションであるエンティティキーは、必要なメンバーシップクラスを持つエンティティに割り当てられた関係に属性として追加されます。
- バイナリ通信の程度が1：1で、どのエンティティのメンバーシップクラスもオプションではない場合、3つのリレーションが使用されます-各エンティティに1つ-キーは対応するリレーションのプライマリとして機能し、もう1つは通信に使用されます。 通信に割り当てられた関係には、各エンティティから1つのエンティティキーがあります。
- バイナリ接続の次数が1：Mであり、M接続されたエンティティのメンバーシップクラスが必須である場合、エンティティキーが対応する関係のプライマリキーとして機能するという条件で、エンティティごとに1つの2つの関係を使用するだけで十分です。 単純に接続されたエンティティのキーは、M接続されたエンティティに割り当てられた関係に属性として追加する必要があります。
- バイナリ接続の次数が1：Mであり、M接続されたエンティティのメンバーシップクラスがオプションの場合、エンティティごとに1つ、通信用に3つの関係を使用する必要があります。 リンクには、その属性の中で、各エンティティからのエンティティキーが必要です。
- バイナリ通信の程度がM：Mに等しい場合、データを保存するには3つの関係が必要です。エンティティごとに1つ、通信に1つです。 本質の鍵はコミュニケーションに入ります。 エンティティの1つが縮退している場合、2つの関係があります（つまり、2つのテーブルで十分です）。
- 3者間通信の場合、4つの関係を使用する必要があります：エンティティごとに1つ、通信用に1つです。 接続によって生成される関係には、属性の中でも、各エンティティの本質のキーがあります。
ルールを使用し、データをテーブルに縮小します。
| エンティティ | ルール番号 | 関係 |
|---|
お客様
ご注文 | 4 | 顧客（＃顧客
注文（＃Order、＃Customer |
従業員
ご注文 | 4 | 従業員（＃従業員
注文（＃Order、＃Employee |
ご注文
注文品 | 4 | 注文（#Order
注文アイテム（＃注文アイテム、＃注文 |
旅団
注文品 | 4 | 旅団（＃旅団
注文アイテム（＃要素、＃旅団 |
製品
注文品 | 4 | 製品（＃製品
注文アイテム（＃アイテム、＃製品 |
お客様
ご注文 | 6 | 顧客（＃顧客
注文（#Order
支払い（＃Payment、＃Customer、＃Order |
旅団
従業員 | 5 | 旅団（＃旅団
従業員（＃従業員
チームメンバー（＃チームメンバー、＃従業員、＃チーム |
注文品
運営 | 5 | 注文アイテム（＃アイテム
操作（＃操作
レコード操作（＃レコード、＃要素、＃操作 |
注文品
素材 | 5 | 注文アイテム（＃アイテム
マテリアル（#Material
消費（＃レコード、＃要素、＃材料 |
タブ。 1
取得したリレーションに従って属性を配布すると、次のようになります（最初のフィールドのリストには主キーがあり、「＃」でマークされた他は外部キーです）。
| 旅団 | （＃旅団、＃准将、場所） |
| オフィス | （＃ポジション、ポジション、給与） |
| ご注文 | （＃Order、＃Customer、＃Employee、Placement Date、RequiredDate、Execution Date、Description） |
| 顧客 | （＃顧客、名前、名、姓、組織または部門、住所、電話番号、電子メールアドレス） |
| 録音 | （＃レコード、＃要素、＃操作、＃従業員、数量） |
| お支払い | （＃Payment、＃Customer、＃Order、支払額、支払日、メモ） |
| 消費量 | （＃Records、＃RaxMat、＃Element、Quantity） |
| 構成 | （＃Item、＃Order、＃Product、＃Gangs、Quantity） |
| コレクション | （＃Sotr旅団、＃旅団、＃従業員） |
| 従業員 | （＃従業員、パスポート番号、姓、名、愛称、＃役職、住所、自宅の電話番号、職場の電話番号、生年月日、雇用日、契約終了日、写真、メモ） |
| 操作 | （＃操作、説明、コスト、時間、機器、実行） |
| 素材 | （＃RaskhMat、NaimRaskhMat、価格、密度、タイプ、構成） |
| PRODUCT | （＃アイテム、ブランド、名前、アイテムの説明、タイプ、シリアル番号、在庫、価格） |
タブ。 2
それが私たちが大学でやることを教えられたものです。 誰かが興味を持つかもしれません。 「必要かどうか」については、あなたの意見を聞いています！
