Re: Migrating from Hierarchial DB model to RDBMS OR ?

On Mon, 16 May 2016 13:17:05 -0700 (PDT) vldm10 <vldm10_at_yahoo.com> wrote:

> > Please note XML is Hierarchial as well but not sure how different
> > it is from IMS
>
>
> I would like to mention that this post is one of the most serious
> issues and problems in DB theory.

I doubt it. You say serious; I say chimera.

> 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.

No general transformation is possible. Any data can be modelled relationally. That they have some hierchical representation just provides a starting point.

As it happens I've had cause lately to investigate IMS. c.d.t readers might not know how little it resembles a SQL DBMS:

1. IMS reserves a "segment" as a key-value store. The value need not be, unless it is a searchable term. The key is known to IMS as a single field, however the application may interpret it.
2. The "key" need not be unique. A search returns the first of N. To find the nth element (as with Berkeley DB) one iterates n times.
3. A segment need not have a single definition. Different element may have different interpretations, depending on a discriminator field (that may or may not be defined to IMS).
4. Fields may repeat, and be of varying lengths, and may be defined as nested within other fields. Every violation of normal forms you can imagine is fully supported. The query language offers no generalized support for these structures.
5. There is nothing resembling a CHECK constraint in SQL. There is a small amount of what might be seen as foreign key enforcement.

Any comparison to the relational model is purely specious. It is not a model. It lacks a basic datatype (analogous to relations), an algebra, and constraint enforcement.

Why would anyone use it, then? How is it IBM continues to sell IMS?

There still exist applications for which the services and features provided by SQL are not needed. If you have a record-keeping system for which the requirements are quite static and the data volumes very high, what need is there for predicate enforcement in the DBMS? If the rules are already enforced and the access patterns already established, why incur the overhead of dynamic storage allocation and location independence? Why "interpret a query" when you can just fetch a record by its key?

These are two different systems. Codd recognized that the power of mathematics would make database management more tractable and rational. He understood that not all data processing need be pure record-keeping. He invented an alternative, and was proved right. But the thing he invented was utterly, completely different. Any comparison risks pure sophistry.

--jkl Received on Thu May 19 2016 - 02:16:26 CEST