Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!usc!elroy.jpl.nasa.gov!ncar!gatech!rutgers!bellcore!towernet!taichi!haim
From: haim@taichi.uucp (24122-Haim Kilov(3786)m000)
Newsgroups: comp.databases
Subject: Re: ER versus dependency normalization methods.
Message-ID: <1990Nov30.220248.12042@towernet.cc.bellcore.com>
Date: 30 Nov 90 22:02:48 GMT
References: <33445@netnews.upenn.edu> <2095@ccadfa.adfa.oz.au> <1990Nov29.032532.23631@informix.com> <33684@netnews.upenn.edu> <2105@ccadfa.adfa.oz.au>
Sender: @towernet.cc.bellcore.com
Reply-To: haim@taichi.UUCP (24122-Haim Kilov)
Organization: Bellcore, Livingston, NJ
Lines: 15


The most important thing is to explain to the customer the concepts you are
going to use. Usually you (the "modeler") and the customer use different
concepts, so that in order to be able to understand each other a common
(semantic) language is to be created and explained. ER diagrams are usually
not sufficient: they _look_ like something reasonable, but vaguely defined
concepts lead to different, incomplete, or incorrect interpretations of the
picture. A precise definition (yes, and a formal one) of each concept is
needed, otherwise your customers will not distinguish (e.g.) between a
component and a subtype, etc. Of course, the concept of object type      
definition (using predefined operations and assertions) comes to mind.
We use such an approach, and I have some papers on the approach published.

-Haim Kilov
haim@bcr.cc.bellcore.com