A CA IDMS database consists of physical occurrences of data whose types are defined within the database's logical description. Types of data are generic descriptions of occurrences of that type.
As an example of data occurrences and types, consider a file of employee information at a company called Commonweather Corporation. The names of the employees on the file, such as John Done and June Moon, are data occurrences. The names actually exist as characters in a disk file. The type for these data occurrences is a description that fits all possible occurrences, which in this case might be defined as "An employee's name consists of 25 alphanumeric characters. Short names shall be padded on the right with blanks. Long names shall be truncated."
To be useable by a program, the description must be specified in a standard way. For example, a COBOL program using employees' names might include the following in its DATA DIVISION:
EMPL-NAME PICTURE X(25).
For CA IDMS databases, types are defined separately from programs and are part of the database's definition residing in an application dictionary. Type definitions are copied into a program during the pre-compilation process.
Types can be singular items, such as that representing an employee's name or groups of items representing a complex type such as an address or an entity such as an employee. When modeling a process or an enterprise, entities often represent things that impact or are impacted by other things.
As shown in the following table, the terms used for these various constructs depend on whether they appear in the definition of a relational (SQL defined) or network (non-SQL defined) database.
Construct |
Relational Term |
Network Term |
---|---|---|
Singular type |
Column |
Element (record element, data item, field) |
Complex type |
-- |
Group element |
Entity type |
Table |
Record type |
Copyright © 2013 CA.
All rights reserved.
|
|