Изучение и анализ рынка товаров, закупаемых и реализуемых торгово-закупочным предприятием (на примере Белгородского территориального фонда обязательного медицинского страхования) )

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

2.1.2.1 СУБД Paradox и dBase

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

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

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

dBase во многом сходен с Paradox, но не имеет такой гибкости, как Paradox, не имеет возможности создания составных индексов, автоматического инкрементирования и не имеет такого большого набора типов, как Paradox.

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

При обеспечении многопользовательского доступа к БД были выявлены следующие недостатки:

·      вся тяжесть вычислительной нагрузки при доступе к БД ложится на приложение клиента (при запросе на выборку данных из таблицы вся БД копируется на клиентское место, где и ведется выборка);

·      локальные СУБД используют подход, ориентированный на работу с отдельными записями;

·      неоптимально расходуются ресурсы клиентского компьютера в сети (когда копируется вся база данных на клиентское место при запросе на выборку информации из таблицы);

·      низкий уровень безопасности данных, так как гораздо проще вносить изменения в отдельные таблицы, минуя приложения, например из Database Desktop;

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

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

Эти недостатки в использовании баз данных можно убрать переведя приложения из архитектуры плоских систем (файл-сервер) в архитектуру клиент-сервер.

2.1.2.2 СУБД InterBase

InterBase – это система клиент-сервер – масштабируемый высокопроизводительный SQL сервер баз данных, совершенный по простоте инсталляции, использования и обслуживания. SQL-сервер InterBase предназначен для хранения и обработки больших объемов информации в условиях одновременной работы с БД множества клиентских приложений.

Для задания смысловой и ссылочной целостности БД используются механизмы: 

·     отношение подчиненности между таблицами за счет первичных и вторичных

ключей;

·     ограничения на значения полей таблиц (бизнес-правила);

·     триггеры – подпрограммы, автономно выполняющиеся сервером до или после события изменения записи в таблице БД;

·     генераторы – для создания и использования уникальных значений нужных полей.

Для ускорения работы клиентских приложений с удаленными БД могут быть определены хранимые процедуры – подпрограммы, способные выполнять запросы к БД. Текст таких процедур хранится на сервере в откомпилированном виде. 

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

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

Для управления сервером используется InterBase Server Manager. 

Для создания и редактирования  БД можно  использовать Windows Interactive SQL (WISQL), на котором можно писать любые запросы, минуя BDE. Для создания, редактирования и просмотра БД можно также использовать Database Desktop и SQL Explorer. 

Таким образом, преимущества архитектуры клиент-сервер заключаются в следующем:

·      большинство вычислительных процессов происходит на сервере; таким образом снижаются требования к вычислительным мощностям компьютера клиента;

·      снижается сетевой трафик  за счет посылки сервером клиенту только тех данных, которые он запрашивал (вся база данных не копируется на клиентское место);

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

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

·      сервер реализует управление транзакциями и предотвращает попытки одновременного изменения данных; различные уровни транзакций определяют поведение сервера при одновременном изменении данных;

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

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

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

На основании всего вышесказанного я останавливаю свой выбор на СУБД InterBase (версии 5.0).  

2.1.3 Выбор аппаратных средств

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

Так как в качестве инструментального средства для разработки программного обеспечения используется Delphi 3.0 Client/Sever Suite, а для разработки системы баз данных – система управления базами данных Interbase 5.0 Server, то в качестве аппаратного обеспечения работы системы поддержки принятия решений для торгово-закупочного предприятия должен использоваться IBM-совместимый персональный компьютер с процессором Pentium или, в крайнем случае, 486. Желательно, чтобы память компьютера была не меньше 32 мегабайта.

От быстродействия ЭВМ зависит скорость работы программного обеспечения, поэтому, чем мощнее ЭВМ, тем лучше. Так как в качестве решения задачи дипломного проекта используется генетический алгоритм, который работает намного быстрее метода перебора, то можно было бы предположить, что задача может быть решена за очень малый промежуток времени. Но так как размерность входных данных в реальных условиях является очень большой (около 500 товаров и 50 поставщиков), и сложность метода перебора равна 50 в 500-й степени, то и сложность генетического алгоритма тоже не мала. Поэтому, для решения поставленной задачи особенно требуется быстродействующий компьютер, и чем больше его быстродействие, тем лучше.

Так как у разработчика в наличии  имеется компьютер Pentium 166 MMX, который не особенно (малое быстродействие), но удовлетворяет  поставленным выше требованиям, то в качестве аппаратного средства для разработки системы поддержки принятия решений для формирования заказа будет использоваться  именно этот компьютер.

2.2 Выбор алгоритма решения задачи формирования заказа

1) Информацию о предложениях товаров можно представить в виде двух таблиц:

a)  Таблица цен P.

                                                                                                              Таблица  2.1

b)  Таблица скидок S.

                                                                                                 Таблица  2.2

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

2) Информацию о потребностях товаров представим в виде таблицы :

Таблица  2.3

Суммарная потребность в товарах представима в виде вектора C:

                                                                                             Таблица   2.4

3) Заказ товаров формируется на основании вектора заказа N.

                                                 Таблица  2.5

4) Таким образом, для формирования оптимального заказа необходимо минимизировать функцию:

  (2.1)

Минимизировать функцию 2.1 можно с помощью генетического алгоритма (обоснование см. в пункте 1.3.3).

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

2.3 Инженерное решение задач дипломного проекта

2.3.1Общая структура проекта

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

Структура программы "СППР для формирования заказа на торгово-закупочном предприятии" представлена на рисунке 2.1.

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

Информация на вход программы может приходить в различном виде, например в виде файлов различных форматов и структуры. Для того, чтобы занести ее в базы входных данных ее необходимо обработать: преобразовать файлы в единый формат и структуру. Это происходит в блоках, называемых  "конвертирование", которые входят в подсистему конвертирования.

Обработанная информация затем заносится в базы входных данных.

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

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

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

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

2.3.2 Представление проекта в модульных диаграммах

Вследствие того, что выбранный инструмент разработки (Delphi) представляет собой среду, базирующуюся на объектно-ориентированной методологии построения программ, то целесообразно провести проектирование основных компонент программы в соответствие с этой методологией.  Для описания общей структуры программы будем использовать диаграммы Гради Буча, а именно: высокоуровневые и обычные модульные диаграммы.

На рисунке 2.2 представлена высокоуровневая модульная диаграмма  всего проекта – СППР для формирования заказа на торгово-закупочном предприятии.

В функции СППР для формирования заказа на торгово-закупочном предприятии входит решение следующих подзадач:

1.   ввод и обработка входных данных системы : прайс-листов поставщиков, листов заказа заказчиков;

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

3.   просмотр состояния рынка и анализ спроса на рынке;

4.   вывод на экран и на принтер разнарядок на поставку и на получение товаров;

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

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

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

На рисунке 2.3 представлена модульная диаграмма СППР для формирования заказа на торгово-закупочном предприятии (обозначим ее СППР).

Главный модуль (СППР) по сути является модулем, в котором происходят вызовы подпрограмм и использование результатов работы других модулей, выполняющих необходимые в данный момент действия. Этот модуль связан с главной формой проекта, которая появляется после запуска программы.  

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

 В модуле "Ввод входных данных" (подзадача 1) реализуется ввод содержимого прайс-листов и листов заказа, который осуществляется вручную, автоматизированно, с помощью списков часто используемых товаров, или автоматически, с использованием конвертированных файлов.  Модуль "Работа со справочниками" отвечает за введение данных в справочники.

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

Модули "Сформированные заказы", "Разнарядки" и "Столбчатая диаграмма " работают уже с выходными данными, полученными в результате работы подсистемы формирования заказов на товары. Модуль "Сформированные заказы" отвечает за работу пользователя с базой выходных данных, в которой  хранится информация о полученных в результате работы программы заказах. Модуль "Разнарядки" реализует выполнение подзадачи 4 системы, а модуль "Столбчатая диаграмма" – подзадачи 5.

На рисунке 2.4 представлена модульная диаграмма подсистемы конвертирования и наполнения базы входных данных.

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

В модуле "Внесение информации в БД" на вход поступают конвертированные файлы. Извлекаемая из этих файлов информация обрабатывается с использованием справочников наименований товаров и производителей (см. п. 2.3.3.1), а затем заносится в базу входных данных.

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

В модуле " Формирование заказа простыми методами " осуществляется введение установок для формируемого заказа, таких как учет территории поставщика, учет условий поставки, учет содержимого на складе и учет производителей. Затем пользователем выбирается один из четырех методов формирования заказа (включая и генетический алгоритм). Данный модуль реализует только три метода формирования заказа : по минимальным ценам, по максимальным ценам и на одно предприятие.

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

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

2.3.3 Базы данных системы.

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

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

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

MAINDRUG (родительская таблица справочника товаров)

Таблица  2.6

SUBDRUG (дочерняя таблица справочника товаров)

Таблица  2.7

MAINPROD (родительская таблица справочника производителей)

Таблица  2.8

SUBPROD (дочерняя таблица справочника производителей)

Таблица  2.9

2.3.3.2 База входных данных.

Струк­тура базы входных данных и используемые справочники  представлены на рисунке 2.7. 

           База входных данных разделяется на две подбазы : база данных прайс-листов и база данных листов заказа (заявок заказчиков).

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

Рассмотрим подробно структуру базы входных данных.

Таблица PRICEATR – это таблица, представляющая атрибуты прайс-листов, является родительской таблицей базы данных прайс-листов. Основные ее поля: ссылка на справочник поставщиков SUPPLIER, ссылка на справочник условий поставки CONDITION, дата прайс-листа, дополнительная информация, наценка и поля системы скидок, предоставляемой поставщиком : первое поле – первая сумма, на которую предоставляется скидка, второе поле – скидка в процентах на стоимость большую или равную первой сумме, но меньшую второй суммы, третье поле – вторая сумма и т.д. (всего пять скидок). Описание полей таблицы PRICEATR смотрите в таблице 2.10.   

Таблица 2.10  Описание полей таблицы PRICEATR

См. продолжение

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

Таблица PRICESHEET представляет содержимое прайс-листов, является дочерней таблицей базы данных прайс-листов. Основными его полями являются: ссылка на атрибуты прайс-листа в родительской таблице PRICEATR, ссылка на справочник лекарственных средств DRUG, ссылка на международное наименование в справочнике международных наименований INTERNAT (о том, зачем необходимо это поле см. в описании справочника DRUG), цена лекарственного средства, упаковка, срок годности. Описание полей таблицы PRICESHEET смотрите в таблице 2.11.   

Таблица 2.11 Описание полей таблицы PRICESHEET

Таблица ZAKSHATR – родительская таблица базы данных листов заказа –  представляет атрибуты  листов заказа от ЛПУ и содержит такие значащие поля как: код заказчика (ЛПУ) – ссылка на справочник LPU, дата листа заказа, дополнительная информация. Описание полей таблицы ZAKSHATR смотрите в таблице 2.12.

Таблица 2.12 Описание полей таблицы ZAKSHATR

Таблица ZAKSHEET – дочерняя таблица базы данных листов заказа – представляет содержимое листов заказа от ЛПУ. Основными полями этой таблицы являются: ссылка на родительскую таблицу ZAKSHATR (номер атрибутов листа заказа), ссылка на справочник лекарственных средств DRUG, ссылка на справочник международных наименований INTERNAT,  необходимое количество упаковок указанного лекарственного средства, срок годности. Описание полей таблицы ZAKSHEET смотрите в таблице 2.13.

Таблица 2.13 Описание полей таблицы ZAKSHEET

Страницы: 1, 2, 3, 4, 5