Использование ключей для идентификации объектов словаря

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

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

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

Поясним все это на примере частей речи.

Каждая часть речи в грамматическом словаре имеет уникальное название и опциональный синоним. Название задается при описании грамматики языка и может содержать любые символы юникода. Например существительное, прилагательное, adjective. В ходе компиляции словаря из исходных текстов объявления частей речи запоминаются в таблице БД и им присваиваются целочисленные идентификаторы. Эти идентификаторы неизменны для конкретной сборки словаря, что позволяет сгенерировать файлы с объявлением символических констант для разных языков программирования и ссылаться на нужные части речи в прикладном коде с помощью целочисленных констант.

Процесс генерации файлов с объявлением символических констант тоже на самом деле автоматизирован, так как описание части речи содержит и имя константы, которая будет объявлена. И вот для этих символических констант действуют уже жесткие правила - только латиница, никаких пробелов, начинаться может только с буквы. Это позволяет делать объявление констант как для старых языков типа C++, так и для относительно новых типа C#, допускающих юникод для идентификаторов.

Продолжая пример с частями речи, можно перечислить такие константы: NOUN_ru - русское существительное, VERB_en - английский глагол.

Символические константы собраны в файлах с именами типа _sg_api.h и _sg_api.py, которые надо просто включить в свой проект.

Прикладная программа может, конечно, найти первичный ключ части речи и самостоятельно по его имени, с помощью функции sol_FindClass. В каких случаях это может быть удобнее, чем использование целочисленных констант? Если программа использует символические константы, то она не сможет работать со словарем, в котором объявления частей речи по каким-то причинам перемешаны и изменили свои первичные ключи. Чтобы сделать код устойчивым к такого рода изменениям, достаточно после загрузки словаря найти с помощью sol_FindClass идентификаторы нужных частей речи по их именам, которые меняются очень редко, и запомнить эти идентификаторы в каких-то глобальных переменных, которые потом и использовать.

Работа с языками, типами связей тезауруса и алфавитами обстоит в целом так же, как и для частей речи. Меняются только функции, позволяющие найти первичный ключ нужного объекта по его названию. Также для id русского языка есть символическая константа RUSSIAN_LANGUAGE, и так далее.

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

Так как словарных статей очень много, обычно несколько десятков тысяч, то генерировать какие-то символические константы в ходе компиляции словаря для них совершенно непрактично. Вместо этого прикладной код должен использовать функции API для поиска словарной статьи, например sol_FindEntry.

Ситуация осложняется таким явлением, как омонимия - несколько словарных статей имеют одинаковое название.

Если омонимы относятся к разным частям речи, то достаточно указать в аргументах вызова sol_FindEntry идентификатор нужной части речи в дополнение к имени. Наиболее типичная ситуация, когда возникает такая необходимость - поиск русских глаголов. В описании русской морфологии в рамках грамматического словаря есть особенность - неопределенные формы глаголов (инфинитивы) объявлены как отдельные словарные статьи с сингулярной парадигмой. Поэтому есть две словарные статьи БЫТЬ - одна для глагола, другая для инфинитива. Чтобы получить ключ нужной статьи, следует указать при вызове sol_FindEntry константу id нужной части речи - либо VERB_ru, либо INFINITIVE_ru.

Обычно необходимость поиска первичных ключей определенных статей возникает для прикладного кода только для небольшого подмножества слов - служебных, типа БЫТЬ, ДЕЛАТЬ, ЭТО. А вот в правилах морфологического, синтаксического анализа и трансформации необходимость сослаться на какую-то словарную статью вне подмножества служебных слов возникает очень часто. И тут перед нами иногда возникает проблема с омонимами, которые принадлежат одной части речи. Например, существительные Орел и орел можно отличить только по грамматическому признаку одушевленности. Синтаксис правил поддерживает специальный механизм точной идентификации словарной статьи при наличии таких близких омонимов - заданием уточняющих грамматических признаков:

существительное:орел { ОДУШ:ОДУШ }
существительное:орел { ОДУШ:НЕОДУШ }

В каждом конкретном случае есть один селективный грамматический признак. Для глаголов это может быть вид, например для сбе́гать и сбега́ть. Для позиции ударения нет специального морфологического (в данном случае скорее фонетического) признака, но глагольный вид вполне достаточен для однозначной идентификации.

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

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

Но для связей есть другая область, в которой символические константы оказываются очень кстати. Речь идет о типах связей. Такие типы, как синонимы, гипернимы и гипонимы, переводы фактически отличаются целочисленным типом. Символические константы для типов связей объявлены опять-таки в файлах _sg_api.*. Например, для переводов на английский язык есть константы типа TO_ENGLISH_link, для антонимов ANTONYM_link.

Особая роль нулевых значений первичного ключа для COORD_PAIRS и TAG_SET

Указанные в заголовке таблицы являются справочниками и хранят в особом нереляционном формате списки из морфологических признаков и значений тегов. Подробнее о работе с COORD_PAIRS написано здесь.

В обоих случаях запись с нулевым первичным ключом играет особую роль, позволяя увеличить эффективность работы со словарем в базе данных. Такая запись соответствует пустому списку. Благодаря этому соглашению прикладной код, в частности слой доступа к данным в ORM, увидев значение SG_FORM.ID_DIMS=0, не будет делать запрос к справочнику COORD_PAIRS для получения списка. Аналогичным образом обстоит дело с полем SG_LINK.TAGS.

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

Дополнительные материалы

Дистрибутив SQL словаря

Словарь в реляционной базе данных

Загрузка SQL словаря

Генерация первичных ключей

Кэширование

  © Elijah Koziev 2010
прикладные проекты на основе грамматического словаря API грамматической машины компоненты для доступа к грамматическому словарю условия получения SDK токенизатор и сегментатор морфологический анализ и синтез лемматизатор база N-грамм синтаксический анализатор словоформы морфология и синтаксис русского языка падеж число род совершенный и несовершенный вид экспорт в SQL формат экспорт в XML формат скрипт SQL словаря структура SQL словаря структура XML словаря компоненты для доступа к грамматическому словарю ORM Persistent Dictionary Library лемматизация стемминг примеры использования грамматического словаря склонение существительных в русском языке склонение русских прилагательных спряжение глаголов в русском языке поиск текста с учетом морфологии OCR подсистема расширенные регулярные выражения генератор текста генератор случайного текста и имитатор рандомизатор синонимизатор перефразировщик Статистика буквенных паттернов

Грамматический словарь русского языка



Грамматический словарь
склонение и спряжение глаголов, существительных, прилагательных

В состав входит русский и английский словарь.

платформа:  Windows 2000 ... Windows 7
требования: 512 Mb свободной памяти, 300 Мб на диске
размер:         34 Мб

  скачать грамматический словарь купить грамматический словарь SDK грамматического словаря
грамматический словарь русского языка



SDK Грамматического словаря



SDK Грамматического Словаря
склонение и спряжение глаголов, существительных, прилагательных

В состав входит русский и английский словарь.

платформа:  Windows 2000 ... Windows 7
размер:         13 Мб

SQL словарь (демо):
sqlite mysql oracle firebird mssql

скачать демо-версию SDK купить SDK API грамматического словаря



Поисковая система



Integra
настольная и сетевая поисковая система 

платформа:  Windows XP ... Windows 7
требования: 512 Mb свободной памяти
размер:         21 Мб

Дополнительные компоненты:
MySQL поисковый сервер 13.5 Мб
Integra.Premium MySQL 3.9 Мб

скачать поисковую систему SDK поисковой системыописание поисковой системы



SDK Поисковой системы



SDK Поискового движка
API для настольной и сетевой поисковая система 

платформа:  Windows XP ... Windows 7
размер:         17 Мб

Дополнительные компоненты:

MySQL поисковый сервер 13.5 Мб
Integra.Premium MySQL 3.9 Мб

скачать SDK SDK поисковой системы



Экранный переводчик



Translator
экранный переводчик

платформа:  Windows XP ... Windows 7
требования: 256 Mb свободной памяти
размер:         4.4 Мб

Дополнительные компоненты:
расширенный англо-русский словарь 6.4 Мб


скачать экранный переводчикописание экранного переводчика



изменено 16-Aug-11