Re: Object-oriented thinking in SQL context?
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Tue, 09 Jun 2009 17:40:01 -0300
Message-ID: <4a2ec8a4$0$23785$9a566e8b_at_news.aliant.net>
>><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.
Date: Tue, 09 Jun 2009 17:40:01 -0300
Message-ID: <4a2ec8a4$0$23785$9a566e8b_at_news.aliant.net>
dr.coffee1_at_gmail.com wrote:
> 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.
Wrong. In relational databases, object values are just values. An n-ary relation is a set of n-ary tuples or compositions of "objects". The scare quotes are there because the term object is imprecise, overloaded and not well-defined.
> Or something like that.
Or not.
>>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?
Walter, shame on you for that suggestion. If he goes reading that shit from Microsoft he will think the relational model is named for referential integrity.
> 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.
Which part of philosophy interests you most? Epistemology? Received on Tue Jun 09 2009 - 22:40:01 CEST