Re: boolean datatype ... wtf?

From: Erwin <e.smout_at_myonline.be>
Date: Sat, 9 Oct 2010 05:59:58 -0700 (PDT)
Message-ID: <cdd89856-20a5-4932-89f7-ab24ace380b5_at_g18g2000yqk.googlegroups.com>


On 6 okt, 23:47, Hugo Kornelis <h..._at_perFact.REMOVETHIS.info.INVALID> wrote:
> Yes, I get that. This is a problem you always get when you combine
> several atomic fact types (falling back to the NIAM terminology) in a
> single table. NIAM and ORM avoid this problem by working with elementary
> fact types. If there is no information about the gender of a customer,
> there is no fact for that customer in the gender fact type.
>
> The FTD notation that prof Nijssen (one of the founders of NIAM)
> developed later removes the requirement to work on elementary fact
> types, and then solves the predicate problem by supplying multiple
> predicates for each FTD (which maps to a table in the relational model).
> So an FTD with one optional role (column) would have two predicates, one
> that includes this role and one that does not.
>
> And in relational database, the answer is to create seperate tables for
> optional attributes, or even to limit tables to at most one non-key
> column (which maps right back to the elementary fact types used in ORM
> and NIAM).
>

Relating to this, Darwen wrote a paper/draft investigating what he calls "multirelations" (essentially: a "supra-relation" encompassing multiple relations, where the heading of one of those relationsencompassed can be a proper subset of the declared heading of the multirelation - iow: a construct that allows a tuple with heading {A:type} to appear in a multirelation that has heading {A:type B:...}).

The draft may still be present on www.thethirdmanifesto.com, the most recent version of the text appears as chpt 24 in "Database Explorations".

You might want to read that too. Received on Sat Oct 09 2010 - 14:59:58 CEST

Original text of this message