4.7. Несовершенство языка sql

Как отмечалось во введении к этой главе, язык SQL далек от совершенства и имеет недостатки, вызванные многочисленными недоделками и переделками. Конкретные кри- тические замечания будут представлены в последующих главах. Здесь лишь отметим, что основной недостаток заключается в том, что, строго говоря, язык SQL, в целом, не- корректно поддерживает реляционную модель. Поэтому возникает сомнение, заслужи- вают ли современные SQL-продукты права называться действительно реляционными. Фактически, насколько это известно автору, на сегодняшний день на рынке нет ни одно- го продукта, который поддерживал бы реляционную модель в полном объеме. Мы не хотим этим сказать, что какие-то аспекты реляционной модели не важны; как раз наобо- рот, каждый элемент в модели важен. Более того, каждый из ее элементов важен по чисто практическим соображениям. Нельзя не подчеркнуть тот непреложный факт, что назначение реляционной теории состоит не в том, чтобы просто быть "теорией для тео- рии". Вовсе нет, ее назначение — обеспечить базу для построения систем, которые бу- дут практическими на все сто процентов. Но, как это ни печально, со стороны изгото- вителей продуктов еще не сделано реальных шагов к решению проблемы реализации ре- ляционной теории во всей ее полноте. В результате "реляционные" продукты сегодняш- него дня все как один по тем или иным причинам оказываются неспособными реализо- вать преимущества, которые теоретически могут быть получены в результате использо- вания реляционной технологии.

4.8. Резюме

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

Язык SQL состоит из двух компонентов: языка определения данных (DDL) и языка манипулирования данными (DML). Язык манипулирования данными может приме- няться и на внешнем уровне (по отношению к представлениям), и на концептуальном уровне (по отношению к базовым таблицам). Аналогично язык определения данных мо- жет использоваться для определения объектов на внешнем уровне (представления), кон- цептуальном уровне (базовые таблицы), а в большинстве коммерческих систем (хотя это и не соответствует самому стандарту) даже на внутреннем уровне (по отношению к ин- дексам и другим физическим структурам организации памяти). Кроме того, язык SQL предоставляет определенные возможности управления данными, т.е. возможности, кото- рые нельзя отнести ни к языку DDL, ни к языку DML. Примером здесь может служить оператор GRANT, который одни пользователи могут применять для предоставления приви- легий доступа другим пользователям системы (глава 16).

Мы показали, как можно использовать язык SQL для создания базовых таблиц с по- мощью оператора CREATE TABLE. Затем мы привели несколько примеров использования операторов SELECT, INSERT, UPDATE и DELETE и, в частности, продемонстрировали, как можно применять оператор SELECT для реализации операций выборки, проекции и со- единения. Также некоторое внимание было уделено информационной схеме, состоящей из множества предопределенных представлений гипотетической "схемы определения", и возможностям языка SQL по работе с представлениями и транзакциями.

Значительная часть этой главы была посвящена внедренным SQL-операторам. Ос- новная идея, лежащая в основе использования внедренных SQL-операторов, называется принципом двухрежимности, т.е. принципом, в соответствии с которым (насколько это возможно) любое SQL-выражение, которое можно использовать интерактивно, мож- но внедрить и в прикладную программу. Главное исключение из этого принципа имеет место в связи с операциями многострочной выборки, для которых требуется исполь- зовать курсоры, позволяющие преодолеть разрыв между возможностью выборки дан- ных на уровне множеств в языке SQL и возможностями выборки данных на уровне стро- ки в базовых языках программирования, таких, например, как PL/I.

Далее мы обсуждали, главным образом, вопросы синтаксиса, в том числе выяснили на- значение переменной SQLSTATE и рассмотрели такие операторы, как однострочный опера- тор SELECT и операторы INSERT, UPDATE и DELETE, для которых курсор не нужен. Затем мы возвратились к операторам, для которых требуется использование курсора, и обсудили операторы DECLARE CURSOR, OPEN, FETCH, CLOSE и формы CURRENT для операторов UPDATE и DELETE. (В стандарте языка SQL форму CURRENT этих операторов называют позиционным оператором UPDATE и DELETE соответственно, а термин поисковый используют для других форм этих операторов, отличных от CURRENT.) Наконец, мы кратко обсудили концепцию динамического языка SQL, в частности -— операторы PREPARE и EXECUTE, а также кратко коснулись назначения интерфейса SQL Call-Level Interface или CLI.

Упражнения

4.1. На рис. 4.5 показаны примеры значений данных для расширенной формы базы данных поставщиков и деталей, которая называется базой данных поставщиков, деталей и проектов. Поставщики (S), детали (Р) и проекты (J) однозначно опреде- ляются номером поставщика (S#), номером детали (Р#) и номером проекта (Jt) со-

ответственно. Значение строки SPJ (поставки) следующее: определенный постав- щик поставляет определенную деталь для определенного проекта в определенном количестве (причем комбинация значений столбцов S#-P#-J# уникальна для от- дельных строк). Запишите соответствующие определения данных на языке SQL для этой базы данных.

Замечание. Эта база данных будет использоваться во многих упражнениях в по- следующих главах.

S	s#	SNAME	STATUS	CITY		SPJ	s#	P#	J#	QTY
	SI	Smith	20	London			SI	PI	Jl	200
	S2	Jones	10	Paris			SI	PI	J4	700
	S3	Black	30	Paris			S2	P3	Jl	400
	S4	Clark	20	London			S2	P3	J2	200
	S5	Adams	30	Athens			S2	P3	J3	200
							S2	P3	J4	500
							S2	P3	J5	600
р	P#	PNAME	COLOR	WEIGHT	CITY		S2	P3	J6	400
	PI	Nut	Red	12.0	London		S2	P3	J7	800
	P2	Bolt	Green	17.0	Paris		S2	P5	J2	100
	P3	Screw	Blue	17.0	Rome		S3	P3	Jl	200
	P4	Screw	Red	14.0	London		S3	P4	J2	500
	P5	Cam	Blue	12.0	Paris		S4	P6	J3	300
	P6	Cog	Red	19.0	London		S4	P6	J7	300
							S5	P2	J2	200
							S5	P2	J4	100
J	J#	JNAME	CITY				S5	P5	J5	500
	Jl	Sorter	Paris				S5	P5	J7	100
	J2	Display	Rome				S5	P6	J2	200
	J3	OCR	Athens				S5	PI	J4	100
	J4	Console	Athens				S5	P3	J4	200
	J5	RAID	London				S5	P4	J4	800
	J6	EDS	Oslo				S5	P5	J4	400
	J7	Tape	London				S5	P6	J4	500

Рис. 4.5. База данных поставщиков, деталей и проектов (значения для примера)

2. В разделе 4.2 был описан оператор CREATE TABLE, как он определен в стандарте языка SQL. Однако многие коммерческие продукты поддерживают дополнитель- ные опции этого оператора, обычно связанные с индексами, размещением на дис- ковом пространстве и другими вопросами реализации, что противоречит цели фи- зической независимости данных и междусистемной совместимости. Исследуйте доступный вам продукт, поддерживающий язык SQL. Верны ли предыдущие заме- чания для этого продукта? В частности, какие дополнительные опции оператора CREATE TABLE поддерживаются в этом продукте?

3. И снова исследуйте доступный вам продукт, поддерживающий язык SQL. Поддер- живается ли в нем информационная схема? Если нет, то каким образом поддержи- вается каталог?

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

а) Вставить нового поставщика 'S10' в таблицу S; имя поставщика— 'Smith', город— 'New York', статус еще неизвестен.

б) Изменить цвет всех красных деталей ('red') на оранжевый ('orange').

в) Удалить все проекты, для которых нет поставок.

5. Используя базу данных поставщиков, деталей и проектов, напишите программу с внедренными SQL-выражениями для выдачи списка всех строк поставщиков по порядку их номеров. За каждой строкой поставщика должны непосредственно сле- довать строки проектов, обеспечиваемых этим поставщиком, по порядку номеров проектов.

6. Даны таблицы PART и PART_STRUCTURE, определенные таким образом.

CREATE TABLE PART

(Pi ... , DESCRIPTION ... , PRIMARY KEY ( Pi ) ) ; CREATE TABLE PART_STRUCTURE

( MAJOR Pi .7. , MINOR Pi ... , QTY ... , PRIMARY KEY ( MAJOR Pi, MINOR Pi ), FOREIGN KEY ( MAJ0R~Pi ) REFERENCES PART, FOREIGN KEY ( MIN0R~Pi ) REFERENCES PART ) ;

В таблице PART_STRUCTURE показано, какие детали (MAJOR_Pi) содержат другие де- тали (MINOR_Pi) как компоненты первого уровня. Напишите программу на языке SQL для получения списка всех компонентов данной детали на всех имеющихся уровнях (задача разузлования деталей).

PART STRUCTURE

Замечание. Значения, показанные в качестве примера на рис. 4.6, могут помочь вам более наглядно представить предложенную выше задачу. Следует отметить, что таблица PART_STRUCTURE демонстрирует, как информация о составе изделий (см. главу 1, раздел 1.3, подраздел "Сущности и связи") обычно представляется в реляционных системах.

MAJOR Р#	MINOR P#	QTY
PI	P2	CM
PI	P3	4
P2	P3	1
P2	P4	CO
P3	P5	9
P4	P5	8
P5	P6	3

Рис. 4.6. Таблица PART STRUCTURE (значения для примера)

Список литературы

4.1. Astrahan М.М., Lorie R.A. SEQUEL-XRM: A Relational System // Proc. ACM Pacific Regional Conference. — San Francisco, Calif., April, 1975.

Описан первый прототип реализации языка SEQUEL — самой ранней версии язы- ка SQL [4.8]. См. также документы [4.2], [4.3], которые выполняют аналогичную функцию для проекта System R.

4.2. Astrahan М.М. et al. System R: Relational Approach to Database Management // ACM TODS. — June, 1976. — 1, № 2.

Система System R была реализацией основного прототипа (ранней версии — языка SEQUEL/2, см. [4.8]) языка SQL. В статье описывается архитектура System R в том виде, в каком она была изначально запланирована; также см. [4.3].

4.3. Blasgen M.W. et al. System R: An Architectural Overview // IBM Sys. J. — February, 1981. —20, № 1.

Описывается архитектура System R на момент, когда система была полностью реа- лизована (ср. с [4.2]).

4.4. Stephen С. and Often G. SQL — The Standard Handbook. Maidenhead, UK: McGrow- Hill International, 1993.

"[Наша] задача ... представить справочное руководство, в котором объясняется и описывается [стандарт SQL/92, как он изначально был определен] в менее фор- мальном и легче воспринимаемом изложении по сравнению с самим стандартом" (цитата из введения к книге).

4.5. Celko J. SQL for Smarties: Advanced SQL Programming. San Francisco, Calif.: Morgan Kaufmann, 1995.

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

6. Eisenberg A. and Meltom J. SQLJ Part 0, Now Known as SQL/OLB (Object Language Bindings) // ACM SIGMOD Record.— Desember, 1998,— 27, M>4. См. также Clossman G. et al. Java and Relational Databases: SQLJ // Proc. ACM SIGMOD Int. Conf. on Management of Data. — Seattle, Wash., June, 1998.

7. Chamberlin D. Using the New DB2. — San Francisco, Calif.: Morgan Kaufmann, 1996. Интересное и всестороннее описание современного положения дел в отношении коммерческих SQL-продуктов, сделанное одним из двух основных разработчиков первоначальной версии языка SQL [4.8].

Замечание. В книге также обсуждаются "некоторые спорные решения", воплощен- ные в проекте языка SQL (прежде всего, решение о поддержке отсутствующих значений и решение о допущении дублирования строк). "Моя цель ... скорее, исто- рическая, чем стремление убедить. Я понимаю, что нули и дубликаты — это рели- гиозные вопросы... В большей части разработчики [языка SQL] были практиками, а не теоретиками, и такая ориентация отразилась на многих решениях [проекта]." Подобная позиция очень отличается от той, которую представляет автор! Нули и дубликаты — это научные вопросы, а не религиозные; они научно обсуждаются в этой книге в главах 18 и 5 соответственно. А относительно противопоставления

"практиками, а не теоретиками" подчеркнем, что мы категорически отвергаем су- ждение, что теория — это не практика. Мы уже констатировали нашу позицию (в разделе 4.5) относительно того, что теория, по крайней мере реляционная, по своей сути очень даже практична.

4.8. Chamberlin D.D. and Воусе R.F. SEQUEL: A Structured English Query Language // Proc. ACM SIGMOD Workshop on Data Description, Access, and Control. — Ann Arbor, Mich., May, 1974.

В статье впервые представлен язык SQL (или SEQUEL, как он назывался вначале; впоследствии название по юридическим причинам было изменено).

9. Chamberlin D.D. et al. SEQUEL/2: A Unified Approach to Data Definition, Manipulation, and Control // IBM J. R&D. — November, 1976. — 20, № 6; January, 1977. —21, № 1. Опыт реализации предыдущего прототипа языка SEQUEL, описанного в [4.1], и результаты проверок практичности, отчет о которых содержится в [8.28], привели к разработке новой версии языка, названной SEQUEL/2. Язык, поддерживаемый системой System R [4.2], [4.3], был, в основном, похож на SEQUEL/2 (с заметным отсутствием возможностей так называемых "утверждений" и "триггеров"; подроб- ности приводятся в главе 8), плюс некоторые расширения, появившиеся в резуль- тате учета опыта пользователей [4.10].

10. Chamberlin D.D. A Summary of User Experience with the SQL Data Sublanguage // Proc. Int. Conf. on Database.— Aberdeen, Scotland, July, 1980. (См. также IBM Research Report RJ2767. — April, 1980.)

В статье обсуждается ранний опыт использования системы System R и предлагают- ся некоторые дополнения языка SQL в свете этого опыта. Некоторые из этих до- полнений — операторы EXISTS, LIKE, PREPARE и EXECUTE — действительно были реализованы в окончательной версии System R.

Замечание. Подробности приводятся в главе 7 и приложении А, в которых обсуж- даются операторы EXISTS и LIKE соответственно.

4.11. Chamberlin D.D. et al. Support for Repetitive Transactions and Ad Hoc Queries in System R // ACM TODS. — March, 1981. — 6, № 1.

В статье приводятся некоторые результаты оценки производительности системы System R как в среде выполнения произвольных запросов, так и в среде выполнения стандартных транзакций. (Стандартные транзакции — это простое приложение, ко- торое имеет доступ лишь к небольшой части базы данных и перед выполнением предварительно компилируется. Это соответствует тому, что мы называли планируе- мым запросом в главе 2 в разделе 2.8) Измерения производились на компьютере IBM System 370 Model 158 в системе System R, выполняющейся под управлением опера- ционной системы VM. Эти измерения названы предварительными. Тем не менее с учетом этого предупреждения статья, кроме всего прочего, демонстрирует, что ком- пиляция почти всегда превосходит интерпретацию, даже для произвольных запросов, и что система, подобная System R, способна выполнять несколько стандартных тран- закций в секунду, если предусмотреть в базе данных соответствующие индексы. Статья достойна внимания, поскольку она была одной из первых статей, показав- ших несостоятельность заявлений (которые в то время можно было слышать очень часто), что "реляционные системы никогда не будут иметь хорошие эксплуатаци- онные качества". Безусловно, со времени этой первой публикации коммерческие

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

4.12. Chamberlin D.D. et al. A History and Evaluation of System R // CACM. — October, 1981. —24, № 10.

Описываются три основные фазы развития проекта System R (предварительный прототип, многопользовательский прототип и оценочный вариант); основное вни- мание уделяется технологиям компиляции и оптимизации, которые использовались в System R впервые. Частично эта статья пересекается с [4.13].

4.13. Chamberlin D.D., Gilbert A.M., Yost R.A. A History of System R and SQL / Data System // Proc. 7th Intern. Conf. on Very Large Data Bases. — Cannes, France, September, 1981.

Обсуждаются уроки, полученные в результате использования прототипа системы System R, а также описывается эволюция этого прототипа до первого семейства реляционных продуктов DB2 компании IBM, а именно — SQL/DS (переименованного впоследствии в DB2 for VM and VSE).

4.14. Date C.J. A Critique of the SQL Database Language // ACM SIGMOD Record. — November, 1984.— 14, №3. (Переиздано: C.J. Date. Relational Database: Selected Writings. — Reading, Mass.: Addison-Wesley, 1986.)

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

Замечание. Некоторые критические замечания из этой статьи не относятся к стан- дарту SQL/92.

4.15. Date C.J. What's Wrong with SQL? // C.J. Date. Relational Database Writings 1985- 1989. — Reading, Mass.: Addison-Wesley, 1990.

Обсуждаются некоторые недостатки языка SQL в дополнение к описанным в [4.14] под заголовками "Недостатки собственно языка SQL", "Недостатки стандарта SQL" и "Переносимость приложений".

Замечание. Некоторые критические замечания из этой статьи не относятся к стан- дарту SQL/92.

4.16. Date C.J. SQL Dos and Don'ts // C.J. Date. Relational Database Writings 1985-1989. — Reading, Mass.: Addison-Wesley, 1990.

В статье предложены некоторые практические советы по использованию языка SQL таким образом, чтобы избежать потенциальных ловушек, вызванных недос- татками этого языка, которые описаны в [4.14], [4.15], [4.18], и получить макси- мальные преимущества по продуктивности, переносимости, связности и т.п.

4.17. Date C.J. How We Missed the Relational Boat // Relational Database Writings 1991— 1994. — Reading, Mass.: Addison-Wesley, 1995.

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

4.18. Date C.J. Grivous Bodily Harm (в двух частях) // DBP&D. — June, 1998. — 11, № 5, 6. Fifty Ways to Query // Web-узел DBP&D ww.dbpd.com. — July, 1998.

Язык SQL чрезмерно избыточен в том смысле, что если не все, то большинство простых запросов могут быть выражены различными способами. В статьях это по- казано на примерах; также в них обсуждаются возможные последствия избыточно- сти языка SQL. В частности показано, что предложения GROUP BY, HAVING и пере- менные диапазонов можно с пользой исключить из языка, не потеряв при этом ни- каких функциональных возможностей (то же самое справедливо и для конструкции "IN <подзапрос>").

Замечание. Все перечисленные выше конструкции поясняются в главе 7 и прило- жении А.

4.19. Date C.J., Darwen Н. A Guide to the SQL Standard (4th edition). — Reading, Mass.: Addison-Wesley, 1997.

Полное руководство по стандарту SQL/92, включая средства CLI и PSM. В частно- сти, в приложении D приведены "многие аспекты стандарта, которые на сегодняш- ний день определены неадекватно или даже неверно".

Замечание. Публикации [4.4], [4.27] также являются руководствами по стандарту SQL/92.

4.20. Date CJ. and Colin J.W. A Guide to DB2 (4th edition). — Reading, Mass.: Addison-Wesley, 1993.

В книге дается обширный и детальный обзор СУБД DB2 компании IBM (по со- стоянию на 1993 год) и некоторых ее сопутствующих продуктов. СУБД DB2, как и SQL/DS, была основана на системе System R.

4.21. Fishman N. SQL du Jour. // DBP&D. — 1997. — 10, № 10.

Скучный обзор некоторых неточностей, найденных в SQL-продуктах, которые бы- ли объявлены как "поддерживающие стандарт SQL".

4.22. International Organization for Standardization (ISO): Database Language SQL. Docu- ment ISO/IEC 9075, 1992. Также доступно как American National Standards Institute (ANSI) Document ANSI X3.135-1992.

Оригинальное определение стандарта ISO/ANSI SQL/92 (также называемое среди знатоков ISO/IEC 9075 или просто ISO 9075). Первоначальный документ, состоя- щий из одной части, был со временем расширен до неограниченной серии отдель- ных частей под общим названием "Information Technolody— Database Languages — SQL". На время написания книги были определены следующие части (хотя, конечно, не все завершены). Часть 1. Структура (SQL/Framework) Часть 2. Основы (SQL/Foundation) Часть 3. Интерфейс на уровне вызова (SQL/CLI) Часть 4. Постоянные хранимые модули (SQL/PSM) Часть 5. Связь с базовым языком (SQL/Bindings) Часть 6. Специализация ХА (SQL/Transaction) Часть 7. Хронологические функции (SQL/Temporal) Часть 8. (Этой части нет)