Re: Just one more anecdote

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.

(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! :-)

(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.

>>>And finally of course is the general rule that one should never design
>>>tables on object-oriented principles, anymore than one designs women's
>>>clothing on male models.
>>
>> Despite it's name, I wouldn't qualify ORM as being object-oriented.
>
>As you've described it it sounds more like the UML class diagrams. In fact,
>it is getting dangerously close to mere table design :)

Guess I didn't describe it too well, than.

The method that I have been teaching, and that I still use whenever I can, is a variant of ORM, known as NIAM. It's solely about gathering the user requirements into a data model, with all constraints. And it uses concrete examples (presented to the user in a form that's familiar for the user) as a foundation for ALL decisions.

>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.
• 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?)
• I am used to it :)

(snip)
>Good luck with those students :)

Thanks. Unfortunately, the call for that type of education has plummeted some years ago (at least it has here in the Netherlands), so I had to find other things to do. I definitely wouldn't mind having a class to teach every now and then, but I don't think it will happen soon.

Best, Hugo

-- 

(Remove _NO_ and _SPAM_ to get my e-mail address)