CC BY
32
УДК 004.043
Р. О. Коротков, П. С. Деменков, В. А. Иванисенко
Институт цитологии и генетики СО РАН пр. Акад. Коптюга, 2, Новосибирск, 630090, Россия E-mail: [email protected]
ВЕБ-ОРИЕНТИРОВАННАЯ СИСТЕМА ПОСТРОЕНИЯ И ИСПОЛНЕНИЯ КОМПЛЕКСНЫХ ЗАПРОСОВ К РЕЛЯЦИОННЫМ ИСТОЧНИКАМ БИОЛОГИЧЕСКОЙ ИНФОРМАЦИИ НА ОСНОВЕ СЕМАНТИЧЕСКОЙ ФОРМАЛИЗАЦИИ СТРУКТУРЫ ДАННЫХ *
В статье речь идет о разработке системы, предоставляющей веб-интерфейс для построения и исполнения комплексных запросов к реляционным источникам биологических данных. Рассматривается архитектура масштабируемой системы, обеспечивающей выполнение множественных запросов и представляющей результаты в виде таблиц или графиков. Предлагается метод трансляции формализованного семантического запроса в запрос к СУБД. Описывается интерфейс веб-приложения, реализованный на технологии Adobe Flex.
Ключевые слова: веб-ориентированная обработка данных, анализ данных, семантическая модель, биоинформатика.
Введение
Развитие экспериментальных высокопроизводительных средств в области биологии обеспечили бурный рост данных. Биологические экспериментальные данные характеризуются большим разнообразием, высокой гетерогенностью и огромными объемами. В частности, только за 2008 г. в банк данных GenBank было добавлено более 19 миллионов вновь секве-нированных нуклеотидных последовательностей, что составляет почти одну пятую часть от общего объема последовательностей, хранимых в этой базе данных [1]. За последнее время созданы тысячи разнообразных баз данных, представленных в различных форматах, имеющих сложную структуру. Так, только за последний год реестр биологических баз данных был расширен более чем на 100 новых источников данных [2]. Особо следует отметить, что существующие средства доступа к большинству таких баз данных не обеспечивают в полной мере возможностей проведения анализа данных и представления результатов. Многие публичные хранилища данных предоставляют довольно ограниченный интерфейс для выполнения комплексных запросов, сводящийся к предопределенному набору компонентов базы данных (таблиц, хранимых процедур и пр.) и предопределенному же набору атрибутов этих компонент (колонок, параметров и пр.) [3].
В мире активно разрабатываются средства и методология разработки баз данных, специфичных для биологической информации [4; 5]. Одной из принципиально важных задач при разработке программно-информационных систем является предоставление интуитивно понятного веб-интерфейса, обеспечивающего возможность построения и выполнения комплексных запросов к данным [6; 7]. В настоящее время широкое распространение получили реляционные базы данных, обеспечивающие выполнение комплексных запросов на языке SQL (Structured Query Language). Предоставление пользователям возможности прямого дос-
Работа частично поддержана интеграционными проектами СО РАН № 94, № 111, программой РАН № 19 и госконтрактом с ФАНИ 02.514.11.4123.
ISSN 1818-7900. Вестник НГУ. Серия: Информационные технологии. 2010. Том 8, выпуск 3 © Р. О. Коротков, П. С. Деменков, В. А. Иванисенко, 2010
тупа к формированию SQL-запросов может рассматриваться как самое простое решение этой задачи, однако оно требует специализированных знаний о синтаксисе SQL, а также информации о структуре базы данных [8].
В настоящей работе представлена интегрированная система, обеспечивающая возможность автоматической семантической формализации биологических данных, предоставляющая простой и удобный веб-ориентированный интерфейс построения запросов, на основе этой формализации. Кроме этого, данная система предоставляет пользователю возможность создания необходимого представления результатов выполнения таких запросов в форме отчета, содержащего таблицы и графики. Она обладает широкими функциональными возможностями для решения задач, связанных с поиском, фильтрацией, группировкой, агрегацией, сортировкой и представлением биологических данных в удобной для пользователя форме.
Архитектура системы
При разработке архитектуры системы особое внимание мы уделяли тенденциям развития и практического применения так называемых «богатых интернет-приложений» (Rich Internet Application), способных, по нашему мнению, стать удачной заменой веб-формам и статическим картинкам, используемым для представления биологической информации.
Одним из важных требований к разрабатываемой системе было возможность ее использования без процесса инсталляции, кросс-платформенность и кросс-браузерность. В нашей системе мы использовали технологию Adobe Flex, поскольку она предоставляет средства объектно-ориентированной разработки и получила на сегодняшний день наибольшее распространение (Flash Player установлен на 99 % компьютеров во всем мире, по данным компании Adobe).
Архитектурно система построена на базе клиент-серверного решения, где клиентская часть реализована на технологии Adobe Flex, а серверная часть представляет собой совокупность сервисов, реализованных с использованием технологий WCF (Windows Communication Foundation) и ASP.NET на платформе .NET. Основные компоненты системы:
• клиентское приложение, которое является Flash-объектом, интегрированным в ASP.NET страницу, обеспечивающим взаимодействие пользователя с системой;
• публичный веб-сервис, представляет собой интерфейс взаимодействия клиентского приложения с серверной частью, в ответственность которого входят также задачи, связанные с обеспечением конфиденциальности данных;
• сервис данных, который обеспечивает хранение формализованных моделей данных, запросов пользователя в форме отчетов, а также сами результаты выполнения запросов в различных форматах;
• сервис управления, основной задачей которого является поддержание очереди пользовательских запросов в актуальном состоянии, а также распределение этих запросов по свободным сервисам исполнения задач;
• сервисы исполнения задач - специализированные сервисы, занимающиеся непосредственно исполнением запросов и генерацией соответствующих представлений для их результатов (количество сервисов исполнителей может варьироваться от одного до нескольких десятков в зависимости от сложности структуры биологических данных, а также от количества пользователей);
• базы данных, непосредственно содержащие биологические данные.
Базовая конфигурация системы подразумевает установку на одном компьютере веб-сайта и службы (Windows Service). На сайте расположены средства администрирования, генерации и редактирования моделей данных, публичный веб-сервис и ASP.NET-страница с клиентским приложением. Служба обеспечивает работу сервиса данных и сервиса управления. Масштабируемость системы достигается за счет увеличения количества компьютеров с установленной службой (Windows Service), обеспечивающей работу сервиса исполнения задач.
Такая конфигурация представляется оправданной, поскольку основная вычислительная нагрузка распределяется между сервисами, ответственными за обработку и представление данных, в то время как остальная часть системы выполняет лишь потоковые операции сохранения и извлечения сохраненных запросов и их результатов, что в большинстве случаев требует существенно меньших ресурсов, чем обработка данных.
Прежде чем пользователь сможет приступить к работе, ему необходимо пройти аутентификацию в клиентском приложении, для того чтобы определить, какие модели данных и сохраненные запросы других пользователей доступны для данного пользователя. Как только аутентификация пройдена, в клиентском приложении появится стартовая страница со списком формализованных моделей данных и сохраненных в форме отчетов пользовательских запросов. С этой страницы можно создать новый запрос на базе одной из моделей данных, редактировать один из сохраненных запросов либо исполнить его и просмотреть результат. Приложение предоставляет широкие возможности по редактированию запроса, настройке фильтрации, группирования и сортировке данных, создания параметров запроса, настройке его визуального представления, а также средства просмотра результатов выполнения запроса.
Публичный WCF-сервис работает по протоколу SOAP и обеспечивает взаимодействие клиентской части с серверной инфраструктурой. Он ответственен за безопасность и контроль над тем, каким пользователям, к каким ресурсам системы разрешен доступ. Автор сохраненного отчета может настроить для него разрешение со стартовой страницы клиентского приложения. Публичный веб-сервис предоставляет методы загрузки и сохранения пользовательских запросов, получения их списка, а также для получения списка моделей данных. Кроме того, данный сервис предоставляет интерфейс для выполнения пользовательских запросов и, поскольку такие запросы могут выполняться довольно долго, методы мониторинга их состояния.
WCF-сервис данных отвечает за сохранение всех ресурсов, возникающих в процессе функционирования системы, в их число входят формализованные модели данных, сохраненные в форме отчетов пользовательские запросы, цветовые темы и стили оформления пользовательских отчетов, а также сами задачи на исполнение тех или иных запросов. Для хранения этой информации сервис данных использует встраиваемую базу данных SQLite, которая благодаря реляционной структуре обеспечивает быстрый и гибкий доступ к ресурсам. Публичный веб-сервис использует сервис данных по протоколу Named Pipes для предоставления авторизованным пользователям доступа к ресурсам. Сервис управления по этому же протоколу - для хранения информации о пользовательских задачах и распределения их между сервисами исполнителями. Последние, в свою очередь, используя протокол TCP, извлекают из него модели данных, отчеты, стили и темы, необходимые для выполнения задачи, и сохраняют результат обратно.
Сервис управления, также являясь WCF-сервисом, принимает от публичного веб-сервиса, по протоколу Named Pipes, сообщения о намерении пользователя исполнить тот или иной запрос. На основании таких сообщений он формулирует задачи для сервисов исполнителей и сохраняет эти задачи в сервисе данных. Основной функцией данного сервиса является управление распределением пользовательских задач по доступным сервисам их исполнения. На основании данных о процессоре, оперативной памяти и других характеристиках сервиса исполнителя он принимает решение, кому необходимо поручить выполнение той или иной задачи. Кроме того, сервис управления следит за самим процессом выполнения всех задач и предоставляет эту информацию пользователям.
Сервис, непосредственно осуществляющий исполнение задач, общается с другими сервисами по протоколу TCP. Получив указание от сервиса управления исполнить определенную задачу, он загружает информацию об этой задаче, а именно: в каком формате представить результаты, какую модель и отчет использовать, и значения параметров для запроса, из сервиса данных загружает все необходимые для исполнения этой задачи ресурсы и приступает к ее выполнению. Первым делом сервис осуществляет преобразование формализованного пользовательского запроса в специфический SQL-запрос к СУБД, после чего, используя
коммерческий продукт, который не является частью данной работы, сервис-исполнитель, на основе данных, полученных при выполнении SQL-запроса, осуществляет построение требуемого пользователем представления. Получив конечный результат, он сохраняет его в сервисе данных и сообщает сервису управления, что пользователь может просмотреть этот результат.
Проведенное тестирование показало устойчивую работу данной конфигурации при одновременной работе нескольких сотен пользователей. При этом зависимость времени выполнения всей совокупности запросов от количества сервисов исполнения задач была близка к линейной, небольшое отклонение, по-видимому, может объясняться коммуникационными издержками на общение сервисов между собой и СУБД.
Формализованная модель данных
Формализованная модель данных, используемая в данной работе, представляет собой некоторую абстракцию, основными понятиями которой являются сущность, атрибут и роль. Сущностью может являться любой объект предметной области, например, ген, белок, выравнивание, реакция и т. д. Сущность характеризуется набором атрибутов, определяющих ее свойства. Атрибут - это некоторая характеристика сущности, ее описание, принимающее значение в контексте определенной взаимосвязи данной сущности с другими сущностями, примерами атрибутов могут служить длина гена, функция белка, скорость реакции и т. д. Взаимоотношения между сущностями описываются при помощи ролей, роль характеризует некоторую функцию сущности в ее взаимоотношении с другой сущностью, например, ген играет роль источника структурной информации для белка, но в то же время белок может играть роль транскрипционного фактора в отношении гена и т. п. Модель, построенная на таком базовом уровне, подлежит дальнейшей формализации.
В качестве такой формализации в настоящей работе использован язык описания семантических моделей (SMDL - semantic model definition language), разработанный компанией Microsoft. Данный язык привносит в базовую модель важные с точки зрения представления данных понятия. Взаимоотношения между сущностями могут описываться при помощи ролей разных типов: единичных и множественных. Например, геном содержит большое количество генов, поэтому роль, характеризующая отношение генов к геному, множественная, в то же время конкретный ген может принадлежать только одному геному, что характеризует отношение генома к гену единичной ролью. Атрибуты сущностей также могут принимать значения лишь определенных типов: строковые, числовые, логические и бинарные. Кроме того, сами атрибуты можно разделить на два класса. Атрибуты первого класса - это те атрибуты, значение которых однозначно определено для конкретного экземпляра данной сущности. Другой класс атрибутов - это те атрибуты, которые принимают свое значение для определенного множества экземпляров данной сущности, которое в свою очередь определяется рассматриваемым отношением между сущностями. Например, длина нуклеотидной последовательности гена всегда одна и та же, для данного гена в данном геноме. В то же время среднее значение длины, которое также может являться атрибутом сущности «ген», полностью зависит от того, в каком контексте мы его рассматриваем: оно может показывать, к примеру, среднюю длину генов в данном геноме либо среднюю длину генов, ответственных за выполнение определенной функции.
В таком виде формализованная модель данных представляется конечному пользователю. Однако чтобы обеспечить возможность построения запросов к данным, необходимо связать эту модель непосредственно с самой структурой источника данных. Для этого используется специальный механизм привязок и так называемое представление источника данных. Представление источника данных - это своего рода тоже модель описания данных, однако она оперирует исключительно объектами того источника данных, который описывает. Например, если в качестве источника данных выступает реляционная СУБД, то такое представление
состоит из таблиц, колонок, хранимых процедур, ключей и т. д. Представление источника данных дает возможность связать объекты формализованного представления данных с объектами источника данных. На базе таких привязанных к источнику данных элементов модель может быть расширена и дополнена при помощи языка построения запросов и выражений, являющегося частью самой семантической формализации данных.
На настоящий момент в нашей системе реализовано представление источника данных и генерация формализованной модели только для реляционных баз данных. Кроме того, для серверов баз данных MS SQL и Oracle разработан и реализован алгоритм преобразования формализованного запроса в специфичный серверу SQL-запрос. В дальнейшем мы планируем расширить типы источников данных, с которыми сможет работать наша система.
Суть метода трансляции формализованного семантического запроса в запрос к СУБД заключается в преобразовании сущностей и их атрибутов к вложенным (nested) выражениям SELECT, а ролей связывающих сущности формализованного запроса к эквивалентным JOIN-выражениям. Для ролей множественного типа используется LEFT OUTER JOIN. Для ролей же единичного типа используется INNER JOIN в том случае, если в представлении источника данных содержится внешний ключ (FOREIGN KEY), соответствующей данной роли, и LEFT OUTER JOIN в противном случае. Существование внешнего ключа гарантирует существование записи в связанной таблице, что позволяет использовать INNER JOIN без потери данных.
Например, рассмотрим базу данных с таблицами «мутация», «белок», «организм». Таблица «мутация» связана внешним ключом с таблицей «белок», таблица «белок» в свою очередь с таблицей «организм». Иными словами, одному организму соответствует множество белков, а одному белку - множество мутаций. На основании такой базы данных система автоматически построит формализованную модель с сущностями: «мутация», «белок» и «организм». При этом сущность «белок» будет играть множественную роль по отношению к сущности «организм», а сущность «организм», в свою очередь, единичную - по отношению к сущности «белок». Аналогичные роли будут созданы для пары сущностей «мутация» и «белок». Предположим теперь, что пользователь хочет посчитать общее количество мутаций всех белков для каждого из геномов. В этом случае формализованный запрос будет представлять собой всего лишь два выражения: группирующее выражение по сущности «организм» и выражение, подсчитывающее количество мутаций. Этот запрос может быть представлен в виде дерева, корневым узлом которого является сущность «организм». На уровне корневого узла определено группирующее выражение по экземплярам сущности «организм». Узел «организм» содержит один дочерний узел - «белок», который в свою очередь также содержит дочерний узел - «мутация», на уровне которого определено выражение, подсчитывающее количество мутаций. В процессе преобразования каждый узел данного дерева будет преобразован к вложенному SELECT-выражению, а каждая роль, связующая узлы, - к JOIN-выражению, в результате получится следующий запрос:
SELECT [организм].[первичный ключ], COUNT ([белок].[ключ мутации]) FROM [организм] LEFT OUTER JOIN (
SELECT [белок].[первичный ключ], [мутация].[ключ мутации]
FROM [белок] LEFT OUTER JOIN (
SELECT [мутация].[первичный ключ] AS [ключ мутации] FROM [мутация]
) [мутация] ON [белок].[первичный ключ] = [мутация].[внешний ключ] ) [белок] ON [организм].[первичный ключ] = [белок].[внешний ключ] GROUP BY [организм].[первичный ключ]
Процесс преобразования формализованного запроса, создаваемого пользователем, к запросу, обрабатываемому источником данных, состоит из трех последовательных стадий.
1. Преобразование формализованного запроса к дереву, содержащему привязки к объектам представления источника данных. Сами по себе такие привязки являются строковыми константами и не несут никакой информации об объектах представления источника данных. На данном этапе все атрибуты, не имеющие привязок, и все выражения запроса разворачиваются до тех пор, пока во всех выражениях запроса не будут фигурировать лишь те объекты, которые имеют связи с объектами представления источника данных.
2. Преобразование дерева привязок к дереву объектов представления источника данных. В случае реляционных баз данных такими объектами являются таблицы, колонки и отношения (relation). На данном этапе восстанавливается информация о первичных и внешних ключах, восстанавливается условие для операции объединения таблиц (JOIN condition) таким образом, что построенное дерево содержит всю необходимую информацию для генерации запроса к источнику данных.
3. Преобразование дерева объектов представления источника данных к запросу, обрабатываемому источником данных. На данном этапе всем элементам, участвующим в запросе, присваиваются уникальные псевдонимы, что обеспечивает однозначность при формировании и вычислении SQL-выражений, а все отношения преобразуются в операции объединения таблиц (INNER JOIN, LEFT OUTER JOIN).
Первая стадия преобразования универсальна для любого источника данных, поскольку оперирует лишь объектами формализованной модели данных. Следующие две стадии выполняются непосредственно самим представлением источника данных, и в общем случае их количество может меняться. В случае реляционных баз данных вторая стадия является универсальной и не зависит от конкретной СУБД. Таким образом, для подключения новых систем управления реляционными базами данных требуется реализовать лишь последнюю стадию преобразования дерева реляционных объектов в SQL-запрос.
Интерфейс системы
Публичный интерфейс системы реализован на технологии Adobe Flex, которая предоставляет средства объектно-ориентированной разработки платформонезависимых кросс-брау-зерных приложений. Использование объектно-ориентированной парадигмы сильно упрощает процесс разработки приложений со сложной архитектурой, что является немаловажным фактором для таких областей, оперирующих столь сложными структурами и взаимосвязями между ними, как информационная биология.
Формализованная модель данных представлена пользователю в виде двух древовидных структур: сущностей и атрибутов. На рис. 1 изображены деревья для модели данных, построенной по тестовой реляционной базе данных. Жирным шрифтом выделены те элементы, которые так или иначе участвуют в текущем пользовательском запросе. Например, на рис. 1 продемонстрирован запрос, который возвращает сгруппированные по геномам белки, участвующие в переносе генов, и подсчитывающий среднюю и максимальную длину генов, кодирующих эти белки для каждой группы белков, построенной для генома. В дереве сущностей дочерними элементами каждого узла являются те сущности, с которыми сущность, представленная данным узлом, имеет связи, выраженные ролями. Тип роли - единичный или множественный - символизируется иконкой. Например, в модели, изображенной на рис. 1, считается, что белку свойственна одна функция, однако в его структуре могут быть выделены несколько доменов. В дереве атрибутов дочерними элементами узлов могут быть атрибуты производные от атрибута, представленного базовым узлом. Например, длина нуклеотидной последовательности является свойством гена, на базе которого могут быть вычислены такие атрибуты сущности «ген», как средняя, максимальная, минимальная или суммарная длины нуклеотидной последовательности. Иконка символизирует тип данных, представленных атрибутом, а фигурная скобка - является ли данный атрибут присущим конкретному экземпляру сущности или же некоторой группе экземпляров, заданной текущим запросом.
Entity Т гее Attribute Tree
т Ш Protein {13 £ Gene
► Д] Domain a Acronym
► Щ Function a Comment
т ЦЩ Gene a Full Name
Т [Ц Dna a Id
► Др Contig T 13 Length
► Др Gene {l3 Avg Length
► Ц Genome {l3 Max Length
► Др Noncoding DNA {i3 Min Length
► Др Орегоп {i3 Total Length
► Ш Туре a Location
► Др Gene Fragment T 13 Position
► Др Gene Mutant {i3 Avg Position
► [Ц Орегоп {i3 Mas Position
► [ДА Protein {i3 Min Position
► ДА RNA Gene {l3 Total Position
► Ш Orf a Short Name
► [ДР Protein Fragment TF Strand Direction
► Д ] Protein Mutant
► Д] Protein Posttranslational Modification
► Ш Protein Surface
► Ш Type
Рис. 1. Дерево сущностей и дерево атрибутов
Genome name
В. АЪс...
Maximal gene length
1 =.34 {13
Filter Proteins with 4и6= -H
Name equals ф репе transfer
Group By Genome
Рис. 2. Табличное представление данных
Pm
l
Ava Length ~ v4 Max Length ' \ Drop data fields hEiE
Average & maximal gene length per genome
I Add a series
i oo
А В C D E
Genome
II Filler Proteins with ►►
:: Category Genorre_________►► j
f АгЫ в rstorm I
Рис. 3. Представление данных в виде диаграммы
Например, акроним и полное название гена являются строками, а его длина - числом, все они присущи конкретному экземпляру гена, в то время как число генов, среднее значение длины и пр. определены лишь для группы генов. В данном примере средняя и максимальная длины нуклеотидной последовательности вычисляются для группы генов, принадлежащих одному геному, продуктом экспрессии которых служат белки, участвующие в переносе генов.
Процесс построения запросов тесно интегрирован с процессом построения представления для результатов выполнения этого запроса. Таким образом, пользователь полностью избавлен от необходимости решать сложную задачу привязки данных, являющихся результатом
запроса, к представляющим их графическим объектам. В реализованной системе пользователь при помощи простых операций перетаскивания элементов из деревьев формализованной модели на рабочую поверхность создает оформление для тех данных, которые он желал бы увидеть, на основании чего система за кадром строит запрос, исполнение которого приводит к извлечению данных, необходимых пользователю (рис. 2).
В текущей версии системы пользователю доступны два варианта представления данных: в виде таблицы или диаграммы (графика). На рис. 2 и 3 изображены примеры соответствующих представлений для описанного запроса. Во время построения запросов, для того чтобы пользователь мог видеть, как приблизительно будет выглядеть результат выполнения запроса, генерируются случайные данные. Поскольку само по себе представление в виде таблицы или диаграммы плохо подходит для отображения фильтрации и группирования данных, то для представления фильтров и группировок была использована концепция декоративных элементов, обрамляющих основное представление данных (см. рис. 3).
Задаваемые условия фильтрации состоят из атрибута, который подвергается фильтрации, функции, определяющей критерий для фильтра, и определенного значения, с которым сравнивается значение атрибута при помощи данной функции. Кроме того, такие условия могут быть объединены в группы при помощи логических операций «И», «ИЛИ» и отрицания.
Система позволяет создавать параметры для запроса, которые пользователю предложено будет задать перед тем, как он отправит запрос на исполнение. Параметры позволяют пользователю создавать группу структурно похожих запросов, например, в случае запроса, описанного выше, создание параметра для исполняемой белком функции позволит для всех геномов получить среднюю и максимальную длины нуклеотидной последовательности генов, кодирующих белки, с различными функциями.
Кроме этого, система обладает богатыми возможностями для сохранения результатов выполнения запросов в различных форматах (PDF, Word, Excel, Html или Xml). Встроенные в веб-приложения средства просмотра обеспечивают навигацию по группам, сформированным в процессе выполнения запроса, средства поиска, а также позволяют вывести эти результаты на печать.
Заключение
Представленная в данной работе система может найти широкое применение для предоставления публичного доступа и построения комплексных запросов к реляционным источникам биологических и других типов данных, обеспечивающих поиск, фильтрацию, группирование, сортировку и агрегацию данных. Использование данной системы не требует от пользователя специальных знаний о реляционной модели данных, структуре используемой базы данных, а также о синтаксисе языка построения запросов к СУБД. В дальнейшем мы планируем реализацию возможности создания модели, учитывающей несколько источников данных, что имеет большое значение для решения задачи интеграции разрозненных источников информации. Прототип системы доступен через Интернет по адресу: http://89.31.116.12:8080/.
Список литературы
1. Benton D. et al. GenBank // Nucleic Acids Research. 2009. Vol. 37. P. D26-D31.
2. Cochrane G. R., Galperin M. Y. The 2010 Nucleic Acids Research Database Issue and online Database Collection: A Community of Data Resources // Nucleic Acids Research. 2010. Vol. 38. P. D1-D4.
3. Chen I.-M. A., Kosky A. S., Markowitz V. M., Szeto E., Topaloglou T. Advanced Query Mechanisms for Biological Databases // AAAI Press. Proceedings of the Sixth International Conference on Intelligent Systems for Molecular Biology. 1998. Vol. 6. P. 43-51.
4. Navarro D. J. et al. BioBuilder as a Database Development and Functional Annotation Platform for Proteins // BMC Bioinformatics. 2004. Vol. 20. P. 5-43.
5. Birney E., Clamp M. Biological Database Design and Implementation // Briefings in Bioinformatics. 2004. Vol. 5. Is. 1. P. 31-38.
6. Chen J. Y., Carlis J. V., Gao N. A Complex Biological Database Querying Method // ACM. Proceeding of the 2005 ACM Symposium of Applied Computing. 2005. Vol. 20. P. 110-114.
7. Kazic T., Coe E., Polacco M., Shyu C.-R. Whither Biological Database Research? // OMICS: A Journal of Integrative Biology. 2003. Vol. 7. No. 1. P. 61-65.
8. Newsome M., Pancake C., Hanus J. HyperSQL: Web-based Query Interfaces for Biological Databases // System Sciences. Proceedings of the 30th Hawaii International Conference. 1997. Vol. 4. P. 329-339.
Материал поступил в редколлегию 12.05.2010
R. O. Korotkov, P. S. Demenkov, V. A. Ivanisenko
WEB-ORIENTED SYSTEM FOR COMPLEX QUERYING BIOLOGICAL RELATIONAL DATA SOURCES BASED ON DATA STRUCTURE SEMANTIC MODEL
The paper describes the system developed for building and executing complex queries to relational data sources of biological information. Architecture of a scalable system designed to support execution of multiple queries and rendering table or chart representation for the results is discussed. We suggest a method of translating a query defined in semantic terms to an equal SQL query. The user interface of the web application implemented with Adobe Flex technology is described.
Keywords: web-based data processing, data mining, semantic model, bioinformatics.
