Интеграция Intranet-технологий и СУБД

4. Интеграция Intranet-технологий и СУБД

Основой для построения информационных Intranet-приложений служит интеграция Intranet-технологий и СУБД.

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

4.1. Основы реляционных БД

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

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

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

4.1.1. Файл-серверные приложения и "настольные" СУБД

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

Однако, такая архитектура имеет два основных недостатка:

Значительный сетевой трафик (некоторые запросы к БД могут перекачивать всю БД клиенту, загружая сеть и имея непредсказуемое время реакции).
Проблема "жирного клиента" ( Windows-интерфейс, коды приложения и СУБД могут перегрузить даже мощный ПК).

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

Основой разработки файл-серверных приложений для локальных сетей ПК является инструментальное окружение различных "персональных" СУБД: FoxPro, Clipper, Paradox, Clarion, dBase, Access и др. Такие инструменты, как правило, реализованы в виде диалоговой интегрированной среды, предоставляющей три уровня доступа:

программирование и создание приложений на языке, сочетающем возможности языка 3GL с некоторыми возможностями языков четвертого поколения 4GL;
создание и ведение структуры БД и индексов, а также интерактивная генерация макетного приложения и его компонентов (меню, форм или окон, отчетов, запросов и программных модулей);
использование диалоговой среды и генераторов конечными пользователями для создания, ведения и просмотра БД, а также формирования несложных запросов и отчетов.

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

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

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

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

В настоящее время появились новые визуальные объектно-ориентированные версии инструментальных средств и СУБД на ПК (MSAccess, VisualFoxPro, CA-VisualObjects и VisualdBase). Эти продукты направлены сугубо на создание Windows-приложений и содержат средства объектно-ориентированного диалога, событийно-управляемого программирования, визуального конструирования интерфейса пользователя и многие другие черты, присущие системам программирования 4GL и средствам быстрой разработки RAD. Кроме того, они поддерживают структурный язык запросов SQL, который характерен для приложений клиент-сервер.

4.1.2. Архитектура клиент-сервер, сервера БД и инструментальные средства

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

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

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

Для реализации серверов БД используются системное ПО реляционных СУБД, понимающих язык запросов SQL, например: Oracle, Informix, Sybase, MSSQLServer. Многие из этих СУБД работают на различных аппаратных платформах и в средах разных ОС.

Объектами разработки в приложениях клиент-сервер, помимо диалога и логики обработки, являются, прежде всего, реляционная модель данных и связанный с ней набор SQL-операторов для типовых запросов для этой БД.

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

В классической схеме клиент-сервер значительная часть приложения располагается на клиенте, а СУБД - на сервере. Поскольку эта схема предъявляет наименьшие требования к серверу, она обладает наилучшей масштабируемостью. Однако сложные приложения, вызывающие большое взаимодействие с БД, могут жестко загрузить как клиента, так и сеть. Результаты SQL-запроса должны вернуться к клиенту для обработки, потому что там находится логика принятия решения. Такая схема возлагает дополнительное бремя администрирования приложений, разбросанных по различным клиентским узлам.

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

Группу инструментальных средств для создания информационных приложений с архитектурой клиент-сервер можно разделить на следующие подгруппы:

среды разработки приложений для серверов баз данных;
независимые от СУБД инструменты для создания приложений клиент-сервер;
средства поддержки распределенных информационных приложений.

Среды разработки приложений для серверов БД представляют собой системы программирования четвертого поколения 4GL или инструментальные средства быстрой разработки приложений RAD (RapidApplicationDevelopment). Особенностями этой подгруппы средств являются:

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

В качестве примера можно назвать инструменты Informix/4GL, Oracle*Forms и др.

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

возможность распределения приложения на клиентах и/или серверах;
создание приложений для разных серверов БД;
поддержка спецификации ODBC (OpenDataBaseConnectivity) для доступа к различным серверам БД, включая СУБД для ПК;
связь с мониторами транзакций для организации трехзвенной архитектуры приложений клиент-сервер;
объектно-ориентированное программирование приложений;
визуальный характер генерации приложения;
ведение репозитория объектов и их свойств, что облегчает интеграцию со средствами автоматизации проектирования программ CASE;
управление проектами и версиями приложений;
интеграция приложения с электронной почтой и средствами офисной автоматизации.

Известными примерами независимых инструментальных средств разработки являются: PowerBuilder, JAM, Uniface и др.

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

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

интерфейсы доступа к базам данных ODBC и IDAPI;
шлюзы для систем управления базами данных;
протоколы и команды мониторов обработки транзакций;
почтовые интерфейсы MAPI, VIM, MHS, X.400 и EDI;
средства обмена сообщениями MOM;
протоколы связывания и встраивания объектов OLE и динамического обмена данными DDE;
протоколы удаленного вызова процедур RPC и именованных конвейеров NamedPipes;
средства коммуникационного ввода-вывода BSDSockets и WinSock.

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

4.1.3. Язык SQL

SQL является наиболее мощным и популярным языком манипулирования данными реляционных систем управления базами данных (СУБД). Основные возможности языка, доступные в SQL-ориентированных СУБД, определены в рамках специального стандарта ANSI/ISO. SQL-стандарт признан с 1982 года, а формально определен как ANSI-стандарт Х3.135 в 1986 году и как ISO-стандарт - в 1987. Стандартизация возможностей SQL продолжается и сейчас. На смену стандарту SQL2, реализованному в большинстве коммерческих СУБД, приходит новый вариант - SQL3.

SQL сочетает в себе возможности языка определения данных, языка манипулирования данными и языка запросов. При этом он реализует и основные функции реляционных СУБД:

Определение данных. SQL позволяет определить структуру поддерживаемых данных и организацию используемых реляционных отношений.

Доступ к данным. SQL обеспечивает доступ к хранимым данным из приложений.

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

Управление доступом. SQL обеспечивает синхронизацию обработки базы данных различными прикладными программами, защиту данных от несанкционированного доступа.

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

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

SQL в стандарте ANSI/ISO является реляционно-полным языком, и СУБД, поддерживающие его, удовлетворяют всем правилам Кодда.

Структура основного предложения SQL

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

SELECT (distinct), <элемент(ы)>
FROM <таблица(ы)>
WHERE <условие отбора>
GROUPBY <колонка(и)>
HAVING <условие отбора>
ORDERBY <упорядоченность(и)>

Результатом запроса всегда является таблица требуемой структуры с требуемыми данными. В частном случае таблица может содержать одну колонку и одну строку, т.е. представлять собой простое значение. Результирующая таблица может иметь повторяющиеся строки, удалить которые можно, указав DISTINCT в позиции SELECT. Рассмотрим назначение позиций в структуре предложения запроса.

SELECTопределяет, какие колонки должна иметь результирующая таблица. Символ "*" означает, что результирующая таблица должна включать в себя все колонки всех таблиц, на основе которых строится запрос. Если несколько исходных таблиц имеют одноименные колонки, то идентифицировать нужную колонку можно, указав ее полное имя, составленное из имени таблицы и имени колонки. В качестве колонки результирующего отношения может быть указано любое выражение, использующее набор стандартных функций, например, COUNT(), AVG(), SUM() и другие.

FROMопределяет список таблиц, на основе которых строится запрос. Поскольку SQL является структурным языком, то он допускает использование вложенных SELECT-конструкций. В качестве базовой таблицы может быть указано некоторое SELECT-предложение.

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

GROUPBY определяет список имен колонок, по одинаковым значениям которых будет выполняться группировка строк. Т. е. строки с одинаковыми значениями в указанных колонках будут представлены в результирующем отношении одной строкой. Но если в SELECT указана, например, функция AVG() или SUM(), то она применяется ко всем строкам группы.

HAVING позволяет отобрать из множества сгруппированных строк только те, которые удовлетворяют указанному условию.

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

Два или более SELECT-предложения могут образовывать общую результирующую таблицу с использованием реляционных операций соединения (UNION), пересечения (INTERSECT) и деления (DIFFERENCE).

Модификация данных

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

Операция вставки INSERT может быть единичной либо групповой. Для единичной вставки необходимо явным образом определить значения колонок новой строки. Если указан неполный перечень колонок таблицы. то оставшиеся колонки получают неопределенное значение (NULL).

Операция групповой вставки предполагает добавление строк в таблицу из некоторой другой таблицы, указанной явно или с помощью SELECT-предложения.

Операция удаления DELETE является групповой, т.е. применяется ко всем строкам таблицы, удовлетворяющим требуемому условию. В отличие от запись-ориентированных языков манипулирования данными, SQL не использует понятия текущей строки в таблице, предполагая. что любая строка может быть однозначно идентифицирована в таблице с помощью значения первичного ключа. Если условие отсутствует, то удаляются все строки таблицы. Условие может использовать функцию проверки вхождения значения в некоторую другую таблицу, заданную с помощью SELECT-конструкции.

Операция обновления значений в строках таблицы UPDATE также является групповой. Условие определяет, к каким строкам требуется применить операцию обновления. В условии, аналогично DELETE, можно использовать SELECT-конструкции.

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

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

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

Такого рода ограничения целостности определяются при создании отдельных таблиц и определении структуры базы данных.

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

Утверждение COMMIT означает удачное окончание текущей транзакции и начало новой. Утверждение ROLLBACK указывает на необходимость выполнения обратного отката, т.е. автоматического восстановления состояния базы данных на момент начала транзакции.

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

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

Создание базы данных

Язык SQL сочетает в себе возможности языка манипулирования данными и языка определения данных. Язык определения данных позволяет:

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

Для определения нового объекта базы данных используется ключевое слово CREATE, для удаления - DROP, для изменения - ALTER.

Внешние ключи FOREIGNKEY используются для логического связывания нескольких таблиц в некоторое представление. Определяя внешний ключ, можно установить соответствие строк между различными таблицами. Логическое связывание выполняется для строк, имеющих совпадающее значение в указанных колонках.

Ограничение на уникальность строк в таблице UNIQUE указывается аналогично определению первичного ключа.

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

Удаление таблицы DROP является наиболее простой операцией.

Реструктуризация таблицы ALTER заключается в изменении состава колонок и ключей.

Полное имя таблицы в базе данных включает в себя префикс - имя владельца. Для удобства идентификации несобственных таблиц в SQL предусмотрена возможность определения синонимов. Использовать синонимы можно во всех предложениях SQL.

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

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

Виртуальная таблица VIEW является результатом неявного выполнения некоторой SELECT-конструкции. Строки такой таблицы образуются либо в момент обращения к ним, либо, однажды сформировавшись, постоянно изменяются при изменении отношений, входящих в соответствующую SELECT-конструкцию.

Важным моментом при создании баз данных является определение привилегий пользователей (перечня разрешенных операций при использовании базы данных). При работе с базой данных пользователь проходит регистрацию, указывая свое имя и пароль. На основе имени пользователя СУБД контролирует действия пользователя и отклоняет несанкционированные операции. Установить привилегии пользователю можно предложением GRANT, а снять - предложением REVOKE.

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

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

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

Встроенный SQL предполагает использование некоторого основного языка программирования (например, С, Pascal, Ada, Cobol, Fortran, Assembler) и SQL-процессора. Реализация встроенного SQL регламентирована стандартом фирмы IBM для SQL-продуктов.

Текст программы состоит из произвольной смеси команд основного языка и команд SQL со специальным префиксом, например, ExecSQL. Структура SQL-предложений расширена для использования переменных основного языка в SQL-конструкциях.

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

Для работы препроцессора необходимо в каждой программе определять структуру используемых таблиц, например, с помощью конструкции CREATETABLE. Вводится дополнительная инструкция DECLARE, предоставляющая возможность ссылаться на описание таблицы из нескольких SQL-предложений в разрабатываемых программах. Структура такой инструкции аналогична CREATE, но содержит только информацию, необходимую для работы SQL-препроцессора.

Обработка ошибок во встроенном SQL выполняется на шаге компиляции и при выполнении. На шаге компиляции программы ошибки в SQL-предложениях выявляются препроцессором. При выполнении приложения код завершения каждого SQL-предложения содержится в специальной переменной основного языка программирования SQLCODE.

Для обработки ошибок времени выполнения предусмотрено специальное SQL-предложение WHENEVER, определяющее действия, которые необходимо предпринять при возникновении ошибочной ситуации.

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

Для получения значений многострочного запроса используется понятие курсора. Определение курсора с помощью DECLARECURSOR заключается в связывании имени курсора с определенным запросом - SELECT-предложением. Затем курсор открывается с помощью OPEN-предложения, с которым можно ассоциировать позиционирование к первой строке таблицы-результата. Предложение FЕTCH позволяет считать строку таблицы в указанные основные переменные и перейти к следующей строке. Это предложение выполняется в цикле до достижения конца таблицы-результата. При возникновении ситуации WHENEVERNOTFOUND необходимо закрыть курсор с помощью CLOSE.

Понятие курсора и текущей строки таблицы используется и для операций позиционированного обновления и удаления строк. В этом случае UPDATE и DELETE выполняются для текущей строки таблицы, с которой связан указанный курсор.

Язык структурированных запросов SQL является непроцедурным языком, ориентированным на работу с БД, и не содержит средств традиционных алгоритмических средств для описания логики приложения. Инструментарий для реляционных СУБД может включать алгоритмические процедурные расширения, оформленные в виде самостоятельных языков и соответствующих интерпретаторов и компиляторов. Примером такого языка является PL/SQL для СУБД Oracle.

OraclePL/SQL вводит следующие процедурные возможности для SQL:

операторы объявления и вызова процедурных модулей;
блочные конструкции BEGIN-END для операторов;
управляющие операторы:
- IF-THEN-ELSE,
- EXIT,
- GOTO;
операторы циклов:
- FOR-LOOP,
- WHILE-LOOP;
операторы объявления переменных;
оператор присваивания с арифметическими выражениями.

Язык PL/SQL широко используется при работе с различными программными продуктами Oracle:

при организации хранимых процедур сервера БД Oracle;
блоки PL/SQL применяются в генераторах OracleForms и Reports;
блоки применяются также во встроенных SQL для языков 3GL (например, в Pro*C).

Механизм PL/SQLEngine встраивается в различные компоненты и обеспечивает распознавание операторов и конструкций SQL и PL/SQL в смешанном потоке предложений. Конструкции и операторы PL/SQL исполняются внутри интерпретатора. Обнаруженный оператор SQL передается серверу БД, где производится его синтаксический разбор, связывание со значениями переменных, компиляция и выполнение запроса к БД.

Блоки и модули PL/SQL могут быть частично откомпилированы, что обеспечивает повышение скорости выполнения хранимых процедур и триггеров.

4.1.4. Открытый протокол ODBC для связи с сервером БД

Интерфейс прикладного программирования ODBCAPI предоставляет общие методы доступа SQL как к реляционным, так и к нереляционным (ISAM) источникам данных.

В ANSISQL входит интерфейс на уровне вызовов (CLI - call-levelinterface), который используется ODBC для обеспечения доступа и работы с данными во многих системах управления базами данных. Интерфейс CLI соответствует требованиям, установленным в 1991 году группой SQLAccessGroup, которые определяют общий синтаксис SQL и интерфейса API. Иметь общий метод доступа к источникам данных удобно потому, что тогда база данных на сервере становится прозрачной для приложений, которые написаны в соответствии с некоторым заданным уровнем совместимости ODBC.

Интерфейс ODBCAPI реализован как набор расслоенных DLL-функций для Windows. Динамическая библиотека ODBC.DLL - это основная библиотека управления драйверами ODBC, которая вызывает специализированные драйверы для разных поддерживаемых системой баз данных. Каждый драйвер совместим со своим уровнем CLI и относится к одной из двух категорий: одноуровневые или многоуровневые драйверы.

Одноуровневые драйверы предназначены для использования при работе с теми источниками данных, которые не могут быть обработаны ANSISQL. Обычно это локальные базы данных на персональных компьютерах, такие как dBase, Paradox, FoxPro и Excel. Драйверы, соответствующие этим базам данных, переводят грамматику ANSISQL в инструкции низкого уровня, которые непосредственно обрабатывают составляющие базу данных файлы.

Многоуровневые драйверы используют сервер СУРБД для обработки SQL-предложений и предназначены для работы в среде клиент-сервер. Помимо обработки ANSISQL, они также могут поддерживать и собственную грамматику конкретной СУРБД, поскольку ODBC может без трансляции передавать SQL-предложения источникам данных (механизм "passthrough"). Драйверы ODBC для баз данных типа клиент-сервер реализованы для OracleV6.0 и Oracle7, а также Informix, Microsoft и SybaseSQLServer, Rdb, DB2, Ingres, HP/Image и AnySQL. Драйверы можно приобрести в фирмах Microsoft, Intersolv, Visigenic и Openlink, причем только Microsoft и Intersolv выпускают и 32-х, и 16-ти разрядные драйверы.

Существует 4 важных этапа (шага) процедуры запроса данных через API.

Шаг 1 - установление соединения. Он состоит в размещении указателей (handle) среды ODBC, которые выделяют оперативную память под ODBC драйверы и библиотеки. Затем происходит выделение памяти для указателей соединения, и соединение устанавливается.

Шаг 2 - выполнение предложения SQL. Выделяется указатель предложения, локальные переменные связываются со столбцами в SQL-выражении (это необязательное действие), и выражение представляется на разбор главному ODBC драйверу для обработки.

Шаг 3 - извлечение данных. Перед извлечением данных возвращается информация о результирующем наборе, такая как число столбцов в наборе. Исходя из этого числа, результирующий набор помещается в буфер записей, выполняется цикл по нему и извлекается по одному столбцу в локальные переменные. Этот шаг необязателен, если используется связывание столбцов.

Шаг 4 - освобождение ресурсов. После того, как данные получены, освобождаются ресурсы вызовом функций освобождения указателей предложения, соединения и среды. Указатели предложения и соединения могут быть использованы в процессе обработки.

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

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

Назад | Содержание | Вперед