Tôi đang cố gắng để có được một phiên bản dứt khoát của Mẫu bình thường đầu tiên. Tất cả mọi thứ tôi đọc có một spin hơi khác nhau.

Nhiều nhà chức trách, chẳng hạn như Date, nói rằng theo định nghĩa, một mối quan hệ luôn ở Dạng thông thường đầu tiên, trong khi những người khác đưa ra một danh sách các yêu cầu. Điều này có nghĩa là có từ 0 đến nhiều yêu cầu cho 1NF.

Tôi cho rằng sự khác biệt là giữa các bảng và các mối quan hệ: các bảng có thể là một mớ hỗn độn hoàn toàn, trong khi một mối quan hệ tuân theo các hạn chế nhất định. Thực tế là một mối quan hệ được biểu diễn dưới dạng bảng trong SQL do đó tạo ra một số nhầm lẫn.

Tôi đang tập trung cụ thể vào 1NF vì nó liên quan đến cơ sở dữ liệu SQL. Câu hỏi là: những thuộc tính nào được yêu cầu để đảm bảo rằng một bảng ở dạng bình thường đầu tiên?

Nhiều nhà chức trách đề nghị rằng nếu một bảng biểu thị một mối quan hệ , thì nó đã có trong 1NF. Điều này đẩy định nghĩa của 1NF trở lại định nghĩa về mối quan hệ.

Dưới đây là một số thuộc tính của bảng trong 1NF:

• Thứ tự cột không đáng kể [1]
• Hàng Rows là không đáng kể
• Tất cả các hàng có cùng độ dài (nghĩa là dữ liệu hàng khớp với các tiêu đề cột)
• Không có hàng trùng lặp (điều này có thể được đảm bảo bằng khóa chính thay thế, nhưng bản thân PK không bắt buộc)
• Không có cột lặp lại
• Mỗi cột có chứa một đơn giá trị (nguyên tử)

[1] Các thuộc tính kỹ thuật không được sắp xếp theo thứ tự, nhưng trong một bảng, dữ liệu hàng phải theo cùng thứ tự với các tiêu đề cột. Tuy nhiên, thứ tự thực tế là không đáng kể.

Trên nhiều dữ liệu :

Khái niệm dữ liệu nguyên tử là một vật phẩm không thể bị phá vỡ thêm. Khái niệm này đã có trình độ ở chỗ mặc dù về mặt kỹ thuật tất cả mọi thứ có thể được chia nhỏ quảng cáo nauseum , dữ liệu trong câu hỏi có thể không được thực tế được chia nhỏ thêm nữa, tùy thuộc vào cách dữ liệu sẽ được sử dụng.

Ví dụ: địa chỉ đầy đủ hoặc tên đầy đủ thường được chia nhỏ hơn, nhưng các thành phần như tên đã cho hoặc tên thị trấn có thể không được chia nhỏ thêm nữa, mặc dù thực tế là có thể là chuỗi.

Đối với các cột lặp lại, đó là một cột thiết kế kém để có các cột gần như lặp lại, chẳng hạn như phone1, phone2v.v. Nói chung, dữ liệu lặp lại cho thấy sự cần thiết của một bảng liên quan bổ sung.

Sự phụ thuộc

Không nên có bất kỳ mối quan hệ nào giữa các hàng, ngoài việc chúng tuân thủ cùng các tiêu đề.

Cũng không nên có mối quan hệ giữa các cột, nhưng tôi tin rằng đó là chủ đề của các hình thức bình thường cao hơn.

Câu hỏi là: Bao nhiêu phần trên trong định nghĩa của 1NF? Liệu các hàng độc lập bit cũng đi vào nó?

Sơ bộ

Định nghĩa của hình thức bình thường (mà từ phần trình bày của “Bình thường hóa hơn nữa về Cơ sở dữ liệu Relational Model” năm 1971 được gọi là hình thức bình thường đầu tiên ) và các định nghĩa của mô hình quan hệ riêng của mình được xuất bản vào năm 1970 trong bài báo khoa học đã cung cấp một mạnh mẽ nền tảng cho việc thực hành quản lý cơ sở dữ liệu, tức là, “một Relational Model của dữ liệu để chia sẻ rộng rãi dữ liệu ngân hàng” (RM cho ngắn gọn) được tạo ra bởi Tiến sĩ EF Codd , là người nhận giải thưởng Turing và các quyền liên quan đến các khuôn khổ quan hệ với.

Vâng, có rất nhiều giải thích, giải thích, giải thích, sai lệch và ý kiến ​​về văn bản của Tiến sĩ Codd, nhưng cá nhân tôi thích bám vào nguồn gốc và tôi khuyên bạn nên tự mình phân tích nó để bạn có thể tự rút ra kết luận.

Tôi chắc chắn không hiểu toàn bộ RM, nhưng những gì tôi hiểu về nó cho phép tôi đánh giá cao sự xuất sắc, tầm nhìn, ý định và phạm vi của nó, và mặc dù nhiều thập kỷ sau, người ta có thể lưu ý rằng nó có một vài sự thiếu sót nhẹ, nhưng chúng không giảm, trong bất kỳ cách nào, thiên tài và thanh lịch của nó. Trong lĩnh vực của mình, RM đã đứng trước thử thách của thời gian theo một cách riêng, và vẫn chưa từng có.

Hành động nhấn mạnh các quy định đã nói ở trên sẽ là sử dụng thuật ngữ từ thiện, vì không công bằng vì nhìn thấy nó từ một khoảng cách đáng kể, tài liệu tinh xảo này đòi hỏi một số tinh chỉnh và mở rộng, vâng, nhưng cơ thể chính của tác phẩm là đá rắn từ rất quan niệm (và, thực sự, Tiến sĩ Codd đã tạo ra hầu hết các dòngifif không phải tất cả các bản tinh chỉnh và phần mở rộng như vậy).

Tôi tiếp tục đọc lại RM liên tục để tăng cường sự hiểu biết của tôi về nguồn kiến ​​thức đặc biệt này (và lòng tự trọng của tôi về nó tiếp tục phát triển trên mỗi lần đọc lại); Mục tiêu là đứng trên vai những người khổng lồ.

Quan hệ và bảng

Điều quan trọng cần lưu ý là vì các mối quan hệ là tài nguyên trừu tượng , Tiến sĩ Codd đã hình dung ra tiện ích của việc biểu diễn chúng dưới dạng bảng (ban đầu, ông sử dụng thuật ngữ biểu diễn mảng mảng nhưng sau đó sử dụng bảng Bảng hoặc hoặc bảng r người dùng, nhà thiết kế và quản trị viên của cơ sở dữ liệu quan hệ (RDB) có thể tiếp cận họ theo cách quen thuộc hoặc cụ thể hơn. Do đó, trong bối cảnh triển khai RDB, việc sử dụng bảng làm tốc ký cho quan hệ là hợp lệ, miễn là bảng nói là viết tắt của một mối quan hệ thực tế. Tính năng này rõ ràng là rất rõ ràng bởi vì trước khi đánh giá liệu một bảng có đại diện cho một mối quan hệ tuân theo hình thức bình thường đầu tiên (1NF) hay không, nó phải thể hiện, chính xác là một mối quan hệ.

RM tự nhiên chứa đựng những phẩm chất mà một bảng phải xác định nếu trên thực tế nó mô tả một mối quan hệ, nhưng tôi sẽ đưa ra một cách giải thích không chính thức và không khoa trương về chúng ở đây (một số khác, vâng!):

• Nó phải có một tên (mỗi quan hệ cụ thể trong cấu trúc cơ sở dữ liệu phải được phân biệt với phần còn lại).
• Mỗi hàng của nó phải mô tả chính xác một tuple của mối quan hệ thích hợp.
• Thứ tự của các hàng của nó không quan trọng chút nào.
• Mỗi cột của nó phải có một tên đại diện cho ý nghĩa của chính xác một miền của mối quan hệ liên quan và tên đã nói phải khác với tên của các cột còn lại của bảng (một cột phải được phân biệt duy nhất và phải mang một ý nghĩa đặc biệt và, vâng, vai trò của một người lập mô hình cơ sở dữ liệu và các chuyên gia kinh doanh để xác định từng miền có ý nghĩa với độ chính xác là tối quan trọng)
• Thứ tự các cột của nó không có ý nghĩa.
• Tất cả các hàng của nó phải có cùng số cột.
• Nó phải có ít nhất một cột hoặc một tổ hợp các cột, xác định duy nhất mỗi một bộ dữ liệu được mô tả qua các hàng; theo cách này, tất cả các hàng phải khác nhau (vâng, điều này nhấn mạnh tầm quan trọng của việc có ít nhất một KEY được khai báo và khi có hai hoặc nhiều KEY phải được định nghĩa là CHÍNH dựa trên lý do thực tế, trong khi phần còn lại có thể được coi là THAY ĐỔI, nhưng đúng vậy, trước khi đưa ra quyết định, mỗi TỪ KHÓA là một ứng cử viên của LÊ cho một định nghĩa là CHÍNH HÃNG).

Có một bảng trong thực tế đại diện cho một mối quan hệ là rất quan trọng, khi nó trải qua các hoạt động thao tác của một loại quan hệ, thì kết quả lại là một bảng đại diện cho một mối quan hệ. Theo cách này, hành vi của bảng nói là có thể dự đoán được .

Miền nguyên tử (cột)

Trong các phần đầu tiên của RM, Tiến sĩ Codd trình bày một số mẫu quan hệ để giới thiệu một số khái niệm; vì vậy, để hiểu ý nghĩa của miền nguyên tử , chúng ta hãy bắt đầu với đoạn trích sau từ RM mô tả chi tiết một số điểm thích hợp:

Cho đến nay, chúng ta đã thảo luận về các ví dụ về các mối quan hệ được xác định trên các miền đơn giản Các miền tên miền có các phần tử là các giá trị nguyên tử (không thể phân tách). Các giá trị phi nguyên tử có thể được thảo luận trong khuôn khổ quan hệ. Vì vậy, một số lĩnh vực có thể có quan hệ là các yếu tố. Lần lượt, các mối quan hệ này có thể được xác định trên các miền không rõ ràng, v.v.

Theo cách này, người ta có thể nói rằng mỗi quan hệ lưu trữ đã nói ở trên phù hợp với một trong hai loại, nói loại A hoặc loại B :

• Loại A chỉ các quan hệ (bảng) được cấu trúc với các miền (cột) chỉ chứa các giá trị đơn giản trong mỗi bộ dữ liệu (hàng) của chúng, tức là các miền (cột) đó không chứa quan hệ (bảng) làm giá trị, trong đó bối cảnh này có nghĩa là các giá trị là nguyên tử vì chúng không thể được phân tách liên tiếp thành các quan hệ mới (bảng). Do đó, các mối quan hệ của lớp này là những mối quan hệ được chuẩn hóa , nghĩa là, chúng tuân thủ 1NF, hình thức của chúng là mong muốn.

• Loại B được tích hợp độc quyền bởi các mối quan hệ (bảng) có một hoặc nhiều tên miền (cột) giữ quan hệ dưới dạng giá trị trong mỗi bộ (hàng) tương ứng và điều đó biểu thị rằng các giá trị đó là không tương tự vì sau đó chúng có thể được chia thành các quan hệ mới (bảng), tức là chúng có thể phân tách được . Do đó, các mối quan hệ của loại này là không bình thường, tức là chúng vi phạm 1NF, chúng ở dạng không mong muốn.

Bình thường hóa

Tiến sĩ Codd giới thiệu phần về bình thường hóa trong RM với đoạn văn sau:

Một mối quan hệ có các miền hoàn toàn đơn giản có thể được biểu diễn trong bộ lưu trữ bằng một cột hai chiều - mảng đồng nhất của loại được thảo luận ở trên. Một số cấu trúc dữ liệu phức tạp hơn là cần thiết cho mối quan hệ với một hoặc nhiều tên miền không rõ ràng. Vì lý do này (và những người khác được trích dẫn dưới đây), khả năng loại bỏ các tên miền không rõ ràng có vẻ đáng để điều tra! Trên thực tế, có một thủ tục loại bỏ rất đơn giản, mà chúng ta sẽ gọi là chuẩn hóa.

Sau đó, anh tiếp tục thể hiện:

1. Một nhóm các mối quan hệ trong đó một quan hệ không được chuẩn hóa (nó có các miền chứa các quan hệ là các giá trị, nghĩa là chúng không đơn giản; nghĩa là chúng không đơn giản)

2. Một nhóm các mối quan hệ được chuẩn hóa (nghĩa là một mối quan hệ đã bị phân tách; tức là, một mối quan hệ có các miền có giá trị được chia thành các mối quan hệ đơn giản biểu thị rằng chúng là nguyên tử)

Và sau đó, ông mô tả các thủ tục để có được quan hệ bình thường hóa từ những người không bình thường.

Về mặt này, các mối quan hệ anh ta sử dụng để minh họa một bài tập bình thường hóa và bản mô tả bài tập khá rõ ràng và tôi khuyên bạn nên tự mình phân tích chúng (và tôi cũng hy vọng điều này khuyến khích một số độc giả tham gia vào văn bản).

Thành công, ông chỉ ra:

Hoạt động hơn nữa của một loại bình thường hóa là có thể. Những điều này không được thảo luận trong bài báo này.

Và các hoạt động đã nói, tức là, dạng thông thường thứ hai và thứ ba (2NF và 3NF) thực sự được mô tả chi tiết trong CÂU bình thường hóa hơn nữa của Mô hình quan hệ cơ sở dữ liệu, và như đã đề cập ở trên, sau khi trình bày (và in và xuất bản sau) của bài báo này , dạng bình thường ban đầu được gọi là dạng bình thường đầu tiên.

Là một học viên có thể quan sát, có các mối quan hệ (bảng) không chuẩn hóa đưa ra sự tích chập (hầu như luôn luôn không cần thiết) vào các triển khai RDB.

Một mối quan hệ thỏa mãn 1NF, giúp giảm bớt định nghĩa về các ràng buộc và thao tác xử lý dữ liệu có thể được thực hiện bằng một ngôn ngữ con dữ liệu ít phức tạp hơn so với yêu cầu đối với các quan hệ không chuẩn hóa (bảng), như Tiến sĩ Codd chỉ ra trong các dòng sau:

Việc áp dụng một mô hình dữ liệu quan hệ, như được mô tả ở trên, cho phép phát triển một ngôn ngữ con dữ liệu phổ quát dựa trên một phép tính vị ngữ được áp dụng. Một phép tính vị ngữ bậc nhất đủ nếu tập hợp các quan hệ ở dạng bình thường. Một ngôn ngữ như vậy sẽ cung cấp một sức mạnh ngôn ngữ cho tất cả các ngôn ngữ dữ liệu được đề xuất khác và chính nó sẽ là một ứng cử viên mạnh mẽ để nhúng (với sửa đổi cú pháp phù hợp) trong nhiều ngôn ngữ máy chủ (lập trình, hướng theo vấn đề hoặc hướng đến vấn đề). [Càng]

[Càng]

Tính phổ biến của ngôn ngữ con dữ liệu nằm ở khả năng mô tả của nó (không phải khả năng tính toán của nó).

Sự hoang mang

Từ quan điểm của tôi, những hoang mang đã phát sinh, do (a) phần chênh lệch nói trên của giải, giải thích, vv về 1NF và các RM chính nó, và vì (b) nỗ lực hơn nữa để xác định lại 1NF rằng trạng thái đó có quan hệ lần lượt với các miền chứa các giá trị, các quan hệ tuân thủ 1NF miễn là chúng là một giá trị duy nhất cho mỗi bộ tương ứng.

Tôi nhận điểm khác của bạn

Không nên có bất kỳ mối quan hệ nào giữa các hàng, ngoài việc chúng tuân thủ cùng các tiêu đề.

Tôi không chắc liệu tôi có hiểu chính xác ý định của tuyên bố đó hay không, ngoài việc tuân thủ cùng các tiêu đề, còn phải có một kết nối giữa các hàng (tuples) của một mối quan hệ vì mỗi trong số chúng phải là một khẳng định về một sự xuất hiện cụ thể của loại thực thể cụ thể (được xác định theo bối cảnh kinh doanh quan tâm) mà mối quan hệ (bảng) được cho là đại diện.

Cũng không nên có mối quan hệ giữa các cột, nhưng tôi tin rằng đó là chủ đề của các hình thức bình thường cao hơn.

Tôi cũng không biết liệu tôi có diễn giải đúng ý nghĩa của câu nói đó hay không, nhưng trên thực tế, và theo phản ứng của tôi với khía cạnh trước đó, cũng phải có mối quan hệ giữa các miền (cột) của một mối quan hệ (bảng) , đó chính xác là lý do tại sao nó là một mối quan hệ (cấu trúc thiết yếu của mô hình quan hệ và triển khai RDB cụ thể).

Để làm gương, liên quan đến mối quan hệ giả định (bảng)

• Salary (PersonNumber, EffectiveDate, Amount)

bộ (hàng)

• Salary (x, y, z)

sẽ truyền đạt ý nghĩa

• The Salary payed to the Person identified by PersonNumber x, on EffectiveDate y corresponds to the Amount of z

Do đó, mỗi bộ (hàng) của Salarymối quan hệ (bảng) phải phù hợp với cấu trúc của xác nhận được hiển thị ở trên và sự khác biệt sẽ là sự thay thế của các giá trị miền (cột) thích hợp, nhưng phải tồn tại mối quan hệ giữa (a) tất cả các Salarymiền (cột) và giữa (b) tất cả các giá trị tương ứng của chúng đối với từng bộ (hàng); một mối quan hệ như vậy nó là không thể thiếu.

Các dạng thông thường cao hơn (2NF và 3NF) rất hữu ích để loại bỏ các phụ thuộc chức năng giữa các miền (cột) của một mối quan hệ (bảng), chúng giúp tránh các kết nối không mong muốn giữa các miền (cột), như các kết nối không mong muốn cho phép giới thiệu các bất thường cập nhật . Cả 2NF và 3NF đều hữu ích để kiểm tra tính đúng đắn của cấu trúc của các mối quan hệ (bảng) trong một triển khai RDB nhất định.

Sự minh họa. Lấy một chuỗi văn bản có chứa một địa chỉ điển hình của Hoa Kỳ:

"123 Cornhusk Rd., South Succotash, NY 12345"

Viết một truy vấn để tìm tất cả cư dân của Cornhusk Road hoặc một cư dân cụ thể của thị trấn South Succotash hoặc tiểu bang New York sẽ là một nhiệm vụ khó khăn. Đặc biệt khi bạn có các chuỗi sau trong dữ liệu:

"123 Cornhusk Road, South Succotash, NY 12345"
"123 Cornhusk Rd., South Succotash, New York 12345"
"123 Cornhusk, South Succotash, NY 12345"
"123 Cornhusk Rd., SOUTH SUCCOTASH, NY 12345"

Mỗi trong số này chỉ định cùng một địa chỉ thực tế (và điều này thậm chí không xem xét các lỗi chính tả như "Succatash") nhưng viết thuật toán để so sánh thành công chúng là điều tôi KHÔNG muốn dành những năm cuối cùng trên Trái đất này để làm.

Nhập mẫu bình thường đầu tiên. Tôi sẽ không đi vào chi tiết về cách thức thực hiện, chỉ xem xét một hình thức phổ biến như đã thấy trong hầu hết các cơ sở dữ liệu:

create table Addresses(
  ...
  Street  varchar,
  City    int        references Cities( ID ),
  State   char( 2 )  references States( ID ),
  Zip     int
  ...
);

Đây không phải là một sự bình thường hóa hoàn toàn. Ví dụ: bạn có thể chia Street thành StreetNum và StreetName hơn nữa nhưng điều này đủ xa cho một minh họa đơn giản và nó thực sự là về quá trình chuẩn hóa được thực hiện trong cuộc sống thực. Vẫn còn một vấn đề nhỏ là tìm tất cả cư dân của Cornhusk Road nhưng nếu bạn tìm kiếm Street cho chuỗi con "Cornhusk" và tình cờ có một thị trấn tên Cornhusk ở đâu đó, ít nhất điều đó sẽ không gây nhầm lẫn.

Vấn đề với định nghĩa được cung cấp bởi Date, et al, là họ không nhìn vào bên trong một phần dữ liệu và xem xét ý nghĩa của dữ liệu đó. Không phải tôi đặc biệt đổ lỗi cho họ, nó có thể khá khó khăn.

Vì vậy, chúng ta phải lấy một "chuỗi ký tự" và biến nó thành một "địa chỉ". Nhưng việc đưa ra một định nghĩa bao gồm tất cả các địa chỉ không đơn giản như vẻ ngoài của nó. Đặc biệt là khi làm việc với các địa chỉ ở nhiều quốc gia.

Đầu tiên, chúng tôi sửa chữa bối cảnh. Không có gì có ý nghĩa mà không có bối cảnh. Bối cảnh của chúng tôi ở đây là địa chỉ . Trong bối cảnh đó, chúng ta có thể thấy các phần của dữ liệu có ý nghĩa cụ thể, chẳng hạn như Đường , Thành phố , v.v. Chúng tôi gán cho mỗi ý nghĩa một trường riêng biệt.

Điều khó khăn là dữ liệu, như từ ngữ, có thể có ý nghĩa khác nhau đối với những người khác nhau hoặc một số người có thể thấy ý nghĩa mà những người khác không có. Nó có thể là một dự án tất cả cho chính nó và đòi hỏi một nỗ lực hợp tác tốt. Nhưng nó là một yếu tố quan trọng trong thiết kế cơ sở dữ liệu tốt.

Điểm chuẩn hóa là loại bỏ hoặc ít nhất là giảm thiểu dữ liệu dị thường . Hãy xem xét thực tế rằng, trong bảng trên, mã Town hoặc Zip có thể được nhập không tồn tại ở trạng thái đã được chọn. Hoặc một con đường đi vào không thực sự tồn tại trong thị trấn đã được chọn. À, nhưng bây giờ chúng ta đang ở dạng bình thường thứ hai và thứ ba và đó là một chủ đề khác.

Hãy nghĩ về 1NF như là một giới thiệu về khái niệm toán học của các mối quan hệ, chứ không phải là một cấu trúc dữ liệu cụ thể hoặc bộ quy tắc cố định. Các cấu trúc toán học như quan hệ có thể được biểu diễn theo nhiều cách khác nhau - bảng chỉ là một trong những cách thuận tiện nhất. Khi sử dụng các bảng, có các hạn chế để đảm bảo rằng chúng thể hiện rõ ràng các mối quan hệ dự định của chúng và các thao tác trên các bảng là hợp lý đối với các quan hệ được biểu diễn.

Khi chúng tôi nói rằng thứ tự và trùng lặp cột và hàng là không đáng kể, điều này là để đảm bảo rằng tất cả thông tin quan trọng được ghi lại dưới dạng giá trị trong bảng và có thể truy cập vào các truy vấn của chúng tôi và không được mã hóa vào phần trình bày của bảng. Mặc dù ít, nếu có, các tác giả đã cấm sử dụng màu sắc trong bảng một cách rõ ràng, việc hiểu mục đích của các hạn chế ở trên sẽ khiến chúng ta loại trừ tương tự việc sử dụng màu sắc trình bày có ý nghĩa để các giá trị màu quan trọng phải được ghi lại rõ ràng. Ngày và các tác giả khác cũng không tán thành các định danh hàng ẩn cho cùng một lý do.

Khái niệm nguyên tử là về việc đảm bảo rằng tất cả các cấu trúc quan trọng được biểu thị dưới dạng quan hệ, để chúng tôi có thể phân tích sự phụ thuộc trong tất cả dữ liệu của chúng tôi và ngăn ngừa sự bất thường, và để tất cả các cấu trúc có ý nghĩa có thể truy cập thống nhất vào các hoạt động quan hệ. Các giá trị tổng hợp không hợp lệ, nhưng chúng yêu cầu các toán tử cụ thể của miền giải nén, điều này làm tăng độ phức tạp và chúng có thể đưa ra sự dư thừa. Tất nhiên, trong thực tế, một số loại hỗn hợp đơn giản và các toán tử liên quan là thuận tiện và giúp tăng tính gọn nhẹ và tính biểu cảm của các truy vấn, nhưng điều này không mâu thuẫn với lý thuyết.

Các phụ thuộc hàng như phụ thuộc đa trị không vi phạm 1NF, nhưng giống như các phụ thuộc giữa các cột, là chủ đề của các hình thức bình thường cao hơn. Gần cột lặp đi lặp lại như thế phone1, phone2, vv không vi phạm 1NF một trong hai, mặc dù họ thiết kế nghèo đang.

Các định nghĩa và giải thích từ Wikipedia về 1NF, tôi nghĩ là khá tốt. - Joanolo

Mở rộng về một câu trong bài viết Wikipedia:

Nhìn như số điện thoại, văn bản không phải là nguyên tử

Điều này có thể cung cấp cho bạn một xử lý tại sao có quá nhiều nhầm lẫn. Nếu đây chỉ là một gob của văn bản, thì nó là nguyên tử. Nhưng nếu nó được coi là số điện thoại, thì nó không phải là nguyên tử. Ngày và những người khác vượt qua vấn đề này. Nó phải làm với những gì dữ liệu có nghĩa. Khi bạn phân tích vấn đề, bạn phải vật lộn với ý nghĩa của dữ liệu.

Liệu có bất kỳ điểm nào để phá vỡ nó hơn nữa có liên quan đến câu hỏi liệu hình thức bình thường đầu tiên đã được đáp ứng hay không. Điểm đằng sau 1NF là cung cấp quyền truy cập có khóa vào tất cả dữ liệu. Nhưng nếu thứ bạn truy xuất thông qua truy cập có khóa có cấu trúc phụ, thì bạn không có quyền truy cập khóa vào cấu trúc phụ. - Walter Mitty

"1NF" được sử dụng để chỉ một loạt những thứ khác nhau , nhiều trong số đó là vô nghĩa và phổ biến simultaneoulsly. Xem câu trả lời của tôi về "Chuẩn hóa trong hệ thống quản lý cơ sở dữ liệu" , bao gồm các liên kết của nó. Một trong số đó là câu trả lời của tôi về "Tính nguyên tử trong dbms" là gì . (Cả hai tại Stack Overflow.) - philipxy

_{Câu trả lời Wiki cộng đồng được tạo từ các bình luận để lại câu hỏi}