SharePoint Alfresco PHP MySQL
О сайте Контакты
вторник, 11 марта 2014 г.

Как проектировать базы данных? Нормальные формы

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

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

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

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

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

Отношение находится во 2-й нормальной форме, если оно находится в 1-й нормальной форме и каждый неключевой атрибут функционально полно зависит от ключа. Например, имеем составной ключ: сотрудник и должность. Должность имеет такой параметр, как категория. Соответственно, все это, допустим, сохранили в одной таблице. Но Иванов сам по себе не может иметь просто 3-ю категорию, такую категорию имеет должность. Значит, надо вывести должности с их категориями в отдельное отношение. Появится справочник должностей, и мы исключим избыточность. Основным признаком того, что данные не находятся во 2-й нормальной форме, является наличие множества повторяемых значений в таблице. Если таковые есть в огромных количествах, следует задуматься: а не сгруппировать ли и не вынести ли их в отдельный справочник.

Третья нормальная форма

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

Нормальная форма Бойса-Кодда

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

Четвертая нормальная форма

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

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

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

Выводы

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

Sergey Lysenko, вторник, 11 марта 2014 г.

Комментарии: