エンティティの依存関係について

どういう場合に依存エンティティにするべきか、逆にどういう場合は独立エンティティかが分からなかったので、追加で調べてみました。
外部キーが主キーになっているなら、それは依存エンティティというのは分かるんですが、理由を知らずに結果だけ覚えても応用が利かないので。

「注文」エンティティと「出荷」エンティティは依存のリレーションシップにあります。「依存のリレーションシップ」とは、つまり「親エンティティに依存しなければ子エンティティが存在できない状態」を意味します。これを踏まえると、図2の依存のリレーションシップは出荷を行うには必ず注文が必要になるというビジネスルールを表しています。なお、依存のリレーションシップを表現する場合は実線を使います。
　例えば、顧客の要望により先行出荷を行うこともある場合、「注文」エンティティと「出荷」エンティティは図3のER図のように「独立のリレーションシップ」として表現します。依存のリレーションシップは実線で表しましたが、独立のリレーションシップは破線で表します。
ビジネス視点のデータモデリング (1/3)：ゼロからのデータモデリング入門（8） - ＠IT

ちょっと心許ないですが、理由を説明していたのはここくらいでした。
もっとデータモデリングの際の考え方的なものがあるかと思ったんですが、[データモデリング依存関係] とかで検索しても出てこなかったので、そんな深いものでもないのかも。

注文/出荷エンティティをER図*1に書いてみました。
出荷が依存してるのと独立なので2パターン。

普通に考えれば注文を受けてから出荷するから、注文エンティティに出荷エンティティが依存します。
注文がまだないのに、先に出荷をするような場合を考えると、出荷エンティティが独立じゃないとだめ。
出荷エンティティに外部キーとしてある注文Idが、注文エンティティにまだなくても良いという事です。

外部キー

外部キーは必ず NOT NULL 制約が付くと勘違いしていました。
外部キー使うときは、いつも NOT NULL にしてたし、実際に外部キーがNULLだとだめなものを作ってたし。
でも実は外部キー制約というのは、NULLを許容しました。
他のRDBMSは分かりませんが、少なくともPostgresでは。
外部キーにNULLが入れられれば、id_order を NULL にして、注文より先に出荷が出来そうです。

もう1個疑問点が・・・

っと、ここまで書いて新たに疑問点が出てきました。
依存エンティティの場合、親子間のカーディナリティはone-to-oneの関係しかありえない？

依存エンティティは、親の主キーを外部キーとして持ち、それを自身の主キーにします。
実際に、ER図を書くツールでも、出荷を依存エンティティに設定しようとすると、強制的に id_order は主キーにせざるを得ません。
でも、例えばPostgresの主キーというのはユニーク制約とNOT NULL制約を合わせたものです。
id_order にユニーク制約があるという事は、注文と出荷はone-to-oneにしかならない気がします。
うーむ、振り出しに戻った感が・・・もっと調べないと。