|
Data Strategy - Chapter 3
(Continued from Page 1)
|
This white paper outlines the issues faced by BI operational staff in maintaining high quality of
BI information, and discusses technologies that have the potential to dramatically raise the
reliability and quality of BI information, improve how BI teams use their time and resources
to deliver rapid ROI and free resources to focus on answering business questions based on
reliable and meaningful data.
|
|
Many companies realize that they did not pay sufficient attention to data while developing systems during the last few decades. While delivery schedules have been shrinking, project scopes have been increasing, and companies have been struggling to implement applications in a timeframe that is acceptable to their business community. Because a day has only 24 hours, something has to give, and what usually gives is quality, especially data quality.
RECOGNIZING DIRTY DATA
When asked to define “data quality,” people usually think of error-free data entry. It is true that sloppy data entry habits are often the culprit, but data quality is also affected by the way we store and manage data. For example, old file structures, such as flat files, did not have strong data typing rules, and it was common practice to use REDEFINE and OCCURS clauses with those structures. A REDEFINE clause allows you to change the data type of a data element or a group of data elements. For example, a character name field can be redefined and reused as a numeric amount field or a date field. An OCCURS clause allows you to define an array of repeating data elements. For example, an amount field can occur 1–12 times, if you were capturing monthly totals for January through December. Relational database management systems and the new generation of object-oriented programming practices no longer encourage such untidy data typing habits, but they do not provide any deterrence for other types of data abuse, such as some extensible markup language (XML) document type definition (DTD) usage that propagates into the relational databases. Many of the dirty data examples described in the following list can be found in relational databases as often as they can be found in flat files:
- Incorrect data—For data to be correct (valid), its values must adhere to its domain (valid values). For example, a month must be in the range of 1–12, or a person’s age must be less than 130. Correctness of data values can usually be programmatically enforced with edit checks and by using lookup tables.
- Inaccurate data—A data value can be correct without being accurate. For example, the state code “CA” and the city name “Boston” are both correct, but when used together (such as Boston, CA), the state code is wrong because the city of Boston is in the state of Massachusetts, and the accurate state code for Massachusetts is “MA.”Accuracy of dependent data values is difficult to programmatically enforce with simple edit checks or lookup tables. Sometimes it is possible to check against other fields or other files to determine if a data value is accurate in the context in which it is used. However, many times accuracy can be validated only by manually spotchecking against paper files or asking a person (for instance, a customer, vendor, or employee) to verify the data.
- Business rule violations—Another type of inaccurate data value is one that violates business rules. For example, an effective date should always precede an expiration date. Another example of a business rule violation might be a Medicare claim for a patient who is not yet of retirement age and does not qualify for Medicare.
- Inconsistent data—Uncontrolled data redundancy results in inconsistencies. Every organization is plagued with redundant and inconsistent data. This is especially prevalent with customer data. For example, a customer name on the order database might be “Mary Karlinsky,” the same name on the customer database might be “Maria Louise Karlinsky,” and on a downstream customer-relationship, decision-support system the same name might be spelled “Mary L. Karlynski.”
|
|
|
|
|
