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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Информационное моделирование и электронные таблицы

Изучаемые вопросы:

• Что такое математическая модель.

• Понятия: компьютерная математическая модель, численный эксперимент.

• Пример реализации математической модели на электронной таблице.

Электронные таблицы являются удобной инструментальной средой для решения задач математического моделирования.

Что же такое математическая модель? Это описание состояния или поведения некоторой реальной системы (объекта, процесса) на языке математики, т.е. с помощью формул, уравнений и других математических соотношений. Характерная конфигурация всякой математической модели представлена на рис. 2.

Рис.2. Обобщенная структура математической модели

Здесь Х и У — некоторые количественные характеристики мо­делируемой системы.

Реализация математической модели — это применение опреде­ленного метода расчетов значений выходных параметров по зна­чениям входных параметров. Технология электронных таблиц — один из возможных методов реализации математической модели. Другими методами реализации математической модели может быть составление программ на языках программирования, применение математических пакетов (MathCAD, Математика и др.), примене­ние специализированных программных систем для моделирова­ния. Реализованные такими средствами математические модели будем называть компьютерными математическими моделями.

Цель создания компьютерной математической модели — про­ведение численного эксперимента, позволяющего исследовать мо­делируемую систему, спрогнозировать ее поведение, подобрать оптимальные параметры и пр.

Итак, характерные признаки компьютерной математической модели следующие: