Scribd
Upload
234 views

Key-Change Vs Key-Specifier in Ab Initio

The key-change method should be used instead of key-specifier when the key needs to be computed based on values in columns rather than being inherent to a column. It is also useful when the key change depends on part of a field, such as changing the key based on the area code of a phone number, or when there is a secondary rule for the key based on a second field, like rolling up based on one field but having two records for each value when another field is a special value.

Uploaded by

Sravya Reddy
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
234 views

Key-Change Vs Key-Specifier in Ab Initio

The key-change method should be used instead of key-specifier when the key needs to be computed based on values in columns rather than being inherent to a column. It is also useful when the key change depends on part of a field, such as changing the key based on the area code of a phone number, or when there is a secondary rule for the key based on a second field, like rolling up based on one field but having two records for each value when another field is a special value.

Uploaded by

Sravya Reddy
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 1

Key-Change vs Key-Specifier in Ab Initio

3/21/2007 By ITtoolbox Popular Q&A Team for

ITtoolbox as adapted from Abinitio-L discussion group Summary: Can anyone give me an example where key-change method has to be used instead of the usual key-specifier? Full Article: Disclaimer: Contents are not reviewed for correctness and are not endorsed or recommended by ITtoolbox or any vendor. Popular Q&A contents include summarized information from ITtoolbox Abinitio-L discussion unless otherwise noted. 1. Adapted from a response by Remediator on 3/14/2007 If your key-change has to be computed from the values in the columns versus inherent to a column (determined by inspection). It is quite frankly easier to manage to just run the data through a transform and make your keys as needed rather than using a key-change. Sometimes this is not always easy, as in the case of a normalize where the key-change is an oblique combination of values that can only be determined via inspection. 2. Adapted from a response by view_poin... on 3/14/2007 An example would be that you want a key change for every 10th record (can be achived in a simple transform) you are reading on a non sorted data and calculate the total on the 'x' field. (achived in a transform or other aggregate components like scan or rollup). 3. Adapted from a response by M.Kornbluth on 3/15/2007 Here are 2 examples: 1: Where the "key change" depends on PART of a field. Example: The field is a phone #, and the rollup is by area code (US type phone #'s, first 3 digits = area code). One way would be to reformat the field first, splitting the phone number into area code, exchange and number; or, one could just use the key-change method on the phone number, only when the 1st three digits change. 2: When there is a secondary RULE that is based on a second field. Example: Roll up based on field #1, BUT have 2 records for each value in field#1; one where field#2=0 signifying a "special" type) and one for all other values of field#2 (a rollup of all normal values). Yes, one could calculate a field with a "special/notspecial" value in a reformat first, but, if the rule is used ONLY in the rollup, might as well use the rule in the key change.

You might also like