Quick links


Common Metadata Framework

Metadata Case Studies


 All METIS pages (click arrow to expand)
Skip to end of metadata
Go to start of metadata


5.1 IT Architecture

IT architecture of SMS is an integral part of IT architecture of SIS. The SMS is a necessary precondition for all statistical data warehouse operations. Data warehouse will finally become the only place to store all statistical data with their completely structured metadata description. 

Technological infrastructure

Computing centre is focused on using servers with UNIX operating system and Oracle database technology. Technological equipment is grouped into Unix clusters on which Oracle database and application servers operate. In the framework of SIS new architecture implementation, applied technological tools will be enlarged by data warehouse technology. 

As client stations are used personal computers with operating system Microsoft Windows 2000 or higher and browsers Internet Explorer and Firefox Mozilla, program package Microsoft Office and other utilities.

SMS application packages
  • will not depend on users' work station platform, they will be under operating system MS Windows (version 7 or higher) or Linux,
  • metadata will be viewed through the Internet browser without installation of supplementary products at the internal user station,
  • for metadata administration "thick client" solution can be used,
  • will be implemented in the following technological environments:
  • Oracle Forms and Reports (three-layer architecture). Oracle Application Server is supposed to be used. In this case the client is Internet browser;
  • Java (possible thick clients);
  • Java Server Pages for thin clients outside Oracle Forms and Reports. The Oracle Forms and Reports technology may not be suitable for some parts of SMS - then Java Server Pages (JSP) will be used;
  • access to individual subsystems will be unified via SMS access portal while this portal will make part of the CZSO internal portal,
  • for metadata presentation on the Internet Java Server Pages (JSP) technology will be used.

5.2 Metadata Management Tools

The following two technologies will be used for communication between SMS subsystems and between SMS and the other applications:

  • technology of direct communication between Oracle data tables of SMS subsystems and tables of other applications,
  • XML technology for defining unified communication interfaces between individual SMS subsystems and interfaces between SMS subsystems and other applications. 
    User interface to SMS subsystems will be developed in Oracle Forms. Standard rules were defined for design of communication windows to keep unified appearance and distribution of function keys. The user's basic tool is the Internet browser in which applications of individual subsystems are started. 
    The link of data with metadata will be established in data warehouse, using ETL processes. Structured metadata to statistical data for data warehouse will be taken from subsystems VAR, CLASS and TASKS. 

5.3 Standards and formats

The SMS subsystem uses:

  • XML interface or exports for other SMS or SIS applications,
  • off-line work with copy of the data (created with the help of XML),
  • SMS applications developed in Oracle Forms 10g can be started at work stations with MS Windows or Linux,
  • Internet mirror of subsystem CLASS will be created with the help of Java Server Pages (JSP),
  • backup on central db server in Oracle ARCHIVELOG product,
  • SDMX technical standards for data interchange (implementation in near future).

5.4 Version control and revisions

Description of object state in SMS is stable in a time interval from - to. From certain point in time, description is changed or its validity terminated. For this stable state of object in certain validity range is used the concept object version. 

Object version may be subject to changes, which are required to be registered in the system. To observe the history of object version changes, the following rules are to be followed:

  • Until object version is approved, the changes are not registered, i.e. only current state of object is stored in the system.
  • Provided object version has been approved, the resulting state is registered in the system for good.

If there is a need to change an object version already approved, so-called object version revision is made. On approval of an object version revision, former objects are designated as cancelled and replaced by new ones.

Each object version may go through the following states:

  • under preparation;
  • for approval;
  • approved;
  • revised;
  • revised for approval. 

Under preparation - new object or new version of already existing object is created.

For approval - no changes of object version can be made. Object version is prepared for approval. The result may bring an object version into the state 'Approved' or back into 'Under preparation'.

Approved - the object version is valid and available for other systems. No changes of object version can be made.

Revised - in case there is a need to change an object version that is in the state 'Approved'. The state before the revision remains stored and changes are made on a new copy of a given object version. The revised object version may be:

  • approved - by which it replaces the former state of a given object version. The former state of object version is also registered in the system but designated as cancelled.
  • rejected - changes made by the revision are cancelled and the former state remains unchanged.

Revised for approval - object version revision is completed and submitted for approval. No changes can be made to object version revision. The result may bring the object version revision into the state 'Approved' or back into 'Revised'. 

5.5 Outsourcing versus in-house development

The following procedure was adopted for preparation and implementation of SMS subsystem:

  • content and functional specifications are prepared by multidisciplinary project teams set up of employees from different CZSO departments (methodology, subject-matter statisticians, IT experts),
  • technology proposal and design, implementation and running of applications will be dealt with by outsourcing,
  • applications are tested by project teams in cooperation with the SMS department and supply and delivery company,
  • initial filling of the subsystem will be made by staff of subject-matter departments in cooperation with the SMS department and supply and delivery company,
  • principal documents such as design proposal or technical specification are subject to opposition discussions,
  • takeover of program applications of SMS subsystems is completed by the acceptance protocol,
  • in routine operation, individual subsystems will be used by statistical subject-matter departments, general methodology department, SMS department and data processing departments,
  • in the end SMS tools should also be available to workplaces of the state statistical service with the aim to integrate methodology and contents of official statistics. 

5.6 Sharing software components of tools


Development of the software for applications CLASS, VAR and TASKS has been financed from the CZSO budget and from the EU Transition Facility Programme. External contractors supplied all three applications. The CZSO in principle is willing to create necessary conditions for sharing these applications. Conditions for the usage of the applications will be a subject of discussion/negotiation between all participating institutions, i.e. the CZSO, EU and suppliers. 

5.7 Additional materials 

When developing subsystems CLASS, VAR and TASKS, the following documents were prepared:

  • Content and functional specifications of subsystem CLASS (incl. conceptual model),
  • Technological specifications of subsystem CLASS (incl. data model),
  • Global architecture of SMS (GA-SMS),
  • Content and functional specifications of subsystem VAR (incl. conceptual model of statistical datum description; statistical variable, statistical object, time variable and complementary variable),
  • Technological specifications of subsystem VAR (incl. data model),
  • Content and functional specifications of subsystem TASKS (incl. conceptual model),
  • System principals for GA-SMS,
  • Metadata of statistical datum,
  • Technological specifications of subsystem TASKS (incl. data model and language of data validation).