Re: What is analysis?

Quoth David Cressey:
> "Jon Heggland" <jon.heggland_at_idi.ntnu.no> wrote in message
> news:fj0fhm$ad9$1_at_orkan.itea.ntnu.no...

>> [...]

Yes, I was thinking about analysis and synthesis when I spoke my piece.

>> No. Nothing that covered analysis /thoroughly/, at least, and certainly
>> not /formally/. I've learned a few diagramming notations in my time, but
>> I've never had analysis presented as a science as opposed to an art or
>> craft.

I was half hoping that you might know of any science in the area, since you used the term "formal analysis" earlier, and seemed surprised that there is confusion about what analysis is. Oh well. :)

>> I have a database of currently 102 relvars with in total 590 attributes.
>> No formal analysis, whatever that means. I drew some pictures in the
>> beginning for communication, but once I had a prototype, it was simpler
>> to just show, tell and ask. People understand tables just fine. What do
>> you mean, "What happened after that?"

"Approximation" sounds strange to my ears in this context; I usually talk about "iterative development". Which goes almost without saying; I can hardly imagine building an information system any other way. The users have hardly any idea what they want until I show them something.

> How do you show people a table? Do you se a diagram? Do you show the table
> through the lens of the application you are building? Do you give them what
> MS Access calls a "datasheet view"?

I'm not familiar with Access. My tool of choice, Dataphor, creates GUIs from table (or rather view) definitions. There isn't any clear separation between the database and the application(s). So I show them the actual application, which shows actual database tables/views quite plainly. Sometimes I draw sample tables (with example data, not just headings) on a whiteboard or something. And sometimes I use an ER-like notation (Carlis and Maguire's LDS), but with a strict and simple correspondence to my relvars. The relvars come first; the diagrams are simplifying representations of them.

> Do your people understand foreign keys just fine? My experience, going
> back to the 1990s was that people who had not worked with databases did NOT
> understand foreign keys just fine. That includes people with 20 years COBOL
> programming experience and who were in other respects highly proficient.

I don't consider foreign keys all that special. It always annoys me when someone says that foreign keys signify relationships. They don't; they /constrain/ relationships. Relationships are given by attributes being defined over the same domain (although this makes far more sense if your DBMS has proper domain support). Anyway, I don't feel the need to talk much about foreign keys. I talk about identifiers (key constraints), and say that this column/attribute is the same as that.

> Managers also couldn't get "the big picture" from a datasheet view.
>
> My biggest success with diagrams did not come from the analysis of a
> proposed system. It came from reverse engineering an existing database back
> into ER form, and using that diagram to communicate with managers and
> programmers.

That fits with my experience, too. But "back into ER form"? Did it start out that way?

> [...] I will admit that MOST of
> the communication was in the form of questions and answers in plain English,
> rather than the diagram itself.

Ditto. Except, y'know, Norwegian. :)

> Where the diagram added value is that it kept the conversation moving
> forward, instead of going around in circles.

Yes. One must have some sort of artifact to point at and scribble on.

> Before I did this, the only person who understood the database was the DBA.
> After I did this, almost all the stakeholders understood it. This was not
> analysis.

No? I'd say it was, but an analysis of the database, not the business problem.

-- 
Jon