Автоматизированная справочно-информационная система учета и контроля поставок на предприятии (стр. 5 из 14)
Сущность “поставщик” является стержневой сущностью разрабатываемой модели. С поставщиком заключается договор, на основании которого ведется вся остальная деятельность предприятии по поставкам, отправление заявки поставщикам, получение от них счета-фактуры, отправление заказа на поставку, получение товара, оплата поставки. В качестве ключа для данной сущности вводится атрибут № Поставщика.
Все сущности , их атрибуты и ключи представлены в табл. 2.1.
Таблица 2.1
| Название сущности | Атрибут | Ключ |
| Договор | №Договора, дата договора, сумма договора, срок действия. | №Договора |
| Поставщик | №Поставщика, наименование поставщика, адрес, телефон. | №Поставщика |
| Ассортимент товаров | №Товара, наименование товара. | №Товара |
| Заявка | №Заявки, ассортимент заявки, номер договора, дата заявки. | №Заявки |
| Заказ | №Заказа, №Договора, ассортимент заказа, дата заказа, номер счета. | №Заказа |
| Счет-фактура | №Счета, ассортимент счета, цена за единицу товара, сумма счета. | №Счета |
2.4.2. Выделение связей между сущностями
Выделение связей между сущностями осуществляется на основании анализа предметной области. Все выделенные связи представлены на рис.2.1
 | ||||||||
 | ||||||||
 | ||||||||
 | ||||||||
 | ||||||||
 | ||||||||
Рис 2.1. Связи между сущностями
2.5 Построение логической модели.
Выполнив анализ сущностей и связей меду ними построим логическую модель, в виде отношений (таблица 2.2)
Таблица 2.2
| Название сущности | Атрибут | Ключ |
| Договор | №Договора, дата договора, сумма договора, срок действия. | №Договора |
| Поставщик | №Поставщика, наименование поставщика, адрес, телефон. | №Поставщика |
| Ассортимент товаров | №Товара, наименование товара. | №Товара |
| Заявка | №Заявки, номер договора, дата заявки. | №Заявки |
| Заявка | №Заявки, №товара, количество. | №Заявки, №Товара |
| Ассортимент заявки | №Заказа, №Договора, дата заказа, номер счета. | №Заказа |
| Ассортимент заказа | №Заказа, №Заявки, №товара. | №Заказа, №Заявки, №товара. |
| Счет-фактура | №Счета, сумма счета. | №Счета |
| Цены поставщика | №Счета, №Заявки, №Товара. | №Счета, №Заявки, №Товара. |
Рис 2.2 ER-диаграмма модели данных АСИС “Учет поставок”
3. Проектирование алгоритмов справочно-информационной системы учета и контроля поставок на предприятие.
Алгоритмизация в самом общем виде может быть определена как процесс направленного действия проектировщика (группы проектировщиков), необходимый для выработки алгоритмов, достаточных для реализации создаваемого объекта (системы), удовлетворяющего заданным требованиям [19]. Завершающим этапом алгоритмизации является выпуск набора алгоритмов, отображающий решения, принятые проектировщиком, в форме, необходимой для производства объекта (системы). При проектировании системы я использовал три класса алгоритмов:
¨ Алгоритмы, связанные с проектированием АСИС;
¨ Алгоритмы реляционной алгебры, необходимые для работы с БД;
¨ Алгоритмы расчета необходимых показателей (вычисление задолженности предприятия по оплате поставок, определение оптимального счета-фактуры).
3.1 Выбор метода проектирования АСИС.
Метод — это последовательный процесс создания моделей, которые описывают вполне определёнными средствами различные стороны разрабатываемой программной системы [18]. Методы важны по нескольким причинам. Во-первых , они упорядочивают процесс создания сложных программных систем. Во-вторых , они позволяют менеджерам в процессе разработки оценить степень продвижения и риск.
Обычно методы проектирования делятся на три основные группы;
· Метод проектирования сверху вниз;
· Метод потоков данных;
· Объектно-ориентированное проектирование.
Для структурного проектирования характерна алгоритмическая декомпозиция. Следует отметить , что большинство программ написано в соответствии с этим методом. Тем не менее структурный подход не позволяет выделить абстракции и обеспечить ограничение доступа к данным; он также не предоставляет достаточных средств для организации параллелизма. Структурный метод не может обеспечить создание предельно сложных систем , и он, как правило, неэффективен в объектных и объектно-ориентированных языках программирования. Поэтому данный метод не использовался для проектирования АСИС “Учет поставок”.
В методе потоков данных программная система рассматривается как преобразователь входных потоков в выходные. Метод потоков данных с успехом применялся при решении ряда сложных задач, в частности , в системах информационного обеспечения, где существуют прямые связи между входными и выходными потоками системы и где не требуется уделять особого внимания быстродействию. Но поскольку одним из основных требований предъявляемых к проектируемой АСИС является увеличение скорости автоматизации учета поставок и уменьшение временных затрат на оформление поставок на предприятии, то применение данного метода также нецелесообразно для проектирования АСИС.
Объектно-ориентированное проектирование (object-oriented design, OOD)—это подход в основе которого лежит представление о том , что программную систему нужно проектировать как совокупность взаимодействующих друг с другом объектов, рассматривая каждый объект как экземпляр определённого класса, причём классы образуют иерархию. Объектно-ориентированный подход отражает топологию новейших языков высокого уровня , таких как Object Pascal, C++, Smalltalk [23] и др. Модели, для проектирования которой используется вышеназванный подход проектирования присущи четыре главных элемента:
¨ Абстрагирование;
¨ Инкапсуляция;
¨ Модульность;
¨ Иерархия.
Абстрагирование позволяет выделить существенные характеристики проектируемого объекта, отличающие его от других объектов;
Инкапсуляция – процесс отделения друг от друга элементов объекта, определяющих его устройство и поведение. Она позволяет изолировать контрактные обязательства абстракции от их реализации.
Модульность – свойство системы, которая была разложена на внутренне связные, но слабо связанные между собой модули.
Иерархия – упорядочивание абстракций, расположение их по уровням.
Абстракция и инкапсуляция дополняют друг друга. Абстрагирование направлено на наблюдение поведения объекта извне, а инкапсуляция определяет четкие границы между различными абстракциями, т.е. наблюдение за поведением объекта изнутри.
Использование этих элементов проектирования и позволяет значительно увеличить производительность любой проектируемой системы.
Таким образом, для проектирования АСИС используется объектно-ориентированный подход.
3.2. Анализ алгоритмов работы с базой данных
Система управления разработанной БД использует реляционный подход для построения базы данных [20]. Подобные системы основаны на реляционной модели данных, которые используются для моделирования взаимосвязей между объектами реального мира и для хранения данных об этих объектах. Применение реляционной модели данных [27] обусловлено использованием реляционной алгебры и соответствующих алгоритмов и операций для выполнения действий над данными. Использование алгоритмов реляционной алгебры [20] позволяет обеспечить высокую производительность работы с базой данных.
Основные операции реляционной алгебры были впервые предложены Коддом [26]. Он доказал, что запросы, формулируемые с помощью языка исчисления могут быть сформулированы в языках реляционной алгебры и наоборот [18], т.е запросы представленные с помощью языка реляционной алгебры могут быть использованы для выполнения запросов к разработанной БД. Ниже приведен ряд запросов к БД:
SELECT nomer_dogovora, postav.nomer_postav, dogovor.nomer_postav,
naimen_post
FROM postav, dogovor
WHERE postav.nomer_postav=dogovor.nomer_postav
SELECT select nomer_zajavki, zajavka.nomer_dogovora,
dogovor.nomer_dogovora, naimen_post,postav.nomer_postav,
dogovor.nomer_postav
FROM from zajavka,dogovor,postav
WHERE (zajavka.nomer_dogovora=dogovor.nomer_dogovora)
AND (postav.nomer_postav=dogovor.nomer_postav)
SELECT nomer_zakaza, zakaz.nomer_dogovora, dogovor.nomer_dogovora,
naimen_post,postav.nomer_postav, dogovor.nomer_postav