Re: Object-oriented thinking in SQL context?

On 9 Jun, 20:27, "Walter Mitty" <wami..._at_verizon.net> wrote:
> <dr.coff..._at_gmail.com> wrote in message
>
> news:50df6983-ba3b-4604-994a-89b595775ea5_at_o20g2000vbh.googlegroups.com...
>
>
>
>
>
> > On 8 Jun, 18:25, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
> >> dr.coff..._at_gmail.com wrote:
> >> > Hi folks.
>
> >> > I have a problem with wrapping my mind into the 'right' wrinkles.
> > ...
> >> > Any general ideas on how to design a SQL database around
> >> > such constraints?
>
> >> > Dr. C.
>
> >> Those are mostly trivial data modelling problems. Have you read anything
> >> on data modelling, normalization, joins?
>
> > Yes, I have. Well, 'browsed' is a better term, as the
> > objective is to get a working demo system up in a hurry.
> > As age progresses, I'm more and more inclined to skip
> > reading what is not immediately percieved as useful, so
> > presumably I don't see the forest for the trees. Databases
> > are the solution to the problem at hand; I just don't have
> > the hands-on experience (yet) needed to come up with a
> > working system.
>
> > The problem is that I think in OO terms, like classes and
> > inheritance. Decades ago I used to work very hard to get
> > away from arrays and other non-OO data structures associated
> > with procedural programming, and now I am unable to revert
> > my mind to that context.
>
> > In particular, I don't recognize OO terminology from what
> > I read, and I am not able to recognize OO concepts from
> > the terminology I do see. As somebody correctly pointed out,
> > I am not used to the problem statement that needs to be used
> > in DB design.
>
> > So in the 'naive' problem statement I see an array of objects
> > of classes derived from a base class (in C++ I'd use
> > boost::shared_ptr to access the objects), while I read that
> > SQL is constrained to 'trivial' arrays. The problem is the
> > vast philosophical distance between the two problem statements,
> > that I am unable to bridge.
>
> > I'd appreciate any key words to look for when re-reading
> > the material. I'm using Teorey's "Database Modeling and
> > Design: Logical Design", 4th edition.
>
> Here are a few key words to look for:
>
> Physical Data Independence and Logical Data Independence.  Between these
> two, they cover much of the same ground that "encapsulation" covers, but in
> a way that can span an entire enterprise's need to share data.  This is
> probably overkill for the problem you outlined in your original post.
...
> Generalization and specioalization.   This concept covers some of the same
> ground that inheritance covers in OO design.  The gain calibration you
> mention for microphones would be an example of  an attribute that pertains
> to a microphone which is a specialized instrument.

That's what confused me. The general concepts are *similar* to concepts from OO, but not the same. I suppose the main difference is that objects are local collections of different attributes, while in relational databases the objects are 'disassembled' and the attributes distributed over the various tables.

So in OO programs one can access the object through the base class and access the specialized attributes through virtual functions. This seems not to be possible in relational databases; one needs to assemble the attributes into objectlike  entities.

Or something like that.

> Most of this is overkill for both your stated problem, and for building a
> simple application in MS Access.  Do you have any good Access tutorials or
> documentation?

I have the Excel-Access integration text by Alexander & Clark. I'm a bit away from anything useful yet, I need to wrap my mind around the design philosophy first.

Thanks for the overview - much appreciated!

Dr. C. Received on Tue Jun 09 2009 - 22:20:19 CEST