Power Query: моделирование данных

Когда данных больше одной таблицы — нужна модель: какие таблицы связаны, по каким ключам, какие из них факты, какие измерения.

Звёздная схема

В центре — факт-таблица (сделки, заказы, события). Вокруг — измерения (клиенты, продукты, даты, регионы).

        dim_Date
           ↓
dim_Customer → fact_Orders ← dim_Product
           ↑
       dim_Region

Факт vs измерение

Факт	Измерение
Что произошло	Кто/что/где/когда
Sales, Quantity, Profit	Customer Name, City, Category
Много строк (миллионы)	Десятки-тысячи строк
Foreign keys + метрики	Primary key + атрибуты

Связи (relationships)

В Power BI: Модель → перетаскиваешь столбец CustomerID из fact на CustomerID в dim_Customer.

Кардинальность:

• Many-to-One (×→1) — стандарт. Много заказов одного клиента.
• One-to-One — редко, обычно ошибка
• Many-to-Many — особый случай, лучше избегать

Направление фильтра:

• Single (←) — фильтр идёт от измерения к факту. Это норма.
• Both (↔) — двунаправленный. Опасно — может создать двусмысленность

Календарь — обязательно отдельной таблицей

Calendar = CALENDARAUTO()

Потом помечаешь как Date Table. Без отдельного календаря TIME INTELLIGENCE функции типа SAMEPERIODLASTYEAR не работают.

Best practices

1. Один факт на одну тему — не смешивай продажи и трафик в одной таблице
2. Не дублируй атрибуты — название клиента только в dim_Customer, в fact_Orders только ID
3. Простые имена — fact_Sales, dim_Customer (префиксы помогают разобраться)
4. Скрывай технические колонки — внешние ключи спрячь правой кнопкой → Hide

Что важно запомнить

• Звёздная схема — стандарт BI. Изучи и применяй
• Снежинка (snowflake) — когда измерения разбиваются на под-измерения. Применяй редко
• Если модель плохая — ни одна DAX-мера не спасёт
• Каждая dim должна быть UNIQUE по primary key