Syntacs, Semantics, and the Problem Domain

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.

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. 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 think so. I remain unconvinced. And unless there is a FORMAL vehicle for speading understanding about :what the data really means" among all stakeholders, 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. 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.

Semantics seem to me to tread on the "problem domain" more so than systax does. But I wonder what others think. Received on Sun Mar 12 2006 - 21:37:19 CET