Classic Computer Magazine Archive ANTIC VOL. 2, NO. 3 / JUNE 1983

Data Base Basics

An overview

by Ken Harms

People display a seemingly insatiable desire to keep track of information. My wife is organizing data on 600 Girl Scourts for their summer camp. I have a file of participants in a research study. My neighbor's job requires tracking the court appearances of various miscreants. All of these chores cry out for an efficient way to store and use information, and in answer we have the computerized Data-Base Management System (DBMS).

This issue of ANTIC surveys most of the DBMS products available for the ATARI. This article introduces DBMS concepts and terminology, and explains how to determine if using one will really make your work easier. Other articles will survey the features and functions of specific systems.


For our purposes, the smallest unit of data manipulated by a DBMS is the character. Characters are letters, numbers, punctuation marks and other symbols that can be entered from the keyboard. The ATARI also generates "graphics characters," but most data bases don't accept them. A single character may be meaningful by itself, for example, the numeral "2" or the letter "a." Characters can also be grouped logically, for example, the number "25" or the word "monkey."

Characters, grouped or standing alone, are the data. All data must appear in appropriate, designated places, and these places are called fields. A field is an area within each record where data of a particular kind is entered and stored. For example, a field to hold a name might be called the NAME field. Every field must have a stipulated length, so let's give NAME field a length of ten character spaces. This will accomodate names like "Smith" or "Richardson," but "Stanislavsky" will be chopped off at the "k." Fields may also be restricted to either alphabetic or numeric characters in some instances.

A record is a group of related fields which contain all the information about the particular thing or person to which the record relates. The title, author, publisher and subject of a book, for instance, would be a record. Records have several characteristics, such as number of fields and relationship to other records.

A file is a related set of records all of which share an identical file structure. All the book title cards in a library constitute a file. The author cards are a separate file. Files are usually referred to by name, or by the type and number of records they contain. In addition to files of data entered by users, a DBMS will create and use special files which describe the records, fields and characters in a file, or define the reports the user wishes to see.

FIELDS are groups of characters describing a logical piece of data. Records are groups of fields describing a total unit of information, in this case the name and address of a person. A file is a collection of records. In this example, only three records constitute the file.

A data base is a set of related files. In the systems now available for the ATARI, a data base consists of files created by users, plus several auxiliary files. One of these, the definition file, contains descriptions of records (field name, number, length, type, etc.). Another, the report file, describes characteristics of reports such as which fields to print, where to print them, which fields to subtotal, and which order to list the records.

Finally, a Data-Base Management System is a set of computer programs which allows you to create records, fields and reports, enter data into files, and delete, change, search, and sort those data. In larger computers a DBMS allows you to use several data files simultaneously. DBMSs for the ATARI, however, are limited to one data file and are, therefore, often called file management systems.

The programs in a Data-Base Management System will ask you how you want your data recorded (the file definition program), and then let you enter and revise your data (the data entry-update section). You'll then be able to search through your records to locate specific data you need and sort the file into the order you wish (the search / sort module). The report writer section of the system will ask you how you want your records printed and will then produce lists of your file on the screen or printer. Finally, some of the systems will let you build new files from the data in one or several existing files (the merge/reorganize program).


It's easy to write by hand various information about the 250 contestants in your tennis tournament. The computer won't save time there; unless you're an excellent typist, data entry will be slower than handwriting. But when you need to write all those names on envelopes, or when the tournament director requests both an alphabetical list and a list by club affiliation, your typing time will have been repaid many times over.

A DATA BASE consists of related files. A definition file describes the record in terms of field lengths and types. A report file describes report characteristics such as which field to print, where and when to subtotal which fields. A data file contains user data such as names or amounts. Files with pointers to data records for random access are often required but are invisible to the user.

Flexibility is the keyword for a good DBMS. Flexible systems allow you to define records as you collect the data, and then change that definition as your needs change. You'll be able to search quickly for specific records, then change the data in them (when a player moves, for instance). You'll be able to sort your records into different sequences for different reports. Finally, the full-scale systems will allow you to describe different reports with different fields in different sequences with subtotals and totals on the fields you wish. Often, the system will compute results from data you've entered; a sales value, for instance, by multiplying number of units sold by selling price.

Since these systems are necessarily complex, the designers put great effort into making them easy to use. Prompts on the screen ("Load this file?") or "help" screens with full pages of the manual are available in a good system. And, of course, the DBMS is useless if it isn't error-free.


First, decide whether you'll need the data in your file sorted in different sequences, reported in different ways, or updated (changed) frequently. If you do, you're a candidate for a DBMS. Next, decide whether your application (the file and all reports from it) will fit one of the systems available. As a first step in this process, you might take a 3 x 5 card and describe the fields you plan to store. Enter a field name, such as Last name, First name, etc. Then, below the field names, write samples of the data you'll record; "Robertson, John," for instance. Fill out several cards, one for each record. Count the fields and guess the length you'll need for each field, then add the field lengths to compute the record length. Then, estimate the number of records you will use in a file. Finally, compare these numbers to the "capacity" charts in following articles. If everything fits, you may wish to examine the features and choose a specific system for your work.


A DATA FILE may be organized in one way and reported in different orders. In this example, a name and address file with addressees' interests, age and dues paid, is organized by DBMS sort and report writer programs into a report by interest area with total dues by area. The report omits data not needed for this use. The data file could be sorted in different orders and reported in different formats.


Although some systems get by on 16K of memory, you'll probably find your file size severely limited. In general, plan to have at least 40K and, even better, 48K. Get 48K for all the fullscale systems, no matter what the manufacturer says.

All the systems in our survey need at least one disk drive. Some, however, could certainly benefit from two drives -to eliminate disk swapping. Only continued on next page one of the systems takes advantage of the double-density feature of Percom drives. The rest should operate with Percoms in single-density mode. Only one system now officially supports the 80-column card from BIT 3, a nice feature for this type of program. And only one system works with the RAMDISK 128K memory card. Would you believe that each of those "one systems" is a different system?

A printer seems almost a necessity for most applications. The systems will work fine without a printer, however. If you can borrow a printer when you need one, that should be okay.


Murphy's Law guarantees that "whatever can go wrong, will." After watching many disasters, I'm a firm believer in seeing all parts work together before buying. A long visit to a reputable dealer who will let you test the software on your application is always a wise step. Bring your own hardware to the store, if necessary. But whatever you do, try it out yourself. The several hours you'll spend here may save hundreds of dollars spent on hardware that won't do what you need, or a program that doesn't feel right.

Ken Harms, our Contributing Editor usually responsible for PILOT articles, is Vice President of Administration for the California Division of the American Cancer Society. Familiar with large data bases and mainframe applications, he courageously waded through the enormously complex comparison of the nine DBMS products surveyed in this issue.