Определение функциональной зависимости кратко

Обновлено: 30.06.2024

Аннотация: В данной лекции вводится понятие функциональной зависимости. Это понятие является основой математической теории реляционных баз данных.

Информация, данные, информационные системы

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

Оставим пока в стороне ответ на вопрос, почему проекты реляционных баз данных бывают плохими, т.е. зачем нужно проектировать реляционную базу данных. Попытаемся сначала ответить на вопросы "В чем заключается проектирование реляционных баз данных ? и "Что лежит в основе процедур проектирования реляционных баз данных ?"

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

На практике построение логической модели базы данных, независимо от используемой модели данных, выполняется с учетом двух основных требований: исключить избыточность и максимально повысить надежность данных. Эти требования вытекают из требования коллективного использования данных группой пользователей. Формальных средств описания данных, необходимых для проверки правильности заполнения конструкций моделей, явно недостаточно. Выбор сущностей, атрибутов и фиксация взаимосвязей между сущностями зависит от семантики предметной области и выполняется системным аналитиком субъективно в соответствии с его личным пониманием специфики прикладной задачи. Разные люди определяют и представляют данные по-разному.

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

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

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

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

F: Х \to Y

Определение 1. Пусть r (A1, A2, . An) - схема отношения R , a X и Y - подмножества r . Говорят, что Х функционально определяет Y , если каждому значению атрибутов кортежа отношения из Х соответствует не более одного значения атрибутов того же кортежа отношения из Y . Такая ФЗ обозначается как .

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

  • каждому рейсу соответствует определенное время вылета;
  • для каждого пилота, даты и времени вылета возможен только один рейс;
  • на определенный день и рейс назначается определенный пилот.
  • "Время_вылета" функционально зависим от "Рейс" : "Рейс" -> "Время_<> вылета" ;
  • "Рейс" функционально зависим от : -> "Рейс" ;
  • "Пилот" функционально зависим от : -> "Пилот" .

Важной задачей при выявлении функциональных зависимостей на атрибутах отношения, которое по определению является множеством, является выяснение, какой из атрибутов выступает как аргумент, а какой - как значение ФЗ. Наиболее подходящими кандидатами в аргументы ФЗ являются возможные ключи , так как кортежи представляют экземпляры сущности , которые идентифицируются значениями атрибутов своего ключа. Нестрого говоря, функциональная зависимость имеет место на отношении, когда значения кортежа на одном множестве атрибутов однозначным образом определяют значения кортежа на другом множестве атрибутов. Это рабочее определение ФЗ не содержит в себе тех формальных элементов, которые позволяют ответить на вопрос "А как проверить наличие ФЗ между атрибутами отношения?" Необходимый для этого формализм дает нам использование реляционных операций . Для получения формального (строгого) определения наличия ФЗ в отношении обратимся к реляционным операциям .

Определение 2. Пусть имеется отношение R со схемой r , X и Y - два подмножества R . ФЗ имеет место на R , если множество (R))" />
имеет не более одного кортежа для каждого значения х . Такая ФЗ называется также F -зависимостью.

F: X \to Y

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

F: X \to Y

Алгоритм, который проверяет, удовлетворяет ли отношение R ФЗ , состоит в сортировке отношения по значениям возможного ключа и установления факта однозначности между его значением и значениями других атрибутов. Этот алгоритм полезен, но он носит вспомогательный характер.

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

Функциональные зависимости фактически представляют собой утверждения обо всех отношениях предметной области. Эти отношения могут являться значениями схемы r и, в сущности, не могут быть получены формальными методами. Единственный способ установления функциональных зависимостей для схемы отношения r - это исследование семантики атрибутов сущностей предметной области . Являясь высказываниями о сущностях предметной области , они не могут быть доказаны. Это обстоятельство по существу порождает неединственность представления предметной области отношениями реляционной БД.

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

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

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

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

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

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

Вначале вспомним некоторые понятия:

Простой атрибут — это атрибут, значения которого неделимы. Иными словами, в таблице нет полей типа ФИО или Адрес — они разложены на поля Фамилия, Имя, Отчество в первом случае и на поля Индекс, Город и т. д. во втором.

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

Определение функциональной зависимости: Пусть Xи Y атрибуты некоторого отношения. Если в любой момент времени произвольному значению X соответствует единственное значение Y, то Y функционально зависит от X (XY)

Если ключ является составным, то любой атрибут должен зависеть от ключа в целом, но не может находиться в функциональной зависимости от какой-либо части составного ключа, т.е. функциональная зависимость имеет вид (X1, X2, . X)Y.

Функциональная зависимость может быть полной или неполной.

Неполной зависимостью называется зависимость неключевого атрибута от части составного ключа.

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

Определение транзитивной функциональной зависимости: Пусть X, Y, Z— три атрибута некоторого отношения. При эtom XY и YZ, но обратное соответствие отсутствует, то есть Y не зависит от Z, а Х не зависит от Y. Тогда говорят, что Z транзитивно зависит от Х.

Рассмотрим следующий пример: Предположим, что для учебной части факультета создается БД о преподавателях, которая включает следующие атрибуты:

ФИО - фамилия и инициалы преподавателя (совпадения фамилий и инициалов исключаются).

Должность - должность, занимаемая преподавателем.

Оклад- оклад преподавателя.

Стаж - преподавательский стаж. Д_Стаж - надбавка за стаж.

Кафедра - номер кафедры, на которой числится преподаватель.

Предмет - название предмета (дисциплины), читаемого преподавателем.

Группа - номер группы, в которой преподаватель проводит занятия.




Вид занятия - вид занятий, проводимых преподавателем в учебной группе.

Исходное отношение ПРЕПОДАВАТЕЛЬ

ФИО Должность Оклад Стаж Д_Стаж Кафедра Предмет Группа Вид занятия
Иванов И. М. Преподаватель БД АС-21 Практика
Иванов И. М. Преподаватель ОС АС-22 Практика
Петров М. И. Ст. преподаватель БД АС-21 Лекция
Петров М. И. Ст. преподаватель Архитектура АС-21 Практика
Сидоров Н. Г. Преподаватель ОС АС-22 Лекция
Сидоров Н. Г. Преподаватель Архитектура АС-21 Лекция
Егоров В. В. Преподаватель Философия ПС-22 Лекция

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

Функциональные зависимости: ФИО→Кафедра, ФИО→Должность, Должность→ Оклад, ФИО→Предмет.

Также в нашем отношении ключ является составным и состоит из атрибутов (ФИО, Предмет, Группа).

Неполная функциональная зависимость: (ФИО, Предмет, Группа)→Должность, т.к. атрибут Должность находится в функциональной зависимости от атрибута ФИО, являющегося частью ключа.

Полная функциональная зависимость: (ФИО, Предмет, Группа)→Вид занятия.

Транзитивная зависимость: ФИО→Должность→Оклад, ФИО→Стаж→Д_Стаж.

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

ФИО →Должность ФИО →Оклад ФИО →Стаж ФИО →Д_Стаж ФИО →Кафедра Стаж →ДСтаж Оклад →Должность Должность →Оклад (ФИО, Предмет, Группа) →Вид занятий

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

Фамилия, Имя и Отчество у преподавателей факультета уникальны. Каждому преподавателю однозначно соответствует его стаж, т. е. имеет место функциональная зависимость ФИО →Стаж. Обратное утверждение неверно, так как одинаковый стаж может быть у разных преподавателей.

Каждый преподаватель имеет определенную добавку за стаж, т. е. имеет место функциональная зависимость ФИО→Д_Стаж, но обратная функциональная зависимость отсутствует, так как одну и ту же надбавку могут иметь несколько преподавателей.

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

Каждый преподаватель является сотрудником одной и только одной кафедры. Поэтому имеет место функциональная зависимость ФИО→Кафедра. С другой стороны, на каждой кафедре много преподавателей, поэтому обратной функциональной зависимости нет.

Каждому преподавателю соответствует конкретный оклад, который одинаков для всех педагогов с одинаковыми должностями, что учитывается зависимостями ФИО→Оклад и Должность→Оклад. Нет одинаковых окладов для разных должностей, поэтому имеет место функциональная зависимость Оклад→Должность.

Один и тот же преподаватель в одной группе по разным предметам может проводить разные виды занятий. Определение вида занятий, которые проводит преподаватель, невозможно без указания предмета и группы, поэтому имеет место функциональная зависимость (ФИО, Предмет, Группа) →Вид Занятия.

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

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

Каждая следующая нормальная форма ограничивает определенный тип функциональных зависимостей, устраняет соответствующие аномалии при выполнении операций над отношениями БД и сохраняет свойства предшествующих нормальных форм. Выделяют следующую последовательность нормальных форм: первая нормальная форма (1НФ); вторая нормальная форма (2НФ); третья нормальная форма (ЗНФ).

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

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

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

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

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

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

Вначале вспомним некоторые понятия:

Простой атрибут — это атрибут, значения которого неделимы. Иными словами, в таблице нет полей типа ФИО или Адрес — они разложены на поля Фамилия, Имя, Отчество в первом случае и на поля Индекс, Город и т. д. во втором.

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

Определение функциональной зависимости: Пусть Xи Y атрибуты некоторого отношения. Если в любой момент времени произвольному значению X соответствует единственное значение Y, то Y функционально зависит от X (XY)

Если ключ является составным, то любой атрибут должен зависеть от ключа в целом, но не может находиться в функциональной зависимости от какой-либо части составного ключа, т.е. функциональная зависимость имеет вид (X1, X2, . X)Y.

Функциональная зависимость может быть полной или неполной.

Неполной зависимостью называется зависимость неключевого атрибута от части составного ключа.

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

Определение транзитивной функциональной зависимости: Пусть X, Y, Z— три атрибута некоторого отношения. При эtom XY и YZ, но обратное соответствие отсутствует, то есть Y не зависит от Z, а Х не зависит от Y. Тогда говорят, что Z транзитивно зависит от Х.

Рассмотрим следующий пример: Предположим, что для учебной части факультета создается БД о преподавателях, которая включает следующие атрибуты:

ФИО - фамилия и инициалы преподавателя (совпадения фамилий и инициалов исключаются).

Должность - должность, занимаемая преподавателем.

Оклад- оклад преподавателя.

Стаж - преподавательский стаж. Д_Стаж - надбавка за стаж.

Кафедра - номер кафедры, на которой числится преподаватель.

Предмет - название предмета (дисциплины), читаемого преподавателем.

Группа - номер группы, в которой преподаватель проводит занятия.

Вид занятия - вид занятий, проводимых преподавателем в учебной группе.

Исходное отношение ПРЕПОДАВАТЕЛЬ

ФИО Должность Оклад Стаж Д_Стаж Кафедра Предмет Группа Вид занятия
Иванов И. М. Преподаватель БД АС-21 Практика
Иванов И. М. Преподаватель ОС АС-22 Практика
Петров М. И. Ст. преподаватель БД АС-21 Лекция
Петров М. И. Ст. преподаватель Архитектура АС-21 Практика
Сидоров Н. Г. Преподаватель ОС АС-22 Лекция
Сидоров Н. Г. Преподаватель Архитектура АС-21 Лекция
Егоров В. В. Преподаватель Философия ПС-22 Лекция

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

Функциональные зависимости: ФИО→Кафедра, ФИО→Должность, Должность→ Оклад, ФИО→Предмет.

Также в нашем отношении ключ является составным и состоит из атрибутов (ФИО, Предмет, Группа).

Неполная функциональная зависимость: (ФИО, Предмет, Группа)→Должность, т.к. атрибут Должность находится в функциональной зависимости от атрибута ФИО, являющегося частью ключа.

Полная функциональная зависимость: (ФИО, Предмет, Группа)→Вид занятия.

Транзитивная зависимость: ФИО→Должность→Оклад, ФИО→Стаж→Д_Стаж.

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

ФИО →Должность ФИО →Оклад ФИО →Стаж ФИО →Д_Стаж ФИО →Кафедра Стаж →ДСтаж Оклад →Должность Должность →Оклад (ФИО, Предмет, Группа) →Вид занятий

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

Фамилия, Имя и Отчество у преподавателей факультета уникальны. Каждому преподавателю однозначно соответствует его стаж, т. е. имеет место функциональная зависимость ФИО →Стаж. Обратное утверждение неверно, так как одинаковый стаж может быть у разных преподавателей.

Каждый преподаватель имеет определенную добавку за стаж, т. е. имеет место функциональная зависимость ФИО→Д_Стаж, но обратная функциональная зависимость отсутствует, так как одну и ту же надбавку могут иметь несколько преподавателей.

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

Каждый преподаватель является сотрудником одной и только одной кафедры. Поэтому имеет место функциональная зависимость ФИО→Кафедра. С другой стороны, на каждой кафедре много преподавателей, поэтому обратной функциональной зависимости нет.

Каждому преподавателю соответствует конкретный оклад, который одинаков для всех педагогов с одинаковыми должностями, что учитывается зависимостями ФИО→Оклад и Должность→Оклад. Нет одинаковых окладов для разных должностей, поэтому имеет место функциональная зависимость Оклад→Должность.

Один и тот же преподаватель в одной группе по разным предметам может проводить разные виды занятий. Определение вида занятий, которые проводит преподаватель, невозможно без указания предмета и группы, поэтому имеет место функциональная зависимость (ФИО, Предмет, Группа) →Вид Занятия.

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

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

Каждая следующая нормальная форма ограничивает определенный тип функциональных зависимостей, устраняет соответствующие аномалии при выполнении операций над отношениями БД и сохраняет свойства предшествующих нормальных форм. Выделяют следующую последовательность нормальных форм: первая нормальная форма (1НФ); вторая нормальная форма (2НФ); третья нормальная форма (ЗНФ).

Если имеются два атрибута А и В какого-либо отношения, то говорят, что В функционально зависит от А, если в каждый момент времени каждому значению А соответствует лишь одно значение В.

Функциональную зависимость (ФЗ) обозначают $А \to В$. Обратим внимание, что А и В могут быть не только единичными атрибутами, но и группами, которые составлены из нескольких атрибутов одного отношения.

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

К примеру, в каждом кортеже на рисунке 1 Фамилия однозначно определяется № работника; Специальность однозначно определяется № работника. Данные функциональные зависимости записывают в виде:

ФЗ: № работника $\to$ фамилия, ФЗ: № работника $\to$ специальность.

Функциональная зависимость значением одного атрибута в кортеже однозначно определяет значение другого атрибута в кортеже.

Готовые работы на аналогичную тему

Другими словами функциональная зависимость определяется следующим образом:

Если в таблице R существуют атрибуты А и В, то запись

значит, что при одном и том же значении атрибута А двух кортежей в таблице R они будут иметь одно и то же значение атрибута В.

Данное определение можно применить также в случае, когда А и В являются множеством столбцов, а не просто отдельными столбцами.

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

Детерминантом всегда является ключ таблицы, т.к. его значением однозначно определяется значение каждого атрибута таблицы.

Типы функциональных зависимостей

Не все функциональные зависимости являются желательными.

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

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

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

Существует еще несколько видов функциональной зависимости.

Транзитивная функциональная зависимость. Пусть А, В, С – атрибуты какого-либо отношения. При этом $А \to В$ и $В \to С$ и отсутствует обратное соответствие, то есть $С \not \to В$ и $В \not \to А$. В таком случае С транзитивно зависит от А.

Многозначная зависимость. Пусть А, В, С – атрибуты некоторого отношения R. В данном отношении R существует многозначная зависимость $R.А \to R.В$ лишь в том случае, когда множество значений В, которое соответствует паре значений А и С, зависит только от А и не зависит от С.

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

Для объяснения понятия функциональной зависимости, рассмотрим следующий пример.

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

Сессия (№ зачетной книжки, Фамилия, Имя, Отчество, Предмет, Оценка);


Таким образом, функциональная зависимость – это однозначная зависимость, затабулированная в системах управления базами данных.

Теперь дадим строгое определение функциональной зависимости.

Запишем это же определение в формулярном виде:

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

Интересно заметить, что в случае функциональной зависимости Y от X, говорят также, что X функционально определяет Y или что Y функционально зависит от X. В схеме функциональной зависимости X ? Y подсхема X называется левой частью, а подсхема Y – правой частью.

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

В частном случае, когда правая часть функциональной зависимости, т. е. подсхема Y, совпадает со всей схемой отношения, ограничение функциональной зависимости переходит в ограничение уникальности первичного или кандидатного ключа. Действительно:

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

Приведем примеры изображения функциональной зависимости:

Данный текст является ознакомительным фрагментом.

Продолжение на ЛитРес

Назначение и функциональные возможности программы

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

6.6. Функциональные клавиши и меню Файл

6.6. Функциональные клавиши и меню Файл До сих пор мы рассказывали только о внешнем виде экрана программы Midnight Commander и о том, как изменить этот вид. Теперь пора рассказать и том, как работать с файлами с помощью этой программы.Наиболее часто выполняемые в Midnight Commander операции

Функциональные клавиши

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

Функциональные возможности Excel Excel 2007 позволяет формировать и выводить на печать документы, представленные в табличном виде, выполнять расчеты на основании исходных данных и др. Задачи, решаемые с помощью табличного редактора Excel, кратко перечислены ниже.• Создание,

Назначение и функциональные возможности

Назначение и функциональные возможности Программа Microsoft Outlook 2007 обладает широкими функциональными возможностями, которые кратко можно сформулировать следующим образом:• выполнение функций персонального органайзера;• работа с электронной почтой (создание,

Функциональные клавиши

Функциональные клавиши Обычно вы посылаете команду ЭВМ, нажимая на клавишу с надписью enter (ввод), с/r (возврат каретки) или return (возврат). Названия клавиш иногда обозначаются прописными буквами. Пусть клавиша [enter] — [ввод]. Здесь квадратные скобки означают, что вы должны

Функциональные объекты

Функциональные объекты Функциональные объекты - это объекты, для которых определён operator(). Они важны для эффективного использования библиотеки. В местах, где ожидается передача указателя на функцию алгоритмическому шаблону, интерфейс установлен на приём объекта с

Другие функциональные сочетания клавиш

Другие функциональные сочетания клавиш

19.2.7. Конструкторы и функциональные try-блоки

19.2.7. Конструкторы и функциональные try-блоки Можно объявить функцию так, что все ее тело будет заключено в try-блок. Такие try-блоки называются функциональными. (Мы упоминали их в разделе 11.2.) Например:int main() catch ( pushOnFull ) catch ( popOnEmpty ) Функциональный

Функциональные клавиши

Функциональные клавиши Для удобной работы с системой сохраняется возможность использования функциональных клавиш:• F1 – вызов справочной системы AutoCAD;• F2 – переключение между текстовым и графическим окнами;• F3 или Ctrl+F – включение/отключение текущих режимов объектной

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

3.3.1 Функциональные возможности a) Установка (инсталляция)Если установка пакета может быть выполнена пользователем, то при ее проведении должна быть обеспечена возможность успешной установки программ в соответствии с информацией, содержащейся в руководстве по

4.1 Функциональные возможности (Functionality)

4.1 Функциональные возможности (Functionality) Набор атрибутов, относящихся к сути набора функций и их конкретным свойствам. Функциями являются те, которые реализуют установленные или предполагаемые потребности:Примечания1 Данный набор атрибутов характеризует то, что

А.2.1 Функциональные возможности (Functionality)

А.2.1 Функциональные возможности (Functionality) А.2.1.1 Пригодность (Suitability) Атрибут программного обеспечения, относящийся к наличию и соответствию набора функций конкретным задачам.Примечание - Примерами Соответствия является состав функций, ориентированных на задачу, из

4.1.2. Функциональные клавиши

4.1.2. Функциональные клавиши В верхней части клавиатуры размещено 12 (от F1 до F12) функциональных клавиш (рис. 30). Функции, выполняемые этими клавишами, зависят от работающей в данный момент программы, т. е. реакцию на нажатие каждой функциональной клавиши задает программист.

Читайте также: