Re: some information about anchor modeling

Dana ponedjeljak, 11. veljače 2013. 08:41:14 UTC+1, korisnik Derek Asirvadem napisao je:

Hi Derek,

>
> 3.1. I do not accept that "[Codd] was unsuccessful at [decomposition of a relvar into binary relvars] and was not able to show how this is done. " I think it is clear in RM/T, and I do it all the time. There may be marginal cases where the technique does not apply or where further techniques are necessary in order to provide resolution, but that does not subtract from the technique given, and you are not one of those idiots who argue at the margins (straining at the gnat and swallowing the camel).
>

1.
In 2005, I solved the binary decomposition for the General databases. These are databases that can maintain "history". This decomposition is determined by the applying of the identifier of the state. The drawback of this decomposition is that it can be applied only in the RM, only for General databases.

2.
The binary decomposition of Simple databases, I published on this user group in May 2006th. Then I published "Simple Form". Simple form defines the following: a) It determines to which relations it can be applied b) It defines how the relations can be decomposed into binary relations. Now things have slightly agreed. But the major issue still unresolved. We need the binary decomposition at the level of the conceptual model.

3.
Conceptual model is always the beginning of the construction of the database. But here, in the conceptual model nothing was done, even there was no definition of the concept. Within the ERM, it was necessary to solve the decomposition of the Simple and the General databases. After that it was necessary to define a mapping from the ERM into RM. All solutions in the ERM should be done with the tools that belong to the ERM. So we have to work with the concepts.

The "Binary decomposition" at the level of ERM I published in 2008. This paper I had to write in a limited number of pages, because Croatian journal in which I submitted the paper, gives a very small number of pages. That's why this paper has become more difficult to read than usual. I showed this decomposition in Example 6, Section 4.2.3, "Database design and data model founded on concept and knowledge constructs”. In this example, implicitly I used my definition of the concept and the extension of the concept. See also my paper "Semantic databases and semantic machines", section 5 at http://www.dbdesign11.com Here you can find more on this very complex matter.

In Example 5 is shown working with binary files. I showed only this example that relates to the m-n relationships in the file data model, because this is the hardest part.

4.
In my model, knowledge was associated to the concept. A new definition of knowledge has been given. Knowledge is defined using atomic facts. The difference between the fact and factual sentence is introduced. So a fact is always tied to a subject, that is, the subject knows that fact. This implies the necessity that the subject should be "aware" of the fact. "Truth conditions" are defined, i.e. the relationship between meaning and truth is introduced.

5.
The mapping (also the corresponding inverse mapping) between ERM and RM is defined. Based on the above mentioned four items, it is obvious that these mappings are defined in the following way: a) The identifier of the entity defines the mapping for "Simple database"; b) The identifier of the state defines the mapping for “General databases".

6.
First, I define the knowledge, and then I have defined entities that are based on the knowledge. In my model, the construction of the entity does not use undefined terms such as the "metadata".

7.
My model allows you to work on all aspects related to the history of events. This is a special large area and therefore I will not explain it here. History is one of the greatest contributions that my solution adopted. This drastically changes the theory of database.

8.
In the item 8 I will discuss the thing that has been in the forefront in this thread. It is the story about the surrogates. The story has boosted the importance of the surrogates to a size with which, the real surrogates have nothing to do. I'll try here to show two things that are an important part of the "big picture" and that they represent some "general" conditions.

One thing is important here, it's my algorithm that is related to memory management. It is an algorithm that defines how to store an entity in the memory and how recall it from memory, and for which kinds of the objects it works. I wrote about this algorithm, in more details in my post from February 25, 2013, in this thread. If we talk in generalized terms, it can be said that this algorithm is about procedures for memory and remembrance (recollect).

Another thing is about some “general” conditions:

(a)
The main part of solving “temporal”, “historical” and other complex databases consists of two sub-steps: 1. Constructing an identifier of an entity or relationship. 2. Connecting all changes of states of one entity (or relationship) to the identifier of this entity (or relationship).

I had published this idea on my website http://www.dbdesign10.com and in this user group in 2005 (see section 1. and 2.)

(b)
“We determine the Conceptual Model so that every entity and every relationship has only one attribute, all of whose values are distinct. So this attribute doesn’t have two of the same values. We will call this attribute the Identifier of the state of an entity or relationship. We will denote this attribute by the symbol Ack. All other attributes can have values which are the same for some different members of an entity set or a relationship set. Besides Ack, every entity has an attribute which is the Identifier of the entity or can provide identification of the entity. This Identifier has one value for all the states of one entity or relationship.” (See section 1.1)

--
Here are given the general conditions for the construction of procedures that are necessary to maintenance the history of events and their application to the identifiers and keys. I would like to emphasize once more: The general conditions are the mentioned procedures, not an “immutable key”. I mean, AM was only took “immutable key” from my procedures. I wrote “the general conditions” because there are many specific conditions in the construction of General database theory. I would like to mention that the next part of the definition: "... or can provide identification of the entity" from case (b), does not apply so much to the surrogates, as they apply to other cases. These cases are more general than surrogates. As I wrote, the surrogate key is unimportant case. 

I also want to show that Codd’s thinking about these issues was kind of narrowly oriented and technical solutions. I mean that he did not understand the nature of these matters. The authors of Anchor Modeling, were applied the surrogate key in the same manner of misunderstanding of the difference between technical solution and theoretical solution and the difference between a special case and the general case.  

The authors of AM gave the name of "immutable" to certain keys. Recently, I quickly glanced what Microsoft is doing with their "EDM", and there I noticed that they used the term "immutable type."
In my model, I gave two options for the identifier of the entity, it may be immutable or it may be mutable, depending on db design. So immutability depends on db designer. For example, it is known that in the U.S. a man in particular situations can change his identity. In the real use of databases, there is the need when an identifier should be immutable only at one period, for example, the identifier must be changed each year, so the identifier is immutable in one year and after that, this identifier must be changed.
In my paper "Database design and data model founded on knowledge constructs", section 4.2.4, I wrote: "In the states of an entity, the identifier of the entity stays unchanged through all the states of the entity, because the states are from one entity (however if we want, then we can decide and determine which of the states belong to one entity). The identifier of the entity determines which states belong to the entity. If an entity only has one state, then the identifier of the entity is semantically equal to the identifier of the state.”
In my paper “Semantic databases and semantic machines”, section 5.12, I demonstrated that history of entities, which changes its identifiers, can be maintain by “seq” structure.
Note that unary relations from RM/T are simple special case of the structure “seq”. The Anchors also are very simple special case of the structure “seq”.
However RM/T and AM can not solve some important matters that the structure “seq” can solve.

-------------------------------------------- 
Conclusion:

None of the above mentioned eight items E. Codd did not do. These items are very important. Item 7, it is history, changed a lot in the db theory. I think Codd did not even notice these areas. The same can be said for AM. Note that I published solution for history, 4 years before it did Anchor Modelling.
Therefore we might set the following question: Does the decomposition presented in "RM / T" is correct? The same question can be asked for AM. Does this decomposition of the structures that are shown in the AM is correct?

I mean, there are no proofs for these decomposition. These are the most important things, and many scientists were tried to prove it. As you can see Codd and AM are the exceptions, they have been able to publish their solution without proof.

From the papers, it is obvious that these decomposition are done, without any proof. How is it possible that such well-known journals have so scandalous omission? AM uses Codd's surrogates. Note that the paper about "AM" has the following title: "An Agile Modeling Technique using the Sixth Normal Form for structurally and Temporally envolving Data", despite the fact that 6nf is unusable.

As I wrote in this thread the surrogate key is not the main thing here. The main thing here is the decomposition into the binary (atomic) structures. This is crucial not only for database theory but also in some other areas.  

Vladimir Odrljin