78
предложил использовать для обработки данных аппарат теории множеств
(объединение, пересечение, разность, декартово произведение множеств и др.)
и показал, что любое представление данных сводится к совокупности
двумерных таблиц особого вида, известного в математике как отношение.
Таким образом, реляционная база данных представляет собой совокупность
связанных между собой реляционных отношений.
Существует два основных метода проектирования реляционных баз
данных: нисходящий и восходящий.
Разработка снизу-вверх (восходящее проектирование) – это получение
целого (описания предметной области) на основе составляющих его частей.
Восходящее проектирование начинается с определения атрибутов, которые на
основе анализа существующих между ними в предметной области
зависимостей группируются в реляционные отношения. Полученные схемы
реляционных отношений подвергаются процессу нормализации, основанного
на анализе функциональных, транзитивных, множественных и других видах
зависимостей между атрибутами. Восходящий метод проектирования подходит
для баз данных с относительно небольшим количеством атрибутов.
Проектирование БД сверху-вниз (нисходящее проектирование) основано
на декомпозиции – разделение целого на составные части с последующим их
исследованием. Использование нисходящего подхода применимо при
разработке БД с большим количеством атрибутов, поскольку установить среди
этих атрибутов все существующие в предметной области зависимости
затруднительно, гораздо проще выявить значимые для предметной области
существительные и связи между ними. Метод нисходящего проектирования
базы данных основан на разработке моделей предметной области, которые
содержат высокоуровневые сущности (классы объектов) и связи (отношения)
между ними.
При разработке модели данных необходимо учитывать:
− исключение или сведение к минимуму повторяющихся данных путем
задания нормализованных структур;
79
− обеспечение всем пользователям быстрого доступа к данным;
− возможность расширения структуры модели данных;
− обеспечение целостности данных;
− предотвращение несанкционированного доступа к данным;
− предоставление делегированного доступа к данным отдельному
пользователю или группе пользователей;
− снижение сложности создания приложений, предназначенных для
ввода, редактирования, обработки данных, а также анализа скрытых
закономерностей в структурах данных.
Иерархия функций автоматизированной системы представлена в таблице
2.13.
Таблица 2.13
Иерархия функций автоматизированной системы
Соединение с БД
Ведение справочных
данных
Фамилия, имя,
отчество
сотрудника
Добавление/Обновление
Ф1
Поиск/Просмотр
Ф2
Должность
Добавление/Обновление
Ф3
Поиск/Просмотр
Ф4
Отдел
Добавление/Обновление
Ф5
Поиск/Просмотр
Ф6
Производитель
Добавление/Обновление
Ф7
Поиск/Просмотр
Ф8
Название,
модель,
серийный номер
Добавление/Обновление
Ф9
Поиск/Просмотр
Ф10
Ведение учетных
данных
Добавление/Обновление
Ф11
Поиск/Просмотр
Ф12
Ремонт
Добавление/Обновление
Ф13
Поиск/Просмотр
Ф14
Ведение документации
Распоряжения
Добавление/Обновление
Ф15
Поиск/Просмотр
Ф16
Приказы
Добавление/Обновление
Ф17
Поиск/Просмотр
Ф18
Выполнение/Просмотр
Ф19
Информационно-логическая модель (ИЛМ) предметной области является
проблемно-ориентированной и системно-независимой, она не зависит от
80
конкретной СУБД, операционной системы и аппаратного обеспечения АС.
Назначение ИЛМ предметной области – адекватное, единое, интегрированное и
непротиворечивое отображение реального мира в рамках решаемой задачи
автоматизации; отражение потребностей всех пользователей разрабатываемой
АС.
ИЛМ предметной области представляет классы объектов предметной
области и связи (отношения) между ними. Связи относятся к одному из
следующих типов: «один-к-одному» (1: 1) и «один-ко-многим» (1: М).
На рисунке 2.4 представлена логическая схема данных модуля «Учет
приема техники клиентов». Построение логической модели данных
осуществляется на основе концептуальной модели данных, отражающей
представление пользователя о предметной области приложения.
Рисунок 2.4 - Схема данных модуля «Учет заявок клиентов»
2.3.3 Структурная схема пакета (дерево вызова программных модулей)
Идентификатор — это уникальный код модуля по списку метаданных.
vid_rab
code_rab: INTEGER
nam: CHAR(18)
stm: REAL
sotr
code_sotr: INTEGER
fio: CHAR(18)
dolgn: CHAR(18)
tel: CHAR(18)
naryad
code_nar: INTEGER
dayplan: DATE
dayfakt: DATE
num: INTEGER
daynach: DATE
code_rab: INTEGER (FK)
code_sotr: INTEGER (FK)
zayav
code_zay: INTEGER
code_obj: INTEGER (FK)
day: DATE
pr_isp: INT
prim: CHAR(18)
code_nar: INTEGER (FK)
objects
code_obj: INTEGER
adt: CHAR(18)
fio: CHAR(18)
tel: CHAR(18)
81
Разработанный модуль включает в себя серверную и клиентскую часть
Серверная часть является приложением для взаимодействия с базой данных,
клиентская –интерфейсом для ввода данных и получения отчетной
информации. Структурная схема пакета представлена на рисунке 2.5.
Рисунок 2.5 - Структурная схема пакета
На рисунке 2.6 представлено дерево программных модулей, отражающее
структурную схему пакета.
82
Рисунок 2.6 - Дерево программных модулей
2.3.4 Описание программных модулей
Технология внутримашинной организации задается последовательностью
реализуемых процедур - схем взаимосвязи программных модулей и
информационных массивов. Такая схема представляет собой декомпозицию
общего процесса решения задачи на отдельные процедуры преобразования
массивов, именуемыми модулями.
83
Работа модуля осуществляется по диалоговому и событийному режиму,
при этом под диалогом понимается предоставление пользователю нескольких
альтернатив и обработка его выбора. В диалоговую систему входит главное
меню с соответствующими всплывающими подменю, а также диалоговые окна.
Под событиями понимаются процессы, активизируемые пользователем
(например, нажатие функциональных клавиш).
На рисунке 2.7 представлена схема взаимосвязи программных модулей и
информационных файлов.
Вход в систему
Регистрация в системе
Вкладки
1. Учет выполнения заявок
2. НСИ
3. Документы
Заявка
План работ
Наряд-задание
Выполнение заявки
2. Справочники
Работы
Сотрудники
Объекты на обслуживании
4. Отчеты
Отчет о выполненных работах
исполнителями
Отчет о выполнении заявки
Отчет о платных услугах
5. Регистры
Расценки работ
Статусы заявок
Выполненные работы
Запланированные заявки
Рисунок 2.7 - Иерархия модулей автоматизированной системы
При работе со справочником Пользователь выбирает нужный справочник
на панели навигации, или меню системы, загружает его, производит нужные
действия и сохраняет данные в базе данных.
Алгоритм работы со справочником представлен на рис. 2.9.
84
При передаче техники Пользователь открывает форму формирования
документа, вводит нужные данные о сопутствующем документе, вводит
перечень техники, подлежащей передаче, и формирует документ.
Рассмотрим алгоритм приема заявок менеджером по работе с клиентами
(рис. 2.8).
Рисунок 2.8 - Обобщенная схема алгоритма принятия техники
менеджером по работе с клиентами
85
Рисунок 2.9 - Алгоритм работы со справочником
2.4 Контрольный пример реализации проекта и его описание
Модуль «Учет заявок клиентов» разработан на платформе 1С 8.3. После
запуска ИС на экране отображается стартовое окно, а затем окно как таковой
программы, представленные на рисунке 2.10 и рисунке 2.11.
Рисунок 2.10 - Окно запуска программы
86
Рисунок 2.11 - Основное окно и меню программы
Как уже описывалось выше, модуль «Учет заявок клиентов» использует в
работе документы программы, перечисленные ниже.
«Заявка» — документ предназначен для регистрации заявок от клиентов,
зарегистрированных на обслуживание. (рисунок 2.12).
Рисунок 2.12 - Форма документа «Заявка»
«План работ» — документ предназначен для составления плана работ,
согласно принятым заявкам. (рисунок 2.13).
87
Рисунок 2.13 - Форма документа «План работ»
«Наряд-задание» — документ предназначен для выдачи исполнителю
задания на выполнения заявки. (рисунок 2.14).
Рисунок 2.14 - Форма документа «Наряд-задание»