Dạng chuẩn 1

Dạng chuẩn 1 (1NF) là một thuộc tính của quan hệ trong cơ sở dữ liệu quan hệ. Quan hệ là 1NF khi và chỉ khi miền của mỗi thuộc tính chỉ chứa các giá trị nguyên tố(không thể phân chia) và giá trị của mỗi thuộc tính chỉ chứa một giá trị từ miền đó. Định nghĩa đầu tiên của thuật ngữ này, trong một hội nghị năm 1971 của Edgar Codd, đã định nghĩa một mối quan hệ ở dạng 1NF khi không có miền nào của nó có bất kỳ tập hợp nào dưới dạng các phần tử. Đây là dạng chuẩn ở mức thấp nhất và là điều kiện cần cho các dạng chuẩn cao hơn như Dạng chuẩn 2 (2NF), Dạng chuẩn 3 (3NF), Dạng chuẩn Boyce-Codd (BCNF)...

1NF là một thuộc tính thiết yếu của một mối quan hệ trong cơ sở dữ liệu quan hệ. Chuẩn hóa cơ sở dữ liệu là quá trình biểu diễn cơ sở dữ liệu theo quan hệ dưới dạng chuẩn, trong đó 1NF là một yêu cầu tối thiểu..

1NF bao gồm các tiêu chí:

Loại bỏ các nhóm lặp lại trong các bảng riêng lẻ
Tạo một bảng riêng cho từng bộ dữ liệu liên quan
Xác định từng bộ dữ liệu liên quan bằng khóa chính

Định nghĩa

Ví dụ
Các kịch bản sau đây trước tiên minh họa cách thiết kế cơ sở dữ liệu có thể vi phạm 1NF, theo sau là các ví dụ tuân thủ.studytonight.comstackoverflow.com

 Các thiết kế vi phạm 1NF 
Dưới đây là bảng lưu trữ tên và số điện thoại của khách hàng. Một yêu cầu mặc dù là giữ lại nhiều số điện thoại cho một số khách hàng. Cách đơn giản nhất để đáp ứng yêu cầu này là cho phép các hàng trong cột "Telephone Number" chứa nhiều hơn một giá trị:

+ CustomerCustomer ID  First Name  Surname  Telephone Number123PoojaSingh555-861-2025, 192-122-1111456SanZhang(555) 403-1659 Ext. 53; 182-929-2929789JohnDoe555-808-9633

Cột số điện thoại chứa nhiều số điện thoại trong một giá trị. Ví dụ: hàng đầu tiên có hai số điện thoại được phân tách bằng dấu phẩy. Các giá trị cột không phải là nguyên tố: nó có thể được chia thành hai số. Điều này vi phạm 1NF.

Một giải pháp rõ ràng là đưa ra nhiều cột hơn:

+ CustomerCustomer ID  First Name  Surname  Telephone Number1  Telephone Number2123PoojaSingh555-861-2025  192-122-1111456SanZhang(555) 403-1659 Ext. 53  182-929-2929789JohnDoe555-808-9633 

Về mặt kỹ thuật, bảng này không vi phạm yêu cầu về giá trị là nguyên tố. Tuy nhiên, một cách không chính thức, hai cột số điện thoại vẫn tạo thành một "nhóm lặp lại": chúng lặp lại những gì thuộc về khái niệm cùng thuộc tính, cụ thể là số điện thoại. Một thứ tự tùy ý và do đó vô nghĩa đã được đưa ra: tại sao 555-861-2025 được đưa vào cột Số điện thoại1 thay vì cột Số điện thoại2? Không có lý do tại sao khách hàng không thể có nhiều hơn hai số điện thoại, vậy nên có bao nhiêu cột Số điện thoại? Không thể tìm kiếm số điện thoại mà không tìm kiếm số cột tùy ý. Thêm một số điện thoại bổ sung có thể yêu cầu bảng được sắp xếp lại bằng cách thêm một cột mới thay vì chỉ có một hàng mới (tuple) được thêm vào. (Giá trị null cho Số điện thoại2 cho khách hàng 789 cũng là một vấn đề.)

Thiết kế tuân thủ 1NF

Để đưa mô hình về dạng 1NF, chúng tôi chia các chuỗi mà chúng tôi đã sử dụng để giữ thông tin số điện thoại của mình thành các thực thể "nguyên tố" (nghĩa là không thể chia tách): các số điện thoại. Và chúng tôi đảm bảo không có hàng nào chứa nhiều hơn một số điện thoại.

+ CustomerCustomer ID  First Name  Surname  Telephone Number123PoojaSingh555-861-2025123PoojaSingh192-122-1111456SanZhang182-929-2929456SanZhang(555) 403-1659 Ext. 53789JohnDoe555-808-9633

Lưu ý rằng "ID" không còn là duy nhất trong giải pháp này với các khách hàng trùng lặp. Để xác định duy nhất một hàng, chúng ta cần sử dụng kết hợp (ID, Số điện thoại). Giá trị của sự kết hợp là duy nhất mặc dù mỗi cột riêng biệt chứa các giá trị lặp lại. Có thể xác định duy nhất một hàng (tuple) là yêu cầu của 1NF.

Một thiết kế thay thế, sử dụng hai bảng:
+ Customer NameCustomer ID  First Name  Surname123Pooja	Singh456SanZhang789JohnDoe+ Customer Telephone NumberId  Customer ID  Telephone Number1123555-861-20252123192-122-11113456(555) 403-1659 Ext. 53 4456182-929-29295789555-808-9633
Các cột không chứa nhiều hơn một số điện thoại trong thiết kế này. Thay vào đó, mỗi liên kết Customer-to-Telephone Number xuất hiện trên hàng riêng của mình. Sử dụngCustomer ID làm khoá chính, tồn tại mối quan hệ một-nhiều giữa tên và bảng số. Một hàng trong bảng "cha", Customer Name, có thể được liên kết với nhiều hàng số điện thoại trong bảng "con", Customer Telephone Number, nhưng mỗi số điện thoại thuộc về một và chỉ một khách hàng.In the "real" world, that would not be a good assumption. Điều đáng chú ý là thiết kế này đáp ứng các yêu cầu bổ sung cho Dạng chuẩn hai (2NF) và ba(3NF).

Nguyên tố
Định nghĩa 1NF của Edgar F. Codd đưa ra tham chiếu đến khái niệm 'nguyên tố'. Codd tuyên bố rằng "các giá trị trong các miền mà mỗi quan hệ được xác định là bắt buộc phải là nguyên tố đối với DBMS."Codd, E. F. The Relational Model for Database Management Version 2 (Addison-Wesley, 1990). Codd định nghĩa một giá trị nguyên tố là một giá trị "không thể phân tách thành các phần nhỏ hơn bởi DBMS (không bao gồm các hàm đặc biệt nhất định)"Codd, E. F. The Relational Model for Database Management Version 2 (Addison-Wesley, 1990), p. 6. có nghĩa là một cột không nên được chia thành các phần có nhiều hơn một loại dữ liệu trong đó sao cho một phần có nghĩa là DBMS phụ thuộc vào một phần khác của cùng một cột.

Hugh Darwen và Chris Date đã gợi ý rằng khái niệm "giá trị nguyên tố" của Codd là mơ hồ và rằng sự mơ hồ này đã dẫn đến sự nhầm lẫn phổ biến về cách hiểu 1NF.Darwen, Hugh. "Relation-Valued Attributes; or, Will the Real First Normal Form Please Stand Up?", in C. J. Date and Hugh Darwen, Relational Database Writings 1989-1991 (Addison-Wesley, 1992)."[F]or many years," writes Date, "I was as confused as anyone else. What's worse, I did my best (worst?) to spread that confusion through my writings, seminars, and other presentations." Date, C. J. ["What First Normal Form Really Means"] in Date on Database: Writings 2000-2006 (Springer-Verlag, 2006), p. 108 Cụ thể, khái niệm "giá trị không thể phân tách" là có vấn đề, vì dường như nó ám chỉ rằng rất ít, nếu có, các loại dữ liệu là nguyên tử:

Một chuỗi ký tự dường như không phải là nguyên tố, vì RDBMS thường cung cấp các toán tử để phân tách nó thành chuỗi con.
Một số nguyên dường như không phải là nguyên tố, vì RDBMS thường cung cấp các toán tử để phân tách nó thành các thành phần nguyên và phân số.
 Một ISBN dường như không phải là nguyên tử, vì nó bao gồm định danh ngôn ngữ và nhà xuất bản.
Date gợi ý rằng "khái niệm nguyên tử không có ý nghĩa tuyệt đối":Date, C. J. ["What First Normal Form Really Means"] p. 112. một giá trị có thể được coi là nguyên tố cho một số mục đích, nhưng có thể được coi là tập hợp các giá trị cho các mục đích khác. Nếu tình huống giá trị được coi là tập hợp, 1NF không thể được xác lập. Các cột của bất kỳ loại dữ liệu cơ bản nào (từ kiểu chuỗi và kiểu số đến kiểu mảng và kiểu bảng) đều được chấp nhận trong bảng 1NF, mặc dù có lẽ không phải lúc nào cũng mong muốn; ví dụ, có thể mong muốn hơn khi tách một cột Customer Name thành hai cột riêng biệt như First Name, Surname.

 Bảng 1NF là đại diện của quan hệ 
Theo định nghĩa của Date, một bảng ở dạng 1NF khi và chỉ khi nó "đẳng cấu với quan hệ",có nghĩa là, cụ thể, nó thỏa mãn năm điều kiện sau:Date, C. J. ["What First Normal Form Really Means"] pp. 127–128.

Vi phạm bất kỳ điều kiện nào trong số này có nghĩa là bảng không quan hệ chặt chẽ, và do đó nó không ở dạng 1NF.

Ví dụ về các bảng (hoặc view) không đáp ứng định nghĩa về dạng thông thường đầu tiên này là:

Một bảng thiếu một ràng buộc khóa duy nhất. Một bảng như vậy sẽ có thể chứa các hàng trùng lặp, vi phạm điều kiện 3.
Một view có định nghĩa bắt buộc các kết quả được trả về theo một thứ tự cụ thể, để thứ tự hàng là một khía cạnh nội tại và có ý nghĩa của view. Điều này vi phạm điều kiện 1. Các bộ dữ liệu trong quan hệ thực sự không được ra lệnh đối với nhau.
Một bảng có ít nhất một thuộc tính nullable. Một thuộc tính nullable sẽ vi phạm điều kiện 4, yêu cầu mỗi cột phải chứa chính xác một giá trị từ miền của cột. Khía cạnh của điều kiện 4 đang gây tranh cãi.Nó đánh dấu một sự khởi đầu quan trọng từ tầm nhìn sau này của Codd về mô hình quan hệ,"Codd first defined the relational model in 1969 and didn't introduce nulls until 1979" Date, C. J. SQL and Relational Theory (O'Reilly, 2009), Appendix A.2. đã đưa ra quy định rõ ràng cho null.The third of Codd's 12 rules states that "Null values... [must be] supported in a fully relational DBMS for representing missing information and inapplicable information in a systematic way, independent of data type." Codd, E. F. "Is Your DBMS Really Relational?" Computerworld, ngày 14 tháng 10 năm 1985.
Dạng chuẩn 1, như được định nghĩa bởi Chris Date, cho phép các thuộc tính có giá trị quan hệ (các bảng trong bảng). Date lập luận rằng các thuộc tính có giá trị là một quan hệ (hoặc bảng), là có ích trong một số trường hợp hiếm hoi.Date, C. J. ["What First Normal Form Really Means"] pp. 121–126.

Xem thêm

 Dạng chuẩn 2
 Dạng chuẩn 3
 Dạng chuẩn 4
 Dạng chuẩn Boyce-Codd

Đọc thêm

 Date, C. J., & Lorentzos, N., & Darwen, H. (2002). Temporal Data & the Relational Model  (1st ed.). Morgan Kaufmann. .
 Date, C. J. (1999), An Introduction to Database Systems (8th ed.). Addison-Wesley Longman. .
 Kent, K. F. C. (1983) A Simple Guide to Five Normal Forms in Relational Database Theory, Communications of the ACM, vol. 26, pp. 120–125
 Codd, E.F. (1970). A Relational Model of Data for. Large Shared Data Banks. IBM Research Laboratory, San Jose, California.
 Codd, E. F. (1971). Further Normalization of the Relational Model. Courant Computer Science Symposium 6 in Data Base Systems edited by Rustin, R.

Tham khảo

Thể loại:Chuẩn hóa dữ liệu