2.2. Постановка задачи

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

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

Эксплуатация задачи должна обеспечивать:

1. Формирование заказов;

2. Учет заказов:

1. Учет выполненных заказов;

2. Возможность отслеживания текущих заказов;

3. Учет результатов выполнения заказов поставщиками;

3. Учет информации о поставщиках:

1. Учет данных поставщиков;

2. Учет поступивших прайсов поставщиков;

3. Учет договоров;

4. Контроль оплаты поставок;

5. Учет работы сотрудников отдела закупок.

Задача предусматривает создание и использование справочной информации.

Разрабатываемая АИС должна реализовать внесение, просмотр, редактирование, хранение данных, а так же следующие вспомогательные функции:

1. быстрый поиск требуемой информации по заданным условиям;

2. формирование стандартных форм документов;

3. отображение и печать внесенных данных в виде стандартных отчетных форм;

4. создание статистических отчетов и т.д.

Задача решается в реальном времени, т.е. доступ к базе данных обеспечивается по мере необходимости.

Объектом управления и объектом применения задачи является отдел снабжения торгового предприятия.

Таким образом, необходимо произвести проектирование АИС, обеспечивающей целесообразность решения поставленных задач с ЭВМ, которая определяется наличием технических средств, персонала соответствующей квалификации и необходимыми исходными данными.

2.3. Информационное обеспечение

Информационное обеспечение (ИО) – это совокупность единой системы классификации и кодирования технико-экономической информации, унифицированной системы документации и информационной базы⁵.

ИО автоматизированных информационных систем состоит из:

• внемашинного ОИ - информация, которая воспринимается человеком без каких-либо технических средств;

• внутримашинного ИО - совокупность всех данных, записанных на машинных носителях, сгруппированных по определенным признакам.

2.3.1. Внемашинное информационное обеспечение

2.3.1.1. Инфологическое моделирование

Инфологическая модель (ИМ) предметной области – это описание предметной области, выполненной без ориентации на используемые в дальнейшем программные и технические средства. Инфологическая модель содержит исходную информацию о предметной области. Этап создания ИМ называется инфологическим проектированием⁶.

Диаграмма сущность-связь представляет собой модель данных верхнего уровня. Она включает сущности и взаимосвязи, отражающие основные бизнес-правила предметной области. Для более наглядного представления инфологической модели построена диаграмма «сущность-связь» (рисунок 11): ???

?Рисунок 11. Диаграмма «сущность-связь»

Для представления информационной модели данных используется CASE-средство ERwin, с помощью которого построена схема данных АИС (рисунок 12). ERwin предоставляет возможности создавать и управлять физическим и логическим уровнями представления модели. Схема данных для проектируемой в данной работе ИС построена на физико-логическом уровне.

На этапе построения информационной модели были совершены следующие работы:

• определение сущностей;

• определение зависимостей между сущностями;

• определение атрибутов сущностей;

• задание первичных и альтернативных ключей;

• задание названий связей, имен ролей;

• физическое описание модели: установление типов данных, назначение соответствий имя сущности - имя таблицы, атрибут сущности - атрибут таблицы.

БД представлена в виде сущностей, их атрибутов и связей между ними.

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

Для целей проектирования был определен следующий список сущностей:

1. Поставщик;

2. Банковские реквизиты;

3. Договор;

4. Условия оплаты;

5. Прайс;

6. Содержание прайса;

7. Счет;

8. Товары;

9. Группа товаров;

10. Артикул;

11. Заказ;

12. Состав заказа;

13. История заказа;

14. Оплата;

15. Заявка;

16. Сотрудники.

Список сущностей (Entity) с указанием ее типа (Entity Type) и описанием (Entity Definition) был сгенерирован в виде отчета в ERwin и представлен в Приложении 3. Описание – Definition - используется для ввода определения сущности, которые полезны, поскольку позволяют понять, что собой представляет указанный объект.

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

Связь является логическим соотношением между сущностями. По связи различают зависимые и независимые сущности. Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями. Экземпляр зависимой сущности определяется только через отношение к родительской сущности и изображается на диаграмме прямоугольником со скругленными углами. На диаграмме из 16 сущностей, 7 – независимые, а остальные 9 – зависимы от независимых сущностей.

Неидентифицирующая связь служит для связывания независимых сущностей.

Рисунок 12 . Схема данных АИС закупочной деятельности (логический уровень).

Рассмотрим связи между сущностями проектируемой системы:

1. Идентифицирующая связь:

   1. «Поставщик» - «Банковские реквизиты». Связь «один-ко-многим», поскольку поставщик может иметь несколько счетов в разных банках;

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

   3. «Поставщик» - «Счет». Связь «один-ко-многим», так как поставщик присылает на каждую поставку накладную, значит у одного поставщика может быть нуль, одна или много накладных.

   4. «Поставщик» - «Заказ». Связь «один-ко-многим», так как один поставщик может выполнять от одного и более заказов, либо не делать поставки по причине не размещения ему заказов.

   5. «Прайс» - «Содержание прайса». Связь «один-к-одному», так как одному прайсу соответствует только одно наполнение. Кардинальность связи – Z – «ноль или один», поскольку прайс может существовать какое-то время и без содержания, пока оно не будет введено.

   6. «Заказ» - «Оплата». Связь «один-ко-многим», так как заказ может быть оплачен частями, а не единовременным платежом.

   7. «Заказ» - «Состав заказа». Связь «один-к-одному», так как один заказ имеет только одно содержание заказа.

   8. «Заказ» - «История заказа». Связь «один-к-одному», так как один заказ может иметь только одну историю. Указанная мощность связи – Z – означает наличие в таблице одной или вообще отсутствие записи, в том случае, когда заказ уже создан и размещен, но пока не выполнен.

   9. «Товар» - «Состав заказа». Связь «один-ко-многим», так как один товар может быть заказан много раз.

   10. «Группа товаров» - «Товар». Связь «один-ко-многим», так как к одной группе товаров может относится от одного и более товаров, либо вообще не относится, если группа создана, а товаров еще нет.

   11. «Артикул» - «Товар». Связь «один-к-одному», так как одному товару может соответствовать только один артикул.

   12. «Счет» - «Оплата». Связь «один-ко-многим», так как каждый документ на оплату (накладная, счет-фактура) может быть оплачен частями, а не единовременным платежом.

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

   1. «Сотрудники» - «Заказ». Связь «один-ко-многим» - сотрудники могут делать один и более заказов, так же могут совсем их не делать. Заказ оформляется только одним сотрудником.

   2. «Сотрудники» - «Заявка». Связь «один-ко-многим» - сотрудники могут делать одну и более заявок или не делать их, но одна заявка делается только одним работником.

   3. «Поставщик» - «Договор». Связь «один-ко-многим», поскольку с поставщиком в процессе работы может быть заключено от нуля до большого числа договоров. Если поставщика не будет в базе (напр., он удален), договор все равно должен храниться.

   4. «Условия оплаты» - «Договор». Связь «один-ко-многим» - в договоре может быть указано исключительно только одно условие уплаты поставки, а на любое условие может быть использовано в нескольких договорах.

   5. «Прайс» - «Состав заказа». Связь «один-ко-многим», так как заказ делается поставщику, который на определенный момент времени может работать только по одному прайсу, но по каждому прайсу может быть сделано много заказов.

   6. «Товар» - «Заявка». Связь «один-ко-многим» - один конкретный товар может быть указан в заявке только один раз, а заявка может содержать один и более товаров. Поэтому мощность связи – P – «один и более».

   7. «Договор» - «Заказ». Связь «один-ко-многим» - в рамках одного договора может быть совершено несколько заказов, но заказ всегда делается по одному договору.

3. Неидентифицирующая связь (необязательная, т.е. в зависимой сущности могут находиться нулевые значения мигрирующих атрибутов):

   1. «Заявка» - «Заказ». Связь «один-ко-многим» - на основе одной заявки может быть сделано несколько заказов разным поставщикам. Но заказ может быть сделан и самостоятельно сотрудником отдела снабжения без заявки.