Система управления базами данных SQLite. Изучаем язык запросов SQL и реляционные базы данных на примере библиотекой SQLite3. Курс для начинающих.

Здравствуйте, уважаемые посетители сайта ZametkiNaPolyah.ru. Продолжаем изучать базы данных и наше знакомство с библиотекой SQLite3. Для демонстрации примеров из этой части я буду пользоваться менеджером баз данных MySQL Workbench, установив его, вы с легкостью сможете повторить все примеры. По традиции повторяем определение второй нормальной формы. Переменная отношения находится во второй нормальной форме тогда и только тогда, когда она находится в первой нормальной форме и каждый неключевой атрибут неприводимо (функционально полно) зависит от её потенциального ключа.

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

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

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

Данная таблица находится в первой нормальной форме

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

Я неслучайно выделил некоторые столбцы цветами. Обратите внимание на зеленые столбцы: в этих столбцах содержится информация о издательствах: наименование и номер. Номер издательства и его название связаны между собой функционально, то есть между ними есть функциональная зависимость, детерминантом в которой является наименование издательства. Голубые столбцы: автор и день рождения автора, так же связаны между собой.

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

Данное отношение находится во второй нормальной форме

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

Приведу пример приведения ко второй нормальной форме в виде ER-диаграмм.

Преобразование базы данных из первой нормальной формы во вторую

Рисунок 23 стоит немного пояснить. Условимся: базы данных у нас разделяются наименованием таблиц, если в названии таблицы есть 1nf – она относится к базе данных в 1-ой нормальной форме, 2nf – к БД во 2-ой, 3nf – к БД в третьей.

На рисунке мы видим две базы данных: одна из них находится в первой нормальной форме, вторая – во второй. В принципе, преобразование происходило по тому же принципу, что я описывал выше: мы выделили функциональные зависимости, исходя из которых были созданы справочники. Помните про связи между таблицами и виды связей? Давайте условимся, что у книги может быть только один автор и одно издательство, чтобы не усложнять нашу структуру.

Поэтому таблица Books (2nf) связана с таблицей Author (2nf) связью один ко многим (один автор может написать несколько книг). Аналогично таблица Books (2nf) связана с таблицей Publish (2nf) связью один ко многим: одна запись из таблицы издательства может соответствовать нескольким записям из таблицы книг (соответствующая стрелочка на диаграмме это отображает).

Я неслучайно выделил красным на рисунке с диаграммой атрибуты ZIP и City, данные атрибуты имеют транзитивную зависимость (зависят не только от ключа, но и друг от друга), такая зависимость ведет к аномалии (логическим и смысловым ошибкам). Например, оператор, наполняющий базу данных в поле City записал Новосибирск, а в поле индекс написал 644000 (индекс Омска), какому значению я должен верить? Чтобы нам избавиться от транзитивной зависимости, необходимо привести нашу базу данных к третьей нормальной форме.