Re: some information about anchor modeling
Date: Mon, 21 Jan 2013 03:43:07 -0800 (PST)
Message-ID: <35b47935-6d82-4a9a-bc45-ca0bd941206f_at_googlegroups.com>
> Let R be Relvar, which has the surrogate key K and three properties
>
> A,B,C,
>
> Let us suppose that it is somehow possible to decompose the
>
> above relvar into binary relvars using the “RM/T discipline”. Let the
>
> following example be one possible situation:
>
>
>
>
>
> K K A K B K C
>
> --------------------------------
>
> k1 k1 a1 k1 b1 k1 c3
>
> k2
>
> k3 k3 c3
>
> k4 k4 c3
>
> k5
>
> k6
This table shows that the surrogate key is a very bad solution. In this table, I added the column K. Column K represents the so-called E-relation, which was introduced by Codd as a unary relation. Authors of Anchor Modeling also introduced this unary relation, they provide naval name "anchor"!?
The table shows the six surrogates keys, but none of them work. Note that the relation that has a surrogate key "k1" is also poorly designed. Malicious programmer can delete one of the attributes a1, b1, c1. In this case, the project leader does not know what to do, because there is no "history".
On the other hand, if someone use my solution in this table, then ALL of these six relations are useful. For instance identifier can be a VIN number. For example, let k2 from this table, is a VIN. In this case, a police officer can check, using the radio, who were the owners of a car.
Now, we see that the “RM / T” needs to know all attributes of the entity, so that it is possible a binary decomposition of the entity. This is due to the use of surrogates. Note that this fact, in a sense, degrades the idea of binary (atomic) structures. Because of this, someone has to collect all the information about the entity to preserve and record this information somewhere, and then enter them into the binary structures (into a database).
The authors of "Anchor Modeling" claim that their model solves problems with nulls. They wrote the following: “Absence of null values – There are no null values in an anchor database. This eliminates the need to interpret null values [27] as well as waste of storage space.” See Anchor Modeling – Agile Information Modeling in Evolving Data Environments , Section 9.2 (The article published in Data & Knowledge Engineering in 2010) Moreover, these authors claim the following: “Anchor Modeling is a technique that has been proven to work in practice for managing data warehouses.” See section 11 of this paper.
Now we have the following situation:
1. I have shown that surrogates can not manage "nulls." 2. Authors of anchor modeling claim that their model manages "nulls", even better than existing solutions.Since Anchor modeling using surrogates, then it seems to me that the statements of these authors are not accurate.
My results related to the design of databases that manage the history of events, the first time I put on this user group in September 2005. The name of the thread was "Database Design, Keys and some other things." In this thread, Joe Celko posted a very good comment regarding surrogates:
David Cressey: 9/27/05>> A VIN, a bank account number, and an SSN are all surrogate keys. <<
Celko:
No; read Codd's definiiton of a surrogate key. These are all
industry-standard, externally verifiable keys with known validation
rules. Honking BIG difference!! The big part of this is that they
are EXTERNAL to the database.
When you use (longitude, latitude) for a location, is it also a
surrogate? If so, wouldn't every key be a surrogate? I verify a
location with a GPS; I verify a VIN, a bank account number, and an SSN
by computers or phone calls. Just a different device.
Vladimir Odrljin Received on Mon Jan 21 2013 - 12:43:07 CET