Підготовка даних до міграції

🌐 Цей документ доступний українською та англійською мовами. Використовуйте перемикач у правому верхньому куті, щоб змінити версію.

1. Вступ

Завантаження даних до системи (первинне або повторне) на цей час здійснюється за допомогою файлів формату CSV. Перед тим, як розпочати процес міграції даних зі старого реєстру до нового, необхідно розв’язати організаційні питання взаємодії між власником даних і розробником реєстру.

2. Основні питання на етапі підготовки

  • Хто готує вихідні файли для завантаження: власник даних або розробник реєстру?

  • Як буде відбуватися передача файлу для завантаження: актом прийняття-передання, в робочому порядку, протоколом, супроводжувальним листом?

  • Якщо дані містять персональні дані, тоді повинно бути врегульовано питання безпеки при роботі з файлами.

  • Визначити порядок взаємодії в процесі завантаження файлу розробником: повідомлення про помилки можна висилати в робочому порядку з зазначенням типу і необхідних виправлень. Якщо завантаження виконано успішно — виконавець повідомляє власника даних офіційним листом про успішне завантаження.

  • Інші організаційні питання.

3. Контрольний список готовності даних до міграції

  • Описані формати, структура полів і дата модель в стані “To Be”.

  • Виконано зіставлення (mapping) полів дата моделі “As is” із “To be”.

  • Сформульовані правила і вимоги до файлів (шаблонів) завантаження.

4. Етапи міграції даних

Етапи міграції даних представлені на діаграмі нижче.

dataload migration stages

4.1. Підготовка шаблонів завантаження даних

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

У шаблоні вказується:

  • Опис усіх полів CSV-файлу даних для завантаження, включаючи:

    • Ім’я поля

    • Ознака обов’язковості заповнення поля

    • Приклад заповнення поля

    • Коментар

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

  • Опис заповнення безпосередньо полів таблиць нового реєстру в разі, якщо передбачається щось відмінне від перенесення даних «один в один» з файлу даних для завантаження. Актуально для посилальних полів, наприклад.

В процесі робіт цього етапу, в новому реєстрі має бути доступною функція первинного завантаження.

4.2. Виявлення джерел даних

Цей етап краще починати разом з попереднім етапом — "Підготовка шаблонів завантаження даних". В рамках цього етапу фахівці Замовника визначають, з яких систем або джерел, та які дані можуть бути вивантажені.

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

На практиці часто трапляються ситуації, коли надалі для забезпечення цілісності інформації деякі дані доводиться переносити з паперових джерел (зацифровувати) або навіть заносити в таблиці зі слів ключових співробітників Замовника. Проте, на цьому етапі необхідно виявити якомога більше потрібних даних.

4.3. Вивантаження вихідних даних

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

Увага! Замовник з тих чи інших причин (наприклад, питання безпеки — зберігання персональних даних) не завжди може вивантажити дані в повному обсязі — тільки структуру даних та кілька тестових позицій. Таким чином, вірогідним є виникнення ситуації, коли при тестових і підсумкових завантаженнях виявлятимуться невалідні[1] дані у вихідних таблицях, що призводитиме до незапланованих помилок і додаткових трудовитрат на їх виправлення.

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

4.4. Зіставлення даних

Зіставлення даних або Data mapping — це процес зіставлення даних історичних систем і нової (цільової) системи-приймача, у нашому випадку — старого реєстру і нового, тобто, вихідних даних і даних для завантаження. Етап зіставлення — найбільш трудомісткий і може займати понад 50% всіх робіт з міграції. На цьому етапі повною мірою залучається вся робоча група проєкту з міграції.

У процесі зіставлення даних необхідно виділити такі підетапи:

  • Зіставлення таблиць

  • Зіставлення полів

4.4.1. Зіставлення таблиць

Зіставлення таблиць або Зіставлення шаблонів — зіставлення таблиць вихідних даних і шаблонів даних для завантаження. Відповідність може бути як 1:1, так і N:N. В результаті такої роботи складається і підтримується реєстр зіставлення таблиць. Цей підетап є необхідним для наступного підетапу зіставлення полів та відстеження загального стану справ із зіставлення.

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

Назва шаблону для нового реєстру Найменування файлу-джерела Правила формування файлу-джерела Відповідальна особа Статус Коментар

laboratory.xls

Журнал обліку заяв та внесених до інформаційного переліку лабораторій.xlsx

Відомості про кадрове забезпечення лабораторій.xlsx

• Виконати аналіз і встановити відбір унікальних значень найменувань лабораторій.

• Сформувати єдиний перелік лабораторій з унікальними значеннями.

Вимоги до файлу:

Перший рядок - шапка.

Кількість стовпців — в залежності від структури шаблону.

Проаналізувати додаткові атрибути, необхідні для заповнення шаблону.

Найменування листа завжди "Sheet 1"

Іваненко І.І.

В процесі виконання

Тестовий коментар

4.4.2. Зіставлення полів

Зіставлення полів — це зіставлення полів таблиць в рамках вже наявного зіставлення таблиць. Результатом цієї роботи є реєстр зіставлення полів.

Приблизний вигляд зіставлення полів може бути наступним (на прикладі Реєстру атестованих лабораторій):

data load prep fields mapping

В рамках цього етапу необхідно також виконати всі можливі роботи з нормалізації даних.

4.5. Підготовка правил трансформації

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

Для оперативної роботи в процесі підготовчих етапів міграції й далі, в ході самої міграції в реєстрі реалізована технічна можливість первинного завантаження. Після відпрацювання етапу зіставлення, на виході повинні з’явитися заповнені файли-шаблони відповідно до вимог заповнення та форматів полів.

Підтримувані версії та формати файлів

  • Для завантаження підтримуються лише файли формату .csv.

  • Зведені таблиці не підтримуються.

Аналіз файлів для завантаження
  • файли CSV підтримують лише одну таблицю на лист.

  • кожен стовпчик файлу має заголовок, найменування якого має відповідати найменуванню поля в моделі даних (назва поля в базі даних);

  • дані не містять об’єднаних рядків або стовпців;

  • у файлах CSV як роздільники повинні використовуватися коми.

  • Відсутні порожні рядки над заголовками.

Слід враховувати, що файли CSV не підтримують ті ж формати, що й Excel. Якщо файл CSV має поля дати або часу, вони відображатимуться в CSV як рядкові поля. Таким чином, необхідно переконатися, що значення, які можуть починатися з символів "0" (коди, номери телефонів, дата, час тощо), представлені у файлі коректно.

За детальною специфікацією щодо формату файлів для первинного завантаження даних до БД зверніться до секції Вимоги до файлів для автоматичного завантаження до БД.

4.6. Вивантаження, трансформація та завантаження даних

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

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

У ході тестових міграцій Виконавець спільно із Замовником виявляють:

  • помилки конвертації, помилки завантаження даних;

  • проводять попередню оцінку якості даних, що завантажуються до нового реєстру;

  • за підсумками тестових міграцій складають або актуалізують план підсумкової міграції.

4.7. Узгодження даних

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

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

Наприклад:

  • перевірка дублювання за ключовими полями — можна і необхідно виконувати ще з вихідними даними;

  • встановлення типів полів;

  • цілісність посилань;

  • математичні нестикування;

  • перевірки обов’язкового заповнення полів;

  • заміна некоректних символів. Наприклад, латинські символи в кириличних полях («о», «а», «е» тощо) — особливо актуально це для ключових полів;

  • перевірка значень строкових полів на відповідність типів нового реєстру (обмеження за довжиною);

  • перевірка орфографічних помилок у довідниках, особливо тих довідниках, які створювалися додатково;

  • вибір типу роздільника: кома або крапка з комою можуть зустрічатися всередині довідника в одному рядку — тоді доцільно вибирати інші символи, наприклад, #, $ тощо.

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

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

1. Невалідний (англ. — invalid) — недійсний, невірний, неправильний.