ERD：「多」対「ゼロまたは多」/「1つまたは多」のクロウフット表記？
背景
ERDで使用されるさまざまなクロウフット表記を説明するこの図を見ました： 
「多」表記と「0個または多」表記の違いを見つけることができませんでした。しかし、例を見つけることはできました（「多く」の左下を参照してください"表記）：
（ ソース ）
質問
Whenで「多」表記を使用し、differenceこの表記と「ゼロまたは多数」および「1つまたは多数」の表記の間。
最初の2つの関係OneとManyには、unspecified下限。したがって、それらを使用する場合、それらが必須であるかオプションであるかというあいまいさを残します。
このあいまいさは、次の状況の1つまたはいくつかに対処するために、モデリングで便利です。
- 下限は一時的に未定義になる可能性があります。たとえば、設計段階では、すべてのビジネスルールがまだ明確ではありません。
- 下限は関係ありません。たとえば、ソフトウェアを構成し、ビジネスルールに従って（たとえば、データベースの not null 制約のアドホック定義、または実行時に）後で決定できるためです。アプリケーションコードが状況を受け入れるかどうかを定義する-timeパラメータ。
- 理論モデルとアプリケーションの実践との間に矛盾がある場合に、不必要な不安を回避するため。通常、これは
shipmentからitemの関係に当てはまります。実際には、1つの出荷に少なくとも1つのアイテムが含まれていると予想します（通常、空を送信したくないボックス！）したがって、モデルではone or many。しかし、アプリケーションの反対側では、出荷を2つの段階で作成することを決定することができます。営業所で空の出荷を作成し、後で（製造現場にバーコードリーダーを使用して）アイテムを追加します。そのため、アプリとデータベースは、一時的に空になる可能性がある出荷を処理する必要があります。
最後のケースは、通常予想されるよりはるかに多く発生します。したがって、下限を指定せずに維持することには、dbaと開発者に、理論的仮定（つまり、1対多、つまり最終的に出荷がなくなるため工場は空です）。
私は人々が特定であることを十分に気にしないときだけそれらを使うと思います。
個人的には、リストの最初の2つの例は完全に避けています。
あなたの例では、コンテキストから-出荷には1つだけの荷送人がいて、アイテムは1つだけの出荷に存在し、サプライヤは0対多の出荷を持つことができると仮定します。
通常、-<ホワイトボードで速く書くときの「多くの」表記。ここでは、一般的なアイデアをスケッチするだけなので便利です。この段階ではあいまいさが役立つ場合があります。
「多数」と「ゼロまたは多数」と「1つまたは多数」の違い...
"たくさんの"
-<は、記載されていない下限を想定できないため、「0または複数」と実質的に同じです。それは、チームがそれをどのように理解しているかに応じて、明白またはあいまいになります。「ゼロまたは複数」
-0<は特定のものです。これは、関連するエンティティの数> = 0を意味します。「1つまたは複数」
-|<は、関連するエンティティの数> 0を意味します。
btw：「1つ」-|-表記は明示的です。これは正確に1つを意味し、比較的使用する頻度は低いです。 "one"の漠然としたバージョンを書きたい場合は、--末尾に記号がありません。
これは、遊び場の野球に少し似ています。これが私の近所での演奏方法です。このためのISO委員会はありますか？本当に気にしますか？
あなたは尋ねました：
いつ多くの表記を使用するのですか？
ERDは、RDBMSルールとして実装することを決定した設計とビジネス要件を反映する必要があります。
あなたが提供したERDの例として、「出荷に多数のline_itemsが含まれています」。両方が必須であるため、これは次のことを意味します。
1-物理設計では、ItemテーブルにShipment IDのFKがあります。
2-このFK列はnullを許可できません。そのため、Item_tableにline_itemを挿入する前に、既存の出荷を参照する必要があります。
3-結果として、ラインアイテムを挿入する前に、出荷テーブルに目的の行を含める必要があります。
あなたは尋ねました：
この表記と「ゼロまたは複数」および「1つまたは複数」の表記の違いは何ですか。
あなたの図は、これを説明するために使用する簡単なケースを提供していません。
1対多のリレーションシップがある場合、リレーションシップの片側のテーブルのPKが作成され、リレーションシップの多側でFKの役割を果たすことになります。前の例とよく似ています。違いは、「ゼロまたは多数」がある場合、それは実際には「ゼロ、1または多数」であることです。つまり、特定のビジネス条件下では、アプリケーションがこれを参照するアイテムがない場合でも、出荷テーブルに行を挿入できます。特定の出荷。
前のケースとは異なり、FKはItemテーブルにNullable（nullを許可）として作成されます。