§ 12. База данных как модель предметной области

Определения и обозначения

Предметная область — часть реального мира, сведения о которой требуется хранить и обрабатывать. Это может быть школьная библиотека, расписание занятий, работа магазина или движение транспорта. Границы области определяются задачей: для учёта выдачи книг важны читатели и экземпляры, а для подсчёта посещаемости понадобятся другие сведения. Такое определение помогает заранее понять, какие данные вообще относятся к будущей системе.

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

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

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

Как это устроено

Построение базы данных начинается с постановки задачи: нужно определить, кто будет пользоваться сведениями и какие действия ему понадобятся. Например, библиотекарю может требоваться найти книгу по автору, узнать, кому её выдали, или проверить срок возврата. От этих действий зависит состав данных: если заранее не выяснить потребности, можно не сохранить нужные сведения или добавить поля, которые никто не использует. Чёткая цель задаёт направление проектирования.

Затем из реальных объектов выбирают существенные для задачи сущности. Сущность — это тип объектов, о которых нужно хранить сведения, например «Книга», «Читатель» или «Выдача». Для каждой сущности определяют свойства и связи с другими сущностями: у книги есть название, а выдача связывает конкретную книгу с читателем. Неважные детали исключают, потому что они занимают место и усложняют работу, не помогая выполнять нужные действия.

Чтобы хранить и обрабатывать сведения, выбранные объекты представляют в определённой структуре. В реляционных базах данных (реляционная — организованная в виде связанных таблиц) такой структурой часто служат таблицы с записями и полями. Для книг можно создать таблицу, где каждая строка описывает книгу, а столбцы задают её характеристики. Единая структура позволяет одинаково трактовать сведения и выполнять по ним поиск.

Структура базы данных задаёт, какие данные допустимы и как они связаны, а записи заполняют её конкретными сведениями о реальных объектах. Например, поле «Год издания» описывает свойство всех книг, а значение 2020 относится к конкретной записи. Если изменить значение в записи, структура поля при этом остаётся прежней. Такое разделение помогает отличать правила хранения от информации, которая хранится по этим правилам.

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

Элементы реляционной базы данных

Чтобы читать таблицу, сначала определите, какой тип объектов она описывает, затем найдите нужную запись. Поле указывает, какое свойство рассматривается, а значение показывает его для выбранного объекта. Например, значение в столбце «Автор» нужно читать в той же строке, что и название соответствующей книги.

Разбор задач

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

1. Определяем объект таблицы: одна запись будет соответствовать книге или отдельному экземпляру.
2. Выбираем свойства для поиска и учёта: название, автор, год издания, издательство и инвентарный номер.
3. Если нужно отслеживать доступность, добавляем поле «Статус» либо связываем таблицу книг с таблицей выдач.

Ответ: подойдут поля «Название», «Автор», «Год издания», «Издательство», «Инвентарный номер» и, если это требуется, «Статус». Точный набор определяется задачами библиотеки. Если важно учитывать несколько экземпляров одного издания, их лучше описывать отдельными записями или разделить сведения об издании и экземпляре.

Задача 2. Даны таблицы «Книги» и «Читатели». Определите, какие сведения следует хранить о выдаче книги, чтобы узнать, кто и когда её взял. Нужно не записывать читателя прямо в таблицу книги: книгу могут брать разные люди в разное время. Значит, сведения относятся к связи между книгой и читателем и должны описывать отдельный факт выдачи. Такой подход сохраняет историю операций.

1. Выделяем сущность «Выдача», которая связывает конкретную книгу с конкретным читателем.
2. Добавляем ссылки на книгу и читателя: например, идентификатор книги и идентификатор читателя.
3. Записываем дату выдачи, а для контроля возврата — плановую и фактическую даты возврата.

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

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

1. Создаём таблицы «Классы», «Учителя», «Кабинеты» и «Предметы», задавая каждой записи свой идентификатор.
2. Создаём таблицу «Занятия»: указываем день недели, номер урока и ссылки на класс, учителя, кабинет и предмет.
3. Для изменений храним актуальные сведения в занятии, а если нужна история — добавляем отдельные записи о периоде действия или изменениях.

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

Типичные ошибки

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

Ошибка — путать базу данных и СУБД. Программа открывает и обрабатывает сведения, поэтому может показаться, что именно она и есть база. Чтобы проверить себя, спросите, что останется при закрытии программы: организованные данные хранятся отдельно, а СУБД служит для работы с ними. Значит, программа управляет базой, но не заменяет её.

Ошибка — включать в модель все подробности реальной ситуации. Так поступают, пытаясь заранее предусмотреть всё, однако лишние поля усложняют ввод, поиск и обновление сведений. Для проверки сопоставьте каждое поле с конкретным действием пользователя: помогает ли оно найти нужное, выполнить учёт или получить результат? Если нет, вероятно, это свойство не требуется для поставленной задачи.

Ошибка — смешивать свойство объекта и конкретные сведения о нём. Поле «Автор» задаёт характеристику книг, а «А. С. Пушкин» является значением этого поля в конкретной записи. Путаница возникает, когда структуру таблицы воспринимают как список готовых данных. Проверьте себя: поле должно подходить для многих записей, а запись — собирать значения полей одного объекта.

Связь с другими темами

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

Что запомнить

• База данных содержит организованные сведения о предметной области.
• Модель отражает только те стороны реальности, которые важны для задачи.
• Перед созданием базы данных определяют цели её использования.
• Объекты предметной области описывают через свойства и связи.
• В реляционной базе данные представляют в таблицах.
• СУБД управляет базой данных, но не является самой базой данных.