Табл. B: РАСПОЛОЖЕНИЕ_ОТДЕЛОВ
| Номер_отдела | Расположение |
| 100 | Москва |
| 100 | Зеленоград |
| 600 | Тверь |
| 100 | Калуга |
2. Приведение ко второй нормальной форме
3. Следующий важный шаг в процессе нормализации состоит в удалении всех неключевых атрибутов, которые зависят только от части первичного ключа. Такие атрибуты называются частично зависимыми. Неключевые атрибуты заключают в себе информацию о данной сущности предметной области, но не идентифицируют ее уникальным образом. Например, предположим, что мы хотим распределить работников по проектам, ведущимся на предприятии. Для этого создадим таблицу ПРОЕКТ с составным первичным ключом, включающим номер работника и идентификатор проекта (Номер_работника+ИД_проекта, в табл. c выделены курсивом).
Табл. C: ПРОЕКТ
| Номер_ работника | ИД_проекта | Фамилия | Назв_проекта | Описание_ проекта | Продукт |
| 28 | БРЖ | Иванов | Биржа | <blob> | программа |
| 17 | ДОК | Петров | Документы | <blob> | программа |
| 06 | УПР | Сидоров | Управление | <blob> | адм.меры |
В этой таблице возникает следующая проблема. Атрибуты Назв_проекта, Описание_проекта и Продукт относятся к проекту как сущности и, следовательно, зависят от атрибута ИД_проекта (являющегося частью первичного ключа), но не от атрибута Номер_работника. Следовательно, они являются частично зависимыми от составного первичного ключа. То же самое можно сказать и об атрибуте Фамилия, который зависит от атрибута Номер_работника, но не зависит от атрибута ИД_проекта. Для нормализации этой таблицы (приведения ее в 2НФ) удалим из нее атрибуты Номер_работника и Фамилия и создадим другую таблицу (назовем ее РАБОТНИК_В_ПРОЕКТЕ), которая будет содержать только эти два атрибута, и они же будут составлять ее первичный ключ.
4. Приведение к третьей нормальной форме
Третий этап процесса приведения таблиц к нормальной форме состоит в удалении всех неключевых атрибутов, которые зависят от других неключевых атрибутов. Каждый неключевой атрибут должен быть логически связан с атрибутом (атрибутами), являющимся первичным ключом. Предположим, например, что мы добавили поля Номер_руководителя и Телефон в таблицу ПРОЕКТ, находящуюся в 2НФ (первичным ключом является поле ИД_проекта). Атрибут Телефон логически связан с атрибутом Номер_руководителя, неключевым полем, но не с атрибутом ИД_проекта, являющимся первичным ключом (табл. d).
Табл. D: ПРОЕКТ
| ИД_проекта | Номер_ руководителя | Телефон | Назв_ проекта | Описание_ проекта | Продукт |
| БРЖ | 02 | 2-21 | Биржа | <blob> | программа |
| ДОК | 12 | 2-43 | Документы | <blob> | программа |
| УПР | 08 | 2-56 | Управление | <blob> | адм.меры |
Для нормализации этой таблицы (приведения ее в 3НФ) удалим атрибут Телефон, изменим Номер_руководителя на Руководитель и сделаем атрибут Руководитель внешним ключом, ссылающимся на атрибут Номер_работника (первичный ключ) в таблице РАБОТНИКИ. После этого таблицы ПРОЕКТ и РАБОТНИКИ будут выглядеть следующим образом:
Табл. E: ПРОЕКТ
| ИД_проекта | Руководитель | Назв_ проекта | Описание_ проекта | Продукт |
| БРЖ | 02 | Биржа | <blob> | программа |
| ДОК | 12 | Документы | <blob> | программа |
| УПР | 08 | Управление | <blob> | адм.меры |
Табл. F: РАБОТНИКИ
| Номер_ работника | Фамилия | Имя | Отчество | Номер_ отдела | Код_ профес | Телефон | Зарплата | |
| 04 | Иванов | Иван | Иванович | 100 | инж | 2-69 | 500 | |
| 08 | Петров | Петр | Петрович | 200 | мндж | 2-56 | 1000 | |
| 23 | Сидоров | Иван | Петрович | 200 | мндж | 2-45 | 800 | |
Теперь, когда мы научились проводить нормализацию таблиц с целью устранения избыточного дублирования данных и группирования информации в логически связанных единицах, необходимо сделать ряд замечаний по вопросам проектирования баз данных. Необходимо четко понимать, что разбиение информации на более мелкие единицы с одной стороны, способствует повышению надежности и непротиворечивости базы данных, а с другой стороны, снижает ее производительность, так как требуются дополнительные затраты процессорного времени (серверного или машины пользователя) на обратное “соединение” таблиц при представлении информации на экране. Иногда для достижения требуемой производительности нужно сделать отход от канонической нормализации, при этом ясно осознавая, что необходимо обеспечить меры по предотвращению противоречивости в данных. Поэтому всякое решение о необходимости того или иного действия по нормализации можно принимать только тщательно проанализировав предметную область и класс поставленной задачи. Может потребоваться несколько итераций для достижения состояния, которое будет желаемым компромиссом между четкостью представления и реальными возможностями техники. Здесь уже начинается искусство...
VII. Седьмой шаг является последним в нашем списке, но не последним по важности в процессе проектирования базы данных. На этом шаге мы должны спланировать вопросы надежности данных и, при необходимости, сохранения секретности информации. Для этого необходимо ответить на следующие вопросы:
· кто будет иметь права (и какие) на использование базы данных
· кто будет иметь права на модификацию, вставку и удаление данных
· нужно ли делать различие в правах доступа
· каким образом обеспечить общий режим защиты информации и т.п.
1. Заключение
На данном уроке мы познакомились с основами теории реляционных баз данных, изучили требования к базам данных, а также основные шаги по проектированию баз данных. Кроме того, рассмотрели очень важный для проектирования баз данных вопрос нормализации таблиц и проблемы, связанные с этим процессом. Теперь мы можем осознанно приступать к созданию приложений, работающих с базами данных.