Companion content

Insert your email address and press Download for access to the files used in this book.

Keep me informed about BI news and upcoming articles with a bi-weekly newsletter (uncheck if you prefer to proceed without signing up for the newsletter)

Send me SQLBI promotions (only 1 or 2 emails per year)

By pressing the Download button you are agreeing to our Privacy Policy.

Errata corrige

To ensure the ongoing accuracy of this book and its companion content, we have reviewed and confirmed the errors listed below. If you find a new oversight, please report it to us.

  • Page 40: Fact table instead of dimension

    Replace “dimension” with “fact table” in the second-last paragraph in the page. It should be:

    In the previous example, you learned the basics of multiple fact table handling. There, you had two over-denormalized fact tables and, to make the model a better one, you had to revert to a simpler star schema. In this next example, we analyze a different scenario, again using Sales and Purchases.

    Edited on Mar 24, 2018
  • Page 52: Wrong data loaded in sample file F03 xx 21.xlsx

    The OrdersInvoices bridge table in the sample file F03 xx 21.xlsx contains inaccurate data because each invoice should include only orders from the same customer.

    The model is correct; we are bringing to your attention the fact that the data loaded in the example might be inconsistent with the data in the other tables.

    Edited on Apr 26, 2020
  • Page 79: Date in Figure 4-31

    In Figure 4-31 the date for the first row (Easter 2009) should be April 12, 2009 instead of December 4, 2009.

    Edited on Mar 24, 2018
  • Page 94: Incorrect reference to Customer table instead of Sales table.

    The paragraph after Figure 5-4 references the Customer table, but it should reference the Sales table instead.
    The correct paragraph is:

    The scenario suddenly becomes much more complex, but there are multiple ways to manage this. In this chapter, we will show a few of them that help in building an analytical report that can track who the manager was at the time of the sale. Imagine the model has already been created by the IT department managing the data warehouse and submitted to you. If done correctly, the Sales table you receive will contain the following two columns:

    Edited on Jun 3, 2019
  • Page 191: Inverted arguments in TREATAS function

    The arguments of TREATAS are inverted in the code.
    The following code:

    Budget 2009 :=
        SUM ( Budget[Budget] ),
        TREATAS ( VALUES ( Budget[Brand] ), 'Product'[Brand] ),
        TREATAS ( VALUES ( Budget[CountryRegion] ), Store[CountryRegion] )

    Must be changed to:

    Budget 2009 :=
        SUM ( Budget[Budget] ),
        TREATAS ( VALUES ( 'Product'[Brand] ), Budget[Brand] ),
        TREATAS ( VALUES ( Store[CountryRegion] ), Budget[CountryRegion] )
    Edited on Sep 12, 2019
  • Page 193: Code error, ISBLANK should be used instead of ISEMPTY

    The right code of the PriceRange calculated column is the following:

    Sales[PriceRange] =
    VAR ResultValue =
        CALCULATE (
            IFERROR ( VALUES ( PriceRanges[PriceRange] ), "Overlapping Configuration" ),
            FILTER (
                AND (
                    PriceRanges[MinPrice] <= Sales[Net Price],
                    PriceRanges[MaxPrice] > Sales[Net Price]
        IF ( ISBLANK ( ResultValue ), "Wrong Configuration", ResultValue )

    In the paragraph after the code sample the function name ISEMPTY must be replaced with ISBLANK.

    Edited on Sep 28, 2018