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

Вернемся к средствам создания запросов. Таких продуктов сейчас очень много: Oracle Data Query, Oracle Data Browser (вместе они называются Discoverer/2000), Business Objects, Cognos Impromptu и т.д. He допускайте ошибку, предполагая, что можно просто инсталлировать эти средства на ПК пользователей и отправиться гулять. Чтобы с этими продуктами можно было работать, требуется значительный объем работ по настройке. Например, необходимо присвоить столбцам подходящие псевдонимы и создать логические представления (либо в рамках продукта, либо как представления Oracle), чтобы отчасти скрыть сложность базы данных. Пример - предварительное соединение двух и более таблиц в представлении. Эту операцию иногда называют созданием уровня отображения для данного продукта (в Business Objects его называют universe - вселенная , просто чтобы подчеркнуть, насколько он важен).

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

Ваш конечный пользователь, скорее всего, не собирается выделять ассигнования на приглашение постоянного администратора БД для управления СУБД Personal Oracle? на однопользовательском ПК или в сети Novell NetWare с тремя пользователями. Если у вас на предприятии 10000 таких систем, можете быть совершенно уверены, что у ваших постоянных администраторов БД не будет свободного времени, чтобы смотреть друг за другом. Поэтому сегодня существует общее требование: создать для таких функций удобный интерфейс, который будет выполнять простую работу и скрывать лежащую за ней сложность. Oracle сама признала этот факт и стремится предоставить как можно больше этих возможностей в базовом продукте, но конечная цель пока не достигнута, поэтому вам, возможно, придется самому добавлять те или иные функции. Для большой сети со множеством узлов можно попробовать приобрести средство для удаленного управления приложениями (например, PATROL фирмы ВМС), которое дополнит сервисы, имеющиеся в Oracle Enteфrise Manager.

Управление приложениями

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

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

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

SELECT 30b

, log user FROM dba 3 0bs WHERE broken = Y ;

Прил1счанис

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

Один из авторов работает в подразделении PATROL Research and Development фирмы ВМС Software, поэтому его мнение в этой области вполне можно считать предвзятым

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

Управление исходным кодом и версиями

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

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

Управление базой данных

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

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