Re: Object-Role Modeling?

"Jan Hidders" <jan.hidders_at_REMOVETHIS.pandora.be> wrote in message news:I07Ae.141508$no5.7264319_at_phobos.telenet-ops.be...
> Marshall Spight wrote:
> > Alfredo Novoa wrote:
> >
> >>> From what I have read of it, it seems that it would be the
> >>>place to start,
> >>
> >>I prefer to start defining relvars.
> >
> > Yeah, I have to agree with Alfredo here. If you want to
> > design a database schema, why not do it by designing a
> > database schema?
>
> Many people seem to like to begin with ER diagrams. I happen to think
> that there's a reason for why they caught on as they did. And if you
> supply them with a formal semantics and a constraint and query language
> (which is easy to do and has in fact already been done by several
> researchers) then it qualifies as a database schema. So actually they
> *would* be beginning by designing a database schema.
>
> > If we want to raise the level of abstraction, it is necessary
> > to omit certain details in order to focus on other details.
> > But all of the details of a table definition are important;
> > you can't just skip over any of them.
>
> Only implementation details like choosing primary keys or choosing
> whether or not to embed a one-to-many relatinship have to be skipped.
> All logically relevant details will still be in there.
>
> > The might *possibly* be some opportunity (as I think Jan was
> > suggesting in another thread) to abstract the relationships
> > between tables, but I am sceptical.
>
> You wouldn't be thinking about relationships between tables. The whole
> point is that you can model at a higher abstraction level in terms of
> entities, properties of entities and relationships between entities. How
> you map that to tables and relationships between these tables, whether
> you split entities into several tables or merge several into one, how
> you model the ISA relationships, whether you embed the one-to-many
> relationship into the entity, those are all implementation issues.
>
> -- Jan Hidders

What you said. Plus my two cents:

At the time I started using and liking ER diagrams, most of the existing databases and many of the new ones were being implemented in network databases. One of the advantages of ER modeling is that the ER model is the same, regardless of whether your ultimate implementation is going to be network or relational. In one case, where an ER model of a large part of the enterprise data had been modeled in ER before building the network database (in VAX DBMS), a team was able to implement a functionally equivalent SQL database straight from the ER model.

Times have changed since then. But I think some of the same advantages persist.

In particular, I think it's useful to model data during data analysis, prior to database design. A model such as ER, among others, captures the requirements (at tleast in part), without embedding design decisions. That's useful. Received on Mon Jul 11 2005 - 15:12:26 CEST