Другой момент, который также недвусмысленно проиллюстрирован на рис. 3.2, заключается в том, что операции применяются сразу ко всему множеству строк, а не к отдельной строке за один раз, т.е. операндами и результатами являются не отдельные строки, а целые таблицы, которые содержат множество строк. (Таблица, содержащая множество из одной строки, конечно, тоже допустима, как и пустая таблица, в которой совсем нет строк.) Например, операция JOIN на рис. 3.2 применяется к двум таблицам, состоящим из трех и четырех строк соответственно, а в результате возвращает таблицу из четырех строк. В противоположность этому операции нереляционных систем обычно за одно обращение обрабатывают только одну строку или запись. Таким образом, возможность обработки множеств- главная отличительная характеристика реляционных систем (обсуждение этого вопроса будет продолжено в разделе 3.5).

Давайте вновь вернемся к рис. 3.1. Есть несколько замечаний, которые можно сделать на основе примера базы данных, приведенного на этом рисунке.

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

В данном случае термин логическая структура в терминологии ANSI/SPARC относится как к концептуальному, так и к внешнему уровням. Дело в том, что, как объяснялось в главе 2, и концептуальный, и внешний уровни в реляционной системе являются одинаково реляционными и лишь внутренний или физический уровень не является таковым. На самом деле реляционная теория вообще ничего не может сказать о внутреннем уровне. Она, как уже отмечалось, определяет то, как база данных представлена пользователю. Повторим, единственное требование состоит в следующем: какая бы физическая структура не была выбрана, она должна полностью реализовывать существующую логическую структуру.

Во-вторых, у реляционных баз данных есть одно замечательное свойство, называемое информационным принципом, все информационное содержимое базы данных представлено одним и только одним способом, а именно - явным зада-

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

нием значений, помещенных в позиции столбцов в строках таблицы. Этот метод представления единственно возможный для реляционных баз данных (естественно, на логическом уровне). В частности, нет никаких указателей, связывающих одну таблицу с другой. Например, на рис. 3.1 существует определенная связь между строкой Dl в таблице DEPT и строкой Е1 в таблице ЕМР, указывающая, что служащий с номером Е1 работает в отделе с номером D1; но эта информация представлена не указателем, а наличием значения D1 в столбце DEPTt строки El в таблице ЕМР. В нереляционных системах (например, в IMS и IDMS), напротив, такая информация обычно представляется (о чем шла речь в главе 1) неким указателем, который пользователь видит явно.

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

На этом закончим с вопросами, связанными со структурой и обработкой данных в реляционной модели, и перейдем к рассмотрению аспекта целостности. Еще раз воспользуемся базой данных отделов и сотрудников, приведенной на рис. 3.1. На практике для такой базы данных потребовалось бы определить несколько ограничений поддержки целостности базы. Например, зарплата служащих не должна выходить за пределы диапазона, скажем, от 25 до 95 тыс. долларов в год, а бюджет отдела должен быть, например, в пределах от 1 до 15 млн долларов и т.д. Некоторые из таких правил имеют настолько важное практическое значение, что получили специальные названия. Рассмотрим их.

1. Каждая строка в таблице DEPT должна включать уникальное значение столбца DEPTt; аналогично каждая строка в таблице ЕМР должна включать уникальное значение столбца EMPt. Говорят, что столбцы DEPTt в таблице DEPT и EMPt в таблице ЕМР являются первичными ключами для своих таблиц. (Вспомните, что в главе 1 мы условились отмечать на рисунках столбцы первичных ключей двойным подчеркиванием.)

2. Каждое значение столбца DEPTt в таблице ЕМР должно существовать как значение столбца DEPTt в таблице DEPT для отражения того факта, что каждый служащий должен быть приписан к существующему отделу. Говорят, что столбец DEPTt в таблице ЕМР является внешним ключом, ссылающимся на первичный ключ таблицы DEPT.

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

1. Неограниченный набор скалярных типов (включая, в частности, логический тип или значение истины).

2. Генератор типов отношений и соответствующая интерпретация для таких сгенерированных типов отношений.

3. Возможность определения переменных отношений для таких сгенерированных типов отношений.

4. Операция реляционного присвоения для присвоения реляционных значений таким переменным отношений.

5. Неограниченный набор обших реляционных операторов для получения значений отношений из других значений отношений.

Как видите, реляционная модель- это нечто большее, чем просто таблицы плюс выборка, проекция и соединение , хотя ее неформально довольно часто характеризуют именно таким образом.

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

3.3. Отношения и переменные-отношения

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

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

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

Принципы реляционной модели были изначально заложены в 1969 и 1970 годах Е.Ф. Коддом (E.F. Codd), который в то время был исследователем, работавшим в корпорации IBM. В конце 1968 года Кодд, математик по образованию, впервые пришел к заключению, что математические дисциплины можно использовать для привнесения в область управления базами данных строгих принципов и точности. Именно этих качеств недоставало данной области в то время. Идеи Кодда впервые подробно были изложены в ставшей классической статье А Relational Model of Data for Large Shared Data Banks (см. [5.1] в главе 5).

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