IDIOT! Your Data Model Can't Possibly Work!

This is so funny! Bob, for half a decade you have been telling me that my data model couldn't possibly work, that I didn't have this or that operator, or this or that predicate, didn't attend this or that college, or have this or that experience; yet NIAM/ORM as explained at http://essentialstrategies.com/publications/modeling/niam.htm has quite a few similarities to mine! Actually mine is more general! Now I had been using my own terminology to describe pretty much the same things but you called me an IDIOT! When I first described objects, the type of object I was referring to is what ORM refers to as objects! But you told me I couldn't use that term since it already meant code+data as defined by object-oriented programming. So I changed from objects to things. And because I don't have a control that can display circles and boxes with line between them, I display the same information in a tree and you railed that I was reinventing the hierarchal data model! I told you it was similar to a network of nodes. You railed that I was reinventing the network data model! But if you look at the diagram on the above NIAM/ORM web page, the network I was referring to is very similar to that formed by the various circles and squares with lines between them! What I have described as types/classes, ORM refers to as domains. What I have described as a thing with multiple classes, ORM refers to as SubTyping. When I talked about recursion and that properties and values can themselves have their own properties and values and so on, is what ORM refers to as "nested fact types". What I have described as verbs, ORM refers to as Roles. What I have described as things can have bi-directional or multiple relationships, ORM describes as entities can have binary, tertiary and higher order roles. Albeit, there are differences. For example, ORM has standardized methods to specify common constriants that are not part of my data model, but none of which that can't be represented as data.

In fact I can use the experimental db to store the data (at least the part that I can understand) in the shown ORM diagram in a normalized and NULL-less manner and doesn't ever require the user to specify a schema, normalize data, or worry about IDs and referential integrity. Is there another tool that does similar? Does that tool store the data in a RMDB? If so, I assert that it won't be as flexible. Would you or someone be willing to demonstrate it here and compare it with the experimental db? Received on Sat Apr 15 2006 - 16:54:43 CEST