Arbeiten mit Repräsentationen in einer versionierten Umgebung

Zum Verständnis der Funktionsweise von Repräsentationen in einer versionierten Umgebung müssen Sie sich zuerst eingehend mit den Prinzipien der Versionierung und mit der Speicherung von Feature-Class-Repräsentationen in der Geodatabase vertraut machen.

Informationen zur VersionierungInformationen zur Speicherung von Repräsentationen

Funktionsweise von Repräsentationen in einer versionierten Umgebung

Feature-Classes mit Repräsentationen werden in einer versionierten Umgebung in sehr ähnlicher Weise wie Feature-Classes ohne Repräsentationen verarbeitet. Im Folgenden finden Sie wichtige Überlegungen zu diesem Thema:

• Die Erstellung einer Repräsentation ist eine Schemaänderung. Da Schemaänderungen nicht versioniert werden können, ist eine Repräsentation, die einer versionierten Feature-Class hinzugefügt wurde, in allen Versionen sichtbar. Analog dazu ist auch das Entfernen einer Repräsentation aus einer Feature-Class in allen Versionen sichtbar. Repräsentationen können nur außerhalb einer Editiersitzung erstellt werden. Informationen zu Repräsentationsregeln werden in der nicht versionierten Systemtabelle gespeichert und gelten daher für die gesamte Datenbank.
• Das Ändern oder Erstellen einer Repräsentationsregel ist eine Schemaänderung.Sämtliche zusätzlichen Regeln oder Änderungen der Struktur, Eigenschaftswerte oder Feldzuordnungen einer Repräsentationsregel sind Schemaänderungen, die in allen Versionen unmittelbar sichtbar ist. Informationen zu Repräsentationsregeln werden in der nicht versionierten Systemtabelle gespeichert und gelten daher für die gesamte Datenbank. Repräsentationsregeln können nur außerhalb einer Editiersitzung geändert werden.
• Das Zuweisen von Repräsentationsregeln zu Features ist eine Attributänderung. Repräsentationsregeln werden Features über das Regel-ID-Feld zugewiesen. Wenn Sie eine andere Regel für ein Feature zuweisen oder für das Feature eine leere Regel festlegen, ist dies eine Attributänderung. Sie ist nur in der aktuellen Version sichtbar. Konflikte können mit den Standardverfahren zum Abgleichen und Zurückschreiben gelöst werden.
• Ein Shape-Override ist eine Attributänderung. Außerhalb der aktuellen Version sind Shape-Overrides erst nach dem Abgleichen und Zurückschreiben sichtbar.
• Das Überschreiben einer Eigenschaft einer Repräsentationsregel ist eine Attributänderung. Overrides werden nur in der aktuellen Version berücksichtigt. Konflikte können mit den Standardverfahren zum Abgleichen und Zurückschreiben gelöst werden.
• Das Konvertieren einer Feature-Repräsentation in eine freie Repräsentation ist eine Attributänderung. Das Erstellen einer freien Repräsentation löst eine Änderung sowohl im Regel-ID-Feld als auch im Override-Feld aus. Wenn es sich bei einer Feature-Repräsentation um eine freie Repräsentation handelt, ist der Regel-ID-Wert stets -1. Konflikte können mit den Standardverfahren zum Abgleichen und Zurückschreiben gelöst werden.

Empfohlene Workflows für die Verwendung von Repräsentationen in einer versionierten Umgebung

Szenario 1

• Bei der Parent-Version (Zielversion) ändert sich der Wert im Feld "RuleID" für eine Feature-Repräsentation von "R" in "R*".
• Bei einer Child-Version (Editierversion) wird dieselbe Feature-Repräsentation bearbeitet, jedoch ein Attribut-Override hinzugefügt, der im Feld "Override" als "O*" gespeichert wird.
  • Die Child-Version wird mit der Parent-Version abgeglichen. Sie erhalten je nach der Definition der Konflikte unterschiedliche Ergebnisse.
  • Zeilenebene: Da dasselbe Feature in beiden Versionen bearbeitet wird, wird ein Konflikt festgestellt. Konflikte können je nach Priorität zugunsten der einen oder der anderen Version gelöst werden. Somit weisen die Felder "RuleID" und "Override" der Repräsentation am Ende entweder die Werte "R" und "O*" oder die Werte "R*" und "O" auf. Die Ergebnisse sind stimmig.
  • Spaltenebene: Es wird zwar dieselbe Feature-Repräsentation bearbeitet, aber die Bearbeitung erfolgt in zwei separaten Feldern oder Attributen, nämlich RuleID und Override. Daher werden keine Konflikte festgestellt. Beim Abgleich enthält das Feld "RuleID" der Feature-Repräsentation den Wert "R*" und das Attribut "Override" der Feature-Repräsentation den Wert "O*". Die Feature-Repräsentation enthält einen Attribut-Override für eine Eigenschaft, die nicht zu der Repräsentationsregel gehört, mit der sie repräsentiert wird. Die Ergebnisse sind unstimmig.
  • Um dies zu vermeiden, verwenden Sie die Option "row_level".

Szenario 2

• Bei einer Parent-Version (Zielversion) wird das Shape der Feature-Repräsentation geändert oder ein Shape-Override hinzugefügt, der im Feld "Override" als "O*" gespeichert wird.
• Bei einer Child-Version (Editierversion) wird dieselbe Feature-Repräsentation bearbeitet, jedoch ein Attribut-Override hinzugefügt, der im Feld "Override" als "O**" gespeichert wird.
• Die Child-Version wird mit der Parent-Version abgeglichen. Gleichgültig, zugunsten welcher Version der Konflikt gelöst wird, das Ergebnis ist immer dasselbe.
  • Zeilen- oder Spaltenebene: In beiden Versionen wird dieselbe Feature-Repräsentation bearbeitet. Zudem wird derselbe Attribut-Override bearbeitet. Shape- und Attribut-Override sind zwar zwei verschiedene Elemente. Nach der Bearbeitung dieser Elemente wird das Ergebnis jedoch im selben Override-Feld gespeichert. Es werden Konflikte festgestellt, und nur eine der Änderungen, "O*" oder "O**", kann beibehalten werden.
  • Behelfslösung: Speichern Sie die Änderungen am Attribut nicht im Feld "Override", sondern in einem expliziten Feld. Wenn beim Abgleich die Definition auf Spaltenebene ausgewählt wird, entstehen keine Konflikte, da die Änderungen in zwei verschiedenen Feldern (nämlich im Feld "Override" und in einem expliziten Feld) vorgenommen wurden. Auf diese Weise können Sie beide Änderungen beibehalten.

Szenario 3

• Bei der Parent-Version (Zielversion) wird für eine Feature-Repräsentation ein Attribut-Override erstellt. Das Feld "Override" wird auf "O*" aktualisiert.
• Bei der Child-Version (Editierversion) wird dieselbe Feature-Repräsentation bearbeitet, die Feature-Repräsentation jedoch in eine freie Repräsentation konvertiert. Der Wert im Feld "RuleID" ändert sich in "-1", und in das Feld "Override" wird ein Grafikobjekt eingefügt. Folglich werden bei diesem Schritt beide Felder, "RuleID" und "Override", in "R*" und "O**" geändert.
• Die Child-Version wird mit der Parent-Version abgeglichen.
  • Zeilen- oder Spaltenebene: Es besteht ein Konflikt. Wenn Sie den Konflikt zugunsten der Parent-Version (Zielversion) lösen, ist das Ergebnis unstimmig. Es besteht ein Attribut-Override, "O*", und der Wert im Feld "RuleID" beträgt "-1" oder "R*".
  • Behelfslösung: Lösen Sie den Konflikt zugunsten der Child-Version, um ein unstimmiges Ergebnis zu vermeiden. Behalten Sie in diesem Fall die durch die Child-Version vorgenommenen Änderungen bei und ignorieren Sie die durch die Parent-Version vorgenommenen Änderungen. Die durch die Parent-Version vorgenommenen Änderungen gehen dabei jedoch verloren.

Szenario 4

Wenn mehrere Kartenprodukte auf mehreren Feature-Class-Repräsentationen basieren, die sich in derselben Feature-Class befinden, verwenden Sie für die Bearbeitung der Kartenprodukte ein Szenario mit mehreren Projekten. Erstellen Sie z. B. eine separate Version für jedes Kartenprodukt: M1, M2, M3 usw. Gleichen Sie diese Versionen nach der Bearbeitung mit den Parent-Versionen (oder mit der Version "SDE.Default") ab, und schreiben Sie sie zurück. Verwenden Sie hierzu die Definition auf Spaltenebene, und lösen Sie mögliche Konflikte zugunsten der Editierversion. Wenn Sie Attribut-Overrides nicht in das Feld "Override", sondern in ein explizites Feld schreiben möchten, können Sie für jedes Kartenprodukt eigene explizite Felder erstellen.

Empfehlungen

• Warum wird ein Konflikt auf Spaltenebene ausgelöst, wenn zwei verschiedene Eigenschaften eines Features in zwei verschiedenen Versionen aufgehoben werden?

  Wenn zwei verschiedene Eigenschaften in zwei verschiedenen Versionen überschrieben werden, kann es zu Verwechslungen kommen. Wenn beide Overrides im Feld "Override" (dem Standardspeicherort für Overrides) gespeichert werden, wird ein Konflikt ausgelöst. Angenommen, ein Feature weist in Version 1 und Version 2 eine Regel namens "Feldweg" auf. In Version 1 wurde die Linienstärke des Feldwegsymbols für dieses Feature aufgehoben. In Version 2 wurde nur die Farbe des Feldwegsymbols für dieses Feature aufgehoben, für die Linienstärke des Features wird die Regel jedoch weiterhin befolgt. Da beide Änderungen im Feld "Override" gespeichert werden, wird beim Abgleichen sowohl auf Zeilen- als auch auf Spaltenebene ein Konflikt ausgelöst, auch wenn eigentlich kein Konflikt zwischen den Änderungen besteht. Zur Vermeidung einer solchen Situation empfiehlt es sich, die Eigenschaften, die wahrscheinlich aufgehoben werden, expliziten Feldern zuzuordnen. Dadurch erfolgen die Änderungen getrennt und in eindeutigen Feldern, sodass sie bei Überprüfungen auf Spaltenebene nicht erkannt werden.

  Weitere Informationen zu expliziten Feldern

• Eine umfangreiche Produktionsdatenbank enthält viele Versionen und eine lange Lineage. Sollte die Registrierung der Feature-Class als versioniert vor dem Aktivieren von Repräsentationen entfernt werden?

  Beim Erstellen neuer Feature-Class-Repräsentationen werden der Feature-Class-Tabelle für alle Versionen zwei neue Felder ("Regel-ID" und "Override") hinzugefügt. Wenn die Repräsentation durch das Konvertieren eines symbolisierten Layers erstellt wurde, wird das Feld "Regel-ID" nur für die aktuelle Version gefüllt. Die Feature-Class-Repräsentation selbst wird in allen anderen Versionen angezeigt, der Regel-ID-Wert ist in diesen Versionen jedoch stets NULL. In diesem Fall kann das Aktualisieren der Regel-IDs für alle Versionen der Datenbank sehr aufwendig sein. Wenn es vom Workflow her möglich ist, sollten Sie die Repräsentationen erstellen, bevor die Datenbank als versioniert registriert wird. Dies ist schneller als das Erstellen von Repräsentationen für eine versionierte Feature-Class, da die Delta-Tabellen nicht gefüllt werden müssen. Wenn alle Änderungen in die Standardversion zurückgeschrieben werden oder die Datenbank zum Beibehalten der Bearbeitungen komprimiert wurde, müssen Sie die Registrierung der Daten als versioniert entfernen, bevor Sie neue Feature-Class-Repräsentationen erstellen können. Beim Erstellen einer neuen Repräsentation werden zwei neue Felder, "RuleID" und "Override" (Änderung des Schemas) erstellt, und das Feld "RuleID" wird mit Werten gefüllt. Wenn Sie in einer Child-Version/abhängigen Version eine neue Feature-Class-Repräsentation erstellen, wird das Feld "RuleID" in den Vorgängerversionen nicht mit Werten gefüllt, obwohl die neuen Felder in allen anderen Versionen erstellt werden. Es empfiehlt sich daher, neue Feature-Class-Repräsentationen in der Version "SDE.Default" zu erstellen, sodass die im Feld "RuleID" angegebenen Werte der Repräsentationsregel an alle abhängigen Versionen weitergeleitet werden.

  Neue Repräsentationen für eine als versioniert registrierte Feature-Class werden langsamer erstellt, da das Feld "RuleID" für alle Features und somit auch die Delta-Tabellen aktualisiert werden. Dieser Vorgang ist zeitaufwändig und hängt direkt von der Größe der Datenbank ab.