Mengapa banyak desain mengabaikan normalisasi dalam RDBMS?

Saya melihat banyak desain yang normalisasi bukan pertimbangan pertama dalam fase pengambilan keputusan.

Dalam banyak kasus, desain tersebut mencakup lebih dari 30 kolom, dan pendekatan utamanya adalah "untuk meletakkan semuanya di tempat yang sama"

Menurut apa yang saya ingat normalisasi adalah salah satu yang pertama, hal yang paling penting, jadi mengapa kadang-kadang turun begitu mudah?

Edit:

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?

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:

1. Mengapa tidak beberapa database di alam liar dinormalisasi?
2. Mengapa / ketika harus database normalisasi akan denormalized ?
3. 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.

Asumsi yang dibangun ke dalam pertanyaan dan dalam beberapa jawaban adalah bahwa normalisasi adalah desain database yang baik. Ini sebenarnya sering tidak demikian. Normalisasi adalah salah satu cara untuk mencapai serangkaian tujuan desain dan persyaratan tertentu jika Anda sangat bergantung pada database untuk menegakkan "aturan bisnis" tentang hubungan antar elemen data.

Normalisasi memberi Anda beberapa manfaat utama:

1. Meminimalkan jumlah data yang berlebihan.
2. Memaksimalkan sejauh mana basis data dibangun dalam mekanisme integritas (batasan kunci asing, batasan keunikan) dapat dimanfaatkan untuk memastikan integritas data.
3. Mengurangi jumlah kolom per baris meningkatkan efisiensi IO dalam beberapa kasus. Baris lebar membutuhkan waktu lebih lama untuk mengambil.

Yang mengatakan, ada banyak alasan yang sah untuk melakukan denormalkan:

1. Kinerja, terutama untuk analitik, dapat dilumpuhkan oleh normalisasi. Untuk analisis terhadap database relasional, model dimensi denormalized adalah pendekatan standar.
2. Manfaat menegakkan integritas data di dalam basis data mulai menurun. Karena semakin banyak pengembangan difokuskan pada tingkat menengah yang berorientasi objek yang sering menegakkan aturan bisnis, ketergantungan pada kendala relasional dalam database menjadi kurang penting.
3. Seperti yang disebutkan orang lain, normalisasi akan mempersulit permintaan yang diperlukan untuk mengambil data yang relevan.

Tidak jelas bahwa normalisasi adalah tanda dari desain yang baik. Dalam beberapa kasus, normalisasi adalah artefak dari waktu ketika ruang penyimpanan berada pada premium dan ketika banyak tanggung jawab untuk pengkodean aturan bisnis berada dalam database (pikirkan tentang 2-tier aplikasi client-server dengan sebagian besar atau tidak semua logika bisnis dalam prosedur tersimpan). Mungkin banyak proyek yang beralih dari normalisasi berdasarkan keputusan arsitektur yang baik daripada pemahaman yang buruk tentang prinsip-prinsip desain database.

Artikel oleh Jeff Atwood yang dirujuk dalam komentar di atas memberikan beberapa diskusi terperinci yang bagus - "Mungkin Normalisasi Bukanlah Normal" .

1. Banyak pengembang tidak tahu atau tidak peduli tentang normalisasi, atau tentang pemodelan data atau database.
2. Untuk beberapa pekerjaan itu benar-benar tidak penting.
3. Terkadang ada alasan yang sangat bagus untuk tidak dinormalisasi, misalnya untuk membuat beban kerja sulit tertentu menjadi baik.
4. Konsep Database Relasional baru-baru ini kurang populer dibandingkan pada 1990-an dan 2000-an. Pengembang cenderung dipengaruhi oleh mode, bahkan jika mereka mengaku sangat rasional. Tidak ada gunanya berdebat tentang rasa.

Normalisasi juga, secara historis, adalah wilayah untuk argumen agama yang dekat, jadi saya ragu untuk mengatakan lebih banyak.

Dalam proyek-proyek besar, dan khususnya yang ada di mainframe, ini bukan masalahnya. Bahkan jika Anda mencari situs pekerjaan Anda akan melihat beberapa posisi untuk pemodel data. Juga, memiliki banyak kolom pada satu tabel tidak bertentangan dengan normalisasi. Namun demikian, pengamatan Anda berlaku untuk beberapa proyek.

Perancangan basis data adalah salah satu keterampilan yang dibutuhkan untuk membangun sistem yang berkualitas. Karena itu, beberapa pengembang tidak cukup tahu tentang desain database dan masih ditugaskan untuk tugas pemodelan data dan desain database. Beberapa proyek bahkan melewatkan pemodelan data. Fokus pada banyak proyek terutama pada pengkodean dan desain front-end.

Faktor lain untuk desain database yang buruk adalah kenyataan bahwa Normalisasi bukan topik sepele khususnya ketika datang untuk NF ke-4, NF ke-5, dll. Sebagian besar buku yang saya lihat tidak dapat dengan jelas menjelaskan bentuk-bentuk itu dengan baik. Biasanya ada contoh-contoh buruk dan terlalu banyak teori. Ini membuat topiknya kurang populer dari yang seharusnya.

Kesalahan dalam desain basis data sulit didapat kecuali Anda mencarinya atau Anda menjumpainya selama pengujian. Tidak memiliki standar untuk kualitas desain database memungkinkan kesalahan terjadi lebih mungkin.

Tambahkan ke fakta bahwa beberapa proyek tidak mengikuti metodologi pengembangan yang ketat (yang mempromosikan desain database), sebagai akibatnya, tanggung jawab bercampur dan tugas-tugas hilang antara analis bisnis, pengembang dan DBA. Pengembang berbicara dalam OO dan UML di mana DBA berbicara dalam DD dan beberapa di ERD dan mungkin banyak yang tidak mendapatkan UML atau OO. Singkatnya, kurangnya pengetahuan, kurangnya sumber daya yang jelas dan baik, kurangnya bahasa yang disatukan untuk menggambarkan data dan kurangnya metodologi adalah semua yang harus disalahkan.