Kapan sebaiknya Anda mendenormalisasi?

Saya pikir kita semua akrab dengan normalisasi basis data .

Pertanyaan saya adalah: Apa saja panduan yang Anda gunakan saat Anda ingin mendenormalisasi tabel?

Denormalkan ketika itu operasi OLAP, normalkan saat OLTP (dari artikel yang ditautkan di bawah bagian Denormalization)

Database yang dimaksudkan untuk pemrosesan transaksi online (OLTP) biasanya lebih dinormalisasi daripada database yang dimaksudkan untuk pemrosesan analitik online (OLAP). Aplikasi OLTP dicirikan oleh volume tinggi transaksi kecil seperti memperbarui catatan penjualan di kasir supermarket. Harapannya adalah bahwa setiap transaksi akan meninggalkan database dalam keadaan yang konsisten. Sebaliknya, basis data yang dimaksudkan untuk operasi OLAP terutama adalah basis data "baca kebanyakan". Aplikasi OLAP cenderung mengekstraksi data historis yang telah terakumulasi dalam periode waktu yang lama. Untuk database seperti itu, data yang redundan atau "didenormalkan" dapat memfasilitasi aplikasi intelijen bisnis. Secara khusus, tabel dimensi dalam skema bintang sering berisi data yang dinormalisasi. Data yang didenormalkan atau redundan harus dikontrol dengan hati-hati selama proses ekstraksi, transformasi, pemuatan (ETL), dan pengguna tidak boleh diizinkan untuk melihat data sampai dalam kondisi yang konsisten. Alternatif yang dinormalisasi untuk skema bintang adalah skema kepingan salju. Dalam banyak kasus, kebutuhan untuk denormalisasi telah berkurang ketika komputer dan perangkat lunak RDBMS telah menjadi lebih kuat, tetapi karena volume data secara umum meningkat seiring dengan kinerja perangkat keras dan perangkat lunak, basis data OLAP sering masih menggunakan skema denormalized.

Denormalisasi juga digunakan untuk meningkatkan kinerja pada komputer yang lebih kecil seperti pada mesin kasir dan perangkat seluler yang terkomputerisasi, karena ini dapat menggunakan data hanya untuk pencarian saja (mis. Pencarian harga). Denormalisasi juga dapat digunakan ketika tidak ada RDBMS untuk platform (seperti Palm), atau tidak ada perubahan yang harus dilakukan pada data dan respons cepat sangat penting.

Normalisasi sampai sakit, denormalkan sampai berfungsi (mis .: kinerja menjadi dapat diterima) :)

Salah satu alasan yang berpotensi masuk akal untuk menerapkan denasionalisasi yang terkendali adalah jika hal itu memungkinkan Anda untuk menerapkan beberapa batasan integritas pada data yang tidak mungkin dilakukan. Sebagian besar DBMS SQL memiliki dukungan yang sangat terbatas untuk kendala multi-tabel. Dalam SQL kadang-kadang satu-satunya cara efektif untuk mengimplementasikan batasan tertentu adalah untuk memastikan bahwa atribut yang terlibat dalam kendala semuanya ada dalam tabel yang sama - bahkan ketika normalisasi akan menentukan bahwa mereka termasuk dalam tabel yang terpisah.

Denormalisasi yang terkendali berarti mekanisme diterapkan untuk memastikan bahwa ketidakkonsistenan tidak dapat muncul karena data yang berlebihan. Biaya dari kontrol tambahan ini dan risiko data yang tidak konsisten perlu dipertimbangkan ketika memutuskan apakah denormalisasi bermanfaat.

Alasan umum lain untuk denormalisasi adalah untuk mengizinkan beberapa perubahan dalam struktur penyimpanan atau mengizinkan beberapa optimasi fisik lain yang tidak diizinkan oleh DBMS. Menurut prinsip Kemandirian Data Fisik, DBMS harus memiliki sarana untuk mengonfigurasi struktur penyimpanan internal tanpa perlu mengubah representasi logis data dalam database. Sayangnya banyak DBMS sangat membatasi pilihan implementasi fisik yang tersedia untuk setiap skema database yang diberikan. Mereka cenderung kompromi independensi database fisik dengan hanya mendukung implementasi sub-optimal dari model logis yang diinginkan.

Seharusnya jelas tetapi masih perlu dikatakan: dalam semua kasus hanya perubahan dalam fitur implementasi fisik yang dapat menentukan kinerja - fitur seperti struktur data internal, file, pengindeksan, perangkat keras dan sebagainya. Normalisasi dan denormalisasi tidak ada hubungannya dengan optimalisasi kinerja atau penyimpanan.

Denormalize jika Anda sering mengakses data dihitung, seperti yang disarankan dalam jawaban atas pertanyaan ini . Biaya penyimpanan dan pemeliharaan data yang dikomputasi akan sering lebih kecil dari biaya komputasi ulang berulang-ulang jika profil beban Anda baca-berat.

Saya secara rutin mendenormalisasi sehingga saya dapat menegakkan integritas data dengan kendala. Salah satu contoh adalah pertanyaan terbaru di situs ini - saya mereplikasi kolom di tabel lain, sehingga saya bisa menggunakan PERIKSA kendala untuk membandingkannya dengan kolom lain. Contoh lain dari teknik ini adalah posting blog saya .

Anda tidak dapat menggunakan kendala PERIKSA untuk membandingkan kolom dalam baris yang berbeda atau dalam tabel yang berbeda, kecuali jika Anda membungkus fungsi tersebut dalam skalar UDF yang dipanggil dari kendala CHECK. Bagaimana jika Anda benar-benar perlu membandingkan kolom di baris yang berbeda atau di tabel yang berbeda untuk menegakkan aturan bisnis? Misalnya, anggap Anda tahu jam kerja dokter, dan Anda ingin memastikan bahwa semua janji temu sesuai jam kerja? Tentu saja, Anda dapat menggunakan pemicu atau prosedur tersimpan untuk menerapkan aturan bisnis ini, tetapi pemicu atau prosedur tersimpan tidak dapat memberi Anda 100% jaminan bahwa semua data Anda bersih - seseorang dapat menonaktifkan atau menjatuhkan pemicu Anda, memasukkan beberapa data kotor, dan aktifkan kembali atau buat kembali pemicu Anda. Juga seseorang dapat langsung memodifikasi tabel Anda dengan melewati prosedur yang tersimpan.

Izinkan saya menunjukkan cara menerapkan aturan bisnis ini hanya dengan menggunakan batasan FK dan PERIKSA - yang akan menjamin bahwa semua data memenuhi aturan bisnis selama semua kendala dipercaya.

Namun contoh lain adalah cara untuk menegakkan bahwa periode waktu tidak memiliki celah dan tidak ada tumpang tindih .