コンピューター ウィンドウズ インターネット

エンティティ間の関係を確立します。 ERWinErwinの例でのモデルの設計

関係は、エンティティ間の論理的な関係です。 各接続には、動詞または動詞句を使用して名前を付ける必要があります。 関係の名前は、ある種の制限またはビジネスルールを表し、図を読みやすくします。 デフォルトでは、リンク名は図に表示されていません。 論理レベルでは、識別可能な1対多の関係、多対多の関係、および識別できない1対多の関係を確立できます。 リンクは、物理層の外部キーに対応する論理層の概念です。 ERwinでは、関係は5つの基本的な情報によって表されます。

●関係のタイプ(識別、非識別、完全/不完全なカテゴリ、非特定の関係)。

●親エンティティ。

●子(依存)エンティティ。

●通信能力(カーディナリティ)。

●空(null)値の許容性。

IDEFIXは、従属エンティティと独立エンティティを区別します。 エンティティのタイプは、他のエンティティとの関係によって決定されます。 識別関係は、独立した(親)エンティティと依存した(子)エンティティの間に確立されます。 依存エンティティは、角の丸い長方形で描画されます。 識別関係が確立されると、親エンティティの主キー属性が子エンティティの主キーに自動的に転送されます。 関係を作成するときに子エンティティの属性を拡張するこの操作は、属性の移行と呼ばれます。 子エンティティでは、新しい属性は外部キー(FK)としてマークされます。

非識別関係が確立されると、子は独立したままになり、親の主キー属性が子の非キー属性に含まれます。 非識別関係は、独立したエンティティをリンクするために使用されます。 ERwin関係を定義するには、関係タイプを選択してから、マウスを使用して親エンティティと子エンティティを指定します。 識別リンクは実線で示されています。 非識別-点線付き。 線は、子エンティティの側面からのドットで終わります。

カーディナリティ-子のインスタンスの数に対する親エンティティのインスタンスの数の比率を示すために使用されます。

エンティティには次の4つのタイプがあります。

・親エンティティの1つのインスタンスが、子エンティティの0、1、または多数のインスタンスに対応する一般的なケース。 記号は付いていません。

・記号Pは、親エンティティの1つのインスタンスが子エンティティの1つまたは複数のインスタンスに対応する場合を示します(ゼロ値は除外されます)。

・記号Zは、親エンティティの1つのインスタンスが子エンティティの0または1つのインスタンスに対応する場合を示します(複数の値は除外されます)。

・数値は、子エンティティの所定の数のインスタンスが親エンティティの1つのインスタンスに対応する場合に、完全に一致する場合を示します。

・非識別関係での空(NULL)値の許容性は、親エンティティの側からの関係の弧上の空のひし形としてERwinによって示されます。

論理レベルでの関係の名前は、エンティティを接続する動詞です。 ERWinのリンクの物理名(論理名とは異なる場合があります)は、制約またはインデックスの名前を意味します。 関係名を表示するには、メニューからオプションを選択します:フォーマット/関係表示/動詞句。

一部のエンティティは、同じタイプのオブジェクトのカテゴリ全体を定義します。 ERwinでは、この場合、カテゴリを定義するエンティティが作成され、カテゴリ内の各アイテムに対して、カテゴリ化関係が導入されます。 カテゴリの親エンティティはスーパータイプと呼ばれ、子はサブタイプと呼ばれます。

たとえば、「受信ドキュメント」エンティティは、リクエストまたはオーダーのいずれかです。 1番目と2番目には、部分的に重複する異なる属性セットがあります(サブタイプの最小共通部分が主キーです)。 主キーを含むこれらの属性の共通部分は、インバウンドドキュメントスーパータイプエンティティに配置されます。 さまざまな部分(たとえば、コンテンツ、送信者に関するデータ)は、エンティティサブタイプに配置されます。

スーパータイプエンティティでは、サブタイプエンティティの特定のインスタンスを区別するために識別子属性が導入されています。

考えられるすべてのサブタイプエンティティがモデルに含まれているかどうかに応じて、カテゴリの関係は完全または不完全です。

図1.4-不完全なカテゴリセットの例

図1.5-カテゴリの完全なセットの例

3.エンティティは、任意の数の分類関係の共通エンティティにすることができます。

4.カテゴリエンティティの主キーの属性は、一般エンティティの主キーの属性と一致する必要があります。

5.エンティティカテゴリのすべてのインスタンスは同じディスクリミネーター値を持ち、他のカテゴリのすべてのインスタンスは異なるディスクリミネーター値を持っている必要があります(図4および図5を参照)。

役割。

ロール名(機能名)は、子エンティティで属性が果たす役割を示す外部キー属性の同義語です。 デフォルトでは、ロール名のみが属性リストに表示されます。 属性のフルネーム(機能名とロール名の両方)を表示するには、コンテキストメニューで[フォーマット] / [エンティティの表示]を選択し、[ロール名/属性]オプションを有効にします。 フルネームは、ピリオドで区切られた機能名とベース名として表示されます。 ロール名は、[リレーションシップ]ダイアログボックスの[ロール名]タブで設定します。 このウィンドウは、リンクをダブルクリックすると呼び出されます。

1つのエンティティの2つ以上の属性が同じスコープで定義されている場合、つまり、ロール名を使用する必要があります。 それらの値の範囲は同じですが、意味が異なります。

表現。

ビュー、または一時テーブルまたは派生テーブルと呼ばれることもあるビューは、データがテーブルのように永続的に保存されないデータベースオブジェクトですが、ビューにアクセスすると動的に生成されます。 ビューはそれ自体で存在することはできませんが、1つ以上のテーブルに関してのみ定義されます。 ビューを使用すると、データベース設計者は各ユーザーまたはユーザーのグループにデータの異なるビューを提供できるため、使いやすさとデータセキュリティの問題に対処できます。

契約

後続のプレゼンテーションを簡潔にするために、いくつかの規則を受け入れましょう。

・クリック-マウスの左ボタンを押します。

・右クリック-マウスの右ボタンを押します。

ダブルクリック-マウスボタンを2回連続してクリック

・選択-カーソルを対応するオブジェクト(図要素、メニュー項目、アイコン)に移動し、マウスの左ボタンをクリックします。

ドラッグ-オブジェクトを選択し、マウスボタンを離さずにカーソルを移動します v別の位置。

・ファイル/開くタイプのレコードは、[ファイル]メニュー項目を選択してから、開いたメニューから[開く]項目を選択する必要があることを意味します。

ERwinデスクトップ

図では。 図1は、LogicWorksによるERwinソフトウェアのデスクトップを示しています。

図1-Erwinデスクトップ。

図1では、数字は次のことを示しています。

1-メインメニュー;

2-ツールバー;

3-特別なツールのセット。

4フォントと色のパネル。

5-チャートフィールド。

デスクトップのコンポーネントを詳しく見てみましょう。

メインメニューには一般的なコマンドが含まれています。 これらのコマンドのほとんどは、ツールバーアイコン、またはマウスを右クリックしてポップアップするメニュー項目のいずれかによって複製されることに注意してください。 したがって、ここでは、デスクトップの一般的なビューに関連するコマンドに焦点を当てます。 ウィンドウアイテムには、次のサブアイテムがあります。

ツールバー-ツールバー;

フォントとカラーツールバー - フォントと色のパネル。

ステータスバー-ステータスバー;

ERwin Toolboxは、特別なツールのセットです。

リストされた項目のいずれかがチェックされていない場合、対応する項目はデスクトップに表示されません。 アイテムオプション/表示メニューの表示とオプション/エディタメニューの表示は、メインメニューに1gushを追加します。あなた:表示とエディタ。

ツールバーには、次のアイコンのグループが含まれています。

ファイルの操作:

新しい図を作成します。

既存の図を開きます。

印刷用の図を送信します。

これらのアイコンは、[ファイル]メインメニュー項目のコマンドによって複製されることに注意してください。



モデルの提示レベル:

エンティティレベル;

属性レベル;

説明レベル;

物理層(このアイコンをクリックすると、デモンストレーション中に、それらのタイプが属性レベルで示されます)。

これらのツールは、[表示]メニュー項目によって複製されます。 追加の表示レベルが含まれています。主キーレベル-主キーのみが表示され、物理順序レベル-属性はキーと非キーに分けられません。

スケーリング:

下降;

増加;

倍率なし。

最小(さらに縮小すると、図が読みにくくなります)。

パーツを表示します(このツールを選択した後、作業フィールドで表示するフラグメントを選択します)。

このグループのすべてのアクションは、[表示] // [ズーム]アイテムによって複製されます。

サーバーの操作:

サーバーのスクリプトを生成します。

サーバーに接続します。

サーバーを選択します。

一連の特別なツールには、データスキーマをグラフィカルに構築するために必要なすべてのアイコンが含まれています。 次のツールで構成されています。

オブジェクトの選択;

属性の操作;

独立したエンティティ;

依存エンティティ;

完全な分類;

不完全な分類;

1対多の識別関係。

非識別関係は「多くの人に頌歌」します。

多対多の関係;

テキストラベル。

コンセプトデザイン

エンティティの作成

概念図のエンティティは、依存および独立することができます。 ダイアグラムでは、エンティティは長方形で表されます。 その上にエンティティの名前があります。 長方形は2つの部分に分割されています。上の部分が主キー領域です。 下-他の属性の領域。 エンティティを作成するとき、長方形は最初は空であり、名前の形式はE / nです(たとえば、E / 1、E / 2など)。

独立したエンティティを作成するには、一連の特別なツールから対応するアイコンをクリックしてから、作成したエンティティを配置する場所の図フィールドをクリックする必要があります。 依存エンティティを作成するには、依存エンティティツールを選択し、グラフフィールドをクリックします。 このようなエンティティを表す長方形の角は丸みを帯びていることに注意してください。 ERwinは、関係を編成したりカテゴリに分割したりするときに通常のエンティティを依存エンティティに変換するため、ダイアグラムを作成するときに、依存エンティティを直接指定する必要はほとんどありません。

設計者がフィールド上のエンティティの位置に満足できない場合は、一連の特別なツールから[オブジェクトへのポイント]アイコンを選択し、エンティティを新しい場所にドラッグします。 選択したエンティティを削除するには、キーボードのDeleteキーを使用します。 メインメニューの[オプション] / [エンティティサイズ]項目を選択して、エンティティを表す長方形のサイズを変更できます。 オプション/レイアウトメニュー項目は、フィールド上のエンティティの位置を配置するために使用されます。

次に、エンティティの名前とその特性属性を定義しましょう。 これを行うには、右クリックメニューの[エンティティ属性]項目を使用します。 開いたエディタの[エンティティ名]フィールドに、エンティティの名前を入力します。 スイッチを使用して、エンティティの依存関係を変更できます。 主キー編集フィールドは、主キーを構成する属性の名前を入力するためのものです。 「非キー属性」フィールドには、非キー属性が含まれています。 どちらの場合も、キーボードのEnterキーを使用して、属性を相互に分離していることに注意してください。 図では。 図2は、独立した実体の例を示している。

米。 2-独立したエンティティ

エンティティの詳細な説明(定義)とすべてのエンティティの一般的なビューを追加するには、レポート/エンティティブラウザを使用します。

ERwinは、個々の属性を操作する機能を提供します。 これを行うには、[操作属性]アイコンを選択します。 このモードでは、次のことができます。

・属性を削除します。 これを行うには、個々の属性を選択し、キーボードのDeleteキーを押します。

・属性をエンティティ内に移動します。 これを行うには、属性を選択し、マウスボタンを離さずに目的の場所に移動します。 このようにして、キー領域と非キー領域の両方内、およびそれらの間で属性を移動できることに注意してください。

・エンティティ間で属性を移動します。 このアクションの手法は、前の手法と同様です。 属性の移動中にCtrlキーを押すと、別のエンティティにコピーされます。

リンクの構築

1対多の関係の構築について考えてみましょう。 これを行うには、一連の特別なツールから適切なアイコンを選択し、親と子を続けてクリックします。 識別リンクは、子を表す長方形に実線と黒い点で示されます。 この関係は、親の主キーが子の識別子に転送されることを特徴としています。 図では。 図3は、1対多の識別関係を示している。

図3。 -識別リンク

非識別関係は、同様の方法で構築されます。 親の長方形の横に点線とひし形で描かれています。 このようなひし形は、親の存在がオプションであることを意味します。 外部キーフィールドはnulにすることができます。 ERwinで非識別関係を構築することは、親の主キーを非キーの子属性に転送することを特徴としています。 図4は、識別できない関係を示しています。

米。 4.-非識別接続

前述のように、多対多の関係を設計すると、新しいエンティティが作成されます。 1番目と2番目のエンティティ間にこのタイプの関係を構築する例を図に示します。 5.5。

米。 5.-多対多の関係

リレーションシップの右クリックポップアップメニューから[リレーションシップ]アイテムを使用して、リレーションシップの説明を表示および変更できます。 開いたウィンドウは次のことを示しています。

・リンク名(動詞句フィールド)。

・関係タイプ:識別または非識別。

・カーディナリティ。 ERwinでは、次のタイプのリンクを定義できます。

1.ゼロ、1つ以上。 このようなカーディナリティの存在は、図に追加の指定を導入しません。

2.1つ以上。 このような関係は、子を表す長方形の横にある文字Pで示されます。

3.ゼロまたは1。 カーディナリティは文字Zで示されます。

4.与えられた。 この場合、Exactlyフィールドにはカーディナリティ番号が含まれている必要があります。 このような関係は、子を表す長方形の数字で示されます。

・Nullの存在の可能性-値(Nullの切り替え)。

・外部キーの役割。 この場合、役割名は「役割名」フィールドに記録されます。 この場合、エディターの外部キーフィールドには構造が含まれています<имя роли>.<имя первичного ключа родителя>.

ダイアグラムに接続の名前またはカーディナリティーが示されていない場合は、「表示/動詞句」および「表示/カーディナリティー」の項目の反対側にポインターを置く必要があります。

リンクを削除するには、[オブジェクトを指す]アイコンを選択し、対応するリンクをクリックして、キーボードの[削除]を押します。

ERwinでのエンティティのカテゴリへの分割は、図と同様の方法で示されます。 6.6。

米。 6-完全な分類

カテゴリを作成するには、次の手順を実行する必要があります。

主要なエンティティを完全に説明します。

カテゴリエンティティを構築します。

一連の特別なツールから、完全または不完全な分類のアイコンを選択します。

本体をクリックします。

カテゴリの1つをクリックします。

後続の各カテゴリを作成するには、カテゴリ記号をクリックしてから、対応するエンティティをクリックします。

カテゴリの1つとメインエンティティとの接続を削除するには、対応するブランチを選択し、キーボードのDeleteキーを押します。 分類全体を削除する場合は、カテゴリ記号をポイントして[削除]を押します。

論理設計

論理設計は、データモデルの選択から始まります。 ERwinが動作するすべてのDBMSはリレーショナルであり、これによりデータモデルの選択が決まります。

特定のDBMSを選択するには、[サーバーの選択]アイコンをクリックします。 開いたウィンドウで、選択したDBMSの反対側にポインタを置き、必要に応じてバージョンを設定します。 さらに、デフォルトでテーブル項目の特性(ゼロ値のタイプと可能性)を選択する必要があります。

論理設計の重要なステップは、情報の整合性を維持するための戦略を定義することです。 さまざまなタイプのリンクのデフォルト戦略を設定するには、DBMS選択ウィンドウの[参照整合性のデフォルト]ボタンをクリックします。 ERwinは、次の3種類の戦略を提供します。

1.制限-禁止。 これは、関連するエンティティとのアクションの禁止を特徴としています。

2.カスケード-カスケード。 このような戦略は、関連するエンティティに対してカスケード操作を実行することです。

3.Null-ゼロを設定します。 この戦略は、フィールド値をNullに設定することです。

DBMSを選択したら、データをその用語で説明し始めましょう。 これを行うには、エンティティであるアイテムを右クリックしてポップアップするメニューから選択します。<имя выбранной СУБД>データベーススキーマ。 開いたウィンドウで、テーブルの名前とそのフィールド、およびこれらのフィールドの特性を指定できます。

実際には、整合性制約を維持するための同じ戦略によって、どのタイプのすべての関係も決定されるわけではないことがよくあります。 特定のリンクの戦略を変更するには、リンクの右クリックポップアップメニューから[参照整合性]項目を使用します。 図で選択された戦略に関する情報がない場合は、[表示/国民投票の整合性]の横にポインターを置きます。

選択したDBMSのスクリプトを作成するには、[サーバーのスクリプトを生成]アイコンをクリックします。 同時に、ERwinは特定のテーブルに従ってデータベーススキーマを構築します。 選択したDBMSがトリガーの書き込みをサポートしている場合、整合性制約をサポートするために選択した戦略に応じてトリガーが作成されます。

物理的設計

設計のこの段階で、結果の回路にインデックスを追加します。 これを行うには、アイテムを使用します<имя СУБД>エンティティを右クリックしてポップアップするメニューのインデックス。 開いたウィンドウで、[新規]ボタンをクリックして新しいインデックスを作成し、この属性のビジュアルイメージをクリックしてその属性を指定します。 一般的な図では、インデックスを構成する属性が文字AKでマークされていることに注意してください。 これは、それらが代替キ​​ーであることを意味します。

エクササイズ

1. ERwinを使用して、認証機関の概念データベーススキーマを構築します。 サブジェクトエリアの説明を以下に示します。

認証機関は、特定の種類の製品の証明書を発行することを認定されています。 製品の各タイプは、コード(分類子による)、タイプ名(乳製品など)、およびタイプ(ミルクなど)によって記述されます。 製品の種類ごとに複数の規制文書が存在する場合があり、各規制文書の効果は製品の種類ごとに適用されます。 規制文書は、そのレベル(GOST、OSTなど)、番号、および名前によって特徴付けられます。

証明書は、1つのタイプの製品と1つのクライアントに対してのみ発行されます。 同じクライアントが認証機関に何度も連絡できるため、クライアントに関する情報(組織コード、名前、住所、電話番号)を保存する必要があります。

クライアントは、申請または宣言の2種類の認証申請のいずれかを使用して認証機関に申請できます。 これに応じて、さまざまな種類の内部文書が作成され、さまざまな情報が保存されます(表1)。

表1

この場合、アプリケーションと宣言の番号付けは連続しています。 これは、番号のあるアプリケーションがある場合、この番号の下に宣言があってはならないことを意味します。

認証機関は、従業員に関する情報(個人コード、名前、役職、住所)を保存します。 さらに、従業員がどのような仕事をし、どのような発言をしたかを知る必要があります。 アプリケーションで実行される作業には、アプリケーションへの記入、アプリケーションの決定、証明書の発行の決定、証明書の発行の4つのタイプがあります。 同じアプリケーションに対して、さまざまなタイプの作業をさまざまな従業員が実行できます。 概念図では、カテゴリへの分割が必要です。 さらに、外部キーの役割を使用する必要があります。

2. ERwinを使用して、概念スキーマを選択したDBMSのテーブルに変換します。 ビルドトリガー。

3.次の権限を持つデータベースの3人のユーザーを作成します。

1)「レポート」-すべての情報を読む権利(他の権利はありません)。

2)「ディレクトリ」-従業員、顧客、製品、規制文書に関する情報に対するすべての権利。

3)「文書化」-認証機関およびクライアントの内部文書化に関する情報に対するすべての権利。 製品および規制データを読む権利。

レポートには次のものが含まれている必要があります。

ERwinからの概念図のプリントアウト。

ベースの完全性の制約をサポートするための戦略の選択の正当化。

テーブルとトリガーの構造。

データベースユーザーを作成する方法の説明。

制御の質問

1.サブジェクトエリアにはどのような種類の関係が存在する可能性がありますか?

2.データベーススキーマから多対多の関係を削除するにはどうすればよいですか?

3.識別リンクと非識別リンクの違いは何ですか?

4.外部キーの役割を説明する必要があるのはいつですか。

5.カテゴリの選択をどのように正当化できますか?

6.完全な分類と不完全な分類の違いは何ですか?

7.ラボでは、整合性制約を維持するためにどのような戦略が使用されていますか?


参考文献

1.日付K.J. データベースシステム入門-教科書。 アローワンス:英語からの翻訳。 -第6版 -M。他:Williams、2000 .-- 846p。

2. Robinson S. Microsoft Access 2000:教科書。 コース:あたり。 英語から --SPB。:Peter、2001 .-- 511p。

3.クズネツォフS.D. データベースの基礎:講義コース:教科書。 manual.M 。:インターネットun-t通知。 テクノロジー、2005年。-484ページ。

4. Hoffman V.E.、Khomonenko A.D. Delphiでデータベースを操作する。 サンクトペテルブルク:Dhv、2002年。-656ページ。

5.マクラコフS.V. BpwinとErwin。 情報システム開発のためのケースツール-M .: Dialogue-Mifi、2003.-254p。

6.マリキナM.P. データベース:基本、設計、使用:教科書。 大学向けマニュアル-第2版-SPB .: BHV-Petersburg、2006.-517p。

Coddの記事で提供されている例を使用して、開発サイクルを見てみましょう。
問題の実質的な側面を簡単に思い出してみましょう。 従業員は記録に残されます。 従業員ごとに、子供に関する情報とこの従業員が保持している役職のリストが保存されます。 投稿の場合、情報は確立された投稿給与に保存されます。
まず、モデルの論理レイヤーを作成しましょう。 これを行うには、エンティティの表示モード(表示/エンティティレベル)を設定します。 ツールバーを使用して、エンティティ「employee」、「children」、「work history」、「salaryhistory」を作成します。 エンティティにはロシア語で名前を付けます。
各エンティティを選択した後、「エンティティ定義」エディタでロシア語で詳細な説明を設定します。 この説明はERwinレポートに表示され、図に表示できます。
エンティティ間の関係を示しましょう。 たとえば、「employee」は、エンティティ「children」のID「parent」に関連付けられています。 リレーションシップの説明は、エディター/リレーションシップエディターに入力されます。
作業の結果はERwin図に表示されます(図2)。

米。 2.エンティティレベルの図

次に、属性を設定するモード(表示/属性レベル)に切り替えましょう。 「エンティティ/属性」エディタで、キー属性と非キー属性の名前をロシア語で設定します。 子の子エンティティには、従業員番号キー属性が手動で指定されていないことに注意してください。 ERwinはそれを親エンティティから移行します。 同じことが他の子エンティティでも起こります。
エンティティ「employee」の属性「name」については、それが代替キーであることを示します(すべての従業員が一意の名前/名前を持っていると想定します)。 これを行うには、属性の名前の後に、AK1ポインターを括弧で囲みます。
作業の結果は、IDEF1X表記でERwin図(図3)に表示されます。

米。 3.IDEF1X表記の属性レベル図

IE(Information Engineering)表記の同じ図のビューを図4に示します。

米。 4.IE表記の属性レベル図

属性とエンティティの名前はロシア語で設定されているため、モデルの物理レベルに移動するには、ターゲットDBMSのルールを満たすテーブル、列、および制約の識別子と一致させる必要があります(通常はこれは、ラテン文字、数字、およびいくつかの特殊文字の使用を意味します)。
「データベーススキーマ」エディタで、各エンティティに対応するテーブル名を指定します。 次に、「属性定義」エディタで、エンティティの属性に対応するテーブル列の名前を設定します。 ERwinは、ここで列名を従属テーブルにも移行します。
この時点で、「拡張属性」エディタを使用して、拡張PowerBuilder属性(表示形式、編集マスク、制御規則、配置、タイトル、コメント)を定義することもできます。
リレーションシップ定義エディターは、ERwinがデータベースに作成する制約の名前と一致するリレーションシップの物理名を指定します。
これで、データベースを作成する準備がすべて整いました。ターゲットDBMSを選択する必要があります(これが以前に行われたことがない場合)。 たとえば、Sybase System10を選択しましょう。
SYBASEデータベーススキーマエディタで、テーブル列のデータ型を設定します。
データ型を選択するダイアログを図5に示します。

米。 5.物理モデルの決定

これで、データベースの作成に進むことができます。 このために、「Sybaseスキーマ生成」コマンドが実行されます。 ERwinは、データベース生成SQLステートメントのパッケージを構築します。 図6は、データベースを生成するためのパッケージを生成するためのパラメーターを選択するためのダイアログを示しています。 この図は、フィルターの設定(すべてのテーブルの生成ではない)、SQLステートメントのパッケージの表示(プレビュー)、印刷、ファイルへの保存(レポート)、および生成(生成)ができることを示しています。

米。 6.データベースを生成するためのパラメータの選択

高度なERwin機能

実験室作業第3。 Erwinを使用したデータベースモデリング

仕事の目的-CASEを使用して論理的および物理的データモデルを作成するための実践的なスキルの学生による習得-情報システム開発ツール。

基本情報

ERwinは、データベースのフォワードモデリングとバックワードモデリングをサポートしています。 直接モデリングでは、データベーススキーマは実体関連図を使用して直接記述されます。 図のエンティティは長方形で表されます。 各長方形は、異なる視覚的属性を持つことができます。 各エンティティには一意の名前を割り当てる必要があります。 エンティティ名は単数である必要があります。 これは、システムが常にエンティティの個別のインスタンスで動作するという事実によって決定されます。 この場合、エンティティの個々のインスタンスはオブジェクトと見なされ、エンティティはオブジェクトのクラスと見なされます。 エンティティがBPwinでのモデリング中に記述された場合、それらは単にERwinにインポートできます。 エンティティが作成された図の例を図に示します。

図4-エンティティが作成された図の例

ERwinでのモデル構築

情報モデルには2つの可能な視点があり、したがって、モデルには2つのレベルがあります。 1つ目は、論理レベル(ユーザーの視点)は、実生活からの事実を直接表示することを意味します。 たとえば、人、テーブル、部門、犬、コンピューターは実際のオブジェクトです。 それらは自然言語で名前が付けられ、単語の区切り文字(スペース、コンマなど)が付いています。 モデルの物理レベルでは、特定のDBMSの使用が考慮され、データ型(整数や実数など)、テーブルのインデックスが決定されます。

ERwinは、単一の図(モデル)のこれら2つの異なるレベルのプレゼンテーションを作成および管理する機能を提供し、各レベルで多くの表示オプションを備えています。 ERwinの「ロジックレイヤー」という用語は、概念モデルに従います。

情報モデルを構築する段階。

  • エンティティの定義;
  • エンティティ間の依存関係を定義する。
  • 主キーと代替キーの設定。
  • エンティティ属性の定義。
  • モデルを必要なレベルの正規形にする。
  • モデルの物理的記述への移行:通信の割り当てエンティティ名-テーブル名、エンティティ属性-テーブル属性。
  • トリガー、手順、制約の設定。
  • データベースの生成。

アーウィンは、解決されている問題の視覚的表現(データモデル)を作成します。 このビューは、開発サイクル中に必要なドキュメントの詳細な分析、改良、および配布に使用できます。 ただし、ERwinは単なる描画ツールではありません。 ERwinは、データベース(テーブル、インデックス、ストアドプロシージャ、参照整合性のトリガー、およびデータの管理に必要なその他のオブジェクト)を自動的に作成します。

エンティティの作成。

モデルにエンティティを追加するには、ツールバー(Erwin Toolbox)のエンティティボタンをクリックしてから、ダイアグラム上の新しいエンティティを配置する場所をクリックする必要があります。 エンティティを右クリックし、ポップアップメニューから[エンティティエディタ]を選択すると、エンティティの名前、説明、およびコメントを定義する[エンティティエディタ]ダイアログを開くことができます。

各エンティティは、[定義]タブのテキストによる説明を使用して完全に定義する必要があります。 これらの定義は、オブジェクトの種類を理解できるため論理レベルでも、スキーマの一部としてエクスポートして実際のデータベースで使用できるため物理レベルでも役立ちます( entity_nameのCREATECOMMENT)。 注、注2、注3、UDP(ユーザー定義プロパティ)タブは、エンティティにコメントと定義を追加するために使用されます。

各エンティティの[アイコン]タブでは、モデルビューモードでアイコンレベルで表示される画像と、他のすべてのレベルで表示される画像を関連付けることができます。

[エンティティエディタ]ダイアログの[UDP]タブは、ユーザー定義のプロパティを定義するために使用されます([ユーザー]-[定義済みのプロパティ])。 このタブのボタンをクリックすると、[ユーザー定義プロパティエディター]ダイアログが呼び出されます([編集] / [UDP]メニューからも呼び出されます)。 その中で、UDPが開始されるオブジェクトのタイプ(図全体、エンティティ、属性など)とデータタイプを指定する必要があります。 新しいプロパティを追加するには、テーブルのボタンをクリックして、名前、データ型、デフォルト値、および定義を入力します。

属性の作成。

モデル作成の次のステップは、各エンティティの属性を設定することです。 属性タイプを指定する場合、ドメインを使用できます。 ドメインは、任意の物理データ型に割り当てられる抽象的なユーザー定義型です。 さらに、各ドメインには、入力データを検証するための独自のデフォルト値とルールを設定できます。 ERwinは、独自のデータ型の作成に関連するすべてのステップを文書化する機能を提供します。 ドメインの概念を使用して、データベースはさまざまなハードウェアプラットフォーム間で移植可能です。

図5-新しいドメインの作成 図6-新しいドメインのプロパティの指定

図7-新しいドメインのデフォルト値

図8-ドメインを使用してデータ型を属性に示します。

属性を説明するには、エンティティを右クリックして、表示されるメニューから[属性エディタ]を選択します。 [属性エディタ]ダイアログが表示されます。

[新規]ボタンをクリックすると、表示される[新しい属性]ダイアログで、属性の名前、物理モデルでそれに対応する列の名前、およびドメインを指定できます。 属性のドメインは、物理モデルレベルで列タイプを定義するときに使用されます。

属性エディタの[全般]タブの主キー属性については、[主キー]選択ボックスでチェックマークを付ける必要があります。
[定義]、[メモ]、および[UDP]タブには、エンティティを定義するときと同じ機能がありますが、属性レベルです。

図をわかりやすくするために、各属性をアイコンに関連付けることができます。 これは、[全般]タブのアイコン選択リストを使用して実行できます。

属性に正しい名前を付けることが非常に重要です。 属性は単数で名前を付け、明確な意味を持っている必要があります。

IDEF1X構文によれば、属性名は(エンティティ内だけでなく)モデル内で一意である必要があります。 デフォルトでは、既存の属性名を入力しようとすると、ERwinはその名前を変更します。 たとえば、Comment属性がモデルにすでに存在する場合、(別のエンティティ内の)別の属性にはComment / 2、次にComment / 3という名前が付けられます。
エンティティ内およびエンティティ間で属性を転送する場合、ツールパレットのボタンを選択することでドラッグアンドドロップ手法を使用できます。

新しい関係を作成するには、ツールボックス(ERwin Toolbox)で識別関係または非識別関係を選択し、最初に親をクリックしてから、子エンティティをクリックします。
ツールパレットでは、ボタンは識別関係、多対多関係ボタンに対応し、ボタンは非識別関係に対応します。 リレーションシップのプロパティを編集するには、リレーションシップを右クリックし、コンテキストメニューから[リレーションシップエディター]を選択します。

表示されるダイアログの[全般]タブで、カーディナリティ、名前、および接続のタイプを設定できます。

通信力(カーディナリティ)-子のインスタンスの数に対する親エンティティのインスタンスの数の比率を示すのに役立ちます。
力には4つのタイプがあります:

・親エンティティの1つのインスタンスが0、1、または子エンティティの多数のインスタンスに対応する一般的なケースでは、記号はマークされていません。

・記号Pは、親エンティティの1つのインスタンスが子エンティティの1つまたは複数のインスタンスに対応する場合を示します(ゼロ値は除外されます)。

・記号Zは、親エンティティの1つのインスタンスが子エンティティの0または1つのインスタンスに対応する場合を示します(複数の値は除外されます)。

・数字は、親エンティティの1つのインスタンスが子エンティティの所定の数のインスタンスに対応する場合を示します。

デフォルトでは、通信電力の記号は図に示されていません。 名前を表示するには、モデルオブジェクトで占められていないダイアグラム内の任意の場所を右クリックした場合に表示されるコンテキストメニューに従い、[表示オプション] / [関係]項目を選択して、[カーディナリティ]オプションを有効にします。

リンクタイプ(識別/非識別)。

IDEF1Xは、従属エンティティと独立エンティティを区別します。 エンティティのタイプは、他のエンティティとの関係によって決定されます。 識別関係は、独立した(関係の親の端)エンティティと依存した(関係の子の端)エンティティの間に確立されます。 識別関係が描画されると、ERwinは子関係を依存関係に自動的に変換します。 依存エンティティは、角の丸い長方形で描画されます。

依存エンティティのインスタンスは、親エンティティとの関係を通じてのみ定義されます。 識別関係が確立されると、親エンティティの主キー属性が子エンティティの主キーに自動的に転送されます。 関係を作成するときに子エンティティの属性を拡張するこの操作は、属性の移行と呼ばれます。 子エンティティでは、新しい属性は外部キーとしてマークされます-(FK)。

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

識別リンクは、リンクの子端に太字の点が付いた実線と、非識別リンクが破線で示されています。

識別できない関係の場合は、必須を指定できます([関係エディター]ダイアログの[全般]タブの[NULL])。 必須の関係(Nullなし)の場合、データベーススキーマを生成するときに、外部キーが子エンティティの主キーに含まれないにもかかわらず、外部キー属性はNOTNULL記号を受け取ります。 オプションの関係(NULLを許可)の場合、外部キーはNULLにすることができます。 オプションの非識別関係は、親エンティティの側面に透明なひし形でマークされています

リンク名(動詞句)-親エンティティと子エンティティ間の関係を特徴付けるフレーズ。 識別または非識別の1対多の関係の場合、親から子への関係(親から子)を特徴付ける名前を指定するだけで十分です。 多対多の関係では、親から子への名前と子から親への名前の両方を指定する必要があります。 名前を表示するには、モデルオブジェクトで占められていないダイアグラム内の任意の場所を右クリックした場合に表示されるコンテキストメニューに従い、[表示オプション] / [関係]項目を選択して、[動詞句]オプションを有効にします。

ロール名または機能名(ロール名)子エンティティでの属性の役割を示す外部キー属性の同義語です。 ロール名は、[リレーションシップエディタ]ダイアログの[ロール名/ RIアクション]タブで設定できます。

キーの作成。

各エンティティインスタンスは一意であり、他の属性とは異なる必要があります。

主キーエンティティインスタンスを一意に識別する属性または属性のグループです。 図の主キー属性は特別な指定を必要としません-これらは水平線の上の属性リストにある属性です。 [属性エディタ]ダイアログで新しい属性を追加する場合、それを主キー属性にするには、[全般]タブの下部にある[主キー]チェックボックスを有効にする必要があります。 図では、属性転送モード(ツールパレットのボタン)を使用して、キー属性を主キーに追加できます。

1つのエンティティには、主キーであると主張する複数の属性または属性のセットが含まれる場合があります。 そのような申請者は呼ばれます 潜在的なキー(候補キー)。

キーは複雑になる可能性があります。 複数の属性を含みます。 複雑な主キーは特別な表記を必要としません-それらは水平線より上の属性のリストです。 主キーを選択するときは、より単純なキーを優先する必要があります。 属性の少ないキー。

多くのエンティティには、潜在的なキーが1つしかありません。 このキーがプライマリになります。 一部のエンティティには、複数の可能なキーがある場合があります。 次に、そのうちの1つがプライマリになり、残りは代替キーになります。

代替キープライマリキーになっていない潜在的なキーです。

各キーにはインデックスが関連付けられており、その名前も自動的に割り当てられます。 キー名とインデックス名は、必要に応じて手動で変更できます。

この図では、代替キー属性は(Akn.m.)として示されています。ここで、nはキーの序数、mはキーの属性の序数です。 代替キーに複数の属性が含まれている場合、(Akn.m。)はそれぞれの後に配置されます。

外部キーリレーションシップがエンティティを接続すると、自動的に作成されます。リレーションシップは、子エンティティの主キー属性への参照を形成し、これらの属性は、子エンティティの外部キーを形成します(キーの移行)。 外部キー属性は、名前の後に(FK)で識別されます。

依存エンティティは、複数の親エンティティからの同じキーを持つことができます。 エンティティは、いくつかの異なる関係を通じて、同じ親から同じ外部キーを複数回受け取ることもできます。 ERwinは、これらのイベントの1つを検出すると、2つの属性が同じであることを認識し、外部キー属性を依存エンティティに1回だけ配置します。 同一の属性のこの組み合わせまたは融合は、統合と呼ばれます。

統一が望ましくない場合があります。 たとえば、2つの属性の名前が同じであるが、実際には意味が異なる場合、この違いを図に反映させる必要があります。 この場合、外部キーロール名を使用する必要があります。

図の関係は、あるエンティティ(テーブル)から別のエンティティ(テーブル)に向かう線で表されます。 各リンクには一意の名前が割り当てられます。 リンクされたテーブルは、親テーブルと子テーブルに分けられます。 親テーブルは右隅の長方形で表示され、子テーブルは角の丸い長方形で表示されます。

データ形式のすべての属性を指定した後、作成した論理モデルを物理モデルに変換する必要があります。 このためにあなたはする必要があります ツール選択する 新しいモデルを導き出す、ここで、ターゲットデータベースは ODBC /ジェネリック(MySQL DBMSで使用する場合)図9を参照してください。モデル(図4を参照)は、図11を参照する形式に変換されます。

図9-論理モデルから物理モデルへの変換

図10-データ形式を示す物理モデル。

図11-SQLコードの生成

エクササイズ

1.特定のサブジェクトエリアの特定のエンティティ(直接モデリング)を使用して図を作成します。

2.定義された各エンティティの属性を設定します。 属性を設定するときにドメインを使用します。

3.エンティティ間の関係を入力します。 リンクに一意の名前を付けます。

4. DBMS MYSQLを使用して、投影された情報のデータベースを直接生成することを決定します。

5.レポートには、MYSQLDBMSの概念モデルと物理データベースが含まれている必要があります。

質問を制御する

1. ERwinを使用したデータモデルの表示の論理レベルと物理レベルの違いは何ですか?

2.実体関連図の形式で、キーに基づいて、および完全な属性モデルの形式で提示されるデータモデルの違いは何ですか?

3. IDEF1X方法論に従って提示されたデータモデルの主なコンポーネントは何ですか?


DBMSでサポートされているデータ型のリストは、製造元に確認する必要があります

異常の概念が必要です。これは、概念データスキーマと論理(および物理)データスキーマの整合性制約の不一致です。 正規化の目標は、データをオンにしたり、更新したり、削除したりするときに表示される異常を正確に排除することです。

4つの第一正規形(より正確には、第1、第2、第3、およびボーイズ-コッド)は、関係図とヒースの定理で与えられる関数の古典的な概念に基づいているため、1つのグループにまとめられます。

さらに2つの正規形(4番目と5番目)は変更されたものを使用します 機能従属性..。 最後 通常の形式-ドメインキー-原点への回帰を示します-関係理論への論理的アプローチ。

最初の4つの正規形でベースのスキーマを取得する実用的な方法が推奨され、ほとんどの場合、スキーマの最終バージョンが提供されます。 この構造の正しさは、形式手法によってチェックする必要があります。つまり、ヒューリスティック手法と正規化の理論の両方が必要です。

最初に、正規化に関する資料を提示するための受け入れられている方法について説明しましょう。 当然のことながら、リレーショナルデータモデルのフレームワークで開発された正規化の理論から進みます。 しかし、経験によれば、このようなプレゼンテーションでは、初心者は、概念的なビジネスモデルからデータベースモデルへのマッピングの「不正確さ」の特徴として定義される、異常の本質的な概念を理解するのが困難です。 それが理由です

リレーショナルモデルからすでに知られている実体関連モデルへのマッピングを使用し、ERモデルでは正規化について検討します。 これにより、異常に対処するために必要なセマンティクスがもたらされます。

関係間の関係、関係の結合、および外部キーについてもう一度考えてみましょう。

5.1関係と外部キー

前の章では、エンティティを接続する概念とそれらの間の関係について説明しました。 それらを明確に区別します。 接続はアクティブであるため、接続の概念は本質的に代数的ではありません。 実装では、リンクはベースの構造を設定し、データ操作とスキーマ変更を処理します。 接続は代数の概念です。 接続中に取得されたデータの意味は、完全に開発者の良心に基づいています。 接続の意味は、モデル化されたビジネスによって厳密に設定されます。

リンクのセマンティクスはかなり発達しています。 両端のカーディナリティに加えて、必須の識別可能なプロパティなどのプロパティが使用されます。 それらをリレーショナルモデルで直接表現することはできません(そのような言葉はありません)。 したがって、最初の正規形は「実体関連」モデルの枠組みの中で考慮されます。

リレーショナルモデルとERダイアグラムの両方の関係/エンティティ間の関係は、「外部キー」(略してFK)と呼ばれる参照整合性制約によって形成されます。

リレーショナルモデルの貧困を何かを実現することが不可能であるという誤った考えを生み出さないために、n:m関係は2つの1:n関係で表され、複雑な関係はさまざまな方法でモデル化できることを忘れないでください。 集合体でさえ、それらの構成を説明するエンティティを導入することによって、何らかの形で表すことができます。 このようなモデルはプログラムに効果的に実装できますが、おそらく人間にとっては不便です。 リレーショナルモデルのフレームワーク内でデータ構造をモデル化する可​​能性は非常に広いですが、もちろん、無限ではありません。

構造の分析への一般的なアプローチについて説明しましょう。これは、図5.1に示す2つの関連エンティティ「従業員」と「部門」の例でさらに分析されます。 左側には識別リンクのあるバリアントがあり、右側には非識別リンクのあるバリアントがあります。


米。 5.1。 1対多の関係の例

例をテキストで説明されているとおりに検討することに同意したことをもう一度お伝えしたいと思います。 この制限は、情報がすべての人に常に同じように認識されるために必要です。

スキームの両方のバージョンで、各従業員は部門の1つに割り当てられます。 私たちは関係を持っています(「従業員」関係の側の「多対」)。 「従業員」に関しては、部門のリストに存在しない部門番号deptno(「Department」エンティティ)を選択することはできません。 1つの部門に、1人、1人、2人、またはそれ以上の従業員を配置することはできません。

同様の例(セクション2.2.7)に関して、逆説的な状況が形成されていることに注目しました。 部長は特定の部署に配属されており、この部署の長は部長に従属し、同時に部長になります。 しかし、おそらく部門はコストセンターであり、ディレクターの給与は部門の1つの費用に請求されることが決定されました。 私たちのチュートリアルでは、もちろん反対のことが示されていない限り、そのような詳細を扱うべきではありません。 とりわけ、最初からビジネスの側面について考えることに慣れるべきですが、教育上の問題を解決するときは、考えられる選択肢を分析するためにタスクを拡張するべきではありません。

図5.1の図の違いは何ですか? 識別接続により、従業員を主に部門の従業員と考えることができます。 非識別関係とは、部門に属することが二次的なものとしてマークされていることを意味します。

5.2コミュニケーションの種類。 識別および非識別、必須およびオプションのリンク

識別リンクタイプと非識別リンクタイプ(図5.1を参照)は、リレーショナルデータベース理論に属していませんが、ERwin(別名AllFusion Data Modeller)の基礎となっているIDEF1Xモデリング標準に属しています。

外部キーが依存(弱い)エンティティを作成する場合、それはこのエンティティの主キーを形成する属性グループに渡されます。 この場合、識別リンクが形成されます。 常に必要です。

非識別関係は、2つの強力なエンティティを接続するために使用されます。 キーを非キー属性領域に渡します。

識別できない関係の場合は、義務を指定できます(関係全体であり、その終わりではありません)。 関係が必要な場合(ERwinでは、これはNullなし機能の設定です)、外部キーの属性はNOT NULL機能を受け取ります。これは、未定義の値が許可されないことを意味します。 オプションの関係(NULL許可フラグ)の場合、外部キーはNULLにすることができます。

ダイレクトエンジニアリングを使用して「SQL言語」のSQL言語に慣れると、データベーススキーマのフラグメントを作成するSQLスクリプトを生成できるようになります。 ただし、現在でも、SQLに少しでも慣れている場合は、[ツール]> [フォワードエンジニア/スキーマ生成]に移動し、[プレビュー]ボタンをクリックして生成されたテキストを表示します。

リレーショナルモデルのフレームワークでの古典的なアプローチに限定するのではなく、正規化を検討するときに、より複雑なエンティティリレーションシップモデルを使用するのはなぜですか? 結局のところ、強いエンティティと弱いエンティティの概念、識別関係、必須およびオプションの非識別関係の追加は、データモデルのセマンティクスを大幅に複雑にします。

上記の5つの高レベルの概念の導入により、タスクの詳細をより適切に反映する言語が提供されるため、開発者にとってより理解しやすくなります。 これにより、正式な変換を行わなくても、リレーショナルベースの初期スキーマをほぼ完全な形式ですばやく取得できます(後で、このアイデアをより正確に表現します:「第3正規形またはボイスコッド正規形」)。