Рефа́кторинг баз да́нных (англ. database refactoring) — это простое изменение в схеме базы данных, которое способствует улучшению её проекта при сохранении функциональной и информационной семантики[1]. Иными словами, следствием рефакторинга базы данных не может быть добавление новых функциональных возможностей или ограничение уже существующих, равно как и добавление новых данных или же изменение смысла существующих.

Категории править

С. Эмблер и П. Садаладж[1] выделяют следующие категории рефакторинга реляционных баз данных:

  • Рефакторинг структуры
Изменения в структуре таблиц или представлений.

Методы: введение вычисляемого столбца; введение суррогатного ключа; замена данных типа LOB таблицей; замена связи "один ко многим" ассоциативной таблицей; замена столбца; замена суррогатного ключа естественным ключом; переименование представления; переименование столбца; переименование таблицы; перемещение столбца; разбиение столбца; разбиение таблицы; слияние столбцов; слияние таблиц; удаление представления; удаление столбца; удаление таблицы.

  • Рефакторинг качества данных
Изменения, направленные на улучшение качества хранимой в базе данных информации.

Методы: введение заданного по умолчанию значения; введение общего формата; введение ограничения столбца; добавление поисковой таблицы; замена кодового обозначения типа флажками свойств; осуществление стратегии консолидированных ключей; перемещение данных; преобразование столбца в недопускающий NULL-значения; применение стандартного типа; применение стандартных кодовых обозначений; уничтожение значения, заданного по умолчанию; уничтожение ограничения столбца; уничтожение столбца, не допускающего NULL-значений.

  • Рефакторинг ссылочной целостности
Изменения, направленные на поддержание ссылочной целостности в базе данных.

Методы: введение каскадного удаления; введение программного удаления; введение триггера для накопления исторических данных; введение физического удаления; добавление ограничения внешнего ключа; добавление триггера для вычисляемого столбца; уничтожение ограничения внешнего ключа.

  • Рефакторинг архитектуры
Изменения, направленные на улучшение взаимодействия внешних программ с базой данных.

Методы: введение вычислительного метода; введение индекса; введение таблицы только для чтения; добавление зеркальной таблицы; добавление метода чтения; добавление методов CRUD; замена метода (методов) представлением; замена представления методом (методами); инкапсуляция таблицы в представление; использование официально заданного источника данных; перенос метода в базу данных; перенос метода из базы данных.

  • Рефакторинг методов
Методы рефакторинга кода, применимые к триггерам и хранимым процедурам.

В 2019 году В. Струзик продолжил развитие рефакторинга баз данных, дополнив ранее предложенный перечень категорий рефакторинга баз данных новой[2]:

  • Рефакторинг доступа
Изменения в системе управления базой данных, которые связаны с доступом к данным.

Методы[3][4]: изменения атрибутов аутентификации; сужение привилегий доступа; расширение привилегий доступа; выделение схемы базы данных; слияние схем базы данных.

Когда проводить рефакторинг править

Выделяются некоторые общие недостатки баз данных, наличие которых может сигнализировать о необходимости рефакторинга[1].

  • Многоцелевые столбцы, т.е. столбцы, которые используются для хранения разнородных данных
  • Многоцелевые таблицы, т.е. таблицы, в которых хранится информация о разных типах сущностей
  • Избыточные данные
  • Таблицы со слишком большим количеством столбцов
  • Таблицы со слишком большим количеством строк
  • Многозначные столбцы, т.е. столбцы, внутри которых в различных позициях представлено несколько разных фрагментов информации
  • Боязнь вносить изменения в схему базы данных из-за возможных нарушений в работе приложений

Переходный период править

Переходный период при рефакторинге - это период времени, в течение которого осуществляется поддержка как первоначальной версии схемы базы данных, так и версии новой. Его введение необходимо для того, чтобы предоставить разработчикам время для внесения необходимых изменений в приложения, работающие с базой данных.

Пример править

 
Переименование столбца в таблице

Как пример рефакторинга базы данных можно привести операцию переименования столбца в существующей таблице.

Таблица Employee, хранящая данные о сотрудниках фирмы, содержит столбец zarplata, который было решено переименовать в salary, чтобы обеспечить единообразное именование объектов в базе данных, т.е. в качестве имён использовать исключительно английские слова. Для этого необходимо сделать следующее: добавить в таблицу столбец salary и скопировать в него данные из столбца zarplata, ввести триггер, который будет синхронизировать данные между двумя столбцами в течение переходного периода, а по прошествии данного периода удалить триггер и первоначальный столбец.

Примечания править

  1. 1 2 3 Скотт В. Эмблер, Прамодкумар Дж. Садаладж Рефакторинг баз данных: эволюционное проектирование = Refactoring Databases: Evolutionary Database Design (Addison-Wesley Signature Series). — М.: «Вильямс», 2007. — С. 368. — ISBN 978-5-8459-1157-5
  2. Струзік, В. А. Категорія рефакторинг доступу / В. А. Струзік // Комп’ютерні науки, інформаційні технології та системи управління : Міжнародна науково-технічна конференція студентів, аспірантів та молодих вчених, 27–29 листопада 2019 р. – Івано-Франківськ : Прикарпатський національний університет ім. Василя Стефаника, 2019. – С. 20-21. URL: http://dspace.nuft.edu.ua/jspui/handle/123456789/31516 Архивная копия от 6 февраля 2023 на Wayback Machine
  3. Струзік, В. А. Категорія рефакторинг доступу / В. А. Струзік, С. В. Грибков, В. В. Чобану // Наукові праці НУХТ. – Т. 26, № 2. – 2020. – С. 31–49. URL: http://dspace.nuft.edu.ua/jspui/handle/123456789/31515 Архивная копия от 6 февраля 2023 на Wayback Machine
  4. Vladislav Struzik, PhD Refactoring: yesterday, today, tomorrow. URL: https://medium.com/@struzik/refactoring-yesterday-today-tomorrow-7fc8c845cfb1 Архивная копия от 6 февраля 2023 на Wayback Machine

См. также править