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

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

Надежность функционирования задач и достоверность БД должны обеспечиваться за счет:

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

3.2 Выбор программного обеспечения

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

3.2.1 Обоснование выбора СУБД

Для разработки базы данных используется СУБД InterBase 7.5.

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

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

Производительность, удобство использования, поддержка Windows, Linux и Solaris, а также таких сред разработки, как Delphi, C++Builder, C#Builder и Kylix позволяют InterBase занять ведущее место среди разработчиков и стать недорогим вариантом ПО для предприятий.

 

 

3.3 Проектирование базы данных

1. Инфологическое проектирование

3.3.1.1 Определение, формулировка и описание сущностей

В ходе анализа предметной области были выделены следующие сущности:

1. Сущность «Единицы измерения» содержит наименование единиц измерения;
2. Сущность «Поставщик» содержит информацию о всех поставщиках с которыми работает СТО;
3. Сущность «Категория запчастей» содержит наименование категорий запчастей для определения назначения запчастей;
4. Сущность «Запчасти» содержит информацию о запчастях;
5. Сущность «Склад» содержит информацию о приходных накладных и запчастях;
6. Сущность «Расходный документ» содержит информацию о дате продаже запчастей, каких именно, их количество и стоимости;
7. Сущность «Расход» содержит информации о всех продажах;
8. Сущность «Приходная накладная» содержит информацию о поступившем товаре.

3.3.1.2 Спецификация атрибутов

В ходе анализа данных сущностей были выделены следующие атрибуты, представленные в таблицах приложения Г.

3.3.1.3 Выбор идентифицирующих атрибутов

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

1.   «Единицы измерения» -  в качестве первичного ключа выбран атрибут «Код единицы измерения», поскольку этот атрибут однозначно идентифицирует наименование единицы измерения.
2.   «Поставщик» - в качестве ключа выбран атрибут «Код поставщика», так как этот атрибут однозначно идентифицирует поставщика фирмы.
3.   «Категория запчастей» - в качестве ключа выбран атрибут «Код категории», так как этот атрибут однозначно идентифицирует категорию запчасти.
4.     «Запчасти» - в качестве ключа выбран атрибут «Код запчасти», так как этот атрибут однозначно идентифицирует определенную запчасть.
5.   «Склад»- в качестве ключа выбран атрибут «Код места», так как этот атрибут однозначно идентифицирует позицию добавления товара.
6.   «Расходный документ»- в качестве ключа выбран атрибут «Код расходного документа», так как этот атрибут однозначно идентифицирует расходный документ.
7.   «Расход»- в качестве ключа выбран атрибут «Код расхода», так как этот атрибут однозначно идентифицирует определенный расходный документ.
8.   «Приходная накладная»- в качестве ключа выбран атрибут «Номер документа», так как этот атрибут однозначно идентифицирует документ.
4. Определение связей между сущностями

Рассмотрим связи между сущностями.

1. Связь «Единица измерения» - «Запчасти» имеет характеристику «один-ко-многим», так как одной единице измерения может соответствовать несколько запчастей, а конкретная запчасть может соответствовать единственной единице измерения;
2. Связь «Единица измерения» - «Приходная накладная» имеет характеристику «один-ко-многим», так как одной единице измерения может соответствовать несколько запчастей, а конкретная запчасть может соответствовать единственной единице измерения;
3. Связь «Единица измерения» - «Расходный документ» имеет характеристику «один-ко-многим», так как одной единице измерения может соответствовать несколько запчастей, а конкретная запчасть может соответствовать единственной единице измерения;
4. Связь «Запчасти» - «Приходная накладная» имеет характеристику «один-ко-многим», так как одна запчасть может быть в нескольких приходных накладных, но одной приходной накладной соответствует одна определенная запчасть;
5. Связь «Запчасти» - «Расходный документ» имеет характеристику «один-ко-многим», так как одна запчасть может быть в нескольких расходных докумнетах, но одному расходному документу соответствует одна определенная запчасть;
6. Связь «Категория запчастей» - «Приходная накладная» имеет характеристику «один-ко-многим», так как одна категория запчасти  может быть в нескольких приходных накладных, но одной приходной накладной соответствует одна определенная категория запчасти для определенной детали ;
7. Связь «Категория запчасти» - «Расходный документ» имеет характеристику «один-ко-многим», так как одна категория запчасти  может быть в нескольких расходных документах, но одной приходной накладной соответствует одна определенная категория запчасти для определенной детали
8. Связь «Поставщик» - «Склад» имеет характеристику «один-ко-многим», поскольку поставщик может поставлять неограниченное число товара, а товар соответствует одному поставщику;
9. Связь «Категория запчасти» - «Запчасти» имеет характеристику «один-ко-многим», так как одному категории может соответствовать несколько запчастей , в то же время конкретной запчасти соответствует единственная категория товара;
10. Связь «Расходный документ» - «Расход» имеет характеристику «один-ко-многим», поскольку номер одного расходного документа соответствует одному расходу и в расходе может быть несколько расходных докуметов;
11. Связь «Приходная накладная» - «Склад» имеет характеристику «один-ко-одному», поскольку одна приходная накладная соответствует одному приходу на склад и склад может содержать несколько приходных накладных.
2. Логическое проектирование

3.3.2.1 Отображение концептуальной инфологической модели на объектно-ориентированную модель

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

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

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

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

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

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

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

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

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

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

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

2. Нормализация отношений

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

Проектируемая база данных является объектно-ориентированной. Объектно-ориентированная база данных – база, в которой данные моделируются в виде объектов, их атрибутов, методов и классов.  В нашем случае нормализация отношений не требуется, так как она необходима только в случаях реляционных БД.

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

Логическая модель, полученная в результате логического проектирования, спроектирована в ERWin и представлена на рисунке Д.1 приложения Д.

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

Таблицы, полученные по итогам логического проектирования представлены в приложении Д.

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

На основании итоговой логической модели, описание таблиц, которые будут реализованы в программе представлены в приложении.

Полученная в результате физическая модель данных представлена на рисунке Д.2 приложения Д.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

4 ПРОГРАММНАЯ РЕАЛИЗАЦИЯ ИС

          4.1 Назначение и функции программы

Разработанная подсистема предназначена для автоматизации складской деятельности, а именно процесса комплектации заказов.

Данная подсистема позволяет:

1. Существенно сократить трудоемкость и время выполнения основных операций;
2. Значительно сократить время формирования приходных накладных  и расходных документов;
3. Обеспечить возможность оперативного анализа хранящейся в базе данных информации;
4. Исключить дублирования и многократный ввод однотипной информации;
5. Обеспечить надежное хранение данных и защиту от несанкционированного доступа.

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

1. Учет товара на складе;
2. Формирование приходной накладной и расходного документа;
3. Внесение изменений, корректировок документов.

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

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

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

Минимизация усилий пользователя при выполнении работы: 

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

Стилевая гибкость: 

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