Pengenalan kepada Normalisasi Pangkalan Data Tiga Borang Normal Pertama

Matlamat normalisasi pangkalan data relasi adalah untuk mencapai dan memperbaiki Integriti data dan elakkan redundansi data Oleh itu, untuk mengelakkan kemungkinan penyisipan, pengemaskinian atau penghapusan. Pangkalan data hubungan dinormalisasi dengan menggunakan siri peraturan yang disebut Borang Normal. Dalam artikel ini kita akan membincangkan tiga bentuk biasa yang pertama.

Dalam tutorial ini anda akan belajar:

• Apakah bentuk biasa yang pertama
• Apakah bentuk normal kedua
• Apakah bentuk normal ketiga

Keperluan perisian dan konvensyen yang digunakan

Bentuk biasa pertama

Katakan kami mempunyai jadual berikut yang kami gunakan untuk menyimpan maklumat mengenai beberapa filem:

+----+--------------------+--------------------+------+ | id | Nama | Genre | tahun | +----+--------------------+--------------------+-- ----+ | 1 | The Exorcist | Seram | 1973 | | 2 | Suspek biasa | Thriller, Neo-Noir | 1995 | | 3 | Star Wars | Space-opera | 1977 | +----+--------------------+--------------------+------+ 

Jadual di atas, tidak memuaskan Borang Normal Pertama, Kenapa? Untuk borang normal pertama yang dipenuhi, setiap lajur jadual mesti mengandungi atom data (tidak dapat dipertahankan). Di barisan kedua jadual kami, yang mengandungi maklumat mengenai filem "suspek biasa", kita dapat melihat bahawa genre Lajur mengandungi data yang bukan atom. Dua genre sebenarnya disenaraikan: Thriller dan neo-noir. Katakan dalam perwakilan kami, kami mahu membenarkan satu filem dikaitkan dengan lebih daripada satu genre; Bagaimana kita menyelesaikan masalah?

Perkara pertama yang masuk ke dalam fikiran adalah untuk menambah baris baru dalam jadual yang sama, mengulangi maklumat mengenai filem itu, dan hanya menentukan satu genre setiap mentah. Idea ini agak mengerikan, kerana kita akan mempunyai banyak data yang berlebihan (kita harus mengulangi maklumat filem yang sama setiap kali kita ingin mengaitkannya dengan genre baru!).

Satu lagi penyelesaian yang lebih baik, adalah untuk menambah lajur baru, jadi mempunyai, sebagai contoh, a genre1 dan genre2 lajur. Walau bagaimanapun, ini akan, antara lain, mewakili had: bagaimana jika filem harus disenaraikan di bawah lebih daripada dua genre?

Cara yang lebih bijak untuk menyelesaikan masalah ini adalah untuk membuat jadual baru yang digunakan untuk menyimpan maklumat genre. Inilah jadual "genre":

+----+-------------+ | id | Nama | +----+-------------+| 1 | Seram | | 2 | Neo-noir | | 3 | Space-opera | | 4 | Thriller | +----+-------------+ 

Sekarang, kerana antara genre dan filem adalah banyak kepada ramai Hubungan (filem boleh dikaitkan dengan beberapa genre, dan genre boleh dikaitkan dengan banyak filem yang berbeza), untuk menyatakannya tanpa redundansi data, kita boleh menggunakan SO
dipanggil Jadual persimpangan:

+----------+----------+ | filem_id | genre_id | +----------+----------+| 1 | 1 | | 2 | 2 | | 2 | 4 | | 3 | 3 | +----------+----------+ 

Jadual persimpangan kami mempunyai satu-satunya tugas untuk menyatakan banyak hubungan antara kedua-dua jadual atau filem entiti dan genre. Ia disusun oleh hanya dua lajur: movie_id dan genre_id. The filem_id lajur mempunyai a kunci asing Kekangan kepada ID lajur filem jadual, dan genre_id mempunyai kekangan utama asing terhadap ID lajur genre Jadual. Kedua -dua lajur bersama -sama digunakan sebagai komposit kunci utama, jadi hubungan antara filem dan genre hanya boleh dinyatakan sekali sahaja. Pada ketika ini, kita boleh mengeluarkan lajur "Genre" dari jadual "Filem":

+----+--------------------+------+ | id | Nama | tahun | +----+--------------------+------+| 1 | The Exorcist | 1973 | | 2 | Suspek biasa | 1995 | | 3 | Star Wars | 1977 | +----+--------------------+------+ 

Jadual sekarang dalam bentuk biasa pertama.

Bentuk biasa kedua

Bentuk normal pertama adalah prasyarat untuk yang kedua: untuk bentuk normal kedua yang dipenuhi, data mesti ada Borang Normal Pertama Dan tidak seharusnya ada ketergantungan separa sifat sekunder dari subset dari mana -mana Kunci calon.

Apakah kebergantungan separa? Mari kita mulakan dengan mengatakan bahawa di dalam meja boleh ada lebih daripada satu Kunci calon. Kunci calon adalah satu lajur, atau satu set lajur yang bersama -sama dapat dikenal pasti sebagai unik dalam jadual: hanya satu dari
kekunci calon, akan dipilih sebagai jadual kunci utama, yang secara unik mengenal pasti setiap baris.

Atribut yang merupakan sebahagian daripada kekunci calon ditakrifkan sebagai Perdana, Walaupun semua yang lain dipanggil sekunder. Untuk hubungan dalam bentuk normal kedua, tidak boleh ada atribut sekunder yang bergantung pada subset
kunci calon.

Mari lihat contoh. Katakan kami mempunyai meja yang kami gunakan untuk menyimpan data mengenai pemain bola sepak dan skor mereka untuk setiap gameday untuk aplikasi bola sepak fantasi, seperti ini:

+-----------+------------+-----------+------------+---------+-------+ | pemain_id | First_name | last_name | Peranan | Gameday | SCORE | +-----------+------------+-----------+------------ +---------+-------+| 111 | Cordaz | Alex | Penjaga gol | 18 | 6.50 | | 117 | Donnarumma | Gianluigi | Penjaga gol | 18 | 7.50 | | 124 | Handanovic | Samir | Penjaga gol | 18 | 7.50 | +-----------+------------+-----------+------------+---------+-------+ 

Mari lihat jadual ini. Pertama sekali kita dapat melihat bahawa ia memenuhi bentuk normal pertama, kerana data dalam setiap lajur adalah atom. Data yang terkandung dalam pemain_id Lajur boleh digunakan untuk mengenal pasti pemain secara unik, tetapi
bolehkah ia digunakan sebagai kunci utama untuk jadual? Jawapannya tidak, kerana baris untuk setiap pemain akan wujud untuk setiap gameday! Di sini kita boleh menggunakan a komposit Kunci utama sebaliknya, dibuat oleh gabungan pemain_id dan gameday lajur, kerana satu dan hanya satu entri yang boleh wujud untuk pemain itu untuk setiap gameday.

Adakah jadual ini memenuhi bentuk normal kedua? Jawapannya tidak, mari kita lihat mengapa. Kami sebelum ini mengatakan bahawa setiap atribut yang bukan sebahagian daripada kekunci calon dipanggil sekunder dan untuk jadual memenuhi normal kedua
bentuknya tidak boleh bergantung pada a subset dari mana -mana kunci calon, tetapi ia mesti bergantung pada kunci calon secara keseluruhan.

Mari ambil peranan Atribut, sebagai contoh. Ini adalah atribut sekunder, kerana ia bukan sebahagian daripada kunci calon. Kita boleh mengatakan bahawa ia bergantung kepada fungsi pemain_id, Oleh kerana jika pemain berubah, juga peranan bersekutu berpotensi boleh berubah; Walau bagaimanapun, ia tidak bergantung gameday, yang merupakan komponen lain dari kunci utama komposit, kerana walaupun gameday mengubah peranan pemain tetap sama. Kita boleh mengatakan bahawa peranan secara fungsional bergantung pada a subset dari kunci utama komposit, oleh itu bentuk normal kedua tidak berpuas hati.

Untuk menyelesaikan masalah ini, kita boleh membuat jadual berasingan yang digunakan untuk menggambarkan secara eksklusif setiap pemain:

+-----------+------------+-----------+------------+ | pemain_id | First_name | last_name | Peranan | +-----------+------------+-----------+------------ + | 111 | Cordaz | Alex | Penjaga gol | | 117 | Donnarumma | Gianluigi | Penjaga gol | | 124 | Handanovic | Samir | Penjaga gol | +-----------+------------+-----------+------------+ 

Sekarang kita boleh mengeluarkan maklumat tersebut dari jadual skor, dan menjadikannya kelihatan seperti ini:

+-----------+---------+-------+ | pemain_id | Gameday | SCORE | +-----------+---------+-------+| 111 | 18 | 6.50 | | 117 | 18 | 7.50 | | 124 | 18 | 7.50 | +-----------+---------+-------+ 

Bentuk normal kedua kini berpuas hati.

Bentuk biasa ketiga

Bentuk normal kedua adalah prasyarat untuk bentuk normal ketiga. Untuk berada dalam bentuk normal ketiga, jadual mestilah dalam bentuk normal kedua, dan tidak boleh mengandungi atribut yang bergantung secara transitif di atas meja utama. Apakah maksudnya? Kita boleh mengatakan bahawa kita mempunyai ketergantungan transitif Apabila atribut sekunder tidak bergantung secara langsung pada kunci utama jadual, tetapi ia mempunyai pergantungan pada atribut sekunder yang lain. Katakan kami menambah dua lajur baru ke pemain Jadual di atas, jadi ia kelihatan seperti ini:

+-----------+------------+-----------+------------+---------+-----------+ | pemain_id | First_name | last_name | Peranan | Kelab | Club_city | +-----------+------------+-----------+------------ +---------+-----------+| 111 | Cordaz | Alex | Penjaga gol | Crotone | Crotone | | 117 | Donnarumma | Gianluigi | Penjaga gol | Milan | Milano | | 124 | Handanovic | Samir | Penjaga gol | Inter | Milano | +-----------+------------+-----------+------------+---------+-----------+ 

Kami menambah Kelab dan Club_city lajur ke meja untuk menentukan, masing -masing, kelab yang dikaitkan dengan pemain, dan bandar yang kelab itu milik. Malangnya jadual sekarang tidak memuaskan Borang Normal Ketiga, Kenapa? Ia agak mudah: The Club_city atribut tidak bergantung secara langsung pemain_id, Yang merupakan kunci utama jadual, tetapi ia mempunyai kebergantungan transitif ke atasnya, melalui atribut sekunder yang lain: Kelab.

Bagaimana menyelesaikan masalah supaya bentuk normal ketiga berpuas hati? Yang harus kita lakukan ialah membuat jadual lain, di mana untuk merakam maklumat mengenai setiap kelab. Inilah jadual "Kelab":

+-----------+-----------+ | Club_name | Club_city | +-----------+-----------+| Crotone | Crotone | | Milan | Milano | | Inter | Milano | +-----------+-----------+ 

Kami mengasingkan maklumat kelab dalam jadual yang berdedikasi. Sebagai kunci utama untuk jadual, dalam kes ini, kami menggunakan Club_name kolum. Di dalam pemain Jadual Kita Sekarang Boleh Buang Club_city lajur, dan tambahkan kekangan utama asing ke Kelab lajur supaya ia merujuk Club_name lajur dalam Kelab Jadual:

+-----------+------------+-----------+------------+---------+ | pemain_id | First_name | last_name | Peranan | Kelab | +-----------+------------+-----------+------------ + ---------+ | 111 | Cordaz | Alex | Penjaga gol | Crotone | | 117 | Donnarumma | Gianluigi | Penjaga gol | Milan | | 124 | Handanovic | Samir | Penjaga gol | Inter | +-----------+------------+-----------+------------+---------+ 

Bentuk normal ketiga kini berpuas hati.

Kesimpulan

Dalam tutorial ini, kami bercakap mengenai tiga bentuk normal pangkalan data relasi dan bagaimana ia digunakan untuk mengurangkan redundansi data dan mengelakkan penyisipan, penghapusan dan pengemaskinian anomali. Kami melihat apakah prasyarat dari setiap bentuk normal, beberapa contoh pelanggaran mereka, dan bagaimana untuk memperbaikinya. Walau bagaimanapun, bentuk normal yang lain melepasi yang ketiga, dalam aplikasi yang paling biasa, mencapai bentuk normal ketiga sudah cukup untuk mencapai persediaan yang optimum.

Tutorial Linux Berkaitan:

• Perkara yang hendak dipasang di Ubuntu 20.04
• Pengenalan kepada Automasi, Alat dan Teknik Linux
• Menguasai Gelung Skrip Bash
• Perkara yang perlu dilakukan setelah memasang ubuntu 20.04 Focal Fossa Linux
• Mint 20: Lebih baik daripada Ubuntu dan Microsoft Windows?
• Fail Konfigurasi Linux: 30 teratas yang paling penting
• Mengkonfigurasi ZFS di Ubuntu 20.04
• Ubuntu 20.04 Trik dan Perkara yang Anda Tidak Tahu
• Manipulasi data besar untuk keseronokan dan keuntungan bahagian 1
• Gelung bersarang dalam skrip bash