On 2012-07-21, vldm10 <vldm10 (AT) yahoo (DOT) com> wrote:
Not the name, the value!!! But no, it does not guarantee the ability to
identify the real world entity, only that everyone is (apparently)
talking about the same entity.

No serious objection to that statement (except for English usage -
"none" rather than "neither").

Only if you expect to use them directly to find the real-world entity.

Unless the database contains "illegal" vehicles and is expected to do
so.

To some level of achievable accuracy. Which is why a database will only
count the "identical" entities (usually those in some definable
location).

A high-value vehicle stolen to order will have its identity changed,
including the VIN. Of course the original VIN still technically refers
to it, but how can you find out? The substitute VIN may or may not be
a duplicate of some other. A cut-and-shut job made out of parts of two
vehicles may inherit the VIN of one of them, or not, but this VIN is no
longer valid. Are the rules for kit-cars and extensive modifications by
legal owners adequate and adequately enforced?

So no, in general a VIN is not intrinsic, and therefore not a very good
example to choose.

I have not read this yet, I may do so at some point, but for the moment
I do not see that it could make any difference to my main point:

Any identifier assigned to a natural or man-made entity (by anyone
whatsoever) does not become an intrinsic property of the entity no matter
how many times or where it is recorded on the entity. Either there will
be a way for the entity to continue as the same entity if it is removed
or altered, or removing it will destroy the entity in which case the
identifier refers only to an entity that no longer exists. All such
identifiers are merely the assigner's surrogate key that they choose to
disseminate in some way.

Eric
--
ms fnd in a lbry

I used an old version of the user group and I noticed that the graphics on the new version is not well represented.
My apologize for these errors.

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 bookis about temporal data rather then about history of data.



I wrote “controls redundancy”. Shortly, by “controls redundancy” I mean the following:
My solution does not update and delete data. So it does not have update anddelete 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”.



There is a precise definition about the "Closed WORLD assumption". However,"the world" and "a change of the world" are the most undefined words in the world.



Please note that the entity and relationship are precisely defined in my papers. But if you believe that the entity and relationship are not well defined in other papers, then you may be right.

Vladimir Odrljin

Op dinsdag 24 juli 2012 03:23:30 UTC+2 schreef vldm10 het volgende:
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 someperiod 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, orshould, never arise when it comes to "the history of the beliefs that wererecorded 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.



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 theDBA's control] ?

Redundancy (the full name for denoting the subject topic was "redundancy and derivability", IIRC) comes from what the external predicates are for eachof 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 truthvalue 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.



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.

These authors do not apply any of the points (ii) a,b,c,d,e,f that I mentioned in my first message in this thread from 14 July. These points are related to the large and important parts of the "History".







I am not sure that you understand my db design. In my database design, I model states of entities and relationships. To be precise, a state of an entity (or relationship) is knowledge about the entity (relationship) (see my paper “Database design and data model founded on concept constructs and knowledge constructs”, section 3.9 and 4.2.4.1 at http://www.dbdesign11.com) .
My db design changes the definition of truth and truth conditions. Truth and truth conditions depend on the state of the corresponding entity. I thinkthat this is very important result.

The relationship between meaning and truth is also defined in my model. (see my paper “Semantic databases and semantic machines”, section 3, at http://www.dbdesign11.com )





There is a huge difference between "close" and "delete". These things can not be compared at all.

Vladimir Odrljin

How should we design a database, so that it supports the decomposition of relvars into corresponding binary relvars?


In current database theory, database design is influenced by functional dependencies. My approach to database design is reversed. That is what I wanted to express with the title.

Let me briefly explain my solution to this problem. My solution only works with entities, relationships, intrinsic/extrinsic properties and simple keys. First, I will describe the general case:

Case 1. All-key entity. In my data model the general case is that the entity has intrinsic properties. This means that properties of the entity take values freely. This entity corresponds to a relation which has mutually independent attributes.

Case 2. All the entities from a set of entities have the same attributes. For instance, they are all Honda Civics with the same attributes. In this case we introduce the identifier id = VIN as a property of the entity. We can note that there are many identifiers introduced into business applications by international standards.

(In the case of a relationship, the key is always predefined.)

These two cases are general cases in my database design and we can note that all FDs here are implied only by keys. We can also note that here join can be done only by the key, because the key is only mutual part for all these attributes.

I introduced Simple Form on May 15, 2006 (see http://www.dbdesign10.com ) and the above two cases satisfy conditions for Simple Form. Simple Form is much better than other normal forms. We don’t need to put relation into 2NF, 3NF, BCNF, 5NF … because the binary schemas can be immediately constructed.
In both of the two general cases, the schema of the entity will be: E (identifier, attribute1, ..., attributeN). This schema meets the conditions for the Simple Form, so now we can construct the corresponding binary relations..

Now we can ask what other cases in database design exist besides the two above-mentioned ones? A better question would be: What generates the other cases?

The other cases for the design of entities (or relationships) can be generated by the following:
Case-a. By introducing business rules and constraints to entities (or relationships)
Case-b. By applying the operation add, delete and update to entities (or relationships)

The mentioned business rules and constrains can ruin every database.
The business rules in my database solution are solved by using binary structures because the business rules and constraints should be defined on the level of binary structures.

Note that business rules can be set up so badly that they cannot be broughtinto compliance with the theory of databases.
Case-b in my database model is solved by creation of “History”. Databases which maintain “History” do not have delete nor update operations; my database model keeps all data.

In my data model, for any database data it is known how it was made and who(or which procedures) made it. In my opinion this property is a huge theoretical and practical advantage of my data model.
We can ask the question, “Is there a way that someone can break the maintenance of history in my data model?” The answer is no.

Note that in object-oriented approach there are constructors, destructors, encapsulations, and states, but it is not possible to determine many thingsrelated to data. Deleting and updating data is allowed, thus there is no maintenance of states. The identity in OOA often uses a physical location inmemory.
In “Anchor Modeling” deleting of data is allowed. This implies that updating of data is also allowed. Therefore there is no history. Deleting or updating of data impedes online (internet supported) databases.

In my data model I work with the conceptual model and the logical model. Toswitch from one model to another, I use the mapping from one data model tothe other. This mapping consists of two mappings: schema mapping and data mapping. Both mappings are determined by binary structures and by identifiers of states of entities (or relationships). See my paper “Database design and data model founded on concepts and knowledge constructs”, Section 6..4 on http://www.dbdesign11.com , from 2008.

Simple Form is on the level of the relational model. However, there is the following problem: how to decompose a structure into binary structures on the conceptual model level? I showed how this can be solved in my paper “Database design and data model founded on concepts and knowledge constructs”, Section 4.2.3, Example 6 on http://www.dbdesign11.com , from 2008 and in my paper “Semantic databases and semantic machines” Section 5.8, on http://www.dbdesign11.com

--
The above text relates to simple databases. Now we will show how to construct a binary structure for complex databases (databases that manage changes,and keep history)
For complex databases, the decomposition into the binary structure is realized by means of states and identifiers of states. See my paper “Database design and data model founded on concept and knowledge constructs", Section4.2.9 )

(Note that in RM / T and "Anchor Modeling" this decomposition is not proven.. For example it is not done at the level of the ER model)

On Tuesday, July 24, 2012 4:12:56 PM UTC+2, Erwin wrote:



Let me give you two examples. These two examples show that the combination of “Surrogate key” and “Delete” is a very bad combination.

Example1.
State1. Person X from a company that supplies consumers with electricity reads a device for measuring the energy consumption for a person Y. Person Xwrites down on paper that, on May 1st, 2011, person Y fully spent 128 units of energy.
State2. Person X submits this list to the IT department on June 1st, 2011, a month later.
State3. The person from the IT department has put this list in a drawer andforgotten about it. After two months, he was reminded of this list and promptly handed it over to the person doing data entry.
State4. Thus, the data was entered into the database on September 1st, 2011..
State5. Then the IT department filed a lawsuit against a person Y, because this person has not paid the electricity consumed.
State6. However, it turns out person Y passed away on May 15th, 2011.
State7. During the trial it is determined that the person who entered the data, made a mistake and entered 728 instead of 128 (as the amount of energyconsumed).
The son of person Y is a good lawyer represents in court his late father.

In this example, it is clear who created each state. We also know the procedure responsible for creating this state. Finally, we have an operation assignment. More formally, we have the “who” from the real world, “whichprocedure” in the db and the “name” of the location in a memory in which the “state” became permanent (assigned).

However, if one uses existing db theory (write and delete), then he doesn’t know what is going on and who is responsible for some particular data.

Example2.
Let there be a data relation that represents the entity Car. Aside from other attributes, car has the attribute VIN (vehicle identification number). If we use the surrogate key, then one of the binary relations has the following scheme : R1 (SurrogateKey, VIN). For example, one of the possible instances of this scheme can be the following relation : R1(SurrogateKey228, VIN1).

In the OO-approach, “RM/T” Codd’s approach and in Anchor Modeling, itis possible to delete this binary relation. Anchor modeling allows the deleting of “erroneous data”. Thus, using the mentioned theories, we can delete R1. Later, we can insert the following new R1(SurrogateKey228, VIN2).Here, VIN1 and VIN2 are two real VIN numbers.

This example shows that anyone can change the identification of an entity. Of course, this is nonsense.
We can notice that the “VIN” identification is determined in accordancewith international standards, procedures and laws.
So, it is possible that a malicious data entry person or insider/outsider/car company can change the identity of a car.
In this way, any country can change someone’s identity. My point here is that this is a kind of "disaster" database design.

Codd, and the authors of OO-approach did not do anything that is relevant to the “history” of events.

Vladimir Odrljin

Thank you George for this information. I think this information is important to those who use the user group to express their opinions, their ideas and their creativity. Also this information is necessary for all professionals from the IT industry who are not "scientists". Probably more should be written on this subject.
Little attention is paid to protecting the intellectual property rights of these large groups of IT professionals. On the other hand, it is enough that some scientists publish a paper, which is the same as the work that has already been done by some IT professional, and the IT professional loses allthe rights in this case.
It took time for me to do serious science. I quit my solid job position andtook lower level, part-time jobs, because it was not possible to work intensively computer science and to be employed full-time at another job. It resulted in a number of other material and non-material consequences. I am writing about this to demonstrate a small fragment of the things that a courtcan never fix.

In my case, I have published my work on my website and this user group, simultaneously. I have paid for my website. My work has been extensively discussed on this user group. At that time, these user groups were being translated into numerous languages. So for my work, there are plenty of witnesses.My results were published four years before the "Anchor Modeling" results.

Anchor Modeling uses a Surrogate Key. In my definition of an identifier of an entity (or relationship), a Surrogate Key is included. That definition states:

“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 at http://www.dbdesign10.com from the year 2005.

In this definition, the second part "... or can provide identification of the entity" refers to a surrogate. But only for those surrogates, that can provide identification of entities.
In fact, my intention with this part of the definition of the identifier ofthe entity, was to identify the relationship. Especially when the relationship is represented via surrogates. This is a much more serious problem, which authors of Anchor modeling have not even noticed.
In my paper, a relationship is, for the first time, defined as an abstract object. I also give a definition of identifiers of abstract objects and a definition of identifiers of states of relationships.

In my complaints to the publishing houses Springer and Elsevier, I stated that the paper Anchor Modeling is incorrect, that it has scandalous theoretical errors and that it uses very important sections from my paper. I showedthe same on this user group. After that, a new version of Anchor Modeling was published. In this new version, my critique and important ideas form mypaper were used to correct certain errors in the paper. As I have indicated in this user group, surrogates can be applied only in very limited cases.
Note that this is a substantial work in computer science, as well as some for other sciences.

Vladimir Odrljin

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”

What is the role of these maritime terms in the theory of databases?
Does anyone know what this is?

Vladimir Odrljin

On Wednesday, October 31, 2012 2:19:19 AM UTC-7, vldm10 wrote:
He is just using it in its everyday metaphoric sense of a rooted base.
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..

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 tothis 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 someparticular 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