1

私が取り組んでいるデータベースの 1 つに、エンティティ関係図で説明したい風変わりな動作があります。

動作の 1 つは、「予約」テーブルと「請求書」テーブルがあることです。「予約」が請求されると、レコードが「請求」テーブルに挿入され、「予約」テーブルから削除されます。

ただし、予約番号の参照は引き続き保持されます。

これをどのようにモデル化しますか？表の間の大きな矢印と、何が起こるかを説明するその横のテキスト?

いいえ、現時点ではデータベース スキーマを変更することはできません

編集: これは私が使用したい図のタイプです: 代替テキスト http://img813.imageshack.us/img813/5601/erdartistperformssong.png リンク

4

3 に答える 3

2

これらの人々が何について話しているのかわかりません。

  1. 実体関連図はデータを完全に説明していません。はい、もちろん、エンティティとリレーションのみが表示され、属性は表示されません。これが、データモデルではなくERDと呼ばれる理由です。明らかに、ここの多くの人々は違いを見分けることができません。

  2. データモデルは可能な限り表示することになっています。ただし、（a）使用する標準（存在する場合）および（b）表記法によって異なります。いくつかは他よりも多くを示しています。唯一のリレーショナルモデリング標準であるIDEF1X（1993年のNIST 184）。それは最も完全であり、他の表記法では示されていない複雑さと複雑さを示しています。最近、MSやその他の人々は「簡略化された」表記法を発表しました。もちろん、「ERD」では多くのことが失われています。

  3. これは「プロセスフロー」ではなく、データベース内の関係です。

  4. UMLは、特に少なくとも1つの標準といくつかの非標準であるが一般的に使用されるデータモデリング表記がある場合、データのモデリングには完全に不適切です。IDEF1Xで表示できないUMLで表示できるものはありません。しかし、ここのほとんどの開発者はそれを聞いたことがありません（開発者は、モデリングスキルを習得していない限り、モデリングを行うべきではありませんが、それは別の話です）。

  5. これは完全に合法です。一般的には知られていないかもしれませんが、合法で名前が付けられています。カーディナリティが1::0-1ではなく1::0-nであることを除いて、これはスーパータイプとサブタイプの関係です。IDEF1X表記（右）にはサブタイプ記号があります。親端には1つの関係しかないことに注意してください。子の端にそれぞれ1つずつ。そしてもちろん、カラスの足はカーディナリティを示しています。これらの関係は、排他的または非排他的である可能性があります。あなたのものは排他的です。それが半円のXの意味です。

    • ERwinは、IDEF1Xを実装する唯一のモデリング（ダイアグラムではない）ツールであるため、IDEF1X表記を完全に補完します。

    • もちろん、モデリング機能である標準は、ツールではなく、すべて念頭に置いています。簡単な描画ツールを使用して、IDEF1Xに準拠したデータモデルを描画します。

  6. 一部の開発者はサブタイプシンボルを嘲笑していることがわかったので、IDEF1Xモデルに簡略化されたバージョン（左）を示します。親端の単一行の保持がサブタイプであることを示している間、それは排他性の感覚を伝えることを目的としています。

Lott：ここをクリック▶<ahref = "http://www.softwaregems.com.au/Documents/Student%20Resolutions/Nitrodist%20DM.pdf" rel = "nofollow">データモデルへのリンク◀ Lott：ここをクリック

リレーショナルモデリング標準に慣れていない人のためのIDEF1X表記へのリンク。

于 2010-11-25T14:59:23.303 に答える
2

ERD とは、関係がひし形で書かれた単語である元の "Chen" ダイアグラムを意味する場合、Booking と Invoice の間には関係があります。これは、単純な外部キーでは実装されない特別な種類の関係です。複雑な移動と制約によって実装されます。

ERD とは、ERwin が描画するダイアグラムを意味する場合、これを行う簡単な方法はありません。PK-FK 関係を描くことに集中する傾向があります。これらのものの間に非 PK-FK 関係があります。テキスト付きのある種の行は、あなたができるすべてのことです。

ERD はデータベースの「状態」を示すため、矢印は適切ではありません。データ フローは ERD の一部ではありません。あなたには関係がありますが、それは典型的な PK-FK 関係ではありません。これは、ある場所に存在し、他の場所には存在しない行に基づく非定型の関係です。

UML では、これを関係間の「制約」として簡単に描くことができます。

于 2010-06-11T20:52:36.420 に答える
1

エンティティ関係ではなく、プロセス フローのように聞こえます。エントリが請求書に追加され、エントリが予約から削除された時点で、両者の間に関係はありません。一緒に関連付けることができるレコードが両方の場所に存在しないため、その関係をたどることができる状況は決してありません。

ERD はデータベースを完全には説明しません。システムの他の側面を詳述するプロセスフローやユースケースなど、他にもあります。

これは、ソフトウェアの UML に似ています。クラス図は、クラスが相互作用するさまざまな方法をすべて示しているわけではありません。1 つのクラスがローカルで初期化して別のクラスの関数を呼び出す場合がありますが、これら 2 つのクラスを関連付ける構成または継承がないため、クラス図にはこの関係が示されません。さまざまな種類のダイアグラムをすべて使用してシステムを完全に文書化して初めて、システムがどのように動作するかのすべての側面を理解できます。

于 2010-06-11T20:53:42.377 に答える