Теория:

Наиболее часто о функциональных зависимостях мы говорим в связи с математическими функциями, то есть о зависимости значения функции от аргумента.
Функцией называется взаимосвязь, при которой одна из величин однозначно определяется другой.
Для реляционных таблиц подходит и такое определение: соответствие двух множеств при котором комбинации из элементов первого множества соответствует комбинация элементов второго.
Отношение называется функциональным, если его атрибуты можно разбить на две группы: одна — аргументы функции, а вторая — значения функции при данном значении аргумента.
Если отношение функционально, то набор атрибутов, относящихся к аргументу, называется ключевым.
Идентификатором, или первичным ключом, называется значение атрибута, однозначно идентифицирующее запись об информационном объекте в данной таблице.
В нашем примере на роль ключа может претендовать номер поезда, так как по номеру однозначно определяются значения остальных полей в таблице: маршрут, время отправления и время прибытия, а также время в пути.
В данном случае мы имеем дело с простым ключом.
Если же в таблицу добавить ещё один поезд с номером \(0\), то за ключ придётся принимать два поля: номер поезда и время отправления. В этом случае ключ будет составным.
 
Скриншот 09-02-2022 013625.jpg
Рис. \(1\). Маршрут

Обратим внимание на то, как построена таблица в примере выше: в ней нет ни одного повторяющегося кортежа, иначе это препятствовало бы быстрому изменению данных. Любое поле зависит от номера поезда, т. е. от ключа записи, нет полей, одинаковых по смыслу.
Однако данная таблица нуждается в нормализации: поля должны быть неделимы, поэтому поле «Маршрут» надо разделить на «Станцию отправления» и «Станцию прибытия». Кроме того, в нормализованной базе отсутствуют вычисляемые поля, поэтому нам надо будет избавиться от поля «Время в пути». Для более гибкого изменения в БД предпочтительнее будет создать отдельную таблицу «Станции» и связать её с основной таблицей через ключи, соответствующие названиям станций.
Нормализация базы данных — это процесс организации данных с целью защиты целостности данных и создания гибкой структуры за счёт устранения избыточности и непоследовательной зависимости.
Скриншот 09-02-2022 014204.jpg
Рис. \(2\). БД «Маршрут»
 
В теории реляционных баз данных существует несколько уровней нормализации.
Рассмотрим ещё один пример, в котором требуется составить реляционную БД.

Допустим, мы занялись культурологическим исследованием, в котором нам требуется создать каталог фильмов.
Сами фильмы будут объектами, а параметры, по которым мы будем их учитывать, следующие:
 
Скриншот09022022014607.jpg
Рис. \(3\). Каталог фильмов
 
Очевидно, что таблица уже получилась громоздкая, но нам хотелось бы учесть ещё некоторые параметры, например, иметь более подробные сведения о режиссёре, об артистах, занятых в главных ролях, о киностудии и ещё, наверное, другую информацию, необходимость в которой возникнет при использовании полученной базы данных.
Вспомнив требования нормализации, мы разобьём предполагаемую таблицу на несколько таблиц, между которыми нам нужно будет установить функциональные зависимости одного из трёх известных типов: «один-к-одному», «один-ко-многим», «многие-ко-многим».
Для однозначной функциональной зависимости аргументов в таблицах требуется вводить поле-идентификатор, ID. Код, который присваивается каждому объекту и является уникальным.
 
В обычной жизни каждый из нас имеет подобный идентификатор, который описывает нас как объект социальных отношений. Это серия и номер паспорта, идентификационный номер налогоплательщика (ИНН), номер медицинского страхового полиса или страховой номер индивидуального лицевого счёта (СНИЛС), для работников в организациях вводят табельный номер. Эти уникальные идентификаторы могут быть учтены для создания связи между таблицами.
 
image1.jpg
Рис. \(4\). БД «Каталог фильмов»
 
Все связи, которые представлены у нас в таблице, относятся к типу «один-ко-многим». Это самый распространённый тип связи, при котором одной уникальной записи в таблице может соответствовать много записей в другой таблице. Так, одному ID режиссёра может соответствовать много названий фильмов. Одному актёру может соответствовать много ролей, и в одном фильме может быть занято много актёров в разных ролях.
Связь «один-к-одному» появляется не так часто и связывает два ключевых поля. Для примера мы создали таблицу «Адрес», куда переместили адрес киностудии. Таким образом, можно разграничить доступ к полям таблицы — например, предоставив доступ к таблице «Адрес» только узкому кругу лиц.
 
image3.jpg
Рис. \(5\). Связь «один-к-одному»
 
Связь «многие-ко-многим» также применяется крайне редко, и мы можем только концептуально её проиллюстрировать — например, соединив поля «ID режиссёра» в таблице «Фильмы» и «ID режиссёра» в таблице «Роли». Такая связь применяется, когда многим записям в первой таблице может соответствовать много записей во второй таблице.
 
Скриншот16022022012658.jpg
Рис. \(6\). Связь «многие-ко-многим»
 
Обычно связь «многие-ко-многим» заменяется промежуточной таблицей.
 
Скриншот16022022013139.jpg
Рис. \(7\). Связь «многие-ко-многим» \(2\)
Источники:
Рис. 1. Маршрут. © ЯКласс.
Рис. 2. БД «Маршрут». © ЯКласс.
Рис. 3. Каталог фильмов. © ЯКласс.
Рис. 4. БД «Каталог фильмов». © ЯКласс.
Рис. 5. Связь «один-к-одному». © ЯКласс.
Рис. 6. Связь «многие-ко-многим». © ЯКласс.
Рис. 7. Связь «многие-ко-многим» 2. © ЯКласс.