Menerapkan hubungan satu ke nol atau satu dalam SQL

Katakanlah saya sedang merancang database untuk skenario di mana ada hubungan satu-ke-nol-atau-satu (1-0..1). Sebagai contoh:

• Ada satu set Pengguna , dan beberapa Pengguna mungkin juga Pelanggan .

Jadi, saya membuat dua tabel yang sesuai, usersdan customers, tapi ...

... Apa cara terbaik untuk mewakili dan mengimplementasikan situasi ini dalam platform SQL yang diberikan? Saya telah mempertimbangkan dua solusi yang mungkin:

1. Dalam userstabel, tambahkan customerkolom yang dapat berupa referensi KUNCI ASING customersatau NULLtanda.

2. Dalam customerstabel, sertakan userkolom (diatur dengan UNIQUEbatasan) yang menunjuk ke userstabel.

Saya sudah mengajukan pertanyaan serupa di beberapa forum, tetapi jawabannya pada dasarnya adalah "apa pun yang Anda butuhkan", "apa pun yang menurut Anda nyaman". Saya tidak suka jawaban seperti ini. Saya ingin sepotong teori DB serius, jawaban yang cukup beralasan. Di mana saya bisa membaca tentang hubungan 1-0..1?

Saya ingin sepotong teori DB yang serius

Teori relasional modern menolak nol , yang tampaknya akan segera membatalkan opsi Anda 1. Namun, pelaku kesalahan ini dapat dihilangkan dengan mengganti nol default dengan nilai default misalnya pelanggan 'dummy' yang dibuat semata-mata untuk secara eksplisit memodelkan "bukan pelanggan" korespondensi.

Saya pikir opsi 2 Anda adalah yang paling teoretis karena, tidak seperti opsi 1 yang dimodifikasi, relasinya dapat berada dalam bentuk normal keenam (6NF), menjadi bentuk normal proyeksi-gabung dan bentuk normal tertinggi yang dapat dicapai.

Saya juga pernah mendengar tentang aturan desain praktis yang menyatakan bahwa suatu relasi harus memodelkan BAIK suatu entitas ATAU hubungan antar entitas tetapi tidak pernah keduanya, yang tampaknya masuk akal bagi saya. Sekali lagi, ini akan mendukung opsi 2. Namun, saya mendengar aturan praktis ini bertahun-tahun yang lalu, tidak ingat di mana dan tidak dapat menawarkan dasar teoritis yang serius (selain 6NF seperti yang disebutkan di atas).

Anda telah diberi jawaban yang benar sebagian. Jawaban sebenarnya datang dari model data Anda dan bagaimana itu dinormalisasi. Kuncinya adalah bagaimana Anda sampai ke hubungan:

• The customersmeja terdiri dari sejumlah bidang dipertimbangkan untuk userstabel yang termasuk ke dalam konsep pelanggan, dan nol kecuali pengguna juga pelanggan (sub-jenis pengguna). Dalam hal ini customerstabel mewarisi kunci utama dari userstabel. (Dimungkinkan untuk beberapa sub-tipe yang mungkin tumpang tindih atau tidak.)

• The customersmeja terdiri dari sejumlah bidang yang berkaitan dengan konsep pelanggan, tetapi belum tentu konsep pengguna. Pelanggan adalah tabel yang kuat dan tidak tergantung pada konsep pengguna. (Menghapus userstabel tidak akan berdampak signifikan terhadap desain tabel pelanggan.) Dalam hal ini tabel pelanggan mendapatkan kunci utama sendiri.

Apa yang Anda miliki adalah kasus khusus hubungan opsional ke banyak di mana batas atas adalah 1. Pertimbangkan dari kedua sisi: Apakah mungkin bagi satu pengguna untuk memiliki banyak pelanggan, atau satu pelanggan untuk memiliki banyak pengguna? Jika demikian, Anda perlu merombak data Anda.

Menambahkan user-idkunci asing ke customerstabel dapat dianggap sebagai pilihan yang lebih baik karena memetakan hubungan satu ke banyak (batas 1) dengan benar dan menghindari bidang yang dapat dibatalkan. Untuk menegakkan batas atas indeks kunci asing harus unik. Ini akan terjadi secara otomatis jika kunci utama adalah user-id.

Menambahkan customer-idsebagai kunci asing opsional ke userstabel memberlakukan batas atas 1 dalam hubungan tetapi membalikkan ketergantungan.

Sudahkah Anda mempertimbangkan pendekatan yang sedikit lebih rumit namun fleksibel. Tabel induk adalah "orang" (atau "entitas" tergantung pada seberapa kompleks Anda ingin menjadi). Kemudian tabel pelanggan dan tabel pengguna masing-masing memiliki FK ke tabel orang. Tabel orang berisi detail pribadi sementara tabel pelanggan dan pengguna hanya berisi atribut yang dikaitkan dengan pengguna atau pelanggan. Seringkali alamat (email dan surat siput), nomor telepon, dll. Juga disajikan dalam tabel terpisah dengan tabel pemetaan untuk memungkinkan banyak situasi. Ini adalah model yang relatif umum yang dapat Anda temukan di sejumlah situs referensi.