 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Books: Corrections
The Microsoft Data Warehouse Toolkit: With SQL Server 2005 and the Microsoft Business Intelligence Toolset
In spite of our best efforts, there are a few errors in the book. Here are the major ones we've spotted so far, along with the corrected text and/or figures. (Many thanks to the folks who have brought some of these to our attention—we appreciate your careful reading!)
| Page | Error and Correction |
|
| 60 | 6/10/06 |
Figure 2.5 has two problems. First, the DateKey in the SalesRep table should be switched with the SalesRepKey in the Orders table. Second, the arrows should be reversed. I spent too much time trying to get the arrows to line up with the columns (which Visio doesn't let you do if you actually have the foreign key relationship declared), and didn't pay attention to the actual relationships. Click to display a corrected version of Figure 2.5. Note that you may need to create an additional table to hold unique values of SalesRepGroupKeys to join between the fact table and the SalesRepGroup table. This will correctly support the one-to-many foreign key relationship from the fact table. |
| 61 | 6/10/06 | Figure 2.6 has similar problems. Click here for a corrected version of Figure 2.6. Note that in addition to the arrows and foreign key indicators, we removed CustomerKey from the Orders fact table. Obviously, the whole reason for the bridge table is because you can't have a one-to-many relationship between Orders and Customer. You could, however, include a PrimaryCustomerKey in the fact table, if you knew which one that was, and if a fair amount of Orders analysis was based on primary customer attributes. |
| 139 | 8/18/06 | The section on RAID should emphasize a configuration known as RAID 1+0 (or RAID 10) rather than RAID 0+1. RAID 1+0 is striping on top of mirrors and RAID 0+1 is a mirror on top of stripes. While there is little difference in terms of performance or cost, RAID 1+0 is more fault tolerant. For a good description of the difference, see: http://www.pcguide.com/ref/hdd/perf/raid/levels/multXY-c.html. |
| 160 | 6/14/06 |
The code sample in the Insert an Unknown Member Row should read: SET IDENTITY_INSERT Dim_MyDim ON We may have to get the syntax right, but we don't have to agree with it. ALTER TABLE PseudoPartition_200405 SWITCH TO PartitionTable Partition 6 The partition script example you can download from the Tools and Utilities page is correct. |
| 233 | 10/17/06 |
In the first paragraph, we suggest you set the AuditKey to 0 for now, and that we'll come back to fix it later, but we never do. As a result, your Promotions package will fail when you try and run it on page 236 because there is no row with a key of 0 in the DimAudit table. Try setting the AuditKey to -1 which will map to the default row in the DimAudit table that is added as part of the script from the Adventure Works dimensional modeling spreadsheet. |
| 305 | 11/15/07 |
In the third bullet point, we talk about reference dimensions. That paragraph should read: Reference dimension: A kind of Kimball Method outrigger table. In the relational dimensional model, you may have a piece of a dimension that’s referenced by two or more other dimensions. For example Customer, Vendor, and Shipping Destination could all refer to a set of geographic information. Sometimes you will design an outrigger Geography table that the other dimensions reference. In Analysis Services this design is called a Reference Dimension. In practice we’ve found it generally works best to avoid this Analysis Services feature and instead to fold the shared information into each primary dimension. You can do this by way of relational views or within the Data Source View layer. |
| 322 | 4/18/2007 |
In the sidebar on cube terminology, we say "You’re allowed to create multiple cubes within a single database, but the best practice is to create a database with a single cube." While this was the design intent when we wrote the book, it has turned out to not be a best practice. Here is a link to a Microsoft paper on this topic, and an excerpt that matches our current recommendation: "Having many measure groups in a cube can adversely affect the query performance of the cube, even for queries that only use a single measure group. If your DSV contains many potential fact tables and they will not usually be used together, consider creating multiple smaller cubes containing topic areas that are used together. Then, you can enable occasional cross-topic querying by creating linked measure groups that join together all measure groups in a special cross-topic cube." This paper is titled OLAP Design Best Practices for Analysis Services 2005—definitely worth reading: |
