ПЗ (Автоматизированная информационная система предприятия компьютерного сервиса), страница 3

При выполнении операций по изменению или удалению данных необходимо обеспечить целостность БД.

2.3.3 Требования к составу и параметрам технических средств

Минимальные необходимые требования для нормального функционирования системы: персональный компьютер на базе процессора Intel или AMD с тактовой частотой не менее 1000МГц, 1 Гб оперативной памяти, свободное пространство на жестком диске 10 Гб, клавиатура, мышь, дисплей, принтер формата А4.

2.3.4 Требования к информационной и программной совместимости

Программа должна быть разработана, как Windows-приложение совместимое с операционными системами семейства MS Windows (Windows 7, Windows 8.1, Windows 10). Файл данных создаётся в формате Microsoft Access.

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

2.3.5 Требования к набору данных

Входные данные для системы должны являться:

 данные о клиентах;

 данные о менеджерах компании;

 данные о запчастях и расходных материалах;

 данные о видах ремонтных работ / сервисных услуг;

 данные о работниках и их специализациях;

 информация об организации;

 данные о приходе или расходе запчастей и расходных материалов.

Выходными данными для системы должны являться:

 прайс-лист на ремонтные работы / сервисные услуги;

 договор-заказ на ремонт или обслуживание техники;

 счет;

 счет-фактура;

 акт сдачи-приемки работ;

 остатки запчастей и расходных материалов на складе;

 суммы выполненных работ по работникам за период;

 суммы выручки по видам работ за период;

 суммы заказов по месяцам;

 суммы работ по клиентам за период.

2.4 Стадии и этапы разработки

Автоматизированная система должна разрабатываться в следующем порядке:

а) анализ предметной области;

б) разработка технического задания;

в) освоение программных средств;

г) проектирование системы;

д) разработка приложения;

е) оформление пояснительной записки.

2.5 Порядок контроля и приемки

Для АИС устанавливаются следующие этапы испытаний:

• Предварительные испытания;

• Опытная эксплуатация;

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

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

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

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

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

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

3 Проектирование АИС предприятия

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

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

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

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

– логическое проектирование – преобразование требований к данным в структуры данных. На выходе получаем СУБД-ориентированную структуру базы данных и спецификации прикладных программ;

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

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

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

Удобно представлять отношение как таблицу, где каждая строка есть кортеж, и каждый столбец соответствует одному компоненту. Столбцы при этом называются атрибутами и им присваивают имена. Список имён атрибутов называется схемой отношения. Совокупность схем отношений, используемых для представления информации, называются схемой базы данных, а текущие значения соответствующих отношений – базой данных [10].

Процесс построения инфологической модели состоит из следующих шагов [11]:

– определение сущностей;

– определение зависимостей между сущностями;

– задание первичных и альтернативных ключей;

– определение атрибутов сущностей;

– приведение модели к требуемому уровню нормальной формы.

Логический уровень представления модели – это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире. Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД. Физическая модель данных, напротив, зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация обо всех объектах БД. Поскольку стандартов на объекты БД не существует (например, нет стандарта на типы данных), физическая модель зависит от конкретной реализации СУБД. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей [1].

Современные объектно-ориентированные CASE-средства позволяют эффективно решать задачи проектирования приложений. Среди таких пакетов – Rational Rose, BPWin, ERWin, Process Analyst.

Для инфологического проектирования базы данных было выбрано CASE‑средство Computer Associates ERwin 4.1.

Создание модели данных, начинается с создания логической модели. После описания логической модели, проектировщик может выбрать необходимую СУБД и ERwin автоматически создаст соответствующую физическую модель. На основе физической модели ERwin может сгенерировать системный каталог СУБД или соответствующий SQL-скрипт. Этот процесс называется прямым проектированием. Тем самым достигается масштабируемость – создав одну логическую модель данных, можно сгенерировать физические модели под любую поддерживаемую ERwin СУБД. С другой стороны, ERwin способен по содержимому системного каталога или SQL-скрипту воссоздать и физическую, и логическую модель данных. На основе полученной логической модели данных можно сгенерировать физическую модель для другой СУБД и затем сгенерировать ее системный каталог [1, 13].

Различают два уровня физической модели [12]:

– трансформационная модель (Transformation Model);

– модель СУБД (DBMS Model).

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

ER-диаграмма системы на логическом уровне представлена на рисунке 3.1.

Рисунок 3.1  ER-диаграмма системы на логическом уровне

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

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

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

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

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

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

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

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

В качестве СУБД была выбрана Microsoft Access 2016.

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

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

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

Таблица 3.1  Описание таблиц базы данных

Продолжение таблицы 3.1. – Описание таблиц базы данных

Продолжение таблицы 3.1. – Описание таблиц базы данных

3.2 Описание алгоритма работы программы