Re: "Structured" Entity-Relationship Model?

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

As a relational theorist that model is completely new to me. But from the theoretical viewpoint I'd say it doesn't matter if you draw boxes, diamonds or decorated boxes. It is also more a matter of taste than one of theory if you decorate edges by arrowheads and double strokes, or if you use, say, the UML notation.

> 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.
>
> Which appears to be a perfectly reasonable rule to me, since such
> dependencies create horrible headaches for working with such databases.
> Just imagine loading or deleting bulk data with circular dependencies.

Actually, headaches in not a theoretical issue ;). Of course DAG-shaped dependencies are less likely to cause problems but even DAG-dependencies may lead to problems, like, say, deadlocks.

> 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? Is it plain nonsense? 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?

Whereas, at the moment, I cannot imagine a case where cyclical dependencies are useful I would not prohibit them entirely. A warning upon their detection would do, too. I am not a friend of "hard-coding" enforcement of design rules into design tools.

> I've noted that in practice, graphical modelling tools seem to be prone
> to making users produce models where this rule is violated. There
> don't seem to be modeling tools that would allow checking for such
> dependencies resp. preventing them.

This is interesting. That would then be a good extension of such tools. However, "prevention" should only consist in warning the user and leaving it up to his decision if he needs cyclical dependencies in his case, say by a Java-annotation-like _at_SuppressWarnings("cyclical"). Note that "being part of a cycle" is an equivalence relation: http://en.wikipedia.org/wiki/Kolmogorov_space#The_Kolmogorov_quotient

Norbert Received on Sun Apr 21 2013 - 13:40:51 CEST