Теоретические основы организации БД. Реляционная модель данных.
(http://www.intuit.ru/department/database/rdbintro/)
Подходы к организации баз данных
Иерархические базы данных
В основе данной модели - иерархическая модель данных. В этой модели имеется один главный объект и остальные - подчиненные - объекты, находящиеся на разных уровнях иерархии. Взаимосвязи объектов образуют иерархическое дерево с одним корневым объектом.
Иерархическая БД состоит из упорядоченного набора нескольких экземпляров одного типа дерева. Автоматически поддерживается целостность ссылок между предками и потомками. Основное правило: никакой потомок не может существовать без своего родителя (см.Рис. 1).
Рис. 1 Схема иерархической модели данных
Типичным представителем (наиболее известным и распространенным) является Information Management System (IMS) фирмы IBM. Первая версия появилась в 1968 г. До сих пор поддерживается много баз данных этой системы
Сетевые базы данных
Сетевой подход к организации данных является расширением иерархического. В иерархических структурах запись-потомок должна иметь в точности одного предка; в сетевой структуре данных потомок может иметь любое число предков.
В сетевой модели данных любой объект может быть одновременно и главным, и подчиненным, и может участвовать в образовании любого числа взаимосвязей с другими объектами. Сетевая БД состоит из набора записей и набора связей между этими записями, а если говорить более точно - из набора экземпляров каждого типа из заданного в схеме БД набора типов записи и набора экземпляров каждого типа из заданного набора типов связи (см. Рис. 2).
Рис. 2 Схема сетевой модели
Типичным представителем является Integrated Database Management System (IDMS) компании Cullinet Software, Inc., предназначенная для использования на машинах основного класса фирмы IBM под управлением большинства операционных систем. Архитектура системы основана на предложениях Data Base Task Group (DBTG) Комитета по языкам программирования Conference on Data Systems Languages (CODASYL) - организации, ответственной за определение языка программирования Кобол. Отчет DBTG был опубликован в 1971 г., а позже появилось несколько систем, среди которых IDMS.
Реляционные базы данных
Принято считать, что реляционный подход к организации баз данных был заложен в конце 1960-х гг. Эдгаром Коддом. В последние десятилетия этот подход является наиболее распространенным (с оговоркой, что в называемых в обиходе реляционными системах баз данных, основанных на языке SQL, в действительности нарушаются некоторые важные принципы классического реляционного подхода). Достоинствами реляционного подхода принято считать следующие свойства: реляционный подход основывается на небольшом числе интуитивно понятных абстракций, на основе которых возможно простое моделирование наиболее распространенных предметных областей; эти абстракции могут быть точно и формально определены; теоретическим базисом реляционного подхода к организации баз данных служит простой и мощный математический аппарат теории множеств и математической логики; реляционный подход обеспечивает возможность ненавигационного манипулирования данными без необходимости знания конкретной физической организации баз данных во внешней памяти. Компьютерный мир далеко не сразу признал реляционные системы. В 70-е года прошлого века, когда уже были получены почти все основные теоретические результаты и даже существовали первые прототипы реляционных СУБД, многие авторитетные специалисты отрицали возможность добиться эффективной реализации таких систем. Однако преимущества реляционного подхода и развитие методов и алгоритмов организации и управления реляционными базами данных привели к тому, что к концу 80-х годов реляционные системы заняли на мировом рынке СУБД доминирующее положение.
Реляционная модель данных основывается на математических принципах, вытекающих непосредственно из теории множеств и логики предикатов. Эти принципы впервые были применены в области моделирования данных в конце 1960-х гг. доктором Е.Ф. Коддом, в то время работавшим в IBM, а впервые опубликованы в технической статье "Реляционная модель данных для больших разделяемых банков данных". Эта статья является родоначальницей современной теории реляционных БД. Доктор Кодд определил 13 правил реляционной модели (которые называют 12 правилами Кодда).
12 правил Кодда:
1. Реляционная СУБД должна быть способна полностью управлять базой данных через ее реляционные возможности.
2. Информационное правило - вся информация в реляционной БД (включая имена таблиц и столбцов) должна определяться строго как значения в таблицах.
3. Гарантированный доступ - любое значение в реляционной БД должно быть гарантированно доступно для использования через комбинацию имени таблицы, значения первичного ключа и имени столбца
4. Поддержка пустых значений (null value) - СУБД должна уметь работать с пустыми значениями (неизвестными или неиспользованными значениями), в отличие от значений по умолчанию и независимо для любых доменов.
5. Онлайновый реляционный каталог - описание БД и ее содержания должны быть представлены на логическом уровне как таблицы, к которым можно применять запросы, используя язык базы данных.
6. Исчерпывающий язык управления данными - по крайней мере, один из поддерживаемых языков должен иметь четко определенный синтаксис и быть всеобъемлющим. Он должен поддерживать описание структуры данных и манипулирование ими, правила целостности, авторизацию и транзакции.
7. Правило обновления представлений (views) - все представления, теоретически обновляемые, могут быть обновлены через систему.
8. Вставка, обновление и удаление - СУБД поддерживает не только запрос на отбор данных, но и вставку, обновление и удаление
9. Физическая независимость данных - на программы-приложения и специальные программы логически не влияют изменения физических методов доступа к данным и структур хранилищ данных.
10. Логическая независимость данных - на программы-приложения и специальные программы логически не влияют, в пределах разумного, изменения структур таблиц.
11. Независимость целостности - язык БД должен быть способен определять правила целостности. Они должны сохраняться в онлайновом справочнике, и не должно существовать способа их обойти.
12. Независимость распределения - на программы-приложения и специальные программы логически не влияет, первый раз используются данные или повторно.
13. Неподрывность - невозможность обойти правила целостности, определенные через язык базы данных, использованием языков низкого уровня
Кодд предложил применение реляционной алгебры в СУРБД, для расчленения данных в связанные наборы. Он организовал свою систему БД вокруг концепции, основанной на наборах данных.
Введение в реляционную модель данных
Основные понятия реляционной модели данных
Выделим следующие основные понятия реляционных баз данных: тип данных, домен, атрибут, кортеж, отношение, первичный ключ .
Для начала покажем смысл этих понятий на примере отношения СЛУЖАЩИЕ, содержащего информацию о служащих некоторого предприятия (Рис. 3).
Рис. 3 Соотношение основных понятий реляционного подхода
Тип данных
Значения данных, хранимые в реляционной базе данных, являются типизированными, т. е. известен тип каждого хранимого значения. Понятие типа данных в реляционной модели данных полностью соответствует понятию типа данных в языках программирования. Напомним, что традиционное (нестрогое) определение типа данных состоит из трех основных компонентов: определение множества значений данного типа; определение набора операций, применимых к значениям типа; определение способа внешнего представления значений типа (литералов).
Обычно в современных реляционных базах данных допускается хранение символьных, числовых данных (точных и приблизительных), специализированных числовых данных (таких, как «деньги»), а также специальных «темпоральных» данных (дата, время, временной интервал). Активно развивается подход к внедрению в реляционные системы возможностей определения пользователями собственных типов данных.
В примере на Рис. 3 мы имеем дело с данными трех типов: строки символов, целые числа и «деньги».
Домен
Понятие домена более специфично для баз данных, хотя и имеются аналогии с подтипами в некоторых языках программирования. В общем виде домен определяется путем задания некоторого базового типа данных, к которому относятся элементы домена, и произвольного логического выражения, применяемого к элементу этого типа данных (ограничения домена).
Элемент данных является элементом домена в том и только в том случае, если вычисление этого логического выражения дает результат истина (для логических значений мы будем попеременно использовать обозначения истина и ложь или true и false). С каждым доменом связывается имя, уникальное среди имен всех доменов соответствующей базы данных.
Наиболее правильной интуитивной трактовкой понятия домена является его восприятие как допустимого потенциального, ограниченного подмножества значений данного типа. Например, домен ИМЕНА в нашем примере определен на базовом типе символьных строк, но в число его значений могут входить только те строки, которые могут представлять имена (в частности, для возможности представления русских имен такие строки не могут начинаться с мягкого или твердого знака и не могут быть длиннее, например, 20 символов). Если некоторый атрибут отношения определяется на некотором домене (как, например, на Рис. 3 атрибут СЛУ_ИМЯ определяется на домене ИМЕНА), то в дальнейшем ограничение домена играет роль ограничения целостности, накладываемого на значения этого атрибута.
Следует отметить также семантическую нагрузку понятия домена: данные считаются сравнимыми только в том случае, когда они относятся к одному домену. В нашем примере значения доменов НОМЕРА ПРОПУСКОВ и НОМЕРА ОТДЕЛОВ относятся к типу целых чисел, но не являются сравнимыми (допускать их сравнение было бы бессмысленно).
Заголовок отношения, кортеж, тело отношения, значение отношения, переменная отношения
Понятие отношения является наиболее фундаментальным в реляционном подходе к организации баз данных, поскольку n-арное отношение является единственной родовой структурой данных, хранящихся в реляционной базе данных. Это отражено и в общем названии подхода – термин реляционный (relational) происходит от relation (отношение) . Однако сам термин отношение является исключительно неточным, поскольку, говоря про любые сохраняемые данные, мы должны иметь в виду тип этих данных, значения этого типа и переменные, в которых сохраняются значения. Соответственно, для уточнения термина отношение выделяются понятия заголовка отношения, значения отношения и переменной отношения. Кроме того, нам потребуется вспомогательное понятие кортежа.
Итак, заголовком (или схемой) отношения
r (Hr) называется конечное множество упорядоченных пар вида
Если все атрибуты заголовка отношения определены на разных доменах, то, чтобы не плодить лишних имен, разумно использовать для именования атрибутов имена соответствующих доменов (не забывая, конечно, о том, что это всего лишь удобный способ именования, который не устраняет различия между понятиями домена и атрибута).
Кортежем
tr, соответствующим заголовку Hr, называется множество упорядоченных триплетов вида
Значением Vr отношения r называется пара множеств Hr и Br. Одно из допустимых значений отношения СЛУЖАЩИЕ показано на рис. 2.1.
В данной теме я затрону 6 нормальных форм и методы приведения таблиц в эти формы.
Процесс проектирования БД с использование метода НФ является итерационным и заключается в последовательном переводе отношения из 1НФ в НФ более высокого порядка по определенным правилам. Каждая следующая НФ ограничивается определенным типом функциональных зависимостей и устранением соответствующих аномалий при выполнении операций над отношениями БД, а также сохранении свойств предшествующих НФ.
Используемые термины
Атрибут - свойство некоторой сущности. Часто называется полем таблицы.Домен атрибута - множество допустимых значений, которые может принимать атрибут.
Кортеж - конечное множество взаимосвязанных допустимых значений атрибутов, которые вместе описывают некоторую сущность (строка таблицы).
Отношение - конечное множество кортежей (таблица).
Схема отношения - конечное множество атрибутов, определяющих некоторую сущность. Иными словами, это структура таблицы, состоящей из конкретного набора полей.
Проекция - отношение, полученное из заданного путём удаления и (или) перестановки некоторых атрибутов.
Функциональная зависимость между атрибутами (множествами атрибутов) X и Y означает, что для любого допустимого набора кортежей в данном отношении: если два кортежа совпадают по значению X, то они совпадают по значению Y. Например, если значение атрибута «Название компании» - Canonical Ltd, то значением атрибута «Штаб-квартира» в таком кортеже всегда будет Millbank Tower, London, United Kingdom. Обозначение: {X} -> {Y}.
Нормальная форма - требование, предъявляемое к структуре таблиц в теории реляционных баз данных для устранения из базы избыточных функциональных зависимостей между атрибутами (полями таблиц).
Метод нормальных форм (НФ) состоит в сборе информации о объектах решения задачи в рамках одного отношения и последующей декомпозиции этого отношения на несколько взаимосвязанных отношений на основе процедур нормализации отношений.
Цель нормализации : исключить избыточное дублирование данных, которое является причиной аномалий, возникших при добавлении, редактировании и удалении кортежей(строк таблицы).
Аномалией называется такая ситуация в таблице БД, которая приводит к противоречию в БД либо существенно усложняет обработку БД. Причиной является излишнее дублирование данных в таблице, которое вызывается наличием функциональных зависимостей от не ключевых атрибутов.
Аномалии-модификации проявляются в том, что изменение одних данных может повлечь просмотр всей таблицы и соответствующее изменение некоторых записей таблицы.
Аномалии-удаления - при удалении какого либо кортежа из таблицы может пропасть информация, которая не связана на прямую с удаляемой записью.
Аномалии-добавления возникают, когда информацию в таблицу нельзя поместить, пока она не полная, либо вставка записи требует дополнительного просмотра таблицы.
Первая нормальная форма
Отношение находится в 1НФ, если все его атрибуты являются простыми, все используемые домены должны содержать только скалярные значения. Не должно быть повторений строк в таблице.Например, есть таблица «Автомобили»:
Нарушение нормализации 1НФ происходит в моделях BMW, т.к. в одной ячейке содержится список из 3 элементов: M5, X5M, M1, т.е. он не является атомарным. Преобразуем таблицу к 1НФ:
Вторая нормальная форма
Отношение находится во 2НФ, если оно находится в 1НФ и каждый не ключевой атрибут неприводимо зависит от Первичного Ключа(ПК).Неприводимость означает, что в составе потенциального ключа отсутствует меньшее подмножество атрибутов, от которого можно также вывести данную функциональную зависимость.
Например, дана таблица:
Таблица находится в первой нормальной форме, но не во второй. Цену машины зависит от модели и фирмы. Скидка зависят от фирмы, то есть зависимость от первичного ключа неполная. Исправляется это путем декомпозиции на два отношения, в которых не ключевые атрибуты зависят от ПК.
Таблица находится во 2НФ, но не в 3НФ.
В отношении атрибут «Модель» является первичным ключом. Личных телефонов у автомобилей нет, и телефон зависит исключительно от магазина.
Таким образом, в отношении существуют следующие функциональные зависимости: Модель → Магазин, Магазин → Телефон, Модель → Телефон.
Зависимость Модель → Телефон является транзитивной, следовательно, отношение не находится в 3НФ.
В результате разделения исходного отношения получаются два отношения, находящиеся в 3НФ:
Нормальная форма Бойса-Кодда (НФБК) (частная форма третьей нормальной формы)
Определение 3НФ не совсем подходит для следующих отношений:1) отношение имеет две или более потенциальных ключа;
2) два и более потенциальных ключа являются составными;
3) они пересекаются, т.е. имеют хотя бы один атрибут.
Для отношений, имеющих один потенциальный ключ (первичный), НФБК является 3НФ.
Отношение находится в НФБК, когда каждая нетривиальная и неприводимая слева функциональная зависимость обладает потенциальным ключом в качестве детерминанта.
Предположим, рассматривается отношение, представляющее данные о бронировании стоянки на день:
Тариф имеет уникальное название и зависит от выбранной стоянки и наличии льгот, в частности:
- «Бережливый»: стоянка 1 для льготников
- «Стандарт»: стоянка 1 для не льготников
- «Премиум-А»: стоянка 2 для льготников
- «Премиум-B»: стоянка 2 для не льготников.
Отношение находится в 3НФ. Требования второй нормальной формы выполняются, так как все атрибуты входят в какой-то из потенциальных ключей, а неключевых атрибутов в отношении нет. Также нет и транзитивных зависимостей, что соответствует требованиям третьей нормальной формы. Тем не менее, существует функциональная зависимость Тариф → Номер стоянки, в которой левая часть (детерминант) не является потенциальным ключом отношения, то есть отношение не находится в нормальной форме Бойса - Кодда.
Недостатком данной структуры является то, что, например, по ошибке можно приписать тариф «Бережливый» к бронированию второй стоянки, хотя он может относиться только к первой стоянки.
Можно улучшить структуру с помощью декомпозиции отношения на два и добавления атрибута Имеет льготы , получив отношения, удовлетворяющие НФБК (подчёркнуты атрибуты, входящие в первичный ключ.):
Тарифы
Бронирование
Четвертая нормальная форма
Отношение находится в 4НФ, если оно находится в НФБК и все нетривиальные многозначные зависимости фактически являются функциональными зависимостями от ее потенциальных ключей.В отношении R (A, B, C) существует многозначная зависимость R.A -> -> R.B в том и только в том случае, если множество значений B, соответствующее паре значений A и C, зависит только от A и не зависит от С.
Предположим, что рестораны производят разные виды пиццы, а службы доставки ресторанов работают только в определенных районах города. Составной первичный ключ соответствующей переменной отношения включает три атрибута: {Ресторан, Вид пиццы, Район доставки}.
Такая переменная отношения не соответствует 4НФ, так как существует следующая многозначная зависимость:
{Ресторан} → {Вид пиццы}
{Ресторан} → {Район доставки}
То есть, например, при добавлении нового вида пиццы придется внести по одному новому кортежу для каждого района доставки. Возможна логическая аномалия, при которой определенному виду пиццы будут соответствовать лишь некоторые районы доставки из обслуживаемых рестораном районов.
Для предотвращения аномалии нужно декомпозировать отношение, разместив независимые факты в разных отношениях. В данном примере следует выполнить декомпозицию на {Ресторан, Вид пиццы} и {Ресторан, Район доставки}.
Однако, если к исходной переменной отношения добавить атрибут, функционально зависящий от потенциального ключа, например цену с учётом стоимости доставки ({Ресторан, Вид пиццы, Район доставки} → Цена), то полученное отношение будет находиться в 4НФ и его уже нельзя подвергнуть декомпозиции без потерь.
Пятая нормальная форма
Отношения находятся в 5НФ, если оно находится в 4НФ и отсутствуют сложные зависимые соединения между атрибутами.Если «Атрибут зависит от «Атрибута_2», а «Атрибут_2» в свою очередь зависит от «Атрибута_3», а «Атрибут_3» зависит от «Атрибута_1», то все три атрибута обязательно входят в один кортеж.
Это очень жесткое требование, которое можно выполнить лишь при дополнительных условиях. На практике трудно найти пример реализации этого требования в чистом виде.
Например, некоторая таблица содержит три атрибута «Поставщик», «Товар» и «Покупатель». Покупатель1 приобретает несколько Товаров у Поставщика1. Покупатель 1 приобрел новый Товар у Поставщика2. Тогда в силу изложенного выше требования I поставщик1 обязан поставлять Покупателю1 тот же самый новый Товар, а Поставщик2 должен поставлять Покупателю 1, кроме нового Товара, всю номенклатуру Товаров Поставщика1. Этого на практике не бывает. Покупатель свободен в своем выборе товаров. Поэтому для устранения отмеченного затруднения все три атрибута разносят по разным отношениям (таблицам). После выделения трех новых отношений (Поставщик, Товар и Покупатель) необходимо помнить, что при извлечении информации (например, О покупателях и товарах) необходимо в запросе соединить все три отношения. Любая комбинация соединения двух отношений изгрех неминуемо приведет к извлечению неверной (некорректной) информации. Некоторые СУБД снабжены специальными механизмами, устраняющими извлечение недостоверной информации. Тем не менее следует придерживаться общей рекомендации: структуру базы данных строить таким образом, чтобы избежать применения 4НФ и 5НФ.
Пятая нормальная форма ориентирована на работу с зависимыми соединениями. Указанные зависимые соединения между тремя атрибутами встречаются очень редко. Зависимые соединениямежду четырьмя, пятью и более атрибутами указать практически невозможно.
Доменно-ключевая нормальная форма
Переменная отношения находится в ДКНФ тогда и только тогда, когда каждое наложенное на неё ограничение является логическим следствием ограничений доменов и ограничений ключей, наложенных на данную переменную отношения.Ограничение домена – ограничение, предписывающее использовать для определённого атрибута значения только из некоторого заданного домена. Ограничение по своей сути является заданием перечня (или логического эквивалента перечня) допустимых значений типа и объявлением о том, что указанный атрибут имеет данный тип.
Ограничение ключа – ограничение, утверждающее, что некоторый атрибут или комбинация атрибутов является потенциальным ключом.
Любая переменная отношения, находящаяся в ДКНФ, обязательно находится в 5НФ. Однако не любую переменную отношения можно привести к ДКНФ.
Шестая нормальная форма
Переменная отношения находится в шестой нормальной форме тогда и только тогда, когда она удовлетворяет всем нетривиальным зависимостям соединения. Из определения следует, что переменная находится в 6НФ тогда и только тогда, когда она неприводима, то есть не может быть подвергнута дальнейшей декомпозиции без потерь. Каждая переменная отношения, которая находится в 6НФ, также находится и в 5НФ.Идея «декомпозиции до конца» выдвигалась до начала исследований в области хронологических данных, но не нашла поддержки. Однако для хронологических баз данных максимально возможная декомпозиция позволяет бороться с избыточностью и упрощает поддержание целостности базы данных.
Для хронологических баз данных определены U_операторы, которые распаковывают отношения по указанным атрибутам, выполняют соответствующую операцию и упаковывают полученный результат. В данном примере соединение проекций отношения должно производится при помощи оператора U_JOIN.
Работники
Переменная отношения «Работники» не находится в 6НФ и может быть подвергнута декомпозиции на переменные отношения «Должности работников» и «Домашние адреса работников».
Должности работников
Домашние адреса работников
Литература
Для более глубокого и основательного изучения рассмотренной темы, рекомендуется книга «Введение в системы баз данных» Криса Дж. Дейта, на основе материалов которой и была написана данная статья.Список вопросов по дисциплине «Базы данных и сетевые базы данных»
Понятие и принципы построения баз данных.
БД – это совокупность связанных данных организованных по определенным правилам.
ПРИНЦИПЫ ПОСТРОЕНИЯ БАЗ ДАННЫХ
К современным базам данных, а, следовательно, и к СУБД, на которых они строятся, предъявляются следующие основные требования.
1. Высокое быстродействие (малое время отклика на запрос).
2. Простота обновления данных.
3. Независимость данных.
4. Совместное использование данных многими пользователями.
5. Безопасность данных - защита данных от преднамеренного или непреднамеренного нарушения секретности, искажения или разрушения.
6. Стандартизация построения и эксплуатации БД (фактически СУБД).
8. Дружелюбный интерфейс пользователя.
Реляционная модель. Три аспекта модели. Основные понятия, лежащие в основе реляционной модели.
Реляционная модель данных является удобной и наиболее привычной формой представления данных в виде таблицы.
В отличие от иерархической и сетевой моделей, такой способ представления: 1) понятен пользователю-непрограммисту; 2) позволяет легко изменить схему – присоединять новые элементы данных и записи без изменения соответствующих подсхем; 3) обеспечивает необходимую гибкость при обработке непредвиденных запросов.
Одним из основных преимуществ реляционной модели является ее однородность.
Основными понятиями, с помощью которых определяется реляционная модель, являются следующие: домен, отношение, кортеж, кардинальность, атрибуты, степень, первичный ключ.
Домен – это совокупность значений, из которой берутся значения соответствующих атрибутов определенного отношения. С точки зрения программирования, домен – это тип данных, определяемый системой (стандартный) или пользователем.
Кортеж – таблица.
Кардинальность – количество строк в таблице.
Атрибут – поле, столбец таблицы.
Степень отношения – количество полей, столбцов.
Первичный ключ – это столбец или некоторое подмножество столбцов, которые уникально, т.е. единственным образом определяют строки.
Внешний ключ – это столбец или подмножество одной таблицы, который может служить в качестве первичного ключа для другой таблицы.
Модель предъявляет к таблицам следующие требования:
1.данные в ячейках таблицы должны быть структурно неделимыми;
2.данные в одном столбце должны быть одного типа;
3.каждый столбец должен быть уникальным (недопустимо дублирование столбцов);
4.столбцы размещаются в произвольном порядке;
5.строки размещаются в таблице также в произвольном порядке;
6.столбцы имеют уникальные наименования.
Отношения. Переменные-отношения. Смысл отношений, свойства отношений. Домены.
Домен является наименьшей семантической единицей данных, которая предполагается отдельным значением данных (таким как номер студента, фамилия студента и т.д.). Такие значения называют скалярами. Скалярные значения представляют собой наименьшую семантическую единицу данных в том смысле, что они являются атомарными: в реляционной модели у них отсутствует внутренняя структура. Следует обратить внимание, что отсутствие внутренней структуры при рассмотрении в реляционной модели вовсе не значит, что внутренняя структура отсутствует вообще. Например, название города имеет внутреннюю структуру (оно состоит из последовательности букв) однако, разложив название по буквам мы потеряем значение. Значение станет понятным лишь в том случае, если буквы сложены вместе и в правильной последовательности.
домен – именованное множество скалярных значений одного типа.
Основное значение доменов в том, что домены ограничивают сравнения. Сравнение будет иметь смысл для атрибутов, основанных на одном и том же домене.
Отношения. Свойства и виды отношений
Вокруг понятия "отношение" сложилась некоторая двусмысленность из-за отсутствия четкого разграничения между переменными отношений и значениями отношений. Переменная отношения – это обычная переменная, такая же, как и в языках программирования, т.е. именованный объект, значение которого может изменяться со временем. А значение этой переменной в любой момент будет значением отношения.
Свойства отношений
1. В отношении отсутствуют одинаковые кортежи.
2. Кортежи не упорядочены сверху вниз.
3. атрибуты не упорядочены слева на право.
4. все значения атрибутов атомарные.
Виды отношений
1. Именованное отношение – это переменная отношения, определенная в СУБД посредством операторов создания отношений.
2. Базовым отношением называется именованное отношение, которое не является производным (т.е. базовое отношения является автономным).
3. Производным отношением называется отношение, определенное (посредством реляционного выражения) через другие именованные выражения и, в конечном счете, через базовые отношения.
4. Выражаемое отношение – отношение, которое можно получить из набора именованных отношений посредством некоторого реляционного выражения. Множество всех выражаемых отношений – это в точности множество всех базовых отношений и всех производных отношений.
5. Представление – это именованное производное отношение. Представления, как и базовые отношения являются переменными отношений. Представления виртуальны – они представлены в системе исключительно через определение в терминах других именованных отношений.
6Снимки – это именованные производные отношения, в отличии от представлений являются реальными и представлены в системе не только в виде определений в терминах других именованных отношений, но и своими данными.
7. Результатом запроса называется неименованное производное отношение, служащее результатом некоторого определенного запроса.
8. Промежуточным результатом называется неименованное производное отношение, являющееся результатом некоторого реляционного выражения, вложенного в другое, большее выражение.
9. Хранимое отношение – отношение, которое поддерживается непосредственно в физической памяти.
Ключи переменных-отношений. Виды ключей.
Потенциальные ключи
Пусть R – переменная отношение. По определению множество атрибутов переменной-отношения R обладает свойством уникальности, т.е. в любой момент времени никакие два кортежа не дублируют друг друга. На практике часто некоторое подмножество множества всех атрибутов переменной-отношения R также обладает свойством уникальности.
Пусть K – множество атрибутов переменной-отношения R. В этом случае множество K будет потенциальным ключом переменной-отношения R тогда и только тогда, когда оно обладает следующими свойствами:
а) Уникальность. Никакие допустимые значения переменной-отношения R не содержат двух различных кортежей с одинаковыми значениями атрибутов множества K.
б) Неизбыточность. Никакое из собственных подмножеств множества K не обладает свойством уникальности.
Обращаем внимание на то, что каждая переменная-отношение имеет по крайней мере один потенциальный ключ. Важно следить за соблюдением свойства неизбыточности, так как в случае, если за потенциальный ключ принимается некоторое надмножество множества атрибутов, обладающих свойством уникальности, то система в этом случае будет поддерживать более слабое ограничение целостности и, как результат, будет возможным хранения в переменной-отношении кортежей со одинаковым значением атрибутов, которые в действительности обладают свойством уникальности. По этой причине требуется, чтобы потенциальные ключи не содержали какие-либо атрибуты, которые не имеют отношения к обеспечению его уникальной идентификации.
Возможно, когда переменная-отношение имеет составной ключ, т.е. потенциальный ключ, содержащий более одного атрибута. Потенциальный ключ, состоящий из одного атрибута, называется простым. У одной переменной-отношения может быть несколько потенциальных ключей, причем одни их них могут быть простыми, другие составными.
Суперключом называется некоторое надмножество потенциального ключа. Суперключ обладает свойством уникальности, но не обладает свойством неизбыточности.
12.Реляционные объекты данных. Отношения. Переменная отношения Значения отношения. Синтаксис оператора создания и удаления базового отношения. Структура и свойства отношения. Виды отношений.
Основными понятиями реляционных баз данных являются тип данных, домен, атрибут, кортеж, первичный ключ и отношение.
Типы данных: Как правило, типы данных делятся на три группы: 1) Простые типы данных. 2) Структурированные типы данных. (Массивы, Структуры). 3) Ссылочные типы данных. (указатели).
Реляционная модель требует, чтобы типы используемых данных были простыми (не обладали внутренней структурой).
Домены - это типы данных, имеющие некоторый смысл (семантику). Домен характеризуется следующими свойствами:
Домен имеет уникальное имя (в пределах базы данных).
Домен определен на некотором простом типе данных или на другом домене.
Домен может иметь некоторое логическое условие, позволяющее описать подмножество данных, допустимых для данного домена.
Домен несет определенную смысловую нагрузку.
Кортеж, отношение
Кортеж - это набор именованных значений заданного типа. Отношение - это множество кортежей, соответствующих одной схеме отношения.
Обычным житейским представлением отношения является таблица, заголовком которой является схема отношения, а строками - кортежи отношения-экземпляра; в этом случае имена атрибутов именуют столбцы этой таблицы.
Свойства отношений: 1) В отношении нет одинаковых кортежей. 2) Кортежи не упорядочены (сверху вниз). 3) Атрибуты не упорядочены (слева направо). 4) Все значения атрибутов атомарны.
Реляционной базой данных называется набор отношений. Схемой реляционной базы данных называется набор заголовков отношений, входящих в базу данных.
Теперь обратимся к переменным отношения (relation variable, или сокращенно relvar). Как было отмечено в главе 3, переменные отношения имеют две разновидности - базовые переменные отношения и представления (называемые также, соответственно, реальными и виртуальными переменными отношения). В данном разделе нас в основном интересует именно базовые переменные отношения (представления подробно рассматриваются в главе 10), но следует отметить, что все сказанное здесь применительно к переменным отношения без дополнительного уточнения распространяется на все переменные отношения в целом, включая представления.
Определение базовой переменной отношения
Ниже показан синтаксис определения базовой переменной отношения.
VAR
Параметр
с обозначением типа отношения
RELATION
{
Здесь
параметр
VAR S BASE RELATION
SNAME NAME, STATUS
INTEGER, CITY CHAR
} PRIMARY KEY { S#
VAR P BASE RELATION { Р# Р#, PNAME NAME,
COLOR COLOR, WEIGHT WEIGHT, CITY CHAR }
PRIMARY KEY { P#};
VAR SP BASE RELATION { S# S#, P# P#, QTY QTY }
PRIMARY KEY { S#, P# } FOREIGN KEY { S# }
REFERENCES S FOREIGN KEY { P#
} REFERENCES P ;
Пояснения
1. Эти три базовые переменные отношения имеют следующие типы (отношения).
RELATION { S# S#, SNAME NAME, STATUS INTEGER, CITY CHAR } RELATION { P# P#, PNAME NAME, COLOR COLOR,
WEIGHT WEIGHT, CITY
CHAR } RELATION { S# S#, P# P#, QTY QTY }
2. Все термины заголовок, тело, атрибут, кортеж, степень (и т.д.), которые были пе ред этим определены для значений отношения, интерпретируются также очевид ным образом применительно к переменным отношения.
3. Все возможные значения любой отдельно взятой переменной отношения принадлежат к одному и тому же типу отношения, а именно к типу отношения, указанному в определении переменной отношения (указанному косвенно, если данная переменная отношения является представлением), и поэтому имеют одинаковый заголовок.
4. При определении базовой переменной отношения ей присваивается начальное зна чение, которое является пустым отношением соответствующего типа.
5. Определения потенциальных ключей подробно рассматриваются в главе 9, а на данный момент мы будем просто предполагать, что определение каждой базовой переменной отношения включает одно и только одно определение потенциаль ного ключа,<candidate key def> в следующей конкретной форме.
PRIMARY
KEY {
6. Определения внешнего ключа также рассматриваются в главе 9.
7. Ввод определения новой переменной отношения вынуждает систему внести в свой каталог записи с описанием этой переменной отношения.
8. Как было отмечено в главе 3, переменные отношения, как и отношения, имеют соответствующий предикат. Таковым является предикат, общий для всех отноше ний, которые представляют собой возможные значения рассматриваемой пере менной отношения. Например, в случае переменной отношения поставщиков S предикат выглядит примерно следующим образом.
Поставщик с номером поставщика S# работает по контракту, имеет имя SNAME и статус STATUS, а также находится в городе CITY
9. Предполагается, что предусмотрены средства определения применяемых по умолчанию значений для атрибутов базовых переменных отношения. Применяемым по умолчанию значением заданного атрибута является такое значение, которое должно быть помещено в позицию соответствующего атрибута, если пользователь явно не предоставит нужное значение при вставке некоторого кортежа. Подходящая синтаксическая конструкция языка Tutorial D для определения применяемых по умолчанию значений может принимать форму новой конструкции в определении базовой переменной отношения, скажем, DEFAULT
Синтаксис оператора создания и удаления базового отношения
CREATE VIEW ТОРЕМР AS
) { EMP#, ENAME, SALARY } ;
(EMP WHERE SALARY > 3 3K
Примечание . Поскольку в данный момент это несущественно, в примере для удобства используется смешанная нотация языков SQL и Tutorial D.
При выполнении этого оператора выражение, следующее за ключевым словом AS и
фактически определяющее представление, не вычисляется, а просто запоминается системой (обычно посредством сохранения в каталоге под указанным именем ТОРЕМР). Однако с точки зрения пользователя все выглядит так, как будто в базе данных появилась вполне
реальная переменная отношения с именем ТОРЕМР, имеющая текущее значение, которое показано на рис. 3.7 только в незатененных участках. И пользователь должен иметь возможность оперировать этим представлением точно так, как если бы оно являлось обычной базовой переменной отношения.
В качестве другого примера рассмотрим операцию удаления DELETE.
DELETE TOPEMP WHERE SALARY < 42K ;
На самом деле будет выполнена следующая операция.
DELETE EMP WHERE SALARY > ЗЗК AND SALARY < 42К;
Рассматриваемое здесь представление ТОРЕМР является очень простым, состоящим (выражаясь неформально) из подмножества строк и столбцов единственной базовой переменной отношения. Однако, в принципе, определение представления может иметь произвольную сложность (оно может даже ссылаться на другие представления). Например, далее приведено представление, определение которого включает соединение двух базовых переменных отношения.
CREATE VIEW JOINEX AS
((EMP JOIN DEPT) WHERE BUDGET > 7M) { EMP#, DEPT# } ;
К вопросу определения и обработки представлений мы еще вернемся в главе 10. Между прочим, сейчас уже можно объяснить смысл приведенного в конце раздела 2.2 замечания, касающегося того, что термин представление (view) в реляционном контексте имеет довольно специфическое значение, не совпадающее со значением, приписанным ему в архитектуре ANSI/SPARC. На внешнем уровне этой архитектуры база данных воспринимается как внешнее представление, определяемое внешней схемой (и разные пользователи могут иметь разные внешние представления). В реляционных системах, наоборот, представление, как пояснялось выше, является специально именованной производной виртуальной переменной отношения. Поэтому реляционным аналогом внешнего представления ANSI/SPARC обычно служит множество из нескольких переменных отношения, каждая из которых является представлением в реляционном смысле. Внешняя схема состоит из определений таких представлений. (Из этого следует, что в реляционной модели представления являются одним из способов обеспечения логической независимости от данных, хотя еще раз следует отметить, что современные коммерческие продукты имеют серьезные недостатки в этой части. Подробности приведены в главе 10.)
Типы отношений
И наконец дадим определение отношению, как некой вершине пирамиды, состоящей из всех предыдущих понятий. Итак, отношение (обозначается r , от англ. relation – «отношение») со схемой отношений S определяется как обязательно конечное множество кортежей, имеющих ту же схему отношения S. Таким образом:
r ≡ r(S) = {t(S) | t ∈ r};
По аналогии со схемами отношений количество кортежей в отношении называют мощностью отношений и обозначают как мощность множества: |r |.
Отношения, как и кортежи, различаются по типам. Итак, отношения называются:
1) частичными , если для любого входящего в отношение кортежа выполняется следующее условие: .
Это (как и с кортежами) общий случай;
2) полными , в том случае если ∀ t ∈ r(S) выполняется: ;
3) неполными , если ∃t ∈ r(S) def(t) ⊂ S;
4) нигде не определенными , если ∀t ∈ r(S) .
Обратим отдельное внимание на нигде не определенные отношения. В отличие от кортежей работа с такими отношениями включает в себя небольшую тонкость. Дело в том, что нигде не определенные отношения могут быть двух видов: они могут быть либо пустыми, либо могут содержать единственный нигде не определенный кортеж (такие отношения обозначаются {∅(S)}).
Сравнимыми (по аналогии с кортежами), т. е., возможно равными, являются лишь отношения с одной и той же схемой отношения. Поэтому отношения с различными схемами отношений являются различными.
В табличной форме представления, отношение – это тело таблицы, которому соответствует строка – заголовок столбцов, т. е. буквально – вся таблица, вместе с первой строкой, содержащей заголовки.
114 Часть I. Основные понятия
3.5. ОПТИМИЗАЦИЯ
Как было описано в разделе 3.2, все реляционные операции, такие как сокращение, проекция и соединение, выполняются на уровне множеств. Поэтому реляционные языки часто называютнепроцедурными, так как пользователь указывает,что делать, а некак делать. Фактически пользователь сообщает лишь, что ему нужно, без указания процедуры получения результата. Процесснавигации (перемещения) по хранимой базе данных в целях удовлетворения запроса пользователя выполняется системой автоматически, а не пользователем вручную. Поэтому реляционные системы иногда называют системамиавтоматической навигации. В нереляционных системах за навигацию по базе данных в основном несет ответственность сам пользователь. На рис. 3.5 приведена яркая иллюстрация преимуществ автоматической навигации - оператору языка SQL INSERT противопоставлен код навигации, подготовленный "вручную". Для получения того же результата подобный код, вероятно, должен быть подготовлен пользователем любой нереляционной системы (в данном случае - сетевой системы CODASYL; пример взят из главы по сетевым базам данных в ). Следует отметить, что здесь в качестве примера снова используется база данных деталей и поставщиков. За подробностями обратитесь к разделу3.9.
Несмотря на предыдущие замечания, следует отметить, что непроцедурный - это хотя и общепринятый, но не совсем точный термин, потому чтопроцедурный инепроцедурный - понятия относительные. Обычно можно с уверенностью определить лишь то, является ли язык А более (или менее) процедурным, чем язык Б. Поэтому точнее будет сказать, что реляционные языки, такие как SQL, характеризуютсяболее высоким уровнем абстракции, чем типичные языки программирования, подобные C++ или COBOL (либо подъязыки данных, обычно принадлежащие нереляционным СУБД; см. рис. 3.5). В принципе, именно более высокий уровень абстракции способствует повышению продуктивности труда программистов, свойственному для реляционных систем.
Ответственность за организацию выполнения автоматической навигации возложена на очень важный компонент СУБД - оптимизатор (мы уже упоминали о нем в главе 2). Другими словами, работа оптимизатора заключается в том, чтобы выбрать самый эффективный способ выполнения для каждого запроса пользователя. Предположим, например, что пользователь сделал следующий запрос (снова воспользуемся языком Tutorial D).
(EMP WHERE ЕМР# = ЕМР# ("Е4")) { SALARY }
Пояснение. Выражение в первых скобках (EMP WHERE ...) означает, что применяется операция сокращения текущего значения переменной отношения ЕМР, касающаяся той строки, в которой значение столбца ЕМР# равно Е4. Применяемая здесь языковая конструкция, представляющая собой имя столбцаSALARY , заключенное в фигурные скобки, означаетпроекцию результата операциисокращения по столбцуSALARY . Результатом этой операции проекции становится отношение, состоящее из одного столбца и одной строки, которое содержит данные о заработке служащего Е4. (Обратите внимание, что в данном случае в неявном виде используется реляционное свойствозамкнутости: мы написали вложенное выражение, в котором результат операции сокращения применяется в качестве входных данных для операции проекции.)
Рис. 3.5. Примерыавтоматическойнавигацииинавигациивручную
Дажевэтомпростомпримеремогутприменятьсяпокрайнеймередваспособадоступа к необходимым данным.
1. Последовательный физический просмотр (хранимой версии) переменной отношения ЕМР, пока требуемая запись не будет найдена.
2. Если есть индекс для столбца ЕМР # (в хранимой версии) переменной отношения (который, вероятно, действительно существует, поскольку этот столбец является уникальным, а большинство систем фактическитребует создания индекса для обеспечения уникальности), то переход с помощью этого индекса непосредствен но к данным служащего с номером Е4.
Оптимизатор определит, какую из двух возможных стратегий следует применить. В общем случае для реализации любого конкретного реляционного запроса оптимизатор будет осуществлять выбор стратегии, исходя из соображений, подобных следующим:
116 Часть I. Основные понятия
■ на какие переменные отношения есть ссылки в запросе;
■ насколько велики эти переменные отношения в настоящее время;
■ какие существуют индексы;
■ насколько избирательны эти индексы;
■ как физически группируются данные на диске;
■ какие реляционные операции используются; и т.д.
Поэтому повторяем: пользователь указывает в запросе, какие данные ему требуются, а некак их получить, тогда как стратегия доступа к данным выбирается оптимизатором (автоматическая навигация). В результате пользователи и пользовательские программы становятся независимыми от применяемых стратегий доступа, что, конечно же, совершенно необходимо, если мы хотим достичь реальной независимости от физического представления данных.
Более подробные сведения об оптимизаторе приводятся в главе 18.
3.6. КАТАЛОГ
Как отмечалось в главе 2, каждая СУБД должна поддерживать функции каталога, илисловаря. Каталог обычно размещается там, где хранятся различные схемы (внешние, концептуальные, внутренние) и все, что относится к отображениям ("внешнийконцептуальный", "концептуальный-внутренний", "внешний-внешний"). Иначе говоря, в каталоге содержится подробная информация (иногда называемаяописательной информацией илиметаданными), касающаяся различных объектов, которые имеют значение для самой системы. Примерами таких объектов могут служить переменные отношения, индексы, ограничения поддержки целостности, ограничения защиты и т.д. Описательная информация необходима для обеспечения правильной работы системы. Например, оптимизатор использует информацию каталога об индексах и других физических структурах хранения данных, а также прочую информацию, необходимую ему для принятия решения о том, как выполнить тот или иной запрос пользователя (см. главу 18). Аналогично, подсистема защиты использует информацию каталога о пользователях и установленных ограничениях защиты (глава 17), чтобы разрешить или запретить выполнение поступившего запроса.
Замечательным свойством реляционных систем является то, что их каталог также состоит из переменных отношения (точнее, изсистемных переменных отношения, на-
званных так для того, чтобы отличать их от обычных пользовательских). В результате пользователь может обращаться к каталогу так же, как к своим данным. Например, в каталоге любой системы SQL обычно содержатся системные переменные отношения TABLES и COLUMNS, назначение которых - описание известных системе таблиц (т.е. переменных отношения) и столбцов этих таблиц. Для базы данных отделов и служащих переменные отношения4 TABLES иCOLUMNS могут быть схематически представлены в виде иерархической структуры так, как показано на рис. 3.6.
4 Отметим, что исходя из наличия на этом рисунке столбца ROWCOUNT, можно сделать следующее за ключение: выполнение в базе данных операций INSERT и DELETE в качестве побочного эффекта потре бует обновления данных каталога. На практике столбец ROWCOUNT обычно обновляется только по спе циальному запросу (например, при запуске некоторой утилиты), поэтому значения этого столбца не всегда будут актуальными.
Рис. 3.6. Каталог базы данных отделов и служащих (изображен схематически)
Примечание. Как упоминалось в главе 2, каталог должен также описывать сам себя, т.е. включать записи, описывающие переменные отношения самого каталога (см. упр. 3.3).
Теперь предположим, что пользователю базы данных отделов и служащих понадобилось узнать, какие именно столбцы содержит переменная отношения DEPT (конечно, предполагается, что по каким-то причинам пользователь не имеет этой информации). Тогда необходимое выражение будет выглядеть следующим образом.
(COLUMNS WHERE TABNAME = "DEPT") { COLNAME }
Вот еще один пример. Пусть необходимо узнать, в каких переменных отношения есть столбецЕМР#.
(COLUMNS WHERE COLNAME = "ЕМР#") { TABNAME }
Упражнениедлясамопроверки. Каким будетрезультатвыполнения следующего выражения?
((TABLES JOIN COLUMNS)
WHERE COLCOUNT < 5) { TABNAME, COLNAME }
3.7. БАЗОВЫЕ ПЕРЕМЕННЫЕ ОТНОШЕНИЯ И ПРЕДСТАВЛЕНИЯ
Мы уже видели, что на основе реляционных значений, присвоенных некоторому множеству переменных отношения, подобных DEPT и ЕМР , реляционные выражения позволяют получить множество других значений отношений, например, в результате соединения двух переменных отношения. Теперь необходимо ввести еще несколько новых терминов. Исходные (заданные) переменные отношения называютсябазовыми переменными отношения, а присвоенные им значения называютсябазовыми отношениями. Отношение, которое получено или может быть получено из базового отношения в результате выполнения каких-либо реляционных выражений, называетсяпроизводным отношением.
118 Часть I. Основные понятия
Примечание. В базовые переменные отношения называютсяреальными переменными отношения.
Реляционные системы, очевидно, должны предоставлять средства для создания, в первую очередь, базовых переменных отношения. В языке SQL, например, эта функция обеспечивается оператором CREATE TABLE (здесь слово TABLE используется в узком смысле, какбазовая переменная отношения). Базовые переменные отношения, конечно же, должны бытьименованными, как, например, показано ниже.
CREATE TABLE EMP ... ;
Однако реляционные системы обычно поддерживают еще один вид именованных переменных отношения, называемых представлениями. В любой конкретный момент их значение являетсяпроизводным отношением (и поэтому упрощенно можно считать, что представление - этопроизводная переменная отношения). Значение данного представления в данное время является результатом вычисления определенного реляционного выражения в данный момент, а упомянутое реляционное выражение определяется в момент создания этого представления. Например, для определения представления ТОРЕМР можно использовать следующий оператор.
CREATE VIEW ТОРЕМР AS
(EMP WHERE SALARY > 3 3K
) { EMP#, ENAME, SALARY } ;
Примечание. Поскольку в данный момент это несущественно, в примере для удобства используется смешанная нотация языков SQL и Tutorial D.
При выполнении этого оператора выражение, следующее за ключевым словом AS и фактически определяющее представление, не вычисляется, а простозапоминается системой (обычно посредством сохранения в каталоге под указанным именем ТОРЕМР). Однако с точки зрения пользователя все выглядит так, как будто в базе данных появилась вполне реальная переменная отношения с именемТОРЕМР , имеющая текущее значение, которое показано на рис. 3.7 только в незатененных участках. И пользователь должен иметь возможность оперировать этим представлением точно так, как если бы оно являлось обычной базовой переменной отношения.
Рис. 3.7. Виртуальная переменная отношения ТОРЕМР (незатененные участки) как представление базовой переменной отношения ЕМР
Примечание. Выше уже было сказано, что если такие переменные отношения, какDEPT и ЕМР, можно считатьреальными, то переменную отношения ТОРЕМР следует рассматривать каквиртуальную переменную отношения, иначе говоря, как переменную отношения, которая внешне существует как таковая, но на самом деле ее нет (значение этой переменной отношения в любой данный момент зависит от значений некоторых
других переменных отношения). И действительно, в представления называются
виртуальными переменными отношения.
Однако будьте внимательны: отмечая, что значение переменной отношения ТОРЕМР является отношением, которое было бы результатом, если бы определяющее данное представление выражение было на самом деле вычислено, мы вовсе не хотим сказать, что существует отдельная копия этих данных. Иначе говоря, мы вовсе не имеем в виду, что выражение, определяющее представление, действительно вычисляется. Наоборот, представление - это по сути простоокно, через которое можно видеть часть значения базовой переменной отношения ЕМР. Отсюда следует, что любые изменения в базовой переменной отношения будут автоматически и немедленно поступать в подобное окно (конечно, если эти изменения относятся к незатененной части реальной переменной отношения). Аналогично, изменения, внесенные в переменную отношения ТОРЕМР, будут автоматически и немедленно применены к реальной переменной отношения ЕМР и, следовательно, станут видны через это окно (примеры будут приведены позднее).
Ниже показан пример запроса, использующего представление TОРЕМР.
(ТОРЕМР WHERE SALARY < 42К) { ЕМР#, SALARY }
Если в качестве исходных используются данные на рис. 3.7, то результат будет иметь вид, показанный на рис. 3.8.
Рис. 3.8. Результат использования представления ТОРЕМР
С концептуальной точки зрения операции с представлениями, подобные рассмотренной выше, аналогичны операциям поиска, которые фактически реализуются посредством замены ссылки на имя представления выражением, которое определяет представление (т.е. выражением, сохраненным в каталоге). Поэтому в рассмотренном примере исходное выражение
(ТОРЕМР WHERE SALARY < 42К) { ЕМР#, SALARY }
модифицируется системой следующим образом.
(((ЕМР WHERE SALARY > ЗЗК) { ЕМР#, ENAME, SALARY })WHERE SALARY < 42К) { ЕМР#, SALARY }
Здесь курсивом выделено имя представления в исходном выражении и заменяющий текст в модифицированной версии. После определенного количества перегруппировок это выражение может быть упрощено (глава 18) и представлено в следующем виде.
(ЕМР WHERE SALARY > ЗЗК AND SALARY < 42К) { ЕМР#, SALARY }
Вычисление данного выражения приводит к результату, показанному выше. Иными словами, первоначальная операция над представлением просто преобразуется в эквивалентную операцию над соответствующей базовой переменной отношения, после чего
120 Часть I. Основные понятия
полученная эквивалентная операция выполняется обычным образом (точнее, оптимизируется и выполняется обычным образом).
В качестве другого примера рассмотрим операцию удаления DELETE .
DELETE TOPEMP WHERE SALARY < 42K ;
На самом деле будет выполнена следующая операция.
DELETE EMP WHERE SALARY > ЗЗК AND SALARY < 42К;
Рассматриваемое здесь представление ТОРЕМР является очень простым, состоящим (выражаясь неформально) из подмножества строк и столбцов единственной базовой переменной отношения. Однако, в принципе, определение представления может иметь произвольную сложность (оно может даже ссылаться на другие представления). Например, далее приведено представление, определение которого включает соединение двух базовых переменных отношения.
CREATE VIEW JOINEX AS
((EMP JOIN DEPT) WHERE BUDGET > 7M) { EMP#, DEPT# } ;
К вопросу определения и обработки представлений мы еще вернемся в главе 10. Между прочим, сейчас уже можно объяснить смысл приведенного в конце раздела 2.2 замечания, касающегося того, что термин представление (view) в реляционном контексте имеет довольно специфическое значение, не совпадающее со значением, приписанным ему в архитектуре ANSI/SPARC. На внешнем уровне этой архитектуры база данных воспринимается каквнешнее представление, определяемое внешней схемой (и разные пользователи могут иметь разные внешние представления). В реляционных системах, наоборот, представление, как пояснялось выше, является специальноименованной производной виртуальной переменной отношения. Поэтому реляционным аналогомвнешнего представ-
ления ANSI/SPARC обычно служит множество из нескольких переменных отношения, каждая из которых является представлением в реляционном смысле.Внешняя схема состоит из определений таких представлений. (Из этого следует, что в реляционной модели представления являются одним из способов обеспечениялогической независимости от данных, хотя еще раз следует отметить, что современные коммерческие продукты имеют серьезные недостатки в этой части. Подробности приведены в главе 10.)
Архитектура ANSI/SPARC является достаточно общей и допускает произвольные преобразования между внешним и концептуальным уровнями. В принципе, даже типы структур данных, поддерживаемые на этих двух уровнях, могут быть различными: например, концептуальный уровень может быть реляционным, тогда как конкретному пользователю может быть передано внешнее представление иерархического типа5 . Однако на практике в большинстве систем в качестве базовых на обоих уровнях используются одинаковые типы структур. Реляционные продукты не являются исключением из этого общего правила - представление по-прежнему остается переменной отношения, как и базовые переменные отношения. А поскольку на обоих уровнях поддерживаются одинаковые типы объектов, на этих уровнях применяется один и тот же подъязык данных (обычно это язык SQL). Действительно, тот факт, что представление - это переменная
5 Пример осуществления такой возможности приведен в главе 27.
отношения, так же важен для реляционных систем, как для математики важно то, что подмножество является множеством.
Примечание. Однако, по-видимому, в документации к реальным продуктам SQL и в самом стандарте языка SQL этот нюанс часто игнорируется (глава 4), поскольку нередко можно встретить упоминания о "таблицах и представлениях" (т.е. при этом подразумева ется, что представление не является таблицей). Советуемне делать этой распространен ной ошибки и использовать терминтаблицы (илипеременные отношения) лишь для обо значениябазовых таблиц(илибазовыхпеременныхотношения).
Есть еще один заслуживающий внимания вопрос, касающийся базовых переменных отношения и представлений. Различие между базовой переменной отношения и представлением часто характеризуют следующим образом.
■ Базовые переменные отношения "реально существуют" в том смысле, что они во площают в себе данные, которые действительно хранятся в базе данных.
■ Представления, наоборот, "реально не существуют", а просто предоставляют раз личные способы просмотра "реальных" данных.
Однако такая характеристика, хотя и полезна в неформальном смысле, неточно отражает истинное положение дел. Действительно, пользователи могут рассматривать базовые переменные отношения как физически хранимые, поскольку фактически главная цель создания реляционных систем состоит в том, чтобы дать возможность пользователю работать с базовыми переменными отношения как с физически существующими, не заботясь о том, как эти переменные отношения физически представлены в памяти. Но (и это весьма существенное "но"!) подобные взгляды пользователей на то, как происходит обработка данных,нельзя толковать так, будто базовая переменная отношения - это непосредственно физически хранимая переменная отношения (например, как единственный хранимый файл). Как пояснялось в разделе 3.2, базовые переменные отношения лучше всего представлять какабстракцию для некоторого набора хранимых данных - абстракцию, скрывающую все детали уровня хранения данных. В принципе, базовая переменная отношения иеехранимыйэквивалент6 могутразличаться впроизвольнойстепени.
Этот вопрос поможет прояснить простой пример. Снова рассмотрим базу данных отделов и служащих. В большинстве современных реляционных систем она, вероятно, была бы реализована в виде двух хранимых файлов, по одному для каждой переменной отношения базы данных. Но нет абсолютно никаких доводов против создания одного хранимого файла иерархически хранимых записей, каждая из которых состоит, во-первых, из номера отдела, названия и бюджета для некоторого отдела, и, во-вторых, вместе с ними заданы табельный номер служащего, фамилия и зарплата каждого служащего, работающего в этом отделе. Иначе говоря, для физического хранения данных может быть использован любой подходящий способ (дополнительные сведения приведены в приложении А), но на логическом уровне данные всегда должны выглядеть одинаково.
6 Следующая цитата из одной недавно вышедшей книги демонстрирует некоторые недоразумения, обсуждаемые здесь, а также недоразумения, которые обсуждались в разделе 3.3: "Важно различать хранимые отношения, которые являютсятаблицами, и виртуальные отношения, которые являютсяпредставлениями... [Мы] будем использовать терминотношение только в тех случаях, когда вместо него можно использовать термин «таблица» или «представление». Если необходимо будет подчеркнуть, что данное отношение является хранимым отношением, а не представлением, то в этом случае мы будем использовать терминбазовое отношение илибазовая таблица." Подобные цитаты, к сожалению, - не редкость.
