Daftar Isi:
- Bentuk normal kunci-domain (DK / NF)
- Sebenarnya, database praktis (yang sangat besar, toh) hampir tidak pernah dinormalisasi sampai ke DK / NF. Anda ingin menormalkan database yang Anda rancang sebanyak mungkin, bagaimanapun, untuk menghilangkan kemungkinan korupsi data yang diakibatkan oleh modifikasi anomali.
Video: Fifth Normal Form 5NF 2024
Setelah database SQL berada dalam bentuk normal ketiga, Anda telah menghilangkan sebagian besar, tapi tidak semua, kemungkinan anomali modifikasi. Bentuk normal di luar yang ketiga didefinisikan untuk memadamkan beberapa bug yang tersisa.
Bentuk normal kunci-domain (DK / NF)
Bentuk normal Boyce-Codd (BCNF), bentuk normal keempat (4NF), dan bentuk normal kelima (5NF) adalah contoh formulir tersebut. Setiap bentuk menghilangkan anomali modifikasi yang mungkin namun tidak menjamin pencegahan semua kemungkinan modifikasi anomali. Bentuk normal kunci domain, bagaimanapun, memberikan jaminan semacam itu.
bentuk normal domain-kunci (DK / NF) jika setiap kendala pada relasi adalah konsekuensi logis dari definisi kunci dan domain. Kendala dalam definisi ini adalah peraturan yang cukup tepat sehingga Anda dapat mengevaluasi apakah benar atau tidak. Kunci adalah pengenal unik dari sebuah baris dalam sebuah tabel. A domain adalah kumpulan nilai atribut yang diizinkan.PENJUALAN (Customer_ID, Produk, Harga)
Kunci: Customer_ID
Kendala: Customer_ID menentukan Produk
Produk menentukan Harga
-
Customer_ID harus berupa bilangan bulat > 1000
-
-
Untuk menerapkan Kendala 3 (bahwa Customer_ID harus bilangan bulat lebih besar dari 1000), Anda dapat menentukan domain untuk Customer_ID untuk memasukkan batasan ini. Itu membuat kendala konsekuensi logis dari domain kolom CustomerID. Produk bergantung pada Customer_ID, dan Customer_ID adalah kunci, jadi Anda tidak memiliki masalah dengan Kendala 1, yang merupakan konsekuensi logis dari definisi kunci.
Kendala 2
adalah
masalah. Harga tergantung pada (adalah konsekuensi logis dari) Produk, dan Produk bukanlah kunci. Solusinya adalah membagi tabel PENJUALAN menjadi dua tabel. Satu tabel menggunakan Customer_ID sebagai kunci, dan yang lainnya menggunakan Produk sebagai kunci. Database, selain berada di 3NF, juga ada di DK / NF. Rancang basis data Anda jadi mereka berada di DK / NF jika memungkinkan. Jika Anda bisa melakukannya, menerapkan batasan kunci dan domain menyebabkan semua kendala terpenuhi, dan anomali modifikasi tidak mungkin dilakukan. Jika struktur database dirancang untuk mencegah Anda memasukkannya ke DK / NF, maka Anda harus membuat batasan ke dalam program aplikasi yang menggunakan database. Database itu sendiri tidak menjamin bahwa kendala akan terpenuhi. Bentuk tidak normal
Seperti dalam kehidupan, jadi di database: Terkadang tidak normal terbayar.Anda bisa terbawa dengan normalisasi dan melangkah terlalu jauh. Anda bisa memecah database menjadi begitu banyak tabel sehingga keseluruhannya menjadi berat dan tidak efisien. Performanya bisa anjlok. Seringkali struktur optimal untuk database Anda agak denormalized.
Sebenarnya, database praktis (yang sangat besar, toh) hampir tidak pernah dinormalisasi sampai ke DK / NF. Anda ingin menormalkan database yang Anda rancang sebanyak mungkin, bagaimanapun, untuk menghilangkan kemungkinan korupsi data yang diakibatkan oleh modifikasi anomali.
Setelah Anda menormalkan database sejauh mungkin, buat beberapa retrievals sebagai run kering. Jika kinerjanya tidak memuaskan, periksalah desain Anda untuk melihat apakah denormalization selektif akan memperbaiki kinerja tanpa mengorbankan integritas. Dengan menambahkan redundansi secara hati-hati di lokasi strategis dan hanya menetapkan
cukup, Anda bisa sampai pada database yang efisien dan aman dari anomali.
