Анотация

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

Что такое рефакторинг баз данных ?

В тексте Мартина Фаулера [1] описывает технику программирования, называемую рефакторинг, это дисциплинированный способ реструктуризации кода по шагам. Рефакторинг позволяет вам модернизировать код медленно с течением времени, принять эволюционный (повторные и дополнительные) подход к программированию. Одним из важнейших аспектов рефакторинга является то, что он сохраняет поведенческих семантики кода. Вы не добавляете функциональность, когда используете рефакторинг, и вы не уменьшеете ее. Рефакторинг только улучшает дизайн вашего кода - не больше и не меньше. Рефакторинг базы данных [2, 3] простое изменение схемы базы данных, что повышает его конструкции при сохранении как его поведении так и информационной семантики, - иными словами, вы не можете добавить новую функциональность или разрушить существующую функциональность, Вы не можете добавлять новые данные, и Вы не можете изменить значение имеющихся данных. Схемы базы данных включает в себя как структурные аспекты, как таблицы и определения, а также функциональные аспекты, таких, как хранимые процедуры и триггеры. Я использую рефакторинг кода для условного обозначения традиционного рефакторинга, как описано у Мартина Фаулера и ба для обозначения рефакторинга схем баз данных. Процесс рефакторинга базы данных является акт принятия этих простых изменений в схему базы данных.

Почему Рефакторинг баз данных?

Есть две основные причины, почему вы хотите применить рефакторинг базы:

Ремонт существующих баз данных, наследия. Рефакторинг базы данных позволяет безопасно развивать дизайн базы данных по шагам, что делает его важным методом для улучшения наследие активов в вашей организации. Это явно намного менее рискованно, чем "большого взрыва", где вы переписываете все ваши приложения и переделываете все схеме базы данных, а потом освободите их всех на производство сразу. Кроме того, это намного лучше, чем "давайте попробуем не допустить, чтобы стало хуже" стратегии используемые в настоящее время подавляющее большинство групп по управлению данными, стратегии, которые не имеют надежды на успех, поскольку все, что нужно является одна команда разработчиков, которые входят в группы по управлению данными и делают несовершенные проекты баз данных.
Поддержка эволюционной разработки программного обеспечения. Современное программное обеспечение процессов развития, в том числе Rational Unified Process (RUP), экстремального программирования (XP), Agile Unified Process (ОПА), Scrum, а динамическая система развития Method (DSDM), все имеют эволюционный характер. Крейг Ларман [4] обобщая исследовательские доказательства, а также хорошо, как и лидеры в рамках ИТ-сообщества поддерживает эволюционные подходы. К сожалению, большинство данных, ориентированные на методы серийного характера, опираются на выполнение специалистов относительно узких задач, таких как логического моделирования данных и физическое моделирование данных. В этом-то и загвоздка - две группы должны работать вместе, но оба хотят сделать это по-разному. Я считаю, что данные специалисты должны принять эволюционные методы, такие как рефакторинг базы данных, который позволяют им иметь отношение к современной команде разработчиков. К счастью, эти методы существуют [3], и они работают достаточно хорошо.

Реализация баз данных Рефакторинг

Иногда команда проекта находится в относительно простых ситуациях, "одного приложения базы данных", и если это так, они должны считать себя счастливчиками. С помощью рефакторинга изменение архитектуры базы данных очень просто - вы просто изменяете схему базы данных и обновляете приложения для использования новой версии схемы. Что является более простым, чем много внешних программ, взаимодействующих с базой данных, некоторые из которых находятся вне сферы вашего контроля. В этой ситуации вы не можете считать, что все внешние программы будут развернуты сразу, и поэтому поддержка переходного периода (также называют устаревший период) в течение которого обе старые схемы и новые схемы поддерживаются параллельно. Для остальной части этой статьи я буду считать, что вы в этой ситуации.

Чтобы использовать рефакторинг базы данных в контексте, делайте шаг через небольшой пример. Вы работаете по банковскому приложению в течение нескольких недель и заметили что-то странное о клиенте в таблице на рисунке 1 [1] - одна из имен столбцов, не легко понять. Вы решили применить рефакторинг, переименовать столбец FName в FirstName.

Рисунок 1 - Первоначальный схемы базы данных для клиентов.

Agilists как правило, работают в парах, один человек должен иметь навыки программирования приложений и другой навыки работы с данными, а в идеале оба должны иметь оба набора знаний и навыков. Пара начинается с определения того, должна ли быть переработана схема базы данных. Может быть, программист ошибся в необходимости разработки схемы, и лучше идти по схеме реорганизации. Когда работы будут закончены, эти изменения будут интегрированы в проект, а также системы перестраивается, тестирование и фиксированные по мере необходимости.

Чтобы переименовать поле в развитии системы, пара первой группы запускает все испытания, чтобы увидеть, что они проходят. Далее они пишут тест, используя Driven Design (TDD) подход [5, 6, 7]. Вероятно,проверкой окажется доступ к значению в колонке Имя. После выполнения тестов и видеть их терпят неудачу, они осуществляют фактический рефакторинга. Для этого они вносят в столбце "Имя и SynchronizeFirstName спусковой крючок

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

Имя столбца FirstName должно быть заполнено значением из столбца FName. Затем нужно запустить обе колонки параллельно в течение "переходного периода" достаточной длины, чтобы дать время команде разработчиков по обновлению и переводу всех свои приложений. Этот переходный период может длиться несколько лет, в зависимости от возможностей вашего проекта вводить новые релизы в производство. В этом случае мы решили, что переходный период будет длиться до 14 ноября 2007.

Пара повторных испытаний, и видно, что они прошли. Затем они реорганизовывают существующие тесты для работы с FirstName, а не колонкой FName. После, реорганизация базы данных завершена, в своей среде разработки пара способствует их интеграции в работу проекта, где они опять проводят испытания, устринив оставшиеся проблемы, которые они находят. Чтобы обновить схему базы данных, пара проходит соответствующие изменения и миграции сценарии в определенном порядке.

После переходного периода, удаляют исходный столбец, в результате чего конечня схемы базы данных на рис 3. Вы удалите эти вещи только по истечении достаточного количества испытаний с целью обеспечить безопасную работу. На данный момент, ваш рефакторинг завершен.

Рисунок 2 - Окончательный вариант схемы базы данных для клиентов.

Существует несколько более успешных вариантов осуществления рефакторинга базы данных, чем то, что я описал. Вам нужен способ, чтобы координировать усилия реорганизации всех команд разработчиков в вашей организации, ясно то, что это может оказаться весьма затруднительным. Кроме того, необходимо получить хорошее в развертывании рефакторинга в производстве, вновь координации усилий нескольких команд. В Рефакторинг баз данных [3], мой соавтор Pramod Sadalage и я обсуждаем несколько стратегий для каждого из этих вещей.

Почему бы просто не получить его правым начать?

Я часто слышала от специалистов, что реальным решением является модель все впереди, и тогда не нужно будет реорганизовать схему базы данных. Хотя это интересное видение, и я видел работы в некоторых ситуациях, опыт последних трех десятилетий показывает, что такой подход не очень хорошо работает, на практике для всего ИТ-сообщества. Традиционный подход к моделированию данных не отражает эволюционный подход, современные методы, такие как RUP и XP, и не отражает тот факт, что бизнес для взыскательных клиентов новые возможности и изменения существующей функциональности развивается более быстрыми темпами. Старые методы просты, нужно больше, если они когда-либо были [8].

Я предлагаю вам принять Agile Model-Driven Development (AMDD) подход [9, 10], в которой некоторые улучшенные модели определения "пейзажа" вашей системы, и тогда модель покажет подробную информацию точно в срок на основе (JIT). Воспользуйтесь преимуществами моделирования, не тратя времени на чрезмерное количество документации, а также в результате бюрократия пытаясь держать слишком много артефактов, современных и синхронизированых друг с другом. Ваш код приложения и базы данных схемы развиваться как ваше понимание предметной области, и сохраняет качество за счет реорганизации и другое.

В Заключении

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

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

Справочники pекомендуемые к прочтению

Fowler, M. (1999). Refactoring: Improving the Design of Existing Code. Menlo Park, California: Addison Wesley Longman, Inc.
Ambler, S.W. (2003). Agile Database Techniques: Effective Strategies for the Agile Software Developer. New York: John Wiley & Sons. www.ambysoft.com/books/agileDatabaseTechniques.html
Ambler, S.W. and Sadalage, P.J. (2006). Refactoring Databases: Evolutionary Database Design. Boston: Addison Wesley. www.ambysoft.com/books/refactoringDatabases.html
Larman, C. (2004). Agile and Iterative Development: A Manager's Guide. Boston: Addison-Wesley.
Astels D. (2003). Test Driven Development: A Practical Guide. Upper Saddle River, NJ: Prentice Hall.
Beck, K. (2003). Test Driven Development: By Example. Boston, MA: Addison Wesley.
Ambler, S.W. (2004). Introduction to Test Driven Development (TDD). www.agiledata.org/essays/tdd.html
Ambler, S.W. (2004). The Agile Data Home Page. www.agiledata.org.
Ambler, S.W. (2002). Agile Modeling: Best Practices for the Unified Process and Extreme Programming. New York: John Wiley & Sons. www.ambysoft.com/books/agileModeling.html
Ambler, S.W. Agile Model Driven Development (AMDD). www.agilemodeling.com/essays/amdd.htm