3 Описание принятых проектных решений

3.1 Определение основных информационных потоков для проектирования модели данных

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

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

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

Рисунок 3.1 - Типичная диаграмма потока данных ИС

Рисунок 3.2 - Диаграмма потока данных ИС малого предприятия

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

На рис. 3.3приведена схема информационных потоков малого предприятия.

Рисунок 3.3 - Схема информационных потоков

Эту идею мы применим к диаграмме потоков. На рис. 3.4 представлена логическая диаграмма потоков данных. Основные элементы – действия (связи).

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

.

Рисунок 3.4 - Диаграмма потоков данных малого мебельного предприятия

3.3 Разработка концептуальной модели

На основании требований пользователей и анализа предметной области, а также составленных физической и логической диаграмм потока данных (ДПД), для данной структуры предприятия, будет создана локальная концептуальная модель данных предприятия [4].

Проводимый анализ дал такой результат – универсальное отношение, содержащее следующие данные:

информация о товаре;

учет продажи товаров;

учет остатков товара;

котроль оплаты за товар;

необходимые документы;

счета фирмы в банке;

товар на складе;

количество товара;

информация о договорах;

информация о фирмах;

информация о сделках;

информация об оплате;

поставленный товар;

сотрудник торговой фирмы;

контроль над продажей;

деятельность предприятия;

менеджер по продаже;

отдел бухгалтерии;

бухгалтер;

кассир;

кладовщик;

договор на поставку товара;

срок периодичности поставки;

вид товара;

цена товара;

количество товара;

реквизиты предприятия;

наименование предприятия;

идентификационный код;

счет в банке;

МФО банка;

наименование банка;

адрес предприятия;

телефон предприятия;

факс;

почтовый ящик в сети Internet;

счет-фактура( счет );

организация – получатель;

платежное поручение;

оплата за товар;

движение денег;

расчетный счет предприятия;

расчетный счет поставщика;

платежное поручение;

отметка банка;

выписка плательщику;

перечисления;

расчеты с поставщиками;

банки;

платежное поручение;

счет поставщика;

документы на отгрузку;

накладная на товар;

сопроводительные документы;

спецификация;

счет фактура;

установочные ярлыки;

описи;

приходная накладная;

карточка формуляр;

подсчет товара;

журнал регистрации прихода товара;

реальное количество товара;

кладовщики;

мат.ответственное лицо;

приходной ордер;

оприходование товара;

журнал реестра товара;

учет движения товара;

номенклатура ценник;

журнал учета движения денег;

финансовые операции;

подготовка товара;

подготовка товара;

заявка-заказ;

прайс-лист;

продажа товара;

менеджер по-продаже;

журнал регистрации заказов;

папка заказов;

количество товара;

журнал учета товара;

плательщик;

получатель;

физическое лицо;

заказчик;

приходной кассовый ордер;

деньги;

расчетный счет фирмы-заказчика;

фирма-заказчик;

банк;

уведомление об оплате;

бухгалтерия;

движение денег;

журнал реестра движения денег;

кладовщик;

расходная накладная;

журнал отгрузки товара;

копии счет-фактуры;

описание товара;

записи по движению товара;

журнал реестра товара;

отчет бухгалтерии;

отчет кладовщика.

Концептуальное проектирование – создание концептуального представления БД, включающее определение типов важнейших сущностей и сущесвующих между ними связей.

Каждая концептуальная модель данных включает:

- типы сущностей;

- типы связей;

- атрибуты;

- домены атрибутов;

- ключи.

Концептуальная модель данных дополняется документацией созданной в процессе разработки этой модели:

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

• определение типов связей;

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

• создание диаграммы «сушность-связь».

Таблица 3.1 - Сведения об основных сущностях

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

Сущности обычно представлены как существительные или выражения, содержащие существительные.

Определение связей между сущностями.

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

Таблица 2.2 - Типы связей

Имя связи	Описание	Особенности использования
Движение денег по счетам через Банк	Документы - платежные проручения, содержащие подробные сведения о расчетных счетах и сумм перечислений	Выписывается на основании счета и реквизитов организаций: плательщик, получатель
Движение товара	Фиксируются документы: приходная/расходная накладная, накладная на товар	Операции по получению и отгрузки товара
Движение денег по кассе	Фиксируется документ для расчетов – приходной кассовый ордер	Выписывается бухгалтерией для оплаты товара через кассу предприятия

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

Таблица 3.3 – Атрибуты сущностей

Тип сущности	Наименование	Тип	Ширина поля
Поставщик	Наименование орган. Контактное Лицо Должность Адрес Город Область Страна Индекс Телефон Факс Домашняя страница	C С С С C С С C С С С	50 25 15 100 30 30 10 8 50 50 50
Клиент	Наименование орган. Контактное Лицо Должность Адрес	C С С C	50 25 15 100

Продолжение таблицы 3.3

Клиент	Город Область Страна Индекс Телефон Факс Домашняя страница	С C С С C С С С	100 30 30 10 8 50 50 50
Заказ	КодЗаказа КодКлиента КодСотрудника ДатаРазмещения ДатаИсполнения ДатаНазначения Доставка СтоимостьДоставки НазваниеПолучателя АдресПолучателя ГородПолучателя ОбластьПoлучателя СтранаПолучателя ИндексПолучателя кодОтборочНакладной	N N N T T T C N C C C C C N N	10 10 10 10 10 10 20 10 30 30 30 30 30 30 10
Тип Товара	КодТипа товара Категория Описание Изображение	N C C OLE	10 20 150
Товар	код товара категория товара наименование поставщик единица измерения закупочная цена	N C C C C N	7 20 30 50 15 10
	розничная цена остаток на складе ожидается минимальный запас поставки прекращены	N N N N N	15 10 10 10 2
Сотрудник	КодСотрудника Фамилия Имя Отчество	N C C C	10 15 15 15

Продолжение таблицы 3.3

Сотрудник	Должность Обращение ДатаРождения ДатаНайма Адрес Город Область Страна Индекс Домашний телефон Добавочный Фотография Кому подчиняется Примечание	C C T T C C C C C C C OLE C C	15 15 10 10 50 15 15 15 10 50 50 OLE 50 250
Товарная накладная	КодТовНакладной Дата кодСотрудника	N T N	20 10 10
Отборочная накладная	КодОтбНакладной Дата кодСотрудника	N T N	20 10 10
Налоговая накладная	КодНалогНакладной КодРасхнойНакл Дата кодСотрудника	N N T N	20 20 10 10
Расходная накладная	КодРасхНакладной КодОтборочнойНакл Дата кодСотрудника	N N T N	20 20 10 10
Возвратная накладная	КодВозврНакладной КодКлиента Дата кодСотрудника	N N T N	20 20 10 10
Заявка	КодТовара КодЗаказаЦена Количество Скидка КодФормыОплаты	N N N N N N	10 10 10 10 10 10
ФормаОплаты	КодФормыОплаты Название	N C	10 15
ФормДоставки	КодФормыДоставки Название	N C	10 15

3.4 Построение модели данных на основе диаграмм ER-типа

Работа существенно упрощается, если сложная система помимо обширного текстового описания имеет и некоторое визуальное представление. Для представления связей между ними обычно используются диаграмма “сущность-связь”( ER-диаграммы).

Диаграммы «сущность-связь» (ER) предназначены для разработки моделей данных и обеспечивают стандартный способ определения данных и отношений между ними. Фактически с помощью ER осуществляется детализация хранилищ данных проектируемой системы, а также документируются сущности системы и способы их взаимодействия, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их отношений с другими объектами (связей) [16].

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

В результате анализа получили следующие обобщенные сущности:Поставщик; Товар; Тип Товара; Заказ; Клиент; СотрудникТоварная накладная; Возвратная накладная; Налоговая накладнаяОтборочная накладная; Форма оплаты; Форма доставки.

Элементы построения ER- диаграммы имеют следующие обозначения (рис. 3.5):

Рисунок 3.5 - Элементы построения ER- диаграммы

Также в результате упрощения определены основные связи между сущностями (рис. 3.6):

Рисунок 3.6, лист 2 - Основные связи между сущностями

Модель данных отражает взаимосвязи между объектами. На основе выделенных сущностей и связей построим ER-диаграмму (рис. 3.7).

Рисунок 3.7 -ER-диаграмма предметной области

3.5 Построение логической и физической модели

Логическая и физическая модели данных будут строиться с помощью CASE– средства продукта фирмыERWinVersion4.0. Продукт имеет два уровня представления модели – логический и физический.

Логический уровень – это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире. Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами. Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД [21]

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

Таблица 3.4 - Преобразование концептуальной модели в реляционную модель

E1 E2		1		n
		О	Н	О	Н
1	О	1	2	2	3
	Н	2	3	2	3
m	О	2	2	3	3
	Н	3	3	3	3

Здесь Е1, Е2-сущности 1,2; О – обязательная связь, Н – необязательная связь. Система автоматизированной обработки данных основывается на использовании определенной модели данных или информационной модели. Логическая и физическая модели представлены в приложении Е.

Концептуальная модель транслируется затем в модель данных, совместимую с выбранной СУБД. Возможно, что отраженные в концептуальной модели взаимосвязи между объектами окажутся впоследствии нереализуемыми средствами выбранной СУБД. Схема базы данных представлена на рис. 3.8.

Рисунок 3.8 - Схема базы данных

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

3.6 Описание основных алгоритмов автоматизированной системы управоления мебельным производством

К основным алгоритмам автоматизированной системы относятся:

• регистрация договора;

• регистрация поставщика и заказчика;

• регистрация заказов и счетов;

• добавление товара;

• поиск товара, поставщиков, заказчиков, счетов или накладных по параметрическим запросам;

• вычисление количества остатка товара;

• алгоритм отправки и приема товара;

• алгоритм оплаты товара;

• алгоритм санкционированного доступа в систему.

Общая для всех выше перечисленных алгоритмов блок-схема представлена на рис. 3.9.

Рисунок 3.9 - Обобщенная блок-схема алгоритмов

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

На рис. 3.10 представлена блок-схема типового поиска.

Рисунок 3.10 - Алгоритм поиска в БД

Рисунок 3.11 - Алгоритм вычисления остатка по товару

Алгоритм санкционированного доступа в системе предназначен для отражения процесса санкционированного доступа в систему (см. рис. 3.12).

Рисунок 3.12 - Алгоритм санкционированного доступа в систему

Алгоритм «Регистрация договора» предназначен для занесения информации в БД о сделке между поставщиком и торговым пердприятием. Алгоритм «Регистрация заказов и счетов» предназначен для занесения информации в БД о заказах и счетах на оплату товара. Алгоритм «Добавление товара» предназначен для занесения информации в БД о поставляемом товаре.

Алгоритм вычисления количества остатка товара, представленный на рис. 3.11, предназначен для подсчета количества товара после его продажи или приема на склад.