Re: circular relationships ok?

Alexandr Savinov wrote:
> David Portas schrieb:
> > Alexandr Savinov wrote:
> >
> >> Now for each order there as an invoice and vice verse (we need of course
> >> a constraint to enforce one-to-one relationship).
> >
> > So you DO allow constraints that are cyclical. This constraint (called
> > "N-cardinality", where N=1) applies "in both directions". In a
> > conventional ER diagram this would be shown as a cycle. Your diagrams
> > on the other hand don't seem to model constraints - they show something
> > else that isn't clear to me. That something else doesn't have any
> > cycles.
>
> Concept graph visualizes what the database will manage and nothing else.
> It represents the formal model. This can be viewed as a reference
> structure: if A reference B then we draw an upward arrow from A to B.
> You are probably talking about informal relationships in the sense of ER
> model. Since these relationships are not managed by the database they
> may have any structure including cycles.
>
> > The OPs original question was specifically about cycles in referential
> > integrity constraints, which you do say you need in your model (you
> > just don't draw pictures of them).
>
> The question was how to get rid of cycles.
>
> The problem however is that there exist different types of cycles.
> Informally we can (and we should) represent all of them. We can draw
> them like it is done in ER model. I am talking about very concrete type
> of cycles, namely, cycles that are known to the database and implemented
> via references. And for this type of relationship implemented via
> references we have to prohibit cycles in order to get significant
> advantages in automating data management. All other types of
> relationships that are not managed by the database may have any
> desirable structure and constraints. Thus we may and we need to model
> cycles and even more complex relationships but we have to do it without
> cycles in reference structure. Why? Because the database will not be
> able to manage such data (only trivial operations are possible). With no
> cycles the database is able to manage the data as a global interrelated
> structure.
>

You are so completely wrong about constraints as far as the relational model and ERD is concerned. An ER diagram represents a set of entities with:

1. entity integrity constraints (AKA candidate keys)
2. referential integrity constraints (AKA foreign keys)

There is NOTHING "informal" about referential constraints (in RM). They are ALWAYS managed and enforced by the database management system (again, in RM).

In any case you have clearly explained that your concept graphs do not represent constraints and therefore I assume constraints with cycles are not eliminated or forbidden by your model. You seem to be indicating that constraints are not part of "concept oriented" AT ALL, which has to be a massive deficit when compared to RM. But thanks for the explanation. I think I've had the answer I was waiting for.

--
David Portas