モデル「エンティティと関係」。 オンラインの学童および学生向けのユニバーサルリモートテストシステム

ただし、ER モデルとリレーショナル データ モデルの用語を同時に使用する必要がある場合は、当然、次の用語を使用する必要があります。 関係そして 関係さまざまなロシア語の同等物。 これらの用語の背後には、非常に異なる概念があります。 リレーショナル モデルでは、リレーションは唯一の一般的なものです。 データ構造。 これと同じメカニズムが「関連する」エンティティを表すために使用されます (たとえば、 外部キー）。 後で説明するように、ER モデルは、エンティティとリレーションシップという 2 つの同等の概念を使用してデータベース スキーマを表します。 ER モデルの関係は、リレーショナル データ モデルの関係とは異なる役割を果たします。

さらに、この用語の純粋な音訳もロシア語の用語になりました。 関係まさにその意味で 態度。 たとえば、次のようなことについて話します。 リレーショナルモデルデータ、関係代数など、関係ベースのデータ モデル、関係代数などを理解するため、少なくともデータベースの文脈では、最終的に用語を留保することが賢明です。 関係そして 態度リレーショナル データ モデルの概念を示すため、および用語 関係別の受け入れ可能なロシア語相当物であるコミュニケーションを使用してください。

使用中で さまざまなオプション ER モデルの大部分は、 現代的なアプローチデータベース設計 (主にリレーショナル)。 このモデルは 1976 年に Peter Chen によって提案されました。 対象分野 少数の異種コンポーネントを含むグラフィック図の使用に基づいています。 プレゼンテーションのシンプルさと明瞭さ データベースの概念図 ER モデルでは、自動化をサポートする CASE システムで広く使用されるようになりました。 リレーショナルデータベースの設計。 多くの種類の ER モデルの中で、最も人気があり開発されたものの 1 つは、Oracle CASE システムで使用されました。 このモデルの簡略化されたバージョンについて説明します。 より正確に言うと、その構造的かつ不可欠な部分に焦点を当てましょう。

ER モデルの基本概念

ER モデルの主な概念は、エンティティ、関係、属性です。 エッセンス現実または想像可能なオブジェクトであり、その情報は保存され、アクセス可能でなければなりません。 4 この「定義」が実際にはトートロジーであることは明らかです。なぜなら、第一に、私たちは未定義の用語オブジェクトを通じて用語エンティティを定義しようとしており、第二に、用語オブジェクトを定義する試みも同様に絶望的だからです。 通常、著者は、そのような文脈では、対象の形式化された概念ではなく「日常」を意味すると言って自分を正当化しようとします。 もちろん、本質の概念をかなり正確な意味で理解する必要があるため、これで作業が容易になるわけではありません。 しかし、このトートロジーはこのコースの著者によって発明されたものではありません。 それはその地域の伝統です セマンティックモデリング。 この分野では、できるだけ形式的な手続きを避けようとします。 ER モデル図では、エンティティはエンティティ名を含む四角形として表されます。 この場合、エンティティの名前は型の名前であり、この型の特定のインスタンスの名前ではありません。 5 ただし、常にエンティティ タイプとエンティティ タイプという用語を使用する方が正確です。 エンティティタイプのインスタンス, 曖昧さを招かない場合に冗長になることを避けるため（そして伝統に従うため）、エンティティという用語をエンティティの種類を意味するものとして使用します。表現力を高め、理解を深めるために、エンティティ名にそのタイプの特定のインスタンスの例を付けることができます。

米。 9.1.

図では、 図 9.1 は、シェレメーチエボとヒースロー空港の例を示し、空港の本質を示しています。 それでもなお、この原始的な図式には次のような特徴があります。 重要な情報。 まず、データベースに同じタイプのデータ構造が含まれることを示しています ( エンティティインスタンス)、空港について説明します。 第二に、人生には空港ではいくつかの視点（たとえば、パイロットの視点、乗客の視点、管理者の視点）があり、さまざまなデータ構造がこれらの視点に対応しているためです。所与の空港の例により、許容できる一連の視点をある程度絞り込むことができます。 私たちの場合、国際空港の例が示されているため、おそらく国際線の乗客またはパイロットの視点があるでしょう。

エンティティ タイプを定義するときは、それぞれのエンティティ タイプが次のとおりであることを確認する必要があります。 エンティティインスタンス同じエンティティの他のインスタンスと区別できます。 この要件は、リレーショナル テーブルに重複したタプルが存在しないという要件に似ています。

繋がり 2 つの間に確立された関連付けをグラフィックで表現したものです。 エンティティタイプ。 エンティティと同様に、関係は一般的な概念であり、関連付けられた両方のタイプのエンティティのすべてのインスタンスは、確立された関連付けルールの対象となります。 したがって、エンティティ タイプ間で確立される接続のタイプについて話すのがより正確です。 接続タイプのインスタンス、間にインストールされています エンティティ タイプのインスタンス. 6ただし、エンティティ タイプと同様に、関係タイプという意味で関係という用語を使用することがよくあります。ここで説明する ER モデルのバージョンでは、この関連付けは常にバイナリであり、2 つの異なる間で存在できます。 エンティティタイプまたはエンティティのタイプとそれ自体の間 ( 再帰的接続）。 どのような接続においても、(接続されたエンティティの既存のペアに従って) 2 つの端が識別され、それぞれに接続の端の名前が示されます。 接続の終了の程度(特定の関係タイプの各インスタンスに、特定のエンティティ タイプのインスタンスがいくつ存在する必要があるか)、 必須のコミュニケーション(つまり、特定のエンティティ タイプのインスタンスが、特定の関係タイプのインスタンスに参加する必要があるかどうか)。 7 ER モデルの一部のバージョンでは、接続の終端は と呼ばれます。 コミュニケーションの役割この実体の中で。 次に、このエンティティにおけるコミュニケーション役割の役割の名前、役割の程度、義務について話します。

接続は、2 つのエンティティを接続する、またはエンティティからエンティティ自体につながる無向線として表されます。 この場合、エンティティとの接続の時点で、以下が使用されます。

• エンティティの四角形への 3 点エントリ。そのエンティティのリレーションシップで多くの ( 多くの) エンティティインスタンス ;
• シングルポイントエントリー (1 つだけが接続に参加できる (または参加すべき) 場合) エンティティインスタンス.

接続の必須の端は実線で示され、オプションの端は点線で示されています。

図に示すエンティティ TICKET と PASSENGER の関係は、 9.2、切符と乗客を結び付ける。 「for」という名前のリンク端を使用すると、複数のチケットを同じ乗客に関連付けることができ、各チケットは異なる乗客に関連付けられます。 「has」という名前の接続の終わりは、各チケットは 1 人の乗客のみが所有でき、乗客は少なくとも 1 枚のチケットを所有する必要がないことを示します。

• 各チケットは 1 人の乗客のみを対象としています。
• 各乗客は 1 枚以上のチケットを持っているか、まったくチケットを持っていない場合があります。

の上 次の例(図9.3)を示します 再帰的接続、MANの本質とそれ自体を結びつけます。 「息子」という名前とのつながりの終わりは、複数の人が同じ父親の息子になり得るという事実を定義します。 「父親」という名前とのつながりがなくなるということは、すべての人が息子を持つべきではないということを意味します。

描かれた図の簡潔な口頭解釈は次のとおりです。

• すべての人はただ一人の人の息子です。
• すべての男性は 1 人以上の男性の父親になることができます。

エンティティ属性エンティティの状態を明確にし、識別し、分類し、数値的に特徴付け、または表現するために役立つ詳細です。 属性名は長方形の中に入力されます。

他のモデルと同様、エンティティ関係モデルにはいくつかの要素があります。 基本概念、最初のレンガを形成し、そこからさらに多くのレンガが構築されます 複雑なオブジェクトあらかじめ決められたルールに従って。

このモデルは 最大限にこれはオブジェクト指向設計の概念と一致しており、現在、間違いなく複雑な開発の基礎となっています。 ソフトウェアシステム非常に多くの概念があなたにとってなじみのあるものに思えるかもしれません。これが本当であれば、ER モデルに基づいたデータベース設計テクノロジを習得するのがより簡単になります。

ER モデルは、次の基本概念に基づいています。

• エッセンス入りこれを利用して、類似したオブジェクトのクラスがモデル化されます。 エンティティには、モデル化されているシステム内で一意の名前が付けられます。 エンティティは同じタイプのオブジェクトの特定のクラスに対応するため、システム内にこのエンティティのインスタンスが多数存在すると想定されます。 エンティティの概念が対応するオブジェクトには独自のセットがあります 属性 -特定のクラス代表の特性を決定する特性。 この場合、属性のセットは、エンティティの特定のインスタンスを区別できるようなものでなければなりません。 たとえば、従業員エンティティには、従業員番号、姓、名、父称、生年月日、子供の数、海外の親族の存在などの属性セットが含まれる場合があります。 エンティティの特定のインスタンスを一意に識別する一連の属性は、 鍵。従業員エンティティの場合、従業員番号は特定の企業のすべての従業員で異なるため、キー属性は従業員番号になります。 Employee エンティティのインスタンスは、企業の特定の従業員の説明になります。 一般に受け入れられているものの 1 つ グラフィックシンボルエンティティ - 上部にエンティティの名前が書かれ、その下に属性がリストされ、主要な属性がたとえばアンダースコアや記号でマークされている四角形。 特殊なフォント(図 7.1):

米。 7.1.ERモデルにおけるエンティティ定義の例

エンティティ間を設定可能 コミュニケーション- エンティティがどのように相互に関係し、相互作用するかを示すバイナリ関連付け。 関係は 2 つの異なるエンティティ間、またはエンティティとそれ自体の間に存在できます。 (再帰接続)。エンティティ インスタンスが互いにどのように関係しているかを示します。 2 つのエンティティ間に関係が確立されると、一方のエンティティともう一方のエンティティのインスタンス間の関係が定義されます。 たとえば、「学生」エンティティと「教師」エンティティの間に接続があり、この接続が卒業証書プロジェクトの監督である場合、各学生の監督者は 1 人だけですが、同じ教師が多数の大学院生を監督できます。 したがって、これは 1 対多 (1:M) の関係になり、教師側に 1 つ、生徒側に多数が存在します (図 7.2 を参照)。

米。 7.2.エンティティ「生徒」と「教師」をリンクする場合の 1 対多の関係の例

表記が異なれば、コミュニケーション能力の表現方法も異なります。 この例では CASE 表記を使用します パワーシステムデザイナーさん、ここではリンクを 3 つに分割して多重度を表しています。リンクには「Degree Design」という共通名があり、両方のエンティティの役割名が付いています。 この役割を学生側からは「指導を受けて論文を書く」といい、教師側からはこのつながりを「指導」といいます。 接続をグラフィカルに解釈すると、エンティティ間の関係の意味が視覚的に分かりやすくなります。 接続は、その多重度に応じて 3 つのタイプに分類されます。 一対一(1:1), od と i-to-many(1M)、 多対多（んん）。 1 対 1 の関係とは、1 つのエンティティのインスタンスが別のエンティティの 1 つのインスタンスのみに関連付けられていることを意味します。

関係 1: M は、関係の左側にあるエンティティの 1 つのインスタンスを、関係の右側にあるエンティティの複数のインスタンスに関連付けることができることを意味します。 1 対 1 (1:1) 関係は、1 つのエンティティの 1 つのインスタンスが別のエンティティの 1 つのインスタンスのみに関連付けられることを意味し、多対多 (M:M) 関係は、エンティティの最初の 1 つのインスタンスが関連付けられることを意味します。エンティティは 2 番目のエンティティの複数のインスタンスに関連付けることができ、逆に 2 番目のエンティティの 1 つのインスタンスを 1 番目のエンティティの複数のインスタンスに関連付けることもできます。 たとえば、エンティティ「Student」と「Discipline」の間のタイプ「Study」の関係を考えると、これは「多対多」(M:M) タイプの関係になります。それぞれの分野は多くの学生によって研究されていますが、そのような関係は図に示されています。 7.3.

• 2 つのエンティティ間では、異なるセマンティック負荷を持つ任意の数の接続を指定できます。 たとえば、2 つのエンティティ「生徒」と「教師」の間に、2 つの意味上のつながりを確立できます。1 つは前述の「ディプロマ デザイン」で、2 つ目は条件付きで「講義」と呼ばれ、どの教師の講義がこの接続であるかが決まります。この教師は生徒に講義をします。 これは次のような接続であることは明らかです 多対多。これらの接続の例を図に示します。 7.3.

米。 7.3.多対多の関係をモデル化する例

• これらのタイプのコミュニケーションはいずれも可能です 必須、エンティティのすべてのインスタンスが特定の関係に参加する必要がある場合、 オプション -すべてのエンティティ インスタンスが特定の関係に参加する必要がない場合でも、 この場合、接続は次のようになります。 一方では必須そして 一方、オプションです。接続の必須の性質も、異なる表記法で異なる方法で示されます。 ここでも POWER DESIGNER 表記を使用します。 ここで、接続のオプションは接続の端にある白丸で示され、義務は接続を取り消す垂直線で示されます。 そして、この表記には簡単な解釈があります。 円は、どのインスタンスもこの接続に参加できないことを意味します。 また、垂直は、エンティティの少なくとも 1 つのインスタンスがこの接続に関与していることを意味すると解釈されます。

これを行うには、前述の「ディプロマ デザイン」接続の例を考慮してください。 この図では、この接続は両側でオプションとして解釈されます。 しかし実際には、論文を書くすべての学生には自分の論文プロジェクトの指導者が必要ですが、一方で、すべての教師が論文プロジェクトを主導する必要はありません。 したがって、この意味論的な定式化では、この接続のイメージは変化し、図に示すように同じように見えます。 7.4.

米。 7.4.エンティティ間の必須およびオプションの関係の例

さらに、ER モデルでは、エンティティの分類の原則が可能になります。 これは、オブジェクト指向プログラミング言語と同様に、エンティティのサブタイプの概念が導入されることを意味します。つまり、エンティティは 2 つ以上のサブタイプとして表現できます。 エンティティ、それぞれに、共通の属性と関係、および/または一度に定義される属性と関係がある場合があります。 上位レベルそして下位レベルに継承されます。 1 つのエンティティのすべてのサブタイプは相互に排他的であるとみなされ、エンティティをサブタイプに分割する場合は、次の形式で表す必要があります。 フルセット相互に排他的なサブタイプ。 分析レベルでは特定できない場合 完全なリストサブタイプを追加すると、条件付きで OTHERS と呼ばれる特殊なサブタイプが導入され、さらに明確化できます。 で 実際のシステム場合によっては、2 つまたは 3 つのレベルでサブタイプを導入するだけで十分な場合があります。

サブタイプの構築に基づいてエンティティは次のように呼ばれます。 スーパータイプ。スーパータイプのインスタンスはすべて、特定のサブタイプに属している必要があります。 のために グラフィック画像エンティティの分類または分類の原則、特別な グラフィック要素、と呼ばれる 識別子ノード、 POWER DESIGNER 表記では、凸面が超エンティティに面した半円として描かれます。 この側は、有向矢印によってスーパーエンティティに接続され、このエンティティのサブタイプは矢印によってこの円の直径に接続されます (図 7.5 を参照)。

米。 7.5。TEST エンティティのサブタイプ図

この図は次のように解読できます。 テスト システムの各テストは、SQL 言語の知識のテスト、事前に作成された Java アプレットを使用して実行される分析タスク、または一連の質問で構成される知識の一部の領域のテストのいずれかです。そして各質問に対して提案された一連の回答。

エンティティと関係のセットの形式でドメイン モデルを構築した結果、接続されたグラフが得られます。 結果として得られるグラフでは、循環接続を避ける必要があります。循環接続はモデルの不正確さを明らかにします。

例として、図書館で提示されている書籍や知識分野に関する情報を保存するように設計されたシステムの神話モデルを設計します。 主題領域の説明は以前に与えられました。 主要なエンティティを特定することからモデルの開発を始めましょう。

まず第一に、「本」というエンティティがあり、各本にはそのキーとなる固有の暗号と、主題領域の説明から取得された多数の属性があります。 エンティティ インスタンスのセットは、図書館に保管される書籍のセットを定義します。 「Book」エンティティの各インスタンスは、棚にある特定の本ではなく、通常は図書館の主題目録に記載されている特定の本の説明に対応します。 各本は複数部存在する可能性があり、これらは図書館の本棚にある特定の本にすぎません。

これを反映するには、ライブラリに保存されている書籍のすべてのコピーの説明を含むインスタンス エンティティを導入する必要があります。 Instances エンティティの各インスタンスは、棚上の特定の本に対応します。 各コピーには、特定の書籍を一意に識別する一意のアクセッション番号が付いています。 さらに、本の各部は図書館にあるか、特定の読者の手に渡っている可能性があり、後者の場合、特定の部数について、読者が本を手に取った日付と返却予定日が記録されます。本に追加表示されます。

「ブック」エンティティと「インスタンス」エンティティの間には 1 対多 (1:M) の関係があり、これは両側で必要です。 このタイプの接続は何によって決まるのでしょうか? 各書籍が図書館に複数部存在する可能性があるため、1 対多の関係になると想定できます。 さらに、図書館に特定の書籍のコピーが 1 部も存在しない場合、その説明は保存されません。そのため、書籍が「書籍」エッセンスで説明されている場合、この書籍の少なくとも 1 部が図書館に存在します。 。 これは、書籍側では接続が必須であることを意味します。 「Copies」エンティティに関しては、特定の書籍に関連しない単一のコピーがライブラリ内に存在することはできないため、「Copies」側からの接続も必須です。

次に、リーダーがシステム内でどのように表現されるかを決定する必要があります。 この目的のために、各インスタンスが特定のリーダーに対応する「Readers」エンティティの導入を提案するのは自然なことです。 図書館では、各リーダーに固有の図書館カード番号が割り当てられ、これによりリーダーを一意に識別できます。 図書館カード番号は、Readers エンティティのキ​​ー属性になります。

さらに、「読者」エンティティには、割り当てられたタスクを解決するために必要な追加の属性が必要です。これらの属性は、「姓、名、父称」、「読者の住所」、「自宅の電話番号」、および「勤務先の電話番号」です。 。 電話機に 2 つの別々の属性を導入したのはなぜですか? 必要だから 違う時間読者を捕まえるためにこれらの番号に電話する必要があるため、図書館管理者はどのタイプを知ることが重要になります。 この電話。 主題領域の説明では、読者の年齢に制限があるため、「読者」エンティティに必須属性「生年月日」を導入する必要があります。これにより、読者の年齢を制御できるようになります。 。

主題領域の説明から、各読者が数冊の本を手に持つことができることがわかります。 この状況を反映するには、「リーダー」エンティティと「インスタンス」エンティティの間に接続を作成する必要があります。 なぜ「読者」と「本」というエンティティの間ではだめなのでしょうか？ なぜなら、読者は単なる本ではなく、図書館から特定の本の特定のコピーを手に取るからです。 特定の読者がどの本を持っているかをどうやって調べることができますか? そして、これは、エンティティ「インスタンス」と「書籍」の間の追加の接続によってわかります。この接続により、各インスタンスに 1 冊の本が割り当てられるため、どの書籍が読者の手元にあるのかをいつでも明確に判断できます。私たちは、読み取られた本の在庫番号のみを読者に関連付けます。 「リーダー」エンティティと「インスタンス」エンティティの間には 1 対多の関係が確立されますが、同時にそれは両側でオプションです。 リーダーイン この瞬間彼は一冊の本も手に持っていない可能性があり、その一方で、その本のこのコピーは誰の読者も所有しておらず、単に図書館の棚に立っているだけかもしれません。

次に、システム ディレクトリに関連付けられている最後のエンティティを反映する必要があります。 システム カタログには、図書館の書籍に含まれている情報を含む、すべての知識分野のリストが含まれています。 著者やタイトルがわからない場合は、通常、図書館のシステム カタログから必要な本を探し始めることができます。 ナレッジエリアの名前は長くなり、複数の単語で構成される場合があるため、システム カタログをモデル化するために、「ナレッジ エリア コー​​ド」と「ナレッジ エリア名」という 2 つの属性を持つエンティティ「システム カタログ」を導入します。 ナレッジエリアコード属性は、エンティティのキ​​ー属性になります。

主題領域の説明から、各書籍には複数の知識領域の情報が含まれる可能性があることがわかりますが、一方で、実践から、図書館には同じ知識領域に関連する多数の書籍が含まれる可能性があることがわかります。エンティティ間に「システム カタログ」と「ブック」を確立する必要があります。これは多対多の関係であり、両側で必須です。 確かに、システムカタログにはそのような知識分野が含まれるべきではなく、図書館のどの本にも掲載されていない情報は無意味です。 逆も同様で、読者がより早く見つけられるように、各書籍を 1 つ以上の知識分野に割り当てる必要があります。

「図書館」主題領域の神話モデルを図に示します。 7.6.

米。 7.6.神話モデル「図書館」

私たちは、先に挙げたタスクのために神話モデル「図書館」を開発しました。 これらのタスクでは、たとえば、以前にその本を持っていて、本を傷つけたり、誤って多額のお金を忘れたりした可能性のある人を見つけることを目的として、本の読書履歴を保存するための条件は設定しませんでした。 この情報を保存するというタスクを自分自身に設定すると、情報論理モデルは異なるものになるでしょう。 この仕事はあなたの自主的な創造性に委ねます。

文書の典型的な形式 論理ドメインモデル ERモデリングでは エンティティ関係図、またはER図（エンティティ関係図）。 ER 図を使用すると、シンプルで直感的でありながら厳密に定義されたルールに従って、論理モデルのすべての要素をグラフィカルに表現できます。 表記法.

ER 図を作成するには、通常、最も一般的な 2 つの表記法のいずれかが使用されます。

• 情報モデリングのための統合 DEFinition (IDEF1X)。 この表記法はアメリカ陸軍のために開発され、アメリカ連邦標準となりました。 さらに、それは多くの標準です 国際機関(NATO、国際通貨基金など)。
• 情報工学 (IE)。 Martin、Finkelstein らによって開発された表記法は、主に業界で使用されています。

ER 図は通常、CASE ツールを使用して構築されます。 この講義では、特に断りのない限り、すべての例で MS Office Visio 2007 の表記を使用します。

ER 図上のエンティティは、上部に名前が付いた長方形で表されます (図 6.3)。

米。 6.3. ER 図上の「従業員」エンティティの表現

四角形のリスト エンティティの属性を構成する属性は 一意のエンティティ識別子、下線が引かれています (図 6.4)。

毎 エンティティインスタンス一意であり、他の属性とは異なる必要があります。 メインの 1 つ コンピュータによる方法 IS におけるエンティティ認識は、エンティティへの識別子 (エンティティ識別子) の割り当てです。 エンティティはその属性のセットによって定義されるため、エンティティごとに、このエンティティを一意に識別する属性のサブセットを選択することをお勧めします。 頻繁 エンティティ識別子主キーと呼ばれます。

主キーは、エンティティのインスタンスを一意に識別する属性または属性のグループです。。 図の主キー属性には特別な指定は必要ありません。これらは上記の属性リストにある属性です。 水平線(図6.3)。

主キーの選択は難しい作業になる可能性があり、その解決策は将来の情報システムの有効性に影響を与える可能性があります。 1 つのエンティティには、主キーであると主張する複数の属性または属性のセットが含まれる場合があります。 このような応募者はこう呼ばれます 潜在的なキー(候補キー)。

キーは次のとおりです。 複雑な、つまり いくつかの属性が含まれています。 複雑な主キーには特別な表記は必要ありません。これらは水平線の上にある属性のリストです。

「従業員」エンティティの主キーの候補を考えてみましょう (図 6.5)。

ここでは、次の潜在的なキーを特定できます。

1. 職員番号。
2. パスポートID。
3. 姓 + 名 + 父称。

プライマリーになるには 潜在的な手がかり多くの要件を満たさなければなりません。

独自性。 2 つのインスタンスが同じ候補キー値を持つことはできません。 潜在的な鍵 (姓 + 名 + 父称) は、その組織に完全に同名の人物が働いている可能性があるため、悪い候補です。

コンパクトさ。 複合候補キーには、削除しても一意性が失われない属性を含めてはいけません。 キーの一意性を確保するには ( 姓 + 名 + 父称) 属性で補足しましょう 生年月日そして 目の色。 ビジネス ルールで属性の組み合わせが次のように規定されている場合、 姓 + 名 + 父称 + 生年月日従業員を一意に識別するのに十分な場合 目の色余分であることが判明、つまりキー 姓 + 名 + ミドルネーム + 生年月日 + 目の色コンパクトではありません。

主キーを選択するときは、より多くのキーを優先する必要があります。 単純なキーつまり、キーに含まれる属性が少なくなります。 この例では、キー #1 と #2 がキー #3 よりも優先されます。

キー属性には以下を含めてはなりません ゼロ値。 従業員がパスポートを持っていない、またはパスポートの代わりに他の身分証明書を持っている可能性がある場合、キー No. 2 は主キーとしては適していません。 一意性を確保するために補足が必要な場合 潜在的な手がかり 追加の属性の場合、ゼロ値を含めることはできません。 キーNo.3を属性で追加する場合 生年月日生年月日を全従業員に周知させる必要があります。

キー属性の値は、その存在全体を通じて変更されるべきではありません。 エンティティインスタンス。 組織の従業員は結婚して姓とパスポートの両方を変更することができます。 したがって、キー No.2 とキー No.3 は主キーとしては適していません。

すべてのエンティティには少なくとも 1 つが必要です 潜在的な手がかり。 多くのエンティティは 1 つだけ持っています 潜在的な手がかり。 これが主キーになります。 エンティティによっては、複数のキーを持つ可能性があります。 その後、そのうちの 1 つがプライマリになり、残りが - 代替キー. 代替キーは、主キーになっていない潜在的なキーです。.

一部のエンティティには自然 (自然) キーがあります。 たとえば、請求書の自然な識別子はその番号です。 それ以外の場合、設計者はサロゲート キー (サロゲート キー) を作成できます。サロゲート キーは、その値が人為的に作成され、サブジェクト領域に関連しない属性です。 データ ウェアハウスのデータ構造をモデル化する場合、多くの状況で代理キーが推奨されます。

ドメインはアナリストによって割り当てられ、特別な文書に記録されます - データディクショナリ(データディクショナリ)。 論理モデルを作成する場合、ER 図のエンティティでドメインを指定できます。

各属性にはドメインがあります。 ドメインは、通常の属性を作成できる抽象属性として定義でき、作成された属性は親ドメインのすべてのプロパティを持ちます。 各属性は 1 つのドメインでのみ定義できますが、各ドメインで複数の属性を定義できます。 ドメインの概念には、データ型だけでなく、データ値の範囲も含まれます。 たとえば、ドメイン「Age」を正の整数として定義し、属性を定義できます。 従業員の年齢このドメインに属するものとして。

レベルで ロジックモデリング属性へのドメインのデータ割り当ては一般的です。 たとえば、属性はテキスト、数値、バイナリ、日付、または「未定義」です。 後者の場合、アナリストはドメインの説明を提供する必要があります。 その後の段階で、ドメインのタイプが指定されます。物理データ モデルにおけるドメインの概念の意味は、アナリストが理解できるよりも狭いものです。 これは、物理モデル内でドメインがドメイン制限メカニズムを通じて実装されているため、DBMS は未定義のドメインを認識しません。

設計者は、アナリストの参加を得て、DBMS での実現可能性の観点から各属性のドメインを注意深く検討し、実現可能性の条件が満たされない場合は変更を加える必要があります。 この場合、設計者は次の指示に従います。

• リレーショナル データベースを実装するには、リレーショナル DBMS またはオブジェクト リレーショナル DBMS (MS など) を使用する必要があります。 SQLサーバー 2008;
• 大多数で リレーショナル DBMS SQL はデータの操作と記述のための言語として使用され、ANSI SQL-92 などの特定の標準をサポートします。

姿勢（つながり） ER 図上のエンティティは、これらのエンティティを接続する線で表されます。 比率は、線に沿って左から右、または右から左に読み取られます。 図では、 6.6 次の関係が示されています: 各教育専門分野は特定の個人 (人) に登録されなければなりません。 個人教育に関して 1 つ以上の専門分野を持っている場合があります。

MS Office Visio では、リンク名、リンク強度 (パワー)、 エンティティのメンバーシップ クラス図に示すように、接続への接続は [データベース プロパティ] タブで定義されます。 6.7. 通信回線の矢印が指しているのは、 親テーブル.

つながりを特定するときは、その特徴を特定することに重点が置かれます。 関係とは、2 つ以上のエンティティ間の関係です。 それぞれのつながりは価値観を通じて実現されます エンティティの属性、 例えば、 エンティティインスタンス「従業員」（図6.6）は、 エンティティインスタンス同じ属性値に基づく「教育」 職員番号。 つまり、子エンティティと呼ばれるエンティティの 1 つにリレーションシップを作成すると、という新しい属性が作成されます。 外部キー(外部キー、FK) (図 6.6 では、これは属性です 職員番号）。 外部キー属性は、名前の後に記号 (FK) で示される場合があります。

関係とは、エンティティ間の論理的な関係です。 各関係には動詞または動詞句として名前を付ける必要があります 関係名 (動詞句) – 親エンティティと子エンティティ間の関係を特徴付ける句。 関係名は何らかの制約やビジネス ルールを表し、図を読みやすくします。 図では、 図 6.8 は、関係に名前を割り当てる方法を示しています。

関係には、1 対多の識別関係、多対多の関係、1 対多の非識別関係など、さまざまな種類があります。 さまざまなタイプのエンティティも関係タイプに関連付けられます。

エンティティには次の 2 種類があります。 依存(依存エンティティ) および 独立した(独立した組織)。 エンティティのタイプは、他のエンティティとの関係によって決まります。 識別関係は、独立エンティティ (関係の親側) と依存エンティティ (関係の子側) の間に確立されます。

依存エンティティのインスタンスは、親エンティティとの関係、つまり図の構造内でのみ定義されます。 6.8 専門分野に関する情報は入力できず、学歴を持つ専門分野を持つ従業員に関する情報がなければ意味がありません。 識別関係が確立されると（図の実線）、親エンティティの主キーの属性が子エンティティの主キー（実線）に自動的に転送されます。 これ 加算演算関係を作成するときの子エンティティの属性は、属性の移行と呼ばれます。 子エンティティでは、このような属性は外部キーとみなされます。

CASE ツールを使用してモデルが作成されている場合、データベース スキーマの生成時に主キー属性は NOT NULL 属性を受け取ります。これは、従業員の従業員番号に関する情報がなければ「従業員」テーブルにエントリを作成することは不可能であることを意味します。

非識別関係が確立されると (図 6.9、点線)、子エンティティは独立したままとなり、親エンティティの主キー属性は親エンティティの非キー コンポーネントに移行されます。 非識別関係は、独立したエンティティをリンクするために使用されます (図 6.9)。

エンティティインスタンス「従業員」は、何の関係も持た​​ずに存在する可能性があります。 エンティティインスタンス「部門」、つまり、従業員は組織内で働くことができますが、どの部門にも登録されません。

識別接続は、接続の子端に太字の点が付いた実線として図に示され (図 6.8 を参照)、非識別接続は点線で示されます (図 6.9 を参照)。

多対多の関係(多対多の関係) は論理モデル レベルでのみ作成できます。 図では、 図 6.10 に、多対多の関係を定義する例を示します。 医師は多くの患者を診察することができ、患者は複数の医師によって治療されることがあります。 このような接続は、端に 2 つの矢印が付いた実線で示されます。

「多対多」関係は、両方向の 2 つのフレーズで名前を付ける必要があります (例では「受け入れる/扱われます」)。 これにより、図が読みやすくなります。 お問い合わせ

Khabravian ueasley による記事「開発 → データベース テーブルの関係」と「開発 → データベースの設計」に少し追加したいと思います。

リレーショナル データベース スキーマを構築するためのルールについて説明したいと思います。 これらのルールは、開発者が直感的なレベルで使用するものであるため、おそらく誰にとってもほとんど役に立ちませんが、データベース スキーマを構築するプロセスを形式化するため、興味深いものですらあります。

これらのルールは ER モデル、つまり「エンティティ関係」モデルに適用されます。

ERモデル

ER モデルは、次のコンポーネントを含む図です。

• エッセンス- これは現実または架空のオブジェクトであり、その情報はデータベースに保存する必要があります。 ER モデル図では、エンティティは、エンティティの名前を含む四角形として表されます。
• 繋がり- 2 つの (ほとんどの場合) エンティティ間の関連付け、または同じエンティティ間の関連付け (再帰的関係)。図上にグラフィカルに表示されます。 接続は、エンティティごとに 1 つずつ、2 つの端を持つダイヤモンドとして描かれています。 この接続の各側で、以下が確立されます。
  1. 関連度 - 特定のエンティティのインスタンスがいくつ関連付けられているか
  2. 必須接続 - このエンティティが必ず接続に参加する必要があるかどうか。

「ORDER」エンティティの側から見ると、その関係は追加の四角形で示されていることに注意してください。これは、「ORDER」エンティティの各インスタンスが「CLIENT」エンティティのインスタンスに対応することを意味します（クライアントにとって、注文は必要ありません）。 次数「M」は、「CLIENT」エンティティのインスタンスごとに「ORDER」エンティティの複数のインスタンスが存在できることを意味します（ただし、各注文には常に顧客が 1 人だけであるため、その逆はありません。次数を「」に設定します） 1”）

リレーションシップ (通常はデータベース内のテーブルに対応する) をエンティティと混同しないでください。 エンティティは、ER 図から分離することによってリレーションに変換されます。

設計段階

1. コンセプチュアルデザイン

   すべてのエンティティと関係を含む ER 図が構築されます。 概念的 (情報学的) モデルが得られます。 このようなモデルは、設計中のデータベースの関係構造に十分に対応していない可能性があることを理解する必要があります。

   を保存する必要があるデータベースを構築する必要があるとします。 完全な情報注文、顧客、従業員について。 各注文には、この注文の要素 (複数の製品) のリストがあり、それぞれが消費された材料と実行された操作のリストに関連付けられています。

   次の図を思いつきました。

   
   米。 2

2. 論理設計

   予備的な関係のセットが構築され、各関係の主キーが示されます。 属性のリストがコンパイルされ、これらの属性が関係に分散されます。 すべての関係が BCNF 内に残ることが必要です。

   リレーショナル構造への移行 (一連の関係の構築) は、次のルールに従って行われます。

   1. 二項関係の次数が 1:1 で、両方のエンティティのメンバーシップ クラスが必要な場合、必要な関係は 1 つだけです。 この関係の主キーは、これら 2 つのエンティティのいずれかのキーにすることができます。 この場合、各キー値はリレーションのどのインスタンスでも 1 回出現することが保証されます。
   2. バイナリ リレーションシップの次数が 1:1 で、エンティティの 1 つのクラスがオプションの場合、2 つのリレーションシップを構築する必要があり、エンティティごとに 1 つのリレーションシップを割り当てる必要があります。 メンバーシップ クラスがオプションであるエンティティのキ​​ーは、必須のメンバーシップ クラスを持つエンティティに割り当てられた関係に属性として追加されます。
   3. 二項関係の次数が 1:1 で、どのエンティティのメンバーシップ クラスもオプションではない場合、エンティティごとに 1 つずつ、3 つのリレーションシップが使用されます。そのキーは、対応するリレーションシップでプライマリとして機能し、もう 1 つはリレーションシップ用です。 関係専用の関係には、各エンティティからの 1 つのエンティティ キーがあります。
   4. 二項関係の次数が 1:M で、M 関連エンティティのメンバーシップ クラスが必須の場合は、エンティティ キーがエンティティの主キーとして機能する限り、エンティティごとに 1 つずつ、つまり 2 つの関係を使用するだけで十分です。対応関係。 単純接続エンティティのキ​​ーは、M 接続エンティティに割り当てられた関係に属性として追加する必要があります。
   5. 二項関係の次数が 1:M で、M 関連エンティティのメンバーシップ クラスがオプションの場合、エンティティ用とリレーションシップ用の 3 つの関係を使用する必要があります。 リレーションシップには、その属性の中に各エンティティのエンティティ キーが含まれている必要があります。
   6. バイナリ関係の次数が M:M の場合、データを保存するには 3 つの関係が必要です。1 つはエンティティ用、もう 1 つはリレーションシップ用です。 エンティティ キーは関係に含まれます。 エンティティの 1 つが縮退している場合、リレーションシップが 2 つ存在します (つまり、テーブルが 2 つあれば十分です)。
   7. 3 者関係の場合は、エンティティごとに 1 つ、リレーションシップに 1 つという 4 つの関係を使用する必要があります。 接続によって生成されるリレーションには、その属性の中に各エンティティからのエンティティ キーが含まれます。

   ルールを使用してデータをテーブルに入力してみましょう。

   エンティティ	ルール番号	関係
   クライアント 注文	4	クライアント(#クライアント Order(#Order, #Customer
   従業員 注文	4	従業員(#従業員 Order(#注文, #従業員
   注文 注文品	4	注文(#注文 Order 要素(#Order 要素, #Order
   旅団 注文品	4	旅団(#旅団) 順序要素(#Element, #Crew
   製品 注文品	4	製品(#製品 注文アイテム(#Items, #Products
   クライアント 注文	6	クライアント(#クライアント 注文(#注文 支払い(#支払い、#クライアント、#注文
   旅団 従業員	5	旅団(#旅団) 従業員(#従業員 チーム従業員(#旅団従業員、#従業員、#旅団)
   注文品 手術	5	注文品目(#品目 オペレーション(#オペレーション レコード操作(#Records, #Element, #Operations
   注文品 材料	5	注文品目(#品目 素材(#素材 消費(レコード数, 要素数, マテリアル数)

   テーブル 1

   結果の関係に従って属性を分散すると、次のようになります (フィールドのリストでは、主キーが最初にあり、残りは「#」でマークされ、外部キーです)。

   旅団	(#乗組員、#職長、場所)
   役職	(役職数、役職、給与)
   注文	(#注文、#クライアント、#従業員、配置日、必須日、実行日、説明)
   クライアント	(#顧客、役職、名、姓、組織または部門、住所、電話番号、電子メール アドレス)
   録音操作	(#レコード、#アイテム、#オペレーション、#従業員、数量)
   支払い	(#お支払い、#クライアント、#注文、お支払い金額、お支払い日、注意事項)
   消費	(レコード数、消耗品数、アイテム数、数量)
   コンパウンド	(#品目、#注文、#製品、#チーム、数量)
   ソトルブリガダ	(#乗組員旅団、#旅団、#従業員)
   従業員	(#従業員、パスポート番号、姓、名、父称、#役職、住所、自宅の電話番号、勤務先の電話番号、生年月日、入社日、契約終了日、写真、メモ)
   手術	(#作業、説明、コスト、時間、設備、実行)
   材料	(#Exp.Mat、NaimExp.Mat、価格、密度、タイプ、組成)
   製品	(#製品、ブランド、名前、製品の説明、タイプ、シリアル番号、在庫、価格)

   テーブル 2

これが私たちが大学で教えられたことです。 もしかしたら誰かが興味を持ってくれるかもしれません。 「これは必要ですか？」については、あなたの意見を聞きます！

物理モデル(表形式) データには、特定の DBMS の特定のデータベースに実装されているすべてのオブジェクトの定義が含まれています。

モデルはデザインの基礎です。 エンジニアは車のモデルを構築し、生産に投入する前にすべての詳細を検討する必要があります。 同様に、システム エンジニアはまずビジネス ロジックを検討し、データベース構造の理解を深めていくためのモデルを開発します。

前回の講義では、情報システム内で発生するビジネス プロセスを記述できるようにする IDEF0 と DFD の方法論について学びました。 DFD モデルでは、システムが動作する情報の種類を示すデータ ストアという要素を考慮しました。 ただし、この方法論は、保存された情報の構造を説明することを目的としたものではありません。 さまざまなエンティティ関係図 (エンティティ図) がこれに適しており、その目的は、保存されたデータの構造とそれらの間の関係を記述することです。 このようなデータを、情報システム データベース内に必要なストレージ (テーブル) を作成する一連のコマンドに変換できる方法が開発されています。

ERモデリング

情報システムでは、データは個別のカテゴリまたはエンティティに分割されます。 結局のところ、データベースは一連の構造化データであることを思い出してください。 データ さまざまな種類別々に保管されます。 ER モデルのタスクは、システムにどのような種類の情報が保存されているか、その構造は何か、それらがどのように相互接続されているかを示すことです。 ER モデルは、ビジネス分析 (構築された DF 図) に基づいて構築されます。 この場合、最初は、DF 図上の各ストアが ER 図上のエンティティになります。 さらに分析を進めると、それらを構成要素に分割できます。 ER モデルは DF 図よりもビジネス構造の変化に対する耐性が高いことは注目に値します。 ビジネス プロセスは変更される可能性がありますが、その実装に必要な情報は変更されないことがよくあります。

ER モデルの主な利点:

• 情報の構造を文書化するための正確でわかりやすい形式。
• データの要件とデータ間の関係を指定できます。
• ストレージ構造を明確に表示できるため、データベースの設計が容易になります。
• ER モデルをデータベース テーブルにマッピングしたり、その逆にマッピングしたりする方法があります。
• 他のアプリケーションとの統合の基礎を築きます。

ER 図のオブジェクトの主なタイプは次のとおりです。

• エンティティはオブジェクトのタイプであり、その情報がデータベースに保存されます。 例: 部門、従業員、商品、請求書。
• 属性 - エンティティを構成する要素。 たとえば、「製品」エンティティの場合、情報システムのニーズに応じて、属性は「名前」、「説明」、「数量」、「価格」などになります。 ER 図の表記に応じて、属性の横に、その名前に加えて、タイプと必須の入力が示されます。 このスライドは、「情報工学」表記法での ER 図を示しています。これに従って、名前、タイプ、および外部呼び出しかプライマリ呼び出しかが属性として示されます。
• 関係はエンティティ間のつながりを示します。 たとえば、従業員は部門で働いており、「部門」と「部門」はエンティティです。

エンティティは現実世界のオブジェクトのセットであり、それぞれには次の特性があります。

• ユニーク (何らかの方法で他のすべてから分離できる)
• モデル化されているシステム内で役割を果たします
• 1つ以上の情報(属性)で記述可能

例: 人、スタッフ、イベント、注文、販売、顧客、サプライヤー

属性はエンティティのいくつかのプロパティを記述します。 エンティティには多くの属性を含めることができますが、システムにとって重要な属性のみが選択されます。 属性は、キー (エンティティ キー) と記述 (エンティティ記述子) に分けられます。 キー属性はエンティティのインスタンスを一意に識別する必要があります。 属性ごとに、ドメイン (タイプ、サブジェクト領域) を指定する必要があります。

このスライドでは、エンティティと属性がさまざまな ER モデル表記法でどのように記述されるかを示します。 すべての表記において、エンティティは長方形のオブジェクトであり、その上部にエンティティの名前が示されます。 属性はエンティティ名の下にリストされます。

重要な属性とは何かを詳しく見てみましょう。 これは、エンティティ間の関係の種類を理解するために重要です。

基本用語

関係モデルは、必要に応じて、数学的言語、つまり人間が発明した最も正確な言語で記述することができます。 以下は、リレーショナル モデルのいくつかの概念の大まかな定義です。

• 「データ型」（タイプ、ドメイン - ドメイン） - 許容される値（「ドメイン」）と操作のセット。 すべての型には比較演算と代入演算があります。 数量が、たとえばオブジェクトの構造を持つことは禁止されていません。
• 「関係」 (関係) - 属性のセット: データ型を明確にした一意の名前。 加えて、属性に対応する「値のセット」(「シリーズ」) のセット。 セット内の値は、属性に対応する型の単一の値でのみ表すことができます。つまり、それらはスカラー (「第 1 正規形」) にすることができます。
• 「キー」（キー）は、すべてのセットの値が関係的に異なる属性のグループですが、これらの属性の単一のサブグループはすでにそのようなプロパティ（キーの「最小性」プロパティ）を持っていません。 特に、グループは単一の属性で構成される場合があります。 関係内のキーは常に存在する必要があり、キーが複数ある場合は、そのうちの 1 つを「プライマリ」に指定する必要があります。
• 「外部キー」は、リレーション値の各セットの値が別のリレーションのキーの値と一致する必要がある属性のグループです。 リレーション内の外部キーはオプションであり、モデリングのニーズに従って宣言されます。
• 「Operations」（操作） - 設定 一般的なアクション関係をめぐって、再び関係が生じます（「業務の閉鎖性」）。 これらは、後続のモデリングのニーズに合わせて新しい関係を取得するため、またはデータベースから必要なデータを抽出するときに使用されます。 操作のリストはさまざまな方法で定義できます。 モデルの最初の文では 8 つの操作 (投影、接続、選択など) が指定されていましたが、もう 最小セット、冗長性の欠如と使いやすさの間の妥協点として。
• " リレーショナルデータベース" (リレーショナル データベース) - 一連の関係。

「データ型」は「ドメイン」と呼ばれることもありますが、「ドメイン」は値の「定義領域」のみを指す場合もあります。 ロシア語の「数量のセット」(タプル) は、「タプル」または「n-coy」とも呼ばれます。

便宜上、リレーションシップはテーブルの形式で表されることがよくありますが、そのような表現は正当ではありません（テーブルとは異なり、リレーションでは属性の順序も値のセットの順序も定義されません）。 Oracle DBMS が構築される SQL では、モデリング ツールとしての「リレーションシップ」の概念が「テーブル」に置き換えられます。 関係データの別の表現としてハイパーキューブを使用することもでき、既存のデータベースについて推論する際にハイパーキューブを利用すると便利な場合もあります。

トレースを定義する「リレーショナル」という言葉を放棄すると、「リレーショナル データベース」という用語は「関係データベース」（より正確には「構築されたデータベース」）と翻訳できます。 を通して「関係」; モデリングのオブジェクトとしてではなく、ツールとしての関係。それ以外の場合、元の用語は関係データベースになります)。同様に、「リレーショナル モデル」という用語は、「関係モデル」、つまり「関係モデル」と翻訳できます。一連の関係の形で主題領域のモデルを構築するための概念体系。」歴史的および言語的理由を含む多くの理由により、これは当時行われませんでした。

すべてのデータ関係が説明されています 明らかにそして のみセット内の値 (これは他のモデリング手法では異なる場合があります)。 変数によって定式化される関係を除き、「暗黙の」依存関係 (プログラム ロジックのレベルを含む) はありません。 リレーショナル アプローチでは、データの記述とアプリケーションに付随するプログラム ロジックが区別されます (たとえば、オブジェクト アプローチとは対照的)。

リレーショナル データベース (関係と操作のセット) の上記のビューは、典型的なものです。 関係代数 。 これは唯一の観点ではありません。 関係変数内の値の各セットは、真のステートメント (「述語」) として理解できます。つまり、これこれのプロパティを持つこれこれの従業員が存在します。 あんな部署など。 それによって リレーショナルベースそれぞれの瞬間のデータは、関係性を通じて定式化された、対象領域に関する一連の真実の記述です。 基本的に、次の一連のステートメントは、 関係変数そしてデータベースによって表されるドメインモデルを形成します。 リレーショナル データベースのこのビューは、次の場合に典型的です。 関係計算。 リレーショナル モデルの両方のビューはよく研究されており、表現上の同等性が証明されています。

前のスライドにリストされている用語には、その意味を理解し、覚えやすくするために、非公式の同等の用語があります。

• 関係→テーブル
• タプル → 文字列、レコード
• カーディナリティ → 行数
• 属性 → 列、フィールド
• 次数 → 列数
• 主キー → 識別子
• ドメイン → 許容値の範囲

主要なフィールド

関係の属性の一部はキーです。 キーにはいくつかの種類があります。

• 単純キーは 1 つの属性で構成され、複合キーは複数の属性で構成されます。
• 潜在的な鍵- リレーションの各タプルを識別できる属性または属性のセット。 たとえば、パスポート局に関しては、(「パスポート番号」) と (「氏名」と「生年月日」) が、各個人を一意に識別できるキーとなる可能性があります。
• 各リレーションシップは、主キーを 1 つだけ持つことができます。主キーは、各レコードを一意に識別する値を持つ属性または属性値のセットです。 複数の属性セットにそのようなプロパティがある場合、そのうちの 1 つが主なものとして選択され、他のすべての属性が代替のものとして選択されます。
• 外部キー - ストア 意味別のリレーションの主キー。 外部キーは、リレーションシップ間の通信に使用されます。

主キー

• 各関係関係には主キーが 1 つだけあり、その他はすべて代替キーです。
• すべての主キー属性の値 ない多分 未定義。たとえば、リレーションには都市の住民に関する情報が保存されます。 主キーは複合キー（名前、姓、生年月日）です。 この情報システムはアイスランドに設置されており、アイスランドでは姓が使用されていないため、ほとんどのタプルでは「姓」属性が空白になります。 それにもかかわらず、複合主キーは引き続き各タプルを一意に識別します。 ただし、すべての主キー属性の値が同時に空になることは受け入れられません。
• 主キーの値は、リレーションシップのテーブル ビュー内のタプルの位置には影響しません。 主キーの値が数値 (1、2、3 など) であっても、一般に、データベース内のタプルが同じ順序で格納され、同じ順序で出力されることは保証されません。 「一般的なケース」とは、特定の DBMS の仕様により、行が主キーの順序で格納される場合があることを意味しますが、これはむしろ例外です。 クエリ結果を出力するとき、行の出力順序が重要である場合は、その順序を明示的に指定する必要があります。 「最初の 5 人を教えてください」というクエリの結果は、どのような基準で「最初」にするかを指定しないと予測できません。
• 主キーはタプルの属性へのアクセスには影響しません。 例えば、「パスポート事務所」に関しては、氏名、生年月日とともに登録住所が保管されます。 氏名や生年月日が分からなくても、データベースにすべての住所を抽出するように依頼できます。

外部キー

外部キーは、リレーションシップ間の接続を確立するために使用されます。 たとえば、「所有者」（主キー「パスポート番号」）と「不動産」という 2 つのリレーションシップを考えてみましょう。 各プロパティの所有者を確立するために、「パスポート番号」属性の値によってこれらの関係を結び付けます。 主キーとは異なり、外部キーの値は未定義にすることができます (スライドの 4 行目)。プロパティの所有者がわからない場合は、それを示しません。 主キーとは異なり、外部キーの値は繰り返すことができます (スライドの株式 1.3)。1 人の所有者が複数の不動産オブジェクトを持つことができます。 ただし、「不動産」リレーションの「パスポート番号」属性が「所有者」リレーションの主キーに対する外部キーであるという事実により、「牧師番号」属性の値は次の値のみであることが保証されます。主キー。 所有者リレーション (5 行目) に存在しない属性値として個人の牧師番号を指定することはできません。

外部キーを設定すると、主キーの値を変更したり、タプルを削除したりした場合の DBMS の動作を明示的に設定できます。 ただし、「外部キーには主キーにある値または未定義の値（NULL）のみを格納する」というルールは変わりません。

リレーションシップ間の外部キーは通常、データベースの設計時に指定されます。 ただし、この制約の追加が外部キーのプロパティと競合しない場合は、いつでも削除したり、再インストールしたりできます。 外部キーの削除/インストールは通常、非常に大量のデータを挿入するときに、このプロセスを高速化するために行われます。DBMS は一貫性のない (正しくない、間違った) データを保存できないため、各行を挿入するときに各制約をチェックします。

ER モデル: 接続

ER モデルでは、外部キーはリレーションシップとして表示されます。

各接続は、強度、パワー、程度、接続へのエンティティの参加という 4 つの特性によって特徴付けられます。

これらの特徴を見てみましょう。

関係へのエンティティの参加

接続部分を横線または円で示します。

横線の意味は、 必須 (必須）接続へのエンティティの参加、およびサークル - オプション (オプション).

エンティティが接続に強制的に参加する場合、動詞「 しなければならない"。エンティティが必ずしも接続に参加しない場合、動詞 " 多分".

部門内 多分数人の従業員を雇用します。 従業員 しなければならないいずれかの部門で働いています。

接続度 ( 関係 程度) 関連するエンティティの数を示します。 バイナリ通信（ バイナリ 関係) 2 つのエンティティの関連付けを説明します。 3次接続 (三項 関係) は、3 つのエンティティが関連付けられている場合に発生します。 単項通信 (単項 関係) は、単一エンティティ内の関連付けを説明します。

最も一般的なのはバイナリ接続です。これらは 2 つの異なるエンティティ (「部門」-「従業員」、「注文」-「商品」、「コース」-「講義」、「グループ」-「学生」) を接続します。 あまり一般的ではありませんが、依然としてよく使用されるのは単項接続です。 彼らの助けを借りて、彼らは通常、同じタイプのオブジェクトに入れ子関係 (「詳細」関係 - 指定できます) を設定します。 整数部これはどのような詳細ですか、関係「従業員」です - この場合、どの従業員が上司であるかを示すことができます）。

リンク強度は、1 つのエンティティのインスタンスが別のエンティティのインスタンスに接続されている数を示します。

電力は次のとおりです。

• 一対一(1:1) - 生徒のグループには 1 人の校長がいます。
• 1対多(1:N) - 多くの従業員が 1 つの部門で働いています。
• 多対多(M:N) - 1 人の購入者が多くの商品を購入し、多くの購入者が商品を購入しました。

つながりの強さ：強いつながり（関係性の識別）

子エンティティは親エンティティなしでは存在できません。 (質問がなければ回答はありません。カート自体が存在しない場合、ユーザーのカートには商品がありません)

この場合、主キーは親エンティティから子エンティティに移行され、そこで主キーの一部になります。

図では、強い関係はエンティティ間の実線で表されます。

関係の強さ: 非識別的な関係

親エンティティと子エンティティは関連していますが、子エンティティを先に作成することもできます。 (貨物は注文に属しますが、注文が作成される前に貨物が倉庫にある可能性があります)。

主キーは親エンティティから子エンティティに移行され、主キーの一部ではありません (単に外部キーになります)。

図は強い関係を示しています 点線エンティティ間。

再帰結合 (単項結合)

階層を構築するために最もよく使用されます。

サプライヤーは、ゼロ以上の顧客 (id_Customer) と協力することができます。

顧客は 1 つのサプライヤー (id_Sup) と協力する必要があります。

ただし、サプライヤーと顧客 (それが会社であっても組織であっても) は同じタイプのオブジェクトであるため、同じ関係に格納されます。

多対多の通信。

例: サプライヤーはさまざまな種類の製品を供給する場合があります。 異なるサプライヤーが同じ種類の商品を供給する場合があります。

多対多の関係は ER モデルの観点からは有効ですが、関係代数の観点からは直接反映できません。

関係の曖昧さは、スライドに示すように、移行エンティティを導入することで解決されます。

ER モデルと現実

1 対 1 の関係を詳しく調べると、ほとんどの場合、A と B は実際には同じものの異なるサブセット、またはそれに対する異なる視点であり、名前が異なり、関係と属性の説明が異なるだけであることがわかります。

A がサプライヤー、B が製品であると想像してみましょう。

必須-必須。スライドに示されている例では、この関係は、各サプライヤーが しなければならない 1つだけ供給する 個性的商品セット（請求書）。 理論的な観点から見ると、ここではすべて問題ありません。 実際には、これは受け入れられません。確認したサプライヤーが複数の製品範囲を提供できる場合、誰も新しいサプライヤーを探すことはありません。 次に、新しいサプライヤーに関するデータを入力しようとするときにオペレーターが経験する感情について説明します。 どのテーブルにもデータを入力できなくなります。 したがって、猥褻な言葉の荷物はすべてあなたに向けられることになります。

オプション - 必須。接続例をスライドに示します。 ご覧のとおり、オペレーターは現在すべて問題なく、データを入力できます。 この企業は再び問題に直面しています。たとえ検証したサプライヤーが複数の製品ラインを提供できるとしても、新しいサプライヤーを探さなければなりません。 ビジネスには問題が必要ですか? いいえ。 それは機能しなければなりません。 ビジネスを満足させるにはどうすればよいでしょうか? 答えは簡単です。 データベースを設計するときは、正規化について考慮する必要があります。 サプライヤーがエンティティの場合は、オプション-必須 (必須-オプション) またはオプション-オプションの関係を使用します。 ただし、ほとんどの場合、1 対 1 の関係は間違いです。

オプション-オプション。ご覧のとおり、オペレーターは再び好調ですが、ビジネスは再び問題を抱えています。 1対1のコミュニケーションに向けてまとめてみましょう。 エンティティが次のように接続に参加する場合、 - 必須 - 必須、そのような接続には存続する権利がありません。 - オプション-必須 (必須-オプション) またはオプション-オプションの場合、ビジネス サポートに問題があります。

1 対多の必須-必須関係は、エンティティ B のオカレンスは、それに関連付けられたエンティティ A のオカレンスを少なくとも 1 つ作成することなしには作成できないことを意味する、非常に強力な構造です。ほとんどの場合、これは誤った関係です。

1 対多の必須とオプションの関係は、最も一般的な関係の形式です。 ここでは、エンティティ A のすべてのオカレンスは、エンティティ B の 1 つ（および 1 つだけ）のオカレンスのコンテキスト内でのみ存在できると想定しています。次に、B のオカレンスは、A のオカレンスがあってもなくても存在できます。

1 対多の関係 オプション-オプション - A と B は、それらの間に関係がなくても存在できます。

前のスライドに関して、これらの図は次の例で説明できます。

1 対多の関係。これらの関係は、1 つのテーブル内の 1 つのレコードが別のテーブル内の複数のレコードに論理的に関連付けられることを意味します。

必須-必須。スライドに示されている例では、この関係は、各サプライヤー (A) が 1 つ以上の商品セット (B) を供給する必要があることを意味します。 理論的な観点から見ると、ここではすべて問題ありません。 ただし、実際には、レコードは次のとおりである必要があるため、オペレーターはどのテーブルにもデータを入力できません。 同時に両方のテーブルに入ります。

オプション - 必須。この場合、オペレーターにとってはすべて問題ありません。オペレーターはデータを入力できますが、ビジネスに問題が発生する可能性があります。 重要なのは、オプションと必須の関係では、サプライヤー (A) が次のことを前提としているということです。 しなければならない 1 つ以上の商品セット (B) を供給し、B 多分サプライヤーに属します。 言い換えれば、供給者が商品を所有している間、商品は供給者なしで存在することができます。 それらの。 管理されていないビジネス行為の可能性があります。商品を供給したのは誰ですか? 誰に聞けばいいのでしょうか？ ビジネスには問題が必要ですか? いいえ。 それは利益を生まなければなりません。 この場合、必須-オプションを使用することをお勧めします。サプライヤーは 1 つ以上の商品セットを供給できますが、商品はサプライヤーに属している必要があります。 つまり、製品にはサプライヤーが存在し、かつてその製品を供給したサプライヤーに関するデータが保存されます。 そして羊は安全で、オオカミには餌が与えられます。オペレーターはデータを入力でき、ビジネスマンは情報を把握できます。

オプション-オプション。ご覧のとおり、オペレーターにとってはすべて問題ありませんが、ビジネスには管理の欠如という問題があります。製品はサプライヤーなしでも存在し、サプライヤーは製品なしでも存在できます。
1対多の通信についてまとめてみましょう。 エンティティが次の関係に参加する場合: - 必須-必須、その場合、両方のテーブルに同時にレコードを入力することは不可能であるため、そのような関係には存続する権利がありません。 - オプション-オプションの場合、ビジネス サポートに問題があります。

ER 図では多対多のリレーションシップが許可されていますが、テーブル ビューに変換すると、リレーションシップは中間エンティティに置き換えられます。

多対多の必須-必須 - この構築は多くの場合、分析段階の最初に行われ、接続を意味します - 完全に理解されていない、または必要である 追加の許可、または単純な集団関係、つまり双方向リストを反映します。

多対多の必須-オプション - ほとんど使用されません。 このような接続は常に詳細が必要になります。

再帰的な接続。これらの関係は、テーブル エントリが互いに論理的に関連している可能性があることを示唆しています。

オプション-オプションの 1 対 1。スライドに示されている例では、この関係は、どの男性 (女性) も 1 人の女性 (男性) と結婚できることを意味します。 このつながりは、結婚した人々の履歴を追跡するのに便利です。初めて、再び、...言い換えれば、別のタイプの関係です。

オプション - オプションの 1 対多。接続例をスライドに示します。 これは典型的な階層 (ツリー構造) です。 スライドに示されている関係は、たとえば次のように解釈できます。どの従業員も 1 人のマネージャーにのみ直属することができますが、マネージャーは 1 人または複数の従業員を管理できます。

オプション-オプション M:M通信の例をスライド3に示します。これはネットワーク構造です。

エンティティの質問チェックリスト

• エンティティ名は本質を反映していますか? このオブジェクトの?
• 他のエンティティと重複する部分はありますか?
• 少なくとも 2 つの属性はありますか?
• 属性は全部で 8 つまでですか?
• このエンティティの同義語/同音異義語はありますか?
• エンティティは完全に定義されていますか?
• 一意の識別子はありますか?
• 少なくとも 1 つの接続はありますか?
• エンティティ値を作成、検索、編集、削除、アーカイブ、および使用するための関数が少なくとも 1 つありますか?
• 変更履歴はありますか？
• データ正規化の原則は遵守されていますか?
• おそらく別の名前で、別のアプリケーション システムに同じエンティティが存在しますか?
• 本質が一般的すぎるのでしょうか？
• そこに具体化された一般化のレベルは十分ですか?

属性チェックリスト:

• 属性名は、その属性によって示されるプロパティの本質を反映する単数名詞ですか?
• 属性名にはエンティティ名が含まれていませんか (そうすべきではありません)?
• 属性には一度に 1 つの値しかありませんか?
• 重複する値(またはグループ)はありますか?
• 形式、長さ、 有効な値、取得アルゴリズムなど？
• この属性は、別のアプリケーション システム (既存または提案されているもの) に役立つ欠落エンティティである可能性がありますか?
• 彼は接続ミスをした可能性がありますか?
• どこかに「プロジェクト機能」としての属性への参照がありますか? アプリケーション層消えるべきですか？
• 変更履歴は必要ですか？
• その意味はこの実体のみに依存するのでしょうか?
• 属性の値が必要な場合、それは常にわかっているのでしょうか?
• この属性および同様の属性に対してドメインを作成する必要がありますか?
• その意味は一部にのみ依存するのでしょうか 一意の識別子?
• その値は、一意の識別子に含まれていないいくつかの属性の値に依存しますか?