. .

Subset Design Considerations - Some Do's and Don'ts

Do's

  • Get a training course if you can - if not, at least make sure you complete and understand the supplied hands-on exercises

  • Make sure you have, or have access to, sufficient knowledge of the application database

  • Consider the reporting requirements you expect to satisfy with this Subset - don't try to make it all things to all people

  • Consider the most likely common selection criteria - look to satisfy these from a node file (preferably the BOF) 

  • Make your initial design on paper and refine it until you're happy with it 

  • Track down the appropriate access paths and identify the correct key arguments to make each link

  • Understand the importance of the link dimension (is it one-to-one or one-to many?)

  • If it's one-to-many, don't worry about how many just yet - BUT MAKE SURE YOU KNOW WHICH IT IS

  • If it is one-to-one and you do not have a full key, you should use "Options - extended info" to choose "FIRST or *LAST 

  • Key in the Subset definition only when you are satisfied with your design

  • Verify its suitability with 1 or 2 "test" reports and adjust it if necessary before you build lots of reports

  • Get your data base files into your library list before you key in the Subset definition

  • Use *LIBL for the library-name field when adding file links

  • Use the text prefix with your links to add context to the dictionary field descriptions

  • Print and file the reports that result from the Subset creation

Don'ts

  • Design Subset with only one report in mind

  • Use specific library names when entering the file links (use *LIBL)

  • Don't guess at whether it's one-to-one or one-to-many UNDERSTAND WHICH IT IS AND WHY

  • If it is one-to-one and you don't have a full key, DON'T MAKE IT ONE-TO-MANY JUST TO GET PAST THE EDIT CHECK 

 

- Back -