Функциональные зависимости
Функциональная зависимость это связь одного атрибута или поля в записи с другим. В базе данных мы часто сталкиваемся с ситуацией, когда одно поле определяетдругое. Например, мы можем сказать, чтоSocial Security Number (SSN) (Номер Социального Страхования)определяетимя. Что это означает? Это означает, что если у меня есть база данных сSSNи именами, и если я знаю чей-нибудьSSN, я смогу найти его имя. В дальнейшем, поскольку мы используем термин «определяет», мы говорим, что для каждогоSSNимеется одно и только одно имя. Другими словами, мыопределяем имя, делая егофункционально зависимымотSSN.
Идея функциональной зависимости состоит в том, чтобы определить одно поле как якорь, посредством которого можно всегда найти единственное значение для другого поля. Например, предположим, что компания присвоила каждому служащему уникальный номер служащего. Каждый служащий имеет номер и имя. Имена могут быть одинаковыми у нескольких служащих, но их номера должны всегда быть уникальными, поскольку так их определила компания. Соответствие одного и того же номера разным именам приведет к противоречиям в базе данных.
Изобразим функциональную зависимость (FD) в виде стрелки:
SSN→Name
или
EmpNo→Name
Выражение SSN→Nameозначает, что «SSNопределяетName» или «SSNсвязан сName».
Рассмотрим примеры данных для функциональной зависимости (FD)EmpNo→Name.
Внимание! У вас есть два человека с именем Fred! Является ли это проблемой для функциональной зависимости? Конечно, нет. Вы предполагаете, чтоNameне уникально; у нескольких людей вполне могут быть одинаковые имена. Однако не существует двух людей с одинаковымEmpNo, и каждомуEmpNoсоответствуетName.
Рассмотрим еще один интересный пример:
Здесь есть ошибка? Нет. Мы имеем функциональную зависимость EmpNo→Name. Это значит, что каждый раз находя 104, мы находим имяFred. Если атрибут находится на левой стороне функциональной зависимости, это не значит, что он является ключом или, что он уникален в базе данных.FDX → Y означает только, что каждому экземпляруXприсваивается некоторое значениеY.
Сейчас на примере рассмотрим еще одну функциональную зависимость. Допустим, что Job → Salary (Должность → Зарплата). В этой базе данных каждый, имеющий должность, имеет некоторую зарплату. Добавляя атрибут Salary(Зарплата) в предыдущий пример, получим:
Есть ли противоречия в уже известной нам функциональной зависимости? Нет. Каждый раз, находя EmpNo, мы находим некотороеName; каждый раз находяJob, мы находим некоторуюSalary.
Рассмотрим другой пример. Вернемся к примеру связи SSN→Nameи добавим два новых атрибута.
Здесь мы можем найти две функциональные зависимости: SSN → Name и School → Location (Школа - Местоположение).
Более того, у нас появляется функциональная зависимость SSN → School.
Нарушаем ли мы какую-нибудь функциональную зависимость наших данных? Так как все SSN– уникальны, здесь не может быть нарушенияFDзависимости SSN → Name. Почему? Потому, чтоFDX→Yподразумевает, что, имея некоторое значениеX, вы также имеете некоторое значениеY. Поскольку всеX– уникальны, вы всегда будете иметь некоторое значение. Эти же комментарии верны и для SSN → School.
А что можно сказать о другой FDзависимости School→ Location? В примере приведены только три школы, и Вы можете отметить, что каждой школе соответствует только одно местоположение, так что нарушенияFDне происходит.
А сейчас, мы хотим обратить ваше внимание на интересный факт. Если мы определим функциональную зависимость X→Yи функциональную зависимостьY→Z, то мы можем сделать вывод, чтоX→Z. Здесь мы определили зависимость SSN → School. Мы также определили зависимостьSchool→Location, следовательно, мы можем предположить, чтоSSN→Location, несмотря на то, что между ними нет непосредственной функциональной зависимости. Проиллюстрированный вывод, называетсяправило транзитивной функциональной зависимости или простотранзитивная зависимость. Эту зависимость можно сформулировать следующим образом:
Чтобы убедиться в том, что функциональная зависимость SSN→ Location является истиной, заметим, что, взяв какое либо значение SSN, всегда можно определить уникальное местоположение (location) данного человека.
Другой способ показать, что транзитивное правило истинно – попытаться построить ряд, в котором оно будет неверно и затем посмотреть, какие из определенных функциональных зависимостей были нарушены.
Определим следующие FDзависимости:
Отсюда делаем логический вывод, что транзитивная зависимость это: SSN→ Location. Предположим, что добавляется другая колонка с теми же SSN, но другими местоположениями (location):
Получаем сохранение связи SSN→ Name, но нарушение SSN→ Location. Можем ли мы это сделать? У нас нет значения для School, но мы знаем, что если School = «Alabama», согласно определению SSN → School, мы можем получить следующие строки:
Однако существует проблема. Alabama и Starkville не могут быть в одной строке, потому что мы определили связь School → Location. Итак, в созданном нами контр-примере мы обнаружили ошибку в определенной нами функциональной зависимости. Следовательно, ряд, содержащий Alabama и Starkville - фиктивный. Если бы Вы попытались создать новое местоположение (location), например:
Вы бы снова нарушили зависимость SSN→ School, то есть был бы снова создан фиктивный ряд. Поэтому невозможность приведения контр-пример подтверждает правило транзитивности. Можно доказать правила транзитивности более формально (см. ElmasriиNavathe, 2000,p. 479).
Существуют и другие логические правила для функциональных зависимостей. Остановимся на них и приведем несколько примеров, оставляя формальные доказательства заинтересованному читателю (см. ElmasriиNavathe, 2000).
Правило рефлексии (возврата)
Если X- составное, состоит изAиB, тогда X→ A и X→ B. Например: X=Name,City. Тогда мы говорим, чтоX→NameиX→City.
Например:
Правило, которое представляется довольно очевидным, говорит, что если у вас есть комбинация <Kaitlyn, New Orleans>, то каково имя человека? В каком городе он живет? Пока это правило кажется очевидным, необходимо получать другие функциональные зависимости.
Правило дополнения
Если X→Y, тогдаXZ→Y. Можно назвать это правило «дополнительная информация не обязательна, но не вредна». Допустим, мы используем некоторые данные, по-прежнему Names и Cities, и устанавливаемFDзависимость Name → City. Теперь, предположим, добавим столбец Shoe Size (размер обуви):
Теперь, поскольку Name→City, тоName+ShoeSize→City(то есть мы объединяемNameсShoeSize). Есть ли здесь несоответствие? Нет, потому, что мы описали связьName→City,Nameплюс дополнительная информация всегда идентифицируютCity. Мы можем добавить еще информации к левой стороне (LHS) функциональной зависимости (FD), и на ее истинность это не повлияет.