Трехуровневая архитектура Internet

С развитием Internet и особенно World Wide Web архитектура сетевого управления базами данных получила дальнейшее развитие Поначалу WWW являлась средой просмотра статических документов и развивалась независимо от рынка СУБД. Но когда Web-браузеры получили широкое распространение, разработчики подумали о том, что это очень удобный способ обеспечения доступа к корпоративным базам данных. Предположим, к примеру, что торговая компания располагает собственным Web-сервером, на котором клиенты могут найти информацию о товарах, выпускаемых компанией, включая текстовое и графическое описание Логично предположить, что следующим шагом будет предоставление клиентам доступа к информации о наличии выбранного товара в продаже, причем посредством того же интерфейса Web-браузера. Для этого требуется связать последний с базой данных, хранящей такую (постоянно меняющуюся) информацию.

Методы связывания Web-серверов и СУБД стремительно развивались в последние годы и в итоге вылились в трехуровневую сетевую архитектуру (рисунок 3.5). Интерфейсом пользователя является Web-браузер, выполняющийся на персональном компьютере или другом “тонком клиенте”. Браузер взаимодействует с Web-сервером, уровень которого можно оценить как прикладной. Если пользователь запрашивает нечто большее, чем просто Web-страницы, Web-cеpвep переадресует запрос серверу приложений, чья роль заключается в анализе запроса Запрос может включать обращение к унаследованной системе, выполняющейся на мэйнфрейме, либо к корпоративной базе данных. Эго уже информационный уровень. В этой архитектуре SQL закрепился как стандартное средство взаимодействия между вторым и третьим уровнями. Все прикладные серверные продукты предоставляют наборы API-функций для доступа к базам данных.

 

 

 

Рисунок 3.5 ─ Место СУБД в трехуровневой архитектуре Internet

 

СУБД организует данные таким образом, чтобы пользователи и прикладные про­граммы могли извлекать и обрабатывать их. Организация данных и способы доступа к ним, обеспечиваемые конкретной СУБД, называются ее моделью данных. Модель данных определяет "лицо" СУБД и круг приложений, для которых она подходит наи­лучшим образом

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

Первые модели данных

С ростом популярности СУБД в 70—80-х годах появилось множество различных моделей данных. У каждой из них имелись свои достоинства и недостатки, которые сыг­рали ключевую роль в развитии реляционной модели данных, появившейся во многом благодаря стремлению упростить и упорядочить первые модели данных Чтобы понять роль SQL и реляционных баз данных и оценить их вклад в развитие СУБД, следует кратко рассмотреть ряд моделей данных, предшествовавших появлению SQL.

Системы управления файлами

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

Знание о содержимом файла — какие данные в нем хранятся и какова их структура — было уделом прикладных программ, использующих этот файл, что иллюстрирует рис 4.1. В приложении для начисления зарплаты каждая из программ, обрабатывающих файл с информацией о служащих, содержит в себе описание структуры данных (ОСД), хранящихся в этом файле. Когда структура данных изменялась (например, в случае добавления нового элемента данных для каждого служащего), необходимо было модифицировать каждую из программ, обращавшихся к файлу. Со временем количество файлов и программ росло, и на сопровождение существую­щих приложений приходилось затрачивать все больше и больше усилий, что замед­ляло разработку новых приложений.

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

Рис. 4.1. Приложение для начисления зарплаты

 

 

Иерархические базы данных

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

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

■ найти конкретную деталь (левую дверь) по ее номеру;

■ перейти "вниз" к первому потомку (ручка двери);

■ перейти "вверх" к предку (корпус);

■ перейти "в сторону" к другому потомку (правая дверь).

Рис.4.2. Иерархическая база данных, содержащих информацию о составных частях

Таким образом, для выборки информации из иерархической базы данных требо­валось перемещаться по записям, за один раз переходя на одну запись вверх, вниз или в сторону.

Одной из наиболее популярных иерархических СУБД была Information Management System (IMS) компании IBM, появившаяся в 1968 году. Ниже перечислены достоинства IMS и реализованной в ней иерархической модели.

■ Простота модели. Принцип построения баз данных в IMS был легок для пони­мания. Иерархия базы данных напоминала структуру компании или генеалоги­ческое дерево.

■ Использование отношений предок/потомок. СУБД IMS позволяла легко представ­лять отношения предок/потомок, например: "А является частью В" или "А при­надлежит В".

■ Быстродействие. В СУБД IMS отношения предок/потомок были реализованы в виде физических указателей из одной записи на другую, вследствие чего переме­щение по базе данных происходило быстро. Поскольку структура данных в этой СУБД отличалась простотой, IMS могла размещать записи предков и потомков на диске рядом друг с другом, что позволяло свести к минимуму количество операций чтения-записи.     

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

 

Сетевые базы данных

Если структура данных оказывалась сложнее, чем традиционная иерархия, про­стота организации иерархической базы данных становилась ее недостатком. Напри­мер, в базе данных для хранения заказов один заказ мог участвовать в трех различных отношениях предок/потомок, связывающих заказ с клиентом, разместившим его, со служащим, принявшим его, и с заказанным товаром, что иллюстрирует рис. 4.3. Та­кие структуры данных не соответствовали строгой иерархии IMS.

 

Рис.4.3 Множественные отношения предок/потомок

В связи с этим для таких приложений, как обработка заказов, была разработана новая, сетевая модель данных. Она являлась улучшенной иерархической моделью, в которой одна запись могла участвовать в нескольких отношениях предок/потомок (рис. 4.4). В сетевой модели такие отношения назывались множествами. В 1971 году на конференции по языкам обработки данных (Conference on Data Systems Languages — CODASYL) был опубликован официальный стандарт сетевых баз данных, который известен как модель CODASYL. Компания IBM не стала разрабатывать соб­ственную сетевую СУБД и вместо этого продолжала наращивать возможности IMS. Но в 70-х годах независимые производители программного обеспечения реализовали сетевую модель в таких продуктах, как IDMS компании Cullinet, Total компании Cincom и СУБД Adabas, которые приобрели большую популярность.

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

■ найти конкретную запись предка по ключу (например, номер клиента);

■ перейти к первому потомку в конкретном множестве (первый заказ, размещен­ный клиентом);

■ перейти в сторону от одного потомка к другому в конкретном множестве (следующий заказ, сделанный этим же клиентом);

■ перейти вверх от потомка к его предку в другом множестве (служащий, приняв­ший заказ).

 

И опять программисту приходилось искать информацию в базе данных, после­довательно перебирая записи, однако указывая при этом не только направление, но и требуемое отношение.

Рис.4.4. Сетевая база данных, содержащая информацию о заказах

Сетевые базы данных обладали рядом преимуществ:

■ Гибкость. Множественные отношения предок/потомок позволяли сетевой базе данных хранить информацию, структура которой была сложнее простой иерархии.

■ Стандартизация. Появление стандарта CODASYL увеличило популярность сете­вой модели, а такие поставщики мини-компьютеров, как Digital Equipment Corporation и Data General, реализовали сетевые СУБД.

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

Конечно, у сетевых баз данных имелись недостатки. Подобно своим иерархиче­ским предкам, сетевые базы данных были очень "жесткими". Наборы отношений и структуру записей приходилось задавать наперед. Изменение структуры базы данных обычно означало перестройку последней.

Как иерархическая, так и сетевая база данных были инструментами программи­стов. Чтобы получить ответ на вопрос "какой товар наиболее часто заказывает компания X?", программисту приходилось писать программу для навигации по базе данных. Реализация пользовательских запросов часто затягивалась на недели и месяцы, и к моменту появления программы информация, которую она предоставля­ла, часто оказывалась бесполезной.

Недостатки иерархической и сетевой моделей привели к повышению интереса к новой, реляционной модели данных, впервые описанной доктором Коддом в 1970 году. Поначалу она представляла лишь академический интерес. Сетевые базы данных продолжали оставаться важной технологией на протяжении 70-х и в начале 80-х годов, особенно в мини-компьютерных системах, переживавших пик популярности. Но в середине 80-х годов начался взлет реляционной модели. В первой половине 90-х годов сетевые базы данных утратили популярность, и сегодня не играют значительной роли на рынке баз данных.

Реляционная модель данных

Реляционная модель была попыткой упростить структуру базы данных. В ней отсутствовали явные указатели на предков и потомков, а все данные были представ­лены в виде простых таблиц, разбитых на строки и столбцы. На рис. 4.5 изображена реляционная версия рассмотренной выше сетевой базы данных, содержащей инфор­мацию о заказах.

 

Таблица PRODUCTS                                                         Таблица ORDERS

DESCRIPTION	PRICE	QTY ON HAND
Ratchet Link	$79.00	210
Widget Remover	$2,750.00	25
Reducer	$355.00	38
•
•

0RDER_NUH	0RDER_DATE	PRODUCT	QTY
112961	17-DEC-89	2A44L	7
113012	11-JAH-90	41003	3b
112989	03-JAN-90	114	6
113051	10-FEB-90	XK47	4
112968	12-0CT-89	41004	34

 

Таблица CUSTOMERS

COMPANY	CUSTJEP	CRED t T_LIHIT
JCP Inc. First Corp. ••	103 101	$50,000.00 $65,000.00

Рис.4.5. Реляционная база данных, содержащая информацию о заказах

К сожалению, практическое определение понятия "реляционная база данных" оказалось гораздо более расплывчатым, чем точное математическое определение, данное этому термину доктором Коддом в 1970 году. В первых реляционных СУБД не были реализованы некоторые из ключевых частей модели Кодда, и этот пробел был восполнен только впоследствии. По мере роста популярности реляционной концепции реляционными стали называться многие СУБД, которые на деле таковы­ми не являлись.

В ответ на неправильное использование термина "реляционный" доктор Кодд в 1985 году написал статью, где сформулировал 12 правил, которым должна удовлетво­рять любая база данных, претендующая на звание реляционной. С тех пор двенадцать правил Кодда считаются определением реляционной базы данных. Однако мы начнем с более простого определения:

 

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

 

Приведенное определение не оставляет места встроенным указателям, имеющим­ся в иерархических и сетевых СУБД. Реляционная СУБД способна реализовать отношения предок/потомок, однако эти отношения представлены исключительно значениями данных, содержащихся в таблицах.

 

Использование триггеров

 

В этом разделе мы рассмотрим механизм триггеров, предлагаемый для иниции­рования необходимых действий при наступлении определенных событий. Мы рас­смотрим возможности стандарта SQL по описанию триггеров, а затем рассмот­рим дополнительные его возможности, предлагаемые в Oracle.

Что такое триггер базы данных?

Существует такое понятие, как событийно управляемые действия. Смысл его заключается в том, что в рассматриваемой предметной области фиксируется мно­жество правил вида «событие -> действие». Интерпретирующая система отсле­живает все происходящие в предметной области события, и при наступлении од­ного из тех, которые приведены в списке, инициируется соответствующее ему действие. В этом случае детерминированная последовательность выполняемых действий отсутствует.

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

- в 8.00, что соответствует открытию магазина, сбросить в нулевое состояние счета всех кассовых аппаратов;

- в 9.00 подготовить обобщающий отчет о продажах за прошлый день;

- при поступлении из любого кассового аппарата информации об оформленной покупке занести эти данные в базу;

- в 18.00, что соответствует закрытию магазина, произвести сводную ревизию всех покупок за день.

В этом примере три события привязаны к временным вехам и одно к операции покупки/продажи. Нечто подобное существует и в базах данных. Здесь события привязываются к изменению состояния системы баз данных, а действия пред­ставляют собой совокупность специальным образом оформленных процедур SQL.

Триггер базы данных — это процедура, которая хранится в виде объекта базы дан­ных и выполнение которой неявно инициируется при наступлении определен­ных событий. Как правило, такими событиями являются изменения в состоянии базы данных, которые инициируются предложениями INSERT, UPDATE или DELETE по отношению к соответствующей таблице базы данных. Однако в общем случае со­бытия, активирующие триггеры, могут быть связаны не только с базой данных. Триггеры расширяют стандартные возможности СУБД по управлению базами данных. Список возможных вариантов использования триггеров приводится в конце раздела.

Впервые триггеры были введены в стандарт только в 1999 году (SQL3). К этому времени триггеры уже около 20-ти лет существовали в развитых СУБД. Стан­дарт SQL обобщил те возможности, которые авторы стандарта посчитали полез­ными. В связи с этим ситуация в настоящий момент такова: общая концепция описания и использования триггеров, поддерживаемая в СУБД, совпадает с пред­ложениями стандарта SQL, однако практически все СУБД имеют свои специфи­ческие особенности. В связи с этим мы сначала опишем триггеры согласно стан­дарту SQL, а затем приведем их специфические особенности в Oracle.

ПРИМЕЧАНИЕ Далее при демонстрации примеров функционирования триггеров мы будем использовать их определение в синтаксисе Oracle. Это прежде всего касается тела триггера.

 

Составляющие триггера

Синтаксис определения триггеров в стандарте SQL следующий:

 

CREATE TRIGGER имя_триггера время_инициирования_триггера событие_триггера ON имя_таблицы [REFERENCING список_переменных_или_таблиц_перехода]

[уровень_триггера]

[условие_триггера]

действие_триггера

 

Как видим, описание триггера состоит из многих составляющих, которые мы да­лее и рассмотрим.

 

Заголовок триггера

Заголовок триггера предназначен для идентификации триггера. Он имеет сле­дующий синтаксис:

CREATE TRIGGER имя_триггера

Триггер — это именованный объект схемы базы данных. Имя триггера должно быть уникальным среди имен триггеров схемы базы данных.