Cross-posted and followups to information_modeling from
ruby-talk.

Rich Morin wrote:
> I'm a big fan of ORM2 (The current name for the ORM effort).

Hooray - someone else! ORM2 is a minor redrawing of the
graphical symbols for ORM, I'm not aware of any semantic
changes. And though the current mapper is relational,
there's no good reason not to do UML and other kinds of
artifacts from it.

Where did you come across ORM?
Did you study at Neumont/Northface?

> I'm not a database wonk, but I play around a lot with graph-
> based data structures, and ORM2 fits my needs very well.  I
> would like to mention 2.5 other technologies that I'm hoping
> to tie together with ORM2, Ruby, and Rails.

>   *  Conceptual Graphs (Dr. John Sowa, et al)
>      Although CGs use a different notation than ORM2, both
>      systems describe hypergraphs (graphs in which edges
>      may have more than two endpoints: "John took the train
>      to Chicago").  While ORM2 maps nicely into relational
>      DBs, CG maps nicely into predicate calculus.

Well, ORM has ternary and higher-order facts, but each
fact role connector has exactly two ends. The NORMA mapper
maps higher-order facts to binary ones before absorption,
which is strictly unnecessary, but simplified the XSLT
approach they were using before LiveOIAL foiled it.
The point is that you have objects types (entity, value
and nested types) and you have fact types with one or
more roles - each role is a 2-ended connector from a
fact type to an object type.

>   *  Ruby Graph Library   (RGL; Horst Duchene)
>      GRAph Theory in Ruby (GRATR; Shawn Garbett)
>      The basic idea in RGL and GRATR is a mapping between
>      graph nodes and objects.

I don't see why the objects couldn't *be* graph nodes.
You could re-open the Object class to add the required
single attr_accessor. But anyhow, you're saying that's
not what they do, and that's ok too.

> It seems to me (SciFi alert) that it should be possible to:

I'm not a graph theorist, though I studied it once, but what
you're suggesting sounds quite reasonable.

> One problem I see with using AR join tables for relationships
> is that there seems to be a presumption that there is only a
> single reason why a set of tables would be joined.  So, "Rich
> drives a Camry" and "Rich owns a Camry" live in cars_people.
> My working plan is to use a "type" field (ala STI) in each
> join table to disambiguate these cases.  Not pretty, however.

Ouch... I thought you could do this properly using has_many_through?
That said, I haven't tried it.

> Another problem is that (apparently) AR doesn't support join
> tables with more than two columns.  Given that I need hyper-
> edges, this loses badly.  So, it looks like I need some model
> (e.g., acts as) code...

I'll post my relational meta-model for ORM 2 shortly, in
the Yahoo group. It can represent (almost?) everything that
NORMA is capable of representing, and it maps to the object
hierarchy I've defined in Ruby that can already load NORMA
diagrams (though not yet constraints). This relational model
should work with AR with minimal changes, so you can use it
for your purposes.

> At 1:30 PM +0900 4/1/07, Clifford Heath wrote:
>> The most recent is an open source plugin for Visual Studio
>> called NORMA, .... Talk
>> about an iceberg in hell! This thing is already *way* cool.
>>...
>> The remaining problem is that the existing tools are only
>> design tools, that generate database schemata and static
>> data layers.
> There's also the slight problem that NORMA requires Visual
> Studio, C#, M$Windows, etc.

Well, I *did* say NORMA is an iceberg in hell :-).
But both Terry and I are, with others, keen to define
a textual language for ORM, and I'll implement that in
Ruby, or even sooner, a Ruby DSL for ORM, which I've
started. So there'll be no need for a visual tool.

> I'd be happy to be part of the discussion.

Great to have your interest, and thanks for joining
the Yahoo group. It only has a few people yet, but
it's only two weeks old too.

Clifford Heath.