The relational model is a wrong theory

[vldm10]

As I wrote in the title of this thread - the Relation model is a wrong theory.
What's the matter here?
Let me explain this on the following example:
A man named John Smith had black hair in 2010. In 2019, his hair was white. According to Codd's Relational model, these are two different people.
The aforementioned John Smith committed murder in 2010. This fact was discovered by police in 2019. The court acquitted John Smith as innocent because he has white hair and the killer had black hair. The Court relied on the theory named "Relational model".
Entity Relationship model is also a wrong theory.

Vladimir Odrljin

[James K. Lowden]

On Mon, 7 Oct 2019 08:38:52 -0700 (PDT)
vldm10 <vld...@yahoo.com> wrote:

> A man named John Smith had black hair in 2010. In 2019, his hair was
> white. According to Codd's Relational model, these are two different
> people.

I would like to think you're being provocative just to breath some life
into c.d.t. You don't truly believe what you wrote, right?

There are two possibilities, depending on how haircolor is modelled.
Neither says anything about the Relational Model.

Either the haircolor database models haircolor over time or at an
instant in time. If the latter, the tuple

{ John Smith, 2010, Black }

will be replaced by

{ John Smith, 2019, White }

whenever someone gets around to it. Codd refers to the phenomenon of
"changing over time" in his 1970 paper.

If time is in the model, the tuples

{ John Smith, 2010, Black }
{ John Smith, 2019, White }

both appear in the database. That doesn't mean there are two people.
It means there is one person at two times.

As a matter of fact, it doesn't even *mean* that: the meaning of the
tuples isn't inherent; it's ascribed by humans interpreting the
information. As far as RM is concerned, they're just tuples adhering
to certain rules.

Let me say that again in a different way. To the DBMS -- which (we
would like to think) implements RM -- name, year, and color are only
strings we associate with attributes. "John Smith" isn't a person; it's
a value taken from a domain and assigned to an attribute in a tuple.
Only that and nothing more.

I think you know all that, which is why I'm surprised you made the
assertion you did.

--jkl

[vldm10]

Dana utorak, 8. listopada 2019. u 20:14:05 UTC+2, korisnik James K. Lowden napisao je:
> On Mon, 7 Oct 2019 08:38:52 -0700 (PDT)
> vldm10 <vld...@yahoo.com> wrote:
>
> > A man named John Smith had black hair in 2010. In 2019, his hair was
> > white. According to Codd's Relational model, these are two different
> > people.
>
> I would like to think you're being provocative just to breath some life
> into c.d.t. You don't truly believe what you wrote, right?

>

> Codd refers to the phenomenon of
> "changing over time" in his 1970 paper.

I can tell you that my grandmother said the same thing as you quoted E. Codd. But she's certainly older than Codd, so the priority for that idea belongs to her.

[Roy Hann]

You have just illustrated why a set of values has no intrinsic meaning.
The intended meaning can be interpreted successfully only with respect
to the agreed predicate that everyone shares. The RM takes this as
given.

I would like to think you did it deliberately, in which case, neatly
done sir. Unfortunately it doesn't illustrate the claim you are making
in the subject heading so it is probably an accident.

Roy

PS: I second James' gratitude to you for reviving c.d.t. Just try not to
gnaw on too many imaginary bones.

[Gene Wirchenko]

On Mon, 7 Oct 2019 08:38:52 -0700 (PDT), vldm10 <vld...@yahoo.com>
wrote:

>As I wrote in the title of this thread - the Relation model is a wrong theory.
>What's the matter here?

Your ranting.

>Let me explain this on the following example:
>A man named John Smith had black hair in 2010. In 2019, his hair was white. According to Codd's Relational model, these are two different people.

Are you serious with this nonsense?

>The aforementioned John Smith committed murder in 2010. This fact was discovered by police in 2019. The court acquitted John Smith as innocent because he has white hair and the killer had black hair. The Court relied on the theory named "Relational model".
>Entity Relationship model is also a wrong theory.

Sincerely,

Gene Wirchenko

[vldm10]

I gave an example in my post. An example is from real life. So you can elaborate on your claims, in this example. My intention with this example was to point out some limitations in the Relational Model. Of course, the Relational model is better than the previous data models. I will start with C. Date definition of key:

Let R be a relation. Then candidate key for R is subset of the set of attributes of R, Key K, such that:
1. No two distinct tuple of R have the same value for K.
2. No proper subset of K has the uniqueness property.

However, my definition of the key is different and much richer. It includes the identifier of the entity and the identifier of the state of the entity. I defined the identification process - it's a whole new theory. I have defined another completely new theory that completely defines how one understands that an entity has been changed. This is what a group of Swedish scientists plagiarized and called "Anchor modeling". Most of these new scientific results have been plagiarized by this group of Swedish scientists at Stockholm University and presented as their theory.

My solution completely defines what a single object change is. RM theory and ER theory assume that any change to an object is a new object and this is reflected in the new key and the "update" of the corresponding data, which by definition means a new object.

That is the essence of my example.

Vladimir Odrljin

[vldm10]

[vldm10]

I really do not understand your comment, so I would ask you to explain your claim in detail so that I can respond.

Vladimir Odrljin

[vldm10]

Dana petak, 11. listopada 2019. u 15:00:36 UTC+2, korisnik Roy Hann napisao je:

[vldm10]

Dana petak, 11. listopada 2019. u 15:00:36 UTC+2, korisnik Roy Hann napisao je:

I really do not understand your comment, so I would ask you to explain your claim in detail so that I can respond. If you think I was wrong somewhere, then say specifically what it is.

Vladimir Odrljin

[vldm10]

My db design is based on atomic structures. I am the only one who has achieved db design at the level of atomic structures. Date & Darwen are bluffing with 6NF. In fact, they just said what atomic structures should look like, which is clear to everyone. What is only important, they have not solved problem. This is the next question: how to get atomic structures and what is the appropriate theory.

The second important thing is that I'm not based on predicates, but on concepts. Concepts are at a higher level of generality than predicates.

The third important thing in my db solution, I only have the add operation. I don't have any other data operation. For example, I do not have a "delete" or "update" operation on some data.

Date & Darwen make the most simple examples in their book Temporal Data and the Relational Model, so we cannot accept that as a theory. For example, they have an example, which has one relation and a simple key.

Date & Darwen make the most simple examples in their book Temporal Data and the Relational Model, so we cannot accept that as a theory. For example, they have one relation and a simple key.

RM accepts "Anchor Modeling". For example, in the paper "Anchor Modeling", which received the first prize at the World Congress, there is the following text "using the Sixth Normal Form" in the title of the paper. There is real chaos here.

The Sixth Normal Form has some "dependencies" and the goal is atomism. However, "Anchor Modeling" has an "Anchor technique" that is the opposite of normal forms. Various changes to "Anchor" accumulate here. I personally could not find a single atom of science in this compound of RM and AM.

Finally, let's mention that Codd chose the surrogate key as the entity key, which is contrary to his previous theory. What's wrong too, this Codd key is invisible to database users.

Vladimir Odrljin

[vldm10]

Dana petak, 11. listopada 2019. u 15:00:36 UTC+2, korisnik Roy Hann napisao je:

Codd's database solution only stores the last attribute-level value. This is the simplest case of a database solution. In that sense, I mean Codd's RM is the wrong solution.
Codd's database solution has the following data operations: delete data and update data. This means that Codd's databases do not have past. And that is very bad for business.
In the same sense, the ER is wrong.

My solution has a complete history of the small world that we call „database“ . In my solution, no one can "tear down" any part of history, even if he wants to. My solution is at the atomic level, that is, at the level of attributes. That means I have atomic thoughts, atomic concepts, atomic objects, atomic predicates, and atomic propositions. From there, one can see the structure of propositions, predicates, objects, concepts and thoughts. Also one can build complex propositions, predicates, objects, concepts and thoughts from corresponding atomic ones.

Vladimir Odrljin

[James K. Lowden]

On Tue, 15 Oct 2019 00:59:57 -0700 (PDT)
vldm10 <vld...@yahoo.com> wrote:

> Codd's database solution only stores the last attribute-level value.

Yes.

> This is the simplest case of a database solution.

Many would say still simpler solutions pre-exist even Codd, but OK.

> In that sense, I mean Codd's RM is the wrong solution. Codd's
> database solution has the following data operations: delete data and
> update data. This means that Codd's databases do not have past. And
> that is very bad for business. In the same sense, the ER is wrong.

(I think you mean "RM is wrong"?)

In your opinion, then, it's a mistake for the DBMS to ignore history,
because businesses need to retain history in their databases.

OK. That's a point of view. I will say that only here among database
theory geeks can we have a robust discussion about how SQL DBMSs are
"bad for business" when the trend over the last decades has been for
businesses to demand less, not more, of the DBMS industry, to say
nothing of theoretical fidelity. I'm looking at you, NULL.

My question to you, Vladimir, is this: How is expressing time in the
database theory -- and, presumably, language -- better than dealing
with time overtly, as data?

In my world, if I have a table of people,

create table people (name text not NULL primary key);

I can create people without a past (rather a neat trick). If they need
a past,

create table people (
asof date not NULL,
name text not NULL,
primary key (asof, name)
);

serves the purpose. A view of "current people" is easily created,

select * from people as P
where not exists (
select 1 from people
where asof > P.asof and name = P.name
);

You seem to want to make the history of people intrinsic in the
language. Obviously, that makes the language more complex, because it
has to express a new dimension, namely time. For that language to be
"better" in any sense, it has to enable simpler, shorter queries than
otherwise possible with simple old SQL. Can you provide an example?

--jkl

[vldm10]

I'm just moving from one city to another. When I get the internet in another location, then we can discuss this solution.
In short, I work at the atomic level, that is, I work on one data. Each piece of information (a real object or an abstract object) is determined by three things (for now). These three things are who entered this information, at what time and at what location. These three data are about a real or abstract object. Abstract objects are those from computer memory. Every procedure that enters the data or the person who enters the data has its "password", so I know who entered that data in the DB. Accordingly, the time in my solution is just a tag to identify when an event has occurred. I only have two data events:
1. The event when the new information was created
2. The event when the existing data in the DB ceased to exist.

My goal was to realize the previous ideas on one piece of information (that is, on each individual attribute from the entity). That is on atomic data. Simply put, that's how I understand time.
Vladimir Odrljin

[Derek Ignatius Asirvadem]

Vladimir Vladimirovich

1. A couple of years ago, I tried interacting with you re your suggestion that Anchor Modelling had plagiarised your unpublished database design. Along with weird and wonderful ideas that the RM does not open the door when your hands are full and should walk the dog. The interaction was disappointing because you would not provide specific logic or details, and you kept repeating your unsubstantiated claims. Ultimately, nothing could be resolved, and I gave up.

We agreed on some aspects of what you defined Anchor Modelling to be, and disagreed on others. That is, while we could not agree on what the damn thing is, we could not therefore proceed to discussing what it does or does not do; whether it is a horse or a zebra or a fish; etc.

You kept telling us how marvellous your database design theory was, but you never actually defined it, or published it. We still do not know what it is (other than your claim that it is brilliant; better than AM; better than RM; better than Elon Musk's batteries), and therefore we still cannot dispute your non-specification and non-proof.

We even agreed that 6NF is not an NF, and that Date & Darwen's idiocy is idiocy.

And finally, your arguments are devoid of logic.

Sorry, but I will not waste time again.

2. Now, a few years later, your database design concept has improved and everything (objects; predicates; propositions; etc) are "atomic" or "atomicised". Marvellous. I commend you on your progress.

Please be advised that all my databases since 1993, in addition to being totally Relational (compliant with the RM), and in addition to being Relational-Progressed (ie. going where any genuine disciple of Codd would naturally go), are /wait for it/ totally atomic. Please do not accuse me of plagiarising your 2019 work, because:
a. I did all that 30 years before you mentioned it
b. you have not yet published your work, therefore plagiarising it is physically impossible.
c. whatever you mean by "atomic" and whatever I mean by "atomic" are not necessarily the same thing. Mine is published (in the form of Data Models and DDL in about 80 large implementations), yours is not.

(In the last ten years, I have progressed to a higher form of "atomic", which is implemented in only 8 databases. But I will not be publishing that here. I will stick to the progression of the RM that is easily understood.)

3. Now you attack Codd and his RM. Without specifics. Using an insane (schizophrenic) example. JKL has done a good job exposing the idiocy of your example, so I will not repeat. You have grand new ideas of temporal treatment of data, but you shy away from the proper terms, and invent your own. Please be advised, those who can read and understand the RM, have implemented genuine Relational Temporal tables in their Relational databases. For me, at least since 1993, for others, I sure sure from 1987, when geuniune SQL platforms were available.

Codd gives a definition for temporal data, but sure, he does not give detailed examples. For those of us who understand his paper, they are no necessary. For those who don't no amount of explanation would be enough. Just look at what Date & Darwen have construed Codd's RM to be.

Based on our past interaction, as well as that which you have had with others on c.d.t, both you and the other participants here have very little idea of what the RM is. It is very silly, the province of a rebellious child, to argue about something that you do not know. First get to know what the RM is, which I acknowledge is difficult, because Date & Darwen and their massed array of followers promote and market 1960's Record Filing Systems as "relational", the very thing that the RM overcomes and replaces.

4. The Relational atom is a thing (relation, table). The Relational atom is Identified by a Relational Key, as defined by Codd. A Relational Key has meaning and context. Whereas D&D's pig poop, the RFS fraudulently marketed as "relational", has a Record ID as "key".

> Finally, let's mention that Codd chose the surrogate key as the entity key, which is contrary to his previous theory.

That is a half-truth, and the other half is a lie.
- in the RM (perhaps what you call his "previous theory"), which is the only theory Codd has given, along with a Relational Algebra, there is only the Relational Key (composite; strings; meaning; external).
- in one of his later papers, actually a presentation he gave in Australia, "RM/Tasmania", yes, he allows surrogates as "keys"
- as explained to you previously, that was as a result of trying to gain acceptance, and being tricked by Date without realising it (he realised it later), into implementing the then widely understood RFS Record IDs.
- RM/T is not a theory, it has no theory behind it, it is only an adjunct paper

So, yes, the later surrogate "key" with no theoretical underpinning contradicts the fully articulated theory of the Relational Key. Assuming you have read more than your own writings, you may have heard of the Four Laws of Thought, which is the foundation for science; Western Thought; and Western Civilisation. The Law of Non-Contradiction and the Law of the Excluded Middle, demand that a scientist resolve that contradiction (ie. not leave it unresolved), and cancel one of the contradicting declarations.

Obviously the RM and the RK, being supported by theory wins, and the anti-Relational Record ID is cancelled. There is no contest.

However, D&D have capitalised on the RM/T, because it allows them to implement what they CAN understand: 1960's Record Filing Systems. In the following years, they came up with all sorts of abnormal "normal forms", replete with maffematical definitions, in order to shore up their otherwise putrid beast. Such have none of the Relational Integrity; Relational Power; and Relational Speed of a Relational database. It fosters the schizophrenic notion that "all data can be perceived as tables". It is schizophrenic because it perceives data, the world that it registers, as fragments, and it denies the rest of the RM. That is, D&D's "RM" consists of;
• 75% 1960's RFS
• about 5% of Codd's RM, plus
• 20% their own manufacture.

Yes, that thinking in fragments is the very opposite of atomic, so you will obtain some traction to argue with the anti-Relational D&D followers here. But not with the RM.

> Finally, let's mention that Codd chose the surrogate key as the entity key, which is contrary to his previous theory.

To sum up, the truth is, the RM has a Relational Key, only, and the RM specifically prohibits surrogate "keys".

If you do not understand that, sure, you will be able to make all sorts of false charges against Codd, same as the idiots who promote D&D's pig poop, who participate in c.d.t. Sure, you will be able to erect straw men and argue about nothing, endlessly. But you will be laughed at by those who can understand the RM.

--

My recommendation is, first learn Codd's RM, and remove the insanity of D&D's "RM". Second, work hard on your concepts, and publish it.

Cheers
Derek

[Derek Ignatius Asirvadem]

> On Tuesday, 15 October 2019 18:59:59 UTC+11, vldm10 wrote:
>
> Codd's database solution only stores the last attribute-level value. This is the simplest case of a database solution.

Yes. So what is the problem.

> In that sense, I mean Codd's RM is the wrong solution.

God help me. Can you not differentiate the car from the driver. If an imbecile drove his car into a river, is that Henry Ford's fault ??? That is what you are implying. Listen carefully.

- The RM is an academic paper that defines one thing: how to perceive data relationally
- As with any paper, it gives definitions, but it is not a "how to" manual
--- therefore it is stupid to expect that it should define database design; modelling; Normalisation (as Date and Darwen wail to be "missing", proving that they are not academics or normal humans)
- Databases without platforms (eg. ISAM by a knowledgeable person) existed prior to Codd; database platforms existed prior to Codd, therefore there was no need to define anything in that area
- but since the RM was a major progression from such DBMS platforms, Codd did detail the differences, and the caveats.

> Codd's database solution

No. Codd did not give a database solution. He gave a definition for Relational modelling and databases. The "database solution" is whatever the designer does, not what Codd prescribed.

Yes, he did give a definition for the Relational Key, and for the temporal Relational Key.

> Codd's database solution only stores the last attribute-level value

Not Codd's "database solution". The designer chooses whatever design he sees fit. If all he requires is a row-level versioning, sure, just add /generation/ to the Relational Key. If he needs attributes in "6NF", sure, just add /generation/ to the Relational Key in the Attribute table.

That latter is the Relational version of Anchor Modelling, whereas they use surrogates as Keys, and have to handle all the madness that goes with it.

If one treats the Entity in the base table as atomic, and thus the Base table is the nucleus and the Attribute tables are electrons (note, they all have precisely the same Relational Key), and one uses OLTP ACID Transactions instead of direct updates, sure, one has a healthy, robust, Relational implementation. Not because of Codd, not despite Codd, but because one is a capable database designer.

> In that sense, I mean Codd's RM is the wrong solution.

Nonsense, as explained above.

If you have need for something more than that which I have explained above, define it (not describe it).

> My solution has a complete history of the small world that we call „database“ .

So what. Any Relational database (complying with the RM, on an RDBMS platform, using little old SQL) can be set up to have:
- a complete history, or
- only a history for those tables that require a history, or
- only a history for those attributes that require a history.
I have been doing that since 1979, Relationally without an RDBMS since 1981, Raltionally on an RDBMS since 1993. Big deal. So what.

To REQUIRE every Entity table to be
(a) de-atomised into "6NF", Base plus Attribute tables, and
(b) have the Base table made temporal, and
(c) have each Attribute table made temporal,
would be a massive, absurd amount of overhead that is not relevant to the business. That is what would truly be "bad for business".

Theoretically, it would be perfectly fine. Nothing new. We had it in pre-relational form before Codd, and in Relational form after Codd.

This too is not something that you can wail "plagiary" about: Codd did not have your thoughts in mind (if indeed you had been born), which in any case you had not published for his notice, in 1970.

> In the same sense, the ER is wrong.

Yes, ER is wrong, but no, for completely different reasons.

ER was fine in the pre-relational context. After the RM, ER modelling is quite stupid, because it does not handle the central article in the RM: Relational Keys, which are composite. It is very sad that ERD is taught these days at tertiary level, and then students have to "switch" to a "welational schema" which is actually an RFS with Record IDs as Keys. AFAIC, it is a purposeful sabotage of the RM. The notion of using ER modelling, a primitive, pre-relational method, suits Record ID based Record Filing Systems just fine,

For Relational Modelling, the method is IDEF1X, which can be erected at the:
- Table
- Table-Key (composites; PKs; AKs; etc)
- Table-Key-Attribute
Levels, as relevant to the progressive stages of modelling.

Cheers
Derek

[vldm10]

I put in the title of this thread the following text "wrong theory" which is not what I meant. I meant to say that the Relational Model solved simple problems in DB theory. Also no other database theory has solved complex problems.

Before we begin our discussion about the fundamental structures of databases, I think it would be good to define these fundamental data structures of the entities that "build" the real world.
In that sense, I think we must first define the atomic structures, that build entities. For example, how would you define the atomic structures of an entity, (for example) that has five properties.

Vladimir Odrljin

[James K. Lowden]

On Wed, 13 Nov 2019 21:56:39 -0800 (PST)
vldm10 <vld...@yahoo.com> wrote:
> Dana ponedjeljak, 28. listopada 2019. u 19:19:51 UTC+1, korisnik
> James K. Lowden napisao je:

> > You seem to want to make the history of people intrinsic in the
> > language. Obviously, that makes the language more complex, because
> > it has to express a new dimension, namely time. For that language
> > to be "better" in any sense, it has to enable simpler, shorter
> > queries than otherwise possible with simple old SQL. Can you
> > provide an example?

> I meant to say that the Relational Model solved simple problems in DB
> theory.

Depending on the meaning of "simple", sure. It remains to be shown
what your theory solves that it does not.

> Before we begin our discussion about the fundamental structures of
> databases, I think it would be good to define these fundamental data
> structures of the entities that "build" the real world. In that
> sense, I think we must first define the atomic structures, that build
> entities. For example, how would you define the atomic structures of
> an entity, (for example) that has five properties.

Sorry, Vladimir, but I won't rise to that bait. It's not for me to
define anything. You're the one making the claims; choose your own
definitions. I come armed only with bouquets and tomatoes.

I made a simple challenge: if your way is better, show us. Choose any
example you like, expressed in any language you like, and demonstrate
that the problem is more readily solved your way than in SQL.
Alternatively, perhaps you've defined a new algebra, or a new relational
operator. Show us.

--jkl

[vldm10]

Suppose you accidentally made a mistake and wrote the following:

{John Smith, 2010, Brown}.



How would you correct your mistake?

--Vladimir Odrljin

[vldm10]

Dana utorak, 8. listopada 2019. u 20:14:05 UTC+2, korisnik James K. Lowden napisao je:

Suppose you accidentally made a mistake and wrote the following:

{John Smith, 2019, Brown}.

[James K. Lowden]

On Tue, 26 Nov 2019 10:02:55 -0800 (PST)
vldm10 <vld...@yahoo.com> wrote:

> Suppose you accidentally made a mistake and wrote the following:
>
> {John Smith, 2019, Brown}.
>
> How would you correct your mistake?

Do you think I'm not paying attention?

You're the one making the claims. You're free to choose any syntax you
like, define any terms as you prefer, pick any use case you think best
illustrates the advantage you think is most important. The whiteboard is
yours.

I'm the one innocently asking how your system is better. I've already
asked that question twice, and twice you've made not the slightest
attempt to answer.

The invitation remains open.

--jkl

[vldm10]

You can see in the specific example in my post from August 7, 2018, that deleting incorrect data can lead to catastrophic results in the database. The title of the post is: "Anchor modeling" has no history, at all.

[vldm10]

I published my first scientific paper in 2005. „Anchor modeling“ was presented in
November 2009 at the congress in Brazil. It is the most significant congress for
database theory.


I have shown in this user group that "anchor modeling" is plagiarism of most
important results of my scientific work. That what is not plagiarism in "Anchor
modeling" it is mostly wrong and incorrect.


At the most notable database conferences ER 2009 in Brazil, „Anchor modeling“ won the
ER 2009 Best Paper Award. Peter P. Chen presented paper „Thirty Years of ER
Conferences“. In this way, the brutal plagiarism of important scientific discovery
was legalized. Ancient Greek philosophers called this problem "The Theseus Ship". The
authors of this plagiarism referred to this problem as "Anchor Modeling".


In the scientific journal Data & Knowledge Engineering Volume 69, Issue 12, December
2010, Pages 1229-1253, the authors of "Anchor modeling" published their second paper:
„Anchor modeling - Agile information modeling in evolving data environments.“


In this paper, the authors of „Anchor modeling“ have plagiarized two new theories
that have been published in my paper and presented and discussed in detail on this
user group.
The authors of "Anchor modeling" are plagiarized my theory of identification and the
theory of the state of entities and relationships.
Editor-in-Chief of journal Data & Knowledge Engineering is Peter P. Chen.

I wrote in this thread that "Anchor modeling" cannot solve the wrong data. Even more,
„Anchor modeling“ enables crime with data from the database.

And after all this plagiarism and versions of „Anchor modeling“, in my opinion
authors of „Anchor modeling“ and Peter P. Chen are far away from scientific solution
in this matter.


Vladimir Odrljin

[vldm10]

Let us have the following example:

  {John Smith, Black}
  {John Smith, Black}
  {John Smith, Black}

In the example, three men with the same name, surname and with the same hair color are given. Many countries allow residents with the same name and surname to exist. How would you solve the history problem for the "hair color" property using any programming language?
One of these three men in this database changed their hair color

[Derek Ignatius Asirvadem]

> On Friday, 6 December 2019 17:18:29 UTC+11, vldm10 wrote:
>
> Let us have the following example:
>
>   {John Smith, Black}
>   {John Smith, Black}
>   {John Smith, Black}

The example is insipid. It does not state what the Keys are, if any.

The Relational Model demands unique rows. By virtue of the evidence (your example), the text you give is not Relational. This thread, YOUR TOPIC, is the Relational Model.

> In the example, three men with the same name, surname and with the same hair color are given.

No they do not. "In the example", no indication is given that they are three men; or two men with one duplicated; or one man duplicated twice. Thus far, zero men exist in the Relational database table.

Therefore your declaration "three men" "in the example" is false. Fix your example and declare it properly. Otherwise what you are trying to explain is incoherent.

> Many countries allow residents with the same name and surname to exist.

Yes, they use database designers whose brains are not scrambled. They use:
- either the Relational model
- or the 1960's Record Filing System plus tons of additional indices
Such that each person is identified uniquely.

In an international database, each person is unique across the planet. This one, earth, not the one you are on.

> How would you solve the history problem for the "hair color" property using any programming language?

Well, before you "solve the history problem", you need to have a coherent database table in which "the history problem" can be exposed as a single isolated problem, such that the "problem" can be understood as a problem, and then possibly solved. Right now you have an incoherent "example", in which "the history problem" can be due to many factors, and cannot be perceived as a single problem.

> One of these three men in this database changed their hair color

No. none of these men are in a database. The term "database" means something. Since your thread is about the Relational Model, the database is supposed to be a Relational database. You do not have a database yet, let alone a Relational database. They exist only as an undefined list that cannot be placed in a database. For the example to exist as stated, it has to be in a file (not a table, not a database), with no index.

Please try and provide a coherent example, for whatever it is that you are trying to say. That means, since you are declaring that the three freaks exist in a "database", and "Relational Model" is the topic:
1. give the CREATE TABLE command for the database table
2. give the PRIMARY KEY and UNIQUE constraints for the table
3. if they are all in one country, or across the globe, then the table has to have the attributes and constraints to allow that
--- if a person is not uniquely identified, it is not a Relational table, and thus your example is false, the declaration re the Relational Model is false
4. then give example data that conforms to the table you have defined
5. then give the example data for the supposed "history problem"

Your supposed problem cannot be discussed coherently until you do that. Thus far you are providing a poor rendition of [5] without [1][2][3][4]. JKL has said the same thing, albeit in different words.

if you continue the nonsense you have posted thus far, which is incoherent and undefined, you will only continue to damage your own case, your own reputation.

Cheers
Derek

[vldm10]

This is your example, I just added two more tuples, As far as I know you use
Date&Darwen definition of tuples, so I wrote 3 tuples as follows:

{John Smith, Black}
{John Smith, Black}
{John Smith, Black}

Now I will add 3 identifiers of coresponding entities. Let me write it as follows:

{IdentifierOfEntity1, John Smith, Black}
{IdentifierOfEntity2, John Smith, Black}
{IdentifierOfEntity3, John Smith, Black} .

You can add these 3 identifiers to these 3 entities, only if these entities are
mutually independent. Also note that these identifiers are different from others
attributes, becouse they identify entities.
Identifiers of entites they are in database and they are in the real world also.
Because they exist in databases and in the real world, the identifiers of entities
are not surrogates.

Let's now third entity changed his color of hair to white. Then I introduce the
identifier of the state of the entity and I have:

{IdentifierOfEntity1, John Smith, Black, ...}
{IdentifierOfEntity2, John Smith, Black, ...}
{IdentifierOfEntity3, John Smith, Black, ...}
{IdentifierOfEntity3, IdentifierOfState1OfEntity3, John Smith, White, ...} .

Now you may notice that I have an atomic structure, that is, I have one attribute and
a history of events in that atomic structure. Note that I use term „events in that
atomic structures“. Anchor modeling use term „history of changes to the attribute
values“. An event in my atomic structures can be: „enter the name of person into DB,
who entered atomic data in DB“.
I know for each my data who is entered the data or with which procedure is entered
this atomic data.
-------------------------------------------------------------------------------------
My point here is the following: From atomic structures you can build everything, by
using any modern language.
I also tried to „save“ SQL, but I paid much more attention to atomic structures and
any modern language.
-------------------------------------------------------------------------------------

You can also see two identifiers:
1. The Identifier of an entity.
2. The identifier of the state of an entity.

Note that my identifier of state is actually a surrogate key. But when I link it to
the corresponding identifier of the entity, then it is a very strong and complete
link. So I have always two identifiers: the identifier of the entity and the
identifier of an state of the entity.

-------------------------------------------------------------------------------------
My point here is that these two identifiers form one whole. In fact, here is shown
how to build one (new) procedure from two procedures which are in our mind. We can
call these procedures mind's procedures.

One procedure is related to identification of an entity. The second procedure is
related to identification of a state of the entity. These two procedures shows that
changed object is not a new objects, rather it is just the changed object. So one
procedure on mind level represent composition of two procedure.
-------------------------------------------------------------------------------------

Of course, Anchor modeling is nonsense, because it is not possible to build a real-
world database using surrogates. „Anchor key“ is the surrogate key.

Let's note that the surrogate key was suggested by Edgar Codd. By the way the
surrogate key contradicts his definition of the key. Note also that the authors of
"Anchor modeling" put 6NF in the title of their award-winning paper.
In this user group, I explained that both Codd and Date & Darwen bluffed that they
solved atomic structures.
6NF is only another name for atomic structures, it is not a solution for atomic data
structures.

In late 2010 and early 2011, the authors of Anchor modeling published their second
paper: Anchor Modeling Agile information in evolving data environments u časopisu
DKE, Editor-in-Chief: Peter P. Chen.

In this second paper, authors of Anchor modeling completely plagiarize my paper, they
introduced states and identifiers. This is published by DKE magazine, whose editor-
in-chief is Peter Chen. In the meantime, I complained to Peter Chen who never
answered me, I only received confirmation that my complaint had been received.

Note that „anchor modeling“ is only a special case of my DB solution.

Vladimir Odrljin