[GRASS-user] Modelling 1:n and m:n relationships in GIS

[Frank Broniewski]

Normalization of data and GIS is a difficult topic. I tend to seperate 
geometry and data into different tables and join them together by need. This 
makes it easier to modify the geometry without touching the data or even use 
different representation forms, e.g. point sizes vs. choroplethe maps.

If more than one table maps to geometry and all the data is really needed for 
querying I create a denormalized table with all the fields needed in it, 
usually by creating a view. This works well when there is only one value in 
each table corresponding to the geometry. When there's more you'd need to 
aggregate your data somehow.
Depending on the user interface it is also possible to write your own query 
interface which is capable of getting data over multiple tables and dealing 
with 1:n relationships more nicely than aggregate views.

Concerning m:n relations - depending on which side has geometry it is really 
nothing else than a 1:n relationship in a certain direction. If both sides 
have geometry you would need to create one layer for each side and then its 
again nothing else than a 1:n relation.

Frank

On Monday 09 March 2009 00:00:27 Benjamin Ducke wrote:
> Dear all,
>
> I keep getting into situations where mapping 1:n and m:n relationships
> in relational DBMS to GIS vector models becomes a problem.
> The toughest restrictions of course are the 1:1 relation between map
> features and attribute table records and the fact that GIS relates
> data by spatial overlay, not foreign fields. I realize that some GIS
> (like GRASS) are somewhat more flexible in that they can attach more
> than one attribute table to a layer, but I am really looking for more
> portable ways to deal with this.
>
> - How do you deal with 1:n and m:n relations in GIS?
>
> - What do you do if there are no spatial representations for the
> records on the "n" side? Can that be handled at all?
>
> Apparently, it would be possible to model some of this using overlapping
> features in Shapefiles, but that would violate topology rules.
>
> Any ideas are very welcome, indeed!
>
> Thanks, everyone,
>
> Ben