Re: [topicmaps-comment] mapping topic maps on a relation database

["Thomas B. Passin" <tpassin@comcast.net>]

[Lars Marius Garshol]
>
> * Thomas B. Passin
> |
> | An association would map to a row in a table,and each role would map
> | to a column in the role.  Of course, this would only make sense if
> | there were many associations built to the same template.
>
> Basically, it only makes sense if you have a strict schema and a topic
> map that conforms to it. The Ontopia Schema Language (OSL) was
> designed to allow just this.
>
Right.

> | This leaves open three points:
> |
> | 1) How to determine the primary key of the table
>
> I would make an ID column for the table. It gets too messy otherwise.
>
> | 2) How to handle multiple role-playing topics with the same role
>
> That one is tricky. It's also tricky in querying, regardless of how
> you store your topic map. I need to work this one out, but haven't had
> time yet.
>
> | 3) How much normalization to apply
>
> Not sure I understand what you mean here. Could you explain?
> (Normalization could mean so many things.)
>

Classically, normalization of a relational data model covers two things:

1) Remove redundancy.
B) Make sure that cells in a row are minimally dependent of each other.  For
example, if you have an address where the city is Chicago, then the state is
always going to be Illinois (no quibbling, please - I don't want to hear
about Chicago, France!).  The two facts are not independent.  This is
related to redundancy but is not exactly the same thing.

I have not analyzed any topic maps with this in mind, but if you were going
to store the data in a large map in a relational database, you would want to
think about it pretty hard, especially if the data were likely to change
often.  Normalization is critical to maintaining data integrity as data is
modified and deleted, as well as for making maintenance and evolution of the
database more reliable.   However, it can work against performance, so there
is always a trade-off between normalization and performance.

Cheers,

Tom P