Эволюционный дизайн базы данных - Evolutionary database design - Wikipedia

Эволюционный дизайн базы данных вовлекает добавочный улучшения схема базы данных так что он может постоянно обновляться с учетом изменений, отражающих требования заказчика. Люди во всем мире работают над одним и тем же программным обеспечением в одно и то же время, поэтому необходимы методы, позволяющие плавно эволюционировать база данных по мере развития дизайна. Такие методы используют автоматизированные рефакторинг и непрерывная интеграция так что он поддерживает гибкие методологии для разработки программного обеспечения. Эти методы разработки применяются в системах, находящихся в подготовка к производству stage также и на уже выпущенных системах. Эти методы не только охватывают соответствующие изменения в схеме базы данных в соответствии с меняющимися потребностями клиента, но также переносят измененные данные в базу данных, а также соответствующим образом настраивают код доступа к базе данных без изменения семантика данных.^[1]

История

После использования модель водопада В течение длительного времени в индустрии программного обеспечения наблюдается рост внедрения гибких методов разработки программного обеспечения. Гибкие методологии не предполагай требования быть постоянным на любом этапе жизненный цикл программного обеспечения. Эти методы предназначены для поддержки спорадических изменений в отличие от техники проектирования водопада. Важной частью этого подхода является итеративная разработка, где весь жизненный цикл программного обеспечения выполняется несколько раз в течение жизненного цикла проекта. Каждая итерация свидетельствует о полном жизненном цикле разработки программного обеспечения, несмотря на непродолжительность итераций, которая может варьироваться от нескольких недель до нескольких месяцев.^[1]

Перед принятием этих методологий вся система была спроектирована перед началом разработки кода. Тот же принцип применялся и к схеме базы данных, где она считалась производной от требования к программному обеспечению которые, в свою очередь, были разработаны в результате сотрудничества между заказчиком, конечными пользователями, бизнес-аналитиками и т. д., и не ожидалось, что эти требования изменятся с прогрессом в разработке программного обеспечения. Этот подход оказался громоздким, потому что с течением времени стала очевидной избыточность в существующей схеме базы данных в виде неиспользуемых строк или столбцов. Эта избыточность вместе с Качество данных проблемы стали дорогостоящим делом. Был сделан вывод, что практика отсутствия чередования проектирования с построением и тестированием была крайне неэффективной.^[1]

Методы

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

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

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

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

Эволюционное моделирование данных

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

Регрессионное тестирование базы данных

Всякий раз, когда в систему добавляются новые функции, важно убедиться, что обновление не повреждает и не делает систему непригодной для использования. В базе данных бизнес-логика реализована в хранимые процедуры, проверка достоверности данных правила и ссылочная целостность и они должны быть тщательно протестированы при внесении каких-либо изменений в систему. Регрессионное тестирование это процесс выполнения всех контрольные примеры всякий раз, когда в систему добавляется новая функция. первая разработка (TFD) - это форма регрессионного тестирования, используемого при эволюционном проектировании баз данных. Шаги, связанные с подходом TFD:^[3]

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

Управление конфигурацией артефактов базы данных

Управление конфигурацией - это подробная запись версий и обновлений, примененных к любой системе. Управление конфигурацией полезно в откат обновления и изменения, которые негативно повлияли на систему. Чтобы гарантировать возможность отката любых обновлений, сделанных при рефакторинге базы данных, важно поддерживать такие артефакты базы данных, как язык определения данных скрипты, файлы модели данных, справочные данные, хранимые процедуры и т. д. в системе управления конфигурацией.^[5]

Песочницы для разработчиков

А песочница это полнофункциональная среда, в которой система может быть построена, протестирована и запущена. Чтобы вносить изменения в схему базы данных эволюционным образом, идеально, чтобы каждый разработчик имел собственную физическую песочницу, копию исходный код и копия база данных. В среде «песочницы» разработчик может вносить изменения в схему базы данных и запускать тесты, не влияя на работу других разработчиков и других сред. Как только изменение было успешно реализовано, оно повышается до подготовка к производству среда, где в приемочное тестирование выполняется и после успешного завершения приемочных испытаний развертывается в производство.

Преимущества и недостатки

Преимущества

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

Недостатки

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

Сравнение с традиционным дизайном базы данных

Традиционная техника проектирования баз данных не поддерживает изменения, подобные эволюционной методике проектирования баз данных. «К сожалению, традиционное сообщество данных предполагало, что эволюционировать схему базы данных - трудное дело, и поэтому никогда не задумывались, как это сделать».^[1] В некотором смысле эволюционный дизайн лучше для разработчиков приложений, а традиционный дизайн лучше для профессионалов в области данных.^[6]

Характеристики	Традиционный дизайн базы данных	Эволюционный дизайн базы данных
Дизайн	Традиционные базы данных были разработаны в сотрудничестве между бизнес-аналитики и пользователи.	Эволюционные базы данных были разработаны разработчиками программного обеспечения и профессионалами в области данных.
Проблемы дизайна	Они демонстрируют некоторые проблемы проектирования в базах данных. Коммерчески доступные базы данных были разработаны опытными специалистами, но в настоящее время обслуживаются базами данных, а не специалистами по данным.^[6]	Они разработаны тесным союзом разработчиков программного обеспечения и профессионалов в области данных. База данных развивается по мере развития и, следовательно, обрабатывается теми же людьми, которые отвечали за разработку.
Подход к изменениям	Любое изменение, запрошенное пользователем, включается в логическую модель, за которой следует физическая модель, а затем тестируется для обеспечения безупречной функциональности.^[6]	Изменения - неотъемлемая часть эволюционного дизайна баз данных. Любое изменение, запрошенное пользователем, немедленно внедряется в базу данных, а также в код. В перенос данных скрипты также нуждаются в обновлении.
Зависимость от диаграммы ER	Традиционный дизайн методичен и из-за его зависимости от Диаграмма ER и его этапы детального проектирования, такие как пользовательские, логические и физические, мы можем отслеживать данные, а также их значение.^[6]	Проектирование чередуется между этапами эволюционного проектирования базы данных. Таким образом, отношения между сущностями могут изменяться в течение цикла разработки программного обеспечения, как и диаграмма ER.

Инструменты

Ниже приводится список инструментов, которые обеспечивают функциональность проектирования и разработки базы данных эволюционным образом.