Re: "Structured" Entity-Relationship Model?

From: Jan Hidders <hidders_at_gmail.com>
Date: Fri, 3 May 2013 14:21:39 +0200
Message-ID: <5183abd3$0$6337$e4fe514c_at_dreader35.news.xs4all.nl>

On 2013-04-30 15:06:50 +0000, Erwin said:

> Op zondag 21 april 2013 17:45:11 UTC+2 schreef Roy Hann het volgende:

>> Wolfgang Keller wrote:
>>
>>
>>

>>> Hello,

>>

>>> 

>>

>>> coming from the "practitioner" side, I wonder what relational theorists

>>

>>> think about "structured entity relationship" modelling:

>>

>>> 

>>

>>> http://en.wikipedia.org/wiki/Structured-Entity-Relationship-Model

>>

>>> 

>>

>>> For me the essential aspect seems to be the rule (which doesn't even

>>

>>> seem to be mentioned in the english-language Wikipedia article) that the

>>

>>> dependency graph of all entities must not contain directed circles,

>>

>>> i.e. there must be no "hen and egg"-type dependencies between entities.

>>
>>
>>
>> I can't think why that would be important.
>>
>>
>>

>>> Which appears to be a perfectly reasonable rule to me, since such

>>

>>> dependencies create horrible headaches for working with such databases.

>>
>>
>>
>> Really? Like what? I suppose if the DBMS insists of testing the
>>
>> referential integrity contstraints before you assert that you have
>>
>> completed a transaction that has left the database consistent (i.e. you
>>
>> COMMIT) that would be a problem, but that's just a broken DBMS. Indeed
>>
>> most SQL DBMSs seem to want to test constraints after every blessed
>>
>> statement, which is silly.
>>
>>
>>
>> I don't really applaud products/methodologies that try to elevate the
>>
>> workarounds for implementation mis-features to "best practice", as it
>>
>> appears SERM does.
>>
>>
>>

>>> Just imagine loading or deleting bulk data with circular dependencies.

>>
>>
>>
>> I have no problem imagining that at all. SQL applies a series of
>>
>> tiny, local, sequential changes to the database. It is absurd to
>>
>> expect every such incremental change must leave the database
>>
>> consistent. It is absurd that one could not do "bulk loading" or "bulk
>>
>> deleting" or any other series of things, in any random order, deferring
>>
>> the question of consistency until you, the programmer, want to make that
>>
>> claim.
>>
>>
>>

>>> Now what do theorists think:

>>

>>> 

>>

>>> Is it perfectly evident that this requirement must be enforced, since a

>>

>>> model with cyclic dependencies is plain "spaghetti", maybe even

>>

>>> violating some normal form?

>>
>>
>>
>> No.
>>
>>
>>

>>> Is it plain nonsense?

>>
>>
>>
>> I'm not sure what "it" is here.
>>
>>
>>

>>> Or does it depend on

>>

>>> the specific case, since there may be situations where it can't be

>>

>>> achieved, and a model that violates this rule can be perfectly valid?

>>

>>> 

>>

>>> I've noted that in practice, graphical modelling tools seem to be prone

>>

>>> to making users produce models where this rule is violated.

>>
>>
>>
>> Most modelling tools are rubbish, but in this particular respect I don't
>>
>> see a problem. Quite the contrary.
>>
>>
>>

>>> There

>>

>>> don't seem to be modeling tools that would allow checking for such

>>

>>> dependencies resp. preventing them.

>>
>>
>>
>> Good.
>>
>>
>>
>> --
>>
>> Roy

> 
> 
> 
> Is the statement-level constraint checking still "silly" if multiple 
> assignment as per TTM is available ?

I would say: no. In theory every transaction can be split into a set of reading operations followed by a single multi-update operation.

• Jan Hidders

Received on Fri May 03 2013 - 14:21:39 CEST