At 1:30 PM +0900 4/1/07, Clifford Heath wrote: > The only solution is a system that enables us to completely > hide the physical layer from the user (from the queries), > and that's what fact-based modeling can do. The details of > how are contained in Terry Halpin's book "Information > Modeling and Relational Databases", and are implemented in > at least four significant database design tools, three of > which he designed (the other is CaseTalk, www.casetalk.com). > The most recent is an open source plugin for Visual Studio > called NORMA, which is available as a CTP as the "orm" > project at <http://sourceforge.net/projects/orm/>. Talk > about an iceberg in hell! This thing is already *way* cool. > I'm visiting the team (which Terry leads) for two days in > May before the Rails conference. I'm a big fan of ORM2 (The current name for the ORM effort). 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. * 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. This lets you, for example, ask a node about its neighbors, forward messages to them, etc. It seems to me (SciFi alert) that it should be possible to: * extend RGL/GRATR to have both nodes and edges as objects, such that you can ask an edge about the objects it links * back the resulting graph by an ORM2-style database (this would let me ask cross-graph questions such as "which As have a B relationship with Cs"). * send links (predicates) to a KR system (e.g., PowerLoom) In fact, I've been musing about how close Active Record is to being able to support a subset of this scheme. Consequently, I found your posting _quite_ interesting. 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. The discussion in http://wiki.rubyonrails.org/rails/pages/ManytoManyPolymorphicAssociations hints at some of the difficulties with this approach. 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... > 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. > What's needed in addition is a flexible runtime > and query processor, written in a dynamic language, and it's > to create such an animal that I registered the ActiveFacts > project on RubyForge. There's no content there yet (sorry > Christian), but if anyone who's willing to do the background > study, they're welcome to help out. I hang out on the new > Yahoo group "information_modeling", and need folk to discuss > ActiveFacts with while I develop it to the point where I have > enough on which to base collaboration. I'd be happy to be part of the discussion. -r -- http://www.cfcl.com/rdm Rich Morin http://www.cfcl.com/rdm/resume rdm / cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Technical editing and writing, programming, and web development