Разработка автоматизированной системы управления учета и товара оптового магазина

     а) ведение базы данных товаров и  групп товаров;

     б) регистрация прихода и расхода  товара;

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

     г) формирование прайс-листа магазина.

     д) формирование следующие отчетные и  первичные документы:

     - прайс-лист;

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

     - книга продаж за заданный интервал дат;

     - книга покупок за заданный интервал дат;

     - счет;

     - накладная;

     - товарный чек. 

     1.2 Проектирование системы 

      1.2.1 ER-диаграмма системы в нотации Чена 

     На  рисунке 1.1 приведена диаграмма «сущность-связь», демонстрирующая отношения между объектами системы учета прихода и расхода товара.

     Предприниматель всегда имеет одну кассу и один банковский счет, из которых он ПЛАТИТ поставщикам. Предприниматель нанимает работника. Каждый работник выполняет СБОРКУ СИСТ. БЛОКОВ (0 или более). В свою очередь, эти СИСТ. БЛОКи ПОКУПАЕТ контрагент. контрагент один, услуг может быть 0 или более. Предприниматель покупает 1 или более товар, а также продает 1 или более товар. В свою очередь, контрагент также покупает 1 или более товар, либо также продает 1 или более товар.

     Сущности  Предприниматель, контрагент, кассА, банковский счет и работник представляет независимые данные, которые всегда присутствуют в системе. Сущности Товар, сист. блок – данные, зависящие от других сущностей в системе. Отношения Нанимает и Имеет представляют собой безусловные отношения, т.е. отношения, которые всегда существуют до тех пор, пока существуют относящиеся к делу сущности. Остальные представляют собой условные отношения между сущностями. 

 

Рисунок 1.1 - ER-диаграмма системы в нотации Чена 

      1.2.2 Проектирование БД 

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

     На  первом этапе проектирования были определены следующие отношения:

     - Товар (Код, Производитель, Группа, Наименование, ЕдиницаИзм,  ЦенаЗакуп, ЦенаРеализ)

     - Контрагент (Код, Наименование, ТипКонтрагента, Организация, Адрес, Телефон, Паспорт, БанкРеквиз, ИНН, КПП).

     Атрибут «ТипКонтрагента» определяет тип - клиент/поставщик.

     Атрибут «Организация» определяет является ли контрагент юридическим лицом, или  физическим.

     -  Договор (№дог, ДатаНачДействия, ДатаОкончДействия, ПредметДоговора)

     - Приход (№прих, Дата, Товар, КолвоЗакуп, КолвоРеализ, ЦенаЗакуп, Сумма)

     - Расход (№расх, Дата, Товар,  Колво, Цена, Сумма)

     - НашиРеквизиты (Наименование, Адрес, РегистрационныеДанные, Адрес, Телефон, Паспорт, БанкРеквиз, ИНН, КПП).

     Подчеркнутые  поля являются первичными ключами. Поля, выделенные курсивом, являются внешними ключами.

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

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

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

     Разработанная на первом этапе модель не удовлетворяет  условиям нормальных форм. Поэтому схема данных была преобразована, было выделено 6 новых сущностей: ГруппаТовара, СоставПрихода, СоставРасхода:

     - ГруппаТовара (GoodsGroup) (Код, НаименованиеГруппы);

     - Товар (Goods) (Код, КодПроизводителя, КодГруппы, Наименование, ЕдиницаИзм,  ЦенаЗакуп, ЦенаРеализ);

     - Приход (Income) (№прих, Дата, Сумма);

     - СоставПрихода (IncomeComp) (Код, №прих, КодТовара, КолвоЗакуп, КолвоРеализ, ЦенаЗакуп, Сумма);

     -  Расход (Realiz) (№расх, Дата, Сумма);

     - СоставРасхода (RealizComp) (Код, №расх, КодТовара, КолвоРеализ, ЦенаРеализ, Сумма);

     - НашиРеквизиты (Наименование, Адрес, РегистрационныеДанные, Адрес, Телефон, Паспорт, БанкРеквиз, ИНН, КПП);

     - Контрагент (Contragent) (Код, Наименование, ТипКонтрагента, Организация, Адрес, Телефон, Паспорт, БанкРеквиз, ИНН, КПП);

     - Договор (Contract) (№дог, КодКонтрагента, ДатаНачДействия, ДатаОкончДействия, ПредметДоговора).

     ER-диаграмма в нотации IDEF1X информационной системы на логическом уровне представлена на рисунке 1.2.

     ER-диаграмма в нотации IDEF1X информационной системы на физическом уровне представлена на рисунке 1.3. 

 

Рисунок 1.2 - ER-диаграмма информационной системы на логическом уровне 

 

Рисунок 1.3 - ER-диаграмма информационной системы на физическом уровне 

     Разработанная модель находится в третьей нормальной форме т.к.:

     - атрибуты сущностей являются атомарными;

     - каждый неключевой атрибут функционально полно зависит от первичного ключа;

     - в модели отсутствуют транзитивные зависимости неключевых атрибутов от ключа. 

      1.2.3 Описание структуры таблиц БД 

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

Таблица 1.1 - Структура таблиц БД

Стадии  разработки	Этапы работ	Содержание  работ
1	2	3
1 Анализ  предметной области	Изучение системы  управления и принципов контроля оптового магазина	Сбор информации о данных об складе, клиентах, контрагентах и товарах, которые необходимо хранить. Сбор информации о принципах ведения учета и продажи товара
2 Техническое  задание	Обоснование необходимости  разработки проекта	Постановка задачи Сбор исходных материалов Выбор и обоснование  критериев эффективности качества разрабатываемой системы Обоснование необходимости  проведения исследовательских работ
	Исследовательские работы	Определение структуры  входных и выходных данных Предварительный выбор методов решения задачи Определение требований к техническим средствам
	Разработка  и утверждение технического задания	Определение требований к программе Определение стадий, этапов и сроков разработки программы  и документации на нее Выбор языков программирования Согласование  и утверждение технического задания
3 Эскизный  проект	Разработка  эскизного проекта	Предварительная разработка структуры входных и  выходных данных Уточнение методов  решения задачи Разработка общего описания алгоритма решения задачи
	Утверждение эскизного  проекта	Разработка  пояснительной записки Согласование  и утверждение эскизного проекта

                                                   

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

1	2	3
4 Технический проект	Разработка  технического проекта	Уточнение структуры  входных и выходных данных Разработка алгоритма  решения задачи Определение формы  представления данных Разработка структуры  программы Окончательное определение конфигурации технических  средств
	Утверждение технического эскиза	Разработка  пояснительной записки Согласование  и утверждение эскизного проекта
5 Рабочий  проект	Разработка  модулей программы	Программирование  и отладка модулей
	Разработка  программной документации	Разработка  программных документов в соответствии с требованиями ГОСТ 19.101-77
	Испытания системы	Разработка, согласование и утверждение программы методик  испытания

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

     2 Анализ целесообразности  использования заданных  средств

       разработки 

     2.1 Приоритетный язык  программирования 

     2.1.1 Программный продукт Delphi 

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

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

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

     Пакет Delphi - продолжение линии компиляторов языка Pascal корпорации Borland. Pascal как язык очень прост, а строгий контроль типов данных способствует раннему  обнаружению ошибок и позволяет  быстро создавать надежные и эффективные программы. Корпорация Borland постоянно обогащала язык. Когда-то в версию 4.0 были включены средства раздельной трансляции, позже, начиная с версии 5.5, появились объекты, а в состав шестой версии пакета вошла полноценная библиотека классов Turbo Vision, реализующая оконную систему в текстовом режиме работы видеоадаптера. Это был один из первых продуктов, содержавших интегрированную среду разработки программ.

     В классе инструментальных средств для  начинающих программистов продуктам  компании Borland пришлось конкурировать со средой Visual Basic корпорации Microsoft, где вопросы интеграции и удобства работы были решены лучше.  Когда в начале 70-х годов Н. Вирт опубликовал сообщение о Pascal, это был компактный, с небольшим количеством основных понятий и зарезервированных слов язык программирования, нацеленный на обучение студентов. Язык, на котором предстоит работать пользователю Delphi, отличается от исходного не только наличием множества новых понятий и конструкций, но и идейно: в нем вместо минимизации числа понятий и использования самых простых конструкций (что, безусловно, хорошо для обучения, но не всегда оправдано в практической работе), предпочтение отдается удобству работы профессионального пользователя. Как язык Turbo Pascal естественно сравнивать с его ближайшими конкурентами - многочисленными вариациями на тему языка Basic (в первую очередь с Visual Basic корпорации Microsoft) и с C++. Object Pascal существенно превосходит Basic за счет полноценного объектного подхода, включающего в себя развитые механизмы инкапсуляции, наследование и полиморфизм. Последняя версия языка, применяемая в Delphi, по своим возможностям приближается к C++. Из основных механизмов, присущих C++, отсутствует только множественное наследование. (Впрочем, этим красивым и мощным механизмом порождения новых классов пользуется лишь небольшая часть программистов, пишущих на С++.) Плюсы применения языка Pascal очевидны: с одной стороны, в отличие от Visual Basic, основанного на интерпретации промежуточного кода, для него имеется компилятор, генерирующий машинный код, что позволяет получать значительно более быстрые программы. С другой - в отличие от C++ синтаксис языка Pascal способствует построению очень быстрых компиляторов.