This module's project was to design a conceptual database for tracking historical water quality data across Pensacola (Escambia and Santa Rosa counties) which is the kind of database that would support mapping water quality trends to inform land-use decisions, similar in spirit to how FDEP's STORET system aggregates water sampling data statewide. Given my work with water quality and regulatory data at DEP, this exercise mapped closely onto real problems I already think about.
The task was to build an entity-relationship diagram (ERD) covering entities like county boundaries, hydrological units, water bodies, water sample stations, and water sample measurements. We were also tasked to make deliberate choices about cardinality (how entities relate: one-to-many, many-to-many) and how to visually distinguish spatial from non-spatial entities, following the modeling framework from Calkins (1996).
I modeled overlapping spatial features like land use polygons and county boundaries, or water bodies and hydrologic units as many-to-many relationships, since real-world spatial overlap is rarely clean or exclusive. Hierarchical or event-based relationships, by contrast, I modeled as one-to-many: a single water sample station can produce many measurements over time, but each measurement belongs to exactly one station; a water body can contain many sample stations, but each station sits in only one water body at a time.
Following Calkins' framework, I distinguished spatial entities (marked with geometry type and G/T indicators) from non-spatial entities like the Water Quality Organization table, which tracks administrative assignment rather than anything with coordinates. I also used different connector shapes (hexagons for spatial/topological relationships, diamonds for non-spatial ones) so the diagram is able to visually separate "this is geometry" from "this is supporting attribute data" at a glance.
The module also asked whether Calkins' and Akinyemi's spatial-relationship frameworks are actually necessary for GIS design. I believe they matter most when a system needs to support real spatial analysis such as routing, tracing, or topology-aware queries. Road networks and stream flowlines often need built-in topology, and land-use overlays rely more on coordinate-based intersection queries. Without deliberately designing for that distinction upfront, it's easy to end up with a database that displays data fine, but can't actually support the analysis that it was built for.
No comments:
Post a Comment