a vice president of worldwide
, a vice president of worldwide data warehousing solutions at Cambridge Technology Partners
Оригинал статьи можно найти по адресу
Забавные вещи происходят с приближением нового тысячелетия. Нет, речь идет не о Проблеме Двухтысячного Года. Отношение к этой проблеме определяется собственным чувством юмора и тем, насколько серьезной она действительно будет. В этой заметке говорится о технологии баз данных.
Ну и что, скажете вы. Сегодня ВСЕ используют базы данных. Автор с этим согласен. Заканчивается десятилетие, в котором мы видели становление Internet, переход технологии "клиент-сервер" в разряд mainstream, рождение новых подсегментов рынка компьютерных приложений (call-центры, пакеты автоматизации продаж, корпоративные информационные приложения в архитектуре "клиент-сервер"). Еще одно обстоятельство не перестает изумлять автора. Раньше в большинстве случаев СУБД использовались как продвинутые системы управления файлами. Сотня приложений, анализируемых автором в течение каждого года, составляет бесконечно малую часть сотен тысяч или даже миллионов приложений, существующих в мире бизнеса. Но определения схемы приложений всегда поражают, независимо от того, включают ли они десяток реляционных таблиц или несколько сотен. Почти всегда приходится видеть скелетные образующие языка определения данных (DDL - Data Definition Language), такие как операторы CREATE TABLE и CREATE INDEX со списками столбцов и указанием их типов данных и размеров, а также, возможно, с несколькими разделами NOT NULL.
Но где же разделы CHECK? Где ограничения для различных видов ссылочной целостности и резидентных в базе данных бизнес-правил? За пределами операторов DDL иногда встречается использование хранимых процедур, ну и что?
Прежде чем сообщать автору по электронной почте, что в некоторых приложениях баз данных используются все эти возможности и даже больше, вспомните, что автор руководствуется состоянием рынка, глядя в основном на крупные корпорации. Конечно, на рынке имеются приложения баз данных с развитым использованием управления бизнес-правил и логики на стороне сервера.
Однако автор полагает, что при рассмотрении возможностей большинства лидирующих продуктов СУБД можно увидеть СУЩЕСТВЕННЫЙ разрыв между широтой их использования на рынке и их возможным потенциалом.
Имеется несколько причин этого ограниченного использования возможностей. Во-первых, поразительно большое число клиент-серверных приложений в действительности является портированными на распределенные платформы приложениями мейнфреймов (основанных на базах данных или файловых системах). И группы, производящие преобразования, выполняют только необходимые действия, такие как создание набора определений таблиц с соответствующими столбцами. Контролируемые базой данных диапазоны значений? Пардон, но преобразуемые данные не являются надежными, и использование этой возможности увеличило бы время загрузки базы данных и всего проекта. Ссылочная целостность? Определения первичных и вторичных ключей? Нет информации о качестве данных в столбцах, которые требуется использовать в качестве ключевых полей.
При использовании технологии складов данных (data warehousing) возникает потребность в частой загрузке (вернее, перезагрузке) содержимого баз данных в течение относительно умеренных промежутков времени, для чего требуется структуризация заново создаваемых баз данных (составляющих склад данных) с минимальным набором определений бизнес-правил. Было бы здорово иметь набор надежных объявлений для каждого столбца каждой таблицы склада данных, таких как допустимые диапазоны или списки значений и межтабличные ограничения целостности. Но большинство разработчиков складов данных находят, что вызываемые накладные расходы напрямую препятствуют использованию по причине слишком большого времени загрузки, а также потребностей перезапуска процесса загрузки при возникновении проблем. Кроме того, философия "это база данных только для чтения, а не система для фиксации этих данных", в течение долгого времени распространенная в мире складов данных, породила распространенное мнение о том, что в этой среде развитые возможности баз данных не требуются.
