Wednesday, November 29, 2006

December 4, 2006


In the past I have discussed the need to manage data (as well as all information resources) as a valuable resource; something to be shared and reused in order to eliminate redundancy and promote system integration. Now, our attention turns to how data should be defined. Well defined data elements are needed in order to properly design the logical data base as well as developing a suitable physical implementation.

First, let's understand how data is used; there are three purposes:

  • Indicative Data - to identify the important objects needed to run a business, be it something as tangible as a customer, employee, product, part, etc. or as intangible as an event, such as a shipment, a billing, or transaction.

  • Descriptive Data - alphanumeric values that are not strong enough to identify an object, but convey important business facts about an object, such as names, addresses, text, codes, etc.

  • Quantitative Data - numeric values that are either calculated or are calculable. Measurements and computations are typical examples: "Net-Pay," "Quantity Ordered," "Elapsed Time," "Percent of Gross," etc.

Basically, there are two types of data elements: Primary and Generated

PRIMARY data refers to data in its virgin state; as introduced to the system from an external source (such as a person or department). "Source" defines who is responsible for entering the data to a system, and who has ultimate authority for the definition of the data element its meaning).

GENERATED data refers to data that relies on other data elements in order to produce the necessary result. This type of data can involve elaborate calculations and algorithms (e.g., DD-1 + DD-2 = DD-3). "Net Pay," "Balance Amount" and "Percent Complete" are some examples of calculated data.


Most data elements easily fall into the two categories of Primary and Generated, but there is a seeming anomaly that often confuses people, namely "Group" Data Elements, such as "Credit Card Number," "Telephone Number," "Check Number," etc. Many companies treat it as a Primary value when, in reality, it is often a Generated value; let me explain.

Group data is actually a concatenation of multiple data elements. For example, "Credit Card Number" typically consists of "Financial Institution ID," "Bank Region Number," "Bank Branch Office ID," and "Account Number." The "Customer Number" on a power bill may represent such things as: "Primary Power Station," "Sub-Station," and "Account." To a communications company, a "Telephone Number" has considerable meaning and represents "Area Code," "Exchange," and "Account." There are many other examples of "group" data: such as product identification codes, bank codes, insurance policy numbers, etc.

It is a common misconception that group data elements should be used for basic groupings (keys) in logical records; THEY SHOULD NOT! Group data is used as a convenient means to describe dependencies between primary data elements. As such, a group data element provides tremendous insight into objects and views. For example, consider the objects and views associated with a "Telephone Number": "Area Code" + "Exchange" + "Account Holder" Consider the dependencies between the three views. Each has an impact on the others. Should the first view be deleted, the second and third views will also be deleted. From this perspective, the basic grouping defines dependencies and eliminates the problem of multiple occurrences.

Data elements such as "Telephone Number" and "Credit Card Number" should only be defined as group items if they truly represent a concatenation of indicative data elements representing objects. For example, "Telephone Number" is a valid group item to identify a "Communications Area" and its views for a telephone company. But if "Communication Area" is not a pertinent object to your business, there is little point in defining it as a group item. Instead, it is a simple primary value.

Another hint as to whether a data element is primary or generated, is whether the company assigns the values to it, if they do not, then it is probably a primary value.


So why do companies have group data elements? Because it is a convenient means to quickly identify the objects and views important to the business. For example, it allows companies to "roll up" data; e.g, the number of accounts within a specific area. Further, a group data element may not be suitable for logical data base design, but has been found to be a useful means in the design of the physical file design (expedites accessing data).

How many Group data elements does a company truly use? Not as many as you might think. For example, Credit Card Numbers, Bank Codes, and Telephone Numbers are primary values in my business. However, a "Customer Number" is a group item consisting of a "Contract" and "Location." It all depends on whether these are important objects your company manages, hence, "Indicative Data" is devised and assigned to uniquely identity it.

To the average programmer, there is little concern for how data is defined other than to assign a suitable program label. However, data definition is a very important consideration to Systems Engineers and Data Engineers who are charged with building major integrated systems. Think about it.

For more information on Data Definition, see:

"PRIDE"-Data Base Engineering Methodology (DBEM)

OUR BRYCE'S LAW OF THE WEEK therefore is... "Group Data tells us a lot about what objects are important to an enterprise."


Friends, the "PRIDE" Methodologies for Information Resource Management (IRM) is a common sense solution for Enterprise Engineering, Systems Engineering, Data Base Engineering, and Project Management. The methodologies include defined work breakdown structures, deliverables, and review points that promote quality and the production of industrial-strength information systems. Building information resources is a science, not an art form. Our methodologies clearly explain the concepts that govern them, which remarkably, is derived from engineering/manufacturing practices. Now you can get these acclaimed methodologies for free at our corporate web site at:


A couple of months ago, my Windows XP computer was attacked by a virus. I believe I have good anti-virus controls in place, but nevertheless something got through causing me considerable headaches for the day. I finally was able to isolate and rid myself of it, but I found the experience very annoying. I know Microsoft and my anti-virus vendors take steps to issue updates to protect my computer, but I'm puzzled as to why Windows is so susceptible to viruses; it probably has something to do with the basic design of the operating system.

I read somewhere that Microsoft's new version of Windows, entitled Vista, is suppose to be virus proof. I'll believe it when I see it. There seems to be an unwritten challenge by the hackers out there as to who can first hack and disrupt each major release of Windows. They've been pretty successful so far and I don't expect Vista to be any different.

In the past, you've heard me talk about IBM's OS/2 operating system, which was a very stable and reliable product that was difficult to hack. I wonder why IBM was able to design effective security and Microsoft hasn't so far? Maybe they're simply being kind to companies like MacAfee and Norton who make a good buck on the anti-virus industry. Or maybe they simply don't know how to design a hack-proof operating system. Maybe both.

Such is my Pet Peeve of the Week.


Folks, be sure to check out our eBook entitled, "The Bryce is Right! Empowering Managers in today's Corporate Culture." This is a frank and candid description of the state of the art in management and includes essays on the problems in management today, along with some pragmatic advice on how to deal with them. Basically, this is a condensed course in management. As such, it is suited for managers, either those aspiring to become a manager or for those who need a refresher course. It will also be of interest to young people entering the work force, and is excellent for college curriculums.

Charles Cole of Lyndhurst, OH, said it is a "Very interesting book. Good work! It reminds me of some of the early works I read by W. Edwards Deming. Too bad the American corporate gurus of his day didn't pay him heed."

And Wolf Hager of Fort Myers, FL, says it is "A very impressive publication which requires careful reading and reminds me somewhat of Peter Drucker."

The price is just $20 plus tax. For more information on our book or to order on-line, see:

We have also produced a new one-day training program of the same name. For more information on both the eBook and course, please visit our web site at:

While there, look for our MS PowerPoint presentation describing both the book and the training program.


I received an e-mail from a Bernie DeMarco in Chicago who wrote me regarding last week's essay, "What exactly are we engineering anyway?"

Bernie writes:

"You make some valid points as to the characteristics of an engineer, but it seems we are stuck with the title of Software Engineer, at least in my business."

Thanks Bernie for your note,

As I mentioned in the essay, titles such as "Software Engineer" are a misnomer in most companies. I know we desire to have a fancy title to express our importance, but I find a lot of Software Engineers haven't the faintest idea what engineering is all about (which is why I wrote the article). The title "Programmer" seems too passe for a lot of people. Okay, how about "Software Specialist" instead? Kind of sounds like a crime-scene detective doesn't it? Nonetheless, it makes no pretense that it is an engineering position, nor does it imply certification. Frankly, I have no problem with the title "Programmer" and do not think any less of a person who has the title. In fact, I prefer it over the title of "Software Engineer" which I consider more suspiciously.

Again, Thanks for your e-mail. Keep those cards and letters coming.

MBA is an international management consulting firm specializing in Information Resource Management. We offer training, consulting, and writing services in the areas of Enterprise Engineering, Systems Engineering, Data Base Engineering, Project Management, Methodologies and Repositories. For information, call us at 727/786-4567. For a complete listing of my essays, see the "PRIDE" Special Subject Bulletins section of our corporate web site.

Our corporate web page is at:

Management Visions is a presentation of M. Bryce & Associates, a division of M&JB Investment Company of Palm Harbor, Florida, USA. The program is produced on a weekly basis and updated on Sundays. It is available in versions for RealPlayer, Microsoft Media Player, and MP3 suitable for Podcasting. See our web site for details. You'll find our broadcast listed in several Podcast and Internet Search engines, as well as Apples' iTunes.

If you have any questions or would like to be placed on our e-mailing list to receive notification of future broadcasts, please e-mail it to

For a copy of past broadcasts, please contact me directly.

We accept MP3 files with your voice for possible inclusion in the broadcast.

There is no charge for adding a link to "Management Visions" on your web page, for details and HTML code, see the "Management Visions" web site.

Management Visions accepts advertising. For rates, please contact yours truly directly.

Copyright © 2006 by M&JB Investment Company of Palm Harbor, Florida, USA. All rights reserved. "PRIDE" is the registered trademark of M&JB Investment Company.

This is Tim Bryce reporting.

Since 1971: "Software for the finest computer - the Mind."



Post a Comment

Subscribe to Post Comments [Atom]

<< Home