We are talking about databases, of course. In a prepaid application, there are dozens of database tables that provide critical information to the application. Examples are databases that contain information about PINs, balances, agents, distributors, carrier destinations, routing information, voice prompts, revenues, costs and personnel. The list goes on and on. The underlying technologies that power databases are extremely complex, abstract and difficult for a lay person to understand, which is why databases insulate users against their intricacies as much as possible. If you want to see how complex databases are, go take a look at an SQL (structured query language) manual. SQL is the most common database language used today, and, even though there is a standard or two, there are dozens of variations.

Because databases are so complex, difficult to manipulate and prone to problems, users are often unaware that they are using databases. What you see instead is a “front end” that interprets the esoteric output and the cryptic input of the database in terms that are understandable for users. So, what the user sees is a friendly, easy to use and intuitive set of forms and screens, making the database accessible for anyone. The database server, or “back end” does all the dirty work of updating, adding and deleting records, changing the information as needed. The back end also enables multiple user access, so that many people, and programs can access the database simultaneously. Actually, seemingly simultaneously, but that is a story for another class.

I alluded to some of the functions that are supported by databases, but let’s take a look at a couple of concrete examples. First, the prepaid application must store the necessary information about PINs, including the PIN number, date activated, the initial denomination, the rate table to be used and a list of the calls made, and the cost. Actually, this information may be spread over several different tables. The list of calls, and the charges may actually be in one, or more tables, linked to the PIN table.

Likewise, the rate table is linked to the PIN table. Otherwise, each PIN record in the PIN table would have to have its own copy of rates. By linking the PIN table to the rate table, we can keep one copy of the rates, saving a lot of disk space and processing time.

Other tables may keep track of routing information, sales information, agents, commissions and other distribution details. Internal to the applications itself is another array of databases for prompts, program errors, traffic and more. Some applications are actually controlled by a database containing the steps in the program, making it easy for the programmer to modify the application or to add new functions. Most accounting systems are databases that are tuned to store and process financial and accounting information.

All these databases, with their continuously changing data, must be regularly backed up, or mirrored. Mirrored databases store the information on two different processors for robust redundancy. RAID (Redundant Array of Independent Disks) arrays, with various levels of inherent redundancy, are also commonly used to provide fast access and security.

Finally, you have to be concerned with security regarding databases. Making sure that the various users of the databases have exactly the right level of access is important. If your level of security is too low, someone may be able to see, or change data that they should not be able to access. Too much security, and users may not be able to access the data they need to perform. Databases have security levels that are very detailed, allowing control of individual fields that can be viewed, searched or changed. This is a task that takes a lot of experience and thinking to get right.

This should give you some idea of the importance of databases in prepaid, and how they are used to control applications and run the business.

See you next class!