Материал: Компьютеризированная система комплексной оценки функционального и психофизического состояния человека

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам

2.5 Концептуальное проектирование


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

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

.5.1 Определение исходных отношений

Связь между отношениями "Пациент" и "Организации" - "многие к одному". Сформировано три отношения - по одному на каждую сущность и одно отношение связи:

-    "Пациент" (Идентификатор пациента, Фамилия, Имя, Отчество, Пол, Дата рождения);

-  "Организации" (Идентификатор организации, Идентификатор родителя, Уровень иерархии, Название);

-  "Пациенты-Организации" (Идентификатор пациента, Идентификатор организации).

Связь между отношениями "Тесты" и "Заключения" - "один ко многим", поэтому сформировано три отношения - по одному на каждую сущность и одно отношение связи:

-    "Тесты" (Идентификатор теста, Наименование теста);

-  "Заключения" (Идентификатор заключения, Наименование заключения);

-  "Тесты-Заключения" (Идентификатор теста, Идентификатор заключения).

Связь между отношениями "Пациент", "Дата проведения теста", "Данные результатов теста" и "Тесты" - "один к одному", поэтому сформировано пять отношений - по одному на каждую сущность и одно отношение связи:

-    "Пациент" (Идентификатор пациента, Фамилия, Имя, Отчество, Пол, Дата рождения);

-    "Тесты" (Идентификатор теста, Наименование теста);

-  "Дата тестирования" (Идентификатор даты, Дата);

-  "Данные результатов теста" (Идентификатор результата, Значение);

-  "Результаты теста" (Идентификатор пациента, Идентификатор теста, Идентификатор даты, Идентификатор результата).

Также ключевой атрибут "Идентификатор заключения" отношения "Заключения" включен в качестве неключевого атрибута в отношение "Данные результатов теста".

.5.2 Описание функциональных зависимостей

Определим все имеющиеся функциональные зависимости. Полные функциональные зависимости отношения "Пациент":

-    Идентификатор пациента→ Фамилия;

-  Идентификатор пациента → Имя;

-  Идентификатор пациента → Отчество;

-  Идентификатор пациента → Пол;

-  Идентификатор пациента → Дата рождения.

Полные функциональные зависимости отношения "Организации":

-    Идентификатор организации → Название организации;

-  Идентификатор организации → Принадлежность.

Полные функциональные зависимости отношения "Тесты":

-    Идентификатор теста → Название теста;

Полные функциональные зависимости отношения "Дата тестирвания":

-    Идентификатор даты → Дата;

Полные функциональные зависимости отношения "Заключения":

-    Идентификатор заключения → Заключение;

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

Для проектирования базы данных было использовано CASE-средство Erwin, которое сочетает графический интерфейс Windows, инструменты для построения ER-диаграмм, редакторы для создания логического и физического описания модели данных и прозрачную поддержку ведущих реляционных СУБД.

ERwin не привязан к технологии какой-либо конкретной фирмы, поставляющей СУБД или средства разработки. Он поддерживает различные серверы баз данных и настольные СУБД, а также может обращаться к базе данных через интерфейс ODBC.

Построенная модель данных была проверена в Erwin Validator на наличие ошибок. В Erwin Validator есть средство ERWin Examiner. С помощью него можно анализировать структуру баз данных с целью выявления недочетов и ошибок проектирования. Ошибки подразделяют на 4 категории:

-    ошибки проектирования доменов;

-  ошибки индексов и ограничений;

-  ошибки нормализации (приведения к 3НФ);

-  ошибки связей;

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

.5.4 Концептуальная модель данных

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

Рисунок 2.3 - Концептуальная модель данных

2.5.5 Концептуальная модель транзакций

Транзакция - действие или серия действий, выполняемых пользователем или прикладной программой как единое целое. Транзакции осуществляют доступ к содержимому базы данных или его изменение. Транзакция автоматически начинается с выполнения пользователем и программой первой инструкции SQL [8].

Формальное описание (алгоритмы) запросов представляют собой концептуальную модель транзакций. Часть данных алгоритмов приведена ниже.

-    Формирование списка результатов тестирования по группе.

 (2.1)

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

(2.2)

-    Получение полной информации о пациентах.

 (2.3)

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

(2.4)

2.5.6 Разработка алгоритмов контроля целостности и согласованности базы данных

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

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

-  Задание шаблонов ввода, позволяет задать вид информации. При несоответствии вида, вводимой информации, заданной маске, формируется сообщение об ошибке.

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

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

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

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

.6 Логическое проектирование


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

2.6.1 Логическая модель данных

Логическая модель данных представляет собой описание инфологической модели данных в терминах конкретной СУБД. Для реализации базы данных выбрана СУБД MySQL. Преобразуем концептуальную модель в логическую, задав типы данных этой СУБД (рис. 2.4)

Рисунок 2.4 - Логическая модель данных

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


Хранимая процедура - объект базы данных, представляющий собой набор SQL-инструкций, который компилируется один раз и хранится на сервере. Хранимые процедуры позволяют повысить производительность, расширяют возможности программирования и поддерживают функции безопасности данных. Вместо хранения часто используемого запроса, клиенты могут ссылаться на соответствующую хранимую процедуру. При вызове хранимой процедуры её содержимое сразу же обрабатывается сервером [11].

В большинстве СУБД при первом запуске хранимой процедуры она компилируется (выполняется синтаксический анализ и генерируется план доступа к данным). В дальнейшем её обработка осуществляется быстрее.

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

Таблица 2.8 - Хранимые процедуры

Наименование хранимой процедуры

Назначение

1

test_vuz

Получение результатов тестирования по ВУЗу для выбранного теста

2

test_inst

Получение результатов тестирования по институту для выбранного теста

3

test_group

Получение результатов тестирования по группе для выбранного теста

4

date_ test_vuz

Получение результатов тестирования по ВУЗу для выбранного теста с группировкой по дате тестирования

5

date_ test_inst

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

6

date_ test_group

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

7

info_patient

Получение полной информации о пациентах

8

sGender_Birth

Получение результатов тестирования по группе для выбранного теста с группировкой по полу и/или возрасту


2.7.1 Физическая реализация базы данных

Физическая реализация базы данных осуществлена с помощью утилиты MySQL WorkBench.

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

Производителем СУБД определена структура базы данных в виде отдельных файлов. Каждый файл соответствует таблице базы данных. Таким образом, размер таблицы ограничен предельным размером файла в используемой файловой системе.

.8 Проектирование программного обеспечения


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

.8.1 Проектирование структуры программного обеспечения

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

Проектируемая система для мониторинга психофизиологического состояния человека подразделяется на несколько подсистем:

-  подсистема взаимодействия с базой данных;

- подсистема визуализации;

- подсистема генерации отчётов.

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

-  соединение приложения с базой данных;

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

-  передача данных в подсистему визуализации;

-  обработка исключительных ситуаций;

Подсистема визуализации включает в себя следующие функции:

-  настройка визуализации;

- представление результатов в виде диаграмм;

- формирование структуры организаций в виде древовидного списка;

Подсистема генерации отчетов выполняет следующие функции:

-  выбор параметров отчёта (данные о группе, данные о тесте);

- выбор критерия группировки: по ВУЗу, по институту, по группе, по дате тестирования, по полу, по возрасту;

- обработка исключительных ситуаций;

- экспорт отчёта в MS Excel.

Объединяя все структурные схемы в одну, получаем одну общую структурную схему для проектируемой системы мониторинга психофизиологического состояния человека (стр. 51).

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

2.8.2 Разработка функциональной схемы

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

-  подсистема взаимодействия с БД;

- подсистема визуализации;

- подсистема генерации отчётов.

Ниже приведена функциональная схема (стр. 53), а также описание для каждой из подсистем.

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

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

.   Подсистема генерации отчетов получает от врача или научного сотрудника параметры генерации отчетов, а от системы соединения с базой данных результаты вычислений. Сформированный отчёт, в последствии, экспортируется в MS Excel.

2.8.3 Модульное описание программного обеспечения

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

Проектируемая система для мониторинга психофизиологического состояния человека разделяется на несколько модулей:

-  модуль взаимодействия с базой данных;