Advanced Search

Notice Of Archiving Versions

Original Language Title: Bekendtgørelse om arkiveringsversioner

Subscribe to a Global-Regulation Premium Membership Today!

Key Benefits:

Subscribe Now for only USD$40 per month.
Table of Contents

Appendix 1

Appendix 2

Appendix 3

Appendix 4

Appendix 5

Appendix 6

Appendix 7

Appendix 8

Completion of Archive Versions

In accordance with paragraph 5 (2), Paragraph 13, paragraph 13. 1, and Section 14 of the notice No 591 of 26. June 2003 on public archives and public archives and after discussion with the local authorities and regional partners shall be :

Area

§ 1. The provisions of this notice shall apply to archivalists created by the public administration and the courts, and which, by the State Archives, are intended for conservation.

§ 2. The processing of data from IT systems and audio and video shall be made in the form of archiving versions.

Paragraph 2. The State Archives may, for conservation reasons, fix the fact that the preservation of other archivalists is to be made in the form of archiving versions.

§ 3. An archiving version of the dignible data must be prepared according to the instructions issued by the impeachment product, cf. Annex 2-8.

Paragraph 2. The rigging archives may show other conservation form other than an archiving version, obtained from the instructions in Annex 2-8, provided that the conservation of the conservation of the conservation is concerned.

Production and delivery

§ 4. The production and delivery of archiving versions of data from the state administration and the IT systems of the courts must be held at times to be determined by the State Archives.

§ 5. The production and delivery of archiving versions of data from the IT systems of the local authorities and regions, which contain personal data, must be carried out before the data is deleted. The municipality or region concerned may reach agreement on past times with the receiving archive.

Paragraph 2. The production of archiving versions of data from other IT systems must be carried out before the data is deleted or when the IT system is taken out of use.

Paragraph 3. The State Archives may, in addition, provide for the production of an archiving version of data from an IT system when it is necessary to maintain the conservation of the conservation requirements.

§ 6. Archiving versions of state authorities data must be approved by the State Archives. Archiving versions of the local authority and regional authorities must be approved by the receiving archive ; archiving versions of the dignible local authority and regional data not covered by the obligation to deliver shall be approved by the same public ; archive, which shall be provided by the competent authority of the authority to deliver archiving versions.

Paragraph 2. Data that was passed to an archiving version must not be deleted from the authority until the archiving version has been approved.

Entry into force, etc.

§ 7. The announcement shall enter into force on 1. September, 2010.

Paragraph 2. Publication no. 342 of 11. March 2004 on the filing versions of the conservation worthy data from electronic archiving systems are hereby repealed.

Paragraph 3. Publication no. 302 of 16. April 2009 on the delivery of audio and video is lifted.

Paragraph 4. For and with 1. July 2011, an agreement may be concluded with a public record that the archiving version of data is drawn up in accordance with the rules laid down in paragraph 1. 2 mentioned proclations.

Paragraph 5. Archive versions of data in accordance with the rules laid down in paragraph 1. 2 that notice shall be delivered to the public archive before 31. December 2011.

Paragraph 6. The rigging archivist may, on application, grant a derogation to the rules referred to in paragraph 1. 4 and 5.

Rigsarchived, the 20th. August 2010

Asbjorn Hellum

/ Kirsten Villadsen Kristmar

Appendix 1

Appendix 1 List of annexes
Appendix 2 Graphical view of elements and structure of an archiving version
Appendix 3 Archiving version of the IT system data and any documents
3.A. General rules for archiving versions
3.B. Data structure
3.C. Data content
3D. Information about the archiving version
Appendix 4 Data structure
4.A. General rules for data structure
4.B. Location of folders and files
4.C. Folder Indices
4.D. Folder Tables
4.E. Folder ContextDocumentation
4.F. Folder Schemas
4.G. Folder Documents
Appendix 5 Data Content
5.A. Table Content
5.B. Data types
5.C. Conversion of table content to digital documents, audio, video, or geodata
5.D. Text format
5.E. Digital documents
5.F. Audio and Video
5.G. Geodata
5.H. Compression
5.I. Optimize
5.J. No deterioration
Appendix 6 Information on the archiving version
6.A. Archive Description File
6B. Context Documentation
6.C. Data about the archiving version's tables
6.D. SQL queries
Appendix 7 Completion Media
Appendix 8 Schemas

Appendix 2

Graphical view of items and structure in an archiving version

Figure 2.1

AK769_18_1.jpg Size : (308 X 617)

Appendix 3

Archiving version of the IT system data and any documents

3.A. General rules for archiving versions

3.A. 1 Archive version consists of :

-WHAT? data structure, cf. 3.B

-WHAT? data content, cf. 3.C

-WHAT? information about the archiving version, cf. 3.D

3.A. 2 An archiving version cannot contain encrypted information.

3.A. 3 A filing version must contain all of the dignible data and any documents from a limited period of time that is no longer being corrected or added as a snapshot and containing all the conservation worthy data and any documents at a specific time.

3.A. 4 If the archiving version of an IT system with documents is drawn up without any change of the journal period, or if the journal period shift occurs during the transfer of documents to a new period, the documents that are part of it must be included in the archiving version is marked in a way in the IT system that they can be exempted from subsequent archiving versions.

3.B. Data structure

3.B. 1 The data structure of the archiving version consists of :

-WHAT? a folder structure, cf. 4.B, illustrated in figure 2.1.

-WHAT? a relational database structure of 1. normal form or higher, specified in the index file tableIndex.xml, cf. 4.C.5.a.

-WHAT? other index files in XML, cf.. 4.C, which structure data on the parent content of the archiving version, all the files in the archiving version, its context documentation and its possible digital documents.

3.C. Data content

3.C.1 The data content consists of :

-WHAT? table contents in standardized data types, cf. 5.B.

-WHAT? any digital documents, audio, video and geodata in standardized data formats, cf. 5.E-5.G.

3D. Information about the archiving version

3.D.1 Information on the archiving version consists of descriptions of administrative usage, data content and the IT system, cf. Annex 6.

Appendix 4

Data structure

4.A. General rules for data structure

4.A. 1 In an archiving version, all keys must have a unique identifier. There should not be a situation where it is necessary to extract parts of key fields to understand the content of the IT system or function.

4.A. 2 When a value in a field is a code as representation for a fixed and unique value, the encoding must be explained. If the value does not exist in a code or lookup table in the IT system, in the archiving version, one or more tables will have to be generated, specifying the values in coded fields. Alternatively, the table data code value in extracting to the archive version is replaced by the actual content.

4.A. 3 If the documents in an IT system with documents are stored in a meaningful structure, this structure in the archiving version must be transformed into one or more tables.

4.B. Location of folders and files

4.B. 1 I root of the file system on the delivery media, cf. In Annex 7, a folder must be placed named with the media name. The name of the media consists of the unique archiving version ID with the addition of a suffix ". n" indicating the order of the media, where n is a consecutive median-number beginning with 1.

4.B. 2 Archiving version content is distributed to folders as specified in figure 4.1.

Figure 4.1
Folder name
Description
Mandatory
Position
Indices
Index files, cf.. 4.C
Yeah.
Always on first media
Tables
Table content, cf. 4.D
Yeah.
Can be free and spread across multiple media
ContextDocumentation
Context documentation, cf. 4.E
Yeah.
Always on first media
Schemas
XML schemas, cf. 4.F. The schema folder must have two subfolders : default and localShared
Yeah.
Always on first media
Documents
Any documents, audio, video, and geodata, cf. 4.G
No.
Can be free and spread across multiple media

4.B. 3 Mappings shall be named as specified in figure 4.1.

4.B. 4.a An archiving version ID consists of the prefix AVID, a 2-4 letter code indicating the receiving archive, as well as an archiving version serial number. The items are separated by periods.

4.B. 4.b Archiving version ID is provided by the State Archives.

4.B. 5.a An archiving version, which cannot be on one media, cf. Annex 7 may be spread over multiple media.

4.B. 5.b Mappers ContextDocumentation , Indices and Schemas must always be placed on the first medium of the delivery.

4.B. 5.c Folder in the media root on the subsequent media shall contain only the folders whose content requires distribution across multiple media. These folders are always named as specified in figure 4.1 without the use of suffix.

4.B. 6 Only one of each of the specified in Figure 4.1 is specified on each media.

4.C. Folder Indices

4.C.1.a Mappen Indices index files containing the following index files with information about the archiving version and its contents :

-WHAT? fileIndex.xml

-WHAT? archiveIndex.xml

-WHAT? contextDocumentationIndex.xml

-WHAT? tableIndex.xml

4.C.1.b If the archiving version contains digital documents, audio, video or geodata, the folder Indices also contain the following index file :

-WHAT? docIndex.xml

4.C.1.c All index files must comply with their corresponding schema, cf. Annex 8.

4.C.2.a fileIndex.xml must include a complete list of all the files that exist in the archiving version. However fileIndex.xml was excluded from this policy.

4.C.2.b For each file in the archiving version, the information that is specified in Figure 4.2 indicates the information specified in Figure 4.2.

Figure 4.2
Element Name
Designation
Description
Occurrence
per File
Mandatory
foN
Path
Specifying the path to the folder in the archiving version where the file exists
1
Yeah.
FiN
Name
Name of the file
1
Yeah.
md5
Checksum
The file's checksum of type MD5 iht. IETF RFC1321-The MD5 Message-Digest Algorithm :
128 bit (16 bytes) represented as 32 hexadecimal digits, all specified with either Minutes or versage (small or uppercase). Requirements for 32 hexadecimal digits in such a way as to ensure that the value of the leading zeros is applied depending on the value.
1
Yeah.

4.C.3 archiveIndex.xml must contain the information contained in 6.A.

4.C.4.a contextDocumentationIndex.xml must include an index of documents found in the context documentation of the archiving version.

4.C.4.b For each document in the context documentation, indicate the information that appears in Figure 4.3.

Figure 4.3
Element Name
Designation
Garbage space
Occurrence per document
Mandatory
documentID
Document ID
ID of up to 12 digits
1
Yeah.
documentTitle
Document title
Free text
1
Yeah.
documentDescription
Document description
Free text
0-1
No.
documentDate
Date
Year, year, year, year-month, iht. XML Standard
0-1
No.
authorName
Author Name
Free text
0-m
No.
authorInstitution
Author institution
Free text
0-m
No.
documentCategory
Document Category
Category Iht. Annex 6,
Figure 6.2
1-m
Yeah.

4.C.5.a tableIndex.xml must contain an indication of a relational database structure on 1. normal or higher. All tables in the archiving version must be specified.

4.C.5.b "TableIndex.xml" must conform to the overall XML schema "tableIndex.xsd", cf. 4.F.

4.C.5.c If a field must have a null value, then the "true" of the column's associated element "nullable" must be set in "TableIndex.xml".

4.C. 6.a docIndex.xml must form the connection between each document and its location. Also "docIndex.xml" must contain information about the document's original file names, file type in the archiving version, as well as any parent documents. "docIndex.xml" should not contain any information about the documents in the context documentation.

4.C.6.b For each document in the docIndex.xml document, specify the information that appears in Figure 4.4.

Figure 4.4
Element Name
Designation
Description
Garbage space
Occurrence per document
Mandatory
dID
DocID
ID that uniquely identifies the individual document
ID of up to 12 digits
1
Yeah.
pID
Parent
Parent document ID
DocID
0-1
No.
mID
MediaID
The name of the save medium to which the document is located
Jf. 4.B. 1
1
Yeah.
dCf
SubFolder
Document collection folder in which the document is in
Jf. 4.G
1
Yeah.
OFn
OrigFilename
Indication of the file's name (including extension) in the IT system
Free text
1
Yeah.
aFt
ArchivalFormat
Specification of file format in the archiving version
Extensiation, cf. 4.G.8
1
Yeah.
glXsd
Schema
For GML files, reference to the schema that will be used for the validation of the relevant GML file
Free text
0-1
No.

4.D. Folder Tables

4.D.1 Folder Tables must contain one folder for each table in the archiving version.

4.D.2.a Folder for a table named "table [ consecutive number ]".

4.D.2.b The sequential numbering starts with 1. The rezeroes must not be used.

The 4.D.3 folder for each table must contain two files :

-WHAT? table [ consecutive number ] .xsd

-WHAT? table [ consecutive number ] .xml

4.D.4 "table [ continuous number ] .xsd" is an XML schema that only specifies the structure of the individual table in question and must be in accordance with the XML instansen "tableIndex.xml", cf. 4.C.5.a, which specifies the structure of the entire relevant relational database, including all tables.

4.D.5 "table [ continuous number ] .xml" is an XML instance that contains data for that table and its structure must be in accordance with the corresponding XML schema, "table [ consecutive number ] .xsd".

4.D.6 If a field in a table can have a null value, then the corresponding column in the corresponding schema ("table [ continuous number ] .xsd") must be specified. contain the attribute naillable="true ". Similarly, the XML instansens ("table [ sequential number ] .xml") element contain the xsi:nil = "true " cf. The W3C standard for handling null values in XML.

4.E. Folder ContextDocumentation

4.E.1 Folder ContextDocumentation must contain one or more document collection folders with context documentation, cf. 6B.

4.E.2 A document collection folder with the context documentation must contain up to 10,000 document folders.

4.E.3 The document collection folders are named "docCollection [ consecutive number ]", starting with 1. The name must be unique within ContextDocumentation.

4.E.4 Each document in the context documentation must be assigned an ID of up to 12 digits. The document ID must be unique within ContextDocumentation.

4.E.5 A document folder must contain one document that consists of one or more files of the same format, and is named with the ID of the document. The rezeroes must not be used.

4.E.6 A document's file (or files) are continuously named with a number, starting with 1 as well as the extensionance of the format, cf. 4.G.8

4.F. Folder Schemas

4.F. 1 Folder Schemas must be divided into the subfolders, default and localShared .

4.F. 2 Folder default must contain schemas for the index files of the archiving version, cf.. Annex 8, as well as the W3C standard XML schema, cf. http://www.w3.org/2001/XMLSchema.xsd.

4.F. 3 For schemers fileIndex.xsd, archiveIndex.xsd, contextDocumentationIndex.xsd, tableIndex.xsd, docIndex.xsd as well as W3C standard XML schema, that the schemas must always be used to make available to the state archives. The schema names and their naming conventions must not be changed in the archiving version.

4.F. 4 Folder localShared must contain any GML schemas that are not in conjunction with the relevant GML document, cf. 4.G.7.a.

4.G. Folder Documents

4.G.1 Folder Documents must contain one or more document collector folders, however, a maximum of 10,000.

4.G.2 Document Collection folders are named "docCollection [ consecutive number ]", starting with 1. The name must be unique within Documents.

4.G.3 A document collection folder must contain up to 10,000 document folders.

4.GG.4 Each document must be assigned to 12 digits in the archiving version. The document ID must be unique within Documents.

4.G.5 A document folder must contain one document that consists of one or more files of the same format, and is named with the ID of the document. The rezeroes must not be used.

4.G.6 A document's file (or files) are consecuted consecutive with a number, starting with 1 as well as the extensionment of the format. The rezeroes must not be used.

4.GML files will store the appropriate schema in the same folder as the GML file and name with sequential number followed by .xsd, cf. However, 4.G.7.a. The rezeroes must not be used.

4.GL 7.a GML schedules can be stored in the schema folder that are named localShared, cf. 4.F. GML schemas in the folder localShared name is "localSchema [ consecutive number ]", starting with 1.

4.G.8 Extentions of extents

4.G.8.a Documents in the form TIFF format must have extensionment tif.

4.G.8.b Documents in MP3 format must have extensionation mp3.

4.G.8.c Documents in MPEG-2 and MPEG-4 format must have extensionment mpg.

4.G.8.d Documents in the format JPEG-2000 must have extension2 jp2.

4.G.8.Documents in the form of the GML format must have extensionary gml.

4.G.8.f Documents in the form WAVE must have extensionwav.

4.G.9 The ability to search objectively connected documents must be transferred to the archiving version after the receiving archive's detailed view.

Appendix 5

Data content

The data content of the archiving version consists of table content in standardized data types and of any digital documents, audio, video, and geodata in standardized formats.

5.A. Table Content

5.A. 1.a In accordance with the table structure defined for each table in each corresponding XML schema, named "table [ sequential number ] .xsd", cf. 4.D, each table must be found in an XML instance named "table [ sequential number ] .xml".

5.A. 1.b The sequential numbering starts with 1. The rezeroes must not be used.

5.A. 2 The content of the individual fields must be pursed for any front and trailing blanks.

5.B. Data types

5.B. 1.a The standardized data types that are to be used for table content are specified in figure 5.1. They are a deduction of data types from the default SQL : 1999 represented as data types in W3C XML Schema Language 1.0.

5.B. 1.b This is the data type of W3C XML Schema Language 1.0, which is to be used.

The translation from data types in SQL : 1999 was specified to show how the translation for data types in W3C XML Schema Language 1.0 must be performed.

Figure 5.1

Data Type

SQL : 1999

XML Data Type
Text
CHAS, CHARACTER, NCHAS,
NATIONAL CHAS, NATIONAL CHARACTER, VARCHAS,
CHARACTER VARYING,
NATIONAL CHARACTER VARYING
string
Integer
INTEGER, SMALL INTEGER
integer
Decimal number
NUMERIC, DECIMAL, FLOAT, DOUBLE PRECISION, REAL
decimal
Boolsk
BOOLEAN
boolean
Hexadecimal
CHAS, CHARACTER, NCHAS,
NATIONAL CHAS, NATIONAL CHARACTER, VARCHAS,
CHARACTER VARYING,
NATIONAL CHARACTER VARYING
hexBinary
Date
DATE
date
Time
TIME [ WITH TIME ZONE ]
Hour
Timestamp
TIMESTAMP [ WITH TIME ZONE ]
dateTime
Time period
RANGE
duration

5.B. 2 Data type string contain only non-marked text which may be interpreted immediately.

5.B. 3 Data type boolean can see cf. W3C only assume values 1 ; 0 or true ; false .

5.B. 4 Data types date, time and dateTime can be used with or without Time Zone .

5.C. Conversion of table content to digital documents, audio, video, or geodata

5.C.1 Table content must conform to the specified data types, cf. 5.B. It follows that data content in a table form from an IT system that is to be transferred to an archiving version that cannot immediately comply with this requirement must have its data content converted in such a way :

5.C.1.a to digital documents, audio, video or geodata, converting content to the formats that are shown in 5.E-5.G.

5.C.1.b to table contents of data type string , cf. 5.B, since other content than the data type allowed.

5.C.2 The archive archive indicates whether a given content should be handled in respect of 5.C.1.a or 5.C.1.b.

5.D. Text format

5.D.1 Unicode encoding

5.D. 1.a Data in the index files and table contents of the archive version must be encoded as well-formed UTF-8, as specified in ISO/IEC 10646:2003 Annex D and as described in The Unicode Standard 5.1, Chapter 3.

5.D. 1.b. The in-coded characters must be valid Unicode scalar values. Surrogating / RC-elements and Unicode non-characters may not be used.

5.D.1.c No grades in Private Use Area must be encoded.

5.D.1.d The Steering code characters from #x00 to and with #x1F are not allowed with the exception of the Tabulator (TAB) #x09, newline (LF) #x0A , and carriage return (CR) #x0D.

5.D. 2 XML encoding

5.D. 2.A, according to the XML standard, the rules for the indication of the characters in question, as shown in Figure 5.2.

Figure 5.2
Characters
Entity
Use
<
<
Mandatory
>
>
Recommended
&
&
Mandatory
'
'
Recommended
"
"
Recommended

5.D. B The towers from #x7F to and with #x9F must be specified with their decimal or hexadecimal character reference.

5.D. 2.c CDATA sections may not be used.

5.E. Digital documents

5.E.1.a A digital document, cf. However, 5.F and 5.G must be stored in one of the following formats :

-WHAT? the graphical bitmap format TIFF, version 6.0 baseline.

-WHAT? JPEG-2000 after the standard ISO/IEC 15444-1:2004. Information technology-JPEG 2000 image coding system-Part 1 : Core coding system.

5.E.1.b It is allowed to use both forms within the same archiving version.

5.E.2 Documents in TIFF must be compressed in accordance with the following compression rules :

5.E.2.a Black / white document is to be compressed with CCITT/TSS grp. Three, gran. 4, PackBit or LZW.

5.E.2.b documents with gray tones or colors must be compressed with PackBit or LZW.

5.F. Audio and Video

5.F. 1 Sound files must be stored according to standard MP3 DS/EN ISO/IEC 11172-3.

5.F. 2 The receiving archive may allow audio files to be delivered in the form WAVE LPCM as specified in Multimedia Programming Interface and Data Specifications 1.0. IBM Corporation and Microsoft Corporation, August 1991. However limited to bits depth, which is the whole multipla of 8.

5.F. 3 Video files must be stored in accordance with one of the following standards :

-WHAT? MPEG-2 D / EN ISO / IEC 13818-2. Any sound is encoded as MP3, as specified in ISO/IEC 13818-3.

-WHAT? MPEG-4 AVC D / EN ISO / IEC 14496-10 (ITU-T H.264). Video is encoded as specified in ISO/IEC 14496-10. Any sound is encoded as AAC, as specified in ISO/IEC 14496-3. Video and sound are wrapped in the MPEG-4 format as defined in ISO/IEC 14496-14.

5.G. Geodata

5.G1 Data from geographic information systems as well as other geodata is stored as the GML files in ht. GML 3v3.DK, the Danish profile of the GML standard ISO 19136.

5.G.2 GML files greater than 1 GB are broken down into units after the receiving archive view.

5.G.3 Each GML file, if any. after splitting, cf. 5.G.2 is treated as a separate document in ht. the rules in 4.G.

5.G 4 The necessary XML schemas to validate the GML files must be included in the archiving version.

5.H. Compression

5.H. 1 An archiving version cannot be compressed other than the compression that is listed for or following the document formats required for use for the archive version, cf. 5.E and 5.F.

5.I. Optimize

5.I. 1 Archiving archive may in specific cases decide on the reduction of the consumption of the documents, for example, by applying the optimum bitdepth to the maximum.

5.J. No deterioration

5.J. 1 For the generation of the archiving version, no quality degradation of the documents, including audio and video, is required in addition to what may be a consequence of the required format for the archiving version or instructions given by the receiving archives.

Appendix 6

Information about the archiving version

The information on the archiving version consists of the following elements :

-WHAT? Archive descriptive file, cf. 6.A.

-WHAT? Context documentation, cf. 6B.

-WHAT? The data on the tables of the archiving version (table index), cf. 6.C.

-WHAT? I'm not. SQL queries, cf. 6.D.

6.A. Archive Description File

6.A. 1 Any archiving version must include an archive description file, specifying information in ht. Figure 6.1.

6.A. 2 Archive descriptive file is named archiveIndex.xml and must comply with the corresponding schema, cf. Annex 8.

6.A. 3 The content of the archive description file is determined after discussion between the issuing authority and the receiving archive.

Figure 6.1

Element Name

Designation

Description

Garbage space

Occurrence

Mandatory
archiveInformationPackageID
Archiving Version ID
Unique ID to be assigned to the archiving version of the State Archives
Archiving version ID, as defined in this notice
1
Yeah.
archiveInformationPackageIDPrevious
Previous Extradition
Entyded archiving version ID on previous delivery from the same IT system
Archiving version ID, as defined in this or earlier notice
0-1
No.
archivePeriodStart
Archive version start date
Start date of the supplied data
Year, year month, or year-month-day
1
Yeah.
archivePeriodEnd
Archive version end date
End date of the
delivered data
Year, year month, or year-month-day
1
Yeah.
archiveInforma-tionPacketType
End Merge
Indication of whether the archiving version is an end table
Boolsk Value
1
Yeah.
creatorName
Archive creator
The authority or authorities responsible for the filing of the archive. Can also be organizational entities within an authority or other contributor to the archival
Free text
1-m
Yeah.
creationPeriod-Start
Archive Start Date
For each archive creates when archive creator is beginning to add data to the IT system
Year, year month, or year-month-day
1-m
Yeah.
creationPeriodEnd
Archive Creator End Date
For each archive creator, specify when archive creator is disclosed by adding data to the IT system
Year, year month, or year-month-day
1-m
Yeah.
archiveType
Archiving Version Period Type
Indication of a completed archived period / year, or whether it is a snapshot
Boolsk Value
1
Yeah.
systemName
System name
The official name of the IT system in which all abbreviations are resolved
Free text
1
Yeah.
alternativeName
Alternate system name
Alternate names of the IT system
Free text
0-m
No.
system Purpose
System Purpose
Description of the purpose of creating and running the IT system
Free text
1
Yeah.
system Content
System Content
The central population and central variables of the IT system
Free text
1
Yeah.
regionNum
Region Numbers
Indication of whether or not there is a systematic form of regional numbers in the IT system
Boolsk Value
1
Yeah.
ComNum
Municipalities
Indication of whether a systematic form is registered local authority numbers in the IT system
Boolsk Value
1
Yeah.
cprNum
CPR numbers
Indication of whether or not there is a systematic form of the CPR numbers in the IT system
Boolsk Value
1
Yeah.
cvrNum
CVR Numbers
Indication of whether or not there is a systematic form of registration for CVR numbers in the IT system
Boolsk Value
1
Yeah.
matrikNum
Matrix Numbers
Indication of whether the system is registered in the system of the IT system in a systematic manner ;
Boolsk Value
1
Yeah.
bbrNum
BBR Numbers
Indication of whether a systematic form has been registered BBR numbers in the IT system
Boolsk Value
1
Yeah.
whoSygKod
WHO-
disease codes
Indication of whether the health code of the WHO has been recorded in the IT system in a systematic manner is the WHO &apos; s disease.
Boolsk Value
1
Yeah.
sourceName
Data Source
Other IT systems that have supplied data to the IT system (lookup, transfer, interconnectors, etc.)
Free text
0-m
No.
userName
Data Routers
Other IT systems that have used data from the IT system (lookup, transfer, interconnectors, etc.)
Free text
0-m
No.
cessorName
Predecessor systems
Systems that have previously handled the same function
Free text
0-m
No.
formVersion
FORM Version
Indication of the version of the FORM (common public business reference model) the categorization below has been obtained from
Valid FORM-ver-ver
(s)
1
Mandatory for IT systems from public authorities
formClass
FORM Classification
Categorization of the archiving version in ht. SHAPE
Any valid FORM reference in ht. the version of the FORM version specified
1-m
Mandatory for IT systems from public authorities
formClassText
FORM Classification Explanation
FORM Classification in Text
Free text
1-m
Mandatory for IT systems from public authorities
containsDigitalDocuments
Digital documents contained
Specifying whether there are any digital documents in the archiving version, other than context documentation
Boolsk Value
1
Yeah.
searchRelatedOtherRecords
Crawler for other cases or documents
Indication of whether the archiving version is a necessary search for paperwork / documents or files / documents in another IT system
Boolsk Value
1
Yeah.
relatedRecordName
Addressed Archivalier
Referral to the archivalists that the archiving version is the search tool for
Free text
0-m
Yes, if there are any answers to the previous question :
systemFileConcept
Existence of the case concept in the IT system
Indication of the fact that the IT system has a case concept, understood as a registered correlation between factually connected documents
House value. Can only be true if there are digital documents in the IT system
1
Yeah.
multipleDataCollection
SOA architecture
Indication of whether the IT system is composed of data and, where necessary, documents from several different IT systems in a service-oriented architecture
Boolsk Value
1
Yeah.
PersonDataRestrictedInfo
Personal Data
Indication of whether there is sensitive personal data in the archiving version. the personal data friend
Boolsk Value
1
Yeah.
otherAccessTypeRestrictions
Exemptive Information
Indication of whether the archiving version can be found in the case of a longer availability notice, by the way.
Boolsk Value
1
Yeah.
archiveApproval
Approval Archive
Indication of the public archive that approves the archiving version
Identification of the archives (2-4 characters)
1
Yeah.
archiveRestric-
tions
Availability Restrictions
Specification of detailed rules for access to the material. The element may be used after the receiving archive's detailed guidelines
Free text
0-1
No.

6B. Context Documentation

6.B. 1 Any archiving version must contain documents that document the administrative function of the IT system, as well as structure and functionality.

6.B. 2 The Receiving Archive after discussion with the issuing authority shall determine which documents are to be delivered, including which points in Figure 6.2, which are not relevant to document in the specific delivery.

6.B. 3.a The documents are placed in one or more of the categories shown in Figure 6.2.

6.B. 3.b Information about the categorization will be recorded in the contextDocumentationIndex index file, cf. 4.C.4.a.

6.B. 4 The documents must be stored in one of the document formats allowed in the archiving version, cf. 5.E-5.F.

Figure 6.2
1. Documentation concerning the administrative use of the IT system
Element Name
Description
1.a
system Purpose
IT system purpose
1.b
system Regulations
IT system law and rule basis
1.c
system Content
The content, population, and specific concepts of the IT system
1.d
systemAdministrativeFunctions
The IT system administrative functions
1.e
System PresentationStructure
IT System Presentation Structure
1.f
systemDataProvision
Alignment of data
1.g
System Data Transfer
Dissemination of data
1.h
systemPreviousSubsequentFunctions
Data and functions shared with predecessor and successor systems
1.i
system AgencyQualityControl
The Authority &apos; s own quality control
1.j
systemPublication
Publication of and on data
1.k
systemInformationOther
Other
2. Documentation relating to the technical design, operation and development of the IT system
Element Name
Description
2.a
operationalSystemInformation
Structure of the Operational Version
2.b
operationalSystemConvertedInformation
Transform at the authority
2.c
operationalSystemSOA
Documentation of the composition of data and any documents from several different IT systems in a service-oriented architecture
2.d
operationalSystemInformationOther
Other
3. Documentation concerning the delivery of data by archiving companies
Element Name
Description
3.a
archivalProvisions
Provisioning of the nature of the archive, including delivery of delivery
3.b
archivalTransformationInformation
Documentation of conversion from operational version to the archiving version
3.c
archivalInformationOther
Other
4. Documentation regarding the receipt of data by the archive of the archive (piled by receiving archive)
Element Name
Description
4.a
archivistNotes
Archivarting notes
4.b
archival Test Notes
Test notes
4.c
archivalInformationOther
Other
5. Documentation of the Archive Retention of the Archive Version (populated by the Receiving Archive)
Element Name
Description
5.a
archival MigrationInformation
Converting to the archive
5.b
archivalInformationOther
Other
6. Other documentation
Element Name
Description
6.a
information-Other
Other

6.C. Data about the archiving version's tables

6.C.1 An archiving version must contain documentation of the archiving version's tables and relationships (table index). The table index must contain the information that appears in Figure 6.3 below.

Figure 6.3
1. Information about the database
Element Name
Description
Occurrence per database
Mandatory
1.a
version
Format version, always "1.0"
1
Yeah.
1.b
dbName
Short name of the database
0-1
Yes, if the information exists in the database
1.c
database Product
Name and version of the database product from which data has been archived
0-1
Yes, if the information exists in the database
2. Information on tables and views
Element Name
Description
Occurrence per archiving version
Mandatory
2.a
tables
List of tables in the database
1
Yeah.
2.b
views
List of views in the database
0-1
Yes, if views are included in the archiving version
3. Details for each table
Element Name
Description
Occurrence per table
Mandatory
3.a
name
Table name. Don't start with a number.
1
Yeah.
3.b
folder
Name of the folder that contains table and associated schema
1
Yeah.
3.c
description
Description of the contents and significance of the table
1
Yeah.
3.d
columns
List of columns in the table
1-m
Yeah.
3.e
primaryKey
Tabellens primary key
1
Yeah.
3.f
foreignKey,
Foreign key in table
0-m
Yes, if there are foreign keys
3.g
rows
Indication of the number of rows in the table
1
Yeah.
4. Information about columns
Element Name
Description
Occurrence per column
Mandatory
4.a
name
Column Name
1
Yeah.
4.b
columnID
Unique identifier of column. Begins with the letter ' c' followed by the number of the column's place in the table.
1
Yeah.
4.c
type
SQL : 1999 data type
1
Yeah.
4.d
type Original
Original Data Type
0-1
Yes, if the information exists in the database
4.e
defaultValue
Defaultvalue for fields in the column
0-1
Yes, if the information exists in the database
4.f
nullable
Specifying whether fields in the column can be "null". House value.
1
Yeah.
4.g
description
Description of the contents of the column
1
Yeah.
4.h
functionalDescription
Indication of the column &apos; s function in respect of figure 6.4, figure 6.5 and figure 6.6
0-m
Yes if the column has one of the specified functions
5. Primary Keys Information
Element Name
Description
Occurrence per key in table
Mandatory
5.a
name
Primary key name. The name must be unique within the archiving version and be in accordance with rules for names of names in standard SQL1999
1
Yeah.
5.b
column
Original name of the primary key columns
1-m
Yeah.
6. Foreign Keys Information
Element Name
Description
Occurrence per key
Mandatory
6.a
name
Foreign key name. The name must be unique within the archiving version and live up to the rules for names of names in the standard SQL : 1999
1
Yeah.
6.b
ReferendTable
The table that the foreign key refers to
1
Yeah.
6.c
reference
Original name of the columns that are part of the foreign key
1-m
Yeah.
6.d
in
Original name of the columns that the foreign key refers to
1-m
Yeah.
7. Details for views and requests
Element Name
Description
Occurrence per query or view
Mandatory
7.a
name
Name of view
1
Yeah.
7.B.
queryOriginal
Original SQL query that defines view or SQL query, which is created specifically for the archiving version
1
Yeah.
7.c
description
Content and importance of view or SQL query
0-1
Yes, if they can be subtracted from the database or if it is queries that are created specifically for the archiving version

6.C.2 System views are not included.

6.C.3 The receiving archive can indicate that the key views must have a description, cf. Figure 6.3, 7.c.

6.C.4 To be specific information for IT systems, with the registration of information about documents.

6.C.5 For archiving versions of IT systems, as mentioned in 6.C. 4, columns containing specific information, cf. Figure 6.4-figure 6.6, is identified by the functionalDescription element, cf. Figure 6.3, 4.h.

6.C. 6 Special information specified in figure 6.6 must be marked to the extent that they are registered in the IT system. If the information in Figure 6.6 does not exist in the IT system, then, in connection with the delivery, any alternative marking shall be agreed to ensure the identification of the related documents in accordance with the Agreement. applicable provisions.

Figure 6.4
Rating columns with fixed information in archiving versions of IT systems with registration of documents shared by multiple authorities
Information
Description
Name-Identification
The column (s) in the archiving version that contains information about which authority has registered the case or document

Figure 6.5
Rating columns with fixed information in archiving versions of IT systems with documents
Information
Description
Tabular data space
Documentation identification
Used to specify the column (s) in the archiving version that describes the document unique identification
Save form
Used to specify the column (s) in the archiving version that describes whether the document is stored digitally, on paper, or partly on paper.
Total or partially digitally = 1, paper = 2, not applicable = 3
Delivered
Used when delivering immediate images etc. to specify the column (s) in the archiving version that describes whether the document is already passed in a previous archiving version
Previously delivered = 1, not previously delivered = 2

Figure 6.6
Rating columns with information in archiving versions of IT systems with registration of documents
Information
Description
Case identification
The column (s) of the archiving version that describes the unique identification of the savers
Case Title
The column (s) in the archiving version that contains the titles of the documents
Document title
The column (s) in the archiving version that contains the titles / descriptions of documents
Document date
The column (s) of the archiving version that contains information about the document's submission and reception dates
Dispatcher / Recipiper
The column (s) in the archiving version that contain information about a document's sender or recipient
Digital Signature
The column (s) in the archiving version that contains information derived from a digital signature
SHAPE
The column (s) in the archiving version that contains a reference to FORM (the common public business reference model)
Kassation
The column (s) in the archiving version containing information about conservation and scrap

6.D. SQL queries

6.D.1 Archive can provide that a number of SQL queries for documentation of specific connections in the archiving version must be defined for a file version version.

6.D.2 SQL queries are designed in accordance with the standard SQL : 1999 (core).

6.D.3 Queries are placed in "Information about views and queries" in the table index, cf. figure 6.3, 7, and named after the authority's choice, however, so that the name of the queries in question begins with "AV".

Appendix 7

Dropping Media

7.A. 1 Archive versions can be delivered on CD-R, DVD-R, or USB media.

7.A. 2 The number of CD-R and DVD R in one pass must not exceed 10, unless otherwise agreed between the contracting authority and the receiving archive.

7.A. 3 The issuing authority and the receiving archive may reach an agreement on other media or other methods for the transport of data.

7.A. 4 The receiving archive can allow an archiving version to be encrypted in connection with transport.

Appendix 8

Schemas

Completed schemas to be used for the creation of an archiving version can be retrieved from the State Archive home page