I think both the OO and the RDBMS view can be a problem when looking at data in the first place. ER diagrams tend to be too focus on tables, not distinguishing objects and relations properly, but OO-modeling languages such as UML tend to be weak when it comes to treating relations as first-class entities.
As an example of the weirdness of the OO view: I once worked on a system to manage Enterprise Architecture. At its heart was a relation with signature (InformationSystem, BusinessProcess, OrganizationalUnit, Product) meaning that a particular information system supports a particular organizational unit in a business process creating a particular product. It might not be obvious but in large organizations this is a true quaternary relation, any dimension can vary independently. The way this was modeled was a big ER diagram, which was the first thing you saw coming into the developers' room. The way it was implemented was a Java model and then Hibernate mappings such that the database schema would match the ER diagram. In my not so humble and rather strong opinion the whole project would have been much easier if it would have been done in a more relational way to begin with. It moved a little bit into that direction by adding more and more reified relations (i.e. turning relations into OO classes). Whenever I can I try to avoid thinking too much in terms of either OO or RDBMS. Relational algebra is actually not too bad on a conceptual level (but quite different from an actual RDBMS), and I like the other ORM (Object-Role Modeling) as conceptual modeling tool. But unfortunately people prefer to see either ER or UML diagrams -- familiarity wins over suitability. Peter PS: another practical approach for conceptual modeling is a glossary with semi-structured English (or other natural language). Write as normal, but make sure some relations have well-defined meanings. Everything term that has a defined meaning has a definition itself and is highlighted wherever it appears. Don't think about Java objects or tables until the glossary has reached a certain maturity level, then try to figure out if you can express the model more easily as tables or objects. Michael Neale wrote: > I agree with that - except for the bit about most enterprise data > suiting a relational model - I think its quite the opposite but years > of DBA brainwashing has convinced everyone otherwise. Very few uses of > RDBMS I have seen really make much use of the R bit to good effect (at > best its just a data quality thing). > > On May 15, 11:52 am, Christian Catchpole <[email protected]> > wrote: > >> I think there are heaps of reasons including the ones you mention. >> But I think the main thing is that dev's might like the idea of a >> clean object DB, but in practice, the data held by an organization >> does not (or should not) match the objects used by a program. And >> this data shouldn't be tied to any one app. And relational people >> will argue that most enterprise data suits a relational model more >> than an OO one. >> >> Then there is the whole investment in DB technologies, admin, tuning, >> reporting, backup, replication etc. >> >> I don't know much about OO databases so I can't say how they compare. >> >> On May 15, 6:12 am, Nico <[email protected]> wrote: >> >> >>> I'd like to hear the posse discuss why technologies such >>> ashttp://www.db4o.com/ >>> has not yet taken over from the traditional Relational Databases like >>> Oralce, SQL Server, MySQL.. >>> >>> Is it because the technology is not mature enough or is it because of >>> vested interest both political and monetary in large enterprises? >>> > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
