In the previous article of this series we examined the association construct from the perspective of Entity-Relationship data model. In this post we demonstrate how Topic Map data model represents associations. In order to link the two we continue with another SQL query from our relational database
This will fetch all the rows of a result set where we are looking for the minimum catalogue price of a Red Fire Hydrant Cap and who is the supplier that manufactures this part. The reader will notice that apart from the deficiensy of the nested JOINs, (see here), we had to formalize our search in SQL language in order to get back our result. Wouldn’t be nice if we could engage the user in a codeless style of search, independent of the business case. Let us see the difference with the Topic Map data model first.
Our first step is to build a Topic Map data model from the SQL result set above. With Wandora this is easy thanks to its powerful set of extractors. Here we use an Excel adjacency list extractor to convert each spreadsheet row of this Excel file to a Topic Map.
In the right panel of the screen capture, you may see that we have four associations of type. They are all sorted by the column. This is the role that cells of this column play in the Tuple association. In our example each Tuple is an instance of the class with a maximum of 8 members and each member plays a role in the association. You may agree that this Topic Map model view of data looks already very familiar to the user that is accustomed with tables.
But behind the scenes Topic Map associations are notably different from the n-ary tuples of the relational model. In the left panel of our screen capture you can see all the data that are extracted from the spreadsheet. Notice that no data value is repeated. Each association is constructed from single instance values and this also means that associations are sharing values among them. We can visualize the network of associations by switching to Wandora’s Graph topic panel.