пятница, 30 мая 2014 г.

Нормализация БД. 4 нормальная форма. Теорема Фейджина.

Теорема Фейджина: Пусть X, Y, Z - непересекающиеся множества атрибутов отношения R(X,Y,Z). Декомпозиция отношения R на проекции R1=R[X,Y] и R2=[X,Z] будет декомпозицией без потерь тогда и только тогда, когда имеется многозначная зависимость X->>Y|Z.
Напомню, что функциональная зависимость - это однозначное соответствие левой и правой части. Например:
  • ребенок -> биологические родители
  • идентификатор товара -> его название
Многозначная зависимость - это когда левой части (детерминанту) соответствует один из множества вариантов правой части. Например:
  • родители -> ребенок  (так как детей может быть несколько)
  • студент -> зачет
Если многозначная зависимость имеет вид X->>Y|Z, при этом функциональные зависимости X->Y или X->Z не существуют, такая  зависимость является нетривиальной многозначной зависимостью.

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

manpubbeer
DarthGolden Gate PubGuinness
DarthGolden Gate PubMurphy's Irish Stout
DarthO'Connor'sMurphy's Irish Stout
DarthO'Connor'sNewcastle
YodaGolden Gate PubGuinness
YodaGolden Gate PubMurphy's Irish Stout
Jabba the HuttO'Connor'sMurphy's Irish Stout
Jabba the HuttO'Connor'sNewcastle

Ваше времяпровождение определяется многозначной зависимостью good_life(pub->>man|beer).
А это значит, что можно выполнить следующую декомпозицию:

pubbeer
Golden Gate PubGuinness
Golden Gate PubMurphy's Irish Stout
O'Connor'sMurphy's Irish Stout
O'Connor'sNewcastle

pubman
Golden Gate PubDarth
Golden Gate PubYoda
O'Connor'sDarth
O'Connor'sJabba the Hutt

И из неё при желании можно восстановить исходное отношение:
pub_beer(pub->>beer) NATURAL JOIN pub_men(pub->>man) = good_life(pub->>man,beer)

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

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

А это значит, что отношение good_life(pub->>man,beer) не находится в 4 НФ. 
И теперь небольшой трюк. Возьмем отношение paid_goof_life(pub,man,beer->payment):

manpubbeerpayment
DarthGolden Gate PubGuinness10$
DarthGolden Gate PubMurphy's Irish Stout20$
DarthO'Connor'sMurphy's Irish Stout30$
DarthO'Connor'sNewcastle15$
YodaGolden Gate PubGuinness10$
YodaGolden Gate PubMurphy's Irish Stout20$
Jabba the HuttO'Connor'sMurphy's Irish Stout30$
Jabba the HuttO'Connor'sNewcastle15$

Трюк этот называется внедренной зависимостью. После добавления атрибута payment отношение стало соответствовать 4 НФ.

вторник, 27 мая 2014 г.

Декомпозиция без потерь. Теорема Хита.

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

Теорема Хита: Если есть отношение  R у которого есть атрибуты A, B, C, связанные зависимостью A -> B, то декомпозиция на r1(A, B) и r2(A,C) будет обратимой: R(A, B, C) = r1(A, B) join r2(A,C).

Например, вы с друзьями посидели в пабе. Имеет место отношение Pub (man, beer, payment).

manbeerpayment
DarthLeffe Blonde5$
YodaHeineken10$
Jabba the HuttAmstel Light 8$

Каждый из вас пьет один определенный сорт пива. Это зависимость man -> beer.
Значит, по теореме Хита мы можем разделить данные на 2 отношения:
  • man -> beer == beer_man (man, beer)
manbeer
DarthLeffe Blonde
YodaHeineken
Jabba the HuttAmstel Light 
  • man -> payment == pay_man (man, payment)
manpayment
Darth5$
Yoda10$
Jabba the Hutt8$

Этих данных достаточно, чтобы однозначно и правильно воссоздать оригинальное отношение Pub (man, beer, payment), используя natural join:
  •        beer_man JOIN pay_man = pub
P.S. На всякий случай напоминаю, что при  natural join, о котором идет речь в теореме, все пары атрибутов из двух отношений, имеющих общее имя, приравниваются, а одна из пар равных атрибутов удаляется путем проекции.

Нормализация БД. Усиленная 3 форма (нормальная форма Бойса-Кодда)

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

  • Детерминант функциональной зависимости - это то, что в левой её части 
  • Потенциальный ключ - подмножество атрибутов, удовлетворяющее требованиям уникальности и минимальности (несократимости)
  • Для проверки на соответствие НФБК нужно выделить все функциональные зависимости. Если любой детерминант можно выбрать в качестве ключа - отношение соответствует усиленной 3 форме.
  • НФБК может отличаться  от 3 НФ только в том случае, если у отношения несколько потенциальных ключей
Например, есть следующая таблица:

producer_idproducer_nameproduct_nameamount
1AlphaApricot10
1AlphaPeach20
1AlphaStrawberry50
2BetaApricot10
2BetaStrawberry30

Есть 2 варианта выбора ключа:

  •  producer_id + product_name

producer_idproducer_nameproduct_nameamount
1AlphaApricot10
1AlphaPeach20
1AlphaStrawberry50
2BetaApricot10
2BetaStrawberry30

  • producer_name + product_name

producer_idproducer_nameproduct_nameamount
1AlphaApricot10
1AlphaPeach20
1AlphaStrawberry50
2BetaApricot10
2BetaStrawberry30

Отношение соответствует 1, 2, 3 НФ.

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

Таких зависимостей две:

  • producer_name -> producer_id
  • producer_id -> producer_name

Для приведения к НБКФ таблицу можно преобразовать так:

producer_idproducer_name
1Alpha
2Beta

producer_idproduct_nameamount
1Apricot10
1Peach20
1Strawberry50
2Apricot10
2Strawberry30

Нормализация БД. 1, 2, 3 НФ

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

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

housefatherchildren
LannisterTywinCersei, Jaime, Tyrion
StarkEddardRobb, Sansa, Arya, Bran, Rickon
BaratheonRobertJoffrey, Myrcella, Tommen

    Данная таблица не соответствует 1 НФ, так как атрибут children при разбиении на части или переупорядочивании эго состовляющих не теряет смысла. Т.е. атрибут children неатомарен.
    Таблица, соответствующая 1 НФ выглядит так:

housefatherchild
LannisterTywinCersei
LannisterTywinJaime
LannisterTywinJaime
StarkEddardRobb
StarkEddardSansa
StarkEddardArya
StarkEddardBran
StarkEddardRickon
BaratheonRobertJoffrey
BaratheonRobertMyrcella
BaratheonRobertTommen

2 НФ: Каждый неключевой элемент неприводимо зависит от первичного ключа. Если потенциальный ключ отношения является простым, то отношение автоматически находится в 2НФ.

Иначе говоря:
  • если ключ состоит из 1 поля и соблюдены требования 1 НФ, 2 НФ соблюдена
  • если ключ составной, то другие атрибуты должны зависеть от всего ключа, а не от одного из его полей
namepositionsmall council member
Tywin LannisterHand Of The KingTRUE
VarysMaster Of WhisperersTRUE
Robb StarkKing In The NorthFALSE
Eddard StarkHand Of The KingTRUE

В данной таблице первичный ключ - имя и должность. Однако атрибут small council member зависит только от занимаемой должности. Иначе говоря, зависимость от первичного ключа неполная. Следовательно, таблица не соответствует 2 НФ. Для приведения ко 2 НФ выполняем декомпозицию:

nameposition
Tywin LannisterHand Of The King
VarysMaster Of Whisperers
Robb StarkKing In The North
Eddard StarkHand Of The King

positionsmall council member
Hand Of The KingTRUE
Master Of WhisperersTRUE
King In The NorthFALSE

3 НФ: 
  • Все неключевые атрибуты взаимно независимы
  • Неключевые элементы не находятся в транзитивной зависимости от первичного ключа
Иначе говоря:
  • каждое из неключевых полей зависит исключительно от ключа 
Снова возьмем таблицу должностей, однако, в этот раз первичным ключом будет только атрибут name.

namepositionsmall council member
Tywin LannisterHand Of The KingTRUE
VarysMaster Of WhisperersTRUE
Robb StarkKing In The NorthFALSE
Eddard StarkHand Of The KingTRUE

Пускай членство человека в малом совете зависит только от его должности. Тогда получаем следующие зависимости:
  • name -> position
  • position -> small council membership
  • name -> small council membership 
Отношение не находится в 3 НФ, т.к.:
  • неключевой атрибут small council member зависит от неключевого position
  • name -> small council membership - транзитивная зависимость
Приводим к 3 НФ:

nameposition
Tywin LannisterHand Of The King
VarysMaster Of Whisperers
Robb StarkKing In The North
Eddard StarkHand Of The King

positionsmall council member
Hand Of The KingTRUE
Master Of WhisperersTRUE
King In The NorthFALSE

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