3. データモデルのコンポーネント

エンティティ、エンティティの定義、エンティティに関する情報のソース

データ モデルは、サブジェクト領域の概念的な記述であり、データベース設計の最も抽象的なレベルです。 データ モデルは、エンティティ、属性、ドメイン、および関係で構成されます。 次に、各要素について詳しく説明します。

3.1 エンティティ

エンティティとは、データベースに情報を保存する必要があるものです。

データベースを設計するときは、現在の状況を説明するだけで十分です。ほとんどの名詞と一部の動詞がエンティティの候補になります。 例: 「顧客は商品を購入します。従業員は顧客に商品を販売します。サプライヤーは商品を配送します。」 - 顧客、商品、従業員、サプライヤーはエンティティです。 動詞「買う」と「売る」もエンティティです (ただし、これらは買い手と売り手の観点からは異なり、1 つのエンティティである可能性があります)。

データベースを設計する場合、エンティティに関する主な情報源は、ビジネス プロセスを理解するための顧客との会話です。 さらに、フォーム、レポート、指示書など、ビジネスプロセスで使用される標準文書も分析されます。 このようなリストを受け取った後、その完全性と一貫性をチェックする必要があり、また重複、つまり異なる単語で呼ばれる同一の実体や、実際には異なるが同じ用語で記述される実体を識別する必要があります。

エンティティは、具体的な概念 (顧客、製品、通話) と抽象的な概念 (エージェントがクライアントを担当し、学生がコースに登録する) をモデル化できます。

ERモデルのコンセプト。 エンティティの概念。 属性。 属性の種類

1. データベースを設計する際、開発者はどのような問題に遭遇する可能性がありますか?

データベースを設計し、ソフトウェア製品を開発する場合、最も重要な問題は、開発者と顧客の間の対話の問題です。 開発者の仕事は、データベース管理ソフトウェア製品を開発する際に、顧客の要望を最も正確に再現することです。 開発者が解決する必要がある主な問題は、データベースの正しい構築、つまりデータベース スキーマ (構造) です。

さらに、開発者は次のような他の困難にも遭遇します。

• 効率的なアルゴリズムを探索する。
• 適切なデータ構造の選択。
• 複雑なコードのデバッグとテスト。
• アプリケーションインターフェイスのデザインと使いやすさ。

開発段階で ソフトウェア、データベースを管理するのは誰か、開発者は顧客の要件を詳細に学習する必要があります。 データベースは、理解しやすく、解決しようとしている問題を最も正確に反映し、冗長なデータが含まれないように設計する必要があります。

データベースの開発 (設計) プロセスを容易にするため、いわゆる セマンティックモデルデータ。 のために 他の種類最も有名なデータベースは ER データ モデル (エンティティ リレーションシップ モデル) です。

2. ER モデル (エンティティ関係モデル) とは何ですか? なぜ ER モデルを開発する必要があるのですか?

ER モデル (エンティティ関係モデルまたはエンティティ関係図) は、データベース設計プロセスを簡素化することを目的としたセマンティック データ モデルです。 リレーショナル、階層、ネットワーク、オブジェクトなど、あらゆるタイプのデータベースを ER モデルから生成できます。 ER モデルは、「エンティティ」、「関係」、「属性」の概念に基づいています。

大規模なデータベースの場合、ER モデルを構築すると、特にデータベースがすでに運用中またはテスト段階にある場合、修正が非常に困難な設計エラーを回避できます。 データベース構造の開発中にエラーが発生すると、このデータベースを管理するソフトウェア コードのやり直しが発生する可能性があります。 その結果、時間、お金、人的資源が非効率に使用されてしまいます。

ER モデルは、データベースを視覚的なグラフィカル ダイアグラムの形式で表現したものです。 ER モデルは、特定のサブジェクト領域を定義するプロセスを視覚化します。 エンティティ関係図は、エンティティ、属性、および関係をグラフィカルに表す図です。

ER モデルは概念的なレベルのモデリングにすぎません。 ER モデルには実装の詳細は含まれていません。 同じ ER モデルでも、実装の詳細が異なる場合があります。

3. データベース内のエンティティとは何ですか? 例

データベース内のエンティティとは、データベースが開発されている主題領域の本質に基づいて識別できるデータベース内の任意のオブジェクトです。 データベース設計者はエンティティを正しく定義できなければなりません。

例1.書店データベースでは次のエンティティを区別できます。

• 本;
• プロバイダー。
• 店内での配置。

例2。特定の教育機関の教育プロセス会計データベースでは、次のエンティティを区別できます。

• 学生（学生）。
• 教師。
• グループ。
• 研究される分野。

4. エンティティ タイプにはどのような種類がありますか? ER モデルにおけるエンティティ タイプの指定

「エンティティ」-「関係」モデルでは、次の 2 種類のエンティティ タイプが区別されます。

• 弱いタイプ。 このタイプのエンティティは、強力なエンティティに依存します。
• 強いタイプ。 これは誰にも依存しない独立したタイプのエンティティです。

図 1 は、ER モデルにおける弱いエンティティ タイプと強いエンティティ タイプの指定を示しています。

米。 1. エンティティの強いタイプと弱いタイプの指定

5. 属性は何のためにありますか? 属性の種類。 ERモデル上の属性の指定

各エンティティ タイプには、特定の属性セットがあります。 属性は、特定のエンティティを説明することを目的としています。

次のタイプの属性が区別されます。

• 単純属性。 これらは、複合属性の一部となることができる属性です。 これらの属性は 1 つのコンポーネントで構成されます。 たとえば、単純な属性には次のものが含まれます。図書館の本のコードや教育機関の学生の学習コース。
• 複合属性。 これらは、いくつかの単純な属性で構成される属性です。 たとえば、居住地の住所には、国、地域、番地、番地が含まれる場合があります。
• 明確な属性。 これらは、あるエンティティの値を 1 つだけ含む属性です。 たとえば、エンティティ タイプ「Student」の属性「Grade booknumber」は、学生には 1 つのテストブック番号 (1 つの値) しか持てないため、明確です。
• 多義的な属性。 これらは、複数の値を含めることができる属性です。 たとえば、「学生」エンティティの複数値属性「電話番号」は、学生は複数の電話番号 (自宅、携帯電話など) を持つことができるためです。
• 任意属性。 これらは、他の属性の値に基づいて値が形成される属性です。 たとえば、学生の現在の学習コースは、現在の学習年度と学生が入学した年の差に基づいて計算できます。 教育機関(学生が勉強に問題がなく、「データベースと知識の組織化」という分野を勉強した場合)

ER 図では、図 2 に示すように属性が指定されます。図からわかるように、属性は楕円として指定され、楕円の中に名前が付けられます。 属性が主キーの場合、その名前には下線が付きます。

図 2. ER モデル図における属性の表現

6. ER モデルのエンティティ タイプと属性は、実際のデータベースとデータベースが管理するプログラムにどのように実装されますか?

データベース管理プログラムを開発する場合、エンティティ タイプとその属性は、次のようないくつかのアプローチに従って、さまざまな方法で表現できます。

• すでに調査、テスト、標準化されており、膨大なデータベース管理機能を備えたよく知られたテクノロジをデータ ソースとして選択します (たとえば、Microsoft SQL Server、Oracle Database、Microsoft Access、Microsoft ODBC データ ソースなど)。ツール。
• 独自のデータベース形式を開発してそれを処理するメソッドを実装し、インポート/エクスポートなどの特別なコマンドの形式で既知のデータ ソースとの対話を実装します。 この場合、データベースの信頼性の高い操作を維持および保証するための日常的な作業をすべて個人的にプログラムする必要があります。
• 上記 2 つのアプローチを組み合わせて実装します。 最新のソフトウェア開発ツールには、複雑なセットを処理し、そのセット内のデータ (コレクション、配列、視覚化コンポーネントなど) を視覚化するための強力なライブラリ セットが備わっています。

データベースがよく知られたリレーショナル DBMS (Microsoft Access、Microsoft SQL Server など) で実装されている場合、エンティティ タイプはテーブルで表されます。 ER モデルの属性はテーブルのフィールドに対応します。 データベース テーブル内の 1 つのエントリは、エンティティの 1 つのインスタンスを表します。

各タイプの属性は次のように実装されます。

• 単純な属性または、単一値の属性は、任意のプログラミング言語にあるアクセス可能な基本型のセットで表すことができます。 たとえば、整数属性は、int、integer、uint などの型で表されます。 小数部分を含む属性は、float、double として表すことができます。 文字列型の文字列属性など。
• 複合属性は、いくつかのネストされた単純な属性を含むオブジェクトです。 たとえば、Microsoft Access DBMS では、一連の単純なタイプ (フィールド) に基づいてテーブルの複合属性を形成できます。 プログラミング言語では、フィールドの結合は構造体またはクラスによって実装されます。
• 複数値の属性単純な属性または複合属性の配列またはコレクションによって実装できます。
• 任意の属性テーブルにアクセスするときに計算される追加フィールドによって実装されます。 このようなフィールドは計算フィールドと呼ばれ、テーブルの他のフィールドに基づいて形成されます。
• 主キーである属性整数、文字列、またはその他の順序型を指定できます。 この場合、主キーに対応する各テーブル セルの値は一意です。 ほとんどの場合、主キーは整数型 (int、integer) です。

データベースが独自の形式で実装されている場合、エンティティ タイプはクラスまたは構造として表すのが最も便利です。 エンティティ属性は、クラスのフィールド (内部データ) として実装されます。 クラス メソッドは、クラス フィールド (属性) の必要な処理を実装します。 クラス間の対話 (通信) は、よく知られた設計パターンを使用して特別に設計されたインターフェイスを使用して実装されます。

7. 「Student」エンティティ タイプの ER モデルのフラグメントの例

上の例は、「Student」エンティティ タイプの ER モデルの一部を示しています。

図 3. 「Student」エンティティ タイプの ER モデルの断片

上の図は次の属性を宣言しています。DBMS (プログラム) では次のタイプを持つことができます。

• 主キー属性は、自動的に生成される一意の整数値です。 DBMS では、これはカウンター フィールドです。
• エントリ year 属性は、整数値 (int、integer) として実装できる単純な属性です。
• 電話番号属性は、配列またはコレクションなどとして実装できる複数値の属性です。
• 属性 レコードブック番号– レコードブック番号には数字に加えて文字も含めることができるため、文字列として実装できる単純な属性。
• 属性 国、市、番地、番地は、複合属性住所を形成する属性です。 これらの属性はすべて文字列 (テキスト) タイプ (文字列、テキスト) にすることができます。
• 属性姓、名、父称 – これらは複合属性学生名の一部である単純な属性です。 これらの属性はすべて文字列 (テキスト) タイプ (文字列、テキスト) にすることができます。
• Birthday 属性は、Date 型 (DateTime) の単純な属性です。
• 属性 学生時代– 現在 (システム) 日付と誕生日属性の値の差として定義される計算フィールド。

「エンティティ関係」データベース モデル (ER モデル) の基本概念: エンティティ、エンティティ間の接続とその属性 (プロパティ)。

エッセンス– 検討中の主題領域における具体的または抽象的なオブジェクト。 エンティティは、データベースに格納される基本的なタイプの情報です (リレーショナル データベースでは、各エンティティにテーブルが割り当てられます)。 エンティティには、学生、顧客、部門などが含まれます。 エンティティ インスタンスとエンティティ タイプは異なる概念です。 エンティティ タイプの概念は、全体として機能する同種の個人、オブジェクト、またはイベントのセット (たとえば、学生、クライアントなど) を指します。 エンティティ インスタンスは、たとえば、セット内の特定の人物を指します。 エンティティ タイプは学生、インスタンスは Petrov、Sidorov などにすることができます。

属性対象領域内のエンティティのプロパティです。 その名前は、特定のエンティティ タイプに対して一意である必要があります。 たとえば、学生エンティティの場合、姓、名、父称、生年月日と出身地、パスポートの詳細などの属性を使用できます。 リレーショナル データベースでは、属性はテーブル フィールドに格納されます。

繋がり– 対象領域内のエンティティ間の関係。 リレーションシップはデータベースの部分間の接続です (リレーショナル データベースでは、テーブル レコード間の接続です)。

エンティティはタイプによって分類されたデータであり、関係はこれらのデータ タイプが互いにどのように関係しているかを示します。 特定のサブジェクト領域をエンティティ関係の観点から記述すると、このデータベースのエンティティ関係モデルが得られます。

矢印は、1 対多の関係の象徴です。

ER モデルの主な利点: * 明瞭さ。 * モデルを使用すると、多数のオブジェクトと属性を含むデータベースを設計できます。

ER モデルの主な要素: * オブジェクト (エンティティ)。 * オブジェクトの属性; * オブジェクト間の接続。

エンティティ間の関係は次の特徴があります。 * 接続タイプ (1:1、1:N、N:M)。 * 所属クラス。 クラスは必須またはオプションの場合があります。 各エンティティ インスタンスが関係に関与している場合、メンバーシップ クラスは必須ですが、それ以外の場合はオプションです。

データ正規化の概念。 機能的依存。

正規化は、主キーと既存の関係に基づいて関係を分析する正式な方法です。 そのタスクは、データベースの 1 つのスキーマ (またはリレーションのセット) を、リレーションがより単純で規則的な構造を持つ別のスキーマに置き換えることです。

機能的依存。 X と Y を、ある関係の 2 つの属性とする。 任意の時点で X の各値が属性 Y の 1 つの値にのみ対応する場合、Y は X に機能的に依存していると言われます。

関数の依存関係は X -> Y として表されます。

態度の学生 S (Ns、Fio、Ngr、Addr、Tel)。 Fio、Ngr、Addr、Tel の各属性は、機能的に Ns 属性に依存します。

したがって、正規化されたリレーションでは、すべての非キー属性はリレーションのキーに機能的に依存します。 リレーション S のキーは属性 Ns です。

基本ルールエンティティ テーブルを作成する場合、これは「エンティティごとに別のテーブル」になります。

エンティティ テーブルのフィールドには、次の 2 つのタイプがあります。 鍵そして 非キー。ほぼすべてのリレーショナル DBMS でテーブルにキーを入力すると、テーブル レコード内の値の一意性をキーによって確保し、テーブル レコードの処理を高速化し、キー フィールドの値によってレコードを自動的に並べ替えることもできます。

通常は定義で十分です 単純キー、頻度は低いですが - Enter 複合鍵。 複合キーを持つテーブルは、たとえば、同名者が見つかる従業員 (姓、名、父称) のリストを保存するテーブルです。 一部の DBMS では、自動的に生成されるキー番号付けフィールド (Access では、これは「カウンタ」タイプのフィールド) を定義するオプションをユーザーに提供しており、これにより、テーブル レコードの一意性の問題の解決策が簡素化されます。

エンティティ テーブルには、オブジェクトのプロパティや特性を説明するフィールドがある場合があります。 表にこれらのフィールドの繰り返しが多く、この情報の量が多い場合は、それらを別の表に分割することをお勧めします (「各エンティティには別の表がある」というルールに従う)。 さらに、プロパティが相互に関連している場合は、追加のテーブルを作成する必要があります。

エンティティ テーブルを処理するときは、次の点に注意してください。 新しいエンティティを追加および変更するのは簡単ですが、削除する場合は、リンク テーブルからそのエンティティへの参照をすべて破棄する必要があります。そうしないと、リンク テーブルが正しくなくなります。 最新の DBMS の多くは、このような操作における不正なアクションをブロックします。

投稿 リンクテーブルエンティティ間の関係を表示することを目的としており、その情報は対応するエンティティ テーブルにあります。

通常、1 つの関係テーブルは 2 つのエンティティ間の関係を記述します。 最も単純な場合のエンティティ テーブルにはそれぞれ 1 つのキー フィールドがあるため、2 つのテーブルのリレーションシップ テーブルには、リレーションシップ レコードの一意性を確保するために 2 つのキーが必要です。 オブジェクトのテーブルのようなリレーションシップのテーブルをキーなしで作成することもできますが、その場合、レコードの一意性を監視する機能はユーザーにあります。

より複雑な関係 (非バイナリ) は、バイナリ関係に還元する必要があります。 N 個のオブジェクトの関係を記述するには、N-1 個の関係テーブルが必要です。 推移的な接続があってはなりません。 接続が過剰になると矛盾が生じます (前のサブセクションの従業員と部門、従業員とプロジェクト、および部門とプロジェクトの関係の例を参照)。

エンティティの特性は関係テーブルに含めるべきではありません。そうしないと、異常が避けられません。 それらを別のエンティティ テーブルに保存することをお勧めします。

接続テーブルを使用すると、線形接続や弱い接続など、やや特殊なタイプの接続を記述することもできます。 線形接続の例としては、エンティティが他の高次のエンティティに属する関係 (ノードで構成されるシステム、コンポーネントで構成される医薬品、金属合金など) が考えられます。 この場合、接続を説明するには 1 つの接続テーブルで十分です。

リンク テーブルを使用する場合は、エンティティはしばらくリンクなしでも機能するため、リンク テーブルのエントリは簡単に削除できることに留意する必要があります。 オブジェクトなしではリレーションシップは存在できないため、テーブル レコードの内容を追加または変更する場合は、既存のオブジェクトへの参照が正しいことを確認する必要があります。 最新の DBMS のほとんどは、オブジェクト参照の正確さを制御します。

下 誠実さデータベースの特性を理解すること。つまり、データベースには対象領域の情報が完全かつ一貫性があり、適切に反映されたものが含まれているということです。

区別する 物理的および論理的誠実さ。 物理的完全性とは、データに物理的にアクセスでき、データが失われていないことを意味します。 論理的整合性とは、データベースに論理エラーがないことを意味します。これには、データベースまたはそのオブジェクトの構造の違反、オブジェクト間の確立された接続の削除または変更などが含まれます。論理的整合性については、後で説明します。

データベースの整合性の維持には、整合性のチェック (監視) と、データベース内で不整合が検出された場合の復元が含まれます。 データベースの整合性は次を使用して設定されます。 整合性制約データベースに保存されているデータが満たさなければならない条件の形で。

整合性制約の中では、主に次の 2 つのタイプの制約に区別できます。 値の制限関係属性と 構造上の制限関係のタプルに。

例 値の制限 関係属性は、属性内の空の値または重複した値が許容されないという要件であり、属性値が特定の範囲に属することを制御します。 したがって、人事に関する関係レコードでは、Birth_Date 属性の値が Registration_Date 属性の値を超えることはできません。

属性値の制御を実装する最も柔軟な手段は次のとおりです。 ストアドプロシージャそして トリガー、一部の DBMS で使用できます。

構造上の制約要件を定義する エンティティの完全性そして リンクの完全性。リレーションで表されるエンティティ インスタンスごとに、それに対応するタプルが 1 つだけ存在します。 要件 エンティティの完全性それは、リレーションのタプルは、このリレーションの他のタプルと区別できなければならないということです。つまり、リレーションには主キーがなければなりません。

リンクの完全性要件の定式化は、概念と密接に関連しています。 外部キー。外部キーはリレーションシップ (データベース テーブル) を相互に接続するために使用されることを思い出してください。 この場合、1 つの関係 (親) の属性は次のように呼ばれます。 外部キー この関係がそうであれば、 主要な別の関係 (子) のキー。 外部キーが定義されているリレーションは、同じ属性が主キーであるリレーションを参照するといいます。

参照整合性では、親テーブル内のすべての外部キー値について、同じ主キー値を持つ行が子テーブルに存在する必要があります。 たとえば、リレーション R1 に部門の従業員に関する情報が含まれており、このリレーション Must の属性がリレーション R2 の主キーである場合、このリレーションには、R1 からの各役職について、対応する給与を含む行が存在する必要があります。

最新の DBMS の多くには、データベースの整合性を監視するツールが備わっています。

エンティティは、対象領域にとって重要な意味を持つ現実または抽象オブジェクトです。 エンティティには単数名詞で表される名前が必要です

エンティティを識別する非公式な方法は、オブジェクト、プロセス、役割、その他の概念を記述する抽象概念を探すことです。 エンティティを識別する正式な方法は、主題領域のテキスト説明を分析し、名詞を強調表示し、それらを抽象化として選択することです。

エンティティ インスタンスは、特定のエンティティの特定の代表です。 たとえば、Employee エンティティのインスタンスは従業員 Ivanov である可能性があります。

各エンティティには次のプロパティが必要です。

固有の名前を持っています。

エンティティに属するか、関係を通じて継承される 1 つ以上の属性を持ちます。

エンティティの各インスタンスを一意に識別する 1 つ以上の属性があります。

属性は、検討中の主題領域にとって重要なエンティティの特性であり、エンティティの状態を識別、分類、定量化、または表現することを目的としています。

次のタイプの属性が存在します。

シンプル - 1 つのデータ要素で構成されます。

複合 - 複数のデータ要素で構成されます。

明確 - 1 つのエンティティに対して 1 つの値が含まれます。

多値 - 1 つのエンティティに対して複数の値が含まれます。

オプション - 空 (未定義) の値を指定できます。

派生 - 別の属性の値から派生した値。

一意の識別子は、その値がエンティティの各インスタンスに対して一意である一連の属性です。 識別子から属性を削除すると、その一意性が侵害されます。 一意の識別子は、図内で下線付きで示されています。

各エンティティは、他のエンティティと任意の数の接続を持つことができます。

エンティティ間の関係

関係とは、検討中の主題領域にとって重要なエンティティ間の名前付き関連です。

接続度は、接続に関与するエンティティの数です。

通信能力 - 通信に参加しているエンティティ インスタンスの数。

電力値に応じて、通信は次の 3 つのタイプのいずれかになります。

1 対 1 (1:1 と表記)。

1 対多 (1:N と表記)。

多対多 (M:N で示される)。

1対1。 このような関係では、1 つの役割を持つエンティティは常に、別の役割を持つ 1 つのエンティティのみに対応することを意味します。 各エンティティの結合度は 1 であるため、1 本の線で接続されます。

1対多。 1 つの役割を持つエンティティは、別の役割を持つ任意の数のエンティティに関連付けることができます。

多対多。 この場合、関連するエンティティはそれぞれ、任意の数のインスタンスで表すことができます。