Стандарт SQL

Рйс-3.1. Миф о перенасимости SQL

Эти отличия, большинство из которых устранено в стандарте SQL2, но не в коммерческих продуктах, включают в себя:

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

Типы данных. В стандарте SQL-89 определен минимальный набор типов данных, однако в нем отсутствуют некоторые из наиболее распространенных и полезных типов, например символьные строки переменной длины, дата и время, а также денежные единицы. В стандарте SQL2 упомянуты эти типы данных, однако отсутствуют новые типы данных, такие как фафические и мультимедийные объекты.

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

Интерактивный SQL. В стандарте SQL-89 определен только программный SQL, используемый в приложениях. Например, инструкция select, предназначенная для выполнения запросов к базе данных в интерактивном режиме, в стандарте отсутствует.

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

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

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

Порядок сортировки. В стандарте SQL-89 не упоминается порядок сортировки символов, хранящихся в базе данных. Результаты запроса с сортировкой будут отличаться при вьшолнении этого запроса на персональном компьютере (с кодировкой ASCII) и на мэйнфрейме (с кодировкой EBCDIC). Стандарт SQL2 включает расширенную спецификацию того, как программа или пользователь могут запрашивать требуемый порядок сортировки, но это касается только верхнего уровня совместимости, который еще не реализован в большинстве СУБД.

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

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

SQL и сети

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

Централизованная архитектура

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

Большая ЭВМ

Нажатия клавиш --

Символы

Припожение

СУБД

База данных

Рис. 3.2. Место СУБД в централизованной.архитектуре

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

Архитектура файл/сервер

Появление персональных компьютеров и локальных вычислительных сетей привело к разработке архитектуры файл/сервер (рис. 3.3). При такой архитектуре приложение, выполняемое на персональном компьютере, может получить прозрачный доступ к файловому серверу, на котором хранятся совместно используемые файлы. Когда приложению, работающему на ПК, требуется получить данные из такого файла, сетевое программное обеспечение автоматически считывает требуемый блок данных с сервера. Архитектура файл/сервер поддерживалась первыми СУБД для персональных компьютеров, такими как dBASE и позднее Microsoft Access, при этом на каждом ПК работала своя копия СУБД.

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