| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> comp.databases.theory -> Re: Conceptual, Logical, and Physical views of data
David Cressey wrote:
> "dawn" <dawnwolthuis_at_gmail.com> wrote in message
> news:1125611358.454623.172590_at_g47g2000cwa.googlegroups.com...
> >
> > mAsterdam wrote:
> > > David Cressey wrote:
> > > > mAsterdam wrote:
> > > [snip agreement]
> > > >>Does it matter if the technical
> > > >>architecture is given or not (say: we will use DBMS xyz)?
> > > >
> > > > Here's the way it works in practice for me:
> > > >
> > > > The conceptual model is implementation independent.
> > >
> > > Agreed.
> >
> > I would agree that is the idea, but it seems rare that it works out
> > this way.
>
> Not so rare in my experience.
Good deal.
> 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. 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.
> If you can keep
> analysis and design separate, you can create a conceptual model that is
> implementation independent.
That's a big "if" in my opinion.
>> > lot of bang for the buck.
> > > 2. How do we make the conceptual model explicit?
> >
> > This is probably a naive response, but where I used to choose an early
> > prototyping tool, possibly paper & pencil, even in the analysis phase
> > of a project, I now use web pages. I can mock these up even in place
> > of showing any end-user an erd (or uml class diagram) with any level of
> > detail in it. If you model the conceptual data with web pages with
> > foreign keys turned into links and sample data values, you can get a
Yes -- in fact a di-graph is a good modeling approach for just about ... nevermind ;-)
>
>
If a logical data model is prepared after a choice of dbms "class", then this would work, in theory. Such selections might be better completed after a logical system design, however. I'm OK with your statement, recognizing there's a bit of grey area.
> The best success, in practice, came when two of us had finished the logical
> modeling for a DEC Rdb/VMS implementation, and it was decided to implement
> in Oracle instead. (That was about the time that Oracle bought the Rdb
> division from DEC).
> We had zero changes to make to our logical model.
excellent!
> If we had decided to implement in a non relational DBMS, or even a non SQL
> DBMS, we might have had to undo and the redo some design decisions.
>
An aside -- it seems to be less expensive to migrate from one non-SQL dbms to another than from one SQL-dbms to another. 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! --dawn Received on Tue Sep 06 2005 - 18:46:24 CDT
 |
 |