You are here

Party time period reference technical data standard

Standard identifier: 
ISB-000278
Standard Type: 
Technical Data Standards
Version: 
1.00
BDA Version: 
8.01
Status: 
Approved: Recommended
Date of Standard: 
Monday, 8 December 2014
Category: 
Party (including organisation and person)
Target audience: 
Data modellers
ICT procurers
Statisticians
System developers or programmers
Introduction: 

This Technical Data Standard (TDS) binds the Party Time Period Reference Business Data Standard (BDS) to an XML Schema (XSD) representation.

Application

This Technical Data Standard (TDS) binds the Party Time Period Reference Business Data Standard (BDS) to an XML Schema (XSD) representation.

A party time period reference is a reference structure that is owned and defined by a party so that it can be used as part of the description of an event defined by a party, to identify a specific division of a Financial Year, Week, Term, Financial Quarter, Academic Year etc.

Compatibility with non-ISB standards

There are no known compatibility issues related to this standard.

XSD

XSD Normalisation

Introduction

This section defines normalisation that has been applied. The Business Data Standard data model may contain multiple entities that inherit primary keys from a parent entity. In this situation the same primary keys will occur in multiple entities. If this pattern was translated directly to the xsd then the same primary key element(s) would be repeated within the xsd. When parsing the xml, if the element was referenced without xpath then the particular instance of the repeated primary key element could not be determined.

If all instances of the repeated primary key element(s) contained the same value then there would not be an issue. However, if there were different values in the repeated primary key element(s) then the value to be returned would be indeterminate. To prevent this situation the conversion from the Entity Relationship Diagram (ERD) model to the xsd involved normalisation to remove the repetition. This results in nodes being created in the xsd to define primary keys once and sub-nodes created that inherit those keys. This section will identify any normalisation that has taken place and how it has been implemented in the schema.

Details of Normalisation specific to Party Time Period Reference

The Party Time Period Reference consists of a single entity and therefore no normalisation is required.

XSD Optimisation

Introduction

This section defines optimisation that has been applied to the xsd. The Business Data Standard data model may contain compound keys made up from a number of attributes. The sequence of the attributes in the Business Data Standard data model is defined to identify any opportunities for optimisation in encodings that can accommodate that capability.

An example is where the primary key contains the values of Party_Id and then Event_Id. This implies that a single Party_Id may have many Event_Ids. Encodings that can accommodate optimisation can define the Party_Id once and then under that have many Event_Ids. For xml encoding, a single Party_Id element node can be defined with an unbounded list under that node for the Event_Ids. This reduces the amount of data redundancy.

Details of Optimisation specific to Party Time Period Reference

The Party Time Period Reference is optimised by having a single top level key instance of

  • Party_Id_Creator

under the Party_ID node

The PartyTimePeriodReference_CN then adds a second level primary key of

  • Party_Time_Period_Reference that allows multiple instances to occur under the above Party_Id_Creator.

The above facilitates two levels or optimisation to be applied

Therefore

  • for one instance of primary key set (1) there are multiple instances of primary key set (2)

When creating data for the Party schedule primary keys there are two options available that both satisfy the xsd

  • Option 1 –One Party_Id_Creator with many Party_Time_Period_Reference

  • Option 2 – One Party_Id_Creator with one instance of Party_Time_Period_Reference

Option 1 utilises the optimisation as there will be one Party_Id_Creator with all its Party_Time_Period_Reference instances

Option 2 does not use the optimisation and repeats the Party_Id_Creator against a single Party_Time_Period_Reference instance.

Providing Option 1 is coded for in the application then either option 1 or 2 option can be supported. However, this is not true if option 2 only is coded for as the program will not hold the Party_Id_Creator in memory for use against each of its Party_Time_Period_Reference nodes.

The recommendation is always to code for the optimisation method option 1.

References: 

The following references are specific to this Technical Data Standard:

  • ESCS ISB Consolidated XML (XSD) Schema, version 1.19

  • ESCS ISB Business Data Architecture Entity Relationship Diagram, version 8.01

  • ESCS ISB XSD Content Model, version 1.0

  • ESCS ISB, Business Data Standard, Party Time Period Reference

The following references apply to all Technical Data Standards:

  • ESCS ISB Standards Overview and Context

  • ESCS ISB “System“ Enterprise Architecture - Business Data Architecture

  • ESCS ISB Business Data Architecture Data Types

  • ESCS ISB BDA Data Architecture Modelling Standards

  • ESCS ISB Management Process