Re: IDJIT! Your Data Model Can't Posssibly Work!

From: Neo <neo55592_at_hotmail.com>
Date: 18 Apr 2006 00:35:15 -0700
Message-ID: <1145345715.498938.232550_at_t31g2000cwb.googlegroups.com>

> Bob: ORM is not a data model. Jay Dee observed that you were attacking a straw man by addressing entities and attributes instead of addressing sound conceptual modelling.

:) Actually, Jay Dee made no such observation and I was attacking no such straw man. Go back and review the posts in the original thread titled "Multiplicity, Change and MV". I summarize below:

In the original thread, OP's asked - how to avoid the headaches caused by changes to db schema, data, queries, code and GUI as a result of changes in application requirements after specifications were given, schema designed, code written, GUI developed and data entered. It wasn't a matter of improperly designing the schema initially. New speficiations now require a relation's attribute to have multiple values instead of just one.

I responded to the OP that to handle the unexpected in RM (without incurring NULLs), he needed to use some level of generic modelling (ie T_Thing, T_Attrib, T_Value, etc) but this quickly becomes impractical. I also asserted that his situation wouldn't result in any schema changes in the experimental db as none is ever required (yet the data is fully "normalized" and queryable).

Jay Dee responded to OP (not me), that the situation was the consequence of the approach to database design. And Jay Dee stated that the most resilient designs are those which accurately represent data, not relationships and he found Halpern's ORM approach to be helpful.

Upon reading Jay Dee's response, I knew ORM wasn't applicable to OP's situation because:
1) OP's situation was not caused by poor database design, but by changes in project requirements after implementation. 2) I vaguely knew that ORM was some sort of modelling tool involving diagrams.

So I asked Jay Dee, if he (or someone else) would be willing to demonstrate this resiliency starting with the OP's simple example and then extending a bit further :) In my book, the best way to prove something is to actually demonstrate it rather than conduct endless debates (much like the ones whether my data model can possibly work).

Now this is where you responded to me and said, NIAM, nijssen and halpin: They set the reference point for conceptual modelling about 20 years ago. Since that time, I have seen nothing I would consider a groundshaking improvement; although, Jan or Vadim might ...

Although I knew you were oblivious to the fact that Jay Dee's suggestion didn't apply to OP's situation, I decided to Google NIAM anyways to see why two persons in a row would recommend it.

Now the funny part is, NIAM which both of you speak so highly of and is only being used to do "conceptual" modelling has similarities to my data model (mine is still more general/flexible) which is already implemented in the experimental db, instead something like VISO, which is mostly just drawing labelled boxes and lines and probably can't even generate schemas for any dbs including RM. When you look at an ORM diagram it is mostly implemented in your mind and that is why you think it is so powerful. But the experimental db can actually implement whatever one draws in ORM directly in the db (doesn't matter if the diagram is modelling general characteristics of a set of data or actual data) in normalized manner and can query/maninpulate it. See example later.

> Bob: ORM is not a data model.

:) I am now going to prove you wrong using a very simple example.

First draw a diagram that models John likes Mary similar to the one at http://essentialstrategies.com/publications/modeling/niam.htm . Draw two circles. Label the left one John. Label right one Mary. Draw a rectangular box between the John and Mary. Split rectangle in two halfs by drawing a vertical line. Label left half "likes". Label right half "isLikedBy". Connect a line between John and left side of rectangle. Connect a line between right half of rectangle to Mary. Near top of diagram draw a circle labelled Person. Between Person and John draw another box with instance/class and draw appropriate lines. Do the same between Person and Mary. When done, the diagram should look similar to below:

                   Person
                  |           |
         instance       instance
      ----------------     ------------------
     class                        class
     |                                     |

John ---- likes | isLikedBy ---- Mary

Not only is the above a data model, but has data to model. According to Codd: A data model has following:
1) A collection of object types, which form the basic buiding blocks. In ORM, the basic ones are circles, boxes, lines and labels. 2) A collection of general integrity rules about object types: In ORM, the basic ones are boxes go between circles, lines connect between circles and boxes, labels go inside circles and boxes, etc. 3) A collection of operators can be applied to objects for retrieval, etc: In ORM, look at various labels in circles to find desired object, to get what a circles relates to follow line to first side of box, read relationship, then follow line on opposite side of box until you get to other circle, etc.

Now you are going to tell me, that isn't a data model because no computer can implement it. I know of two. First, the one between your ears. Second, the experimental db.

Below is the script to represent essential parts of the above ORM diagram in the experimental db and perform some queries, thus showing not only that ORM is a data model, can model actual data, but is actually implementable in the experimental db.

// Create verb likes.
// Note: Db already has class/instance.
// Note: Verbs are classified in ORM diagram, but I do.

(create (new) name (findElseAdd name instance 'likes'))
(create verb instance likes)
(create likes class verb)

// Create verb isLikedBy.
(create (new) name (findElseAdd name instance 'isLikedBy'))
(create verb instance isLikedBy)
(create isLikedBy class verb)

// Create type person.
(create (new) name (findElseAdd name instance 'person'))
(create type instance person)

// Create a person named John.
(create (new) name (findElseAdd name instance 'John'))
(create John class person)
(create person instance John)

// Create a person named Mary.
(create (new) name (findElseAdd name instance 'Mary'))
(create Mary class person)
(create person instance Mary)

// Create John likes Mary.
(create John likes Mary)

// Create Mary isLikedBy John.
(create Mary isLikedBy John)

// Find person instances.
// Displays John then Mary.
(msgbox (select person instance *))

// Find what John likes.
// Displays Mary.
(msgbox (select John likes *))

// Find Mary isLikedBy what.
// Displays John.
(msgbox (select Mary isLikedBy *))

// Find the class of the thing that John likes. // Displays person.
(msgbox (select (select John likes *) class *))

// Find a person who isLikedBy another person. // Displays John.
(msgbox (and (select person instance *)

                     (select (select person instance *) isLikedBy *)
              )

)

If the db exe had a graphics control that could display circles, lines and boxes it would similar to original diagram or in Visio. While the db exe does not have a such a graphic control, it can display equivalent info in tree (a portion shown below):

Type
  -instance-

     Verb
        -instance-
            Likes
            IsLikedBy
     Person
        -instance-
           John
              -class-
                 Person+
              -likes-
                 Mary+
           Mary
              -class-
                 Person+
              -isLikedBy-
                 John+

I am able to email you a small zip file (200Kb, 1/7th of a floppy) for verification, if requested. It contains the script to create db, db file and db executable. The program requires no installation. Just double-click to run. Throw in trash when done. Received on Tue Apr 18 2006 - 09:35:15 CEST