Re: circular relationships ok?

From: Alexandr Savinov <spam_at_conceptoriented.com>
Date: Thu, 02 Mar 2006 15:48:50 +0100
Message-ID: <440705d2$1@news.fhg.de>

Volker Hetzer schrieb:

> Alexandr Savinov schrieb:

>> Volker Hetzer schrieb:
>>> Hi!
>>> Just in general, are circular relationships something that
>>> can always be avoided?
>>> Or, given a model with a circular relationship, possibly
>>> spanning several tables, is there a way to get rid of them?
>>
>> One approach consists in using the concept-oriented data model as
>> follows.
>>
>> 1. Order your tables so that if table A references records from table
>> B, then A is positioned under B. For example, if an order has a field
>> with its customer then you position them as follows:
>>
>> Customre
>> |
>> Order

> So, what if A references B, B references C and C references A?

Generally, that is very bad idea. In programming it is unavoidable (for fundamental reasons). In data modeling it can be and should be avoided. It can be substantiated from many different sides. Here are some of them   adapted for data modeling. If an element e1 references element e2 then it is interpreted as e1 is a member of e2, where e2 is a collection (logical collection, not physical). In other words, if a thing has an attribute value then this value is a set where it is a member. For example, if a product references a category then the category is a collection while this product is a member of this collection. If a product has a color then this color is a collection and this product is a member of this collection. Manipulating attribute values in this case is equivalent to manipulating collections. Now assume that you have a cycle. This means that an element is a member of itself and it is normally interpreted as a non-sense. A wide spread approach to data modeling is manipulating groups of data, i.e., viewing data as structured using collections. In this case we want these collections to be consistent and have no cycles. Why? For example, having ordered your data by organizing it in collections you can build levels of details. Naturally we do not want to have a cycle somewhere in our structure of levels because that would mean that one level is a more specific or more general level of itself.

In most existing models this constraint is not taken into account so that you are free to build any meaningless data structure you want. Having this constraint (ordered elements with no cycles) you have a number of other advantages. It allows you to carry complex analytical operations, meaningfully query data etc.

-- 
http://conceptoriented.com

Received on Thu Mar 02 2006 - 08:48:50 CST