Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
240277_DD9BE_baranov_a_n_vvedenie_v_prikladnuyu....doc
Скачиваний:
30
Добавлен:
20.11.2018
Размер:
2.81 Mб
Скачать

4.2. Типы информационно-поисковых систем

По типу хранимой и обрабатываемой информации, а также по осо­бенностям поиска ИПС разделяются на две больших группы — докумен­тальные и фактографические. В документальных ИПС хранятся тексты документов или их описания (рефераты, библиографические карточки и пр.). До последнего времени обычной формой представления данных в документальных ИПС был реферат (или другое краткое описание до­кумента) и его библиографические данные. В этом массиве, который называется первым документальным контуром, и проводился основной по­иск. Первичные документы хранились отдельно на бумаге или микрофи­шах. Массив первичных документов называется вторым документальным контуром. В настоящее время в связи с развитием ИПС бестезаурусного типа и появлением новых продуктивных способов архивации данных, а также новых типов памяти ЭВМ (оптические диски большой емко­сти) различие между первым и вторым контурами стирается: в память ЭВМ вводятся и сам текст документа, и его сокращенные аналоги. Для этих целей разрабатываются международные стандарты. Сейчас получил широкое распространение стандарт ISO 2709 (ГОСТ 7.14-84), который, кроме текста документа, предполагает наличие маркера записи (включает характеристики, относящиеся ко всей записи) и справочника (характе­ристики внутренней структуры документа).

Фактографические ИПС имеют дело с описанием конкретных фак­тов, причем не обязательно в текстовой форме. Это могут быть таблицы, формулы и пр. Существуют и смешанные ИПС, включающие как до­кументы, так и фактографическую информацию. В настоящее время фактографические ИПС строятся на основе технологий баз данных (БД). С теоретической точки зрения база данных представляет собой совокуп­ность признаков описываемых объектов с указанием отношений между ними. В качестве описываемого объекта может выступать, например, книга, телефонный номер и пр. Объект в базе данных характеризует­ся по признакам или атрибутам. Так, книга может иметь следующие атрибуты: 1) автор; 2) название; 3) год выхода; 4) издательство; 5) ти­раж; 6) объем. Телефонный номер может характеризоваться по фамилии владельца, месту его проживания, сумме абонементной оплаты и т.д.

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

Для создания структуры данных, ввода информации в реляционные БД и ее обработки создаются специальные программные средства — системы управления базами данных (СУБД). С программной точки зре­ния каждый объект в реляционной БД представляется в виде отдельной записи (record). Атрибутам объекта в записи соответствуют поля (fields). Поиск может происходить по всем полям БД. Типы полей различаются. Основная проблема заключается в том, что у полей записи (кроме полей типа «memo») ограничена и фиксирована длина поля. Так, для поля типа «text» она не должна превышать 255 знаков. Иными словами, атрибуты объекта описания в БД должны быть внимательно проанализированы, чтобы поле не было избыточным по длине, поскольку это значительно увеличивает объем используемой памяти ЭВМ. Дело в том, что незапол­ненные фрагменты поля все равно заносятся в память. С другой стороны, поле не должно быть и излишне коротким, иначе часть информации невозможно будет ввести в БД. Ср. структуру реляционной базы данных по политической метафорике, разработанной в Институте русского языка РАН, и пример записи в этой базе данных:

Структура базы данных по политической метафорике

Название поля: METAPHOR (метафора) Тип поля Text — 90 знаков

Название поля: SIGNIF_DES (сигнификативный дескриптор — метафорическая модель)

Тип поля Text — 100 знаков

Название поля: DENOT_DES (денотативный дескриптор — политическая реалия)

Тип поля Text — 100 знаков

Название поля: EXAMPLE

Тип поля Memo27)

Название поля: DATE

Тип поля Date/Time

Название поля: NEWSPAPER

Тип поля Text — 10 знаков

Название поля: AUTHOR

Тип поля Text — 30 знаков

Запись 900

METAPHOR (метафора)

ПОЛИТИЧЕСКАЯ КУХНЯ

SIGNIF_DES (сигнификативный дескриптор — метафорическая модель)

КУХНЯ

DENOT_DES (денотативный дескриптор — политическая реалия)

ПОЛИТИКА

EXAMPLE

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

DATE

01.11.93

NEWSPAPER

Собеседник

AUTHOR

Соколов М.

27)В реляционных БД типа FOX, D-Base, ACCESS поле Memo не ограничено по длине.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]