Автоматизированное рабочее место "Логистика" ЗАО "Приосколье"

Основываясь на всем вышеуказанном, было принято решение использовать в качестве инструментального средства разработки проекта Rational Rose Enterprise Edition, который полностью поддерживает объектно-ориентированный подход.

Rational Rose - CASE-средство фирмы Rational Software Corporation (США) - предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации.

Структура и функции

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

Средства автоматической генерации кодов программ на языке С++, используя информацию, содержащуюся в логической и физической моделях проекта, формируют файлы заголовков и файлы описаний классов и объектов. Создаваемый таким образом скелет программы может быть уточнен путем прямого программирования на языке С++. Анализатор кодов С++ реализован в виде отдельного программного модуля. Его назначение состоит в том, чтобы создавать модули проектов в форме Rational Rose на основе информации, содержащейся в определяемых пользователем исходных текстах на С++. В процессе работы анализатор осуществляет контроль правильности исходных текстов и диагностику ошибок. Модель, полученная в результате его работы, может целиком или фрагментарно использоваться в различных проектах. Анализатор обладает широкими возможностями настройки по входу и выходу. Например, можно определить типы исходных файлов, базовый компилятор, задать, какая информация должна быть включена в формируемую модель и какие элементы выходной модели следует выводить на экран. Таким образом, Rational Rose/С++ обеспечивает возможность повторного использования программных компонент.

В результате разработки проекта с помощью CASE-средства Rational Rose формируются следующие документы:

диаграммы классов;

диаграммы состояний;

диаграммы сценариев;

диаграммы модулей;

диаграммы процессов;

спецификации классов, объектов, атрибутов и операций

заготовки текстов программ;

модель разрабатываемой программной системы.

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

Тексты программ являются заготовками для последующей работы программистов. Они формируются в рабочем каталоге в виде файлов типов .h (заголовки, содержащие описания классов) и .cpp (заготовки программ для методов). Система включает в программные файлы собственные комментарии, которые начинаются с последовательности символов //##. Состав информации, включаемой в программные файлы, определяется либо по умолчанию, либо по усмотрению пользователя. В дальнейшем эти исходные тексты развиваются программистами в полноценные программы.

Взаимодействие с другими средствами и организация групповой работы

Rational Rose интегрируется со средством PVCS для организации групповой работы и управления проектом и со средством SoDA - для документирования проектов. Интеграция Rational Rose и SoDA обеспечивается средствами SoDA.

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

Для управляемой подмодели предусмотрены операции:

загрузка подмодели в память;

выгрузка подмодели из памяти;

сохранение подмодели на диске в виде отдельного файла;

установка защиты от модификации;

замена подмодели в памяти на новую.

Наиболее эффективно групповая работа организуется при интеграции Rational Rose со специальными средствами управления конфигурацией и контроля версий (PVCS). В этом случае защита от модификации устанавливается на все управляемые подмодели, кроме тех, которые выделены конкретному разработчику. В этом случае признак защиты от записи устанавливается для файлов, которые содержат подмодели, поэтому при считывании "чужих" подмоделей защита их от модификации сохраняется и случайные воздействия окажутся невозможными.

2.4 Постановка задач по подсистемам

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

Использование диаграммы Use Case (рисунок 4)- это возможность увидеть систему с ее функциями и подфункциям с точки зрения пользователя.

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

Рисунок 4. Диаграмма Use Case.

Рассмотрим каждую функцию:

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

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

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

Использование финансовых и материальных ресурсов - необходимо увязать имеющиеся у нас ресурсы с необходимыми требованиями рынка.

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

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

Входной информацией является:

ID поставщика;

Наименование товара;

Количество единиц;

Дата и время доставки;

Остаток товара на складе.

Выходной информацией является оформление заявки.

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

Исполнение обязательств по договорам - здесь работник Склада оговаривает точные сроки поставки и отгрузки товара. Выписывает необходимые для этого документы.

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

«Отдел продаж» Какой бы выгодный товар не получил Склад, как бы хорошо не распланировало весь процесс Генеральный директор в конечном итоге все упирается в Отдел продаж и его работников. От того, насколько хорошо они знают и умеют выполнять свою работу, зависит, как будет продаваться товар, и, как следствие, благополучие управления продажами. В разрабатываемой системе считается, что работник Отдела продаж сам заполняет форму заказа. Форма заполняется каждый раз, когда приходит новый клиент.

Формирование заказа - заказ формируется основываясь на БД имеющихся в наличии товаров.

Входной информацией является:

№ заказа;

ID клиента;

Наименование товара;

Количество единиц товара;

Стоимость товара;

Дата заказа.

Выходной информацией является оформленный заказ.

Учет и контроль за исполнением заказов клиентов.

Ведение договоров с покупателями - оговариваются условия доставки товара, а также условия расчета.

Анализ продаж - на основании анализа продаж производится изучение потребительского спроса.

«Бухгалтерия» Главной задачей является автоматизация складского учета, анализ состояния складов, контроль движения товарно-материальных ценностей; бухгалтерский и налоговый учет в полном соответствии с национальным законодательством; формирование налоговой, бухгалтерской и другой регламентированной отчетности в различные органы; бухгалтерский учет и контроль смет расходов бюджетных организаций в полном соответствии с законодательством и ведомственными инструкциями; сбор сводной отчетности бюджетных организаций

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

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

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

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

Критерии оценки поставщика:

- приемлемая цена;

- качество поставляемой продукции;

- качество обслуживания потребителей;

- гибкость поставок;

- ограничение размера заказа;

- дороги;

-удаленность поставщика от потребителя;

- психологический климат в коллективе;

- кредитоспособность и финансовое положение.

Критерии выбора поставщика:

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

- определение позиции поставщиков на рынке;

- определение профессионализма и надежности поставщиков;

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

- проведение переговоров с поставщиками;

- оценка уровня цены;

- надежность поставок.

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

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

Рисунок 5. Диаграмма классов.

Диаграмма Use Case и диаграмма классов являются основанием для построения структуры БД.

2.5 Обоснование выбора СУБД Access для разработки БД

Приложение Microsoft Access является мощной и высокопроизводительной 32-разрядной системой управления реляционной базой данных (далее СУБД).

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

Реляционная база данных. Практически все СУБД позволяют добавлять новые данные в таблицы. С этой точки зрения СУБД не отличаются от программ электронных таблиц (Microsoft Excel), которые могут эмулировать некоторые функции баз данных. Существует три принципиальных отличия между СУБД и программами электронных таблиц:

СУБД разрабатываются с целью обеспечения эффективной обработки больших объёмов информации, намного больших, чем те, с которыми справляются электронные таблицы.

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

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

Access - мощное приложение Windows. При этом производительность СУБД органично сочетаются со всеми удобствами и преимуществами Windows.

Как реляционная СУБД Access обеспечивает доступ ко всем типам данных и позволяет одновременно использовать несколько таблиц базы данных. Можно использовать таблицы, созданные в среде Paradox или dBase. Работая в среде Microsoft Office, пользователь получает в своё распоряжение полностью совместимые с Access текстовые документы(Word), электронные таблицы(Excel), презентации(PowerPoint).С помощью новых расширений для Internet можно напрямую взаимодействовать с данными из World Wide Web и транслировать представление данных на языке HTML, обеспечивая работу с такими приложениями как Internet Explorer и Netscape Navigator.

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

Несмотря на то, что Access является мощной и сложной системой, его использование не сложно для непрофессиональных пользователей.

Элементы базы данных.

Таблицы. В базе данных информация хранится в виде двумерных таблиц. Можно так же импортировать и связывать таблицы из других СУБД или систем управления электронными таблицами. Одновременно могут быть открыты 1024 таблицы.

Запросы. При помощи запросов можно произвести выборку данных по какому-нибудь критерию из разных таблиц. В запрос можно включать до 255 полей.

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

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

Макросы

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

База данных может содержать до 32768 объектов.

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

2.6 Разработка структуры базы данных и отношений атрибутов

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

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

Для идентификации требований, в соответствии с которыми сущности вовлекаются в отношения, используются связи. Каждая связь соединяет сущность и отношение и может быть направлена только от отношения к сущности. Значение связи характеризует её тип и выбирается из множества: "0 или 1", "0 или более", "1", "1 или более", "диапазон p:q". Пара значений связей, принадлежащая одному и тому же отношению, определит тип этого отношения.

Для большинства приложений достаточно использовать следующие типы отношений:

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

один ко многим (отношения такого типа являются наиболее часто используемыми);

многие ко многим (используется на ранних этапах проектирования с целью прояснения ситуации).

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

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

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

Разработка структуры базы данных включает такие основные этапы, как:

идентификация сущностей, их атрибутов, а также первичных и альтернативных ключей;

идентификация отношений между сущностями и указание типов отношений;

разрешение неспецифических видов отношений (многие к многим).

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

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

Согласно Кодду любая нормализованная схема (схема без повторяющихся групп) автоматически находится в первой нормальной форме (1НФ), независимо от того, насколько сложен ее ключ и какая взаимосвязь может существовать между ее элементами. По определению схема находится во второй нормальной форме (2НФ), если все её ключевые атрибуты полностью зависят от ключа. Схема находится в третьей нормальной форме (3НФ), если она находится во 2НФ, и ни какой неключевой атрибут не зависит от другого неключевого атрибута.

Этап 2 служит для выявления и определения отношений между сущностями, а также для идентификации типов отношений. На этом этапе допускаются неспецифические отношения "многие ко многим".

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

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

2.6.1 Нормализация базы данных

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

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

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

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

Первая нормальная форма

Первая нормальная форма:

запрещает повторяющиеся столбцы (содержащие одинаковую по смыслу информацию)

запрещает множественные столбцы (содержащие значения типа списка и т.п.)

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

Вторая нормальная форма

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

Третья нормальная форма

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

Нормальная форма Бойса-Кодда

Нормальная форма Бойса-Кодда требует, чтобы в таблице был только один потенциальный первичный ключ. Чаще всего у таблиц, находящихся в третьей нормальной форме, так и бывает, но не всегда. Если обнаружился второй столбец (комбинация столбцов), позволяющий однозначно идентифицировать строку, то для приведения к нормальной форме Бойса-Кодда такие данные надо вынести в отдельную таблицу.

Четвертая нормальная форма

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

Пятая нормальная форма

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

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

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

2.6.2 База данных автоматизированной системы управления складом

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

Рисунок 6. Схема данных.

Для этих целей система в общем виде условно разделяется на три составляющие:

Клиенты и оформление их заказов;

Поставщики, оформление заявок;

БД товаров.

В раздел «Клиенты и оформление их заказов» включены 2 таблицы:

«Клиенты»;

«ОформлениеЗаказа».

Связываются таблица «Клиенты» с таблицей «ОформлениеЗаказа» по ключевому полю «IDклиента», используя отношение типа «один ко многим». Схема связей показана на рисунке 7:

Рисунок 7. Схема связи «Клиенты и оформление их заказов».

В раздел «Поставщики, оформление заявок» включены следующие таблицы:

«Поставщики»;

«ОформлениеЗаявки».

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

Рисунок 8. Схема «Поставщики, оформление заявок».

В разделе «БД товаров» используются уже вышеупомянутые таблицы:

«ОформлениеЗаказа»;

«ОформлениеЗаявки».

Эти таблицы связываются между собой с помощью с помощью третьей таблицы «БД товаров» типом отношения «один ко многим». Это видно из рисунка 9:

Рисунок 9. Схема «БД товаров».

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

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

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

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

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

В данной БД используются следующие таблицы:

1. «Клиенты» (таблица 3):

IDКлиента: идентификатор клиента. Является ключевым полем данной таблицы. По нему выполняется поиск конкретного клиента;

ФИО клиента: вводятся фамилия, имя, отчество нового клиента;

Город: предприятию необходимо знать тот город, в котором проживает клиент;

Адрес: адрес клиента;

Телефон: телефон клиента;

e-mail: необходим для того, чтобы предприятие в любой момент могло вязаться с клиентом и уточнить его заказ;

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

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

Таблица 3.

«Клиенты»

«ОформлениеЗаказа» (таблица 4):

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

IDКлиента: идентификатор клиента;

НаименованиеТовара: дается перечень товаров;

КоличествоЕдиницТовара: выбирается количество товара;

СтоимостьТовара: цена за единицу товара;

ДатаЗаказа: число оформления заказа;

БДТоваров: обращение к БД товаров.

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

Таблица 4.

«Оформление заказа»

«Продажа» (таблица 5):

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

ФИОКлиента: вводятся фамилия, имя и отчество клиента;

НаименованиеТовара: выбирается из списка всех товаров;

СтоимостьТовара: цена за единицу товара;

КоличествоЕдиницТовара: количество покупаемого товара;

ДатаЗаказа: число оформления продажи.

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

Таблица 5.

«Продажа»

«БДТоваров» (таблица 6):

НаименованиеТовара: предлается весь перечень имеющихся товаров;

КоличествоТовараНаСкладе: количество всех товаров, которые имеются на складе;

ЦенаЗаЕдиницуТовара: цена за единицу выбранного товара;

ОстатокТовараНаСкладе: остаток определенного товара на складе.

Продавая товар или приобретая товар через поставщиков нам необходимо руководствоваться какими-то данными. Эти данные мы получаем из таблицы «БДТоваров».

Таблица 6.

«БДТоваров»

«ОформлениеЗаявки» (таблица 7):

IDПоставщика: идентификатор поставщика, в данной таблице является ключевым полем;

НаименованиеТовара: тот товара, который необходимо включить в список заявки;

КоличествоЕдиниц: количесво заказываемого товара;

ДатаВремяДоставки: оговариваются дата и время когда товар будет доставлен.

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

Таблица 7.

«ОформлениеЗаявки»

«Поставщики» (таблица 8):

IDПставщика: идентификатор поставщика, в данной таблице является ключевым полем;

ЮридическийАдрес: адрес, по которому можно связаться с поставщиком;

ФИО: фамилия, имя, отчество поставщика;

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

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