Yang menarik dari utas T&J ini adalah sebenarnya ada 3 pertanyaan. Semua orang telah menjawab yang berbeda, dan hampir tidak ada yang menjawab yang pertama:
- Mengapa tidak beberapa database di alam liar dinormalisasi?
- Mengapa / ketika harus database normalisasi akan denormalized ?
- Dalam situasi apa pertama-tama berbahaya atau tidak perlu dinormalisasi?
Lansiran pembaca akan mencatat bahwa ini adalah pertanyaan yang sangat berbeda, dan saya akan mencoba menjawab masing-masing secara terpisah sambil menghindari terlalu banyak detail. Dengan "terlalu banyak", maksud saya bahwa saya tidak berpikir ini adalah konteks yang tepat untuk melakukan debat panjang tentang manfaat berbagai argumen yang mendukung atau menentang normalisasi; Saya hanya akan menjelaskan apa argumen itu, mungkin daftar beberapa peringatan, dan simpan filosofi untuk pertanyaan yang lebih spesifik, jika mereka pernah muncul.
Juga, dalam jawaban ini saya mengasumsikan bahwa "normalisasi" menyiratkan "BCNF, 3NF, atau setidaknya 2NF" , karena itulah tingkat normalisasi yang umumnya ingin dicapai oleh desainer. Lebih jarang melihat desain 4NF atau 5NF; meskipun mereka jelas bukan tujuan yang mustahil, mereka lebih mementingkan diri sendiri dengan semantik hubungan daripada hanya representasi mereka , yang membutuhkan lebih banyak pengetahuan tentang domain.
Jadi, maju dan naik:
1. Mengapa beberapa basis data di alam liar tidak dinormalisasi?
Jawaban untuk ini bisa "karena mereka tidak boleh", tetapi membuat asumsi langsung dari kelelawar adalah pekerjaan detektif yang sangat buruk. Kami tidak akan membuat banyak kemajuan sebagai masyarakat jika kami selalu beroperasi dengan asumsi bahwa apa pun itu, seharusnya.
Alasan sebenarnya bahwa database tidak menjadi normal pada awalnya lebih rumit. Inilah 5 teratas yang saya temui:
Pengembang yang mendesainnya tidak tahu atau tidak mengerti cara menormalkan. Bukti kuat dari ini datang dalam bentuk banyak pilihan desain buruk lain yang menyertainya, seperti menggunakan kolom varchar untuk semuanya atau memiliki kekacauan spaghetti dari nama tabel dan kolom yang tidak berarti . Dan saya yakinkan Anda, saya telah melihat database "nyata" yang sama buruknya dengan yang ada di artikel TDWTF.
Pengembang yang mendesainnya tidak peduli atau secara aktif menentang normalisasi prinsip . Catatan, di sini saya tidak berbicara tentang contoh-contoh di mana keputusan yang disengaja dibuat tidak untuk dinormalisasi berdasarkan analisis kontekstual, melainkan tim atau perusahaan di mana normalisasi lebih atau kurang dipahami tetapi hanya diabaikan atau dijauhi kebiasaan. Sekali lagi, sangat umum.
Perangkat lunak ini / dilakukan sebagai proyek Brownfield . Banyak puritan mengabaikan bisnis yang sangat sah ini daripada alasan teknis untuk tidak normal. Kadang-kadang Anda tidak benar-benar bisa merancang database baru dari awal, Anda harus beralih ke skema warisan yang ada, dan berusaha untuk menormalkan pada saat itu akan melibatkan terlalu banyak rasa sakit. 3NF tidak ditemukan sampai tahun 1971, dan beberapa sistem - terutama sistem keuangan / akuntansi - berakar lebih jauh dari itu!
Basis data pada awalnya dinormalisasi , tetapi akumulasi perubahan kecil selama periode waktu yang lama dan / atau tim yang didistribusikan secara luas memperkenalkan bentuk duplikasi halus dan pelanggaran lain dari bentuk normal apa pun yang awalnya ada. Dengan kata lain, hilangnya normalisasi itu tidak disengaja , dan terlalu sedikit waktu yang dihabiskan untuk refactoring.
Keputusan bisnis yang disengaja dibuat untuk tidak menghabiskan waktu pada analisis bisnis atau desain database dan hanya "menyelesaikannya". Ini sering merupakan ekonomi palsu dan akhirnya menjadi bentuk meningkatnya hutang teknis , tetapi kadang-kadang merupakan keputusan yang rasional, setidaknya berdasarkan informasi yang diketahui pada saat itu - misalnya, basis data mungkin dimaksudkan sebagai prototipe tetapi akhirnya dipromosikan menjadi penggunaan produksi karena kendala waktu atau perubahan dalam lingkungan bisnis.
2. Mengapa / kapan seharusnya suatu database yang dinormalisasi dinormalisasi?
Diskusi ini sering muncul ketika database yang dinormalisasi untuk memulai dengan. Entah kinerjanya buruk atau ada banyak duplikasi dalam kueri (bergabung), dan tim merasa, benar atau salah, bahwa mereka sudah sejauh yang mereka bisa dengan desain saat ini. Penting untuk dicatat bahwa normalisasi meningkatkan kinerja sebagian besar waktu, dan ada beberapa opsi untuk menghilangkan kelebihan bergabung ketika normalisasi tampaknya bekerja melawan Anda, banyak di antaranya kurang invasif dan berisiko daripada hanya mengubah ke model yang didenormalkan:
Buat tampilan yang diindeks yang merangkum area masalah yang paling umum. DBMS modern mampu membuatnya dapat dimasukkan atau diupdate (misalnya INSTEAD OFpemicu SQL Server ). Ini memerlukan sedikit biaya untuk pernyataan DML pada tabel / indeks yang mendasarinya tetapi umumnya merupakan opsi pertama yang harus Anda coba karena hampir tidak mungkin untuk gagal dan hampir tidak ada biaya untuk mempertahankannya. Tentu saja, tidak setiap kueri dapat diubah menjadi tampilan yang diindeks - kueri agregat adalah yang paling menyusahkan. Yang membawa kita ke item berikutnya ...
Membuat tabel agregat terdenormalkan yang secara otomatis diperbarui oleh pemicu. Tabel ini ada di samping tabel yang dinormalisasi dan membentuk semacam model CQRS . Model CQRS lain, yang lebih populer akhir-akhir ini, adalah menggunakan pub / sub untuk memperbarui model kueri, yang memberikan manfaat asinkron, meskipun itu mungkin tidak cocok dalam kasus yang sangat jarang terjadi di mana data tidak dapat basi.
Terkadang, tampilan yang diindeks tidak dimungkinkan, tingkat transaksi dan volume data terlalu tinggi untuk mengakui pemicu dengan kinerja yang dapat diterima, dan kueri harus selalu mengembalikan data waktu nyata. Situasi ini jarang terjadi - saya akan menebak bahwa mereka mungkin berlaku untuk hal-hal seperti Perdagangan Frekuensi Tinggi atau database penegakan hukum / intelijen - tetapi mereka bisa ada. Dalam kasus ini, Anda benar-benar tidak memiliki pilihan selain untuk mendenormalkan tabel asli.
3. Dalam situasi apa pertama-tama berbahaya atau tidak perlu dinormalisasi?
Sebenarnya, ada beberapa contoh bagus di sini:
Jika basis data hanya digunakan untuk pelaporan / analisis. Biasanya ini menyiratkan bahwa ada tambahan , database yang dinormalisasi digunakan untuk OLTP, yang secara berkala disinkronkan ke database analisis melalui ETL atau pesan.
Ketika menerapkan model yang dinormalisasi akan membutuhkan analisis kompleks dari data yang masuk. Contohnya adalah sistem yang perlu menyimpan nomor telepon yang dikumpulkan dari beberapa sistem eksternal atau basis data. Anda dapat mendenormalisasi kode panggilan dan kode area, tetapi Anda harus memperhitungkan semua format yang mungkin berbeda, nomor telepon tidak valid, nomor batil (1-800-GET-STUFF), belum lagi berbagai tempat. Biasanya lebih banyak masalah daripada nilainya, dan nomor telepon biasanya hanya didorong ke satu bidang kecuali Anda memiliki kebutuhan bisnis khusus untuk kode area sendiri.
Ketika basis data relasional ada di sana untuk menyediakan dukungan transaksional untuk basis data tambahan non-relasional. Misalnya, Anda mungkin menggunakan database relasional sebagai antrian pesan, atau untuk melacak status transaksi atau kisah, ketika data primer disimpan di Redis atau MongoDB atau apa pun. Dengan kata lain, data adalah "data kontrol". Biasanya tidak ada gunanya menormalkan data yang sebenarnya bukan data bisnis .
Arsitektur Berorientasi Layanan yang berbagi database fisik. Ini adalah sedikit aneh, tetapi dalam SOA benar, Anda akan sesekali perlu memiliki data fisik digandakan karena layanan tidak diperbolehkan untuk langsung permintaan data masing-masing. Jika mereka terjadi untuk berbagi database fisik yang sama, data akan muncul tidak dinormalisasi - tetapi umumnya, data yang dimiliki oleh masing-masing individu layanan ini masih normal kecuali salah satu faktor yang meringankan lainnya adalah di tempat. Misalnya, layanan Penagihan mungkin memiliki entitas Bill, tetapi layanan Akuntansi perlu menerima dan menyimpan Tanggal dan Jumlah Tagihan untuk memasukkannya dalam pendapatan untuk tahun itu.
Saya yakin ada lebih banyak alasan yang belum saya sebutkan; apa yang saya maksudkan, pada dasarnya, adalah bahwa mereka cukup spesifik dan akan cukup jelas ketika mereka muncul dalam praktik. Database OLAP seharusnya menggunakan skema bintang, SOA seharusnya memiliki duplikasi, dll. Jika Anda bekerja dengan model arsitektur terkenal yang tidak bekerja dengan normalisasi, maka Anda tidak menormalkan; secara umum, model arsitektur lebih diutamakan daripada model data.
Dan untuk menjawab pertanyaan terakhir:
Benarkah arsitek dan pakar yang baik memilih desain yang terdenormalisasi, sedangkan pengembang yang tidak berpengalaman memilih yang sebaliknya? Apa argumen yang menentang memulai desain Anda dengan mempertimbangkan normalisasi?
Tidak, itu BS lengkap dan mengucapkan BS juga ahli yang selalu memilih desain yang dinormalisasi . Para ahli tidak hanya mengikuti mantra. Mereka meneliti, menganalisis, mendiskusikan, mengklarifikasi, dan mengulang, dan kemudian mereka memilih pendekatan apa pun yang paling masuk akal untuk situasi khusus mereka.
Basis data 3NF atau BCNF biasanya merupakan titik awal yang baik untuk analisis karena sudah dicoba dan terbukti berhasil dalam puluhan ribu proyek di seluruh dunia, tetapi sekali lagi, begitu pula C. Itu tidak berarti kita secara otomatis menggunakan C di setiap proyek baru. Situasi dunia nyata mungkin memerlukan beberapa modifikasi pada model atau penggunaan model yang berbeda sama sekali. Anda tidak tahu sampai Anda berada dalam situasi itu.