Managing Reference Data in Enterprise Databases: Binding...

Features

• Cover Type: Hard Cover with 387 pages
• Published by: Morgan Kaufmann
• Edition: 1st Edition August 2000
• Written in: English
• ISBN 10 Number: 1558606971
• ISBN 13 Number: 978-1558606975
• Book Dimensions: 9.6 x 7.7 x 1.1 inches
• Weighs: 2.1 pounds

Product Review
Managing Reference Data in Enterprise Databases explores technologies and techniques for managing data that's used to categorize or sort data, with emphasis on keeping it clean, consistent, and current. Reference data, in the lingo of author Malcolm Chisholm, is primarily any data that is used to categorize other data. The U.S. Postal Service abbreviations "PA" for Pennsylvania and "HI" for Hawaii are examples of reference data. Under Chisholm's definition, reference data is generally not data that exists on a remote system, or that another organization maintains. This book has an academic tone and steers clear of implementation issues that exist in particular database management systems (DBMS); it's a platform-independent engineer's handbook, full of structural diagrams, standard SQL queries, and pseudocode.

Using the clear and widely understood IDE1FIX means of graphically representing table relationships, the author shows how reference tables exist alongside other database contents. He presents some of the reference data problems that pop up in real life (in one succinct example, he writes about getting bonds rated "AAA" to come ahead of bonds rated "A," even though "A" comes first in ASCII sorts). His content will make you think about how to redesign your databases to use reference data more reliably, and offer you enough advice to enable you to realize your designs. --David Wall

Topics covered: Efficient database design as it relates to reference data, or data that's used to categorize other pieces of data. Sections deal with establishing table relationships, deciding on special values (such as those for "none" versus "not applicable"), and dealing with multiple languages. There's also information on referring to remotely maintained reference data, such as abbreviations lists maintained by the International Standards Organization (ISO).

Product Review
"This is an great book that brings out for the first time a comprehensive view of the problems and opportunities that are associated with reference data as part of an organisation's information systemsHe also provides great summaries of the risks and benefits that can accrue when considering establishing an operational reference data management service. He highlights the important aspects of reference data value maintenance involving data ownership and data stewardship" -- Arthur Haynes
Chairman, British Computer Society's Data Management Specialist Group

Reader Reviews
This unique book fills a much needed void in data architecture and system design. Reference data is too often done as an afterthought when data architecture starts taking form. Worse, it is too often misused, resulting in no clear boundaries between transaction data structures and real reference data. Mr. Chisholm starts with definitions of what reference data is, and what it is not. He defines reference data as data that is used to categorize, classify, or otherwise qualify or constrain transaction data. In other words, reference data is typically used in look-up tables. This brings us to what reference data is not - it's not transaction structure data, although it is commonly miscast into this role. To see the difference using an example from my own experience, a two column table of reference data could be a digital phone manufacturer and the first three octets of an electronic serial number that is assigned to the manufacturer. This is static. Extending this example to another table of reference data that is keyed to the first could be the manufacturer and specific phone models. While models come and go, this is still static and qualifies as reference data. However, a designer might be tempted to include a table that lists a specific phone, keyed on the electronic serial number, but also keyed to a status, such as active, inactive or stolen. This is a transaction structure because it changes based on a number of conditions, such as if the equipment is active and assigned to a customer, or in stock. Therein lies the distinction and the theme of the book - reference data is static and other types of data are not. The author covers basic database design concepts, types of reference data and their use, and managing reference data. As the book progresses it is apparent that there is a lot more to consider about reference data than including look-up tables in a database. This is amply shown in the chapter on the reference data life cycle where he discusses changing codes and descriptions. Other issues that the data architect needs to take into consideration, thoroughly covered in this book, are mapping reference data, and implementing reference data in an existing database. Too often look-up tables are added to the schema with no thought to how it is going to be integrated and maintained. The author gives some sage advice on this topic. I particularly liked the discussion on what I call "reference data from hell" - dates, times & time zones, currency conversions and the such. Also germane because I recently did a consulting assignment in the Middle East is the treatment of foreign languages and translations. I was most gratified, however, to see a chapter that addressed testing reference data and the associated problems with production vs. test data. From personal experience I can attest that this is often overlooked and is a real problem if your data architecture uses a lot of reference data. My main experience is wireless telecom provider billing systems which use a *lot* of reference data. Mr. Chisholm's advice on testing is on the mark and should be heeded. This book is valuable to any data architect or system designer, however, its real value is to those who are working with e-commerce systems and telecommunications billing systems, because both domains heavily use reference data and need the mature approach set forth in this book. Comment | | (Report this)