Re: "Structured" Entity-Relationship Model?

From: Erwin <e.smout_at_myonline.be>
Date: Tue, 30 Apr 2013 08:13:10 -0700 (PDT)
Message-ID: <28fd5c96-23d8-45b5-b1e2-d63c1648c035_at_googlegroups.com>


Op dinsdag 30 april 2013 16:30:54 UTC+2 schreef Wolfgang Keller het volgende:
> > Using the SERM example on the wikipedia page, the graph says every
>
> > order has N order items, and every order item has 1 order. Although
>
> > drawn as just one line, that line states two rules, mutually
>
> > dependent: a cycle. (Try using DRI to enforce them.)
>
>
>
> And just two (mutually co-dependent) constraints wouldn't be enough
>
> to correctly implement the semantics, as far as I understand. But
>
> database design books don't seem to explain it either. At least those
>
> that I have access to. Or am I just blind?
>
>
>
> This issue (it's "just" a 1:n relationship with n>0, right?) must be
>
> as old as the relational database model itself (fourty years now?).
>
>
>
> I've tried to google for the relevant terms, and couldn't find a
>
> documented example for a correct, tested solution. Or is it just that
>
> you need to know *the* terms to search for?
>
>
>
> Does someone in this group know of a book (or an online document) that
>
> shows how to *correctly* implement such things? And maybe one that also
>
> gets other things (that I haven't stumbled over yet) *right*? Something
>
> like "database design caveats that most textbooks conveniently ignore"?
>
>
>
> TIA,
>
>
>
> Sincerely,
>
>
>
> Wolfgang

If updates to >1 table are(/may be) necessary before consistency (of the data with the rules/constraints) can be achieved, then you"ll need deferred constraint checking. Or a TTM-compliant DBMS that offers multiple assignment, which is better for reasons that have not so much to do with consistency per se. Received on Tue Apr 30 2013 - 17:13:10 CEST

Original text of this message