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

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

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

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

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

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

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

Устройство такой таблицы стоит запомнить намертво, потому что у её строк и столбцов свои имена. Строка называется записью, столбец — полем (рис. 1).

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

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

У каждого поля есть три постоянных признака: имя, тип и длина. Имена полей в одной таблице обязаны быть разными — иначе непонятно, к какому столбцу относится запрос. Тип поля говорит, какого рода данные в нём лежат. Их четыре основных.

Числовое поле держит числа, с которыми можно считать: цену, залог, массу, количество. Текстовое поле держит любые цепочки символов: фамилию, адрес, название модели, номер телефона. Логическое поле держит ровно два значения — да и нет; вместо них пишут истину и ложь или единицу и ноль, а в таблице обычно видны как раз единица и ноль. Поле типа «дата» держит календарные даты; у нас их принято записывать так: сначала день, потом месяц, потом год.

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