Re: Atomic Structures
Date: Tue, 17 May 2016 04:27:30 -0700 (PDT)
Message-ID: <ce3847f6-2929-4343-89c2-40bb2e75994b_at_googlegroups.com>
Vladimir
I am coming into this a bit late. Let me cut to the chase.
——
1. I reject Codd’s RM/T and his 1971 paper, on the basis that it breaks the Law of Non-Contradiction (it contradicts the RM plus other papers that support it). Now we have 95% of Codd’s work, with the contradicting bits excised. I suggest you do the same.
No surrogates. Real world identifiers only.
Record IDs are not surrogates, they are even worse, a physical record number. (Sure, in SQL a Record ID is “logical”, but it ain’t logical.)
Both surrogates and Record IDs have no Relational integrity, whereas Relational Keys have Relational Integrity (as distinct from Referential Integrity).
I accept that RM/T is not acceptable on theoretical grounds as well.
——
2. I have pure Relational databases only.
That means way, way, beyond that which is written about in books by post-Codd authors. It also means that I have formalised items in the RM, with a full exposition (not given here), that are not mentioned by post-Codd authors.
——
3. I have also formalised Predicates (FOPC) and their usage.
Eg. I have many more of them than you mention (indirectly) or the post-Codd authors are aware of.
——
4. I am not about to redefine the word *Atom*.
You are a bit loose in your use of the term Atom. Eg. you can’t have this kind or that kind of Atom, or a atom plus this and sometimes plus that. You need to define each of those precisely, and name them, and then reference them.
——
5. I don’t have any problem with *Type*.
Most of what you say is quite agreeable. A proper classification of Types are essential, long before you get to entities/tables.
I do not accept that Codd is unclear about Types (he calls them Domains, but uses that word in many contexts).
——
6. My *Atom* is a Relational Key.
Not only a simple one, compound keys are normal fare for Relational databases. This is Existence, Identity. If it does not have this, it does not exist. All things other than this, are based on this.
(Compound keys do not break 1NF, each component of the key must be 1NF.) You could say, my Atoms are non-simple.
The Atom *IS* the Entity. The Entity *IS* the Key. The Key *IS* the Atom.
Existence is of two kinds.
6.a. Independent
The Atom exists without relation to anything else.
6.b. Dependent
The Atom exists only in relation to a parent Atom. In Relational terms, this means it is Identified by the parent Atom (Key).
Eg. Country is independent. State is dependent on Country, it exists only in the context of a Country. The notion of a Sate without a Country is absurd (does not match the natural universe which the UoD is a subset of).
Now we can have Atoms plus something.
——
7. Atom plus Attribute.
An Attribute is a non-key domain (Type, column); a key is not an attribute. (Note, you are not clear about this point, and it gets you into trouble, long explanations, etc.)
Each Attribute is a Descriptor of the Key (Atom).
Mandatory Attributes are placed in the same row as the Key, 5NF.
Optional Attributes are placed in a separate table (“6NF”), the key of which is the same as the Atom.
——
8. Atom plus Relation.
A relation to any other Atom. A binary relation.
Each of which is a separate table, the key of which is the compound of the two parent keys. Thus these should be viewed as Compound Atoms.
The Compound Atom may have Attributes which are Descriptors of the relation. Usually just one, because it describes the nature of the relation. That one Attribute is Mandatory, and the rest are Optional Attributes, in a separate table.
Ternary relations are not allowed.
Therefore, I have three Atomic Structures [6][7][8].
——
9. Predicate
> A particular problem was to work with atomic structures and the
corresponding theory to identifiers. Note that the atomic structures imply
atomic propositions in logic and atomic predicates in logic. The special
question is about atomic concepts. I will only mention some facts regarding
the concepts. Concepts are related to Theory of Mind, Frege's set theory is
based on the concepts and also the theory of predicates. From Frege's
definition of the concepts and its extensions can be derived first two
axioms of set theory (called comprehension and extensionality for sets).
I agree, totally.
As stated in my previous post, I have formalised the Predicates required, plus Inten[s]ion and Extension. And they work easily, because the Atomic Structures are defined. That is the part of Logical that is way beyond the post-Codd authors. If you email me, I will give you a few pages.
Note, the pig-poop-eaters have their own private definition of “extension”, in order to (a) subvert the use of the real thing, so that (b) their students, ignorant of the real ting, will be happy with their pig-poop. What passes for “education” in “universities” these days is sad, very sad.
——
10.
> I would like to put this topic on the discussion because it has never been
> seriously analyzed in this group. The theme is one of the most important,
> because Atomic structures provide a variety of important solutions for
> databases. Atomic structures are also of great importance in some other
> areas, such as the atomic propositions and atomic predicate, they are also
> related to atomic concepts and atomic facts.
I would state that differently.
Atoms; Atomic Structures; and Predicates are all integrated, they are different forms of expression of one concept, FOPC.
They are not merely to “provide a variety of important solutions”, they should be the foundation of every database.
The problem is, people work from the data that they know, so that it is backwards, and the Atoms have no Form, and thus the Atomic Structures also. The foundation is missing.
Whereas I work forwards, from the Predicates, downwards, and only create Atoms and Atomic Structures, which have definitive Forms. Thus they are the foundation of every database I write.
——
11. Temporal Database
Your General database. These are pedestrian these days. All my databases allow generation of data AS AT a date and time.
First a word of warning, if you get into the Date, Darwen, Fagin, etc (not et al) methods you will be confused, because they eat pig poop, and they write about the marvels of pig poop, not about temporal databases. Their latest method involves implementation of a matrix, and turns 2010’s SQL developers into 1960’s Assembler programmers.
Codd has given the perfect, the ultimate key for temporal databases, in the RM (search for “generation”).
> In RM/T there is no some theory about maintaining "history". E. Codd did not
even mention the "history" in his paper RM / T.
He gave it in the RM. “History” = “generation” = temporal.
In the modelling arena that applies to [7] and translates to: — place each Attribute in a separate table (“6NF”) — the key is the key of the Atom, plus a DateTime column (or generation number)
This applies to [6]:
— Add one Attribute that states the currency of the Key (Atom), an Indicator eg. IsObsolete.
This is also called a Soft Delete. The idea is, all joins continue to work, but rows that are IsObsolete are excluded from drop-downs, etc, and therefore cannot be used to create transactions. Delete and Update are not permitted for historic tables.
That is probably your “event”.
——
12.
> Is a byte atomic? Note that a byte can be considered an 8-tuple of bits.
Only by an idiot. Or an Assembler programmer.
——
13. “History”
In my neck of the woods, high-end banking systems, it is standard practice to have
— UserId
— UpdatedDateTime
in every row. If the table is temporal, the latter doubles as a component of the key. Codd didn’t need to state that.
For online databases, we might have:
— IPAddress
— Longitude
— Lattitude
——
14. Anchor Modelling
I have previously answered your post on this subject. AFAIC, AM is:
- RM/T plus a few bits and pieces.
— It does use surrogates.
— It has no Relational Integrity.
— They are clueless re Predicates
It is primitive, in comparison to my Atoms and Atomic Structures.
——
15.
> Although B. Russell introduced the theory of types
Nonsense. Aristotle did, in 350 BC. Also Sets. His volume is /Categories/.
Aristotle invented Formal Logic, Propositional Logic, and Predicates. 2,200 years before Frege. The volume is /Metaphysics/.
——
16.
> Finally, regarding the types I would recommend the work of Suad Alagic and
Philip A. Bernstein (I wrote the above web address of their paper) that
discusses the problem of mismatch between the (data) type systems during
schema mapping between two data models
The papers are pure garbage.
Type mismatch is the easiest problem to eliminate. Just use a correct set of DataTypes, in every code segment. Only idiots suffer type mismatch problems.
Same with refactoring. It is evidence that the database isn’t a database, it is a data storage location for persistence of RECORDS, the structure of which is forever changing, due to the (gee whiz) changing Object definitions. Imbeciles. Data, if treated as data, independently, does not change in structure. (Added to, yes, which does not afeect code, but changed, no.)
——
16.
> According to C. Date, the best definition of the relational model, has given
by E. Codd in his paper RM / T.
That is because Date & Darwen and the other freaks subvert the RM, that is their purpose. The RM/T and surrogates is all they understand. The result of reading their books is, you will implement a 1960’s style ISAM Record Filing System. Pre-Relational. Pre-Hierarchical. They implement precisely what an undamaged human has excised, the waste matter, they feed on excreta.
The only definition of the RM is the RM.
——
17.
> In the architectural drawing(model) we have simple mathematics, mostly we
apply geometry. In the the relational model, we have a very complex mathematics.
I disagree. In the RM we have simple mathematics.
The idiots on this newsgroup make it very complex, yes, but then idiots make anything complex. That is why they cannot build anything, such as a database or a house.
——
18.
> Relationship must not be just between the two entities. Relationships may be
between 2, 3, or in general case between n entities. Note also that in some
relationsihps may participate in another relarionship.
That is incorrect. That means your data model is very primitive, unresolved. Codd states that every “complex” relationship can be resolved into a series of binary relations.
——
19.
> AmountKey Amount
116 $2000.00
Stop confusing yourself. Use precise and meaningful labels. A RECORD ID is not a key, it has none of the qualities of a key, so do not call it a Key. A key is not a surrogate or record ID, it has qualities that a surrogate or record ID do not have.
> (AmountKey, Amount, Date1, Date2, Operator1, Date3, Date4, Operator2).
Ditto. The dates and their purpose is lost. Hopeless example.
——
20.
> RM / T and 6NF do not have theoretical significance.
Agreed.
——
21.
> The theory of atomic data structures is done and presented only by my
solutions.
That is incorrect. Others have come to the same or similar comclusions decades before you. Eg. I have, based on Codd’s work. My Atoms are one; my Atomic Structures are fewer than yours, and absent the complexity of yours (due to yours being unresolved; n-ary, etc).
> These solutions are correct solutions. When I say correct solutions, then I
think that these solutions are both theoretically and practically correct
and effective.
That is not a proof. Ok, it may be in Modernist times. I am pre-Modern, I am quite happy with Aristotle. The Law of Sufficient Proof requires proof outside the concept. This is a self-referential “proof”, and with no implementation to test it.
——
22.
> The second thing was consequence of a much deeper problem. This problem, in
short can be presented as follows.
People have always held that a name denotes a certain entity, although this
entity has been changed many times. But the following problem has always
existed: How an entity which has changed to another entity is, in fact, the
same entity.
First let me say that I don’t have the complexity around States that you have. States are already implemented in my Atomic Structures, without added complexity to support States.
The “problem” of a entity changing into another entity, is not a problem for me. It may be good to understand the problem in the context of my Atomic Structures. The list of Attributes simply changes over time. No big deal.
Separately, if the Key changes in structure, then the entity itself has has changed drastically, its IDENTITY has changed, the Atom has changed. In that case, the Atom is defunct, and a new Atom is created. In the practical order, the contents of teh tables will be transformed and loaded into the new tables. Still, no big deal.
——
23.
> (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).
If you use Relational Keys, [1] is eliminated.
If you resolve your n-ary relations into binaries, [2] is simplified.
If you get clear on your notion of States [22], your number of Atomic Structures will be reduced.
If you use simpler Atoms and Atomic Structures, [2] is simpler still.
> I believe that the reason complex databases and databases of a general
character have not been solved until now is because no one came up with that
in part (a).
Well, little old me came up with it, and a much simpler one, three decades ago. AN dit has had three decades of implementation in high-end OLTP+OLAP systems.
——
24. Identifier
My Identifiers are Keys, as previiously discussed.
> Roughly speaking, the identification I defined recursively:
(i) attributes are identifiers.
(ii) entities are constructed from attributes (therefore the identification
of an entity is determined by using identification of entities'
attributes.
(iii) relationships are constructed from the the entities or from known
relationships...
(iv) By using my theory of identification, I gave the solution Russell's paradox. Very roughly speaking I solved Russell paradox by using two constructions. One of these construction is a "concept" and the other is the "identification".
[i] No. A column is either a Key or Attribute. Of course before the key is chosen, all columns pertaining to an Atom are Attributes, but after the election, the Key columns are no longer called attributes.
— In my model —
[i] Identifiers are Relational Keys, not surrogates, not Record IDs.
[ii] Entities are composed from its Atom, plus the Atomic Structures for that entity.
[iii] Relationships are not constructed. They exist, in Atom+Relation tables. They are simply re-composed.
[iv] The theory I use for Identification is first Aristotle, and second FOPC, as defined by Codd, which works perfectly for me, with no gaps. I had some understanding of Godel and Frege, and much more re Boole and Hamilton, but I viewed them as in-between, and not completely articulated until Codd. I can’t stand Russell and other Modernists, I don’t suffer the Russell paradox, so there is nothing to fix.
——
25.
> If the matter is based only on the concept, then it is possible to construct
a paradox. In short, the construction of the set depends not only on
"conceptual thinking", it also depends on our capacity to identify
individual objects.
That, my dear sir, is precisely why you need a real Key, and not a surrogate or Record ID.
For the life of me, I do not understand how you can have so much deep understanding of database theory, and still be stuck in the caveman era of surrogates and Record IDs, which prevent the use of said theory.
——
26.
> The future is stored in the database as follows: The
database keeps a set of programs. More precisely databases keeps the states
of programs. By execution of a state of a program we implement the
corresponding future state.
Nah. There is a simpler method, no programs required. Use Views. One View for each entity, for each change-of-structure. These days we have no control of who uses the database, and of which version of program they will use. The current state of an entity may be version 123, they may be using any version from say 100 to 123.
- I agree, the SNO implementation is wrong, because Date is stupid. You will find more stupidity in his books.
As a general, overall note, I would say:
- Back off from criticising Codd, and instead, try to understand his work.
Do *not* try to understand his work from any post-Codd authors books, they are confused, and they expose only 5% of the RM. Read only Codd.
His paper is about the RM. He was not required to define how to design databases, etc (as the freaks expect, and thus say it is “incomplete”).
b. Stop using the term “6NF”, because as you have posted previously, it is not an NF. Or else, write a NF definition that is useful.
“6NF” is not something that you apply, to solve a problem. It is an implementation, after you have solved the problem.
c. I am quite busy, please do not expect daily responses.
Cheers
Derek
Received on Tue May 17 2016 - 13:27:30 CEST