Saya menemukan masalah desain database yang keluar dari liga saya, dan guru saya yang masuk DBA tidak aktif.
Intinya, saya punya meja dengan kunci utama berikut (PK untuk singkatnya):
child_id integer
parent_id integer
date datetime
child_id
dan parent_id
kunci asing ke tabel entitas. Tabel "child" itu sendiri juga berisi kunci asing ke tabel "parent", dan lihat, masing-masing child_id
selalu referensi sama parent_id
seperti yang diharapkan oleh tabel di atas. Bahkan, ternyata ada beberapa kode tambahan yang menjaga keduanya tetap sinkron.
Yang membuat pemula normalisasi yang terlalu bersemangat ini mengatakan, "Saya harus menghapus redundansi sebagai gantinya!"
Saya menguraikan sebagai berikut:
Table_1 PK:
child_id integer
date datetime
Table_2 PK:
parent_id integer
date datetime
Table_3: (already exists)
child_id integer PRIMARY KEY
parent_id integer FOREIGN KEY
Dan lihatlah, ketika saya bergabung dengan orang-orang ini secara alami, saya memulihkan tabel aslinya. Pemahaman saya yang membuat 5NF ini.
Namun, sekarang saya menyadari ada aturan bisnis yang tersembunyi.
Biasanya, tanggal yang terkait dengan yang diberikan child_id
harus merupakan bagian dari tanggal yang terkait dengan yang bersangkutan parent_id
. Anda dapat melihat bahwa tabel pertama menegakkan aturan ini.
Dekomposisi saya tidak memberlakukan aturan, karena Anda dapat dengan bebas menambahkan ke Tabel 1 sampai tanggal terlalu besar.
Yang menuntun saya ke sini, dengan pertanyaan-pertanyaan berikut:
Apakah 5NF dekomposisi ini? Meskipun saya akan mengatakan itu memungkinkan anomali penyisipan, tampaknya juga mengikuti contoh Wiki, yang dengan sendirinya mengikuti panduan ini . Ungkapan (penekanan saya) "kita dapat merekonstruksi semua fakta sebenarnya dari bentuk yang dinormalisasi yang terdiri dari tiga jenis catatan yang terpisah" memberi saya jeda khusus, karena tidak peduli berapa banyak sampah yang saya pompakan
Table_1
, gabungan alami masih mengabaikannya.Andaikata saya tidak suka dekomposisi ini (saya tidak). Saya dengan bebas mengakui bahwa solusi praktisnya adalah meninggalkan tabel dan kode sebagaimana adanya. Tetapi, secara teori, apakah ada cara untuk menguraikan dan / atau menambah kendala sehingga saya bisa keluar dari tabel pertama dan mempertahankan aturan bisnis saya?