Re: Representation for Heterogeneous Attribute Set

<robertbrown1971_at_yahoo.com> wrote in message news:1108102001.898621.256240_at_l41g2000cwc.googlegroups.com...
> My company is working on a bond derivative portfolio analysis tool and
> we're facing a problem that I did not see adequately addressed any
> where in literature. I really did RTFM. I'm very experienced in
> relational modelling (10+ years) so this is not a case of not
> understanding the principles. Here is the problem stripped of
> irrelevant context. The problem below is simplified for the sake of the
> example so don't sweat the details.
>
[major snip]

Robert,

Normally, when I see a question like yours, I recommend doing a google search on "relational model generalization".

However, I think, from the examples you provide, that you already know the things most people learn from such a search. You might want to do the search anyway, just to cross check your conclusions.

What follows is, I am afraid, not terribly helpful. I write it in the hope that it can lead somewhere constructive.

The nut of the problem, it seems to me, is the requirement that users can define new types of bonds on the fly.

In classical relational design, a data analysis of the subject matter reveals all the "entities" and "relationships between entities" that are in the universe of discourse. From there, adding the attributes and domains that describe all of the relevant data values is straightforward, if tedious.

The next step is to design a relational model. In this step a fairly limited, and very stable set of tuple types is derived. The tuple types are comprehensive, in the sense that they permit stating all the facts in the universe of discourse in terms of the data domains. You only need to add a new tuple type when the universe of discourse expands.

The next step is to build a physical model, and build the database. When that's done, we generally find that adding a new instance of an existing tuple type can be done by inserting new data. Creating a new tuple type, on the other hand, requires altering the metadata. That's classical relational design and development.

From your outline of the problem, I'm pretty sure you already know everything I've said up to this point, even if you would have phrased it differently.

Now, here's the rub: Can you create a new bond type without creating a new tuple type? I think the answer is no.
Can you create a new tuple type without altering metadata? I think the answer is no.
Can you trust end users with the management of metadata? I think the answer is no.

The usual solution, which you've called "dynamic" is to disguise metadata as data, by storing it in user tables.
That may be the best you are going to do. But it still means that your users are managing metadata, whether they know it or not.

This is not the answer, but it's worth giving some thought. Received on Fri Feb 11 2005 - 14:48:51 CET