3-5-2 Ключи для отношений

Множество атрибутов {/)[./Ii.....А } является кяючом для отношения R, еали:

1, Эти атрибуты функционально определяют все остальные ат1эи6уты данного отношения, т.е. два различных кортежа R не могут совпадать по всем атрибутам Aj.....Л .

2. Ни одно собственное полмножество множества {Ai, Ai.....А ) функционально не определяет все остальные атрибуты R, т.е. ключ должен быть минимальным.

Если ключ состоит из единственного атрибута А, часто говорят, что А (а не \А\) есть ключ.

Пример 3.21. Атрибуты {title, year, startame} формируют ключ для отношения Movie на рнс. 3.27. Во первых, нужно показать, что они функционально определяют все оста/гьные атрнбуты. Допустим, два кортежа совпадают по этим трем атрибутам. Поскольку они совпадают по title и year, они должны совпадать и по остальным атрибутам: lengtti, filmType и studioName (что бьшо показа!ю в примере 3.20). Значит, два разных кортежа не могут совпадать по title, year и starName, так как в случае такого совпадения онн фактически были бЬ[ одним и те,ч же кортежем.

Теперь нуж1го доказать, что ни одно собственное псдмножество множества (title, year, StarName} функционально не определяет все остальные атрибуты. Действительно, title и year не определяют starName, поскольку во f.fhortix фильмах участвуют несколько кинозвез.ч. Значот. {ttle, year} не является ключом.

{year, starName} ие является ключом потому, что одна кинозвезда может участ-bomitb в двух фнльмач. снятых в опном и том же юлу. Следовательно,

year StarName -> title

не яв;гяегся функционально!* зависимостью Можно также сказать, что {title, StarName} не являегся ключом потому, что в разные голы могут бь.ть сняты два

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

Функциональные зависимости относятся к схемам

ПомН1Гге, что функциональная зависимость, подобно любому ограииче- j

I нию, является утверждением о схеме отношения, а не об отдельном ее экзем- i

I пляре. По отдельному экземгшяру нельзя определить, верна ли дли него S

I функциональная зависимость. Например, глядя на рис. 3 27. можно предполо- j

5 жить, что ecTii зависимость типа title - filmType, так как для каждого кортежа ;

и этом экземпляре отношения верно, что любые два кортежа, совпадающие по i

title, совпадают и но filmType. i

Однако нельзя утверждать, что эта функциональная зависимость верна ]

для отношения Movie. Напри.мер, если его экземпляр содержит кортежи j

двух версий Книг Кинга - цветной и черно белой, данной функциональной \

зависимости нет.

Функциональное в функциональных зависимостях

А, А2... -> В называется функциональной зависимостью, потому что, п принципе, это функция, которая из списка значений, содержащего по одно- \ му значению для каждого из атрибутов И И .... порождает уникальное j значение для В (или не порождает никакого). Например, можно представить i себе функцию в отношении Movie, которая из строки Star Wars и числа 1977 порождает уникальное значение лля lengtli, а именно, число 124, появляющееся в этом же отношении Movie. Но такая зависимость не является обычной .математической функцией, так как ее невозможно вычислить из исходных данных. Другими словами, нельзя получить правильную длину фильма, f выполнив какие-то операции на строках типа Star Wars и числах типа 1977. ( Эта функция вычисляется путем просмотра отношения: мы смотрим на кортеж j с заданнь[ми title и year и видим, какое значение он имеет для lengtli. i

3-5-3 Надключи

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

Пример 3.22. В от1гошснии из примера 3.2! много надключей. Ими являются не только ключ

{title, year. starName}. но и любое надмножество этого множества атрибутов, например

{title, year, staitlame, length}. □

3-5-4 Обнаружение ключей для отношений

Когда при конвергировании ODL ilih E/R-проекта в отношение строится реляционная с\ема, обычно можно заранее сказать, каким будет ключ этого отношения. В данном разделе рассматриваются отношения, полученные из E/R-диаграмм, а в следующем - из ODL-проектов,

А Помните, что функциональные завнси.мости - это допушсиня или 1тверждения, касаюшнсея данных. Не еушествуст внешнего апторитега, способного выносить окончательное решение го поводу нялкчия или отсутствия функциональной jamicilmceni, Поэто.чу в нашей no.:ie принимать любые разумные решения о том, какая функипональиая jaiiiioilvioetb верна.

фильма с олммм и тем же названием. Возможно даже, что в этих фильмах участвовала одна и та же кинозвезда. П

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

Дртгая термииологш, относящаяся к ключам

: В некоторых книгах и статьях к.пючи описываются в другой терминоло-

\ гии. Иногда термином ключ обозначается то. что мы называем надключом .

i т.е. множество атрибутов, функционально опревеляюшее все атрибуты без

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

5 потенциальный ключ ( candidate key ).

Первое правило введения ключей:

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

Пример 3.23. В примерах 3.10 и 3.11 показано, как множества сущностей Movies и Stars конвертируются в отношения. Ключами этих множеств являются {title, year] и {кате} соответственно. Значит, они являются также ключами соответствующих отношений, имеющих следующие схемы:

MoviesCtitle. year, length, filmType) Stars(riame, eddress)

D которых ключи подчеркнуты. □

Второе правило относится к бинарным связям Если отношение R строется из связи, ее сложность влияет на ключ для R. Имеется три случая:

При связи типа многие-ко-многам ключи обоих связанных множеств являются ключевыми атрибутами для R.

Если есть связь типа многие к-одному множества £, с множеством fj, ключевыми атрибутами R являются ключевые атрибуты но не fj.

При связи тина одни-к-одному ключи любого из связанных множеств являются ключевыми атрибутами для R. Поэтому для R не существует уникального ключа.

Пример 3.24. В примере 3.12 обсуждалась связь Owns типа многие-к-одному между множествами Movies и Studios. Из него ясно, что ключ для отношения Owns - это ключевые атрибуты title и уеег, взятые из ключа для Movies. Схема для Owns с подчеркнутыми атрибутами имеет вид-

Owns(title. year, studioname)

В примере 3 13 рассматривалась связь Stors-in tima многие-ко-мнопиГ между М1южествами Movies и Stars. В этом случае все атрибугы результирующего отношения

Slars-in(ti!e, year. starName)

Когда отношения строятся т ODL или E/R-проекта, в болыииистве случаев (хотя и НС всегда) для каждого отношения существует единственные! ключ. Если отношение имеет единстнен1И.1й ключ, при соспавлении его схемы полезно полчер-кннать атрибуты, которые этог ключ фор.мируют.