Глава 5. Методология концептуального проектирования

В этой главе мы опишем методологию концептуального проектирования с использованием ER-технологии проектирования.

Методология концептуального проектирования предполагает поэтапное построение локальной концептуальной модели, отражающей представление отдельного пользователя о предметной области.

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

5.1. Источники представления пользователей о предметной области

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

Определить характеристики представлений пользователей можно с помощью различных методов. Начать следует с изучения диаграмм потоков данных, которые к этому моменту уже должны быть созданы. Изучение этих диаграмм позволит установить функциональные области и, возможно, отдельные функции. Затем рекомендуется провести опросы потенциальных пользователей, изучить деловые процедуры, существующие отчеты и формы и/или провести обследование работы предприятия.

На первом этапе разработки должны быть выполнены следующие задания:

1. Определение типов сущностей.

2. Определение типов связей.

3. Определение атрибутов и связывание их с типами сущностей и связей.

4. Определение доменов атрибутов.

5. Определение потенциальных и первичных ключей.

6. Специализация или генерализация типов сущностей (необязательный этап).

7. Создание диаграммы "сущность-связь".

8. Обсуждение локальных концептуальных моделей данных с пользователями.

5.2. Определение типов сущностей

Первый этап в построении локальной концептуальной модели данных состоит в определении основных объектов, которые могут интересовать пользователя. Эти объекты являются типами сущностей, входящих в модель. Один из методов идентификации сущностей состоит в изучении спецификаций по выполнению конкретных функций пользователя на данном предприятии. Из этих спецификаций следует извлечь все используемые в них существительные или сочетания существительного и прилагательного (например, "личный номер", "фамилия работника", "номер объекта недвижимости", "адрес объекта недвижимости", "арендная плата", "количество комнат").

Затем среди них выбираются самые крупные объекты (люди, города) или представляющие интерес концепции и исключаются все существительные, которые просто определяют другие объекты. Например, свойства "личный номер" и "фамилия работника" могут быть объединены в сводном объекте под названием "работник", тогда как свойства "номер объекта недвижимости", "адрес объекта недвижимости", "арендная плата" и "количество комнат" можно объединить в сущности под названием "объект недвижимости".

Альтернативный способ идентификации сущностей состоит в поиске объектов, которые существуют независимо от других. Например, объект "работник" (staff) безусловно является сущностью, потому что любой работник существует независимо от того, знаем мы его имя, адрес и номер телефона или нет. В этой работе существенную помощь могут оказать пользователи создаваемого приложения.

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

После выделения каждой сущности ей следует присвоить некоторое осмысленное имя, которое обязательно должно быть понятно пользователям. Выбранное имя и описание сущности помещается в словарь данных.