1.2.Проектирование базы данных

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

Личные данные				Организация		Занимаемая должность и условия работы
						Должность
Фамилия	Имя	Отчество	…	Название	…	Название должности	…	Штатный / совместитель
Таблица «Сотрудники»				Таблица «Организации»		Таблица «Должности»

Рассмотрим и проанализируем эту структуру таблицы с точки зрения избыточности представленной в ней информации:

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

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

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

Получаем структуру БД, включающую 4 таблицы:

Таблица «Сотрудники»

К од

Фамилия

Имя

Отчество

…

Таблица «Организации»

Код

Название

…

Таблица «Должности»

Код

Название

…

Таблица «Должности сотрудников»

Код сотрудника

Код организации

Код должности

Штатный

…

Для организации связей между таблицами используем уникальные коды, сопоставляемые с каждой записью в каждой таблице и используемые для ссылок на эту запись из других записей, расположенных в связанных таблицах БД. В реальной БД в качестве таких кодов для организаций, например, могут использоваться коды ОКПО или ИНН, для сотрудников – серия и номер паспорта сотрудника, его ИНН или номер свидетельства пенсионного страхования и т.п.

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

Процесс проектирования БД, определения ее структуры – это процесс нормализации, который выполняется по четко определенным правилам, последовательно. Самое общее правило в упрощенной форме можно сформулировать так: один объект – одна таблица.

СУБД предоставляет возможности для создания таблиц и поддержания и связей между ними и организации работы пользователя с данными, размещенными в них.