Anda mungkin ingin mempertimbangkan model data Type/SubType. Ini sangat mirip dengan kelas/subkelas dalam pemrograman berorientasi objek, tetapi jauh lebih canggung untuk diterapkan, dan tidak ada RDBMS (yang saya ketahui) mendukungnya secara asli. Ide umumnya adalah:
- Anda menentukan Tipe (Bangunan), buat tabel untuknya, berikan kunci utama
- Anda mendefinisikan dua atau lebih sub-tipe (di sini, Rumah Sakit, Klinik, Sekolah, Universitas), membuat tabel untuk masing-masing subtipe, membuat kunci utama… tetapi kunci utama juga merupakan kunci asing yang mereferensikan tabel Bangunan
- Tabel Anda dengan satu kolom “ObjectType” sekarang dapat dibuat dengan kunci asing ke tabel Bangunan. Anda harus menggabungkan beberapa tabel untuk menentukan jenis bangunannya, tetapi Anda tetap harus melakukannya. Itu, atau menyimpan data yang berlebihan.
Anda telah memperhatikan masalah dengan model ini, bukan? Apa yang mencegah Bangunan memiliki entri di dua atau lebih tabel subtipe? Senang Anda bertanya:
- Tambahkan kolom, mungkin “Tipe Bangunan”, ke Bangunan, misalnya char(1) dengan nilai {H, C, S, U} yang diizinkan yang menunjukkan (duh) jenis bangunan.
- Buat batasan unik pada BuildingID + BuildingType
- Memiliki kolom BulidingType di subtabel. Beri batasan centang di atasnya sehingga hanya dapat disetel ke nilai (H untuk tabel Rumah Sakit, dll.) Secara teori, ini bisa berupa kolom yang dihitung; dalam praktiknya, ini tidak akan berhasil karena langkah berikut:
- Buat kunci asing untuk menghubungkan tabel menggunakan kedua kolom
Voila:Diberikan set baris BUILDING dengan tipe H, entri dalam tabel SCHOOL (dengan tipe S) tidak dapat disetel untuk mereferensikan Gedung tersebut
Anda akan ingat bahwa saya pernah mengatakan bahwa penerapannya sulit.
Sebenarnya, pertanyaan besarnya adalah:Apakah ini layak dilakukan? Jika masuk akal untuk menerapkan empat (atau lebih, seiring berjalannya waktu) tipe bangunan sebagai tipe/subtipe (keuntungan normalisasi lebih lanjut:satu tempat untuk alamat dan atribut lain yang umum untuk setiap bangunan, dengan atribut khusus bangunan yang disimpan dalam subtabel), mungkin sepadan dengan upaya ekstra untuk membangun dan memelihara. Jika tidak, maka Anda kembali ke titik awal:model logis yang sulit diterapkan di rata-rata RDBMS modern.
