Re: What is that "more" that makes E-R model truly independent ?

"beginner16" <kaja_love160_at_yahoo.com> wrote in message news:1185291874.325737.75510_at_w3g2000hsg.googlegroups.com...
> On Jul 24, 1:22 pm, "David Cressey" <cresse..._at_verizon.net> wrote:
> > "beginner16" <kaja_love..._at_yahoo.com> wrote in message
> >
> >
> > My insight into what makes E-R valuable comes, in part, from some
> > experiences dating back to the 1990s. In one case, I was working with
the
> > local data modeller, and he had taken a huge enterprise wide database
built
> > for VAX DBMS and abstracted it out to an E-R model (including, but not
> > limited to, a diagram). when the time came to design and build a
reporting
> > database in Oracle that used some data from an Rdb database, but which
> > described the same underlying enterprise as the old database, the data
> > analysis phase of the project was essentially completed in an afternoon,
by
> > taking the suubset of the E-R model relevant to the subject at hand.
> >
> > For your background, VAX DBMS was (and still is) a CODASYL database
> > product. CODASYL (or network) databases are like hierarchical except
that
> > a record can belong to more than one set.
> >
> > Anyway, the advantage that E-R offers over some alternatives is that it
is
> > less biased toward one data model or another. It's easy to derive a
> > relational model from an E-R model. It's also fairly easy to derive a
> > hierarchical model, a network model, or even an object oriented model
from
> > the same starting place. This lack of bias is, from my experience, very
> > important. It helps in the necessary discipline of keeping design
distinct
> > from analysis.
> >
> > As to whether relational has its own diagramming convention, the answer
is
> > decidedly yes. There are even some tools out there that will manage an
E-R
> > model and an equivalent relational model in parallel. One such tool is
Data
> > Architect from Sybase.
> >
>
>
> Do we sometime use relational diagrams even at conceptual level( data
> modelling and not ANSI/SPARC ) or only at logical level?
>

I have seen this done. However, it seems to me that such diagrams often intermix requirements issues (problem domain) with design issues (solution domain). I prefer to treat the conceptual level as modeling the data only from the point of view of the problem domain, and let the logical level take care of those aspects of the design that are on the one hand relational data model dependent, but on the other hand, independent of the specific DBMS, platform, or expected volume and load.

Many of the regulars in this forum are quite firm in maintaining the distinction between the relational model as such, and the SQL model, often called "relational" out there in the industry. When matters of theory are being discussed, such a distinction is often crucial for clarity. In terms of practical database design, using today's soi disant commercial relational DBMS products, the design of SQL tables can often be treated as "close enough to relational" so that the differneces won't affect the design.

> 2)
> Quote from my book:
> "With conceptual model we can't ( ussually ) define semantics of
> data".
>
> I know what the term semantics means, but not in this context. Does it
> mean that at conceptual level the diagrams don't tell us the meaning
> of that data? Uh, that doesn't make much sense
>

For what it's worth, it doesn't make much sense to me, either. The concpetual level is precisely where the semantics of the data should be pinned down. Down at the logical level or below, the data is increasingly being stored, structured, retrieved and manipulated in ways that are independent of what the data really means. This is where math is helpful. Received on Tue Jul 24 2007 - 18:42:09 CEST