1.3-2 Ограничения и триггеры

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

1. Ограничения это булевы функш1и, значения которых должны быть истинными. Например, в банковскую БД можно ввести ограничение, согласно которому баланс не может Быть меньше нуля. Измеиегте БД, нй)>ушающее это ограничение, например изъятие денег, делаюшее счет отрицательной величиной, отвергается СУБД.

2. Триггеры - то части программы, ожидающие какого-то события. Событиями могут быть впедение или уда1ение элементов данных определенного типа. Когда событие происходит, выполняется (или инициируется) определенная последовательность действий. Например, система резервирования авиабилетов может иметь правило, условие которого инициируется, когда какой-то рейс приобретает статус cancelled. Действующей частью правила может Быть запрос номеров телефонов всех клиентов, забронировавших билеты на этог рейс, для их оповещения об отмене рейса. Более сложное действие-автоматическое бронирование мест для этих клиентов на другие альтернативные рейсы.

Активные элементы не являются чем-то принципиально новым. Они возникли как ON-условия в языке программирования PL/I. В течение многих лет они появлялись также в системах искусственного интеллект£ и родственны демонам, применяемым в операционных системах. Однако, когда объем данных, на которых действуют активные элементы, очень велик, число их интенсивно возрастает и возникают технические трудности их эффективной реализации. Поэтому активные элементы не применялись в стандартных компонентах СУБД до начала 1990-х. В этой книге они рассматриваются в главе 6.

1.33 Данные мульхимедиа

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

Для хранения данных мультимедиа пришлось создавать различные средства расширения СУБД. Операции, выполняемые с данными мультимедиа, не являются простыми и не подходят ддя традиционных форм данных. Например, можно искать в банковской БД счета с негативными балансами, сравнивая каждый баланс с числом 0 0, но невозможно найти в БД фотографии, похожие на конкретный образ. Поэтому СУБД должно включать в себя возможности пользователей вводить по собственному выбору функции, применимые к данным мультимедиа. Часто объектно-ориентированные методы используются для таких расширений даже в реляционных системах.

Размеры объектов мультимедиа также вынуждают СУБД модифицировать менеджер памяти для работы с обтлктами или кортежами размером гигабайт или более. К проблемам, связанным с такими большими элементами, огносится и проблема ответов на запросы. В коивенциональной, реляционной БД ответы - это множества кортежей, которые сервер БД поставляет клиенту как единое целое,

Предположим, однако, что ответ на запрос - это видеоклип длиной в гигабайт. Сервер ie может предоставить клиенту гигабайт в виде единого иелого. Do-первых, это займет слишком много времени и не позволит серверу обрабаты-ват1. другие запросы Во-вторых, может оказаться, что клиенту нужна только небольшая часть клипа, но запросить именно то, что ему нужно, не просмотрев начало клипа, он не мог. В-третьих, даже если клиенту нужен весь клип, например, для просмотра его на экране, достаточно передавать клип с фиксированной скоростью в течение часа (столько времени уходит на просмотр гигабаГгга уплотненного видео). 1так, ciicrcMa памяти мультимедийной СУБД должна выдавать ответы в интерактивном режиме, перелапая клиенту части ответа по его требованию или с фиксированной скоростью.

1.3.4 Интеграция данных

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

Пример 1.4. Представьте себе компанию по производству дисков, имеющую множество отделов. В каталоге одного отдела скорость вращения диска может быть представлена в оборотах в секунду, в каталоге другого-в оборотах в минуту, а третий эту скорость вообще игнорирует. И отдел, производящий дискеты, и отдел, выпускающий жесткие диски, могут называть свои продукты дисками. В одном отде.1е число дорожек на диске может называться дорожками, а в другом цилинарами. □

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

Чаше всего проблема решается Еуте.и соэщания хранилищ данных, в которых копируется информация множества наследственных БД и соответствующим образом переводится в иентр;1льную БД. При изменении наследственных БД хранилище обновляется, ио необязательно в тот же момент. Согласно общей схеме хранилище реконструируется каждую ночь, когда наследственные БД, вероятнее всего, менее загружены ()аботоЙ.

!аким образом, наследственные БД могуг продолжать выполнять задачи, ради которых они были созданы. Новые функции типа распространетгя электронного каталога через Web выполняются в хранилище данных. Оно может применяться также для планирования и анализа Например, аналитики компании могут посылать в хранилище запросы о направлениях продаж для более эф()ективного планирования оборудования и производства. Создание хранилищ данных обеспечило также разработку дпнны.х - почек интересных, необычных образцов данных, поз1Ю-ляюших улучшить процесс продаж.

1.4 Краткий обзор книги 17

1.4 Краткий обзор книги

Вопросы, связанные с системами БД, можно разделить иа три крупные категории:

1. Проектирование БД. Как построить действительно полезную БД? Какие виды информации поступают я БД? Как структурируется информация? Какие допущения прини.маются относительно типов или значений элементов данных Как связаны элементы данных?

2. Программирование БД. Как выражаются о БД запросы и другие операции? Как применяются другие средства СУБД типа триггеров или транзакций?

3. Реализация БД. Как строится СУБД, осуществляющая обработку процессов и транзакций, а также организацию памяти для эффективного доступа?

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

1-4.1 Проектирование

Проектированию посвящены главы 2 и 3. В главе 2 рассмотрены две нотации высокого уровня для выражения проектов БД: язык определения объектов ODL - объектно-ориентированный язык декларирования классов; модель E/R (или модель сущности-связи) - графическая система обозначений для описания организации БД.

Ни ODL, ни модель E/R не предназначены для прямого применения в качестве определения структуры БД, хотя ODL очень близок к языку определения данных при наличии объектно-ориентированной СУБД, Вместо этого предполагается, что проект, представленный в одной из этих моделей, будет переводиться в любую формальную нотацию, используемую языком определения данных, связанным с применяемой СУБД. Поскольку большинство СУБД являются реляционными, сосредоточимся на переводе ODL или E/R в реляционную модель. Поэтому глава 3 посвящена реляционной модели и процессу перевода. Далее, в разаеле 5.7 будет показано, как формально представить схемы реляционной БД в части языка SQL, связанной с определением данных,

1.4.2 Программирование

Главы с 4 по 8 посвящены программированию БД. В главе 4 дана абстрактная трактовка запросов в реляционной модели, введено семейство операторов на отношениях, образующее реляционную алгебру, а также рассмтрен альтернативнь й способ описания запросов, основанный на логических выражениях, под названием [>atalog.

Главы с 5 по 7 посвящены программированию иа SQL-доминирующем языке запросов В главе 5 вводятся базовые понятия, относящиеся к запросам в SQL. и выражение схем БД в SQL, Почти все п этой и последующих двух главах основано на стандартной версии SQL. называемой SQ1.2. Однако определенные аспекты программирования SQL, которые можно найти в некоторых коммерческих системах, не относятся к SQL2. В таких случаях используется более поздний, еще не принятый формально стандарт S0L3,

Глава 6 посвящена аспектам SQL, связанным с триггерами и ограничениями на данные. Поскольку в этих областях возможности SQL2 ограничены, мы уделим внимание и трактовке ограничений и триггеров в языке SQL3.