Cтраница 4
Индексирование последовательного текста связано с решением двух взаимосвязанных проблем: какая информация в действительности нужна пользователю и как найти место для ее хранения. Было бы неправильно подходить к индексированию текста так же, как к индексированию значений отдельных полей записи. На первый взгляд вроде неплохо, но вряд ли Вам поможет индекс в конце книги, где будет записано Проблемы, 56, Проблемы в чем. Бесполезно также индексировать каждое слово в абзаце. Представьте себе базу данных, в которой индексированы все служебные слова. Конечно, этого делать не надо, и интересующие нас слова встречаются гораздо реже других слов, но по какому критерию их отбирать. Если мы условимся, что вероятность появления в тексте коротких служебных слов превышает X % и поэтому надо индексировать слова, которые встречаются реже, то как быть со словом поэтому, индексировать которое тоже не имеет смысла. Очевидно, надо оказать помощь индексатору и попытаться автоматизировать процесс. Он, а чаще она, просматривает текст и отмечает слова, которые могут интересовать читателя. Затем ЭВМ хеширует отмеченные слова и помещает кодовые обозначения в 5-дерево вместе с указателями записи, в которой содержится сам текст. Возможен вариант, когда индексатор заранее составляет список разрешенных ключевых слов. СУБД затем отыскивает в заданном тексте ключевые слова. Например, нефтедобывающая компания может использовать базу данных о своих многочисленных эксплуатационных буровых скважинах. Запись о каждом объекте содержит описание геологической структуры в зоне скважины. Прежде чем пробурить первую скважину и ввести информацию о ней в базу данных, разработчики системы уже решили, что термины, подобные терминам лигнит, оолит, падение пласта, необходимо индексировать. Применение списка разрешенных ключевых слов возможно, если пользователи уверены в том, что слова, которые они ищут, индексированы, не говоря уже о том, что эти слова вообще есть в базе данных. [46]
Индексирование последовательного текста связано с решением двух взаимосвязанных проблем: какая информация в действительности нужна пользователю и как найти место для ее хранения. Было бы неправильно подходить к индексированию текста так же, как к индексированию значений отдельных полей записи. На первый взгляд вроде неплохо, но вряд ли Вам поможет индекс в конце книги, где будет записано Проблемы, 56, Проблемы в чем. Бесполезно также индексировать каждое слово в абзаце. Представьте себе базу данных, в которой индексированы все служебные слова. Конечно, этого делать не надо, и интересующие нас слова встречаются гораздо реже других слов, но по какому критерию их отбирать. Если мы условимся, что вероятность появления в тексте коротких служебных слов превышает X % и поэтому надо индексировать слова, которые встречаются реже, то как быть со словом поэтому, индексировать которое тоже не имеет смысла. Очевидно, надо оказать помощь индексатору и попытаться автоматизировать процесс. Он, а чаще она, просматривает текст и отмечает слова, которые могут интересовать читателя. Затем ЭВМ хеширует отмеченные слова и помещает кодовые обозначения в 5-дерево вместе с указателями записи, в которой содержится сам текст. Возможен вариант, когда индексатор заранее составляет список разрешенных ключевых слов. СУБД затем отыскивает в заданном тексте ключевые слова. Например, нефтедобывающая компания может использовать базу данных о своих многочисленных эксплуатационных буровых скважинах. Запись о каждом объекте содержит описание геологической структуры в зоне скважины. Прежде чем пробурить первую скважину и ввести информацию о ней в базу данных, разработчики системы уже решили, что термины, подобные терминам лигнит, оолит, падение пласта, необходимо индексировать. Применение списка разрешенных ключевых слов возможно, если пользователи уверены в том, что слова, которые они ищут, индексированы, не говоря уже о том, что эти слова вообще есть в базе данных. [47]