Hướng dẫn học Microsoft SQL Server 2008 part 33 doc

10 248 0
Hướng dẫn học Microsoft SQL Server 2008 part 33 doc

Đang tải... (xem toàn văn)

Thông tin tài liệu

Nielsen c11.tex V4 - 07/23/2009 1:54pm Page 282 Part II Manipulating Data With Select relational division query would list only those students who passed the required courses and no others. A relational division with a remainder, also called an approximate divide, would list all the students who passed the required courses and include students who passed any additional courses. Of course, that example is both practical and academic. Relational division is more complex than a join. A join simply finds any matches between two data sets. Relational division finds exact matches between two data sets. Joins/subqueries and relational division solve different types of questions. For example, the following questions apply to the sample databases and compare the two methods: ■ Joins/subqueries: ■ CHA2: Who has ever gone on a tour? ■ CHA2: Who lives in the same region as a base camp? ■ CHA2: Who has attended any event in his or her home region? ■ Exact relational division: ■ CHA2: Who has gone on every tour in his or her home state but no tours outside it? ■ OBXKites: Who has purchased every kite but nothing else? ■ Family: Which women (widows or divorcees) have married the same husbands as each other, but no other husbands? ■ Relational division with remainders: ■ CHA2: Who has gone on every tour in his or her home state, and possibly other tours as well? ■ OBXKites: Who has purchased every kite and possibly other items as well? ■ Family: Which women have married the same husbands and may have married other men as well? Relational division with a remainder Relational division with a remainder essentially extracts the quotient while allowing some leeway for rows that meet the criteria but contain additional data as well. In real-life situations this type of division is typically more useful than an exact relational division. The previous OBX Kites sales question (‘‘Who has purchased every kite and possibly other items as well?’’) is a good one to use to demonstrate relational division. Because it takes five tables to go from contact to product category, and because the question refers to the join between OrderDetail and Product, this question involves enough complexity that it simulates a real-world relational-database problem. The toy category serves as a good example category because it contains only two toys and no one has purchased a toy in the sample data, so the query will answer the question ‘‘Who has purchased at least one of every toy sold by OBX Kites?’’ (Yes, my kids volunteered to help test this query.) First, the following data will mock up a scenario in the OBXKites database. The only toys are ProductCode 1049 and 1050. The OBXKites database uses unique identifiers for primary keys and therefore uses stored procedures for all inserts. The first Order and OrderDetail inserts will list the stored procedure parameters so the following stored procedure calls are easier to understand: USE OBXKites; DECLARE @OrderNumber INT; 282 www.getcoolebook.com Nielsen c11.tex V4 - 07/23/2009 1:54pm Page 283 Including Data with Subqueries and CTEs 11 The first person, ContactCode 110, orders exactly all toys: EXEC pOrder_AddNew @ContactCode = ‘110’, @EmployeeCode = ‘120’, @LocationCode = ‘CH’, @OrderDate= ‘2002/6/1’, @OrderNumber = @OrderNumber output; EXEC pOrder_AddItem @OrderNumber = @OrderNumber, @Code = ‘1049’, @NonStockProduct = NULL, @Quantity = 12, @UnitPrice = NULL, @ShipRequestDate = ‘2002/6/1’, @ShipComment = NULL; EXEC pOrder_AddItem @OrderNumber, ‘1050’, NULL, 3, NULL, NULL, NULL; The second person, ContactCode 111, orders exactly all toys — and toy 1050 twice: EXEC pOrder_AddNew ‘111’, ‘119’, ‘JR’, ‘2002/6/1’, @OrderNumber output; EXEC pOrder_AddItem @OrderNumber, ‘1049’, NULL, 6, NULL, NULL, NULL; EXEC pOrder_AddItem @OrderNumber, ‘1050’, NULL, 6, NULL, NULL, NULL; EXEC pOrder_AddNew ‘111’, ‘119’, ‘JR’, ‘2002/6/1’, @OrderNumber output; EXEC pOrder_AddItem @OrderNumber, ‘1050’, NULL, 6, NULL, NULL, NULL; The third person, ContactCode 112, orders all toys plus some other products: EXEC pOrder_AddNew ‘112’, ‘119’, ‘JR’, ‘2002/6/1’, @OrderNumber output; EXEC pOrder_AddItem @OrderNumber, ‘1049’, NULL, 6, NULL, NULL, NULL; EXEC pOrder_AddItem @OrderNumber, ‘1050’, NULL, 5, NULL, NULL, NULL; EXEC pOrder_AddItem @OrderNumber, ‘1001’, NULL, 5, NULL, NULL, NULL; EXEC pOrder_AddItem @OrderNumber, ‘1002’, NULL, 5, NULL, NULL, NULL; The fourth person, ContactCode 113, orders one toy: EXEC pOrder_AddNew ‘113’, ‘119’, ‘JR’, ‘2002/6/1’, @OrderNumber output; 283 www.getcoolebook.com Nielsen c11.tex V4 - 07/23/2009 1:54pm Page 284 Part II Manipulating Data With Select EXEC pOrder_AddItem @OrderNumber, ‘1049’, NULL, 6, NULL, NULL, NULL; In other words, only customers 110 and 111 order all the toys and nothing else. Customer 112 pur- chases all the toys, as well as some kites. Customer 113 is an error check because she bought only one toy. At least a couple of methods exist for coding a relational-division query. The original method, proposed by Chris Date, involves using nested correlated subqueries to locate rows in and out of the sets. A more direct method has been popularized by Joe Celko: It involves comparing the row count of the dividend and divisor data sets. Basically, Celko’s solution is to rephrase the question as ‘‘For whom is the number of toys ordered equal to the number of toys available?’’ The query is asking two questions. The outer query will group the orders with toys for each contact, and the subquery will count the number of products in the toy product category. The outer query’s HAVING clause will then compare the distinct count of contact products ordered that are toys against the count of products that are toys: Is number of toys ordered SELECT Contact.ContactCode FROM dbo.Contact JOIN dbo.[Order] ON Contact.ContactID = [Order].ContactID JOIN dbo.OrderDetail ON [Order].OrderID = OrderDetail.OrderID JOIN dbo.Product ON OrderDetail.ProductID = Product.ProductID JOIN dbo.ProductCategory ON Product.ProductCategoryID = ProductCategory.ProductCategoryID WHERE ProductCategory.ProductCategoryName = ‘Toy’ GROUP BY Contact.ContactCode HAVING COUNT(DISTINCT Product.ProductCode) = equal to number of toys available? (SELECT Count(ProductCode) FROM dbo.Product JOIN dbo.ProductCategory ON Product.ProductCategoryID = ProductCategory.ProductCategoryID WHERE ProductCategory.ProductCategoryName = ‘Toy’); Result: ContactCode 110 111 112 284 www.getcoolebook.com Nielsen c11.tex V4 - 07/23/2009 1:54pm Page 285 Including Data with Subqueries and CTEs 11 Some techniques in the previous query — namely, group by, having,andcount() —are explained in the next chapter, ‘‘Aggregating Data.’’ Exact relational division Exact relational division finds exact matches without any remainder. It takes the basic question of rela- tional division with remainder and tightens the method so that the divisor will have no extra rows that cause a remainder. In practical terms it means that the example question now asks, ‘‘Who has ordered only every toy?’’ If you address this query with a modified form of Joe Celko’s method, the pseudocode becomes ‘‘For whom is the number of toys ordered equal to the number of toys available, and also equal to the total number of products ordered?’’ If a customer has ordered additional products other than toys, then the third part of the question eliminates that customer from the result set. The SQL code contains two primary changes to the previous query. One, the outer query must find both the number of toys ordered and the number of all products ordered. It does this by finding the toys purchased in a derived table and joining the two data sets. Two, the HAVING clause must be modified to compare the number of toys available with both the number of toys purchased and the number of all products purchased, as follows: Exact Relational Division Is number of all products ordered SELECT Contact.ContactCode FROM dbo.Contact JOIN dbo.[Order] ON Contact.ContactID = [Order].ContactID JOIN dbo.OrderDetail ON [Order].OrderID = OrderDetail.OrderID JOIN dbo.Product ON OrderDetail.ProductID = Product.ProductID JOIN dbo.ProductCategory P1 ON Product.ProductCategoryID = P1.ProductCategoryID JOIN and number of toys ordered (SELECT Contact.ContactCode, Product.ProductCode FROM dbo.Contact JOIN dbo.[Order] ON Contact.ContactID = [Order].ContactID JOIN dbo.OrderDetail ON [Order].OrderID = OrderDetail.OrderID JOIN dbo.Product ON OrderDetail.ProductID = Product.ProductID JOIN dbo.ProductCategory ON Product.ProductCategoryID = ProductCategory.ProductCategoryID WHERE ProductCategory.ProductCategoryName = ‘Toy’ 285 www.getcoolebook.com Nielsen c11.tex V4 - 07/23/2009 1:54pm Page 286 Part II Manipulating Data With Select ) ToysOrdered ON Contact.ContactCode = ToysOrdered.ContactCode GROUP BY Contact.ContactCode HAVING COUNT(DISTINCT Product.ProductCode) = equal to number of toys available? (SELECT Count(ProductCode) FROM dbo.Product JOIN dbo.ProductCategory ON Product.ProductCategoryID = ProductCategory.ProductCategoryID WHERE ProductCategory.ProductCategoryName = ‘Toy’) AND equal to the total number of any product ordered? AND COUNT(DISTINCT ToysOrdered.ProductCode) = (SELECT Count(ProductCode) FROM dbo.Product JOIN dbo.ProductCategory ON Product.ProductCategoryID = ProductCategory.ProductCategoryID WHERE ProductCategory.ProductCategoryName = ‘Toy’); The result is a list of contacts containing the number of toys purchased (2) and the number of total products purchased (2), both equal to the number of products available (2): ContactCode 110 111 Composable SQL Composable SQL, also called select from output or DML table source (in SQL Server BOL), is the ability to pass data from an insert, update, or delete’s output clause to an outer query. This is a very powerful new way to build subqueries, and it can significantly reduce the amount of code and improve the per- formance of code that needs to write to one table, and then, based on that write, write to another table. To track the evolution of composable SQL (illustrated in Figure 11-3), SQL Server has always had DML triggers, which include the inserted and deleted virtual tables. Essentially, these are a view to the DML modification that fired the triggers. The deleted table holds the before image of the data, and the inserted table holds the after image. Since SQL Server 2005, any DML statement that modifies data ( INSERT, UPDATE, DELETE, MERGE) can have an optional OUTPUT clause that can SELECT from the virtual inserted and deleted table. The OUTPUT clause can pass the data to the client or insert it directly into a table. 286 www.getcoolebook.com Nielsen c11.tex V4 - 07/23/2009 1:54pm Page 287 Including Data with Subqueries and CTEs 11 The inserted and deleted virtual tables are covered in Chapter 26, ‘‘Creating DML Trig- gers,’’ and the output clause is detailed in Chapter 15, ‘‘Modifying Data.’’ In SQL Server 2008, composable SQL can place the DML statements and its OUTPUT clause in a sub- query and then select from that subquery. The primary benefit of composable SQL, as opposed to just using the OUTPUT clause to insert into a table, is that OUTPUT clause data may be further filtered and manipulated by the outer query. FIGURE 11-3 Composable SQL is an evolution of the inserted and deleted tables. Output Select From Output Inserted Deleted Insert Select From SQL 2008 SQL 2005 SQL 2000 DML Insert, Update, Delete, Merge Client, table variable, temp tables, tables subquery The following script first creates a table and then has a composable SQL query. The subquery has an UPDATE command with an OUTPUT clause. The OUTPUT clause passes the oldvalue and newvalue columns to the outer query. The outer query filters out TestData and then inserts it into the CompSQL table: CREATE TABLE CompSQL (oldvalue varchar(50), newvalue varchar(50)); INSERT INTO CompSQL (oldvalue, newvalue ) SELECT oldvalue, newvalue FROM (UPDATE HumanResources.Department SET GroupName = ‘Composable SQL Test’ OUTPUT Deleted.GroupName as ‘oldvalue’, Inserted.GroupName as ‘newvalue’ WHERE Name = ‘Sales’) Q; 287 www.getcoolebook.com Nielsen c11.tex V4 - 07/23/2009 1:54pm Page 288 Part II Manipulating Data With Select SELECT oldvalue, newvalue FROM CompSQL WHERE newvalue <> ‘TestData’; Result: oldvalue newvalue Sales and Marketing Composable SQL Test Note several restrictions on composable SQL: ■ The update DML in the subquery must modify a local table and cannot be a partitioned view. ■ The composable SQL query cannot include nested composable SQL, aggregate function, sub- query, ranking function, full-text features, user-defined functions that perform data access, or the textptr function. ■ The target table must be a local base table with no triggers, no foreign keys, no merge replication, or updatable subscriptions for transactional replication. Summary While the basic nuts and bolts of subqueries may appear simple, they open a world of possibilities, as they enable you to build complex nested queries that pull and twist data into the exact shape that is needed to solve a difficult problem. As you continue to play with subqueries, I think you’ll agree that herein lies the power of SQL — and if you’re still developing primarily with the GUI tools, this might provide the catalyst to move you to developing SQL using the query text editor. A few key points from this chapter: ■ Simple subqueries are executed once and the results are inserted into the outer query. ■ Subqueries can be used in nearly every portion of the query — not just as derived tables. ■ Correlated subqueries refer to the outer query, so they can’t be executed by themselves. Con- ceptually, the outer query is executed and the results are passed to the correlated subquery, which is executed once for every row in the outer query. ■ You don’t need to memorize how to code relational division; just remember that if you need to join not on any row but every row, then relational division is the set-based solution to do the job. ■ Composable SQL is useful if you need to write to multiple tables from a single transaction, but there are plenty of limitations. The previous chapters established the foundation for working with SQL, covering the SELECT state- ment, expressions, joins, and unions, while this chapter expanded the SELECT with powerful subqueries and CTEs. If you’re reading through this book sequentially, congratulations — you are now over the hump of learning SQL. If you can master relational algebra and subqueries, the rest is a piece of cake. The next chapter continues to describe the repertoire of data-retrieval techniques with aggregation queries, where using subqueries pays off. 288 www.getcoolebook.com Nielsen c12.tex V4 - 07/21/2009 12:46pm Page 289 Aggregating Data IN THIS CHAPTER Calculating sums and averages Statistical analysis Grouping data within a query Solving aggravating aggregation problems Generating cumulative totals Building crosstab queries with the case, pivot, and dynamic methods T he Information Architecture Principle in Chapter 2 implies that informa- tion, not just data, is an asset. Turning raw lists of keys and data into useful information often requires summarizing data and grouping it in meaningful ways. While summarization and analysis can certainly be performed with other tools, such as Reporting Services, Analysis Services, or an external tool such as SAS, SQL is a set-based language, and a fair amount of summarizing and grouping can be performed very well within the SQL SELECT statement. SQL excels at calculating sums, max values, and averages for the entire data set or for segments of data. In addition, SQL queries can create cross-tabulations, commonly known as pivot tables. Simple Aggregations The premise of an aggregate query is that instead of returning all the selected rows, SQL Server returns a single row of computed values that summarizes the original data set, as illustrated in Figure 12-1. More complex aggregate queries can slice the selected rows into subsets and then summarize every subset. The types of aggregate calculations range from totaling the data to performing basic statistical operations. It’s important to note that in the logical order of the SQL query, the aggregate functions (indicated by the Summing function in the diagram) occur following the FROM clause and the WHERE filters. This means that the data can be assem- bled and filtered prior to being summarized without needing to use a subquery, although sometimes a subquery is still needed to build more complex aggregate queries (as detailed later in the ‘‘Aggravating Queries’’ section in this chapter.) 289 www.getcoolebook.com Nielsen c12.tex V4 - 07/21/2009 12:46pm Page 290 Part II Manipulating Data With Select What’s New with Query Aggregations? M icrosoft continues to evolve T-SQL’s ability to aggregate data. SQL Server 2005 included the capability to roll your own aggregate functions using the .NET CLR. SQL Server 2008 expands this feature by removing the 8,000-byte limit on intermediate results for CLR user-defined aggregate functions. The most significant enhancement to query aggregation in SQL Server 2008 is the ability to use grouping sets to further define the CUBE and ROLLUP functions with the GROUP BY clause. WITH ROLLUP and WITH CUBE have been deprecated, as they are non-ISO-compliant syntax for special cases of the ISO-compliant syntax. They are replaced with the new, more powerful, syntax for ROLLUP and CUBE. FIGURE 12-1 The aggregate function produces a single row result from a data set. Where From Col(s), Expr(s) Single Row Summing Data Source(s) Basic aggregations SQL includes a set of aggregate functions, listed in Table 12-1, which can be used as expressions in the SELECT statement to return summary data. ON the WEBSITE ON the WEBSITE The code examples for this chapter use a small table called RawData. The code to create and populate this data set is at the beginning of the chapter’s script. You can download the script from www.SQLServerBible.com. CREATE TABLE RawData ( RawDataID INT NOT NULL IDENTITY PRIMARY KEY, Region VARCHAR(10) NOT NULL, Category CHAR(1) NOT NULL, Amount INT NULL, SalesDate Date NOT NULL ); 290 www.getcoolebook.com Nielsen c12.tex V4 - 07/21/2009 12:46pm Page 291 Aggregating Data 12 TABLE 12-1 Basic Aggregate Functions Aggregate Function Data Type Supported Description sum() Numeric Totals all the non-null values in the column avg() Numeric Averages all the non-null values in the column. The result has the same data type as the input, so the input is often converted to a higher precision, such as avg(cast col as a float). min() Numeric, string, datetime Returns the smallest number or the first datetime or the first string according to the current collation from the column max() Numeric, string, datetime Returns the largest number or the last datetime or the last string according to the current collation from the column Count[_big](*) Any data type (row-based) Performs a simple count of all the rows in the result set up to 2,147,483,647. The count_big() variation uses the bigint data type and can handle up to 2 ˆ 63-1 rows. Count[_big] ([distinct] column) Any data type (row-based) Performs a simple count of all the rows with non-null values in the column in the result set up to 2,147,483,647. The distinct option eliminates duplicate rows. Will not count blobs. This simple aggregate query counts the number of rows in the table and totals the Amount column. In lieu of returning the actual rows from the RawData table, the query returns the summary row with the row count and total. Therefore, even though there are 24 rows in the RawData table, the result is a single row: SELECT COUNT(*) AS Count, SUM(Amount) AS [Sum] FROM RawData; Result: Count Sum 24 946 291 www.getcoolebook.com . Data.’’ In SQL Server 2008, composable SQL can place the DML statements and its OUTPUT clause in a sub- query and then select from that subquery. The primary benefit of composable SQL, as opposed. query. FIGURE 11-3 Composable SQL is an evolution of the inserted and deleted tables. Output Select From Output Inserted Deleted Insert Select From SQL 2008 SQL 2005 SQL 2000 DML Insert, Update, Delete, Merge Client,. products available (2): ContactCode 110 111 Composable SQL Composable SQL, also called select from output or DML table source (in SQL Server BOL), is the ability to pass data from an insert,

Ngày đăng: 04/07/2014, 09:20

Từ khóa liên quan

Tài liệu cùng người dùng

Tài liệu liên quan