Сравнения, ограниченные доменом

Часть II

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

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

Как уже отмечалось в главе 3, в реляционной модели рассматриваются три аспекта данных — структура данных (объекты данных), целостность данных и обработка данных (операторы). В этой части книги рассматривается каждый из трех аспектов: в главе 4 обсуждаются объекты, в главе 5 — целостность, в главах 6 и 7 — операторы. (Мы посвятили последней теме две главы, поскольку операционную часть модели можно реализовать двумя различными, но эквивалентными способами, известными соответственно как реляционная алгебра и реляционное исчисление) Назначение главы 8 будет описано ниже.

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

Как отмечалось выше, реляционная модель не очень сложна для понимания. Но она является теорией, а большинство теорий сопровождается своей специальной терминологией, и реляционная модель (по причинам, указанным в главе 3) не является исключением

Глава 4

Реляционные объекты данных: домены и отношений

Вводный пример

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

Итак, вкратце:

■ ■ Отношение соответствует тому, что мы до сих пор называли таблицей.

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

■ ■ Первичный ключ — это уникальный идентификатор для таблицы, т.е. столбец или такая комбинация столбцов, что в любой момент времени не существует двух строк, содержащих одинаковое значение в этом столбце или комбинации столбцов.

■ ■ И наконец, домен — это общая совокупность значений, из которой берутся настоящие значения для определенных атрибутов определенного отношения. Например, домен, обозначенный S# на рис. 4.1 — это множество всех допустимых значений номера поставщика, а множество значений S# в отношении S в любой момент времени является подмножеством этого множества. Точно так же множество значений S# в отношении SP в любой момент времени является подмножеством этого множества.

На рис. 4.2 представлен обзор этих терминов. Этот рисунок требует некоторых пояснений.

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

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

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

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

Теперь перейдем к формальному изложению.

Домены

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

Замечание. Мы мимоходом заметили, что понятие "атомарности скалярных значений" довольно расплывчатое [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 СУБД создает запись в каталоге с описанием этого нового отношения.

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

■ ■ Домены имеют уникальные имена в базе данных.

■ ■ Именованные отношения имеют уникальные имена в базе данных.

■ ■ Атрибуты имеют уникальные имена в содержащем их отношении (даже если содержащее их отношение не именовано!).

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

Можно дополнительно придерживаться другого общего соглашения и полностью опускать ссылку к основному домену из определения любого атрибута, который имеет то же самое имя, что и домен. Например, оператор CREATE BASE RELATION для базового отношения S может быть упрощен:

Удаление доменов. Мы уже знаем, как создать новый домен. Должна также быть возможность удалить существующий домен, если мы больше в нем не нуждаемся:

DESTROY DOMAIN domain;

Здесь domain— это имя удаляемого домена. С помощью этой операции удаляется элемент каталога, описывающий домен, поэтому такой домен становится неизвестным для системы. (До особого указания будем подразумевать, что операция DESTROY DOMAIN просто не будет выполняться, если какое-нибудь базовое отношение в этот момент еще включает атрибут, который определен на указанном домене.)

Запросы, основанные на доменах. Вот другой пример практического значения доменов. Рассмотрим запрос, который формулируется так:

"Какие отношения в базе данных содержат какую-либо информацию, имеющую отношение к поставщикам?"

Этот вопрос может быть сформулирован более точно:

"Какие отношения в базе данных включают атрибут, который определен на домене поставщика?"

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

Date: 2016-05-25; view: 527; Нарушение авторских прав