Re: Migrating from Hierarchial DB model to RDBMS OR ?

Op donderdag 19 mei 2016 02:16:32 UTC+2 schreef James K. Lowden:
> On Mon, 16 May 2016 13:17:05 -0700 (PDT)
> vldm10 <> 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

Hmmmmmmmm. Just like DB2 or whatever should not be mistaken to "be" the relational model, so should IMS not be mistaken to "be" the hierarchical model (to the extent that any such thing exists).

IMS is a physical-level data recording engine whose prime (if not sole) benefit over its predecessors was that it had commit/rollback. It can accept records presented in bit pattern from clients, and store them, and feed them back in exactly the same form to same or other clients. I'm pretty sure some graph-based systems exist that do not suffer all of the shortcomings you mention.

The hierarchical model is a modeling paradigm stating that all information should be represented as nodes and edges. That per se says very little about particular features/characteristics of implemented versions of it.

As for "chimera", the IDMS system ("network", ergo graph-based) has had an SQL layer since somewhere in the 90's. Proprietary dialect early on, standard-compliant later on. Which means in particular that they have implemented exactly what you said was a chimera : a way for presenting all of their graph-structured data to the user as relations. Received on Fri May 20 2016 - 13:34:37 CEST