База данных для хранения документов кратко
Обновлено: 05.07.2024
Значительная часть программного обеспечения — будь то ПО для банков, страховых организаций, фондов, денежного рынка, платежных сервисов — разрабатывается на основе базы данных.
Но многие разработчики испытывают трудности при выборе подходящей БД: иногда лучший выбор действительно не очевиден. Если реляционные и нереляционные базы данных сразу приходят на ум, то о системах управления базами данных (СУБД) часто забывают или не знают разницу между ними.
Восполним этот пробел и простыми словами расскажем, какие решения существуют на рынке СУБД, из каких продуктов стоит выбирать и как сделать правильный выбор в соответствии с решаемыми задачами.
Вот список наиболее часто используемых СУБД:
В конце статьи приведена резюмирующая таблица с кратким описанием того, в каких случаях подходит конкретный тип СУБД и какие популярные решения существуют. Так что самые нетерпеливые могут перейти прямо к таблице.
Отметим, что у ряда крупных поставщиков имеется по нескольку типов СУБД — в виде отдельных продуктов или внутренних реализаций.
Типы СУБД. Как выбрать правильный?
Реляционная СУБД
Это классическая система, которая чаще используется для создания OLTP-решений (обработка транзакций в реальном времени), когда СУБД работает с большим количеством маленьких транзакций. Системе требуется короткое время отклика и возможность отменять любые изменения, сделанные во время транзакции при определенных условиях.
Реляционная СУБД подойдет для создания системы, предназначенной для хранения значительного числа сущностей — таблиц — с различными типами отношений между ними (один к одному, один ко многим, многие ко многим).
Самые известные реляционные СУБД:
- Oracle;
- Microsoft SQL;
- PostgreSQL;
- MySQL;
- IBM DB2.
Когда следует выбирать реляционную базу данных?
Во-первых (1), при высокой нормализации данных. А во-вторых (2), при обработке большого количества коротких транзакций, среди которых немалый процент транзакций с вставкой.
Когда не следует выбирать реляционную СУБД?
Графовая СУБД
Это особый тип СУБД для работы с графами, их узлами и свойствами, а также произвольными отношениями между узлами.
Простой пример — создание приложений типа соцсетей, где нужно хранить соединения между пользователями (узлами) в соответствии с критериями: общие интересы, коллеги, родственники.
Самые известные графовые СУБД:
- Neo4j;
- Amazon Neptune;
- InfiniteGraph;
- InfoGrid.
Когда следует выбирать графовую базу данных?
1) При создании соцсети или реализации рейтинговой и рекомендательной системы и 2) при глубоком понимании графов и их назначения.
Когда не следует выбирать графовую базу данных?
Почти во всех остальных случаях.
Документная СУБД
Документная или документоориентированная СУБД — это одна из самых популярных разновидностей нереляционных СУБД. В качестве базовой единицы логической модели данных у нее структурированный текст со специфическим синтаксисом (документ).
Считается, что модели данных документных и объектно-ориентированных БД аналогичны. Это так, хотя разница все же есть: документные БД не хранят поведение объектов, а только их состояние. Документные СУБД активно развиваются — некоторые даже поддерживают проверку схемы.
Самые известные документные СУБД:
- CouchDB;
- MongoDB;
- Amazon DocumentDB.
Когда следует выбирать документную БД?
У документной СУБД широкий диапазон применения: от 1) компактной БД для одного микросервиса до 2) крупномасштабных решений в качестве хранилища состояния.
Лучше хранить объекты в одной сущности, но с разными структурами. Кстати, очень полезны они и 3) для хранения структур (включая объекты, списки и словари), особенно в JSON-подобном формате.
Когда не следует выбирать документную СУБД?
Документная система не подходит для реализации модели транзакций и, конечно, это не лучшее решение для формирования отчетов.
Столбцовая СУБД
Столбцовая СУБД очень непохожа на реляционную: хотя так же состоит из сгруппированных в таблицы строк с атрибутами и по логической модели мало чем от нее отличается — на уровне физического хранилища имеет существенные различия.
Реляционная СУБД хранит данные построчно. То есть для считывания значения конкретного столбца приходится считывать почти всю строку — от первого до этого столбца.
Столбцовая СУБД хранит данные по столбцам. То есть столбец предстает в виде отдельной таблицы. А считывание выполняется прямо из конкретного столбца. На самом деле работает очень быстро — протестировано на нескольких реализованных хранилищах данных.
Преимущества столбцовой СУБД:
- эффективно выполняет сложные аналитические запросы для большого объема данных;
- простое и почти мгновенное реструктурирование таблиц с данными;
- существенное сжатие, которое экономит много места.
Самые известные столбцовые СУБД:
- Sybase IQ (SAP IQ);
- Vertica;
- ClickHouse;
- Google BigQuery;
- InfoBright;
- Apache Druid.
Когда следует выбирать столбцовую БД?
1) При создании хранилища данных и осуществлении выборки со сложными аналитическими вычислениями. 2) Когда количество запрашиваемых строк превышает сотни миллионов.
Когда не следует выбирать столбцовую СУБД?
1) Когда количество строк в таблице, из которой делаются запросы, меньше сотен миллионов. Здесь у столбцовой СУБД перед реляционной преимуществ будет немного.
2) Когда запросы достаточно простые и со статичными параметрами. В этом случае — учитывая специфику системы — столбцовая СУБД будет неэффективна.
К тому же у столбцовой СУБД есть и другие ограничения. Например, язык запросов может отличаться от классического SQL или отсутствует поддержка транзакций.
Это одна из простейших СУБД, что-то вроде таблицы с уникальным ключом и связанным значением, в котором может быть что угодно. Такие СУБД чаще всего используются для кеширования, потому что они быстры — ведь есть уникальный ключ и запрос возвращает только одно значение.
Когда 1) в БД хранится много сущностей (таблиц), имеющих сложные структуры с разными типами данных. Когда 2) надо выполнять сложные запросы, возвращающие много строк.
СУБД временных рядов
Эта СУБД оптимизирована для хранения данных с метками времени или данных временных рядов. Данные временных рядов содержат измерения или события, которые отслеживаются, собираются или объединяются за определенный период времени.
Это данные с датчиков отслеживания движения, метрики JVM из приложений на Java, данные о рыночной торговле, сетевые данные, ответы от API, время безотказной работы процесса и т. д.
Данные хранятся с метками времени — это ключевая особенность — и индексируются и записываются так, чтобы данные этого временного ряда запрашивались намного быстрее, чем при использовании в классической реляционной БД.
Самые известные СУБД временных рядов:
Когда следует выбирать СУБД временных рядов?
Основная область применения таких СУБД — мониторинг, обработка телеметрии и финансовые системы.
Когда не следует выбирать СУБД временных рядов?
Воздержитесь от использования такой СУБД в задачах, не связанных с временными рядами и метками времени.
Объектно-ориентированная СУБД
Эта СУБД предназначена для хранения и обработки объектов. Как и в ООП (объектно-ориентированном программировании), у этих объектов в СУБД есть свойства и методы. И они тоже реализуют инкапсуляцию и полиморфизм.
Главная цель применения объектно-ориентированной СУБД — облегчить жизнь разработчикам, использующим модель объектного программирования. Им не придется преобразовывать объекты в таблицы и строки со связями и обратно.
Самые известные объектно-ориентированные СУБД:
- MongoDB Realm ;
- InterSystems Caché ;
- ObjectStore ;
- Actian NoSQL DB ;
- Objectivity/DB .
Когда следует выбирать объектно-ориентированную СУБД?
Вообще-то не доводилось видеть много успешных реализаций с такими СУБД. Объектно-ориентированные базы данных обычно рекомендуется использовать при 1) высокопроизводительных манипуляциях с объектами, имеющими сложную структуру.
В то же время разработка 2) предполагает применение объектно-ориентированных языков программирования. Объектно-ориентированные БД распространены в системах реального времени, архитектуре и инженерии для 3D-моделирования, телекоммуникациях и научных продуктах, молекулярной науке и астрономии.
Когда не следует выбирать объектно-ориентированную СУБД?
1) При использовании классического языка SQL, 2) когда не применяется ООП или 3) при переходе на другую БД. И 4) при отсутствии глубокого понимания ООП. Тогда стоит выбрать документную СУБД.
Поисковая СУБД
Этот тип СУБД используется для осуществления полнотекстового поиска. А также поиска по различным данным, например из других БД, электронной почты, RSS-канала, текста, JSON, XML, CSV и даже PDF и документам MS Office.
Поисковая СУБД имеет собственные оптимизированные подходы к индексированию данных, в том числе использование так называемых инвертированных и фасетных индексов для поиска почти в реальном времени.
Различные СУБД этого типа применяют разные языки запросов.
Самые известные поисковые СУБД:
Когда следует выбирать поисковую СУБД?
Идеальные примеры — подходящие для быстрого полнотекстового поиска в различных источниках данных системы сбора и поиска по журналам структурированных, полуструктурированных и неструктурированных данных.
Когда не следует выбирать поисковую СУБД?
При поиске по ограниченному числу полей структурированных данных.
СУПБД (система управления пространственными базами данных)
Этот тип СУБД оптимизирован для работы с объектами, определенными в геометрическом пространстве — как простыми (точки, кривые, многоугольники), так и сложными (3D-объекты, топологическое покрытие, линейные сети).
СУПБД имеет набор специальных функций для обработки создания, преобразования, измерения (расстояние, площадь, объем), вычисления (пересечение/контакт) и выбора на основе определенных критериев. И содержит специальные индексы, оптимизирующие обработку объектов, и особый стандартизированный язык SQL/MM.
Самые известные СУПБД:
Когда следует выбирать СУПБД?
При создании ГИС-решений — не только для хранения, но и для работы с геометрическими объектами на уровне СУПБД.
Когда не следует выбирать СУПБД?
Для хранения геометрических объектов в качестве координат.
Заключение
Определиться с выбором СУБД бывает нелегко, ведь их так много! Надеемся, вы немного прояснили для себя этот вопрос и теперь легко выберите подходящую.
Хотите создать сложное решение? Тогда понадобится несколько типов СУБД. И не торопитесь с выбором поставщиков СУБД: обычно это тема второстепенная.
Выбирайте тип СУБД на основе следующих трех факторов:
- тип решаемых задач;
- типы обрабатываемых данных;
- перспективы роста и масштабирование.
Обратите внимание на популярные СУБД — такой выбор гарантирует наличие большого разнообразия инструментов разработки и единомышленников, которые помогут быстро найти решение возникающих вопросов.
Любые данные где-то хранятся. Будь это интернет вещей или пароли в *nix. Показываем схемы основных типов баз данных, чтобы наглядно представить различия между ними.
Типы баз данных, называемых также моделями БД или семействами БД, представляют собой шаблоны и структуры, используемые для организации данных в системе управления базами данных (СУБД). Выбор типа повлияет на то, какие операции сможет выполнять приложение, как будут представлены данные, на функции СУБД для разработки и рантайма.
Начнём с трёх типов БД, которые всё ещё могут встречаться в специализированных средах, но в основном заменены надежными и производительными альтернативами.
1. Простые структуры данных
Первый и простейший способ хранения данных – текстовые файлы. Метод применяется и сегодня для работы с небольшими объёмами информации. Для разделения полей используется специальный символ: запятая или точка с запятой в csv-файлах датасетов, двоеточие или пробел в *nix-подобных системах:
/etc/passwd в *nix системе
- ограничен тип и уровень сложности хранимой информации;
- трудно установить связи между компонентами данных;
- отсутствие функций параллелизма;
- практичны только для систем с небольшими требованиями к чтению и записи;
- используются для хранения конфигурационных данных;
- нет необходимости в стороннем программном обеспечении.
- /etc/passwd и /etc/fstab в *nix-системах
- csv-файлы
2. Иерархические базы данных
Пример построения иерархических связей
3. Сетевые базы данных
Сетевые базы данных расширяют функциональность иерархических: записи могут иметь более одного родителя. А значит, можно моделировать сложные отношения.
Пример связей в сетевой базе данных
- сетевые базы данных представляются не деревом, а общим графом
- ограничены теми же шаблонами доступа, что иерархические БД
4. SQL базы данных
Реляционные базы данных – старейший тип до сих пор широко используемых БД общего назначения. Данные и связи между данными организованы с помощью таблиц. Каждый столбец в таблице имеет имя и тип. Каждая строка представляет отдельную запись или элемент данных в таблице, который содержит значения для каждого из столбцов.
- поле в таблице, называемое внешним ключом, может содержать ссылки на столбцы в других таблицах, что позволяет их соединять;
- высокоорганизованная структура и гибкость делает реляционные БД мощными и адаптируемыми ко различным типам данных;
- для доступа к данным используется язык структурированных запросов (SQL);
- надёжный выбор для многих приложений.
- хранилища обеспечивают быстрый и малозатратный доступ;
- часто хранят данные конфигураций и информацию о состоянии данных, представленных словарями или хэшем;
- нет жёсткой схемы отношения между данными, поэтому в таких БД часто хранят одновременно различные типы данных;
- разработчик отвечает за определение схемы именования ключей и за то, чтобы значение имело соответствующий тип/формат.
6. Документная база данных
- база данных не предписывает опредёленный формат или схему;
- каждый документ может иметь свою внутреннюю структуру;
- документные БД являются хорошим выбором для быстрой разработки;
- в любой момент можно менять свойства данных, не изменяя структуру или сами данные.
7. Графовая база данных
Вместо сопоставления связей с таблицами и внешними ключами, графовые базы данных устанавливают связи, используя узлы, рёбра и свойства.
Графовые базы представляют данные в виде отдельных узлов, которые могут иметь любое количество связанных с ними свойств.
- выглядят аналогично сетевым;
- фокусируются на связях между элементами;
- явно отображает связи между типами данных;
- не требуют пошагового обхода для перемещения между элементами;
- нет ограничений в типах представляемых связей.
8. Колоночные базы данных
Колоночные базы данных (также нереляционные колоночные хранилища или базы данных с широкими столбцами) принадлежат к семейству NoSQL БД, но внешне похож на реляционные БД. Как и реляционные, колоночные БД хранят данные, используя строки и столбцы, но с иной связью между элементами.
- БД удобны при работе с приложениями, требующими высокой производительности;
- данные и метаданные записи доступны по одному идентификатору;
- гарантировано размещение всех данных из строки в одном кластере, что упрощает сегментацию и масштабирование данных.
9. Базы данных временных рядов
Базы данных временны́х рядов созданы для сбора и управления элементами, меняющимися с течением времени. Большинство таких БД организованы в структуры, которые записывают значения для одного элемента. Например, можно создать таблицу для отслеживания температуры процессора. Внутри каждое значение будет состоять из временной метки и показателя температуры. В таблице может быть несколько метрик.
- ориентированы на запись;
- предназначены для обработки постоянного потока входных данных;
- производительность зависит от количества отслеживаемых элементов, интервала опроса между записью новых значений и фактической полезной нагрузки данных.
NewSQL и многомодельные БД являются разными типами баз данных, но решают одну группу проблем, вызванных полярными подходами SQL или NoSQL-стратегии. Почему бы не объединить преимущества обеих групп?
10. NewSQL базы данных
NewSQL базы данных наследуют реляционную структуру и семантику, но построены с использованием более современных, масштабируемых конструкций. Цель – обеспечить большую масштабируемость, нежели реляционные БД, и более высокие гарантии согласованности, чем в NoSQL. Компромисс между согласованностью и доступностью является фундаментальной проблемой распределённых баз данных, описываемой теоремой CAP.
- возможность горизонтального масштабирования;
- высокая доступность;
- большая производительность и репликация;
- небольшой функционал и гибкость;
- немалое потребление ресурсов и необходимость специализированных знаний для работы с базой данных.
11. Многомодельные базы данных
Многомодельные базы данных – базы, объединяющие функциональные возможности нескольких видов БД. Преимущества такого подхода очевидны – одна и та же система может использовать различные представления для разных типов данных.
Совместное размещение данных из нескольких типов БД в одной системе позволяет выполнять новые операции, которые в противном случае были бы затруднены или невозможны. Например, многомодельные базы могут позволить юзерам получить доступ к данным, хранящимся в разных типах БД, и управлять ими в рамках одного запроса, а также поддерживают согласованность данных при выполнении операций, изменяющих информацию сразу в нескольких системах.
- помогают уменьшить нагрузку на СУБД;
- позволяют расширяться до новых моделей по мере изменения потребностей без внесения изменений в базовую инфраструктуру;
- обеспечивают непрерывный доступ и простое распределение данных;
- имеют линейную масштабируемость и просты для разработки.
Заключение
Изменение типов хранимых данных, требования к скорости и производительности привели и к продолжающемуся расширению типов баз данных. При этом каждый из них продолжает быть нужным в своей нише, где взаимосвязи между данными ассоциируются с определенной схемой строения базы данных.
Электронные документы проще и быстрее формировать, отправлять и обрабатывать. Они ускоряют рабочие процессы и экономят ресурсы. Поэтому бизнес и контролирующие органы активно переходят на электронный документооборот.
Электронные документы также проще хранить, потому что не нужно содержать помещение и тратить время сотрудников на сортировку и поиск. Однако хранение электронных документов тоже требует соблюдения правил и обеспечения технической возможности. Информацию нужно правильно оформлять, защищать от системных сбоев и внешних вмешательств.
В статье разберем способы и правила хранения электронных документов, особенности и преимущества облачных архивов, а также расскажем, как выбрать подходящий сервис хранения.
Способы хранения электронных документов
Электронные документы хранят на флешках или дисках. Это самый ненадежный способ. Носитель легко потерять или повредить, он может прийти в негодность со временем. Безопасность информации при таком способе самая низкая — защиту диска или флешки легко взломать.
Не требует установки ПО, комплексных настроек и больших затрат. Обеспечивает нужный уровень защиты, хранит документы по правилам закона. Позволяет настроить функции под нужды бизнеса, управлять ролями сотрудников. Для доступа к данным необходим стабильный интернет.
Обычно это папка на компьютере, например, бухгалтера, к которому имеют доступ некоторые сотрудники. Это самый простой, но небезопасный способ. Компьютер может сломаться, тогда все данные будут утеряны. А еще простой защиты папки недостаточно, чтобы уберечь информацию от изменений, утери или копирования. Даже модератор документов не обеспечивает должный уровень безопасности и управляемости. Еще один минус — правила хранения и организации локального архива. Нужно потратить немало времени, чтобы обучить сотрудников работе с собственным архивом.
Обычно это архив при системе электронного документооборота (СЭД) или отдельное ПО, которые обеспечивают нужный уровень защиты, оперативный доступ, понятную структуру и правила хранения. Но для многих компаний и предпринимателей способ может быть избыточным, потому что требует отдельного ПО, настройки и немалых затрат. Поэтому чаще всего бизнес выбирает облачный электронный архив.
Электронные документы хранят на флешках или дисках. Это самый ненадежный способ. Носитель легко потерять или повредить, он может прийти в негодность со временем. Безопасность информации при таком способе самая низкая — защиту диска или флешки легко взломать.
Обычно это папка на компьютере, например, бухгалтера, к которому имеют доступ некоторые сотрудники. Это самый простой, но небезопасный способ. Компьютер может сломаться, тогда все данные будут утеряны. А еще простой защиты папки недостаточно, чтобы уберечь информацию от изменений, утери или копирования. Даже модератор документов не обеспечивает должный уровень безопасности и управляемости. Еще один минус — правила хранения и организации локального архива. Нужно потратить немало времени, чтобы обучить сотрудников работе с собственным архивом.
Обычно это архив при системе электронного документооборота (СЭД) или отдельное ПО, которые обеспечивают нужный уровень защиты, оперативный доступ, понятную структуру и правила хранения. Но для многих компаний и предпринимателей способ может быть избыточным, потому что требует отдельного ПО, настройки и немалых затрат. Поэтому чаще всего бизнес выбирает облачный электронный архив.
Не требует установки ПО, комплексных настроек и больших затрат. Обеспечивает нужный уровень защиты, хранит документы по правилам закона. Позволяет настроить функции под нужды бизнеса, управлять ролями сотрудников. Для доступа к данным необходим стабильный интернет.
Для всех перечисленных способов требования и правила со стороны закона идентичные.
Далее процессы и особенности хранения электронных документов мы будем рассматривать на примере облачных архивов.
Но даже электронный обмен не избавляет от необходимости где-то учетную документацию хранить, поэтому хранение электронных документов в организации – весьма актуальный вопрос на сегодня. Хранение документов в электронном виде должно быть очень хорошо организовано и защищено, ведь сбой такой системы грозит потерей годами накопленной информации за прошедшие периоды.
Рис.1 Схема архивного хранения ЭД
Способы хранения документов
Можно выделить три основных способа хранения архивов, при этом неважно, какое количество документов необходимо хранить, как часто проводится обмен документами с архивом и сколько сотрудников планирует с таким архивом работать.
Локальный архив. Доступный и простой способ хранения документации, которым, тем не менее, сложно управлять. Такой архив представляет собой папку на локальном ПК, к которой все сотрудники имеют доступ с возможностью вложить в папку файл, но без права на удаление файлов из этой папки.
Существует также модератор, которому предоставлена возможность удалить файлы. Модератор следит, чтобы вложения файлов сотрудниками происходило по четко определенным правилам. Основная проблема такого архива в том, что каждый сотрудник, включая новых сотрудников организации, который имеет к нему доступ, должен знать все правила работы с ним. Также нет гарантий безопасности такого архива.
Облачное хранилище. Предоставляется оператором ЭДО, который хранит все ваши данные в закрытом доступе по определенным паролям, заранее согласованным с оператором. Имеется возможность разграничения доступа, а также можно согласовать политику хранения документации. Основной минус в том, что для доступа к файлам необходимо интернет-соединение. Если его нет, то файлы не будут доступны.
Хранилище системы электронного документооборота. Такие системы изначально создаются для поддержки внутреннего документооборота, но ничто не мешает использовать их и для целей внешнего. Такой метод решает множество проблем. Например, файлы находятся на внутренних серверах и к ним всегда есть доступ. Все пользователи имеют доступ к архиву на чтение, т.к. запись файлов выполняет сама система. Система же может использовать помещенные в архив файлы для повторного открытия пользователей, сохраняя связи. При этом всегда можно ограничить определенным группам доступ к определенным документам.
Правила и сроки хранения электронных документов
С 01.10.2017 внесены изменения в формы и правила заполнения (ведения) счетов-фактур, книг покупок и книг продаж, журнала учета счетов-фактур, утв. постановлением Правительства РФ от 26.12.2011 № 1137. Основным изменением стала обязанность и продавцов, и покупателей хранить данные бухгалтерские документы в хронологическом порядке по мере их выставления или получения за соответствующий налоговый период.
Электронные счета-фактуры должны храниться совместно:
- С квалифицированным сертификатом ключа подписи, применявшимся для их формирования (п. 1.13 Порядка выставления и получения счетов-фактур в электронной форме виде, утв. приказом Минфина России от 10.11.2015 № 174н);
- С подтверждениями оператора электронного документооборота и извещениями покупателей о получении счета-фактуры (п. 10 Правил заполнения счета-фактуры). При этом следует учитывать, что извещение о получении счета-фактуры формируется покупателем.
Конкретный срок хранения счетов-фактур (как бумажных, так и цифровых) не установлен ни нормами НК РФ, ни нормами Постановления № 1137.
Однако журнал учета полученных и выставленных счетов-фактур, книга покупок и книга продаж вместе с дополнительными листами к ним должны храниться не менее 4 лет с даты последней записи (п. 13 Правил ведения журнала учета, п. 24 Правил ведения книги покупок, п. 22 Правил ведения книги продаж, утв. постановлением Правительства РФ от 26.12.2011 № 1137). Кроме того, согласно пп. 8 п. 1 ст. 23 НК РФ, общий срок хранения документов, необходимых для исчисления и уплаты налогов, составляет 4 года. То есть ЭСФ (равно как и бумажные) необходимо сохранять в течение четырех лет.
Рис.2 Хранение финансовой отчетности
Требования ГОСТ к хранению электронных документов
В теории электронный архив подразумевает банальное сохранение необходимой информации, но на практике существуют некоторые требования, которым должен соответствовать процесс сохранения документов в электронном виде.
Как и для бумажного архива, должны быть обеспечены:
- Читабельность документа. Изображения имеют разные форматы, могут сжиматься и конвертироваться. Все эти действия снижают читабельность документа, что со временем может повлечь его полную утрату.
- Наличие маркировки или иных общепринятых обозначений для быстрой идентификации документа по определенным признакам. Поиск по годами формировавшимся массивам документов чаще всего сопряжен с требованием предоставления отчетности в государственные органы, поэтому обеспечить его оперативность – важнейшее требование к хранилищу.
- Установка связи между архивными документами. Приложение к основному документу должно быть либо прикреплено непосредственно к нему, либо на него должна быть актуальная ссылка, при переходе по которой можно открыть нужный документ.
- Регулярное перезаписывание или переформатирование. Обеспечивает сохранность документа, т.к. технологии развиваются, и если сегодня определенный формат актуален и поддерживается каждым приложением, то уже через несколько лет формат хранилища может оказаться устаревшим и его поддержка сторонними приложениями закончится.
Все эти и другие нормы регламентируются ГОСТ Р 54989-2012/ISO/TR 18492. Это национальный стандарт, но он был разработан, ориентируясь на международный стандарт ISO.
Читайте также: