- Using the Internet
- Everyday Transactions
- Nontechnology Databases
- Summary
- Workshop
This chapter is from the book
This chapter is from the book
This chapter is from the book
Everyday Transactions
Most of us use databases daily and may not realize it. The following sections describe a few everyday situations in which people access and utilize data from a database. By understanding real-world, daily activities, you will gain a better understanding of database usage and will be able to better apply these concepts to understand the corporate world.
A couple of everyday transactions with which everyone is familiar are
Getting a prescription filled
Using a bank machine
Getting a Prescription Filled
The next example walks you through a process everyone does at some point—having a prescription filled.
As you are standing in your local pharmacy waiting for your prescription, you may not think that this transaction is database intensive. But, if you were to take a closer look, hundreds of gigabytes of data, maybe terabytes, are involved in this routine transaction.
When you evaluate a transaction like this one, it is helpful to look at one layer of the transaction at a time, peeling away successive layers, just like peeling an onion. Figure 3.8 shows the "layers" of this transaction that you will review.
)
Figure 3.8 Transaction layers for a prescription purchase.
The Doctor's Office Databases
You can start by looking back to the beginning of this transaction—at the doctor's office. A database must be kept of each patient, including data elements such as name, address, phone number, insurance carrier, closest relative, medical history, and family history. Billing records, payment receipts, appointment schedules, and insurance filing information make up other databases that are used often.
The Pharmacy Databases
The actual pharmacy has database information that it maintains on a broad range of subjects. The most obvious one is you—the customer. Every pharmacy will have, minimally, a database of customer name and address information, customer date of birth, prescribing physician and phone number, insurance carrier, and past prescription history of each customer.
The insurance company, HMO, or PPO provides each pharmacy with another database that must be used extensively. This database is called the formulary database. It contains an approved list of brand drugs, approved generic substitutions, dosages, and National Drug Code (NDC) information. Your insurance prescription card more than likely has a specific formulary that the pharmacy must reference to ensure that the drug used to fill your prescription, or an allowable substitution, will be covered by your insurance. This type of database may also be used by the physician's office to ensure that the drug they want to prescribe can be filled, without any substitution or dosage change, when you get to the pharmacy.
Another database that is used prior to filling the prescription is the drug interaction database. The prescribed drug may have serious interaction issues if used in conjunction with medications currently in use. The database identifies potential interaction problems, provides a detailed explanation of the interaction consequence, and possibly suggests alternatives.
After the formulary and interaction databases have been utilized, the prescription is ready to fill. The pharmacy inventory database is checked to determine whether the NDC being requested is in stock and at what shelf location it can be found. The inventory database must track expiration dates of each drug to prevent outdated medication from being dispensed. After the prescription is filled, the available on-hand inventory for your medication must be reduced by the quantity or volume of your prescription.
If the medication is not available in stock, the pharmacy must search through its wholesaler database to determine the best source for the drug. The wholesaler database identifies each of the wholesalers from whom the needed drug can be acquired, the cost from the wholesaler, and possibly the inventory availability at the wholesaler.
The final database to be reviewed at the pharmacy is the order database. This database contains all the outstanding orders that have been placed with all the wholesalers. They may represent simple inventory replenishment orders or special orders for drugs not normally stocked. If the orders are for narcotic items, or Schedule 2 drugs, special order and tracking requirements must be met to satisfy the requirements of the Drug Enforcement Administration (DEA). Figure 3.9 shows the database entities involved at the pharmacy layer.
)
Figure 3.9 Pharmacy layer databases.
The Wholesaler's Database
As you continue to peel away layers in the transaction, you see that the next layer represents the drug wholesaler. The pharmaceutical supply chain in the United States is typically serviced by a wholesaler that operates between the manufacturer and the retail or hospital pharmacy.
The wholesaler layer begins with an extensive customer database. Name, address, billing address, and accounts receivable information are maintained. A customer who represents a large chain, such as K-Mart, may have Ship To destinations all over the country. Each of the Ship To locations must be maintained separately for order tracking and for sales analysis purposes.
A separate database that identifies every drug and strength is used by the wholesaler to ensure that the customer's intent on which drug they want to purchase from the wholesaler is clear and, in turn, to make sure the drug the wholesaler purchases from the manufacturer is explicitly identified. This database, by NDC number, changes frequently with new manufacturers, generic suppliers, dosage changes, and the constant introduction of new drugs. The management of this type of database has spawned new businesses in the pharmaceutical industry because of its complexity and volatility. Many wholesalers purchase this database with quarterly updates to ensure that they have an up-to-date NDC database.
Most national and regional wholesalers have multiple distribution centers, or DCs, located throughout the country or throughout the geographical area they serve. Each of these DCs has an inventory database that is a focal point of their operations. The inventory database must identify each item that the DC stocks, and for each item, many inventory management attributes are tracked. Something as simple as the picking location can include a forward picking location, a backup picking location, a bulk location, a backup bulk location, packaging quantities, packaging dimensions, packaging weights, expiration dates, and lot-tracking information along with inventory quantities at each location. With thousands of items at a DC, you can begin to see the complexity and size of the inventory database required for each DC within a wholesaler's operation.
The wholesaler's database will always include, among other items, a shipping and invoicing database and an accounts receivable database. Figure 3.10 shows the database entities involved at the wholesaler layer.
)
Figure 3.10 Wholesaler layer databases.
The Manufacturer's Database
A manufacturer has many databases that are very similar to those of the wholesalers. The supply-chain relationship between pharmacy and wholesaler is very similar to the relationship between wholesaler and manufacturer. There are a few additional databases, though, that are unique to the manufacturing process.
The first unique database you will look at in this layer of the transaction is the product database. The product must contain a list of raw materials, or recipe ingredients, that make up the product. Careful attention must also be given to the manufacturing process. The FDA (Food and Drug Administration) expects every manufacturer to stringently adhere to the recommended process to produce the drug. The database has extensive instructions and quality control data for each step within the routing or operational steps in the manufacturing process.
The other database that is unique to the manufacturer in this transaction is one that tracks the capacity of each manufacturing process. Whether it is a material movement operation, a mixing operation, an application of heat, or a packaging operation, each operation has a finite limitation in terms of hours available and capacity. A complex database is required to look at all the scheduled shop orders, retrieving the lot size of each order, multiplying the shop order quantity by the routing quantity, and then determining the work center or material-handling equipment necessary to complete the operation. Each of these extended routing operations are aggregated by work center and compared to the finite limitations noted earlier. The required due dates of the shop orders are used as a starting point, and the entire process is backward scheduled to determine when the shop order would need to begin to meet the required completion date. When you factor in scheduled and unscheduled maintenance, breakdowns, and required setups and quality inspections, the database necessary to adequately evaluate capacity requirements and material requirements planning is significant. Figure 3.11 shows the database entities involved at the manufacturer layer.
)
Figure 3.11 Manufacturer layer databases.
Using Your Bank Machine
The next example involves a transaction that takes only a few minutes to complete—you are going to look at the databases that are used when you visit a bank and use the ATM.
Don't let the quickness of the transaction fool you—the databases are busy whenever you walk up to use the ATM! You will look at the account database and the financial transaction database in a cash withdrawal example.
When you insert your ATM card into the bank machine, the first thing that must be completed is to identify the account number of the user. The user may be using a local bank or may be using another bank that is part of a participating network. The bank must search its account databases and try to find a match within their system. If this fails, the account number can be searched against a database that represents participating banks.
After an account record is identified, the user is prompted for a PIN, or personal identification number. The PIN is verified against a database entry. The transaction, for obvious reasons, is canceled if the user does not supply a matching PIN.
After the PIN verification is completed, the account details are retrieved from the database regarding the types of accounts that you have—checking, savings, or both. The ATM prompts you for the type of transaction you are interested in completing. Typical transactions are deposits, withdrawals, transfer savings to checking, and check account balances. For this transaction, you are going to withdraw cash from your checking account.
Now it's time for you to indicate how much cash you need. A couple of databases must be accessed at this point. The first is easy—determine how much money you currently have in your account. The second is more involved because most ATM systems limit your withdrawal amounts in a 24-hour period. The system issues a SQL select statement against the database to add the transaction amounts of all withdrawal transactions for your account within the most recent 24 hours. If the daily limit minus the returned summed amount is greater than your transaction amount, you get the cash. If not, you will be limited as to how much can be withdrawn, or you may not qualify to receive any cash.
Beyond the portion of the transaction that you see, a couple more databases are being used. The transaction must be recorded, with account number, account type (savings or checking), date, time of day, type of transaction, and amount. This is used to post the transaction to your account and compute your current balance. This is the database of transactions that you see on your statement at the end of your banking period. The transaction is also used to post to the general ledger database for the bank. If any ATM charges apply, these annoying charges are recorded in the transaction database described previously.
The final database is composed of ACH (Automated Clearinghouse) transactions that are forwarded to the Federal Reserve System so that banks can clear transactions across the country. Each of these transactions are logged to a transaction database for reconciliation purposes in the event of a failure within banking computer systems.