«

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.

On Apr 1, 2:07 am, Rich Morin <r...@cfcl.com> wrote:
> 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.

Just a heads-up since feedback from this group would be appreciated:

I've implemented that in my DataMapper project.

RubyForge project (svn access): http://rubyforge.org/projects/datamapper
Blog (with related posts): http://substantiality.net/archives/tags/datamapper

Jochen Theodorou wrote:
> Austin Ziegler schrieb:
> [...]
>> SQL is, at best, an approximation of the relational model and it is
>> generally a failure at that, because SQL doesn't let you think in
>> logical terms more often than not.
>
> say, is there a better way to make queries? I mean one that is in actual
> use in one of the big databases and that is no sql dialect.

Nansen said: `Yes, there is.'

`What is it?' asked the monk.

Nansen replied: `It is not mind, it is not Buddha, it is not things.'

--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

Joel VanderWerf schrieb:
> Jochen Theodorou wrote:
>> Austin Ziegler schrieb:
>> [...]
>>> SQL is, at best, an approximation of the relational model and it is
>>> generally a failure at that, because SQL doesn't let you think in
>>> logical terms more often than not.
>>
>> say, is there a better way to make queries? I mean one that is in
>> actual use in one of the big databases and that is no sql dialect.
>
> Nansen said: `Yes, there is.'
>
> `What is it?' asked the monk.
>
> Nansen replied: `It is not mind, it is not Buddha, it is not things.'

hehe, ok.

bye blackdrag

Sam Smoot wrote:
> Just a heads-up since feedback from this group would be appreciated:
> I've implemented that in my DataMapper project.

(CC'ed into information_modeling - DataMapper is on
RubyForge for those folk).

It looks interesting Sam. I've not got very far into
reading it, but I like what I see. It's not heading
in the same direction as ActiveFacts, but we still
have some goals in common. Perhaps there's some room
for collaboration?

I have a couple of plans for AF that goes somewhat
against the tide of O/RM's, based on my experience
from building a very successful AR-style O/RM in C#:

* I don't believe in dynamic reflection from the DB.
If reflection is needed it should be a manual thing
that yields a schema file of some sort. DB schema
don't have enough scope for documenting the original
intent and conceptual structure - a simple list of
tables, columns, FK's and indexes isn't a sufficient
basis for writing good programs. Instead, the whole
database schema should be generated from a higher-
level schema that *is* properly annotated so that
effective code can be generated, and result sets
have an appropriate structure. (... and I certainly
don't believe you should have to do a relational
schema, an object hierarchy, *and* a set of XML
mapping files, like iBatis for example!)

* I don't believe in fetching whole records, or in
fetching from only a single relation (including a
view) in one operation. Applications too often don't
need that, and it makes lazy programmers who do it
anyhow. Query results should be structured so they
can reflect the sum of all the data that must be
fetched in response to a single user action.

* I think that every row and value fetched should be
traceable back through the query to the schema.
IOW you can look at this value "42" and find out
what the question was . This last goal is a bit
demanding considering with AF, the query is made
against the fact-based schema, translated to one
or more SQL queries, potentially cached into a
stored procedure, processed with parameters into
one or more tabular result sets, then re-assembled
into a graph that reflects the structure of the
original query.

The idea here is that (for example in a Rails context)
you take the parameters from the user's context and
any submitted values, you run one query, and you get
the entire hierarchical result set for rendering the
next view. The result set is structured appropriately
too, so it can be mapped to a view that's dynamic, it
can wrap itself around a number of similar result sets.

If that sounds interesting, lets talk.

Clifford Heath.

On 3/31/07, Austin Ziegler <> wrote:
> On 3/31/07, Rick DeNatale <> wrote:
> > On 3/31/07, Clifford Heath <> wrote:
> >> Yes. Relations are the right way to store data, objects are the right
> >> way to manipulate them, but facts are the right way to conceive of
> >> them, and hence to query them. Both ER and OO schemata are
> >> absorptions of fact-based schemata to suit the physical
> >> characteristics of disk storage and RAM storage/allocation
> >> respectively. IOW they're both derived, to some extent contrived, for
> >> different purposes. Neither can ever be the "one true way".
> > And there's a fundamental tension between the driving ideas of a
> > database and object oriented programming.
>
> I don't think that there's a fundamental tension, but that's just me.
>
> > Databases come from a philosophy of separating data and it's
> > representation from the programs which operate on it. In the case of
> > relational databases, that representation is encapsulated behind an
> > interface defined by SQl.
>
> This is not correct. Fabian Pascal would have a field day with this
> statement. Databases come from a formalization of the need to store
> data.

I think you misinterpret my point.

> Hierarchical databases (and, to a degree, object databases) store
> the data in the same way that the programs which manipulate the data
> represent the data.

I don't believe that this is, in general, true. but let me get back to that.

> Relational databases come from the realisation that more than one
> program needs to work with a given set of data, you don't want to store
> more than one copy of any given datum, and there should be a formal way
> of modelling such things. Thus, you have the Relational Model of Data --
> which, as I have mentioned several times, is a model that represents
> tuples, attributes, and relations that can be queried using relational
> algebra.

I'll refer you to Chris Dates 1975 book "An Introduction to Database
Systems." Which was the bible on database systems to folks of my
generation. Actually I'm looking at the third edition from 1981. The
book covers the relational (using System R as the example),
hierarchical (using IMS/DB), and network (EBTG) approaches.

In the introduction, Date gives the driving reason for databases as
allowing enterprises to put their operational data under centralized
control. He gives a lengthy list of advantages from this reduction in
redundancy, reduction in inconsistency, data can be shared, standards
(various levels of enterprise standards, industry, national and
international), easier data interchange/migration, ability to apply
security restrictions, integrity maintenance, and the ability to
balance conflicting requirements.

These requirements lead to what Date calls an important goal of
database systems, 'data independence.' This is the separation between
the database managment system and the applications which I was talking
about. Data indepence allows applications to have different views of
the data, and to allow a DBA to change the storage structure and/or
access strategy without affecting applications.

The abstract model for this presented by Date is that the architecture
of the system has three levels, in internal storage level, an external
level (which comprises the individual views of the different
applications), and a conceptual level which provides a 'level of
indirection' between the two. This conceptual level is what provides
the encapsulation/information hiding I alluded to. The use of SQL as
the realization of the conceptual level for the relational approach
was just an example.

Maybe I'm just an old fuddy duddy, but this is what I learned as the
defining quality of a database system when I first encountered the
idea in the 1970s.

Object oriented databases back off just a bit from data independence
because they turn the conceptual level into a framework to be fleshed
out by the clients rather than sticking with a standard, and that's
the tension I'm talking about.

Now getting back to your statement:

> Hierarchical databases (and, to a degree, object databases) store
> the data in the same way that the programs which manipulate the data
> represent the data.

This depends on the programs. Some programs are written to look at
data hierarchically, or as a network. Others aren't. In fact the
vast majority of applications written when database systems were
introduced tended to work on sequential (usually sorted) data. Back
then the ideas introduced by systems like IMS and CODASYL DBTG were
actually rather foreign and might be one reason why the relational
approach was widely adopted, the conceptual model looked more like an
extension and formalization of what application developers were
accustomed to back in those days.

It might be hard to see this, but for someone who lived through some
of the revolutions in information technology since the early 1970s,
it's evident. I spent a good part of my career evangelizing
enterprise programmers about object-oriented technologies, so I know
how foreign what we take for granted these days was for the older
folks.

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/