Re: Atomic Structures

Vladimir

I have moved a post from another thread, in order to avoid hijacking that thread, and because this is an important subject, already established under this thread.

On Tuesday, 17 May 2016 06:17:06 UTC+10, vldm10 wrote:
>
> I would like to mention that this post is one of the most serious issues and
> problems in DB theory. This topic has the following name: Mapping one data
> model into another data model.
> Related to this problem, I gave my solution for this problem. Roughly
> speaking my solution consists of the following: these data models should be
> presented with corresponding atomic structures. When we have atomic
> structures of these two data models, then it is easy to construct the
> mapping between these atomic structures.
> My solution assumes that the corresponding conceptual model is solved also
> by using atomic structures. My solution can be found on my website
> http://www.dbdesign11.com
>
> As far as I know this is the only complete solution to the problem of the
> mapping between two data models. In case you are interested in my solution,
> feel free to ask me that what you are interested, I will try to answer.
>
> Notice also, that other solutions that use two data models are wrong and
> therefore illegal. Here I think primarily on mapping from some data model
> into relational model. Also mapping from ER model into relational model is
> illegal. For example, Codd introduced "entity type" to make a "bridge"
> between ER model and the relational model. Of course "entity type" does not
> solve the mapping between two data models, at all. C. Date also uses this
> "technique" by applying "entity type".

In sum, I agree with you. But you and I have arrived at that (those?) conclusions via different paths, therefore each of us would express it differently.

1. I reject the notion of conceptual vs logical vs physical models. I have only one model. In the early days, it is conceptual, as it progresses it is logical /to various degrees of Logical/, and close to implementation, with very little work, that is based on the platform, it is physical.

Therefore there is no mapping to be done.

Conceptual/logical/physical are merely renderings of one model, showing some chosen amount of detail.

ERwin is the only data modelling tool that implements the one-model concept. All the others have duplicate models; mapping; time wasting; hair pulling, and of course, all the errors that result.

2. Further, there are physical aspects in the logical phases. If one ignores them (on the schizophrenic notion that theory is divorced from application), the data base suffers.

3. The highest level of modelling data is (agreed) atomic. So what are those atomic structures, what are those atoms ?

• Predicates (FOPC) --

  ---

Since the RM is founded on FOPC, it is completely stupid to model a database without reference to Predicates.

Thus all the books written by post-Codd authors are completely stupid, at least in this regard, because they have no idea re Predicates, they give no chapters on how to use them. The foundation is missing. So the house that is built may be of bricks, but it will have the strength and duration of straw.

(They are stupid for other reasons /as well/ which I have posted about in these pages.)

In all cases, the data model exposes the Predicates, and the Predicates verify the data model. It is a very important feedback loop.

To someone who is new to this concept, I would say: -- If your Predicates are not completely defined, you do not have a Relational database. They are working somewhere in the middle, I would raise their sights, and make the whole task easier.

To someone who is used to this concept, I would say: -- model the data from the Predicates, downward. They are working at the top, down, so I would ensure they have the top identified correctly.

I don't know what your atoms are, but my atoms do not ever need mapping.

4. Now one dirty great caveat here is, in the literature, the notion of "logical" isn't. The pseudo-theoreticians, the pig-poop-eaters, have established a pathetic notion of "logical", that is limited to their rodent-sized crania. Logical is much more than that.

You have to draw all the Logical elements out of the Relational Model (the original Codd paper, not the hysterical 42 or so "algebras", not the books that allege to be about the RM), and create methods for implementing them. Then formalise those methods. That includes Normal Forms (real ones, not the 17 or so fragments of pig poop that "theoreticians", "mathematicians", and "poofessors" use and teach these days). I already have a complete set of Methods and NFs, matured over four decades of implementations.

5. Now if you understand that, there is no mapping from one type of data model to another. Because the root of each type of data model, should be Predicates, FOPC.

Cheers
Derek Received on Tue May 17 2016 - 08:49:17 CEST