Design strictly in terms of externally defined files; field offsets must not be conditional. Do not specify that a field is to represent one data item in some circumstances and a totally different data item in other circumstances. Instead, introduce a separate field.
Avoid repeating groups of items within a record. For instance, ‘Order quantity 1’, ‘Order quantity 2’ ‘Order quantity 3’. In a database of fixed length records like that of iSeries, unnormalized data of any repeating group imposes a limitation on the number of groups allowed. It also requires more complicated programming.
Do not concern yourself with design detail, in particular, field attributes such as lengths, edit codes, and allowed values, until you have established what the contents of your data model should be. Then, create a field reference file (FRF) entry for each field description, and refer every occurrence of the field to the FRF entry. For example, the FRF will contain a definition for Customer number, to which Customer numbers in the Sales order, Sales ledger, and Sales analysis files will refer. Every different type of date should have its own FRF entry: Date of birth, Expiry date, Order date. One of them may one day need to be changed to a different format. Define total and accumulator fields as having the base field length + n digits.
On your later design passes, consider interrogation requirements, especially if a rapid response is required. IBM gives a performance guideline of not more than 25 database accesses per transaction. The ‘Join’ operation may be used to lessen the need to introduce redundancy to achieve performance.
|
Copyright © 2014 CA.
All rights reserved.
|
|