Re: some information about anchor modeling

Op dinsdag 24 juli 2012 03:23:30 UTC+2 schreef vldm10 het volgende:
> > > b) My database solution introduces and enables the construction and
> > > maintenance of a
> > > “history of changes”. My work gives the first complete solution of
> > > the “history”
> > > problem.
> >
> > Are you familiar with the work by one Nikos Lorentzos ? I have a book in my >library that was published 2003, summarizing his approach.
> >
> > And since you claim that your solution is "complete", I reckon you > also know what to do about and how to deal with, say, cyclic point types ?
>
>
> If you refer to the book “Temporal Data & the Relational Model “ by C. j. Date, Hugh Darwen, Nikos Lorencos, then you are wrong, because this book is about temporal data rather then about history of data.

Chpater 15 of that book is entirely devoted to the particular subject of "history of the data itself". And if you think that there is a logical difference between "a statement about the modeled reality that was true for some period of time" and "a statement about the beliefs recorded in the database and the period during which they were recorded in said database", then you are wrong too, and pathetically wrong at that.

There is nothing to stop relational theory from still applying, even when the "modeled reality" is the very set of beliefs itself that were recorded in the database, and there is nothing that stops the presented concepts of temporal data management from applying to that case too.

There is a _practical_ difference (the issue of retroactive updates can, or should, never arise when it comes to "the history of the beliefs that were recorded in the database"), but that does not count as a _logical_ difference.

There may be differences in the algorithms that turn out to be the most optimal for dealing with either of both kinds of history, and there may be differences in the syntactic shorthands that are built into the language and offered to the user for dealing with either kind of history, but none of those count as logical differences either.

> > Wait a sec. Just because you allow only additions in your databases, implies that it is impossible to have redundancy in your databases ?
>
>
> I wrote “controls redundancy”. Shortly, by “controls redundancy” I mean the following:

OK. I'll rephrase.

So just because you have dropped, in a certain sense, UPDATE and DELETE from your DML language, this implies by and of itself that redundancy in the database has now come under control [whereas in a language that does have UPDATE and DELETE, redundancy and derivability must necessarily be beyond the DBA's control] ?

Redundancy (the full name for denoting the subject topic was "redundancy and derivability", IIRC) comes from what the external predicates are for each of the elements in your database design (in a TR system, those elements are relvars, I don't know how you call them in your system, I'll assume "entity" henceforth).

If the truth value for any instantiation of a predicate (that's a proposition), or for any portion thereof, is derivable by looking at _other_ predicates and propositions, then you [inevitably] have redundancy and/or derivability. In each such case, you [inevitably] have an update anomaly problem, because there are then two distinct possible ways for determining the truth value of said proposition [or portion thereof] , let's call this proposition p :

(a) By looking at the database element (relvar/entity) and inspecting whether the tuple (entity occurrence) corresponding to p appears or not (making the truth value of p true or false, respectively).

(b) By looking at the _other_ database elements, determining the truth value of whatever it is that allows us to derive p, and doing that derivation.

The two might yield different results, and if they do, then you have a contradiction at hand. The only way to avoid this is by imposing a constraint. Whether or not the DML has UPDATE and/or DELETE, has nothing to do with it.

> My solution does not update and delete data. So it does not have update and delete anomalies (usually caused by redundancy). The intention of this solution is to save all that is entered into the database. My solution uses the binary structures and only two events. Therefore, it is possible to set powerful constraints on the level of data entry. The possible events are: “create new data” and “close the existing data”.

The only thing you have done is renamed DELETE (to CLOSE, IIRC). Doing that does not eliminate update anomalies. At best, you only replace DELETE anomalies with CLOSE anomalies. Received on Tue Jul 24 2012 - 16:12:56 CEST