|
Corrections
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 |
Date Added |
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 here 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
INSERT Dim_MyDim (MyDim_Key, MyDim_TK, Attribute1, Attribute2)
VALUES (-1, NULL, 'Unknown', 'Unknown')
SET IDENTITY_INSERT Dim_MyDim OFF
We may have to get the syntax right, but we don't have to agree
with it. |
| 171 |
6/10/06 |
The table name in the ALTER TABLE command is
slightly off. It should read:
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:
http://www.microsoft.com/technet/prodtechnol/sql/bestpractice/ olapdbpAnalysis
Services2005.mspx
|
|
