Pengantar Normalisasi Basis Data Tiga bentuk normal pertama

Tujuan normalisasi database relasional adalah untuk mencapai dan meningkatkan integritas data dan hindari redundansi data Jadi untuk menghindari kemungkinan penyisipan, pembaruan atau anomali penghapusan. Database relasional dinormalisasi dengan menerapkan serangkaian aturan yang disebut bentuk normal. Dalam artikel ini kita akan membahas tiga bentuk normal pertama.

Dalam tutorial ini Anda akan belajar:

• Apa bentuk normal pertama
• Apa bentuk normal kedua
• Apa bentuk normal ketiga

Persyaratan dan konvensi perangkat lunak yang digunakan

Bentuk normal pertama

Misalkan kami memiliki tabel berikut yang kami gunakan untuk menyimpan informasi tentang beberapa film:

+----+--------------------+--------------------+------+ | ID | Nama | Genre | Tahun | +----+--------------------+--------------------+- ----+ | 1 | The Exorcist | Horor | 1973 | | 2 | Tersangka biasa | Thriller, Neo-Noir | 1995 | | 3 | Star Wars | OPERA-OPERA | 1977 | +----+--------------------+--------------------+------+ 

Tabel di atas, tidak memuaskan bentuk normal pertama, Mengapa? Agar bentuk normal pertama dipenuhi, setiap kolom tabel harus berisi atom (tidak terpisahkan) data. Di baris kedua tabel kami, yang berisi informasi tentang film "The Equual Suspects", kita dapat melihat bahwa genre Kolom berisi data yang bukan atom. Dua genre sebenarnya terdaftar: thriller dan neo-noir. Katakanlah dalam representasi kami, kami ingin mengizinkan satu film dikaitkan dengan lebih dari satu genre; Bagaimana kita menyelesaikan masalah?

Hal pertama yang terlintas dalam pikiran adalah menambahkan baris baru di tabel yang sama, mengulangi informasi tentang film, dan hanya menentukan satu genre per mentah. Gagasan ini cukup mengerikan, karena kami akan memiliki banyak data yang berlebihan (kami harus mengulangi informasi film yang sama setiap kali kami ingin mengaitkannya dengan genre baru!).

Solusi lain yang sedikit lebih baik, adalah menambahkan kolom baru, jadi untuk memiliki, misalnya, a genre1 Dan genre2 kolom. Namun ini, antara lain, akan mewakili batas: bagaimana jika sebuah film harus terdaftar di bawah lebih dari dua genre?

Cara yang lebih cerdas untuk menyelesaikan masalah ini adalah dengan membuat tabel baru yang digunakan untuk menyimpan informasi genre. Inilah tabel "Genre":

+----+-------------+ | ID | Nama | +----+-------------+| 1 | Horor | | 2 | Neo-noir | | 3 | OPERA-OPERA | | 4 | Thriller | +----+-------------+ 

Sekarang, karena satu antara genre dan film adalah a banyak ke banyak hubungan (film dapat dikaitkan dengan beberapa genre, dan genre dapat dikaitkan dengan banyak film yang berbeda), untuk mengekspresikannya tanpa redundansi data, kita dapat menggunakan SO
ditelepon tabel persimpangan:

+----------+----------+ | film_id | Genre_id | +----------+----------+| 1 | 1 | | 2 | 2 | | 2 | 4 | | 3 | 3 | +----------+----------+ 

Tabel persimpangan kami memiliki satu-satunya tugas untuk mengekspresikan hubungan banyak-ke-banyak antara dua tabel atau film dan genre entitas. Ini disusun oleh hanya dua kolom: film_id dan genre_id. Itu film_id kolom memiliki a kunci asing kendala untuk pengenal kolom dari film meja, dan genre_id memiliki batasan kunci asing untuk pengenal kolom dari genre meja. Dua kolom bersama -sama digunakan sebagai a gabungan kunci utama, jadi hubungan antara film dan genre hanya dapat diekspresikan sekali. Pada titik ini, kita dapat menghapus kolom "Genre" dari tabel "Film":

+----+--------------------+------+ | ID | Nama | Tahun | +----+--------------------+------+| 1 | The Exorcist | 1973 | | 2 | Tersangka biasa | 1995 | | 3 | Star Wars | 1977 | +----+--------------------+------+ 

Tabel sekarang dalam bentuk normal pertama.

Bentuk normal kedua

Bentuk normal pertama adalah prasyarat untuk yang kedua: untuk bentuk normal kedua untuk dipenuhi, data harus sudah masuk bentuk normal pertama dan tidak boleh ada ketergantungan parsial atribut sekunder dari subset dari apapun Kunci kandidat.

Apa ketergantungan parsial? Mari kita mulai dengan mengatakan itu di meja mungkin ada lebih dari satu Kunci kandidat. Kunci kandidat adalah satu kolom, atau satu set kolom yang bersama -sama dapat diidentifikasi sebagai unik dalam tabel: hanya satu dari
kandidat kunci, akan dipilih sebagai tabel kunci utama, yang secara unik mengidentifikasi setiap baris.

Atribut yang merupakan bagian dari kunci kandidat didefinisikan sebagai utama, sedangkan yang lainnya dipanggil sekunder. Agar hubungan berada dalam bentuk normal kedua, seharusnya tidak ada atribut sekunder yang tergantung pada subset
kunci kandidat.

Mari kita lihat contohnya. Misalkan kami memiliki meja yang kami gunakan untuk menyimpan data tentang pemain sepak bola dan skor mereka untuk setiap gameday untuk aplikasi sepak bola fantasi, sesuatu seperti ini:

+-----------+------------+-----------+------------+---------+-------+ | player_id | first_name | last_name | Peran | gameday | skor | +-----------+------------+-----------+------------ +---------+-------+| 111 | Cordaz | Alex | Penjaga gawang | 18 | 6.50 | | 117 | Donnarumma | Gianluigi | Penjaga gawang | 18 | 7.50 | | 124 | Handanovic | Samir | Penjaga gawang | 18 | 7.50 | +-----------+------------+-----------+------------+---------+-------+ 

Mari kita lihat meja ini. Pertama -tama kita dapat melihat bahwa itu memenuhi bentuk normal pertama, karena data di setiap kolom adalah atom. Data yang terkandung di player_id Kolom dapat digunakan untuk mengidentifikasi secara unik pemain, tetapi
Bisakah itu digunakan sebagai kunci utama untuk tabel? Jawabannya adalah tidak, karena baris untuk setiap pemain akan ada untuk setiap gameday! Di sini kita bisa menggunakan gabungan kunci utama sebagai gantinya, dibuat oleh kombinasi player_id Dan hari bermain kolom, karena satu dan hanya satu entri yang dapat ada untuk pemain itu untuk setiap gameday.

Apakah tabel ini memenuhi bentuk normal kedua? Jawabannya adalah tidak, mari kita lihat mengapa. Kami sebelumnya mengatakan bahwa setiap atribut yang bukan bagian dari setiap kandidat kunci disebut sekunder dan agar meja memuaskan normal kedua
bentuknya tidak boleh bergantung pada a subset dari kunci kandidat apa pun, tetapi harus tergantung pada kunci kandidat secara keseluruhan.

Mari kita ambil peran atribut, misalnya. Ini adalah atribut sekunder, karena ini bukan bagian dari kunci kandidat apa pun. Kita dapat mengatakan bahwa itu secara fungsional tergantung player_id, Karena jika pemain berubah, juga peran asosiasi berpotensi berubah; Namun, itu tidak tergantung pada hari bermain, yang merupakan komponen lain dari kunci primer komposit, karena bahkan jika gameday mengubah peran pemain tetap sama. Kita bisa mengatakan itu peran secara fungsional tergantung pada a subset dari kunci primer komposit, oleh karena itu bentuk normal kedua tidak terpenuhi.

Untuk menyelesaikan masalah, kami dapat membuat tabel terpisah yang digunakan untuk secara eksklusif menggambarkan setiap pemain:

+-----------+------------+-----------+------------+ | player_id | first_name | last_name | Peran | +-----------+------------+-----------+------------ + | 111 | Cordaz | Alex | Penjaga gawang | | 117 | Donnarumma | Gianluigi | Penjaga gawang | | 124 | Handanovic | Samir | Penjaga gawang | +-----------+------------+-----------+------------+ 

Kami sekarang dapat menghapus informasi tersebut dari tabel skor, dan membuatnya terlihat seperti ini:

+-----------+---------+-------+ | player_id | gameday | skor | +-----------+---------+-------+| 111 | 18 | 6.50 | | 117 | 18 | 7.50 | | 124 | 18 | 7.50 | +-----------+---------+-------+ 

Bentuk normal kedua sekarang terpenuhi.

Bentuk normal ketiga

Bentuk normal kedua adalah prasyarat untuk bentuk normal ketiga. Untuk berada dalam bentuk normal ketiga, tabel harus sudah dalam bentuk normal kedua, dan tidak boleh berisi atribut yang ada tergantung secara transitif Di atas meja kunci utama. Apa artinya? Kita bisa mengatakan kita memiliki file ketergantungan transitif Ketika atribut sekunder tidak bergantung langsung pada kunci primer tabel, tetapi memiliki ketergantungan pada atribut sekunder lain. Misalkan kita menambahkan dua kolom baru ke pemain Tabel di atas, jadi terlihat seperti ini:

+-----------+------------+-----------+------------+---------+-----------+ | player_id | first_name | last_name | Peran | klub | club_city | +-----------+------------+-----------+------------ +---------+-----------+| 111 | Cordaz | Alex | Penjaga gawang | Crotone | Crotone | | 117 | Donnarumma | Gianluigi | Penjaga gawang | Milan | Milano | | 124 | Handanovic | Samir | Penjaga gawang | Inter | Milano | +-----------+------------+-----------+------------+---------+-----------+ 

Kami menambahkan klub Dan club_city kolom ke meja untuk menentukan, masing -masing, klub yang terkait dengan pemain, dan kota tempat klub itu berasal. Sayangnya meja sekarang tidak memuaskan bentuk normal ketiga, Mengapa? Ini cukup sederhana: club_city Atribut tidak secara langsung bergantung pada player_id, yang merupakan kunci tabel primer, tetapi memiliki ketergantungan transitif di atasnya, melalui atribut sekunder lainnya: klub.

Bagaimana menyelesaikan masalah sehingga bentuk normal ketiga terpenuhi? Yang harus kami lakukan adalah membuat tabel lain, di mana merekam informasi tentang setiap klub. Inilah tabel "klub":

+-----------+-----------+ | club_name | club_city | +-----------+-----------+| Crotone | Crotone | | Milan | Milano | | Inter | Milano | +-----------+-----------+ 

Kami mengisolasi informasi klub di tabel khusus. Sebagai kunci utama untuk tabel, dalam hal ini, kami menggunakan club_name kolom. Dalam pemain Tabel yang sekarang dapat kita hapus club_city kolom, dan tambahkan kendala kunci asing ke klub kolom sehingga merujuk club_name kolom di klub meja:

+-----------+------------+-----------+------------+---------+ | player_id | first_name | last_name | Peran | klub | +-----------+------------+-----------+------------ + ---------+ | 111 | Cordaz | Alex | Penjaga gawang | Crotone | | 117 | Donnarumma | Gianluigi | Penjaga gawang | Milan | | 124 | Handanovic | Samir | Penjaga gawang | Inter | +-----------+------------+-----------+------------+---------+ 

Bentuk normal ketiga sekarang terpenuhi.

Kesimpulan

Dalam tutorial ini kami berbicara tentang tiga bentuk normal pertama dari database relasional dan bagaimana mereka digunakan untuk mengurangi redundansi data dan menghindari anomali penyisipan, penghapusan dan pembaruan. Kami melihat apa prasyarat dari setiap bentuk normal, beberapa contoh pelanggaran mereka, dan bagaimana cara memperbaikinya. Bentuk normal lainnya ada melewati yang ketiga, bagaimanapun, dalam aplikasi yang paling umum, mencapai bentuk normal ketiga sudah cukup untuk mencapai pengaturan yang optimal.

Tutorial Linux Terkait:

• Hal -hal yang harus diinstal pada ubuntu 20.04
• Pengantar Otomatisasi Linux, Alat dan Teknik
• Menguasai loop skrip bash
• Hal -hal yang harus dilakukan setelah menginstal ubuntu 20.04 FOSSA FOSSA Linux
• Mint 20: Lebih baik dari Ubuntu dan Microsoft Windows?
• File Konfigurasi Linux: 30 Teratas Paling Penting
• Mengkonfigurasi ZFS di Ubuntu 20.04
• Ubuntu 20.04 trik dan hal -hal yang mungkin tidak Anda ketahui
• Manipulasi data besar untuk kesenangan dan keuntungan bagian 1
• Loop bersarang dalam skrip bash