Концептуальное проектирование имеет целью создания обобщенной точки зрения на информационную систему всех категорий пользователей.
Концептуальная модель информационной системы понимается как формализованное описание элементов данных, их семантических связей и организационной структуры с указанием ограничений целостности и согласованности данных, а также соответствующих алгоритмов контроля. Кроме того, концептуальная модель должна быть ясной, однозначно и просто понимаемой, легко трансформируемой при изменении требований или появлении новых приложений [11].
Связь между отношениями "Пациент" и "Организации" - "многие к одному". Сформировано три отношения - по одному на каждую сущность и одно отношение связи:
- "Пациент" (Идентификатор пациента, Фамилия, Имя, Отчество, Пол, Дата рождения);
- "Организации" (Идентификатор организации, Идентификатор родителя, Уровень иерархии, Название);
- "Пациенты-Организации" (Идентификатор пациента, Идентификатор организации).
Связь между отношениями "Тесты" и "Заключения" - "один ко многим", поэтому сформировано три отношения - по одному на каждую сущность и одно отношение связи:
- "Тесты" (Идентификатор теста, Наименование теста);
- "Заключения" (Идентификатор заключения, Наименование заключения);
- "Тесты-Заключения" (Идентификатор теста, Идентификатор заключения).
Связь между отношениями "Пациент", "Дата проведения теста", "Данные результатов теста" и "Тесты" - "один к одному", поэтому сформировано пять отношений - по одному на каждую сущность и одно отношение связи:
- "Пациент" (Идентификатор пациента, Фамилия, Имя, Отчество, Пол, Дата рождения);
- "Тесты" (Идентификатор теста, Наименование теста);
- "Дата тестирования" (Идентификатор даты, Дата);
- "Данные результатов теста" (Идентификатор результата, Значение);
- "Результаты теста" (Идентификатор пациента, Идентификатор теста, Идентификатор даты, Идентификатор результата).
Также ключевой атрибут "Идентификатор заключения" отношения "Заключения" включен в качестве неключевого атрибута в отношение "Данные результатов теста".
Определим все имеющиеся функциональные зависимости. Полные функциональные зависимости отношения "Пациент":
- Идентификатор пациента→ Фамилия;
- Идентификатор пациента → Имя;
- Идентификатор пациента → Отчество;
- Идентификатор пациента → Пол;
- Идентификатор пациента → Дата рождения.
Полные функциональные зависимости отношения "Организации":
- Идентификатор организации → Название организации;
- Идентификатор организации → Принадлежность.
Полные функциональные зависимости отношения "Тесты":
- Идентификатор теста → Название теста;
Полные функциональные зависимости отношения "Дата тестирвания":
- Идентификатор даты → Дата;
Полные функциональные зависимости отношения "Заключения":
- Идентификатор заключения → Заключение;
Процесс преобразования отношений базы данных к виду, отвечающему нормальным формам, называется нормализацией. Нормализация предназначена для приведения структуры БД к виду, обеспечивающему минимальную логическую избыточность, и не имеет целью уменьшение или увеличение производительности работы или же уменьшение или увеличение физического объёма базы данных [11].
Для проектирования базы данных было использовано CASE-средство Erwin, которое сочетает графический интерфейс Windows, инструменты для построения ER-диаграмм, редакторы для создания логического и физического описания модели данных и прозрачную поддержку ведущих реляционных СУБД.
ERwin не привязан к технологии какой-либо конкретной фирмы, поставляющей СУБД или средства разработки. Он поддерживает различные серверы баз данных и настольные СУБД, а также может обращаться к базе данных через интерфейс ODBC.
Построенная модель данных была проверена в Erwin Validator на наличие ошибок. В Erwin Validator есть средство ERWin Examiner. С помощью него можно анализировать структуру баз данных с целью выявления недочетов и ошибок проектирования. Ошибки подразделяют на 4 категории:
- ошибки проектирования доменов;
- ошибки индексов и ограничений;
- ошибки нормализации (приведения к 3НФ);
- ошибки связей;
В результате проведения анализа базы данных ошибок нормализации не выявлено, следовательно полученные отношения находятся в третьей нормальной форме.
Логическую связь полученных отношений поясняет концептуальная модель базы
данных, изображенная на рис. 2.3.
Рисунок 2.3 - Концептуальная модель данных
2.5.5 Концептуальная модель транзакций
Транзакция - действие или серия действий, выполняемых пользователем или прикладной программой как единое целое. Транзакции осуществляют доступ к содержимому базы данных или его изменение. Транзакция автоматически начинается с выполнения пользователем и программой первой инструкции SQL [8].
Формальное описание (алгоритмы) запросов представляют собой концептуальную модель транзакций. Часть данных алгоритмов приведена ниже.
- Формирование списка результатов тестирования по группе.
(2.1)
- Формирование списка результатов тестирования по группе с группировкой по
дате тестирования.
(2.2)
- Получение полной информации о пациентах.
(2.3)
- Формирование списка результатов тестирования по группе для выбранного
теста, с группировкой по полу и/или возрасту.
(2.4)
Для обеспечения целостности и согласованности реализованы следующие методы:
- Задание типов данных, позволяющее избежать ввода значений неверного типа. Например, при определении даты рождения задание символа, приведет к возникновению сообщения об ошибке;
- Задание шаблонов ввода, позволяет задать вид информации. При несоответствии вида, вводимой информации, заданной маске, формируется сообщение об ошибке.
- Организация ссылочной целостности, позволяет организовать необходимую логическую связь таблиц. При этом поля, по которым устанавливается связь, должны иметь одинаковый тип. Ссылочная целостность позволяет вводить в поле таблицы только те значения, которые содержатся в соответствующем поле связанной с ней таблицы. Например, пациент не может пройти тест, который не содержится в списке предлагаемых тестов. Также ссылочная целостность позволяет при удалении или изменении записей в родительских таблицах, удалять или изменять записи и в дочерних таблицах соответственно.
- При вводе значений в поле одной таблицы из списка значений поля другой таблицы используется не ручной ввод с клавиатуры, а выбор значений из выпадающего списка, связанного с соответствующими полями таблиц. Например, при заполнении таблицы, содержащей сведения о пациентах для указания организации используется связь с таблицей "Организации", из которой выбираются значения идентификатора организации.
- При вводе значений, которые должны входить в заранее определенный перечень (например, пол - мужской или женский) используется не ручной ввод этих значений их с клавиатуры, а выбор из выпадающего списка.
- При удалении записей запрашивается подтверждение, что исключает непреднамеренное удаление информации из базы данных.
Логическое проектирование состоит из двух взаимосвязанных процессов:
проектирования логической модели БД (переформулирование концептуальной модели в
терминах конкретной СУБД) и проектирование программ обработки данных. В
результате этого этапа разрабатывается логическая схема данных и
структурированное описание обрабатывающих программ в терминах языковых средств
конкретной системы [11].
Логическая модель данных представляет собой описание инфологической
модели данных в терминах конкретной СУБД. Для реализации базы данных выбрана
СУБД MySQL. Преобразуем концептуальную модель в
логическую, задав типы данных этой СУБД (рис. 2.4)
Рисунок 2.4 - Логическая модель данных
Хранимая процедура - объект базы данных, представляющий собой набор 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 |
Получение результатов тестирования по группе для выбранного теста с группировкой по полу и/или возрасту |
Физическая реализация базы данных осуществлена с помощью утилиты MySQL WorkBench.
Полученные на этапе концептуального проектирования отношения являются таблицами базы данных.
Производителем СУБД определена структура базы данных в виде отдельных файлов. Каждый файл соответствует таблице базы данных. Таким образом, размер таблицы ограничен предельным размером файла в используемой файловой системе.
Процесс проектирования программного обеспечения начинается с уточнения его структуры, т. е. определения структурных компонентов и связей между ними. Результат уточнения структуры представлен в виде описания (спецификаций) компонентов.
Структура отражает состав и взаимодействие частей разрабатываемого программного обеспечения.
Проектируемая система для мониторинга психофизиологического состояния человека подразделяется на несколько подсистем:
- подсистема взаимодействия с базой данных;
- подсистема визуализации;
- подсистема генерации отчётов.
Подсистема взаимодействия с базой данных выполняет следующие функции:
- соединение приложения с базой данных;
- получение численных результатов и их группировка по выбранному критерию;
- передача данных в подсистему визуализации;
- обработка исключительных ситуаций;
Подсистема визуализации включает в себя следующие функции:
- настройка визуализации;
- представление результатов в виде диаграмм;
- формирование структуры организаций в виде древовидного списка;
Подсистема генерации отчетов выполняет следующие функции:
- выбор параметров отчёта (данные о группе, данные о тесте);
- выбор критерия группировки: по ВУЗу, по институту, по группе, по дате тестирования, по полу, по возрасту;
- обработка исключительных ситуаций;
- экспорт отчёта в MS Excel.
Объединяя все структурные схемы в одну, получаем одну общую структурную схему для проектируемой системы мониторинга психофизиологического состояния человека (стр. 51).
Более полное представление о проектируемом программном обеспечении с
точки зрения взаимодействия его компонентов между собой и с внешней средой дает
функциональная схема.
Функциональная схема - это схема взаимодействия компонентов программного обеспечения. Функциональная схема верхнего уровня соответствует структурной схеме верхнего уровня, т.е. система разбивается на три подсистемы:
- подсистема взаимодействия с БД;
- подсистема визуализации;
- подсистема генерации отчётов.
Ниже приведена функциональная схема (стр. 53), а также описание для каждой из подсистем.
. Подсистема взаимодействия с БД получает информацию из таблиц базы данных путем запроса, проводит их проверку и передает в подсистему визуализации.
2. В ходе выполнения запросов к БД результаты записываются в оперативную память для их дальнейшей обработки подсистемой визуализации и подсистемой генерацией отчетов, а также, при необходимости, отображаются в табличном виде.
. Подсистема генерации отчетов получает от врача или научного
сотрудника параметры генерации отчетов, а от системы соединения с базой данных
результаты вычислений. Сформированный отчёт, в последствии, экспортируется в MS
Excel.
Модульное программирование предполагает выделение групп подпрограмм, использующих одни и те же глобальные данные в отдельно компилируемые модули, например, модуль графических ресурсов, модуль подпрограмм вывода на принтер. Связи между модулями при использовании данной технологии осуществляются через специальный интерфейс, в то время как доступ к реализации модуля (телам подпрограмм и некоторым "внутренним" переменным) запрещен [12].
Проектируемая система для мониторинга психофизиологического состояния человека разделяется на несколько модулей:
- модуль взаимодействия с базой данных;