Re: Syntacs, Semantics, and the Problem Domain

David Cressey wrote:
> "dawn" <dawnwolthuis_at_gmail.com> wrote in message
> news:1142209572.359169.190150_at_u72g2000cwu.googlegroups.com...
> >
> > David Cressey wrote:
>
> >
> > Agreed. This has to do with the difference between a conceptual model
> > of the data and an implementation (typically called logical) data
> > model. The conceptual model should indicate whether something is a
> > list or not. The logical/implementation model might be different
> > depending on the target dbms, however.
> >
>
> The difference between "logical" and "physical" as often used in c.d.t. is
> not the same as the distinction as used in the texts that originally taught
> me relational databases. It is also not the same as the distinction between
> such things as "logical page numbers" and "physical page numbers" that I
> had dealt with in years prior to being exposed to relational databases.
>
> Many people in c.d.t. use the term "logical" where I would have used the
> term "conceptual".
>
> In this particular circumstance, I think your usage and mine are rather
> similar.
>
>
> > > Now, most of the
> > > problems I have with the comments of pickies generally in c.d.t. is
> that,
> > > nearly always, they come down to the idea that a team consisting of two
> or
> > > three pickies are so very productive that they can provide all the
> technical
> > > services to support and run a large scale database.
> >
> > I don't know if I'm in that group, nor do I recall when I've talked
> > about how many people support large Pick systems.
>
> You know what you've written better than I know what you've written. More
> importantly, you know whether you really meant it, or whether you were just
> pushing somebody's buttons.

I always mean what I say (at the time -- if I'm wrong, I'll correct it), but sometimes I'm ALSO pushing buttons. However, I try to play it perfectly straight these days with you, brother David.

> I do recall someone other than you saying that the ratio of Pick programmers
> to SQL programmers, for the same result was something like ten to one.

I wouldn't be surprised if this were true, but I doubt there is emperical data to back that up, likely only anecdotal evidence.

> When
> the same person admitted later to not knowing anything about SQL, I
> dismissed that comment as the voice of ignorance and arrogance.

Someone could know about data centers and HR budgets without knowing every tool or language used, however. While the youngsters were taught SQL in college so they know a little even if they never used it, those over 45 or so might be well-versed in business data processing with no SQL experience. Just as I would not write someone off if they didn't know language XYZ, or the IMS database or Pick, I would not write someone off simply for not knowing the SQL language while possibly having an educated opinion on the relative difference in cost between shops using SQL and Pick.

> > I would claim
> > (without proof) that, in general, if you have a system with similar
> > features implemented in a SQL-DBMS and a Pick DBMS, you will need fewer
> > developers/dbas supporting the Pick system. I have surely seen shops
> > where there are more than two or three Pickies supporting the large
> > scale system, however.
> >
> > > I don't think so. I remain unconvinced. And unless there is a FORMAL
> > > vehicle for speading understanding about :what the data really means"
> among
> > > all stakeholders,
> >
> > I agree that the meaning of the data is of utmost importance. The
> > ability to have synonyms in Pick is both an advantage in this as well
> > as a way to junk up a system with too many words for the same thing.
> >
>
> The synonym problem and, worse yet, the homonym problem, is by not means
> pecusliar to Pick, or to RDM, or to any other particular system for the
> representation of data. It is inherent in the way people use symbols. The
> synonym problem and the homonym problem, together, make data analysis much
> more difficult.
>
> And it brings into sharper focus than ever the need for a FORMAL vehicle for
> spreading understanding about "what the data really means".

I have seen synonyms be very helpful for understanding the meaning of data, and also for obscuring it. For example, if from one view of the data, let's say a STUDENTS view, an attribute is called TUITION_PAID_AMT and from another view of the data, let's say ACCOUNTS_RECEIVABLE, an attribute is called RECEIVED_AMT, there could be better clarity for the users of those views than calling both TUITION_PAID_AMT, as well as more confusion on whether these are the same thing.

I agree that a vehicle for spreading and maintaining understanding is very important. I'm not opposed to your use of the term "formal" for it either, but hesitant to agree, not knowing what you intend with that. A system that is effective within one corproate culture might not be in another. People talk about formal system development methodologies too, with which I agree, but then find out they mean xyz written in triplicate and signed off on by all God's children before anything can move forward. In short, I agree, but wouldn't state it quite that way.

I'm on the road for a couple of weeks, so you get a break from me. And, David, if you haven't read past my first blog, it would be great if you happen to get a chance to read a few more of them. I take more time to write with a bit more clarity there ( www.tincat-group.com/mewsings ). Cheers! --dawn Received on Tue Mar 14 2006 - 03:07:43 CET