Open Enrollment | Subscribe to Printing Impressions HERE
Follow us on

Dickeson--Give Poor Roger's OLAP a Look

February 2000
Most of us in printing use relational database technology for accounting and production files. Job-cost and general-ledger files we keep in relational tables; transaction processing is what we do.

That's cool, but industry is zipping by us, leveraging data to make critical decisions. Printers are living in the days of OLTP: Online Transaction Processing. But the world around us is moving into variants of OLAP: Online Analytical Processing technology.

Let me use a personal example to illustrate. I've maintained a database of web printers for nine years. It's a "relational" database consisting of four tables or files. Table One is for companies. Each company has an ID, a number that identifies it. Table Two describes the dozen or so products that presses produce. Table Three details the presses, their IDs and the IDs of the companies operating them, as well as product IDs. Lastly, there's a "transaction" file: Companies send me monthly operational data for their presses, and I enter a record for each press, including the ID numbers of the company and the press, as well as the data for time intervals and impressions.

It's a "rationalized relational database" set up for OLTP. Each transaction record is "related" to a company, a press and a product.

Know What to Know
It's easy to enter transaction data each month: I don't have to repeat a string of data for each company, press and product. Nor do I use up a lot of disk storage space or "read" time for the disk drive heads. I publish structured reports using special report-writing software that "joins" the tables using the ID number relationships.

That's also the way our general-ledger and cost-accounting systems work. They're designed to speed entry of transactions at different terminals feeding a network. They use "rationalized" tables that relate to transaction tables for joining by the computer in data processing. Fine and dandy, as long as you know what you want to know.

The trouble with us humans is that we think. We think we know what we must have when we design a system but, at the design stage, we don't know what we don't know. That's where that Latin phrase "ad hoc" enters the scene: We demand answers from a system for questions that occur to us as we ponder some decision or action. Ad hoc questions occur in this specific situation. We want to cross-examine those computer data tables, regardless of transaction entry ease at this point; we want analytic ease for decision support. Right now.


Companies Mentioned:


Click here to leave a comment...
Comment *
Most Recent Comments: