Designing DB in accordance with the relational model
Date: Tue, 9 Nov 2010 07:03:33 -0800 (PST)
Message-ID: <acae2d76-e8e2-493a-9f88-c9d5ff7624a2_at_x42g2000yqx.googlegroups.com>
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. Received on Tue Nov 09 2010 - 16:03:33 CET