Планирование реализации

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

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

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

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

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

в этой главе:

Архивация

Аудит

Бе son а си ость

Резервное ьопировтше

Защита данных

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

архивацию;

аудит;

безопасность;

резервное копирование.

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

По поводу всех рассматриваемых в этой главе задач необходимо сказать следующее:

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

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

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

Архивация

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

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

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

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

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

SELECT МАХ(transaction date) FROM transactions WHERE account id = :account;

Чем больше транзакций выполнено для данного счета, тем медленнее работает этот запрос.

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