I recently read the book Agile Data Warehouse Design – Collaborative Dimensional Modeling, from Whiteboard to Star Schema (quite the title) by Lawrence Corr and Jim Stagnitto. The book was recommended to my years ago by a former colleague (the book is from 2011, with the latest revision from 2014) and it has been sitting on my “to-read” for all this time. Quite frankly, I had forgotten about the book, but at a precon workshop Johnny Winter mentioned the book so I decided to go read it.

TL;DR: my only regret of when reading this book, was that I haven’t read it sooner.

The book is amazing. It’s very clearly written, and it’s goal is to help you become a better data warehouse modeler, in the context of designing a DWH using an agile methodology. The book has planted itself firmly in my top 5 of best technology books (alongside The Data Warehouse Toolkit and Star Schema The Complete Reference).

The book is divided in two parts. The first part talks about modelstorming, a brainstorming technique for data warehouse modeling that is introduced in this book, alongside the BEAM* framework. BEAM stands for Business Event Analysis & Modeling. Using 7 questions (who, what, where, how many, who and how > the 7w), you work together with IT and business stakeholders to define, analyze, model and document business processes. The result is a BEAM table (which kind of looks like a fact or dimension table but without surrogate keys). Each row contains an example of how an event (for example, a customer buys a product) looks like. Because you use examples, the data will become more clear for the business stakeholders. The BEAM table can be used as documentation, and it serves as a good foundation for designing the logical and physical layers of your data warehouse. This technique is well-suited to be used in an agile context, as you can model one type of event (which probably corresponds with one star schema) at a time and you can do this in a sprint for example.

In short, the first part of the book will help you to do better and more efficient “requirements gathering & design workshops” with your stakeholders.

The second part talks about dimensional design patters, and dives deeper on how you can design your dimensions and fact tables better (roughly one or two questions from the 7w corresponds with one chapter). Some of the content can probably found in the Kimball books as well, but it was great to have a refresher. I definitely picked up a few nice design techniques, such as the hierarchy map pattern for dealing with parent-child relationships. Quite some exotic use cases are dealt with in this part of the book, and it will make you a better data warehouse developer when you’ve finished the book.

In conclusion: if you want to be a better, more agile data warehouse developer, than I absolute recommend this book. I recommend though that you already have a couple of years behind your belt, it will make you appreciate the book better.

I was asked to do a review of the book Microsoft Power BI Performance Best Practices 2nd edition (Amazon link), which means I got a copy for free. The book is written by Thomas Leblanc and Bhavik Merchant and published by Packt.

As the title obviously implicates, the book aims to give you a set of best practices regarding Power BI performance, but in the broadest sense possible. The book will not only talk about DAX or that you shouldn’t put too many visuals on one page, but it also explores capacity management, data modelling (star schema all the things!), the benefits of a performance governance framework, DirectQuery & Direct Lake performance, Power Query folding and so on. The book talks about performance in every layer of a Power BI architecture.

With about 320 pages, the book is a compromise between high-level overviews and deep technical content. If you want to know everything about DAX performance tuning, this probably isn’t the book for you (there is a book for that, it’s called The Definitive Guide to DAX and it’s over 700 pages long). However, the book will set you on the right path. It’s an excellent book for people who have a bit of experience in Power BI and who want to deepen their knowledge, or at least want to know what they should take into account regarding performance when they start a new Power BI project.

I think the book is nicely written, it has decent examples and there were definitely some interesting tips that I can use. However, sometimes I could notice the book was written by two different authors. There was some redundant information (for example, the Fabric Capacity Metrics App is explained in two different chapters. On the other hand, that monstrosity needs all the explaining that there can be). There were also some editing mistakes (some typos, some incorrect links and even a section missing). But all in all I enjoyed reading the book.

One thing I would have liked more is additional reading material. Sure, there are links to blog posts or official documentation, but there are no links to other books. Even if some books are the “de facto” standard in the industry (I mean, not a single book of the Italians mentioned in a chapter about DAX?). Only one chapter has a “further reading” section at the end. If the book doesn’t dive deep in the technical details – which again, this is fine, otherwise this book would have been at 2,000 pages – at least provide more reading materials. I was impressed though with the inclusion of some Fabric content, even this is all still quite new and changing very fast.

I’d recommend this book for people who are still somewhat in the start of their Power BI journey, so they know what they can focus on when delivering Power BI project. Seasoned Power BI professionals should know most of the stuff covered in the book, but it’s always nice to have your knowledge confirmed and to plug any holes that might exist.

Sometimes you need a numbers table (also called tally table) when you’re working with data. It’s a table with one single integer column that contains incremental numbers (0,1,2,3,4,…). In a database, it’s fairly easy to generate using either cross-joins or a generator function (GENERATE_SERIES in T-SQL). Recently, I needed such a table in Power BI Desktop. Suppose you don’t have a database as a source (or maybe you cannot change the database), so we need to generate this in Power Query. First, add a blank query:

Then you go to the advanced editor, where you paste the following code:

let
    Source =  List.Generate(()=>0, each _ <= 100, each _ + 1),
    #"Converted to Table" = Table.FromList(Source, Splitter.SplitByNothing(), null, null, ExtraValues.Error),
    #"Changed Type" = Table.TransformColumnTypes(#"Converted to Table",{{"Column1", Int64.Type}}),
    #"Renamed Columns" = Table.RenameColumns(#"Changed Type",{{"Column1", "NumberCol"}})
in
    #"Renamed Columns"

This will generate a table with 101 rows, starting at 0 and ending with 100.

UPDATE:

I got this reaction from Alex Powers – a Fabric aficionado from Microsoft – on Bluesky:

This means we can replace the first line of the M code with the elegantly simple {0..100}.

Suppose you want to log into Azure Data Factory, and you have access to multiple tenants. No problem, you just pick the one you need when you launch Azure Data Studio:

If you’re already logged into another tenant, no problem, you can easily switch as explained in this blog post. You can do the same in the Azure portal (or in other services such as Azure Devops or even Microsoft Teams):

But not in the Power BI Service (or in Microsoft Fabric). Nope. There was no option there to switch tenants. You had to do some awkward work around by adding the tenant ID to the URL. And the problem is even worse in Power BI Desktop. I explain how you can log into another tenant in this blog post. But let us rejoice, because we can now easily switch between tenants in the Power BI Service!

Hoozah! You still have to do the excruciating work around in Power BI Desktop though.

This book was making its rounds on social media, and the concept seems interesting enough to make me want to read it. It’s a very short book (only 106 pages), but a pleasant read. It focuses on the people side of a data strategy, instead of focusing on technology and tools as sometimes many of us do.

The author introduces the 5C model: Competence, Collaboration, Communication, Creativity and Conscience. Each “C” gets its own chapter, where the first three make up the bulk of the book.

There are certainly some interesting concepts in the book, such as the follow the pain methodology. You can use it when you interview people when you’re looking for problems your data strategy might solve. People with the biggest pains will be very pleased to work with the data team, as it will mean their pain will be reduced.

The book finishes with a questionnaire, where each topic gets its own set of questions that you can ask yourself or your organization, to assess how well you are implementing the “human side” of your data strategy.

I can definitely recommend this book, as it’s refreshing to read and it’s a nice change of pace from all those technical books.

The gaps and islands problem is a common problem in data analysis. Some examples are:

• How long are active periods that my server was running? Or, how long are the periods that the server was down?
• On average, how long are the billable periods of my consultants?
• What was the longest stretch of days without rain?

In this session, you’ll be introduced to the powerful concepts of window functions in T-SQL. With a practical use case, the gaps and islands problem is explained and solved. At the end of the session, you should feel confident in using window functions in your own data analyses.

A basic understanding of T-SQL querying concepts is required to follow this session.

I hope to see you there!

Having multiple tenants usually isn’t an issue. In the Azure Portal, it’s easy to switch between multiple organizations (or directories as they’re sometimes called):

You get a list of all organizations you’re account has been added into, and you switch to the one you need.

In Azure Data Factory, you can do the same thing.

However, such an easy switch is not available in Power BI, unfortunately. When you go to https://app.powerbi.com and you log into your account, you will always go to the Power BI service of your own home tenant. So, how do you go to another tenant with your own account? You use this straight-forward, user-friendly (ahem) trick: you add the tenant-ID in the URL. Because every regular user knows their tenant ID, right? Anyway, if you do know it, you just add it to the URL like this:

https://app.powerbi.com/home?ctid=yourtenantID&experience=power-bi

You can find your tenant ID in the Azure Portal on the overview page of Entra ID:

But what about Power BI Desktop? There’s no URL where you can put a tenant ID, and there certainly isn’t an easy button to switch tenant. By default, Power BI Desktop will also connect to your home tenant (especially if you’ve logged in before). To connect to another tenant, you need to follow these steps:

1. In the top-right corner, click on your name.

2. Choose to switch to another account.

3. You will get a non-helpful window where you need to enter your e-mail address. Since the address is the same in all the tenants, this is not going to help you any further. You need to get to the “real” login screen where you have multiple options to log in. To get there, you can enter an e-mail that won’t work or isn’t associated with any of the tenants.

4. This will take you to the login screen you need. Click on Use another account.

5. This will give a login screen with no email address entered yet. However, you cannot enter your email address just yet, because that will take you – again – to your home tenant. Instead, choose Sign-in options.

6. This will finally give you the option to specify another tenant.

7. Unfortunately, no handy drop-down like in any other service; you need to enter the name of the tenant manually. Don’t make a mistake, because you’ll get an error and choosing an organization will be gone from the sign-in options, meaning you can start over from scratch.

8. After entering the tenant you need, you can specify your own e-mail again, but instead of your home tenant you will log into the tenant you just specified. Hoozah.

If you think this is quite cumbersome and not that user-friendly, please upvote the following idea: Switch accounts and tenants in the portal in the same way as Azure.

The biggest advantage for the Lookup is that it supports all data sources, while the Script activity only supports databases (aka stuff that can deal with SQL). The Script activity on the other hand can execute multiple statements which might save you the effort of configuring multiple activities.

The biggest downside of the Lookup is that this the default:

However, there’s also another downside of the Lookup which isn’t mentioned: it can only return max 5000 rows. Do you really want to loop over 5000 items in ADF, probably not. But let’s suppose you do, then the Script activity is your savior.

How do we use it as a Lookup? Configure your query as normal, and make sure there’s at least one SELECT statement in there that actually returns data.

When you run the activity, you’ll get JSON output like this:

You’ll get a count of how many result sets are returned, along with an array called resultSets. Each result set has a row count, and another array called rows. To loop over the rows of a specific result set, you can use the following expression in a ForEach:

@activity('myScriptActivity').output.resultSets[0].rows

If you only have one result set, you take the index 0 of the resultSets array. If you need the second, you use 1, and so on. And that’s it, you are now using a Script activity instead of a Lookup.