Найкращі практики імпорту даних у Power BI - SQLBI

Не всі описані пропозиції можна застосувати до всіх ваших моделей даних. Ви повинні адаптувати ці найкращі практики до свого конкретного сценарію, розглядаючи, як досягти цілей, які є причиною певного зразка, більш ніж ледве застосувати його, не враховуючи плюси і мінуси кожного вибору.

Навіть якщо у статті згадується Power BI, усі описані найкращі практики також діють для табличних моделей Power Pivot та Analysis Services. Демо-файл, який ви можете завантажити (в кінці статті), містить зразок файлу Power BI та відповідні подання, визначені у файлі SQL для AdventureWorksDW.

Використовуйте подання

Завжди імпортуйте подання та ніколи не імпортуйте таблиці в моделі даних.

Якщо ви отримуєте дані з реляційної бази даних, наприклад, SQL Server або Oracle, вам ніколи не слід імпортувати таблицю бази даних безпосередньо у вашій моделі даних. Причина полягає в тому, що це створює сильну залежність між фізичною моделлю даних та звітом. З часом певні зміни в структурі бази даних можуть пошкодити існуючий звіт. Наприклад, перейменування стовпця або таблиці або зміна потужності таблиці - це всі операції, які вимагають відповідного зміни моделі даних Power BI.

Справжня проблема полягає в тому, що ніхто не знає, на скільки звітів може вплинути певна зміна. Навіть якщо аналіз залежностей був би можливий з технічної точки зору, сьогодні у нас немає стандартного інструменту та процедури для цього. Створення конкретних поглядів для кожної моделі даних відповідає введенню непрямого рівня, який спрощує управління змінами в структурі бази даних.

Найкраща практика використання подань:

Створіть схему для певної моделі даних: наприклад, це може бути ім'я маркера даних або назва групи звітів, які будуть використовувати спільну модель даних.
Створіть одне подання для кожної таблиці, яку потрібно створити в моделі даних Power BI в рамках цієї схеми.
Додайте до подання лише ті стовпці, які є корисними та будуть використовуватися в моделі даних Power BI.
Під час імпорту таблиць у Power BI видаліть ім'я схеми та збережіть лише ім'я подання.

Дотримуючись цієї найкращої практики, ви заявляєте в базі даних, які таблиці та стовпці використовуються у звіті, щоб адміністратор бази даних був відомий існуючим залежностям від самої бази даних. Перш ніж публікувати у виробництві зміни в структурі бази даних, можна адаптувати ці представлення, щоб вони продовжували працювати, повертаючи той самий вміст, не порушуючи оновлення існуючих звітів. Більше того, набагато простіше відстежувати залежності між поданнями та таблицями в одній реляційній базі даних. Наприклад, у SQL Server ви можете використовувати вбудовані функції (наприклад, Перегляд залежностей таблиці) або сторонні інструменти (наприклад, SQL Dependency Tracker від Red Gate).

Зберігання всіх подань для моделі даних в одній і тій же схемі спрощує відстеження залежних звітів. Зміна подання, щоб зберегти сумісність із існуючими звітами, як правило, є першим тимчасовим кроком. Якщо ви змінили структуру бази даних, можливо, ви хочете відобразити цю зміну у звітах, але з іншим часом. Ви не будете затримувати розгортання у виробництві певних змін бази даних, оскільки вам не потрібно синхронізувати розгортання нової версії всіх існуючих звітів. Вам просто потрібно розгорнути сумісну версію подань, які використовують нову структуру, і повідомити аналітиків BI, які володіють моделлю даних, що вони можуть використовувати нову версію даних, узгодивши з ними, як надати нову структуру (для наприклад, шляхом зміни існуючих поглядів або надання різних поглядів).

Створені подання повинні містити явний список стовпців і не повинні бути загальним, наприклад:

Погляди можуть включати перетворення даних. Це важливо, коли ви хочете включити бізнес-логіку, яка повинна бути спільною для різних моделей даних, тому вам не потрібно дублювати одну і ту ж логіку перетворення в декількох моделях даних Power BI.

Імпортуючи подання замість таблиць, модель даних може не розпізнати всі існуючі взаємозв'язки між таблицями, оскільки посилальні обмеження цілісності застосовуються до таблиць, а не до подань. Однак додавання взаємозв’язків до моделі даних вручну є лише мінімальними витратами

Використовуйте значущі імена

Імена як подань, так і стовпців, що виставляються у поданнях, повинні бути зручними для користувача та ідентичними іменам, доступним для користувачів.

Вам слід видалити будь-який префікс та будь-який суфікс, який ви можете використовувати в назвах таблиць. Наприклад, звичайно бачити Dim і Fact, які використовуються як префікси таблиць у схемі реляційної зірки. Немає сенсу показувати ці префікси користувачеві. Слід також уникати префіксів подань, таких як "v" або "vw". Ви повинні показати "Клієнти" замість "DimCustomers" або "vwCustomers".

Слід уникати скорочень, префіксів та суфіксів в назвах стовпців. Однак можливий виняток із відомих скорочень. Наприклад, вам слід використовувати “Сума продажів” замість “SalesAmt” або “SalesAmount”. Ви можете використовувати пробіл та спеціальні символи в іменах стовпців подання. Мета полягає в тому, щоб спростити життя для користувача, а не спростити життя для програміста, який повинен ввести ім'я стовпця на клавіатурі. У Power BI у вас є Intellisense, коли ви пишете формулу DAX.