Buku Craig Larman "Menerapkan UML dengan Pola" menjelaskan 3 solusi umum untuk masalah ini.
Contoh Anda tidak terlalu membantu - tidak ada alasan logis untuk memiliki 3 cara berbeda dalam mengelola nama seseorang di database Anda (meskipun ini sering terjadi karena keanehan impor/ekspor data).
Namun, sangat umum ada entitas "orang" yang mungkin merupakan karyawan (dengan employee_id), kontak (dengan tautan ke tabel prospek), atau pelanggan (dengan customer_id dan tautan ke tabel pesanan) .
Dalam buku Larman, ia memberikan 3 solusi.
Satu meja untuk mengatur semuanya Di sini, Anda membuat satu tabel dengan semua kolom yang diketahui. Ini menciptakan tabel yang berantakan, dan mendorong tanggung jawab untuk mengetahui aturan untuk mempertahankan setiap subkelas ke lapisan aplikasi - database tidak akan memaksakan kebutuhan pelanggan untuk memiliki customer_id. Namun, ini membuat penggabungan menjadi lebih mudah - tabel apa pun yang perlu ditautkan ke seseorang dapat, yah, menautkan ke tabel orang.
Tabel kelas super Ini membersihkan semuanya dengan mengekstraksi atribut umum ke dalam satu tabel - mis. "person" - dan mendorong bidang khusus subkelas ke tabel subkelas. Jadi, Anda mungkin memiliki "orang" sebagai tabel kelas super, dan tabel "kontak", "karyawan" dan "pelanggan" dengan data subkelas tertentu. Tabel subclass memiliki kolom "person_id" untuk ditautkan kembali ke tabel superclass. Ini lebih kompleks - biasanya memerlukan gabungan tambahan saat mengambil data - tetapi juga jauh lebih sedikit rawan kesalahan - Anda tidak dapat secara tidak sengaja merusak model data dengan bug yang menulis atribut tidak valid untuk "karyawan".
Tabel per subkelas - ini adalah apa yang telah Anda jelaskan. Ini memperkenalkan cukup banyak duplikasi ke dalam model data, dan Anda sering memiliki gabungan bersyarat - "bergabung di tabel x jika tipe orang =y", yang dapat membuat kode akses data menjadi rumit.
