Bài viết này là bài đầu tiên trong loạt bài về các nguyên tắc cơ bản của biểu thức bảng trong T-SQL. Tôi sẽ chủ yếu tập trung vào bốn loại biểu thức bảng được đặt tên, được biết đến trong T-SQL là bảng dẫn xuất, biểu thức bảng thông dụng (CTE), dạng xem và các hàm có giá trị bảng nội tuyến (TVF nội tuyến).
Tôi được truyền cảm hứng để viết bộ truyện này bởi người bạn tốt của tôi, Grant Fritchey, người mà tôi đã biết trong nhiều năm. Như Grant nhiều lần chỉ ra, nhiều người sử dụng biểu thức bảng phổ biến trong T-SQL nghĩ rằng SQL Server vẫn duy trì tập kết quả truy vấn bên trong và lý do cho niềm tin này là việc sử dụng thuật ngữ bảng trong tên của công trình. Khi chủ đề này xuất hiện trong các cuộc thảo luận cộng đồng, mọi người thường tranh luận rằng việc sử dụng bảng thuật ngữ trong tên của công trình là không phù hợp vì nó không thực sự là một bảng. Thậm chí còn có những gợi ý để bắt đầu chiến dịch đặt tên với hy vọng sẽ thấy sự thay đổi tên trong tương lai cho cấu trúc này, ít nhất là trong T-SQL. Một số đề xuất bao gồm biểu thức truy vấn , chế độ xem nội tuyến , chế độ xem cấp tuyên bố , và những người khác.
Có lẽ điều này sẽ gây ngạc nhiên cho một số người, nhưng tôi thực sự thấy việc sử dụng thuật ngữ bảng trong biểu thức bảng chung là rất thích hợp. Trên thực tế, tôi thấy việc sử dụng thuật ngữ biểu thức bảng sao cho phù hợp. Đối với tôi, cách tốt nhất để mô tả CTE là gì trong T-SQL, đó là biểu thức bảng được đặt tên . Điều tương tự cũng áp dụng cho những gì T-SQL gọi các bảng dẫn xuất (cấu trúc ngôn ngữ cụ thể trái ngược với ý tưởng chung), các khung nhìn và TVF nội tuyến. Chúng đều là biểu thức bảng được đặt tên.
Nếu bạn có thể chịu đựng được tôi một chút, tôi sẽ cung cấp lý do cho quan điểm của tôi về mọi thứ trong bài viết này. Tôi nhận ra rằng cả sự nhầm lẫn về đặt tên và sự nhầm lẫn về việc liệu có khía cạnh tồn tại lâu dài đối với các biểu thức bảng hay không, đều có thể được giải quyết khi hiểu rõ hơn về các nguyên tắc cơ bản của lĩnh vực hệ thống quản lý cơ sở dữ liệu quan hệ của chúng tôi. Các nguyên tắc cơ bản đó là, lý thuyết quan hệ, cách SQL (ngôn ngữ chuẩn) liên quan đến nó và cách phương ngữ T-SQL được sử dụng trong triển khai Cơ sở dữ liệu SQL Server và Azure SQL liên quan đến cả hai.
Khi bắt đầu, bạn muốn có thể trả lời các câu hỏi sau:
- Tính năng độc lập dữ liệu vật lý nguyên tắc trong mô hình quan hệ có nghĩa là?
- Bảng trong SQL là gì và bản sao trong mô hình quan hệ là gì?
- Thuộc tính đóng của đại số quan hệ là gì?
- Biểu thức bảng là gì và đối số trong mô hình quan hệ là gì?
Khi bạn có thể trả lời chính xác các câu hỏi trên, rất có thể bạn sẽ thấy việc sử dụng thuật ngữ biểu thức bảng được đặt tên sao cho phù hợp với các cấu trúc nói trên (cái mà T-SQL gọi là bảng dẫn xuất, CTE, chế độ xem và TVF nội tuyến).
Tôi không muốn có vẻ như tôi hiểu rất sâu về lý thuyết quan hệ. Chuyên môn của tôi là T-SQL. Tôi thừa nhận rằng còn nhiều điều mà tôi không biết về lý thuyết quan hệ hơn là tôi biết, và một số điều mà tôi nghĩ rằng tôi biết, thực tế không phải như vậy. Khi tôi đọc các bài viết của C. J. Dates về chủ đề này, tôi cảm thấy rằng mình hầu như chỉ đang tìm hiểu về những gì cần biết, và rằng tôi có thể và nên cố gắng hiểu rõ hơn về chủ đề này. Tôi công nhận và tin tưởng chắc chắn rằng sự hiểu biết tốt về lý thuyết quan hệ sẽ chuyển trực tiếp đến sự hiểu biết tốt hơn về SQL và T-SQL, đồng thời viết mã T-SQL tốt hơn, chính xác hơn và mạnh mẽ hơn. Đối với bất kỳ ai chọn dữ liệu là nghề nghiệp của họ, tôi khuyên bạn nên đọc SQL và Lý thuyết quan hệ:Cách viết mã SQL chính xác, phiên bản thứ 3 của C. J. Date (O'Reilly 2015).
Trong phần đầu tiên của loạt bài này, tôi muốn hiểu về cách sử dụng các thuật ngữ biểu thức bảng và biểu thức bảng được đặt tên , phù hợp với việc sử dụng thuật ngữ này của Date và rất tiếc là không phù hợp với cách sử dụng thuật ngữ này của Tiêu chuẩn SQL. Để đạt được điều này, tôi sẽ cung cấp một chút kiến thức nền tảng từ lý thuyết quan hệ và tiêu chuẩn SQL. Nhưng như tôi đã nói, tôi khuyên bạn nên đọc cuốn sách của Date để có tầm nhìn thực sự chi tiết về chủ đề này.
Tôi sẽ bắt đầu bằng cách giải thích ý nghĩa của nguyên tắc độc lập dữ liệu vật lý. Tiếp theo, tôi sẽ giải thích bảng là gì trong SQL và bản sao của nó trong lý thuyết quan hệ. Sau đó, tôi sẽ giải thích thuộc tính đóng của đại số quan hệ có nghĩa là gì. Khi bạn đã có ý tưởng hợp lý về bảng là gì và thuộc tính bao đóng có nghĩa là gì, việc hiểu biểu thức bảng là gì trở nên khá đơn giản. Sau đó, trọng tâm của tôi sẽ chuyển sang các chi tiết cụ thể trong T-SQL. Tôi có rất nhiều điều để nói về các nguyên tắc cơ bản của biểu thức bảng trong T-SQL — cả về cách xử lý khái niệm và về chi tiết triển khai, bao gồm cả biểu diễn vật lý và cân nhắc điều chỉnh truy vấn.
Tôi thấy chủ đề này hấp dẫn và rất thực tế khi bạn đi sâu vào chi tiết triển khai. Trên thực tế, tôi có quá nhiều điều để nói về điều đó nên tôi không chắc cuối cùng loạt phim này sẽ có bao nhiêu phần. Điều tôi có thể nói với bạn với một mức độ tự tin là sẽ có nhiều phần. Có thể nhiều hơn một và ít hơn 100. Trong các phần sau, tôi sẽ đi sâu vào các loại biểu thức bảng được đặt tên riêng lẻ, cân nhắc sửa đổi, các khía cạnh nội tuyến, các khía cạnh thứ tự, các mối tương quan và hơn thế nữa.
Trong các ví dụ của mình, tôi sẽ sử dụng cơ sở dữ liệu mẫu có tên là TSQLV5. Bạn có thể tìm thấy tập lệnh tạo và điền cơ sở dữ liệu này tại đây và sơ đồ ER của nó tại đây.
Độc lập dữ liệu vật lý
Tính độc lập dữ liệu vật lý là một nguyên tắc trong lý thuyết quan hệ nói rằng các chi tiết thực hiện vật lý phải được ẩn hoặc trong suốt đối với người dùng gửi truy vấn chống lại hệ thống quản lý cơ sở dữ liệu quan hệ. Trong các truy vấn, người dùng phải tập trung vào cái gì họ cần sử dụng các phép toán logic dựa trên đại số quan hệ, trái ngược với cách để lấy dữ liệu. Họ không phải lo lắng về cách dữ liệu được cấu trúc, truy cập và xử lý. Các chi tiết triển khai vật lý như vậy có xu hướng khác nhau đáng kể giữa các triển khai khác nhau (các sản phẩm RDBMS). Ngay cả với cùng một RDBMS, các chi tiết thực hiện vật lý đôi khi thay đổi giữa các phiên bản và bản dựng khác nhau. Về lý thuyết, ý tưởng đằng sau nguyên tắc độc lập dữ liệu vật lý là bảo vệ khoản đầu tư của người dùng bằng cách loại bỏ nhu cầu sửa đổi các giải pháp của bạn khi bạn nâng cấp RDBMS lên phiên bản mới hoặc ngay cả khi bạn chuyển từ RDBMS này sang RDBMS khác. Như bạn có thể biết rõ, trong thực tế, mọi thứ không đơn giản như vậy, nhưng đó là một chủ đề cho một cuộc thảo luận khác.
Bảng là gì?
Nếu bạn đã làm việc với T-SQL hoặc bất kỳ phương ngữ SQL nào khác trong một thời gian, bạn sẽ phát triển sự hiểu biết trực quan về bảng là gì. Vấn đề là nếu không có một số nền tảng về lý thuyết quan hệ, thường thì sự hiểu biết trực quan không chính xác lắm. Một sai lầm điển hình là chúng ta có xu hướng tập trung vào các chi tiết thực hiện vật lý một cách trực quan. Ví dụ:khi bạn đang nghĩ về bảng là gì, bạn có đang nghĩ về bảng như một cấu trúc logic (một tập hợp các hàng) hay bạn đang nghĩ về các chi tiết triển khai vật lý trong nền tảng mà bạn đang sử dụng (trong SQL Server , trang, phạm vi, chỉ mục đống so với chỉ mục nhóm, chỉ mục không hợp nhất, v.v.)? Là người dùng viết mã SQL để truy vấn bảng, tuân theo nguyên tắc độc lập dữ liệu vật lý, bạn phải nghĩ về bảng như một cấu trúc logic và hãy để RDBMS lo lắng về các chi tiết triển khai vật lý. Vì vậy, hãy lùi lại một bước và cố gắng tìm ra bảng là gì.
Một bảng là bản sao của SQL với cấu trúc chính trong lý thuyết quan hệ - một mối quan hệ. Để đơn giản hóa mọi thứ và giới hạn phạm vi bao phủ của tôi, tôi sẽ không đi sâu vào phân biệt giữa biến quan hệ và giá trị quan hệ. Nếu bạn làm theo lời giới thiệu của tôi và đọc cuốn sách của Date, bạn sẽ nhanh chóng có một bức tranh rõ ràng về sự tinh tế đó.
Một quan hệ có một tiêu đề và một nội dung.
Tiêu đề của mối quan hệ là một bộ trong tổng số thuộc tính . Trong lý thuyết tập hợp toán học, một tập hợp không có thứ tự và không có bản sao. Bạn phải xác định một thuộc tính theo tên chứ không phải theo một số vị trí. Do đó, tên thuộc tính phải là duy nhất.
Bạn có thể xác định đâu là bản sao của một thuộc tính trong SQL không? Có thể bạn đã đoán rằng đó là một cột . Tuy nhiên, SQL thực sự có khái niệm về thứ tự các cột của nó dựa trên thứ tự xuất hiện của chúng trong câu lệnh CREATE TABLE. Ví dụ:đây là câu lệnh CREATE TABLE cho bảng Sales.Shippers trong cơ sở dữ liệu TSQLV5:
CREATE TABLE Sales.Shippers ( shipperid INT NOT NULL IDENTITY, companyname NVARCHAR(40) NOT NULL, phone NVARCHAR(24) NOT NULL, CONSTRAINT PK_Shippers PRIMARY KEY(shipperid) );
Truy vấn bảng bằng SELECT * khét tiếng , như vậy:
SELECT * FROM Sales.Shippers;
Khi tôi chạy truy vấn này trong hệ thống của mình, tôi nhận được kết quả sau:
shipperid companyname phone ---------- -------------- --------------- 1 Shipper GVSUA (503) 555-0137 2 Shipper ETYNR (425) 555-0136 3 Shipper ZHISN (415) 555-0138
SQL đảm bảo rằng các cột sẽ được trả về từ trái sang phải dựa trên thứ tự định nghĩa. Tôi sẽ giải thích điều gì xảy ra với các hàng trong thời gian ngắn. SQL thậm chí còn cho phép bạn tham chiếu đến vị trí thứ tự của cột từ danh sách CHỌN trong mệnh đề ORDER BY, như vậy (không phải tôi đề xuất phương pháp này, Aaron Bertrand cũng vậy):
SELECT shipperid, companyname, phone FROM Sales.Shippers ORDER BY 2;
Truy vấn này tạo ra kết quả sau:
shipperid companyname phone ---------- -------------- --------------- 2 Shipper ETYNR (425) 555-0136 1 Shipper GVSUA (503) 555-0137 3 Shipper ZHISN (415) 555-0138
Nội dung của mối quan hệ là một tập hợp các bộ giá trị . Một lần nữa, hãy nhớ lại rằng một tập hợp không có thứ tự và không có bản sao. Do đó, một quan hệ phải có ít nhất một khóa ứng viên cho phép bạn xác định duy nhất một bộ giá trị. Bản sao của SQL với một tuple là một hàng . Tuy nhiên, trong SQL, bạn không bị buộc phải xác định khóa trong bảng và nếu không, bạn có thể có các hàng trùng lặp. Ngay cả khi bạn có một khóa được xác định trong bảng của mình, bạn có thể nhận được các hàng trùng lặp được trả về từ một truy vấn đối với bảng. Đây là một ví dụ:
SELECT country FROM HR.Employees;
Truy vấn này tạo ra kết quả sau:
country -------- USA USA USA USA UK UK UK USA UK
Truy vấn này không tạo ra kết quả quan hệ do có thể có các hàng trùng lặp. Trong khi lý thuyết quan hệ dựa trên lý thuyết tập hợp, SQL dựa trên lý thuyết đa tập. Nhiều bộ (hay còn gọi là bộ siêu hoặc túi) có thể có các bản sao. SQL cung cấp cho bạn một công cụ để loại bỏ các bản sao bằng mệnh đề DISTINCT, như sau:
SELECT DISTINCT country FROM HR.Employees;
Truy vấn này tạo ra kết quả sau:
country -------- UK USA
Điều mà SQL duy trì từ lý thuyết quan hệ về phần thân của bảng là thuộc tính không có thứ tự. Trừ khi bạn thêm mệnh đề ORDER BY trong truy vấn, bạn không có bất kỳ đảm bảo nào rằng kết quả sẽ có bất kỳ thứ tự cụ thể nào giữa các hàng. Vì vậy, nội dung của kết quả truy vấn ở trên là quan hệ, ít nhất là theo nghĩa nó không có bản sao và nó không có thứ tự đảm bảo.
Giả sử rằng bạn truy vấn một bảng trong SQL Server và bạn không bao gồm mệnh đề ORDER BY trong truy vấn. Bạn có mong đợi SQL Server luôn trả về các hàng theo một số thứ tự cụ thể như một hành vi được đảm bảo không? Nhiều người làm. Nhiều người nghĩ rằng bạn sẽ luôn lấy lại các hàng dựa trên thứ tự chỉ mục nhóm. Đó là một ví dụ điển hình về việc bỏ qua nguyên tắc độc lập dữ liệu vật lý và đưa ra các giả định dựa trên trực giác và có thể dựa trên hành vi đã quan sát trong quá khứ. Microsoft biết rằng một truy vấn SQL không có mệnh đề ORDER BY không đảm bảo bất kỳ thứ tự nào giữa các hàng kết quả và do đó, ngay cả khi ở mức vật lý, dữ liệu nằm trong cấu trúc chỉ mục, SQL Server không phải xử lý dữ liệu trong chỉ mục gọi món. Nó có thể chọn, trong những điều kiện vật chất nhất định, làm như vậy, nhưng nó có thể không chọn trong những điều kiện vật chất khác. Cũng xin nhắc lại rằng các chi tiết thực hiện vật lý có thể thay đổi giữa các phiên bản và bản dựng khác nhau của sản phẩm. Nếu bạn muốn đảm bảo rằng truy vấn sẽ trả về các hàng kết quả theo một số thứ tự cụ thể, thì cách duy nhất để đảm bảo điều này là giới thiệu mệnh đề ORDER BY trong truy vấn ngoài cùng.
Như bạn có thể đã thu thập được, các nhà thiết kế SQL không thực sự coi việc tuân theo lý thuyết quan hệ là một ưu tiên. Và những gì tôi mô tả ở đây chỉ là một vài ví dụ. Chúng còn nhiều nữa. Như đã đề cập trước đó, mục tiêu của tôi trong bài viết này chỉ là cung cấp đủ nền tảng lý thuyết quan trọng để xóa sự nhầm lẫn xung quanh các biểu thức bảng, trước khi tôi bắt đầu đi sâu vào các chi tiết cụ thể trong T-SQL trong các bài viết sau.
Biểu thức bảng là gì?
Đại số quan hệ (đại số xác định các phép toán trên các quan hệ trong lý thuyết quan hệ) có một đóng bất động sản. Điều đó có nghĩa là một phép toán trên các quan hệ mang lại một quan hệ. Một toán tử quan hệ hoạt động trên một hoặc nhiều quan hệ dưới dạng đầu vào và mang lại một quan hệ duy nhất dưới dạng đầu ra. Thuộc tính đóng cho phép bạn lồng các hoạt động. A biểu thức quan hệ là một biểu thức hoạt động trên quan hệ và trả về một quan hệ. Do đó, một biểu thức quan hệ có thể được sử dụng khi đại số quan hệ mong đợi một mối quan hệ.
Nếu bạn nghĩ về nó, nó không khác gì các phép toán trên số nguyên mang lại kết quả là số nguyên. Giả sử rằng biến @i là một biến số nguyên. Biểu thức @i + 42 mang lại một số nguyên và do đó có thể được sử dụng khi một số nguyên được mong đợi, như trong (@i + 42) * 2.
Cho rằng một bảng trong SQL là bản sao của một quan hệ trong lý thuyết quan hệ, mặc dù không phải là một bản sao rất thành công ở đó, một biểu thức bảng trong SQL là bản sao của một biểu thức quan hệ. Như đã đề cập trước đó, tôi sử dụng cụm từ bảng biểu sau việc sử dụng cụm từ này của C. J. Dates. Tiêu chuẩn SQL có rất nhiều thuật ngữ khó hiểu, một số thuật ngữ trong số đó tôi e rằng không phù hợp lắm. Ví dụ:Tiêu chuẩn SQL sử dụng biểu thức bảng thuật ngữ để mô tả cụ thể một biểu thức dựa trên các mệnh đề truy vấn bắt đầu bằng mệnh đề FROM bắt buộc và bao gồm tùy chọn các mệnh đề WHERE, GROUP BY, HAVING và WINDOW (cuối cùng không được hỗ trợ trong T -SQL), và loại trừ mệnh đề SELECT. Đây là thông số kỹ thuật của tiêu chuẩn:
7.4
Chức năng
Chỉ định một bảng hoặc một bảng được nhóm.
Định dạng
Đúng là kết quả của cái mà tiêu chuẩn gọi là biểu thức bảng được coi là một bảng, nhưng bạn không thể sử dụng một biểu thức như vậy như một truy vấn độc lập. Phiên bản ngày tháng của biểu thức bảng thuật ngữ thực sự gần với những gì mà tiêu chuẩn SQL gọi là biểu thức truy vấn . Dưới đây là đặc điểm kỹ thuật của tiêu chuẩn cho cái mà nó gọi là biểu thức truy vấn:
7.17
Chức năng
Định dạng
7.3
Chức năng
Định dạng
Hãy quan sát rằng đặc điểm kỹ thuật này bao gồm những gì T-SQL gọi là biểu thức bảng chung, mặc dù tiêu chuẩn không thực sự sử dụng thuật ngữ này, thay vào đó chỉ gọi nó là với phần tử danh sách . Cũng lưu ý rằng cái gọi là biểu thức truy vấn không nhất thiết phải dựa trên một truy vấn, mà có thể dựa trên cái được gọi là phương thức tạo giá trị bảng (việc sử dụng mệnh đề VALUES để xây dựng một tập hợp các hàng). Cuối cùng, mặc dù biểu thức truy vấn của tiêu chuẩn dựa trên một biểu thức, nhưng nó sẽ trả về một bảng và có thể được sử dụng ở nơi mà một bảng thường được mong đợi. Vì những lý do này, tôi thấy việc sử dụng biểu thức bảng thuật ngữ của Ngày thích hợp hơn nhiều.
Tôi có thể hiểu tại sao một số người có thể thấy việc đặt tên và thuật ngữ là một chút ngữ nghĩa và thậm chí có thể là lãng phí thời gian. Tuy nhiên, tôi cảm thấy rất khác. Tôi tin rằng trong bất kỳ lĩnh vực nào, nguyện vọng sử dụng tên riêng và thuật ngữ buộc bạn phải nghiên cứu kỹ nền tảng và phản ánh kiến thức của mình. Hy vọng rằng trong bài viết này, tôi đã không làm bạn xa lánh đến mức không muốn tiếp tục các phần sắp tới của loạt phim, bắt đầu với bài viết của tháng tới, tôi sẽ chuyển trọng tâm của mình sang cách các loại khác nhau được đặt tên. biểu thức bảng được xử lý bằng T-SQL trong SQL Server và Azure SQL Database.
[
[
[
[
Chỉ định một bảng.
[
[
WITH [RECURSIVE]
AS
|
[
|
[
|
[
|
[
<đặc tả truy vấn>
|
|
BẢNG
CORRESPONDING [THEO
ORDER BY <đặc tả sắp xếp danh sách>
OFFSET <đếm hàng bù> {ROW | ROWS}
FETCH {FIRST | NEXT} [
|
<đặc tả giá trị đơn giản>
<đặc tả giá trị đơn giản>
<đặc tả giá trị đơn giản> PERCENT
Chỉ định một tập hợp các
VALUES
VALUES
[{ Kết luận
