Re: Designing DB in accordance with the relational model

paul c wrote:
> Roy H snipped the first sentence in Clifford H's paragraph: "You
> shouldn't need NULLs in your conceptual model." For me
> the big problem with nulls is that I don't know how to express them in a
> predicate.

Exactly. A logical formula uses predicates over one or more "individuals", and has no meaning when one of the individuals may be absent.

> (Until the late 1990's, I never thought much about
> predicates only because I hadn't seen much written about them.

That's because you haven't followed fact-oriented modeling, which has been built on these ideas since its inception in the 1970s.  

> Instead,
> I had thought of relations as being abstractions of what I called
> uniform sentences. This 'thinking' was casual and a little fuzzy, not
> formal at all but it did at least prevent me from associating two 'very
> unlike' sentences with the same 'table'.)

FCO-IM and NIAM are also built on such sentences. They (and ORM2) show how to break down such sentences into elementary form, which is where only one fact is conveyed - nothing further can be taken away without losing information. When facts are expressed in elementary form, there is never a need for NULLs. The result has a direct mapping to formal logic (as Halpin's thesis proved) and thus (like RM) forms a formal basis for designing information systems.

Fact orientation has significant communication advantages when you're engaged in requirements capture, because of its natural-language foundations. The tools produce properly normalized relational models automatically.

Clifford Heath, http://dataconstellation.com Received on Sat Nov 13 2010 - 02:18:24 CET