SQL xử lý NULL đặc biệt theo phiên bản 3VL (logic 3 giá trị) của nó. Chuẩn hóa và lý thuyết quan hệ khác thì không. Tuy nhiên, chúng ta có thể dịch các thiết kế SQL thành các thiết kế quan hệ và ngược lại. (Giả sử không có hàng trùng lặp ở đây.)
Bình thường hóa xảy ra với quan hệ và được định nghĩa theo các toán tử không đối xử đặc biệt với NULL. Thuật ngữ "chuẩn hóa" có hai ý nghĩa riêng biệt phổ biến nhất:đặt một bảng thành "1NF" và thành "NFs cao hơn (dạng bình thường)". NULL không ảnh hưởng đến "chuẩn hóa thành 1NF". "Chuẩn hóa thành NF cao hơn" thay thế một bảng bằng các bảng nhỏ hơn kết hợp tự nhiên với nó. Đối với mục đích chuẩn hóa, bạn có thể coi NULL giống như một giá trị được phép trong miền của cột có thể null bên cạnh các giá trị của kiểu SQL của nó. Nếu bảng SQL của chúng ta không có NULL thì chúng ta có thể hiểu chúng là quan hệ &SQL join, v.v. là nối, v.v. Nhưng nếu bạn phân tách nơi chia sẻ cột nullable giữa các thành phần thì hãy nhận ra rằng để tạo lại bản gốc trong SQL, bạn phải tham gia SQL vào các cột cùng tên bằng hoặc cả hai NULL . Và bạn sẽ không muốn các CK (khóa ứng viên) như vậy trong cơ sở dữ liệu SQL. Ví dụ:bạn không thể khai báo nó dưới dạng SQL PK (khóa chính) vì điều đó có nghĩa là KHÔNG ĐỦ KHÔNG ĐỦ. Ví dụ:ràng buộc DUY NHẤT liên quan đến cột có giá trị rỗng cho phép nhiều hàng có giá trị NULL trong cột đó, ngay cả khi các hàng có cùng giá trị trong mọi cột. Ví dụ:NULL trong SQL FK khiến chúng hài lòng (theo nhiều cách khác nhau cho mỗi chế độ MATCH), không để không xuất hiện trong bảng được tham chiếu. (Nhưng DBMSs khác biệt với SQL tiêu chuẩn.)
Thật không may, việc phân tách có thể dẫn đến một bảng có tất cả CK chứa NULL, do đó chúng ta không có gì để khai báo là SQL PK hoặc UNIQUE NOT NULL. Giải pháp chắc chắn duy nhất là chuyển đổi sang thiết kế không có NULL. Sau khi chuẩn hóa, chúng tôi có thể muốn giới thiệu lại một số tính năng vô hiệu hóa trong các thành phần.
Trong thực tế, chúng ta quản lý để thiết kế các bảng sao cho luôn có một tập hợp các cột không chứa NULL mà chúng ta có thể khai báo là CK, thông qua SQL PK hoặc UNIQUE NOT NULL. Sau đó, chúng ta có thể loại bỏ một cột có thể không có giá trị bằng cách loại bỏ nó khỏi bảng và thêm một bảng có cột đó và các cột của một số CK không có NULL:Nếu cột không phải là NULL cho một hàng trong thiết kế cũ thì một hàng có Giá trị cột con và cột CK của nó được đưa vào bảng đã thêm; nếu không thì nó là NULL trong thiết kế cũ và không có hàng tương ứng nào trong bảng được thêm vào. (Bảng gốc là phép nối bên trái tự nhiên của các bảng mới.) Tất nhiên, chúng tôi cũng phải sửa đổi các truy vấn từ thiết kế cũ sang thiết kế mới.
Chúng ta luôn có thể tránh NULL thông qua thiết kế thêm cột boolean cho mỗi cột cũ có thể null và có cột cũ KHÔNG ĐỦ. Cột mới cho biết một hàng liệu cột cũ có phải là NULL trong thiết kế cũ hay không và khi true thì cột cũ là một giá trị nào đó mà chúng tôi chọn cho mục đích đó cho kiểu đó trong toàn bộ cơ sở dữ liệu. Tất nhiên, chúng tôi cũng phải sửa đổi các truy vấn từ thiết kế cũ sang thiết kế mới.
Bạn có muốn tránh NULL hay không là một câu hỏi riêng. Theo một cách nào đó, cơ sở dữ liệu của bạn có thể "tốt hơn" hoặc "tệ hơn" đối với ứng dụng của bạn với một trong hai thiết kế. Ý tưởng đằng sau việc tránh NULL là nó làm phức tạp ý nghĩa của các truy vấn, do đó làm phức tạp việc truy vấn, theo một cách sai lệch, so với sự phức tạp của nhiều phép nối từ nhiều bảng không có NULL hơn. (Nghịch cảnh đó thường được quản lý bằng cách loại bỏ các NULL trong biểu thức truy vấn càng gần vị trí chúng xuất hiện càng tốt.)
PS Nhiều thuật ngữ SQL bao gồm PK &FK khác với các thuật ngữ quan hệ. SQL PK có nghĩa là một cái gì đó giống như superkey hơn; SQL FK có nghĩa là một cái gì đó giống với superkey nước ngoài hơn; nhưng thậm chí không có ý nghĩa gì khi nói về "superkey" trong SQL:
Do sự giống nhau của các bảng SQL với các quan hệ, các thuật ngữ liên quan đến quan hệ được áp dụng một cách cẩu thả cho các bảng. Nhưng mặc dù bạn có thể mượn các thuật ngữ và cung cấp cho chúng ý nghĩa SQL - giá trị, bảng, FD (phụ thuộc hàm), siêu khóa, CK (khóa ứng viên), PK (khóa chính), FK (khóa ngoại), tham gia và, vị từ, NF (dạng bình thường), chuẩn hóa, 1NF, v.v. - bạn không thể chỉ thay thế các nghĩa SQL đó cho các từ đó trong định nghĩa, định lý hoặc thuật toán RM và nhận được điều gì đó hợp lý hoặc đúng. Hơn nữa các bài thuyết trình SQL về khái niệm RM hầu như không bao giờ thực sự cho bạn biết cách áp dụng đúng các khái niệm RM vào cơ sở dữ liệu SQL . Họ chỉ đọc vẹt các bài thuyết trình của RM, không biết liệu việc sử dụng các ý nghĩa SQL của họ cho các thuật ngữ có khiến mọi thứ trở nên vô nghĩa hay không hợp lệ hay không.
