Лекция 2

Проблемы переносимости (миф о переносимости)

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

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

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

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

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

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

• Программный интерфейс. В первом стандарте определен абстрактный способ использования SQL в приложениях, написанных на таких языках программирования, как COBOL, С, FORTRAN и др. Этот способ не реализован ни в одном коммерческом продукте, а в существующих программных интерфейсах имеются значительные отличия. В стандарте 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 играет в каждой из них.

Инструкции

В SQL существует приблизительно сорок инструкций. Каждая из них ''просит" СУБД выполнить определенное действие, например извлечь данные, создать таблицу или добавить в таблицу новые данные.

Каждая инструкция SQL начинается с команды, т.е. ключевого слова, описывающего действие, выполняемое инструкцией. Типичными командами являются create (создать), insert (добавить), delete (удалить) и commit (зафиксировать). После команды идет одно или несколько предложений. Предложение описывает данные, с которыми работает инструкция, или содержит уточняющую информацию о действии, выполняемом инструкцией. Каждое предложение также начинается с ключевого слова, такого как where (где), from (откуда), into (куда) и having (имеющий). Одни предложения в инструкции являются обязательными, а другие — нет. Конкретная структура и содержимое предложения могут изменяться. Многие предложения содержат имена таблиц или столбцов; некоторые из них могут содержать дополнительные ключевые слова, константы и выражения.

В стандарте ANSI/ISO определены ключевые слова, которые применяются в качестве команд и в предложениях инструкций. В соответствии со стандартом эти ключевые слова нельзя использовать для именования объектов базы данных, таких как таблицы, столбцы и пользователи. Во многих СУБД этот запрет ослаблен, однако следует избегать использования ключевых слов в качестве имен таблиц и столбцов. В табл. 5.2 перечислены ключевые слова, включенные в стандарт SQL2. Их почти в три раза больше, чем в SQL1. В стандарте SQL2 определен также список "потенциальных" ключевых слов, которые могут стать таковыми в будущих версиях стандарта (табл. 5.3).

Имена

У каждого объекта в базе данных есть уникальное имя. Имена используются в инструкциях SQL и указывают, над каким объектом базы данных инструкция должна выполнить действие. Основными именованными объектами в реляционной базе данных являются таблицы, столбцы и пользователи; правила их именования были определены еще в стандарте SQL1. В стандарте SQL2 этот список значительно расширен и включает схемы (коллекции таблиц), ограничения (ограничительные условия, накладываемые на содержимое таблиц и их отношения), домены (допустимые наборы значений, которые могут быть занесены в столбец) и ряд других объектов. Во многих СУБД существуют дополнительные виды именованных объектов, например хранимые процедуры (Sybase и SQL Server), отношения "первичный ключ — внешний ключ" (DB2) и формы для ввода данных (Ingres).

В соответствии со стандартом ANSI/ISO имена в SQL должны содержать от 1 до 18 символов, начинаться с буквы и не содержать пробелов или специальных символов пунктуации. В стандарте SQL2 максимальное число символов в имени увеличено до 128. На практике поддержка имен в различных СУБД реализована по-разному. В DB2, к примеру, имена пользователей не могут превышать 8 символов, но имена таблиц и столбцов могут быть более длинными. Кроме того, в различных СУБД существуют разные подходы к использованию в именах таблиц специальных символов. Поэтому для повышения переносимости лучше делать имена сравнительно короткими и избегать употребления в них специальных символов.

Имена таблиц

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

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

SAM.BIRTHDAYS

Полное имя таблицы можно использовать вместо короткого имени во всех инструкциях SQL.

Стандарт SQL2 еще больше обобщает понятие полного имени таблицы. Он разрешает создавать именованное множество таблиц, называемое схемой. Для доступа к таблице в схеме также применяется полное имя. Например, обращение к таблице birthdays, помещенной в схему employeeinfo, записывается так:

EMPLOYEEINFO.BIRTHDAYS

Имена столбцов

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

SALESREPS.SALES

Если столбец находится в таблице, владельцем которой является другой пользо­ватель, то в полном имени столбца следует указывать полное имя таблицы. Например, полное имя столбца вirth_date в таблице birthdays, владельцем которой является пользователь SAM, имеет следующий вид:

SAM.BIRTHDAYS.BIRTH_DATE

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

Контрольные вопросы

1. Стандарт SQL и переносимость приложений.

2. Перечислите основные проблемы переносимости.

3. Сформулируйте правила формирования имен объектов в SQL.