[GRASS-user] Modelling 1:n and m:n relationships in GIS
liste at geo-dienstleistung.de
Mon Mar 9 04:36:43 EDT 2009
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.
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,
More information about the grass-user