Re: a union is always a join!

On Mar 28, 3:51 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:

> You're being short-sighted.  A relational database that states not just what
> has been the case since the last update, but what has ever been the case is
> called a historical database.  It is a simple matter to define a set of
> views on the historical database that represents just what has been the case
> since the last update: restrict each relation to just those tuples that have
> indefinite intervals, and then project away the interval attributes.
> Moreover, every delete, insert or update that target those views maps to an
> update, an update and an insert, or an insert against the historical base
> relations, given the point in time that the delete, insert or update occurs.
> So in effect, it can easily be argued that a database that is not historical
> is essentially just a view on one that is.

There are many questions related to insert, delete and update operations. I will mention some of them.

1.
A database theory, which uses delete and update operations – is it a good database theory?
This kind of db theory is good only for simple databases i.e. for databases which don’t maintain changes. Therefore these kinds of theories are naive, there are not of general character. Current software and db theories use these operations. However in my opinion it is not appropriate to allow maintenance of changes using deletes and updates. In fact I believe it is nonsense to maintain states and history using deletes and updates. 2.
Is there a database theory that can establish a good database design which will not allow “screwing up of history” and which uses insert, delete and update operations?
Let me mention just the following cases where “history” can be “screwed up”:
a) Wrong data. There is huge amount of wrong data in every complex database, entered by data entry persons. A company can start an action based on the wrong “history”.
b) One who intends to falsify “History” applying these three data entry operations.
(crime, hackers, bad organization and technology, competition etc). Is it possible to prevent these cases by applying an appropriate database design?
3.
Is there a database theory that can establish a good database design which will not allow “screwing up of history” but which uses others data entry operations?
For example, in my db model (you can see it at www.dbdesign11.com), I am using in fact only one data entry operation. I am not using deletes and updates.

The above questions are related only to data entry operations, and they are not the most important things related to complex databases.

Vladimir Odrljin Received on Tue Mar 31 2009 - 11:50:37 CEST