Основы реляционной алгебры. Реляционная теория баз данных Теория реляционных бд
Реляционная алгебра базируется на теории множеств и является основой логики работы баз данных.
Когда я только изучал устройство баз данных и SQL, предварительное ознакомление с реляционной алгеброй очень помогло дальнейшим знаниям правильно уложиться в голове, и я постараюсь что бы эта статья произвела подобный эффект.
Так что если вы собираетесь начать свое обучение в этой области или вам просто стало интересно, прошу под кат.
Реляционная база данных
Для начала введем понятие реляцинной базы данных, в которой будем выполнять все действия.
Реляционной базой данных называется совокупность отношений, содержащих всю информацию, которая должна хранится в базе. В данном определении нам интересен термин отношение, но пока оставим его без строго определения.
Лучше представим себе таблицу продуктов.
Таблица PRODUCTS
| ID | NAME | COMPANY | PRICE |
| 123 | Печеньки | ООО ”Темная сторона” | 190 |
| 156 | Чай | ООО ”Темная сторона” | 60 |
| 235 | Ананасы | ОАО ”Фрукты” | 100 |
| 623 | Томаты | ООО ”Овощи” | 130 |
Таблица состоит из 4х строк, строка в таблице является кортежем в реляционной теории. Множество упорядоченных кортежей называется отношением.
Перед тем как дать определение отношения, введем еще один термин - домен. Домены применительно к таблице это столбцы.
Для ясности, теперь введем строгое определение отношения.
Пусть даны N множеств D1,D2, …. Dn (домены), отношением R над этими множествами называется множество упорядоченных N-кортежей вида
Каждый элемент кортежа представляет собой значение одного из атрибутов, соответствующего одному из доменов.
Ключи в отношениях
В отношении требованием является то, что все кортежи должны различаться. Для однозначной идентификации кортежа существует первичный ключ. Первичный ключ это атрибут или набор из минимального числа атрибутов, который однозначно идентифицирует конкретный кортеж и не содержит дополнительных атрибутов.Подразумевается, что все атрибуты в первичном ключе должны быть необходимыми и достаточными для идентификации конкретного кортежа, и исключение любого из атрибутов в ключе сделает его недостаточным для идентификации.
Например, в такой таблице ключом будет сочетание атрибутов из первого и второго столбца.
Таблица DRIVERS
Видно, что в организации может быть несколько водителей, и чтобы однозначно идентифицировать водителя необходимо и значение из столбца “Название организации” и из “Имя водителя”. Такой ключ называется составным.
В реляционной БД таблицы взаимосвязаны и соотносятся друг с другом как главные и подчиненные. Связь главной и подчиненнной таблицы осуществляется через первичный ключ (primary key) главной таблицы и внешний ключ (foreign key) подчиненной таблицы.
Внешний ключ это атрибут или набор атрибутов, который в главной таблице является первичным ключем.
Этой подготовительной теории будет достаточно для знакомства с основными операциями реляционной алгебры.
Операции реляционной алгебры
Основные восемь операций реляционной алгебры были предложены Э.Коддом .- Объединение
- Пересечение
- Вычитание
- Декартово произведение
- Выборка
- Проекция
- Соединение
- Деление
Для понимания важно запомнить, что результатом любой операции алгебры над отношениями является еще одно отношение, которое можно потом так же использовать в других операциях.
Создадим еще одну таблицу, которая нам пригодится в примерах.
Таблица SELLERS
| ID | SELLER |
| 123 | OOO “Дарт” |
| 156 | ОАО ”Ведро” |
| 235 | ЗАО “Овоще База” |
| 623 | ОАО ”Фирма” |
Условимся, что в этой таблице ID это внешний ключ, связанный с первичным ключом таблицы PRODUCTS.
Для начала рассмотрим самую простую операцию - имя отношения. Её результатом будет такое же отношение, то есть выполнив операцию PRODUCTS, мы получим копию отношения PRODUCTS.
Проекция
Проекция является операцией, при которой из отношения выделяются атрибуты только из указанных доменов, то есть из таблицы выбираются только нужные столбцы, при этом, если получится несколько одинаковых кортежей, то в результирующем отношении остается только по одному экземпляру подобного кортежа.Для примера сделаем проекцию на таблице PRODUCTS выбрав из нее ID и PRICE.
Синтаксис операции:
π
(ID, PRICE) PRODUCTS
В условии выборки мы можем использовать любое логическое выражение. Сделаем еще одну выборку с ценой больше 90 и ID товара меньше 300:
σ (PRICE>90 ^ ID<300) PRODUCTS
Умножение
Умножение или декартово произведение является операцией, производимой над двумя отношениями, в результате которой мы получаем отношение со всеми доменами из двух начальных отношений. Кортежи в этих доменах будут представлять из себя все возможные сочетания кортежей из начальных отношений. На примере будет понятнее.Получим декартово произведения таблиц PRODUCTS и SELLERS.
Синтаксис операции:
PRODUCTS × SELLERS
Можно заметить, что у двух этих таблиц есть одинаковый домен ID. В подобной ситуации домены с одинаковыми названиями получают префикс в виде названия соответствующего отношения, как показано ниже.
Для краткости перемножим не полные отношения, а выборки с условием ID<235
(цветом выделены одни и те же кортежи)
| PRODUCTS.ID | NAME | COMPANY | PRICE | SELLERS.ID | SELLER |
| 123 | Печеньки | ООО ”Темная сторона” | 190 | 123 | OOO “Дарт” |
| 156 | Чай | ООО ”Темная сторона” | 60 | 156 | ОАО ”Ведро” |
| 123 | Печеньки | ООО ”Темная сторона” | 190 | 156 | ОАО ”Ведро” |
| 156 | Чай | ООО ”Темная сторона” | 60 | 123 | OOO “Дарт” |
Для примера использования этой операции представим себе необходимость выбрать продавцов с ценами меньше 90. Без произведения необходимо было бы сначала получить ID продуктов из первой таблицы, потом по этим ID из второй таблицы получить нужные имена SELLER, а с использованием произведения будет такой запрос:
π (SELLER) σ (RODUCTS.ID=SELLERS.ID ^ PRICE<90) PRODUCTS × SELLERS
В результате этой операции получим отношение:
| SELLER |
| ОАО ”Ведро” |
Соединение и естественное соединение
Операция соединения обратна операции проекции и создает новое отношение из двух уже существующих. Новое отношение получается конкатенацией кортежей первого и второго отношений, при этом конкатенации подвергаются отношения, в которых совпадают значения заданных атрибутов. В частности, если соединить отношения PRODUCTS и SELLERS, этими атрибутами будут атрибуты доменов ID.Также для понятности можно представить соеднинение как результат двух операций. Сначала берется произведение исходных таблиц, а потом из полученного отношения мы делаем выборку с условием равенства атрибутов из одинаковых доменов. В данном случае условием явлется равенство PRODUCTS.ID и SELLERS.ID.
Попробуем соединить отношения PRODUCTS и SELLERS и получим отношение.
| PRODUCTS.ID | NAME | COMPANY | PRICE | SELLERS.ID | SELLER |
| 123 | Печеньки | ООО ”Темная сторона” | 190 | 123 | OOO “Дарт” |
| 156 | Чай | ООО ”Темная сторона” | 60 | 156 | ОАО ”Ведро” |
| 235 | Ананасы | ОАО ”Фрукты” | 100 | 235 | ЗАО “Овоще База” |
| 623 | Томаты | ООО ”Овощи” | 130 | 623 | ОАО ”Фирма” |
Натуральное соединение получает схожее отношение, но в случае, если у нас корректно настроена схема в базе (в данном случае первичный ключ таблицы PRODUCTS ID связан с внешним ключем таблицы SELLERS ID), то в результирующем отношении остается один домен ID.
Синтаксис операции:
PRODUCTS ⋈ SELLERS;
Получится такое отношение:
| PRODUCTS.ID | NAME | COMPANY | PRICE | SELLER |
| 123 | Печеньки | ООО ”Темная сторона” | 190 | OOO “Дарт” |
| 156 | Чай | ООО ”Темная сторона” | 60 | ОАО ”Ведро” |
| 235 | Ананасы | ОАО ”Фрукты” | 100 | ЗАО “Овоще База” |
| 623 | Томаты | ООО ”Овощи” | 130 | ОАО ”Фирма” |
Пересечение и вычитание.
Результатом операции пересечения будет отношение, состоящее из кортежей, полностью входящих в состав обоих отношений.Результатом вычитания будет отношение, состоящее из кортежей, которые являются кортежами первого отношения и не являются кортежами второго отношения.
Данные операции аналогичны таким же операциям над множествам, так что, я думаю, нет необходимости подробно их расписывать.
Источники информации
- Основы использования и проектирования баз данных - В. М. Илюшечкин
- курс лекций Introduction to Databases - Jennifer Widom, Stanford University
Буду благодарен за аргументированные замечания
Коротко о важном.
Нормализация БД
Первая нормальная форма (1НФ)
- отсутствуют повторяющиеся группы данных
- гарантируется элементарности(atomicity) данных (все данные являются автономными и независимыми).
На верхнем уровне это достигается созданием первичного ключа, затем осуществляется перенос повторяющихся групп данных в новые таблицы, создание первичных ключей для этих таблиц и так далее. Кроме того, необходимо разбить все записи, столбцы которых содержат составную информацию, на отдельные строки для каждого фрагмента данных столбца.
Вторая нормальная форма (2НФ)
- таблица удовлетворяет условиям 1НФ
- каждый столбец зависит от всего ключа, а не от его части.
Третья нормальная форма (3НФ)
- таблица удовлетворяет условиям 2НФ
- ни один столбец не зависит от столбца, который не является частью первичного ключа
- не содержит производных данных
Другие нормальные формы, не имеющие особой практической ценности:
Нормальная форма Бойса-Кодда(Boyce-Codd)
Вариант 3НФ. Предназначена для решения ситуации с наличием множества перекрывающихся ключей-кандидатов. По сути, не находит логического обоснования за пределами академического сообщества.
Четвертая нормальная форма
Предназначена для решения вопроса с многозначными зависимостями. Такие ситуации возникают, если в приведенной к 3НФ таблице один столбец составного первичного ключа зависит от другого столбца первичного ключа.
Пятая нормальная форма
Применяется при работе с декомпозицией отношений с потерями и без потерь. Возникает в ситуации, когда можно разбить одно отношение на несколько различных отношений, но после этого мы уже не сможем логически вернуть его к первоначальному виду.
Шестая нормальная форма (нормальная форма доменного ключа)
Гарантирует отсутствие аномалий модификации в базе данных. В реальных условиях практически не достижима.
Отношения.
Однажды я услышал от женщин, что мужчины
немедленно стараются покинуть помещение, в котором
прозвучало слово "отношения". <...> ключом к успеху
отношений является осведомленность каждого о своей роли
в данном отношении, а также о правилах и ограничениях,
налагаемых данным отношением.
(С)Robert Viera, “Professional SQL Server 2000 Programming”
Типы отношений
- Одного–к–одному (иммет смысл, когда в разных базах нужно хранить совпадающие данные или когда происходит превышение максимального размера данных строки)
- Нуля– или одного–к–одному
- Одного–ко–многим
- Одного к –нулю, –одному или –многим
- Многих–ко–многим (развязочные таблицы)
Объединения
INNER JOIN
Исключающее объединение (exclusive join). В результат выборки попадают только те записи таблиц, у которых есть соответствия в парной таблице по заданному условию.
LEFT|RIGHT JOIN
Включающее объединение (inclusive join). В результат выборки попадают записи из таблицы, стоящей слева/справа от JOIN
соответственно. При этом данные из недостающей «парной» записи будут заполнены NULL
.
FROM left_table LEFT JOIN right_table
– включены все записи из левой таблицы left_table
FROM left_table RIGHT JOIN right_table
– включены все записи из правой таблицы right_table
FULL JOIN
Включающее объединение (inclusive join). В результат выборки попадают не только записи, которые имеют соответствие в другой таблице, но и записи из обоих таблиц, для которых в соответствие в другой таблице не найдено. При этом данные из недостающей «парной» записи будут заполнены NULL.
CROSS JOIN
Перекрестное объединение (декартово произведение). Каждая запись из одной таблицы ставится в соответствие каждой записи из другой таблицы. Количество результирующих записей равно произведению количества записей в обоих таблицах.
Принципы упорядочивания нескольких JOIN ’ов
В случае, если необходимо произвести объединение нескольких таблиц, нужно помнить о двух принципах:
- Все объединения левее JOIN воспринимаются как одиночная таблица для включения или исключения из запроса.
- Все объединения ПРАВЕЕ JOIN ТАКЖЕ воспринимаются как одиночная таблица для включения или исключения из запроса.
Следствием из этих принципов является следующая рекомендация для формирования сложных объединений:
P.S. Все вышеизложенное является общими "постулатами" теории реляционных баз данных, не привязанными к особенностям определенных СУБД.
ПРОГРАММИРОВАНИЕ В СРЕДЕ DELPHI 6
Базы данных. Создание отчета с помощью Word.
Утверждено Редакционно-издательским советом
университета в качестве лабораторного практикума
Воронеж 2004
УДК 681.3
Воробьёв Э.И., Короткевич Д.Э.. Программирование в среде Delphi 6: Лабораторный практикум: Ч. 2: Базы данных. Создание отчета с помощью Word. Потоки. Воронеж: Воронеж. гос. техн. ун-т, 2004. 107 с.
Во второй части лабораторного практикума рассматриваются теоретические и практические сведения для написания программ в среде Delphi 6 на тему: «Проектирование баз данных, создание отчетов в программе Word и использование потоков при создании высокопроизводительных приложений».
Издание соответствует требованиям Государственного образовательного стандарта высшего профессионального образования по направлению 230100 «Информатика и вычислительная техника», специальности 230104 «Системы автоматизированного проектирования», дисциплине «Программирование на языках высокого уровня».
Табл. 3. Ил. 19. Библиогр.: 7 назв.
Научный редактор: д-р техн. наук, проф. Я.Е. Львович
Рецензенты: кафедра вычислительной техники Воронеж- ской лесотехнической академии (зав. кафедрой д-р техн. наук, проф. В.Е. Межов);
д-р техн. наук, проф. О.Ю.Макаров
© Воробьёв Э.И., Короткевич Д.Э., 2004
© Оформление. Воронежский государственный
технический университет, 2004
Введение
Концепция баз данных
Базы данных считаются основным преимуществом Delphi. Даже специализированные языки для работы с базами данных (такие, как MS Visual FoxPro) явно уступают по простоте и мощи программирования этого типа приложений. Delphi скрывает все сложности и в то же время даёт величайшую мощь. Ещё не было такой задачи, которую не смогли бы реализовать на Delphi за короткий промежуток времени. А главное, что всё это реализовано очень удобно и легко для понимания. В Delphi можно создавать простые приложения, даже со сложными базами, без единой строчки кода. В данном учебном пособии рассмотрены лабораторные задания для освоения приемов работы с локальными базами данных.
Теория реляционных баз данных
Ещё десять лет назад программирование баз данных было очень сложным занятием. Сейчас уже такое трудно себе представить, потому что благодаря Delphi процесс написания программ упростился, а количество разновидностей баз данных уже исчисляется десятками.
Базы данных делятся на локальные (установленные на компьютере клиента, там же где и работает программа) и удалённые (установленные на сервере, удалённом компьютере). Серверные базы данных располагаются на удалённом компьютере и работают под управлением серверного программного обеспечения. К их главным преимуществам можно отнести возможность работы с одной базой данных одновременно несколькими пользователями, и при этом осуществляется минимальная нагрузка на сеть. Есть ещё сетевые базы данных, которые создают слишком большую нагрузку на сеть и неудобны в работе как для программиста, так и для конечного пользователя. Когда программа присоединяется к сетевой базе данных, то она выкачивает с сервера практически полную его копию. Если Вы внесли изменения, то Ваша копия полностью закачивается обратно. Это очень неудобно, потому что создаётся большая нагрузка на сеть из-за излишней перекачки данных. При клиент-серверной технологии программа клиент посылает простой текстовый запрос на сервер на получение каких-либо данных. Сервер обрабатывает его и возвращает только необходимую порцию данных. Когда нужно изменить какие-то данные опять посылается запрос к серверу на их изменение, и сервер изменяет данные в своей базе. Таким образом, по сети происходит перекачка в основном только текстовых запросов, которые в основном занимают меньше килобайта. Все данные обрабатывает сервер, а значит, машина клиента загружается намного меньше и не так сильно требовательна к ресурсам. Сервер отсылает клиенту только самые необходимые данные, а значит, отсутствует излишняя перекачка копии всей базы. Благодаря всему этому сетевые базы данных уже устарели и практически не используются. Их практически полностью вытесняет технология клиент-сервер. А вот локальные базы данных будут жить всегда. Может измениться формат их хранения или добавиться какие-то новые функции, но сами базы данных будут существовать. Для дальнейшего рассмотрения нам надо определить новое понятие – таблица . Пока что говорились только общие принципы, поэтому использовалось общее понятие баз данных . Таблица базы данных – это как двухмерный массив, в котором в столбец выстроены данные (яркий пример таблицы – Excel). База данных – грубо говоря, это всего лишь файл, в котором может храниться от одной до нескольких таблиц. Большинство локальных баз данных могут хранить только одну таблицу (dBase, Paradox, XML). Но есть представители локальных баз, где в одном файле заключено несколько таблиц (например Access).
Локальные базы данных
Из локальных баз данных рассмотрим реляционные как самые распространённые. Что такое реляционная база данных? Это таблица, в которой в качестве столбцов выступают имена хранимых в ней данных, а каждая строка хранит сами данные. Таблица базы данных похожа на электронную таблицу Excel (если быть точнее, то Excel хранит свои данные в виде собственного формата, построенного на основе технологии баз данных). Локальные таблицы баз данных могут храниться на локальном жёстком диске или централизовано сохраняться на сетевой диск файлового сервера. Эти файлы можно копировать с помощью стандартных средств как любой другой файл, потому что сами таблицы базы данных не привязаны к определённому месту расположения. Главное, чтобы программа могла найти таблицу. В каждой таблице должно быть одно уникальное поле, которое однозначно будет идентифицировать строку. Это поле называется ключевым. Эти поля очень часто используются для связывания нескольких таблиц между собой. Но даже если таблица не связана, ключевое поле всё равно обязательно. В качестве ключа желательно использовать численный тип и если позволяет база данных, то будет лучше если он будет типа "autoincrement" (автоматически увеличивающееся/уменьшающееся число или счётчик). Имена столбцов в таблице базе данных также должны быть уникальными, но в этом случае не обязательно числовыми. Их можно называть как угодно, лишь бы было уникально и понятно. Каждый столбец (поле базы данных) обязательно должен иметь определённый тип. Количество типов и их разновидности зависят от типа базы данных, например формат dBASE (файлы с расширением DBF) поддерживает только 6 типов, а Paradox уже до 15. База данных может храниться в одном файле (Access) или в нескольких (Paradox, dBase). Точнее сказать, данные таблицы всегда хранятся в одном файле, а вот дополнительная информация может располагаться в отдельных файлах. В качестве дополнительной информации могут быть индексы, ограничения или список значений по умолчанию для конкретных полей. Если хотя бы один из файлов запортится или будет удалён, то данные могут стать недоступными для редактирования.
Что такое индексы ? Очень часто данные из таблиц подвергаются каким-то изменениям, поэтому прежде чем произвести редактирование над какой-либо строкой, необходимо её найти. Даже статические таблицы, использующиеся в качестве справочников, тоже подвергаются операциям поиска перед выводом запрашиваемых данных. Поиск достаточно трудоёмкая операция, особенно если таблица содержит очень много строк. Индексы направлены на ускорение этой процедуры, а так же могут использоваться в качестве отправной точки при сортировке. На данном этапе достаточно знать, что не проиндексированное поле невозможно упорядочить.
Если надо, чтобы какая-то таблица была упорядочена по полю «Фамилия », то это поле надо сначала проиндексировать. Затем нужно только указать, что таблица должна работать сейчас с таким-то индексом, и она сортируется автоматически.
В хорошо спроектированной базе данных избыточность данных исключается, и вероятность сохранения противоречивых данных минимизируется. Таким образом, создание баз данных преследует две основные цели: понизить избыточность данных и повысить их надежность.
Жизненный цикл любого программного продукта, в том числе и системы управления базой данных, состоит (по-крупному) из стадий проектирования, реализации и эксплуатации.
Естественно, наиболее значительным фактором в жизненном цикле приложения, работающего с базой данных, является стадия проектирования. От того, насколько тщательно продумана структура базы, насколько четко определены связи между ее элементами, зависит производительность системы и ее информационная насыщенность, а значит - и время ее жизни.
Требования к базам данных
Итак, хорошо спроектированная база данных:
1. Удовлетворяет всем требованиям пользователей к содержимому базы данных. Перед проектированием базы необходимо провести обширные исследования требований пользователей к функционированию базы данных.
2. Гарантирует непротиворечивость и целостность данных. При проектировании таблиц нужно определить их атрибуты и некоторые правила, ограничивающие возможность ввода пользователем неверных значений. Для верификации данных перед непосредственной записью их в таблицу база данных должна осуществлять вызов правил модели данных и тем самым гарантировать сохранение целостности информации.
3. Обеспечивает естественное, легкое для восприятия структурирование информации. Качественное построение базы позволяет делать запросы к базе более “прозрачными” и легкими для понимания; следовательно, снижается вероятность внесения некорректных данных и улучшается качество сопровождения базы.
4. Удовлетворяет требованиям пользователей к производительности базы данных. При больших объемах информации вопросы сохранения производительности
начинают играть главную роль, сразу “высвечивая” все недочеты этапа проектирования.
Следующие пункты представляют основные шаги проектирования базы данных:
1. Определить информационные потребности базы данных.
2. Проанализировать объекты реального мира, которые необходимо смоделировать в базе данных. Сформировать из этих объектов сущности и характеристики этих сущностей (например, для сущности “деталь” характеристиками могут быть “название”, “цвет”, “вес” и т.п.) и сформировать их список.
3. Поставить в соответствие сущностям и характеристикам - таблицы и столбцы (поля) в нотации выбранной Вами СУБД (Paradox, dBase, FoxPro, Access, Clipper, InterBase, Sybase, Informix, Oracle и т.д.).
4. Определить атрибуты, которые уникальным образом идентифицируют каждый объект.
5. Выработать правила, которые будут устанавливать и поддерживать целостность данных.
6. Установить связи между объектами (таблицами и столбцами), провести нормализацию таблиц.
7. Спланировать вопросы надежности данных и, при необходимости, сохранения секретности информации.
Похожая информация.
Аннотация: Эта и две следующие лекции посвящены вопросам теории реляционных баз данных. Поскольку все направление реляционного подхода к организации баз данных является сугубо практическим, эта теория, главным образом, прагматическая. Основная проблема, на решение которой направлена теория реляционных баз данных, состоит в обнаружении полезных свойств некоторых схем баз данных и выработке способов построения таких схем. Принято кратко называть эту проблему проблемой проектирования реляционных баз данных.
Введение
Несмотря на свою практическую ориентированность, теория реляционных баз данных является самостоятельным научным направлением, в котором работали (и продолжают работать) многие известные исследователи, чьи имена будут встречаться в наших лекциях. Мы не планировали в данном курсе подробно описывать основные результаты в области . Наша цель состоит в том, чтобы обеспечить только определения и утверждения, необходимые для общего понимания процесса проектирования реляционных баз данных на основе нормализации.
Поскольку наиболее важные с практической точки зрения свойства реляционных баз данных базируются на понятии функциональной зависимости , мы выделили в отдельную лекцию краткое обсуждение соответствующих теоретических вопросов. Среди этих вопросов наибольший интерес представляют замыкания и покрытия множеств функциональных зависимостей , аксиомы Армстронга и теорема Хита о достаточном условии декомпозиции отношения без потерь . Понятия и утверждения данной лекции действительно нужны для усвоения материала лекции 7, но мы стремились еще и продемонстрировать читателям на несложных примерах, что собой представляет теория реляционных баз данных , каков уровень ее сложности и насколько она понятна интуитивно.
Заметим, что мы не выделяли в отдельные лекции теоретический материал, касающийся многозначных зависимостей и зависимостей соединения . Это было сделано по двум причинам. Во-первых, эти виды зависимостей реже встречаются при моделировании предметной области средствами баз данных. Поэтому мы сочли достаточным представить внутри лекции 8 только основы соответствующего теоретического материала. Во-вторых, хотя теория многозначных зависимостей и зависимостей соединения , по сути, не намного сложнее теории функциональных зависимостей , ее определения и утверждения слишком громоздки для данного курса.
Функциональные зависимости
Наиболее важные с практической точки зрения нормальные формы отношений основываются на фундаментальном в теории реляционных баз данных понятии функциональной зависимости . Для дальнейшего изложения нам потребуется несколько определений и утверждений (по ходу изложения мы будем пояснять их и иллюстрировать).
Общие определения
Пусть задана переменная отношения r , и X и Y являются произвольными подмножествами заголовка r ("составными" атрибутами).
В значении переменной отношения r атрибут Y функционально зависит от атрибута X в том и только в том случае, если каждому значению X соответствует в точности одно значение Y . В этом случае говорят также, что атрибут X функционально определяет атрибут Y (X является детерминантом (определителем ) для Y , а Y является зависимым от X ). Будем обозначать это как r.X->r.Y .
Для примера будем использовать отношение СЛУЖАЩИЕ_ПРОЕКТЫ {СЛУ_НОМ, СЛУ_ИМЯ, СЛУ_ЗАРП, ПРО_НОМ, ПРОЕКТ_РУК} (рис. 6.1). Очевидно, что если СЛУ_НОМ является первичным ключом отношения СЛУЖАЩИЕ , то для этого отношения справедлива функциональная зависимость (Functional Dependency – FD) СЛУ_НОМ->СЛУ_ИМЯ .
На самом деле, для тела отношения СЛУЖАЩИЕ_ПРОЕКТЫ в том виде, в котором оно показано на рис. 6.1 , выполняются еще и следующие FD (1):
Рис.
6.1.
СЛУ_НОМ->СЛУ_ИМЯ СЛУ_НОМ->СЛУ_ЗАРП СЛУ_НОМ->ПРО_НОМ СЛУ_НОМ->ПРОЕКТ_РУК {СЛУ_НОМ, СЛУ_ИМЯ}->СЛУ_ЗАРП {СЛУ_НОМ, СЛУ_ИМЯ}->ПРО_НОМ {СЛУ_НОМ, СЛУ_ИМЯ}->{СЛУ_ЗАРП, ПРО_НОМ} … ПРО_НОМ->ПРОЕКТ_РУК и т.д.
Поскольку имена всех служащих различны, то выполняются и такие FD (2):
СЛУ_ИМЯ->СЛУ_НОМ СЛУ_ИМЯ->СЛУ_ЗАРП СЛУ_ИМЯ->ПРО_НОМ и т.д.
Более того, для примера на рис. 6.1 выполняется и FD (3):
СЛУ_ЗАРП->ПРО_НОМ
Однако заметим, что природа FD группы (1) отличается от природы FD групп (2) и (3). Логично предположить, что идентификационные номера служащих должны быть всегда различны, а у каждого проекта имеется только один руководитель. Поэтому FD группы (1) должны быть верны для любого допустимого значения переменной отношения СЛУЖАЩИЕ_ПРОЕКТЫ и могут рассматриваться как инварианты , или ограничения целостности этой переменной отношения .
FD группы (2) базируются на менее естественном предположении о том, что имена всех служащих различны. Это соответствует действительности для примера из рис. 6.1 , но возможно, что с течением времени FD группы (2) не будут выполняться для какого-либо значения переменной отношения СЛУЖАЩИЕ_ПРОЕКТЫ .
Наконец, FD группы (3) основана на совсем неестественном предположении, что никакие двое служащих, участвующие в разных проектах, не получают одинаковую зарплату. Опять же, данное предположение верно для примера из рис. 6.1 , но, скорее всего, это случайное совпадение.
В дальнейшем нас будут интересовать только те функциональные зависимости , которые должны выполняться для всех возможных значений переменных отношений .
Заметим, что если атрибут A отношения r является возможным ключом, то для любого атрибута B этого отношения всегда выполняется
