it-swarm.asia

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?

47
Richard

Dinormalisasi ketika itu OLAP operasi, normalkan ketika 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). OLTP aplikasi ditandai 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 ditujukan untuk OLAP operasi terutama adalah basis data "baca sebagian besar". OLAP aplikasi cenderung mengekstraksi data historis yang telah terakumulasi dalam periode waktu yang lama. Untuk itu database, data redundan atau "didenormalkan" dapat memfasilitasi aplikasi intelijen bisnis. Secara khusus, tabel dimensi dalam skema bintang sering berisi data yang didenormalisasi. Data yang didenormalisasi atau redundan harus dikontrol secara hati-hati selama pemrosesan ekstrak, transformasi, pemuatan (ETL), dan pengguna harus tidak diizinkan untuk melihat data sampai dalam kondisi yang konsisten. Alternatif yang dinormalisasi untuk skema bintang adalah skema kepingan salju. Dalam banyak kasus, kebutuhan untuk denormalization telah berkurang ketika komputer dan perangkat lunak RDBMS telah menjadi e lebih kuat, tetapi karena volume data umumnya meningkat seiring dengan kinerja perangkat keras dan perangkat lunak, OLAP database 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 dilakukan pada data dan respon Swift sangat penting.

35
billinkc

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

25
Andrei Rînea

Salah satu alasan yang berpotensi masuk akal untuk diterapkan dikontrol denormalisasi 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-batasan tertentu adalah untuk memastikan bahwa atribut-atribut yang terlibat dalam kendala semuanya ada dalam tabel yang sama - bahkan ketika normalisasi akan menentukan bahwa mereka termasuk dalam tabel terpisah.

Terkendali denormalisasi berarti mekanisme diterapkan untuk memastikan bahwa inkonsistensi 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 Data Fisik Kemandirian a DBMS harus memiliki sarana untuk mengkonfigurasi struktur penyimpanan internal tanpa perlu mengubah representasi logis dari data dalam database. Sayangnya banyak DBMS sangat membatasi pilihan implementasi fisik yang tersedia untuk setiap skema database yang diberikan. Mereka cenderung membahayakan independensi basis data 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.

15
nvogel

Denormalkan jika Anda sering mengakses data yang dihitung, seperti yang disarankan dalam jawaban pertanyaan ini . Biaya menyimpan dan memelihara data yang dikomputasi sering kali akan lebih kecil dari biaya komputasi ulang berulang-ulang jika profil beban Anda berat.

4
Nick Chammas

Saya secara rutin mendenormalisasi sehingga saya dapat menegakkan integritas data dengan kendala. Salah satu contohnya 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 cocok dengan 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. Bagaimanapun Anda dapat berakhir dengan data yang melanggar aturan bisnis Anda tanpa mengetahuinya.

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

Contoh lain adalah cara untuk memastikan bahwa periode waktu tidak memiliki celah dan tidak ada tumpang tindih .

3
A-K