Теория и практика построения баз данных (1088289), страница 35
Текст из файла (страница 35)
Функциональные зависимости Функциональная зависимость (1епст!она! дерепдепсу) — это связь мехгду атрибутами. Предположим, что если мы знаем значение одного атрибута, то можем вычислить (нли найти) значение другого атрибута. Например, если нам известен номер счета клиента, то мы можем определить состояние его счета. В таком случае мы можем сказать, что атрибут СостояниеСчетаКлиента фуггкционально зависит от атрибута НомерСчетаКлиента. Говоря более общим языком, атрибут У функционально зависит от атрибута Х, если значение Х определяет значение У. Другими словами, если нам известно значение Х, мы момсем определить значение У. Уравнения выражают функциональные зависимости.
Например, если мьг знаем цену и количество прнобретснного товара, мы можем определить стоимость покупки по следующей формуле: Стоимость = Цена х Количество В этом случае мы могли бы сказать, что атрибут Стоимость функционально зависит от атрибутов Цена и Количество, Функциональные зависимости между атрибутами в отношении обычно не выражаются уравнениями. Пусть, например, каждому студенту присвоен уникальный идентификационный номер, и у каждого студента есть одна и только одна специальность. Имея номер студента, мы можем узнать его специальность, поэтому атрибут Специальность функционально зависит от атрибута НомерСтудента. Или рассмотрим компьютеры в вычислительной лаборатории.
Каждый компьютер имеет конкретный размер основной памяти, поэтому атрибут ОбъемПамяти функционально зависит от атрибута Серий мы йНомерКомпьютера. В отличие от случая с уравнением, такие функциональные зависимости нельзя разрешить при помощи арифметики; вместо этого они хранятся в базе данных, Фактически, можно утверждать, что базу данных стоит иметь только ради хранения и выдачи функциональных зависимостей. Функциональные зависимости обозначаются следующим образом; НомерСтудента» Специальность СерийныйНомерКомпьютера > ОбъемПамяти Первое вьграхгенне читается так: «атрибут НомерСтудента функционально определяет атрибут Специальность», «атрибут НомерСтудента определяет атрибут Специальность» илп «атрибут Специальность зависит от атрибута НомерСтудента».
Атрибуты по правую сторону от стрелки называются детерминанлгами (т(етеггп!паптз). Как уже говорилось, если номер студента определяет специальность, то каждому номеру студента соответствует только одна спецпалъность. Между тем, од- ной и той же специальности может соответствовать более одного номера студента. Пусть студент под номером 123 специализируется на бухгалтерском учете. Тогда для любого отношения, где присутствуют столбцы НомерСтудента и Специальность, выполнится условие: если НомерСтудекта = 123, то Специальность - Бухгалтерскийучет. Обратное, однако, невернгл если Специальность = Бухгалтерскийучет, то атрибут НомерСтудента ьгохсет принимать различные значения, так как на бухгалтерском учете может специализироваться много студентов.
Следовательно, мы можем сказать, что связь атрибутов НомерСтудекта и Специальность имеет вид !»1:1. В общем случае можно утверждать, что если А определяет В, связь между значениями А и В имеет вид !ч:1. В функциональные зависимости могут быть вовлечены группы атрибутов, Рассмотрим отношение ОЦЕНКИ (НомерСтудента, Дисциплина, Оценка).
Комбинация номера студента и дисциплины определяет оценку. Такая функциональная зависимость записывается следующим образом: (НомерСтудента, Дисциплина) > Оценка Заметьте, что для определения оценки требуется как номер студента так и дисциплина. Мы не можем разделить зту функциональную зависимость, поскольку ни номер студента, ни дисциплина не определяют оценку сами по себе. Обратите внимание на следукштее различие. Если Х» (У, 7), то Х > У и Х > 7. Например, если НомерСтудента > (ИмяСтудента, Специальность), то НомерСтудента» ИмяСтудента и НомерСтудента > Специальность.
Но если (Х У) > 7, то в общем случае неверно, что Х > У или Х > 7. Следовательно, если (НомерСтудента, Дисциплина) > Оценка, то ни номер студента, ни дисциплина как таковые оценку не определяют. Ключи Ключ (!«еу) — это группа из одного или более атрибутов, которая уникальным образом идентифицирует строку. Рассмотрим отношение СЕКЦИЯ (рис, 5.3), имеющее атрибуты НомерСтудента, Секция и Плата.
Строка этого отношения содержит информацию о том, что студент посещает определенную секцию за определенную плату, Предположим, что студент одновременно не может посещать более одной секции. В этом случае значение атрибута НомерСтудента идентифицирует единственную строку, поэтому данный атрибут является платном. СЕКЦИЯ (НомерСтудента, Секция, Плата] Ключ: Номеротудента Загврге Вага Номврцтудемта Секция плата Рис. В.З. Отношение СЕКЦИЯ Реляционная модель 171 ИомерСтудента Секция Плата Рмо. 5.4. Отношение СЕКЦИИ 170 Глава 5.
Реляционная модель и нормализация Ключи могут также составляться из нескольких атрибутов. Например, если студентам разрешено одновременно посещать более одной секции, то один и тот же номер студента может появиться в разных строках таблнцьь поэтому атрибут НомерСтудента не будет уникальным образом определять строку. Для этого потребуется какое-то сочетание атрибутов; возможно, это будет комбинация (НомерСтудента, Секция).
Попутно отметим, что в предыдущем абзаце затронут тонкий, но весьма важный аспект. Являются ли атрибуты ключами и являются ли они функционально зависимыми — зто определяется не абстрактным набором правил, а моделями, присутствукнцимн в воображении пользователей, а также деловым регламентом организашш, использующей базу данных. Что в приведенном выше примере является ключом — НамерСзудента, комбинация (НомерСзудента, Секция) или какоето еше сочетание атрибутов, — целиком и полностью определяется тем, как представляют себе ситуацию люди, работающие в организации, которая использует базу данных.
Ответы на зти вопросы мы должны получить от пользователей. По ходу дальнейшего изложения имейте в виду, что все наши предположения о функциональных зависимостях, ключах, ограничениях и тому подобных вещах определяются моделями в воображении пользователей. Допустим, в ходе опроса пользователей мы выяснили, что студентам разрешено одновременно быть записанными в несколько спортивных секций. Эта ситуация отражена в отношении СЕКЦИИ (рис. 5.4). Как мы отметили, НомерСтудента не является ключом этого отношения. В самом деле, студент с номером 100 посещает секцию гольфа и секцию лыж, и атрибут НомерСтудента со значением 100 появляется в двух различных строках.
Фактически, для этого атно|пения ни один атрибут сам по себе не является ключом, то есть ключ должен состоять из двух или более атрибутов. Рассмотрим, какие комбинации из двух атрибутов возможны для данной таблицы. Таких комбинаций имеется три: (НомерСтудента, Секция), (НомерСтудента, Плата) и (Секция, Плата). Является ли какая-либо из этих комбинаций ключом? к1тобы быть клк>чали группа атрибутов должна уникальным образом идентифицировать строку. Опять-таки, ответы на подобные вопросы мы должны получить от пользователей.
Наше решение не должно основываться на выборочных дан- ных, подобных тем, которые приведены на рис. 5.4, или на наших собственных предположениях. Допустим, поговорив с пользователями, мы пришли к вьтоду, что плата за абонемент в различных секциях может совпадать. Поскольку это так, комбинация (НомерСтудента, Плата) не может уникальным образом определить строку. Например, студент с номером 100 может посещать две различных секции, каждая из которых стоит $200. Это означает, что комбинация (100, $200) возникла бы в таблице дважды, поэтому такая комбинация не может быть ключом. Может ли быть ключом сочетание (Секция, Плата)? Может ли комбинация (Лыжи, 1200) уникальным образом определить строку? Нет, не может, поскольку секцию лыж может посещать много студентов. А как насчет сочетания (Номер- Студента, Секция)? Имея те сведения, которые мы получили от пользователей, можно ли сказать, что комбинация значения атрибутов НомерСтудеита и Секция уникальным образом определяет строку таблицы? Да, можно, пока от нас не требуется вести записи об истории посегпения секций студентом.
Иными словами, должна лп эта таблица содержать сведения только о тех секциях, которые студент посещает на данный момент, илп же в ней должны быть записи о секциях, которые студент посещал ранее? И снова, чтобы ответить на этот вопрос, мы должны обратиться к пользователям. Предположим, мы выяснили, что необходимо хранить сведения только о посещаемых в настоягций момент секциях.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
