Data Structures
Two Parent Tables and One Child Table shows how keys can be co-ordinated. When key1 pairs up with key2, a new entity is born.
|
.One Parent Table and Two Child Tables: this diagram is the basis for many comparative screens. The number of child records has no theoretical limit. For example, the description of a student might have the one parent record and many child records.
|
Program Table
This table has a record for each program. The record contains descriptive data, conditions, and simple statistics. In the typical business, every employee has a badge. This table fulfills a similar role for programs.
Program Logs Table
Every run of every program produces two log records under normal conditions: one initial record and one final record. The initial record should come from early in the program and the final record from near the end. The lack of a final record suggests a program crash. Detecting the lack of an initial record is harder unless the program specifically is being tested.
Parameter Tables
These tables contain names of modules and parameters for those modules. In older systems, these parameters existed as field on records and the re-usage of fields could become confusing. For example, given many records, the first field might contain a capital Y, but the meaning of each capital Y would differ from record to record. In current systems, the parameters exist more commonly as HTML tags. These are easier to understand, but they also require more sophisticated software to read and to write. (Libraries of routines are wonderful.)
Data Codes Table
Every system has a similar table; this table contains general codes and codes that are specific to certain fields. For example, income tax tables or payroll tables. Chemistry periodic tables. Statistical tables galore. Good data tables can remove the control of logic from inside the program to a table that a well-informed clerk can maintain.
Data Dictionary
Every field has an entry here. This sounds like a lot of work, but this helps define the system thoroughly. Extensible systems use dictionaries to introduce new fields and objects. Records here contain the name of the field, an English description, a default label and a default format, a status, and possibly some edit controls, like positive number, or phone, or date.
Messages Table
When carefully set up, this table helps greatly in debugging, particularly when a clerk calls the help desk. If this message is precise, the solution is likely precise. Also, in switching languages, this table can be useful; the error number of the same, but the language is different.
Screen Tables
These tables describes the screens and sub-screens and fields
HTML Tables
These tables contain the building blocks for computer generated pages or documents.
Data Extension Tables
These tables contain data that relates to main tables. The typical keys are a table name, the value of the particular primary key of that table, and a tage to identify the subsequent value to the program and thus to the dictionary. At NEC, a manager could extend a major table like vendors by making three entries. For example, beepers, pagers, teletypes, and drop-boxes came and went during the 80's and 90's. Rather than add a separate field for a beeper to the vendor table, the manager could take three steps:
Data Control Records
The a program called cr1main ran as the cash register at the Group. The main logic was held in ASCII files that described the operations in a form of pidgeon-English called Cash-Speak. The first level controlled logons and logoffs. The next level control navigation between screens and sub-screens. The third level controlled navigation and called edits within a screen. The fourth level was incomplete and had a few edit controls about fields in the data buffers. The language was simple enough that upper management took an interest. The fifth level contained many edit controls, like:
CHECK_AMT: IF ACTIVE=TRUE AND AMT > 50: DRLC
A VP could command that a checks over a certain amount required ID from the buyer; the VP could implement the request by changing the dollar amount on a certain line of the control file. Similarly, a VP could change the sequence of fields on a screen. A VP could turn on or turn off other data checks. The language was incomplete, but having the language greatly reduced the maintenance time. For example, the VP could change the incentive for large sales by making a change in the file and then having the Chief Cashier at Headquarters send the file to every store in the morning broadcast.
This table has a record for each program. The record contains descriptive data, conditions, and simple statistics. In the typical business, every employee has a badge. This table fulfills a similar role for programs.
Program Logs Table
Every run of every program produces two log records under normal conditions: one initial record and one final record. The initial record should come from early in the program and the final record from near the end. The lack of a final record suggests a program crash. Detecting the lack of an initial record is harder unless the program specifically is being tested.
Parameter Tables
These tables contain names of modules and parameters for those modules. In older systems, these parameters existed as field on records and the re-usage of fields could become confusing. For example, given many records, the first field might contain a capital Y, but the meaning of each capital Y would differ from record to record. In current systems, the parameters exist more commonly as HTML tags. These are easier to understand, but they also require more sophisticated software to read and to write. (Libraries of routines are wonderful.)
- the module describes a group of programs, like payroll, or some smaller group
- the parameter belongs to the module and has its own key
- the parameter codes table is a list which belongs to a parameter
Data Codes Table
Every system has a similar table; this table contains general codes and codes that are specific to certain fields. For example, income tax tables or payroll tables. Chemistry periodic tables. Statistical tables galore. Good data tables can remove the control of logic from inside the program to a table that a well-informed clerk can maintain.
Data Dictionary
Every field has an entry here. This sounds like a lot of work, but this helps define the system thoroughly. Extensible systems use dictionaries to introduce new fields and objects. Records here contain the name of the field, an English description, a default label and a default format, a status, and possibly some edit controls, like positive number, or phone, or date.
Messages Table
When carefully set up, this table helps greatly in debugging, particularly when a clerk calls the help desk. If this message is precise, the solution is likely precise. Also, in switching languages, this table can be useful; the error number of the same, but the language is different.
Screen Tables
These tables describes the screens and sub-screens and fields
HTML Tables
These tables contain the building blocks for computer generated pages or documents.
Data Extension Tables
These tables contain data that relates to main tables. The typical keys are a table name, the value of the particular primary key of that table, and a tage to identify the subsequent value to the program and thus to the dictionary. At NEC, a manager could extend a major table like vendors by making three entries. For example, beepers, pagers, teletypes, and drop-boxes came and went during the 80's and 90's. Rather than add a separate field for a beeper to the vendor table, the manager could take three steps:
- add entry to the Data Dictionary for a new tag called beeper
- add a field to a screen table in a vacant place and reference the new tag
- go to the vendor screen and input data into the new field
Data Control Records
The a program called cr1main ran as the cash register at the Group. The main logic was held in ASCII files that described the operations in a form of pidgeon-English called Cash-Speak. The first level controlled logons and logoffs. The next level control navigation between screens and sub-screens. The third level controlled navigation and called edits within a screen. The fourth level was incomplete and had a few edit controls about fields in the data buffers. The language was simple enough that upper management took an interest. The fifth level contained many edit controls, like:
CHECK_AMT: IF ACTIVE=TRUE AND AMT > 50: DRLC
A VP could command that a checks over a certain amount required ID from the buyer; the VP could implement the request by changing the dollar amount on a certain line of the control file. Similarly, a VP could change the sequence of fields on a screen. A VP could turn on or turn off other data checks. The language was incomplete, but having the language greatly reduced the maintenance time. For example, the VP could change the incentive for large sales by making a change in the file and then having the Chief Cashier at Headquarters send the file to every store in the morning broadcast.