Optimizing a Power BI data model is conceptually not too different from optimizing most types of databases. You want to reduce the size of the database as much as possible, so the server's CPU has less data pull from disk into RAM and then from RAM into cache before beginning the report processing. And like a relational database, the relationships between tables in the Power BI data model need to be clean and straightforward, so many-to-many relationships should be avoided as well as compound keys. This is why we have reporting-oriented data designs like the star schema. To see how this is achieved in practical terms, we must first understand the underlying architecture of Power BI's Vertipaq database engine.

First and foremost, data imported into Power BI, instead of direct querying of an external data source, are stored as columns rather than rows. This is not merely a case of transposing rows to columns as you might in Excel with the Special Paste function, as the column data is also compressed by only storing unique values. Storing unique values as columns is the primary mechanism behind Power BI's relatively quick performance. 

Cardinality is the term given to describe the uniqueness of values within a dataset, or in this case, a column. As Power BI's Vertipaq engine only stores unique values, high cardinality data can negatively impact performance. Not only can reducing cardinality reduce the amount of raw data but also the related index data for looking up column values. Less unique values mean small indexes, which translates into faster performance.

I'll start with a freshly imported model, and as I apply the various optimizations, we will see how the data model reduces in size, which in turn will lead to better report performance.