1対0または1（1-0..1）の関係が存在するシナリオ用のデータベースを設計しているとしましょう。例えば：
したがって、対応する2つのテーブル、usersおよびを作成しましたcustomersが、…
…特定のSQLプラットフォームでこの状況を表現して実装する最良の方法は何ですか？私は2つの可能な解決策を検討しました：
でusersテーブル、追加customerのFOREIGN KEY参照のいずれであってもよく、列customersまたはNULLマーク。
customersテーブルに、テーブルを指すuser列（UNIQUE制約付きで設定）を含めusersます。
すでにいくつかのフォーラムで同様の質問をしましたが、答えは基本的に「必要なものは何でも」「便利だと思うものは何でも」でした。このような答えは好きではありません。代わりに、DB理論の真面目な部分が必要です。1-0..1の関係についてどこで確認できますか？
回答:
DB理論の真面目な部分が欲しい
現代の関係理論はnullを拒否しますが、これはオプション1をすぐに無効にするように思われます。ただし、このストローマンは、デフォルトのnullをデフォルト値で置き換えることで排除できます。対応。
変更されたオプション1とは異なり、関係は第6正規形（6NF）になる可能性があるため、オプション2が最も理論的に正しいと思います。
私は、関係がエンティティまたはエンティティ間の関係のどちらか一方をモデル化する必要があると述べた設計経験則も聞いたことがあります。これは私には理にかなっているようです。繰り返しになりますが、これはオプション2を支持します。しかし、この経験則を何年も前に聞いたことがあります。どこで、深刻な理論的根拠を提供できないかを思い出さないでください（上記の6NF以外）。
あなたは部分的に正しい答えを与えられました。本当の答えはあなたのデータモデルとそれがどのように正規化されたかから来ます。重要なのは、どのようにして関係を築くかです。
customers表は、のために考慮フィールドの数で構成されusers、顧客の概念に属し、ユーザは、顧客（ユーザのサブタイプ）でない限り、ヌルであるテーブル。この場合、customersテーブルはusersテーブルから主キーを継承します。（重複することもしないこともある複数のサブタイプが可能です。）
このcustomers表は、顧客の概念に関連するいくつかのフィールドで構成されていますが、必ずしもユーザーの概念とは限りません。顧客は強力なテーブルであり、ユーザーの概念に依存していません。（usersテーブルを削除しても、customersテーブルの設計に大きな影響はありません。）この場合、customersテーブルは独自の主キーを取得します。
あなたが持っているのは、上限が1であるオプションの1対多の関係の特別なケースです。両側から検討してください。1人のユーザーが複数の顧客を持つことは可能ですか、または1人の顧客が複数のユーザーを持つことは可能でしょうか？その場合は、データを再構築する必要があります。
テーブルにuser-id外部キーを追加するcustomersことは、1対多（上限1）の関係を正しくマップし、null許容フィールドを回避するため、より良い選択と考えることができます。上限を強制するには、外部キーインデックスが一意である必要があります。これは、主キーがの場合に自動的に発生しますuser-id。
customer-idオプションの外部キーとしてをusersテーブルに追加すると、関係の上限が1に強制されますが、依存関係は逆になります。
もう少し複雑ですが柔軟なアプローチを検討しましたか？親テーブルは "person"（または、どのくらい複雑にしたいかによって "entity"）です。次に、customerテーブルとuserテーブルにはそれぞれpersonテーブルへのFKがあります。personテーブルには個人の詳細が含まれ、customerテーブルとuserテーブルにはユーザーまたは顧客に関連付けられた属性のみが含まれます。多くの場合、アドレス（電子メールと普通郵便）、電話番号なども、多対多の状況を可能にするために、マッピングテーブルを含む個別のテーブルで表されます。これは、多くの参照サイトで見つけることができる比較的一般的なモデルです。