Mengapa banyak desain mengabaikan normalisasi dalam RDBMS?


23

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?


7
karena DB yang dinormalisasi membutuhkan banyak penggabungan bahkan pada pertanyaan yang paling sepele
ratchet freak

1
mereka bergabung masih perlu terjadi bahkan disembunyikan oleh pandangan
ratchet freak

29
Banyak programmer tidak tahu dasar-dasar model relasional.
mike30

10
"Normalisasi sampai sakit, denormalkan sampai berfungsi". codinghorror.com/blog/2008/07/… memiliki beberapa jawaban yang bagus.
Matthew Steeples

3
Mereka mengabaikannya karena mereka tidak perlu menjawab DBA, analis BI, atau auditor keamanan.
Aaronaught

Jawaban:


19

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.


1
Anda harus menyalin-menempel ini ke artikel blog ... ini GOLD.
Marcel Popescu

15

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" .


7
Hai Yosi, saya mengerti maksud Anda. Normalisasi sangat mendasar dalam memahami teori database relasional dan memiliki aplikasi nyata dalam praktiknya, sehingga tidak mengherankan bahwa ini adalah topik besar dalam kursus. Insinyur yang baik harus memahaminya dan memahami kapan harus diterapkan. Hal yang tampaknya tidak tercakup dalam pekerjaan lapangan adalah bahwa denormalisasi selektif dapat menghasilkan banyak manfaat dan beberapa masalah benar-benar tidak cocok untuk model normal.
DemetriKots

1
Bagaimana dengan konsistensi data? Misalnya jika Anda memiliki nama toko di setiap detail penjualan, maka Anda dapat berpotensi memiliki deskripsi yang berbeda, sedangkan jika data dinormalisasi, nama toko hanya muncul satu (di tabel toko) dan tidak ada tempat untuk inkonsistensi.
Tulains Córdova

1
Saya setuju. Saya pikir normalisasi sering digunakan oleh DBA yang telah diajarkan bahwa ini adalah desain terbaik. Saya selalu menyarankan bahwa DBA dapat menormalkan tabel di ETL semua yang mereka inginkan, tetapi ketika datang ke tabel referensi UI, saya perlu tabel yang mudah untuk query tanpa bergabung berlebihan. Saya telah mengalami tabel yang terlalu dinormalisasi, sehingga hampir tidak bisa memecahkan masalah pengguna tanpa menghabiskan pemecahan masalah HOURs.
L_7337

1
Au contraire, analytics sangat sulit jika Anda tidak dapat memulai dari model yang dinormalisasi. Saya hanya harus melalui latihan ini, dan itu adalah neraka. Pengembang aplikasi tidak boleh berasumsi bahwa skema denormalized akan cocok untuk kebutuhan analitik. Dan untuk poin # 3 melawan normalisasi, itu adalah masalah yang hampir dipecahkan oleh pandangan terwujud / terindeks.
Aaronaught

1
Dan # 2 kedengarannya masuk akal tetapi menegangkan kredibilitas dalam praktik - Saya tidak ingat pernah melihat satu contoh pun dalam 10+ tahun saya di mana kendala sebenarnya ditegakkan secara menyeluruh oleh aplikasi. Lebih sering, pengembang salah menyamakan aturan bisnis dengan integritas data atau menggunakan fakta bahwa ORM secara teoritis dapat menegakkan kendala relasional sebagai alasan untuk tidak melakukannya di mana pun. Mungkin saya hanya bersikap sinis, tetapi semua pengalaman karier saya telah mengajarkan saya bahwa pernyataan seperti "aplikasi akan menegakkan integritas data" adalah tanda bahaya yang sangat besar.
Aaronaught

11
  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.


Saya akan menambahkan ini bahwa kadang-kadang relasional sebenarnya bukan desain yang benar untuk database; misalnya, direktori LDAP bersifat hierarkis, beberapa tipe lain mungkin lebih baik dilayani oleh desain datar.
Maximus Minimus

1
Sejauh poin # 4, saya akan mengatakan bahwa database relasional kurang populer dan mulai diganti untuk varietas nosql, dan itu sebenarnya adalah hal yang hebat banyak waktu. Tapi saya tidak melihat banyak penggerak dan pengocok yang menyatukan model data non-relasional menggunakan RDBMS. Itu hanya bodoh.
Aaronaught

@ joshp - Terima kasih, ringkasan yang bagus. poin # 3 adalah yang saya pribadi lebih tertarik. Mengapa faktor lain "mengalahkan" kebutuhan normalisasi.
Yosi Dahari

@ JimmyShelter, saya setuju. Selain mode, relasional tidak selalu menjadi pilihan terbaik.
joshp

4
@Yosi - Alasan beberapa faktor dapat melampaui normalisasi adalah bahwa normalisasi adalah teknik untuk menghindari masalah konsistensi data umum ketika data dimasukkan, diperbarui, dan dihapus. Jika data ditulis sekali dan kemudian hanya membaca setelah itu maka C, U, dan D dari CRUD tidak penting lagi. Dalam kasus seperti itu, manfaat normalisasi pada dasarnya tidak ada artinya sehingga tekanan lain yang bersaing dapat diutamakan, seperti kinerja baca atau kesederhanaan kueri.
Joel Brown

9

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.


Bisakah Anda menyarankan kualitas desain database (tidak hanya skema, tetapi juga prosedur) dokumen / artikel?
Tilak

"Memiliki banyak kolom pada satu tabel tidak bertentangan dengan normalisasi" -Tentu niat saya adalah #incailments. Dalam pertanyaan yang saya sebutkan # kolom hanya untuk kesederhanaan, asumsi saya adalah bahwa pembaca akan memahami korelasi dan maksud saya
Yosi Dahari

@Tilak, saya tidak yakin apakah ada referensi khusus untuk mendapatkan pedoman terbaik dari tetapi Anda dapat mengumpulkan daftar Anda dari pemodelan data dan literatur desain database. Maaf jika ini tidak menjawab pertanyaan Anda. Saya pikir ini bisa menjadi subjek yang bagus untuk sebuah buku.
NoChance
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.