Для каждого локального представления необходимо сформулировать сущности, требуемые для его описания, т.е. необходимо указать те типы объектов (т.е. наборы подобных объектов) ПО, о которых в системе должна накапливаться информация. В отдельных случаях это может оказаться затруднительным, так как некоторый фрагмент информации может быть представлен любым из типов конструктивных элементов (сущность, атрибут или связь). Например, тот факт, что конкретная деталь используется при сборке конкретного изделия, может быть выражен либо как связь Входит в состав между сущностями Деталь и Изделие, либо как атрибут Имеет в составе деталь для сущности Изделие, либо как сущность Схема сборочного состава и т.п.
В этих случаях рекомендуется проработать несколько вариантов моделей локального представления и отобрать тот, который окажется более гибким с точки зрения представления информации (т.е. позволяет представлять не только всю порцию некоторой информации, но и ее отдельные фрагменты). Такой подход расширяет возможности совместного использования данных в базе различными пользователями и закладывает основы для обеспечения долгосрочной гибкости системы при удовлетворении их информационных потребностей.
Пример. Пусть в некотором локальном представлении выполняется описание поставок товаров на склад. Предполагается, что в одной поставке участвует только один поставщик, поставляя только один вид товара. При этом поставщик может участвовать в нескольких поставках. Для описания можно воспользоваться, например, только двумя основными конструкциями (сущность и атрибут). Введем в рассмотрение сущность Поставка и выполним ее описание с помощью следующих атрибутов:
|
|
Индекс поставки;
Индекс поставщика;
Адрес поставщика;
Индекс товара;
Название товара;
Количество поставленного товара;
Цена единицы товара;
Шифр склада;
Дата поставки.
Графическая диаграмма локального представления приведена на рис. 3.1. Такая модель обладает определенными недостатками. С ее помощью нельзя представить такую порцию информации, как информация об отдельном поставщике, который не выполняет поставок в настоящее время. Чтобы эту порцию информации можно было представлять, необходимо ввести в модель сущность Поставщик, назначить ей соответствующие атрибуты, связать с сущностью Поставка и удалить избыточные элементы (рис. 3.2.).
При таком представлении всегда можно определить, какой конкретно поставщик выполнил поставку, используя для этого связь Поставляет между сущностями Поставщик и Поставка, т.е. в информационном плане данная модель сохраняет все возможности предыдущей модели. Но при этом она является более универсальной с точки зрения информационного представления, так как представляет еще информацию и об отдельных поставщиках независимо от того, выполняли ли они уже поставку товаров или еще нет.
Рис. 3.1. Графическая диаграмма локального представления данных
Рис. 3.2. Введение в модель сущности ПОСТАВЩИК
Однако полученный вариант не позволяет представлять информацию об отдельных товарах, если они отсутствуют в поставках. Чтобы такие порции информации можно было в модели представлять, необходимо ввести в модель сущность Товар и выполнить аналогичные процедуры построения, как и для сущности Поставщик (рис. 3.3.). Данный вариант заключает в себе возможности предыдущих вариантов и, кроме того, позволяет представлять информацию об отдельном товаре независимо от того, присутствовал он в поставках или нет. Однако в этом варианте нельзя представить такую информацию, как «какие товары может поставлять отдельный поставщик» и «какие поставщики могут поставлять данный товар». Чтобы реализовать в модели возможность представления подобной информации, необходимо организовать соответствующие связи между сущностями Поставщик и Товар (рис. 3.4).
|
|
Рис. 3.3. Введение в модель сущности ТОВАР
Для локального представления, рассмотренного в примере, выбираем последний вариант модели, поскольку он оказался более гибким для представления информации, т.е. позволяет представлять не только информацию о поставках, но также ее отдельные фрагменты: о поставщиках, товарах, возможностях поставщиков, распределении поставщиков по видам товаров. Следовательно, БД, реализующая это представление, окажется более гибкой в обработке данных и будет обладать большими возможностями по обработке произвольных запросов.
Итак, для данного локального представления целесообразно сформулировать такие сущности, как Поставка, Поставщик, Товар.
Каждой выбранной сущности должно быть присвоено четкое наименование. Желательно, чтобы оно отражало смысловое содержание вводимого понятия. Расплывчатые наименования, наличие синонимов (одно и то же понятие имеет различные наименования) и омонимов (различные понятия имеют одно и то же наименование) приводят к ошибкам в проектировании и являются недопустимыми.
|
|
Рис. 3.4. Организация связей между сущностями
Обобщение категорий сущностей на этом шаге обычно не выполняется. При моделировании локального представления необходимо выполнить распознавание этих категорий и представить каждую в виде самостоятельной сущности. Распознавание выполняется с использованием концепции типа или роли. Например, содержание сущности Учащийся вуза может быть разделено по категориям типов: Студент, Аспирант, Слушатель факультета повышения квалификации и т.д. (Обобщение этих типов в родовую сущность Учащийся вуза выполняется на этапе объединения локальных представлений).
Как уже отмечалось, общее количество сформулированных сущностей в отдельном локальном представлении должно быть ограниченным. 94
Большое число типов сущностей в одном локальном представлении говорит о том, что его область слишком обширна и ее необходимо пересмотреть с целью ограничения, разбив на несколько более мелких локальных областей.