Le mode sémantique présente toutes les fonctionnalités avancées de TIBCO EBX® en matière de gestion de données de référence. En particulier les espaces de données, l'héritage des jeux de données et les champs hérités.
Le mode sémantique est le mode par défaut de persistance des données gouvernées par le référentiel EBX®. Les modèles de données sont en mode sémantique, à moins que le mode relationnel ne soit spécifié de manière explicite.
En interne, les données de référence gérées en mode sémantique sont représentées en XML standard, conformément au document XML Schema de son modèle de données. La représentation XML est compressée à nouveau et segmentée pour être stockée dans des tables génériques de bases de données relationnelles. Ce mode permet de stocker et d'accéder efficacement aux données, notamment pour :
les espaces de données: lors de la création d'un espace de données enfant, aucune donnée n'est dupliquée, et
l'héritage : aucune donnée n'est dupliquée lors de la création d'une instance héritée.
Le mode sémantique permet aussi de maintenir un nombre illimité de jeux de données pour chaque modèle de données, organisés dans un nombre illimité d'espaces de données et d'images. Tout cela sans impacter le schéma de base de données.
Comme ce mode n'utilise que des tables communes internes et génériques, les modifications de structure du modèle de données n'ont pas non plus d'impact sur le schéma de base de données. Les évolutions du modèle de données n'impactent que le contenu des tables génériques de la base de données.
Le mode relationnel, qui est un mode mappé, conserve les données de référence directement dans la base de données. Le but premier du mode relationnel est de pouvoir tirer parti des performances et des capacités de montée en charge de la base de données relationnelle sous-jacente. Cependant, le mode relationnel ne gère pas les fonctionnalités avancées de gouvernance proposées en mode sémantique.
Dans certains cas où les avantages de la gestion en mode sémantique ne sont pas indispensables, comme pour les tables "à un instant donné", ou les tables mises à jour régulièrement par des systèmes externes, les gains de performance offerts en mode relationnel peuvent être plus utiles.
De manière générale, quand un jeu de données est en mode relationnel, chaque table de ce jeu de données possède une table correspondante dans la base de données, et tous les champs de son modèle de données correspondent à une colonne de table relationnelle.
Le tableau suivant résume les différences entre les deux modes de persistance :
Mode sémantique | Mode relationnel | |
|---|---|---|
Espaces de données | Oui | Non |
Héritage de jeu de données | Oui | Non |
Champs hérités | Oui | Non |
Modèle de données | Toutes les fonctionnalités sont supportées. | Des restrictions s'appliquent, voir Restrictions du modèle de données pour les tables en mode relationnel. |
Lectures directes en SQL | Non | Oui, voir Lectures SQL. |
Écritures directes en SQL | Non | Oui, mais uniquement sous certaines conditions spécifiques, voir Écritures SQL. |
Validation des données | Oui, active le mode tolérant. | Oui, certaines contraintes deviennent bloquantes, voir Validation. |
Transactions | ||
Évolutions du modèle de données | Voir Évolutions du modèle de données dans le Manuel de référence. | Voir Évolutions du modèle de données dans le Manuel de référence. |
Le modèle de données déclare qu'il est en mode relationnel. En raison des contraintes intrinsèques au mode relationnel, telles que l'absence d'espace de données enfant ou d'image, un espace de données relationnel spécifique devra être fourni, sur lequel le modèle de données sera publié. Les espaces de données relationnels ne permettent pas de créer de sous-espaces de données ou d'images.
Exemple d'une déclaration de mode relationnel :
<xs:schema> <xs:annotation> <xs:appinfo> <osd:relationalMode> <dataSpace>aDataSpaceKey</dataSpace> <dataSet>aDataSetReference</dataSet> <tablesPrefix>aPrefixForTablesInRDBMS</tablesPrefix> </osd:relationalMode> </xs:appinfo> </xs:annotation> ...</xs:schema> |
avec les éléments :
Élément | Description | Requis |
|---|---|---|
| Désigne l'espace de données dans lequel le modèle de données doit être publié. Cet espace de données doit être lui-même en mode relationnel. Aucun espace de données ou image ne peut être créé à partir de l'espace de données déclaré dans ce mode. | Oui |
| Désigne le jeu de données où le modèle de données doit être publié. | Oui |
| Désigne le préfixe commun utilisé pour nommer les tables générées dans la base de données. | Oui |
Cette section détaille l'impact du mode relationnel sur la validation de données.
Certaines contraintes du modèles de données d'EBX® vont générer une "contrainte structurelle" sur le schéma du SGBDR sous-jacent du mode relationnel. C'est également le cas quand l'historique de table est activé. Les facettes suivantes sont concernées :
les facettes xs:maxLength et xs:length sur les éléments string ;
les facettes xs:totalDigits et xs:fractionDigits sur les éléments xs:decimal.
Les bases de données n'offrent pas le mode de validation tolérant proposé par EBX®. Les contraintes citées précédemment deviennent alors des contraintes bloquantes. Une contrainte bloquante signifie que les mises à jour non conformes seront rejetées. De plus, ces contraintes ne sont plus vérifiées au cours du processus de validation, à l'exception des contraintes de clés étrangères dans certains cas (voir Mode de blocage de clé étrangère). Quand une transaction n'est pas conforme à une contrainte bloquante, elle est annulée et une ConstraintViolationException est levée.
Afin de réduire le temps de validation, les contraintes de clé étrangère sont automatiquement définies en mode bloquant si :
Les contraintes de clé étrangère sont définies dans une table en mode relationnel,
Les contraintes de clé étrangère sont définies dans une table en mode sémantique ou relationnel référençant une table en mode relationnel.
Pour cette contrainte, le mode bloquant implique que la tentative d'exécution des actions suivantes provoque une ConstraintViolationException :
effacer un enregistrement référencé par une contrainte de clé étrangère,
effacer une instance référencée par une contrainte de clé étrangère,
fermer un espace de données référencé par une contrainte de clé étrangère.
Il est cependant possible de surcharger ce comportement par défaut en définissant un mode de validation spécifique. Voir Blocking and non-blocking constraints pour plus d'informations.
Afin de garantir l'intégrité des contraintes de clé étrangère après une écriture SQL directe qui contourne le cadre de gouvernance d'EBX®, les contraintes de clé étrangère seront validées dans les cas suivants :
à la première validation explicite via l'interface utilisateur ou l'API,
à la première validation explicite via l'interface utilisateur ou l'API après actualisation du schéma,
à la première validation explicite via l'interface utilisateur ou l'API après la réinitialisation du rapport de validation d'un jeu de données dans l'interface utilisateur.
Important :
L'aspect bloquant de la contrainte de clé étrangère ne concerne pas les filtres qui peuvent être définis. C'est à dire qu'une contrainte de clé étrangère est non bloquante si un enregistrement référencé existe mais ne répond pas aux critères de filtre de la clé étrangère. Dans ce cas, les mises à jour ne sont pas rejetées et une erreur sera alors ajoutée au rapport de validation.
Les contraintes de clé étrangère ne sont pas en mode bloquant lors de l'import d'archives. En effet, toutes les contraintes bloquantes, à l'exception des contraintes structurelles, sont toujours désactivées lors de l'import d'archives. Ceci permet d'avoir une certaine souplesse lors de l'import d'archives lorsque, sous certaines conditions, l'import de clés étrangères référençant des enregistrements qui n'ont pas encore été importés doit être tolérant.
Les contraintes programmatiques sont vérifiées pour chaque enregistrement de la table à la validation. Si la table définit des millions d'enregistrements, des problèmes de performance se poseront. Il est alors recommandé de définir une contrainte au niveau table.
Dans les cas où une contrainte au niveau table ne peut être définie, il est recommandé de définir au moins une dépendance locale ou explicite, afin de réduire le coût de la validation incrémentale.
Cette section décrit comment accéder directement aux données en mode relationnel via SQL.
Pour chaque table EBX® en mode relationnel, une table correspondante est générée dans le SGBDR. En utilisant l'interface utilisateur d'EBX®, il est possible de trouver le nom de cette table en cliquant sur le panneau de documentation de la table.
Les lectures directes en SQL sont possibles sur des transactions bien gérées et à durée de vie courte de préférence. Cependant, pour ce type d'accès, les permissions d'EBX® ne sont pas prises en compte. Les applications autorisées à réaliser des lectures doivent être identifiées à travers d'autres processus d'authentification et permissions.
Les écritures directes en SQL contournent le cadre de gouvernance d'EBX®. Par conséquent, elles doivent être utilisées avec une grande précaution. Elles peuvent être à l'origine des situations suivantes :
échec de l'historisation des tables d'EBX® ;
échec de l'exécution des triggers d'EBX® ;
échec de la vérification des permissions et des contraintes d'EBX® ;
modifications qui échappent au processus de validation incrémentale ;
perte de visibilité des tables sémantiques d'EBX®, qui peuvent être référencées par des clés étrangères.
Par conséquent, les écritures directes en SQL doivent être réalisées si, et seulement si, toutes les conditions suivantes sont remplies :
les tables modifiées ne sont pas historisées et n'ont pas de triggers EBX®.
l'application réalisant les écritures peut être authentifiée grâce aux permissions associées, afin de garantir l'intégrité des données. Plus particulièrement, l'intégrité des clés étrangères (osd:tableRef) doit être préservée à tout moment. Voir Mode bloquant de clé étrangère pour plus d'informations.
le serveur d'application qui exécute EBX® doit être arrêté lorsqu'une écriture est réalisée. Ceci permet de garantir que la validation incrémentale ne devienne obsolète, ce qui serait le cas dans un contexte batch.
Le mode relationnel est pleinement opérationnel mais fait l'objet de quelques limitations, listées ci-dessous. Dans le cas de l'utilisation du mode relationnel, il est fortement recommandé de prendre connaissance de ces limitations et de contacter l'équipe support de TIBCO EBX® à https://support.tibco.com en cas de questions.
Voir Supported databases pour les bases de données supportant le mode relationnel.
Certaines restriction s'appliquent aux modèles de données en mode relationnel :
Les listes agrégées ne sont pas supportées dans les tables relationnelles. Un tel schéma provoquera une erreur de compilation.
Les attributs définis par l'utilisateur sur des tables relationnelles provoquent des erreurs de compilation dans le modèle de données.
Des contraintes programmatiques, puisque le coût de calcul de la validation serait trop important. Cependant, les contraintes sur tables restent disponibles.
Les évolutions de schéma peuvent aussi être limitées par le SGBDR sous-jacent selon les données déjà contenues dans les tables concernées.
Il n'est pas possible de créer d'espaces de données enfants ou d'images à partir d'un espace de données contenant des jeux de données en mode relationnel.
Pour D3, il n'est pas possible de diffuser un espace de données défini en mode relationnel.
Pour de très grands volumes de données, la validation aura une faible performance si la table relationnelle déclare une de ces fonctionnalités : osd:function, osd:select, osd:uiFilter, osd:tableRef/filter. De plus, aucun tri ne peut être appliqué sur une colonne osd:function.
Il est impossible de définir AdaptationValue.INHERIT_VALUE sur un noeud appartenant à un modèle de données en mode relationnel.