ContentsIndexPreviousNext

6.2.2 How Relational Databases Organize Data

Because SQL is designed to work with relational databases, you should understand the way relational databases organize data before attempting to write an ODBC program.

In general, where COBOL manages data using files, databases manage data using tables. A table is composed of rows and columns. Each row corresponds to a record, while each column corresponds to a single field from all of the records.

Even though, using AcuODBC, you are gaining access to an indexed or relative file system, you will have to write SQL statements referring to "tables" and "columns." AcuODBC uses a data dictionary to convert COBOL data files into database tables that can be accessed with SQL commands. (Refer to Chapter 7 for more information on data dictionaries.)

For example, a COBOL record structured in the following way:

01  CLIENT-RECORD.
    03 COMPANY-NAME     PIC X(30).
    03 ADDRESS             PIC X(30).
    03 ZIP-CODE            PIC 9(5).
    03 TOWN                PIC X(30).

would be interpreted as the following table by AcuODBC.

Company Name
Address
Zip Code
City
Acucorp Inc.
8515 Miralani Drive
92126
San Diego
Acucorp Deutschland GmbH
Otto-Hahn-Strasse 9
61381
Friedrichsdorf Koeppern
Acucorp Italia srl
Via I Maggio 3
29100
Piacenza

Each COBOL record can be viewed as a row of a table. In this example, each row contains a complete set of information regarding a single client. Columns specify the type of information we have gathered for each client.

A difference is that COBOL records can define certain data types which database tables cannot define. For example, COBOL can redefine records or fields, and define arrays with the OCCURS clause. This representation of data is not supported by relational databases and therefore is not supported by SQL.

In addition, COBOL programs can redefine records so that two different database columns actually occupy the same record location in the COBOL data file. Attempting to modify such columns is not valid, and will result in an error.

Another difference is that Vision and relative records don't have any type-checking. Just because a field is defined by the database as numeric is no guarantee that there is actually numeric data in every row. This may cause problems with some applications that try to display or update data that is invalid for a particular column.

If you define characteristics in your records that are not supported by the RDBMS table structure, you must include special comments known as directives in your FD, as described in Section 7.3, Using Directives.