Re: "Structured" Entity-Relationship Model?
Date: Sun, 21 Apr 2013 15:35:37 +0200
Message-ID: <5173eb29$0$6369$e4fe514c_at_dreader35.news.xs4all.nl>
On 2013-04-20 20:02:46 +0000, Wolfgang Keller said:
> 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
Right. SERM. Part of Aris, a SAP thing. The hierarchical database model, once again trying to make a come back in a new disguise. :-)
> 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.
The German page is more explicit and does mention this rule.
> 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.
>
> 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?
It has nothing to do with normalization in the classical relational theory sense of the word.
In theory it can always be achieved: you can take any ER diagram (or a dialect that also has the associative entity concept) and turn it into a SER diagram by suitably picking the direction of the connections between entitties and relationships. However, that direction might not always be natural or intuitively clear.
You should not think of SERM as a replacement of ERM, rather it is a slightly specialized form of it that introduces certain modelling artifacts that help with certain practical implementation issues, but can be conceptually meaningless. This can work well if you have a data management layer that offers you a SERM interface. Less so if you don't and will ultimately map it to a relational or SQL-based data management system.
So summarizing, the answer to your question is: - At the conceptual level this restriction is nonsensical. - At the logical level it can be useful.
- Jan Hidders