С.Д. Кузнецов - Основы баз данных (1121716), страница 10

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 10)

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

Иногда также используются термины тбайл как аналог таблицы, запись как аналог строки и поле как аналог столбца. Напомню, что этой терминологией мы пользовались в лекции 1. Фундаментальные свойства отношений Остановимся теперь на некоторых важных свойствах отношений, которые следуют из приведенных ранее определений. Отсутствие кортежей-дубликатов, первичный и возможные ключи отношений То свойство, что тело любого отношения никогда не содержит кортежей-дубликатов, следует из определения тела отношения как множества кортежей.

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

Действительно, поскольку в любое время все кортежи тела любого отношения различны, у любого значения отношения свойством уникальности обладает, по ' Напомним, что Л' является собственным подмножеством множества Л в том н только в том случае, когда л' входит в д но не совпадает с з тато обозначается как л ' ~ я), 42 Лекция 2 Введение в реляционную модель данных крайней мере, полный набор его атрибутов. Однако в формальном определении первичного ключа требуется обеспечение его «минимальностиа, т. е. в набор атрибутов первичного ключа не должны входить такие атрибуты, которые можно отбросить без ущерба для основного свойства — однозначного определения кортежа.

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

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

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

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

Теперь поясним, почему проектировщику следует явно объявлять В лекции ) 2 мы обсудим различия между первичными и возможными ключами в языке Б()).. 43 Курс Основы баз данных первичный и возможные ключи переменных отношений.* Дело в том, что в результате этого объявления СУБД получает информацию, которая в дальнейшем будет использоваться как ограничения целостности.'* СУБД никогда не допустит появления в переменной отношения значения-отношения, содержашего два кортежа с одинаковым значением атрибута ОЛУ НОМЕР (определение первичного ключа для данной переменной отношения отменить нельзя). Появление двух кортежей с одинаковым значением атрибута ОЛУ иня будет также невозможно до тех пор, пока остается в силе определение (слу име) как возможного ключа.

Тем самым объявления первичного и возможных ключей дают СУБД возможность поддерживать целостность базы данных даже в случае попыток занесения в нее некорректных данных. Наконец, вернемся к свойству минимальности первичного и возможных ключей. Как отмечалось выше, это свойство является критически важным, и вазкность проявляется именно при трактовке первичного и возможных ключей как ограничений целостности. В нашем примере с отношением Олужйдие свойством уникальности будет обладать не только множество атрибутов (Олу НОМЕР), но и, например, множество (ОЛу НОМЕР, слу Отд нОмеР).

Но если бы мы выставили в качестве ограничения целостности требование уникальности (слу номеР, Олу Отд номер), то СУБД гарантировала бы отсутствие кортежей с одинаковым значением атрибута СЛУ НОМЕР не во всем значении отношения ОЛУжйцИЕ, а только в группах кортежей с одним и тем же значением атрибута слу От~ МОмер. Понятно, что это не соответствует смыслу моделируемой предметной области. Забегая вперед, заметим, что во многих практических реализациях реляционных СУБД допускается нарушение свойства уникальности кортежей для промежуточных отношений, порождаемых неявно при выполнении запросов. Такие отношения являются не множествами, а мульти- множествами, что в ряде случаев позволяет добиться определенных преимушеств, но часто приводит к серьезным проблемам.

Мы остановимся на этом подробнее при обсуждении языка Я)(.. Отсутствие упорядоченности кортежей Конечно, формально свойство отсутствия упорядоченности кортежей в значении отношения также является следствием определения тела ' Если он является сторонником классического реляционного подхода; в языке ЕОь допускается определение таблиц без первичного и возможных ключей. " Кстати, заметим, что в классической реляционной модели, если при определении переменной отношенИя яВно Не указЫвается ее первичный ключ, то по умолчанию первичным клю юм считается полный набор атрибутов заголовка отношения. Конечно, в этом случае такая переменная отношения может принимать любое значение-отношение, соответствующее заголовку, и первичный ключ нс играет роль ограничения.

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

Но, на мой взгляд, основная причина не в этом. Достаточно часто у пользователей реляционных СУБД и разработчиков информационных систем вызывает раздражение тот факт, что они не могут хранить кортежи отношений на физическом уровне в нужном им порядке. И ссьшки на требования реляционной теории здесь не очень уместны. Можно было бы разработать другую теорию, в которой допускались бы упорядоченные «отношениякь Однако хранить упорядоченные списки кортежей в условиях интенсивно обновляемой базы данных гораздо сложнее технически, а поддержка упорялоченности влечет за собой существенные накладные расходы.

Отсутствие требования к поддержанию порядка на множестве кортежей отношения придает СУБД дополнительную гибкость при хранении баз данных во внешней памяти и при выполнении запросов к базе данных. Это не противоречит тому, что при формулировании запроса к БД, например, на языке ЯЯ. можно потребовать сортировки результирующей таблицы в соответствии со значениями некоторых столбцов. Такой результат, вообще говоря, является не отношением, а некоторым упорядоченным списком кортежей, и он может быть только окончательным результатом, к которому уже нельзя адресовать запросы, Отсутствие упорядоченности атрибутов Атрибуты отношений не упорядочены, поскольку по определению заголовок отношения есть множество пар <имя атрибута, имя домена>.

Характеристики

Список файлов книги