Object-oriented thinking in SQL context?
dr.co...@gmail.com
I have a problem with wrapping my mind into the 'right' wrinkles.
I need to come up with a database design in SQL/MSAccess,
since that's the tool that is available to me. The subject of the
database is an inventory of electronic instruments, and the
objective is to maintain a status log of these instruments.
The naive idea is:
- Instrument ID
- Instrument status (active / stand-by / inactive)
- Instrument location (room / shelf / position)
The above ought to be valid for all instruments. Then there
are a few instruments that need to be calibrated before use.
These need to have some additional fields:
- Calibration status ( OK / not calibrated )
- Calibration data ( varies with type of instruments )
The problem is the latter two fields. Only a few instruments
need to be calibrated at all; and the calibration data varies
with the exact type of instrument. A microphone might
need a gain factor from sound pressure to voltage; a
GPS position sensor might need an (x,y,z) location
plus orientation along three axes.
The above would be almost trivial to implement in an
object-oriented context (well, this si my first attempt at
databases at all - my experience is with OO programming),
but I don't see how to come up with a table-based database
design.
Any general ideas on how to design a SQL database around
such constraints?
Dr. C.
Bob Badour
Those are mostly trivial data modelling problems. Have you read anything
on data modelling, normalization, joins?
cim...@hotmail.com
Before doing any database design, you need to define first your
problem in a way you are not accustomed to. OO thinking is too
sloppy and imprecise to be easily transposed to database design.
dr.co...@gmail.com
> dr.coff...@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.
Dr. C.
Gene Wirchenko
>On 8 Jun, 18:25, Bob Badour <bbad...@pei.sympatico.ca> wrote:
[snip]
>> 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.
Then you will make the mistakes that newbies make.
>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.
You need knowledge first.
[snip]
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
Bernard Peek
<bf7e8cca-4cbc-4a8c...@g1g2000yqh.googlegroups.com>,
dr.co...@gmail.com writes
>Hi folks.
>
>I have a problem with wrapping my mind into the 'right' wrinkles.
>I need to come up with a database design in SQL/MSAccess,
>since that's the tool that is available to me. The subject of the
>database is an inventory of electronic instruments, and the
>objective is to maintain a status log of these instruments.
>
>The naive idea is:
>
>- Instrument ID
>- Instrument status (active / stand-by / inactive)
>- Instrument location (room / shelf / position)
>
>The above ought to be valid for all instruments. Then there
>are a few instruments that need to be calibrated before use.
>These need to have some additional fields:
>
>- Calibration status ( OK / not calibrated )
>- Calibration data ( varies with type of instruments )
>
>The problem is the latter two fields. Only a few instruments
>need to be calibrated at all; and the calibration data varies
>with the exact type of instrument. A microphone might
>need a gain factor from sound pressure to voltage; a
>GPS position sensor might need an (x,y,z) location
>plus orientation along three axes.
You also need to consider calibration state too. Calibration has to be
redone at intervals, you need to know when the current calibration will
expire.
But, getting back to the issue at hand. Database design generally starts
by establishing what types of thing you need to hold information about.
So "Instrument" is the first entity to design. You need a key for this.
Do the instruments have any sort of asset tag? If so then the tag number
is a good choice to use as the ID. If they don't already have an asset
tag then you need to find some way of permanently labelling the
instrument. If an instrument has a serial number record it here too.
Add a field that shows whether the instrument requires calibration. Add
another field to show the instrument's storage location. Add one for
active/standby/inactive status. Add any more fields that you need to
describe a generic instrument.
You also need a table that holds calibration information. You need to
make some decisions about how you are going to use the data. There is no
point in building a horrendously complex system if all you need is a
free-text note. You probably want a table that shows calibration events,
with a start and end-date for each calibration. An instrument is
calibrated if today's date lies between the start and end date of the
latest calibration.
Do you need any more than a simple text-field to hold notes about what
type of calibration was done? That's generic and could be applied to
pretty much any device. Do you need this data to have any more structure
than that?
--
Bernard Peek
Bob Badour
> On 8 Jun, 18:25, Bob Badour <bbad...@pei.sympatico.ca> wrote:
>
>>dr.coff...@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.
Define 'working'.
> 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.
Hands-on experience is no substitute for fundamental education. If we
had to rely on hands-on experience for multiplication, I doubt anyone
would have ever progressed beyond the 12 times tables.
> 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.
Am I hearing you correctly? You worked very hard to force your brain to
think in terms of a single physical computational model? That's
unfortunate and must be very limiting. No doubt you will have to work
equally hard to overcome that impediment.
> 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.
I am not sure what use you would make of OO terminology. It's all rather
nebulous, overloaded and imprecise. None of it is any good for
communicating much of anything.
> 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.
Philosophy? An n-dimensional relation of arbitrary domains is 'trivial'?
And all these years I thought the number of golf balls on the moon was
trivial.
> 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.
>
> Dr. C.
Keywords? Introduction, preamble, prologue, chapter 1. I would start
with one of those. Not sure which terminology Teorey uses in the 4th
edition, but I am sure you will find something suitable shortly after
Table of Contents.
dr.co...@gmail.com
> dr.coff...@gmail.com wrote:
> > On 8 Jun, 18:25, Bob Badour <bbad...@pei.sympatico.ca> wrote:
>
> >>dr.coff...@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.
>
> Define 'working'.
A demo system based on databases where some basic functionality
is up and running, to demonstrate how to solve administrative
tasks that are handled manually these days.
The techies are asked to keep track of the instruments, and
somebody somewhere else do occasionally want to know the
status of the inventory or calibration data for some operational
instrument. I'm sure you'll get some impression of the problem
from the sketch in my first post.
Instead of making a phone call ordering the techies to dig
out that info manually and send back by email, my goal is
to get a skeleton MSAccess database and MSExcel interface up
to demonstrate how those who want to know can get the info
without requiring manual interference from other people.
Everybody are happy and time-wasting stress factors are
removed.
> > 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.
>
> Hands-on experience is no substitute for fundamental education. If we
> had to rely on hands-on experience for multiplication, I doubt anyone
> would have ever progressed beyond the 12 times tables.
I know. But I'm doing this on my own, and am just starting out.
I have a few books lying around that I need to make sense of.
Naively, I thought asking experts for help would be useful.
> > 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.
>
> Am I hearing you correctly? You worked very hard to force your brain to
> think in terms of a single physical computational model? That's
> unfortunate and must be very limiting. No doubt you will have to work
> equally hard to overcome that impediment.
Well, my basic programming training (I'm not a programmer but a
data analyst by vocation) was in terms of assembler-style GOTO
constructs and procedural programming. After a while I found
that these styles or models were far too limiting for the
types of problems I worked at. I had to make a serious effort
to learn OO in general and C++ in particular. These days I think
in terms of class hierarchies and policies.
Your name and location suggest your native language is English.
If correct, you likely do not know a second language very well.
Bilingual people will know that different languages tend to be
useful for expressing different things. My native language is
not English, but all my professional training was in English.
Which has had the effect that I am unable to think about
professinal questions in my native language. I find that I
always refer to English terms when discussing work.
OO and policies has had the same effect, and have worked well
enough that I haven't needed to look back. Until I encountered
databases and SQL.
> > 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.
>
> I am not sure what use you would make of OO terminology. It's all rather
> nebulous, overloaded and imprecise. None of it is any good for
> communicating much of anything.
Ever heard of a 'class'? 'Supertype'? 'Specialization'?
Teorey uses UML to communicate problems and solutions
in the context of databases. Just as lots of folks do
with OO programming. The concepts are the same everywhere.
Terminology differs.
> > 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.
>
> Philosophy?
Yes, philosophy. It seems you are young enough that your
basic training was in terms of OO concepts. I can assure you,
when your basic training is in terms of procedural programming,
the transition to OO is one of philosophy.
> An n-dimensional relation of arbitrary domains is 'trivial'?
No. The individual tables are trivial, not the overall relation.
This relation is essentially the philosophical difference I was
talking about: Procedural programming can represent anything the
OO model can (as I understand it, OO programs are implemented as
procedural constructs) but the details are understood by human
users in different ways.
Complex relations, that are trivial for the human to comprehend
when expressed in OO terminology and concepts, are not at all so
when expressed in terms of basic data structures like tables and
arrays.
This is the philosophical difference some of the posters here
seem not to understand but nonetheless are gloating about - like
in the 'laugh of the day' a couple of days ago: What database
professionals and experts take for granted is at least percieved
as at odds with the basic training of general-purpose computer
practitioners like myself.
Referring back to natural languages, it is a very humbling
experience to arrive in a place where you have no language
in common with the natives. One is essentially set back to
the level of a toddler, struggling to interact over the
simplest things. As English becomes more and more wide-spread,
native English-speakers would not have this experience.
Now, it makes no sense to mock people who ask about databases
because they do not know English. It makes no sense to mock
people who want to get help with basic terminology because
they do not know basic terminology.
The database community can handle this in a couple of ways:
1) Close in on yourself and mock people who do not have the
insights you have.
2) Recognize the problem and help sort out the misunderstandings
and snags.
Over the past couple of days I have got a clear impression about
what approach seems to be preferred by the regulars here.
Dr. C.
Walter Mitty
<dr.co...@gmail.com> wrote in message
news:50df6983-ba3b-4604...@o20g2000vbh.googlegroups.com...
some combination of easy and unimportant.
SQL tables are very easy for those who have learned to think in terms of
them, to understand data requirements from a data-centric and set oriented
point of view, and to implement tables that will be easy to keep current,
easy to maintain data integrity, and easy to write queries against. The
results you can acheive with SQL tables are far from unimportant. I read
recently where somebody replaced sometihng like 20,000 lines of object
oriented code with about 300 lines of SQL, and sped up the weekend update
process from 45 hours to 45 minutes. The object oriented code in this case
may have been clumsy. There are many clumsy designs where an OO language is
used to merely code up a software design that is fundamentally procedural.
When you do that, you get all the overhead of OO run time systems, without
most of the power.
Something analogous happens with database design. People who begin
designing databases based only on prior experience with indexed files, and
who expect to put all the business logic in the application, end up with
databases that are clumsy, slow, and fairly inflexible. People who know
what they are doing can acheive outstanding results. Unless you are far more
intelligent than I, mere "browsing" works on database design is not going
to make you a competent designer.
Just as you moved away from thinking procedurally when you migrated to OO
thinking, so likewise most of us who started with procedural languages and
migrated to SQL moved away from procedural thinking. To you, thinking in
terms of tables or arrays looks like a return to procedural programming.
Believe it or not, coding up all the intelligence in a business system in
Java looks to me like a return to procedural thinking. I would prefer to
design a database that is relevant, flexible, fast, and powerful. I think
I'm not alone in this perception.
One key difference between procedural thinking and SQL thinking is thinking
in terms of sets of data rather than breaking a set down into a loop that
processes elements one at a time. At some point, the SQL query optimizer
may have to do that, in order to come up with a strategy for carrying out
your query. But outthinking the optimizer is a singularly wasteful use of
brainpower. It's much better to come up with logical data structures that
are relevant to the problem at hand, and to implement physical data
structures that capture the essential features of the logical data
structures.
Back when I learned SQL, we tended to think of SQL as "relational". Since
that time, in places like this newsgroup, I've learned about some flaws in
SQL, when viewed as an implementation of the relational model of data.
Those flaws are real. Nevertheless, SQL allows you to do a lot of the
things that led Codd to propose using the relational model of data for large
shared data banks. There is a learning curve here. You can shorten it, but
you can't skip over it.
cim...@hotmail.com
Snipped
> The database community can handle this in a couple of ways:
>
> 1) Close in on yourself and mock people who do not have the
> insights you have.
> 2) Recognize the problem and help sort out the misunderstandings
> and snags.
> Over the past couple of days I have got a clear impression about
> what approach seems to be preferred by the regulars here.
Let me get this straight. You need help from the database community
for a design exercice but you need that help to be done according to
the principles you believe are universal (whatever these may be). All
I have seen so far are goodwill people who wanted to help you by
advising you to do some reading necessary to understand some basic
principles of database design. In a word, you ask a question and
because you don't like the answer you now imply that the *regulars*
have closed themselves and mocked you.
Don't you think this is a hasty harsh judgment on your part ?
Bernard Peek
<61940522-4566-4b27...@o18g2000yqi.googlegroups.com>,
cim...@hotmail.com writes
I've been reading and posting to this newsgroup on and off for years. I
think his analysis is pretty accurate.
--
Bernard Peek
cim...@hotmail.com
> In message
> <61940522-4566-4b27-be4f-ad8afcbf8...@o18g2000yqi.googlegroups.com>,
thread where you think the questionner's *analysis* seems accurate.
dr.co...@gmail.com
> Snipped
>
> > The database community can handle this in a couple of ways:
>
> > 1) Close in on yourself and mock people who do not have the
> > insights you have.
> > 2) Recognize the problem and help sort out the misunderstandings
> > and snags.
> > Over the past couple of days I have got a clear impression about
> > what approach seems to be preferred by the regulars here.
>
> Let me get this straight. You need help from the database community
> for a design exercice but you need that help to be done according to
> the principles you believe are universal (whatever these may be).
As for my starting point, I have made the observation that
object orentated designs and methodologies are more or less
universally useful in programming and general system analysis.
Check the textbooks in just about any such activity, be it
programming, buisness modelling, XML or UML. My personal
experience coincides with this impression - OO is a very
useful tool.
I have also made the observation that object oriented
*terminology* is absent from the database texts I have
available. I don't recognize the concepts I am familiar
with in what I read about databases. I'm not saying they
are absent; I'm saying they have taken a different guise.
In my first post:
"I have a problem with wrapping my mind into the 'right' wrinkles."
"The [system] would be almost trivial to implement in an
object-oriented context [...],
but I don't see how to come up with a table-based database
design."
In my second post:
"The problem is that I think in OO terms, like classes and
inheritance."
"So in the 'naive' problem statement I see an array of objects
of classes derived from a base class [...], 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."
So it would be immensely helpful if somebody could
come up with a general comment about
1) If OO concepts can be handled at all in SQL databases.
2) If so, how it is done.
As I'm getting older, I don't appreciate building a big
picture from gazillions of details. I rather prefer to
get the big picture first, and then fill in with the
deatils.
> All
> I have seen so far are goodwill people who wanted to help you by
> advising you to do some reading necessary to understand some basic
> principles of database design. In a word, you ask a question and
> because you don't like the answer you now imply that the *regulars*
> have closed themselves and mocked you.
I have asked the one question that just about everybody
with a little bit of OO programming experience will ask
when entering the world of SQL databases:
How do OO class concepts map to SQL table concepts?
It's a trivial question that I have found no clear answer
for, neither in my books or here. Check out a textbook
on C++, 'You Can Program in C++' by Glassborow. It is
intended for programmers who know some other programming
language and want to learn C++. The author includes a
number of sections on how C++ is similar and different
to a number of languages, like C, Java, Fortran, etc.
While the section doesn't tell anything a programmer who
knows both C++ and, say, Java knows, it summarizes it
up front so that the newbie has a chance to sort out
'philosophical' and practical differences. This kind
of thing would be immensely helpful for somebody who
just starts out.
I ask the same question: How is SQL different and similar
to what I already know.
This simple question has not been answered. Instead,
you seem to suggest that object orientation is *not* a
useful context for system analysis or design, generally
or with databases. Some of the posts I have seen in
other threads in this forum suggest to me that the
database community sees the apparent discrepancy in
terminology between it and the rest of the world, is
the rest of the world's problem.
If these impressions are indeed correct, please state
it unequivocally, and I will stop wasting my and
everybody else's time.
> Don't you think this is a hasty harsh judgment on your part ?
No. The database community (posters here, textbooks) seem
unable to answer the one, simple general question any
programmer unfamiliar with SQL will ask.
That's a problem with the database community, not the
question.
Dr. C.
cim...@hotmail.com
> On 9 Jun, 14:49, cim...@hotmail.com wrote:
>
> > Snipped
>
> > > The database community can handle this in a couple of ways:
>
> > > 1) Close in on yourself and mock people who do not have the
> > > insights you have.
> > > 2) Recognize the problem and help sort out the misunderstandings
> > > and snags.
> > > Over the past couple of days I have got a clear impression about
> > > what approach seems to be preferred by the regulars here.
>
> > Let me get this straight. You need help from the database community
> > for a design exercice but you need that help to be done according to
> > the principles you believe are universal (whatever these may be).
>
> As for my starting point, I have made the observation that
> object orentated designs and methodologies are more or less
> universally useful in programming and general system analysis.
> Check the textbooks in just about any such activity, be it
> programming, buisness modelling, XML or UML. My personal
> experience coincides with this impression - OO is a very
> useful tool.
I am not aware of any precisely and consensually OO defined concept.
I have asked hundreds of OO programmers in the past about a definition
about what an object and each of them came with a totally different
definition.
> I have also made the observation that object oriented
> *terminology* is absent from the database texts I have
> available. I don't recognize the concepts I am familiar
> with in what I read about databases. I'm not saying they
> are absent; I'm saying they have taken a different guise.
The fact that you don't recognize in database texts what you are
accustomed to simply means that you do not have a proper background in
database technology. By educating yourself, you would be in a
position to relate more easily what you already know. That is just an
advice.
I would suggest this may not be the right place for that. You will
be luckier in a *database quick and dirty* forum..
> How do OO class concepts map to SQL table concepts?
Simple, they hardly do. OO concepts are way too imprecise to be
mapped to the rigor of database theory.
I suggest you take a look to some of Date's books where he treated
that subject.
> It's a trivial question that I have found no clear answer
> for, neither in my books or here. Check out a textbook
> on C++, 'You Can Program in C++' by Glassborow. It is
> intended for programmers who know some other programming
> language and want to learn C++. The author includes a
> number of sections on how C++ is similar and different
> to a number of languages, like C, Java, Fortran, etc.
> While the section doesn't tell anything a programmer who
> knows both C++ and, say, Java knows, it summarizes it
> up front so that the newbie has a chance to sort out
> 'philosophical' and practical differences. This kind
> of thing would be immensely helpful for somebody who
> just starts out.
Or maybe you just are not ready to accept the answer as it is. set
oriented approaches are radically opposites of procedural approaches.
> I ask the same question: How is SQL different and similar
> to what I already know.
In ways you can not tell if you do not go through a self learning
process of education in database concepts. If you believe this is not
necessary and OO concepts are sufficient to understand database theory
then it will be difficult to help you.
> This simple question has not been answered. Instead,
> you seem to suggest that object orientation is *not* a
> useful context for system analysis or design, generally
> or with databases.
Well that's is a correct assertion.
Snipped
> If these impressions are indeed correct, please state
> it unequivocally, and I will stop wasting my and
> everybody else's time.
This is the last post I am making to help you out. My time is as
limited as yours.
> > Don't you think this is a hasty harsh judgment on your part ?
>
> No. The database community (posters here, textbooks) seem
> unable to answer the one, simple general question any
> programmer unfamiliar with SQL will ask.
I believe on the contrary that the question has been answered very
clearly by several people. The fact that you accept this response or
not is another matter. That is no reason for blaming an entire
community.
> That's a problem with the database community, not the
> question.
Maybe the problem lies elsewhere...but since you are so convinced then
I wish you have a good luck in your endeavours.
> Dr. C.
Jan Hidders
Unfortunately it is.
-- Jan Hidders
dr.co...@gmail.com
You are a database desinger, right? Do you ever use the
'entity-relation' method when you design a database?
If so, what is an 'entity'?
> > I have also made the observation that object oriented
> > *terminology* is absent from the database texts I have
> > available. I don't recognize the concepts I am familiar
> > with in what I read about databases. I'm not saying they
> > are absent; I'm saying they have taken a different guise.
>
> The fact that you don't recognize in database texts what you are
> accustomed to simply means that you do not have a proper background in
> database technology. By educating yourself, you would be in a
> position to relate more easily what you already know. That is just an
> advice.
Right. As I said previously, I was naive when I hoped for
help when asking the more experienced.
Pointers, please?
> > How do OO class concepts map to SQL table concepts?
>
> Simple, they hardly do. OO concepts are way too imprecise to be
> mapped to the rigor of database theory.
>
> I suggest you take a look to some of Date's books where he treated
> that subject.
Ah, at last we are getting somewhere. Any pointers to books?
Any quick'n dirty synopses of the arguments?
> > It's a trivial question that I have found no clear answer
> > for, neither in my books or here. Check out a textbook
> > on C++, 'You Can Program in C++' by Glassborow. It is
> > intended for programmers who know some other programming
> > language and want to learn C++. The author includes a
> > number of sections on how C++ is similar and different
> > to a number of languages, like C, Java, Fortran, etc.
> > While the section doesn't tell anything a programmer who
> > knows both C++ and, say, Java knows, it summarizes it
> > up front so that the newbie has a chance to sort out
> > 'philosophical' and practical differences. This kind
> > of thing would be immensely helpful for somebody who
> > just starts out.
>
> Or maybe you just are not ready to accept the answer as it is. set
> oriented approaches are radically opposites of procedural approaches.
Ah, 'set oriented vs procedural approach'. The first time
I see it. Any synopses on *how* they are different?
> > I ask the same question: How is SQL different and similar
> > to what I already know.
>
> In ways you can not tell if you do not go through a self learning
> process of education in database concepts. If you believe this is not
> necessary and OO concepts are sufficient to understand database theory
> then it will be difficult to help you.
I hoped for useful answers. After two days and who-cares-
how-many-posts, key words at last seem to trickle into
the replies.
> > This simple question has not been answered. Instead,
> > you seem to suggest that object orientation is *not* a
> > useful context for system analysis or design, generally
> > or with databases.
>
> Well that's is a correct assertion.
Huh?
'The rest of the world is wrong, only *I* see the truth' ?
Maybe an explanation why this forum averages to about
one post per day?
> Snipped
>
> > If these impressions are indeed correct, please state
> > it unequivocally, and I will stop wasting my and
> > everybody else's time.
>
> This is the last post I am making to help you out. My time is as
> limited as yours.
>
> > > Don't you think this is a hasty harsh judgment on your part ?
>
> > No. The database community (posters here, textbooks) seem
> > unable to answer the one, simple general question any
> > programmer unfamiliar with SQL will ask.
>
> I believe on the contrary that the question has been answered very
> clearly by several people. The fact that you accept this response or
> not is another matter. That is no reason for blaming an entire
> community.
I'm blaming the community because members seem systematically
unable to project themselves into the shoes of a newbie, and
are thus unable to see the subject from the newbie's perspective.
That's a sign of a professional community well on its way
to professional degeneracy.
Dr. C.
Bernard Peek
<4062e85f-4566-4111...@y17g2000yqn.googlegroups.com>,
dr.co...@gmail.com writes
>How do OO class concepts map to SQL table concepts?
The answer to that is "badly."
In this newsgroup we occasionally have visitors who claim to have
discovered some way to link the two sets of concepts and so far all of
the ones we have seen have shown a limited grasp of relational theory. I
was one of those but I've hung around long enough to pick up more of the
theory. You have been caught in the backwash from dealing with some real
idiots. Sorry about that.
We aren't going to be able to give you a crib-sheet that maps the
concepts in the two paradigms. Lots of very bright people have been
trying to do that for a long while and they haven't succeeded. The
assembled multitude here know vastly more about relational algebra than
I ever will, I'm a very pragmatic software development manager who
happens to concentrate on building infrastructure while managing
development teams. I'm going in the opposite direction to you because
I'm satisfied that I have enough knowledge of relational databases to be
able to design a back-end system I need to make them available to OO
developers and analysts.
I've been reading a book called "Beginning C# Databases" from Wrox. It
has some information about the .NET architecture and how it wraps
relational databases. From reading that I would guess that your most
productive route would be to develop your software in one of the OO .NET
languages, quite possibly C#.
If you still want to learn about relational theory then this is a very
good place to do that, but it won't happen overnight. It's not a trivial
task and the advice others have given you, to read some books on the
subject, is good (although the advice could have been phrased more
tactfully.) Personally I would be much happier if this newsgroup had
someone who could fly the flag for OO systems, preferably while being
able to walk *and* chewing gum.
There needs to be a better understanding of the mapping between objects
and relational systems. For better or worse UML is the de facto standard
for the design of new systems.
--
Bernard Peek
Bernard Peek
<439c733f-05f3-4240...@r34g2000vba.googlegroups.com>,
dr.co...@gmail.com writes
>
>I'm blaming the community because members seem systematically
>unable to project themselves into the shoes of a newbie, and
>are thus unable to see the subject from the newbie's perspective.
>
>That's a sign of a professional community well on its way
>to professional degeneracy.
At the moment relational theory seems to be so effective at handling
low-level database management that I think that its practitioners are
quite right in considering themselves an essential component of
efficient systems design.
On the other hand from an OO practitioner's point of view relational
theory is a quite little backwater that doesn't have much applicability
in the real world.
I don't see an inherent conflict between these views and both are very
probably true.
--
Bernard Peek
dr.co...@gmail.com
> dr.coff...@gmail.com writes
>
> >How do OO class concepts map to SQL table concepts?
>
> The answer to that is "badly."
> We aren't going to be able to give you a crib-sheet that maps the
> concepts in the two paradigms. Lots of very bright people have been
> trying to do that for a long while and they haven't succeeded.
This is very helpful in that I now know that there is no point
in looking for OO concepts, since they are not present. I suppose
the corollary is that I'll have to settle for what functionality
I can get, and instead be a bit economic about the efforts to
obtain what OO functionality or emulations I want; most of the
efforts will be futile.
Thank you very much.
Dr. C.
Bernard Peek
>> be luckier in a *database quick and dirty* forum..
>
>Pointers, please?
microsoft.public.access.tablesdbdesign
--
Bernard Peek
cim...@hotmail.com
SQL systems and I did not have to use any concept such the *entity
relation* method. I do not use the concept of *entity* when working
with *relations* as meant in *relational* model.
> > > I have also made the observation that object oriented
> > > *terminology* is absent from the database texts I have
> > > available. I don't recognize the concepts I am familiar
> > > with in what I read about databases. I'm not saying they
> > > are absent; I'm saying they have taken a different guise.
>
> > The fact that you don't recognize in database texts what you are
> > accustomed to simply means that you do not have a proper background in
> > database technology. By educating yourself, you would be in a
> > position to relate more easily what you already know. That is just an
> > advice.
>
> Right. As I said previously, I was naive when I hoped for
> help when asking the more experienced.
You being naive is not the point I was trying to address in this
reply. You simply need to do some reading. Unfortunately that the
only way to answer your request.
Maybe a good starter for you...
> > > How do OO class concepts map to SQL table concepts?
>
> > Simple, they hardly do. OO concepts are way too imprecise to be
> > mapped to the rigor of database theory.
>
> > I suggest you take a look to some of Date's books where he treated
> > that subject.
>
> Ah, at last we are getting somewhere. Any pointers to books?
> Any quick'n dirty synopses of the arguments?
I am afraid not...There are no easy answer to your request...
> > > It's a trivial question that I have found no clear answer
> > > for, neither in my books or here. Check out a textbook
> > > on C++, 'You Can Program in C++' by Glassborow. It is
> > > intended for programmers who know some other programming
> > > language and want to learn C++. The author includes a
> > > number of sections on how C++ is similar and different
> > > to a number of languages, like C, Java, Fortran, etc.
> > > While the section doesn't tell anything a programmer who
> > > knows both C++ and, say, Java knows, it summarizes it
> > > up front so that the newbie has a chance to sort out
> > > 'philosophical' and practical differences. This kind
> > > of thing would be immensely helpful for somebody who
> > > just starts out.
>
> > Or maybe you just are not ready to accept the answer as it is. set
> > oriented approaches are radically opposites of procedural approaches.
>
> Ah, 'set oriented vs procedural approach'. The first time
> I see it. Any synopses on *how* they are different?
Read the book provided and see the difference for yourself...
> > > I ask the same question: How is SQL different and similar
> > > to what I already know.
>
> > In ways you can not tell if you do not go through a self learning
> > process of education in database concepts. If you believe this is not
> > necessary and OO concepts are sufficient to understand database theory
> > then it will be difficult to help you.
>
> I hoped for useful answers. After two days and who-cares-
> how-many-posts, key words at last seem to trickle into
> the replies.
>
> > > This simple question has not been answered. Instead,
> > > you seem to suggest that object orientation is *not* a
> > > useful context for system analysis or design, generally
> > > or with databases.
>
> > Well that's is a correct assertion.
>
> Huh?
>
> 'The rest of the world is wrong, only *I* see the truth' ?
My assertion is shared by many in the database community. I also
confirm that it is perfectly possible to do database design by using
database theory only concepts. Bringing OO context does not help, on
the contrary.
> Maybe an explanation why this forum averages to about
> one post per day?
>
>
>
> > Snipped
>
> > > If these impressions are indeed correct, please state
> > > it unequivocally, and I will stop wasting my and
> > > everybody else's time.
>
> > This is the last post I am making to help you out. My time is as
> > limited as yours.
>
> > > > Don't you think this is a hasty harsh judgment on your part ?
>
> > > No. The database community (posters here, textbooks) seem
> > > unable to answer the one, simple general question any
> > > programmer unfamiliar with SQL will ask.
>
> > I believe on the contrary that the question has been answered very
> > clearly by several people. The fact that you accept this response or
> > not is another matter. That is no reason for blaming an entire
> > community.
>
> I'm blaming the community because members seem systematically
> unable to project themselves into the shoes of a newbie, and
> are thus unable to see the subject from the newbie's perspective.
> That's a sign of a professional community well on its way
> to professional degeneracy.
I do not think you are having a newbie's attitude in this thread.
When a newbie *sincerely* wants to learn something, he/she does not
take an attitude which consists of the following:
--> expecting the people who are *not* responsible for his/her lack of
database formal education and who do not owe him/her much to accept
his/her hurting remarks when all they do is try to help him/her
--> expecting answers with his/her terminology when well established
terminologies have been and are still used
--> ignore efforts and answers to point him/her out in the right
direction
--> declare that an entire community is degenerating.
I know of other newbie's attitudes which consist of taking a more
humble approach of simply listenning to what people who have nothing
against you personally may have to say. Does that sound so
unreasonnable?
cim...@hotmail.com
> dr.coff...@gmail.com writes
>
>
>
> >I'm blaming the community because members seem systematically
> >unable to project themselves into the shoes of a newbie, and
> >are thus unable to see the subject from the newbie's perspective.
>
> >That's a sign of a professional community well on its way
> >to professional degeneracy.
>
> At the moment relational theory seems to be so effective at handling
> low-level database management that I think that its practitioners are
> quite right in considering themselves an essential component of
> efficient systems design.
management?
> On the other hand from an OO practitioner's point of view relational
> theory is a quite little backwater that doesn't have much applicability
> in the real world.
There seem to be a contradiction between this statement and the
previous. How can you claim that relational theory is effective into
handling some database management and then denounce its lack of
applicability.
> I don't see an inherent conflict between these views and both are very
> probably true.
Much have been written on the subject but I remember reading somewhere
that a perfect OODBMS is nothing else than a TRDBMS...
> Bernard Peek
Bob Badour
As Dr. Codd so succinctly pointed out over 2 decades ago: An entity is a
relation and a relationship is a relation.
>>>I have also made the observation that object oriented
>>>*terminology* is absent from the database texts I have
>>>available. I don't recognize the concepts I am familiar
>>>with in what I read about databases. I'm not saying they
>>>are absent; I'm saying they have taken a different guise.
>>
>>The fact that you don't recognize in database texts what you are
>>accustomed to simply means that you do not have a proper background in
>>database technology. By educating yourself, you would be in a
>>position to relate more easily what you already know. That is just an
>>advice.
>
> Right. As I said previously, I was naive when I hoped for
> help when asking the more experienced.
We gave you help. OO concepts--for the most part--are not only not
useful but counter-productive. They impede communication and mask a lack
thereof.
>>>How do OO class concepts map to SQL table concepts?
>>
>>Simple, they hardly do. OO concepts are way too imprecise to be
>>mapped to the rigor of database theory.
>>
>>I suggest you take a look to some of Date's books where he treated
>>that subject.
>
> Ah, at last we are getting somewhere. Any pointers to books?
Google "third manifesto"
> Any quick'n dirty synopses of the arguments?
No.
>>>It's a trivial question that I have found no clear answer
>>>for, neither in my books or here. Check out a textbook
>>>on C++, 'You Can Program in C++' by Glassborow. It is
>>>intended for programmers who know some other programming
>>>language and want to learn C++. The author includes a
>>>number of sections on how C++ is similar and different
>>>to a number of languages, like C, Java, Fortran, etc.
>>>While the section doesn't tell anything a programmer who
>>>knows both C++ and, say, Java knows, it summarizes it
>>>up front so that the newbie has a chance to sort out
>>>'philosophical' and practical differences. This kind
>>>of thing would be immensely helpful for somebody who
>>>just starts out.
>>
>>Or maybe you just are not ready to accept the answer as it is. set
>>oriented approaches are radically opposites of procedural approaches.
>
> Ah, 'set oriented vs procedural approach'. The first time
> I see it. Any synopses on *how* they are different?
One approach expresses logic directly at the level of intent and the
other expresses steps at the level of a physical computational model.
>>>I ask the same question: How is SQL different and similar
>>>to what I already know.
>>
>>In ways you can not tell if you do not go through a self learning
>>process of education in database concepts. If you believe this is not
>>necessary and OO concepts are sufficient to understand database theory
>>then it will be difficult to help you.
>
> I hoped for useful answers. After two days and who-cares-
> how-many-posts, key words at last seem to trickle into
> the replies.
You must not have been listening earlier, then.
>>>This simple question has not been answered. Instead,
>>>you seem to suggest that object orientation is *not* a
>>>useful context for system analysis or design, generally
>>>or with databases.
>>
>>Well that's is a correct assertion.
>
> Huh?
A most eloquent expression of ignorance. Well said!
>>>If these impressions are indeed correct, please state
>>>it unequivocally, and I will stop wasting my and
>>>everybody else's time.
>>
>>This is the last post I am making to help you out. My time is as
>>limited as yours.
>>
>>>>Don't you think this is a hasty harsh judgment on your part ?
>>
>>>No. The database community (posters here, textbooks) seem
>>>unable to answer the one, simple general question any
>>>programmer unfamiliar with SQL will ask.
>>
>>I believe on the contrary that the question has been answered very
>>clearly by several people. The fact that you accept this response or
>>not is another matter. That is no reason for blaming an entire
>>community.
>
> I'm blaming the community because members seem systematically
> unable to project themselves into the shoes of a newbie, and
> are thus unable to see the subject from the newbie's perspective.
Newbies--real, honest to goodness, self-aware newbies--seldom dictate
the terms of an education.
Bob Badour
Not "futile". "Counter-productive". Crippling a higher-level abstraction
down to the level of a relatively primitive computational model is not
the brightest idea.
Bob Badour
Hi Jan! Long time no see.
What do you recognize as the OP's problem? What would you say to sort
out the misunderstandings and snags?
Bernard Peek
<ebb2fda2-f8ef-4f52...@g20g2000vba.googlegroups.com>,
cim...@hotmail.com writes
>On 9 juin, 17:30, Bernard Peek <b...@shrdlu.com> wrote:
>> In message
>> <439c733f-05f3-4240-a009-c13dae47d...@r34g2000vba.googlegroups.com>,
>> dr.coff...@gmail.com writes
>>
>>
>>
>> >I'm blaming the community because members seem systematically
>> >unable to project themselves into the shoes of a newbie, and
>> >are thus unable to see the subject from the newbie's perspective.
>>
>> >That's a sign of a professional community well on its way
>> >to professional degeneracy.
>>
>> At the moment relational theory seems to be so effective at handling
>> low-level database management that I think that its practitioners are
>> quite right in considering themselves an essential component of
>> efficient systems design.
>What is low level database management? What is high level database
>management?
In this context high-level database systems are object-oriented. The
analogy is with high and low-level programming languages.
>
>> On the other hand from an OO practitioner's point of view relational
>> theory is a quite little backwater that doesn't have much applicability
>> in the real world.
>There seem to be a contradiction between this statement and the
>previous. How can you claim that relational theory is effective into
>handling some database management and then denounce its lack of
>applicability.
Please re-read what I actually said.
>
>> I don't see an inherent conflict between these views and both are very
>> probably true.
>Much have been written on the subject but I remember reading somewhere
>that a perfect OODBMS is nothing else than a TRDBMS...
>> Bernard Peek
>
--
Bernard Peek
cim...@hotmail.com
> cim...@hotmail.com writes
>
>
>
> >On 9 juin, 17:30, Bernard Peek <b...@shrdlu.com> wrote:
> >> In message
> >> <439c733f-05f3-4240-a009-c13dae47d...@r34g2000vba.googlegroups.com>,
> >> dr.coff...@gmail.com writes
>
> >> >I'm blaming the community because members seem systematically
> >> >unable to project themselves into the shoes of a newbie, and
> >> >are thus unable to see the subject from the newbie's perspective.
>
> >> >That's a sign of a professional community well on its way
> >> >to professional degeneracy.
>
> >> At the moment relational theory seems to be so effective at handling
> >> low-level database management that I think that its practitioners are
> >> quite right in considering themselves an essential component of
> >> efficient systems design.
> >What is low level database management? What is high level database
> >management?
>
> In this context high-level database systems are object-oriented. The
> analogy is with high and low-level programming languages.
according to what principles you can qualify a system as being high
level or low level. In database theory, low level = physical level =
procedural languages. What is high level according to OO mindset?
> >> On the other hand from an OO practitioner's point of view relational
> >> theory is a quite little backwater that doesn't have much applicability
> >> in the real world.
> >There seem to be a contradiction between this statement and the
> >previous. How can you claim that relational theory is effective into
> >handling some database management and then denounce its lack of
> >applicability.
>
> Please re-read what I actually said.
I believe I did. I just asked a question. How can something that is
applied on a daily basis have a lack of applicability ?
paul c
...
> Something analogous happens with database design. People who begin
> designing databases based only on prior experience with indexed files, and
> who expect to put all the business logic in the application, end up with
Since business 'logic' is so rarely expressed logically and since most
practitioners have no logical training and haven't bothered to learn
relational algebra, which parallels classical logic in sets (and
possibly exceeds it in expressiveness), this shouldn't be a surprise.
In other words, most practitioners, no matter whether they call
themselves OO programmers or DB designers have not spent time
understanding the implications of the theory. If they had, it would
occur to them that relational theory doesn't mandate where attribute
values come from. They would also have realized that the theory points
to practical implementation questions, such as "is the work to produce
such and such an answer in proportion to the answer?".
Most of what's published offers no foundation to achieve this
understanding, being mostly recipes and examples from which it takes
extraordinary effort to distill the essence, as opposed to blindly
following. Most "newbies" don't even have the advantage of long-time
trench work so it is hard for them to see the lessons of history and
avoid repeating very old mistakes.
It seems such understanding is hard for DBMS implementers too, witnesss
the PhD's in the System R team who not only read Codd but sometimes
worked in the same building with him. They saw quantification in his
calculus bits and must have thought they could implement that, they saw
his algebra and must have thought they could implement that, as long as
they used bags instead of sets and ordered attributes instead of naming
them, they saw R-tables and thought they could implement those. They
ended up implementing some kind of bastard table theory.
It may well be that one cannot read Codd to see his real intent without
a knowledge of the times during which he wrote his first papers. It
will be obvious to anybody who worked around computers then that he was
deliberately making his points in the context of IMS-style db's and the
file systems of the day.
I doubt if one in ten posters here could express a simple key constraint
algebraically. While implementing keys that way would be silly, one
will not have a solid foundation for understanding the uses for keys
without being able to do it on paper. As various posts here show, there
is wide-spread confusion about more subtle constraints, such as
transition constraints. Without a basic understanding most posters are
reduced to mysticism.
The essential relational theory is very small, in text, it's perhaps
only one percent of the size of the SQL standard. I would go so far as
to say that it needn't include type theory. Somebody here referred to
"data modellers and database designers who have to turn theoretical
concepts into database schemas". Well actually, hardly anybody has to
do that, to some degree or other, the theory will have already been
"turned into" a dbms, no doubt incorrectly in places. The sensible
practitioner needs to know what those places are, so that he can
recognize the deviations from theory. There are regular questions here
along the lines of "I have this application, but I can't identify the
attributes I need". Well, actually, those posters are dreaming, they do
not even "have" an application, because they cannot even name what they
are talking about, which is a sine qua non for entering into design.
This leads to endless talk about "what is an identifier?", which is not
a relational theory question. It is a consequence of the faithful
technocrat's blind reason to want to see apps where there are none and
there are some here who will grope endlessly in that pursuit. They are
actually talking about interpretations about which relational theory
says nothing. They habitually fail to recognize this and refuse to
offer any kind of formal interpretation theory. I suspect Darwin (not
Darwen) if he were alive today would recognize the mystic guild as one
of the natural manifestations of his ideas.
In fact, they are talking stupidly and I think of it as an evolutionary
necessity to call them on that, the goal being not to illuminate the
poster, but to remind naive non-posters that the full moon is once again
on the rise. Some people are too stupid to know they are stupid, but
those aren't the people of interest. Any student of history will know
that progress and politeness are contradictory. The people who are
capable of both reading and thinking will also occasionally say
something stupid but that small minority soon stops huffing and puffing
and re-asseses their position.
OO programmers should get off their various indulgent cans such as
'reuse' and try to realize their place in all this, apart from the rare
true simulations, in an ideal evolution of the world their purpose would
be mainly to provide equality tests for types, sometimes they might be
permitted to code GUI event handlers. For evidence they need only
remember the questions they were asked at their commercial job
interviews, most of which would not have needed any fundamental
knowledge in order to answer.
Bob Badour
That seems to define 'demo system', but I see nothing there to define
'working'.
> Everybody are happy and time-wasting stress factors are
> removed.
Your definition of 'working' appears to revolve around happiness and
stress factors. Would it make your customers happy to discover their
data are incomplete, incorrect, or inconsistent? If those sorts of
things would stress them or waste their time, I respectfully suggest you
would do them a service by educating yourself first instead of seeking
to learn by making mistakes.
>>>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.
>>
>>Hands-on experience is no substitute for fundamental education. If we
>>had to rely on hands-on experience for multiplication, I doubt anyone
>>would have ever progressed beyond the 12 times tables.
>
> I know. But I'm doing this on my own, and am just starting out.
> I have a few books lying around that I need to make sense of.
> Naively, I thought asking experts for help would be useful.
I am not sure whether naive is the right word. It seems to me you have
been given very useful help, and the problem originates in your
insistence that your uninformed preconceptions can dictate what is
useful or helpful.
>>>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.
>>
>>Am I hearing you correctly? You worked very hard to force your brain to
>>think in terms of a single physical computational model? That's
>>unfortunate and must be very limiting. No doubt you will have to work
>>equally hard to overcome that impediment.
>
> Well, my basic programming training (I'm not a programmer but a
> data analyst by vocation)
How ironic. What studies did you complete to qualify as a data analyst?
> was in terms of assembler-style GOTO
> constructs and procedural programming. After a while I found
> that these styles or models were far too limiting for the
> types of problems I worked at. I had to make a serious effort
> to learn OO in general and C++ in particular. These days I think
> in terms of class hierarchies and policies.
Well, I can certainly see how moving from an even lower-level
computational model to another physical computational model would seem
like a great advance.
> Your name and location suggest your native language is English.
> If correct, you likely do not know a second language very well.
> Bilingual people will know that different languages tend to be
> useful for expressing different things. My native language is
> not English, but all my professional training was in English.
> Which has had the effect that I am unable to think about
> professinal questions in my native language. I find that I
> always refer to English terms when discussing work.
Dijkstra noted the advantages of coming to programming with english as a
second language.
> OO and policies has had the same effect, and have worked well
> enough that I haven't needed to look back. Until I encountered
> databases and SQL.
The problem is you haven't yet realized that databases (and even SQL as
flawed as it is) require looking forward not back from your current
position.
>>>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.
>>
>>I am not sure what use you would make of OO terminology. It's all rather
>>nebulous, overloaded and imprecise. None of it is any good for
>>communicating much of anything.
>
> Ever heard of a 'class'? 'Supertype'? 'Specialization'?
Of course. I wouldn't make statements about nebulosity, overloading and
imprecision if I hadn't.
> Teorey uses UML to communicate problems and solutions
> in the context of databases. Just as lots of folks do
> with OO programming. The concepts are the same everywhere.
> Terminology differs.
UML borrows heavily from ER, which itself was a misguided attempt to
create a graphical crutch. Graphical analysis often misleads and hinders
understanding by fostering preconceptions. You will do yourself a great
service to learn to think without that crutch.
>>>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.
>>
>>Philosophy?
>
> Yes, philosophy. It seems you are young enough that your
> basic training was in terms of OO concepts. I can assure you,
> when your basic training is in terms of procedural programming,
> the transition to OO is one of philosophy.
I was programming quite extensively in a variety of languages for 5 or 6
years before I was ever exposed to an OO concept.
OO certainly has a slightly different aesthetic from other computational
models, and of course, linguistic differences fall under the philosophy
of language. Logic is still pretty much the same, however. And the
relational model has much closer and deeper association with logic. It
has in fact contributed quite a lot more to the topic.
>>An n-dimensional relation of arbitrary domains is 'trivial'?
>
> No. The individual tables are trivial, not the overall relation.
A table is an n-dimensional relation of arbitrary domains.
<elaboration based on false assumption snipped>
> Referring back to natural languages, it is a very humbling
> experience to arrive in a place where you have no language
> in common with the natives. One is essentially set back to
> the level of a toddler, struggling to interact over the
> simplest things. As English becomes more and more wide-spread,
> native English-speakers would not have this experience.
It is even more humbling to arrive in a place that nominally speaks the
same language as oneself and to discover on cannot make out a word
anyone is saying.
> Now, it makes no sense to mock people who ask about databases
> because they do not know English. It makes no sense to mock
> people who want to get help with basic terminology because
> they do not know basic terminology.
I am sorry you feel mocked.
> The database community can handle this in a couple of ways:
>
> 1) Close in on yourself and mock people who do not have the
> insights you have.
> 2) Recognize the problem and help sort out the misunderstandings
> and snags.
>
> Over the past couple of days I have got a clear impression about
> what approach seems to be preferred by the regulars here.
>
> Dr. C.
Interesting. What if one recognizes the problem is a simple lack of
fundamental education? What if the misunderstandings and snags spring
from a newbie's false but deeply ingrained assumptions?
Bernard Peek
<70ba4afc-8f87-43aa...@f19g2000yqo.googlegroups.com>,
cim...@hotmail.com writes
>> >> At the moment relational theory seems to be so effective at handling
>> >> low-level database management that I think that its practitioners are
>> >> quite right in considering themselves an essential component of
>> >> efficient systems design.
>> >What is low level database management? �What is high level database
>> >management?
>>
>> In this context high-level database systems are object-oriented. The
>> analogy is with high and low-level programming languages.
>I am having difficulties understanding you. Could you state
>according to what principles you can qualify a system as being high
>level or low level. In database theory, low level = physical level =
>procedural languages. What is high level according to OO mindset?
Higher level languages deal with more abstract concepts that are closer
to the way non-specialists view them. So I see the relationship between
OO and RM as essentially similar to that between COBOL and Assembler.
Whether or not you agree with this characterisation it's the prevailing
view in software engineering now.
I'll extend the analogy a bit further. In the past assembler languages
were used to coax the last bit of performance from limited hardware. Now
it's usually easier to upgrade the hardware than to rewrite code in
assembler. But the people who write compilers still occasionally need to
rewrite critical sections of code in assembler.
By analogy, most developers use OO analysis and coding techniques. They
aren't concerned with RM at all. But there are still some people who
need to get maximum performance from database systems. Those are the
DBAs and the compiler writers who write the driver software that
interfaces between OO languages and relational databases.
>
>> >> On the other hand from an OO practitioner's point of view relational
>> >> theory is a quite little backwater that doesn't have much applicability
>> >> in the real world.
>> >There seem to be �a contradiction between this statement and the
>> >previous. �How can you claim that relational theory is effective into
>> >handling some database management and then denounce its lack of
>> >applicability.
>>
>> Please re-read what I actually said.
>I believe I did. I just asked a question. How can something that is
>applied on a daily basis have a lack of applicability ?
That wasn't what I said. I said that *from the OO practitioner's point
of view* RM has little applicability. So I don't see any conflict
between the two viewpoints.
--
Bernard Peek
Bob Badour
> On 9 Jun, 14:49, cim...@hotmail.com wrote:
>
>>Snipped
>>
>>>The database community can handle this in a couple of ways:
>>
>>>1) Close in on yourself and mock people who do not have the
>>> insights you have.
>>>2) Recognize the problem and help sort out the misunderstandings
>>> and snags.
>>>Over the past couple of days I have got a clear impression about
>>>what approach seems to be preferred by the regulars here.
>>
>>Let me get this straight. You need help from the database community
>>for a design exercice but you need that help to be done according to
>>the principles you believe are universal (whatever these may be).
>
> As for my starting point, I have made the observation that
> object orentated designs and methodologies are more or less
> universally useful in programming and general system analysis.
That's like saying shovels are more or less universally useful in
digging holes, but for some holes, a dozer, back-hoe or loader will work
much better.
> Check the textbooks in just about any such activity, be it
> programming, buisness modelling, XML or UML.
99.9% of the textbooks you will find on the programming shelf in any
bookstore are pure, unadulterated crap. An entire industry revolves
around ignorant people repeating ignorant people. As a general rule, at
any given time, the truly useful texts take up no more than 6 inches of
shelf space.
> My personal
> experience coincides with this impression - OO is a very
> useful tool.
If one assumes a low-level physical computational model, it is useful.
The relational model and SQL don't make that assumption.
> I have also made the observation that object oriented
> *terminology* is absent from the database texts I have
> available. I don't recognize the concepts I am familiar
> with in what I read about databases. I'm not saying they
> are absent; I'm saying they have taken a different guise.
>
> In my first post:
>
> "I have a problem with wrapping my mind into the 'right' wrinkles."
>
> "The [system] would be almost trivial to implement in an
> object-oriented context [...],
> but I don't see how to come up with a table-based database
> design."
>
> In my second post:
>
> "The problem is that I think in OO terms, like classes and
> inheritance."
>
> "So in the 'naive' problem statement I see an array of objects
> of classes derived from a base class [...], 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."
>
> So it would be immensely helpful if somebody could
> come up with a general comment about
>
> 1) If OO concepts can be handled at all in SQL databases.
> 2) If so, how it is done.
Thank you for repeating what you wrote earlier. I am quite capable of
reading and comprehending written english the first time, however. For
your edification, I will repeat what I wrote on the topic:
"I am not sure what use you would make of OO terminology. It's all
rather nebulous, overloaded and imprecise. None of it is any good for
communicating much of anything."
> As I'm getting older, I don't appreciate building a big
> picture from gazillions of details. I rather prefer to
> get the big picture first, and then fill in with the
> deatils.
The big pictures are predicate logic and set theory. I find the above
paragraph ironic because when I tried to lead you to the big picture you
seemed to object that I didn't give you the details you asked for.
>> All
>>I have seen so far are goodwill people who wanted to help you by
>>advising you to do some reading necessary to understand some basic
>>principles of database design. In a word, you ask a question and
>>because you don't like the answer you now imply that the *regulars*
>>have closed themselves and mocked you.
>
> I have asked the one question that just about everybody
> with a little bit of OO programming experience will ask
> when entering the world of SQL databases:
>
> How do OO class concepts map to SQL table concepts?
Ignoring the nebulosity and overloading of the OO terms, the term
"object class" maps to the concept of data type.
> I ask the same question: How is SQL different and similar
> to what I already know.
SQL is a deeply flawed approximation of predicate calculus.
>>Don't you think this is a hasty harsh judgment on your part ?
>
> No. The database community (posters here, textbooks) seem
> unable to answer the one, simple general question any
> programmer unfamiliar with SQL will ask.
>
> That's a problem with the database community, not the
> question.
The widespread ignorance of fundamentals among the programming community
is not the fault of the database community or of anyone other than the
programming community.
paul c
...
> Higher level languages deal with more abstract concepts that are closer
> to the way non-specialists view them. So I see the relationship between
> OO and RM as essentially similar to that between COBOL and Assembler.
Given that (as we see in c.d.t) there is a general inability to abstract
and if it is actually so that OO is a 'higher' abstraction (which I
doubt anyway), the conclusion would be instead that most people who
think they are applying OO must be incompetent.
cim...@hotmail.com
> >I am having difficulties understanding you. Could you state
> >according to what principles you can qualify a system as being high
> >level or low level. In database theory, low level = physical level =
> >procedural languages. What is high level according to OO mindset?
>
> Higher level languages deal with more abstract concepts that are closer
> to the way non-specialists view them. So I see the relationship between
> OO and RM as essentially similar to that between COBOL and Assembler.
by the audience that uses it.
What abstracts concepts are you refering to? Could you name them ?
What is in your perspective, the difference between COBOL and
Assembler ? To me they are both low level languages.
> Whether or not you agree with this characterisation it's the prevailing
> view in software engineering now.
I only agree/disagree with what I understand. So far I have hard time
making sense of what you are trying to express.
> I'll extend the analogy a bit further. In the past assembler languages
> were used to coax the last bit of performance from limited hardware. Now
> it's usually easier to upgrade the hardware than to rewrite code in
> assembler. But the people who write compilers still occasionally need to
> rewrite critical sections of code in assembler.
Are you refering to performance aspects ? Are you defining what a high
or low level language according to how it performs. I am sorry but
you are confusing me.
> By analogy, most developers use OO analysis and coding techniques. They
> aren't concerned with RM at all. But there are still some people who
> need to get maximum performance from database systems. Those are the
> DBAs and the compiler writers who write the driver software that
> interfaces between OO languages and relational databases.
OK. Maybe they should. I often have to fix their blunders in
production (loss of data integrity, poor perfomance due to poor SQL
database design, you name it)
>
>
> >> >> On the other hand from an OO practitioner's point of view relational
> >> >> theory is a quite little backwater that doesn't have much applicability
> >> >> in the real world.
> >> >There seem to be a contradiction between this statement and the
> >> >previous. How can you claim that relational theory is effective into
> >> >handling some database management and then denounce its lack of
> >> >applicability.
>
> >> Please re-read what I actually said.
> >I believe I did. I just asked a question. How can something that is
> >applied on a daily basis have a lack of applicability ?
>
> That wasn't what I said. I said that *from the OO practitioner's point
> of view* RM has little applicability. So I don't see any conflict
> between the two viewpoints.
OK.
Walter Mitty
>> dr.coff...@gmail.com wrote:
>> > Hi folks.
>>
>> > 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.
> 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
> working system.
>
> The problem is that I think in OO terms, like classes and
> 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.
>
> 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.
>
> SQL is constrained to 'trivial' arrays. The problem is the
> vast philosophical distance between the two problem statements,
> that I am unable to bridge.
>
> 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.
>
paul c
...
> 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.
Not to criticize the rest of the post, but regarding ACID, Date, for
one, has pointed out that it is flawed, rather ironically, in that it
doesn't prevent a single user of a db from violating integrity, assuming
they are using an 'imperative' language.
Walter Mitty
"paul c" <toledob...@oohay.ac> wrote in message
news:nZxXl.31160$PH1.11785@edtnps82...
It wasn't my point to guide the OP into the "correct" view of every aspect
of database theory. Rather, I was trying to respond to hes need for
keywords to guide him in browsing the Teorey book. I don't know which of
these keywords are even covered in Teorey. But hopefully my list will be
helpful in places.
Actually, ACID has very little to do with the relational model as such.
I've seen non relational systems (graph databases) that apply ACID rules to
transactions. The concepts play out almost identically.
Tegiri Nenashi
> Data Normalization. I don't know what this corresponds to in OO design.
Refactoring?
dr.co...@gmail.com
> <dr.coff...@gmail.com> wrote in message
> 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 object-
like 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.
Gene Wirchenko
Since the two areas are different, why strain at correspondences?
Normalisation is during design. Refactoring is after the fact.
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
Bob Badour
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?
Walter Mitty
"Gene Wirchenko" <ge...@ocis.net> wrote in message
news:b0it25h2ai2ag1qgh...@4ax.com...
> Tegiri Nenashi <Tegiri...@gmail.com> wrote:
>
>>On Jun 9, 11:27 am, "Walter Mitty" <wami...@verizon.net> wrote:
>>> Data Normalization. I don't know what this corresponds to in OO design.
>>
>>Refactoring?
>
> Since the two areas are different, why strain at correspondences?
>
> Normalisation is during design. Refactoring is after the fact.
>
Actually, normalization is a bottom-up approach, and is done after the fact.
After the fact of coming up with an unnormalized model. If you do modeling
*correctly*, your model will be normalized as soon as you build it, and you
don't have to go through the rigmarole of converting the schema into another
equivalent schema that acheives a higher normal form, and repeating that
exercise.
Having said that, I never learned how to model data *correctly*, so I ended
up normalizing during design time, just as you say.
none Reinier Post
>> I have asked hundreds of OO programmers in the past about a definition
>> about what an object and each of them came with a totally different
>> definition.
But it's pretty much clear what a UML class diagram is, isn't it.
>You are a database desinger, right? Do you ever use the
>'entity-relation' method when you design a database?
>If so, what is an 'entity'?
The entity-relationship method is often used, advocated and taught
for the design of databases. The design starts by creating
an entity-relationship diagram, that is systematically transformed
and provided with implementation detail until an ER diagram results
that specifies a relational database schema.
An ER diagram is a representation of the relations (tables)
and foreign key relationships in a relational database schema.
The relations in the schema are the entities and many-to-many
relationships in the ER diagram; the foreign keys are the
one-to-many relationships and the links between many-to-many
relathipships and entities in the ER diagram. Every ER diagram
can be created out of a relational schema in this way, but not
every relational schema corresponds to an ER diagram; certain
limitations on the structure of the structure of the foreign keys
apply.
Entity-relationship diagrams and UML class diagrams are very closely
related. The entity sets in an ER diagram correspond to the classes
of an ER diagram; the relationship sets to associations.
There are also many differences, but the starting point is the same.
[...]
>> > In my first post:
>>
>> > "I have a problem with wrapping my mind into the 'right' wrinkles."
>>
>> > "The [system] would be almost trivial to implement in an
>> > object-oriented context [...],
>> > but I don't see how to come up with a table-based database
>> > design."
Think 'class' ~ 'relation' (table), 'reference' ~ 'foreign key',
'object' ~ 'tuple' (row), 'object model' ~ 'database schema'.
But don't equate them: there are important differences.
One is that objects can hold references to objects, while
a database table can only hold attribute values. This is often
resolved by adding a (usually autonumbered) special attribute
to relations that is guaranteed to be unique for each tuple,
and can therefore be used by way of tuple reference; this may
or may not be a good idea, depending on your purpose and
whom you talk to. Tools exist that automatically map a class model
to a relational database using this idea, but some people in this group
are very much against it. They think one should start with
a relational model and when possible only use 'natural' attributes,
i.e. ones with values we humans can observe, otherwise you
run the risk of creating structures with unnecessary levels of
references, duplication of information, and other issues.
The main thing is that the technical differences may appear
small, but the whole approach to handling data is different,
and you can't expect to pick up such differences nmerely by
participating in a newsgroup discussion.
[...]
>> > 1) If OO concepts can be handled at all in SQL databases.
>> > 2) If so, how it is done.
Well, sometimes you have 'data' classes that do little but
define a bunch of properties with simple values, and you create
and manipulate collections of such objects; such classes and
collections are a quite like database tables. Inheritance
is also a very useful notion in database design, if we apply
it to properties (attributes, columns) only. But nothing
corresponds to the notion of method. Methods invite
class-specific, object-by-object manipulation techniques;
SQL on the other hand is essentially a language that maps
tables to tables with operations such as row selection,
column selection (projection), union, and join. You don't
manipulate or navigate iundividual values and rows, databases
weren't designed for that.
>> Or maybe you just are not ready to accept the answer as it is. �set
>> oriented approaches are radically opposites of procedural approaches.
>
>Ah, 'set oriented vs procedural approach'. The first time
>I see it. Any synopses on *how* they are different?
Set-oriented: you apply operations on whole sets at once.
Non-procedural: you don't change variables, but yield results.
It's a bit like doing all your programming with functions that take
collections and iterators and return resulting collections and iterators.
>> > I ask the same question: How is SQL different and similar
>> > to what I already know.
>>
>> In ways you can not tell if you do not go through a self learning
>> process of education in database concepts. �If you believe this is not
>> necessary and OO concepts are sufficient to understand database theory
>> then it will be difficult to help you.
Some people in this newsgroup believe that the relational model
is sacred, its inventor Codd was a holy man, and a guy called Date
who has written a bunch of popular books on the subject is his
replacement on earth. Anything you say to suggest that other people have
something intelligent to contribute on the subject, or have already done
so, perhaps using slightly different ideas or terminology, is met with
the scorn only dogmatists can muster. Pay attention to their ideas,
ignore their attitude.
>I'm blaming the community because members seem systematically
>unable to project themselves into the shoes of a newbie, and
>are thus unable to see the subject from the newbie's perspective.
Not only newbies, anyone with different ideas or different terminology.
This problem is hard to avoid in human communication, but it seems
particularly bad in computer science.
--
Reinier
Bernard Peek
<wam...@verizon.net> writes
Some years back I was handling support for a CASE tool that handled
normalisation. The users didn't want a tool that took them through the
various stages, they assumed that the first time they committed a
structure to the system it would already be in TNF - which was as far as
they were interested in.
--
Bernard Peek
Walter Mitty
<dr.co...@gmail.com> wrote in message
news:35fe9916-b423-49e4...@x5g2000yqk.googlegroups.com...
>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.
If the mapping between OO concepts and RM concepts were simple, someone
would have, by now, written a book that ties the two of them together, and
explains both patterns in terms that makes sense. to someone coming from one
pattern or the other. To my knowledge, there is no such book. I'm going to
echo something Bernard said in another response.
Better minds than mine have attempted to reconcile the OO way of thinking
and the RM way of thinking with each other. By their own reckoning, their
attempts have been unsuccessful.
So you really shouldn't expect to reduce RM to a pattern that you already
know. And you shouldn't expect, based on your success with OO up to this
point, to be able to treat RM as something that can be marginalized as
either a specialized niche or a trivial development. It is neither.
Possibly the best person to speak to this would be Marshall. Marshall is a
regular here who spend at least ten years as an OO programmer before going
over to the RM side. He might be able to relate to what you do and do not
understand at your present stage.
Meanwhile, I need to correct the general thrust of my first response to
you. In that response, I contrasted the OO way of thinking with the SQL way
of thinking. That completely overlooks the fact that your target is to
build an Access application that stores and serves up data for analysis with
Excel. Much of what I said, while true, is beside the point. You can, in
fact, build a simple yet functional MS Access application without learning
much of any relational theory and without gaining much of any proficiency in
SQL. Sadly, I can't help you do that, because I learned SQL before my first
exposure to Access. So everything new that I learned in Access was
something that I related back to what I already knew in SQL. After playing
around with some wizard for a while, I would switch to the "SQL view" in
order to "Find out what's really going on".
That was a useful way for me to understand it, but may be the long way
around for you.
Like you, I like to learn the big picture first, and then fill in all the
details. I was fortunate to learn the big picture of relational (or at
least SQL) databases back in the 1980s, when there was less to learn. I
find MS Access tutorials to be infuriating, because they all approach the
subject matter as if there is no big picture. Here's how you chage the font
in a dialogue box. And here's how you declare a primary key. And here's
how you use the forms wizard to create a form. Gee whiz! Isn't that
wonderful! But there's no central unifying theme in the narrative.
Anyway, it turns out you can do almost everything in design mode that you
might be able to do by learning the syntax and semantics of SQL DDL and DML.
And all you have to do is point and click, most of the time. And, because
MS Access integrated application building with database building, you end
up building a functioning application alongside the building of a working
database. That's no small benefit. I actually built some useful stuff for
myself using MS Access without really learning it. I hope somebody who
really has learned it can help you more than I can. In the meantime, I'm
going to focus on some sidelights.
MS Access owes a lot to its heritage. It was built to make desktop
database work available to the same kind of person who was comfortable with
Excel or Word. Desktop database work is very different from enterprise
integration database work. Access was typically for one user at a time. It
wasn't easy to get data into an access database, except by interactive data
entry. If you were dealing with more than 10 million rows, you were
probably maxed out. And so on. Over the years, it has matured to where it
has overcome a lot of the initial limitations. But it still looks like a
strange beast, to those of us who grew up with industrial strength DBMS
products. It would be sort of like Object Oriented COBOL, if you get my
drift.
If you learn MS Access from the ground up, you are going to learn several
things about the RM that just ain't so. That is why some of the regulars
are chiding me for encouraging you. The design patterns that work for you
are design antipatterns at the larger scale. That may not matter to you, at
least for a while.
There is one antipattern that I want to mention in particular. Your problem
description, in the original post, reminds me of the Entity-Atrribute-Value
(EAV) antipattern. Different insrument types are like different entities,
different calibrations are like different attributes, and different
measurements are like different values. The terible thing about EAV is the
hell you have to go through to create meaningful queries out of that mess,
if you're using SQL or any language remotely like it.
But there is a tool that can reduce an EAV data glob to a legible summary
without much difficulty. It's the Pivot Table Report in MS Excel. A pivot
table doesn't care whether the row headers and column headers are data or
metadata. It's all databurger to the pivot table. So, if your plan is to
simply pump data into Excel, and reduce it there, you may be able to get
away with an EAV like design, in spite of the fact that people like me
consider it a monstrosity.
none Reinier Post
>> My personal
>> experience coincides with this impression - OO is a very
>> useful tool.
>
>If one assumes a low-level physical computational model, it is useful.
>The relational model and SQL don't make that assumption.
That is because they don't address the same problems.
As long as you're happy manipulating typical business data
in a database, the relational model is all you need.
As soon as you try to build working software systems,
some considerations arise that the relational model
has nothing to say about. E.g. how do we design and implement
a GUI to present data and allow their manipulation? How do
we split systems into parts that can be designed and implemented
independently and can be reused? OO was created to address
these issues. Relational theory doesn't. Besides, OO is
neither low-level nor a computational model.
--
Reinier
Bernard Peek
<rp@raampje.?.invalid> writes
>>> I am not aware of any precisely and consensually OO defined concept.
>>> I have asked hundreds of OO programmers in the past about a definition
>>> about what an object and each of them came with a totally different
>>> definition.
>
>But it's pretty much clear what a UML class diagram is, isn't it.
>
>>You are a database desinger, right? Do you ever use the
>>'entity-relation' method when you design a database?
>>If so, what is an 'entity'?
>
>The entity-relationship method is often used, advocated and taught
>for the design of databases. The design starts by creating
>an entity-relationship diagram, that is systematically transformed
>and provided with implementation detail until an ER diagram results
>that specifies a relational database schema.
>
>An ER diagram is a representation of the relations (tables)
>and foreign key relationships in a relational database schema.
That's the physical data structure which describes the way the database
has been built. That's often derived from the logical (and sometimes a
separate conceptual) data structure. That's where the objects on the
diagrams are entities. Entities and tables are not the same thing.
The ERD is an entity relationship diagram which details the logical or
conceptual structure which is then used as a basis for a physical
design.
Entities loosely map to classes in that there are instances of each
entity which vaguely map to objects as instances of a class.
One thing to be aware of is that different design methodologies use
entities and ERDs in slightly different ways. Some have the concept of a
sub-entity, others don't.
--
Bernard Peek
Bob Badour
>>>>In my first post:
>>>
>>>>"I have a problem with wrapping my mind into the 'right' wrinkles."
>>>
>>>>"The [system] would be almost trivial to implement in an
>>>>object-oriented context [...],
>>>>but I don't see how to come up with a table-based database
>>>>design."
>
>
> Think 'class' ~ 'relation' (table)
But that would not only be a blunder but a great blunder.
>>>>I ask the same question: How is SQL different and similar
>>>>to what I already know.
>>>
>>>In ways you can not tell if you do not go through a self learning
>>>process of education in database concepts. If you believe this is not
>>>necessary and OO concepts are sufficient to understand database theory
>>>then it will be difficult to help you.
>
> Some people in this newsgroup believe that the relational model
> is sacred, its inventor Codd was a holy man, and a guy called Date
> who has written a bunch of popular books on the subject is his
> replacement on earth.
You are an idiot if that is what you honestly believe.
Bob Badour
> Bob Badour wrote:
>
>>>My personal
>>>experience coincides with this impression - OO is a very
>>>useful tool.
>>
>>If one assumes a low-level physical computational model, it is useful.
>>The relational model and SQL don't make that assumption.
>
> That is because they don't address the same problems.
Au contraire.
> As long as you're happy manipulating typical business data
> in a database, the relational model is all you need.
You don't have a clue what you are talking about.
> Besides, OO is
> neither low-level nor a computational model.
Really? Define OO.
none Reinier Post
>>An ER diagram is a representation of the relations (tables)
>>and foreign key relationships in a relational database schema.
>
>That's the physical data structure which describes the way the database
>has been built. That's often derived from the logical (and sometimes a
>separate conceptual) data structure. That's where the objects on the
>diagrams are entities. Entities and tables are not the same thing.
They are the same thing regarded at a different level of abstraction
and a different level or detail. They do map to each other.
Every ER diagram maps to a relational schema after certain
transformation steps, and many relational schemas map to
ER diagrams of a particular type.
>The ERD is an entity relationship diagram which details the logical or
>conceptual structure which is then used as a basis for a physical
>design.
I thought that's what I wrote, in different words.
>Entities loosely map to classes in that there are instances of each
>entity which vaguely map to objects as instances of a class.
Yes, for 'entity-like' classes.
>One thing to be aware of is that different design methodologies use
>entities and ERDs in slightly different ways. Some have the concept of a
>sub-entity, others don't.
Yes, is-a (specialization), if used, is one of the constructs that have
to be transformed away, relational schemas don't support it.
--
Reinier
Walter Mitty
"Bernard Peek" <b...@shrdlu.com> wrote in message
news:YsEN5ynC...@shrdlu.com...
> Some years back I was handling support for a CASE tool that handled
> normalisation. The users didn't want a tool that took them through the
> various stages, they assumed that the first time they committed a
> structure to the system it would already be in TNF - which was as far as
> they were interested in.
Some years back, I had occasion to use Data Architect, part of the Power
Designer suite from Sybase.
It had two kinds of data models, a Concpetual Data Model and a Physical
Data Model.
The CDM was basically ER modeling with a few additions. It also supported
user defined domains.
The PDM was DBMS specific, for any one of over a dozen DBMSes. The PDM
included tables, indexes, procedures, yada yada. And also product specific
objects like Tablespaces for Oracle.
If you did the ER model "right", your table came out in 3NF right away. Two
examples of "wrong" ER modeling: attaching an attribute to the wrong
entity, and picking bad keys for your entities. IIRC, you couldn't hang
attributes on relationships. If you had a relationship with attributes, you
had to "reify" it. The word "reify" wasn't in DA documentation. I picked
it up somewhere else. It's right up there with haeccity.
none Reinier Post
>> Some people in this newsgroup believe that the relational model
>> is sacred, its inventor Codd was a holy man, and a guy called Date
>> who has written a bunch of popular books on the subject is his
>> replacement on earth.
>
>You are an idiot if that is what you honestly believe.
That attitude exactly.
--
Reinier
Walter Mitty
"none (Reinier Post)" <rp@raampje.> wrote in message
news:4a2edac9$0$27727$703f...@news.kpn.nl...
> The entity-relationship method is often used, advocated and taught
> for the design of databases. The design starts by creating
> an entity-relationship diagram, that is systematically transformed
> and provided with implementation detail until an ER diagram results
> that specifies a relational database schema.
Back when I learned databases, ER modeling (including diagrams) was NOT
used for design purposes. It was used for data analysis.
analysis and design are easily confused with each other, but they are not
the same thing. The same would go for OOA and OOD.
The fact that database design features don't go into an ER model is not a
limitation of ER. It's a feature.
That means that you can start with ER and from there move forward to
designing relations or SQL tables, or CODASYL sets, or IMS hierarachies or
presumably some kind of persistent objects in an OODBMS, if there were such
a thing.
>
> An ER diagram is a representation of the relations (tables)
Entities are not tables, or relations. It only looks that way.
paul c
...
> But it's pretty much clear what a UML class diagram is, isn't it.
> The entity-relationship method is often used, advocated and taught
Of course it is, along with its ilk, partly because of instructors who
learned by recipe and couldn't write down a predicate if their lives
depended on it. Makes it easier for them to pretend they aren't
copping-out along with the rest of the industry. ER is so lacking in
theory that it's not even a model but most everybody pretends it has
substance, just like the Emperor's new clothes.
Gene Wirchenko
>Bob Badour wrote:
>
>>> Some people in this newsgroup believe that the relational model
>>> is sacred, its inventor Codd was a holy man, and a guy called Date
^^^^^^ ^^^^^^^^
>>> who has written a bunch of popular books on the subject is his
^^^
>>> replacement on earth.
^^^^^^^^^^^^^^^^^^^^
>>
>>You are an idiot if that is what you honestly believe.
>
>That attitude exactly.
I think that what I have caretted shows more bad attitude. You
insult people and then complain about their attitude. I think Bob was
wrong to call you an idiot. He should have called you a fool.
Bob Badour
> rp@raampje.(none) (Reinier Post) wrote:
>
>>Bob Badour wrote:
>>
>>>>Some people in this newsgroup believe that the relational model
>>>>is sacred, its inventor Codd was a holy man, and a guy called Date
> ^^^^^^ ^^^^^^^^
>>>>who has written a bunch of popular books on the subject is his
> ^^^
>>>>replacement on earth.
> ^^^^^^^^^^^^^^^^^^^^
>>>You are an idiot if that is what you honestly believe.
>>
>>That attitude exactly.
Noting Reinier's idiocy does not indicate or communicate anything about
holiness or sanctity.
> I think that what I have caretted shows more bad attitude. You
> insult people and then complain about their attitude. I think Bob was
> wrong to call you an idiot. He should have called you a fool.
No, he is an idiot. He has been here long enough for any reasonably
intelligent person to know how absurd his accusations are. Regardless
whether one uses the term 'idiot' or 'fool', he is demonstrably very stupid.
paul c
> rp@raampje.(none) (Reinier Post) wrote:
>
>> Bob Badour wrote:
>>
>>>> Some people in this newsgroup believe that the relational model
>>>> is sacred, its inventor Codd was a holy man, and a guy called Date
> ^^^^^^ ^^^^^^^^
>>>> who has written a bunch of popular books on the subject is his
> ^^^
>>>> replacement on earth.
> ^^^^^^^^^^^^^^^^^^^^
>>> You are an idiot if that is what you honestly believe.
>> That attitude exactly.
>
> I think that what I have caretted shows more bad attitude. You
> insult people and then complain about their attitude. I think Bob was
> wrong to call you an idiot. He should have called you a fool.
I think one reason the caret'ed names get mentioned so often by the
cognoscenti is that their ideas are so widely misunderstood or ignored.
I can't remember the last time, if there was one, that anyone of the
OO cult quoted any one of the big names and asked of c.d.t, "what does
that mean?" without presuming the answer must necessaryily be couched in
OO jargon . I think this is telling, and detect a certain desperation
in it, whereas hip and un-lazy types like Bob B have made it a point to
look for coherence in OO notions (but when he points out the
incoherence, he is met with bafflegab). Plus, even though I disagree
with Date on a few minor points, the fact is he makes a big effort to
write more clearly than most experts would ever try to match. There is
at least one non-OO mystic here who has obviously read substantial parts
of their writings and mastered parts of it, but he has other problems
such as being a pathological obfuscator, that go beyond what RT could
ever address, so I don't count him in that crowd, even though his raving
could be considered a danger to accurate interpretation. Finally, there
is no inconsistency with posters who illustrate SQL, as long as they
don't pretend it has a coherent theory behind it, personally I welcome
SQL examples that don't pretend to be anything other than practical
technique in an ignorant world..
paul c
...
> Back when I learned databases, ER modeling (including diagrams) was NOT
> used for design purposes. It was used for data analysis.
> analysis and design are easily confused with each other, but they are not
> the same thing. The same would go for OOA and OOD.
> The fact that database design features don't go into an ER model is not a
> limitation of ER. It's a feature.
That's like an old joke, it's not a bug it's a feature! Probably too
late now, I wish, back when ER people first started to try to inculcate
me, that I had the nous to ask them how constraints are specified in ER.
David BL
Actually Reinier is very intelligent. BB is as well. However BB is
also a jerk. Only a jerk would for example, mock the OP who claimed
ignorance and asked for help. For example, the OP said:
"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."
and Bob replies with
"Keywords? Introduction, preamble, prologue, chapter 1.
I would start with one of those. Not sure which
terminology Teorey uses in the 4th edition, but I am
sure you will find something suitable shortly after
Table of Contents."
This is clearly intended to mock, and in a nasty way. It is typical of
BB. Perhaps BB could himself do with some suggestions for reading
material - books with titles like "How to win friends and influence
people".
Of course Reinier was also mocking various regulars in the newsgroup.
However, I found his comment quite amusing - and nothing like BB's
aggressive tone. BB's reaction also suggests lack of balance.
paul c
...
> This is clearly intended to mock, and in a nasty way. It is typical of
> BB. Perhaps BB could himself do with some suggestions for reading
> material - books with titles like "How to win friends and influence
> people".
>
> Of course Reinier was also mocking various regulars in the newsgroup.
> However, I found his comment quite amusing - and nothing like BB's
> aggressive tone. BB's reaction also suggests lack of balance.
Maybe you should count yourself lucky that you didn't get called for
suggesting a paradox could ever be a foundation, aka DVA's!
David BL
What paradox would that be?
paul c
Russell's.
David BL
I know Russel's paradox. What has that got to do with it?
Bob Badour
> David BL wrote:
> ...
>
>> This is clearly intended to mock, and in a nasty way. It is typical of
>> BB. Perhaps BB could himself do with some suggestions for reading
>> material - books with titles like "How to win friends and influence
>> people".
Given I already have friends and I already influence people, I have no
use for Carnegie's recipes for intellectual dishonesty. I suggest that's
more appropriate reading for the snake oil salesmen and
self-aggrandizing ignorants.
>> Of course Reinier was also mocking various regulars in the newsgroup.
>> However, I found his comment quite amusing - and nothing like BB's
>> aggressive tone. BB's reaction also suggests lack of balance.
Or blunt honesty. Twits like Reinier and David are predisposed to see
whatever fantasy they want to see in any case.
> Maybe you should count yourself lucky that you didn't get called for
> suggesting a paradox could ever be a foundation, aka DVA's!
I count myself lucky that my news reader has a twit filter.
Brian Selzer
> rp@raampje.(none) (Reinier Post) wrote:
>
>>Bob Badour wrote:
>>
>>>> Some people in this newsgroup believe that the relational model
>>>> is sacred, its inventor Codd was a holy man, and a guy called Date
> ^^^^^^ ^^^^^^^^
>>>> who has written a bunch of popular books on the subject is his
> ^^^
>>>> replacement on earth.
> ^^^^^^^^^^^^^^^^^^^^
>>>
>>>You are an idiot if that is what you honestly believe.
>>
>>That attitude exactly.
>
> I think that what I have caretted shows more bad attitude. You
> insult people and then complain about their attitude. I think Bob was
> wrong to call you an idiot. He should have called you a fool.
>
While Bob delights in berating and belittling anyone who doesn't share his
limited interpretation of database theory and in bullying those new to the
field, at least he has the stones to be direct about it. What I don't
understand is why he doesn't take offense at your presumption. Why should
it have been Bob that called Reiner a fool? If you think Reiner is a fool,
then why can't you just say it directly and unequivocally? Why should you
have to pawn it off on Bob? Is it that such adolescent behavior is somehow
beneath you? But not beneath Bob?
paul c
What I suggest you do is look for his Intro. to Math. Philo., (it might
help you if you were to concentrate), a pretty skinny book compared to
most in the db field. Unlike his other theoretical stuff, it was aimed
at the the layman, in particular, various self-taught technologists and
interested readers of the time who had been introduced such theory and
spent their Monday evenings at the local scientific society meetings in
pre-WWI Britain, albeit ones whose first language was English. It may
not tell you in five words why DVA's are paradoxes, and it may not tell
most readers why "DA's" (not data administrators, ha, ha), aren't
paradoxes, but it may give you some practice that would help to see why
values that refer to the context that refers to them are a distortion
of the recursion idea. I'd guess you could read parts of it for free on
google books. It pisses me off that various publisers like Cambridge
Univ. help to pay their useless bureaucrats by preserving copyrights of
dead people. On the other hand, this keeps those off the welfare rolls.
It is perhaps the the first book to anticipate Codd, maybe by more
than fifty years.
paul c
...
> I know Russel's paradox. ...
>
Sorry, I forgot to say I don't think you do.
David BL
> paul c wrote:
> > David BL wrote:
> > ...
>
> >> This is clearly intended to mock, and in a nasty way. It is typical of
> >> BB. Perhaps BB could himself do with some suggestions for reading
> >> material - books with titles like "How to win friends and influence
> >> people".
>
> Given I already have friends and I already influence people, I have no
> use for Carnegie's recipes for intellectual dishonesty. I suggest that's
> more appropriate reading for the snake oil salesmen and
> self-aggrandizing ignorants.
Not having read that book myself, I could not say whether it contains
recipes for intellectual dishonesty. However I think BB would do well
to think about the idea of being able to influence a wider audience.
The importance of the relational model need to be pushed, and BB is
talented enough to do so. I often find myself reading his posts for
words of wisdom, despite my distaste for his personality.
paul c
Bob B knows more (about this subject, maybe not others, such as HVAC)
than Gene, who posts more about practice, and I suspect that Gene knows
it, which suggests that he actually knows more than he says, and doesn't
play around about it when he enters theory and good for him. From their
material it is clear that they both have worked to find good grounds for
their confidence in the opinions they have about the aspects of the
subject they choose to comment on, as far as they go, which is among the
finest human traits. Everything else is genes. Both have more posts
that I have marked 'important' or 'work' than any other poster here.
You are off on an irrelevant tangent, hand-waving, as usual, but on an
different tack than usual.. I tbink words like 'limited' reveal an
underlying resentment towards people who are capable of incisiive
abstraction.
David BL
I never suggested that a value would refer to the context that refers
to it. Definately not. Why do you think that?
There is nothing self-contradictory about a relation type that uses a
database type as the domain type for one of the attributes, meaning
that values of that domain type are sets of named relation values.
In the same way that one can static type relations by the names and
types of the attributes, one can static type databases by the names
and types of the relations. This would tend to avoid recursive type
definitions when using DVAs - not that recursive types should be
regarded as a problem in general.
paul c
...
> There is nothing self-contradictory about a relation type that uses a
> database type as the domain type for one of the attributes, meaning
> that values of that domain type are sets of named relation values.
Sorry, I may have made a mistake by assuming that English is your first
language. What you are suggesting only works in conventtional theory if
the relation values are values of the same relation type, in which case
you tare talking about RVA's, not DVA's. Unless you have a different,
unspecified algebra in mind. Suspect the next question will be along
the lines of "why?" but I'll try to pre-empt that and ask first, "why
not English?".
David BL
There is no need to be rude. It is difficult to say it in English.
I am suggesting you can have a "database" type where a given value of
that type is a set of named relation values, where the relations
values are of distinct types. More specifically I'm thinking that the
database type fixes the names and types of the relations.
It is the same pattern used for a tuple. A tuple value represents a
mapping from a attribute name to an attribute value, where the names
and types of the attributes are fixed by the tuple type.
Walter Mitty
<dr.co...@gmail.com> wrote in message
news:e0e5c65b-16b8-4d73...@r34g2000vba.googlegroups.com...
> Well, my basic programming training (I'm not a programmer but a
> data analyst by vocation) was in terms of assembler-style GOTO
> constructs and procedural programming.
What does a data analyst do? do you do data analysis?
> Your name and location suggest your native language is English.
> If correct, you likely do not know a second language very well.
I am an exception to your assertion. English is my native language, and I
speak one other language quite well.
> Bilingual people will know that different languages tend to be
> useful for expressing different things.
Yes, and there are some things that OO language is not well suited to
express. Complex interrelationships in shared data is one such thing.
>My native language is
> not English, but all my professional training was in English.
> Which has had the effect that I am unable to think about
> professinal questions in my native language. I find that I
> always refer to English terms when discussing work.
>
Good for you!
> OO and policies has had the same effect, and have worked well
> enough that I haven't needed to look back. Until I encountered
> databases and SQL.
>
Don't look back. Look forward.
> Ever heard of a 'class'? 'Supertype'? 'Specialization'?
> Teorey uses UML to communicate problems and solutions
> in the context of databases. Just as lots of folks do
> with OO programming. The concepts are the same everywhere.
> Terminology differs.
>
Do a google search on "generalization specialization relational modeling".
You'll find several interesting articles on the subject. Most of what you
will learn will be overkill for the problem you stated in the OP. But if
you are interested in general principles, you'll learn some interesting
things from the articles.
Bernard Peek
<wam...@verizon.net> writes
>
>Anyway, it turns out you can do almost everything in design mode that you
>might be able to do by learning the syntax and semantics of SQL DDL and DML.
>And all you have to do is point and click, most of the time. And, because
>MS Access integrated application building with database building, you end
>up building a functioning application alongside the building of a working
>database. That's no small benefit. I actually built some useful stuff for
>myself using MS Access without really learning it. I hope somebody who
>really has learned it can help you more than I can. In the meantime, I'm
>going to focus on some sidelights.
I'm an enthusiastic Access user although I'm far from being an expert.
But I know that it does have some serious weaknesses and in some
situations actively encourages bad practise.
>
>MS Access owes a lot to its heritage. It was built to make desktop
>database work available to the same kind of person who was comfortable with
>Excel or Word. Desktop database work is very different from enterprise
>integration database work. Access was typically for one user at a time. It
>wasn't easy to get data into an access database, except by interactive data
>entry. If you were dealing with more than 10 million rows, you were
>probably maxed out. And so on. Over the years, it has matured to where it
>has overcome a lot of the initial limitations. But it still looks like a
>strange beast, to those of us who grew up with industrial strength DBMS
>products. It would be sort of like Object Oriented COBOL, if you get my
>drift.
>
>If you learn MS Access from the ground up, you are going to learn several
>things about the RM that just ain't so. That is why some of the regulars
>are chiding me for encouraging you. The design patterns that work for you
>are design antipatterns at the larger scale. That may not matter to you, at
>least for a while.
That's where a decision is required. Do you want to learn Access or do
you want to learn relational theory. The two are related but they aren't
the same thing.
>
>There is one antipattern that I want to mention in particular. Your problem
>description, in the original post, reminds me of the Entity-Atrribute-Value
>(EAV) antipattern. Different insrument types are like different entities,
>different calibrations are like different attributes, and different
>measurements are like different values. The terible thing about EAV is the
>hell you have to go through to create meaningful queries out of that mess,
>if you're using SQL or any language remotely like it.
That's one of its many disadvantages. It's another one of the ideas that
visitors to this newsgroup occasionally espouse as the next Big Thing.
>
>But there is a tool that can reduce an EAV data glob to a legible summary
>without much difficulty. It's the Pivot Table Report in MS Excel. A pivot
>table doesn't care whether the row headers and column headers are data or
>metadata. It's all databurger to the pivot table. So, if your plan is to
>simply pump data into Excel, and reduce it there, you may be able to get
>away with an EAV like design, in spite of the fact that people like me
>consider it a monstrosity.
EAV systems generally require very high skill levels in all of the
users. That's fine for a single-user database but generally won't work
for more than one user, without an extraordinary infrastructure to
maintain consistency.
--
Bernard Peek
David BL
I'm guessing that your "issues" have to do with recursive types. I
don't put much credence in your understanding of that subject matter
(e.g. given your posts in Jan 2007) relating to the following
definition by Bob:
A = { a1, a2, a3, a4, a5 }
B = { {a,b} | a in A and b in B }
Note that B = {} is consistent with the definition. It is not
immediately clear to me whether B is ill-defined. There cannot be any
element of B with a finite number of "nestings" of sets within sets,
because otherwise we can easily obtain a proof by contradiction as
follows: Let x be an element of B with the smallest number n of
nestings. Then x = {a,b} for some a in A and b in B. It follows that
b has n-1 nestings, which gives us a contradiction.
BTW Bob assumed {} was an element of B, which is obviously incorrect
because by definition all elements of B must be sets with two
elements.
I concluded that Bob failed to correctly give a recursive definition
of a type, and you were unable to realise it. In fact you even seemed
generally confused between the distinction of value and type.
Any decent mathematician knows that the right way to understand
recursive types (or sets) is to understand its relationship to the
principle of mathematical induction. Inductive definitions need a
starting point as well as the inductive step. For example, the
fibonacci sequence can be defined by two rules:
1. The first two fibonacci numbers are 0 and 1
2. Each remaining number is the sum of the previous two.
Are you going to continue blowing your own trumpet?
cim...@hotmail.com
> >> I am not aware of any precisely and consensually OO defined concept.
> >> I have asked hundreds of OO programmers in the past about a definition
> >> about what an object and each of them came with a totally different
> >> definition.
>
> But it's pretty much clear what a UML class diagram is, isn't it.
> >You are a database desinger, right? Do you ever use the
> >'entity-relation' method when you design a database?
> >If so, what is an 'entity'?
>
> The entity-relationship method is often used, advocated and taught
> for the design of databases. The design starts by creating
> an entity-relationship diagram, that is systematically transformed
> and provided with implementation detail until an ER diagram results
> that specifies a relational database schema.
> An ER diagram is a representation of the relations (tables)
> and foreign key relationships in a relational database schema.
> The relations in the schema are the entities and many-to-many
> relationships in the ER diagram; the foreign keys are the
> one-to-many relationships and the links between many-to-many
> relathipships and entities in the ER diagram. Every ER diagram
> can be created out of a relational schema in this way, but not
> every relational schema corresponds to an ER diagram; certain
> limitations on the structure of the structure of the foreign keys
> apply.
> Entity-relationship diagrams and UML class diagrams are very closely
> related. The entity sets in an ER diagram correspond to the classes
> of an ER diagram; the relationship sets to associations.
> There are also many differences, but the starting point is the same.
Thanks for the explanations. In a past life, I used visual
representations and diagrams to represent relations, functionnal
dependencies or required components of a data model but I came to the
conclusion that a textual representation was more effective into
representing logical aspects of a model. I now mainly use one tool
for database design: notepad.
Snipped
> [...]
>
> >> > 1) If OO concepts can be handled at all in SQL databases.
> >> > 2) If so, how it is done.
>
> Well, sometimes you have 'data' classes that do little but
> define a bunch of properties with simple values, and you create
> and manipulate collections of such objects; such classes and
> collections are a quite like database tables. Inheritance
> is also a very useful notion in database design, if we apply
> it to properties (attributes, columns) only. But nothing
> corresponds to the notion of method. Methods invite
> class-specific, object-by-object manipulation techniques;
> SQL on the other hand is essentially a language that maps
> tables to tables with operations such as row selection,
> column selection (projection), union, and join. You don't
> manipulate or navigate iundividual values and rows, databases
> weren't designed for that.
Databases are meant to be used to manipulate sets of values. Saying
that databases weren't designed for that seems a hasty conclusion.
>
> >> > I ask the same question: How is SQL different and similar
> >> > to what I already know.
>
> >> In ways you can not tell if you do not go through a self learning
> >> process of education in database concepts. If you believe this is not
> >> necessary and OO concepts are sufficient to understand database theory
> >> then it will be difficult to help you.
>
> Some people in this newsgroup believe that the relational model
> is sacred, its inventor Codd was a holy man, and a guy called Date
> who has written a bunch of popular books on the subject is his
> replacement on earth. Anything you say to suggest that other people have
> something intelligent to contribute on the subject, or have already done
> so, perhaps using slightly different ideas or terminology, is met with
> the scorn only dogmatists can muster.
What may appear as dogmatism by a minority is in fact a counter
balance reaction to the indignified promotion of ignorance done by
some others. There is no dogmatism into encouraging people to do some
reading.
> Pay attention to their ideas,
> ignore their attitude.
Would the *dogmatic* people have some interesting things to say ?
Snipped
> Not only newbies, anyone with different ideas or different terminology.
> This problem is hard to avoid in human communication, but it seems
> particularly bad in computer science.
The communication is bad because of the ignorance of most computer
science practitionners. For most of them, a limited grasp of computer
science concepts helps making a living, which I respect. But a small
minority of self promoted morons uses the ignorance of the majority to
promote further ignorance.
Anybody serious scientist would tell you that the*serious* basis
science communication is understanding first how fundamental theory
works to be able to relate to common fundamental concepts with larger
audiences.
Walter Mitty
"Bernard Peek" <b...@shrdlu.com> wrote in message
news:L97ZNNt$QuLK...@shrdlu.com...
> I'm an enthusiastic Access user although I'm far from being an expert. But
> I know that it does have some serious weaknesses and in some situations
> actively encourages bad practise.
Agreed.
> That's where a decision is required. Do you want to learn Access or do you
> want to learn relational theory. The two are related but they aren't the
> same thing.
>
Agreed.
>>
>>There is one antipattern that I want to mention in particular. Your
>>problem
>>description, in the original post, reminds me of the
>>Entity-Atrribute-Value
>>(EAV) antipattern. Different insrument types are like different entities,
>>different calibrations are like different attributes, and different
>>measurements are like different values. The terible thing about EAV is
>>the
>>hell you have to go through to create meaningful queries out of that mess,
>>if you're using SQL or any language remotely like it.
>
> That's one of its many disadvantages. It's another one of the ideas that
> visitors to this newsgroup occasionally espouse as the next Big Thing.
>
The people who consider EAV the next Big Thing generally do so because it
permits one to design a database without understanding the data at all.
This enables one to skip right over that messy, tedious, and time consuming
process of interviewing people who work with the data to find out how it
really works.
No analysis. Simple, universal design. On to implementation.
Meaningful outputs? We'll worry about that later.
Actually, I kinda hoping our OP will read some of the articles on
"generalization specialization relational modeling" and use the ideas to
design the tables. I can't be sure, but I think he'll get more return on
investment than he will going the EAV route. The best article actually
starts out showing how to do gen-spec ER modeling, and treats that as if it
were relational modeling. I use ER modeling myself with no apologies to
anyone, but ER modeling and relational data modeling are different, as
several regulars always point out.
dr.co...@gmail.com
> <dr.coff...@gmail.com> wrote in message
>
> news:35fe9916-b423-49e4...@x5g2000yqk.googlegroups.com...
>
> >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.
>
> If the mapping between OO concepts and RM concepts were simple, someone
> would have, by now, written a book that ties the two of them together, and
> explains both patterns in terms that makes sense. to someone coming from one
> pattern or the other. To my knowledge, there is no such book. I'm going to
> echo something Bernard said in another response.
> Better minds than mine have attempted to reconcile the OO way of thinking
> and the RM way of thinking with each other. By their own reckoning, their
> attempts have been unsuccessful.
I can see your point, now that Bernard and you kindly have
taken the time to explain it. Again, the concepts are so
*similar* that it's an obvious idea to anyone coming from the
OO side to at least ask why they aren't expressed in OO form.
And again, I start to get an impression what the problem is:
OO philosophy is founded on 'encapsualization', where attributes
are collected into 'objects' that make some sort of sense in
the problem (business) domain. Relational databases are all
about breaking that encapsualization, to efficiently search
for information.
However, since the problem domain is the same, the analysis
starts out in the same way (which was what confused me), but
the routes towards solutions and implementations are different.
> So you really shouldn't expect to reduce RM to a pattern that you already
> know. And you shouldn't expect, based on your success with OO up to this
> point, to be able to treat RM as something that can be marginalized as
> either a specialized niche or a trivial development. It is neither.
Oh, I never said RM is trivial! I only said the building
blocks are, which means the inter-relations between tables
that are trivial when seen in isolation, become complex.
A brick might be trivial; A structure built from bricks,
like Hagja Sophia, is not.
> Possibly the best person to speak to this would be Marshall. Marshall is a
> regular here who spend at least ten years as an OO programmer before going
> over to the RM side. He might be able to relate to what you do and do not
> understand at your present stage.
>
> Meanwhile, I need to correct the general thrust of my first response to
> you. In that response, I contrasted the OO way of thinking with the SQL way
> of thinking. That completely overlooks the fact that your target is to
> build an Access application that stores and serves up data for analysis with
> Excel. Much of what I said, while true, is beside the point. You can, in
> fact, build a simple yet functional MS Access application without learning
> much of any relational theory and without gaining much of any proficiency in
> SQL. Sadly, I can't help you do that, because I learned SQL before my first
> exposure to Access. So everything new that I learned in Access was
> something that I related back to what I already knew in SQL. After playing
> around with some wizard for a while, I would switch to the "SQL view" in
> order to "Find out what's really going on".
Not to worry - I use MSAccess because of neessity (it's what
I have available), not from preference.
> That was a useful way for me to understand it, but may be the long way
> around for you.
Point taken. I use MSVisual Studio for my C++ programming,
but do what I can to stick with standard-conforming C++.
Not always simple or convenient, but I'll never give in
to The MS Way.
> Like you, I like to learn the big picture first, and then fill in all the
> details. I was fortunate to learn the big picture of relational (or at
> least SQL) databases back in the 1980s, when there was less to learn. I
> find MS Access tutorials to be infuriating, because they all approach the
> subject matter as if there is no big picture. Here's how you chage the font
> in a dialogue box. And here's how you declare a primary key. And here's
> how you use the forms wizard to create a form. Gee whiz! Isn't that
> wonderful! But there's no central unifying theme in the narrative.
I have got a textbook on databases for the local college.
It sketches how to set up tables and formulate a query with
MSAccess, and how MSAccess is different from standard SQL.
It's what I need right now - I'll have to come back when I
hit the limitations.
> Anyway, it turns out you can do almost everything in design mode that you
> might be able to do by learning the syntax and semantics of SQL DDL and DML.
> And all you have to do is point and click, most of the time. And, because
> MS Access integrated application building with database building, you end
> up building a functioning application alongside the building of a working
> database. That's no small benefit. I actually built some useful stuff for
> myself using MS Access without really learning it. I hope somebody who
> really has learned it can help you more than I can. In the meantime, I'm
> going to focus on some sidelights.
Right now my main goal is to get a demo up and running that
focuses on how a database can save manual efforts, time and
reduce errors and glitches. It would be nice to get a 'proper'
DB up along the way, but that's a secondary goal right now.
If those who ought to know catches the point of my demo,
those things will be discussed in the follow-up.
> MS Access owes a lot to its heritage. It was built to make desktop
> database work available to the same kind of person who was comfortable with
> Excel or Word. Desktop database work is very different from enterprise
> integration database work. Access was typically for one user at a time. It
> wasn't easy to get data into an access database, except by interactive data
> entry. If you were dealing with more than 10 million rows, you were
> probably maxed out. And so on. Over the years, it has matured to where it
> has overcome a lot of the initial limitations. But it still looks like a
> strange beast, to those of us who grew up with industrial strength DBMS
> products. It would be sort of like Object Oriented COBOL, if you get my
> drift.
>
> If you learn MS Access from the ground up, you are going to learn several
> things about the RM that just ain't so. That is why some of the regulars
> are chiding me for encouraging you. The design patterns that work for you
> are design antipatterns at the larger scale. That may not matter to you, at
> least for a while.
Thanks for the warning. Again, I'm used to MS tools for
'proper' work in other contexts, so none of this is
surprising.
> There is one antipattern that I want to mention in particular. Your problem
> description, in the original post, reminds me of the Entity-Atrribute-Value
> (EAV) antipattern. Different insrument types are like different entities,
> different calibrations are like different attributes, and different
> measurements are like different values. The terible thing about EAV is the
> hell you have to go through to create meaningful queries out of that mess,
> if you're using SQL or any language remotely like it.
>
> But there is a tool that can reduce an EAV data glob to a legible summary
> without much difficulty. It's the Pivot Table Report in MS Excel. A pivot
> table doesn't care whether the row headers and column headers are data or
> metadata. It's all databurger to the pivot table. So, if your plan is to
> simply pump data into Excel, and reduce it there, you may be able to get
> away with an EAV like design, in spite of the fact that people like me
> consider it a monstrosity.
I wasn't aware of that. Again, thanks for the heads-up warning.
I'll have to try and stay clear of the MS-specific mess and
think in terms of 'clean' concepts.
Dr. C.
Walter Mitty
<dr.co...@gmail.com> wrote in message
news:e8dfe799-ce3e-4fc4...@t11g2000vbc.googlegroups.com...
>>OO philosophy is founded on 'encapsualization', where attributes
are collected into 'objects' that make some sort of sense in
the problem (business) domain. Relational databases are all
about breaking that encapsualization, to efficiently search
for information.
<<
The motive behind encapsulation is information hiding. The motive behind
database building is information sharing. You can hide information or you
can share it. Take your pick.
cim...@hotmail.com
As a remark, the relational model is not just about *tricks* and
*stuff* that can be noticed *here* and *there*. Relational model is a
direct application of math. This is a fundamental difference from OO
*mindset* (if one accepts it would make sense to compare them) which
has a sloppy and obscure fundamental fundation. From the perspective
of RM, encapsulation is synonymous with accepting low level computing
as a rule. Which is one of the reason they are difficult to compare.
> However, since the problem domain is the same, the analysis
> starts out in the same way (which was what confused me), but
> the routes towards solutions and implementations are different.
>
> > So you really shouldn't expect to reduce RM to a pattern that you already
> > know. And you shouldn't expect, based on your success with OO up to this
> > point, to be able to treat RM as something that can be marginalized as
> > either a specialized niche or a trivial development. It is neither.
>
> Oh, I never said RM is trivial! I only said the building
> blocks are, which means the inter-relations between tables
> that are trivial when seen in isolation, become complex.
>
> A brick might be trivial; A structure built from bricks,
> like Hagja Sophia, is not.
>
>
>
> > Possibly the best person to speak to this would be Marshall. Marshall is a
> > regular here who spend at least ten years as an OO programmer before going
> > over to the RM side. He might be able to relate to what you do and do not
> > understand at your present stage.
Anybody who would make the effort of educating himself *seriously* on
relational model would not do otherwise. That is what several people
tried to encourage you to do. That is another, some would say bluntly
genuine and different, but genuine nevertheless, to help you...
You seem to fail to understand that...Anyway good luck in your work...
Regards...
Brian Selzer
"paul c" <toledob...@oohay.ac> wrote in message
news:2CFXl.31240$PH1.18952@edtnps82...
I should have expected your response, since you have imposed some of the
same arbitrary limits on your own interpretation of database theory. But
thank you for clearing up my misconceptions on the pecking order here. I
thought Bob was Gene's flunky, not the other way around.
Your usage here is strange. An incisive comment is one that bypasses the
social niceties and gets right to the point; an incisive argument is one
that is clear, direct, and also gets to the point. Applying 'incisive' to
abstraction seems somehow off, at least to me. Maybe it is that abstraction
is a process, not an expression. Nevertheless, my use of the word 'limited'
has nothing to do with resentment. You appear to be projecting the
connotation of 'limited' in 'limited understanding,' in which the limits are
inherent, onto my usage of the term in 'limited interpretation,' in which
arbitrary limits are self-imposed. Moreover, the resentment I feel toward
Bob is due to his numerous attempts to berate, belittle and bully me, and
has nothing to do with what he is capable of. I could care less what he is
capable of.
Bob Badour
> On 10 Jun, 00:12, "Walter Mitty" <wami...@verizon.net> wrote:
>
>><dr.coff...@gmail.com> wrote in message
>>
>>news:35fe9916-b423-49e4...@x5g2000yqk.googlegroups.com...
>>
>>>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.
>>
>>If the mapping between OO concepts and RM concepts were simple, someone
>>would have, by now, written a book that ties the two of them together, and
>>explains both patterns in terms that makes sense. to someone coming from one
>>pattern or the other. To my knowledge, there is no such book. I'm going to
>>echo something Bernard said in another response.
>>Better minds than mine have attempted to reconcile the OO way of thinking
>>and the RM way of thinking with each other. By their own reckoning, their
>>attempts have been unsuccessful.
>
> I can see your point, now that Bernard and you kindly have
> taken the time to explain it.
Frankly, your biggest problem is not knowing who to ignore and who to
pay attention to.
> Again, the concepts are so
> *similar* that it's an obvious idea to anyone coming from the
> OO side to at least ask why they aren't expressed in OO form.
> And again, I start to get an impression what the problem is:
>
> OO philosophy is founded on 'encapsualization', where attributes
> are collected into 'objects' that make some sort of sense in
> the problem (business) domain. Relational databases are all
> about breaking that encapsualization, to efficiently search
> for information.
Your ignorance is showing. "Encapsulation" is just a syntactic/physical
implementation of a specific type of the general engineering principle
of "information hiding". The RM addresses the same principle much more
powerfully and much more completely through data independence.
>>So you really shouldn't expect to reduce RM to a pattern that you already
>>know. And you shouldn't expect, based on your success with OO up to this
>>point, to be able to treat RM as something that can be marginalized as
>>either a specialized niche or a trivial development. It is neither.
>
> Oh, I never said RM is trivial! I only said the building
> blocks are, which means the inter-relations between tables
> that are trivial when seen in isolation, become complex.
>
> A brick might be trivial; A structure built from bricks,
> like Hagja Sophia, is not.
A brick is trivial. An n-dimensional relation of "object" values is not.
You seem rather impervious to grasping the simplest of observations even
when pointed out to you.
dr.co...@gmail.com
> <dr.coff...@gmail.com> wrote in message
>
> news:e0e5c65b-16b8-4d73...@r34g2000vba.googlegroups.com...
>
> > Well, my basic programming training (I'm not a programmer but a
> > data analyst by vocation) was in terms of assembler-style GOTO
> > constructs and procedural programming.
>
> What does a data analyst do? do you do data analysis?
Data analysts, as I prefer to use the term, try to make sense
of data which originate from observations, and use whatever
is learned from that excercise to their advantage. To achieve
some purpose.
You can do that in several ways, like stock brokers why try
to play the market in order to make a profit, or like myself
who is supposed use remote sensing techniques to learn
something about the natural world. I've done a lot of
programming as part of the endeavour of developing data
analyst methods, and so have had to learn system design
and analysis as on-the-job-training.
I am saying I am 'supposed to analyze data' since my work
is more and more hampered by the sheer administration-by-
manhandling of data. There is less and less time for doing
useful work, hence my interest in databases.
> >My native language is
> > not English, but all my professional training was in English.
> > Which has had the effect that I am unable to think about
> > professinal questions in my native language. I find that I
> > always refer to English terms when discussing work.
>
> Good for you!
Actually, no. It is not fun to discover that either one's
native language is insufficient to express an idea, or
alternatively, that one does not master one's native
language sufficiently well.
> > Ever heard of a 'class'? 'Supertype'? 'Specialization'?
> > Teorey uses UML to communicate problems and solutions
> > in the context of databases. Just as lots of folks do
> > with OO programming. The concepts are the same everywhere.
> > Terminology differs.
>
> Do a google search on "generalization specialization relational modeling".
> You'll find several interesting articles on the subject. Most of what you
> will learn will be overkill for the problem you stated in the OP. But if
> you are interested in general principles, you'll learn some interesting
> things from the articles.
Thanks.
Dr. C.
Gene Wirchenko
He did not mock. He gave a reply.
> "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."
>
>and Bob replies with
>
> "Keywords? Introduction, preamble, prologue, chapter 1.
> I would start with one of those. Not sure which
> terminology Teorey uses in the 4th edition, but I am
> sure you will find something suitable shortly after
> Table of Contents."
>
>This is clearly intended to mock, and in a nasty way. It is typical of
Is it? I read it as "If you start at the beginning, you will
find what you are looking for." Sometimes, just getting started can
be the biggest hurdle.
Too many are after the magic incantation. There is no substitute
for sitting down and studying.
>BB. Perhaps BB could himself do with some suggestions for reading
>material - books with titles like "How to win friends and influence
>people".
Is your statement intended to mock, and in a nasty way?
>Of course Reinier was also mocking various regulars in the newsgroup.
>However, I found his comment quite amusing - and nothing like BB's
>aggressive tone. BB's reaction also suggests lack of balance.
Oooh, balance! It is so important to have balance. Ha! Sense
and nonsense should not be getting equal time.
Gene Wirchenko
If you had to pick one, which would you pick words of wisdom or
agreeableness?
Fabian Pascal gave up on Database Debunking after several years.
It was grinding water.
The same old stupidities keep coming again and again. It is not
surprising that people get tired of explaining the same thing over and
over.
Gene Wirchenko
>Brian Selzer wrote:
[snip]
>> While Bob delights in berating and belittling anyone who doesn't share his
>> limited interpretation of database theory and in bullying those new to the
>> field, at least he has the stones to be direct about it. What I don't
>> understand is why he doesn't take offense at your presumption. Why should
>> it have been Bob that called Reiner a fool? If you think Reiner is a fool,
>> then why can't you just say it directly and unequivocally? Why should you
>> have to pawn it off on Bob? Is it that such adolescent behavior is somehow
>> beneath you? But not beneath Bob?
Mr. Selzer:
I did not pawn it off on Bob. He simply wrote first. I do not
claim that Bob's behaviour is adolescent; you do. I claim that it is
exasperation with someone seemingly determined to be and remain a
fool.
I killfiled you long ago, and have seen nothing (in the replies
to your posts, those I do see) to indicate my decision was erroneous
or even hasty.
paul c:
>Bob B knows more (about this subject, maybe not others, such as HVAC)
>than Gene,
Yes.
>who posts more about practice,
Yes, because I do not know too much of the theory.
>and I suspect that Gene knows
>it,
Yes.
>which suggests that he actually knows more than he says,
Not quite. I try to cultivate an awareness of what I am ignorant
of. I tend to avoid speaking about matters that I do not know of,
unless I am asking all too many questions.
>and doesn't
>play around about it when he enters theory and good for him.
Yes. When I am in my home ground in theory, I am even fussier
about things than my instructors, way fussier.
>From their
>material it is clear that they both have worked to find good grounds for
>their confidence in the opinions they have about the aspects of the
>subject they choose to comment on, as far as they go, which is among the
>finest human traits.
I try to cultivate an awareness of what I do know, too.
>Everything else is genes.
I do not follow this sentence.
>Both have more posts
>that I have marked 'important' or 'work' than any other poster here.
Thank you for the compliment. I try, but without much feedback,
it is hard to see what difference I have made.
I think that Bob deserves the compliment far more than I do. He
does much more heavy lifting than I do and gets pilloried far more for
his efforts. I simply add a few fillips.
>You are off on an irrelevant tangent, hand-waving, as usual, but on an
>different tack than usual.. I tbink words like 'limited' reveal an
>underlying resentment towards people who are capable of incisiive
>abstraction.
I agree on this.
What is "limited" anyway? It is a code word for "Let's dismiss
this".
Everything is limited. I am 48 years old. English is my first
language. I tutor people in English. Nonetheless, I have a limited
knowledge of the English language. After all, my knowledge of the
English language is not infinite.
Limited, schimited.
Gene Wirchenko
[snip]
>The communication is bad because of the ignorance of most computer
>science practitionners. For most of them, a limited grasp of computer
>science concepts helps making a living, which I respect. But a small
>minority of self promoted morons uses the ignorance of the majority to
>promote further ignorance.
>
>Anybody serious scientist would tell you that the*serious* basis
>science communication is understanding first how fundamental theory
>works to be able to relate to common fundamental concepts with larger
>audiences.
Very nicely stated, sir!
jayga...@gmail.com
That's a false and self-serving dichotomy.
> The same old stupidities keep coming again and again. It is not
>surprising that people get tired of explaining the same thing over and
>over.
Then please stop martyring yourselves to the cause, Besides, it's not
as though you have anything original to say anyway. While you're at
it, please drop the pretext that this group is anything other than a
circle-jerk for you, Badour, Marshall, cimode, et al., and an insular
platform for omphaloskepsis and unwarranted egotism.
Please, all of you, put your flaccid penises away and dispense with
the Don Quixote/Sisyphus affectations.
cim...@hotmail.com
Just take it easy. This is a place of public speech about database
science. Contradictions and argument exchange are to be promoted and
expected. Personal attacks, OTOH, such as the one you just made are
to be avoided as much as possible. I wander what exactly have I said
to upset you up to that point.
Just keep in mind there is in fact no *you*. Each of the names you
quoted have no relationship to one another other than, perhaps, the
firm belief that neither eloquence nor mumbo jumbo could be
reasonnable substitutes for substance.
Brian Selzer
I need to look into setting up my own killfile. You'll be first on the
list! Ahead of Bob.
jayga...@gmail.com
No, that's what it's supposed to be. In fact, though, this "place" is
nothing more than a claque for Fabian Pascal, Chris Date and Hugh
Darwen, and a fortification against the advancement of useful new data
management theories (an oxymoron here, naturally) populated by
sclerotic epigones of those guiding lights just listed.
> Personal attacks...are to be avoided as much as possible
Agreed. In this case, it wasn't possible. Just like it wasn't possible
every time Badour called someone an idiot (often a "self-aggrandizing"
one), moron, twit or asshole, or when you called someone a chicken
shit.
>neither eloquence nor mumbo jumbo could be reasonnable substitutes for substance.
Sure--that's what postmodern literary theory is for. Anyhow, I look
forward to more substance here on such clearly related topics as
electrons, Clinton, Iraq, and speculations on whether a given poster's
first language is English.
David BL
It's the same message, but that's the polite version. Bob's version
was offensive. It suggested the OP was so dumb he needed to be told
in detail how to read a book from the beginning.
> Too many are after the magic incantation. There is no substitute
> for sitting down and studying.
Completely agree.
> >BB. Perhaps BB could himself do with some suggestions for reading
> >material - books with titles like "How to win friends and influence
> >people".
>
> Is your statement intended to mock, and in a nasty way?
Yes, obviously. I have no problem mocking a bully.
Gene Wirchenko
>On Jun 11, 12:47 am, Gene Wirchenko <ge...@ocis.net> wrote:
>> David BL <davi...@iinet.net.au> wrote:
[snip]
>> >This is clearly intended to mock, and in a nasty way. It is typical of
>>
>> Is it? I read it as "If you start at the beginning, you will
>> find what you are looking for." Sometimes, just getting started can
>> be the biggest hurdle.
>
>It's the same message, but that's the polite version. Bob's version
>was offensive. It suggested the OP was so dumb he needed to be told
>in detail how to read a book from the beginning.
When someone has a book, has not started it, and is still asking
questions, what is the next thing to do? Start reading the book
perhaps?
>> Too many are after the magic incantation. There is no substitute
>> for sitting down and studying.
>
>Completely agree.
Which is likely why Bob stated what he did.
>> >BB. Perhaps BB could himself do with some suggestions for reading
>> >material - books with titles like "How to win friends and influence
>> >people".
>>
>> Is your statement intended to mock, and in a nasty way?
>
>Yes, obviously. I have no problem mocking a bully.
Well, you are getting rather pugnacious. I suppose I could
declare you a bully and then start mocking you. That presupposes that
I consider your activity acceptable. I do not.
[snip]
David BL
> David BL <davi...@iinet.net.au> wrote:
> >On Jun 11, 12:47 am, Gene Wirchenko <ge...@ocis.net> wrote:
> >> David BL <davi...@iinet.net.au> wrote:
>
> [snip]
>
> >> >This is clearly intended to mock, and in a nasty way. It is typical of
>
> >> Is it? I read it as "If you start at the beginning, you will
> >> find what you are looking for." Sometimes, just getting started can
> >> be the biggest hurdle.
>
> >It's the same message, but that's the polite version. Bob's version
> >was offensive. It suggested the OP was so dumb he needed to be told
> >in detail how to read a book from the beginning.
>
> When someone has a book, has not started it, and is still asking
> questions, what is the next thing to do? Start reading the book
> perhaps?
I wasn't disagreeing with the advice, only with the tone.
David BL
1)
On Dec 21 2006, 11:23 am, paul c <toledobythe...@oohay.ac> wrote:
> Marshall wrote:
> > On Dec 20, 3:13 pm, monaro...@gmail.com wrote:
>
> >>Is English your second language?
>
> > Wow, an insult in which you imply that I don't speak
> > English very well. Isn't *that* original, and oh so relevant?
> > ...
>
> Hey Marshall, your anglais is satisfactaire. it's standard technique
> for newsgroup/"successful" hand-wavers to challenge an irrelevant aspect
> of the questioner's manner, ie., to try to change the subject.
2)
On Jun 10, 12:00 pm, paul c <toledobythe...@oohay.ac> wrote:
>
Cimode
> > This is a place of public speech about database science
>
> No, that's what it's supposed to be.
different ways to do that ?
> In fact, though, this "place" is
> nothing more than a claque for Fabian Pascal, Chris Date and Hugh
> Darwen, and a fortification against the advancement of useful new data
> management theories (an oxymoron here, naturally) populated by
> sclerotic epigones of those guiding lights just listed.
To be qualified as *useful*, a data management theory must stand on
its own feet and be subjected to public scrutiny. This place also
allows that. I do not believe on the contrary that people who devoted
their life to database management feel it as a claque since they are
focus their energies on finding truth.
> > Personal attacks...are to be avoided as much as possible
>
> Agreed. In this case, it wasn't possible. Just like it wasn't possible
> every time Badour called someone an idiot (often a "self-aggrandizing"
> one), moron, twit or asshole, or when you called someone a chicken
> shit.
If you feel offended by BB or others, just ignore him or others (as
simple as that). I do not recall calling anybody *chicken shit* and
since I do not ever recall using this specific expression, I would be
glad if you could post where I said it. But I admit I can get pretty
frustrated and offended by the *I am ignorant and proud to be*
attitude of some people who are not aware of their limits as far as
database theory is concerned. Since I find that attitude very
offensive and disrespectful, I can understand how reactions may go
over the edge whith people who promote this attitude.
> >neither eloquence nor mumbo jumbo could be reasonnable substitutes for substance.
>
> Sure--that's what postmodern literary theory is for.
I am sorry I am not following you.
> Anyhow, I look
> forward to more substance here on such clearly related topics as
> electrons, Clinton, Iraq, and speculations on whether a given poster's
> first language is English.
I believe I agree with that as I can see how this thread has gone off
topic. What I meant by substance is database theory substance.
jaygarrick7
Given your thoughtful replies, I was wrong to have singled you out.
Gene Wirchenko
[snip]
>I wasn't disagreeing with the advice, only with the tone.
One problem with the know-nothings who flame here is that they
get caught up in the so-called tone and push it as more important than
the message.
Do you want to be in that company?
Bob can get testy, but his advice is good. I would prefer that
he be lighter, but not at the cost of the useful advice.
Cimode
> Given your thoughtful replies, I was wrong to have singled you out.
Just keep in mind that there are usually always hidden reasons to take
strong positions.
Regards
Marshall
> On Jun 10, 9:55 am, Gene Wirchenko <ge...@ocis.net> wrote:
>
> >If you had to pick one, which would you pick words of wisdom or
> >agreeableness?
>
> That's a false and self-serving dichotomy.
He presented it as a hypothetical, not a dichotomy. Since
it's not a dichotomy, it can't be a false dichotomy.
But since you note that it "serves" Gene, I guess that
means you recognize the value of content over
pleasantry. This recognition is what caused me finally
to stop whining to Bob about his manners. He and I
waged a long and severe battle of attrition over
that very issue. Ultimately, however, I was won
over by the strength of his arguments.
> While you're at
> it, please drop the pretext that this group is anything other than a
> circle-jerk for you, Badour, Marshall, cimode, et al., and an insular
> platform for omphaloskepsis and unwarranted egotism.
Omphaloskepsis is an awesome word; I commend your entirely
correct use of it, even though I disagree completely with what
you are saying. Seeing it and my name in the same sentence
was a surprise. Being mentioned at all here these days is a
surprise, since I rarely post, and my apparent perceived status
as a Circle Jerker of first repute is an honor I probably do not
deserve, if only for lack of recent posting volume.
> Please, all of you, put your flaccid penises away and dispense with
> the Don Quixote/Sisyphus affectations.
Hmm. Well, you stepped away from the classical Greek motif
to bring in Don Quixote; I would call that a stylistic mistake.
This last sentence is a muddle; if you are going to bring in
penises, the better approach would be to go with the
lately-popular "swordfight"; this is consistent with your
generally hellenic diction. Sisyphus's name is often
presented in adjectival form; that would have worked better
too. Referencing impotence is potentially quite a strong
rhetorical device, if perhaps overused, however it's not
a good fit with the overall theme of excessive conflict.
I'd have skipped the "flaccid" part.
However, there is another difficulty, altogether different
in kind from these I have mentioned so far.
The thing you're arguing against is incivility. And yet
your own post is entirely uncivil. Apparently your
argument is that politeness is for other people.
Alas, hypocrisy is never the basis for a compelling
argument.
Now, of these two problem areas, of diction and of
self-consistency, whichever is to be considered the
more pressing will depend on whether one is attending
more to style or substance. If you had to pick one, which
would you pick: words of wisdom or agreeableness?
Marshall