Re: teaching relational basics to people, questions

On Nov 27, 5:13 am, Clifford Heath <no.s..._at_please.net> wrote:
> vldm10 wrote:
> > Regarding DK/NF and 6NF you can see my solution atwww.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.

No, my approach is very different from NIAM/ORM. My approach is a kind of ER, while NIAM/ORM isn’t. I have entities and relationships and a lot of semantic modeling.
I don’t have any of basic things from NIAM/ORM, such as object, roles and fact types.
ORM uses concepts and I also use concepts. In ORM the concept is not defined although it is basic thing. I defined the term concept with general definition and I also defined the following particular concepts: properties, entities, relationships and states. When we speak about basic facts, I must say that I haven’t noticed a definition of facts in ORM. So, for example how do you know that facts are types if you haven’t defined facts?
As you wrote, I use attributes a lot and this is also a big difference between my approach and ORM. I believe that more than 90% of the data in my DBs is related to attributes.
All of the above mentioned are fundamental differences between my approach and the one in NIAM/ORM.

> 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.

However, there is one thing I believe you haven’t noticed. It is about a sentence and its corresponding thought. No doubt a sentence denotes its truth-value. But sentence is not a possessor of truth-value. So a sentence is not a fact, rather a fact is related to the its corresponding thought.
This is the reason why I introduced two very different things: a fact about an entity and the corresponding factual sentence. I also determined the construction of a fact about an entity. It involves the construction of Binary Concept of an entity, the construction of attribute’s abstraction (see 3.3.3 in my paper), etc.
And in my opinion this is very different from ORM and from any other DB models and designs.

> 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.

Regarding “temporal” DBs, I gave a solution. You can see it on my web site. Note that the solution is more general than the field of “temporal” DBs. I put the main ideas on my web page in 2005 and have completely integrated them in this paper. I am fairly certain that my solution for the first time solves “temporal” and historical DBs and that is one of the things which is novel.

>
> Clifford Heath, Data Constellation,http://dataconstellation.com
> Agile Information Management and Design.

Vladimir Odrljin Received on Sun Nov 29 2009 - 18:03:34 CET