Bert Moore

Abstract

This presentation will introduce distributed micro-databases, a new tracking concept for equipment maintenance, asset management, storage warehousing, document archiving and other applications where material is stored for extended periods of time.

Using bar codes and touch memory, distributed micro-databases provide immediate access to location, history, status and other pertinent data.

Introduction

In data processing, we've seen a steady progression away from centralized databases on mainframes and towards distributed databases running on midrange and PC computers.

While the influence of increasingly powerful and cost-effective mini- and microprocessors can't be denied, a more significant reasons for this decentralization was the desire to provide access to data to those people who need it for day-to-day decision-making.

This trend has progressed even further, with the arrival of notebooks, palmtops and intelligent hand-held terminals. Portions of a main database are downloaded for routine activities. These are, in effect, distributed mini-databases.

Micro-databases are a further extension of this trend.

The scenarios I will present utilize bar codes for data entry and button memory as the micro-database "host."

Overview of a Micro-Database

Micro-databases are intended to augment, not replace, centralized databases. They will relieve the main database of additional complexity and I/O burdens by providing local storage of, and access to, information.

It's important to note that distributed micro-databases are not practical for every application. There are several characteristics which may indicate that a micro-database approach might be beneficial.

• Materials are stored for extended periods of time but may be frequently removed for short periods of time for review, inspection, research, repair, or
• frequently moved for consolidation. or other reasons.
• The tracking application is running on a PC which has limited processing and storage capacity.
• Access to a central database is not feasible and downloading all pertinent data to a hand-held terminal is not practical.
• There is a need to provide a history of activities on a local level.
• Local redundancy for a master database is desired.

Application Scenarios

The following examples highlight reasons that distributed micro-databases might be used. While these examples demonstrate real needs, they shouldn't be taken to be the only applications for distributed micro-databases.

It is hoped that they will stimulate your own thinking about how micro-databases could solve problems in your facilities.

• A large company wants to track its office furniture and equipment using bar code labels. This material, however, is often temporarily moved from one space to another to meet changing demands. Performing ongoing database updates of hundreds of items which are only temporarily moved becomes a problem. However, not maintaining the database greatly reduces the reliability of the project.
• A document warehouse wants to track file boxes using bar codes. Material is frequently requested by the customer for review, then returned to storage. Tracking these temporary removals is important but begins to overburden the database.
• A museum storage facility wants to use bar code tracking for its collection. However, many of these items occupy many "locations" on a shelf while many others may be put in the same "location." Material is frequently cycled in and out from other parts of the museum. Maintaining the specific "sub-location" of all these items would exceed the capacity of the current computer system.
• A utility company has equipment in the field which is routinely inspected. An inspector may visit 10-20 locations a day. For the inspector to adequately evaluate the status of equipment, maintenance histories are sometimes required. Downloading the maintenance history of all equipment at all locations the inspector may visit isn't feasible and dial-up or cellular connection to the central database isn't practical.

How Micro-Databases Work

In the preceding examples, bar code identification labels or menus would be used to provide data input. This data would then be downloaded to a memory button for storage.

When updating of the central database is required, reading a limited number of contact memory is all that's required. To access local information, a portable computer equipped with a memory button reader or other suitable terminal would be used to call up the pertinent data.

In terms of the examples, this would operate as follows.

Fixed Asset Tracking

Bar code/touch memory readers would be used to record all equipment and furniture moves.

As each item is removed, the bar code label would be read. A bar code menu indicating whether it's a permanent or temporary move, the reason for the move and the intended location would then be scanned.

This information would be stored in the memory button for the location. The delivery location's memory button would be similarly updated.

When material is returned to its designated area, the "local" inventory would be adjusted.

For permanent moves, the appropriate records could be uploaded to the central database.

Performing a real-time physical inventory, then, would only require the reading of the contact memory for each room or location, rather than each individual bar code symbol.

Document Control

Bar codes identifying each file or file box removed from storage for temporary review would be scanned along with the location bar code. A bar code menu would record the activity (removal or return), and reason. The employee's ID and a date/time stamp would be added to the record.

This information would then be stored in a memory button at the end of each storage location.

As materials are returned, the "local inventory" would be updated.

The central database, of course, would maintain an audit trail of the activities but would not need to record every detail.

Storage Location

For the museum application, the same approach would be followed. Bar coded items and locations would be scanned, activities, destination and reasons recorded from a menu, and employee ID and date/time appended.

This record would be stored in the button memory at the end of the rack or in another convenient location.

In this application, the sub-location would only be stored in the memory button. The central database would know, for example, that the upper wing for a World War I "Jenny" airplane is in Building C, Rack 17. The memory button on Rack 17 would record the exact location as "Shelf 2, Locations 15-37." This distribution of data could significantly reduce the storage and processing requirements on the collection tracking computer system.

Equipment Maintenance

Each major piece of equipment, assembly or location would be equipped with a memory button. These would serve as the local database for maintenance history.

As equipment is inspected, repaired, or replaced, bar code menus would be used to record the specifics of the activity, date and other pertinent data.

This information would also be stored in the master database.

Inspectors or maintenance personnel would have direct access to the entire maintenance history of any given item, permitting them to make better assessments of its condition or possible problems.

-

Note