Re: Just one more anecdote

From: Kenneth Downs <knode.wants.this_at_see.sigblock>
Date: Sat, 06 Aug 2005 09:30:02 -0400
Message-Id: <8hqes2-8g8.ln1@pluto.downsfam.net>

Hugo Kornelis wrote:

> On Thu, 04 Aug 2005 18:24:42 -0400, Kenneth Downs wrote:
>
> (snip)

>>So if you mean that the final built database will express all constraints
>>from the ORM, we probably are in agreement on the goal here and can drop
>>this line.

>
> Hi Kenneth,
>
> Yes, that's what I mean. I am a firm believer that all business rules
> should be enforced in the database.

OK.

>
>
> (snip)

>>> I'm not sure if I interpret you correctly. If you propose to add some
>>> symbols, notes, or whatever to the tables you've drawn to show the
>>> constraints that are not available as standard constraints in SQL, then
>>> this would indeed allow the entire application to be specified in terms
>>> of tables (plus extra symbols and notes).
>>
>>Actually I mean calculated values or automated cascades into other tables.

>
> ROFL!!
>
> Sorry for laughing. Nothing personal. You see - I was thinking about
> those as well when I wrote my message, but I didn't dare to include
> them, for fear of the flak I'd get from the normalization police. I am
> so glad that YOU mentioned them first! :-)

LOL! Agree completely. I will offer my personal experience that I have never regretted bringing up something in this particular forum that might be controversial or bring down some orthodoxy police of one stripe or another.

First off, this is one of the most civil forums on usenet, so even those who irrevocably disagree with you will generally refrain from insult and nastiness.

Of course the big advantage to bringing up the tough arguments is your position is strengthened by disagreement - some will find weak spots you can shore up and others will find hidden strengths.

As for normalization, I've debated it with several kind souls here and am now very confident in my position on normalization and automation, not because everyone agrees with it, but because so many were patient enough to disagree.

>
>
> (snip)

>>Also this is why I say automation allows me to specify the entire
>>application in terms of what goes into the tables, and as i find myself
>>saying quite a bit lately, if I can do that, why do anything else?

>
> Mainly a matter of taste, I guess.
>
> In my experience, the best way to get reliable information about the
> business rules is to use concrete examples. Your approach allows that,
> since it's easy to jot some rows of sample data in the table on your
> whiteboard, chalkboard, or slip of paper. I prefer to present the
> concrete examples to the user in the form they are most familiar with:
> the form that they use for the same data in their regular work. So for
> an insurance company, I'd present the sample data in the form of a
> policy or a claim form. For a bank, I'd use a bank statement. Though the
> user might not have trouble interpreting a table, I believe that he'll
> have even less trouble interpreting the documents he works with on a
> daily basis.
>

There is probably an entire sub-thread just on this topic, people who think in terms of forms.

I once had a customer who thought entirely in terms of the paper forms he handled, one particular form more than most. This was the form that he used to bill, so it was crucial to him. I noticed he conducted all conversation in terms of the form. This was a government form, of course.

Once I realized that I stopped talking tables and spoke to him in terms of the form. Nevertheless, I was still translating everything he said into table design.

Is this similar to the examples you are giving?

<snip>

>

>>But seriously, when the class diagrams or the ORM pictures can completely
>>express the situation in terms of columns and tables, one wonders why we
>>don't just specify the columns and tables.

>
> I can't tell you why "we" don't, but I can say why "I" don't. The
> reasons are (in no particular order):
>
> - The NIAM methods are the best methods I've seen so far for extracting
> user requirements and business constraints (for the data model only;
> processes are unfortunately not covered by NIAM). The same methods can
> be used with other diagramming techniques, of course - but the NIAM
> diagram has the closest match to the NIAM mehods.

OK.

How do you handle processes? How do you related processes and automation, if at all?

> - The NIAM diagram holds more information than a (standard) relational
> model, a (standard) ERD diagram, a (standard) UML class diagram or any
> other diagramming technique that I know of. (Note: it is of course
> possible to extend each of those diagramming techniques to include more
> information, but why extend a technique to hold more information when
> there is already a technique that has it included?)

Reasonable.

> - I am used to it :)

Authoritative!

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec)ure(Dat)a(.com)

Received on Sat Aug 06 2005 - 08:30:02 CDT