Re: circular relationships ok?

David Portas schrieb:
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:

A) entity integrity constraints (AKA candidate keys)
B) 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).

And how they are managed, could you explain? The only thing it can do is to execute queries and constraints. In other words, without this information the database knows almost nothing about data. But it is already another issues so let us return to our cycles.

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.

You always try to make global conclusions like the world is unfair and some model is bad. Let us consider the following example:

an Order references one customer (who made this order)
a Item reference one order it belongs to
a Customer reference one item he wants to be delivered first (for some reason)

We have a cycle. There are two opinions:

1. That is quire normal and there is nothing bad here. Moreover, it is frequently used pattern.

2. That has to be prohibited because it not only prevents us from developing "good" formal properties but also is a rare and unusual situation in practice.

You insist that the first option is right while I prefer the second option. Here are my arguments:

- cycles reflect infinite containment relation
- cycles produce infinite dimensions
- cycle produce problems in cascaded operations
- cycles produce problems with grouping, aggregation and inference

Notice that it has nothing to do with constraints imposed on data and implementing cycles indirectly. We still can impose any constraints just as in RM. The only difference is that we avoid cycles in referencing.

--
David Portas

.

Relevant Pages

  • Re: A real world example
    ... If a constraint is defined in terms of successive states of a database, ... Yes, that's all facts are, though constraints mean that your facts are ... value of a candidate key determines the values of all other attributes, ... The frame of reference for a candidate key is a ...
    (comp.databases.theory)
  • Re: CLP(FD) Prolog: help needed with a simple problem
    ... Chema wrote: ... >> constraints to prevent cycles. ... > The problem is just to find this constraints. ... > Right now, I've used a kind of incidence matrix, then I've ...
    (comp.lang.prolog)
  • Re: circular relationships ok?
    ... So you DO allow constraints that are cyclical. ... Concept graph visualizes what the database will manage and nothing else. ... if A reference B then we draw an upward arrow from A to B. ... may have any structure including cycles. ...
    (comp.databases.theory)
  • Re: CLP(FD) Prolog: help needed with a simple problem
    ... >, state that the sum ... > constraints to prevent cycles. ... Thank you for your replay and suggestion. ... The problem is just to find this constraints. ...
    (comp.lang.prolog)
  • Re: circular relationships ok?
    ... We still can impose any constraints just ... The only difference is that we avoid cycles in referencing. ... In RM, foreign key references ARE ... same cycles in constraints but you call them "indirect" for some ...
    (comp.databases.theory)