Data Analyst Professional · Модуль 2 · Урок 5 із 51
Табличні дані: структура, типи й контроль введення
Excel і Google Sheets стають надійним аналітичним інструментом не через форматування, а через структуру. Один рядок має представляти одне спостереження, кожна колонка — одне поле, а типи, ключі та правила введення повинні бути явними.
Шість правил аналітичної таблиці
Унікальні, стабільні назви колонок без подвійних заголовків і merged cells.
Замовлення, позиція замовлення або клієнт — оберіть grain і не змішуйте.
Не зберігайте «Київ, Петренко, 12.05» в одній клітинці.
Дата не повинна чергуватися з текстом «невідомо», а число — з символом валюти.
ID має однозначно ідентифікувати grain; ім’я або позиція рядка не є надійним ключем.
Порожні рядки, subtotal всередині source і кольори замість значень ламають сортування та pivot.
Архітектура workbook
| Аркуш | Призначення | Правило |
|---|---|---|
| README | Мета, owner, джерела, refresh, версія, limitations | Читається без відкривання формул |
| RAW | Незмінений імпорт або контрольна копія джерела | Не редагувати вручну |
| MAP | Довідники й узгоджені відповідності | Ключі унікальні, owner відомий |
| CALC | Перетворення, helper columns і формули | Один крок має пояснювану логіку |
| CHECKS | Row count, duplicates, missing keys, totals, freshness | Чіткі PASS/WARN/FAIL |
| REPORT | Pivot, KPI й таблиці для користувача | Не містить прихованої ручної правки фактів |
Таблиця Excel і range у Sheets
Excel Table додає header row, filters, calculated columns і structured references; нові рядки можуть включатися в таблицю та формули автоматично. У Google Sheets джерело також має бути суцільним діапазоном із заголовком у кожній колонці. Формат не виправляє погану структуру, але добре структуроване source робить filters, formulas і pivot передбачуванішими.
Не плутайте формат і значення
Клітинка може виглядати як дата або відсоток, але всередині залишатися текстом. Перевіряйте тип через сортування, просту арифметику, функції перевірки типу або явне перетворення.
Типи, locale і приховані помилки
Data validation — профілактика, не очищення
Dropdown, date range, numeric bounds і custom rule зменшують нові помилки, але не виправляють старі автоматично. Критичні поля можуть мати validation, пояснення і conditional formatting для сигналу; сам колір не повинен бути єдиним носієм статусу.
Field | Type | Required | Allowed values | Example | Owner
order_id | text | yes | unique non-blank | 0001842 | CRM
order_date | date | yes | 2025-01-01…today | 2026-08-29 | Sales Ops
net_revenue | decimal | yes | >=0, UAH | 1250.50 | Finance
region | category | yes | MAP!region_code | CE | CommercialПрактика: підготуйте source
- Створіть README, RAW, MAP, CALC, CHECKS і REPORT.
- Для кожної source-колонки вкажіть тип, grain, required і owner.
- Перевірте унікальність ключа й кількість порожніх required values.
- Знайдіть дати/числа, що збережені як text.
- Додайте validation для двох контрольованих полів і не змінюйте RAW.
Офіційні довідки
Готовність до тесту
Ви можете назвати grain, відрізнити ID від міри, побудувати data dictionary та пояснити, чому merged cells, subtotal у source і змішані типи шкодять аналізу.
Закріпіть матеріал уроку
Три сценарні питання. Для зарахування уроку потрібно дати щонайменше дві правильні відповіді.