DA/T 82-2019 in English
VALIDSpecification for storage of archival data based on document-oriented non-relational database
- Issued on:2019-12-16
- Implemented on:2020-05-01
- File Format:PDF
- Delivery:Via email within 1~3 business days
$243.00
本标准规定了使用文档型数据库存储档案数据的总体要求,提出了使用文档型数据库存储和管理档案数据的基本功能和实施方法.
本标准适用于各级各类档案馆、机关、团体、企业事业单位对档案数据的存储.
Introduction
Standard Background and Technological Evolution
As archival data becomes large-scale, multi-format, and unstructured, traditional relational databases are limited in terms of storage flexibility. DA/T 82-2019 standard came into being, establishing document-based database as a new paradigm for archival data storage. Its technical evolution path is as follows:
| Dimension | Relational database | Document database |
|---|---|---|
| Data structure | Strict two-dimensional table | Dynamic document model |
| Field extensibility | Requires pre-definition | Increase and decrease on demand |
| Content storage | Separate storage | Embedded storage |
Core term analysis
Document database: A non-relational database that stores data objects in JSON/BSON format. Typical representatives include MongoDB, CouchDB, etc. Its core features include:
- Document is the smallest processing unit (such as a single archive and its metadata)
- Supports nested data structures
- No fixed table structure restrictions
Storage implementation specifications
Field type requirements
Chapter 4 of the standard clearly stipulates that document-based databases must support six basic fields:
| Field type | Storage content | Example |
|---|---|---|
| Binary field | Digital copy | Scanned image/audio/video |
| Text field | Archive description information | Title/Abstract |
Hybrid storage strategy
Clause 3.4 of the standard proposes a complementary storage solution:
Case: A provincial archives uses MongoDB to store original electronic archives, and uses Oracle to manage catalog metadata, establishing associations through unique identifiers.
Key technology implementation
Data import quality control
Standard clause 6.3 stipulates that a three-level verification mechanism must be established:
- Format pre-check (file type/field format)
- Integrity check (hash value comparison)
- Log tracking (operation audit)
Database splitting strategy
When implementing horizontal splitting according to clause 7.1, two methods are recommended:
| Method | Applicable scenarios | Advantages |
|---|---|---|
| Record number segmentation | Continuously numbered archives | High splitting efficiency |
| Capacity balance | Heterogeneous data | Storage load balancing |
Implementation recommendations
Selection evaluation matrix
According to clauses 3.1-3.3 of the standard, it is recommended to evaluate from three dimensions:
- Scalability: Single document supports binary storage of more than 16MB
- Openness: Provide standard API interface
- Security: Support field-level encryption
Migration path planning
Referring to clause 6.2.4 of the standard, it is recommended to implement in stages:
- Pilot period: Select non-structured data such as photo archives for migration first
- Promotion period: Establish a two-way synchronization mechanism between relational and document databases
Loading PDF document...
Error loading PDF. Please make sure the file is valid and try again.
We also recommend
-
DA/T 23-2000 in English
Detailed rules for the description of geological data files
2000-12-06 -
DA/T 6-1992 in English
Archive Fixtures
1992-07-20
