Линия "Формализация и моделирование" учебного курса "Информатика"

Таблица 2

БД «Поликлиника»

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

Полученная таблица соответствует первой нормальной форме. Для устранения отмеченных недостатков требуется ее дальнейшая нормализация. Структура такой таблицы (отношения) описыва­ется следующим образом:

Необходимо установить ключ записей. Здесь ключ составной, который включает в себя два поля: ФАМИЛИЯ и ДАТА_ПОСЕЩЕНИЯ. Каждая запись — это информация о конкретном посеще­нии пациентом больницы. Если допустить, что в течение одного дня данный пациент может сделать только один визит к участково­му врачу, то в разных записях не будет повторяться комбинация двух полей: фамилии пациента и даты посещения врача.

Согласно определению второй нормальной формы, все неклю­чевые поля должны функционально зависеть от полного ключа. В данной таблице лишь ДИАГНОЗ определяется одновременно фа­милией пациента и датой посещения. Остальные поля связаны лишь с фамилией, т. е. от даты посещения они не зависят. Для преобра­зования ко второй нормальной форме таблицу нужно разбить на две следующие:

В отношении ПОСЕЩЕНИЯ по-прежнему действует состав­ной ключ из двух полей, а в отношении ПАЦИЕНТЫ — одно ключевое поле ФАМИЛИЯ.

Во втором отношении имеется так называемая транзитивная зависимость. Она отображается следующим образом:

Значение поля ВРАЧ связано с фамилией пациента транзитивно через поле УЧАСТОК. В самом деле, всякий участковый врач приписан к своему участку и обслуживает больных, относя­щихся к данному участку.

Согласно определению третьей нормальной формы в отноше­нии не должно быть транзитивных зависимостей. Значит, требуется еще одно разбиение отношения ПАЦИЕНТЫ на два отношения.

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

Еще одним важным свойством полученной БД является то, что между тремя отношениями существует взаимосвязь через общие поля. Отношения ПОСЕЩЕНИЯ и ПАЦИЕНТЫ связаны общим полем ФАМИЛИЯ. Отношения ПАЦИЕНТЫ и ВРАЧИ связаны через поле УЧАСТОК. Для связанных таблиц существует еще одно понятие: тип связи. Возможны три варианта типа связей: «один — к—одному», «один—ко—многим», «многие — ко — многим». В нашем примере между связанными таблицами существуют связи типа «один — ко — многим», и схематически они отображаются так:

Смысл следующий: у каждого врача (на каждом участке) мно­го пациентов; каждый пациент посещает врача множество раз.

В приведенном примере показана процедура нормализации в строгом соответствии с теорией реляционных баз данных. Пони­мание смысла этой процедуры очень полезно для учителя.

На примере приведенной выше таб­лицы ПОЛИКЛИНИКА нужно увидеть три различных типа объектов, к которым относится данная информация: это паци­енты поликлиники, врачи и посещения пациентами врачей. Со­ответственно строятся три таблицы, содержащие атрибуты, от­носящиеся к этим трем типам объектов и связанные между со­бой через общие поля.