Программные продукты и системы

Важной частью любой системы (в статье рассматривается экспертная система) является подсистема хранения данных. В зависимости от важности и оперативности доступа к данным, значимости самих данных, используемых алгоритмов и методов работы в системе выбираются различные способы организации хранения данных. Это могут быть простые текстовые файлы, представляющие наборы пар вида <имя параметра, значение>, а также структурированные файлы как в текстовом, так и в двоичном виде. Могут использоваться файлы с разметкой типа XML или JSON [1, 2]. Нередки случаи смешанного (гетерогенного) хранения данных, например, заголовки для данных хранятся в одном формате, а сами данные - в другом. Все это обусловливает необходимость наличия (разработки), помимо стандартного ПО для хранения и оперирования данными, специализированного ПО - конвертера, который может быть использован для преобразования данных из одного формата в другой.

Такая ситуация сложилась из-за отсутствия единых подходов к организации хранения данных [1]. Простой пример – метод хранения числовых последовательностей. Если используется БД, то можно хранить числовые последовательности в отдельных таблицах, на что будет расходоваться дополнительная память и создаваться нагрузка на ядро СУБД при работе с ними. Другим подходом является сохранение (запись) числовой последовательности в некоторый массив (строковый или бинарный) в отдельное поле БД. По мере дальнейшего развития технологии хранения данных наблюдается переход к форматам, простым в понимании и содержащим как сами данные, так и их разметку. Легкость понимания обеспечивается наличием разметки в файлах и соглашения о формате представления тех или иных типов данных (строковые, целые, вещественные, логические, дата и время и т.д.) [3–5].

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

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

Описание ПО аппарата медицинской диагностики Tomey

Медицинский аппарат Tomey является компьютеризированной полуавтоматической системой диагностики, предназначенной для биофизических исследований зрения. Он позволяет получить данные о потенциалах, возникающих в глазу при разных световых стимулах, в виде электроретинограмм (ЭРГ) - специальных кривых для оценки функционального состояния сетчатки, получаемых при регистрации биопотенциалов, возникающих в ней при световом раздражении [6, 7]. На основании данных ЭРГ специалист по физиологии зрения (Tomey используется в МНИИ глазных болезней им. Г. Гельмгольца) может делать вывод о наличии или отсутствии патологий зрения и стадии заболевания и давать рекомендации врачу-офтальмологу. ПО, поставляемое с Tomey, позволяет осуществлять исследования и хранить данные о них в БД с возможностью вывода графического представления результатов исследований. Пример представления ЭРГ приведен на рисунке 1, где а1 и а2 – амплитуда а-волны; b1 и b2 – амплитуда b-волны; D – длительность b-волны; L – латентный период; Tb – время кульминации; по оси абсцисс представлена длительность волн ЭРГ, по оси ординат – амплитуда волн. Каждый компонент ЭРГ гене- рируется различными структурами сетчатки.

Аппарат Tomey предоставляет пользователю ряд экранов-окон для анализа ЭРГ (см. http://www.swsys.ru/uploaded/image/2019-3/ 2019-3-dop/3.jpg, http://www.swsys.ru/uploaded/ image/2019-3/2019-3-dop/4.jpg).

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

В результате было решено разработать дополнительную БД для аппарата Tomey.

Описание БД аппарата Tomey

БД Paradox, поставляемая в составе ПО Tomey EP-1000, реализована на ядре Borland Database Engine версии 5.0.1, собственно СУБД написана на языке Delphi. Средства разработки и драйверы чтения для данной БД обновлялись в последний раз в 1996 г., после чего разработка и поддержка данного продукта были прекращены.

БД имеет всего две таблицы – Examins и Patients. На рисунке 2 приведена логическая схема сущностей БД, которой соответствуют таблицы в БД. Ключевой сущностью является пациент, для каждого экземпляра сущности пациента может быть несколько экземпляров сущности исследования. Ключевой атрибут – числовой атрибут PatNo, входящий в состав сущности пациента. Наиболее значимыми являются данные, хранящие непосредственно результаты исследования. Это бинарные объекты (BLOB), хранящиеся в полях PreviewData и CheckData таблицы Examins. Необходимо реа- лизовать ПО (конвертер) для корректного счи- тывания информации из всех полей, а для этого провести анализ двоичных данных, хранящихся в этих полях [8, 9].

Анализ двоичных данных

Файловая структура и архитектура БД Tomey достоверно неизвестны, поэтому будем исходить из предположения, что поля, хранящие двоичные данные об исследованиях, на самом деле не содержат эту информацию непосредственно, а ссылаются на некоторые внешние файлы или области внешних файлов. Действительно, в папке с БД есть два файла, имена которых соответствуют описанным выше таблицам: Examins.db и Patients.db. Файлы имеют значительный размер, поэтому будем считать, что они представляют информацию из полей таблицы.

Известно, что бинарные поля включены в состав сущности Examins, поэтому рассмотрим именно этот файл в побайтовом виде. Будем исходить из предположения, что файл разделен на записи, число которых равно числу исследований в БД. Известно, что БД с тестовым набором данных содержит 3 934 записи об исследованиях. Для анализа файла используем редактор файлов 010 Editor.

Просматривая файл, можно заметить, что он заполнен информацией неравномерно: пу- стые участки чередуются с участками, содержащими некоторую информацию. Предположим, что информативные участки и являются записями, хранящими данные об исследованиях. Поскольку считаем, что файл состоит из записей, выделим для всех информативных участков некоторую последовательность байтов, которая может быть заголовком для всех записей об исследованиях. В результате поиска (см. http://www.swsys.ru/uploaded/image/2019-3/2019-3-dop/5.jpg) удается найти последовательность 0C 51 AB 67 03 00 02 00 и определить число вхождений данной последовательности в файл. Число вхождений соответствует количеству записей об исследованиях в БД (3 934). Поскольку данная последовательность находится в начале каждой записи, будем считать ее заголовочной. Далее проанализируем байты, расположенные между найденными заголовками, то есть байты, образующие запись.

Будем исходить из предположения, что данные внутри каждой записи также упорядочены и структурированы, а результаты исследования хранятся в виде последовательностей дробных значений, то есть в виде float-значений. Удалось найти некоторый набор байтов, который делит запись на участки 0C 51 AB 67, а так как значение типа float представляется четырьмя байтами, то это последовательности из четверок байтов. Заметим, что найденный набор не всегда относится к участкам записи, содержащим данные исследования. Поскольку результатом исследования является хорошо детализированный график, количество точек в нем велико, поэтому нас интересуют длинные промежутки между найденными наборами. Удалось найти еще несколько наборов байтов, наличие которых характерно для промежутков большой длины. Это наборы 0C 00 00 00 и 0D 00 00 00. При дальнейшем анализе найденных участков, содержащих последовательности дробных значений, удалось обнаружить, что следующие четыре байта после найденных наборов хранят целое число, отражающее количество идущих за ним дробных значений. В результате получена полная картина структуры бинарного файла, хранящего результаты исследований (рис. 3).

В итоге получен формат хранения бинарных данных результатов исследований, который может быть использован при реализации конвертера. Стоит отметить, что на данных в БД Tomey не было никакой дополнительной защиты, что упростило анализ [10].

Программная реализация конвертера

Реализованное в виде конвертера ПО позволяет устанавливать подключение к БД Tomey и считывать всю информацию как с полей таблиц БД, так и из бинарного файла, структура которого была рассмотрена ранее. Имеется также возможность просмотра считанной информации. Весь основной функционал конвертера реализован в главном окне, изображенном на рисунке 4. Использованы такие опции, как выпадающее меню, контекстное меню, кнопки и радио-группы.

Главное окно включает три основных блока:

-     таблица с перечнем исследований;

-     блок с просмотром графика исследования и подробными сведениями об исследовании;

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

В главном окне имеется возможность просмотра сведений о пациенте, к которому относится текущее исследование. Для этого необходимо нажать на кнопку Show patient info.

Разработано также меню экспорта для передачи результатов в формате СSV в другие программы, в которых возможно проведение интеллектуального анализа и диагностики с применением методов искусственного интеллекта, в частности, на основе байесовских сетей доверия и нейронных сетей.

Заключение

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

Работа выполнена при финансовой поддержке РФФИ (проекты №№ 17-07-00553 а, 18-01-00201 а, 18-51-00007 Бел а, 18-29-03088 МК).

Литература

1.    Cleve A., Gobert M., Meurice L., Maes J., Weber J.H. Understanding database schema evolution: a case study. Sci Comput Program 97, 2015, no. P1, pp. 113–121. DOI: 10.1016/j.scico.2013.11.025.

2.    Ma Z., Zhao Z., Yan L. Heterogeneous fuzzy XML data integration based on structural and semantic similarities. Fuzzy Sets and Systems, 2018, vol. 351, pp. 64–89.

3.    Vinoth P. and Sankar P. Encoding of coordination complexes with XML. J. Mol. Graphics Modell., 2017, vol. 76, pp. 242–259. DOI: http://dx.doi.org/10.1016/j.jmgm.2017.07.009.

4.    Eito-Brun R. Chapter 4 – Databases for XML Data. XML-based Content Management. Chandos Publishing, 2018, pp 117–153. DOI: 10.1016/b978-0-08-100204-9.00004-4.

5.    Mata C., Oliver A., Lalande A., Walker P., Martí J. On the use of XML in medical imaging web-based applications. IRBM, 2017, vol. 38, pp. 3–12. DOI: 10.1016/j.irbm.2016.10.001.

6.    Eremeev A., Khasiev R., Tcapenko I., Zueva M. The intelligent decision support system for diagnos­tics of difficult diseases of vision. IJ ICP, 2014, vol. 1, no. 3, pp. 269–279.

7.    Еремеев А.П., Ивлиев С.А. Построение онтологии на основе нереляционной базы данных для интеллектуальной системы поддержки принятия решений медицинского назначения // Программные продукты и системы. 2017. № 4. С. 5–14. DOI: 10.15827/0236-235X.030.4.005-014.

8.    Панов А.С. Реверсинг и защита программ от взлома. СПб: БХВ-Петербург, 2006. 256 с.

9.    Хогланд Г., Мак-Гроу Г. Взлом программного обеспечения: анализ и использование кода; [пер. с англ.]. М.: Вильямс, 2005. 400 с.

10. Altheide C., Carvey H. Chapter 8 – Digital Forensics with Open Source Tools. File Analysis, 2011, pp. 169–210. DOI: 10.1016/B978-1-59749-586-8.00001-7.

References

1. Cleve A., Gobert M., Meurice L., Maes J., Weber J.H. Understanding database schema evolution: a case study. Sci. Comput. Program. 2015, no. 97, pp. 113–121. DOI: 10.1016/j.scico.2013.11.025.
2. Ma Z., Zhao Z., Yan L. Heterogeneous fuzzy XML data integration based on structural and semantic similarities. Fuzzy Sets and Systems. 2018, vol. 351, pp. 64–89.
3. Vinoth P., Sankar P. Encoding of coordination complexes with XML. J. Mol. Graphics Modell. 2017, no. 76, pp. 242–259. DOI: http://dx.doi.org/10.1016/j.jmgm.2017.07.009.
4. Eito-Brun R. Ch. 4 – Databases for XML Data, XML-based Content Management. Chandos Publ., 2018, pp. 117–153. DOI:10.1016/b978-0-08-100204-9.00004-4.
5. Mata C., Olivera A., Lalande A., Walker P., Martía J. On the use of xml in medical imaging web-based applications. IRBM. 2017, vol. 38, iss. 1, pp. 3–12. DOI: 10.1016/j.irbm.2016.10.001.
6. Eremeev A., Khasiev R., Tcapenko I., Zueva M. The intelligent decision support system for diagnostics of difficult diseases of vision. Information Cоntent & Processing. 2014, vol. 1, no. 3, pp. 269–279.
7. Eremeev A.P., Ivliev S.A. Ontology design based on non-relational database for intelligent decision support system for medical purposes. Software & Systems. 2017, no. 4, pp. 5–14. DOI: 10.15827/0236-235X.
   030.4.005-014.
8. Panov A.S. Reversing and Protecting Programs from Hacking. St. Petersburg, BHV-Peterburg Publ., 2006, 256 p.
9. Hoglund G., McGraw G. Exploiting Software: How to Break Code. Addison-Wesley Publ., 2004,
   512 p. (Russ. ed.: Moscow, Vilyams Publ., 2005, 400 p.).
10. Altheide C., Carvey H. Ch. 8 – File Analysis, Digital Forensics with Open Source Tools. 2011,
    pp. 169–210. DOI: 10.1016/B978-1-59749-586-8.00001-7.