Версия для печати

Рефакторинг баз данных: эволюционное проектирование

Авторы: Скотт В. Эмблер
Прамодкумар Дж. Садаладж
Издательство: Вильямс, 2007
368 страниц

Материал предоставил: Денис Миллер

Найти в магазинах

Купить в Books.Ru

Купить в OZ.by (Беларусь)

Аннотация

Аннотация

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

Содержание

Об авторах

Скотт В. Эмблер

Консультант в области усовершенствования программных процессов (Software Process Improvement - SPI), проживающий недалеко от Торонто. Скотт создал методологии AM (Agile Modeling) (www.agilemodeling.com), AD (Agile Data) (www.agiledata.org), EUP (Enterprise Unified Process) (www.enterpriseunifiedprocess.com) и AUP (Agile Unified Process) (www.ambysoft.com/unifiedprocess), а также возглавил работы по их усовершенствованию. Скотт - автор нескольких книг, в том числе Agile Modeling (John Wiley & Sons, 2002), Agile Database Techniques (John Wiley & Sons, 2003), The Object Primer 3rd Edition (Cambridge University Press, 2004), The Enterprise Unified Process (Prentice Hall, 2005) и The Elements of UML 2.0 Style (Cambridge University Press, 2005). Скотт работает в качестве редактора с правами публикации в коммерческом журнале Software Development (www.sdmagazine.com), участвует и выступает с программными речами на различных международных конференциях, включая Software Development, UML World, Object Expo, Java Expo и Application Development. Скотт закончил Университет Торонто, получив степень магистра информатики. В свободное время Скотт изучает стили каратэ - годзюрю и кобудо.

Прамодкумар Дж. Садаладже

Консультант компании ThoughtWorks, которая занимается разработкой и интеграцией приложений для предприятия. Прамод стал инициатором внедрения методов и процессов эволюционного проектирования и рефакторинга баз данных в 1999 году, работая над крупными приложением J2EE с использованием методологии экстремального программирования (Extreme Programming - XP). С тех пор Прамод, принимая участие во многих проектах, неизменно применяет эти методы и процессы. Прамод охотно делится своми знаниями в области администрирования баз данных в эволюционных проектах, применения эволюционных процессов к базам данных и влияния эволюционных подходов на администрирование базы данных, и в письменном, и в устном виде, чтобы дать возможность всем желающим освоить эволюционные методы проектирования баз данных. Свое свободное время Прамод проводит с женой и дочерью, совершая прогулки и бегая трусцой.

Введение

За последние несколько лет в индустрии информационной технологии (ИТ) стремительно распространились эволюционные методологии разработки программногообеспечения, часто называемые адаптивными, такие как экстремальное программирование (Extreme Programming - XP), метод Scrum, унифицированный процесс компании Rational (Rational Unified Process - RUP), адаптивный унифицированный процесс (Agile Unified Process - AUP) и разработка на основе функций (Feature-Driven Development - FDD). Чтобы было проще понять особенности этих методов, подчеркнем, что эволюционный метод по своему характеру является и итеративным, и инкрементным, а адаптивный подход является эволюционным и вместе с тем характеризуется высокой степенью взаимодействия участников разработки. Кроме того, в организациях, применяющих информационные технологии, все шире внедряются такие адаптивные методики, как рефакторинг, программирование в паре, разработка на основе тестирования (Test-Driven Development - TDD) и адаптивное проектирование на основе модели (Agile Model Driven Development - AMDD). Эти подходы и методики были разработаны и получили свое развитие в течение многих лет в среде рядовых разработчиков и доведены до совершенства обычными программистами, а не придуманы теоретиками, живущими в башнях из слоновой кости. Короче говоря, эти эволюционные и адаптивные методики, повидимому, невероятно успешно действуют на практике.

В своей оригинальной книге Refactoring Мартин Фаулер дал определение рефакторинга как небольшого изменения в исходном коде, которое способствует улучшению проекта кода без изменения его семантики. Иными словами, рефакторинг - это улучшение качества сделанной вами работы без нарушения или добавления чего-либо. Кроме того, в своей книге Мартин обсуждает идею, что если возможно подвергнуть рефакторингу прикладной исходный код, то есть возможность подвергнуть рефакторингу схему базы данных. Но Мартин указал, что рефакторинг баз данных - очень сложная задача,поскольку базы данных отличаются высокой степенью связности; поэтому он решил исключить эту тематику из своей книги.

После публикации книги Refactoring в 1999 году оба автора настоящей книги стали искать способы проведения рефакторинга схем базы данных. Первоначально мы работали отдельно, встречаясь друг с другом на таких конференциях, как Software Development (www.sdexpo.com), и ведя переписку с помощью списков рассылки (например, www.agiledata.org/feedback.html). Мы обсуждали идеи, посещали лекции и презентации друг друга на конференциях и вскоре обнаружили, что наши идеи и методы пересекаются, а также являются весьма взаимосовместимыми. Поэтому мы объединили свои усилия в написании настоящей книги, чтобы поделиться своим опытом и рассказать о методах развития схем баз данных путем проведения операций рефакторинга.

Все примеры, приведенные в книге, написаны на языке Java и на языках баз данных Oracle. Практически каждое описание операции рефакторинга базы данных включает код, предназначенный для модификации непосредственно самой схемы базы данных, а применительно к некоторым наиболее интересным операциям рефакторинга мы показали, какое влияние они могут оказать на прикладной код Java. Безусловно, нельзя найти две базы данных, которые были бы неотличимыми друг от друга, поэтому мы включили описания альтернативных стратегий реализации в тех случаях, когда между программными продуктами баз данных имеются тонкие, но важные различия. В некоторых случаях мы обсуждаем альтернативные реализации каких-то аспектов рефакторинга с помощью таких характерных для СУБД Oracle средств, как команды SET UNUSED или RENAME TO, а во многих приведенных нами примерах кода используются средства COMMENT ON, предусмотренное в СУБД Oracle. В других программных продуктах баз данных предусмотрены другие средства, позволяющие упростить рефакторинг баз данных, и хороший администратор базы данных должен знать, как воспользоваться этими особенностями в своих интересах. Но лучше всего, если в будущем появятся инструментальные средства рефакторинга баз данных, которые могли бы выполнять всю эту работу за нас. Кроме того, мы стремились показать настолько простой код Java, чтобы можно было преобразовать его в код C#, C++ или даже Visual Basic практически без затруднений.

Комментарий

Денис Миллер, инструктор Luxoft (http://luxoft.ru/edu)

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

В книге "Refactoring Database: Evolutionary Database Design" рассказывается о тактике внесения изменений в схему базы данных и секретах, как избежать возможных трудностей. Автор предлагаемой книги и адепт Agile-технологии разработки программного обеспечения Скотт Амблер обобщил опыт поддержки разрабатываемых им приложений на основе реляционных баз данных и отразил его в книге. Амблер предложил ряд методов по изменению внутренней структуры баз данных, приводящих к улучшению качества базы, более легкой поддержки и эволюции системы.

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

Идеологически книга разбита на 2 части. Первая часть описывает общий процесс внесения изменений. Вторая - конкретные примеры рефакторинга, сгруппированные в пять категорий.

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

Для тех, кто участвует в поддержке корпоративных приложений, не секрет как сложен процесс внесения изменений в схему базы данных. Вкратце, процесс рефакторинга (см. главу 4) состоит в ряде шагов: изменения, тестирования, внедрения, завершение изменений. Внеся изменения в схему, необходимо внести изменения в приложения, провести миграцию данных, выполнить регрессионные тесты. Автор подчёркивает важность тщательных проверок. Проверки проводятся в специальных тестовых средах, называемых "песочницами" (sandboxes). После тестирования в песочнице программистов, тестирование переходит в среду, дублирующую производственную. И только потом изменения достигают производственной среды (production).

Если процесс наскучил, переходим к "душкам" (database smells - проблемные области, которые требуют рефакторинга). Очень важные главы 2 и 5. В главе 2 (п.4) описаны типовые архитектурные промахи, в главе 5 стратегии опытного проектировщика баз. Во избежание многих осложнений, автор приводит "идеальную" архитектуру для проведения рефакторинга, в которой весь интерфейс взаимодействия прячется в выделенном слое (framework, п. 2.6). Противопоказано бездумное применение предложенной архитектуры, ещё Петр I говорил "Не держись устава, аки стенки. В каждом случае надо и голову приложить".

Вторая часть наполнена конкретными техниками рефакторинга. Автор разбил все методы на пять групп: рефакторинг структуры, качества, целостности, архитектуры и методов.

Рефакторинг кода (method refactoring) - это конспект книги Мартина Фаулера "Рефакторинг: улучшение кода" в приложении к хранимым процедурам. Структурный рефакторинг (Structural Refactoring) описывает простые преобразования со столбцами в таблицах. Рефакторинг качества (Data Quality Refactorings) и целостности (Referential Integrety Refactoring) содержит интересные доводы для архитекторов баз данных. Например: преимущество Lookup-таблиц, введение или исключение ограничений (constraints); случаи использования внешнего ключа (FK, Foreign Key), триггера (немного о trigger hell), и операция Delete во всех проявлениях. Хорошие примеры для размышления и сравнения.

Серьезная глава - архитектурный рефакторинг (Architectural Refactoring). В ней демонстрируются подходы расположения бизнес-логики, инкапсуляции данных через слой хранимых процедур и представлений (view) и много другого интересного.

В завершении книги приведены советы по миграции данных и краткий справочник по UML, который советую скопировать и использовать при подготовке спецификаций.

Вывод: справочное пособие для принятия решений в области баз данных. Решили использовать FK - открыли соответствующую главу, посмотрели варианты и мотивацию.