Databases Reference
In-Depth Information
and information portals, you can afford to offer assistance to customers who really need special atten-
tion. Customers often need to look up account and transaction histories, order status, and shipping
information. Making these services available through a web browser, e-mail, or a mobile device can
provide a greater degree of customer satisfaction.
Vendors and Partners
Like customers, business vendors may need to interface with an organization to place orders, schedule
service calls, and obtain status information. Making this information available in the most appropriate
form will improve efficiency and ultimately business-vendor partnerships. Business vendors are often
more accepting of special procedures and automated systems. Vendors can be trained to use more
sophisticated systems to obtain product information, service orders, invoices, and other business-related
information. Systems may be designed to interface and automate the download or exchange of informa-
tion that enable a partnering business to work cooperatively.
Reporting Solution Alternatives
The following section discusses some common reporting solution alternatives. The alternatives usually
represent an evolution in a company's reporting sophistication. Generally, organizations start with some
main reports from an OLTP (Online Transaction Processing) system. Once they meet the limitations of
the OLTP system, they evolve their reporting into data warehouses. Eventually, even more complex
reports and interactivity are required. This usually leads to the implementation of an OLAP system. We
will take a look at each of these alternatives and their relative advantages.
Reporting with Relational Data (OLTP)
Transactional databases are designed to capture and manage real data as it is generated, for example,
as products are purchased and as services are rendered. Relational databases are designed according to
the rules of normal form and typically have many tables, each containing fragments of data rather than
comprehensive information or business facts. This helps preserve the integrity and accuracy of data at
the detail level, but it presents challenges for deriving useful information from a large volume of trans-
actional data. In order to obtain information with meaningful context, tables must be joined and values
must be aggregated.
For simple report requests, this usually is not an issue. Take the example of an invoice. An invoice is a sim-
ple report. It displays custom information along with detail for a small number of transactions. For this
type of report, querying an OLTP system is not very costly and the query should be relatively straightfor-
ward. However, users will eventually move past these simple reports as they start to look for information
for an entire year or product line. Developing these types of reports will eventually consume considerable
resources on an OLTP system as well as require increasingly difficult queries. Although relational database
systems may support complex queries, reporting against these queries routinely could prove to be slow
and inefficient.
Relational Data Warehouses
I have seen many organizations evolve away from reporting on their OLTP data. Usually their first step
is to create a carbon copy of the OLTP system on another server. This alleviates the resource constraints
Search WWH ::
Custom Search