2009-06-26 37 views
7

Một khung nhìn SQL là một bảng logic, toàn cầu có thể có hoặc không thể tồn tại. Nhưng nó vẫn là một cái bàn. Vì vậy, một VIEW luôn luôn tuân theo hình thức bình thường đầu tiên (1NF)? nghĩa là không có các hàng trùng lặp, chỉ các loại vô hướng, không có thứ tự từ trên xuống dưới hoặc từ trái sang phải, v.v ... về các hình thức bình thường cao hơn thì sao?Một khung nhìn SQL có luôn ở trong 1NF không?

Đối với tôi, ứng dụng của tôi 'tiêu thụ' kết quả của procs được lưu trữ, VIEW của tôi bị 'tiêu thụ' bởi truy vấn SQL và hai tập quán này đều loại trừ lẫn nhau (nghĩa là tôi không truy vấn kết quả của procs được lưu trữ bằng SQL và các ứng dụng của tôi không chứa mã SQL). Tôi đã thấy những người khác sử dụng VIEW để 'ghép nối' nhiều giá trị trong một cột thành một hàng duy nhất, thường là định dạng được phân cách bằng dấu phẩy. Viết các vị từ trong một truy vấn SQL chống lại một cột như vậy đòi hỏi một kludges tương tự như sau:

',' + concat_col + ',' LIKE '%' + ',' + search_value + ',' + '%' 

Vì vậy, có vẻ như với tôi hợp lý để hy vọng tất cả các bảng có thể được truy vấn để bao gồm chỉ các loại vô hướng. Tôi có quá 'thuần khiết' bằng cách suy nghĩ điều này không?

Trả lời

3

Điều này có ý nghĩa hoàn hảo để đảm bảo chế độ xem của bạn được chuẩn hóa ở mức tối thiểu là 1NF. Ví dụ, việc cho phép các bản sao có bất lợi là ý nghĩa của chế độ xem được thực hiện mơ hồ và thông tin có thể bị người dùng nhận dạng sai. Dữ liệu không chính xác có thể xảy ra nếu các bảng được cập nhật dựa trên sự mơ hồ như vậy.

E.F.Codd không nhất thiết phải đồng ý. Trong cuốn sách RM phiên bản 2 của mình, ông đề nghị cho phép xem mà không có chìa khóa - một sai lầm lớn tôi nghĩ. Quan điểm của Codd không thực sự cho phép trùng lặp nhưng chúng cho phép mỗi cột có thể rỗng và do đó không có khóa và không có trong 1NF.

Giá trị chuỗi chứa danh sách được phân tách bằng dấu phẩy không phải là vi phạm 1NF. Giá trị chuỗi là một vô hướng giống như bất kỳ giá trị nào khác, bất kể giá trị nào chứa nó. Hầu hết các DBMS SQL không cho phép các thuộc tính đa giá trị.

9

Không - tôi tạo chế độ xem để khớp với đầu ra mà chương trình của tôi yêu cầu.

+0

quan điểm của tôi là 'tiêu thụ' bởi chỉ truy vấn SQL. Nếu chương trình của tôi cần một resultset trong một định dạng 'đặc biệt' thì tôi sẽ làm điều này trong một proc được lưu trữ hoặc tầng giữa. Tôi không đề xuất đầu ra của mỗi proc được lưu trữ phải ở trong 1NF, chỉ có đầu ra ở dạng * bảng * (và tôi đoán rằng sẽ bao gồm các biến bảng nếu có). – onedaywhen

+0

Bạn đã tạo quy tắc rõ ràng cho ứng dụng của riêng mình (không có SQL trong ứng dụng khách, ví dụ:) hoạt động cho bạn. Chúng hạn chế hơn là những gì tôi sẽ xem là thực hành tốt nhất, nhưng điều tốt đẹp về việc quá hạn chế là luôn dễ thay đổi tâm trí của bạn sau này và thoải mái hơn - không dễ dàng đi theo cách khác. Nhưng nói chung, đầu ra của các khung nhìn có thể vi phạm 1NF (mặc dù các hàng dupe là vô ích, AFAIK). Thực tế, việc sử dụng các khung nhìn xấu là một trong những cách tốt nhất để di chuyển một thiết kế xấu xí sang một thiết kế sạch - bạn cần các khung nhìn để hỗ trợ các máy khách cũ cho đến khi chúng cũng có thể được sửa. –

4

Toàn bộ hệ thống quan hệ là bạn giữ dữ liệu trong các quan hệ bình thường về hiệu quả và/hoặc quản lý, và sau đó sử dụng toán tử quan hệ để chuyển đổi chúng thành các mối quan hệ bạn cần.

Chế độ xem phi vật chất không được lưu trữ, đó là truy vấn.

Đó là lý do tại sao bạn nên tạo biểu mẫu ở dạng phù hợp nhất với nhu cầu ứng dụng của bạn.

Xem this answer để biết thêm chi tiết.

1

Tôi không nghĩ đây là quy tắc, nhưng nếu có - Không quy tắc nào nên luôn theo dõi.

+1

Tôi nghĩ rằng cách tiếp cận được chấp nhận là bạn tuân theo 'các quy tắc' về bình thường hóa sau đó bạn tuân theo 'các quy tắc' của việc không chuẩn hóa nếu có lý do chính đáng để làm như vậy. Trừ khi bạn là một vô chính phủ trong trường hợp các quy tắc là không có quy tắc, chống lại quyền lực, quần bondage, kudo cho bạn. – onedaywhen

0

một cái nhìn (trừ khi nó được cụ thể hóa/xem lập chỉ mục) là gì, nhưng một truy vấn được lưu trữ Quan điểm có thể chứa nhiều hơn một bảng, có thể có tự tham gia vào cùng một bảng vv vv

+0

Thật vậy và tôi có thể tham gia một bảng đã xem (a.k.a. VIEW) với các bảng khác ... vì vậy nó sẽ thực sự giúp ích nếu tất cả các cột là các loại vô hướng. – onedaywhen

+0

... Tôi đã thêm một mô tả về cách sử dụng này và ý nghĩa của 1NF đối với câu hỏi của tôi. – onedaywhen

-2

Không - bình thường các quy định áp dụng đối với sự bền bỉ của dữ liệu, chứ không phải sự trình bày của dữ liệu. Ví dụ: bất kỳ hàng trùng lặp nào trong chế độ xem sẽ phá vỡ 1NF, điều này rõ ràng là quá hạn chế.

Để biết thêm thông tin, hãy xem First normal form.

+0

CHẾ ĐỘ XEM với hàng trùng lặp hữu ích như thế nào? Bạn có một ví dụ thực tế về cuộc sống? Cảm ơn. – onedaywhen

+0

Tại sao lại là downvote? – RedFilter

+0

Bạn không trả lời câu hỏi lịch sự của tôi nhưng bạn mong đợi phản hồi cho bạn? ;) Tuy nhiên, downvote không phải của tôi. – onedaywhen

0

Theo Chris ngày, quan điểm nên hoàn toàn bình thường:

Sự lựa chọn như mà các mối quan hệ bạn thực hiện những cơ sở, và số lượt xem, là tùy ý. Như một ví dụ tầm thường, bạn có thể có nhân viên và bạn có thể có một mối quan hệ cơ bản chứa tất cả các nhân viên, và bạn có thể có nhân viên Bờ Đông và Nhân viên Bờ Tây là hai quan điểm. Hoặc bạn có thể có nhân viên Bờ Đông và Bờ Tây làm hai quan hệ cơ sở, và lấy được sự kết hợp của tất cả chúng như một quan điểm. Nó hoàn toàn tùy ý.

DBMS Phỏng vấn với Chris ngày - tháng 10 năm 1994

Các vấn đề liên quan