Пишу про ситуації, де слабке визначення, невдала модель або погана якість даних змінюють висновок. Тут важлива не термінологія, а наслідок для рішення.
Поле може бути заповнене майже всюди й усе одно бути непридатним. Серія документа в полі номера, дата в різних форматах, довідник із шістьма значеннями там, де очікується два. Повнота відповідає лише на питання “чи щось є в полі”. Якість починається після цього.
Коли в обміні передається лише номер, одна й та сама послідовність цифр може збігатися з різними документами. Надійна ідентифікація потребує типу, формату і правил перевірки. Це архітектурне питання, а не косметика SOAP або API.
Архітектура даних (Data Architecture) · Якість даних (Data Quality)
Якщо Power BI постійно очищає назви, зшиває довідники й відновлює логіку, якої немає в джерелі, звіт стає крихким. Частину роботи треба винести в модель даних і правила підготовки.
Бізнес-аналітика (Business Intelligence, BI) · Архітектура даних (Data Architecture)
Коли два підрозділи приносять різні цифри, стає зрозуміло, чи є в організації управління даними. Хто вирішує, яке визначення правильне. Яке джерело офіційне. Хто змінює правило. Якщо відповіді немає, регламент сам по собі не допоможе.