EA006562B1

EA006562B1 - Способ кодирования ключей в базе данных и база данных

Info

Publication number: EA006562B1
Application number: EA200500009A
Authority: EA
Inventors: Дункан Гюнтер Паули
Original assignee: Копперай Лимитед
Priority date: 2000-11-30
Filing date: 2001-11-28
Publication date: 2006-02-24
Also published as: JP4267046B2; EP1364314B1; GB2369695A; AR035508A1; CY1109459T1; KR20080024237A; GB2369695B; GB0427860D0; KR100886189B1; GB0427862D0; GB2406678B; DE60139212D1; MY132130A; GB2406680B; EA200500009A1; JP4810785B2; GB2406681A; AU2002222096B2; EA200500010A1; JP2004527813A

Abstract

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

Description

Настоящая заявка является выделенной из заявки № 200300522.27 и относится к группе изобретений согласно независимым пунктам 48, 77 и 99.

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

Типы скалярных данных включают, например, логические данные, строки текста, числовые данные, и данные даты и времени.

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

Механизмы индексации требуют создания и поддержки внутренней индексной структуры. Передвижение между объектами в базах данных (навигация) и обслуживание этой структуры связаны с дополнительными расходами. Расходы могут меняться в зависимости от используемого механизма индексации. Кроме того, они могут меняться в связи с периодическими изменениями объема данных в базе данных.

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

Эффективность способа индексации может быть оценена по множеству свойств, таких как

1) размер индекса. Большие индексы требуют большего количества времени для передвижения между объектами в базах данных. Кроме того, они могут потребовать увеличенного количества перекачек данных или операций чтения из среды памяти с большим объемом данных, например жестких дисков, и более быстрой памяти, в частности полупроводниковой памяти;

2) структурные ограничения индексации. Структура с большими ограничениями может иметь некоторые начальные преимущества, но она связана с повышенными вычислительными затратами, если требуется обновить индекс при увеличении емкости базы данных в процессе размещения в ней большого объема данных;

3) ограничения по данным ключа, накладываемые индексом. Таким образом, максимальный размер ключей или типов ключей или диапазонов, представленных ключами, может начать сказываться на характеристиках индекса по мере его роста или по мере того, как база данных заполняется данными;

4) ограничения поиска ключей, налагаемые индексом. Некоторые индексы позволяют только точное совпадение ключей, тогда как другие разрешают соответствие диапазонов;

5) ограничения роста индекса. Максимальный размер индекса может быть ограничен;

6) ограничения по взаимной совместимости. Индекс может позволять или запрещать одновременную вставку и поиск данных ключа.

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

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

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

Передвижение между объектами базы данных (навигация)

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

- 1 006562

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

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

Каждый узел решений может принять два решения. Иными словами, каждый узел имеет максимум только два пути выхода.

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

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

Если выход из узла указывает на другой узел, поиск продолжается. Однако если выход из узла указывает на вывод данных, навигация по индексу, в основном, заканчивается.

Возможно, что никакие результаты не будут соответствовать условиям поиска, в этом случае поиск завершается нулевым результатом.

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

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

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

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

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

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

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

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

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

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

- 2 006562 налагает никаких ограничений на структуру ключа. Более того, часть ключа, с которой связан узел, не должна следовать тому структурному порядку, по которому осуществляется передвижение по графу. Таким образом, часть ключа, о которой идет речь, не должна постепенно перемещаться вдоль ключа по мере того, как происходит передвижение по графу.

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

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

Предпочтительно, чтобы отсутствовали функциональные ограничения, налагаемые на размер графа решений. Структура индекса обеспечивает умеренное увеличение времени поиска по мере того, как граф решений увеличивается, чтобы адаптироваться к увеличенному количеству данных.

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

Предпочтительно, чтобы каждый элемент данных в базе данных относился бы только к одному конечному набору данных.

Разделение графа решений

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

В таких условиях граф решений может содержаться в блоках вычислительной системы с запоминающим устройством большой емкости. Контроллер диска управляет диском с учетом размера дискретных блоков данных. Так, например, если минимальный размер блока, используемый контроллером диска, равен 64 килобайтам, то индекс 40К и индекс 60К оба занимают один и тот же объем памяти на диске, а именно, один блок, и подобным образом, индекс 65К и индекс 130К также занимают одинаковый объем памяти, а именно два блока.

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

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

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

- 3 006562 мое при выборе этого узла, и на основании полученного результата выбирает другой проверяемый узел, пока не будет достигнуто примерно равномерное распределение.

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

Сравнение с шаблоном

Как уже было сказано, известные системы хранят полный поисковый ключ, связанный с любым заданным режимом.

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

В соответствии с третьим вариантом настоящего изобретения разработан способ запроса базы данных, содержащей индекс и данные, в котором индекс запрашивается с использованием поискового ключа для осуществления поиска данных, соответствующих критерию поиска, отличающийся тем, что индекс является иерархической структурой, состоящей из узлов решений, причем навигация по структуре осуществляется до тех пор, пока не будет получен искомый набор данных, и в котором узел может содержать подпоследовательность ключа, с которой может сравниваться потенциальный ключ, с целью определения действия, которое должно быть предпринято, и в котором часть ключа, записанная в узле в Ν+1-ом слое индекса, не связана с частью, записанный в предыдущем узле в Ν-ом слое.

Используемое здесь выражение часть ключа в Щ+1)-ом узле не связана с частью ключа в Ν-ом узле означает, что эта часть ключа не вычисляется путем последовательного выбора частей ключа, изменяющихся обычным порядком.

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

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

Улучшенное сравнение с шаблоном

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

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

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

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

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

Как отмечено выше, чем больше символов включено в последовательность, тем менее вероятно, что эта последовательность появится в ключе. Таким образом одиночный символ, вероятно, появится в ключе вместе со многими другими символами, принимая во внимание, что определенная последовательность четырех символов намного менее вероятна.

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

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

Однако комбинации двойных символов являются весьма редкими.

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

- 4 006562

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

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

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

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

Сжатие ключа

Как отмечено выше, в некоторых базах данных известной области техники в каждом узле решений хранится полный ключ решения/поиска. Такое решение может создавать относительно большую индексную структуру, в которой сами ключи могут быть большими. Отметим, что в базе данных, составляющей вариант настоящего изобретения, поисковые ключи не должны храниться в каждом узле решений, хотя может оказаться желательным хранить часть поискового ключа в узле решений. Опция хранения части поискового ключа приводит к созданию относительно компактного дерева решений базы данных, в которой можно осуществлять быстрый поиск. Однако заявитель пришел к выводу, что ключ не должен храниться в индексе в его первоначальном виде. Таким образом, ключ может быть кодирован в виде, который требует меньше места для хранения.

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

Таким образом возможно обеспечить более компактный конечный набор данных. При этом база данных поддерживает точное совпадение.

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

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

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

Для функций преобразования могут быть использованы известные и опубликованные алгоритмы преобразования, например СВС32 и Лб1ет 32.

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

Например, преобразование может быть вычислено из скалярной величины длины N в байтах с использованием следующей функции:

[(Κ0χ31λ(Ν-1))+(Κ1χ31λ (N-2))... +ΚΝ-1] модуль В, где ΚΝ - η-ая величина байта (0 ..255) или ключ К

В - наименьшая степень 2, большая чем размер заполнения различных ключей, размещенных в индексе.

Предлагаются следующие величины В: 216 для индексов, содержащих менее чем 65000 ключей; 232 для индексов, содержащих менее чем 4х109 ключей; 264 для индексов, содержащих менее чем 1,8х1019 ключей.

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

Указатель

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

Однако могут потребоваться не все выбранные данные.

Рассмотрим, например, случай многонациональной организации, которая желает опросить свои базы данных о персонале, чтобы определить число служащих, работающих в Лондоне, и диапазон их заработной платы. Индекс, основанный только на месте проживания или на заработной плате, дал бы ответ на данный запрос по многим служащим. Это окончилось бы только новым запросом на сокращение списка.

- 5 006562

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

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

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

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

Предпочтительно, чтобы множество ключей было бы представлено в сжатом виде.

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

Здесь, благодаря тому, что различные ключи могут быть представлены тем же самым уменьшенным представлением, возникает риск, что на запрос будут выданы как результаты, которые соответствуют запросу, так и некоторые результаты, которые не соответствуют запросу. Однако, предполагая, что используется надежное кодирование хешированием, вероятность несоответствия на одном ключе равна 1/255, для N указателей вероятность несоответствия - (1/255)Ν.

Таким образом, частота появления ошибок в целом небольшая.

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

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

Предпочтительно, чтобы каждый дополнительный элемент после первого элемента сцепленного ключа был бы представлен как указатель. Каждый указатель предпочтительно имеет длину не более одного 1 байта.

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

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

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

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

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

Ограниченный ключ

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

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

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

В основном, указанный ключ используется хешированием или по модулю, когда ключи, в основном, одинаково распределены по всей базе данных. Таким образом, например, неограниченная дата/время (К) (которое может, например, составлять миллисекунды) преобразовано в (К модуль Ν), где N - выбранный модуль для индекса. Таким образом, величина ключа преобразователя будет всегда относиться к диапазону от 0 до (Ν-1).

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

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

Настоящее изобретение может применяться к обычному В-дереву или другим индексам.

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

Переходные ключи

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

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

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

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

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

Предпочтительно, чтобы модуль возраста представлял бы собой переменную, длина которой представляет число секунд в одном модуле возраста. Возрастной предел представляет собой число модулей возраста, после которого ключ может быть удален из индекса.

Преимущественно, каждый конечный набор данных содержал бы базу возраста, которая является отметкой даты/времени недавно введенного или обновленного входа в этот комплект. При обращении к конечному набору данных, возраст каждого входа вычисляется, и предпочтительно результаты вычислений хранятся в поле возрастной вход. Можно сравнить возрастной вход и возрастной предел, чтобы определить, когда новые данные могут быть записаны вместо устаревших данных.

Определение дублирования скалярных данных

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

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

- 7 006562

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

Итак, изобретение эффективно дополняет стандартную структуру индекса путем хранения кодированных величин ключа в полупроводниковой памяти. Существование ключа проверяется к памяти до поиска индекса. Если в указанной памяти найден совпадающий вход, ключ отклоняется как дубликат, в противном случае будет сделана попытка вставки входа в индекс.

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

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

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

Могут быть использованы опубликованные алгоритмы хеш-кода, типа СК.С 32 и Аб1ег 32, поскольку они обеспечивают подходящие функциональные возможности.

При применении индекса ключей память может быть организована в виде однородного массива элементов из четырех байтов. Этот массив известен как тождественный массив. Предпочтительно, чтобы число элементов в тождественном массиве было бы в 1,1 или несколько раз больше числа уникальных элементов ключа, размещенных в структуре индекса. Однако из этого следует, что тождественный массив просто должен быть, по меньшей мере, такого же размера, что и индекс. Две хеш-функции, А и В, используются в соединении с массивом. Функции выбраны так, что для любых двух неравных ключей, К и Ь, где (К)=(Ъ) маловероятно, что В(К) =В(Ь);

для любых двух неравных ключей К и Ь, где В(К)=В(Ь), маловероятно что (К)=(Ь).

Хеш-функция А используется для вычисления элемента смещения (Ο...Ν) в тождественном массиве для ключа К, используя следующее уравнение:

Номер элемента=АВ8(АК) модуль N

Где АБСОЛЮТНО АВ8(...) возвращает беззнаковую величину номера и N - число элементов в тождественном массиве.

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

При попытке вставлять ключ К в индекс происходит следующая последовательность событий. Вопервых, вычисляется Е(К). Затем вычисляется В(К). Если элемент в Е(К) в тождественном массиве содержит В(К), то попытка вставки отклоняется как дубликат К. Однако, если элемент в Е(К) в тождественном массиве не содержит В(К), то элемент записывается на место В(К) и осуществляется поиск индекса, чтобы определить, является ли ключ дубликатом.

Использование массива тождеств значительно уменьшает область памяти, требуемую для хранения списка ключей. Если база данных имеет миллион входов и каждый ключ имеет длину 32 байта, то это требовало бы более 32 мегабайт памяти для кэширования индекса в памяти. Однако эквивалентный массив тождеств занял бы всего 4,4 мегабайт памяти.

Организация индексов по иерархии

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

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

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

- 8 006562

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

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

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

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

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

фиг. 2 - схематическое представление логической структуры графа решений;

фиг. 3 - схема, иллюстрирующая структуру узла решений;

фиг. 4 - схема, иллюстрирующая структуру конечного набора данных;

фиг. 5 - схема, иллюстрирующая структуру входа в конечном наборе данных;

фиг. 6 - схема, иллюстрирующая точную процедуру поиска;

фиг. 7 - схема, иллюстрирующая процедуру поиска диапазона;

фиг. 8 - схема, иллюстрирующая процедуру вставки ключа;

фиг. 9 - схема, иллюстрирующая процедуру удаления ключа;

фиг. 10 - схема, иллюстрирующая процедуру точного запроса ключа;

фиг. 11 - схема, иллюстрирующая процедуру для диапазона запроса;

фиг. 12 - схема, иллюстрирующая процедуру пересечения узла с группой решения С, величиной решения V, минимальным и максимальным диапазонами ключа и возврата результата;

на фиг. 13 показана структура части графа решений;

на фиг. 14 показана логическая схема изменения узла решений;

на фиг. 15 показана процедура вставки ключа;

на фиг. 16 показана процедура удаления ключа;

на фиг. 17 показана процедура для точного совпадения запроса;

на фиг. 18 показана процедура для перемещения дерева с листингом шаблона с перечислением и возвратом результата;

на фиг. 19 показана процедура для поиска листинга шаблона (Ь);

на фиг. 20 показан пример того, как шаблон, согласованный с процессом, помогает сортировать данные;

на фиг. 21 представлена схема графа решений, имеющего ограниченный индекс;

на фиг. 22 показана структура измененного конечного набора данных;

на фиг. 23 показана схема, иллюстрирующая первый способ разделения графа решений;

на фиг. 24 показана схема, иллюстрирующая второй способ разделения графа решений; и на фиг. 25 показана схема, иллюстрирующая конфигурацию составного ключа, включающего указатели.

Фиг. 1 - схема, иллюстрирующая базу данных с индексом и представляющую вариант настоящего изобретения с накопителем данных. Индекс 2 включает граф узла решений 4 и множество конечных наборов данных 6, 8, 10, 12 и 14. К каждому конечному набору данных имеется доступ по одному и только по одному пути со стороны графа решений. Однако каждый конечный набор данных имеет выход, соединенный с соответствующим входом хранилища данных 16.

На фиг. 2 показана логическая структура графа решений, в основном, обозначенная позицией 20. Граф решений начинается в начале координат 22. Все стадии навигации через граф решений должно начинаться в начале координат. Начало координат может быть нулем (например, в новой базе данных), с одним или двумя указателями решений, указывающими на последующие узлы графа решений или на

- 9 006562 конечные наборы данных. Каждый следующий узел решений может содержать 0, 1 или 2 указателя решений, причем каждый указатель решений указывает либо на другой узел решений, либо на конечный набор данных. Указатели решений в узле решений будут называться по тексту как низкий указатель и высокий указатель.

Указатель решений в любом узле решений в графе решений может только указывать либо на любой другой узел решений в том же самом графе решений, либо на один конечный набор данных. Любой узел графа решений должен быть указан точно узлом решений в том же самом графе решений или началом координат. Точно так же, любой конечный набор данных должен быть указан только одним узлом решений графа решений. Таким образом, любой конечный набор данных может быть достигнут только по одиночному и уникальному пути через граф решений от начала координат. Этот уникальный путь известен как путь навигации.

На фиг. 3 схема логической структуры узла решений, в основном, обозначенная позицией 40, представлена более подробно. Узел решений включает тип низкого указателя, низкий указатель, тип высокого указателя и высокий указатель. Тип низкого указателя 41 указывает на цель низкого указателя 42. Тип низкого указателя 41 может определять, указывает ли низкий указатель 42 на узел решений или на конечный набор данных. Низкий указатель 42 дает адрес узла решений или конечного набора данных, на который он указывает. Здесь может быть введена нулевая величина, чтобы указать, что никакого указателя не существует. Аналогичным образом тип высокого указателя 44 определяет, указывает ли высокий указатель 45 на узел решений или на конечный набор данных. Высокий указатель указывает адрес узла решений или конечного набора данных, на который он указывает. Здесь снова может использоваться нулевая величина, чтобы указать, что не существует никакого указателя. Это позволяет представлять древовидную структуру графа решений и хранить ее в памяти вместе с процессором данных и его памятью.

Фиг. 4 - схема структуры конечного набора данных. Конечный набор данных содержит множество ключей и соответствующих входов 60, 62, 64, 66 и 68, каждый из которых связан вместе направленной связью, дающей адрес следующего входа в конечном наборе данных. На фиг. 5 показана схема логической структуры каждого входа в конечном наборе данных. Вход состоит из трех полей, а именно поле связи 80, поле ключа 82 и поле свойств. Пункты поля связи указывают на следующий вход конечного набора данных. Нулевая величина может указывать на отсутствие входа. Поле ключа 82 включает точную величину ключа, тогда как поле свойств содержит свойства, относящиеся к определенному ключу, например адрес данных, соответствующих полю ключа 82. Определив компоненты индекса, мы можем далее решить, как использовать и перемещать индекс.

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

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

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

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

1) математическая медиана всех возможных величин группы решений;

2) математическая медиана всех ожидаемых величин групп решений;

3) математическое среднее число всех ожидаемых величин групп решений;

4) произвольная величина, указанная при создании индекса;

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

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

ί) группа решений, которая может быть одной и той же для всех узлов решений;

ίί) группа решений, которая может быть изменена при каждом посещении узла решений;

ίίί) группа решений, которая может быть изменена, когда величина решения от предыдущего узла решений достигает или приближается к максимуму диапазона решений или к минимуму диапазона решений текущей группы решений;

- 10 006562 ίν) группа решений, которая может быть изменена, когда величина решения между последовательными узлами изменится меньше чем на одну единицу или меньше чем некоторый другой предопределенный порог.

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

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

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

Следует рассмотреть некоторые примеры навигации индекса. На фиг. 6 показано, как ключ в 4 байта может передвигаться при точном поиске совпадения. В этом примере ключи хранятся в А8СП коде, а числа, показанные против каждого ключа, показывают его величину в шестнадцатеричной системе счисления. В этом примере каждая группа решений имеет установленный размер из четырех битов. Группа решений перемещается последовательно до следующих четырех младших битов в каждом вновь посещенном узле. В этом примере наиболее значимый бит обозначен нулем, следующий наиболее значимый бит - единицей, следующий наиболее значимый бит - двойкой и так далее. Кроме того, для простоты величина решения в каждом узле обозначена цифрой 4. Таким образом, если группа решений имеет величину нуль, один, два, три или четыре, граф перемещается налево. С другой стороны, если группа решений имеет величину диапазона от пяти до пятнадцати, граф перемещается направо.

Как показано на фиг. 6, база данных включает множество имен. Эти имена или величины ключа, представлены как Егеб, ίοΐιη. Βίΐΐ, Ζοο. Епк и Рс1с (Фред, Джон, Билл, Зо, Эрик и Пит). Шестнадцатеричный эквивалент каждого ключа расположен рядом с именем. Процесс навигации будет далее описан применительно к вставке, удалению или согласованию.

Сначала ключи представлены первому узлу решений 100, в котором проверяются биты от нуля до трех. Поскольку каждое шестнадцатеричное слово занимает один байт, очевидно, что биты от нуля до трех соответствует первому символу в ключах. Таким образом, поскольку имена Фред, Джон, Билл, Зо, Эрик и Пит все начинаются с 4, то ключи проходят влево вдоль ветви 102 к узлу 104 второго уровня. Однако и Ζοе, и Пит имеют начальные четыре бита, выходящие за пределы диапазона от нуля до трех и, следовательно, их ключи проходят по пути высокого указателя 106 до узла 108.

Узлы 104 и 108 занимают второй уровень в графе решений и, следовательно, их решения основаны на следующих четырех битах в ключе. Это соответствует отображению следующего символа в шестнадцатеричном представлении. Таким образом, узел 104 Билл проходит вдоль указателя 110 низкого уровня до последующего узла (не показан) поскольку биты от 4 до 7 в ключе кодируют величину 2, тогда как Фред, Джон и Эрик проходит вдоль указателя 112 высокого уровня до дальнейшего узла (не показан), потому что биты от четырех до семи в их ключе кодируют величины 6, А и 5 соответственно, в шестнадцатеричном исчислении. Точно так же, в узле 108 ключ Пит проходит по указателю 114 низкого уровня, поскольку биты от 4 до 7 в нем кодируют величину нуль, тогда как Зо проходит по указателю 116 высокого уровня, поскольку биты от 4 до 7 кодируют величину А. Этот процесс может повторяться до тех пор, пока не будет отыскан ключ, который достигнет конечного набора данных.

Фиг. 7 - схема, иллюстрирующая, как ключ из четырех битов может перемещаться при поиске диапазона совпадения. Как и на фиг. 6, ключи хранятся в кодировке А8СП и величины А8СП напротив каждого ключа показывают их величину в шестнадцатеричном исчислении.

В этом примере группа решений имеет установленный размер из восьми битов. Группа решений перемещается до следующих восьми младших битов только после того, как диапазон решения полностью выбран; т.е. когда величина решения достигает любой границы диапазона решений. В этом примере наиболее значимый бит обозначен как нулевой разряд, следующее бит как единица, как и в примере, показанном на фиг. 6. Диапазон решений в каждом узле лежит в пределах от 30 до 50 в шестнадцатеричном исчислении, чтобы охватить все цифры и прописные буквы, представленные в формате А8СП. Величина решения в каждом узле, используемом для новой группы решений 48, является шестнадцатеричной и затем изменяется до среднего значения предыдущих величин решения той же самой группы решений в каждом последующем узле для этой же самой группы. Как только одна предыдущая величина решения станет известной, используется минимальная или максимальная величина из диапазона решений в зависимости от того, переместились ли мы только налево или направо, соответственно.

Используя те же самые ключи, что и в предыдущем примере, ключи представляются первому узлу 118, который проверяет первые восемь битов, от нуля до семи, и сравнивает их с величиной решения 48 (шестна

- 11 006562 дцатеричной). Как показано на чертеже, с этими ключами Фред, Билл и Эрик проходят вдоль низкого указателя к узлу 122, тогда как Джон, Зо и Пит проходят вдоль высокого указателя 124 к узлу 126.

В узле 122 становится необходимым изменить величину решения. Величина решения, используемая для этой новой группы решений, изменяется до величины медианы предыдущих групп решений, достигнутых на том же самом пути. При этом стала известна только одна предыдущая величина решения, поскольку в этом случае используется минимальный или максимальный предел диапазона величин решения. Учитывая то, что узел четыре 122 был установлен против низкого указателя 120, используется нижний предел диапазона решений.

Таким образом, для того, чтобы вычислить новую величину решения, потребуется найти медиану чисел в диапазоне от 30 шестнадцатеричной до 48 шестнадцатеричной величины. Это группа чисел 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 3А, 3В, 3С, 3Ό, 3Е, 3Е, 40, 41, 42, 43, 44, 45, 46, 47 и 48. Из этого ряда можно видеть, что величина медианы - 3С. Устанавливая ее как величину решения, Фред, Билл и Эрик, продолжают двигаться вдоль высокого указателя 127 к следующему узлу (не показан), величина решения которого будет величиной медианы диапазона от шестнадцатеричной величины 3С до шестнадцатеричной 48.

Точно так же, узел 126, достигнутый по высокой точке 124 от узла 118, имеет новую расчетную величину решения, которая в этом примере будет 4С (шестнадцатеричная). Применяя ключ к этому узлу, Джон пройдет влево (низкий указатель), потому что он имеет величину 4А, которая меньше величины решения 4С, тогда как Зо и Пит пройдут вправо (высокий указатель), потому что они имеют величину 5А и 50, соответственно, которая больше величины решения 4С.

Дальнейший пример поиска может быть найден в контексте поиска символа, при этом поиск выполняется, используя следующие критерии:

точное совпадение индекса с ключом символа А8СП, при этом каждый символ занимает 8 битов и находится в диапазоне от А до Ζ;

установленная группа решений состоит из 8 битов;

начало координат графа решений представляет собой 8 наиболее значимых битов (1-ый символ); группа решений проходит вперед на 8 битов (один символ) для каждого узла решений.

Коды А8СП для А и Ζ составляют 65 и 90 соответственно. Следовательно, разумная величина решения для этой группы - величина медианы (т.е. 78).

В этом примере группа решений проходит вперед на один символ (8 битов) каждый раз, когда получен новый узел решений. Делается сравнение величины битов в группе решений в ключе до установленной величины решения (78), чтобы определить, за каким указателем следовать.

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

Группа решений в ключе имеет величину 82. Стартовая величина решения для новой группы - 78. Диапазон решения - от 65 до 90. Группа решений была установлена таким образом, что новая группа выбирается, когда величина решения меньше единицы.

Величина решения	Изменение величины решения	Действие
78		Вдоль высокого указателя (82 > 78). Новая величина решения = (78+90) 72
84	6	Вдоль низкого указателя (82 < 84). Новая величина решения = (84+78) 72
81	3	Вдоль высокого указателя (82 > 81). Новая величина решения = (81+ 84) 72
82,5	1,5	Вдоль низкого указателя (82 < 83). Новая величина решения = (82.5+81) 72
81,75	0,75	Изменить группу решений

- 12 006562

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

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

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

1) установленный предел;

2) предел, указанный во время создания индекса;

3) предел, который может быть определен в течение всего срока службы индекса; и

4) предел, который изменяется в зависимости от роста индекса.

На фиг. 8 показана процедура вставки ключа (К), имеющего свойства (О). Процедура начинается на стадии 150, когда индекс вводится в его начало координат со значением по умолчанию или начальной группой решений ΌΟ, в зависимости от установки проектировщика. Алгоритм выполняется для определения начальной величины решения Όνο. Затем Управление передается на стадию 152, на которой проверяется, является ли группа решений в ключе больше величины решения. Если проверка дает положительный результат, управление передается на стадию 154, на которой проверяется высокий указатель НР и создается новая величина решения Όνί.

От стадии 154 управление передается на стадию 156, на которой выполняется проверка, чтобы убедиться, что указатель (высокий или низкий) существует. Точно так же, если на стадии 152 найдено, что группа решений в ключе не больше величины решения, управление передается на стадию 158, где проверяется низкий указатель и вычисляется новая величина решения Όνί. Управление переходит от стадии 158 на стадию 156. От стадии 156 управление передается на стадию 160 при условии, что указатель существует. На стадии 160 проверяется, указывает ли указатель на следующий узел решений. Если указатель указывает на узел решений, то управление передается на стадию 162, на которой проверка передается на следующий узел решений. От стадии 162 управление передается на стадию 164, на которой проверяется, должна ли группа решений быть изменена. Если ответ положительный, управление передается на стадию 166, которая вычисляет величину новой группы решений в совпадении с критерием, как изложено выше. От стадии 166 управление затем передается на стадию 164 или 166 и затем на стадию 152.

Если на стадии 156 найдено, что указателя не существует, управление передается на стадию 170, чтобы обеспечить создание нового конечного набора данных, и затем на стадию 172, на которой указатель обновляется, чтобы указывать на новый конечный набор данных. Затем управление передается на стадию 174, которая добавляет ключ и его свойства к конечному набору данных.

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

Очередная проверка делается на стадии 175, чтобы определить, не превысил ли конечный набор данных свой предел по размеру. Если конечный набор данных находится в допустимых пределах, управление передается на стадию 178, которая представляет собой выход из процедуры вставки ключа. Однако если конечный набор данных достиг своего предела по размеру, управление передается на стадию 180, которая создает новый узел решений без указателей. От стадии 180 управление переходит к стадии 182, на которой обновляется указатель предыдущего узла решений, чтобы указание производилось на новый узел решений, а не старый конечный набор данных. Затем управление передается на стадию 184, на которой проверяется старый конечный набор данных С8(8), чтобы проверить его заполнение. Если этот комплект не пуст, управление передается на стадию 186, на которой происходит переход к первому ключу и ввод свойств в конечный набор данных С8(8), а также перемещение индекса, чтобы найти новый конечный набор данных, в который этот ввод должен быть сделан. После перераспределения входа на конечный набор данных он удаляется из его текущего конечного набора данных С8(8) на стадии 188. Затем управление возвращается на стадию 184, и процесс повторяется до тех пор, пока конечный набор

- 13 006562 данных С8(8) не опустеет. Затем управление передается на стадию 190, которая представляет собой точку выхода из процедуры вставки ключа.

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

Объем данных в базе данных будет расширяться в течение определенного периода, и такое развитие будет включать стирание ключей и данных либо потому что данные в базе данных больше не нужны, либо потому что они нужны для целей архивирования с тем, чтобы живой вариант базы данных не был бы загроможден ненужными или устаревшими данными. На фиг. 9 представлена схема, иллюстрирующая процедуру удаления ключа. Некоторые из стадий идентичны тем, которые были описаны по отношению к фиг. 8, и, следовательно, эти стадии имеют те же самые цифровые позиции. Таким образом, стадии от 150 до 166 идентичны уже описанным, за исключением того, что, если проверка, выполненная на стадии 156, указывает, что данного указателя не существует, управление передается на стадию 200, которая представляет собой процедуру удаления данных.

Стадия 160 передает управление на стадию 176, если проверка на стадии 160 определяет, что указатель не указывает на узел решений (как это имело место с процедурой вставки ключа). От стадии 176 управление передается на стадию 202, где выполняется проверка наполнения конечного набора данных С8(8). Если конечный набор данных пуст, управление передается на стадию 204, которая представляет собой выход из процедуры, в противном случае управление передается на стадию 206, на которой осуществляется ввод данных в конечный набор данных. Поиск начинается с первым ключом (Ь) в конечном наборе данных и управление затем передается на стадию 208, где проверяется, равен ли ключ (Ь) ключу стирания. Если это так, управление передается на стадию 210, где ключ (Ь) и его свойства удаляются из конечного набора данных. От стадии 210 управление передается на стадию 214, где проверяется, является ли ключ (Ь) последним ключом в конечном наборе данных. Управление также передается от стадии 208 на стадию 214, если ключ (Ь) отличается от последнего удаленного ключа. Затем управление передается на стадию 216, на которой выбирается следующая величина, и управление затем переходит к 208. В противном случае управление переходит от стадии 214 на стадию 218, которая представляет собой выход из этой процедуры.

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

На фиг. 10 представлена процедура для точного запроса ключа и для получения ответного результата. Процедура во многом подобна процедуре удаления ключа и стадии 150-206 аналогичны описанным операциям со ссылкой на фиг. 9. Однако между стадиями 150 и 152 введена дополнительная стадия 151, в которой установленный результат (В) обнуляется. После перемещения индекса к конечному набору данных на стадии 202 управление передается на стадию 206, на которой инициализируется последовательный поиск через конечный набор данных. От стадии 206 управление передается на стадию 230, где проверяется, является ли обрабатываемый в данное время ключ (Ь) равным поисковому ключу. Если да, то управление передается на стадию 232, в противном случае управление передается на стадию 234. На стадии 232 ключ и его свойства добавляются к списку результатов запроса на поиск (В), после чего управление передается на стадию 234. На стадии 234 проверяется, является ли обрабатываемый в данное время ключ последним ключом в конечном наборе данных. Если это не так, проверяется следующий ключ и управление передается на стадию 230. Если проверяемый ключ является последним ключом, управление переходит от стадии 234 на стадию 236, которая представляет собой выход из этой подпрограммы.

На фиг. 11 представлена схема, иллюстрирующая процедуру выполнения запроса диапазона с минимальной величиной ключа (I), максимальной величиной ключа (А) и для возврата результата (В). Процедура начинается на стадии 300, на которой набор результатов (В) сбрасывается в нуль или в пустое

- 14 006562 состояние. Затем управление переходит к стадии 302, на которой рассчитываются группа решений и величины решений, после чего управление передается на стадию 304, на которой индекс перемещается, чтобы найти те результаты, которые соответствуют запросу диапазона. Процедура перемещения индекса показана более на фиг. 12. Процедура начинается на стадии 350, на которой процедура вводится в ее стартовый узел. Затем управление переходит к стадии 352, на которой проверяется, является ли минимальный ключ меньше величины решения или равен ей и, если это так, максимальный ключ больше соответствующей величины решения. Если результат испытания доказывает, что оба условия удовлетворены, управление переходит к стадии 370, в противном случае управление переходит к стадии 354. Стадия 370 выясняет, был ли установлен низкий указатель, и если да, то управление передается на стадию 372, на которой проверяется, указывает ли низкий указатель на конечный набор данных. Если это так, управление передается на стадию 400. Если нет, то управление передается на стадию 374, на которой группа решений и величины решений вычисляются и используются для перемещения индекса от узла, достигнутого через указатель. Процедура может вызвать саму себя и в этом смысле она рекурсивна. Затем управление переходит к стадии 376, на которой проверяется, существует ли высокий указатель, и если нет, управление переходит на стадию 378, которая представляет собой выход, а если да, то управление переходит на стадию 390, где проверяется, указывает ли высокий указатель на конечный набор данных; если да, то управление переходит на стадию 400, в которой, если высокий указатель не указывает на конечный набор данных, управление передается на стадию 392, где вычисляются новая группа решений и величина решения и выполняется дальнейший переход индекса, используя новый узел в качестве стартового узла.

Возвратимся теперь к точке у начала процедуры, в тех примерах, где стадия 352 передает управление на стадию 354. Стадия 354 проверяет, являются ли минимальная величина ключа и максимальная величина ключа меньше чем или равны величине решения. Если они равны, управление переходит на стадию 356, в противном случае управление переходит на стадию 358. Стадия 356 проверяет, существует ли низкий указатель и, если это не так, управление переходит к стадии 357, которая представляет собой выход из процедуры; в противном случае управление передается на стадию 360. Стадия 360 проверяет, указывает ли низкий указатель на конечный набор данных, и если это так, управление переходит на стадию 400, в противном случае управление переходит на стадию 402, которая повторно вычисляет группу решений и величину решения и инициирует процедуру прохождения рекурсивным способом. Вернемся к стадии 358, которая проверяет, существует ли высокий указатель, и если это так, управление переходит на стадию 362, в противном случае управление переходит на стадию 364, которая представляет собой выход из процедуры. Стадия 362 проверяет, указывает ли высокий указатель на конечный набор данных, и если это так, то управление переходит на стадию 400, в противном случае управление передается на стадию 364, которая вычисляет новую группу решений и величину решения и обеспечивает выполнение дальнейшего движения индекса, начиная с этих новых величин.

Стадия 400 проверяет, не является ли конечный набор данных (8) пустым, и если это так, управление переходит на стадию 404, которая представляет собой выход из процедуры. Если конечный набор данных не пуст, то последовательный поиск этих входов в конечном наборе данных инициализируется, начиная со стадии 406, где выбирается первый ключ в конечном наборе данных. Затем управление переходит к стадии 408, где проверяется, находится ли ключ (Ь) в диапазоне, определяемым минимальными и максимальными величинами ключа. Если это так, ключ и его свойства добавляются к конечному набору данных (8) на стадии 410, а если результат проверки на стадии 408 отрицательный, управление передается на стадию 412, которая проверяет, является ли ключ в настоящее время последним ключом в конечном наборе данных и, если это так, управление передается на стадию 414, которая представляет собой выход из процедуры. Стадия 410 также передает управление на стадию 412. Если проверка на стадии 412 определяет, что рассматриваемый ключ не является последним ключом, то выбирается следующий ключ в наборе данных на стадии 416 и управление возвращается на стадию 408.

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

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

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

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

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

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

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

Сравнение с шаблоном

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

Структура базы данных требует только небольшой модификации, которая уже описана выше. На фиг. 13 показана структура графа решений, которая во многом соответствует структуре, показанной на фиг. 2. Однако здесь начало координат и каждый узел решений содержат последовательность двоичных разрядов (битов). Битовая последовательность представляет собой часть дополнительного ключа, с которым сравнивается ключ-кандидат. Логическая структура каждого узла выбора решения показана на фиг.

14. Эта структура очень напоминает структуру, описанную по отношению к фиг. 3. Узел, в основном, обозначенный позицией 440, имеет область памяти 450 для последовательности битов решения. Последовательность битов решения может иметь любую длину. Однако следует обратить внимание на то, что в целом последовательность битов решения будет значительно короче, чем длина ключа для дерева решений. Узел включает указатель исключения 452 и указатель включения 456, которые указывают, связаны ли их соответствующие указатели исключения или указатели включения со следующим узлом решений или с конечным набором данных. Таким образом, эти указатели выполняют ту же функцию, что и низкий указатель и высокий указатель 41 и 44 соответственно, описанные со ссылкой на фиг. 3. Указатель исключения 454 и указатель включения 458 указывают на адрес следующего узла или конечного набора данных после данного узла. Таким образом, указатели 454 и 458 аналогичны низкому указателю и высокому указателю 42 и 45 соответственно, которые описаны выше. Изменение терминологии просто объясняет тот факт, что один указатель сопровождается, если ключ-кандидат включает битовую последовательность выбора, а другой указатель сопровождается, если ключ-кандидат не имеет последовательности битов решения.

- 16 006562

Фиг. 15 иллюстрирует процедуру вставки ключа в древовидную структуру. Эта процедура очень похожа на процедуру, описанную по отношению к фиг. 8, и на ней для краткости те же позиции используются для аналогичных частей. Однако стадия 152 изменена и обозначена как стадия 152', поскольку изменена проверка того, содержится ли последовательность битов решения узла принятия решений в ключе, и, если это так, управление передается на стадию 154', на которой сопровождается указатель включения. Затем управление переходит к стадии 156. Если стадия 152 находит, что ключ-кандидат не содержит последовательности битов решения, то управление передается на стадию 158', на которой сопровождается указатель исключения. Дополнительное изменение в процедуре имеется на стадии 162, где можно указывать непосредственно на ввод стадии 152', пропуская, таким образом, стадии 164 и 166. Однако в других отношениях процедура вставки ключа происходит, как было описано выше.

Процедура для удаления ключа, показанная на фиг. 16, также очень похожа на описанную выше, и снова сходные позиции используются для сходных частей. Как и в случае с процедурой вставки ключа, стадии 152, 154 и 158 изменяются и обозначаются как стадии 152', 154' и 158', описанные со ссылкой на фиг. 13. Стадия 152 проверяет, включает ли ключ-кандидат последовательность битов решения, и если это так, то сопровождается указатель включения, в противном случае сопровождается указатель исключения. Кроме того, здесь стадия 162 указывает непосредственно на вход стадии 152', исключая, таким образом, стадии 164 и 166.

Конечно, для точного совпадения запроса ключа индексом можно управлять. На фиг. 17 показана процедура навигации для возврата точного запроса ключа. Процедура очень похожа на описанною выше со ссылкой на фиг. 10 и, как и прежде, аналогичные стадии будут обозначены теми же позициями, чтобы избежать повторения, за исключением факта изменения стадий 152, 154 и 158, в результате чего стадия 152' теперь сравнивает ключ-кандидат с последовательностью битов решения, и если последовательность битов решения находится в ключе-кандидате, управление передается на стадию 154', на которой сопровождается указатель включения, в противном случае управление переходит к стадии 158', на которой сопровождается указатель исключения. Кроме того, стадия 162 теперь непосредственно указывает на вход стадии 152'.

На фиг. 18 показана процедура перемещения от узла со списком шаблонов (Ь) и возвратом результата (В). Процедура начинается на стадии 500, на которой вводится пусковой узел. Затем управление передается на стадию 502, на которой проверяется, содержится ли последовательность битов решения в списке шаблонов (Ь). Если результат проверки отрицателен, управление передается на стадию 504, на которой проверяется, выходит ли указатель исключения из узла решений. Если указатель исключения существует, управление передается на стадию 506, на которой проверяется, указывает ли указатель на другой узел решений, и если это так, управление передается на стадию 508; в противном случае управление передается на стадию 510. Стадия 508 инициирует выбор следующего узла решений, и процедура обхода осуществляется рекурсивным способом на стадии 512. На стадии 512 управление переходит к стадии 514. Кроме того, если проверка на стадии 502 приводит к заключению, что последовательность битов решения содержится в перечне шаблонов, управление переходит на стадию 514, аналогично, управление также переходит на стадию 514, если стадия 504 указывает, что указателя исключения не существует.

На стадии 510 выполняется переход к конечному набору данных, указанному указателем и проверенным на стадии 506, после чего поиск делается через конечный набор данных на стадии 516. Процедура поиска будет далее описана со ссылкой на фиг. 19. От стадии 516 управление передается на стадию 514. Стадия 514 проверяет, существует ли указатель включения, и если это так, управление передается на стадию 518, в противном случае управление передается на стадию 520, которая представляет собой выход из процедуры. Стадия 518 проверяет, указывает ли указатель на следующий узел решений, и если это так, управление передается на стадию 522, на которой процедура повторяется снова рекурсивным способом, в противном случае управление передается на стадию 524, на которой осуществляется переход к конечному набору данных, указанному указателем. От стадии 524 поиск конечного набора данных выполняется на стадии 526, которая аналогична стадии 516. На стадии 526 и 522 указывается переход к стадии выхода, стадия 528 представляет собой окончание процедуры.

На фиг. 19 представлена схема, иллюстрирующая процедуру поиска на стадиях 516 и. 526. Эта процедура вводится в стадию 530, на которой управление переходит к стадии 532. Стадия 532 проверяет, является ли конечный набор данных пустым, и если это так, процедура передается на стадию 534, в противном случае управление передается на стадию 536. Стадия 536 выбирает первый ключ в конечном наборе данных и затем управление передается на стадию 538, на которой проверяется, содержит ли ключ каждый шаблон в списке шаблонов. Если это так, управление передается на стадию 540, в противном случае управление передается на стадию 542. На стадии 540 ключ и его свойства передаются от конечного набора данных в список результатов. Затем управление передается на стадию 542. Стадия 542 проверяет, является ли текущий ключ последним ключом в конечном наборе данных, и если да, то процедура заканчивается на стадии 544, в противном случае управление передается на стадию 546. Стадия 546 выбирает следующий ключ в конечном наборе данных и возвращает управление на стадию 538.

- 17 006562

На фиг. 20 схематически показано, как выполняется поиск диапазона, используя базу данных, представляющую собой вариант настоящего изобретения. Предположим, что узел 560 имеет битовую комбинацию ВЕ, хранящуюся в этом узле, а узел 562 имеет битовую комбинацию ОН. Когда узел опрашивается словами Ред, Фред, Билл и Джон, слова, Ред и Фред направляются по включающему пути к следующему узлу 564, а слова Билл и Джон направляются по исключающему пути к узлу 562. Узел 562 направляет слово Билл по исключающему пути и слово Джон по включающему пути, поскольку оно содержит битовую комбинацию ОН.

Если база данных опрашивается, используя поисковую карту, например, используя строку поиска *гсй*. в которой * представляет собой мультисимвол поисковой карты, то узел 560 может определить, что исключающий путь к узлу 562 не нужно искать и, следовательно, поиск может быть ограничен маршрутом, включающим узел 564. Однако, если индекс опрашивается, используя поисковый термин *1ар*, то узел 560 не может определить, находится ли битовая комбинация ВЕ в строке поиска (поскольку она может находиться в поисковой карте) и, следовательно, индекс должен выполнять поиск по включающему и исключающему путям.

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

Сжатие ключа

В обычных базах данных весь ключ хранится в каждом узле решений. Хотя в описанном выше изобретении часть ключа хранится в каждом узле решений, длина этой части не ограничена. Заявитель нашел, что дальнейшая экономия места может быть достигнута, сохраняя не весь ключ или части ключа в первоначальном виде, а выражение ключа, полученное в результате процесса преобразования. Алгоритмы хеш-кода, типа СВС32 и Ай1ег 32 хорошо известны и предлагают функцию преобразования величин кодирующего ключа. Эти алгоритмы работают на длинной битовой последовательности, чтобы получить более короткую битовую последовательность. Алгоритм преобразования является детерминированным в том смысле, что если входная битовая последовательность всегда одна и та же, полученная битовая последовательность тоже всегда одна и та же. Однако преобразование не может быть однозначным из-за высокой степени сжатия и, следовательно, несколько входных последовательностей будут преобразованы в гораздо более короткую выходную последовательность. Тем не менее, учитывая это обстоятельство, структуры индекса могут быть значительно уменьшены. Таким образом, при перемещении древовидного графа для ключа-кандидата используется обычный способ обхода за исключением того, что величина А(К) используется вместо К, где А - функция преобразования, используемая для древовидного графа.

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

Следовательно, необходимо проверить введенные данные в конечном наборе данных и исключить те, которые не соответствуют оригинальному ключу. Это может быть сделано, удерживая оригинальный ключ в конечном наборе данных и сравнивая эти ключи с первоначальным поисковым ключом, чтобы исключить те термины, которые не согласуется с ним. Однако можно сэкономить место, кодируя ключи в конечном наборе данных со вторым алгоритмом кодирования В, которой отличается от А. Вероятность неправильного преобразования поискового ключа по двум идентичным величинам преобразования по обоим алгоритмам преобразования очень невелика и, следовательно, маловероятно, что будут получены некорректные данные. Действительно, вероятность ложного совпадения приблизительно один к В2, где В - размер диапазона функции преобразования. Оба преобразованных ключа А и В хранятся в конечном наборе данных, поскольку это облегчает повторное преобразование конечного набора данных, если он достигнет своего максимального размера.

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

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

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

Ограниченный ключ

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

- 18 006562 использования. Применение модуля к ключу типа строки символов требует, чтобы строка обрабатывалась как очень большое беззнаковое целое число, первый символ которого является наиболее значащим байтом в величине целого числа, к которому применяется вычисление по модулю.

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

На фиг. 22 представлена схема, иллюстрирующая возможности, которые предлагает изобретение, когда оператор желает выполнить поиск по диапазону, в отличие от точного совпадения, описанного выше. Минимальные и максимальные поисковые ключи для данного диапазона представлены как Ь (нижний) и и (верхний) соответственно. Эти ключи существуют в неограниченной или неотображаемой области поиска 580 как показано на фиг. 22. Ключи выбираются по модулю в процессе 582, чтобы преобразовать их в ограниченный диапазон индекса. Он не может гарантировать, что порядок ключей будет сохранен после процесса преобразования. Здесь имеются две возможности. Во-первых, как показано в преобразованном наборе, схематично обозначенном как 584, нижний ключ преобразования имеет величину меньше, чем величина преобразования верхнего ключа. Если дело обстоит именно так, то индекс направляется к конечному набору данных, используя стандартные способы навигации индекса. Однако, что также рассмотрено и схематично показано набором 586, нижний ключ МЬ может иметь величину больше величины преобразованного верхнего ключа Ми. В этом примере поиск должен быть сделан по всем конечным наборам данных, имеющим кодированные величины, которые больше или равны минимальному кодированному ключу МЬ. Этот поиск выполняется, используя стандартные способы навигации. Кроме того, поиск должен быть сделан для всех конечных наборов данных, имеющих кодированные величины, которые меньше чем или равны максимальному кодированному ключу МИ. Еще раз отметим, это выполняется, используя стандартные способы навигации.

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

Переходные ключи

На фиг. 23 представлена схема, иллюстрирующая структуру конечного набора данных или блока 600, представляющего вариант настоящего изобретения. Конечный набор данных содержит базу возраста 602, которая содержит дату и время самой последней модификации в конечном наборе данных 600. Он также содержит множество входов ключа 604, 606 и 608. Рассмотрим для простоты только вход ключа 608, который далее разделен на три части, а именно, возрастной вход 608А, информация о входе ключа 608В и информация свойств входа 608С.

Когда сделан переходной вход, он имеет связанный с ним входные данные возраста 608А. Эти данные относятся к возрастному блоку и возрастному пределу, которые могут быть установлены для индекса в целом, но произвольно могут быть установлены для отдельных конечных наборов данных. Возрастной блок определяет число секунд в отдельном возрастном блоке. Таким образом, например, величина 60 подразумевает одну минуту, тогда как 86400 подразумевает один день. Возрастной предел представляет число возрастных блоков, после которого ключ может быть вынут из индекса. Как правило, оно лежит в диапазоне от 1 до 254, позволяя, таким образом, уложиться в слово из 8 бит. Таким образом, если ключ установлен на истечение после 31 дня, возрастной блок устанавливается на 86400 секунд, а возрастной предел устанавливается на 31. Для ключей, срок действия которых истекает после одного дня, возрастной блок и возрастной предел могут быть набраны на 3600 секунд и 24, соответственно.

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

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

Любой такой вход затем становится доступным для повторного использования. Затем возрастная база устанавливается на дату и время, отмеченные в начале процедуры. Любой ключ, который будет вставлен в слот в конечном наборе данных, устанавливается на нуль в возрастном входе. Имеющийся слот может быть либо слотом, которой еще не был распределен, либо слотом, которой устарел (поскольку его возраст входа достиг 255). Кроме того, возраст любого обновленного входа приводится к нулю.

- 19 006562

В вышеупомянутом варианте возраст входа хранится как одиночный байт. Это дает диапазон в 254 промежутков времени, в которых тип данных может стать устаревшим. Можно использовать больше одного байта, что дает более широкий диапазон возрастных пределов, но только за счет увеличения объема памяти. Альтернативно можно использовать меньше одного байта для возраста входа, уменьшая, таким образом, объем памяти, но это также уменьшает диапазон возрастных пределов, которые могут быть определены индивидуально.

Таким образом, можно создать улучшенную базу данных.

Разбиение графа решений

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

Известно, что запоминающие устройства большой емкости типа жесткого диска делятся на блоки предопределенного размера файла, хотя файл любого размера меньше, чем размер блока, тем не менее, занимают весь блок. Таким образом, физическая память используется в объемах, кратных размеру блока. При чтении и записи графа решений в такую память, предпочтительно, чтобы граф решений был структурирован таким образом, чтобы он в максимально возможной степени был бы записан в виде одного блока. Таким образом, наиболее вероятно, что граф решений будет постоянно находиться в блоке памяти. Однако по мере заполнения индекса граф решений растет вместе с заполнением ключа. Следовательно, наступит время, когда становится невозможным разместить граф решений в одном блоке. В результате потребуется разместить граф решений в нескольких блоках.

Обращаясь к фиг. 24, предположим, что блок памяти 700 представляет физический размер блока на жестком диске компьютерной системы, и что этот блок разделен, чтобы хранить отдельные части 702, 704, 706 и 708 среди других, каждая из которых относится к данным относительно соответствующего узла в графе решений. Кроме того, предположим, что индекс достиг такого размера, что блок полностью заполнен.

Теперь предположим, что при операции ввода в базу данных требуется вставить следующий узел в граф решений. Вставка узла может происходить в любой точке. Как отмечено выше, каждый узел решений (фиг. 3) включает величину решения, низкий указатель и высокий указатель, которые указывают на следующий узел в графе. В результате, местные изменения в графе могут быть сделаны таким образом, что новый узел может быть вставлен после любого существующего узла. Предположим теперь, что требуется вставить новый узел после узла, чьи данные представлены элементом данных 706. Во-первых, поскольку новый узел уже вставлен, один из указателей выхода узла 706 изменяется, чтобы указать на новый узел. Как часть процесса вставки выходные указатели нового узла также установлены правильно, в результате чего граф решений не будет нарушен. Однако, учитывая, что больше невозможно хранить данные, относящиеся к новому узлу 710, в блоке памяти 700, детали, относящиеся к новому узлу 710, должны храниться в следующем блоке 712. Последующие узлы должны учитывать, что новый узел также может быть создан, и информация должна храниться в блоке памяти 712.

Если позднее потребуется вставить новый узел, относящийся к ранее существующему узлу 708, блок памяти снова переполняется и следовательно детали следующего нового узла 714 должны храниться вне блока памяти. Этот процесс позволяет увеличивать объем графа принятия решений, но может привести к созданию большого количества почти пустых блоков памяти от каждого заполненного (родительского) блока.

На фиг. 25 показан альтернативный способ роста индекса. Снова предположим, что блок памяти 700 заполнен и требуется вставить новый узел. Как и прежде, должен быть создан новый блок памяти для графа. Однако теперь родительский граф решений разбит на равные части. Одна часть помещена в старый блок 700, а другая часть помещена в новый блок 712.

Со ссылкой на фиг. 25 предположим, что индекс 720 хранится в блоке памяти 700 и что этот блок теперь переполнен. Предположим также, что вставка индекса приведет к созданию нового узла 722 и что эта операция приведет к переполнению блока памяти 700 данными индекса. Однако в этом способе управления роста индекса структура индексов анализируется, чтобы разбивать его, в основном, одинаково между индексными блоками. Таким образом, просматривая часть индекса, показанного на фиг. 25, можно видеть, что, начиная от узла 724, десять узлов, окруженные пунктирной линией 726, могут быть достигнуты по пути налево от узла 724, тогда как двенадцать узлов, окруженные пунктирной линией 728, могут быть найдены на пути, проходящим направо от узла 724. Алгоритм рекурсивно сканирует структуру индекса, выбирая проверяемый узел и затем вычисляя узлы, зависящие от них, чтобы найти подходящего узла-кандидата для разбиения индекса. В примере, показанном на фиг. 25, узел 724 и узлы, окруженные линией 726, были бы помещены в старый блок памяти, тогда как узлы, окруженные пунктирной линией 728, были бы помещены в новый блок памяти. Этот процесс гарантирует, что каждый блок памя

- 20 006562 ти используется оптимально и эффективно и останавливает быстрое увеличение, в основном, пустых блоков памяти.

Указатели

Часто желательно, чтобы поиск в индексе был выполнен с использованием двух или нескольких критериев поиска. Эти критерии, в основном, объединены на принципах Булевой алгебры.

Она может быть использована для запроса, которой будет разделен на отдельные части, причем каждая часть выполняется прежде чем следующая с последующим объединением конечных результатов. Однако это может потребовать очень большого объема вычислений и частых обращений чтения-записи к блоку памяти данных типа жесткого диска. Так, например, запрос, на который выдается 100 ответов, мог бы затем потребовать еще 100 медленных операций ввода-выхода с диском, чтобы выбрать указатель данных на запрос индекса.

Не все данные, выданные по запросу, могут потребоваться. Например, если сделать запрос в базу данных, чтобы найти все автомобили, зарегистрированные в 1997 году под маркой Мерседес, будет выдано много тысяч результатов. Однако только небольшое их число будет относиться к настоящим Мерседесам. Кроме того, для многих запросов можно изменить порядок запроса таким способом, который позволяет уменьшить число нежелательных результатов.

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

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

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

Во время запроса основной ключ дополняется нулевым или несколькими значащими описательными ключами. Индекс перемещается, используя основной ключ, как и ранее. Наконец, как только достигнут правильный конечный набор или наборы данных, они сканируются, сравнивая величину основного ключа и хеш-коды описательного ключа с введенными данными в конечном наборе данных. Принимаются только те введенные данные, которые соответствуют всем основным ключам и всем хеш-кодам описательных ключей.

Отметим, что множественные описательные ключи могут быть преобразованы в одиночный байт. Следовательно имеется небольшая, но конечная вероятность того, что будут выданы и нежелательные данные. Однако, при предположении, что используются надежное хеширование при кодировании, вероятность неправильного совпадения равна одному из 255 (или менее 0,5%). Отметим, что настоящее изобретение гарантирует возврат всех правильных результатов, но также с небольшим процентом неправильных результатов. Таким образом, все ключевые ответные справки должны затем быть проверены в памяти данных, чтобы удалить любой из нежелательных входов. Однако сокращение размера индекса и упрощение обработки запроса более чем компенсирует дополнительную проверку ответных справок. Это преимущество возрастает, когда используются несколько описателей, при условии, что вероятность получения неправильных ответных справок уменьшается с увеличивающемся числом описателей. Вероятность плохого результата при идеальных обстоятельствах равна (1/255)Ν. Таким образом, с двумя описателями (N=2) вероятность плохого результата 1 из 65025 или меньше чем 0,002%. С тремя описателями, шанс возвращения неправильного элемента данных уменьшает приблизительно до 14 миллионов к 1.

Следует отметить, что размер поискового ключа и требования к хранению данных в конечных наборах данных значительно снижены. Таким образом, если была задача поиска в 8 промежутках времени, каждый из которых мог бы иметь длину 8 байтов, это традиционно потребует хранения 64 байтов данных для каждого поискового ключа. В настоящем изобретении это требование снижено до 15 байтов данных.

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

Следует отметить, что эта описательная методика может применяться к любым структурам индекса, например к известным структурам типа В-дерева. На фиг. 26 схематически представлен формат поискового ключа в совпадении с этим вариантом настоящего изобретения, в котором первая часть ключа содержит первичные данные ключа, а оставшаяся часть ключа включает описатели р1, 02 и так далее до

- 21 006562

Р7, каждый из которых - слово длиной 1 байт, полученное хешированием первоначальных дополнительных ключей.

Сравнение с шаблоном

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

Эффективность такого поиска зависит от того, как хорошо разделено заполнение ключа в каждом узле в графе решений.

Проблема с набором символов А8СП состоит в том, что он включает 255 символов и вероятность появления сходных символов является очень высокой, хотя комбинации двойных символов весьма редки.

Заявитель понял, что сравнение с шаблоном может быть значительно улучшено, если набор символов А8СП (или реально эквивалентный набор) преобразован в меньший набор.

Заявитель определил число преобразований, которые уменьшают набор до 16 символам так, что одиночный символ соответствует четырем битам (0-15), тогда как две последовательности символов могут соответствовать одному байту.

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

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

Фонетический набор

Символы А8СП	Преобразованная Величина ,
Гласные (А, Е, Ь, 0, и)	Удалены
Цифры (0, 1, 2, 3, 4, 5, 6, 7, 8, 9)	Удалены
Знаки пунктуации	Удалены
Пробел, Табуляция	0
в	1
с,к, ц	2
о	3
Р	4
о, э	5
н	6
к	7
ь	8
Μ,Ν	9
Р	10
К	И
8, Ζ	12
т	13

V______________________________________________________К.14 \У_________________________________________________________15_______

X, Υ Удалены

Сходства

Символы А8СП	Преобразованная Величина
Пробел, Табуляция	0
Знаки пунктуации · .	1 .
Цифры (0, 1,2,3,4,5,6, 7, 8, 9)	2
Гласные (А, Е, Г, О, и)	3
в, о	4
с, к	5
Р,Р	6
О, I	7
Η, Υ	8
к, ь	9
Μ.,Ν	10
Ρ.Ω	11
К, 8	12
т	13
V, λν	14
χ,ζ	15

- 22 006562

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

Использование уменьшенного набора позволило значительно улучшить характеристики сравнения с шаблоном.

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

Claims

ФОРМУЛА ИЗОБРЕТЕНИЯ

1. Способ кодирования ключей в базе данных, отличающийся тем, что данные ключа хранятся по меньшей мере в одном конечном наборе данных в хешированном виде, чтобы уменьшить область памяти для хранения ключей.
2. База данных, в которой данные ключа хранятся по меньшей мере в одном конечном наборе данных в кодируемом виде, чтобы уменьшить область памяти ключей.
3. Способ организации базы данных, отличающийся тем, что ключ, используемый для навигации, представляет собой сложный ключ, а один или несколько ключей в базе данных представлены в сжатом виде.
4. Способ по п.3, отличающийся тем, что первичный ключ не сжат, а последующие ключи сложного ключа сжаты.
5. Способ по п.3 или 4, отличающийся тем, что каждый сжатый ключ действует как описатель, который служит для облегчения поиска в базе данных.
6. Способ по п.5, отличающийся тем, что индекс перемещается, используя первичный ключ до тех пор, пока не будет получен конечный набора данных, и результаты конечного набора данных проверяются, используя описатель.
7. Способ по п.3, отличающийся тем, что ключи сжимаются, используя функцию хеширования.