55
– Он очень хорошо взаимодействует с другими продуктами Microsoft.
Недостатки
– Цена для юридических лиц оказывается неприемлемой для большей
части организаций.
– Даже при тщательной настройке производительности корпорация SQL
Server способен занять все доступные ресурсы.
– Сообщается о проблемах с использованием службы интеграции для
импорта файлов.
Таким образом, для управления базой данных автоматизированной
информационной системы функций СУБД MS SQL Server Express более чем
достаточно.
Также следует отметить, то, что СУБД Microsoft SQL сервер и IDE Visual
Studio являются бесплатными продуктами, что также снижает расходы на
разработку ПО.
2.3.1. Общие положения (дерево функций и сценарий диалога)
Разрабатываемая система мониторинга представляет из себя набор
функциональных АРМов, работающих непосредственно с общей для всей системы
базой данных. В стандартный набор входят следующие АРМы:
– Администратор
– Менеджер
– Механик
Рассмотрим дерево функций на примере АРМа администратора (рис. 2.4).
56
Рисунок 2.4 Дерево функций АРМ администратора
Рассмотрим дерево функций на примере АРМа менеджера (рис. 2.5).
Рисунок 2.5 Дерево функций АРМ менеджера
Рассмотрим дерево функций на примере АРМа механика (рис. 2.6).
Авторизация
Формирование заявки на
ремонт/обслуживание
Редактирование
перечня
технического парка
Выйти
Редактирование списка
клиентов
Авторизация
Просмотр данных
сотрудников
Добавление, редактирование
записи о сотрудниках
Выйти
57
Рисунок 2.6 Дерево функций АРМ механика
2.3.2. Характеристика базы данных
В основе процесса проектирования лежит метод нормализации.
Процесс нормализации – это формальный метод анализа отношений на
основе их первичных или потенциальных ключей и существующих
функциональных зависимостей, являющийся одним из наиболее строгих способов
улучшения характеристик БД. Он включает ряд формальных правил, используемых
для проверки всех отношений БД.
Можно выделить два подхода к проектированию реляционной БД.
Первый, более традиционный предложенный Коддом подход, предполагает
создание на этапе концептуального проектирования не концептуальной модели
данных, а непосредственно реляционной схемы базы данных, состоящей из
определений реляционных отношений. Собственно, проектирование реляционной
базы данных заключается в нормализации определений этих отношений.
Нормализация представляет собой вариант восходящего подхода к
проектированию базы данных, который заключается в постепенном выявлении
различного рода зависимостей между атрибутами и устранении нежелательных из
них.
Авторизация
Просмотр текущих
заказов на
ремонт/облуживание
Отметка о статусе
исполнения
Выйти
Просмотр текущих заказов на
ремонт/облуживание
авторизированного механика
58
Второй подход основан на концептуальной модели данных, создаваемой на
этапе концептуального проектирования. Затем эта модель механически
преобразуется в реляционную модель. Процесс преобразования автоматически
гарантирует получение нормализованной реляционной модели. Данный подход
можно отнести к категории нисходящих, поскольку он начинается с построения
концептуальной модели, где усилия концентрируются, прежде всего, на выявлении
важных для организации объектов и их связей. К полученной таким путем
реляционной схеме базы данных для проверки ее корректности применяется
процесс нормализации, но уже в упрощенном виде, поскольку, как правило, он уже
не приводит к перестройке отношений, так как в схеме реляционной базы данных
отсутствуют нежелательные зависимости между атрибутами отношений.
До широкого распространения и признания концептуальных моделей
традиционно использовался первый подход. Он все еще полезен в ситуациях, когда
требуется достаточно простая схема базы данных. Второй подход с
использованием концептуальных моделей имеет высокую ценность при
проектировании больших, сложных схем баз данных, необходимых для
корпоративных ИС.
В реляционных базах данных схема содержит как структурную, так и
семантическую информацию. Структурная информация связана с объявлением
отношений. Семантическая информация выражается множеством известных
функциональных зависимостей между атрибутами отношений, объявленными в
схеме. Присутствие в отношении функциональных зависимостей объясняется
разными причинами. Одни функциональные зависимости отражают взаимосвязи в
исследуемой предметной области, источник других же кроется в структуре
сформированных отношений. При неправильно сгруппированных отношениях
некоторые функциональные зависимости могут оказаться нежелательными из-за
побочных эффектов или аномалий, которые они вызывают при обновлении БД. В
связи с этим возникает вопрос о корректности представленной схемы. Корректной
считается схема, в которой отсутствуют нежелательные функциональные
зависимости между атрибутами.
59
Для приведения реляционной БД к корректному состоянию Кодд предложил
использовать разработанный им процесс нормализации, который представляет
собой метод создания набора отношений с заданными свойствами на основе
требований к данным, установленным в некоторой организации. Другими словами,
нормализация – это пошаговый, обратимый процесс замены данной схемы (или
совокупности отношений) другой схемой, в которой отношения имеют более
простую и регулярную структуру.
Процесс нормализации – это формальный метод анализа отношений на
основе их первичных или потенциальных ключей и существующих
функциональных зависимостей, являющийся одним из наиболее строгих способов
улучшения характеристик БД. Он включает ряд формальных правил, используемых
для проверки всех отношений БД.
Выделяют следующую последовательность нормальных форм:
– первая нормальная форма (1НФ);
– вторая нормальная форма (2НФ);
– третья нормальная форма (3НФ);
– нормальная форма Бойса-Кодда (НФБК);
– четвертая нормальная форма (4НФ);
– пятая нормальная форма, или нормальная форма проекции-соединения
(5НФ или НФПС)
Каждая нормальная форма более высокого порядка является более выгодной
с точки зрения реляционных БД, чем предыдущая. При этом необходимо заметить
тот факт, что если некоторая БД находится, скажем, во 2НФ, то не исключено, что
ее часть уже находится в 3НФ, внутри которой может находиться часть в НФБК и
т.д.
Основные свойства НФ:
– каждая следующая НФ в некотором смысле лучше предыдущей;
– при переходе к следующей НФ свойства предыдущих нормальных форм
сохраняются.
Рассмотрим последовательно 1,2,3 нормальные формы.
60
Отношение будет находиться в 1НФ при условии, что оно содержит только
логически неделимые значения. При этом необходимо заметить, что приведенное
определение говорит о нахождении любого нормализованного отношения в 1НФ. В
то же время отношение, находящееся только в 1НФ, обладает структурой не совсем
желательной, например, по причине ее возможной избыточности.
Отношение находится во 2НФ в том случае, когда оно уже считается
находящимся в 1НФ, и каждый неключевой атрибут полностью зависит от
первичного ключа.
Отношение находится в 3НФ в том случае, если оно находится во 2НФ,
неключевые атрибуты взаимно независимы и каждый неключевой атрибут
неприводимо зависит от первичного ключа
Логический уровень — это абстрактный взгляд на данные, которые
представляются так, как выглядят в реальном мире и могут называться так, как они
называются в реальном мире. Объекты модели на логическом уровне называются
сущностями и атрибутами. Логическая модель является универсальной и никак не
связана с конкретной СУБД, она может быть построена на основе другой
логической модели.
На данном этапе осуществим нормализацию таблиц.
База данных в первой нормальной форме:
Данные о технике:
– марка;
– модель;
– тип;
– пробег;
– год выпуска;
– ориентировочная стоимость;
– дата последней проверки.
Данные о пользователях (менеджеры и механики):
– фамилия;
– имя;
61
– отчество;
– роль в системе;
– логин;
– пароль.
Данные по заявкам на ремонт/обслуживание:
– идентификатор механика;
– идентификатор техники;
– ремонтируемый узел;
– дата начала;
– дата окончания;
– описание ремонта.
Данные по статусам:
– идентификатор заявки;
– идентификатор пользователя;
– текст статуса;
– дата статуса.
Отношение находится во 2НФ в том случае, когда оно уже считается
находящимся в 1НФ, и каждый неключевой атрибут полностью зависит от
первичного ключа. На рисунках 2.7-2.10 изображена преобразованная база данных
во 2 НФ.
Для хранения указанной выше информации были созданы следующие
таблицы базы данных.
62
Рисунок 2.7 Таблица Cars
Поле ID является первичным ключом, остальные поля информационные.
63
Рисунок 2.8 Таблица ServiceRepair
Поле ID является первичным ключом, RegTech – внешний ключ к таблице
Cars, IDTech – внешний ключ к таблице Users, остальные поля информационные.
Рисунок 2.9 Таблица RepairStatus
64
Поле ID является первичным ключом, IDRepair – внешний ключ к таблице
ServiceRepair, IDUser – внешний ключ к таблице Users, остальные поля
информационные.
Рисунок 2.10 Таблица Users
Поле ID является первичным ключом, остальные поля информационные.
В базе данных имеется тип множественной связи «один ко многим» (1:n):
– связь между сущностью «Cars» – «ServiceRepair», то есть один экземпляр
техники может быть несколько раз на ремонте или обслуживании;
– связь между сущностью «Users» – «ServiceRepair», то есть один механик
может выполнять несколько заявок на ремонт/обслуживание;
– связь между сущностью «ServiceRepair» – «RepairStatus», то есть у одной
заявки на ремонт/обслуживание может быть несколько статусов;
– связь между сущностью «Users» – «RepairStatus», то есть у один
пользователь может добавить несколько статусов к заявке на
ремонт/обслуживание.
ER–диаграмма, содержащая различные типы связей, приведена на рисунке
2.11. Обратите внимание, что обязательные связи выделены двойной линией.