My concern with using ORM, which I think is brilliant, is making it useful at the conceptual level, and pushing the diagrams through design, whilst making them useful to anyone other than a technical user (only me so far in the company)

Does anyone have any suggestions on how one might achieve such readability, whilst maintaining the technical content?  I currently build up the diagrams and can switch between showing conceptual names, and physical names, and also suppressing operation parameters and the like.

Suggestions would be good, on how we might make the use of this technology applicable in more than just a level above ERDs?  I like to work with ORM diagrams, and make sure they're up to date, then generate ERDs, whereas a lot of the people who might be interested in my work would either only understand or prefer to work with ERDs.  I guess this is down to the fact that ORM notation becomes complex in anything but the simplest situations?

Cheers,

Martin Platt.

Scot,

I see what you're saying, but think that there should be the ability to 'scope' and trim back irrelevant functionality, using something similar to the system boundary.

I found that treaking the document settings does help somewhat - I tend to take down requirements and work through their details, then commit the ORM details to a document.  I guess that process would remove some of the relevance to clients.  I would expect to be able to take a logical design, and push that through to physical design at the very least, by changing 'views' on the same information.  This process can be partly done, but it would be good to take that further and use it as a toll that can be used for the whole process rather than always having to resort to paper, as is the case with most tools.

My view is that these tools should be improved to make then truly useful, I'm sure that this can be done because the process is almost there already, but does not go all the way?

Cheers,

Martin.