Организационный аспект

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

Для того, чтобы спроектировать информационную систему, например, для сберегательного банка, АБД должен быть не банковский работник, а специалист по информационным системам, пусть даже плохо понимающий различия между терминами «дебет» и «кредит». В этом случае ему необходим консультант-экономист, знающий предметную область. На начальных шагах проектирования консультант часто будет выполнять роль переводчика между АБД и заказчиком. Наличие такого специалиста в группе способствует успешному обследованию предметной области.

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

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

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

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

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

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

Вопросы заказчику формулируются в предположении типа «да – нет» либо числового параметра. На отдельные вопросы заказчик может сразу не ответить, тогда они переносятся на следующую встречу.

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

Результаты встреч обязательно документируются (желательна виза заказчика на все протоколы встреч).

Концептуальное проектирование БД

Студент должен

знать:

· место, цели и задачи этапа концептуального проектирования;

· основные методы создания концептуальной модели;

· значение словаря баз данных;

· принципы создания модели «сущность–связь»;

уметь:

· создавать концептуальную модель для предметной области;

· обрабатывать требования, предъявляемые к базам данных;

· выделять сущности, атрибуты и связи;

· оценивать полученные варианты моделей.

План

1. Основы концептуального проектирования. Использование средств автоматизации проектирования (CASE-средства).

2. Объектное представление (нисходящее проектирование).

3. Моделирование сущностей (восходящее проектирование).

4. Классификация бинарных связей.

5. Модель «сущность – связь». Основные понятия.

6. Словари баз данных.

7. Пример проектирования БД.

Дата добавления: 2014-01-07