Re: Meaning of 1:1, 1:1 generalization, 1:n, 1:n non identifying, n:m

Joshua Beall wrote:
> mAsterdam wrote:

 >>> Joshua Beall wrote:
 >>> ... nomenclature:
 >>>
 >>> '1:1' - Ok, one to one.  Got it.
 >>> '1:1 generalization' - Don't know this.
 >>> Obviously different somehow from
 >>> one to one, but how?

I guess this is one to zero or one.

 >>> '1:n' - One to many, I assume.
 >>> '1:n non identifying' - Nonidentifying? What does this mean?

The foreign key is not part of the child key. IOW the key of the child does not include identification of the parent.

 >>> 'n:m' - Many to many? Again, not sure.

> ... I actually did post to their forums, but from the way it is
> talked about in the documentation, I got the idea that these
> terms are general database terms that you should understand
> *before* using their product. This is why they don't bother
> to explain them, they just say "the common relationships (insert
list) can be accessed via these buttons." I have looked through the documentation and was not able to
> find any further description of these terms.

"one to many" (1:m), "many to many" (m:n) are ways to express an aspect of how data relate. I don't know where these popped up, but they are pre-CODASYL. It has something to do with cardinality. Attempts to formalize this
aspect have been incorporated in ER
(Entity-Relationship) and ORM
(Object Role Modeling).
Both are used in the pre-design stage.

Some call the design of the database when there is a ER or ORM to start with a
"translation" (from the "logical" to the "physical", but I don't think there is
anything physical about tables).

Because some of the possible cardinalities are not at all consequential for the functional
dependencies in the actual SQL-database design and others do not have enough information on how to implement them, some dismiss these (as pseudo-)formalisms They start with the table design right away.

Downs' law: "People understand tables just fine."

Very recent discovery ;-)

TIMTOWTDI:
http://c2.com/cgi/wiki?ThereIsMoreThanOneWayToDoIt

Here is one way to look at these cardinalities:

Association (Relationship) AB:

      +---+    AB - name                +---+
      | A |-cAB---------------------cBA-| B |
      +---+                BA - name    +---+

A, B are entities
cAB is the cardinality minimum and maximum: min is in [0,1] max is in [1, m]

e.g.:

          A -->0----------------1<-- B

Many to many (m:n) relationships/associations will be split into two: AJ and JB. (J for Junction)

Trying to get the associations
with the same minimum on both sides
right is a pain and does nothing
to help the database design.

Don't bother. Just label them "maybe problematic", and only solve the problems which are still there when you get there (they appear later, at design time) with adequate domain knowledge.

That leaves just three types of dependencies as relevant, 1/0:1/1, m/0:1/1 (identifying) and m/1:0/1 (non-identifying).

In 1/0:1/1 A may be a specialization of B, B a generalization of A.

HTH Received on Fri Oct 01 2004 - 22:42:13 CEST