Relational database & OO
in [OOP]
|
From: H. S. Lahman on 16 Nov 2006 10:49 Responding to Jacobs... >>Typically the Class Model will not map 1:1 to a storage Data Model > > > Us table fans cringe at calling it "storage model". It is already an > abstraction, not a hardware model. How is an ERD Data Model not abstract? The issue is what it models. A Data Model models the way data will be organized statically in the persistent repository. A Class Model models the way properties will be used dynamically in the solution to some problem. The point is that those representations are not necessarily the same once one is outside CRUD/USER processing. >>outside of CRUD/USER processing. (That's the main reason why I advocate >>isolating persistence access mechanisms in a subsystem; such isolation >>encapsulates the conversion in views.) Two models of the problem space >>can be in 3NF without being exactly the same. >> >>For example, in an OO application the developer can abstract problem >>space delegation so that properties are "owned" by quite different >>objects than in the Data Model, which is common when abstracting >>entities that are conceptual rather than concrete. In addition, >>behavior properties are largely anthropomorphized at the developer's >>discretion. IOW, the developer has a lot of leeway in allocating which >>abstractions own particular properties. But ensuring NF compliance is >>not an option. > > > Note that I used to use local temporary (app-level) tables to do > similar things. However, the tools stopped readily supporting this when > vendors switched to OOP-centric designs to fit the fad. It was sort of > a self-fullfilling prophecy. I am still pissed at OOP for killing > nimble tables. They are still there. The mapping of object/tuple and class/table is pretty straight forward, which is why normalization can work on a Class Model. Check out Leon Starr's "Executable UML: How to Build Class Models". It is the most comprehensive book on OO class modeling available and almost every example is explained in terms of the table analogy. I don't have any problem with using tables. In fact, I use lookup tables extensively in parametric polymorphism. What I have a problem with is using tables for a specific problem solution that have the exact same schema as tables in the database (once one is outside the realm of CRUD/USER). ************* There is nothing wrong with me that could not be cured by a capful of Drano. H. S. Lahman hsl(a)pathfindermda.com Pathfinder Solutions http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman "Model-Based Translation: The Next Step in Agile Development". Email info(a)pathfindermda.com for your copy. Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php. (888)OOA-PATH
From: Dmitry A. Kazakov on 16 Nov 2006 10:59
On Thu, 16 Nov 2006 15:33:52 GMT, H. S. Lahman wrote: > Responding to AndyW... > >>>>Are you saying your OO models are normalized the same way your RDB >>>>models are? I guess I'm wondering if you're thinking of systems with >>>>1:1 ratio of tables to classes. >>> >>>Yes. In a well-formed OO application the Class Model should fully >>>conform to at least 3NF. >> >> *cough* *splutter* *choke* >> >> How do you normalise a 'fish'. > > One normalizes a fish class the same way one normalizes a fish table; by > properties and their relationship to fish identity. Yep, fishsticks is normalized fish. A normalized fish table must be built out of normalized fishsticks... I believe. I am not sure about fish identity in those sticks... (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de |