Re: circular relationships ok?
Date: Thu, 02 Mar 2006 19:54:19 -0100
Message-ID: <44075b78_at_news.fhg.de>
Volker Hetzer schrieb:
> Alexandr Savinov schrieb:
>> Volker Hetzer schrieb:
>>> Alexandr Savinov schrieb:
>>>> A model with cycles is not a concept-oriented model (theoretically).
>>>> It is a strong constraint but it is part of the definition. Then the
>>>> question is if it is useful or not. For any model there are examples
>>>> which are non-trivial and very difficult to implement. Loops and
>>>> cycles can be always avoided by introducing a common subconcept. If
>>>> A and B mutual reference each other then we introduce a common
>>>> subconcept C:
>>>>
>>>> A B
>>>> \ /
>>>> C
>>>
>>> Ok, here goes:
>>>
>>> Net<-------\
>>> | |
>>> V |
>>> Constraint*|
>>> | |
>>> V |
>>> Token* |
>>> / \ |
>>> | -----/
>>> V
>>> Constant
>>>
>>> (* denotes "zero or more")
>>> ("Token" refers to either a constant or a Net, not both.)
>>>
>>> How would you do it?
>>> Maybe I'm blind but I simply don't see it.
>>> My problem is that the relations are directed. A Nrt doesn't
>>> refer to constraints and tokens, a net refers to constraints
>>> and the token optionally refers to another net.
>>> Even if I add a Token/Net table, I still have the circle.
>>
>> Try the following approach in order to find directions for arrows and
>> establish an order without cycles. Assume that you do not have any
>> entities and your model is empty. Then take, say, Net, and ask a
>> question:
>>
>> - Does net know what is a Constant? Can it exist without Constants? Is
>> it created before Constants? Is it more general thing than Constant?
> A net can exist alone, without any constraints.
So net does not reference any other item.
> A constraint always needs a net, it doesn't need tokens.
So constraint item will reference (know) a net. It will not reference a token.
> A token needs a constraint, and it needs either a net or a constant.
So a token references constraint. For OR you might define two fields, it is a separate problem in data modeling.
> The tricky bit is deleting a net. If that net is referenced by other > tokens, the delete ought to fail.
No, in good model it should be managed automatically. If you delete a collection then all its elements have to be also deleted (we treat a referenced item as a collection). In the concept-oriented model the deletion is propagated automatically down till the bottom. However, the deletion is not necessary a physical deletion. It is more general. When you delete a data item, say a net object, then you actually say that it does not exist anymore as an entity. The non-existence then is expressed as physical deletion of this item. However, for all its subitems (items that reference this item) we do not use physical deletion but rather we set this reference to null. Since null is equivalent to non-existence (in COM) then it is quite correct operation. So a token that referenced the deleted net will have null instead of it automatically. However, each concept where data items live should define if null is permitted, i.e., if this item can exist with null in some position. If not then this item is automatically deleted and, as a consequence, its subitems are assigned null value in the corresponding field. This operation is then propagated down to the bottom.
By the way, the deletion can propagate also upward and in this case it is based on reference counting. If some item is referenced less than N times (by its subitems) then it can be automatically deleted. If N=0 then it is precisely garbage collection mechanism. Items which are not referenced are deleted.
> I need to think that over. > >>
>> I thing yes, but you should decide yourself. If so then Net is
>> positioned above Constant and any constant object can reference one
>> object.
>>
>> The same question should be asked about other pairs of concepts. As
>> far as understand your problem domain, Net is the primary object which
>> is able to exist without any constraints. However, constraints are not
>> able to exist without a net. So a net object should not reference any
>> other object in your model and has to be positioned at the top. (No
>> outgoing arrows from Nets.)
>>
>> Constraint is probably the most specific concept. It has to know
>> (reference) a net (for which it is created), a constant and other
>> elements it involves. So position it at the bottom and all arrows will
>> originate in it. However, if we need to reference several elements,
>> say, a constraint can be used in many nets then we need a common
>> subconcept,say, NetConstraint which references both. The same is
>> applied to other relationships.
>> > > Thanks a lot! > Volker
http://conceptoriented.com Received on Thu Mar 02 2006 - 21:54:19 CET