Re: domain questionnaire

> Yes, well, that seems like a good idea, and there have been periods in
> which I was all for such things. However, early on, I noted that some
> early AI work based on such was later characterized even by its
> creators, as quickly becoming so complex that it could not be read,
> even by its creators. These days, I approach such models with heavy
> skepticism.

I can't comment much on AI, as I know very little about it. However, we're designing vendor-restricted relational databases here, not neural networks, so.... <g>

> >It is a good trick. Essentially, ORM's use of elementary facts maps out
 the
> >FD's, and thus algorithms can be applied to make it "optimally
 normalized".
>
> Groan.
>
> Y'see, my problem is, I don't really believe in "facts". One can

I'm not sure I follow you. A fact is merely an assertion that an object has some property or that one or more objects participate in a relationship. If the assertion is true, then the fact exists.

I'm a card-carrying skeptic, so I can't help but poke a bit of fun at something like, "I don't believe in things that exist". <I'm kidding around here...>

> normalize a database by turning a crank, true. But there are many
> perspectives in the real world, each of which might require a

A collection of facts that one is interested in -- the problem domain, if you will -- is known as the Universe of Discourse (UoD). If you can define a UoD, then information you need to model is finite. If a fact is suddenly no longer true, or if a brand new one is added, the UoD has changed, and thus your model must change as well.

It is true that the information conveyed by the facts can be represented by different sets of facts .... so then the schema changes, but the information represented by the facts should not (more below).

> different data model, each of which might represent a given real-world
> object in different terms, with different "facts". Language like

I think you are getting at transformations between fact schemas, and yes, I agree. That is where the "art" comes in to play. There is more than one way to represent a finite set of facts. However, the information conveyed by those sets of facts must be equivalent (or else the transformation is not valid).

For example, you could have two (unary, or single-object and single-role) facts like: Person(SSN) is female and Person(SSN) is male. Adding an exclusive constraint across those roles makes it impossible for the same person to play both roles (e.g. no person is male and female). (Ignoring the discussion of whether or not a person must be one in the real world versus in the application domain, both of which can be handled).

An equivalent fact schema can be produced with just one fact, Person(SSN) is of Sex(Code), where the Sex Code is limited to exactly two possible values, one for each sex. (Still ignoring whether or not a Person must be of a Sex Code)

(See my previous post for descriptions of my fact "notation" above).

The resulting ORM (conceptual) schema, (logical) ER schema, and database (physical) schema changes between these two collections of facts, but the information represented by them does not.

So, sure, transformations happen, and there isn't a good way to automate that. That's the "art" -- that's why I get paid. <g> There are guidelines though, at least when it comes to designing business systems. Thus, suggestions could be automated, but an information systems designer would still need to be involved.

> "optimally normalized" gives me the willies. I think that the
> boundary between world and application is an entirely different
> exercise than that kind of phrasing suggests.

Sure, and those either represent new UoD's are alternate depictions of the same UoD.

At any rate, "optimally normalized" is Terry Halpin's term, not mine. Terry uses very precise language, so I suspect he says that for a very precise reason, knowing much more about normalization theory than I do.

From a pragmatic standpoint, I have yet to see an ORM schema not produce a "fully normalized" (up to 5NF, and probably some of the latter forms as well... again, I don't know them all) schema. I deal with business system models and meta-models though, so I guess your mileage may vary.

HTH,
Scot.

Partner, InConcept, Inc.

     http://www.inconcept.com

Editor, The Journal of Conceptual Modeling

     http://www.inconcept.com/JCM Received on Sun Feb 25 2001 - 00:40:33 CET