    Глава з 

    Введение в реляционные базы данных 

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

    3.2. Реляционные системы 

    Реляционная система управления базами данных (или просто реляционная 
система) — это такая система, в которой, выполняются как минимум два условия. 
    1.  Данные воспринимаются пользователем как таблицы (и никак иначе). 
    2.  В распоряжении пользователя имеются операторы (например, для выборки 
данных), которые генерируют новые таблицы из старых и среди которых, по 
крайней мере, есть операторы SELECT (также известный как RESTRICT), PROJECT и JOIN. 
    Хотя это определение все еще довольно поверхностно, оно точнее данного в 
главе 1. 
    На рис. 3.1 показан простой пример реляционной базы данных отделов и 
служащих. Как видите, эта база данных действительно "воспринимается как 
таблицы" (мы полагаем, что значение этих таблиц не требует пояснений). 

    DEPT 

    DEPT#       DNAME			BUDGET 
    Dl         Marketing		10M 
    D2         Development		12M 
    D3         Research			5M 

    ЕМР	

    EMP#	ENAME		DEPT#		SMARY 
    El	Lopez		Dl		40K 
    E2	Cheng		Dl		42K 
    E3	Finzi		D2		30K 
    E4	Saito		D2		35K 
    
    
    Рис. 3.1. База данных отделов и служащих (значения взяты для примера) 

    На рис. 3.2 показаны некоторые примеры операций SELECT, PROJECT и JOIN для 
этой базы данных. Ниже приведены (очень нестрогие!) определения этих операций. 
    •  Операция SELECT (или RESTRICT) предназначена для извлечения 
определенных строк из таблицы. 

    Глава 3. Введение в реляционные базы данных 57 

    •  Операция PROJECT предназначена для извлечения определенных столбцов из таблицы. 
    •  Операция JOIN предназначена для соединения двух таблиц на основе общих 
значений в общих столбцах. 

    SELECT (RESTRICT) :	Результат: Выборка строк из DEPT, где BUDGET > 8М 

    DEPT*	DNAME	BUDGET 
    Dl	Marketing	10M 
    D2	Development	12M 

    PROJECT: 
    Извлечение столбцов DEPT#, BUDGET 

    Результат: 

    DEPTff	BUDGET 
    D1	ЮМ 
    D2	12М 
    D3	5М 

    JOIN: 
    Соединение DEPT и ЕМР на основе столбца DEPT# Результат: 

    DEPT#	DNAME		BUDGET	EMP#	ENAME	SALARY 
    Dl	Marketing	10M		El	Lopez	40K 
    Dl	Marketing	10M		E2	Cheng	42K 
    D2	Development	12M		E3	Finzi	30K 
    D2	Development	12M		E4	Saito	35K 

    Рис. 3.2. Примеры операций SELECT, PROJECT и JOIN 

    Из трех приведенных примеров комментарии, по-видимому, необходимы только к 
операции JOIN. Прежде всего, обратите внимание на то, что в таблицах DEPT и 
ЕМР есть общий столбец DEPT#, а следовательно, эти таблицы можно соединить на 
основе общих значений в этом столбце. 
    Это значит, что строка таблицы DEPT соединяется со строкой таблицы ЕМР, 
при этом образуется более длинная строка, но это происходит тогда и только 
тогда, когда у этих двух строк общее значение поля DEPT#. Например, следующие 
строки таблиц DEPT и ЕМР 

    DEPT#	DNAME		BUDGET 
    Dl	Marketing	10M 

    ЕМР#	ENAME	DEPT#	SALARY 
    Е1	Lopez	Dl	40K 
    (названия столбцов приведены для наглядности) можно соединить в 
результирующую строку 

    DEPT#	DNAME		BUDGET	EMP#	ENAME	SALARY 
    Dl	Marketing	ЮМ		El	Lopez	4 OK 

    (так как в общем столбце у этих строк одно и то же значение D1). Общий 
результат состоит из множества всех таких соединенных строк. Обратите 
внимание, что столбец DEPT# в каждой результирующей строке встречается один 
раз, а не два. Обратите также внимание на то, что поскольку в таблице ЕМР нет 
значения D3 в поле DEPT# (т.е. нет служащих, работающих в отделе D3), то нет и 
результирующих строк со значением D3 в этом поле, хотя и есть строка со 
значением D3 в таблице DEPT. 
    Необходимо отметить один важный момент, очевидный из рис. 3.2: результат 
каждой из трех операций — это еще одна таблица. Это реляционное свойство 
замкнутости. Оно имеет очень большое значение главным образом потому, что ре-

    58 Часть I. Основные понятия 

зультатом операции является объект того же рода, что и объект, над которым 
производилась операция, — а именно таблица, А это значит, что над результатом 
операции можно вновь проделать какую-либо другую операцию. Например, можно 
выбрать столбцы (операция PROJECT) из соединенной (операция JOIN) таблицы или 
соединить два результата операции SELECT и т.д. Другими словами, можно 
использовать вложенные выражения, т.е. выражения, в которых операнды 
представлены выражениями, а не простыми именами таблиц. В данной и последующих 
главах вы увидите, что этот факт имеет, в свою очередь, множество важных следствий. 
    Замечание. Отмечая, что результатом каждой операции является таблица, мы 
имеем в виду, что это таблица с концептуальной точки зрения. Мы не хотим 
сказать, что система обязательно должна полностью материализовать результат 
каждой отдельной операции. Предположим, например, что нам понадобилось выбрать 
строки (операция SELECT) из соединения таблиц. Тогда, как только данная строка 
соединения будет сформирована, система может немедленно применять ограничение 
к такой строке, чтобы проверить, будет ли она принадлежать конечному 
результату, и немедленно отбросить ее, если нет. Иначе говоря, промежуточный 
результат, который выводится операцией соединения, может никогда и не будет 
существовать в виде полной материализованной таблицы как таковой. На практике, 
как правило, система весьма упорно пытается не материализовать полностью 
промежуточные результаты по вполне понятной причине — чтобы не терять производительность. 
    Другой момент, который тоже недвусмысленно проиллюстрирован на рис. 3.2, 
заключается в том, что операции применяются сразу ко всему множеству строк, а 
не к отдельной строке за один раз, т.е. операндами и результатами являются не 
отдельные строки, а целые таблицы, которые содержат множество строк. Например, 
операция JOIN на рис. 3.2 применяется к двум таблицам из трех и четырех строк 
соответственно, а возвращает в результате таблицу из четырех строк. Такая 
возможность обработки множества — главная отличительная характеристика 
реляционных систем. И наоборот, операционные и нереляционные системы обычно за 
одно обращение выполняют обработку на уровне строки или записи. 
    Давайте вновь вернемся к рис. 3.1. Есть несколько замечаний, которые можно 
сделать, используя пример базы данных на этом рисунке. 
    •   Во-первых, обратите внимание, что определение "реляционной системы" 
требует, чтобы база данных воспринималась пользователем только как таблицы. 
Таблицы в реляционной системе являются логическими, а не физическими 
структурами. На самом деле на физическом уровне система может использовать 
любую или все применяемые структуры памяти — последовательные файлы, 
индексирование, хэширование, цепочки указателей, сжатие и т.п. — лишь бы 
обеспечивалась возможность отображать эти структуры в таблицы на логическом 
уровне. Это можно сказать и по-другому: таблицы представляют абстракцию 
способа физического хранения данных, в которой множество деталей на уровне 
памяти — размещение хранимой записи, последовательность хранимых записей, 
кодировка хранимых данных, префиксы хранимых записей, хранимые структуры 
доступа, такие как индексы, и т.д. — скрыто от пользователя. 
    В данном случае термин "логическая структура" в терминологии ANSI/SPARC 
относится как к концептуальному, так и к .внешнему уровню. Дело в том, что, 
как объяснялось в главе 2, концептуальный и внешний уровни в реляционной 
системе являются реляционными, а внутренний, или физический уровень — нет. На 
самом деле реляционная теория ничего не может сказать о внутреннем уровне 
вообще; она, как уже отмечалось, "заботится" о том, как база данных 
представлена пользователю. 
    •  Во-вторых, у реляционных баз данных, подобных изображенной на рис. 3,1, 
есть одно замечательное свойство: все информационное содержимое базы данных 
представлено одним и только одним способом, а именно: явным заданием значений 
данных. Этот метод представления (задание явным образом значений позиций 

    Глава 3. Введение в реляционные базы данных	59 

    столбцов в строках таблицы) единственно возможный для реляционных баз 
данных. В частности, нет никаких указателей, связывающих одну таблицу с 
другой. Например, существует связь между строкой D1 в таблице DEPT и строкой 
Е1 в таблице ЕМР, так как служащий Е1 работает в отделе D1; но эта информация 
представлена не указателем, а появлением значения D1 в столбце DEPT# строки Е1 
в таблице ЕМР. А в нереляционных системах, напротив, такая информация 
представлена неким указателем, который пользователь видит явно. 
    Замечание. Когда мы говорим, что в реляционной системе нет указателей, мы 
не имеем в виду, что в ней не может быть указателей на физическом уровне — 
наоборот, они, конечно, могут быть на этом уровне и в действительности 
наверняка есть. Но, как уже объяснялось, такие детали физического хранения в 
реляционных системах скрываются от пользователя. 
    И наконец, обратите внимание на то, что все значения данных атомарные (или 
скалярные). Это значит, что в каждой таблице в позиции на пересечении столбца 
и строки всегда находится только одно значение и никак не группа из нескольких 
значений. Поэтому, например, в таблице ЕМР (рассматриваются только столбцы, 
для наглядности размещенные слева направо) мы имеем 

    DEPT*	ЕМР* 

    D1	Е1 
    D1	Е2 

    вместо 

    DEPT#	ЕМР# 
    D1	Е1,Е2 

    Столбец ЕМР# во второй версии таблицы — пример того, что обычно называют 
группой повторения. Группа повторения — это столбец или комбинация столбцов, 
которая содержит несколько значений данных в каждой строке (в общем случае 
разное количество значений в разных строках). В реляционных базах данных 
группы повторения недопустимы; а значит, вторая версия таблицы в реляционной 
системе недопустима. (Причина такого явного ограничения — упрощение системы.) 
    В заключение отметим, что данное в начале раздела определение "реляционной 
системы" представляет собой лишь минимальное определение (оно взято из [3.1] и 
в основном использовалось в начале 1980-х). Конечно, в этом разделе можно и 
нужно было бы рассказать о реляционных системах значительно больше. В 
частности, заметьте, что реляционная модель — это нечто большее, чем просто 
"таблицы плюс операции SELECT, PROJECT и JOIN". 

    3.3. Замечание относительно терминологии 

    Если предположить, что реляционная база данных — это, по существу, просто 
база данных, в которой данные представлены в виде таблиц (а это так и есть), 
то возникает резонный вопрос: почему же мы называем такую базу данных именно 
реляционной? Почему не табличной? Ответ прост: термин "relation" (отношение) — 
это математическое название таблицы (точнее, определенного вида таблиц; 
подробнее это описано в главе 4). Например, можно сказать, что база данных 
отделов и служащих, показанная на рис. 3.1, содержит два отношения. (Не 
путайте отношения, отождествляемые с таблицами, с отношениями между объектами, 
которые можно отождествить с объектами. Свойства отношений в последнем смысле, 
как и свойства объектов, заносят в таблицы.) 

    60 Часть I. Основные понятия 

    В неформальном контексте термины "отношение" и "таблица" принято считать 
синонимами; на практике в таком контексте термин "таблица" используется 
гораздо чаще, чем термин "отношение". На обсуждении этого вопроса стоит 
немного задержаться, чтобы выяснить, почему все-таки термин "таблица" 
поставлен на первое место. Вкратце это объясняется следующим. 
    •  Как уже отмечалось, реляционные системы основаны на модели, которая 
называется реляционной моделью данных. Реляционная модель, в свою очередь, — 
это абстрактная теория данных, основанная на некоторых положениях математики 
(в основном теории множеств и предикативной логики). 
    •  Принципы реляционной модели были изначально заложены в 1969-70-х годах 
доктором Е.Ф. Коддом (E.F. Codd), в то время исследователем, работавшим в 
корпорации IBM. В конце 1968 года Кодд, математик по образованию, впервые 
осознал, что математические дисциплины можно использовать, чтобы привнести в 
область управления базами данных строгие принципы и точность; именно таких 
качеств и не доставало этой области в то время. Идеи Кодда подробно 
рассмотрены в ставшей классической статье "A Relational Model of Data for 
Large Shared Data Banks" (CM. [4.1] в главе 4). 
    • С того времени эти идеи стали общепринятыми и оказали весьма 
существенное влияние на все аспекты технологии баз данных, а также и на другие 
области, такие как искусственный интеллект, обработка естественных языков и 
разработка аппаратных систем. 
    Сейчас в реляционной модели, такой как изначально сформулированная Коддом, 
умышленно применяют определенные термины, например сам термин "отношение", 
который не был распространен в то время, хотя такое понятие иногда 
использовалось. Проблема заключалась в том, что многие распространенные 
термины были очень нечеткими — им не хватало точности, необходимой для такой 
формальной теории, которую предложил Кодд. 
    • Пример. Рассмотрим термин "запись". В разное время этот термин мог 
означать экземпляр записи или тип записи; запись в стиле языка COBOL (в 
которой разрешены группы повторения) или плоские записи (в которых не 
разрешены группы повторения); логические записи или физические записи; 
хранимые записи или виртуальные записи; а возможно, и еще что-то. 
    Поэтому в формальной реляционной модели не используется термин "запись" 
вообще; вместо него используется термин "кортеж", точное определение которого 
дал Кодд, когда впервые ввел его. Мы не станем приводить здесь это 
определение, а лишь отметим, что термин "кортеж" приблизительно соответствует 
понятию экземпляра плоской записи (так же, как термин "отношение" 
приблизительно соответствует понятию таблицы). При дальнейшем изучении более 
формальных аспектов реляционных систем будет использоваться более формальная 
терминология, в этой же главе мы будем придерживаться не формальных терминов, 
а более знакомых, таких как "таблица", "строка" и "столбец". 

    3.4. Реляционная модель 

    Так что же такое реляционная модель? Достаточно точно ее характеризует 
следующее определение: реляционная модель — это способ рассмотрения данных, 
т.е. предписание для способа представления данных (посредством таблиц) и для 
способа работы с таким представлением (посредством операторов, таких как 
JOIN). Или точнее, реляционная модель связана с тремя аспектами данных: 
структурой, целостностью и обработкой данных. Вопросы, связанные со структурой 
и обработкой данных, уже были проиллюстрированы. Чтобы рассмотреть целостность (заметьте, 

    Глава 3. Введение в реляционные базы данных	61 

    весьма поверхностно), мы еще раз воспользуемся базой данных отделов и 
сотрудников, приведенной на рис. 3.1. По всей вероятности, такая база данных 
могла бы быть примером для многих правил целостности. Существуют определенные 
правила, которые должны соблюдаться в базе данных, если она отвечает 
требованиям реляционной модели. 
    1. Каждая строка в таблице DEPT должна включать уникальное значение DEPT#; 
также и каждая строка в таблице ЕМР должна включать уникальное значение ЕМР #. 
    2.  Каждое значение DEPT# в таблице ЕМР должно существовать как значение 
DEPT# в таблице DEPT (для отражения того факта, что каждый служащий должен 
быть приписан к существующему отделу). 
    Столбцы DEPT# в таблице DEPT и ЕМР# в таблице ЕМР являются первичными 
ключами для соответствующих таблиц. Столбец DEPT# в таблице ЕМР является 
внешним ключом, ссылающимся на первичный ключ таблицы DEPT. 
    Замечание. Читатель уже, возможно, заметил, что первичные ключи таблицы 
указаны на рисунках двойной линией, проведенной под наименованием ключа (см., 
например, рис. 3.1). Мы будем следовать этому соглашению на протяжении всей книги. 
    Сейчас уместно сделать предупреждение. Реляционная модель, как уже 
отмечалось, это теория. Обратите особое внимание, однако, что для системы нет 
необходимости поддерживать такую теорию полностью, чтобы квалифицировать эту 
систему как реляционную в соответствии с определением. В действительности, 
насколько известно, в настоящее время на рынке не существует продукта, который 
бы поддерживал все до единого требования этой теории. Это отнюдь не значит, 
что некоторые аспекты этой теории не важны; как раз наоборот, важна каждая 
деталь этой теории, причем по действительно практическим причинам. И в самом 
деле, нельзя делать акцент на том, что это просто "теория ради теории"; 
скорее, главное назначение этой теории— обеспечить базу для построения систем, 
которые на 100% практичны. Но, как это ни печально, поставщики еще реально не 
подошли к осуществлению этой теории во всей ее полноте. И как следствие, 
реляционные продукты на сегодняшний день в той или иной степени неполно 
реализуют возможности реляционной технологии. 
    Замечание. Отмечая, что каждая деталь теории важна, мы не имеем в виду, 
что они важны в равной степени. Дело в том, что некоторые аспекты теории не 
так широко признаны, как другие; в действительности существуют вопросы, такие 
как, например, обработка отсутствующей информации, которые до сих пор являются 
предметом разногласий. Подробное обсуждение таких вопросов выходит за рамки 
этой главы и приводится в следующих частях книги. 

    3.5. Оптимизация 

    Как уже объяснялось выше, реляционные операции, такие как SELECT, PROJECT 
и JOIN, выполняются на уровне множеств. Поэтому реляционные языки, такие как 
SQL, часто называют непроцедурными, так как пользователь указывает, что 
делать, а не как делать, т.е. пользователь говорит, что ему нужно, без 
указания процедуры получения результата. Процесс "навигации" по хранимой базе 
данных для удовлетворения пользовательского запроса выполняется системой 
автоматически, а не пользователем вручную. Поэтому реляционные системы иногда 
называют системами автоматической навигации. В нереляционных системах за 
навигацию по базе данных в основном несет ответственность пользователь. На 
рис. 3.3 приведена яркая иллюстрация преимуществ автоматической навигации— 
оператору SQL INSERT противопоставлен код, выполняющий навигацию "вручную"; 
подобный код, возможно, должен написать пользователь нереляционной системы для 
получения того же результата. 

    62	Часть I. Основные понятия 

    Несмотря на эти замечания, следует отметить, что "непроцедурный" — это 
хотя и общепринятый, но не совсем точный термин, потому что процедурный и 
непроцедурный -— понятия относительные. Можно лишь с уверенностью сказать, что 
язык А более (или менее) процедурный, чем язык Б. Поэтому точнее будет 
сказать, что реляционные языки, такие как SQL, принадлежат более высокому 
уровню абстракции, чем языки программирования, такие как С или COBOL (или 
подъязыки данных, обычно принадлежащие нереляционным СУБД; убедитесь в этом 
сами — см. рис. 3.3) 

    INSERT INTO SP ( Stt, P#, QTY ) ______VALUES ( 'S4', 'P3', 1000 ) 

    MOVE 'S4' TO S# IN S 
    FIND CALC S 
    ACCEPT S-SP-ADDR FROM S-SP CURRENCY 
    FIND LAST SP WITHIN S-SP 
    while SP found PERFORM 
    ACCEPT S-SP-ADDR FROM S-SP CURRENCY 
    FIND CWNER WITHIN P-SP 
    GET P 
    IF P# IN P < 'P3' leave loop 
    END-IF 
    FIND PRIOR SP WITHIN S-SP END-PERFORM MOVE 'P3' TO P# IN P FIND CALC P 
    ACCEPT P-SP-ADDR FROM P-SP CURRENCY FIND LAST SP WITHIN P-SP while SP 
found PERFORM 
    ACCEPT P-SP-ADDR FROM P-SP CURRENCY 
    FIND CWNER WITHIN S-SP 
    GET S 
    IF S# IN S < 'S4' leave loop 
    END-IF 
    FIND PRIOR SP WITHIN P-SP END-PERFORM MOVE 1000 TO QTY IN SP FIND DB-KEY 
IS S-SP-ADDR FIND DB-KEY IS P-SP-ADDR STORE SP 
    CONNECT SP TO S-SP CONNECT SP TO P-SP 

    Рис. 3.3, Автоматическая и ручная навигация 

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

    RESULT   :=   {  ЕМР WHERE ЕМР# =   'Е4'   )    [   SALARY  ]   ; 

    Пояснение. Выражение в первых скобках (ЕМР WHERE ...) означает запрос 
выборки строк из таблицы ЕМР, а именно строки, в которой значение ЕМР# равно 
Е4. Название столбца в квадратных скобках (SALARY) означает запрос выборки 
столбцов (также называемый проекцией) из результата выборки строк, а именно 
столбца SALARY. И наконец, оператор присвоения (:=) означает запрос присвоения 
результата выборки столбцов таблице RESULT. Следовательно, после выполнения 
запроса RESULT — это таблица из одной строки и одного столбца, содержащая 
зарплату служащего Е4. (Здесь использован синтаксис реляционных операций, 
который подробно будет описан в следующих главах. Обратите также внимание, что 
в данном случае в явном виде используется реляционное свойство замкнутости: мы 
написали вложенное выражение, в котором результат выборки строк — это входные 
данные для выборки столбцов.) 

    Глава 3. Введение в реляционные базы данных	63 

    Даже в этом простом примере существует по крайней мере два способа 
выполнения поиска необходимых данных. 
    1.  Последовательный физический просмотр таблицы ЕМР (хранимой версии), 
пока не будет найдена требуемая запись. 
    2.  Если есть индекс для столбца ЕМР# (в хранимой версии) таблицы 
(который, вероятно, действительно существует, поскольку этот столбец является 
первичным ключом, а большинство систем фактически требует созданил индекса по 
первичному ключу), то переход с помощью этого индекса непосредственно к данным 
служащего Е4. 
    Оптимизатор выберет, какую из этих двух стратегий применить. В общем 
случае для реализации любого определенного отдельного реляционного запроса 
оптимизатор будет делать выбор стратегии на основе соображений, подобных следующим: 
    •  на какие таблицы есть ссылки в запросе (может быть несколько ссылок, 
если, например, используются какие-то соединения); 
    •	насколько велики эти таблицы; 
    •	какие индексы созданы; 
    •	как выбраны эти индексы; 
    •	как физически группируются данные на диске; 
    •	какие реляционные операции используются и т.д. 
    Поэтому повторяем — пользователь указывает в запросе, какие данные 
требуются для него, а не как получить эти данные; стратегия доступа к данным 
выбирается оптимизатором (автоматическая навигация). Поэтому пользователи и 
пользовательские программы обретают независимость от таких стратегий доступа, 
которая, конечно, необходима, если мы хотим достичь независимости данных. 
    Более подробные сведения об оптимизаторе можно получить в главе 18. 

    3.6. Каталог 

    Как отмечалось в главе 2, каждая СУБД должна обеспечивать функцию 
каталога, или словаря. Каталог, между прочим, размещается там, где сохраняются 
различные схемы (внешние, концептуальные, внутренние) и все, что относится к 
отображениям (внешнее-концептуальное, концептуальное-внутреннее). Иначе 
говоря, каталог содержит детальную информацию (иногда называемую 
дескрипторами), касающуюся различных объектов, которые имеют значение для 
самой системы. Примерами таких объектов могут служить таблицы, индексы, 
правила целостности, правила безопасности и т.д. Информация дескриптора 
необходима для обеспечения правильной работы системы. Например, оптимизатор 
использует информацию каталога об индексах, а также другую информацию, чтобы 
определиться, каким образом выполнить запрос пользователя. Подобно этому, 
подсистема безопасности использует информацию каталога о пользователях и 
правилах безопасности, чтобы разрешить (или отказать) запросу первоочередное выполнение. 
    Прекрасным свойством реляционных систем в настоящее время является то, что 
каталог сам состоит из таблиц (точнее, системных таблиц, названных так для 
отличия от обычных пользовательских). В результате пользователь может 
обращаться к каталогу так же, как к своим данным. Например, в каталоге обычно 
содержатся системные таблицы TABLES и COLUMNS, назначение которых — описание 
известных системе таблиц и столбцов этих таблиц. (Мы говорим "обычно", потому 
что каталоги в различных системах разные, так как большая доля информации 
каталога является особенной для системы.) Для базы данных отделов и служащих 
таблицы TABLES и COLUMNS могут схематически выглядеть так, как показано на 
рис. 3.4. 

    64	Часть I. Основные понятия 

    Замечание. Точнее говоря, таблицы TABLES и COLUMNS описывают известные 
системе именованные таблицы, в противоположность неименованным таблицам, 
которые являются результатом какoгo-либо реляционного выражения. Обратите 
также внимание на то, что категория "именованные таблицы" включает таблицы 
каталога, т.е. каталог описывает сам себя. Однако на рис. 3.4 сам каталог не 
показан в таблицах. 
    
    TABLES	TABNAME	COLCOUNT	ROWCONT 
    		DEPT		3		3 
    		ЕМР		4		4 
    
    COLUMNS	TABNAME	СОLNAМЕ 
		    DEPT		DEPT# 
		    DEPT		DNAME 
		    DEPT		BUDGET 
		    ЕМР		ЕМР#	..... 
		    ЕМР		ENAME	..... 
		    ЕМР		DEPT# 
		    ЕМР		SALARY 

    Рис. 3.4. Каталог базы данных отделов и служащих (изображен схематически) 

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

    ( COLUMNS WHERE TABNAME = 'DEPT' ) [ COLNAME ] 

    Замечание. Если бы нам понадобилось сохранить результат в более постоянном 
виде, мы могли бы присвоить его другой таблице, скажем, таблице RESULT, как 
было показано в примере выше, но мы будем опускать этот шаг присвоения в 
большинстве наших примеров (как в этой, так и в последующих главах). 
    Вот еще один пример. Необходимо узнать, в каких таблицах есть столбец ЕМР#: 

    ( COLUMNS WHERE COLNAME = 'ЕМР#' ) [ TABNAME ] 

    Упражнение для самопроверки. Каким будет результат выполнения следующего выражения: 

    ( ( TABLES JOIN COLUMNS ) 
    WHERE COLCOUNT < 5 ) [ TABNAME, COLNAME ] 


    3.7. Базовые таблицы и представления 

    Мы уже видели, что из данного множества таблиц, таких как DEPT и ЕМР, 
реляционные выражения позволяют получить множество других, например путем 
соединения двух таблиц. Пришло время ввести еще несколько новых терминов. 
Исходные (данные) таблицы называются базовыми таблицами; а таблицы, полученные 
из них путем выполнения каких-либо реляционных выражений, называются 
производными таблицами. Поэтому базовые таблицы существуют независимо, в то 
время как производные таблицы зависят от базовых. Следовательно, если быть 
более точным, производная таблица — это такая таблица, которая определяется в 
терминах других таблиц и, в конечном счете, в терминах базовых таблиц, а 
базовая таблица — это такая таблица, которая не является производной. 

Глава 3. 
Введение в реляционные базы данных 

    65 3 Введение в системы баз данных 

    Реляционные системы, очевидно, должны предоставлять средства для создания 
в первую очередь базовых таблиц. В SQL, например, эта функция выполняется 
оператором CREATE TABLE (здесь TABLE используется в узком смысле, как базовая 
таблица). Базовые таблицы, конечно, должны быть именованными (т.е. их имена 
указываются в операторах создания). Большинство производных таблиц, наоборот, 
неименованные. Однако реляционные системы обычно поддерживают один 
определенный вид производных таблиц, называемый представлением, которое имеет 
имя. Таким образом, представление — это именованная таблица, которая, в 
отличие от базовой, не может существовать сама по себе, а определяется в 
терминах одной или нескольких именованных таблиц (базовых таблиц или других представлений). 
    Например, инструкцию 

    CREATE VIEW TOPEMPS AS ( EMP WHERE SALARY > 33K ) [ EMP#, ENAME, SALARY ] ; 

    можно использовать для определения представления TOPEMPS. Когда эта 
инструкция выполняется, выражение, следующее за ключевым словом AS и 
фактически определяющее представление, не вычисляется, а просто "запоминается" 
системой (обычно путем сохранения в каталоге под указанным именем TOPEMPS). 
Однако для пользователя это теперь такая же реальная таблица базы данных с 
именем TOPEMPS, со строками и столбцами, как и показанная на рис. 3.5, но 
только в незатемненных участках. Иными словами, имя TOPEMPS обозначает 
виртуальную таблицу, т.е. таблицу, которая была бы результатом, если бы 
выражение, определяющее представление, было на самом деле вычислено. 

    TOPEMPS 

    ЕМР#	ENAME	DEPT#	SALARY 
    Е1	Lopez	Dl	40K 
    Е2	Cheng	Dl	42K 
    ЕЗ	Finzi	D2	30K 
    Е4	Saito	D2	35K 

    Рис. 3.5. TOPEMPS как представление базовой таблицы ЕМР (незатемненные участки) 

    Однако будьте внимательны: отмечая, что имя TOPEMPS обозначает "таблицу, 
которая была бы результатом, если бы выражение, определяющее представление, 
было на самом деле вычислено", мы вовсе не хотим сказать, что она ссылается на 
отдельную копию данных, т.е. мы не имеем в виду, что выражение, определяющее 
представление, на самом деле вычисляется. Наоборот, представление — это просто 
"окно" в основной таблице ЕМР. Более того, естественно, что любые изменения в 
основной таблице будут автоматически и немедленно видны через такое "окно" 
(конечно, если эти изменения относятся к незатемненной части таблицы ЕМР); 
аналогично, изменения в TOPEMPS будут автоматически и немедленно применены к 
реальной таблице ЕМР и, следовательно, будут видны через "окно". 
    Ниже показан пример запроса, использующего представление TOPEMPS: 

    ( TOPEMPS WHERE SALARY < 42K ) [ EMP#, SALARY ] 

    Результат будет выглядеть подобно следующему: 

    ЕМР#	SALARY 
    Е1	40К 
    Е4	35К 

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

    ( TOPEMPS WHERE SALARY < 42К ) [ ЕМР#, SALARY ] 

    модифицируется системой к виду 

    ((( ЕМР WHERE SALARY > ЗЗК ) [ ЕМР#, ENAME, SALARY ] ) WHERE SALARY < 42K 
) [ EMP#, SALARY ] 

    66 Часть I. Основные понятия 

    После определенного количества перегруппировок это выражение упрощается и 
принимает следующий вид: 

    ( ЕМР WHERE SALARY > ЗЗК AND SALARY < 42К ) [ ЕМР#, SALARY ] 

    А вычисление этого выражения приводит к результату, показанному ранее. 
Иными словами, первоначальная операция над представлением практически 
конвертируется в эквивалентную операцию над соответствующей базовой таблицей. 
Затем такой эквивалент операции выполняется обычным способом (точнее, 
оптимизируется и выполняется обычным способом). 
    Теперь TOPEMPS — очень простое представление, состоящее, как обычно, из 
подмножества строк и столбцов основной базовой таблицы. Однако в принципе 
определение представления может быть произвольной сложности. Например, вот 
представление, определение которого включает соединение двух основных базовых таблиц: 

    CREATE VIEW JOINEX1 AS ( ( ЕМР JOIN DEPT ) WHERE BUDGET > 7M ) [ EMP#, 
DEPT# ] ; 

    Мы еще вернемся к общему вопросу определения и обработки представлений в 
главе 17. 
    Между прочим, сейчас можно объяснить замечание в главе 2 относительно 
того, что термин "представление" ("view") имеет довольно специфическое 
значение в реляционном контексте, не совпадающее со значением, приписанным ему 
в архитектуре ANSI/SPARC. На внешнем уровне этой архитектуры база данных 
воспринимается как "внешнее представление", определяемое внешней схемой (и 
разные пользователи могут иметь разные внешние представления). В реляционных 
системах, наоборот, представление, как пояснялось выше, является специально 
именованной производной виртуальной таблицей. Поэтому реляционным аналогом 
"внешнего представления" ANSI/SPARC обычно служит множество из нескольких 
таблиц, каждая из которых является представлением в реляционном смысле. 
"Внешняя схема" состоит из определений таких представлений. 
    Архитектура ANSI/SPARC является довольно общей и учитывает произвольные 
изменения между внешним и концептуальным уровнями. В принципе, даже типы 
структур данных, поддерживаемые на двух уровнях, могут быть разными: например, 
концептуальный уровень может быть основан на отношениях, в то время как 
пользователь может иметь внешнее представление базы данных в виде иерархии. 
Однако на практике большинство систем использует одинаковые типы структур в 
качестве базовых на обоих уровнях, и реляционные продукты не являются 
исключением из этого общего правила — представление по-прежнему остается 
таблицей, как и базовая таблица. А поскольку одинаковые типы объектов 
поддерживаются на обоих уровнях, то на двух уровнях применяется один и тот же 
подъязык данных (обычно SQL). Действительно, тот факт, что представление — это 
тоже таблица, так же важен для реляционных систем, как для математики важен 
факт, что подмножество также является множеством. 
    Замечание. Однако продукты SQL и стандарт SQL, похоже, часто игнорируют 
этот момент, поскольку нередко ссылаются на "таблицы и представления" (в том 
смысле, что представление не является таблицей). Советуем не делать этой 
распространенной ошибки и использовать термин "таблицы" лишь для базовых таблиц. 
    Есть еще один заслуживающий внимания вопрос, который касается базовых 
таблиц и представлений. Различие между базовой таблицей и представлением часто 
характеризуется так: 
    •  базовые таблицы "реально существуют" в том смысле, что они представляют 
данные, которые действительно хранятся в базе данных; 
    •   представления, наоборот, "реально не существуют", а просто 
предоставляют различные способы просмотра "реальных" данных. 
    Однако такая характеристика, хотя это вряд ли имеет значение в 
неформальном смысле, неточно отражает истинное положение дел. Верно, что 
пользователи могут 

    Глава 3. Введение в реляционные базы данных	67 

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

    3.8. Язык SQL 

    Большинство современных реляционных продуктов поддерживает один из 
диалектов стандартного языка SQL. Этот язык был разработан в компании IBM 
Research в начале 1970-х годов, его впервой крупной реализацией был 
реляционный прототип IBM-продукта System R; впоследствии он был реализован в 
многочисленных коммерческих продуктах как компании IBM, так и других 
изготовителей. С того времени диалекты языка SQL стали Американским 
национальным стандартом (ANSI), Международным стандартом (ISO), стандартом 
системы UNIX (X/Open), стандартом корпорации IBM, описывающим "общий интерфейс 
базы данных", который является частью архитектуры системных приложений IBM 
(System Applications Architecture, сокращенно SAA), федеральным стандартом 
обработки информации (FIPS). В этом разделе кратко рассматривается язык SQL. 

    CREATE TABLE DEPT 
    ( DEPTS  CHAR (2), ШАМЕ  CHAR(20), BUDGET DECIMAL (7), PRIMARY KEY ( DEPT# 
) ) 
    CREATE TABLE EMP 
    ( EMP#   CHAR(2), 
    ENAME  CHAR(20), 
    DEPT#  CHAR(2), 
    SALARY DECIMAL (5), PRIMARY KEY ( EMP# ), FOREIGN KEY ( DEPT# ) REFERENCES 
DEPT ) 

    Рис. З.6. База данных отделов и служащих (определение данных SQL) 

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

    68	Часть I. Основные понятия 

    дополнительная информация не показана на рис. 3.6). Если вам необходимо 
освежить в памяти информацию о первичных и внешних ключах, просмотрите этот 
материал выше в данной главе. 
    Создав таблицы, можно начинать применение операций к этим таблицам с 
помощью средств обработки данных SQL, т.е. операций SELECT, INSERT, UPDATE и 
DELETE. В частности, можно выполнить реляционные операции с данными SELECT, 
PROJECT и JOIN и во всех случаях использовать оператор обработки данных SQL 
SELECT. На рис. 3.7 показаны примеры операций SELECT, PROJECT и JOIN (см. рис. 
3.2), сформулированные на языке SQL. 

    SELECT (КЕЯПШЛУ : 
    SELECT DEPT#,   DNAME,   BUDGET 
    FROM      DEPT 
    WHERE BUDGET > 8M ; 

    Результат: 

    DEPTtt	DNAME		BUDGET 
    Dl	Marketing	10M 
    D2	Development	12M 

    PROJECT: 
    SELECT DEPT#, BUDGET FRCM  DEPT ; 

    Результат: 

    DEPT#	BUDGET 
    Dl	10M 
    D2	12M 
    D3	5M 

    JOIN: 
    SELECT DEPT. DEPT*, DNAME, BUDGET, EMPtt, ENAME, SALARY 
    FROM  DEPT, BMP 
    WHERE DEPT.DEPT* = EMP.DEPT* ; 

    Результат: 

    DEPT#	DNAME	BUDGET	EMPt	ENAME	SALARY 
    Dl	Marketing		10M	El	Lopez	40K 
    Dl	Marketing		10M	E2	Cheng	42K 
    D2	Development		12M	E3	Finzi	30K 
    D2	Development		12M	E4	Saito	35K 

    Рис. 3.7. Примеры операций SELECT, PROJECT и JOIN на языке SQL 

    Замечание. Пример операции соединения на этом рисунке иллюстрирует 
использование точки, которая иногда необходима в уточненных именах SQL для 
"устранения неоднозначности" ссылок на столбцы. Если бы использовались 
неуточненные имена, т.е. предложение WHERE было бы записано в виде "WHERE 
DEPT# = DEPT#", то две ссылки DEPT# порождали бы неоднозначность, т.е. было бы 
неясно, к какому случаю относится ссылка — к DEPT.DEPT# или к EMP.DEPT#. 
    Вы, наверное, заметили, что оператор SELECT языка SQL и операция SELECT 
реляционной модели — это не одно и то же! 
    Действительно, язык SQL поддерживает все три реляционные операции — 
SELECT, PROJECT и JOIN (и даже больше)— в операторе SELECT. Поэтому RESTRICT в 
качестве имени реляционной операции предпочтительнее имени SELECT, поскольку 
ссылка к двум разным операциям с помощью разных имен уменьшает вероятность 
перепутать их. (На самом деле, первоначальным именем реляционной операции было 
имя RESTRICT (ограничение); более того, интуитивно это имя лучше, так как 
операция предназначена для ограничения, например, множества отделов теми, 
бюджет которых превышает 8 млн.) 
    Завершаем это краткое обсуждение языка SQL несколькими наблюдениями. 

    Глава 3. Введение в реляционные базы данных 69 

    1.  Операции обновления. Примеры таких операций языка SQL, как INSERT, 
UPDATE и DELETE, уже приводились в главе 1. Однако все примеры этой главы 
использовали операции для отдельных строк. Тем не менее, как и операция 
SELECT, операции INSERT, UPDATE и DELETE обрабатывают данные на уровне 
множества (некоторые упражнения и ответы в главе 1 действительно 
демонстрировали эту возможность). Вот несколько примеров обновления на уровне 
множества для базы данных отделов и служащих: 

    INSERT 
    INTO        TEMP  ( ЕМР# ) 
    SELECT EMP# 
    FRCM   EMP 
    WHERE  DEPT# = 'Dl' ; 

    В этом примере подразумевается, что предварительно уже создана другая 
таблица TEMP с одним столбцом ЕМР#. Оператор INSERT вставляет в эту таблицу 
номера для всех служащих отдела D1. 

    UPDATE	EMP 
    SET	SALARY = SALARY * 1.1 
    WHERE	DEPT# = 'Dl' ; 

    Оператор UPDATE обновляет базу данных с учетом того факта, что всем 
сотрудникам отдела D1 на 10% была повышена зарплата. 

    DELETE 
    FRCM        EMP 
    WHERE       DEPT# = 'D2' ; 

    Оператор DELETE удаляет все строки таблицы ЕМР для служащих отдела D2. 
    2.  Каталог. Стандарт SQL включает спецификации для стандартного каталога, 
который называется информационной схемой (подробности в главе 8). Однако во 
время написания книги немногие продукты, если они действительно были, могли 
реализовать информационную схему. 
    3.  Представления. Ниже приведены аналоги SQL-оператора CREATE VIEW для 
представления TOPEMPS и пример запроса для сравнения с таким же 
представлением, приведенным выше в этой главе. 

    CREATE VIEW TOPEMPS AS 
    SELECT EMP#, ENAME, SALARY 
    FRCM   EMP 
    WHERE  SALARY > 33K ; 
    SELECT	EMP#, SALARY 
    FRCM	TOPEMPS 
    WHERE	SALARY < 42K ; 

    4.  Средства вызова. В большинстве продуктов SQL возможно выполнять 
операторы SQL двумя способами: "непосредственно", т.е. интерактивно с 
активного терминала, и как часть прикладной программы (т.е. оператор SQL может 
быть "встроен", а это означает, что такой оператор находится в программе 
вместе с операторами языка программирования). Кроме того, во втором случае 
программа обычно пишется на одном из базовых языков (С, COBOL, Pascal, PL/1 и т.п.). 
    5. SQL не идеален. В этой книге приводится множество примеров SQL, 
поскольку этот язык является стандартом реляционного языка, очень широко 
используется и внедряется. Но необходимо подчеркнуть, что язык SQL весьма 
далек от того, чтобы быть совершенным реляционным языком. Он страдает 
многочисленными недостатками, связанными с недоработками и реализацией. В 
главе 8 будет продолжено обсуждение языка SQL. 

    70	Часть I. Основные понятия 

    3.9. База данных поставщиков и деталей 

    Наш пример, используемый на протяжении почти всей книги, известен как база 
данных поставщиков и деталей. Цель настоящего раздела — познакомить с этой 
базой данных, которая будет служить примером для ссылок в последующих главах. 
На рис. 3.8 показано множество значений данных примера. Эти конкретные 
значения будут фактически использоваться и в последующих примерах (где это 
имеет смысл). На рис. 3.9 показано определение базы данных, синтаксис этого 
описания объясняется в главе 4. Обратите внимание, в частности, на 
спецификации первичного и внешнего ключей. 

    S									SP 

    s#	SNAME	STATUS	CITY				S#	P#	QTY 
    SI	Smith	20		London			SI	PI	300 
    S2	Jones	10		Paris				SI	P2	200 
    S3	Black	30		Paris				SI	P3	400 
    S4	Clark	20		London			SI	P4	200 
    S5	Adams	30		Athens			SI	P5	100 
    SI	P6	100 						S2	PI	300
									S2	P2	400
    P									S3	P2	200
									S4	P2	200
    P#	PNAME	COLOR	WEIGHT	CITY			S4	P4	300			 
    PI	Nut	Red	12		London		S4	P5	400		 
    P2	Bolt	Green	17		Paris			 
    P3	Screw	Blue	17		Rome			 
    P4	Screw	Red	14		London		 
    P5	Cam	Blue	12		Paris			 
    P6	Cog	Red	19		London 
    
    
    Рис. З.8. База данных поставщиков и деталей (значения для примера) 

    CREATE CREATE CREATE CREATE CREATE CREATE CREATE 

CREATE DOMAIN S# DOMAIN NAME DOMAIN STATUS DCMAIN CITY DOMAIN P# DCMAIN COLOR 
	DCMAIN WEIGHT DCMAIN QTY 
	CHAR(5)   ; CHAR(20)   ; NUMERIC(S) CHAR(15)   ; CHAR(6)   ; CHAR(6)   ; 
	NUMERIC(S) NUMERIC(9) 
CREATE BASE RELATION S 
    	(  S#	DCMAIN   (  S#   ) , SNAME DCMAIN   (  NAME  ), STATUS               
   	DCMAIN   (  STATUS  ), CITY                      DCMAIN   (  CITY  )   ) 
	PRIMARY      KEY     (  S#  )   ; 
CREATE BASE RELATION P 
    (  P#	DCMAIN   (  P#   ), PNAME DCMAIN   ( NAME ) , COLOR DCMAIN WEIGHT CITY 
    PRIMARY KEY   (  P#  )   ; 
CREATE BASE RELATION SP 
    (  S#	DCMAIN  COLOR ), 
    DCMAIN   ( WEIGHT  ), DCMAIN   (  CITY  )   ) s# ), 
    DCMAIN   (  P#   ), DCMAIN   (  OTY  )   ) 
    P# OTY PRIMARY KEY ( S#, P# ) FOREIGN KEY ( S# ) REFERENCES S FOREIGN KEY ( P# ) 
	REFERENCES P 

    Рис, 3.9, База данных поставщиков и деталей (определение данных) 

    Глава 3. Введение в реляционные базы данных 71 

    В базе данных предполагается следующая семантика.	? 
    •  Таблица S представляет поставщиков. Каждый поставщик имеет уникальный 
номер (S#); имя (SNAME), не обязательно уникальное (хотя оно может быть, как
случае на рис. 3.8, уникальным); значение рейтинга или статуса (STATUS); место 
расположения (CITY). Предполагается, что каждый поставщик расположен точно в 
одном городе (т.е. у нас всегда будет одно значение CITY — город). 
    •  Таблица Р представляет детали (точнее, виды деталей). У каждого вида 
детали есть номер детали (Р#), который является уникальным; название детали 
(PNAME); цвет (COLOR); вес (WEIGHT); место расположения, где хранится этот вид 
деталей (CITY). Предполагается (где это имеет значение), что вес детали 
приведен в фунтах. Также предполагается, что каждый отдельный вид детали 
только одного цвета и хранится на складе точно в одном городе. 
    •  Таблица SP представляет поставки. Она в известном смысле служит для 
соединения двух других таблиц. Например, первая строка таблицы SP на рис. 3.8 
соединяет поставщика S1 таблицы S с соответствующей деталью Р1 таблицы Р, т.е. 
представляет факт поставки деталей Р1 поставщиком S1 (а также указывает 
количество деталей — 300 штук). Таким образом, каждая поставка характеризуется 
номером поставщика (S#), номером детали (Р#) и количеством (QTY). 
Предполагается, что в одно и то же время может быть не более одной поставки 
для одного поставщика и одной детали; поэтому для данной поставки комбинация 
значений S# и Р# уникальна с точки зрения набора текущих поставок, находящихся 
в таблице SP. 
    В принципе, каждая деталь является товаром, который поставляет 
определенный поставщик. Поэтому в последующих главах книги о поставке деталей 
мы часто будем говорить просто как о поставке определенных товаров, т.е. база 
данных поставщиков и деталей может служить базой данных поставщиков и товаров. 
    Как уже отмечалось, поставщиков и детали можно рассматривать как объекты, 
а поставку — как отношение между определенным поставщиком и определенной 
деталью. Также было указано, что отношения можно рассматривать как специальный 
вид объектов. Одно из преимуществ реляционных баз данных состоит именно в том, 
что все объекты, независимо от того, являются ли они на самом деле отношениями 
или объектами, представляются одним универсальным способом, а именно с помощью 
таблиц, как показано в нашем примере. 
    И последнее замечание: наша база данных поставщиков и деталей очень 
простая, гораздо проще любой реальной базы данных, которая может встретиться 
на практике; в большинстве реальных баз данных используется значительно больше 
объектов и отношений, чем в нашей. Но несмотря на это, наш пример вполне 
подходит для объяснения большинства вопросов, которые будут обсуждаться в 
следующих частях книги, и (как уже упоминалось) будет использоваться как 
основа для большинства (не для всех) примеров последующих нескольких глав. И 
еще один комментарий: конечно, нет ничего плохого в том, чтобы использовать 
описательные названия таблиц, такие как SUPPLIERS (поставщики), PARTS (в 
качестве таблицы деталей) и SHIPMENTS (поставки), вместо сокращенных названий 
S, Р и SP; более того, на практике рекомендуется использовать именно такие 
описательные названия. Однако в нашем конкретном случае в последующих главах 
так часто будут употребляться названия этих таблиц, что целесообразнее 
использовать именно короткие названия. Многократно употребляемые длинные 
названия начинают раздражать. 

    3.10. Резюме 

    На этом завершается краткий обзор реляционной технологии. Конечно, мы 
затронули лишь вершину айсберга, ставшего сегодня весьма обширным предметом 
изучения, но, как уже отмечалось, цель данной главы — введение в более 
расширенное обсуждение, которое проводится далее в этой книге. Однако несмотря 
на это, нам удалось охватить немалую часть материала. Подведем итог обсуждению 
затронутых нами тем. 

    72	Часть I. Основные понятия 

    Реляционная база данных представлена пользователю как множество отношений 
или таблиц. Все значения в отношении атомарные или скалярные (нет групп 
повторения). Реляционная система поддерживает реляционные базы данных и 
операции над ними, в частности включающие в себя операцию выборки строк 
RESTRICT (иногда называемую SELECT), операцию выборки столбцов PROJECT (также 
называемую проекцией) и операцию соединения таблиц JOIN. Эти и подобные 
операции выполняются на уровне множества. Свойство замкнутости реляционных 
систем означает, что результат операции имеет тот же тип, что и объекты, над 
которыми проводилась операция (все они являются отношениями); это позволяет 
использовать вложенные реляционные выражения. 
    Формальная теория, которая лежит в основе реляционных систем, называется 
реляционной моделью. Реляционная модель изучает материал только на логическом 
уровне и не затрагивает физический уровень. В модели рассматриваются три 
аспекта данных — структура (объекты данных), целостность и обработка данных 
(операторы). Объектами в основном являются таблицы, целостность обеспечивается 
внешними и первичными ключами, а операторы — это RESTRICT, PROJECT, JOIN и т.д. 
    Оптимизатор — это компонент системы, определяющий, как будут реализованы 
запросы пользователя (которые указывают, что делать, а не как делать). Таким 
образом, в реляционных системах предусмотрена ответственность за "навигацию" 
по хранимой базе данных для нахождения необходимых данных; такие системы 
иногда называют системами автоматической навигации. Оптимизация и 
автоматическая навигация являются предпосылками независимости данных в 
реляционной системе. 
    Каталог — это множество системных таблиц, которые содержат дескрипторы 
различных важных для системы элементов (базовых таблиц, представлений, 
индексов и т.д.). Пользователи могут опрашивать каталог так же, как 
собственные данные. 
    Производная таблица — это таблица, полученная из других таблиц посредством 
реляционного выражения. Базовая таблица— это таблица, не являющаяся 
производной. Представление — это именованная производная таблица, определение 
которой через другие таблицы содержится в каталоге. Пользователь может 
оперировать представлениями практически так же, как и базовыми таблицами. 
Система выполняет операции над представлениями, заменяя ссылки на название 
представления выражением, определяющим его, т.е. преобразуя операцию над 
представлением в соответствующую операцию над базовыми таблицами. Этот метод 
реализации операций называется методом подстановки. 
    Стандартным языком для работы с реляционными базами данных является язык 
SQL. Для создания новой базовой таблицы используется оператор SQL CREATE 
TABLE. Оператор выборки SELECT (или SELECT-FROM-WHERE) языка SQL предоставляет 
функциональные возможности реляционных операторов RESTRICT, PROJECT и JOIN и 
даже больше. Операторы обновления SQL— это операторы INSERT, UPDATE и DELETE. 
Язык SQL очень важен с коммерческой точки зрения, но весьма далек от 
"идеального" реляционного языка. 
    И наконец, в данной главе приведен основной пример, к которому мы будем 
обращаться в ходе дальнейшего изложения, — это база данных поставщиков и 
деталей. Рекомендуется ознакомиться с этим примером сейчас, если вы еще не 
сделали этого. Вы должны, по крайней мере, знать, какие существуют столбцы и в 
каких таблицах данного примера, а также какие существуют внешние и первичные 
ключи (конечно, конкретные значения таблиц не очень важны). 
    И в заключение попробуем провести параллель между материалом этой главы и 
компонентами архитектуры ANSI/SPARC, описанной в главе 2. Это соответствие не 
всегда четкое, но полезное для лучшего понимания материала. 
    1.  Базовые таблицы соответствую!  концептуальному уровню архитектуры 
ANSI/ SPARC. 
    2.  Как отмечалось в этой главе, представления соответствуют внешнему 
уровню архитектуры ANSI/SPARC. 

    Глава 3. Введение в реляционные базы данных	73 

    Замечание. В действительности в большинстве современных реляционных 
продуктов иногда не делается различия между внешним и концептуальным уровнем, 
так как эти системы позволяют пользователям оперировать непосредственно с 
базовыми таблицами так же, как и с представлениями. 
    3.  В реляционной модели не рассматривается внутренний уровень систем баз 
данных, в частности внутренний уровень архитектуры ANSI/SPARC. В принципе, как 
объяснялось в этой главе, в системе могут использоваться любые структуры 
хранения на внутреннем уровне. Единственным условием является то, что система 
должна "уметь" преобразовывать эти структуры хранения и представлять данные на 
концептуальном уровне в чистой табличной форме. К сожалению, это еще одна 
область, где современные реляционные продукты пока недостаточно совершенны: 
большинство этих продуктов чаще отображает одну базовую таблицу в один 
хранимый файл; что касается разницы между ними, то продукты практически не 
обеспечивают гибкости в этом направлении. Иначе говоря, эти продукты не 
обеспечивают необходимой независимости данных, которую теоретически могут 
предоставить реляционные системы. 
    Замечание. Несмотря на это, в пользовательских запросах (например, в 
выражениях SQL) этих продуктов нет прямых ссылок на структуры доступа, такие 
как индексы. В результате эти структуры могут быть свободно созданы или 
уничтожены администратором базы данных или самой СУБД (с целью настройки или 
увеличения производительности), не причиняя вреда существующим приложениям. 
(По крайней мере, это верно для стандарта SQL, хотя опять же, к сожалению, 
некоторые продукты игнорируют упомянутый принцип и не отвечают стандарту в 
этом отношении.) 
    4. Язык SQL — это типичный (фактически стандартный) подъязык данных. В 
этом смысле он включает в себя язык определения данных и язык обработки 
данных. Как уже отмечалось, язык обработки данных SQL может использоваться как 
на внешнем, так и на концептуальном уровне. Так же и язык определения данных 
SQL можно использовать для определения объектов на внешнем уровне 
(представлений), концептуальном уровне (базовые таблицы) и в большинстве 
систем (хотя эти возможности не входят в стандарт) даже на внутреннем уровне 
(например, для определения индексов). Более того, язык SQL предоставляет даже 
некоторые средства "управления данными", т.е. средства, которые нельзя отнести 
ни к языку определения данных, ни к языку обработки данных. Примером таких 
средств является оператор GRANT, который позволяет одному пользователю 
передать определенные привилегии доступа другому пользователю (подробнее об 
этом в следующих частях книги). 
    5.  Прикладные программы в SQL-системе могут получить доступ к базе данных 
из базового языка, такого как COBOL, посредством встроенных SQL-операторов. 
Встроенный язык SQL представляет "слабую связь" между языком SQL и базовым 
языком. В общем, любой оператор интерактивного языка SQL можно использовать во 
встроенном языке. Более того, существуют специальные операторы, которые можно 
использовать только во встроенном языке (подробнее это будет описано в главе 8). 

    Упражнения 

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

    74	Часть I. Основные понятия 

    3.2. Опишите содержимое таблиц каталога TABLES и COLUMNS для базы данных 
поставщиков и деталей. 
    3.3. Как пояснялось в этой главе, каталог описывает сам себя, т.е. 
включает записи о самих таблицах каталога. Дополните рис. 3.4 так, чтобы он 
включал необходимые записи о самих таблицах TABLES и COLUMNS. 
    3.4. Вот запрос для базы данных поставщиков и деталей: 

    RESULT := ( ( S JOIN SP ) WHERE Pi = 'P2' ) [ Si, CITY ] ; 

    Что получится в результате выполнения этого запроса? 
    3.5. Предположим, что выражение, расположенное справа в запросе упр. 3.4, 
используется для определения представления 

    CREATE VIEW V AS ( ( S JOIN SP ) WHERE Pi = 'P2' ) [Si, CITY ] ; 

    Теперь рассмотрим запрос 

    ANSWER :=   ( V WHERE CITY =  'London'   )   [ Si ]   ; 

    Что получится в результате выполнения этого запроса? Покажите, что 
используется со стороны СУБД при выполнении запроса. 

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

    3.1. Codd E.F. Relational Database: A Practical Foundation for 
Productivity // CACM.— 1982.— 25, №2. (Переиздано: Robert L. Ashenhurst (ed.). 
ACM Turing Award Lectures: The First Twenty Years 1966-1985. — Reading, Mass.: 
Addison-Wesley, 1989.) 
    Статья была представлена Коддом на соискание награды ACM Turing Award в 
1981 году. В ней обсуждается хорошо известная проблема занятости приложения. 
Перефразируя, можно сказать: "Потребности в приложениях для компьютера быстро 
возрастают — так быстро, что отделы информационных систем (которые несут 
ответственность за написание приложений) отстают от них все больше и больше." 
Существует два дополнительных метода разрешения этой проблемы. 
    1.  Предоставить  специалистам  по  информационным  технологиям  новые 
средства для повышения их продуктивности. 
    2.  Предоставить пользователям возможность доступа непосредственно к базе 
данных, полностью игнорируя специалистов. 
    Оба подхода необходимы, а в статье Кодда приводится обоснование того, что 
основа для этих подходов предоставляется реляционной технологией. 
    3.2. Date C.J. Why Relational? // C.J. Date. Relational Database Writings 
1985-1989. — Reading, Mass.: Addison-Wesley, 1990. 
    Попытка предоставить краткую, но достаточно основательную сводку основных 
преимуществ реляционного подхода. Приведем следующее высказывание из статьи: 
среди многочисленных преимуществ реляционного подхода существует одно, которое 
следует особо подчеркнуть, — наличие солидной теоретической базы. Цитирую: 
    "...реляционная фактически означает различная. Она является различной, 
поскольку не является специальной. Старые же системы, напротив, имели 
специальное назначение; они предоставляли решения для определенных задач того 
времени, но у них не было твердой теоретической базы. А у реляционных систем 
такая база есть... а это означает, что [они] надежны как скала". 
    "Благодаря этому твердому основанию поведение реляционных систем 
отличается предсказуемостью; пользователь (возможно, не осознавая этого) 
держит в голове простую модель этого поведения, и это позволяет ему 
предвидеть, что 

   Глава 3. Введение в реляционные базы данных	75 

    сделает система в той или иной ситуации. Сюрпризов быть не может (или не 
должно быть). Предопределенность означает, что пользовательский интерфейс 
прост для понимания, обучения, изучения, использования и запоминания". 
    3.3. Date C.J. Relational Technology: A Brief Introduction // C.J. Date 
and Hugh Darwen. Relational Database Writings 1989-1991. — Reading, Mass.: 
Addison-Wesley, 1992. 
    В этой статье настоящая глава была частично опубликована в несколько иной форме. 

    Ответы к некоторым упражнениям 

    3.2. На рис. 3.10 показаны записи для таблиц TABLES и COLUMNS (другие 
записи для пользовательских таблиц пропущены). Понятно, что дать точные 
значения COLCOUNT и ROWCOUNT невозможно. 
    
    
    TABLES	TABNAME	COLCOUNT	ROWCOUNT	..... 
    TABLES COLUMNS	(>3) (>2)	02) 05)	..... 
    
    
    COLUMNS	TABNAME	COLNAME 
    TABLES TABLES TABLES COLUMNS COLUMNS	TABNAME COLCOUNT ROWCOONT TABNAME COLNAME	..... 
    
    
    Рис. 3.10. Записи каталога для самих таблиц TABLES и COLUMNS (схематически) 
    3.4. Запрос предназначен для выбора номеров и городов поставщиков, которые 
поставляют деталь Р2. 
    3.5. Значение этого запроса следующее: "Выбрать номер поставщика из 
Лондона, поставляющего деталь Р2". Первый шаг при выполнении запроса (замена 
названия V значением, определяющим таблицу V) дает: 

    (   (   (   (  S JOIN SP  )   WHERE Р# =   'Р2'   )    [  S#,   CITY ]   ) 
    WHERE CITY =   'London1   )    [  S#  ] 

    Это выражение можно упростить следующим образом: 

    ( ( S WHERE CITY = 'London1 ) JOIN ( SP WHERE P# = 'P2' ) ) [ S# ] 

    Объяснение и дальнейшее обсуждение подобных выражений вы найдете в 
последующих главах книги. 

    76 Часть I. Основные понятия 

