Desktop

Ask something
Discussion Locked

Data Normalization is killing us!

0 helpful
7 replies

by donq

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

There must be 350 Naming Conventions based on Hungarian Notation in one form or the other.....and database objects named by most of them do NOT support efficient Data Normalization requirements! None (other than Business Notation) require a Field object carry an elemental (or unique) name eliminating the dreaded ambiguous error. None (other than Business Notation) were created for non-computer skilled business executives or professionals so they understand where and what a named object represents.

When is the IT Industry as a whole going to wise-up and begin constructing normalized dayabase back-ends everyone can understand? Does anyone agree with me? Is a standard everyone can understand needed?

7 replies

by sparent

I'm not sure what data normalization has to do with your issue.

Data normalization refers to the process of placing data attributes in appropriate entity type so as to maximize data integrity.

What you're referring to is naming conventions. (Unless you're trying to normalize your names, too!)

I do agree that naming conventions should be
standardized. I've seen many different conventions, often more than one in a given project.

As far as providing something for business executives,I suggest a meta-data tool: you'll never get a convention that will be clear enough for an executive but concise enough for IT!

by donq

Your comments and observations are 100% "right on" and I agree wholehartedly. I am involved in the re-write of a book and construction of accompanying software that allows computer illiterate buusiness managers to define what they "need" (or Facts they base decisions on) using their own words and suppliments their "Needs" with coordinated IT values. Applying a new SIMPLE naming convention, defined "needs" can (invisibly to the user) be placed in a normalized data structure (thus the software we are working on). Think about it a little and you'll reolize the two are VERY closely related - and if Field Names were unique (users understood) MUCH could be accomplished. The original material and process was copy protected in 1998 and it's really cool - and quite simple???

by sparent

You don't have to sell me on the value of a good naming convention!

As a past data administrator, I've had many discussions on appropriate names for attributes. It seems that every place I go, they have words that mean different things to different users!

That is why we need to shield the users from the naming conventions we choose for database objects. Better to provide the users with a meta-data dictionary and thesaurus. Hopefully, you can integrate this into their adhoc reporting solutions.

From a DA point of view, I've always found two areas that were particularly sensitive to naming: cascaded foreign keys and administrative attributes.

Since many CASE tool can automatically cascade the foreign keys, you have to worry aboutthe children attribute names versus their parent's!

Administrative attributes are usually common to many entities (last updated on, last updated by, etc.). We, of course, have to worry about whether or not the names should be unique (for example,by using an entity-specific prefix) or not.

Another debate is whether or not an entity's attributes should all have a common prefix when implemented physically.

Finally, you want to balance information redundancy with developer-friendliness. For example, why should I call a foreign key constraint FK_child_parent_column when I can find all that information in the DBMS data dictionary? But it's a lot easier that figuring out which of the umphteen SYS000nnn constraints is the one the DBA is interested in.

Let me know what other issues you've had to tackle in regards to data/database naming conventions.

by generalist

Normalization is relatively easy. It has a nice and simple protocol that a good database developer does automatically after a bit of practice.

Naming, on the other hand, is wide open because there aren't standards that are universally useful anduniversally accepted. What works for the programmers in the IT department are sometimes incomprehensible to end users. At the same time, what works for the users may not be usable on the programming side.

And when you have multiple groups of end users having different names for the same things, or the same names for different things, the complexity of having a standard naming system increases.

This is where aliases and extremely well documented descriptions come into play. And if the documentation comes with a cross-reference grid, comparing similar items, so much the better.

by donq

Your comments and observations are 100% "right on" and I agree wholehartedly. I am involved in the re-write of a book and construction of accompanying software that allows computer illiterate buusiness managers to define what they "need" (or Facts they base decisions on) using their own words and suppliments their "Needs" with coordinated IT values. Applying a new SIMPLE naming convention, defined "needs" can (invisibly to the user) be placed in a normalized data structure (thus the software we are working on to emulate your "Protocol"). Think about it a little and you'll reolize the two are VERY closely related - and if Field Names were unique (users understood) MUCH could be accomplished. The original material and process was copy protected in 1998 and it's really cool - and quite simple???

by donq

I think your comments MOST interesting as I am approaching this problem from 180 degrees!

My manuscript is in Word (I use Office 2K Pro) and I would really appreciate it if you reviewed the first two chapters of a book named "Business Notation".The software design starts in Chapter 3 so I keep that a little closer to the vest.

My approach is to involve management, or let them name the warehouse "objects". It's quite different and very user friendly!!!

May I e-mail you the first 35 pages (of 1000+ total). If so - where?

by sparent

Yes, I would be interested!!

It sounds like your Business Notation could be a welcome relief!

srparent@canada.com

This discussion is closed to new replies.