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 đó.[1] Đị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ử.[2] Đâ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í:[3]
- 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[sửa | sửa mã nguồn]
| “ |
Lược đồ quan hệ R ở dạng chuẩn 1(1NF-First Normal Form) nếu mọi thuộc tính của R đều chứa các giá trị nguyên tố (atomic value), giá trị này không là một danh sách các giá trị hoặc giá trị phức hợp (composite value) |
” |
| — Hệ Cơ Sở Dữ Liệu: Dương Tuấn Anh, Nguyễn Trung Trực - Nhà Xuất Bản ĐHQG Thành phố Hồ Chí Minh | ||
Ví dụ[sửa | sửa mã nguồn]
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ủ.[4][5]
Các thiết kế vi phạm 1NF[sửa | sửa mã nguồn]
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ị:
| Customer ID | First Name | Surname | Telephone Number |
|---|---|---|---|
| 123 | Pooja | Singh | 555-861-2025, 192-122-1111 |
| 456 | San | Zhang | (555) 403-1659 Ext. 53; 182-929-2929 |
| 789 | John | Doe | 555-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:
| Customer ID | First Name | Surname | Telephone Number1 | Telephone Number2 |
|---|---|---|---|---|
| 123 | Pooja | Singh | 555-861-2025 | 192-122-1111 |
| 456 | San | Zhang | (555) 403-1659 Ext. 53 | 182-929-2929 |
| 789 | John | Doe | 555-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[sửa | sửa mã nguồn]
Để đư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.
| Customer ID | First Name | Surname | Telephone Number |
|---|---|---|---|
| 123 | Pooja | Singh | 555-861-2025 |
| 123 | Pooja | Singh | 192-122-1111 |
| 456 | San | Zhang | 182-929-2929 |
| 456 | San | Zhang | (555) 403-1659 Ext. 53 |
| 789 | John | Doe | 555-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:
|
|
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.[6] Đ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ố[sửa | sửa mã nguồn]
Đị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."[7] 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)"[8] 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.[9][10] 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":[11][12] 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ệ[sửa | sửa mã nguồn]
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:[13]
- Không có thứ tự từ trên xuống dưới cho các hàng.
- Không có thứ tự từ trái sang phải vào các cột..
- Không có hàng trùng lặp.
- Mỗi giao lộ hàng và cột chứa chính xác một giá trị từ miền áp dụng (và không có gì khác).
- Tất cả các cột là liền mạch [tức là các hàng không có các thành phần ẩn như ID hàng, ID đối tượng hoặc dấu thời gian ẩn].
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ệ,[14] đã đưa ra quy định rõ ràng cho null.[15]
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.[16]
Xem thêm[sửa | sửa mã nguồn]
Đọc thêm[sửa | sửa mã nguồn]
- Date, C. J., & Lorentzos, N., & Darwen, H. (2002). Temporal Data & the Relational Model Lưu trữ 2012-12-09 tại Archive.today (1st ed.). Morgan Kaufmann. ISBN 1-55860-855-9.
- Date, C. J. (1999), An Introduction to Database Systems (8th ed.). Addison-Wesley Longman. ISBN 0-321-19784-4.
- 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[sửa | sửa mã nguồn]
- ^ Elmasri, Ramez; Navathe, Shamkant B. (tháng 7 năm 2003). Fundamentals of Database Systems, Fourth Edition. Pearson. tr. 315. ISBN 0321204484.
It states that the domain of an attribute must include only atomic (simple, indivisible) values and that the value of any attribute in a tuple must be a single value from the domain of that attribute.
- ^ E. F. Codd (tháng 10 năm 1972), Further normalization of the database relational model, Courant Institute: Prentice-Hall, ISBN 013196741X,
A relation is in first normal form if it has the property that none of its domains has elements which are themselves sets.
Đã bỏ qua tham số không rõ|book-title=(trợ giúp) - ^ Watt, Adrienne; Eng, Nelson (2014). Database Design - 2nd Edition. Victoria, B.C: BCcampus.
- ^ studytonight.com
- ^ stackoverflow.com
- ^ In the "real" world, that would not be a good assumption.
- ^ Codd, E. F. The Relational Model for Database Management Version 2 (Addison-Wesley, 1990).
- ^ Codd, E. F. The Relational Model for Database Management Version 2 (Addison-Wesley, 1990), p. 6.
- ^ 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
- ^ Date, C. J. ["What First Normal Form Really Means"] p. 112.
- ^ C.J. Date (ngày 6 tháng 11 năm 2015). SQL and Relational Theory: How to Write Accurate SQL Code. "O'Reilly Media, Inc.". tr. 50–. ISBN 978-1-4919-4115-7. Truy cập ngày 31 tháng 10 năm 2018.
- ^ Date, C. J. ["What First Normal Form Really Means"] pp. 127–128.
- ^ "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.
- ^ 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.
- ^ Date, C. J. ["What First Normal Form Really Means"] pp. 121–126.