Лучшие практики для реорганизации базы данных

Мне известны некоторые общие рекомендации при проектировании базы данных для приложения, но как насчет редизайна?

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

Текущая программа в Oracle Forms, разбросанная по куче ненормализованных таблиц, иногда с несколькими почти дублированными таблицами, содержащими небольшие варианты данных друг друга. Ограничения часто имеют форму плохо соблюдаемых хранимых процедур. Даже типы не сохраняются правильно. Я сталкивался со всевозможными неверными данными, которые Oracle, похоже, игнорирует, но подходит (и это правильно) мастеру импорта / экспорта SQL Server. (Например, двузначные целые числа не составляют полное время!)

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

Конечным результатом перезаписи будет веб-версия, работающая на ASP.NET с MS SQL Server для серверной части.

Мои два других товарища по команде разработчиков намного, намного старше меня, оба с опытом работы в бизнесе / MIS, в то время как у меня CS. Опыт старшего члена был почти исключительно формами Oracle, а другой участник в основном занимался бизнес-приложениями в Visual Basic. Хотя мой опыт работы с базами данных был ограничен проектированием новых баз данных для проектов в MySQL или SQLite, в основном для моих старшеклассников, я, похоже, единственный, кто имеет опыт проектирования баз данных вообще.

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

Итак, суть моего вопроса: каковы некоторые передовые практики для проведения редизайна с уровня базы данных до существующего приложения?

Я думаю, вы уже знаете, как нормализовать базу данных.

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

То, что я предлагаю, - это больше работать как компромисс для меньшего риска.

Нормализуйте базу данных и создайте процесс для заполнения нормализованной базы данных данными из исходной базы данных. Исходная база данных будет базой данных для вставок, обновлений и удалений. Нормализованная база данных будет базой данных запросов только во время преобразования.

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

Создайте часть запроса вашей новой системы ASP.NET, указывая на новую нормализованную базу данных.

Результаты запроса вашей новой системы должны сравниваться с результатами запроса исходной системы.

Вы можете остановиться на этом этапе. Это деловое решение, а не техническое решение.

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

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

Вы преобразуете функции вставки / обновления / удаления по одному процессу за раз. Если есть проблема с неправильным пониманием бизнес-логики, ее можно исправить, пока ваши пользователи используют исходную систему.

Само собой разумеется, что ваш процесс заселения лучше быть абсолютно последовательным.

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

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

Спроектируйте необходимую вам нормализованную базу данных с нужными вам типами данных. Тогда самая сложная часть - это миграция данных. Во-первых, вам нужно составить план того, как вы будете отображать старое на новое и что вы собираетесь делать с данными, которые не соответствуют новой структуре. Например, у вас могут быть данные, которые теперь нельзя идентифицировать, если у вас не было надлежащих ограничений целостности. Возможно, вы захотите просто не перемещать эти данные или вам может потребоваться переместить их, но присоединить их к новой родительской записи с именем «Неизвестно». Если дата на самом деле не является реальной датой, можете ли вы поставить нулевое значение в поле при миграции? Вам понадобятся ответы на такие вопросы. Я полагаю, что некоторые разработчики работают над изменением графического интерфейса пользователя, чтобы использовать новую базу данных, а другие - только над миграцией. Миграция - огромная задача, это займет много навыков и много времени. Не оставляй это как запоздалую мысль.

Поскольку вы используете SQL Server, вы можете выполнить фактическую миграцию через SSIS.

Создайте хороший солидный набор тестов, чтобы вы могли сравнить результаты со старой системой так же, как и с новой.

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

Я сталкиваюсь с редизайном схемы базы данных почти ежедневно из-за поддержки и дальнейшей разработки нескольких устаревших приложений, которые были созданы в виде файлов MS Access (.mdb), а затем выросли до больших баз данных с несколькими сотнями таблиц, которые теперь расположены в MS SQL. Сервер, но все еще с "младенческими болезнями" оригинального дизайна. Вот некоторые практики, которые я нашел полезными для меня:

Постарайтесь минимизировать общедоступную поверхность вашей схемы базы данных.

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

Только они (представления, хранимые процедуры и скалярные функции) видны внешним приложениям (через ORM или напрямую) и используются для всех операций CRUD. Затем эта схема полностью замораживается, тогда как внутри вы можете изменить базовые таблицы, улучшить процедуры и т. Д. - это не нарушит совместимость с вашим приложением.

Попробуйте оптимизировать под реальные критерии, а не из книг.

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

Запишите сеанс профилирования и проанализируйте их.

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

Вот мой ответ:

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

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

3. Также проанализируйте и поймите текущий процесс ETL, который загружает данные в базу данных и извлекает данные из базы данных.

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

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

6. Удачи!