Re: Designing DB in accordance with the relational model

From: paul c <anonymous_at_not-for-mail.invalid>
Date: Tue, 9 Nov 2010 16:02:11 +0000 (UTC)
Message-ID: <ibbra3$a69$1_at_tioat.net>


On 09/11/2010 7:03 AM, Kentauros wrote:
> Date's "Introduction to Database Systems" is an amazing book. However,
> it doesn't says very much on HOW one should translate a given universe
> of discourse into a database which can be treated as a sane
> representation if it. Maybe Date also wrote a book mostly concerned on
> this topic, but unfortunately I haven't heard of it.
>
> So, maybe someone could explain what do I do with the next situation?
> Here it is:
>
> There are entities with attributes (yes, very trivial). Maybe they're
> fiscal reports, or something.One day, however, the entities change:
> several attributes are thrown out, several new attributes are
> introduced, and for some attributes, their domain are expanded.
>
> Well, if I were using SQL DBMS, I would just add new columns for new
> attributes and spam them with NULLs for the older entities, and the
> columns for thrown-out attributes will have NULLs in them from now on.
> Domains? Ha, I was using a special table of "id# -- describing text",
> so I just add some new records in it.
>
> But what do I do if I have D DBMS, implemented strictly by The Third
> Manifesto? I just can't imagine. I can't use NULLs. Making tables
> "ENTITIES_1999-2010", "ENTITIES_2011-NOW" surely won't work. How do I
> extend domains, again? It's not subtyping, it's supertyping, but I
> dislike the idea I introduce new wider types, then rewrite the existed
> ones so they will be the subtypes of the newly introduced types.
>
> So, what should I do? And please, no "screw that moronic theory Date
> invented" replies. I won't.

(This thread has the kind of title that I think will keep it 'alive' for a quite a while.)

My first answer to the question, as far a relational theory goes, is a general one. Codd intended his table names to stand for predicates. If one desires to follow his and Date's theory, predicates can't be ignored. They don't prevent two tables or what Codd called 'R-tables' from standing for the same predicate, but when the attributes are different it's clear that the predicates must be different. So for me the question becomes "what are the application requirements for each of the predicates?" which might (or might not) lead to recognizing what is common, which in turn might lead to a third predicate for which the question needs to be repeated, or it might even lead to a recognition that as far as the application is concerned, they have nothing in common.

(Date has written at least an order of magnitude more words than Codd did and sometimes this makes it harder to appreciate the essence of what both of them intended. Then there is the essence of what the original two predicates 'mean'. Coming up with a clear answer to that for a given application often involves much soul-searching for designers. Personally I think that more often than some people expect, the answer is that there are in fact two distinct applications. Often there is a huge psychological resistance to this answer and pressure on developers to somehow make it not so. For me, a basic understanding of the algebra makes things clearer, a few people prefer the calculus. I mean 'clearer' in the sense of what the logical underpinnings of the model allow.) Received on Tue Nov 09 2010 - 17:02:11 CET

Original text of this message