Проектирование корпоративных баз данных: новые требования

проектирования Баз Данных (БД), которая превратилась в мощное и красивое течение - со своей философией и способами восприятия реальности. В этом течении возникло свое понятие "Мира", "Предметной Области" (ПрО) и их моделей, своя индустрия инструментов проектирования БД. Были скомпонованы стройные схемы применения методов, позволяющие выполнить все проектные этапы - начиная от сбора сведений о ПрО и кончая тестированием БД, настройкой ее структуры и параметров СУБД. Целостная методология позволила позаботиться о "сапожнике-проектировщике" и сшить ему сапоги в виде систем автоматизации проектирования БД - CASE-систем для проектирования собственно БД или интегрированных инструментов, которые позволяют как проектировать БД, так и разрабатывать использующие их прикладные программы (при этом принцип отделения данных от программ сохранялся).

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

Это цитата из книги Д. Цикритзиса и Ф.Лоховского "Модели данных". С тех пор СУБД, CASE-системы и соответствующие методы значительно шагнули вперед в возможностях. Но и остальной мир не стоял на месте.

"К 1990 году почти все аспекты "стандартной процедуры работы" с ИТ были поставлены под сомнение, и вычислительные архитектуры вырвались из-под контроля. ... Стандарты программирования размывались, а понятие неизбыточных, непротиворечивых, высококачественных данных годилось разве для груды хлама." (В. Меллинг, "Garthner Group").

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

• глобализация бизнеса: работа с клиентами и партнерами в любой точке мира, а также работа с клиентом в режиме "24 часа в сутки, 365 дней в году";
• снабжение работника всеми возможностями для самостоятельного получения конечного результата, опора на рост мобильности персонала;
• работа на будущие потребности клиента, ускоренное продвижение новых технологий.

Вместе с тем возникли новые требования к архитектуре корпоративных БД. Вот некоторые из них:

• наличие распределенных БД с тиражируемой информацией на разнородных платформах; изменения структуры и размещения должны производиться на нижних организационных уровнях предприятия;
• хранение произвольной некодированной информации; объем БД существенно возрастает, архивы DSS увеличиваются в три раза и более;
• ориентация на асинхронные системы обработки сообщений и мониторы процессов; предельно высокие требования к надежности;
• мобильная работа с базами данных превращается в стандарт, а стационарная становится ее вырожденным случаем.

Конечно, все новое есть кем-то ранее уже обнаруженное старое. И тем не менее:

объединение "хранилищ данных", баз данных ГИС-систем, архивов текстовых документов в общей постановке проектирования корпоративной БД приводит к отказу от принципа обязательного исключения избыточности;

компонентный подход в разработке информационных систем требует компонентного проектирования БД: замена функционального компонента системы на подобный, но спроектированный другим разработчиком, потребует структурной замены некоторой части корпоративной БД, и такая замена должна поддерживаться как постоянный процесс перепроектирования.

Чтобы исключить консервацию существующих ситуаций на предприятиях в "цельноинтегрированных" структурах БД, должна меняться CASE-технология.

Должны быть определены границы применимости двух концепций: проектирование баз данных как предмета, осознанно отделенного от программ, и объектно-ориентированное проектирование, в котором в объекте инкапсулирует и данные, и методы их обработки.

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