Ist ein guter Datenbankentwurf für räumliche Datenbanken weniger wichtig?

Ich habe das starke Gefühl, dass Datenbankdesign und -normalisierung beim Umgang mit Geodaten häufig aus zweiter Hand kommen.

Bei Software, die ein Vermögen kostet und Datenbanken mit über 100 Feldern, muss ich fragen:

Gibt es gute Gründe für andere Überlegungen als die Normalisierung beim Entwerfen einer räumlichen Datenbank?

Ich denke, die Leute werden nach Beispielen fragen, aber das kann ich hier nicht angeben, deshalb ist meine Frage vielleicht eher für diejenigen gedacht, die meinen, dass 100 Felder kein Problem sind und einfacher zu pflegen sind als ein ordnungsgemäß normalisiertes Design.

Was sind die Argumente?

Ich bin der Meinung, dass räumliche Datenbanken nicht anders behandelt werden sollten als herkömmliche Datenbanken. Sie tun im Wesentlichen das Gleiche und speichern große Datenmengen für den schnellen Abruf. In PostgreSQL / PostGIS ist die Geometrie beispielsweise nur ein weiterer Datentyp. Genau wie Text oder eine Ganzzahl. Dasselbe in SQL Server 2008. Dasselbe in Oracle. Wenn der "räumliche" Teil nur ein anderer Feldtyp in der Datenbank ist, unterscheidet er sich dann wirklich so von der ursprünglichen Datenbank? Bedeutet dies, dass wir alle Regeln des traditionellen Datenbankdesigns verwerfen sollten?

Natürlich kann die Normalisierung zu weit gehen, genau wie bei herkömmlichen Datenbanken. Daher ist es ein Kompromiss, das beste Design zu finden, das Ihren Anforderungen entspricht.

Wenn Sie vorhaben, eine stark de-normalisierte Struktur mit Tabellen von 100 Spalten zu erstellen, müssen Sie sich fragen, was sich in Zukunft wahrscheinlich ändern wird. Beeinträchtigt dies bei einem enormen Anstieg der Zeilen auch die Abfrageleistung? Wird dies die Wartbarkeit in Zukunft beeinträchtigen?

Was ist falsch daran, eine normalisierte Struktur zu erstellen und Ansichten zu verwenden, um alle Daten für den Datenbank-Client verfügbar zu machen, sei es für GIS oder einen anderen Client?

Alle diese Fragen gelten sowohl für traditionelle Datenbanken als auch für räumliche Datenbanken. Wenn Sie http://en.wikipedia.org/wiki/Database_normalization durchgehen, werden Sie feststellen, dass dies auch für räumliche Datenbanken gilt.

Wenn die Software, die Sie über der Datenbank verwenden, Sie dazu zwingt, stark de-normalisierte Strukturen zu verwenden, ist dies ein anderes Argument. Sie sind von der Software und nicht von der Datenbank abhängig, sodass Sie keine Auswahl für das beste Datenbankdesign haben.

Ich denke also, die kurze Antwort ist (meiner Meinung nach), dass Datenbankdesign bei räumlichen Datenbanken genauso wichtig ist wie bei traditionellen Datenbanken.

Ich sehe das sehr. Ich bin der Meinung, dass dies auf die Tatsache zurückzuführen ist, dass GIS-Mitarbeiter traditionell aus Vermessungsunternehmen stammen und keinen Hintergrund bzw. kein Verständnis für Datenbanken haben. Ich sehe diese Änderung jedoch, da immer mehr Organisationen die GIS-Infrastruktur in die IT-Branche verlagern.

GIS Software Legacy

Aufgrund der hohen Kosten für ArcSDE und des Fehlens eines räumlichen Datentyps in SQL Server (bis 2008) und von Oracle bis zur Version 10 blieb vielen Organisationen nur die Wahl, Daten in Shapefiles zu speichern (und von Bietern, um die Gebotskosten niedrig zu halten). .

Die Einführung von systemeigenen räumlichen Typen in SQL Server bedeutete, dass ArcSDE von einer enormen Investition in die kostenlose Integration in ArcGIS und das "Zusammenführen" von räumlichen Daten in Organisationen überging.

Organisationen, die ArcGIS und SQL Server verwenden, hatten zuvor drei Möglichkeiten:

1. Bezahlen Sie die Gebühr von über 20.000, um ArcSDE zu kaufen und räumliche Daten in "richtigen" SQL Server-Datenbanken zu speichern.
2. Speichern Sie räumliche Daten in Shapefiles / persönlichen GDBs und verknüpfen Sie sie mit den restlichen Organisationsdaten in Datenbanken (oder exportieren Sie diese Attribute in DBFs).
3. Wechseln Sie zwischen GIS-Anbietern und speichern Sie räumliche Daten in einer einzigen Datenbank, jedoch in einem Format, auf das nur die neue GIS-Software zugreifen kann

Sobald SQL Server einen systemeigenen räumlichen Typ hatte, verwendeten die meisten Anbieter diesen anstelle ihrer proprietären Formate, sodass andere Anwendungen plötzlich auf räumliche Daten zugreifen konnten. ESRI musste entweder die Kosten für ArcSDE senken (durch Integration in ArcGIS) und / oder die Speicherung von räumlichen Daten im nativen Datenbankformat ermöglichen.

Darüber hinaus mussten in ArcIMS ausgeführte Abfragen von Shapefiles, die mit DBFs verknüpft sind, alle erforderlichen Felder und Duplikate enthalten, da keine Möglichkeit bestand, räumliche Ansichten zu erstellen oder Features einfach mit einer Back-End-Datenbank zu verknüpfen.

Organisatorische Gründe

Ich stimme anderen zu, dass Geodaten bis vor kurzem zu einem systemeigenen Datenbanktyp wurden, der von Datenbankadministratoren in Organisationen lange Zeit ignoriert oder getrennt wurde, und somit die Verantwortung eines GIS-Managers tragen. Die Konzepte des Datenbankdesigns, der Normalisierung, der Replikation, der Sicherheit und der SQL-Ansichten erfordern häufig sehr unterschiedliche und spezialisierte Kenntnisse und können im Laufe der Zeit nicht leicht erlernt werden.

Kostengründe

In einer Ausschreibung zu erklären, dass für ein Datenmodell viel Zeit und Mühe aufgewendet werden muss, und Daten zu bereinigen / in dieses Modell zu importieren, ist häufig unmöglich. Oft kommen die Projekteinkäufer aus einer analytischen Sicht von GIS und übersehen die Bedeutung strukturierter Daten.

Mit 100-Spalten-Tabellen meine ich die Arten von Ausgaben, die Sie durch das Erstellen von "Master Coverage" -Overlays mehrerer Eingaben erhalten. Ja, dies sind Artefakte des Arc / INFO-Workflows. In der Verteidigung können Sie sich diese Tabellen jedoch auch als absichtlich de-normalisierte Tabellen für OLAP vorstellen . Da sie hauptsächlich für die Abfrageverarbeitung und nicht für die Datenaktualisierung verwendet werden, ist das de-normalisierte Formular sinnvoll. Wie ein Sternschema , aber ohne die, äh, Punkte. OK, schwacher Tee, aber ich denke immer noch, dass da etwas ist.

Ja, wenn der Start eines neuen GI-Projektdesigns wichtig ist und in Zukunft Zeit = Geld sparen kann. http://www.amazon.com/Spatial-Database-Systems-Implementation-Management/dp/1402053916 bietet einen guten Überblick darüber, warum dies wichtig ist.