Ce chapitre décrit la façon dont les données de référence, l'historique et les tables répliquées sont conservés. Une table peut utiliser n'importe quelle combinaison de modes de persistance des données de référence, d'historisation et de réplication.
Bien que toutes les informations conservées dans TIBCO EBX® soient ensuite stockées dans la base de données sous-jacente en tant que tables relationnelles, le fait qu'elles se trouvent de façon accessible en dehors d'EBX® dépendra du mode mappé.
Le terme mode mappé fait référence à toute table stockée telle quelle et dont le contenu est accessible directement en base de données.
Les données modélisées et gouvernées par le référentiel EBX® peuvent être conservées dans l'un des deux modes suivants : sémantique (par défaut) ou relationnel, selon ce qui a été spécifié dans le modèle de données sous-jacent. Des tables distinctes définies dans l'un ou l'autre mode peuvent coexister et collaborer dans le même référentiel EBX®.
Pour comparer le mode relationnel et le mode sémantique, voir le chapitre Présentation des modes
Les tables de données de référence peuvent activer l'historisation afin de tracer les modifications sur leurs données, indépendamment du fait qu'elles soient conservées en mode sémantique ou relationnel et qu'elles soient répliquées ou non.
L'historique est en mode mappé, ce qui signifie qu'il peut être consulté directement dans la base de données sous-jacente.
La réplication permet un accès SQL direct aux tables, en faisant une copie des données du référentiel vers les tables relationnelles de réplique en base de données. La réplication peut être activée sur n'importe quelle table, indépendamment de son mode de persistance (sémantique ou relationnel) et du fait que l'historique soit activé ou non.
Les répliques sont conservées en mode mappé, leur but principal étant de rendre les données de référence accessibles par requête directe en dehors d'EBX®.
Le mode mappé fait référence aux cas où les tables sont conservées dans la base de données relationnelle sous-jacente dans un format permettant d'accéder directement aux données, en dehors d'EBX®. Les données de référence déclarées en mode relationnel, l'historique et les copies de tables sont autant d'exemples de tables en mode mappé.
Tous les cas de mode mappé impliquent une modification automatique du schéma de la base de données (les tables, les index, etc.) le cas échéant, en exécutant automatiquement les commandes DDL nécessaires en arrière-plan. Ce type de procédure est toujours déclenché au moment de la compilation du modèle de données, et le rapport de compilation du modèle de données signale toute erreur éventuelle.
Autre remarque d'ordre général concernant les modes mappés : la plupart du temps, lorsqu'une entité d'un modèle de données est supprimée, l'objet correspondant en base de données n'est pas supprimé immédiatement. Il est noté comme désactivé, ce qui laisse la possibilité de réactiver l'objet par la suite. Afin de supprimer définitivement de la base de données l'objet et les données et ressources qui y sont associées, il faut le marquer pour la purge. La suppression a alors lieu lors de la purge générale suivante.
En raison de la nature de la persistance directe en base de données sous-jacente, certaines restrictions s'appliquent à toutes les tables stockées en mode mappé :
Longueur illimitée pour les chaînes de caractères : tous les champs chaînes de caractère, excepté les clés étrangères, de type xs:string, leurs types dérivés et xs:anyURI, doivent définir une facette 'maxLength' ou 'length'. Puisqu'un champ de clé étrangère est composé des champs de la clé primaire finale de ses tables cibles, ce critère sur les facettes s'applique à chacun des champs de clé primaire finale, et non au champ de clé étrangère lui-même. De plus, les limitations de la base de données sous-jacente concernant la longueur maximale de ses types de caractères s'appliquent, telles que VARCHAR et NVARCHAR2.
Les longues listes de colonnes sont parfois non-indexables. Exemple sur Oracle : la base de données exige une limite de taille maximale cumulée des colonnes comprises dans un index. Pour les chaînes de caractères, cette taille dépend également du jeu de caractères. Si le serveur de base de données échoue lors de la création de l'index, il sera nécessaire d'envisager de revoir la conception des index, typiquement en réduisant la longueur des colonnes concernées, ou en incluant moins de colonnes dans l'index. Le raisonnement est qu'un index menant à cette situation aurait des en-têtes tellement grands qu'il ne pourrait de toute façon pas être efficace.
Les champs de type type="osd:password" sont ignorés.
Les types complexes terminaux sont supportés ; cependant, ils ne peuvent être définis à null de manière globale, au niveau de l'enregistrement.
D'une façon plus générale, les tables en mode mappé sont soumises aux limitations du SGBDR sous-jacent. Par exemple, le nombre maximum de colonnes dans une table doit être respecté (1000 pour Oracle 11g R2, 1600 pour PostgreSQL). Remarque : une table d'historique contient deux fois plus de champs que ceux déclarés dans le schéma (un champ fonctionnel, plus un champ généré pour le code de l'opération).
Les évolutions du modèle de données peuvent aussi être limitées par le SGBDR sous-jacent, en fonction du modèle de données existant.