Re: database design method

From: Doris Schupp <doris.schupp_at_sympatico.ca>
Date: Mon, 21 Oct 2002 20:46:54 -0400
Message-ID: <ee1t9.3307$A12.490255_at_news20.bellglobal.com>


"David Cressey" <david_at_dcressey.com> wrote in message news:Z_bs9.196$0I3.17251_at_petpeeve.ziplink.net...
> > I'm confused about the methods of database design.
> >
> > It seems to me that most theoretical texts talk about 'conceptual',
> > 'logical' and 'physical' design. These steps produce conceptual, logical
> and
> > database schema. However in the 'real world' conceptual and logical
steps
> > seem to be combined into a single step.
> >
>
> Here's my take on it. A "conceptual model" is typically the result of
> analysis, not design. The best conceptual models capture the information
> requirements of some proposed system or database, from a data centric
point
> of view.

In our work, we use the 'conceptual design' to document the high level business
entities and subject areas of the database. For example a sales agent can have one or
more customers, a sales agent must be an employee. An employee is identified by
one and only one identification number. This gives us three conceptual entities -
employee, sales agent, and customer (independent of applications or RDBMS)

Our logical model then defines in more detail the attributes associated with each
entitiy. Generally, we don't keep a seperate conceptual, but use it to build the logical.

The physical is then defined based on the RDBMS you are going to be using in the
final application

Hope this helps.

D
>The ER model, when it was first proposed and for about a decade
> following, was a good model for this purpose, because of the way
> relationships are treated. In the ER model, relationships are identified,
> but not implemented.
>
> Again, taking the point of view of 20 years ago, databases of that era
> were mostly hierarchical or network, with "newfangled" relational
databases
> making rapid inroads. Hierarchical and Network databases implement
> relationships by embedding pointers in records, alongside the data.
> Relational databases implement relationships in the data itself. If a
> reference is made to the data in a table row, a foreign key at the point
of
> reference is used, and not a pointer.
>
> This point has come to the forefront again, because many OODBMS products
> make the same use of pointers that Hierarchical and network DBMS did.
>
> A Relational DBMS may have pointers and keys associated together in
indexes,
> but these are managed by the RDBMS itself, and are nearly transparent to
> the application programmer.
>
> So what's the difference between a conceptual (ER) model, and a logical
> (Relational) model? Well, one difference is how tied to a relational
> implementation you are. A relational model is somewhat more bound to a
> relational physical implementation than an ER model is. Another
difference
> is normalization. An ER model isn't particularly normalized, although a
> "good" ER model tends to produce a fairly normalized design, almost
> automatically.
>
> But the big difference, in my mind, is the difference between analysis
and
> design. The conceptual model captures the analysis, while the logical
model
> captures the logical design. I expect to hear a lot of contending views on
> this topic.
>
>
>
>
>
>
>
Received on Tue Oct 22 2002 - 02:46:54 CEST

Original text of this message