Dickeson–Give Poor Roger’s OLAP a Look
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.