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

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

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

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

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

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

Разбиение множества маршрутов на подмножества

Для выделения претендентов на включение во множество дуг, по которым производится ветвление, рассмотрим в приведенной матрице все элементы, равные нулю. Найдем степени И_ij нулевых элементов этой матрицы. Степень нулевого элемента И_ij равна сумме минимального элемента в строке i и минимального элемента в столбце j (при выборе этих минимумов c_ij- не учитывается). С наибольшей вероятностью искомому маршруту принадлежат дуги с максимальной степенью нуля.

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

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

Рейс можно задать системой из пяти подчеркнутых (выделенных другим цветом) элементов матрицы С, например, такой, как показано втабл. 2.2. Подчеркивание элемента означает, что в рейс из i-го элемента едут именно в j-тый. Для рейса из пяти городов подчеркнутых элементов должно быть пять, так как в рейсе из пяти городов есть пять ребер. Каждый столбец должен содержать ровно один подчеркнутый элемент (в каждый город коммивояжер въехал один раз), в каждой строке должен быть ровно один подчеркнутый элемент (из каждого города коммивояжер выехал один раз); кроме того, подчеркнутые элементы должны описывать один рейс, а не несколько меньших циклов. Сумма чисел подчеркнутых элементов есть стоимость рейса. На табл. 2.2 стоимость равна 26, это тот минимальный рейс, который получен лексикографическим перебором.

Таблица 2.2

-	1	2	3	4	5
1	-	6	4	8	7
2	6	-	7	11	7
3	4	7	-	4	3
4	8	11	4	-	5
5	7	7	3	5	-

Нам будет удобнее трактовать С_ij как стоимость проезда из города i в город j. Вычитая любую константу из всех элементов любой строки или столбца матрицы С, мы оставляем минимальный маршрут минимальным.Для алгоритма нам будет удобно получить побольше нулей в матрице С, не получая там, однако, отрицательных чисел. Для этого мы вычтем из каждой строки ее минимальный элемент (это называется приведением по строкам, см. табл. 2.3), а затем вычтем из каждого столбца матрицы, приведенной по строкам, его минимальный элемент, получив матрицу, приведенную по столбцам. (см. табл. 2.4).

Таблица 2.3

-	1	2	3	4	5
1	-	2	0	4	3	4
2	0	-	1	5	1	6
3	1	4	-	1	0	3
4	4	7	0	-	1	4
5	4	4	0	2	-	3

Таблица 2.4

-	1	2	3	4	5
1	-	0	0	3	3
2	0	-	1	4	1
3	1	2	-	0	0
4	4	5	0	-	1
5	4	2	0	1	-
		2		1

Прочерки по диагонали означают, что из города i в город i ездить нельзя. Заметим, что сумма констант приведения по строкам равна 20, сумма по столбцам 3, сумма сумм равна 23.

Теперь будем рассуждать от приведенной матрицы на табл. 2.4. Если в ней удастся построить правильную систему подчеркнутых элементов, т.е. систему, удовлетворяющую трем вышеописанным требованиям, и этими подчеркнутыми элементами будут только нули, то ясно, что для этой матрицы мы получим минимальный рейс. Но он же будет минимальным и для исходной матрицы С, только для того, чтобы получить правильную цену рейса, нужно будет обратно прибавить все константы приведения, и изменится цена рейса с 0 до 23. Таким образом, цена рейса не может быть меньше 23. Мы получили оценку снизу для всех рейсов.

Теперь приступим к ветвлению. Для этого проделаем шаг оценки нулей. Нарисуем заново таблицу 2.4, но при этом покажем в ней оценку нулей (см. Таблицу 2.5).

Таблица 2.5

-	1	2	3	4	5
1	-	02	00	3	3
2	02	-	1	4	1
3	1	2	-	01	01
4	4	5	01	-	1
5	4	2	01	1	-

Цифра, написанная над нулями, это и есть их оценка.

Выберем максимальную из этих оценок (в примере есть несколько оценок, равных двум, выберем первую из них, в клетке (1,2)).

Итак, выбрано нулевое ребро (1,2). Разобьем все рейсы на два класса - включающие ребро (1,2) и не включающие ребро (1,2). Про второй класс можно сказать, что придется приплатить еще 2, так что рейсы этого класса стоят 25 или больше.

Что касается первого класса, то в нем надо рассмотреть матрицу на табл. 2.6 с вычеркнутой первой строкой и вторым столбцом.

Таблица 2.6

-	1	3	4	5
2	0	1	4	1
3	1	-	0	0
4	4	0	-	1
5	4	0	1	-

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

Таблица 2.7

-	1	3	4	5
2	0	0	3	0
3	0	-	0	0
4	3	0	-	1
5	3	0	1	-

Продолжим ветвление в положительную сторону: влево - вниз. Максимальная оценка в клетке (3,1) равна 3.

Таблица 2.8

-	1	3	4	5
2	0	00	3	00
3	03	-	01	00
4	3	01	-	1
5	3	01	1	-

Таким образом, можно сказать, что оценка для маршрута, не включающего ребро (3,1) равна 25+3=28. Для оценки маршрута включающего ребро нужно вычеркнуть из матрицы C[1,2] еще строку 3 и столбец 1, получив матрицу C[(1,2),(3,1)] в табл. 2.9.

Таблица 2.9

-	3	4	5
2	00	3	00
4	01	-	1
5	01	1	-

Уменьшенную матрицу можно привести на 1 по второму столбцу.Также в эту матрицу нужно поставить запрет в клетку (2,3), так как уже построен фрагмент тура из ребер (1,2) и (3,1), т.е. [3,1,2], и нужно запретить преждевременное замыкание (2,3).Результат наших ветвлений и получения оценок показан в табл.2.10.

Таблица 2.10

-	3	4	5
2	0	2	0
4	0	-	1
5	0	0	-

Оценка для маршрута включающего ребро(3,1) равна 25+1=26.

Оцениваем теперь нули в приведенной матрице C[(1,2),(3,1)].Нуль с максимальной оценкой 3 находится в клетке (2,5) (табл.2.11). Отрицательный вариант имеет оценку 26+3=29.



Таблица 2.11

-	3	4	5
2	0	2	03
4	00	-	1
5	00	02	-

Для получения оценки положительного варианта убираем строчку 2 и столбец 5, ставим запрет в клетку (5,3), см. табл. 2.12.

Таблица 2.12

-	3	4
4	0	-
5	0	02

Оценка для маршрута, включающего ребро (2,5), равна 26.

Теперь, когда осталась матрица 2х2 с запретами по диагонали, достраиваем рейс ребрами (4,3) и (5,4). Мы не зря ветвились, по положительным вариантам. Сейчас получен рейс: 1>2>5>4>3>1 стоимостью в 26. При достижении низа по дереву перебора класс рейсов сузился до одного рейса, а оценка снизу превратилась в точную стоимость.

Итак, все маршруты, имеющие оценку 36 и выше, лучшего рейса не содержат. Поэтому соответствующие вершины вычеркиваются. Вычеркиваются также вершины, оба потомка которой вычеркнуты. Мы колоссально сократили полный перебор. Осталось проверить, не содержит ли лучшего тура маршрут, не включающий ребро (1,2).Оценка нулей дает 2 для нуля в клетке (1,2), так что оценка отрицательного варианта 25+2 превосходит стоимость уже полученного рейса 26 и отрицательный вариант отсекается.

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



Размещено на http://www.allbest.ru/

Рис. 2.12 Дерево ветвления с оценками

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

2.8 Измененная функционально-ориентированная модель

Если учесть, что приведенный выше алгоритм будет реализован в некотором программном средстве, то естественно изменится функционально-ориентированная модель функции «Вычисление длины пути на основе полученного маршрута». Результат изменения представлен на рисунке 2.13.

Как видно из ФОМ первые два этапа функции «Вычисление длины пути на основе полученного маршрута» (рис. 11) после внедрения гипотетического ПС заменяются на один этап. Это связано с тем, что программа извлекает расстояния между городами из матрицы расстояний, заполненной инженером, а не вычисляет их на основе координат городов. Теперь построим модернизированный, опять же с помощью внедрения некоторого программного средства, сценарий бизнес процесса «Поиск решения задачи».

Рис. 2.13 Измененная функционально-ориентированная модель функции «Вычисление длины пути на основе полученного маршрута»

где с - расстояние между городами,

?_т - текущая длина пути, а ? - итоговая длина пути.

2.9 Модернизированный сценарий бизнес процесса «Поиск решения задачи»

Изобразим сценарий работы функции «поиска решения задачи» при помощи уже программного средства. Данный сценарий продемонстрирован на рисунке 2.14.

Комментарий

На этапе формулирования задачи для инженера, формулируются входные данные. Эти входные данные представляют собой количество городов (n) и расстояние между этими городами (d). Вводя эти данными в ПС, инженер получает оптимальный маршрут и длину пути. Эти данные представляют собой выходные данные, которые обозначим s.



Специалист из отдела заключения контрактов	Главный инженер	Инженер

Рис. 2.14 Модернизированный сценарий бизнес процесса «Поиск решения задачи»

Т₁ - это время, которое затрачивается инженером на то, чтобы внести в программу необходимые данные. Расчет этого времени производится исходя из интерфейса программы. В программу необходимо внести n²+1 цифр, где единица обуславливается тем, что необходимо ввести количество городов в программу, а n² связано с заполнением матрицы расстояний. Если предположить, что для внесения в программу одного числа достаточно 3 сек, то время для внесения заданных данных вычисляется по формуле: .

Т₂ - это время необходимое для запуска программы и получения результата. Так как результат работы программы выдается сразу после нажатия кнопки запуска программы, то время Т₂ определяется только временем нажатия кнопки запуска программы. Если предположить, что для нажатия этой кнопки достаточно около 2 сек, то Т₂ можно принять равное 2.

Т_общ - это общее время, затрачиваемое на работу инженером, складывающееся из суммы Т₁ и Т₂, и это время будет иметь следующий вид:



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

При поиске оптимального маршрута по карте:

сек или же 6 мин 10 сек.

При поиске оптимального маршрута с помощью программного средства:

сек или же 1 мин 20 сек.

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

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

информационный программный маршрут груз



3. Проектирование информационной системы

3.1 Выбор архитектуры информационной системы

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

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

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

Под сетью понимается логическая структура вычислительной сети (локальной и глобальной), состав и характеристики серверной группы и клиентской части системы [7].

3.1.1 Архитектура Файл-Сервер

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

Объектами разработки в файл-серверном приложении являются компоненты приложения, определяющие логику диалога PL, а также логику обработки BL и управления данными DL. Разработанное приложение реализуется либо в виде законченного загрузочного модуля, либо в виде специального кода для интерпретации.

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

Одним из традиционных средств, на основе которых создаются файл-серверные системы, являются локальные СУБД. Однако такие системы, как правило, не отвечают требованиям обеспечения целостности данных (в частности, они не поддерживают транзакции). Поэтому при их использовании задача обеспечения целостности данных возлагается на программы клиентов, что приводит к усложнению клиентских приложений. Однако эти инструменты привлекают своей простотой, удобством использования и доступностью. Поэтому файл-серверные информационные системы до сих пор представляют интерес для малых рабочих групп. [8].

3.1.2 Архитектура клиент-сервер

Архитектура клиент-сервер предназначена для разрешения проблем файл-серверных приложений путем разделения компонентов приложения и размещения их там, где они будут функционировать наиболее эффективно. Особенностью архитектуры клиент-сервер является использование выделенных серверов баз данных, понимающих запросы на языке структурированных запросов SQL (Structured Query Language) и выполняющих поиск, сортировку и агрегирование информации. Отличительная черта серверов БД -- наличие справочника данных, в котором записана структура БД, ограничения целостности данных, форматы и даже серверные процедуры обработки данных по вызову или по событиям в программе. Объектами разработки в таких приложениях помимо диалога и логики обработки являются, прежде всего, реляционная модель данных и связанный с ней набор SQL-операторов для типовых запросов к базе данных.

Большинство конфигураций клиент-сервер использует двухуровневую модель, в которой клиент обращается к услугам сервера. Предполагается, что диалоговые компоненты PS и PL размещаются на клиенте, что позволяет обеспечить графический интерфейс. Компоненты управления данными DS и FS размещаются на сервере, а диалог (PS, PL), логика BL и DL -- на клиенте. Двухуровневое определение архитектуры клиент-сервер использует именно этот вариант: приложение работает у клиента, СУБД -- на сервере.

Поскольку эта схема предъявляет наименьшие требования к серверу, она обладает наилучшей масштабируемостью. Однако сложные приложения, вызывающие большое взаимодействие с БД, могут жестко загрузить как клиента, так и сеть. Результаты SQL-запроса должны вернуться клиенту для обработки, потому что там находится логика принятия решения. Такая схема приводит к дополнительному усложнению администрирования приложений, разбросанных по различным клиентским узлам [8].

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

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

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

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

Двухуровневые схемы архитектуры клиент-сервер могут привести к некоторым проблемам в сложных информационных приложениях с множеством пользователей и запутанной логикой. Решением этих проблем может стать использование многоуровневой архитектуры.

3.1.3 Многоуровневая архитектура

Многоуровневая архитектура стала развитием архитектуры клиент-сервер и в своей классической форме состоит из трех уровней:

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

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

· верхний уровень представляет собой удаленный специализированный сервер базы данных, выделенный для услуг обработки данных DS и файловых операций FS (без риска использования хранимых процедур).

Подобную концепцию обработки данных пропагандируют, в частности, фирмы Oracle, Sun, Borland и др.

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

Централизация логики приложения упрощает администрирование и сопровождение. Четко разделяются платформы и инструменты для реализации интерфейса и прикладной логики, что позволяет с наибольшей отдачей реализовывать их специалистам узкого профиля. Наконец, изменения прикладной логики не затрагивают интерфейса, и наоборот. Но поскольку границы между компонентами PL, BL и DL размыты, прикладная логика может появиться на всех трех уровнях. Сервер приложений с помощью монитора транзакций обеспечивает интерфейс с клиентами и другими серверами, может управлять транзакциями и гарантировать целостность распределенной базы данных. Средства удаленного вызова процедур наиболее соответствуют идее распределенных вычислений: они обеспечивают из любого узла сети вызов прикладной процедуры, расположенной на другом узле, передачу параметров, удаленную обработку и возврат результатов.

С ростом систем клиент-сервер необходимость трех уровней становится все более очевидной. Продукты для трехзвенной архитектуры, так называемые мониторы транзакций, являются относительно новыми. Эти инструменты в основном ориентированы на среду UNIX, однако прикладные серверы можно строить на базе Microsoft Windows NT с использованием вызова удаленных процедур для организации связи клиентов с сервером приложений. На практике в локальной сети могут использоваться смешанные архитектуры (двухуровневые и трехуровневые) с одним и тем же сервером базы данных. С учетом глобальных связей архитектура может иметь больше трех звеньев. В настоящее время появились новые инструментальные средства для гибкой сегментации приложений клиент-сервер по различным узлам сети [1].

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

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

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

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

3.2 Модель базы данных информационной системы отдела заказов предприятия «Комстар»

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

Рис. 3.1 Модель данных для базы данных информационной системы

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

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

1) № акта о разгрузке;

2) оператор, производящий приемку продукции на склад (зав. складом);

3) № товарно-транспортной накладной, по которой продукция прибыла на склад;

4) дата создания акта о разгрузке;

5) время создания акта о разгрузке;

6) № машины, с которой прибыла продукция;

7) поставщик продукции;

8) водитель машины;

9) дата разгрузки;

10) время разгрузки;

11) код продукта;

12) наименование продукта;

13) срок годности продукта;

14) количество коробов продукции;

15) вес короба продукции;

16) цена короба продукции;

17) адрес разгруженной продукции на складе;

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

Определим атрибуты объектного отношения «Карточка товара»:

1) наименование товарной единицы;

2) производитель товарной единицы;

3) код продукта;

4) вес короба продукции;

5) высота короба продукции;

6) ширина короба продукции;

7) длина короба продукции;

8) цена короба продукции.

Определим атрибуты объектного отношения «Поставщики»:

1) код поставщика;

2) название поставщика;

3) адрес поставщика;

4) телефон поставщика;

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

6) № договора с поставщиком;

Определим атрибуты объектного отношения «операторы»:

1) фамилия оператора;

2) имя оператора;

3) отчество оператора;

4) адрес оператора;

5) телефон оператора;

Определим атрибуты объектного отношения «Документы прихода»:

1) № акта разгрузки;

2) оператор;

3) № товарно-транспортной накладной;

4) время создания акта разгрузки;

5) дата создания акта разгрузки;

6) № машины, с которой прибыла продукция;

7) поставщик;

8) водитель машины;

9) дата разгрузки;

10) время разгрузки;

Определим атрибуты объектного отношения «Расположение»:

1) № акта разгрузки;

2) код продукта;

3) количество коробов;

4) срок годности продукции;

5) адрес;

Информация о товарах будет располагаться в файле с именем «tovar.dbf» со следующей структурой файла:

Таблица 3.1

Карточка товара

Название	Имя поля	Тип поля	Длина
Наименование товарной единицы	Nаim_tov	текстовый	30
Производитель товарной единицы	Naim_proizvod	текстовый	15
Код продукта	Kod_prod	числовой	6
Вес короба продукции	Ves_prod	числовой	4
Ширина короба продукции	Shir_prod	числовой	3
Высота короба продукции	Visot_prod	числовой	3
Длина короба продукции	Dlin_prod	числовой	3
Цена короба продукции	Cena_prod	числовой	4

Информация о поставщиках будет располагаться в файле с именем «postav.dbf» со следующей структурой файла:



Таблица 3.2

Поставщики

Название	Имя поля	Тип поля	Длина
код поставщика	Kod_post	числовой	5
Название поставщика	Naim_post	текстовый	15
Адрес поставщика	Adres_post	текстовый	30
Телефон поставщика	Telef_post	числовой	6
расчетный счет поставщика	Ras_shet	числовой	30
№ договора с поставщиком	№_dogov	числовой	10

Информация об операторах будет располагаться в файле с именем «operators.dbf» со следующей структурой файла:

Таблица 3.3

Операторы

Название	Имя поля	Тип поля	Длина
Фамилия оператора	FIO1_oper	текстовый	10
Имя оператора	FIO2_oper	текстовый	8
Отчество оператора	FIO3_oper	текстовый	10
Адрес оператора	Adres_oper	текстовый	30
Телефон оператора	Telef_oper	числовой	6

Информация о документах прихода будет располагаться в файле с именем «prihod.dbf» со следующей структурой файла:

Таблица 3.4

Документы прихода

Название	Имя поля	Тип поля	Длина
№ акта разгрузки	№_akt	числовой	10
Оператор	operator	текстовый	10
№ товарно-транспортной накладной	№_TTN	числовой	5
Время создания акта о разгрузке	Time	time	8
Дата создания акта о разгрузке	Data	data	10
№ машины, с которой прибыла продукция	№_cars	общий	10
Код поставщик	Kod_post	текстовый	15
Водитель машины	Voditel	текстовый	10
Дата разгрузки	Data1	data	10
Время разгрузки	Time1	time	8

Информация о расположении будет располагаться в файле с именем «adress.dbf» со следующей структурой файла:

Таблица 3.5

Распоряжения

Название	Имя поля	Тип поля	Длина
№ акта разгрузки	№_acts	числовой	10
Код продукта	Kod_prod	числовой	6
Количество коробов	Kol_case	числовой	3
Срок годности продукции	BBD	общий	15
Адрес	Аdress	общий	15

Информация о клиентах будет располагаться в файле с именем «klient.dbf» со следующей структурой файла:

Таблица 3.6

Клиенты

Название	Имя поля	Тип поля	Длина
код клиента	Kod_klien	числовой	5
название клиента	Naim_klien	текстовый	15
адрес клиента	Adres_klien	текстовый	30
телефон клиента	Telef_klien	числовой	6

Информация о документах отгрузки будет располагаться в файле с именем «otgryska.dbf» со следующей структурой файла:

Таблица 3.7

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

Название	Имя поля	Тип поля	Длина
№ акта отгрузки	№_akt1	числовой	10
№ заказа	№_zakaz	числовой	10
Оператор	operator	текстовый	10
Время создания акта oб отгрузки	Time2	time	8
Дата создания акта об отгрузки	Data2	data	10
Код клиента	Kod_klien	общий	5
Дата отгрузки	Data3	data	10
Время отгрузки	Time3	time	8



4. Выбор программного обеспечения для реализации информационной системы

Современные СУБД в основном являются приложениями Windows, так как данная среда позволяет более полно использовать возможности персональной ЭВМ. Снижение стоимости высокопроизводительных ПК обусловил не только широкий переход к среде Windows, где разработчик программного обеспечения может в меньше степени заботиться о распределении ресурсов, но также сделал программное обеспечение ПК в целом и СУБД в частности менее критичными к аппаратным ресурсам ЭВМ [7].

Среди наиболее ярких представителей систем управления базами данных можно отметить: Microsoft Access, Borland dBase, Borland Paradox, Microsoft Visual FoxPro, Microsoft Visual Basic, а также баз данных Microsoft SQL Server и Oracle, используемые в приложениях, построенных по технологии “клиент-сервер”. Фактически, у любой современной СУБД существует аналог, выпускаемый другой компанией, имеющий аналогичную область применения и возможности, любое приложение способно работать со многими форматами представления данных, осуществлять экспорт и импорт данных благодаря наличию большого числа конвертеров. Общепринятыми, также, являются технологи, позволяющие использовать возможности других приложе...