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

On 15 Apr 2006 21:59:06 -0700, Neo wrote:

(snip)
>But the intent of your statement is correct. I know very little about
>NIAM/ORM. In fact, currently it is limited to that described on the
>referenced web page. (If someone can point me to a better summary,
>please post it)

Hi Neo,

For ORM, start at www.orm.net. Or google for "Obejct Role Modeling" + "Terry Halpin". Or buy Terry Halpin's book: "Information Modeling and Relational Databases".

For NIAM, I've never been able to find any good descriptions on the Internet. And that's a shame, because I do believe NIAM to be slightly better than ORM - not just because the NIAM diagrams carry more meaning than the ORM diagram, but mainly because the methods to find out the model are better fleshed out in the NIAM methods.

If you're able to read Dutch, get a copy of "Universele Informatiekunde" by prof dr ir G.M. Nijssen. It's never been translated and it's allsoo out of print, so you need luck hunting one down (and I wouldn't give you my copy, even if you offered $1,000 for it). Though the book is laden with lots of small mistakes, it's the best resource for NIAM to date.

Finally, for FCO-IM, you'll find even less information. FCO-IM is a recent spin-off of NIAM. You may find some info on FCO-IM at http://www.casetalk.com/php/.

>
>> ORM, NIAM, FCO-IM, ... are all methods that are _specifically designed_ to specify a schema ...
>
>Well that's a bummer.
(snip)
> if you are telling me
>that ORM is specifically for modelling schemas,

Seeing back this quote, I realize I was telling only part of the truth. I'm a database worker, I replied from a database-centric view.

ORM, NIAM, and FCO-IM are methods for conceptual modeling. A conceptual model can easily be transformed to a data model, but it actually is more. To wit, G.M. Nijssen (one of the founding fathers of this line of modeling) has now abolished NIAM and moved on to "Kenniskunde" ("knowledge engineering" [??]) - it turned out that he only had to make some minor changes to the foundations of NIAM to get a working model for knowledge enigineering.

> it doesn't seem to
>be as general as mine which can model almost anything, including
>schemas;

I have yet to encounter a situatiuon that could not be modeled in NIAM.

> Now I realize more clearly what that is. I wondered how anybody
>was going to implement ORM.

ORM has already been implemented. Years ago, there was a tool called "Infomodeler". This tool was acquired by Visio and renamed Visiomodeler. Later, Microsoft bought Visio and incorporated the ORM support in Microsoft Office Visio for Enterprise Architects. They also released an unsupported version of Visiomodeler as a free download. http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=27FE6786-A439-4286-B8B6-7A9B84CFA709

There's also a new tool (NORMA) in development: http://sourceforge.net/projects/orm.

For FCO-IM, there are two tools: CaseTalk and Infagon: http://www.casetalk.com/php/index.php
http://www.mattic.com/category.html?identifier=inf_introduction

There are no publicly available tools for NIAM yet. But we are working on it.

>So now I am asserting that my data model is not only the most general
>method for representing things

I'm sorry, but you have no data model at all. A data model, by definition, is a description of how the business data should look. This implies that everything that looks differently shoould be rejected.

Your experimental database is just a dumpster that accepts everything thrown at it. As it never rejects any data, it obviously has no constraints and no predefined structure. Ergo, no data model.

> It is only a guess (someone educate me), but I bet they are
>having difficulties actually modelling things on computers the way ORM
>models them in its diagrams, especially if RM is being used to
>implement it. So when you say ORM is a method that specifies a schema
>(with more precision and accuracy than any other method), normalize the
>data, and maintains referential and other integrity, this is in great
>part due to your mind and probably not completely achieved on computer
>hardware at this time.

BS. Both books I mentioned in this message describe exactly the steps one must take to transform an ORM or NIAM diagram to a relational design in optimal normal form. At least four of the tools mentioned above will carry out this procedure on request (the others probably do so too, but I've never tried them so I can't tell for sure).

>
>Actually, I believe you are wrong that ORM is just a method of
>specifying schemas,

Maybe you are confused about which ORM I am talking about?

For me, ORM stands first and foremost for "Object Role Modeling" For many people, ORM is the abbreviation for "Object-Relational Modeling"
And a recent thread in this group introduced ORM as a short form for "the OverRelational Manifesto" (sic)

(snip)
> that whatever ORM can model in its diagrams I can
>actually model in the db

I don't doubt for a single secoond that you're ablle to enter any information that adheres to any ORM model someone can perceive in your experimental db - after all, your db is just a dumpster that accepts everything thrown at it.

The point is: I (and many other people) don't WANT a db that happily accepts any input - my customers expect any application I write for them to beep annd show an error message when inconsistant information is being entered. I need a model for that - and for many reasons I won't divulge here, I have a strong preference for using NIAM as my modeling method.

Best, Hugo Received on Mon Apr 17 2006 - 00:38:38 CEST