1. Серія контенту:
2. Цей контент є частиною серії: Автоматизація для програмістів
3. Про це циклі статей
4. Малюнок 1. Ручне внесення змін до таблиці бази даних
5. Малюнок 2. Автоматизація міграції бази даних
6. Що саме змінюється? DDL, DML, схеми, бази даних або дані
7. Управління змінами в базі даних за допомогою LiquiBase
8. Створення файлу change log і XML-елемента change set
9. Лістинг 1. Визначення набору змін в XML-файлі LiquiBase
10. Виконання LiquiBase з командного рядка
11. Лістинг 2. Запуск LiquiBase з командного рядка
12. Запуск LiquiBase в ході автоматизованого складання
13. Лістинг 3. Ant-сценарій для виконання завдання Ant updateDatabase
14. До і після
15. Малюнок 3. Стан бази даних до виконання набору змін LiquiBase
16. Малюнок 4. Зміни, внесені в базу даних після виконання набору змін LiquiBase
17. Інтеграція змін в БД
18. Таблиця 1. Підходи до інтеграції баз даних
19. Внесення змін у вже існуючу базу даних
20. Додавання стовпця
21. Лістинг 4. Використання команди Add Column для рефакторінга бази даних через набір змін LiquiBase
22. видалення стовпця
23. Лістинг 5. Видалення стовпця з бази даних
24. Лістинг 6. Створення нової таблиці в LiquiBase
25. Управління даними
26. Лістинг 7. Вставка даних через XML-елемент changeSet LiquiBase
27. Лістинг 8. Запуск довільного SQL-файлу з XML-елемента changeSet LiquiBase
28. Постійна синхронізація даних
29. Таблиця 2. зведена інформація по можливости LiquiBase
30. Ресурси для скачування

Автоматизація для програмістів

Використання LiquiBase для внесень змін до бази даних

Серія контенту:

Цей контент є частиною # з серії # статей: Автоматизація для програмістів

https://www.ibm.com/developerworks/ru/views/global/libraryview.jsp?series_title_by=Автоматизация+для+программистов

Слідкуйте за виходом нових статей цієї серії.

Цей контент є частиною серії: Автоматизація для програмістів

Слідкуйте за виходом нових статей цієї серії.

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

• ручне внесення змін до БД;
• різні версії БД у різних учасників команди розробників;
• непослідовні підходи до внесення змін (в базу даних або дані);
• неефективні механізми ручного управління змінами при переходах між версіями баз даних.

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

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

Про це циклі статей

Як розробники, ми працюємо над автоматизацією процесів для кінцевих користувачів; і все ж багато хто з нас не беруть переваги автоматизації самого процесу розробки. Саме тому, цикл статей jsp?search_by=%D0%90%D0%B2%D1%82%D0%BE%D0%BC%D0%B0%D1%82%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F+%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%81%D1%82%D0%BE%D0%B2:> "Автоматизація для програмістів" зосереджений на поясненні практичних прикладів автоматизації процесу розробки та покаже, як і коли успішно впровадити автоматизацію.

Малюнок 1. Ручне внесення змін до таблиці бази даних

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

• використання інструменту LiquiBase для міграції між різними версіями однієї і тієї ж бази даних;
• автоматичне виконання міграції бази даних;
• способи послідовного внесення змін до бази даних;
• виконання рефакторінга бази даних за допомогою LiquiBase.

На малюнку 2 сервер постійної інтеграції і збірки (build / continuous Integration server) опитує на предмет змін систему контролю версій (наприклад, Subversion). Коли сервер виявляє зміна в репозиторії, він запускає автоматичний сценарій збірки, який використовує LiquiBase для оновлення бази даних

Малюнок 2. Автоматизація міграції бази даних

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

Що саме змінюється? DDL, DML, схеми, бази даних або дані

У цій статті термін зміни в базі даних використовується для позначення структурних змін в базі даних за допомогою DDL-сценаріїв (Data Definition Language - мова визначення даних). (Деякі постачальники баз даних називають DDL-сценарії схемами.) Під змінами даних будуть розумітися зміни, зроблені в базі даних за допомогою DML-сценаріїв (Data Manipulation Language - мова маніпулювання даними).

Управління змінами в базі даних за допомогою LiquiBase

Продукт LiquiBase, що розвивається з 2006 року, - це безкоштовний інструмент з відкритим вихідним кодом, призначений для міграції з однієї версії бази даних на іншу (див. Розділ ресурси ). Крім LiquiBase, є і багато інших програм з відкритим вихідним кодом, призначені для міграції баз даних, наприклад, openDBcopy і dbdeploy. LiquiBase підтримує 10 типів баз даних, включаючи DB2, Apache Derby, MySQL, PostgreSQL, Oracle, Microsoft® SQL Server, Sybase і HSQL.

Щоб встановити LiquiBase, необхідно завантажити заархівований файл ядра LiquiBase, розпакувати його і помістити файл liquibase- version .jar в загальносистемний шлях пошуку програм (змінна PATH).

Щоб почати працювати з LiquiBase, потрібно виконати чотири кроки:

1. Створити файл з журналом змін в базі даних (change log).
2. Визначити набір змін (change set - XML-елемент) всередині цього файлу.
3. Застосувати набір змін до бази даних через командний рядок або сценарій збірки.
4. Перевірити зміни в базі даних.

Створення файлу change log і XML-елемента change set

Першим кроком для роботи з LiquiBase, як демонструється в лістингу 1, є створення XML-файла, відомого як журнал змін до бази даних (database change log):

Лістинг 1. Визначення набору змін в XML-файлі LiquiBase

Трохи про XML

Деякі читачі знайомі зі світом XML-сценаріїв, деякі ні. Багато розробники навіть звикли писати програми з використанням XML-сценаріїв (наприклад, за допомогою Apache Ant), але знання XML не є обов'язковим для адміністратора баз даних. Нещодавно я вирішив показати одному знайомому адміністратору бази даних деякі з можливостей LiquiBase. Йому сподобалися багато з потужних можливостей цієї утиліти для управління змінами в базі даних, але він скептично поставився до питання про те, чи зможуть адміністратори баз даних освоїти XML-подібна мова. Я переконав його, що LiquiBase також підтримує виклик довільних SQL-сценаріїв за допомогою тега sqlFile і підтримує рефакторинг через тег sql.

Як можна бачити, log-файл database change містить посилання на XML-схему (файл dbchangelog-1.7.xsd включений в інсталяційний пакет LiquiBase). У вузлі change log створюється вузол <changeSet>. Як показано в схемі LiquiBase, всередині <changeSet> в структурованому форматі визначаються зміни в базі даних.

Виконання LiquiBase з командного рядка

Після визначення блоку change set можна запустити LiquiBase з командного рядка способом, показаним в лістингу 2:

Лістинг 2. Запуск LiquiBase з командного рядка

У цьому прикладі при запуску LiquiBase йому передаються такі параметри:

• драйвер бази даних;
• значення змінної classpath для визначення місця розташування JAR-файлу драйвера бази даних;
• назва change log-файлу, який був створений в лістингу 1 - database.changelog.xml;
• URL-адресу бази даних;
• ім'я користувача та пароль.

На закінчення в лістингу 2 викликається команда update, яка вказує LiquiBase внести зміни в базу даних.

Запуск LiquiBase в ході автоматизованого складання

Замість того щоб викликати LiquiBase з командного рядка, можна зробити процес внесення зміни в базу даних частиною автоматизованого процесу складання, викликаючи для цього завдання Ant, що надається LiquiBase. Лістинг 3 містить приклад використання цього завдання Ant:

Лістинг 3. Ant-сценарій для виконання завдання Ant updateDatabase

У лістингу 3 створюється елемент з назвою update-database. У ньому визначається Ant-завдання з ім'ям updateDatabase, що відноситься до LiquiBase. У неї передаються необхідні значення, включаючи changeLogFile (визначає файл з журналом змін, описаний в лістингу 1 ) І інформацію для підключення до бази даних. В змінної classpath, що задається атрибутом classpathref, повинен бути шлях до файлу liquibase- version .jar.

До і після

Малюнок 3 показує стан бази даних до того, як в неї було внесено набір змін з лістингу 1 :

Малюнок 3. Стан бази даних до виконання набору змін LiquiBase

Малюнок 4 показує результати виконання набору змін з елемента change set для бази даних з командного рядка (як показано в лістингу 2 ) Або з Ant (як показано в лістингу 3 ):

Малюнок 4. Зміни, внесені в базу даних після виконання набору змін LiquiBase

Ряд аспектів на малюнку 4 заслуговує окремого розгляду. Крім нових таблиць, які були створені на основі опису в XML-елементі change set (див. лістинг 1 ), LiquiBase створив дві спеціальні таблиці. Перша LiquiBase-специфічна таблиця, звана databasechangelog, зберігає історію всіх змін, зроблених в базі даних - вона дозволяє відслідковувати, хто вніс зміни в базу даних і навіщо. Друга специфічна для LiquiBase таблиця, databasechangelock, визначає користувача, який заблокував базу даних для внесення в неї змін.

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

Інтеграція змін в БД

Автоматизуйте процес адміністрування баз даних

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

Протягом останніх років команди розробників привносили в управління змінами в базах даних принципи, подібні до тих, які використовуються при роботі з вихідним кодом. Тому цілком закономірно створення сценаріїв зміни для БД, завантаження цих сценаріїв в репозиторії вихідного коду і інтеграція цих змін в процес постійної збірки (Continuous-Integration process). У таблиці 1 представлено огляд ключових можливостей, які слід використовувати командам розробників при автоматизації процесу внесення змін до БД:

Таблиця 1. Підходи до інтеграції баз даних

Ці підходи покращують сумісність і дозволяють уникнути втрати даних при переходах між версіями програмного продукту.

Внесення змін у вже існуючу базу даних

Коли в додаток додаються нові можливості, часто виникає необхідність вносити структурні зміни в базу даних або змінювати обмеження таблиць. LiquiBase підтримує більше 30 команд для рефакторінга баз даних (див. Розділ ресурси ). Цей розділ зачіпає чотири з цих команд: додавання стовпця, видалення стовпця, створення таблиці і управління даними.

Додавання стовпця

Іноді виникає ситуація, коли неможливо на самому початку проекту заздалегідь передбачити і створити в таблицях всі стовпці, які знадобляться згодом. Також іноді користувачі можуть зажадати нових можливостей - наприклад, збору більшої кількості даних, - що може зажадати додавання нових стовпців. У лістингу 4 до таблиці distributor в базі даних додаються стовпці за допомогою команди рефакторінга LiquiBase addColumn:

Лістинг 4. Використання команди Add Column для рефакторінга бази даних через набір змін LiquiBase

Новий стовпець phonenumber має тип даних varchar.

видалення стовпця

Тепер припустимо, що через кілька версій було вирішено видалити стовпець phonenumber, доданий в лістингу 4. Це легко зробити за допомогою XML-команди dropColumn, як показано в лістингу 5:

Лістинг 5. Видалення стовпця з бази даних

створення таблиці

Додавання нової таблиці до бази даних - ще одна задача, часто виникає при рефакторінгу бази даних. У лістингу 6 створюється нова таблиця з ім'ям distributor; при цьому визначаються стовпці, обмеження і значення за замовчуванням для нової таблиці:

Лістинг 6. Створення нової таблиці в LiquiBase

В даному прикладі команда рефакторінга createTable є вкладеним вузлом XML-елемента changeSet (команда createTable також використовувалася в прикладі з лістингу 1 ).

Управління даними

Після рефакторинга структури БД (наприклад, за допомогою команд Add Column і Create Table) часто буває потрібно вставити дані в змінені таблиці. Більш того, може знадобитися зміна вже існуючих даних в таблицях перетворення і інших типах таблиць. У лістингу 7 наведено приклад того, як вставити дані через XML-елемент changeSet LiquiBase:

Лістинг 7. Вставка даних через XML-елемент changeSet LiquiBase

Можливо, у вас вже є готові SQL-сценарії для управління даними, або можливості LiquiBase XML здаються дещо обмеженими. Крім того, SQL-сценарії іноді зручніше для внесення масових змін в БД. LiquiBase може працювати з SQL-файлами. У лістингу 8 показаний фрагмент коду, в якому в XML-елементі changeSet викликається файл insert-distributor-data.sql, який вставляє дані в таблицю distributor:

Лістинг 8. Запуск довільного SQL-файлу з XML-елемента changeSet LiquiBase

LiquiBase підтримує багато інших команд рефакторінга бази даних, включаючи додавання таблиці перетворення і злиття стовпців. Вони визначаються так само, як показано в лістингу з 4 по 8-й.

Постійна синхронізація даних

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

• показати, як використовувати LiquiBase для створення сценаріїв міграції баз даних і як зробити ці зміни частиною автоматизованого процесу складання;
• описати принципи і практичні підходи до інтеграції баз даних, що забезпечують узгодженість процесу;
• показати, як використовувати команди рефакторінга типу addColumn і createTable для зміни структури таблиць і поновлення даних засобами LiquiBase

Таблиця 2 підсумовує деякі можливостей, що надаються LiquiBase:

Таблиця 2. зведена інформація по можливости LiquiBase

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

Ресурси для скачування

Схожі тими

• Automation for the people: Hands-free database migration : Оригінал статті (EN).
• LiquiBase : Ресурси по LiquiBase на Інтернет-сайті проекту, включаючи повний список команд рефакторінга , Які підтримує LiquiBase. (EN)
• Incremental Migration : (EN) (Мартін Фаулер, martinfowler.com, июль 2008 г.): у статті стверджується, що оскільки міграція даних є складним процесом, її слід виконувати частіше.
• Refactoring Databases: Evolutionary Database Design : (Скотт Емблер і Прамод Садаладж, Addison-Wesley Professional, 2006): книга про те, як розвивати і керувати схемами бази даних паралельно з управлінням вихідним кодом. (EN)
• Continuous Integration: Improving Software Quality and Reducing Risk (Поль Дюваль, Стів Матіас і Ендрю Гловер, Addison-Wesley Signature Series, 2007): приклади в розділі 5, "Continuous Database Integration", ( "Постійна інтеграція бази даних") демонструють, як вбудувати інтеграцію бази даних в автоматизований процес збірки. (EN)
• Recipes for Continuous Database Integration: Evolutionary Database Development : (Прамод Садаладж, Addison-Wesley Professional, 2007): книга про те, як реалізувати процес постійної інтеграції для бази даних. (EN)
• Evolutionary Database Design (EN) (Фаулер і Садаладж, martinfowler.com, 2003): стаття про постійну інтеграції та автоматизованому процесі рефакторінга при розробці баз даних. (EN)
• Database Integration in your Build scripts (EN) (Поль Дюваль, testearly.com, липень 2006): стаття про застосування DDL- і DML-сценаріїв в рамках автоматизованого процесу складання.
• LiquiBase : Завантажте LiquiBase і автоматизуйте процес міграції баз даних. (EN)
• Ant : Завантажте Ant і забезпечте передбачуваність і повторюваність процесу складання ПО. (EN)
• developerWorks на Твіттер. (EN)
• завантажте ознайомчі версії продуктів IBM і отримаєте доступ до інструментів для розробки і налагодження додатків, а також ПО сполучного рівня DB2®, Lotus®, Rational®, Tivoli® і WebSphere®. (EN)
• Вдосконалить свій проект з відкритим вихідним кодом за допомогою ознайомлювальних версій ПЗ від IBM , Які можна скачати з сайту або замовити на DVD. (EN)

Підпішіть мене на ПОВІДОМЛЕННЯ до коментарів