6.31. Выбрать названия проектов, детали для которых поставляются поставщиком с номером S1.

6.32. Определить цвета деталей, поставляемых поставщиком с номером S1.

6.33. Установить номера деталей, поставляемых для какого-либо проекта в Лондоне.

6.34. Выбрать номера проектов, в которых используется по крайней мере одна деталь, имеющаяся у поставщика с номером S1.

6.35. Определить номера поставщиков по крайней мере одной детали, поставляемой по крайней мере одним поставщиком, который поставляет по крайней мере одну красную деталь.

6.36. Выбрать номера поставщиков со статусом, меньшим, чем статус поставщика с номером S1.

6.37. Определить номера проектов, находящихся в городе, который указан первым в алфавитном списке городов.

6.38. Выбрать номера проектов, для которых среднее количество поставляемых деталей с номером Р1 больше, чем наибольшее количество любых деталей, поставляемых для проекта с номером Л.

6.39. Определить номера поставщиков детали с номером Р1 для некоторого проекта в количестве, большем среднего количества деталей с номером Р1 в поставках для этого проекта.

6.40. Найти номера проектов, для которых поставщиками из Лондона не поставляются красные детали.

6.41. Определить номера проектов, детали для которых полностью поставляются поставщиком с номером S1.

6.42. Определить номера деталей, поставляемых для лондонских проектов.

6.43. Установить номера поставщиков одной и той же детали для всех проектов.

6.44. Выбрать номера проектов, в состав которых входят как минимум все типы деталей, поставляемые поставщиком с номером S1.

6.45. Установить все города, в которых находится по крайней мере один поставщик, одна деталь или один проект.

6.46. Определить номера деталей, поставляемых либо лондонским поставщиком, либо для лондонского проекта.

6.47. Найти все пары типа номер поставщика- номер детали , причем только такие, в которых данный поставщик не поставляет данную деталь.

6.48. Выбрать все пары номеров поставщиков (скажем, Sx и Sy), причем такие, что оба эти поставщика поставляют в точности одно и то же множество деталей. (Выражаю благодарность г-ну Фатма Мили (Fatma Mill) из Оклендского университета (Рочестер, Мичиган), предложившему эту задачу.)

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

6.50. Получить разгруппированную версию отношения из предыдущего упражнения.

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

6.1. Codd. E.F. Relational Completeness of Data Base Sublanguages in Randall J. Rustin (ed.) Data Base Systems, Courant Computer Science Symposia Series 6. - Englewood Cliffs, N.J.: Prentice-Hall, 1972.

В этой статье Кодд впервые дает формальное определение операторов исходной версии реляционной алгебры (определения операторов приводились также в [5.5], однако они были неполными и менее формальными).

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

Другие комментарии к этой статье можно найти в главе 7, в частности в разделе 7.4. Замечание. В [3.3] описана так называемая алгебра А с сокрашенным набором инструкций , которая позволяет систематически определять более сложные операторы в виде определенной комбинации небольшого числа примитивных операторов. Фактически в [3.3] показано, что вся функциональность оригинальной алгебры Кодда может быть получена с помошью всего лишь двух примитивных операторов - remove и nor.

6.2. Darven Н. (writing as Andrew Warden). Adventures in Relationland Date C.J. Relational Database Writings 1985-1989. - Reading, Mass.: Addison-Wesley, 1990.

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

1. The Naming of Columns (Наименования столбцов)

2. In Praise of Marriage (O пользе супружества)

3. The Keys of the Kingdom (Ключи от королевства)

4. Chivalry (Рыцарство)

5. A Constant Friend (Верный друг)

6. TableDee and TableDum (Таблица Чертовка и ТаблицаПустышка)

7. Into the Unknown (B неведомое)

6.3. Darwen H. and Date C.J. Into the Great Divide Darwen H. and Date C.J. Relational Database Writings 1989-1991. - Reading, Mass.: Addison-Wesley, 1992.

В данной статье анализируется оригинальный оператор деления, определенный Коддом в [6.1], а также обобшение этого оператора, сделанное Холлом (Hall), Хитчкоком (Hitchcock) и Тоддом (Todd) [6.10], которое в отличие от определенного Коддом оригинального оператора деления позволяет делить любые отношения на любые другие отношения. (Оригинальный оператор деления Кодда был определен только для таких делимых и делителей, заголовок делителя которых является подмножеством заголовка делимого.) В этой статье описаны трудности, возни-

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

Замечание. Как видно из синтаксиса языка Tutorial D, эти два оператора различны. В частности, оператор Great Divide представляет собой (к сожалению) не вполне совместимое сверху вниз расширение оператора Small Divide. В данной статье также предлагается не называть переделанные операторы делением (см. упр. 6.5). Для дальнейших ссылок приведем определение оригинального оператора деления Кодда. Пусть даны отношения А и В с заголовками {X,Y} и {Y} соответственно. (X и Y могут быть составными.) Тогда результатом вычисления выражения А DIVIDEBY В будет отношение с заголовком {X} и телом, состоящим из всех кортежей {Х:х}, таких, что кортеж {Х:х, Y:y} содержится в теле отношения А для всех кортежей {Y:y}, содержащихся в отношении В. Другими словами, результат состоит из тех значений атрибута X из отношения А, для которых соответствующие значения атрибута Y (в отношении А) содержат все значения атрибута Y в отношении В.

6.4. C.J. Date. Quota Queries (в трех частях) Date С.J., Darven В., and McGoveran D. Relational Database Writings 1994-1997. - Reading, Mass.: Addison-Wesley, 1998. Квота-запрос - это запрос, в котором указывается желаемый предел для кардинальности результирующего отношения. Например, это может быть запрос Найти три самые тяжелые детали . На языке Tutorial D его можно записать следующим образом.

Р QUOTA ( 3, DESC WEIGHT )

Это выражение является сокращенной записью следующего оператора. ( ( EXTEND Р

ADD COUNT ( ( Р RENAME WEIGHT AS WT ) WHERE WT > WEIGHT ) AS HEAVIER ) WHERE HEAVIER < 3 ) { ALL BUT HEAVIER }

(Здесь имена WT и t HEAVIER могут быть произвольными.) Если взять за основу наши обычные данные, то результат будет состоять из деталей с номерами Р2, РЗ и Рб.

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

6.5. Carey M.J. and Kossmann D. On Saying Enough Already in SQL Proc. 1997 Int. Conf. On Management of Data. - Tucson, Ariz., May, 1997.

Еще одна работа, посвященная квота-запросам. В отличие от [6.4], здесь основное внимание уделяется вопросам реализации, а не моделирования. Запрос Найти три самые тяжелые детали в контексте этой статьи будет выглядеть так.

SELECT * FROM Р

ORDER BY WEIGHT DESC STOP AFTER 3;