3

エンティティ関係図に関するすべてのチュートリアルで、関係に固定カーディナリティを指定することは許可されていないことを読みました。ERD に関する非公式のコメントのみが、パイロットの数がexactly 2.

したがって、たとえば、各フライトに正確に 2 人のパイロットが存在するフライトとパイロットの関係は、次のように表す必要があります。

<flight> 0..N <------> 1..N <pilot>

それよりも

<flight> 0..N <------> 2 <pilot>

私の表記法は0..N= オプションです。1..N= 必須、多数、1= 必須、1 つ。

この制限は普遍的なものですか? その背後にある理由は何ですか?

編集:表記を明確にしました。

編集: 2 つの関係が同じ制約をどのように適用するかがわかります。

         0..N <------> 1
<flight>                 <pilot>
         0..N <------> 1

しかし、パイロットが特定のフライトに乗っているかどうかを確認するクエリは、2 つの属性のそれぞれをチェックする必要があるため、非常に厄介なものになります。また、属性の数が増えると (たとえば、客室乗務員が 15 人になると)、クエリは完全に管理できなくなり、スキーマはほとんど管理できなくなります。

4

6 に答える 6

7

他の回答は、答えのいくつかの貴重な部分を提供しました。さらに 2 つの部分を追加する必要があります。

まず、ER モデリングは単なる ERD ではありません。ER モデル全体を 1 つの図にまとめようとする傾向があります。しかし、完全な ER モデリングは、1 つの図に収まるもの以上のものです。リレーションシップのカーディナリティを 10 以上 15 以下に制限するビジネス ルールが存在する場合があります。 . 完全な ER モデルには、データに関するこれらすべてのビジネス ルールを含めることができ、必要に応じて平易な英語で表現することができます。

ルールが存在する理由など、ルールを明確にするために詳細が必要でない限り、10..15 という表記がより簡潔であるため、優先されます。

上記は、作成する必要がある 2 番目のポイントを示しています。それが分析と設計の違いです。ER モデリングが古典的な方法で使用される場合、それはデータ分析のツールであり、データベース設計のツールではありません。「データ分析」とは、データ中心の観点からの問題分析を意味します。分析と設計、問題の特徴と解決策の特徴を区別することは、正式な CS や IT 教育では十分に教えられていないことです。物事を正しく行うには、絶対に重要です。

そして、違いを認識している私たちでさえ、問題の定義にソリューションの機能を滑り込ませたり、滑らせたりすることがあります。これは「箱の中で考える」と呼ばれます。

データベースの設計図を作成する場合は、ERD を使用しないでください。設計しているデータベースがリレーショナルである場合は、リレーショナル スケマティック ダイアグラムを使用します。リレーショナル スケマティックには、ジャンクション テーブルや外部キーなど、ERD に含めるべきではない機能が含まれています。ERD を「リレーショナル ライト」として使用しないでください。それはそうではありません。

ちなみに、別の回答では、ERD はどの DBMS でも実装可能であるべきだというコメントがありました。これは、ERD が設計ではなく分析を捉えるという、私が今提示した概念の結果です。

于 2012-09-16T10:24:20.040 に答える
2

カーディナリティ ルール自体は、「一般的に考えられるありとあらゆるルール」の特殊なケースにすぎません。「ありとあらゆる可能な規則」を表現できる言語は、人間の自然言語 (どんなに頑張ってもあいまいで不正確であることが多いという欠点があります) と、形式的な述語論理の記号言語の 2 つだけです。

データモデリングのコンテキストで後者を使用する方法は、優れた(そして非常に称賛に値する)本「データベース専門家のための応用数学」の全体的なトピックです。

Halpin の ORM は、E/R よりも多くの種類のビジネス ルールをカバーできる (つまり、表現するグラフィック シンボルがある) モデリング言語を考え出す試みです。たとえば、非巡回グラフの制約を表すための記号があります (「自分の祖先になる人はいない」)。しかし、この言語でさえすべてを表現することはできず、自然言語を使用してのみ記述できる「その他」と呼ばれる最終クラスの制約に必然的に頼らなければなりません。

言語の問題です。ごく少数の記号 (四角形、接続線、0、1、およびクロウフット) を使用して言語を考案した場合、それらを組み合わせる方法は非常に少なく、そのような言語に次のことができるとは期待できません。考えられることは何でも表現します。

于 2012-09-16T10:14:47.567 に答える
1

あなたの質問に対する直接的な回答ではありませんが、実際のデータベースでこの種の制約を適用する方法に興味があるかもしれません...

フライトには最大 2 人のパイロットを乗せることができるとしましょう。2 つの "0..N から 0..1" の関係を簡単に作成できます。

ここに画像の説明を入力

そして、正確に2 人のパイロットが必要な場合は、PILOT1_ID と PILOT2_ID を NOT NULL にします (そして、CHECK によってそれらが異なることを確認します)。


ただし、すでに指摘したように、これはカーディナリティが大きくなるとすぐに扱いにくくなるため、別の手法が必要です。客室乗務員の数を 15 人に制限する必要があるとしましょう。次のようにできます...

ここに画像の説明を入力

...ジャンクション テーブルに次の制約があります。

CHECK (POSITION BETWEEN 1 AND 15)

U1上の図で示されているように、{FLIGHT_ID, POSITION} には UNIQUE 制約があることに注意してください。

基本的に、私たちはフライトごとに特定の位置にアテンダントを配置しています。2 人のアテンダントが同じフライトで同じポジションを占有することはできません ( のおかげですU1)。フライトごとに正確に 15 のポジションがあるため、フライトごとに 15 人を超えるアテンダントは存在できません。

残念ながら、すべてのポジションを強制的に埋める良い方法はないため、フライトごとにアテンダントが 15 人未満になる可能性があります。それが重要な場合は、アプリケーション コードから強制する必要があります。

- - 編集 - -

(次の INSERT に使用する) 空いている位置を探すには、それが 2 つの既に埋められた位置の間の「穴」であっても、次のようにすることができます (1目的の FLIGHT_ID に置き換えます)。

SELECT DISTINCT *
FROM (
    SELECT POSITION + 1 FREE_POSITION
    FROM FLIGHT_ATTENDANT
    WHERE FLIGHT_ID = 1
    UNION ALL
    SELECT POSITION - 1 FREE_POSITION
    FROM FLIGHT_ATTENDANT
    WHERE FLIGHT_ID = 1
)
WHERE
    FREE_POSITION NOT IN (
        SELECT POSITION
        FROM FLIGHT_ATTENDANT
        WHERE FLIGHT_ID = 1
    )
ORDER BY FREE_POSITION;

このクエリの結果は次のようになります。

  • 行が返されない可能性があり、すべての位置が空いていることを示しているため、有効な範囲内のいずれかを選択してください。
  • 行が返される可能性があり、その最初と最後が有効な範囲外である可能性があるため、そうである場合は無視してください。残りの行の 1 つを使用します。残りの行がない場合、これはすべての位置が埋まっていることを示しています。

これは、Oracle でのSQL Fiddle の実際の例ですが、同じ手法をどの DBMS にも適用できるはずです。これらの種類のクエリを実行するためのより洗練された DBMS 固有の方法があります (特に、一部だけでなくすべての空き位置が必要な場合)、この「一般的な」ソリューションでさえ、ほとんどの実用的な目的には十分すぎるはずです...

于 2012-09-16T11:59:32.897 に答える
0

E-R図は、各エンティティが関係に参加する回数の制約を示す方法を提供します。
エンティティ セットとバイナリ リレーションシップ セットの間のエッジには、最小カーディナリティと最大カーディナリティを関連付けることがmin...max
できminます1。のmax値は1最大 1 回の参加を示しmax*またはのN値は上限がないことを示します。
今あなたの質問に来ます。パイロットは多くのフライトに参加し、あなたが暗示しているように1つではありません。
また、各フライトに正確に 2 人のパイロットがいて、両方が必要な場合、これはモデル化されません。1-N関係はありませんが、フライトの 2 つの属性 (パイロット ID) としてです。これは、null またはオプションになることはないためです (2 人のパイロットなしでフライトを行うことはできません)。
したがって、定数の上限は、システムをモデル化するのに十分な汎用性がない設計の問題を示しています。

于 2012-09-16T08:48:30.277 に答える
0

一意のインデックス (主キーなど) と一意でないインデックスがあります。一意のキーの定義に従って、1 つのレコードまたは複数のレコードが許可されています。

それで

null フィールドまたは強制的に値を持つフィールドがあります: ここでは、値が 0 または 1 の可能性があります

これら2つのことを組み合わせると、なぜ常に0以上と言うのかを知ることができるはずです

ERD は常に RULES を強制できるわけではありません。ルールは通常、DB 設計によって強制できますが、ソフトウェア (または少なくともストアド プロシージャ) からの別のレイヤーが常に必要になります。

ちなみに、あなたの例に関しては、すべてのフライトに常に 2 人のパイロットがいて、データベースの設計によってこのルールを適用したい場合は、Pilots テーブルから Flight テーブルへの 2 つのリレーションを作成するだけです。はい、2 つの外部キーがあります。同じテーブルに、ERD はそれを許可します

于 2012-09-16T08:34:57.563 に答える
0

私は同様の問題を経験しました。私のシナリオは、2 つのサッカー チームが 1 つの試合に参加することでした。したがって、2 つのテーブルは「Team」と「Fixture」でした。フィクスチャ テーブルには、「team_home」列と「team_away」列がありました。これが最善の方法なのか、それとも正しい方法なのかはわかりませんが、私にとってはうまくいきました。

ソリューション max をどのように実装しましたか?

于 2012-10-03T15:28:25.700 に答える