Ce chapitre présente les modifications qui peuvent être réalisées sur les modèles de données, ainsi que les éventuelles limitations. Les restrictions et/ou impacts potentiels des évolutions du modèle de données dépendent du mode de persistance. Les principes applicables à chaque mode sont les suivants :
Mode sémantique : flexible et non-bloquant. Peut conduire à une perte de données, par exemple une définition de clé primaire peut évoluer librement, mais tout enregistrement existant, dans un espace de données ou dans un snapshot, qui enfreint la contrainte de clé primaire ne sera plus chargé.
Tout mode mappé : restrictif et donc bloquant si les données existent et si l'évolution viendrait enfreindre leur intégrité.
A chaque évolution du modèle de données, il est crucial d'anticiper la perte potentielle de données. Si la perte est avérée, dans le cas où les données existantes doivent être conservées, un plan de migration de données doit être mis en place et appliqué avant la publication ou le déploiement du nouveau modèle de données. Il est important de noter également que les données ne sont pas détruites immédiatement après l'évolution du modèle de données ; en mode sémantique, du moment qu'aucune mise à jour n'est effectuée sur une table dont la définition a évolué, si le modèle de données est publié à un état précédent, alors les données précédentes sont récupérées.
Certains types d'évolutions du modèle de données ne peuvent être réalisés directement dans l'interface utilisateur. Le modèle de données doit alors être exporté, modifié au format XSD, puis ré-importé. En ce qui concerne les modifications d'un modèle de données impactant également sa configuration, en plus de sa structure, le XSD doit être importé dans TIBCO EBX® à partir d'un module. Sans quoi, les modifications de configuration ne seront pas prises en compte.
Cette section décrit les modifications possibles sur les modèles de données après leur création.
Les modifications suivantes peuvent être effectuées sur les modèles de données existants :
Un modèle de données, en mode sémantique, peut être déclaré comme étant en mode relationnel. Les données doivent être transférées manuellement, en exportant puis ré-important un fichier XML ou une archive.
Le mode relationnel peut être désactivé sur le modèle de données. Les données doivent être transférées manuellement, en exportant puis ré-important un fichier XML ou une archive.
Des unités de réplication peuvent être ajoutées au modèle de données. Si leur politique d'actualisation est 'onCommit', les répliques correspondantes seront créées et actualisées lors de la prochaine compilation de schéma.
Les unités de réplication peuvent être retirées du modèle de données. Les répliques correspondantes seront immédiatement abandonnées.
Le modèle de données peut être supprimé. S'il déclare des unités de réplication, les répliques correspondantes seront immédiatement abandonnées. S'il est relationnel ou contient des tables historisées, cette modification marque les tables mappées associées comme désactivées. Voir Mapping en bases de données pour la suppression effective des objets de base de données associés.
Le modèle de données peut subir les modifications suivantes au niveau de la table :
Une nouvelle table peut être ajoutée. Lors de la création, la table peut aussi déclarer un ou plusieurs modes mappés.
Une table existante peut être supprimée. Si elle déclare des unités de réplication, les répliques correspondantes seront immédiatement abandonnées. Cette modification marque la table mappée comme désactivée, si elle est historisée ou relationnelle. Voir Mapping en bases de données pour la suppression effective des objets de base de données associés.
Une table existante en mode sémantique peut être déclarée comme étant en mode relationnel. Les données doivent être transférées manuellement, en exportant puis ré-important un fichier XML ou une archive.
L'historique peut être activé ou désactivé sur une table. Il ne prendra pas en compte les opérations réalisées pendant sa période de désactivation.
Une table peut être renommée. Les données doivent être transférées manuellement, en exportant puis ré-important un fichier XML ou une archive, car cette modification est considérée comme étant une combinaison de suppression et de création.
Le modèle de données peut subir les modifications suivantes au niveau du champ :
Un nouveau champ peut être ajouté.
Un champ existant peut être supprimé. En mode sémantique, les données du champ supprimé seront retirées de chaque enregistrement lors de sa prochaine mise à jour. Pour une table de réplique, la colonne correspondante est automatiquement supprimée. En mode historique ou relationnel, le champ est marqué comme désactivé.
Un champ peut être spécifiquement désactivé de l'historique ou de la réplication qui s'appliquent à sa table, en utilisant l'attribut disable="true". Pour une table répliquée, la colonne correspondante est automatiquement retirée. Pour une table d'historique, la colonne reste présente mais est marquée comme désactivée. Voir Désactivation de l'historique d'un champ ou d'un groupe spécifique et Désactiver la réplication pour un champ ou un groupe donné.
Les facettes d'un champ peuvent être modifiées, excepté celles listées sous Limitations/restrictions.
Les modifications énoncées ci-dessus sont acceptées, mais peuvent donner lieu à une perte de données. Les données doivent être transférées manuellement, en exportant puis en ré-important un fichier XML ou une archive, car ces modifications sont considérées comme étant la combinaison d'une suppression et d'une création.
Un champ peut être renommé.
Le type d'un champ peut être changé.
Un index peut être ajouté ou renommé.
Un index peut être modifié, en modifiant ses champs ou en changeant leur ordre. En mode mappé, l'index existant est effacé et un autre est créé.
Un index peut être supprimé. En mode mappé, un index supprimé est aussi supprimé de la base de données.
Toutes les limitations listées dans cette section, qui impactent le mode mappé, peuvent être contournées en purgeant les ressources de base de données de la table mappée. Pour la procédure de purge des ressources de base de données de la table mappée, voir Mapping en bases de données.
Lorsqu'une définition de clé primaire est modifiée :
En mode sémantique, les enregistrements existants sont chargés dans le cache uniquement s'ils :
Respectent la contrainte d'unicité de la clé primaire,
Sont conformes à la nouvelle structure de la clé primaire.
En mode mappé, le SGBDR sous-jacent accepte uniquement une modification de clé primaire si tous les enregistrements de la table respectent ses contraintes d'unicité et de non-nullité. En particulier, si une table contient déjà des enregistrements :
L'ajout d'un nouveau champ à la clé primaire nécessite l'attribution d'une valeur par défaut pour ce champ. Contournement : d'abord ajouter le champ, le valoriser pour les enregistrements existants, puis ajouter le champ à la clé primaire.
La suppression d'un champ existant de la clé primaire sera rejetée si elle implique de rendre non unique la clé primaire d'enregistrements existants (l'attribution d'une valeur par défaut ne change rien dans ce cas).
En règle générale, il n'est pas possible de renommer un champ de clé de primaire ; ceci est uniquement possible si ce champ n'était pas nécessaire pour rendre toutes les clés primaires uniques. En effet, le renommage d'un champ se traduit par une combinaison de suppression et de création ; par conséquent, l'opération sera rejetée si elle implique de rendre non unique la clé primaire d'enregistrements existants (l'attribution d'une valeur par défaut ne change rien dans ce cas).
Lorsque la déclaration d'une facette osd:tableRef est ajoutée ou modifiée, ou que la clé primaire de la table cible d'une facette osd:tableRef est modifiée :
En mode sémantique, les valeurs du champ sont uniquement chargées dans le cache si elles respectent la nouvelle structure de la clé primaire cible.
En mode mappé, la structure d'un champ de clé étrangère est définie pour correspondre à celle de la clé primaire cible. Un champ unique déclarant une contrainte osd:tableRef peut alors être divisé en colonnes, dont le nombre et les types correspondent à ceux de la clé primaire cible. Par conséquent, les cas d'évolution suivants auront un impact sur la structure de la table mappée :
déclaration d'une nouvelle contrainte osd:tableRef sur un champ de table ;
suppression d'une contrainte osd:tableRef existante sur un champ de table ;
ajout (respectivement suppression) d'une colonne à (respectivement d') une clé primaire référencée par une contrainte osd:tableRef existante ;
modification du type ou du chemin de n'importe quelle colonne d'une clé primaire référencée par une contrainte osd:tableRef existante.
Ces différents cas d'évolution se traduisent par une combinaison de créations et/ou de suppressions de champs. Par conséquent, les données existantes doivent être transférées manuellement.
En mode mappé, lorsqu'une facette maxLength, length, totalDigits ou fractionDigits est modifiée :
L'acceptation ou non de cette modification dépend du SGBD sous-jacent, ainsi que du type de champ et du contenu de la table.
Par exemple, Oracle acceptera de changer une VARCHAR(20) en VARCHAR(50), mais ne changera une VARCHAR(50) en VARCHAR(20) que si la table ne contient pas de valeurs faisant plus de 20 caractères.
PostgreSQL connaît les mêmes limitations. Par ailleurs, toute modification d'un type de champ (incluant les modifications de sa longueur) invalidera toutes les déclarations pré-établies qui y sont liées et nécessitera un redémarrage du serveur d'application.
Lorsque la cardinalité d'un élément est modifiée :
En mode sémantique, ce changement est pris en charge. Cependant, deux cas sont à distinguer :
Lors de la transformation d'un élément unique vers une liste agrégée, la valeur unique précédente est conservée et ajoutée à la nouvelle liste agrégée.
Lors de la transformation d'une liste agrégée en un élément unique, seule la dernière valeur de la liste agrégée est conservée dans l'élément unique. Les autres valeurs sont perdues.
En mode relationnel, les listes agrégées ne sont pas prises en charge. Un message d'erreur est ajouté au rapport de compilation du modèle de données si un élément est changé en liste agrégée.
En mode historisé, lorsqu'un élément unique est transformé en liste agrégée, la modification est prise en compte, mais la valeur unique précédente est perdue.