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

On 18 Apr 2006 00:35:15 -0700, Neo wrote:

(snip)
>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,

Hi Neo,

Cut the crap! You're comparing apples and gasoline.

NIAM is a method for data modeling - a toolset, consisting of a prescribed way to collect and refine information; a drawing technique for visually representing that information; and techniques to derive an ER model, a Relational Model, a UML class diagram or any of a lot of other models from the finished NIAM diagram. These can then be used to build or generate the database schema.

What you have a storage tool that stores all kinds of data without the need (or even the possibility) to define a schema that the data will and has to adhere to.

Whereas your tool removes both the need and the possibility to define and create a data model, NIAM provides the (IMO) best way to define and create a data model. They are not similar at all - in fact, they are direct opposites!!

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

Don't you read my replies? The Enterprise Architects edition of Visio can generate schemas for many dbs, including (but not limited to) SQL Server, Oracle, DB2, Informix, Sybase, Access, ...

And the freely available Visiomodeler is also able to generate schemas for several dbs (though in most cases only for older versions, so you'll often have to edit the generated DDL scripts).

>> 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
(snip)
>between Person and Mary. When done, the diagram should look similar to
>below:
(SNIP) LOL!!! This is soooooo unbelievably wrong.

John is not an object type. Neither is Mary. Both are object instances, of the same object type: Person.

BTW, a NIAM modeler never starts with circles or rectangles. He or she starts with concrete examples of the information that is of importance to the end users. Those are verbalised. The verbalisations are "disected" (for lack of a better word - English is not my native tongue). After that, the first attempt at diagramming can be made. The diagram will be refined later, when constraints are found.

The end result for the extremely simple case you coined is like this: * In NIAM: http://www.juti.nl/Neo_NIAM.jpg * In ORM: http://www.juti.nl/Neo_ORM.jpg

(BTW, both are incomplete because not all constraints that apply are shown - I couldn't concllude the exact constraints from your example as you have given insufficient information)

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

No. In ORM and NIAM, the circles _represent_ both object types and attributes, and the rectangles _represent_ the relationships between object types or between object type and attribute.

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

Wrong again. In ORM and NIAM, constraints are specified by various symbols. Like the arrow above the rectangle - that's a unicity constraint; the one in the diagram says that it's okay for John to like other people beside Mary, and that it's okay for Mary to be liked byy other people as well - but that it's not okay to represent the fact "John likes Mary" more than once.

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

Again, wrong. Neither ORM nor NIAM represent operators in their diagrams. That's because both are concepptual modeling tools. A conceptual model is a high-level model from the end user's perspective, representing how the end user sees the information. No such thing as datatypes or retrieval methods in the conceptual model. And if a derived fact is important, it is represented (and marked as derived), even though it would generallly be omitted from the date model.

>Now you are going to tell me, that isn't a data model because no
>computer can implement it.

Nonsense. The model translates to a very simple database schema:   CREATE TABLE WhoLikesWho

           (Liker varchar(20) NOT NULL,
            Likee varchar(20) NOT NULL,
            PRIMARY KEY (Liker, Likee)
           )

(In a more realistic example, there would also be a table Persons, and both Liker and Likee would be a foreign key to the Persons table.)

>Below is the script to represent essential parts of the above ORM
(snip)

So xdb stores meta-information aboout an ORM model. No surprise there, since I've already asserted that xdb is a dumpster that stores everything yoou throw at it, without making any attempt to check constraints (and thereby allowing the most insane input, even if it renders all the data in the db worthless).

Best, Hugo Received on Wed Apr 19 2006 - 00:56:47 CEST