 |
Проектирование базы данных
|
|
|
|
Системы, имеющие архитектуру «клиент-сервер», строятся на основе реляционных баз данных. Качество таких информационных систем зависит от того, насколько успешно спроектирована база данных.
В основу проектирования БД должны быть положены представления конечных пользователей конкретной организации – концептуальные требования к системе. Именно конечный пользователь в своей работе принимает решения с учетом получаемой в результате доступа к базе данных информации. От оперативности и качества этой информации будет зависеть эффективность работы организации. Данные, помещаемые в базу данных, также предоставляет конечный пользователь.
Разработка концептуальной модели данных была осуществлена с использованием Case-средства Erwin 4.0. Данное программное средство использовалось в связи с тем, что Rational Rose Enterprise Edition 2002 не поддерживает взаимосвязи с Microsoft SQL Server 2005.
Разработка модели базы данных состоит из двух этапов:
- создание логической модели;
- создание физической модели.
ERWin – мощное и простое в использовании средство проектирования баз данных, завоевавшее широкое признание и популярность. На протяжении всего процесса моделирования ERWin позволяет наглядно отобразить структуру и основные элементы базы данных. Он оптимизирует модель в соответствии с физическими характеристиками целевой базы данных. В отличие от других инструментальных средств ERWin автоматически поддерживает согласованность логической и физической схем и осуществляет преобразование логических конструкций.
Логический уровень – это абстрактный взгляд на данные, на этом уровне данные представляются так же, как выглядят в реальном мире. Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами. Логический уровень модели данных является универсальным и никак не связан с конкретной реализацией СУБД. При проектировании базы данных было создано несколько таблиц для хранения используемой в системе информации.
|
|
|
Логическое представление модели данных, описывающее проведение лабораторных исследований реализовано на предыдущих этапах разработки ЛИС. В ходе реализации проекта были определены дополнительные сущности, необходимые для сохранения в базе данных информации о проведенных гематологических исследованиях.
Для описания гематологических исследований такими сущностями являются: «Лейкоформула», «Тромбоциты», «Миелограмма», «Ед. измерения», «Показатели числовые». Доработанная логическая модель данных системы лабораторных исследований представлена на рисунке 2.4.
Рисунок 2.4 – Логическая модель данных
Внесенные изменения в структуру БД Laboratory, реализованную в MS SQL Server 2005 представлены на рисунке 2.5.
Рисунок 2.6 – Структура данных подсистемы учета гематологических анализов
Обоснование выбора платформы создания информационной системы
Платформой для создания программного продукта по учету гематологических анализов является Visual Studio 2005. Приложение реализуется на языке C++. Этот выбор обусловлен тем, что существующая версия ПО и все подключаемые модули системы реализованы на C++ для Visual Studio 2005 [39]. В качестве базовой библиотеки классов для основного управляющего компонента ПО используется библиотека MFC, обеспечивающая реализацию архитектуры Document/View. Настройка данной библиотеки под шаблон реализации комплекса реализованы в используемой динамически подключаемой библиотеке MFC_Lab.dll. Эта библиотека обеспечивает реализацию программного интерфейса взаимодействия с компонентами прорисовки графиков в основном окне управляющего компонента, а также интерфейсы межпрограммного взаимодействия.
|
|
|
Проектирование модулей
Основная задача проектирования заключается в том, чтобы превратить модели анализа в документы детализированного проектирования, на основе которых реализуется система. Логическая модель проектируемой подсистемы строится на основе технологии Rational [30], используя основные объектно-ориентированные подходы языка UML [33, 34].
Начальный этап проектирования подсистемы учета гематологических анализов, как указывалось, связан с разработкой основных ActiveX-элементов, обеспечивающих ввод и модификацию основных сущностей предметной области разрабатываемой подсистемы. Разработка логической модели системы этих компонентов обеспечивает в дальнейшем возможность эффективного построения ряда систем, связанных с ведением учета гематологических анализов и, таким образом, может рассматриваться как этап проектирования горизонтальной предметной области [16].
Основными функциями, реализуемыми над этими сущностями, являются функции ввода нового элемента, удаления и модификации существующих элементов.
Каждый ActiveX-элемент с одной стороны является сервером для модуля, осуществляющего управление вызовами используемых элементов. С другой стороны данные элементы являются клиентами, осуществляющими запросы соответствующих данных из хранилища и их модификацию. Взаимодействие ActiveX-элементов с СУБД, как указывалось, осуществляется с использованием технологии OLE DB.
Для реализации функциональности сервера, взаимодействующего с клиентом, реализованном на произвольном языке программирования, данные элементы наследуются от интерфейса IDispatch. Для взаимодействия с сервером БД используются модуль стандартной динамической библиотеки stdole.dll. Диаграмма классов данного модуля, обеспечивающего функциональность COM, представлена на рисунке 2.7.
Рисунок 2.7 – Диаграмма классов, модулем гематологического счетчика
Выводы к разделу
Во втором разделе выполнено проектирование подсистемы учета гематологических анализов для КДЛ.
На данном этапе были построены модели логического и физического представления подсистемы. Разработана база данных подсистемы.
Разработано логическое представление основных компонентов подсистемы как независимых ActiveX-компонентов, реализующих функциональность основных понятий предметной области.
|
|
|
