Re: definitions

From: Anne & Lynn Wheeler <lynn_at_adcomsys.net>
Date: 2000/04/29
Message-ID: <uwvlg96rn.fsf_at_mail.adcomsys.net>#1/1


"Ken" <harmonhsd_at_earthlink.net> writes:

> I have a few questions about database models...
>
> For a somewhat formal definition of the E-R data model, I know that an
> entity-relationship model consists of a set of objects entities and a set of
> relationships among those objects. I can't seem to find a definition for
> the relational data model. Is the relational data model simply a collection
> of tables (relations)? A table (relation) can be defined as a relationship
> among a set of values (tuple).
>
> There are few if any databases based on the E-R data model, most are based
> on the relational data model. My question is: was the E-R data model
> created just for the sole purpose to facilitate database design? After an
> database schema is designed using the E-R model and diagrams, is it just
> simply converted into tables to fit the relational model?
>
> I was just curious as to what the relationship between the two data models
> are..
>
> Thanks,
> Ken
>
>

typically e-r data model is attempt to state something that is descernable &/or closer to the real world. once the e-r model is completed, then it can be translated into row&column form for regular/homogeneous data that is characteristic of relational database (normalize). it is suited for circumstances where there is a one to (large) many correspondance (account transaction activity where there there is a large number of different account numbers related to doing financial transactions).

row/column is less suited to situations where the population has much more of one-to-one correspondance ... i.e. if relationally normalized rather than having a few tables with millions of rows each ... millions of tables with few rows each.

some examples tend to the data dictionaries themselves or other information populations with complex and hetrogeneous/non-homogeneous structures. when instantiated in relational databases they tend to be non-normalized (i.e. tendency to have columns which are "relationships" ... and one or more fields in each row that give the actual relationship information).

the taxonomy/glossaries at

http://www.garlic.com/~lynn/

are rather trivial ... but would represent interesting problem to do as a few tables if done as fully normalized relational ... including consistent maint. of bi-directional relations ...

http://www.garlic.com/~lynn/rfc1983.htm
http://www.garlic.com/~lynn/payment.htm
http://www.garlic.com/~lynn/secure.htm
http://www.garlic.com/~lynn/x9f.htm
http://www.garlic.com/~lynn/financial.htm

-- 
Anne & Lynn Wheeler   | lynn_at_adcomsys.net, lynn_at_garlic.com
 http://www.garlic.com/~lynn/ http://www.adcomsys.net/lynn/
Received on Sat Apr 29 2000 - 00:00:00 CEST

Original text of this message