CC BY
18
ОБЪЕКТНО-РЕЛЯЦИОННАЯ СУБД «DATA STRUCT DESIGNER»
Вейко Роман Владимирович, науч. сотр. ФГБНУ «Медико-генетический научный центр», Россия, Москва. E-mail: veikor@rambler.ru
Аннотация. В настоящее время одной из особенностей работы медико-биологических научных центров является то, что зачастую они работают с данными, которые получаются на основе результатов разнородных экспериментов. В этих условиях создание информационно аналитических систем на основе традиционных реляционных баз данных является достаточно трудоемки и не всегда оправданным подходом. Данная особенность определила актуальность решения задачи по созданию инструмента быстрой реализации небольших и легко расширяемых баз данных, которые будут позволять осуществлять автоматизированную выборку. Методологию исследований составило совмещение подходов, принятых в объектно-ориентированном проектировании и реляционных базах данных. Разработанная СУБД была протестирована на данных медицинских и генетических анализов биоматериалов людей, страдающих психическими заболеваниями в рамках текущей деятельности ФГБНУ «МПНЦ».
Ключевые слова: база данных, транслятор, объектно-ориентированный дизайн, реляционные базы.
OBJECT-RELATIONAL DATABASE MANAGEMENT SYSTEM «DATA STRUCT DESIGNER»
Veiko Roman V., researcher of Research Centre for Medical Genetics (RCMG), Moscow, Russia
Annotation. The modern biomedical research centers work with data received by heterogeneous experiments. So, the development and support of informational and analytical systems using relational database management systems is labour-intensive and unjustified. These factors determines the actuality of solution search to create small and easily extensible databases with automated selection. We combined the methods of object-oriented design and relational databases. The developed database management system was tested on the data of medical and genetic analyzes of biomaterial of mentally ill people in the current activity process of Research Centre for Medical Genetics (RCMG).
Key words: database, translator, object-oriented design, relational databases.
Современные условия осуществления медико-генетических исследований характеризуются тем, что они сопряжены с необходимостью реализации разнообразных процессов сбора и обработки информации из разнородных источников, данные в которых генерируются в разное время и в условиях отсутствия централизованных систем хранения и сбора информации. В этих условиях использование стандартизированных решений (например, MongoDB, Apache Cassandra и т.п., а также - реляционных СУБД) сопряжено с рядом проблем, которые напрямую обусловлены тем, что:
1) в соответствии с «теоремой CAP» Эрика Брюера, для подобных систем внутренняя непротиворечивость данных и их целостность находится в противоречии с требованиями к простоте масштабируемости. Кроме этого практическое использование подобных систем для решения задачи построения большого множества малых баз данных не всегда является актуальным;
2) отсутствует полное отображение хранящихся в подобных системах данных на 2D пространство, что, с одной стороны, снижает трудоемкость и ресурсоемкость задачи накопления информации, а с другой стороны существенно повышает трудоемкость и сложность ее обработки автоматизированными системами;
3) используемые в реляционных базах данных логические модели проверки целостности не всегда позволяют описать биохимическую модель процесса.
В этих условиях для решения поставленной задачи является целесообразным совместить использование подходов связанных с реализацией преимуществ ООП (инкапсуляция, наследование и полиморфизм) и реляционного подхода к хранению данных. К преимуществам этого решения возможно отнести, то, что он позволяет унифицировать проектирование и реализацию информационных систем, ввод данных, а также выборку из базы данных.
Основу предложенному в статье решению составляет экспертно задаваемая иерархия классов, которая описывается в виде дерева и позволяет на ее основе генерировать стандартные наборы графических интерфейсов. Ее отличительной особенностью является то, что для упрощения задачи был выбран механизм наследования «один-к-одному», т.е. каждый класс может иметь только один непосредственный класс-предок (наподобие того, как это реализовано в языках Object Pascal или Java). отличительно особенностью подобного подхода является то, что он позволяет избежать конфликтов связанных с тем, что при множественном наследовании нетипизированных данных является реальной ситуация, когда автоматизированное средство не будет обладать достаточной информацией о предметной области, а следовательно не будет обладать набором адекватных правил по трансформации данных.
Данные допущения привели к тому, что в качестве базовой архитектуры для предлагаемого решения было выбрано решение на основе следующей архитектуры:
Вейко Р.В.
трудозатрат, а кроме того обеспечивает ее интероперабель-ность с различными системами хранения информации.
Транслятор запросов
Согласно представленной ранее схемы деления, основной задачей, которую решает разработанный транслятор является преобразование поступаемого от сгенерированного интерфейса потока команд к виду принятому стандартом SQL-92 [1]. С математической точки зрения этот процесс может быть описан в виде:
S = FS(1)
где S - результирующая командная строка стандарта SQL-92; F - реализованный на основе конечных автоматов преобразователь; S' - строка на исходном языке.
Основу преобразователю составляет специально разработанная формальная грамматика [2] (табл. 1), которая определяет состав и структуру соответствующего ей конечного автомата обеспечивающего проверку и трансляцию передаваемых данных.
Таблица 1
Формальная грамматика
Наименование правила Правило
Select "SELECT" ["DISTINCT"] selectExpression "FROM" tableExpression ["WHERE" expression] ["HAVING" expression] ["ORDER BY" order]
Insert "INSERT" "INTO" tableName "("field_list")" "VALUES" "("expression_comma")"
Update "UPDATE" tableName "SET" [field_value_list] "WHERE" expression
Delete "DELETE" ["HARD"] "FROM" tableName "WHERE" expression
selectExpression * || expression || expression "AS" quatedName
expression_comma expression || expression "," expression_comma
Expression andCondition || andCondition "OR" expression
andCondition condition || condition "AND" expression
Condition operand conditionRightHandSide || operand || "NOT" condition || "EXISTS" select
conditionRightHandSide compare operand
Operand summand || summand "||" operand
Summand factor ||factor ADDOP summand
Factor term || term MULOP factor
Term value || columnName || SIGN term || "("expression")" || select || qualified_name
Value string || numeric || date || time || timestamp || boolean || null || "["id"]" || "["virtual_id_list"]" || "[" "]"
virtual_id_list virtual_id "," virtual_id_list || virtual_id ||
virtual_id tableName ":" decimal_integer ||
field_list columnName "," field_list || columnName ||
field_value_list field_value_item "," field_value_list || field_value_item ||
field_value_item columnName "=" expression
tableExpression tableName || tableName "," tableExpression
Order expression_comma ["ASC" | "DESC"]
qualified_name quated_name || quated_name "." qualified_name || quated_name "." cast_to "." qualified_name
cast_to "CASTTO" "("quated_name")"
is_null "ISNULL" "(" ")"
Count "COUNT" "(" ")"
Numeric decimal || decimal_integer
Экспертно заданная иерархия классов
Графический интерфейс Генератор графического интерфейса
Транслятор запросов - Данные об иерархии классов для трансляции
] Разработанные элементы
Система управления СУБД (на основе языка программирования SOL)
Система хранения реляционной СУБД
Существующие элементы
Сгенерированные элементы
Рис. 1. Архитектура (схема-деления) объектно-реляционной СУБД «Data Struct Designer»
К преимуществам выбранного решения возможно отнести то, что оно по своей сути являясь надстройкой над реляционной базой данных позволяет избежать связанных с необходимостью модернизации ядра реляционной СУБД
Особенностью построенной грамматики является то, что фактически она может быть разделена на две части, а именно:
• данные условия, которые задают условия выборки в реляционной СУБД;
• данные получаемой информации, которые задают возвращаемое 2-D множество данных.
Подобное разделение позволило дополнить работу транслятора этапами предварительной и окончательной обработки. В связи с этим укрупненная последовательность работы этого блока выглядит следующим образом.
1. На вход транслятора передается входная строка содержащая сформированный в графическом интерфейсе запрос.
2. Осуществляется трансляция в язык SQL при этом на данном этапе также осуществляется и предобработка правой части запроса путем выделения из него частей связанных с непосредственным получением данных и той, которая связана с решением сложных математических задач решение которых в рамках возможностей реляционных баз данных не представляется возможным.
3. Осуществление запроса к СУБД.
4. Постобработка полученных данных с целью удаления из полученного множества тех записей, которые не соответствует полученным на втором этапе правилам.
5. Постобработка получаемой матрицы исходных данных. В основном эта обработка связана с необходимостью получения не сырых данных в виде матрицы, а в виде обработки при помощи средств математической статистики.
Практическая реализация транслятора выполнена на основе теории формальных языков и работает следующим образом. Из визуальной формы запрос переводится в текстовое представление, которое затем проходит лексический (на основе конечного автомата), синтаксический (на основе рекурсивного спуска) и семантический анализ (на основе структуры классов семантического дерева). После этого, запрос выполняется при помощи виртуальных методов элементов семантического дерева.
К преимуществам созданного решения возможно отнести:
• достаточно высокую производительность, что обеспечено возможностью проведения дополнительной оптимизации SQL-выражений;
• возможность вызова в процессе трансляции информации со стороны внешних систем (обеспечивается за счет специализированной работы вершин автомата). В частности, если в иерархии классов не задано какое-либо определение или необходимо удаленная обработка полученных данных, то они могут быть осуществлены как в момент трансляции, так и непосредственно перед передачей данных в графический интерфейс;
• возможность кэширования полученных результатов, что положительно сказывается на общей скорости выполнения процесса обработки данных.
Данные об иерархии классов для транслятора
Необходимо отметить, что для практической реализации представленного механизма помимо решения задачи трансляции запросов необходимо также предусмотреть возможности по дополнительной проверке и преобразованиям данных. В частности, необходимо выполнять множественные операции по проверке существования запрашиваемых
полей запроса в первоначально заданной иерархии классов. В этой связи, в рамках данной работы было обеспечено динамическое расширение грамматики и соответствующего ей конечного автомата путем ее дополнения на основе заданной в иерархии классов информации. В частности расширения позволяет описать такие функции статистической обработки исходных данных как линейная регрессия и т.д.
Генератор графического интерфейса
В рамках представленной на рисунке архитектуры графический интерфейс представляет из себя средство для ввода данных конечным пользователем системы. При этом, его общий вид генерируется на основе заданной иерархии классов, а порождаемые средства первичного контроля представляют сгенерированные по изначально заданной иерархической структуре соответствующие команды языка программирования высокого уровня. Структурно работа с базой данных начинается с выбора базового класса для которого создается окно (рис. 2). Доступ к наследуемым классам и связанным с ним записям осуществляется посредством иерархически задаваемой структурой. При этом, необходимо отметить, что сгенерированные для базового класса средства первичного контроля за введенными данными также являются обязательными к проверке и при введении данных о дочерней сущности. Практическое достижение этого результата достигается тем, что помимо непосредственной проверки на непротиворечивость правилам заполнения наследуемого элемента также осуществляется и проверка на соответствие всем правилам классов-предков. С математической точки зрения это означает, что если мы обозначим множество допустимых в классе-наследнике значений через Х1, а предка Х2, то Х1 е Х2.
Укрупнено реализованная система может быть описана при помощи следующей UML-схема классов (см. рис. 2), обеспечивающих объектно-ориентированное представление данных в информационной системе.
Базовым классом схемы является класс TDefinition (определение). Каждый элемент схемы данных содержит уникальный идентификатор который задается автоматически. Класс TClassSchema дает представление схемы данных. Схема данных может содержать один или несколько объектов TClassDefintion, определяющих классы. Каждый класс может содержит 3 или более атрибутов (TClassAttribute). Атрибуты, в свою очередь, могут быть полями с данными (TClassField), ссылками «один-к-одному» и «один-ко-многим» (наследники класса TClassLink, а также служебными полями, к которым относятся:
• TClassServiceFieldId - поле, которое автоматически создается в главном классе и соответствует автоинкрементному первичному ключу в реляционных базах данных;
• TClassServiceDeleteDt - поле, содержащее дату и время удаления записи;
• TClassServiceFieldParent - поле, содержащее старшую запись (для самоподчиненных классов - то есть классов, записи которых выстроены в древовидную иерархию).
Вышеперечисленные 3 служебных поля служебные поля задаются автоматически при создании классов.
Многомерная структура, которая создается при помощи объектно-ориентированного подхода отображается в двумерные реализации. Структура классов, обеспечивающая отображение (реализацию) объектно-ориентированной структуры в 2D-объекты представлена на рис. 3.
Вейко Р.В.
Рис. 2. Структура классов, обеспечивающих объектно-ориентированное представление данных в информационной системе
Рис. 3. Структура классов, обеспечивающая хранение данных
Базовый класс - Т1тр1ете^. Схема трансформируется в реализацию класса TImplementSchema, который может содержать одну или несколько реализаций классов (Т1т-plementClass). В свою очередь, реализация класса может содержать 0 или более записей (TImplementAttributes2D). Каждая запись представлена классом TImplementAttributes и уникально идентифицируется числовым идентификатором - аналогом автоинкрементного первичного ключа в реляционных базах данных. Ссылка «один-к-одному» (TImplementLinkSingleToSingle) указывает 0 или 1 запись из TImplementAttributes2D, а ссылка «один-ко-многим» - на 0 или больше записей из TImplementAttributes2D. В терминологии ООП ссылка «один к одному» - это указатель на экземпляр класса, а «один-ко-многим» - массив указателей на экземпляр класса. Класс TImplementField обеспечивает хранение данных (числовых, логических, полей дата/время и текстовых). Классы, представленные на рис. 3 связаны с классами - определителями объектной модели, представленными на рис. 2.
Заключение
В рассматриваемой статье разработана и представлена архитектура системы для быстрой генерации большого числа взаимосвязанных малых баз данных. Ее основу составляет основанная на разработанном автором языке программирования. Структурно этот язык построен на основании существующего языка запросов SQL и позволяет компактно осуществлять трансляцию запросов на реляционные СУБД. Помимо этого, на основе заданной системы иерархии классов была разработана интерпретирующая машина, которая позволяет осуществлять верификацию поступаемых в систему хранения данных.
Работа производится в рамках НИР (№ гос. регистрации 01201156783).
Литература
1. ISO/IEC 9075:1992, Database Language SQL. July 30, 1992.
2. Ахо А., Сети Р., Ульман Д. Компиляторы : принципы, технологии,
инструменты. Вильямс, 2008.
