Die zweite Idee (ein boolesches Attribut zur Auswahl zu erstellen) hat viele Vorteile :
(i) es dokumentiert klar, was gekennzeichnet werden muss,
(ii) es ist so dauerhaft und portabel wie der zugrunde liegende Datensatz,
(iii) es bietet einen einfachen und direkten Mechanismus, um zu bestimmen, welche Etiketten angezeigt werden (der sogar auf ein anderes GIS oder Plotpaket portierbar ist),
(iv) es ist sogar für eine Analyse zugänglich, falls es jemals Fragen zu den Beziehungen zwischen diesen Auswahlmöglichkeiten von Bezeichnungen und anderen Variablen gibt, und
(v) durch sparsame Kodierung der Wahl des Kunden werden keine doppelten Informationen erstellt.
Hier gelten einige allgemeine Prinzipien für die Erstellung und Verwaltung von Datenbanken , wie in der Frage mit Bedacht vorgeschlagen. Eine davon ist, dass kohärente Informationen nach Möglichkeit in der Datenbank eindeutig dargestellt werden sollten. (Informationen, die als Schlüssel zum Implementieren von Verknüpfungen und Bezügen verwendet werden, müssen natürlich an mehreren Stellen erscheinen, da sie dazu dienen, entsprechende Datensätze in verschiedenen Tabellen zu identifizieren.) Es gibt ausgezeichnete Gründe für dieses Prinzip, wie jeder, der versucht hat, einen nicht normalisierten Wert beizubehalten Eine relationale Datenbank kann bestätigen: Wenn Sie nicht konsequent daran denken, diese Informationen zu aktualisieren, zu entfernen oder zu allen hinzuzufügen In der Tabelle, in der es angezeigt wird, wird Ihre Datenbank bald intern inkonsistent: Sie ist beschädigt, oft unwiederbringlich.
Ein weiteres Prinzip ist, dass in einem guten relationalen Datenbankdesign jede Tabelle eine einzelne konzeptionelle "Entität" darstellen sollte : etwas, das die Daten modellieren, oder eine Beziehung zwischen diesen Dingen. Wenn ein Client eine scheinbar willkürliche Auswahl von Features angibt, gibt er effektiv eine Teilmenge von Zeilen in einer Tabelle an. Mathematisch gesehen ist dies nach dem Axiom der Trennung dasselbe wie das Markieren mit einem Booleschen Feld. Somit kann jede sinnvolle "beliebige" Teilmenge von Dingen in einer Datenbank durch ein boolesches Feld dargestellt werden, und umgekehrt ist ein solches Feld eine gute Möglichkeit, beliebige Teilmengen (oder Auswahlen) zu speichern.
Ein weiteres Prinzip ist, dass Sie es vorziehen sollten , die zugrunde liegenden Datenverwaltungsfunktionen des GIS zum Speichern von Informationen zu verwenden . Die Alternative ist eine Ad-hoc- AlternativeMethode, die auf der Fähigkeit des GIS basiert, Informationen in seinen "Projektdateien" oder auf andere unabhängige Weise zu speichern. Ein typisches Beispiel hierfür ist die manuelle Auswahl und Platzierung der gewünschten Etiketten. Oft ist dies schnell und einfach möglich. Die Probleme treten immer dann auf, wenn entweder eine Änderung erforderlich ist oder die Arbeit reproduziert werden muss. Die eine oder andere dieser Situationen ist praktisch unvermeidlich. Die manuelle Platzierung der Beschriftungen ist gleichbedeutend mit der extrem elliptischen Speicherung von Informationen (dh welche Teilmenge von Merkmalen beschriftet werden soll) außerhalb des RDBMS. Die Auswahl gibt nämlich nur an, welche Beschriftungen erscheinen und welche nicht. Überlegen Sie, wie Sie diese Folgeprobleme lösen könnten:
Der Kunde möchte, dass dieselben Beschriftungen in einer verwandten, aber unterschiedlichen Karte angezeigt werden, die Teil eines anderen Projekts ist.
Es stellt sich die Frage, ob die Beschriftungen einem anderen Attribut zugeordnet sind.
Nachdem Sie im Laufe der Zeit mehrere Änderungen an den Beschriftungen vorgenommen haben, werden Sie aufgefordert, zur Originalversion zurückzukehren.
In diesen Fällen kann der Aufwand zur Lösung des Problems enorm sein: Sie müssen die Beschriftung erneut wiederholen oder manuelle Gegenprüfungen für Datenbanktabellen durchführen oder eine alte archivierte Projektdatei suchen und wiederherstellen. Wenn die Beschriftungen stattdessen durch ein boolesches Feld in der Datenbank dargestellt würden, wäre die Arbeit fast trivial.
