Database Management Systems (DBMS)

1.

Database Management Systems (DBMS)
База данных — это
упорядоченный набор
структурированной
информации или данных,
которые обычно хранятся в
электронном виде в
компьютерной системе. База
данных обычно управляется
системой управления
базами данных (СУБД).
Данные вместе с СУБД, а
также приложения, которые с
ними связаны, называются
системой баз данных, или,
для краткости, просто базой
данных.

2.

Relational Databases
Реляционная база данных —
база данных, основанная на
реляционной модели данных.
Это набор данных с
предопределенными связями
между ними. Эти данные
организованы в виде набора
таблиц, состоящих из
столбцов и строк. В таблицах
хранится информация об
объектах, представленных в
базе данных.

3.

Немного реляционной
теории БД

4.

Связи
Различают три типа связи между сущностями: «один к одному»,
«один ко многим» (один отдел – много сотрудников) и «многие
ко многим».
Связь «многие ко многим» встречается реже: офисы разных
компаний размещены в разных городах, множество издательств
опубликовало произведения различных авторов и т. п.
Реляционная модель на прямую не поддерживает отношение
«многие ко многим», поэтому его приходится разбивать на два
отношения «один ко многим».

5.

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

6.

Ключ
Есть 2 основных вида ключей:
• Первичный ключ уникально идентифицирует запись в таблице.
• внешний ключ SQL — это ключ, используемый для объединения
двух таблиц. Иногда его также называют ссылочным ключом.
Внешний ключ — это столбец или комбинация столбцов,
значения которых соответствуют Первичному ключу в другой
таблице.

7.

Database Management Systems (DBMS)

8.

Database Management Systems (DBMS)

9.

Database Management Systems (DBMS)

10.

Relational Databases
Плюсы реляционной модели данных
● Данные легко структурируются по
категориям.
● Ваши данные единообразны по вводу,
значению и просты в навигации.
● Между точками данных можно легко
определить отношения.
● Сама структура реляции
хорошо подходит для
обеспечения
транзакционности (ACID)

11.

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

12.

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

13.

2 Нормальная форма
Отношение находится во 2НФ, если оно находится в 1НФ и каждый не
ключевой атрибут неприводимо зависит от Первичного Ключа(ПК).
Неприводимость означает, что у такой таблицы не должно быть атрибутов,
зависящих только от части первичного ключа.
Пример:
Таблица находится в первой
нормальной форме, но не во второй.
Цена машины зависит от модели и
фирмы. Скидка зависят от фирмы, то
есть зависимость от первичного
ключа неполная. Исправляется это
путем декомпозиции на два
отношения

14.

Преобразование к 2 нормальной форме
Декомпозируем исходную таблицу на 2:

15.

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

16.

Преобразование к 3 нормальной форме
Декомпозируем исходную таблицу на 2:

17.

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

18.

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

19.

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

20.

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

21.

ACID
Atomicity (атомарность) — выражается в том, что транзакция должна быть выполнена целиком или не выполнена вовсе.
Consistency (согласованность) — гарантирует, что по мере выполнения транзакций, данные переходят из одного
согласованного состояния в другое, то есть транзакция не может разрушить взаимной согласованности данных.
Isolation (изолированность) — во время выполнения транзакции параллельные транзакции не должны оказывать влияния на
её результат. Изолированность — требование дорогое, поэтому в реальных БД существуют разные уровни изоляции.
Durability (долговечность) — устойчивость к ошибкам — если транзакция завершена успешно, то те изменения в данных,
которые были ею произведены, не могут быть потеряны ни при каких обстоятельствах.

22.

Уровень изоляции
1) Потерянное обновление
Ситуация, когда при одновременном изменении одного блока данных разными транзакциями одно из изменений теряется.
2) «Грязное» чтение
Чтение данных, добавленных или изменённых транзакцией, которая впоследствии не подтвердится (откатится).
3) Неповторяющееся чтение
Ситуация, когда при повторном чтении в рамках одной транзакции ранее прочитанные данные оказываются изменёнными.
4) Чтение «фантомов»
Ситуация, когда при повторном чтении в рамках одной транзакции одна и та же выборка дает разные множества строк.
Data bases

23.

Потерянное обновление
Ситуация, когда при одновременном изменении одного блока данных разными транзакциями одно из изменений теряется.
Предположим, имеются две транзакции, выполняемые одновременно:
В обеих транзакциях изменяется значение поля f2, по их завершении значение поля должно быть увеличено на 45. В действительности
может возникнуть следующая последовательность действий:
1) Обе транзакции одновременно читают текущее состояние поля. Точная физическая одновременность здесь не обязательна, достаточно,
чтобы вторая по порядку операция чтения выполнилась до того, как другая транзакция запишет свой результат.
2) Обе транзакции вычисляют новое значение поля, прибавляя, соответственно, 20 и 25 к ранее прочитанному значению.
3) Транзакции пытаются записать результат вычислений обратно в поле f2. Поскольку физически одновременно две записи выполнить
невозможно, в реальности одна из операций записи будет выполнена раньше, другая позже. При этом вторая операция записи перезапишет
результат первой.

24.

Грязное чтение
«Грязное» чтение происходит, когда транзакция считывает данные, которые еще не были зафиксированы.
Например, транзакция 1 обновляет строку. Транзакция 2 считывает обновленную строку до того, как транзакция 1
зафиксирует обновление. Если транзакция 1 выполняет откат изменений, то транзакция 2 будет считать данные,
которые никогда не существовали.

25.

Неповторяющееся чтение
Неповторяемое чтение происходит, когда транзакция дважды считывает одну и ту же строку, но
каждый раз получает разные данные.
Например, транзакция 1 считывает строку. Транзакция 2 обновляет или удаляет эту строку и
фиксирует изменения. Если транзакция 1 пересчитывает строку, она получает различные значения
строки или обнаруживает, что строка была удалена.

26.

Фантомное чтение
Фантом — это строка, которая соответствует условиям поиска, но изначально не отображается.
Ситуация, когда при повторном чтении в рамках одной транзакции одна и та же выборка дает разные множества
строк.
Предположим, имеется две транзакции
В транзакции 2 выполняется SQL-оператор, использующий все значения поля f2. Затем в транзакции 1 выполняется
вставка новой строки, приводящая к тому, что повторное выполнение SQL-оператора в транзакции 2 выдаст другой
результат.
Такая ситуация называется чтением фантома (фантомным чтением).
От неповторяющегося чтения оно отличается тем, что результат повторного обращения к данным изменился не из-за
изменения/удаления самих этих данных, а из-за появления новых (фантомных) данных.

27.

Соответствие уровня изоляции и
решаемых проблем
Уровень изоляции
Фантомное чтение
Неповторяющееся
чтение
“Грязное чтение”
Потерянное
обновление
SERIALIZABLE
+
+
+
+
REPEATABLE READ
-
+
+
+
READ COMMITTED
-
-
+
+
READ UNCOMMITTED
-
-
-
+

28.

Блокировки

29.

Пессимистичная блокировка
При пессимистичной блокировке мы считаем, что доступ к одним и тем же данным будет осуществляться
параллельно. Существует несколько видов пессимистичных блокировок:
1. блокировка при чтении
2. блокировка при записи
При блокировке чтения запись блокируется когда она запрашивается из базы данных. Недостаток метода в том, что
таким образом можно заблокировать даже те данные, которые не изменяются в рамках текущей транзакции. При
этом множество транзакций может читать данные, но ни одни изменять. (share lock)
При блокировке записи, транзакция получает эксклюзивную блокировки, т.е. другие транзакции не имеют доступа к
залоченым данным (exclusive lock).
Блокировка с данных снимается либо при коммите, либо при откате транзакции.

30.

Оптимистичная блокировка
При оптимистичной блокировке на базе данных реальной блокировки не происходит. Вместо этого
используется следующий подход - если во время выполнения транзакции она изменяет данные, которые
были изменены после её начала, то транзакция прерывается с исключением.
Использование оптимистичных блокировок позволяет избежать взаимных блокировок (dead-lock).
Для реализации оптимистичной блокировки часто используется версионирование данных - в таблицу
добавляется колонка, которая хранит текущую версию. При выполнении update в запросе в секции where
передается версия данных, которая была получена на изменение. Если update вернул 0 изменённых строк,
значит данные были уже изменены и транзакцию необходимо запускать заново. Вместо версии можно
хранить время последнего изменения данных.

31.

Алгоритмы блокировок
Есть 2 основных алгоритма:
1. 2PL (2 Phase Locking)
2. MVCC (Multi-Version Concurrency Control)