Re: Conceptual, Logical, and Physical views of data

"dawn" <dawnwolthuis_at_gmail.com> wrote in message news:1126126111.444396.247600_at_g44g2000cwa.googlegroups.com...
>
> David Cressey wrote:
> > "dawn" <dawnwolthuis_at_gmail.com> wrote
> > > David Cressey wrote:
> > > > "dawn" <dawnwolthuis_at_gmail.com> wrote
> >
> > > > The difficulty is distinguishing a feature of
> > > > the problem itself from a feature of some imaginary soultion to the
> > problem.
> > > > In other words, the difference between analysis and design.
> > >
> > > And in theory there is a clear line between the question of "what is
> > > the system we planning to build?" and "how are we planning to build
> > > it?". However, I would suggest, as others have, that how we describe
> > > what we are building, or what problems we are solving, is necessarily
> > > influenced by how we think we will be designing a system.
> >
> > And this can be called "thinking inside of the box".
>
> Or simply shorthand, recognizing that the cost of doing analysis while
> making no assumptions is likely not worth the benefit. It is a risk
> and if the risk is high enough, then it needs to be mitigated.
> Additionally, when reviewing the analysis, the readers/designers should
> make an effort not to be trapped by solutions present in the analysis.
>
> > "The box" is not a
> > feature of the problem itself,
> > but of our early attempts to frame the problem in terms of a solution.
> >
> > > In some
> > > sense, analysis turns out to be an early stage in design, although I
do
> > > teach them as separate. If you try to write a requirements document
> > > without any assumptions about the target system, it will be
> > > unnecessarily obscure.
> > >
> >
> > The skill is to recognize elements of design in your analysis, and back
> > them out.
>
> Yes, but they don't need to be backed out in the writing, recognizing
> the risk.
>

The risk is huge, when the database and the application are going to be passed on to another team.

The cost of rediscovering design that was hidden in analysis is much larger than the cost of writing it down.

> > > If your application
> > > logic is in your code instead of your dbms, then you can point your
> > > code at something else, while if you have application logic (e.g.
> > > constraints) in your dbms and you switch, you need to recode that
> > > application logic in your new proprietary language that might be
> > > something like the previous one, but often not close enough. cheers!
> >

Oh? And what if you migrate your code from one language to another? When it's time to recode the application
from Data-Basic or COBOL to Java (or its successor), I'm sure the differences between the languages are going to require some reverse engineering (or retrospecitve analysis) to derive a functional model from the prior implementation, before writing the new code.

BTW, there is a way arounf this problem, but that's another discussion.

> > All programmers feel this way about databases. Your problem isn't that
you
> > don't like relational databases, or the relational data model. Your
> > problem is that you don't like databases, period.
>
> I'm almost willing to say "Good catch, David". I might lean that way.

I think this puts the cap on a two year dialogue between you and me.

> However, I do want support for transactions, backup & recovery,
> logging, security, derived data, query languages, indexes, caching,
> logical schema, ... . I suspect SQL is more of an issue for me than
> the relational model now that the relational model seems to have
> evolved to include what was once non-1NF (NF2). I do want navigational
> operators, however and that seems to go against relational theory. I
> want to "click on" a foreign key value and navigate to the referenced
> entity.
>

"seems" is the operative word here. A careful reading of Codd's 1970 paper will show that he proposed
"normalization" as an expedient, to facilitate initial implementation of relational systems, rather than as an inherent part of the relational data model.

Another point that many readers seem to have missed is that the relational data model predates Codd's 1970 paper, and Codd makes reference to that fact. What Codd was introducing was not the relational data model itself, but its application to the problem of large, shared databases. The prior use of the relational data model was in inference engines, sort of "expert systems" whose focus was data manipulation, rather than primarily sharing, storage, and retrieval, although those systems maintained a large body of persistent data to operate on.

And that brings me to a continuing discussion that happens over and over again in this newsgroup. When people compare Oracle and Dataphor, for example, they never focus on the way each of them supports "transactions, backup & recovery, logging, security, derived data, query languages, indexes, caching, logical schema". They compare the two of them in terms of their strength as an application development environment.

A database is NOT an application development environment. If you want to do fancy things with data, use a programming language. If you want to store it and share it, use a database. And the ongoing conundrum is between the SQL view of data, and the OO view of messages. Received on Thu Sep 08 2005 - 14:05:25 CEST