Главная Случайная страница


Полезное:

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


Категории:

АрхитектураАстрономияБиологияГеографияГеологияИнформатикаИскусствоИсторияКулинарияКультураМаркетингМатематикаМедицинаМенеджментОхрана трудаПравоПроизводствоПсихологияРелигияСоциологияСпортТехникаФизикаФилософияХимияЭкологияЭкономикаЭлектроника






Потенциальные ключи и другие аспекты





Введение

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

Начав с такой необычной преамбулы, продолжим в том же духе. Сначала немного философии.

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

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

3. 3. Следовательно, определение базы данных нуждается в расширении, включающем правила целостности, назначение которых в том, чтобы информировать СУБД о разного рода ограничениях реального мира (таких как ограничение на вес детали, который не может быть отрицательным), а значит, и предотвращать появление таких недопустимых конфигураций значений. В примере с весом детали, конечно, все СУБД должны контролировать операции INSERT и UPDATE на отношении Р, а также отказывать в выполнении операции, если в ней проводится попытка ввести отрицательное значение атрибута веса.

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

■ ■ номера поставщиков должны быть в форме Snnnn, где пппп может принимать значение до четырех десятичных цифр;

■ ■ номера деталей должны быть в форме Рппппп, где ппппп может принимать значение до пяти десятичных цифр;

■ ■ значение статуса поставщика должно быть в диапазоне 1-100;

■ ■ города поставщиков и деталей должны выбираться из определенного списка;

■ ■ цвета деталей должны выбираться из определенного списка;

■ ■ вес деталей должен быть больше нуля;

■ ■ количество при отправке должно быть умножено на 100;

■ ■ все красные детали должны сдаваться на хранение в Лондоне;

■ ■ если город поставщика — Лондон, то статус поставщика должен быть равен 20; и т.д.

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

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

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

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

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

Потенциальные ключи

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

1. 1. Свойством уникальности.

Нет двух различных кортежей в отношении R с одинаковым значением К.

2. 2. Свойством неизбыточности.

Никакое из подмножеств К не обладает свойством уникальности.

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

■ ■ Либо эта комбинация обладает свойством неизбыточности, а значит, будет потенциальным ключом (на самом деле единственным потенциальным ключом).

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

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

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

■ ■ Например, если мы говорим, что комбинация атрибутов {S#, P#} — это потенциальный ключ для базового отношения SP, мы не имеем в виду, что просто в данный момент в отношении нет двух кортежей с одинаковым значением этой комбинации; мы имеем в виду, что для всех возможных отношений R, которые могут быть значениями SP, нет двух различных кортежей отношения R с одинаковым значением этой комбинации. Поэтому для переменных отношения нам нужно дополнить определение потенциального ключа следующим образом (дополнения выделены жирным).

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

1. 1. Свойством уникальности.

Нет двух различных кортежей в текущем значении переменной R с одинаковым значением К.

2. 2. Свойством неизбыточности.

Никакое из подмножеств К не обладает свойством уникальности.

Впредь будем использовать термин "потенциальный ключ" в этом более требовательном значении (за исключением специальных оговорок).

Ниже приведен синтаксис операторов определения потенциального ключа для базового отношения (отметьте, что каждый оператор create base relation должен включать в себя, по крайней мере, одно определение потенциального ключа):

candidate-key-definition

::= CANDIDATE KEY (attribute-commalist)

׀ PRIMARY KEY (attribute-commalist)

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

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

■ ■ Во-первых, хотя на практике отношения чаще всего имеют только один потенциальный ключ, их, конечно же, может быть несколько. Пусть, например, у нас есть отношение ELEMENTS, представляющее таблицу химических элементов. У каждого элемента есть уникальное имя, уникальное обозначение (например, обозначение свинца — "Рb") и уникальное атомное число. Поэтому ясно, что в отношении есть три различных потенциальных ключа:

CREATE BASE RELATION ELEMENTS

(NAME …,

SYMBOL …,

NUMBER …,

… …,

CANDIDATE KEY (NAME)

CANDIDATE KEY (SYMBOL)

CANDIDATE KEY (NUMBER)

■ ■ Во-вторых, заметьте, что потенциальные ключи определены как множества атрибутов. Поэтому при ссылке на них используются "скобки множества", т.е. фигурные скобки. Например, в базе данных поставщиков и деталей {S#} — это потенциальный ключ отношения S, (Р#) — это потенциальный ключ отношения Р, {S#, P#} — это потенциальный ключ отношения SP. Однако в неформальном контексте скобки обычно опускают, если это множество содержит только один атрибут. Поэтому можно сказать, например, что S# (вместо {S#}) — это потенциальный ключ отношения S.

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

Кроме того, понятие неизбыточности требует некоторого уточнения. Дело в том, что, если мы определили "потенциальный ключ", не являющийся неизбыточным, системе не будет известно об этом и потому она не сможет обеспечить должным образом соответствующее ограничение целостности. Пусть, например, мы определили потенциальный ключ отношения S как комбинацию {S#,CITY} вместо S#. Тогда система не сможет соблюдать ограничение, обеспечивающее уникальность номера поставщика в "глобальном смысле"; вместо этого в системе будет выполняться более слабое ограничение, согласно которому номер поставщика будет уникальным в "локальном смысле", т.е. в пределах одного города. Таким образом, настоящие потенциальные ключи не должны включать лишних атрибутов для идентификации уникальности.

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

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

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

Date: 2016-05-25; view: 1091; Нарушение авторских прав; Помощь в написании работы --> СЮДА...



mydocx.ru - 2015-2024 year. (0.006 sec.) Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав - Пожаловаться на публикацию