19. Нормализация таблиц. Назначение нормализации. Первая нормальная форма. Вторая нормальная форма. Третья нормальная форма.

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

Нормальные формы

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

Первая нормальная форма. Отношение находится в первой нормальной формы, если значения всех атрибутов отношения атомарны (неделимы).

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

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

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

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

20. Этапы проектирования бд и их процедуры.

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

Концептуальное проектирование. Цель: создание концептуальной модели данных, исходя из пользовательских представлений о предметной области. Процедуры: 1)определение сущности и их документирование; 2)определение связей между сущностями и их документирование; 3) создание ER-модели предметной области; 4) определение атрибутов и их документирование; 5) определение значений атрибутов и их документирование; 6) определение первичных ключей для сущностей и их документирование; 7) обсуждение концептуальной модели с конечным пользователем. Логическое проектирование. Цель: преобразование концептуальной модели на основе выбранной модели данных в логическую модель, не зависимую от особенностей СУБД для физической реализации БД. Процедуры: 1) выбор модели данных; 2) определение набора таблиц исходя из ER-модели и их документирование (в соответствии с правилами преобразования 1-6); 3) нормализация таблиц; 4) проверка логической модели на предмет возможности выполнения транзакций – набор действий, выполняемых пользователем или прикладной программой для изменения содержимого БД так, чтобы она осталась в непротиворечивом состоянии; 5) определение требований поддержки целостности данных и их документирование; 6) создание окончательного варианта логической модели и обсуждение ее с пользователем. Физическое проектирование. Цель: описание конкретной реализации БД, размещенной во внешней памяти компьютера. Процедуры: 1) проектирование таблиц БД средствами СУБД; 2) реализация бизнес-правил в среде выбранной СУБД; 3) проектирование физической организации БД; 4) разработка стратегии защиты БД; 5) организация мониторинга функционирования БД и ее настройки.