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

Настройте специальный экземпляр Oracle для тестирования проблемы тьюячелетия. Использование отдельного экземпляра позволит для выбираемых с сервера данных установить фиксированное значение даты (с помощью параметра инициализации Oracle FIX DATE; он будет влиять только на дату Oracle - SYSDATE). Приложения клиент/сервер могут применять локальные часы на клиенте, и для получения даты вам придется проверять вызовы операционной системы. В Oracle Forms существует различие между переменными $$DATE$$ и $$DBDATE$$ . первая - это локальная дата операционной системы, а вторая - дата базы данных сервера.

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

Универсальное решение

Было бы прекрасно найти действительно универсальное рещение, но, скорее всего, это несбыточная мечта. Если вы сможете изобрести такое рещение, то наверняка заработаете кучу денег, когда начнется паника, а начальство высунет голову из песка и поймет, что, сколько бы тел оно не бросило на эту амбразуру, момент будет вот-вот упущен!*

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

Выводы

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

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

Обеспечение расширяемости

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

Когда рассматривать возможность расширяемости

Многие требования по настраиваемости системы под требования пользователей легко реализовать с помощью обычных методов проектирования и компоновки. Если цены могут изменяться, то мы сохраняем их в таблице PRICES. Если уровни скидок могут изменяться, то мы заносим их в таблицу DISCOUNT LEVELS, и т.д. Как мы отмечали в главе 3, выявление таких случаев должно быть частью аналитической работы, а ее результаты должны отражаться в модели сущность-отнощение .

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

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

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

Для простоты изложения мы проигнорируем целый ряд вопросов, которые нужно решать в реальной жизни (и которые часто игнорируются и там), например:

Кто отвечает за проверку влияния предлагаемого изменения на систему?

Кто отвечает за тестирование изменения на предмет того, работает ли оно так, как ожидалось?

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

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

Типы расширяемости

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

алгоритмическая расширяемость, где необходимы новые правила обработки, дополняющие или заменяющие существующие правила;

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

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

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

Расширяемость, управляемая данными

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

Пример Б. 5. Определение таблицы, позволяющее реализовать части правила или формулы для расчета

CREATE TABLE rule elements

( rule# NUMBER . -

CONSTRAINT rule element rule# REFERENCES rules