организаций в каждом приложении были свои определения данных (их часто называли моделями, ориентированными на приложения). Например, в Приложении Sales была одна таблица Customer, в приложении Billing - еще одна, в Support - третья и т.д.

Один из авторов когда-то работал с фирмой, у которой было семь разных моделей данных о покупателях! В результате эти данные были несогласованными, а структура таблиц отличалась. Форматы адресов были настолько разными, что было практически невозможно с помощью почтового адреса обнаружить, что Serious Cybernetics Corporation в одном приложении - это та же компания, что и Serious Cybernetics Софога11оп в другом! В результате фирма теряла деньги, бесплатно обслуживая оборудование покупателей, так как просто не могла определить, стоит ли это оборудование на гарантии (эта информация находилась в базе данных Sales).

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

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

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

этим они разгласят конфиденциальную информацию и утратят преимущество перед конкурентами;

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

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

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

Секреты мастерства

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

Проблема мутирующих таблиц

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

Мы можем определить табличные триггеры для различных событий в базе данных. Эти события происходят или на уровне строки, или уровне предложения. Вспомним, что одно предложение может обрабатывать много строк. Например, при помощи предложения DELETE FROM MY TAB можно обработать все строки таблицы MY TAB. Следовательно, триггер BEFORE DELETE сработает один раз, а триггер BEFORE DELETE...FOR EACH ROW -один раз для каждой строки таблицы. Проблема мутирующих таблиц возникает, когда в триггере уровня строки гфоизводится попытка обратиться к таблице, которая изменяется или может изменяться тем же предложением.

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