It’s Sunday night, and my column is due on my editor’s desk tomorrow
morning. Sometimes, I just can’t think profound or even clever thoughts,
and this is one of those times. So, I thought I would let you, the reader, take
an active part in this column. Over the years, I’ve talked about many
things that have generated strong opinions,interesting feedback, and even a
flame or two.This month, I thought I’d introduce a few contentious topics,
then discuss them with you on SQL Server Magazine’s Forums area.
I’m going to take a stand:We shouldn’t avoid contentious topics
in data modeling. In many cases, the very fact that a topic is contentious means
that it’s significant and that it might be of vital importance to the
accuracy, integrity, and efficiency of the data, the data model, and management
of the data itself. My goal isn’t to change anyone’s mind; rather,
my goal is enlightenment. My hope is that, by participating in or even observing
these forum discussions, you’ll understand and maybe even appreciate
another person’s point of view or be exposed to ideas that you hadn’t
considered before.
You’ve formulated your current viewpoint as a result of your job, the
organization’s structure, and your personal experiences. Your working
environment—be it your job,the organization’s structure, technical
standards, and your personal experiences in the trenches—affects your
perception and most likely your deeply held opinions. There’s nothing
like hands-on experience in a multitude of situations to show you what works
and what doesn’t.
So let’s review some of the more popular contentious topics in data
modeling. I’ve included six broad topics with specific areas of interest,
in hopes that you’ll go to the Database Design forum (http://sqlforums.windowsitpro.com/web/forum/categories.aspx?catid=69&entercat=y)
to share ideas, comments, questions, and helpful tips.
Class Words in Your Naming Conventions
Let’s start with an easy topic:naming conventions (aka naming standards
or class words). Has your organization or group defined naming conventions or
standards that you need to follow when creating a name for entities or tables,
attributes or columns, relationships, constraints, or other database objects?
Do you use naming conventions all the time? Does your organization enforce the
use of naming conventions, or class words, and if so, how?
Here’s an example: Suppose you create a table named Customer. In the
Customer table, there’s an attribute that represents each customer’s
first name.Would you call that attribute CustomerFirstName, CustFirstName, or
just FirstName? Why?
Do you use Hungarian notation, the naming convention popularized by Microsoft
Access? Recently, I worked on a project with an application development group
that had established and was using naming conventions for all aspects of the
project. One comment that caught my eyewas,“Hungarian notation is so
yesterday!”
Some folks think that class words are metadata. Metadata is more than just
data about data. Metadata is another dimension of data that gives meaning and
structure to data. Metadata also helps you identify, assess, and manage data.
By adding the name of a table as a prefix to an attribute, you can argue that
you’re associating the attribute with the table and strengthening the
attribute’s “identity.” In this respect, I think class
words can be viewed as meta-data. What do you think?
Surrogate Keys vs. Natural Keys
I think the discussion of surrogate versus natural primary keys can attract
even the most reluctant lurker to the forum to weigh in with an opinion. In
the SQL Server world, a surrogate key is often an integer column that has an
identity property: an autonumber function. A natural key is, well, a natural
key. You can read more about what constitutes a surrogate or a natural primary
key in the article “Surrogate Key vs. Natural Key” (February 2002,
InstantDoc ID 23449). No mudslinging now; I want only good,well-reasoned arguments
about this topic.There are pros and cons to each type of primary key, so go
ahead and make a comment.
Design for Compliance or Ignore It
Regulatory compliance refers to systems and procedures that organizations
should have in place to ensure that workers are aware of and comply with the
laws and regulations that govern your industry. Regulatory compliance is a must
for almost every industry—financial, manu- facturing, real estate, retail,
and health care—and it isn’t unique to the United States. For
example, the European Union (EU) has a long history of regulatory compliance,with
many regulations inher- ited from its component countries.
With the Sarbanes-Oxley (SOX) Act and Health Insurance Portability and Accountability
Act (HIPAA) requirements hanging over everyone’s head;with increasing
demands for financial accountability, traceability, and reliability; with antispam
legislation on the docket and more promised; and with the focus on privacy and
security, the demands for strong data integrity have never been higher. Does
your company require you to design applications that meet the compliance regulations,
or do you just ignore the regulations? If you’re working under a tight
deadline,do you neglect to add the additional audit controls dictated by these
compliance requirements? Or do you stand your ground and insist on additional
time and resources so that your model and implementation can pass the compliance
litmus test?
Prev. page
[1]
2
next page 
