Какие виды аномалий обновления возникают в бд
Перейти к содержимому

Какие виды аномалий обновления возникают в бд

  • автор:

Аномалии обновления

Даже одного взгляда на таблицу отношения СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ достаточно, чтобы увидеть, что данные хранятся в ней с большой избыточностью. Во многих строках повторяются фамилии сотрудников, номера телефонов, наименования проектов. Кроме того, в данном отношении хранятся вместе независимые друг от друга данные — и данные о сотрудниках, и об отделах, и о проектах, и о работах по проектам. Пока никаких действий с отношением не производится, это не страшно. Но как только состояние предметной области изменяется, то, при попытках соответствующим образом изменить состояние базы данных, возникает большое количество проблем.

Исторически эти проблемы получили название аномалии обновления. Попытки дать строгое понятие аномалии в базе данных не являются вполне удовлетворительными [51, 7]. В данных работах аномалии определены как противоречие между моделью предметной области и физической моделью данных, поддерживаемых средствами конкретной СУБД. «Аномалии возникают в том случае, когда наши знания о предметной области оказываются, по каким-то причинам, невыразимыми в схеме БД или входящими в противоречие с ней» [7]. Мы придерживаемся другой точки зрения, заключающейся в том, что аномалий в смысле определений упомянутых авторов нет, а есть либо неадекватность модели данных предметной области, либо некоторые дополнительные трудности в реализации ограничений предметной области средствами СУБД. Более глубокое обсуждение проблемы строгого определения понятия аномалий выходит за пределы данной работы.

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

  • Аномалии вставки (INSERT)
  • Аномалии обновления (UPDATE)
  • Аномалии удаления (DELETE)
  • В отношении СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ можно привести примеры следующих аномалий:

    1.1. Избыточность данных и аномалии обновления.

    Основная цель проектирования реляционной БД – группирование атрибутов в отношениях таким образом, чтобы минимизировать избыточность данных (сокращение объема вторичной памяти для хранения БД) и повышение надежности при работе с данными. Обычно процесс проектирования отношений реляционной БД ведется на основе разработанной ER-диаграммы или на основе просто здравого смысла разработчика. В общем случае при таком подходе расположение атрибутов в отношениях неоптимальное.

    При работе с отношениями, содержащими избыточные данные, могут возникать проблемы – аномалии обновления. Аномалии обновления делят на три вида:

    1) Аномалии вставки – возникают при добавлении новых несогласованных данных (нарушающих целостность данных в отношении).

    2) Аномалии изменения – возникают при изменении части ранее введенных данных; частичное обновление сведений приведет к нарушению целостности данных отношения (перестанет выполняться оговоренная выше зависимость).

    3) Аномалии удаления – возникают при удалении строк из отношений.

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

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

    Функциональная зависимость (ФЗ) – это соотношение проекций R[A] и R[B] при котором в каждый момент времени любому элементу R[A] соответствует только один элемент проекции R[B], входящий в вместе в какой-либо кортеж отношения R.

    Полная функциональная зависимость (ПФЗ). Набор атрибутов В функционально зависит от А, и не зависит функционально от любого подмножества А.

    Транзитивная функциональная зависимость (ТФЗ). Пусть существует набор атрибутов С, таких что:

    1. С не является подмножеством А;
    2. С не включает в себя В;
    3. Существует функциональная зависимость С от А ();
    4. Не существует функциональная зависимость А от С ();
    5. Существует функциональная зависимость B от C ().

    Детерминант отношения. Если в отношении существуют несколько ФЗ, то каждый атрибут или набор атрибутов, от которого зависит другой атрибут, называется детерминантом отношения. Выявление смысловой зависимости между данными – один из способов формализации смысловой информации о данных. Функциональная зависимость описывает связь типа многие-к-одному между атрибутами отношения, где много – детерминант функциональной зависимости. Функциональная зависимость является семантическим свойством атрибутов отношения. Если в отношении R, содержащем атрибуты A и B, атрибут B функционально зависит от атрибута A (А является детерминантом атрибута B) AB, то в каждом кортеже этого отношения каждое конкретное значение атрибута A всегда связано только с одним значением атрибута B. Атрибуты A и B могут быть составными атрибутами. Особенности функциональных зависимостей, лежащие в основе процесса нормализации: • функциональная зависимость является специализированным правилом целостности – она накладывает ограничения на допустимые значения атрибутов отношений; эту особенность можно использовать при обновлении БД, т.к. зная какие функциональные зависимости есть в отношении, можно проанализировать нарушат ли новые данные целостность данных отношения; • функциональная зависимость является обобщением понятия потенциального ключа; функциональные зависимости позволяют определить все потенциальные ключи отношения (и соответственно – первичный ключ): все атрибуты отношения, которые не являются частью первичного (или потенциального) ключа, должны функционально зависеть от этого ключа; если не все остальные атрибуты отношения зависят от некоторого детерминанта, то этот детерминант не является потенциальным ключом этого отношения. Одни функциональные зависимости подразумевают другие зависимости. Для данного множества зависимостей S замыканием S + называется множество всех функциональных зависимостей, подразумеваемых зависимостями множества S. Множество S обязательно является подмножеством собственного замыкания S + . Правила логического вывода Армстронга (аксиомы Армстронга) обеспечивают исчерпывающую и полную основу для вычисления замыкания S + для заданного множества S: -рефлексивность XX; -пополнение XY =>XZY; — аддитивность (XY)and(XZ) =>XYZ; — проективность XYZ =>XY; — транзитивность (XY)and(YZ) =>XZ; — псевдотранзитивность (XY)and(YZW) =>X ZW; Два множества функциональных зависимостей S1 и S2 эквивалентны тогда и только тогда, когда они являются покрытиями друг друга, то есть S1 + =S2 + . Каждое множество функциональных зависимостей эквивалентно, по крайней мере, одному неприводимому множеству. Множество функциональных зависимостей является неприводимым, если: • каждая функциональная зависимость этого множества имеет одноэлементную правую часть; • ни одна функциональная зависимость множества не может быть устранена без изменения замыкания этого множества; • ни один атрибут не может быть устранен из левой части любой функциональной зависимости без изменения замыкания множества. Если I является неприводимым множеством, эквивалентным множеству S, то проверка выполнения функциональных зависимостей из множества I автоматически проверяет выполнение всех функциональных зависимостей множества S.

    Какие виды аномалий обновления возникают в бд

    Аномалии

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

    Сегодняшняя лекция посвящена вопросу, «какие проблемы связанные с хранилищами данных мы можем предотвратить на этапе планирования?». Здесь нам на помощь приходит реляционная алгебра, которая в конечном счете будет задействована при хранении данных в базе данных.

    Аномалии — это проблемы, возникающие в данных из-за дефектов проектирования БД. Выделяют аномалии вставки, удаления и обновления. Заметим, что все аномалии связаны с появлением несогласованности данных при их изменении. Аномалий чтения не бывает.

    Аномалии вставки (INSERT)

    Пример: Отношение «сторудник_проект» нельзя вставить данные о проекте, над которым пока не работает ни один сотрудник.

    Причина аномалии — хранение в одном отношении разнородной информации (и о сотрудниках, и о проектах, и о работах по проекту).

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

    Аномалии обновления (UPDATE)

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

    Причина аномалии — избыточность данных, также порожденная тем, что в одном отношении хранится разнородная информация.

    Вывод — увеличивается сложность разработки базы данных. База данных, основанная на такой модели, будет работать правильно только при наличии дополнительного программного кода в виде триггеров.

    Аномалии удаления (DELETE)

    При удалении некоторых данных может произойти потеря другой информации. Например, если закрыть проект «Космос» и удалить все строки, в которых он встречается, то будут потеряны все данные о сотруднике Петрове. Если удалить сотрудника Сидорова, то будет потеряна информация о том, что в отделе номер 2 находится телефон 33-22-11. Если по проекту временно прекращены работы, то при удалении данных о работах по этому проекту будут удалены и данные о самом проекте (наименование проекта). При этом если был сотрудник, который работал только над этим проектом, то будут потеряны и данные об этом сотруднике.

    Причина аномалии — хранение в одном отношении разнородной информации (и о сотрудниках, и о проектах, и о работах по проекту).

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

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

    Пусть задано отношение R, которое содержит наборы атрибутов А и В. В отношении R набор атрибутов В функционально зависит от А и А функционально определяет В тогда и только тогда, когда в любой момент времени каждому значению проекции R[A] отвечает ровно одно значение R[В].

    Нормализация

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

    • группировка атрибутов в отношении предметной области;
    • распределение атрибутов по отношениям базы данных.

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

    Во многом процесс приведения к нормальным формам просто формализует опыт, который нарабатывает проектировщик баз данных в процессе своей работы. Сам процесс нормализации полезен для большинства проектов. Однако, как показывает практика, в маленьких проектах он может быть избыточным, а в крупных проектах разработчики сознательно могут производить деморализацию для повышения скорости доступа к данным. Так грамотное применение практически всех NoSQL решений требует деморализации. На этапе разработки системы вам нужно знать, была ли проведена нормализация. Если нет — в каких случаях от нее отклонились. Если нормализация не была проведена ответственность за консистентность данных ложится на плечи программиста, который своим кодом должен предусмотреть методы ее поддержания, проверки и восстановления. То есть ответственность СУБД переносится на плечи программиста в угоду скорости работы продукта.

    Отношение находится в первой нормальной форме ( 1НФ ), если все атрибуты отношения являются простыми (требование атомарности атрибутов в реляционной модели), т.е. не имеют компонентов.

    Пример: Приведение отношения к 1НФ

    Отношение SHIPMENT (ОТГРУЗКА) является ненормализованным. Оно содержит повторяющиеся группы, представляющие массив значений, 1st Consignment, 2st Consignment, 3st Consignment (партии грузов).

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

    Использование отношения, представленного не в 1НФ, может породить следующие проблемы:

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

    Приведение отношения SHIPMENT к 1НФ заключается в изъятии данных о партиях груза из отношения SHIPMENT и создании для них связанного подчиненного отношения CONSIGNMENT (ПАРТИЯ_ГРУЗА).

    Результат приведения отношения SHIPMENT к 1НФ показан на слайде.

    Все нормальные формы «вложены» друг в друга. Если отношение удовлетворяет 2 нормальной форме, значит оно должно удовлетворять и 1 нормальной форме. Если отношение удовлетворяет 3 нормальной форме, оно должно удовлетворять 1 и 2 нормальным формам.

    Атрибут отношения считается ключевым если он является элементом какого-либо ключа отношения. В противном случае атрибут будет считаться неключевым атрибутом.

    Так в отношении (Город, Адрес, Почтовый_индекс) все атрибуты являются ключевыми, поскольку при заданных ФЗ (город, адрес) почтовый_индекс и почтовый_индекс → город ключами являются пары (город, адрес) и (адрес, почтовый_индекс).

    Отношение находится во второй нормальной форме ( 2НФ ), если оно находится в 1НФ, и все неключевые атрибуты отношения функционально- полно зависят от составного ключа отношения.

    Пример. Приведение отношения ко 2НФ.

    Отношение SHIPMENT содержит частичную ФЗ: неключевой атрибут Ship Capacity (грузоподъемность корабля) не зависит от ключевого атрибута Departure Date (даты убытия), а зависит от ключевого атрибута Ship Registration Number (регистрационный номер корабля).

    Использование отношения, представленного не во 2НФ, может породить следующие проблемы:

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

    Приведение отношения SHIPMENT ко 2НФ заключается в изъятии атрибутов Отношения SHIPMENT и создании для нее связанного подчиненного отношения SHIP.

    Отношение находится в третьей нормальной форме ( 3НФ ), если оно находится во 2НФ, и все неключевые атрибуты отношения зависят только от первичного ключа.

    Возможна следующая проблема: наличие транзитивной зависимости не позволяет связать значения Y и Х, если не существует значения А, связанного со значением Y. Это затрудняет вставку и обновление данных, которые необходимо выполнить сразу для пары связей, а в случае удаления данных приводит к потере связи.

    Пример. Приведение отношения к 3НФ. Отношение SHIPMENT содержит транзитивную ФЗ: атрибут Customs Declaration (таможенная декларация) является по своей сути свойством атрибутов Origin (пункт отправления) и Destination (пункт назначения).

    Нормальные формы выских порядков

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

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

    Отношение находится в нормальной форме Бойса-Кодда (НФБК), если оно находится в 3НФ, и в нем отсутствуют зависимости ключевых атрибутов от неключевых атрибутов.

    Иными словами, НФБК допускает наличие только таких ФЗ, в которых ключ определяет один или более других атрибутов

    Пример: в отношение (Город, Адрес, Почтовый_индекс), находящееся в 3НФ, невозможно записать кортеж для города с известным почтовым индексом, если не известен адрес с этим почтовым индексом. Данное отношение не находится в НФБК, так как имеет место ФЗ Почтовый_индексГород, а атрибут почтовый_индекс не является ключом этого отношения.

    Отношение находится в четвертой нормальной форме ( 4НФ ), если оно находится в 3НФ или НФБК и все независимые многозначные ФЗ разнесены в отдельные отношения с одним и тем же ключом.

    Иными словами, 4НФ применяется при наличии в отношении более чем одной многозначной ФЗ и требует, чтобы отношение не содержало независимых многозначных ФЗ.

    Пример. Приведение к 4НФ

    Рассмотрим отношение, содержащее сведения о кораблях (Ship), совершаемых ими рейсах (Voyage) и капитанах (Captain)

    Отношение находится в НФБК и содержит только многозначные ФЗ.

    Однако имеет место аномалия удаления: если капитан Петров уйдет в отставку и все кортежи о нем будут удалены, то будут потеряны сведения о том, что корабль Потемкин совершает рейсы Санкт-Петербург — Марсель. Если добавить новый рейс, то, возможно, придется ввести несколько кортежей в наше отношение.

    Приведение отношения к 4НФ заключается в выделении для каждой многозначной ФЗ своего отношения представлено на слайде.

    Нормализация отношений выполнялась путем разложения (декомпозиции) схем отношений.

    Очевидно, что при таком подходе должен соблюдаться принцип обратимости: соединение проекций должно приводить к исходным отношениям.

    Это предполагает отсутствие потери кортежей; появление ранее не существовавших кортежей; сохранение ФЗ (семантика взаимосвязей между данными не должна нарушаться).

    Декомпозиция схем отношений не всегда гарантирует обратимость. Это обстоятельство связано с существованием класса ФЗ по соединению.

    Если отношение удовлетворяет ФЗ по соединению, то оно может быть восстановлено по своим проекциям.

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

    Отношение находится в пятой нормальной форме ( 5НФ ), если оно находится в 4НФ и удовлетворяет зависимости по соединению относительно своих проекций.

    5НФ называют также нормальной формой с проецированием соединений. Она используется для разрешения трех и более отношений, которые связаны более чем тремя ФЗ по типу «многие-ко-многим»

    Приведение отношения к 5НФ заключается во введении еще одного отношения, связывающего три исходных отношения, как показано на слайде.

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

    Выводы

    • 1НФ — все атрибуты отношения простые;
    • 2НФ — отношение находится в 1НФ и не содержит частичных ФЗ;
    • 3НФ — отношение находится во 2НФ и не содержит транзитивных ФЗ от ключа;
    • НФБК — отношение находится в 3НФ и не содержит ФЗ ключей от неключевых атрибутов;
    • 4НФ, применяется при наличии более чем одной многозначной ФЗ — отношение находится в НФБК или 3НФ и не содержит независимых многозначных ФЗ;
    • 5НФ — отношение находится в 4НФ и не содержит ФЗ по соединению.
    Дополнительные материалы
    Тема 4 Нормализация структуры базы данных Краткий конспект

    Нормализация отношений. Шесть нормальных форм

    В данной теме я затрону 6 нормальных форм и методы приведения таблиц в эти формы.

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

    Используемые термины

    Атрибут — свойство некоторой сущности. Часто называется полем таблицы.

    Домен атрибута — множество допустимых значений, которые может принимать атрибут.

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

    Отношение — конечное множество кортежей (таблица).

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

    Проекция — отношение, полученное из заданного путём удаления и (или) перестановки некоторых атрибутов.

    Функциональная зависимость между атрибутами (множествами атрибутов) X и Y означает, что для любого допустимого набора кортежей в данном отношении: если два кортежа совпадают по значению X, то они совпадают по значению Y. Например, если значение атрибута «Название компании» — Canonical Ltd, то значением атрибута «Штаб-квартира» в таком кортеже всегда будет Millbank Tower, London, United Kingdom. Обозначение: -> .

    Нормальная форма — требование, предъявляемое к структуре таблиц в теории реляционных баз данных для устранения из базы избыточных функциональных зависимостей между атрибутами (полями таблиц).

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

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

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

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

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

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

    Первая нормальная форма

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

    Например, есть таблица «Автомобили»:

    Фирма Модели
    BMW M5, X5M, M1
    Nissan GT-R

    Нарушение нормализации 1НФ происходит в моделях BMW, т.к. в одной ячейке содержится список из 3 элементов: M5, X5M, M1, т.е. он не является атомарным. Преобразуем таблицу к 1НФ:

    Фирма Модели
    BMW M5
    BMW X5M
    BMW M1
    Nissan GT-R
    Вторая нормальная форма

    Отношение находится во 2НФ, если оно находится в 1НФ и каждый не ключевой атрибут неприводимо зависит от Первичного Ключа(ПК).

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

    Например, дана таблица:

    Модель Фирма Цена Скидка
    M5 BMW 5500000 5%
    X5M BMW 6000000 5%
    M1 BMW 2500000 5%
    GT-R Nissan 5000000 10%

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

    Модель Фирма Цена
    M5 BMW 5500000
    X5M BMW 6000000
    M1 BMW 2500000
    GT-R Nissan 5000000
    Фирма Скидка
    BMW 5%
    Nissan 10%
    Третья нормальная форма

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

    Модель Магазин Телефон
    BMW Риал-авто 87-33-98
    Audi Риал-авто 87-33-98
    Nissan Некст-Авто 94-54-12

    Таблица находится во 2НФ, но не в 3НФ.
    В отношении атрибут «Модель» является первичным ключом. Личных телефонов у автомобилей нет, и телефон зависит исключительно от магазина.
    Таким образом, в отношении существуют следующие функциональные зависимости: Модель → Магазин, Магазин → Телефон, Модель → Телефон.
    Зависимость Модель → Телефон является транзитивной, следовательно, отношение не находится в 3НФ.
    В результате разделения исходного отношения получаются два отношения, находящиеся в 3НФ:

    Магазин Телефон
    Риал-авто 87-33-98
    Некст-Авто 94-54-12
    Модель Магазин
    BMW Риал-авто
    Audi Риал-авто
    Nissan Некст-Авто
    Нормальная форма Бойса-Кодда (НФБК) (частная форма третьей нормальной формы)

    Определение 3НФ не совсем подходит для следующих отношений:
    1) отношение имеет два или более потенциальных ключа;
    2) два и более потенциальных ключа являются составными;
    3) они пересекаются, т.е. имеют хотя бы один общий атрибут.

    Для отношений, имеющих один потенциальный ключ (первичный), НФБК является 3НФ.

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

    Предположим, рассматривается отношение, представляющее данные о бронировании стоянки на день:

    Номер стоянки Время начала Время окончания Тариф
    1 09:30 10:30 Бережливый
    1 11:00 12:00 Бережливый
    1 14:00 15:30 Стандарт
    2 10:00 12:00 Премиум-В
    2 12:00 14:00 Премиум-В
    2 15:00 18:00 Премиум-А
    • «Бережливый»: стоянка 1 для льготников
    • «Стандарт»: стоянка 1 для не льготников
    • «Премиум-А»: стоянка 2 для льготников
    • «Премиум-B»: стоянка 2 для не льготников.

    Отношение находится в 3НФ. Требования второй нормальной формы выполняются, так как все атрибуты входят в какой-то из потенциальных ключей, а неключевых атрибутов в отношении нет. Также нет и транзитивных зависимостей, что соответствует требованиям третьей нормальной формы. Тем не менее, существует функциональная зависимость Тариф → Номер стоянки, в которой левая часть (детерминант) не является потенциальным ключом отношения, то есть отношение не находится в нормальной форме Бойса — Кодда.

    Недостатком данной структуры является то, что, например, по ошибке можно приписать тариф «Бережливый» к бронированию второй стоянки, хотя он может относиться только к первой стоянки.

    Можно улучшить структуру с помощью декомпозиции отношения на два и добавления атрибута Имеет льготы, получив отношения, удовлетворяющие НФБК (подчёркнуты атрибуты, входящие в первичный ключ.):

    Тариф Номер стоянки Имеет льготы
    Бережливый 1 Да
    Стандарт 1 Нет
    Премиум-А 2 Да
    Премиум-В 2 Нет

    Бронирование

    Тариф Время начала Время окончания
    Бережливый 09:30 10:30
    Бережливый 11:00 12:00
    Стандарт 14:00 15:30
    Премиум-В 10:00 12:00
    Премиум-В 12:00 14:00
    Премиум-А 15:00 18:00
    Четвертая нормальная форма

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

    В отношении R (A, B, C) существует многозначная зависимость R.A -> -> R.B в том и только в том случае, если множество значений B, соответствующее паре значений A и C, зависит только от A и не зависит от С.

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

    Такая переменная отношения не соответствует 4НФ, так как существует следующая многозначная зависимость:

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

    Для предотвращения аномалии нужно декомпозировать отношение, разместив независимые факты в разных отношениях. В данном примере следует выполнить декомпозицию на и .

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

    Пятая нормальная форма

    Отношения находятся в 5НФ, если оно находится в 4НФ и отсутствуют сложные зависимые соединения между атрибутами.
    Если «Атрибут_1» зависит от «Атрибута_2», а «Атрибут_2» в свою очередь зависит от «Атрибута_3», а «Атрибут_3» зависит от «Атрибута_1», то все три атрибута обязательно входят в один кортеж.

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

    Например, некоторая таблица содержит три атрибута «Поставщик», «Товар» и «Покупатель». Покупатель_1 приобретает несколько Товаров у Поставщика_1. Покупатель_1 приобрел новый Товар у Поставщика_2. Тогда в силу изложенного выше требования Поставщик_1 обязан поставлять Покупателю_1 тот же самый новый Товар, а Поставщик_2 должен поставлять Покупателю_1, кроме нового Товара, всю номенклатуру Товаров Поставщика_1. Этого на практике не бывает. Покупатель свободен в своем выборе товаров. Поэтому для устранения отмеченного затруднения все три атрибута разносят по разным отношениям (таблицам). После выделения трех новых отношений (Поставщик, Товар и Покупатель) необходимо помнить, что при извлечении информации (например, о покупателях и товарах) необходимо в запросе соединить все три отношения. Любая комбинация соединения двух отношений из трех неминуемо приведет к извлечению неверной (некорректной) информации. Некоторые СУБД снабжены специальными механизмами, устраняющими извлечение недостоверной информации. Тем не менее, следует придерживаться общей рекомендации: структуру базы данных строить таким образом, чтобы избежать применения 4НФ и 5НФ.

    Пятая нормальная форма ориентирована на работу с зависимыми соединениями. Указанные зависимые соединения между тремя атрибутами встречаются очень редко. Зависимые соединения между четырьмя, пятью и более атрибутами указать практически невозможно.

    Доменно-ключевая нормальная форма

    Переменная отношения находится в ДКНФ тогда и только тогда, когда каждое наложенное на неё ограничение является логическим следствием ограничений доменов и ограничений ключей, наложенных на данную переменную отношения.
    Ограничение домена – ограничение, предписывающее использовать для определённого атрибута значения только из некоторого заданного домена. Ограничение по своей сути является заданием перечня (или логического эквивалента перечня) допустимых значений типа и объявлением о том, что указанный атрибут имеет данный тип.

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

    Любая переменная отношения, находящаяся в ДКНФ, обязательно находится в 5НФ. Однако не любую переменную отношения можно привести к ДКНФ.

    Шестая нормальная форма

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

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

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

    Таб.№ Время Должность Домашний адрес
    6575 01-01-2000:10-02-2003 слесарь ул.Ленина,10
    6575 11-02-2003:15-06-2006 слесарь ул.Советская,22
    6575 16-06-2006:05-03-2009 бригадир ул.Советская,22

    Переменная отношения «Работники» не находится в 6НФ и может быть подвергнута декомпозиции на переменные отношения «Должности работников» и «Домашние адреса работников».

    Должности работников

    Таб.№ Время Должность
    6575 01-01-2000:10-02-2003 слесарь
    6575 16-06-2006:05-03-2009 бригадир

    Домашние адреса работников

    Таб.№ Время Домашний адрес
    6575 01-01-2000:10-02-2003 ул.Ленина,10
    6575 11-02-2003:15-06-2006 ул.Советская,22
    Литература

    Для более глубокого и основательного изучения рассмотренной темы, рекомендуется книга «Введение в системы баз данных» Криса Дж. Дейта, на основе материалов которой и была написана данная статья.

    • реляционные базы данных
    • БД
    • нормальные формы
    • нормализация отношений
    • mysql

    Добавить комментарий

    Ваш адрес email не будет опубликован. Обязательные поля помечены *