Сетевой электронный научный журнал "СИСТЕМОТЕХНИКА", № 2, 2004 г.

СПЕЦИАЛИЗИРОВАННЫЕ СУБД ДЛЯ ПОДДЕРЖКИ РЕЧЕВЫХ БАЗ ДАННЫХ

 

Белолипецкий С.И., Буря А.Г.

(Московский государственный институт электроники и математики)

 

Введение

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

Такая обширная сфера применения неизбежно вызывает интерес к данной теме всего мирового научного сообщества. Над данной тематикой работают такие крупные фирмы как IBM, Intel, ScanSoft. В нашей стране этой проблематикой занимается Российская академия наук, Московский государственный институт, Московский государственный лингвистический университет и многие другие [1].

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

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

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

Огромный объем (обычно не менее нескольких Гб цифровых данных) и необходимость быстрого и произвольного доступа выдвигает определенные требования к системе управления базами данных СУБД (СУБД) служащей для поддержки РБД.

Например, на кафедре ЭВА МГИЭМ была создана и непрерывно расширяется по настоящее время РБД «SpeechBase» [2], [3]. Целью создания SpeechBase было обеспечение поддержки студенческих и аспирантских проектов по речевых технологиям (распознавание речи, верификация диктора). Речевые данные «SpeechBase» сохраняются в виде файлов на жестком диске персонального компьютера, что дает некоторые преимущества и удобства в работе с ними. Однако в настоящее время объем РБД настолько вырос (более 300 Мб цифровой речи и более 4000 записей), что возникает вопрос о применении принципиально иного подхода к сохранению речевых данных.

 

Требования к СУБД для эффективного хранения речевых данных

При разработке РБД неминуемо встает проблема выбора СУБД. Здесь возможны следующие варианты: выбрать существующую хорошо зарекомендовавшую себя СУБД из числа присутствующих на рынке информационных технологий или разработать свою СУБД специально для этой задачи.

При выборе из возможных вариантов разработчики руководствуются следующими требованиями к СУБД, на которой будет реализована речевая база данных:

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

СУБД должна поддерживать хранение данных большого объема (и большого суммарного объема). Объем речевой БД может в несколько раз превышать объем доступной оперативной памяти.

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

СУБД должна иметь средства для различных статистических расчетов по текущему состоянию речевой БД.

СУБД должна иметь средства для импорта и экспорта речевых бинарных данных (а также сопутствующих им текстовой информации).

СУБД должна предоставлять возможность как однократного полнообъемного прочтения бинарного речевого образа, так и поэтапного (постраничного) чтения. Это требование возникает из-за различных потребностей алгоритмов обработки данных, алгоритмов распознавания и процедур импорта/экспорта. В реляционных СУБД существует подобный механизм, позволяющий указывать оптимизатору запросов, требуется ли последовательное получение результатов запроса и однократное (спецификаторы FIRST_ROWS, ALL_ROWS).

СУБД должна позволять получить речевые данные на внешнем носителе информации в стандартном формате звукозаписи для возможности использования большинства программ обработки звука. Это требование можно обеспечить либо постоянным хранением бинарных данных в файлах со стандартным форматом (наподобие типа данных BFILE в Oracle) или с помощью развитых средств импорта/экспорта.

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

 

Анализ существующих СУБД

Существующие реляционные СУБД мало подходят для хранения речевых данных [4], [5], [6]; наиболее удобный механизм реляционных СУБД, позволяющий хранить речевые данные: тип данных BLOB. К сожалению, использование этого типа данных для хранения речевых данных сопряжено с рядом проблем. Тип данных BLOB рассматривается разработчиками реляционных СУБД как дополнительный или даже необязательный. Вследствие этого, операции для работы с ним малочисленны и неоптимизированны. Во многих реляционных СУБД нет таких операций для работы с типом данных BLOB, как вставка и удаление части данных, есть только полная перезапись и обнуление. Уже одно то, что в языке SQL нет никаких операций для работы с типом данных BLOB [4], показывает насколько затруднено его использование.

У ряда реляционных СУБД есть возможность хранить данные во внешних файлах (например, тип данных BFILE в СУБД Oracle), что позволяет использование средств файловой системы для работы с данными. Но и это не панацея. С тем же успехом можно и не пользоваться СУБД, а хранить речевые данные просто в файлах.

Несколько лучше отвечают требованиям речевой базы данных объектно-ориентированные СУБД (ООСУБД). Особенно заманчиво использовать для подобной цели ООСУБД типа Jasmine [7], ориентированные на разработку мультимедийных приложений. В этом случае не возникает проблемы с надлежащим типом данных, поскольку ООСУБД так или иначе предоставляют возможность создать свой тип данных (класс), для которого можно задать формат хранимых данных, описать нужные операции по обработке данных. Также мультимедийные ООСУБД работают с большими объемами данных намного эффективнее реляционных [8].

К сожалению, и ОО СУБД не свободны от недостатков, сильно затрудняющих их применение для реализации РБД [5], [6]. Среди таковых прежде всего следует назвать высокую стоимость подобных систем, отсутствие стандартов на языки манипулирования и описания данных (до недавнего времени многие ООСУБД вообще не обладали декларативным языком для формулировки запросов и по уровню своих возможностей приблизительно соответствовали сетевым и иерархическим системам), чрезмерную сложность их языком запросов (типа OQL и OSQL). Также для современных ООСУБД характерно недостаточное наличие средств для поддержания целостности данных [6]. Если при создании реляционной модели одной из целей является четкое отделение правил целостности от запросов на модификацию, то объектная модель не представляет подобных возможностей: вместо декларативного задания ограничений целостности нам приходиться встраивать соответствующие проверки в текст каждой процедуры.

Таким образом, приходим к заключению, что ООСУБД очень перспективны, и в будущем их применение для реализации РБД наверняка станет оправданным и эффективным. В настоящее время ООСУБД еще не развились настолько, чтобы можно было говорить об их успешном применении в области поддержки РБД [6].

Поскольку существующие СУБД не отвечают вышеуказанным требованиям, то приходится либо использовать «гибридные» варианты с совместным использованием РСУБД, ООСУБД и функциональных возможностей операционной системы, либо принимать решение о реализации собственной специализированной СУБД с ограниченной функциональностью, но подходящей для цели организации речевой базы данных. Такой подход имеет свои недостатки – снижение надежности хранения данных, большие затраты времени и средств на реализацию гетерогенного хранилища данных, ограниченная функциональность такого хранилища. Тем не менее, разработчики РБД предпочитают использовать именно гетерогенное хранилище, а не какую-либо СУБД.

Получаем, что существующие в настоящее время СУБД мало соответствуют задаче поддержки РБД. Все они имеют какие-либо недостатки, приводящие к дополнительным сложностям для разработчика. Среди этих недостатков можно выделить:

Отсутствие типа данных, позволяющего не только хранить, но и обрабатывать речевые данные.

Неоптимальное быстродействие при работе с большими двоичными данными.

Ограничения на размер хранимых данных.

Отсутствие средств обработки двоичных данных (и речевых данных в том числе). Особенно можно отметить отсутствие в языке SQL языковых конструкций для обработки двоичных данных.

Отсутствие средств импорта/экспорта больших двоичных данных.

То, что существующие СУБД малопригодны для разработки речевой СУБД вполне объяснимо. Как видно из списка требований, требования сложно осуществимы и весьма противоречивы – требуется совместить максимальное быстродействие и удобную форму представления речевых данных, развитые средства импорта/экспорта и гибкую настройку доступа к данным. Пытаясь объединить противоречивые пункты вместе и найти, таким  образом, приемлемый компромисс, получаем следующие выводы:

Если при реализации СУБД нельзя обеспечить одновременно приемлемое быстродействие и удобную форму представления данных, то можно реализовать ядро СУБД, ориентированное на максимальное быстродействие и приложить к нему утилиты для быстрого импорта/экспорта в удобную форму представления данных – таким образом можно обеспечить выполнение обоих требований с минимальными трудозатратами.

Следует либо расширить язык SQL средствами для обработки двоичных данных, либо отказаться от SQL в пользу другого языка, обладающего нужными качествами.

Речевые данные ввиду своей специфики адекватно ложатся на архитектуру объектно-ориентированных СУБД, а в реляционных СУБД приходится идти на нарушения концепции, чтобы обеспечить их обработку и хранение.

СУБД должна позволять расширять свои возможности каким-либо способом, чтобы разработчик мог добавлять свои средства и алгоритмы обработки данных.

 

Заключение

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

Из рассмотренных требований можно вывести следующие рекомендации разработчику специализированной СУБД:

Особое внимание при разработке СУБД нужно уделить вопросам быстродействия при работе с большими объемами двоичных данных.

Следует обязательно снабдить СУБД средствами для импорта/экспорта данных (в том числе двоичных) в различные форматы.

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

Язык SQL не подходит для реализации речевых баз данных из-за отсутствия в нем конструкций для работы с двоичными данными. К тому же применение языка SQL в объектно-ориентированной системе нельзя назвать разумным решением. Лучше выбрать для этой цели объектно-ориентированный язык с богатыми возможностями.

Следует также предусмотреть специальный интерфейс пользователя, ориентированный на работу с большими объемами двоичных данных. Стандартные универсальные интерфейсы доступа к СУБД, такие как ODBC, BDE, JDBC, не подходят, поскольку предполагают работу с данными через курсоры и тесно привязаны к языку SQL.

Следование данным рекомендациям позволит создать СУБД, эффективно решающую задачу организации речевой базы данных. Эти рекомендации и требования отражают только специфику речевых баз данных, поэтому их следует учитывать вместе с рекомендациями и требованиями по надежности, защиты информации,  целостности данных и т.д. Можно рассматривать вопрос создания универсальной СУБД, которая может решать различные задачи, а среди них и реализацию речевых баз данных.

 

Список литературы

 

  1. Андреев С. В. "Программное обеспечение для создания и использования фонетических баз данных" в сб. "Речевая и музыкальная  информатика" // ВЦ РАН отв. ред. В.Я. Чучупал, М.: 1992, с. 81-96.
  2. Буря А.Г., Чекмарев А.В. Информационная система для хранения и управления образцами оцифрованной речи. // Научно-техническая конференция студентов, аспирантов и молодых специалистов МГИЭМ. 1999. С. 57.
  3. Петров Г.М., Буря А.Г., Ноздрачев Р.А. Речевая база данных // Датчики и системы. 2000. № 4. С. 17-19.
  4. Дейт К. Дж. Введение в системы баз данных. Шестое издание. // «Диалектика», Киев, Москва, 1998.
  5. Кузнецов С. Тенденции в мире систем управления базами данных. // Материалы конференции "Корпоративные базы данных '96" (Адрес в интернете: http://citforum.gatchina.net/database/kbd96/48.shtml)
  6. Кузнецов С. Что было, то и теперь есть, и что будет, то уже было … // http://www.inteltec.ru/publish/articles/objtech/kuznetsd.shtml
  7. Зашихин А. Обзор объектно-ориентированной СУБД Jasmine. // Материалы конференции "Корпоративные базы данных'2001" (Адрес в интернет: http://www.citforum.ru/seminars/cbd2001/day_2_1_jasmin.shtml)
  8. Дж. Харрингтон. Проектирование объектно-ориентированных баз данных.  // ДМК Пресс, Москва, 2001.

Сетевой электронный научный журнал "СИСТЕМОТЕХНИКА", № 2, 2004 г.