Re: Entity R Diagrams/Case

In article <wayneC920zv.HEs_at_netcom.com>, wayne_at_netcom.com (wayne t. watson) writes:
|> I've been looking at an Addison Wesley book about the Oracle Case Tools.
|> The author's name escapes me. He is British.

He's Richard Barker, an Oracle Senior VP and founder of our CASE development group.

|> Anyway, I have two questions regarding what I've read so far.
|> 1. In an ER diagram, suppose you have something like
|> Entity A
|> _________________
|> | |
|> | |- - - - ---------- B
|> | |
|> | |- - - - ---------- C
|> _________________
|>
|> That is, Entity A has relationships with two other entities that are
|> each of the 'may be' kind. But suppose these are exclusive OR and
|> the appropriate symbol for this is placed across the symbols. Does this
|> now mean either 'A may be related to B' or 'A may be related to C', so
|> that one might expect either relationship, and possibly none? Assume
|> The same relationships are 'must be'. Does the either/or imply always
|> one or the other (but never none)? If in the first case ('may be') none
|> is not a choice, then doesn't the exclusive OR imply the two
|> relationships are then the same as 'must be'.

Your first notion is correct. Each A may be related to a B, or to a C, or to neither. An A may not be related to both a B and a C.

|> Ok, here is any easier one? Does the Oracle Case ER Diagram tool somehow
|> generate the necessary tables from the diagram? I mean, at some point,
|> in the ER diagram game, doesn't someone actually have to generate tables
|> for each of the entities (which I assume are really tables).

Yes, it does. You'll need the CASE*Dictionary Design menu, and under that you'll find various utilities to generate default database designs, screens to record your variations on the default, and an SQL Data Definition Language generator. Check it out in the CASE Dictionary Tutorial manual.

Be careful though: the mapping of one entity to one table is the simplest case - there may be times when one entity maps to >1 table, or >1 entity maps to one table. Think of entities as things of significance to be modelled, real or abstract, rather than tables, and you'll be able to do table design separately - and design for performance or redundancy or distribution or whatever you need.

|> Well, here is another question. Who started all this ER Diagram business
|> anyway?

One of the earliest and most influential papers was "The Entity-Relationship Model - Toward a Unified View of Data", published in the ACM Transactions on Database Systems in March 1976. The notation in Oracle's tools is better (IMHO), but conceptually similar. ER modelling is proving a sound foundation - most OO modelling techniques are an evolution of it.

John Bestwick,
CASE Development,
Oracle Corporation Received on Wed Jun 23 1993 - 10:15:42 CEST