Дата (Date) – дата проводки документа.

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

     Список  соответствующих количеств товаров  – каждому товару в  соответствие ставится его количество.

     Список  соответствующих цен товаров  – каждому товару в соответствие ставится его цена, то есть цена покупки  товара у поставщика.

     Поставщик – в данном случае "продавец" товара.

     Склад – склад, в который физически  поставляется товар.

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

     Дата (Date) – дата проводки документа.

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

     Список  соответствующих количеств товаров  – каждому товару в соответствие ставится его количество.

     Список  соответствующих цен товаров  – каждому товару в соответствие ставится его розничная цена, т.е. конечная цена для клиента.

     Магазин – магазин, от имени которого поставляются указанные товары. Именно "от имени", а не непосредственно из магазина, так как один и тот же магазин  может продавать товары с различных  складов. А случай, когда магазин  является складом – частный.

     Склад – склад, из которого физически поставляется товар.

     Таким образом, проявляется существенное различие между приходными и расходными документами. По приходной накладной  товар приходит на склад. По расходной  – продается\перемещается со склада "от имени" того или иного магазина.

     При обработке перечисленных сущностей  получаем диаграмму "сущность-связь": 

     

 

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

     3.2.2 Физическое проектирование

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

     Итак, нормализуем отношения логической модели данных, установив характер связей в разрабатываемой схеме  базе данных:

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

     "Приход" – "Поставщик": данная связь  носит характер "один ко многим", так как одной приходной накладной  может соответствовать только  один поставщик, но одному поставщику  могут соответствовать несколько  приходных накладных.

     "Приход" – "Склад": данная связь носит  характер "один ко многим", так  как одной приходной накладной может соответствовать только один склад, но одному складу могут соответствовать несколько приходных накладных.

     "Расход" – "Склад": данная связь носит  характер "один ко многим", так  как одной расходной накладной  может соответствовать только  один склад, но одному складу  могут соответствовать несколько  расходных накладных.

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

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

     

     HTML прототипы

 

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

     Для данной Системы прототипы разрабатывались  в среде интегрированной разработки Delphi 2006. Дело в том, что к моменту реализации Системы вышла новая версия Delphi, немного более удобная предыдущей в отношении проектирования ASP.NET страниц.

     На  данном рисунке представлен прототип окна входа в систему (авторизации): 

 

     На  данном рисунке представлен прототип окна просмотра Приходных накладных: 

 

 

     Для конечного пользователя прототипы  компилировались в HTML страницы: 

 

     

     Разработка  интерфейса пользователя

 

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

 

     Заключение

 

     В результате всей проделанной работы был получен готовый к работе программный комплекс торгово-складской  автоматизации, предназначенный для  розничных предприятий заказчика  – ЗАО "Белгородский бройлер". В процессе разработки и поиска технологий удалось сохранить главную отличительную  особенность программы - её простоту для конечного пользователя. Понятный и стильный интерфейс создает  приятную и удобную атмосферу  работы с программой.

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

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

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