Apakah praktik yang buruk untuk memiliki beberapa hubungan satu-ke-satu yang saling eksklusif?

Katakanlah, meja carmemiliki hubungan satu-ke-satu ke meja electric_car, gas_cardan hybrid_car. Jika caradalah electric_car, tidak bisa lagi muncul dalam gas_caratau hybrid_car, dll

Apakah ada yang salah dengan desain seperti itu? Beberapa masalah yang mungkin terjadi di ujung jalan?

Berbagai jenis mobil adalah contoh masalah umum yang muncul berulang kali dalam pemodelan data. Ini disebut "generalisasi / spesialisasi" dalam pemodelan ER, dan "superclass / subclass" dalam pemodelan objek.

Pemodel objek menggunakan fitur warisan yang dibangun ke dalam model objek untuk menyelesaikan masalah dengan cukup mudah. Subclass hanya memperpanjang superclass.

Pemodel relasional dihadapkan pada suatu masalah. bagaimana cara mendesain tabel agar bisa meniru manfaat yang akan didapat dari warisan?

Teknik paling sederhana disebut pewarisan tabel tunggal . Data tentang semua jenis mobil dikelompokkan ke dalam satu tabel untuk mobil. Ada kolom, car_type, yang mengelompokkan semua mobil dari satu tipe. Tidak ada mobil yang dapat dimiliki lebih dari satu jenis. Jika kolom tidak relevan dengan, katakanlah, mobil listrik, kolom NULL akan ditinggalkan di baris yang berkaitan dengan mobil listrik.

Solusi sederhana ini bekerja dengan baik untuk kasus yang lebih kecil dan sederhana. Kehadiran banyak NULLs menambahkan sedikit ke overhead penyimpanan, dan sedikit untuk mengambil overhead. Pengembang mungkin harus belajar logika tiga nilai SQL jika tes boolean dilakukan pada kolom nullable. Ini bisa membingungkan pada awalnya, tetapi orang terbiasa dengannya.

Ada teknik lain, yang disebut pewarisan tabel kelas . Dalam desain ini, ada tabel terpisah untuk gas_car, electric_car, dan hybrid_car, selain tabel gabungan, mobil, untuk semuanya. Saat Anda menginginkan semua data tentang jenis mobil tertentu, Anda bergabung dengan tabel mobil dengan tabel khusus yang sesuai. Ada lebih sedikit NULL dalam desain ini, tetapi Anda lebih banyak bergabung. Teknik ini bekerja lebih baik dalam kasus yang lebih besar dan lebih kompleks.

Ada teknik ketiga yang disebut kunci primer bersama. Teknik ini sering digunakan bersamaan dengan pewarisan tabel kelas. Tabel khusus untuk subclass memiliki, sebagai kunci utama, salinan kunci utama dari entri yang sesuai dalam tabel mobil. Kolom id ini dapat dideklarasikan sebagai kunci primer dan kunci asing.

Ini melibatkan sedikit pemrograman tambahan ketika mobil baru akan ditambahkan, tetapi itu membuat sambungannya sederhana, mudah, dan cepat.

Superclasses dan subclass terjadi setiap saat di dunia nyata. Jangan takut. Tetapi lakukan uji desain awal Anda untuk kinerja. Jika upaya pertama Anda sederhana dan sehat, Anda dapat mengubahnya untuk mempercepatnya.

Tidak ada yang salah dengan memiliki sub-tipe entitas dalam model Anda sebanyak yang diperlukan untuk mencerminkan realitas data yang Anda coba modelkan. Pertanyaannya bukan apakah sub-tipe adalah praktik yang buruk. Masalahnya mungkin apakah itu model yang bagus ?

Misalnya, di bawah contoh Anda, apa yang Anda lakukan dengan sesuatu seperti Audi A4 eTron - yang merupakan plug-in hybrid? Apakah itu "mobil listrik" atau apakah itu "mobil hibrida"?

Pertanyaan lain yang harus Anda tanyakan pada diri sendiri adalah mengapa Anda mengetik sama sekali? Berapa banyak predikat berbeda yang Anda miliki di sub-tipe Anda? Apakah ada dari predikat ini dibagi di antara sub-tipe? Situasi bisa menjadi rumit.

Sub-pengetikan tidak digunakan dalam desain basis data untuk klasifikasi. Anda dapat melakukan klasifikasi dengan kode, kunci asing ke tabel kode, atau dengan bendera. Sub-pengetikan digunakan untuk memodelkan set predikat berbeda untuk berbagai jenis hal yang menarik. Jika Anda menggunakan sub-tipe hanya untuk klasifikasi maka itu praktik yang buruk.

Jika sub-tipe Anda memodelkan set predikat berbeda dengan jelas dan tidak ambigu untuk hal-hal yang dipedulikan oleh database Anda, maka ini adalah praktik yang sangat baik, terlepas dari berapa banyak sub-tipe yang Anda butuhkan.