Механизм актуализации записи — различия между версиями

Материал из Wikipedia
Перейти к: навигация, поиск
Строка 1: Строка 1:
 +
==Механизм актуализации записи до версии ИРБИС 2011.1 включительно==
 +
 
Механизм актуализации записи до версии ИРБИС 2011.1 включительно:
 
Механизм актуализации записи до версии ИРБИС 2011.1 включительно:
 
* рассматриваются две копии актуализируемой записи: последняя копия (т.е. актуальное состояние записи после корректировки) и предыдущая копия (т.е. состояние записи до выполнения корректировки, или точнее - то состояние записи, для которого выполнялась предыдущая актуализация);
 
* рассматриваются две копии актуализируемой записи: последняя копия (т.е. актуальное состояние записи после корректировки) и предыдущая копия (т.е. состояние записи до выполнения корректировки, или точнее - то состояние записи, для которого выполнялась предыдущая актуализация);
Строка 11: Строка 13:
 
понятно, что это не поле 100 - а то поле, чья метка указана в поле 100 текущей записи.)
 
понятно, что это не поле 100 - а то поле, чья метка указана в поле 100 текущей записи.)
  
−
И тем не менее, для решения "хитрой" задачи предлагается следующее. Вводится новая структура - дополнительная по отношению к таблице инвертирования. Будем называть ее ТАБЛИЦА АКТУАЛИЗАЦИИ - IFS (именно такое расширение предлагается для соответствующего файла). Таблица актуализации создается ИСКЛЮЧИТЕЛЬНО на основе таблицы инвертирования (каким образом - об этом ниже) и является ее ОДНОЗНАЧНЫМ следствием ("придатком"). Отличие таблицы актуализации от таблицы инвертирования только лишь в структуре первого элемента (если смотреть через Редактор РЛ - это первая колонка). В таблице инвертирования это т.н. "точка входа". В таблице актуализации - в первом элементе дополнительно к точке входа указываются (через запятую) МЕТКИ полей, имеющих отношение к данной строке (т.е. метки тех полей, которые используются в соответствующем формате - третьем элементе таблицы).
+
==Таблица актуализации==
 +
 
 +
И тем не менее, для решения "хитрой" задачи предлагается следующее. Вводится новая структура - дополнительная по отношению к [[Таблица выбора полей#ТВП для инвертированного файла|таблице выбора полей для инвертированного файла]]. Будем называть ее ''таблица актуализации''. Таблица актуализации как отдельная структура сохраняется в текстовом файле с расширением [[Файлы ИРБИС#Таблица актуализации|<tt>.ifs</tt>]].
 +
 
 +
Таблица актуализации создается ИСКЛЮЧИТЕЛЬНО на основе таблицы инвертирования (каким образом - об этом ниже) и является ее ОДНОЗНАЧНЫМ следствием ("придатком"). Отличие таблицы актуализации от таблицы инвертирования только лишь в структуре первого элемента (если смотреть через Редактор РЛ - это первая колонка). В таблице инвертирования это т.н. "точка входа". В таблице актуализации - в первом элементе дополнительно к точке входа указываются (через запятую) МЕТКИ полей, имеющих отношение к данной строке (т.е. метки тех полей, которые используются в соответствующем формате - третьем элементе таблицы).
  
 
Схематичный пример строки таблицы инвертирования:  
 
Схематичный пример строки таблицы инвертирования:  
Строка 21: Строка 27:
 
Понятно, что такая структура таблицы актуализации позволяет легко решать задачу отбора строк инвертирования, имеющих отношение к изменившимся полям.  
 
Понятно, что такая структура таблицы актуализации позволяет легко решать задачу отбора строк инвертирования, имеющих отношение к изменившимся полям.  
  
−
Механизм актуализации записи, действующий начиная с версии ИРБИС 2012.1:  
+
==Механизм актуализации записи, действующий начиная с версии ИРБИС 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 информацию на форуме].)
  
 
==Ссылки==
 
==Ссылки==

Версия 17:17, 24 января 2013

Механизм актуализации записи до версии ИРБИС 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

Механизм актуализации записи, действующий начиная с версии ИРБИС 2012.1:

  • сравниваются последняя и предыдущая копии записи - в результате определяются метки изменившихся полей;
  • из таблицы актуализации отбираются строки, имеющие отношение к изменившимся полям и на их основе формируется временная (создаваемая налету для конкретной записи) таблица инвертирования;
  • отрабатывает "старый" механизм актуализации на основе временной таблицы инвертирования.

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

Файл <имя_БД>.fst остаётся обязательным в структуре базы данных, в отличие от таблицы актуализации <имя_БД>.ifs. (См. также информацию на форуме.)

Ссылки

См. также:

Источники информации:

Источник — «http://wiki.elnit.org/index.php?title=Механизм_актуализации_записи&oldid=1546»