Bentuk Normal Pertama: Definisi Definitif


9

Saya mencoba untuk mendapatkan versi definitif dari apa itu First Normal Form. Semua yang saya baca memiliki putaran yang sedikit berbeda.

Banyak pihak berwenang, seperti Date, mengatakan bahwa menurut definisi suatu relasi selalu dalam Bentuk Normal Pertama, sementara yang lain memberikan daftar persyaratan. Ini berarti bahwa ada dari nol hingga banyak persyaratan untuk 1NF.

Saya kira perbedaannya adalah antara tabel dan relasi: tabel bisa berantakan total, sementara hubungan mengikuti batasan tertentu. Fakta bahwa suatu relasi direpresentasikan sebagai tabel dalam SQL dengan demikian menciptakan beberapa kebingungan.

Saya fokus secara khusus pada 1NF karena berkaitan dengan database SQL. Pertanyaannya adalah: properti apa yang diperlukan untuk memastikan bahwa tabel dalam bentuk normal pertama?


Banyak pihak berwenang menyarankan bahwa jika suatu tabel mewakili suatu relasi , maka itu sudah ada dalam 1NF. Ini mendorong definisi 1NF kembali ke definisi suatu relasi.

Berikut adalah beberapa properti tabel di 1NF:

  • Urutan Kolom tidak signifikan [1]
  • Pesanan Baris tidak signifikan
  • Semua baris memiliki panjang yang sama (yaitu, data baris cocok dengan tajuk kolom)
  • Tidak ada baris duplikat (ini dapat dijamin menggunakan kunci primer pengganti, tetapi PK itu sendiri tidak diperlukan)
  • Tidak ada kolom berulang
  • Setiap kolom berisi nilai tunggal (atom)

[1] Atribut secara teknis tidak berurutan, tetapi dalam sebuah tabel, data baris harus dalam urutan yang sama dengan header kolom. Namun, urutan sebenarnya tidak signifikan.

Pada banyak data :

Konsep data atom adalah bahwa suatu barang tidak dapat dirinci lebih lanjut. Konsep ini telah memenuhi syarat bahwa meskipun secara teknis semuanya dapat dipecah ad nauseum , data tersebut tidak dapat dipecah secara praktis lebih lanjut, tergantung pada bagaimana data akan digunakan.

Misalnya, alamat lengkap atau nama lengkap biasanya harus dirinci lebih lanjut, tetapi komponen seperti nama yang diberikan atau nama kota mungkin tidak boleh dirinci lebih lanjut, meskipun fakta bahwa sebagai string mereka dapat.

Mengenai kolom berulang, itu adalah kolom desain yang buruk untuk memiliki kolom hampir berulang, seperti phone1, phone2dll. Secara umum, data berulang menunjukkan kebutuhan untuk tabel terkait tambahan.

Ketergantungan

Seharusnya tidak ada hubungan antara baris, selain itu mereka sesuai dengan header yang sama.

Seharusnya juga tidak ada hubungan antara kolom, tapi saya percaya itu adalah subjek dari bentuk normal yang lebih tinggi.

Pertanyaannya adalah: Berapa banyak di atas dalam definisi 1NF? Apakah baris independen juga ikut terlibat?

Jawaban:


7

Pendahuluan

Definisi bentuk normal (yang dari presentasi “Normalisasi lebih lanjut dari Data Base Relational Model” pada tahun 1971 dikenal sebagai bentuk normal pertama ) dan yang definisi paradigma relasional itu sendiri diterbitkan pada tahun 1970 dalam makalah ilmiah yang disediakan kuat landasan bagi praktek administrasi database, yaitu, “A Relational Model data untuk besar Shared data Bank” (RM untuk singkatnya) yang dibuat oleh Dr EF Codd , yang merupakan penerima Turing Award dan yang berwenang sehubungan dengan kerangka relasional.

Ya, ada banyak penjelasan, interpretasi, eksposisi, penyimpangan, dan pendapat tentang teks Dr. Codd, tetapi saya pribadi lebih suka menempel pada sumber aslinya dan saya sangat menyarankan agar Anda menganalisisnya sendiri sehingga Anda dapat menarik kesimpulan sendiri.

Saya tentu saja tidak memahami RM secara keseluruhan, tetapi apa yang saya mengerti tentang hal itu memungkinkan saya menghargai keunggulan, visi, niat dan ruang lingkupnya, dan meskipun beberapa dekade kemudian orang dapat mencatat bahwa ia memiliki beberapa ketidaktepatan sedikit, mereka tidak mengurangi, dengan cara apa pun, kejeniusan dan keanggunannya. Di bidangnya, RM telah bertahan dalam ujian waktu dengan cara yang unik, dan tetap tak tertandingi.

Tindakan yang menekankan ketidaktepatan yang disebutkan di atas adalah — menggunakan istilah amal — tidak adil karena, jika dilihat dari jarak yang cukup jauh, bahan mani ini membutuhkan beberapa penyempurnaan dan perluasan, ya, tetapi bagian utama dari karya ini sangat solid dari sangat konsepsi (dan, memang, Dr. Codd membuat sebagian besar — ​​jika tidak semua — dari penyempurnaan dan perluasan itu sendiri).

Saya terus membaca ulang RM terus-menerus untuk memperkuat pemahaman saya tentang sumber pengetahuan yang luar biasa ini (dan harga saya akan RM terus bertambah di setiap membaca ulang); tujuannya adalah untuk berdiri di atas bahu raksasa.

Hubungan dan tabel

Penting untuk dicatat bahwa karena hubungan adalah sumber daya abstrak , Dr. Codd membayangkan utilitas untuk mewakili mereka dalam bentuk tabel (ia awalnya menggunakan istilah "representasi array" tetapi kemudian menggunakan "tabel" atau "r-tabel"), sehingga para pengguna, perancang, dan administrator dari basis data relasional (RDB) dapat mendekati mereka dengan cara yang lebih akrab atau konkret . Oleh karena itu, dalam konteks implementasi RDB, valid untuk menggunakan tabel sebagai singkatan untuk hubungan, selama tabel tersebut merupakan hubungan aktual. Fitur ini —sudah jelas — cukup signifikan karena sebelum mengevaluasi apakah suatu tabel mewakili relasi yang sesuai dengan bentuk normal pertama (1NF), ia harus mewakili, tepatnya, relasi.

RM secara alami mengandung kualitas-kualitas yang harus dimiliki suatu tabel untuk menentukan apakah suatu tabel sebenarnya menggambarkan suatu relasi, tetapi saya akan menawarkan interpretasi informal dan tidak bersahaja tentang mereka di sini (yang lain, ya!):

  • Itu harus memiliki nama (setiap hubungan tertentu dalam struktur database harus dibedakan dari yang lain).
  • Setiap barisnya harus menggambarkan tepat satu tupel dari relasi yang bersangkutan.
  • The agar baris yang tidak penting sama sekali.
  • Setiap kolomnya harus memiliki nama yang mewakili arti tepat satu domain dari relasi yang bersangkutan, dan nama tersebut harus berbeda dari nama-nama sisa kolom tabel (kolom harus dibedakan secara unik dan harus membawa makna yang berbeda dan, ya, peran yang dimainkan oleh pemodel basis data dan pakar bisnis untuk menentukan setiap domain signifikansi dengan akurasi sangat penting)
  • The rangka kolom yang tidak memiliki arti.
  • Semua barisnya harus memiliki jumlah kolom yang sama.
  • Itu harus memiliki setidaknya satu kolom, atau satu kombinasi kolom, yang secara unik mengidentifikasi setiap tupel yang digambarkan melalui baris; dengan cara ini, semua baris harus berbeda (ya, ini menekankan pentingnya memiliki setidaknya satu KUNCI yang dinyatakan, dan ketika ada dua atau lebih KUNCI satu harus didefinisikan sebagai PRIMER berdasarkan alasan pragmatis, sedangkan sisanya dapat dianggap sebagai ALTERNATIF, tetapi ya, sebelum membuat keputusan, masing-masing KUNCI adalah "kandidat" untuk definisi sebagai PRIMER).

Memiliki tabel yang dalam kenyataannya mewakili suatu relasi adalah penting, ketika ia mengalami operasi manipulasi dari suatu relasional, maka hasilnya adalah, sekali lagi, sebuah tabel yang mewakili relasi. Dengan cara ini, perilaku tabel tersebut dapat diprediksi .

Domain atom (kolom)

Pada bagian pertama RM, Dr. Codd menyajikan beberapa sampel hubungan untuk memperkenalkan beberapa konsep; jadi, untuk memahami makna domain atom , mari kita mulai dengan kutipan berikut dari RM yang merinci beberapa poin terkait:

Sejauh ini, kita telah membahas contoh-contoh hubungan yang didefinisikan pada domain sederhana — domain yang elemen-elemennya adalah nilai atom (tidak dapat dikomposasikan). Nilai-nilai nonatomik dapat didiskusikan dalam kerangka relasional. Dengan demikian, beberapa domain mungkin memiliki hubungan sebagai elemen. Hubungan-hubungan ini, pada gilirannya, dapat didefinisikan pada domain yang tidak sederhana, dan sebagainya.

Dengan cara ini, seseorang dapat mengatakan bahwa masing-masing hubungan ekspositori yang disebutkan di atas cocok dengan salah satu dari dua jenis, misalnya jenis A atau jenis B :

  • Jenis A mengelompokkan hanya relasi (tabel) yang disusun dengan domain (kolom) yang berisi nilai-nilai sederhana secara eksklusif di setiap tupel (baris) mereka, yaitu domain (kolom) tersebut tidak mengandung relasi (tabel) sebagai nilai, yang dalam konteks ini berarti bahwa nilai-nilai itu bersifat atomik karena nilai-nilai itu tidak dapat diuraikan secara berturut-turut ke dalam hubungan baru (tabel). Oleh karena itu, hubungan kelas ini adalah orang-orang yang dinormalisasi , yaitu, mereka mematuhi 1NF, bentuknya diinginkan.

  • Jenis B secara eksklusif diintegrasikan oleh relasi (tabel) yang memiliki satu atau lebih domain (kolom) yang menyimpan relasi sebagai nilai di setiap tuple (baris) masing-masing, dan yang menandakan bahwa nilai-nilai tersebut nonatomik karena selanjutnya dapat dipecah menjadi relasi baru (Tabel), yaitu, mereka dapat terurai . Dengan demikian, hubungan semacam ini tidak dinormalisasi, yaitu, mereka melanggar 1NF, mereka berada dalam bentuk yang tidak diinginkan.

Normalisasi

Codd memperkenalkan bagian tentang normalisasi dalam RM dengan paragraf berikut:

Suatu relasi yang domainnya semuanya sederhana dapat direpresentasikan dalam penyimpanan oleh array dua dimensi kolom-homogen dari jenis yang dibahas di atas. Beberapa struktur data yang lebih rumit diperlukan untuk hubungan dengan satu atau lebih domain tidak sederhana. Untuk alasan ini (dan yang lainnya dikutip di bawah) kemungkinan menghilangkan domain nonsimple nampaknya perlu diselidiki! Sebenarnya, ada prosedur eliminasi yang sangat sederhana, yang akan kita sebut normalisasi.

Kemudian dia menunjukkan:

  1. Sekelompok hubungan di mana seseorang tidak dinormalisasi (memiliki domain yang berisi hubungan sebagai nilai, yaitu, mereka nonatomik; yaitu, mereka tidak sederhana)

  2. Sekelompok hubungan yang dinormalisasi (yaitu, yang didekomposisi; yaitu, yang hubungan domain bernilai dipecah menjadi yang sederhana yang menandakan bahwa mereka adalah atom)

Dan kemudian dia menjelaskan prosedur untuk mendapatkan hubungan normal dari yang tidak normal.

Dalam hal ini, hubungan yang ia gunakan untuk menggambarkan latihan normalisasi dan deskripsi latihan itu sendiri cukup jelas, dan saya sarankan lagi agar Anda menganalisisnya sendiri (dan saya juga berharap ini mendorong beberapa pembaca untuk terlibat dengan teks).

Secara berturut-turut, ia menunjukkan:

Operasi lebih lanjut dari jenis normalisasi dimungkinkan. Ini tidak dibahas dalam makalah ini.

Dan operasi tersebut, yaitu, bentuk normal kedua dan ketiga (2NF dan 3NF) sebenarnya dirinci dalam "Normalisasi Lebih Lanjut dari Model Relasional Basis Data", dan sebagaimana disebutkan di atas, setelah presentasi (dan kemudian pencetakan dan publikasi) dari makalah ini , bentuk normal aslinya dikenal sebagai bentuk normal pertama.

Seperti yang dapat diamati oleh seorang praktisi, memiliki hubungan yang tidak normal (tabel) memperkenalkan konvolusi (hampir selalu tidak perlu) ke dalam implementasi RDB.

Suatu relasi yang memenuhi 1NF, memudahkan definisi kendala dan operasi manipulasi data yang dapat diimplementasikan dengan menggunakan subbahasa data yang kurang kompleks daripada yang dibutuhkan untuk hubungan (tabel) yang tidak dinormalkan, seperti yang ditunjukkan Dr. Codd dalam baris berikut:

Adopsi model data relasional, seperti dijelaskan di atas, memungkinkan pengembangan subbahasa data universal berdasarkan pada kalkulus predikat terapan. Kalkulus predikat orde pertama cukup jika koleksi hubungan dalam bentuk normal. Bahasa seperti itu akan memberikan tolok ukur kekuatan linguistik untuk semua bahasa data yang diusulkan lainnya, dan itu sendiri akan menjadi kandidat yang kuat untuk menanamkan (dengan modifikasi sintaksis yang sesuai) dalam berbagai bahasa host (pemrograman, perintah-atau berorientasi masalah). [...]

[...]

Keuniversalan dari subbahasa data terletak pada kemampuan deskriptifnya (bukan kemampuan komputasinya).

Kebingungan

Dari sudut pandang saya, bingung telah muncul, karena (a) kelebihan tersebut interpretasi, penjelasan, dll, sekitar 1NF dan para RM sendiri, dan karena (b) upaya lebih lanjut untuk mendefinisikan kembali 1NF bahwa negara yang memiliki hubungan dengan domain yang memiliki nilai yang, pada gilirannya, hubungan mematuhi 1NF selama mereka adalah satu nilai tunggal untuk setiap tupel yang sesuai.

Pandangan saya tentang poin Anda yang lain

Seharusnya tidak ada hubungan antara baris, selain itu mereka sesuai dengan header yang sama.

Saya tidak yakin apakah saya memahami maksud dari pernyataan itu dengan benar tetapi, selain dari menyesuaikan diri dengan header yang sama, harus ada hubungan antara baris (tuple) relasi (tabel) karena masing-masing dari mereka harus menjadi pernyataan tentang suatu kemunculan khusus dari tipe entitas spesifik (didefinisikan dalam konteks konteks bisnis yang diminati) yang harus diwakili oleh relasi (tabel).

Seharusnya juga tidak ada hubungan antara kolom, tapi saya percaya itu adalah subjek dari bentuk normal yang lebih tinggi.

Saya tidak tahu apakah saya benar menafsirkan makna pernyataan itu baik tetapi, pada kenyataannya, dan sesuai dengan tanggapan saya terhadap aspek sebelumnya, harus ada hubungan antara domain (kolom) dari relasi (tabel) juga , itulah sebabnya mengapa itu adalah hubungan (struktur penting dari model relasional dan implementasi RDB yang konkret).

Sebagai contoh, berkaitan dengan hubungan hipotetis (tabel)

  • Salary (PersonNumber, EffectiveDate, Amount)

tuple (baris)

  • Salary (x, y, z)

akan menyampaikan artinya

  • The Salary payed to the Person identified by PersonNumber x, on EffectiveDate y corresponds to the Amount of z

Oleh karena itu, setiap tupel (baris) Salaryrelasi (tabel) harus sesuai dengan struktur pernyataan yang ditunjukkan di atas, dan perbedaannya adalah penggantian nilai domain (kolom) terkait, tetapi harus ada hubungan antara (a) semua Salarydomain (kolom) dan juga antara (b) semua nilai yang terkait dengan masing-masing tupel (baris); hubungan seperti itu sangat diperlukan.

Bentuk normal yang lebih tinggi (2NF dan 3NF) berguna untuk menghilangkan dependensi fungsional antara domain (kolom) dari suatu relasi (tabel), mereka membantu menghindari koneksi yang tidak diinginkan antara domain (kolom), karena koneksi yang tidak diinginkan memungkinkan pengenalan anomali pembaruan . 2NF dan 3NF keduanya membantu untuk menguji kesehatan struktur hubungan (tabel) dalam implementasi RDB tertentu.


3

Sebuah ilustrasi. Ambil string teks yang berisi alamat US khas:

"123 Cornhusk Rd., South Succotash, NY 12345"

Menulis pertanyaan untuk menemukan semua penduduk Cornhusk Road atau penduduk tertentu di kota South Succotash atau negara bagian New York akan menjadi tugas yang menakutkan. Terutama ketika Anda memiliki string berikut dalam data:

"123 Cornhusk Road, South Succotash, NY 12345"
"123 Cornhusk Rd., South Succotash, New York 12345"
"123 Cornhusk, South Succotash, NY 12345"
"123 Cornhusk Rd., SOUTH SUCCOTASH, NY 12345"

Masing-masing menentukan alamat aktual yang sama (dan ini bahkan tidak mempertimbangkan kemungkinan salah eja seperti "Succatash") tetapi menulis algoritma untuk berhasil membandingkannya adalah sesuatu yang TIDAK AKU ingin dedikasikan tahun-tahun terakhir saya yang tersisa di Bumi ini untuk dilakukan.

Masukkan bentuk normal pertama. Saya tidak akan masuk ke rincian tentang bagaimana hal itu dilakukan, cukup pertimbangkan bentuk umum seperti yang terlihat di kebanyakan database:

create table Addresses(
  ...
  Street  varchar,
  City    int        references Cities( ID ),
  State   char( 2 )  references States( ID ),
  Zip     int
  ...
);

Ini bukan normalisasi lengkap. Misalnya, Anda dapat membagi Street menjadi StreetNum dan StreetName lebih jauh, tetapi ini cukup untuk ilustrasi sederhana dan sebenarnya sejauh proses normalisasi diambil dalam kehidupan nyata. Masih ada masalah kecil dalam menemukan semua penghuni Cornhusk Road tetapi jika Anda mencari Street untuk substring "Cornhusk" dan kebetulan ada sebuah kota bernama Cornhusk di suatu tempat, setidaknya itu tidak akan menimbulkan kebingungan.

Masalah dengan definisi yang disediakan oleh Date, dkk, adalah bahwa mereka gagal untuk melihat ke dalam sepotong data dan mempertimbangkan arti dari data itu. Bukannya saya menyalahkan mereka, itu bisa sangat sulit.

Jadi kita harus mengambil "serangkaian karakter" dan mengubahnya menjadi "alamat." Tetapi datang dengan definisi alamat yang inklusif tidak semudah kelihatannya. Terutama ketika bekerja dengan alamat di lebih dari satu negara.

Pertama, kami memperbaiki konteksnya. Tidak ada yang berarti tanpa konteks. Konteks kami di sini adalah alamat . Dalam konteks itu, kita dapat melihat bagian data yang memiliki makna tertentu, seperti Street , City , dll. Kami memberikan masing-masing arti bidang yang terpisah.

Bagian yang sulit adalah bahwa data, seperti kata-kata, dapat memiliki makna yang berbeda untuk orang yang berbeda atau beberapa orang dapat melihat makna di mana orang lain tidak. Ini bisa menjadi proyek untuk dirinya sendiri dan membutuhkan banyak upaya kerja sama. Tetapi itu adalah elemen penting dalam desain database yang baik.

Titik normalisasi adalah untuk menghilangkan atau setidaknya meminimalkan anomali data. Pertimbangkan fakta bahwa, dalam tabel di atas, kode Kota atau Kode Pos dapat dimasukkan yang tidak ada di negara bagian yang dipilih. Atau jalan masuk yang sebenarnya tidak ada di kota yang dipilih. Ah, tapi sekarang kita masuk ke bentuk normal kedua dan ketiga dan itu adalah topik lain.


1

Pikirkan 1NF sebagai pengantar konsep hubungan matematika, daripada struktur data tertentu atau seperangkat aturan tetap. Struktur matematika seperti relasi dapat direpresentasikan dengan berbagai cara - tabel hanyalah salah satu cara yang paling nyaman. Saat menggunakan tabel, ada batasan untuk memastikan bahwa mereka mewakili hubungan yang dimaksudkan dengan jelas dan bahwa operasi di atas meja secara logis sesuai dengan hubungan yang diwakili.

Ketika kami mengatakan bahwa urutan kolom dan baris serta duplikasi tidak signifikan, ini untuk memastikan bahwa semua informasi signifikan dicatat sebagai nilai dalam tabel dan dapat diakses ke kueri kami, dan tidak dikodekan ke dalam presentasi tabel. Sementara beberapa, jika ada, penulis telah secara eksplisit melarang penggunaan warna dalam tabel, memahami tujuan pembatasan di atas akan mengarahkan kita untuk mengecualikan penggunaan warna presentasi yang bermakna sehingga nilai warna yang signifikan harus direkam secara eksplisit. Date dan penulis lain juga mencabut pengidentifikasi baris tersembunyi karena alasan yang sama.

Konsep atomicity adalah tentang memastikan bahwa semua struktur signifikan dinyatakan sebagai hubungan, sehingga kami dapat menganalisis dependensi dalam semua data kami dan mencegah anomali, dan agar semua struktur yang bermakna dapat diakses secara seragam untuk operasi relasional. Nilai komposit tidak valid, tetapi mereka membutuhkan operator khusus domain untuk membongkar, yang meningkatkan kompleksitas, dan mereka dapat memperkenalkan redundansi. Tentu saja, dalam praktiknya beberapa tipe komposit sederhana dan operator terkait mudah digunakan dan membantu meningkatkan kekompakan dan ekspresifitas kueri, tetapi ini tidak bertentangan dengan teori.

Dependensi baris seperti dependensi multinilai tidak melanggar 1NF, tetapi seperti dependensi di antara kolom, adalah subjek bentuk normal yang lebih tinggi. Kolom yang hampir berulang seperti phone1,, phone2dll juga tidak melanggar 1NF, meskipun desainnya buruk.


0

The definisi dan penjelasan dari WikiPedia tentang 1NF, saya pikir cukup baik. - joanolo

Memperluas satu kalimat dalam artikel Wikipedia:

Dilihat sebagai nomor telepon, teksnya bukan atom

Ini dapat memberi Anda pegangan mengapa ada begitu banyak kebingungan. Jika ini hanya sekumpulan teks, maka itu adalah atom. Tetapi jika itu dilihat sebagai nomor telepon, maka itu bukan atom. Date dan lainnya menghindari masalah ini. Itu ada hubungannya dengan apa artinya data. Ketika Anda menganalisis materi pelajaran, Anda harus bergulat dengan apa yang dimaksud dengan data.

Apakah ada titik untuk memecahnya lebih lanjut relevan dengan pertanyaan apakah bentuk normal pertama telah dipenuhi. Poin di balik 1NF adalah untuk menyediakan akses kunci ke semua data. Tetapi jika hal yang Anda ambil melalui akses kunci memiliki substruktur, maka Anda tidak memiliki akses kunci ke substruktur. - Walter Mitty

"1NF" digunakan untuk mengartikan banyak hal yang berbeda , banyak yang secara simultan tidak masuk akal dan umum. Lihat jawaban saya untuk "Normalisasi dalam sistem manajemen basis data" , termasuk tautannya. Salah satunya adalah jawaban saya untuk "Apa itu atomisitas dalam dbms" . (Keduanya di Stack Overflow.) - philipxy


Komunitas Wiki menjawab dibuat dari komentar yang tersisa pada pertanyaan

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.