Re: Syntacs, Semantics, and the Problem Domain

David Cressey wrote:
> This topic is a spin off from another topic, where Marshall Spight brought
> syntax and semantics into the conversation.
>
> My term "the problem domain" comes from a phrase that crops up over and
> over in "Object Oriented Analysis (Coad&Yourden, 1992). The complete phrase
> is "the problem domain and the system's responsibilities". That phrase
> captures in a few words, a disctinction that many of us, myself included,
> keep dancing around all the time.
>
> The person who understands the problem domain, sometimes, called the
> "subject matter expert" is the most underrated stakeholder in the majority
> of large scale database application projects. Especially when you consider
> the projects that go awry because the subject was not well enough
> understood when version one was frozen.
>
> In any event, I finally got my answer as to whether a pizza has a set of
> toppings or a list. More importantly, I got an answer about whether we
> should look to the problem domain or the system's responsibilities to find
> the answer: we should look to the problem domain. In other words if you
> really want to know, ask somebody who runs a pizza parlor. If that person
> is a franchisee, he may have to accept the franchisor's answer to the
> question, or lose his franchise. But that's where the answer lies.
>
> Now let me turn to the question of syntax and semantics: If I design schema
> of tables, the syntax of tables is going to make it look like the set of
> toppings is a set, not a list. If I design a pick file to hold the same
> data, it's going to look like the set of toppings is a list, just because
> the convenience of using the multivalue feature is, in this case, going to
> overwhelm any other design considerations.

Agreed.

> That makes it seem as though the question is a syntactic one, and platform
> dependent to boot. But it isn't. It's really semantics.

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.

> 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. 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 road leads to hell. "What the data really means" is
> really about both syntax and semantics. It's about the rpoblem domain, too,
> not just the system's responsibilities.

Agreed.

> Now this objection is by no means
> limited to Pick. Codd wrote about how the RDM itself didn't pin the
> semantics of a columns down tight enough to make all users of the database
> share a common understanding.

Agreed.

> Semantics seem to me to tread on the "problem domain" more so than systax
> does. But I wonder what others think.

Yes. It is in the translation from conceptual to implementation/logical data model that developers, rather than SME's, might add to or modify the semantics for one reason or another. For example, a set of pizza toppings, as identified in a conceptual model, might be implemented as a list where the order has no meaning.

This can sometimes change the SME's opinion so that they decide to make use of this ordering feature for some purpose, although they had never thought to do so prior to the implementation. So, you can see that as a poor implementation of the SME's stated requirements or a sometimes useful side-effect of the Pick data model.

Cheers! --dawn Received on Mon Mar 13 2006 - 01:26:12 CET