Utilisation des représentations dans un environnement versionné

Pour comprendre le fonctionnement des représentations dans un environnement versionné, il est primordial de maîtriser les principes du versionnement et du stockage des représentations de classes d'entités dans la géodatabase.

Pour en savoir plus sur le versionnementPour en savoir plus sur le stockage des représentations

Fonctionnement des représentations dans un environnement versionné

Les classes d'entités avec représentations dans un environnement versionné fonctionnent quasiment de la même manière que les classes d'entités sans représentation. Voici quelques notions importantes dont vous devez tenir compte :

• La création d'une représentation est un mouvement de structure. Puisque les mouvements de structure ne peuvent pas être versionnés, une représentation ajoutée à une classe d'entités versionnée sera visible dans toutes les versions. De même, la suppression d'une représentation d'une classe d'entités sera répercutée dans toutes les versions. Les représentations peuvent uniquement être créées en dehors d'une session de mise à jour. Les informations de la règle de représentation sont stockées dans la table système non versionnée et sont donc conservées dans toute la base de données.
• La création ou la modification d'une règle de représentation est un mouvement de structure. Toute règle supplémentaire ou modification de la structure, des valeurs de propriétés ou des appariements de champs d'une règle de représentation constitue un mouvement de structure et est immédiatement répercutée dans toutes les versions. Les informations de la règle de représentation sont stockées dans la table système non versionnée et sont donc conservées dans toute la base de données. Les règles de représentation peuvent être uniquement modifiées en dehors d'une session de mise à jour.
• L'affectation de règles de représentation aux entités est un changement attributaire. Les règles de représentation sont affectées aux entités via le champ d'ID de règle. L'affectation d'une règle différente à une entité (ou l'attribution d'une règle nulle à une entité) constitue un changement attributaire. Ce changement sera uniquement répercuté dans la version en cours. Les conflits peuvent être résolus à l'aide des processus de réconciliation et de réinjection standard.
• Un débrayage de forme est un changement attributaire. Les débrayages de formes seront uniquement répercutés dans la version en cours jusqu'à exécution des opérations de réconciliation et de réinjection.
• Le remplacement d'une propriété d'une règle de représentation est un changement attributaire. Les débrayages seront uniquement répercutés dans la version en cours. Les conflits peuvent être résolus à l'aide des processus de réconciliation et de réinjection standard.
• La conversion d'une représentation d'entité en représentation libre est un changement attributaire. Le processus de création d'une représentation libre déclenche un changement dans le champ d'ID de règle et dans le champ de débrayage. La valeur d'ID de règle est toujours -1 lorsqu'une représentation d'entité est une représentation libre. Les conflits peuvent être résolus à l'aide des processus de réconciliation et de réinjection standard.

Workflows recommandés pour l'utilisation de représentations dans un environnement versionné

Scénario 1

• La version parent (version cible) modifie l'ID de règle de représentation de R à R * pour une représentation d'entité.
• La version enfant (version mise à jour) met à jour la même représentation d'entité mais ajoute un débrayage attributaire, mémorisé dans le champ Débrayage comme O*.
  • La version enfant est réconciliée avec la version parent. Selon la définition des conflits, vous obtiendrez des résultats différents.
  • Au niveau de la ligne : comme la même entité est mise à jour dans les deux versions, un conflit est détecté. Les conflits peuvent être résolus en faveur de l'une ou l'autre version, au choix. La dernière représentation a donc soit ID de règle R avec Débrayage O * ou ID de règle R* avec Débrayage O. Les résultats sont cohérents.
  • Au niveau de la colonne : bien que la même représentation d'entité soit mise à jour, les mises à jour sont effectuées dans deux attributs ou champs séparés, à savoir RuleID et Débrayage, et aucun conflit n'est donc détecté. A la réconciliation, la représentation d'entité a un ID de règle égal à R * et un débrayage attributaire O*. La représentation d'entité a un débrayage attributaire pour une propriété qui n'appartient pas à la règle d'une représentation avec laquelle il est représenté. Les résultats ne sont pas cohérent.
  • Pour éviter cette situation, utilisez plutôt l'option au niveau de la ligne.

Scénario 2

• La version parent (version cible) change la forme d'une représentation d'entité ou ajoute un débrayage de forme, mémorisé dans le champ Débrayage comme O*.
• La version enfant (version mise à jour) met à jour la même représentation d'entité mais ajoute un débrayage attributaire, mémorisé dans le champ Débrayage comme O**.
• La version enfant est réconciliée avec la version parent. Quelle que soit la version en faveur de laquelle vous choisissez de résoudre les conflits, vous obtiendrez le même résultat.
  • Au niveau de la ligne ou de la colonne : la même représentation d'entité est mise à jour dans les deux versions. Les mises à jour sont effectuées pour le même débrayage attributaire. Bien que la forme et les débrayages attributaires soient deux entités séparées, la mise à jour de ces sauvegardes a lieu dans le même champ Débrayage. Les conflits sont détectés et vous pourrez garder l'une des mises à jour, O * ou O**.
  • Solution : stockez les mises à jour attributaires dans un champ explicite au lieu de les stocker dans le champ de débrayage. A la réconciliation, si la définition au niveau de la colonne est sélectionnée, vous n'aurez aucun conflit étant donné que les mises à jour sont effectuées dans deux champs séparés (champ de débrayage et champ explicite). En conséquence, vous serez en mesure de garder les deux mises à jour.

Scénario 3

• La version parent (version cible) crée un débrayage attributaire pour une représentation d'entité. Le champ Débrayage est actualisé à O*.
• La version enfant (version mise à jour) met à jour la même représentation d'entité mais convertit la représentation d'entité en représentation libre. L'ID de règle passe à -1 et un objet graphique est introduit dans le champ Débrayage. En conséquence, cette étape modifie les champs d'ID de règle et Débrayage en R* et O**.
• La version enfant est réconciliée avec la version parent.
  • Au niveau de la ligne ou de la colonne : il y a un conflit. Si vous choisissez de résoudre les conflits en faveur de la version parent (cible), le résultat ne sera pas cohérent. Un débrayage attributaire, O *, existera avec une valeur d'ID de règle égale à -1 ou R*.
  • Solution : choisissez de résoudre les conflits en faveur de la version enfant afin d'éviter des résultats non cohérents. Dans ce cas, gardez les changements faits par la version enfant et ignorez les mises à jour faites par la version parent. Cependant, vous devez noter que les mises à jour effectuées par la version parent sont perdues dans ce cas.

Scénario 4

S'il y a plusieurs produits cartographiques basés sur plusieurs représentations de classes d'entités qui sont présents sur la même classe d'entités, utilisez un scénario Projets multiples pour mettre à jour les produits cartographiques. Par exemple, créez une version distincte pour chaque produit cartographique : M1, M2, M3, etc. Après avoir mis à jour ces versions, effectuez la réconciliation et la réinjection avec les versions parent (ou SDE.Default) à l'aide de la définition au niveau de la colonne et résolvez les éventuels conflits en faveur de la version mise à jour. Si vous voulez écrire des débrayages attributaires à un champ explicite au lieu du champ Débrayage, créez des champs explicites séparés pour chaque produit cartographique.

Meilleures pratiques

• Pourquoi un conflit est-il généré au niveau d'une colonne lorsque je remplace deux propriétés différentes d'une même entité dans deux versions différentes ?

  Une confusion est possible lorsque deux propriétés distinctes sont remplacées dans deux versions différentes. Un conflit survient lorsque les deux débrayages sont stockés dans le champ de débrayage, qui est l'emplacement de stockage par défaut de tous les débrayages. Par exemple, une entité suit la règle Cart Track dans la version 1 et la version 2. Dans la version 1, la largeur de ligne du symbole de la piste a été remplacée pour cette entité. Dans la version 2, seule la couleur du symbole de la piste de cette entité a été remplacée et la largeur de ligne suit toujours la règle. Etant donné que ces deux modifications sont conservées dans le champ de débrayage, un conflit survient pendant la réconciliation à l'aide de la résolution des conflits au niveau des lignes et des colonnes, même lorsque ces modifications ne sont pas réellement en conflit. Pour éviter cette situation, la meilleure pratique consiste à mapper les propriétés que vous êtes susceptible de remplacer à des champs explicites. Ceci permet de séparer les modifications dans des champs uniques afin qu'elles ne soient pas détectées par la vérification au niveau des colonnes.

  Pour en savoir plus sur les champs explicites

• J'utilise une base de données de production volumineuse comportant de nombreuses versions et une longue généalogie. Dois-je désinscrire la classe d'entités comme versionnée avant d'activer des représentations ?

  La création de représentations de classes d'entités ajoute deux nouveaux champs (ID de règle et débrayage) à la table de classes d'entités dans toutes les versions. Si vous avez créé la représentation en convertissant une couche symbolisée, le champ ID de règle est uniquement renseigné dans la version en cours. La représentation de classe d'entités proprement dite apparaît dans toutes les autres versions, mais le champ ID de règle contient la valeur NULL dans ces versions. Dans ce cas, il peut être fastidieux de mettre à jour les ID de règle de toutes les versions de la base de données. Si votre workflow le permet, créez les représentations avant d'enregistrer votre base de données comme versionnée. Cette technique est plus rapide que la création des représentations dans une classe d'entités versionnée, étant donné que les tables delta ne doivent pas être renseignées. Si toutes les mises à jour sont postées dans la version par défaut (ou que la base de données a été compressée pour conserver les mises à jour), désinscrivez les données comme versionnées avant de créer de nouvelles représentations de classes d'entités. La création d'une représentation entraînera la création de deux nouveaux champs, ID de règle et Débrayage (changez dans la structure) et inscrira des valeurs dans le champ ID de règle. Si vous créez une représentation de classe d'entités dans une version enfant/descendant, même si les nouveaux champs sont créés dans toutes les autres versions, les versions antérieures n'inscriront pas de valeurs dans le champ ID de règle. C'est pratique pour créer des représentations de classes d'entités dans la version SDE.Default afin que les valeurs de règle d'une représentation présentes dans le champ ID de règle soient appliquées à toutes les versions descendantes.

  La création de représentations pour une classe d'entités enregistrée comme versionnée sera plus lente, car le champ RuleID est actualisé pour toutes les entités et les tables delta le sont donc également. Ce processus est long et dépend directement de la taille de votre base de données.