Применение ER-моделирования к построению информационной системы коммерческой фирмы

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

Создание проекта начинается с формулировки требований к системе и составления технического задания.

Техническое задание может содержать следующие пункты. Названия и примеры заполнения пунктов приведены далее.

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

Наименование разработки Система управления базой данных (СУБД) по обслуживанию сельскохозяйственных предприятий компании. Пестициды и агрохимикаты.

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

Задачи разработки С целью эффективного обслуживания клиентов разработанная СУБД должна решать следующие задачи.

Ввод, хранение и анализ сведений о клиентах компании, их должностных лицах, местоположении.

Планирование, расчет и мониторинг заявок клиентов, их выполнения и оплаты.

Ведение справочника препаратов и агрохимикатов и условий их применения на культурных растениях против перечня вредящих объектов.

Мониторинг цен производителей препаратов и цен конкурентов — поставщиков.

Составление, расчет и выдача прайс-листов о предлагаемых товарах.

Планирование, расчет и мониторинг наших заявок поставщикам, их выполнения и оплаты.

Выдача суммирующих и сравнительных отчетов по результатам деятельности компании.

Сбор и анализ информации по клиентам.

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

Средства выполнения работы Персональная вычислительная техника типа IBM PC, теория и программы системы управления базами данных, опыт компании. В качестве основного программного инструментального средства разработки выбирается среда Visual FoxPro версии 5 и выше.

Содержание проекта Разработка проекта ИС основана на методе сущностей и связей. СУБД относится к реляционному типу, то есть информация представляется в виде двумерных таблиц. Каждой информационной сущности соответствует отдельная таблица.

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

Информационные сущности, наборы данных.

Вредящие объекты Против чего или для чего применяются препараты.

Действующие вещества препаратов Показывает состав действующих веществ в каждом препарате.

Действующие вещества Список химических составляющих, на основе которых изготавливаются препараты.

Должностные лица Содержатся сведения о должностных лицах клиентов и поставщиков.

Заявки клиентов Это заголовочная часть заявок клиентов нам. Табличная часть находится в Пунктах заявок клиентов.

Заявки компании Для обслуживания клиентов мы берем (покупаем) товары у крупных поставщиков, которым хлопотно заниматься каждым отдельным потребителем.

Классы культур Зерновые, овощи и прочее.

Классы препаратов Инсектициды, фунгициды, регуляторы роста и прочее.

Клиенты Сельскохозяйственные предприятия, которым мы продаем товары или оказываем услуги.

Культуры Сельскохозяйственные объекты, которые защищаются и стимулируются (пшеница, картофель кусты, картофель клубни и т. д.).

Курс условной единицы Курсы доллара и евро по отношению к рублю.

Менеджеры Сотрудники компании, отвечающие за работу с клиентами и их должностными лицами.

Начисления по ФПК Фонд поощрения клиентов (ФПК) организуется в компании с целью продвижения своих товаров на рынок.

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

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

Оплаты по ФПК Оплаты заявок клиентов Оплата заявки может проходить в несколько этапов и не привязывается к отдельным пунктам заявки.

Оплаты поставщикам Поставки для компании Поставки по заявкам клиентов Каждый пункт заявки клиента может удовлетворяться в несколько поставок. Поставка понимается как поставка одного товара одному клиенту.

Поставщики У них мы покупаем товары.

Поставщики товаров Здесь указываются цены сторонних поставщиков на поставляемые ими товары в одной из трех валют.

Прайс-листы Здесь содержится информация по прайс-листу в целом. Строки табличной части листов содержатся в сущности Пункты прайс-листов.

Препаративные формы Препараты могут изготавливаться в виде порошка, суспензии, раствора и т. п.

Препараты Производители товаров Если производитель и продает товары, то его надо включить в Поставщики.

Пункты заявок клиентов Табличная часть заявок клиентов нам.

Пункты заявок компании Табличная часть наших заявок поставщикам.

Пункты прайс-листов Список наших товаров и цены на них.

Районы События клиента События должностного лица Субъекты федерации Товары Хотя в нашей СУБД все товары являются препаратами, однако, один и тот же препарат может образовать несколько товаров с разной ценой в зависимости от упаковки и производителя. Также сущность Товары облегчит подключение к СУБД новых видов сельхозпродуктов.

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

Модель насчитывает 36 связей между информационными сущностями. Все связи относятся к типу «один ко многим» (1:М), т. е. каждому объекту из одного набора соответствует 0 и более объектов из второго набора и каждому объекту из второго набора соответствует 0 или 1 объект из первого набора. Например, каждому клиенту соответствует 0 и более заявок, и каждая заявка относится не более чем к одному клиенту. Связи показаны на рисунке 1 линиями, причем сторона «многие» оканчивается трезубцем, а сторона «один» — крестиком.

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

Рис 8.13.

Заметим, что на рисунке показано 37 сущностей. Две сущности: Семена и Удобрения, — не предполагаются входящими в состав проектируемой ИС. Они показывают место изменения системы при появлении новых видов потребностей клиентов.

Схема имеет несколько колец связей: Товары — Пункты наших заявок — Наши заявки — Поставщики — Поставщики товаров — Товары, Товары — Пункты заявки — Клиенты — Должностные лица — Поставщики — Товары, Клиенты — Объемы — Нормы расхода — Препараты — Товары — Пункты заявки — Клиенты. Ни один из модулей системы не должен обрабатывать все сущности кольца вместе.

Главной сущностью, как видно, является Товары — у нее 9 связей (система торговая). Вторая по важности — Клиенты — 8 связей (система обслуживающая). Третья сущность по важности — Препараты — 5 связей (система сельскохозяйственная).

Декомпозиция С целью составления плана работ по реализации СУБД выделим из системы более или менее независимые подсистемы. При выделении выполним требование, чтобы каждая подсистема после реализации и внедрения решала определенную задачу в компании и приносила пользу.

При анализе общей структуры (рис 8.19) выделяются следующие подсистемы.

Справочник препаратов (рис 8.20).

Рис 8.14.

Подсистема обрабатывает 9 сущностей и 8 связей.

Справочник клиентов (рис 8.21).

Рис 8.15.

Подсистема обрабатывает 11 сущностей и 10 связей, из которых сущность Культуры формируется в подсистеме Справочник препаратов.

Поставщики и товары (рис 8.22).

Рис 8.16.

Подсистема обрабатывает 7 сущностей и 6 связей, из которых сущность Препараты формируется в подсистеме Справочник препаратов, а сущность Должностные лица формируется так же как в подсистеме Клиенты. При реализации имеет смысл разделить ее на 2 подсистемы: подсистему Товары, обрабатывающую сущности Товары, Упаковка, Препараты и Производители, и подсистему Поставщики, обрабатывающую сущности Товары, Должностные лица, Поставщики товаров и Поставщики.

Заявки клиентов (рис 8.23).

Рис 8.17.

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

Прайс-листы (рис 8.24).

Рис 8.18.

Самая простая подсистема. Обрабатывает 3 сущности и 2 связи, из которых сущность Товары формируется в подсистеме Поставщики и товары.

Заявки компании поставщикам (рис 8.25).

Рис 8.19.

Обрабатывает 6 сущностей и 5 связей, из которых сущности Товары и Поставщики формируются в подсистеме Поставщики и товары.

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

План работ Последовательность этапов диктуется максимумом и комплексностью внедренных функций.

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

В таблице 8.1 находится календарный план выполнения работ по реализации СУБД и примерная стоимость.

Таблица 8.1. Календарный план.

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

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

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

Сетевой график выполнения работ показан на рис 8.26. Цифрами указаны номера этапов в соответствии с таблицей 8.1.

Рис 8.20. Сетевой график проведения работ

Минимальный срок исполнения системы — 15 месяцев. Ориентировочная стоимость работы 106 000 рублей. Сетевой график показывает также, какие этапы можно выполнять параллельно.

В ходе выполнения могут появиться новые подсистемы информационные сущности, их атрибуты, новые запросы к данным, экранные формы, отчеты. Их необходимость несколько раз оговаривается и затем оформляется отдельными договорами, которые не входят в этапы таблицы 8.1. Это увеличивает общий срок выполнения работы.

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

Форма обновления всегда модальная. Форма навигации может быть немодальной.

Форма навигации содержит список, из которого выбирается объект, кнопки обновления: Добавить, Изменить, Удалить — и, возможно, кнопку фильтра по родительскому объекту (рис 8.27). При активизации родительский объект равен последнему использовавшемуся.

Рис 8.21. Форма навигации

Кнопки обновления вызывают форму обновления (рис 8.28), в которой можно редактировать информацию об объекте. Кнопки ОК и Отмена закрывают форму обновления. ОК вносит изменения в набор данных, Отмена не вносит изменений.

Рис 8.22. Форма обновления

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

Рис 8.23. Дочерние объекты

При задании справочных объектов (объект со стороны «1» на связи), например, Культуры к Нормам расхода использовать значение по умолчанию, в качестве которого берется объект последнего применения.

Замечание: Если имеется реализованная ИС для какой-либо предметной области, при помощи анализа интерфейса ИС можно восстановить и построить информационную модель.

Авторы проекта Забиралов С. В., системный администратор компании;

Киселев В.Г., доцент финансового факультета ННГУ;

Хаванов С.В., генеральный директор компании.

Август 2002 года.

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

Текст приложения не приводится.