Материал: Graber_Martin_-_SQL_dlya_prostykh_smertnykh_-_2014

Приложение Е. Таблицы, используемые в 1tримерах

Таблица 1. Salespeople (продавцы)

356

Приложение F. SQL сегодня

SQLсегодня

В настоящее время SQL переживает новый подъем. В качестве коммерческого продукта язык был впервые реализован в Oracle в 1976 году, но официального стан­ дарта SQL не существовало до 1986 года, когда он был опубликован как результат объ­

единенных усилий ANSI (the American National Standards Institute) и ISO (lnternational

Standards Organization). Поскольку ANSI является частью ISO, в данном приложении мы ссылаемся на обе эти организации как на ISO. Стандарт 1986 года был пересмот­ рен в 1989 году, в него были введены средства, обеспечивающие ссылочную целост­

ность (referential integrity).

К тому времени, когда появился стандарт 86, ряд программных продуктов уже ис­ пользовал SQL, и ISO попытался закрепить в стандарте наиболее общие черты этих реа­ лизаций для того, чтобы ввод стандарта не отразился слишком болезненно на готовых программных продуктах. ISO проанализировал все основные характеристики сущест­ вовавших к тому времени программных реализаций и определил весьма минимальный стандарт. Некоторые существенные характеристики, например, как уничтожение объек­ тов и передача привилегий, были опущены из стандарта полностью. Теперь, когда мно­ гообразный компьютерный мир стал столь коммуникабельным, разработчики и пользователи хотят без особых проблем взаимодействовать с множеством баз данных, разработанных индивидуально. В результате возникла потребность в стандартизации тех характеристик, которые ранее были отданы на усмотрение разработчика. Несколько лет эксплуатации конкретных систем и теоретических исследований дали новые идеи, которые требуют единообразия при воrшощении в программных продуктах. Для удов­ летворения этих потребностей ISO разработал новый стандарт SQL 92 .

Стандарт SQL 92 превышает первый стандарт SQL по объему примерно в пять раз. В нем значительно расширена область стандартизаuии, а также определен стандарт для ряда существовавших характеристик, которые до этого были отданы на волю раз­ работчика, включены те моменты, которые ранее были опущены. Поскольку стандарт SQL 92, включает как подмножество стандарт 89, можно ссылаться на стандарт 92, если программный продукт удовлетворяет требованиям стандарта 89 или некоторым промежуточным требованиям.

Естественно, те продукты, которые используются, могут по-своему расширять стандарт. Для того чтобы прикладной программист мог выделять все специфические моменты, имея дело с такими расширениями, новый стандарт требует применения флаггера (flagger) - программы, проверяющей основной код и помечающей (марки­ рующей) все предложения SQL, не соответствующие стандарту 92. Непомеченные предложения ведут себя так, как описано в этой книге. Для помеченных предложений,

конечно, следует применять системную документаuию. Возможна ситуация, при кото­

рой предложение соответствует стандарту, а его поведение - нет. Такое предложение также помечается. В любом случае, этот стандарт более полон, чем предыдущий, по­

этому необходимость в стандартных характеристиках для достижения функциональ­

ной полноты программного продукта практически отпала.

358

SQL сегодня

Пользователи, схемы и сеансы связи

Одной из областей, в которой старый стандарт отсутствовал, а новый стандарт су­ щественно улучшен, является определение контекста применения SQL - определе­ ния пользователя, схемы и сеанса. Предыдущий стандарт отдавал эти области практически полностью на усмотрение разработчика базы данных. В этом разделе мы приводим обзор среды SQL в соответствии со стандартом 92.

В SQL имеются средства организации данных. Данные содержатся в таблицах, таб­

лицы группируются в схемы, схемы группируются в каталоги. Каталоги могут далее

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

тельствовать системная документация.

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

возможность использования каталогов, отражающих связь кластеров.

В стандарте уточняется смысл требований SQL относительно того, кто и какие предложения может задавать. Тот, кто выдает предложения SQL, называется SQL- агентом. Им может быть пользователь, непосредственно работающий с SQL, или приложение. Агент SQL устанавливает связь с СУБД. Как только связь установле­ на, начинается сеанс. Реализации позволят SQL-агентам переключаться на некото­ рые другие связи и сеансы. В среде клиент/сервер эти связи или сеансы могут быть полностью адресованы другому серверу. В любой момент времени может сущест­

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

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

пользователями или модулем какого-то языка программирования, если таковой

имеется.

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

Что нового в стандарте 92?

Стандарт 92, за редкими исключениями, полностью включает в себя стандарт 89. Если он вам известен, то достаточно ознакомиться лишь с обзором того, что было к нему добавлено.

Предложения определения схемы. Схема (shema) - это множество объектов базы данных, которые управляются единственным пользователем и могут рассматри­ ваться как единое целое. Предыдущий стандарт SQL определял процедуры создания и удаления таблиц и других объектов, но он просто отождествлял схемы с идентифи­ каторами пользователей (authorization IDs), как правило, понимая под пользователем его ID, что не оговорено в стандарте. Для пользователей, которые могут захотеть соз­ дать более одной схемы, новый стандарт включает предложения для создания и уда-

359

Приложение F. SQL сегодня

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

стеры.

Временные таблицы. В первом стандарте было выделено два типа таблиц: по­ стоянные базовые таблицы (base taЫes) и представления (views). Базовые табли­ цы - это основные (базовые) данные, а представления - это, так называемые, виртуальные таблицы (virtual taЫes) - таблицы, выводимые из базовых с помощью запросов. Оба типа таблиц - постоянные, хотя содержимое представления не опре­ делено до тех пор, пока к нему не осуществляется доступ. Теперь в дополнение к постоянным базовым таблицам и представлениям появились три типа временных базовых таблиц. Два из них (глобальные временные таблицы и созданные локаль­ ные временные таблицы) имеют, подобно представлениям, постоянные определе­ ния, как объекты в схеме, но их содержимое постоянно не хранится в базе данных. Третий вид - локальные временные таблицы не имеет даже постоянно хранящего­ ся определения. В отличии от представлений, временные таблицы не являются только альтернативными представлениями данных, содержащихся в базовых табли­ цах или выводимых из них, а содержат и свои собственные данные, которые авто­ матически создаются по концу сессии или транзакции. Следовательно, содержимое определения временной таблицы является определением базовой таблицы, но дан­ ные в ней не хранятся постоянно. С другой стороны, содержимым представления является запрос, используемый для того, чтобы вывести данные, когда к представ­ лению осуществляется доступ. Временные таблицы, как правило, используются для рабочей памяти или для получения промежуточных результатов подобно перемен­

ным в программе, которые являются полезными в течение некоторого времени и не

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

ния доступом.

Встроенные операторы JOIN. Способность выполнять соединения является ча­ стью предложения SELECT, но ранее не было механизмов встраивания SQL в авто­ матически генерируемые соединения различных типов. При определении множества таблиц (или многократных вхождений одной и той же таблицы) в предложении FROM для запроса, предполагающего соединение, считается, что в оставшейся части предложения определен тип соединения, который нужно выполнить. Например, но­

вый стандарт имеет встроенные операторы для получения соединения следующих

типов:

360