Объясните в чем разница между детерминантом и возможным ключом отношения
Методы проектирования логических моделей реляционных баз данных. Декомпозиция и синтез отношений
Методы проектирования на основе декомпозиции отношений
Понятие о методах декомпозиции отношений
Предположим, что схема базы данных содержит F-зависимости. Из положений теории о F-зависимостях следует, что если отношения базы данных находятся в нормальной форме Бойса-Кодда (НФБК), то проектирование логической модели базы данных можно считать завершенным в этом классе зависимостей. Как видно, теория дает полезный (!) критерий останова проектирования.
Сформулируем наглядный критерий, позволяющий определить, находится ли отношение в НФБК. Для этого введем следующее вспомогательное понятие.
Определение 3. Пусть дана ФЗ:
и В функционально не зависит от любого подмножества А, тогда А называется детерминантом В.
и В функционально не зависит от любого подмножества А, тогда А называется детерминантом В.Детерминантами в отношениях являются атрибуты левых частей ФЗ. Возможные ключи (см. учебный элемент » Реляционная модель данных «) идентифицируются путем нахождения минимального множества значений атрибутов, которые определяют значения всех остальных атрибутов в отношении. Напомним понятие возможного ключа отношения как атрибута или атрибутов данного отношения, который (-ые) могут быть в данном отношении выбраны в качестве первичного.
Тогда критерий Кодда, позволяющий определить, находится ли отношение в НФБК, может быть сформулирован следующим образом:
Таким образом, при декомпозиции отношений необходимо строить списки возможных ключей и детерминантов и сравнивать их на совпадение. Устранив таким образом большинство потенциальных аномалий, проектирование можно завершить.
Алгоритм метода декомпозиции отношений
Алгоритм метода декомпозиции отношений
Уточним некоторые аспекты метода декомпозиции.
Если
то в качестве ФЗ для осуществления проекции используется крайняя правая зависимость или «конец цепочки» 
Методы проектирования на основе синтеза отношений
Некоторые проблемы метода декомпозиции
Первая ситуация: в процессе декомпозиции потеряна ФЗ 
и если отношения R1 и R2 будут использованы для создания базы данных, то нельзя гарантировать, что связи между этими атрибутами будут внесены в БД корректно. Отсюда вытекает второе эмпирическое правило выбора ФЗ для выполнения проекции: не следует использовать ФЗ в качестве ФЗ для осуществления проекции, если ее левая часть является детерминантом другой ФЗ. Эта проблема разрешается путем применения правила цепочки.
Прежде чем перейти к изучению метода синтеза, рассмотрим использование элементов синтеза в декомпозиции. Как можно было заметить, декомпозиция осложняется при наличии транзитивных ФЗ. Особенностью транзитивной ФЗ является ее избыточность. ФЗ принято считать избыточной, если она содержит в себе информацию, которая может быть получена из других ФЗ базы данных. Исключение избыточной транзитивной ФЗ из базы данных может быть выполнено без отрицательного воздействия на ее результаты. Избыточность присуща не только транзитивным ФЗ и, следовательно, избыточные ФЗ желательно исключать до применения алгоритма декомпозиции.
Понятие о методах синтеза отношений
Исключить избыточность в исходном наборе ФЗ можно путем применения правил вывода ФЗ (См. учебный элемент » Функциональные зависимости «). Как известно, для класса F-зависимостей достаточно использовать шесть таких правил. При этом критерием останова процедуры исключения может служить получение минимального покрытия исходного набора ФЗ.
Неединственность минимальных покрытий указывает на то, что порядок исключения избыточных ФЗ может оказать влияние на полученные результаты. Отсюда следует эмпирическое правило:
Избыточные ФЗ следует удалять по одной, каждый раз проводя анализ полученного набора ФЗ на избыточность.
Первое. Если универсальное отношение содержит большое количество атрибутов, например более трех десятков, то ручное проектирование становится трудоемким и может, с одной стороны, привести к большим временным затратам, а с другой стороны, породить недопустимое для практики число отношений в базе данных. Поэтому в данном случае следует подумать об автоматизации процесса проектирования, т.е. создать программу проектирования схем баз данных.
Кроме того, задача приведения исходных отношений к НФБК может оказаться невыполнимой. Такой факт имел место в практике проектирования. Поскольку НФБК может не существовать на заданном наборе ФЗ, то логичным было бы отказаться от требования приведения отношений базы данных к этой форме. Эта ситуация подкрепляется и теоретически: при любом заданном множестве F-зависимостей над схемой r БД можно построить схему БД в 3НФ.
Таким образом, ограничимся поиском 3НФ в ходе применения метода синтеза, при этом остаются проблемы, связанные с выполнением операций над данными.
Методы проектирования логических моделей реляционных баз данных. Декомпозиция и синтез отношений
Методы проектирования на основе декомпозиции отношений
Понятие о методах декомпозиции отношений
Предположим, что схема базы данных содержит F-зависимости. Из положений теории о F-зависимостях следует, что если отношения базы данных находятся в нормальной форме Бойса-Кодда (НФБК), то проектирование логической модели базы данных можно считать завершенным в этом классе зависимостей. Как видно, теория дает полезный (!) критерий останова проектирования.
Сформулируем наглядный критерий, позволяющий определить, находится ли отношение в НФБК. Для этого введем следующее вспомогательное понятие.
Определение 3. Пусть дана ФЗ:
Детерминантами в отношениях являются атрибуты левых частей ФЗ. Возможные ключи (см. учебный элемент » Реляционная модель данных «) идентифицируются путем нахождения минимального множества значений атрибутов, которые определяют значения всех остальных атрибутов в отношении. Напомним понятие возможного ключа отношения как атрибута или атрибутов данного отношения, который (-ые) могут быть в данном отношении выбраны в качестве первичного.
Тогда критерий Кодда, позволяющий определить, находится ли отношение в НФБК, может быть сформулирован следующим образом:
Таким образом, при декомпозиции отношений необходимо строить списки возможных ключей и детерминантов и сравнивать их на совпадение. Устранив таким образом большинство потенциальных аномалий, проектирование можно завершить.
Алгоритм метода декомпозиции отношений
Алгоритм метода декомпозиции отношений
Уточним некоторые аспекты метода декомпозиции.
Если
Методы проектирования на основе синтеза отношений
Некоторые проблемы метода декомпозиции
Первая ситуация: в процессе декомпозиции потеряна ФЗ и если отношения R1 и R2 будут использованы для создания базы данных, то нельзя гарантировать, что связи между этими атрибутами будут внесены в БД корректно. Отсюда вытекает второе эмпирическое правило выбора ФЗ для выполнения проекции: не следует использовать ФЗ в качестве ФЗ для осуществления проекции, если ее левая часть является детерминантом другой ФЗ. Эта проблема разрешается путем применения правила цепочки.
Прежде чем перейти к изучению метода синтеза, рассмотрим использование элементов синтеза в декомпозиции. Как можно было заметить, декомпозиция осложняется при наличии транзитивных ФЗ. Особенностью транзитивной ФЗ является ее избыточность. ФЗ принято считать избыточной, если она содержит в себе информацию, которая может быть получена из других ФЗ базы данных. Исключение избыточной транзитивной ФЗ из базы данных может быть выполнено без отрицательного воздействия на ее результаты. Избыточность присуща не только транзитивным ФЗ и, следовательно, избыточные ФЗ желательно исключать до применения алгоритма декомпозиции.
Понятие о методах синтеза отношений
Исключить избыточность в исходном наборе ФЗ можно путем применения правил вывода ФЗ (См. учебный элемент » Функциональные зависимости «). Как известно, для класса F-зависимостей достаточно использовать шесть таких правил. При этом критерием останова процедуры исключения может служить получение минимального покрытия исходного набора ФЗ.
Неединственность минимальных покрытий указывает на то, что порядок исключения избыточных ФЗ может оказать влияние на полученные результаты. Отсюда следует эмпирическое правило:
Избыточные ФЗ следует удалять по одной, каждый раз проводя анализ полученного набора ФЗ на избыточность.
Первое. Если универсальное отношение содержит большое количество атрибутов, например более трех десятков, то ручное проектирование становится трудоемким и может, с одной стороны, привести к большим временным затратам, а с другой стороны, породить недопустимое для практики число отношений в базе данных. Поэтому в данном случае следует подумать об автоматизации процесса проектирования, т.е. создать программу проектирования схем баз данных.
Кроме того, задача приведения исходных отношений к НФБК может оказаться невыполнимой. Такой факт имел место в практике проектирования. Поскольку НФБК может не существовать на заданном наборе ФЗ, то логичным было бы отказаться от требования приведения отношений базы данных к этой форме. Эта ситуация подкрепляется и теоретически: при любом заданном множестве F-зависимостей над схемой r БД можно построить схему БД в 3НФ.
Таким образом, ограничимся поиском 3НФ в ходе применения метода синтеза, при этом остаются проблемы, связанные с выполнением операций над данными.
Детерминанты и их роль в базе данных
Детерминанты определяют значения, присвоенные другим атрибутам
Определитель в таблице базы данных – это атрибут, который можно использовать для определения значений, присвоенных другим атрибутам в той же строке. По этому определению любой первичный ключ или ключ-кандидат является определителем, но могут быть детерминанты, которые не являются первичными или потенциальными ключами.
Например, компания может использовать таблицу с атрибутами, и.