Làm gì với giá trị null khi lập mô hình và chuẩn hóa?

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.)

Chuẩn hóa xảy ra với các quan hệ và được định nghĩa theo các toán tử không xử lý đặc biệt NULL. Thuật ngữ " bình thường hóa"có hai ý nghĩa riêng biệt phổ biến nhất: đặt bảng thành" 1NF "và thành" NF 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. nối lại 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 cho 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 tham gia, v.v. dưới dạng tham gia, v.v. Nhưng nếu bạn phân tách nơi một cột có thể không được chia sẻ giữa các thành phần thì nhận ra rằng để tạo lại bản gốc trong SQL, bạn phải tham gia SQL trên các cột cùng tên bằng nhau hoặc cả hai. Và bạn sẽ không muốn các CK như vậy (khóa ứng viên) 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 một cột có thể rỗng cho phép nhiều hàng có 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 rã có thể dẫn đến 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ế 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 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. Chúng ta có thể loại bỏ một cột có giá trị rỗng không có trong tất cả các CK không có NULL 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 có NULL cho một hàng trong thiết kế cũ, sau đó một hàng có giá trị cột con và cột CK của nó sẽ đượ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. 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 một thiết kế thêm cột cờ cho biết một cột có thể null trước đó có phải là NULL trong thiết kế cũ hay không và nếu có cột đó là một giá trị nào đó mà chúng ta chọn cho mục đích đó cho loại đó trong suốt 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ầm, 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 các biểu thức truy vấn càng gần nơi 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, siêu khóa, CK, PK, FK, nối và, vị từ, NF, chuẩn hóa, v.v.), bạn không thể thay thế các nghĩa SQL đó cho những từ đó trong RM định nghĩa, định lý hoặc thuật toán và nhận được một cái 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 khái niệm RM vào cơ sở dữ liệu SQL một cách hợp lý . Họ chỉ nói vẹt các bài thuyết trình của RM, không biết liệu việc họ sử dụng các ý nghĩa SQL cho các thuật ngữ có làm cho mọi thứ trở nên vô nghĩa hay không hợp lệ hay không.

Trước hết, không có gì sai với null trong cơ sở dữ liệu. Và chúng được tạo ra chính xác cho mục đích này, nơi các thuộc tính chưa được biết đến. Để tránh null trong một cơ sở dữ liệu là một lời khuyên có ý nghĩa nhỏ theo quan điểm của tôi.

Vì vậy, bạn sẽ có ba (hoặc bốn) giá trị - tên (họ / tên), địa chỉ email và số điện thoại - xác định khách hàng. Bạn có thể có chúng trong một bảng và thêm một ràng buộc vào nó để đảm bảo rằng luôn luôn có ít nhất một trong những cột này được lấp đầy, ví dụ coalesce(name, email, phone) is not null. Điều này đảm bảo việc đặt phòng không thể được thực hiện hoàn toàn ẩn danh.

Từ lời giải thích của bạn, không rõ liệu bạn có luôn nhận được cùng một thông tin từ khách hàng hay không. Vì vậy, có thể xảy ra trường hợp khách hàng đặt phòng bằng tên của họ và sau đó họ đặt phòng khác đưa điện thoại của họ thay thế? Hay khách hàng sẽ được tra cứu trong cơ sở dữ liệu, tên của họ được tìm thấy và hai đặt chỗ được chỉ định cho họ? Trong trường hợp thứ hai, bạn có thể có một bảng khách hàng chứa tất cả thông tin bạn nhận được cho đến nay và đặt chỗ sẽ chứa ID hồ sơ khách hàng như một tham chiếu đến dữ liệu này. Trong trường hợp trước đây, bạn có thể không muốn có bảng khách hàng, vì bạn không thể xác định được liệu hai khách hàng (Jane Miller và mrsx@gmail.com) có thực sự là hai khách hàng khác nhau hay chỉ một khách hàng thực sự.

Các bảng tôi thấy cho đến nay:

• room (room_id, ...)
• địa điểm (venue_id, ...)
• khách hàng (client_id, tên, email, điện thoại)
• đặt phòng (địa điểm_id, room_id, client_id, ...)