Re: Object-oriented thinking in SQL context?

<dr.coffee1_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.

Restrict(sometimes called select), project, and join. These three operators combined with set primitives like INTERSECTION, UNION, and MINUS take the place of literally hundreds of processing algorithms for combining data in useful ways.

Concurrency, transaction control, and ACID (Atomic, Consistent, Isolated, and Durable). These are big concepts that permit a database server to serve diffferent transactions concurrently, without the actions of one participant propagting chaotically onto the view that another transaction has of the current state of affairs.

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.

Data Normalization. I don't know what this corresponds to in OO design. But it really provides a handle on one way (not the only way) of distinguishing a good table design from a design that's asking for trouble.

Metadata. The fact that data definitions can be reduced to data whose subject is data is amazing. It permits data sturctures to be queried and analyzed using the same query tools that are used on ordinary data.

Data Definition Language and Data Manipulation Language. An important distinction, if the database is to be treated as an integrated whole, and not just a bunch of user idiosyncratic data smashed together into one big amorphous mess.

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?

> Dr. C.
>
Received on Tue Jun 09 2009 - 20:27:50 CEST