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

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

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

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

Теория реляционных баз данных была разработана в 1970-х гг. Е.Коддом. Он предложил технологию проектирования баз данных, в результате применения которой в полученной БД не возникает отмеченных выше недостатков. Сущность этой технологии сводится к приведению таблиц, составляющих БД, к третьей нормальной форме. Этот процесс называется нормализацией данных сначала все данные, которые планируется включить в БД, представляются в первой нормальной форме, затем преобразуются ко второй и на последнем шаге - к третьей нормальной форме.

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

Ниже приведен пример такой таблицы. Таблица 2 БД Поликлиника Фамилия пациента Дата рождения Номер участка Фамилия врача Дата посещения Диагноз Лосев О.И. 20.04.65 2 Петрова О.И. 11.04.98 грипп Орлова Е.Ю. 25.01.47 1 Андреева И. В. 05.05.98 ОРЗ Лосев О.И. 20.04.65 2 Петрова О.И. 26.07.98 бронхит Дуров М.Т. 05.03.30 2 Петрова О.И. 14.03.98 стенокардия Жукова Л. Г. 30.01.70 2 Петрова О.И. 11.04.98 ангина Орлова Е.Ю. 25.01.47 1 Андреева И. В. 11.07.98 гастрит Быкова А.А. 01.04.75 1 Андреева И. В. 15.06.98 ОРЗ Дуров М.Т. 05.03.30 2 Петрова О.И. 26.07.98 ОРЗ Нетрудно понять недостатки такой организации данных.

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

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

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

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

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

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

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

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

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