Об уровнях абстракции при моделировании данных
В процессе проектирования схему данных удобно представлять с помощью следующих моделей (см. рис. 8.2):
концептуальная модель служит средством для извлечения знаний о предметной области, то есть для работы с экспертами, пользователями, заказчиками; эта модель помогает программистам разобраться с той сферой человеческой деятельности, для которой им предстоит создать свое программное приложение, выявив там основные сущности и связи между ними; поскольку концептуальная модель предназначена для обсуждения с непрограммистами, то она не должна содержать конструкций и понятий, которых последним не воспринять;
логическая модель позволяет полностью задать структуру данных, однако без "привязки" к конкретной платформе реализации; с одной стороны, такое описание получается компактнее, чем физическая модель, позволяя взглянуть на схему данных в целом, без лишних деталей; с другой стороны, такая спецификация может быть в дальнейшем реализована для разных СУБД; логическая модель содержит абстракции, которые уже могут быть непонятны экспертам предметной области - эта модель служит для уточнения информации о предметной области в виде, удобном для последующей реализации;
физическая модель является описанием структуры данных в терминах платформы реализации - конкретной СУБД; эта модель уже содержит информацию о различных деталях реализации - индексах и ключах, типах атрибутов и т.д., которые определены в терминах целевого языка программирования и т. д.; физическая модель фактически является диаграммным представлением части программного кода, определяющего схему данных.
Рис. 8.2. Различные модели данных
Далее следует реализация схемы данных в виде:
полной спецификации с помощью программы на языке программирования, например, на SQL/DDL, с описанием всех таблиц, значений записей по умолчанию, определением прав на таблицы и группы таблиц, хранимыми процедурами и триггерами и т. д.; эта спецификация может содержать информацию, которая отсутствует в физической модели, так как в последнюю попадает только то, что хорошо выразимо с помощью диаграмм сущность-связь;
"живой" базы данных, получаемой как результат исполнения средствами некоторой СУБД программы, задающей схему (SQL/DDL-скрипта); создается электронное хранилище, которое реализует доступ к данным со стороны программных приложений, а также обеспечивает сохранение данных после окончания работы приложения и выключения компьютера - это свойство данных обычно называют персистентностью (persistent).
Пример концептуальной модели
В этом примере рассматривается схема данных для приложения, автоматизирующего работу факультетов университета. Фрагмент соответствующей концептуальной модели представлен на рис. 8.3.
Рис. 8.3. Пример концептуальной модели
Анализируя эту предметную область, можно выделить следующие сущности - "Студент", "Преподаватель", "Кафедра", "Отделение" и "Факультет", а также их отношения и атрибуты; для отношений показывается множественность. Важно, что в концептуальной модели нет типов атрибутов, а также ключей и индексов, сущности не нормализуются (то есть допускается наличие сложных атрибутов, например "Адрес" и "ФИО"). Все это нужно для того, чтобы такую модель можно было легко обсуждать со специалистами в той предметной области, для которой создается данное приложение, - секретарем декана, заместителем декана по учебной части и пр. Если в концептуальную модель будет добавлена лишняя программистская информация, то, как показывает опыт, она сразу перестанет быть понятной этим людям. В каждом случае этот "порог" может быть своим; он зависит от IT-компетентности специалистов предметной области, соответственно, диапазон используемых модельных средств может варьироваться.