SQL memperlakukan NULL secara khusus per versi 3VL (logika bernilai 3). Normalisasi &teori relasional lainnya tidak. Namun, kami dapat menerjemahkan desain SQL ke dalam desain relasional dan sebaliknya. (Asumsikan tidak ada baris duplikat di sini.)
Normalisasi terjadi pada hubungan dan didefinisikan dalam istilah operator yang tidak memperlakukan NULL secara khusus. Istilah "normalisasi" memiliki dua arti berbeda yang paling umum:menempatkan tabel ke dalam "1NF" dan ke dalam "NF yang lebih tinggi (bentuk normal)". NULL tidak memengaruhi "normalisasi ke 1NF". "Normalisasi ke NF yang lebih tinggi" menggantikan tabel dengan tabel yang lebih kecil yang bergabung kembali secara alami. Untuk tujuan normalisasi, Anda dapat memperlakukan NULL seperti nilai yang diizinkan dalam domain kolom yang dapat dibatalkan selain nilai tipe SQL-nya. Jika tabel SQL kami tidak memiliki NULL maka kami dapat menafsirkannya sebagai relasi &SQL join dll sebagai join, dll. Tetapi jika Anda menguraikan di mana kolom nullable dibagikan di antara komponen, maka sadarilah bahwa untuk merekonstruksi aslinya dalam SQL Anda harus bergabung dengan SQL kolom dengan nama yang sama sama dengan atau keduanya NULL . Dan Anda tidak akan menginginkan CK (kandidat kunci) seperti itu dalam database SQL. Misalnya Anda tidak dapat mendeklarasikannya sebagai SQL PK (kunci utama) karena itu berarti UNIQUE NOT NULL. Misalnya kendala UNIK yang melibatkan kolom nullable memungkinkan beberapa baris yang memiliki NULL di kolom itu, bahkan jika baris memiliki nilai yang sama di setiap kolom. Misalnya NULL dalam SQL FKs menyebabkan mereka puas (dalam berbagai cara per mode MATCH), tidak gagal karena tidak muncul di tabel yang direferensikan. (Tetapi DBMS sangat berbeda dari SQL standar.)
Sayangnya dekomposisi mungkin mengarah ke tabel dengan semua CK berisi NULL, sehingga tidak ada yang bisa kita deklarasikan sebagai SQL PK atau UNIQUE NOT NULL. Satu-satunya solusi pasti adalah mengonversi ke desain bebas NULL. Setelah menormalkan, kami mungkin ingin memperkenalkan kembali beberapa nullability dalam komponen.
Dalam praktiknya, kami berhasil mendesain tabel sehingga selalu ada kumpulan kolom bebas NULL yang dapat kami deklarasikan sebagai CK, melalui SQL PK atau UNIQUE NOT NULL. Kemudian kita dapat menyingkirkan kolom yang dapat dibatalkan dengan menjatuhkannya dari tabel dan menambahkan tabel dengan kolom itu dan kolom dari beberapa CK bebas NULL:Jika kolom tersebut bukan NULL untuk baris dalam desain lama maka baris dengan subrow CK dan nilai kolomnya masuk ke tabel yang ditambahkan; selain itu NULL dalam desain lama dan tidak ada baris yang sesuai di tabel yang ditambahkan. (Tabel asli adalah gabungan kiri alami dari yang baru.) Tentu saja, kita juga harus mengubah kueri dari desain lama ke desain baru.
Kami selalu dapat menghindari NULL melalui desain yang menambahkan kolom boolean untuk setiap kolom nullable lama dan memiliki kolom lama NOT NULL. Kolom baru mengatakan untuk satu baris apakah kolom lama adalah NULL dalam desain lama dan ketika true memiliki kolom lama menjadi satu nilai yang kami pilih untuk tujuan itu untuk jenis itu di seluruh database. Tentu saja, kita juga harus mengubah kueri dari desain lama ke desain baru.
Apakah Anda ingin menghindari NULL adalah pertanyaan terpisah. Basis data Anda mungkin dalam beberapa hal menjadi "lebih baik" atau "lebih buruk" untuk aplikasi Anda dengan salah satu desain. Gagasan di balik menghindari NULL adalah bahwa hal itu memperumit arti kueri, karenanya memperumit kueri, dengan cara yang salah, dibandingkan dengan komplikasi lebih banyak gabungan dari lebih banyak tabel bebas NULL. (Kejahatan itu biasanya dikelola dengan menghapus NULL dalam ekspresi kueri sedekat mungkin dengan tempat kemunculannya.)
PS Banyak istilah SQL termasuk PK &FK berbeda dari istilah relasional. SQL PK berarti sesuatu yang lebih seperti superkey; SQL FK berarti sesuatu yang lebih seperti superkey asing; tetapi bahkan tidak masuk akal untuk berbicara tentang "superkey" dalam SQL:
Karena kemiripan tabel SQL dengan relasi, istilah yang melibatkan relasi diterapkan secara sembarangan ke tabel. Tetapi meskipun Anda dapat meminjam istilah dan memberi mereka arti SQL--nilai, tabel, FD (ketergantungan fungsional), superkey, CK (kunci kandidat), PK (kunci utama), FK (kunci asing), gabung, dan, predikat, NF (bentuk normal), normalisasi, 1NF, dll--Anda tidak bisa hanya mengganti arti SQL itu dengan kata-kata itu dalam definisi RM, teorema, atau algoritme dan mendapatkan sesuatu yang masuk akal atau benar. Selain itu, presentasi SQL dari gagasan RM hampir tidak pernah sebenarnya memberi tahu Anda cara menerapkan gagasan RM dengan baik ke database SQL . Mereka hanya menirukan presentasi RM, tidak menyadari apakah penggunaan arti SQL untuk istilah membuat hal-hal menjadi tidak masuk akal atau tidak valid.
