Vous pouvez utiliser les vues d'une base de données pour interroger les données de relation sans utiliser le gestionnaire de
relations.
Vous pouvez utiliser vos vues de base de données pour directement interroger les données de relation stockées sur la
base de données. Lorsque vous créez une nouvelle table de base de relations, une vue SQL correspondante est automatiquement générée. Ces vues correspondent
essentiellement à des encapsulations des données de relation stockées dans les tables de base de données. Vous pouvez utiliser ces vues pour
remplir et/ou interroger les données de relation en :
- utilisant les instructions SQL avec un client de base de données (par exemple, avec le centre de commandes
DB2) ;
- utilisant JDBC pour exécuter des instructions SQL avec un programme Java™.
Dans chaque cas, vous pouvez utiliser les vues SQL de la même manière que vous le feriez pour les tables. Vous pouvez utiliser cette technique en remplacement de l'application Gestionnaire de relations pour remplir directement de grands ensembles
de données propres à l'application à l'aide d'instructions SQL dans les bases de relations. Vous pouvez également utiliser cette technique
pour importer des données d'un fichier texte à plat dans une table de base de données.
Les vues SQL de la base de relations sont créées en fonction des données contenues dans les tables situées en dehors de la source de
données. La vue existe même si la table de base de données est vide. Chaque vue a un nom unique attribué selon la convention suivante :
"V_"+
nom_affichage_relation+"_"
nom_affichage_role+"_"+
uuid (notez que les variables
sont concaténées à l'aide d'un caractère de soulignement "_"). Les noms affichés sont limités à 20 caractères alphanumériques et l'identificateur unique universel (UUID) est un nombre généré à partir d'une combinaison des noms affichés. En conséquence, chaque nom de vue doit être unique au sein d'une source de données. Exemple de convention de dénomination avec les variables suivantes :
- nom_affichage_relation = SAMPLECUSTID
- nom_affichage_rôle = MYCUSTOMER
- uuid = 80C (ce nombre est généré automatiquement par le serveur)
Le nom de la vue résultant serait "V_SAMPLECUSTID_MYCUSTOMER_80C". Pour une relation donnée, vous devriez avoir deux vues correspondantes contenant le même nom affiché pour la relation mais différents UUID et noms affichés pour les rôles.
Remarque : Pour les bases de données Oracle, la convention de dénomination est différente : seuls les dix premiers caractères
denom_affichage_relation et nom_affichage_role sont utilisés.
Chaque vue contient les colonnes (y compris les propriétés associées de type, valeur et de valeur nulle admise) répertoriées dans le
tableau ci-dessous :
Exemple
L'exemple présenté ici est une relation d'identité incluant trois ensembles de données
issus de trois applications d'entreprise :
Les données sont corrélées à l'aide du service de relation
WebSphere ESB. Chaque application contient des informations client similaires et une relation d'identité pour corréler ces informations entre les
applications.
Les trois tableaux ci-après présentent les données stockées dans chaque base de données :
Tableau 2. Client ClarifyPrénom |
Nom |
Tél. domicile |
ID |
Jessica |
Reed |
111 111 11111 |
clarify_1 |
Tara |
McLean |
333 333 33333 |
clarify_2 |
Tableau 3. Client SAPPrénom |
Nom |
Tél. domicile |
ID |
Jessica |
Reed |
111 111 11111 |
sap_10 |
Tara |
McLean |
333 333 33333 |
sap_8 |
Tableau 4. Client SiebelNom et prénom |
Tél. domicile |
ID |
Jessica Reed |
111 111 11111 |
siebel_6 |
Tara McLean |
333 333 33333 |
siebel_8 |
Les noms et éléments de définition d'objet métier (créés dans
WebSphere Integration Developer pour chaque base de données) sont indiqués
dans le tableau ci-après :
Tableau 5. Définitions d'objet métier pour client dans chaque base de donnéesClarifyCustomer |
SapCustomer |
SiebelCustomer |
Elément |
Type |
Elément |
Type |
Elément |
Type |
givenName |
string |
firstName |
string |
fullName |
string |
lastName |
string |
lastName |
string |
|
|
homePhone |
string |
homePhone |
string |
homePhone |
string |
clarifyId |
string |
sapId |
string |
siebelId |
string |
Une relation d'identité est définie pour corréler les informations client entre
chaque base de données. Cette relation, appelée
ID dans l'exemple, utilise les éléments d'objet métier
clarifyId,
sapId et
siebelId. Ces éléments sont utilisés car ils contiennent, pour chaque
base de données, des données ID qui sont uniques pour chaque client. Le tableau ci-après décrit les rôles utilisés pour corréler différentes
bases de données de la relation en ID commun employé par
WebSphere ESB :
Tableau 6. Définition de relation d'IDNom de relation |
Nom de rôle |
Nom d'objet métier |
Clé |
ID |
GenCustomer |
GenCustomer |
genId |
ClarifyCustomer |
ClarifyCustomer |
clarifyId |
SapCustomer |
SapCustomer |
sapId |
SiebelCustomer |
SiebelCustomer |
siebelId |
Le nom de relation complet est
http://CustomerModule/ID. Les noms de rôle complets sont :
- http://CustomerModule/ClarifyCustomer
- http://CustomerModule/SapCustomer
- http://CustomerModule/SiebelCustomer
Vous pouvez corréler les données dans les objets métier contenus dans les
trois bases de données à l'aide de la relation définie. Les données ID client de chaque base de données sont corrélées avec les données
client des autres bases de données en partageant les ID instance. Par exemple, Tara McLean est identifiée par
clarify_3 ID
dans Clarify,
sap_8 dans SAP et
siebel_8 dans Siebel. Un ID unique est généré par
le service de relation
WebSphere ESB.
Remarque : Vous ne pouvez pas manipuler les tables d'instances de relation à l'aide de vues pour la base de données Derby. Cependant, vous pouvez utiliser les vues pour parcourir le contenu des tables de relations.
Vous pouvez définir plusieurs instances de relation à l'aide de vues créées dans la base de données commune. Le mappage du nom de vue (conforme à la convention de dénomination décrite précédemment) avec le rôle de relation correspondant est capturé
dans la table
RELN_VIEW_META_T, dans la base de données commune. Le tableau ci-après présente des exemples de noms de vue
pour les rôles
ClarifyCustomer,
SapCustomer et
SiebelCustomer :
Tableau 7. RELN_VIEW_META_T tableVIEW_NAME |
RELATIONSHIP_NAME |
ROLE_NAME |
V_ID_CLARIFYCUSTOMER_098 |
http://CustomerModule/ID |
http://CustomerModule/ClarifyCustomer |
V_ID_SAPCUSTOMER_515 |
http://CustomerModule/ID |
http://CustomerModule/SapCustomer |
V_ID_SIEBELCUSTOMER_411 |
http://CustomerModule/ID |
http://CustomerModule/SiebelCustomer |
V_USASTATE_ABBREVIATION_DE8 |
http://CustomerModule/USASTATE |
http://CustomerModule/Abbreviation |
V_USASTATE_CODE_B32 |
http://CustomerModule/USASTATE |
http://CustomerModule/Code |
V_USASTATE_NAME_933 |
http://CustomerModule/USASTATE |
http://CustomerModule/FullName |
La définition de colonne de vue (décrite dans
table
1) présente une colonne
ROLE_ATTRIBUTE_COLUMN caractérisée par les propriétés suivantes :
Tableau 8. Définition de colonne de vue Nom de colonne |
Type de données |
Valeur |
Description |
KEY_ATTRIBUTE_NAME |
Dépend du type d'attribut de clé |
Non NULL |
Emplacement dans lequel les données d'instance de rôle sont stockées. Pour les relations d'identité, la colonne est
désignée par le nom de l'attribut de clé. Par exemple, SAPCUSTOMER_SAPID utilise sapid comme nom
d'attribut de clé et sapcustomer pour le nom d'objet métier. Une colonne est définie pour chaque attribut de clé. Pour les relations statiques, la colonne est nommée DATA |
Le tableau ci-après présente, dans la base de données commune, les vues des relations d'ID.
Tableau 9. Définition de colonne de vueVue de rôle Clarify |
Vue de rôle SAP |
Vue de rôle Siebel |
INSTANCEID |
INSTANCEID |
INSTANCEID |
CLARIFYCUSTOMER_CLARIFYID |
SAPCUSTOMER_SAPID |
SIEBELCUSTOMER_SIEBELID |
STATUS |
STATUS |
STATUS |
LOGICAL_STATE |
LOGICAL_STATE |
LOGICAL_STATE |
LOGICAL_STATE_TIMESTAMP |
LOGICAL_STATE_TIMESTAMP |
LOGICAL_STATE_TIMESTAMP |
CREATE_TIMESTAMP |
CREATE_TIMESTAMP |
CREATE_TIMESTAMP |
UPDATE_TIMESTAMP |
UPDATE_TIMESTAMP |
UPDATE_TIMESTAMP |
ROLEID |
ROLEID |
ROLEID |
Remarque : Dans ces vues, tous les noms de colonne
correspondent, à l'exception des noms de colonne des attributs de clé.
Au préalable, vous devez connaître le nom de la vue
Table d'exécution des rôles pour exécuter SQL sur la vue afin de manipuler les données d'instance de rôle. Le script SQL ci-après présente
un exemple avec DB2 Universal Database. Cet exemple considère que toutes les
données de chaque base de données sont copiées dans la base de relations. Vous pouvez copier les données à l'aide de l'instruction
SELECT INTO SQL :
//Créer une table pour stocker les valeurs d'ID des trois applications pour chaque client
//et associer un ID instance unique à chaque client. Utiliser cette table comme
//table source de base pour remplir les tables de relations.
CREATE TABLE joint_t (instanceid INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY,
clarify_id VARCHAR(10) NOT NULL,
sap_id VARCHAR(10) NOT NULL,
siebel_id VARCHAR(10) NOT NULL)
//Comparer le nom et le numéro de téléphone du domicile entre les trois tables d'application.
//En cas de correspondance, insérer la valeur d'ID de la personne extraite de chaque table d'application
//dans la table joint_t. Associer les trois valeurs d'ID à un ID unique ; cet
//ID sera utilisé ultérieurement comme ID d'instance de relation.
INSERT INTO joint_t (clarify_id,sap_id,siebel_id)
SELECT A.ID, B.ID, C.ID
FROM clarifycustomer A,sapcustomer B, siebelcustomer C
WHERE A.homephone=B.homephone AND
B.homephone=C.homephone, AND
B.givenname=C.firstname AND
B.lastname=C.lastname AND
A.fullname=C.firstname CONCAT ' ' CONCAT C.lastname
//Créer une séquence pour chaque application ; cette séquence sera
//utilisée ultérieurement comme ID rôle dans chaque table des rôles.
CREATE SEQUENCE clarify_roleid MINVALUE 1 ORDER CACHE 100
CREATE SEQUENCE sap_roleid MINVALUE 1 ORDER CACHE 100
CREATE SEQUENCE siebel_roleid MINVALUE 1 ORDER CACHE 100
//Remplir la table des instances de rôle pour le rôle CLARIFY.
INSERT INTO V_ID_CLARIFYCUSTOMER_098 (instanceid, roleid,
clarifycustomer_clarifyid, status, logical_state, logical_state_timestamp,
create_timestamp, update_timestamp)
FROM joint_t
//Remplir la table des instances de rôle pour le rôle SAP.
INSERT INTO V_ID_SAPCUSTOMER_515 (instanceid, roleid, sapcustomer_sapid,
status, logical_state, logical_state_timestamp, create_timestamp,
update_timestamp)
SELECT instanceid NEXTVAL FOR sap_roleid, sap_id, 0, 0, current
timestamp, current timestamp, current timestamp
FROM joint_t
//Remplir la table des instances de rôle pour le rôle SIEBEL.
INSERT INTO V_ID_SIEBELCUSTOMER_AFC (instanceid, roleid, siebelcustomer_siebelid,
status, logical_state, logical_state_timestamp, create_timestamp, update_timestamp)
SELECT instanceid, NEXTVAL FOR siebel_roleid, sap_id, 0, 0, current timestamp,
current timestamp, current timestamp
FROM joint_t
La table
joint_t est créée pour stocker temporairement des valeurs de clés. Lorsque vous avez
terminé la sauvegarde des ressources, vous pouvez supprimer la table si nécessaire. Vous pouvez également créer une table de vue ou une
table temporaire.