Главная » SQL, Базы данных » Введение в реляционные  базы данных

0

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

■     Структурный аспект. Данные в базе воспринимаются пользователем, как таблицы

(и никак иначе).

■     Аспект целостности. Эти таблицы отвечают определенным условиям целостности

(которые будут рассматриваться в конце раздела).

■     Аспект обработки. В распоряжении пользователя имеются операторы манипулиро вания таблицами (например, предназначенные для поиска данных), которые гене рируют новые таблицы на основании уже имеющихся и среди которых есть, по крайней мере, операторы сокращения (restrict), проекции (project) и объединения (join).

На рис. 3.1 показан простой пример реляционной базы данных отделов (таблица DEPT) и служащих (таблица ЕМР). Очевидно, что эта база данных действительно "воспринимается как набор таблиц" (по-видимому, смысл этих таблиц не требует пояснений). На рис. 3.2 показаны некоторые примеры операций сокращения, проекции и соединения для этой базы данных. Ниже приведены (очень нестрогие!) определения этих операций.

Рис. 3.1. База данных отделов и служащих (приведенные в ней данные часто используются в качестве примера)

■     Операция сокращения извлекает указанные строки из таблицы (в названии этой операции подразумевается, что кардинальность ее результата меньше или равна кардинальности исходной таблицы). Следует отметить, что операцию сокращения иногда называют выборкой; мы предпочитаем термин сокращение, поскольку соот ветствующий оператор не полностью соответствует оператору SELECT языка SQL.

■     Операция проекции предназначена для извлечения определенных столбцов из таб лицы.

а   Операция соединения предназначена для получения комбинации двух таблиц на основе общих значений в общих столбцах.

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

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

Рис. 3.2. Примеры применения операций сокращения, проекции и соединения

Таблица 3.1. Строки таблиц ЕМР и DEPT перед соединением

Таблица 3.2. Результат соединения

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

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

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

Примечание. Если промежуточные результаты материализуются полностью, то  стратегия вычисления выражения в целом называется (что не удивительно) материализованными вычислениями (materialized evaluation); если промежуточные результаты передаются последующей операции по частям, то этот подход называется конвейерными вычислениями (pipelined evaluation).

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

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

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

1 Другими словами, как было отмечено в главе 1, реляционная модель — это действительно только модель; в ней ничего не сказано о реализации.

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

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

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

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

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

На этом завершается тема, связанная со структурой и обработкой данных в реляционной модели. Перейдем к рассмотрению аспекта целостности. Еще раз воспользуемся базой данных отделов и сотрудников, приведенной на рис. 3.1. На практике для такой

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

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

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

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

Более формальное определение

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

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

или истинностное значение).

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

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

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

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

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

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

Источник: Дейт К. Дж., Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом «Вильямс», 2005. — 1328 с.: ил. — Парал. тит. англ.

По теме:

  • Комментарии