Re: teaching relational basics to people, questions

From: Clifford Heath <no.spam_at_please.net>
Date: Fri, 27 Nov 2009 15:13:19 +1100
Message-ID: <4b0f51e5$0$3253$afc38c87_at_news.optusnet.com.au>



vldm10 wrote:
> Regarding DK/NF and 6NF you can see my solution at www.dbdesign11.com.
> There I introduce “Simple Form” an effective solution which decomposes
> any relation to Binary Relations.

Your approach seems very similar in general to NIAM and other fact-oriented modeling approaches like ORM2. They are built on "Elementary Form", which in ORM2 can include fact types that are ternary and higher (though these are always trivial to binarise, the higher-order fact types are useful in modeling because they reflect natural verbalisations).

The main difference is that in fact orientation, the model is expected always to be *constructed* in elementary form. For efficiency of storage and access, uniqueness constraints allow automatic and invisible aggregation into non-elementary structures. This means you can model in elementary form, and get a correct and efficient schema which holds the same facts to use with your SQL DBMS. This is the implementation principle behind my "Constellation Query Language" as well.

You use the term "attribute" a lot. In fact orientation, there are no attributes, they are just fact types that encompass a functional dependency between objects. To drop the notion of "attribute" is a major win for a number of reasons, including that it isn't a clearly-defined concept in natural usage; vis the conflict between relational and object-oriented aggregation; and also the fact that "attribute migration" is a major driver of schema evolution, hence project scope inflation and failure.

In any case, before you go claiming your work as "novel", it'd be good if you did some reading on fact orientation and see whether others haven't been there before you, like, for example, more than twenty years ago ;-). This isn't a criticism actually; I haven't looked in sufficient depth at your work to decide whether you've done something new. But a lot of it does seem very familiar...

> Regarding time my solution is event oriented.

I like this view - it accords with my thoughts on the quantization of time where the general principle that "time is just G*d's way of keeping everything from happening at once" ;-).

Terry Halpin (creator of ORM2) has a recent article series on temporal modeling published at brcommunity.com, if you're interested.

Clifford Heath, Data Constellation, http://dataconstellation.com Agile Information Management and Design. Received on Thu Nov 26 2009 - 22:13:19 CST

Original text of this message