Показаны сообщения с ярлыком базы данных. Показать все сообщения
Показаны сообщения с ярлыком базы данных. Показать все сообщения

среда, 4 июня 2014 г.

Транзакции. ACID.

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

Требования к транзакционной системе обозначаются акронимом ACID. Они дают представление о принципах, обеспечивающих надежную  и предсказуемую работу БД.


вторник, 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, о котором идет речь в теореме, все пары атрибутов из двух отношений, имеющих общее имя, приравниваются, а одна из пар равных атрибутов удаляется путем проекции.

Нормализация БД. 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

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