Re: some information about anchor modeling

On Thursday, November 1, 2012 6:01:54 AM UTC+1, com..._at_hotmail.com wrote:
> On Wednesday, October 31, 2012 2:19:19 AM UTC-7, vldm10 wrote:
>
> > On page 211, Appendix A / Primary Keys Are Nice but Not Essential,
>
> > of his last book, "Database Design & Relational Theory – Normal Forms & All That Jazz” C.J. Date writes about “anchor relvars”
>
>
>
> He is just using it in its everyday metaphoric sense of a rooted base.

Here, C. Date tries to declare RM / T discipline, however RM / T is not discipline. RM / T did not provide a solution and has many very serious mistakes. This state of affairs reminds me on the use of other people's papers in order to prove that the RM / T is actually a "discipline". Speaking in the style of maritime terms, it seems to me that the "anchor relation" as a kind of a release ink.

On Jull 18, 2012 in this thread, I explained, with examples, that the surrogate key is a very bad solution. Note that these examples are given only for the entities. However, relationships with surrogates have much worse solutions. Note that there are more serious problems for the RM / T at the theoretical level.

> Google gives a Safari book preview of a few lines, below. (I have the book, this enough to give you an idea of his usage, introduced here.) See http://en.wikipedia.org/wiki/Relational_Model/Tasmania re kernel entities of RM/T.

Let me comment only few basic things from this web site. In the section "Summary of RM/T", the following basic concepts are defined:

(i) Definition
Surrogates. A surrogate is a unique value assigned to each entity.

my comment: The entity is the real world object and it is not possible to assign value to the real world object.

(ii) Definition
A nonentity is some thing that is not an entity…

my comment: Note that “entity” and “thing” are synonyms.

(iii) Definition
The RM/T addresses atomic semantics by…

my Comment: With the most carefully observing the RM / T, one could not find a single atom of the semantics, because in the RM/T, section 4, E. Codd wrote: "Database users may cause the system to generate or delete a surrogate, but they have no control over its value, nor is its value ever displayed to them.”

>
>
>
> philip
>
>
>
> A. Primary Keys Are Nice but Not Essential
>
> ONE PRIMARY KEY PER ENTITY TYPE?
>
> I turn now to the second of the two issues mentioned in the introduction to this appendix: viz., that entities of a given type are supposed to be identified in exactly the same way everywhere in the database. What this means, loosely speaking, is that there’ll typically be:
>
> A single “anchor” relvar for the pertinent entity type, having some particular primary key, together with
>
> Zero or more subsidiary relvars giving further information about entities of that type, each having a foreign key that refers back to the primary key of that anchor relvar.
>
> (Does this state of affairs remind you of the RM/T discipline discussed in Chapter 15?)
>
>
>
>
>
> he

Vladimir Odrljin Received on Sun Nov 04 2012 - 19:31:33 CET