Дейт К. Введение в системы баз данных
Подождите немного. Документ загружается.
Дейт К. Введение в системы баз данных. К.; М.; Спб; Издат. Дом
«Вильямс». 2000.
Реляционная модель (стр. 81-100)
Часть II
Реляционная модель
Основой современной технологии баз данных, без сомнения, является
реляционная модель; именно эта основа делает область технологии баз данных
наукой. Поэтому любое описание этой области, не охватывающее описание модели,
может быть лишь поверхностным. Точно так же умение или опыт в этой области
нельзя признать удовлетворительными, если человек не имеет глубокого
представления о реляционной модели. Поспешим добавить — мы вовсе не хотим
сказать, что этот материал труден для понимания, просто он представляет основу.
Как уже отмечалось в главе 3, в реляционной модели рассматриваются три
аспекта данных — структура данных (объекты данных), целостность данных и
обработка данных (операторы). В этой части книги рассматривается каждый из
трех аспектов: в главе 4 обсуждаются объекты, в главе 5 — целостность, в главах 6 и
7 — операторы. (Мы посвятили последней теме две главы, поскольку операционную
часть модели можно реализовать двумя различными, но эквивалентными способами,
известными соответственно как реляционная алгебра и реляционное исчисление)
Назначение главы 8 будет описано ниже.
Замечание. Важно понимать, что модель не статична, она изменилась с годами
и, конечно, продолжает изменяться. Определения, описания и объяснения в этой
книге отвечают современным взглядам автора и других специалистов в этой
области. Однако следует отметить, что хотя большая часть обсуждаемого материала
действительно является "нерушимой скалой" (упомянутые выше изменения носят
эволюционный, а не революционный характер), все еще существуют темы для
разногласий. Такие темы соответствующим образом отмечены в тексте.
Как отмечалось выше, реляционная модель не очень сложна для понимания. Но
она является теорией, а большинство теорий сопровождается своей специальной
терминологией, и реляционная модель (по причинам, указанным в главе 3) не
является исключением
Глава 4
Реляционные объекты данных: домены и отношений
4.1. 4.1. Вводный пример
Как отмечалось в главе 3 реляционная модель делится на три части, в которых
рассматриваются соответственно объекты, целостность и операторы. Во всех трех
частях есть свои специальные термины. Наиболее важные термины, используемые в
части "объектов" (предмет настоящей главы), показаны на рис. 4.1. В качестве
иллюстрации взята таблица S из базы данных поставщиков и деталей. Речь идет о
терминах отношение, кортеж, кардинальное число, атрибут, степень, домен и
первичный ключ (вы уже должны быть знакомы по крайней мере с терминами
отношение и первичный ключ). Сейчас мы дадим неформальное объяснение каждого
термина, а в последующих разделах представим формальные определения.
Итак, вкратце:
■ ■BBBBBBB Отношение соответствует тому, что мы до сих пор называли таблицей.
■ ■BBBBBBB Кортеж соответствует строке этой таблицы, а атрибут — столбцу.
Количество кортежей называется кардинальным числом, а количество атрибутов
— степенью.
■ ■BBBBBBB Первичный ключ — это уникальный идентификатор для таблицы, т.е.
столбец или такая комбинация столбцов, что в любой момент времени не
существует двух строк, содержащих одинаковое значение в этом столбце или
комбинации столбцов.
■ ■BBBBBBB И наконец, домен — это общая совокупность значений, из которой
берутся настоящие значения для определенных атрибутов определенного
отношения. Например, домен, обозначенный S# на рис. 4.1 — это множество всех
допустимых значений номера поставщика, а множество значений S# в отношении S
в любой момент времени является подмножеством этого множества. Точно так же
множество значений S# в отношении SP в любой момент времени является
подмножеством этого множества.
На рис. 4.2 представлен обзор этих терминов. Этот рисунок требует некоторых
пояснений.
1. 1.BB Нужно понимать, что "эквивалентности", показанные на рисунке, лишь
приблизительны, так как реляционные термины, перечисленные слева, имеют
точные определения, в то время как неформальные эквиваленты справа имеют лишь
грубые, нестрогие определения.
Поэтому, например, отношение и таблица — это не одно и то же, хотя часто на
практике удобно считать, что это так. (Далее в этой главе мы объясним точную
разницу между отношением и таблицей.)
2. 2.BB Понятие домена является иллюстрацией одного важного момента, о
котором шла речь в главе 3, — не все реляционные системы поддерживают
полностью все аспекты реляционной модели. На самом деле в главе 3 мы дали
общее описание реляционных систем, не упоминая доменов вообще.
В действительности большинство современных реляционных систем не
поддерживает домены в полной мере, несмотря на то что они являются одной из
фундаментальных составляющих реляционной модели в целом. Поэтому помните,
что в следующих нескольких главах описывается только реляционная модель;
поведение же реляционной системы совсем не обязательно соответствует
описанному.
Теперь перейдем к формальному изложению.
4.2. 4.2. Домены
В качестве отправной точки возьмем наименьшую семантическую единицу
данных, которая предполагается отдельным значением данных (таким как
отдельный номер поставщика, отдельный вес детали или отдельное количество
деталей в поставке). Мы будем называть такие значения скалярами (хотя этот
термин редко используется в реляционной литературе). Скалярные значения
представляют собой "наименьшую семантическую единицу данных" в том смысле,
что они атомарные: у них нет внутренней структуры (т.е. они неразложимы) в
реляционной модели, а значит, и при рассмотрении в реляционной СУБД. Обратите
особое внимание на то, что не иметь внутренней структуры при рассмотрении в
реляционной модели вовсе не значит не иметь внутренней структуры вообще.
Например, название города, конечно же, имеет внутреннюю структуру (оно состоит
из последовательности букв); однако, разложив название по буквам, мы потеряем
значение. Значение станет понятным, лишь в том случае, если буквы сложены
вместе и в правильной последовательности.
Замечание. Мы мимоходом заметили, что понятие "атомарности скалярных
значений" довольно расплывчатое [4.8, 4.15]. Однако дальнейшее обсуждение этого
вопроса отложено для следующих глав книги; а сейчас будем полагать, что это
понятие интуитивно понятно.
Теперь можно определить домен как именованное множество скалярных
значений одного типа. Например, домен номеров поставщиков — это множество
всех возможных номеров поставщиков; домен количества деталей для поставок —
это множество всех целых чисел, больших нуля и меньших, скажем, 10 000. Итак,
домены являются общими совокупностями значений, из которых берутся реальные
значения атрибутов. Точнее, каждый атрибут должен быть определен на
единственном домене (или на основе одного домена); это значит, что значения
атрибута должны браться из этого домена. Например, атрибут номера детали для
отношения Р и атрибут номера детали для отношения SP определены на домене
номера детали (потому что эти два атрибута, бесспорно, представляют номера
деталей). Другими словами, в любой момент времени каждое значение Р# в
отношении Р должно быть значением из домена номера детали, то же верно для
значения Р# в отношении SP. Иными словами, в любой момент времени набор
значений Р# в отношении Р является некоторым подмножеством множества
значений домена номера детали, и то же верно для значения Р# в отношении SP.
Между прочим, обратите внимание, что обычно в любой момент времени в
домене будут значения, не являющиеся значением ни одного из атрибутов,
соответствующих этому домену. Например, если значение Р8 — допустимое
значение детали, то оно входит в домен номера детали, даже если в нашем
отношении Р из примера базы данных поставщиков и деталей нет детали Р8, т.е. в
данный момент не существует такой детали.
Сравнения, ограниченные доменом
В чем состоит значение доменов? Один из наиболее важных ответов на этот
вопрос следующий: домены ограничивают сравнения. Поясним сказанное.
Рассмотрим два запроса SQL к базе данных поставщиков и деталей (заметьте, что
оба запроса используют соединение):
Один из этих запросов, а именно левый, возможно, имеет смысл, тогда как
правый, скорее всего, — нет. Откуда это известно? С формальной точки зрения
ответ заключается в том, что запрос слева использует сравнение между атрибутами
Р.Р# и SP.P#, которые (как уже упоминалось) определены на одном и том же домене,
в то время как запрос справа использует сравнение между атрибутами P.WEIGHT и
SP.QTY, которые, вероятно, определены на разных доменах. (Мы здесь говорим
"вероятно", поскольку, хотя вес и количество являются числами, это числа разного
"сорта". Не имеет смысла сравнивать вес и количество. Поэтому домены веса и
количества должны быть различными.)
Следовательно, в соответствии с предыдущими рассуждениями, если значения
двух атрибутов взяты из одного и того же домена, тогда сравнения, а отсюда и
соединения, объединения и многие другие операции, использующие такие два
атрибута, тоже, вероятно, будут иметь смысл, так как в них сравнивается подобный
атрибут с подобным. И наоборот, если значения двух атрибутов взяты из различных
доменов, тогда сравнения и другие операции, наверное, не будут иметь смысла.
Поэтому преимущество системы поддержки доменов заключается в том, что такая
система способна предотвратить грубые ошибки. Обратите внимание, что здесь
легко допустить механическую ошибку, например набрав S# вместо Р#. Если
пользователь попробует выполнить операцию, использующую сравнение значений
разных доменов, система прервет свою работу и сообщит пользователю о
возможной ошибке. (Мы говорим "возможной", поскольку могут быть
обстоятельства, при которых такое сравнение не является ошибкой. Но об этом в
следующих частях книги.)
Между прочим, следует отметить, что хотя все примеры, которые мы
приводили, были выражены в терминах языка SQL, этот язык на самом деле не
поддерживает доменов в том смысле, который мы им придаем. Оба указанных выше
запроса допустимы в SQL. Однако второй, конечно же, даст бессмысленный ответ.
Определение данных
Один вопрос, который еще, возможно, не ясен читателю, заключается в том,
что домены прежде всего имеют концептуальную природу. Они могут быть или не
быть явно сохранены в базе данных как реальные наборы значений; фактически в
большинстве случаев они не сохраняются. Но они должны быть, по крайней мере,
определены в рамках определений базы данных (имеется в виду в системе,
поддерживающей понятие домена в полной мере; но как уже отмечалось,
большинство сегодняшних продуктов такой поддержки не обеспечивают); и тогда
каждое определение атрибута должно включать ссылку на соответствующий домен,
таким образом системе будет известно, какие атрибуты можно сравнивать, а какие
— нет.
Теперь, чтобы конкретизировать идеи реляционной модели (как в этом разделе,
так и во всей части), мы будем использовать гипотетический реляционный язык для
иллюстрации этих идей. Операторы языка будут постепенно вводиться по ходу
изложения. Ясно, что в первую очередь нам нужен способ создания нового домена:
CREATE DOMAIN domain data-type ;
Здесь domain— это имя нового домена, a data-type соответствует типу
данных, например CHAR(n) или NUMERIC(n). Замечание. Далее в книге мы
обсудим некоторые дополнительные компоненты оператора CREATE DOMAIN, не
показанные выше.
На рис. 4.3 (такой же рисунок уже приводился в главе 3) показано, как с
помощью этого языка можно определить базу данных поставщиков и деталей.
Обратите внимание, что в этом примере наряду с операторами CREATE DOMAIN
используются операторы CREATE BASE RELATION. Полное описание оператора
здесь мы лишь отметим, что каждое определение атрибута в операторе CREATE
BASE RELATION включает ссылку на соответствующий домен.
При создании нового домена с помощью оператора CREATE DOMAIN СУБД
создает запись в каталоге с описанием этого нового домена. (Чтобы вспомнить, что
такое каталог, обратитесь еще раз к главе 3.) Точно так же при создании нового
отношения с помощью оператора CREATE BASE RELATION СУБД создает запись
в каталоге с описанием этого нового отношения.
Замечание о названиях. Для определенности будем предполагать следующие
ограничения на названия:
■ ■BBBBBBBBBBBB Домены имеют уникальные имена в базе данных.
■ ■BBBBBBBBBBBB Именованные отношения имеют уникальные имена в базе данных.
■ ■BBBBBBBBBBBB Атрибуты имеют уникальные имена в содержащем их отношении (даже
если содержащее их отношение не именовано!).
Вообще говоря, атрибут может иметь как имя, совпадающее с именем
соответствующего домена, так и отличное от него имя. Очевидно, чтобы избежать
двусмысленности, следует использовать разные имена (в частности, если два
атрибута в одном отношении основаны на одном домене). Однако в общем
желательно называть атрибуты таким же именем, что и лежащий в основе домен,
или, по крайней мере, называть так, чтобы, например, в имени атрибута содержалась
ключевая часть имени домена. Мы следуем этому указанию и в примере на рис. 4.3.
Можно дополнительно придерживаться другого общего соглашения и
полностью опускать ссылку к основному домену из определения любого атрибута,
который имеет то же самое имя, что и домен. Например, оператор CREATE BASE
RELATION для базового отношения S может быть упрощен:
Удаление доменов. Мы уже знаем, как создать новый домен. Должна также
быть возможность удалить существующий домен, если мы больше в нем не
нуждаемся:
DESTROY DOMAIN domain ;
Здесь domain— это имя удаляемого домена. С помощью этой операции
удаляется элемент каталога, описывающий домен, поэтому такой домен становится
неизвестным для системы. (До особого указания будем подразумевать, что операция
DESTROY DOMAIN просто не будет выполняться, если какое-нибудь базовое
отношение в этот момент еще включает атрибут, который определен на указанном
домене.)
Запросы, основанные на доменах. Вот другой пример практического значения
доменов. Рассмотрим запрос, который формулируется так:
"Какие отношения в базе данных содержат какую-либо информацию, имеющую
отношение к поставщикам?"
Этот вопрос может быть сформулирован более точно:
"Какие отношения в базе данных включают атрибут, который определен на
домене поставщика?"
В системе, поддерживающей понятие домена, такой запрос, как видим,
транслируется в простой запрос к каталогу. В системе, которая не поддерживает
домены, очевидно, невозможно обратиться с запросом к каталогу относительно
доменов. Можно обратиться только через атрибуты. Запрос по атрибутам
достигнет указанной цели лишь в том случае, если разработчик базы данных следует
рекомендациям по наименованиям, приведенным выше (другими словами, если он
соблюдает в базе данных порядок по отношению к доменам).
Домены и типы данных
Включение этого раздела вызвано тем, что многие читатели уже вполне готовы
понять следующее: домен — это на самом деле ни больше ни меньше, чем тип
данных (как это понимается в современных языках программирования). Например,
в языке программирования Pascal допустимы следующие выражения:
Здесь мы имеем определенный пользователем тип, названный "Day" (имеющий
в точности семь допустимых значений), и переменную, названную "Today",
принадлежащую этому типу данных (а значит, ограниченную этими семью
значениями). Очевидно, что эта ситуация полностью аналогична ситуации в
реляционной базе данных, когда мы имеем домен, названный "Day", и атрибут,
названный "Today", Более того, существуют языки программирования, например
SIMULA 67, MODULA-2 или Ada (однако Pascal в их число не входит), которые
поддерживают некоторые или даже все функции, обычно приписываемые доменам в
реляционной модели [4.8].
Исходя из того, что домен в своей основе является просто типом данных, было
бы неверно утверждать, что СУБД вовсе не поддерживают доменов. В
действительности системы поддерживают домены в очень примитивном смысле, так
же как они предоставляют определенные встроенные (т.е. определенные системой)
примитивные типы данных, такие как тип целых чисел или тип чисел с плавающей
точкой. Но, если говорить о поддержке доменов в контексте реляционных систем,
мы имеем в виду нечто большее, чем такая примитивная поддержка, а именно то,
что система должна обеспечивать возможность пользователю создавать свои, более
сложные типы данных, такие как "номера поставщиков", "номера деталей",
"названия городов", "цвета" и т.д., а также обеспечивать все возможности для
работы с этими типами.
Что же включают в себя возможности для работы с этими типами? Конечно,
это не только описанные выше сравнения, ограниченные доменами. На самом деле
понятие домена значительно сложнее, чем может показаться с первого взгляда
(именно поэтому многие современные системы и не поддерживают его). Однако из-
за большого объема материала мы некоторое время не будем касаться дальнейших
следствий. Поэтому пока будем предполагать, что поддержка доменов означает
только одно: если два скалярных значения можно сравнивать, то они принадлежат
одному домену. Нужно понимать, что это весьма существенное упрощение, и мы
прибегли к нему, чтобы упростить общее изложение. Дальнейшее обсуждение этого
вопроса приводится в следующих частях книги.
4.3. 4.3. Отношения
А теперь попытаемся точно выяснить, что же такое "отношение". Вначале
следует отметить, что исторически вокруг этого относительно простого понятия
сложилась некоторая двусмысленность (это касается и предыдущих изданий книги).
Причина кроется в отсутствии четкого разграничения между переменными
отношений и значениями отношений. Переменная отношения — это обычная
переменная, такая же как и в языках программирования, т.е. именованный объект,
значение которого может изменяться со временем. А значение этой переменной в
любой момент времени и будет значением отношения. Например, с помощью
выражения
создается переменная отношения с именем s, значение которой в любой момент
времени будет определенным значением отношения.
1[1]
Поэтому обратите внимание, что базовое отношение (или "базовая таблица")—
это не совсем точный термин; более точным, хотя и более громоздким, будет термин
переменная базового отношения. В конце концов, если мы в некотором языке
программирования объявим переменную QTY следующим образом:
то эту переменную мы будем называть не целым числом, а переменной целого типа.
В действительности целыми числами являются значения этой переменной; иначе
говоря, неподходящий термин "целое" используется для обозначения целого
значения. Поэтому далее до конца книги будет использоваться термин "переменная
отношения", когда нужно будет подчеркнуть, что мы имеем в виду собственно
переменную; и будет специально использоваться неудачный термин "отношение"
для обозначения значения отношения. В частности, для краткости и простоты, мы
будем продолжать использовать термин "базовое отношение" чаще, чем термин
"переменная базового отношения" (когда будет сложно их перепутать).
Значения отношений
Вот определение термина "отношение" (специфически обозначающего
значение отношения):
■ ■BBB Отношение R, определенное на множестве доменов D1, D2,..., Dn (не
обязательно различных), содержит две части: заголовок и тело. (Если
представить отношение в терминах таблиц, заголовок — это строка заголовков
столбцов, а тело — это множество строк данных.)
1. 1. Заголовок содержит фиксированное множество атрибутов или, точнее, пар
<имя-атрибута:имя-домена>:
1[1]
Если рассматривать отношения как таблицы, то мы могли бы сказать, что, например,
переменная отношения S в разное время представляет разные таблицы. Однако заметьте, что в
этих разных таблицах будут разные строки, а столбцы будут одинаковые.
{<A1:D1>, <A2:D2>, ..., <A1:Dn>},
причем каждый атрибут Aj соответствует одному и только одному из лежащих в
основе доменов Dj (j= 1,2,..., n). Все имена атрибутов А1, А2,..., An разные.
2. 2. Тело содержит множество кортежей. Каждый кортеж, в свою очередь,
содержит множество пар <имя-атрибута:значение-атрибута>:
{<A1:vi1>, <A2: vi2>, ..., <Аn: vin>}
(i = 1,2, ..., т, где т — количество кортежей в этом множестве). В каждом таком
кортеже есть одна такая пара <имя-атрибута:значение-атрибута>, т.е. <Aj:vij>,
для каждого атрибута Aj в заголовке. Для любой такой пары <Aj:vij> vij является
значением из уникального домена Dj, который связан с атрибутом Aj.
Значения т и п называются соответственно кардинальным числом и
степенью отношения R.
В качестве примера давайте рассмотрим таблицу S из рис. 4.1 (мы умышленно
сейчас не называем ее отношением), чтобы проверить, как она соответствует этому
определению.
■ ■BBB Во-первых, в этой таблице есть четыре основных домена, а именно: домен
номеров поставщиков (S#), домен имен (NAME), домен значений статуса
(STATUS) и домен наименований городов (CITY). (Изображая отношение как
таблицу на листе бумаги, мы обычно не заботимся о том, чтобы показать
лежащие в основе домены, но должны понимать, что, по крайней мере
концептуально, они всегда есть.)
■ ■BBB Далее, в таблице непременно есть две части: строка заголовков столбцов, а
также множество строк данных. Рассмотрим вначале строку заголовков
столбцов:
(S#, SNAME, STATUS, CITY)
Эта строка в действительности представляет набор упорядоченных пар:
Первый компонент каждой пары — это имя атрибута, второй компонент — имя
соответствующего домена. Поэтому можно условиться, что строка заголовков
столбцов действительно представляет собой заголовок.
Замечание. На практике заголовок отношения обычно рассматривают просто
как набор имен атрибутов (т.е. имена доменов часто опускаются), за исключением
случаев, когда очень важна точность. Хотя, возможно, эта практика несколько
небрежна, но она удобна, и мы часто будем ею пользоваться.
■ ■BBB Что касается остальной таблицы, то это; конечно, набор строк. Давайте
сконцентрируем внимание на какой-нибудь одной строке, скажем, на строке
Эта строка в действительности представляет набор упорядоченных пар:
Первый компонент каждой пары — это имя атрибута, второй компонент —
соответствующее значение атрибута. Часто в неформальном описании опускают
имена атрибутов, так как известно, что каждое отдельное значение в таблице в
действительности является значением атрибута, имя которого находится сверху
соответствующего столбца; кроме того, мы знаем, что значение принадлежит
лежащему в основе этого атрибута домену. Например, значение "S1" — это
значение атрибута S#, и оно взято из соответствующего лежащего в основе
домена, а именно домена номера поставщика (который также называется S#).
Таким образом, можно условиться, что каждая строка представляет кортеж в
соответствии с определением.
Исходя из вышесказанного, мы можем согласиться, что таблицу S на рис. 4.1
можно рассматривать как изображение отношения в смысле определения, если мы
условились, как "читать" такое изображение (т.е. если у нас есть определенные
правила интерпретации таких изображений). Иначе говоря, мы должны условиться,
что есть некоторые, лежащие в основе домены; каждый столбец соответствует
только одному из этих доменов; каждая строка представляет кортеж; каждое
значение атрибута принадлежит соответствующему домену и т.д. Если мы приняли
все эти "правила интерпретации", то тогда и только тогда можно говорить, что
таблица — это приемлемое изображение отношения.
Теперь можно сказать, что отношение и таблица — это действительно не одно
и то же (даже хотя в предыдущих главах и предполагалось обратное). Отношение
— это в соответствии с данным ранее определением довольно абстрактный вид
объекта, а таблица — это конкретное изображение (обычно на бумаге) этого
абстрактного объекта. Конечно, они очень близки... и по крайней мере в
неформальном контексте обычно их отождествляют. Но когда мы хотим говорить
более формально и более точно (а теперь мы, конечно, хотим быть более точными),
то должны признать, что эти два понятия не являются в точности идентичными.
(Ведь тот же набор значений отношения можно представить и не в виде
таблицы, а например, в виде перечисляющегося списка. Например, в отделе А
работают Иванов, Петров и Сергеев, а в отделе Б — Григорьев и Николаев. Такое
перечисление не является таблицей (во всяком случае в данном контексте), хотя эти
значения и составляют некое отношение служащих и отделов. — Прим. ред.)
Замечание. Если у вас возникли затруднения с пониманием идеи некоторых
различий между отношением и таблицей, вам может помочь следующее. Во-первых,
одним из неоспоримых преимуществ реляционной модели является то, что ее
основной абстрактный объект, (т.е. отношение) имеет простое представление на
бумаге (т.е. представление в виде таблицы); именно такое представление делает
реляционные системы простыми в использовании и простыми для понимания, а
также облегчает понимание их поведения. Однако, к сожалению, табличное
представление предполагает некоторые неверные факты. К примеру, оно явно
предполагает, что строки таблицы (т.е. кортежи отношения) расположены в
определенном порядке сверху вниз, хотя это неверно. Ниже в этой главе приводится