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

Третий критерий, очевидно, выполняется, поскольку речь идет о компьютерной базе данных, созданной в среде некоторой СУБД.

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

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

выполнить сортировку данных по некоторому ключу; сформировать отчет с нужной информацией. Решение этой задачи не требует вмешательства в готовую модель.

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

БИБЛИОТЕКА(НОМЕР, ШИФР, АВТОР, НАЗВАНИЕ)

Требуется изменить структуру БД таким образом, чтобы из нее можно было узнать, находится ли книга в настоящее время в библиотеке, и если книга выдана, то когда и кому.

Новые цели требуют внесения изменений в модель, в структуру базы данных. Ученики должны спланировать добавление новых полей, определить их типы. Решение может быть таким: после добавления полей база данных будет иметь следующую структуру:

БИБЛИОТЕКА(НОМЕР, ШИФР, АВТОР, НАЗВАНИЕ, НАЛИЧИЕ, ЧИТАТЕЛЬ, ДАТА)

Здесь добавлены поля:

— НАЛИЧИЕ — поле логического типа; принимает значение True, если книга находится в библиотеке, и значение False, если выдана читателю;

— ЧИТАТЕЛЬ — поле числового (или символьного) типа; содержит номер читательского билета человека, взявшего книгу;

— ДАТА — поле типа «дата»; указывает день выдачи книги.

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

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

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

Теория реляционных баз данных была разработана в 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	ОРЗ

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

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

ПОЛИКЛИНИКА (ФАМИЛИЯ, ДАТА_РОЖДЕНИЯ, УЧАСТОК, ВРАЧ, ДАТА ПОСЕЩЕНИЯ, ДИАГНОЗ)

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

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

ПОСЕЩЕНИЯ (ФАМИЛИЯ, ДАТА ПОСЕЩЕНИЯ, ДИАГНОЗ)

ПАЦИЕНТЫ (ФАМИЛИЯ, ДАТА_РОЖДЕНИЯ, УЧАСТОК, ВРАЧ)

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

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

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

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

В итоге получаем базу данных, состоящую из трех отношений:

ПОСЕЩЕНИЯ(ФАМИЛИЯ, ДАТА ПОСЕЩЕНИЯ, ДИАГНОЗ)

ПАЦИЕНТЫ(ФАМИЛИЯ, ДАТА_РОЖДЕНИЯ, УЧАСТОК)

ВРАЧИ(УЧАСТОК, ВРАЧ)

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