Нетрудно понять недостатки такой организации данных. Во-первых, очевидна избыточность информации: повторение даты рождения одного и того же человека, повторение фамилии врача одного и того же участка. В такой БД велика вероятность иметь недостоверные, противоречивые данные. Например, если на втором участке сменится врач, то придется просматривать всю базу и вносить изменения во все записи, относящиеся к этому участку. При этом велика вероятность что-то пропустить. После каждого нового посещения пациентом больницы потребуется снова вводить его дату рождения, номер участка, фамилию врача, т.е. информацию, уже существующую в БД.
Полученная таблица соответствует первой нормальной форме. Для устранения отмеченных недостатков требуется ее дальнейшая нормализация. Структура такой таблицы (отношения) описывается следующим образом:
Необходимо установить ключ записей. Здесь ключ составной, который включает в себя два поля: ФАМИЛИЯ и ДАТА_ПОСЕ-ЩЕНИЯ. Каждая запись — это информация о конкретном посещении пациентом больницы. Если допустить, что в течение одного дня данный пациент может сделать только один визит к участковому врачу, то в разных записях не будет повторяться комбинация двух полей: фамилии пациента и даты посещения врача.
Согласно определению второй нормальной формы, все неключевые поля должны функционально зависеть от полного ключа. В данной таблице лишь ДИАГНОЗ определяется одновременно фамилией пациента и датой посещения. Остальные поля связаны лишь с фамилией, т. е. от даты посещения они не зависят. Для преобразования ко второй нормальной форме таблицу нужно разбить на две следующие:
ПОСЕЩЕНИЯ(ФАМИЛИЯ. ДАТА ПОСЕЩЕНИЯ. ДИАГНОЗ)
ПАЦИЕНТЫ (ФАМИЛИЯ. ДАТА_РОЖДЕНИЯ, УЧАСТОК, ВРАЧ)
В отношении ПОСЕЩЕНИЯ по-прежнему действует составной ключ из двух полей, а в отношении ПАЦИЕНТЫ — одно ключевое поле ФАМИЛИЯ.
Во втором отношении имеется так называемая транзитивная зависимость. Она отображается следующим образом:
Значение поля ВРАЧ связано с фамилией пациента транзитивно через поле УЧАСТОК. В самом деле, всякий участковый врач приписан к своему участку и обслуживает больных, относящихся к данному участку.
Согласно определению третьей нормальной формы в отношении не должно быть транзитивных зависимостей. Значит требуется еще одно разбиение отношения ПАЦИЕНТЫ на два отношения.
В итоге получаем базу данных, состоящую из трех отношений:
ПОСЕЩЕНИЯ(ФАМИЛИЯ. ДАТА ПОСЕЩЕНИЯ. ДИАГНОЗ)
ПАЦИЕНТЫ(ФАМИЛИЯ. ДАТА_РОЖДЕНИЯ, УЧАСТОК)
ВРАЧИ(УЧАСТОК. ВРАЧ)
В третьем отношении ключом является номер участка, поскольку он повторяться не может. В то же время возможна ситуация, когда один врач обслуживает больше одного участка. Полученная структура БД удовлетворяет требованиям третьей нормальной формы: в таблицах все неключевые поля полностью функционально зависят от своих ключей и отсутствуют транзитивные зависимости.
Еще одним важным свойством полученной БД является то, что между тремя отношениями существует взаимосвязь через общие поля. Отношения ПОСЕЩЕНИЯ и ПАЦИЕНТЫ связаны общим полем ФАМИЛИЯ. Отношения ПАЦИЕНТЫ и ВРАЧИ связаны через поле УЧАСТОК. Для связанных таблиц существует еще одно понятие: тип связи. Возможны три варианта типа связей: «один — к —одному», «один —ко —многим», «многие —ко —многим». В нашем примере между связанными таблицами существуют связи типа «один —ко —многим», и схематически они отображаются так:
Смысл следующий: у каждого врача (на каждом участке) много пациентов; каждый пациент посещает врача множество раз.
В приведенном примере показана процедура нормализации в строгом соответствии с теорией реляционных баз данных. Понимание смысла этой процедуры очень полезно для учителя.
В школьном учебнике не представляется целесообразным подробно описывать формальную процедуру нормализации, приводить строгое определение трех нормальных форм. В учебнике [31, ч. 2] разговор на эту тему ведется на понятийном уровне. Используется нетрадиционный термин «хорошо нормализованная база данных». В этом понятии фактически заложены свойства третьей нормальной формы. Эти свойства сформулированы так: «Все поля таблицы должны отражать непосредственные характеристики (атрибуты) объекта, к которому относится запись». Ученикам предлагается следующая, в некотором смысле интуитивная, методика получения хорошо нормализованной БД. Все множество данных нужно разделить между различными объектами, к которым они относятся. На примере приведенной выше таблицы ПОЛИКЛИНИКА нужно увидеть три различных типа объектов, к которым относится данная информация: это пациенты поликлиники, врачи и посещения пациентами врачей. Соответственно строятся три таблицы, содержащие атрибуты, относящиеся к этим трем типам объектов и связанные между собой через общие поля.
