Re: a union is always a join!

<vldm10_at_yahoo.com> wrote in message
news:0e775a1d-611c-44fa-88b9-f81a84e66ec0_at_f19g2000yqh.googlegroups.com...
> 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?

Yes.

> This kind of db theory is good only for simple databases i.e. for
> databases which don’t maintain changes.

I don't think you're right.

> Therefore these kinds of
> theories are naive, there are not of general character.

I don't agree: A historical database is a specialized kind of relational database; therefore the relational database is the more general.

> 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.

I think that you're belief is unfounded. Faith is extremely important, since it leads to repentence and salvation, but it really doesn't pertain to database theory.

> 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?

Yes.

> 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”.

Wars have begun as a result of bad data: consider everything that led up to the invasion of Iraq.

> 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?

The database can only guarantee that what is entered is consistent with the constraints defined on the schema. No system can determine whether what is consistent is also correct.

Did you know that Saddam kept even most of his generals in the dark about whether he had stockpiles of WMD and in fact encouraged the belief that he did? The only thing that kept Iran at bay was the threat that WMD would be used against them.

> 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.

From what I can discern (and I suggest that you in some writing classes, or if you already had and you passed, then you should sue to get your money back, because what you "submitted" is incoherent to the point of being unintelligible), your db model (if it can even be called a model) uses two data entry operations: update and insert.

>
> 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 Fri Apr 03 2009 - 01:28:53 CEST