Механизм актуализации записи - История изменений

Sokv в 21:17, 4 сентября 2015

2015-09-04T21:17:41Z

Sokv в 10:58, 30 мая 2014

2014-05-30T10:58:44Z

Sokv в 14:17, 24 января 2013

2013-01-24T14:17:16Z

Sokv в 15:28, 23 января 2013

2013-01-23T15:28:14Z

Sokv: Новая страница: «Механизм актуализации записи до версии ИРБИС 2011.1 включительно: * рассматриваются две копи…»

2013-01-23T14:25:41Z

Новая страница: «Механизм актуализации записи до версии ИРБИС 2011.1 включительно: * рассматриваются две копи…»

Новая страница

Механизм актуализации записи до версии ИРБИС 2011.1 включительно:
* рассматриваются две копии актуализируемой записи: последняя копия (т.е. актуальное состояние записи после корректировки) и предыдущая копия (т.е. состояние записи до выполнения корректировки, или точнее - то состояние записи, для которого выполнялась предыдущая актуализация);
* обе копии записи подвергаются обработке (в оперативной памяти) в соответствии с таблицей инвертирования данной БД (<имя_БД>.FST). Обработка состоит в том, что копии записи форматируются по КАЖДОЙ строке таблицы инвертирования (см. структуру FST) и в соответствии с методами инвертирования создаются списки терминов. В результате - формируются два списка терминов: один - связанный с предыдущей копией записи, другой - с последней копией;
* два списка терминов (после сортировки) сравниваются. В результате: а) термины, являющиеся общими для обоих списков отбрасываются (не рассматриваются), б) термины, оставшиеся в списке последней копии (т.е. те термины, которые присутствовали в списке последней копии и отсутствовали в списке предыдущей копии) ДОБАВЛЯЮТСЯ в словарь БД, в) термины, оставшиеся в списке предыдущей копии (т.е. те термины, которые присутствовали в списке предыдущей копии и отсутствовали в списке последней копии) УДАЛЯЮТСЯ из словаря.

Нетрудно понять, что данный механизм имеет существенный недостаток, связанный с нечувствительностью к тому, КАКИЕ и СКОЛЬКО полей записи подвергались изменению (корректировке). Т.е. если изменялись все или большинство полей записи (или точнее – большинство тех полей, которые участвуют в инвертировании), этот механизм эффективен; если же изменялось одно или несколько полей (а именно это имеет место на практике при работе с библиографическими БД) - механизм малоэффективен. И уж совсем "впустую" он работает в тех случаях, когда изменялись только те поля, которые не участвуют в инвертировании (т.е. те, по которым не создаются словари).
Проиллюстрировать это можно на следующем примере. При корректировке записи изменялось только поле 910 (экземпляры). В этом случае форматирование последней и предыдущей копий записи по строкам таблицы инвертирования, не имеющим отношения к полю 910, заведомо бессмысленно, поскольку сформированные в результате этого термины окажутся общими для обоих списков и будут отброшены. Имеет смысл использовать только те строки таблицы инвертирования, которые имеют отношение к полю 910. Но этого не происходит - старый механизм "тупо" обрабатывает ВСЕ строки таблицы инвертирования и тратит время на ненужное форматирование. Таким образом, идея нового механизма актуализации лежит как будто на поверхности: определять, какие поля в записи изменялись (сравнивая последнюю и предыдущую копии записи) и отбирать из таблицы инвертирования только те строки, которые имеют отношение к изменившимся полям.
(Все именно так - только надо сразу видеть и "обратную сторону", т.е. недостатки нового механизма: в случае изменения всех или большинства полей записи впустую уже будет тратиться время на сравнение копий и отбор строк из таблицы инвертирования.)
Процесс сравнения копий (с целью выявления изменившихся полей) - очевиден и его реализация не вызывает никаких проблем. А вот задача отбора строк таблицы инвертирования, имеющих отношение к изменившимся полям, более "хитрая".(И даже более того - в силу изощренности языка форматирования ИРБИС эта задача алгоритмически строго говоря вообще неразрешима. Вот пример - разумеется, чисто теоретический - строки таблицы FST, по которой нельзя определить, к какому полю она относится:
100 0 ....&uf('AV',f(val(v100),0,0),'#1').....
понятно, что это не поле 100 - а то поле, чья метка указана в поле 100 текущей записи.)

И тем не менее, для решения "хитрой" задачи предлагается следующее. Вводится новая структура - дополнительная по отношению к таблице инвертирования. Будем называть ее ТАБЛИЦА АКТУАЛИЗАЦИИ - IFS (именно такое расширение предлагается для соответствующего файла). Таблица актуализации создается ИСКЛЮЧИТЕЛЬНО на основе таблицы инвертирования (каким образом - об этом ниже) и является ее ОДНОЗНАЧНЫМ следствием ("придатком"). Отличие таблицы актуализации от таблицы инвертирования только лишь в структуре первого элемента (если смотреть через Редактор РЛ - это первая колонка). В таблице инвертирования это т.н. "точка входа". В таблице актуализации - в первом элементе дополнительно к точке входа указываются (через запятую) МЕТКИ полей, имеющих отношение к данной строке (т.е. метки тех полей, которые используются в соответствующем формате - третьем элементе таблицы).

Схематичный пример строки таблицы инвертирования:
100 0 .....v100......v200......v300....

Ей будет соответствовать следующая строка таблицы актуализации:
100,100,200,300 0 .....v100......v200......v300....

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

Механизм актуализации записи, действующий начиная с версии ИРБИС 2012.1:
* сравниваются последняя и предыдущая копии записи - в результате определяются метки изменившихся полей;
* из таблицы актуализации отбираются строки, имеющие отношение к изменившимся полям и на их основе формируется временная (создаваемая налету для конкретной записи) таблица инвертирования;
* отрабатывает "старый" механизм актуализации на основе временной таблицы инвертирования.

Необходимо отметить, что по понятным причинам при актуализации (т.е. сохранении) НОВОЙ записи (у которой нет никаких предыдущих копий), а также при УДАЛЕНИИ и РАЗУДАЛЕНИИ записи будет применяться старый механизм актуализации.
Логичен вопрос: зачем поддерживать две структуры - таблицу инвертирования и таблицу актуализации, почему нельзя отказаться от таблицы инвертирования и применять только новую структуру - таблицу актуализации. Ответ очевиден: исключительно для соблюдения принципа наследования. Т.е. если в структуре БД присутствует таблица актуализации (<имя_БД>.IFS) , будет применяться новый механизм актуализации, в противном случае - старый механизм.

(Необходимо сразу отметить, что при полном создании словаря используется ТОЛЬКО таблица инвертирования - <имя_БД>.FST - т.е. этот файл остается ОБЯЗАТЕЛЬНЫМ в структуре БД, в отличие от таблицы актуализации <имя_БД>.IFS, которая может отсутствовать).

==Ссылки==

См. также:
* [[Базы данных ИРБИС]]
* [[Полнотекстовые базы данных ИРБИС]]
* [[Язык форматирования системы ИРБИС]]
* [[Язык запросов ИРБИС]]
* [[Инвертированный файл]]

Источники информации:
* {{Ссылка на открытый FTP|filename=RELEASE_12_1.doc|text=Файл описания релиза 2012.1}}

[[Категория:Языки и алгоритмы ИРБИС]]
[[Категория:Базы данных ИРБИС]]
[[Категория:Анонсированные статьи]]

@@ Строка 42: / Строка 42: @@
 См. также:
-* [[Базы данных ИРБИС]]
+* [[Индекс базы данных ИРБИС]]
 * [[Язык форматирования системы ИРБИС]]
 * [[Язык запросов ИРБИС]]
 Источники информации:
 * {{Ссылка на открытый FTP|filename=RELEASE_12_1.doc|text=Файл описания релиза 2012.1}}
-[[Категория:Языки и алгоритмы ИРБИС]]
+[[Категория:Индекс базы данных ИРБИС]]
 [[Категория:Анонсированные статьи]]

@@ Строка 1: / Строка 1: @@
 Механизм актуализации записи до версии ИРБИС 2011.1 включительно:
 * рассматриваются две копии актуализируемой записи: последняя копия (т.е. актуальное состояние записи после корректировки) и предыдущая копия (т.е. состояние записи до выполнения корректировки, или точнее - то состояние записи, для которого выполнялась предыдущая актуализация);
@@ Строка 11: / Строка 13: @@
 понятно, что это не поле 100 - а то поле, чья метка указана в поле 100 текущей записи.)
-И тем не менее, для решения "хитрой" задачи предлагается следующее. Вводится новая структура - дополнительная по отношению к таблице инвертирования. Будем называть ее ТАБЛИЦА АКТУАЛИЗАЦИИ - IFS (именно такое расширение предлагается для соответствующего файла). Таблица актуализации создается ИСКЛЮЧИТЕЛЬНО на основе таблицы инвертирования (каким образом - об этом ниже) и является ее ОДНОЗНАЧНЫМ следствием ("придатком"). Отличие таблицы актуализации от таблицы инвертирования только лишь в структуре первого элемента (если смотреть через Редактор РЛ - это первая колонка). В таблице инвертирования это т.н. "точка входа". В таблице актуализации - в первом элементе дополнительно к точке входа указываются (через запятую) МЕТКИ полей, имеющих отношение к данной строке (т.е. метки тех полей, которые используются в соответствующем формате - третьем элементе таблицы).
+==Таблица актуализации==
 Схематичный пример строки таблицы инвертирования:
@@ Строка 21: / Строка 27: @@
 Понятно, что такая структура таблицы актуализации позволяет легко решать задачу отбора строк инвертирования, имеющих отношение к изменившимся полям.
-Механизм актуализации записи, действующий начиная с версии ИРБИС 2012.1:
+==Механизм актуализации записи, действующий начиная с версии ИРБИС 2012.1==
 * сравниваются последняя и предыдущая копии записи - в результате определяются метки изменившихся полей;
 * из таблицы актуализации отбираются строки, имеющие отношение к изменившимся полям и на их основе формируется временная (создаваемая налету для конкретной записи) таблица инвертирования;
@@ Строка 27: / Строка 35: @@
 Необходимо отметить, что по понятным причинам при актуализации (т.е. сохранении) НОВОЙ записи (у которой нет никаких предыдущих копий), а также при УДАЛЕНИИ и РАЗУДАЛЕНИИ записи будет применяться старый механизм актуализации.
-Логичен вопрос: зачем поддерживать две структуры - таблицу инвертирования и таблицу актуализации, почему нельзя отказаться от таблицы инвертирования и применять только новую структуру - таблицу актуализации. Ответ очевиден: исключительно для соблюдения принципа наследования. Т.е. если в структуре БД присутствует таблица актуализации (<имя_БД>.IFS) , будет применяться новый механизм актуализации, в противном случае - старый механизм.
+Логичен вопрос: зачем поддерживать две структуры - таблицу инвертирования и таблицу актуализации, почему нельзя отказаться от таблицы инвертирования и применять только новую структуру - таблицу актуализации. Ответ очевиден: исключительно для соблюдения принципа наследования. Т.е. если в структуре БД присутствует таблица актуализации (<имя_БД>.IFS), будет применяться новый механизм актуализации, в противном случае - старый механизм.
-Несмотря на то, что в описании релиза указано, что ''при полном создании словаря используется ТОЛЬКО таблица инвертирования - <имя_БД>.FST - т.е. этот файл остается ОБЯЗАТЕЛЬНЫМ в структуре БД, в отличие от таблицы актуализации <имя_БД>.IFS, которая может отсутствовать'', тем не менее практика показывает, что при полном создании словаря также используется таблица актуализации <tt>.ifs</tt>. См., например, [http://irbis.gpntb.ru/read.php?3,76647 сообщения на форуме на данную тему].
+Файл <tt><имя_БД>.fst</tt> '''остаётся обязательным''' в структуре базы данных, в отличие от таблицы актуализации <tt><имя_БД>.ifs</tt>. (См. также [http://irbis.gpntb.ru/read.php?3,76647 информацию на форуме].)
 ==Ссылки==