Multi Valued Interface Models?
Date: 8 Feb 2006 18:21:36 -0800
Message-ID: <1139451696.614258.233640_at_g43g2000cwa.googlegroups.com>
This post is primarily directed at the latest http://www.tincat-group.com/ blog, but is also at heart comment on other recent non-RM work as well as Pick.
Dawn, I am not sure about the argument you follow in your latest blog - the logic as I read it appeared to be that because an interface might contain data in non-1NF, then the RM is not preferable as the underlying model. (I am happy to be rectified if I have misconstrued the angle).
Now this is the same underlying logic I hear in the promotion of XML and OO databases. But it appears to me that this neglects the point that RM takes the principal that its model is interface independant - the data model does not know if you are going to represent the data in an "entity" format as you specify in the UML of your blog or some differing format - perhaps an interface that lists every possible colour of an animal, perhaps something else...who knows? Not the data model that's for sure.
This hence seems to me another case of forcing a fixed hierarchical structure upon deeply interconnected data (the plague of computer science?). Information has a whole host of (perhaps yet unrecognised) relationships linking items within it, and as such I firmly believe that the data model must reflect this faciliting future discovery, extraction and manipulation of them. This is at the heart of everything that is wrong with the XML-centric standpoint, and imo its not a strong argument in favour of MV. Fix oneself into a hierarchy that appears to make sense at the time and at some point, somewhere down the line you'll find your goose is cooked (I hope that's not just a british phrase).
Better cases for MV appear to me to be along other lines. Practicality or efficiency for instance - when one knows that a certain hiearchical representation is the only one that will _ever_ be used. On my last project in order to implement persistence I adopted for mass serialization of a relatively complex class hierarchy. It was a pain (smart-pointer based C++ and serialization capabilites, not a rewarding mix in my experience) but it got the job done and was entirely appropriate for that case. But if I'd believed that data might be required by other processes in the future it _obviously_ wouldn't have been appropriate, and flexibility of representation would have been essential.
The other line I'd look at would if I was an MV-advocate might be the underlying principles of predicate logic. There is nothing in FOL that states a predicate should have to exist in 1NF. I can quite happily state "There is an animal called a penguin which is coloured black and coloured white" without having to split the poor penguin up into two seperate predicates. I have never explored this area, but this seems to me the core of the MV debate, and examination of that theoretical line is perhaps the only way a purist (like myself I guess) might be convinced.
However in the meantime I will continue to sit on this MV fence, watching the debate and getting multi-valued splinters.
All best, Jim. Received on Thu Feb 09 2006 - 03:21:36 CET