2.2.5.2 Реализация ограничений целостности бд

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

Целостность таблицы. Обязательно должны поддерживаться:

- уникальность строк таблицы. Должен быть определен первичный ключ таблицы, и значение его должно быть определено;

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

Эти ограничения реализуются в командах создания и модификации таблиц. Например, в языке SQL это команды Create Table, Alter Table. В этих командах для описания полей – первичных ключей используется конструкция Primary Key, для описания полей – уникальных ключей конструкция Unique, обязательность значений полей задается конструкцией Not Null.

Ссылочная целостность. Каждая таблица проектируемой БД должна быть связана с другими посредством соответствующих первичных и внешних ключей. Назначение внешнего ключа – связывать каждую строку дочерней таблицы с соответствующей строкой родительской таблицы. Значение внешнего ключа может иметь и пустое значение (Null), если он реализует необязательную связь, выявленную в предметной области. В качестве значения внешнего ключа может выступать значение и любого уникального (потенциального) ключа [22].

Декларативные ограничения данных. Так называют ограничения реляционной базы данных, объявленные предметной областью и выявленные в ходе её анализа. Задача проектировщика БД – адекватно отобразить их в БД.

Самые распространенные ограничения предметной области – это ограничения на свойства объекта предметной области, далее атрибута отношения или поля таблицы:

- обязательность значения поля;

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

Такие ограничения могут быть заданы в командах создания и модификации таблиц – Create Table, Alter Table при описании поля таблицы.

Ниже рассмотрена реализация ограничений целостности БД на примере таблица «Status»:

CREATE TABLE "Status"

(

idstatus integer NOT NULL,

statusname character varying(15) NOT NULL,

CONSTRAINT "PK_Справочник_статусов" PRIMARY KEY (idstatus)

)

WITH (

OIDS=FALSE

);

ALTER TABLE "Status" OWNER TO postgres;

Такие записи как NOT NULL, character varying(15) обеспечивают поддержку ограничений предметной области, запись PRIMARY KEY (idstatus)обеспечивают поддержку ограничений первичного ключа.

Реализация ограничений целостности БД аналогична для остальных таблиц.

2.3 Разработка программного средства автоматизации обслуживания заявок

Разработка велась согласно следующей модели жизненного цикла [23], представленной на рисунке 2.4.

Рисунок 2.4 – Поэтапная модель жизненного цикла

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

В ходе беседы с пользователями и сотрудниками ОИТ были определены следующие функции программы:

- подача и принятие заявок на обслуживание и установку компьютерной оргтехники;

- осуществление контроля над исполнением заявок;

- генерирование отчетов.

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

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

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

Создание диаграммы вариантов использования имеет следующие цели:

- определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы;

- сформулировать общие требования к функциональному поведению проектируемой системы;

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

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

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

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

На диаграмме изображено два актера:

- администратор;

- пользователь.

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

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

- просмотреть свои заявки. Данный вариант использования позволяет пользователю просматривать свои заявки, поданные ранее;

- просмотреть текущие заявки. Этот вариант использования подразумевает просмотр имеющихся заявок администратором БД, при желании он может их удалять и менять их статус;

- подать новую заявку. Этот вариант использования позволяет пользователю подавать новые заявки;

Готовая диаграмма вариантов использования изображена на рисунке 2.5.

Рисунок 2.5 – Диаграмма вариантов использования

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

Поведение проектируемого программного средства описывается следующими состояниями. Авторизация/регистрация – состояние, которое в свою очередь делится на два состояния: ввод данных для регестрации и ввод данных для авторизации. При успешной авторизации возможны следующие состояния: для актера «администратор»: просмотр данных о правах пользователей, подача новой заявки, просмотр текущих заявок; для актера «пользователь»: подача новой заявки, просмотр текущих заявок.

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

Рисунок 2.6 – Диаграмма состояний

Приступая к этапу реализации программного средства, следует помнить, что оно является большой программной системой, поэтому целесообразно принять меры для его упрощения, разделив весь процесс на отдельные модули [26]. Такое разбиение позволит:

а) упростить их разработку и реализацию;

б) облегчить чтение программы;

в) упростить настройку и модификацию;

г) облегчить работу с данными, имеющими сложную структуру;

д) избежать чрезмерной детализации алгоритмов;

е) обеспечить более выгодное размещение программ в памяти ЭВМ.

Модуль — фрагмент программного текста, являющийся строительным блоком для физической структуры системы. Как правило, модуль состоит из интерфейсной части и части-реализации [27].

Модульная структура разрабатываемого автоматизированного средства по обслуживанию заявок отображена на рисунке 2.7.

Рисунке 2.7 – Модульная структура автоматизированного средства

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

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

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

Модули доступа к таблицам БД выполняют соединение с базой данных и выборку полей из соответствующих таблиц.

Модуль добавления заявки в БД выполняет соединение с базой данных и обновление полей таблицы заявок.

Модуль создания интерфейса для просмотра текущих заявок осуществляет вывод данных из таблицы заявок БД в форму просмотра.

Листинг данных модулей представлен в приложении Б.

На этапе тестирования было сделано следующее: на одном из компьютеров ОИТ был установлен сервер приложений Tomcat и развернута созданная база данных. Далее на этот же компьютер было установлено спроектированное программное средство. После чего пользователем была отправлена заявка на установку проектора (мультимедиа оборудование). Она прошла успешную обработку и в последующем удалена из БД. Необходимо отметить, что процесс обработки заявки в очереди проводился при 100% загрузке пользователями базы данных. Все испытания прошли успешно, недостатков и ошибок не было выявлено.

Во втором разделе проведена следующая работа:

- представлено обоснование выбора и описание инструментальных средств: языка программирования, СУБД, языка запросов;

- представлено описание принципов работы Java web-приложения;

- проанализирована архитектура АСУОД Tandem, функционирующая в Филиале;

- разработана БД проектируемого средства;

- разработано программное средство автоматизации обслуживания заявок пользователей ЛВС Филиала.