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

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

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

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

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

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

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

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

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

Таблица 2

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

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

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

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

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