Файл: Руководство пользователей 47.docx

1.6.3. Обоснование проектных решений по программному обеспечению

Разрабатываемый програмный продукт будет реализован в технологии «клиент-сервер».

В качестве сервера баз данных использован сервер Firebird 2.5. Клиентская часть разработана в среде Borland Delphi 7. При этом требования к конфигурации клиентской машине минимальны. Клиентское ПО поддерживает сетевой протокол TCP/IP.[4]

Програмное обеспечение: Операционная система Windows XP, Vista, 7; сервер Firebird; MS Excel, IBExpert.

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

1.6.4. Обоснование проектных решений по технологическому обеспечению

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

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

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

» средства быстрого и удобного построения программ, в том числе визуального;

» встроенные компиляторы и отладчики.

Одной из таких RAD-систем является Delphi. Итак, Delphi — это объектно-ориентированная среда для визуального проектирования Windows приложений с развитыми механизмами повторного использования программного кода. Существенной чертой Delphi является компонентная модель разработки программных продуктов. Суть модели заключается в поддержке системой постоянно расширяемого набора объектных компонентов, из которых и строится программа. Компоненты в Delphi просты для использования и развития, как результат сокрытия значительной части той структуры программы, которая близка к взаимодействию с операционной системой.

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

Глава 2. Проектная часть

2.1. Информационное обеспечение задачи (комплекса задач, АРМ)

2.1.1. Информационная модель и ее описание

Построение инфологической модели БД начнем с реализации диаграммы потоков данных (DFD). Стандарт описания бизнес-процессов DFD — Data Flow Diagram переводится как диаграмма потоков данных и используется для описания процессов верхнего уровня и для описания реально существующих в организации потоков данных. Созданные модели потоков данных компании могут быть использованы при решении таких задач, как:

1. 
   определение  существующих  хранилищ данных  (текстовые  документы, файлы, система управления базой данных — СУБД);
   
2. 
   определение  и  анализ данных,  необходимых для  выполнения  каждой функции процесса;
   
3. 
   подготовка к созданию модели структуры данных организации,   так называемая ERD-модель (IDEF1X);
   
4. 
   выделение основных и вспомогательных бизнес-процессов организации.
   

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

Существуют две нотации диаграмм: графические нотации Йордана Де Марко и Гейна-Сарсона. Различие заключается в графических формах объектов. [2]

Основные объекты нотации, :

• 
  Процессы (Activities). Отображают процессы обработки и изменения информации;
  
• 
  Стрелки (Arrows). Отображают информационные потоки;
  
• 
  Хранилища данных (Data Store). Отображают данные, к которым осуществляется доступ, эти данные используются, создаются или изменяются работами;
  
• 
  Внешние сущности (External References). Отображают объекты, с которыми происходит взаимодействие.
  

Рисунок 2. Основные объекты DFD в нотации Йордана Де Марко

На Рисунок 3 показана диаграмма потоков данных в рамках рассматриваемой предметной области компании.



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

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

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

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

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

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

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

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

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

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

На Рисунок 4 показана инфологическая модель, включающая в себя сущности и атрибуты сущностей. Инфологическая модель базы данных представляет собой описание объектов (сущностей), с набором атрибутов и связей между ними, которые выявляются в процессе исследования как входных, так и выходных данных. Она предназначается для структурного образования предметной области, с ориентированием на информационное внимание пользователей, разрабатываемой системы. Так же инфологическая модель должна быть как стабильной, так и неизменной, и являться представлением аспекта пользователя на описанную предметную область. Однако, при проектировании инфологической модели, должна присутствовать возможность для её увеличения и вставки вспомогательных данных. [1]


Рисунок 4. Инфологическая модель данных
Даталогическая модель строится на основе существующей инфологической модели, для более наглядного вида и анализа - Рисунок 5.

Таблица «Товар»

Поле	Тип поля	Примечание
Код товара	Числовой	Уникальный код товара
Код отдела	Числовой	Уникальный код отдела
Код ед. измерения	Числовой	Уникальный код ед. измерения
Код группы	Числовой	Уникальный код группы
Наименование	Текстовый	Наименование товара
Цена	Денежный	Цена товара
Количество	Числовой	Количество товара
Комментарий	Текстовый	Комментарий на товар

Таблица «Информация о расходе»

Поле	Тип поля	Примечание
Код	Числовой	Уникальный код
Код расхода	Числовой	Уникальный код расхода
Код товара	Числовой	Уникальный код товара
Ед. измерения	Текстовый	Ед. измерения товара
Количество	Числовой	Количество товара
Цена	Денежный	Цена товара
Скидка	Числовой	Скидка на одно наименование товара

Таблица « Расход»

Поле	Тип поля	Примечание
Код расхода	Числовой	Уникальный код расхода
Код клиента	Числовой	Уникальный код клиента
Дата	Дата	Дата продажи
Сумма	Денежный	Сумма продажи
Статус	Текстовый	Закрыт счет или открыт

Таблица « Информация о приходе»

Поле	Тип поля	Примечание
Код	Числовой	Уникальный код
Код товара	Числовой	Уникальный код товара
Код прихода	Числовой	Уникальный код прихода
Количество	Числовой	Количество товара
Цена	Денежный	Цена товара
Ед. измерения	Текстовый	Ед. измерения товара

Таблица « Приход»

Поле	Тип поля	Примечание
Код прихода	Числовой	Уникальный код прихода
Код поставщика	Числовой	Уникальный код поставщика
Дата	Дата	Дата прихода
Сумма	Денежный	Сумма прихода

Таблица « Клиенты»

Поле	Тип поля	Примечание
Код клиента	Числовой	Уникальный код клиента
Наименование	Текстовый	Наименование клиента
Телефон	Текстовый	Телефон клиента
Электронная почта	Текстовый	E-mail клиента
Юридический адрес	Текстовый	Адрес клиента
Фактический адрес	Текстовый	Адрес клиента
Расчетный счёт	Текстовый	Расчетный счет клиента
ИНН	Текстовый	ИНН клиента
КПП	Текстовый	Код постановки на учет организации клиента
БИК	Текстовый	Банковский идентификационный номер

Таблица « Поставщики»

Поле	Тип поля	Примечание
Код поставщика	Числовой	Уникальный код поставщика
Наименование	Текстовый	Наименование поставщика
Юридический адрес	Текстовый	Адрес организации
Фактиеский адрес	Текстовый	Адрес организации
Телефон	Текстовый	Номер телефона организации
Электронная почта	Текстовый	E-mail организации
Расчетный счет	Текстовый	Расчетный счет поставщика
ИНН	Текстовый	ИНН поставщика
КПП	Текстовый	Код постановки на учет организации поставщика
ОГРН	Текстовый	Государственный регистрационный номер организации
ОКПО	Текстовый	Регистрационный номер организации
БИК	Текстовый	Банковский идентификационный номер

Таблица « Договора»

Поле	Тип поля	Примечание
Код договора	Числовой	Уникальный код договора
Код клиента	Числовой	Уникальный код клиента
Номер договора	Текстовый	Номер договора с клиентом
Дата заключения	Дата	Дата заключения договора
Скидка	Числовой	Скидка по договору

Таблица « Компания»

Поле	Тип поля	Примечание
Код компании	Числовой	Уникальный код компании
Наименование	Текстовый	Наименование компании
Адрес	Текстовый	Адрес компании
ИНН	Текстовый	ИНН компании
КПП	Текстовый	Код постановки на учет компании
Расчетный счет	Текстовый	Расчетный счет компании

Таблица « Сотрудники»

Поле	Тип поля	Примечание
Код сотрудника	Числовой	Уникальный код сотрудника
Код должности	Числовой	Уникальный код должности
Полное имя	Текстовый	Полное имя сотрудника
Логин	Текстовый	Логин сотрудника
Телефон	Текстовый	Телефон сотрудника

Таблица « Должности»

Поле	Тип поля	Примечание
Код должности	Числовой	Уникальный код должности
Наименование	Текстовый	Наименование должности

Таблица « Отделы»

Поле	Тип поля	Примечание
Код отдела	Числовой	Уникальный код отдела
Наименование	Текстовый	Наименование отдела

Таблица « Группы»

Поле	Тип поля	Примечание
Код группы	Числовой	Уникальный код группы товаров
Код отдела	Числовой	Уникальный код отдела
Наименование	Текстовый	Наименование группы товаров

Таблица « Единицы измерения»

Поле	Тип поля	Примечание
Код ед. измерения	Числовой	Уникальный код ед. измерения
Наименование	Текстовый	Наименование ед. измерения
Полное наименование	Текстовый	Полное наименование ед. изм.

Рисунок 5. Даталогическая модель данных

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

1. 
   Каждая ячейка в таблице представляет точно один элемент данных;
   
2. 
   Каждая таблица имеет однородные столбцы, все элементы в любом из столбцов одного и того же вида;
   
3. 
   Каждому столбцу назначено определенное имя;
   
4. 
   Все строки различны, дублировать строки не разрешается;
   
5. 
   Строки, и столбцы не зависят от последовательности, просмотр в различной последовательности не может изменить информационное содержание отношения;
   
6. 
   Каждая строка олицетворяет уникальный элемент данных, который ею и описывается;
   
7. 
   Столбцы представляют собой отдельные куски информации (атрибуты данных), которые известны о данном элементе.
   

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

Нормализация — это процесс организации данных в базе данных, включающий создание таблиц и установление отношений между ними в соответствии с правилами, которые обеспечивают защиту данных и делают базу данных более гибкой, устраняя избыточность и несогласованные зависимости. Существует несколько правил нормализации баз данных. Каждое правило называется «нормальной формой». Если выполняется первое правило, говорят, что база данных представлена в «первой нормальной форме». Если выполняются три первых правила, считается, что база данных представлена в «третьей нормальной форме». Разрабатываемая БД нормализована до 3НФ и представлена на Рисунок 6.[4]