Dans la plupart des cas, le connecteur suppose que chaque objet métier est représenté par une table de base de données ou une vue et que chaque attribut simple (c'est-à-dire un attribut qui représente une valeur unique de type String, Integer ou Date) dans l'objet est représenté par une colonne dans cette table ou vue. De cette façon, les attributs à l'intérieur d'un même objet métier ne peuvent pas être stockés dans différentes tables de base de données. Toutefois, les situations suivantes sont envisageables :
Les objets métier WebSphere Business Integration Adapter peuvent être plats ou hiérarchiques. Tous les attributs d'un objet métier plat sont simples et représentent une valeur unique. Le terme d'objet métier hiérarchique désigne un objet métier complet, incluant tous les objets métier enfant qu'il contient à n'importe quel niveau. Le terme d'objet métier individuel désigne un objet métier unique, indépendant des objets métier qu'il peut contenir ou qui le contient. Le terme d'objet métier de niveau supérieur désigne l'objet métier individuel en haut de la hiérarchie qui ne possède pas lui-même d'objet métier parent.
Un objet métier hiérarchique dispose d'attributs qui représentent un objet métier enfant, un tableau d'objets métier enfant ou une combinaison des deux. A son tour, chaque objet métier enfant peut contenir un objet métier enfant ou un tableau d'objets métier enfant et ainsi de suite. Le terme de relation à cardinalité simple est utilisé lorsqu'un attribut contenu dans un objet métier parent représente un objet métier enfant unique. Dans ce cas, l'attribut est de même type que l'objet métier enfant.
Le terme de relation à cardinalité multiple est utilisé lorsqu'un attribut contenu dans l'objet métier parent représente un tableau d'objets métier enfant. Dans ce cas, l'attribut est un tableau de même type que les objets métier enfant.
Le connecteur prend en charge les relations suivantes entre les objets métier :
Dans chaque type de cardinalité, la relation entre les objets métier parent et enfant est décrite par les informations d'application de l'attribut clé de l'objet métier hébergeant la relation. Pour plus d'informations sur ces informations spécifiques à l'application, voir FK=[fk_object_name.]fk_attribute_name.
En règle générale, un objet métier contenant un objet métier enfant de type cardinalité simple possède au moins deux attributs représentant la relation. L'un des attributs est de même type que l'enfant. L'autre attribut est un attribut simple qui contient la clé primaire de l'enfant considérée comme la clé étrangère dans le parent. Le parent dispose d'autant d'attributs de clé étrangère que l'enfant dispose d'attributs de clé primaire.
Dans la mesure où les clés étrangères qui établissent la relation sont stockées dans le parent, chaque parent ne peut contenir qu'un seul enfant de type cardinalité simple d'un type donné.
La Figure 2 illustre une relation spécifique à cardinalité simple. Dans cet exemple, fk1 représente l'attribut simple qui contient la clé primaire de l'enfant et child[1] désigne l'attribut qui représente l'objet métier enfant.
Figure 2. Relation spécifique à cardinalité simple
En règle générale, chaque objet métier parent est propriétaire des données contenues dans l'objet métier enfant qu'il contient. Par exemple, si chaque objet métier Customer contient un objet métier Address unique, une nouvelle ligne est alors insérée dans les tables des clients et des adresses lors de la création d'un client. La nouvelle adresse est propre au nouveau client. De la même manière, lors de la suppression d'un client de la table des clients, l'adresse du client est également supprimée de la table des adresses.
Toutefois, il existe certains cas dans lesquels plusieurs objets métier hiérarchiques possèdent les mêmes données dont aucun d'eux n'est propriétaire. Par exemple, supposons qu'un objet métier Address possède un attribut StateProvince[1] représentant la table de recherche StateProvince avec le type de cardinalité simple. Dans la mesure où la table de recherche est rarement mise à jour et qu'elle est gérée indépendamment des données d'adresse, la création ou la modification des données d'adresse n'affecte pas les données contenues dans la table de recherche. Le connecteur recherche un nom de région ou de département existant ou échoue. Il n'ajoute ni ne modifie aucune valeur dans la table de recherche.
Lorsque plusieurs objets métier contiennent le même objet métier enfant de type cardinalité simple, l'attribut de clé étrangère contenu dans chaque objet métier parent doit spécifier la relation NO_OWNERSHIP. Lorsqu'un courtier d'intégration envoie un objet métier hiérarchique au connecteur avec une requête de création, de suppression ou de mise à jour, le connecteur ignore les enfants de type cardinalité simple contenus sans droits de propriété. Le connecteur réalise uniquement l'extraction de ces objets métier. Si le connecteur ne parvient pas à extraire cet objet métier de type cardinalité simple, il renvoie un message d'erreur et met fin au traitement.
Pour plus d'informations sur la manière de spécifier la relation sans droits de propriété, voir Attributs représentant un objet métier enfant de type cardinalité simple. Pour plus d'informations sur la spécification de relations de clé étrangère, voir Spécification de la clé étrangère d'un attribut.
Outre la simplification de l'utilisation des tables de recherche statiques, le confinement sans droits de propriété présente un autre intérêt : la synchronisation des données normalisées et dénormalisées.
Grâce à la relation NO_OWNERSHIP, vous pouvez créer ou modifier les données lorsque vous effectuez une synchronisation depuis une application normalisée vers une application dénormalisée. Par exemple, supposons que votre application source normalisée stocke des données dans deux tables, A et B. Supposons également que votre application cible dénormalisée stocke toutes les données dans une seule table de telle manière que chaque entité de la table A stocke de manière redondante les données de la table B.
Dans cet exemple, pour synchroniser une modification apportée aux données de la table B depuis votre application source vers votre application cible, vous devez déclencher un événement de table A chaque fois que les données de la table B sont modifiées. De plus, dans la mesure où les données de la table B sont stockées de manière redondante dans la table A, vous devez envoyer un objet métier pour chaque ligne dans la table A contenant les données modifiées de la table B.
Lors de la synchronisation de données depuis une application source dénormalisée vers une application cible normalisée, le connecteur ne crée, ne supprime ni ne met à jour aucune donnée contenue sans droits de propriété dans l'application normalisée.
Lors de la synchronisation de données vers une application normalisée, le connecteur ignore tous les enfants de type cardinalité simple contenus sans droits de propriété. Pour pouvoir créer, supprimer ou modifier ces données enfant, vous devez traiter les données manuellement.
En règle générale, un objet métier contenant un tableau d'objets métier enfant possède un seul attribut représentant la relation. L'attribut est un tableau de même type que les objets métier enfant. Pour permettre à un parent de contenir plusieurs enfants, les clés étrangères qui établissent la relation sont stockées dans chaque enfant.
Par conséquent, chaque enfant possède au moins un attribut simple contenant la clé primaire du parent considérée comme une clé étrangère. L'enfant dispose d'autant d'attributs de clé étrangère que le parent dispose d'attributs de clé primaire.
Dans la mesure où les clés étrangères qui établissent la relation sont stockées dans l'enfant, chaque parent peut n'avoir aucun enfant ou en avoir plusieurs.
La Figure 3 illustre une relation à cardinalité multiple. Dans cet exemple, parentId représente l'attribut simple qui contient la clé primaire du parent et child[n] désigne l'attribut qui représente le tableau des objets métier enfant.
Figure 3. Relation d'objet métier à cardinalité multiple
Certaines applications stockent une entité enfant unique de sorte que la relation est stockée dans l'enfant plutôt que dans le parent. En d'autres termes, l'enfant contient une clé étrangère dont la valeur est identique à celle stockée dans la clé primaire du parent.
La Figure 4 illustre ce type de relation spécifique à cardinalité simple.
Figure 4. Objet métier de type cardinalité avec une relation stockée dans l'enfant
Les applications utilisent ce type de relation à cardinalité simple lorsque les données enfant n'existent pas indépendamment de leurs parents et qu'elles sont accessibles uniquement par l'intermédiaires des parents. Ces données enfant n'appartiennent jamais à plus d'un parent et requièrent l'existence du parent et de sa valeur de clé primaire avant que l'enfant et sa valeur de clé étrangère ne puissent être créés.
Pour concilier de telles applications, le connecteur prend également en charge les objets métier hiérarchiques qui contiennent un enfant de type cardinalité simple mais qui stockent la relation dans l'enfant plutôt que dans le parent.
Pour spécifier qu'un objet métier parent contient un enfant de type cardinalité simple de cette manière, n'incluez pas le paramètre CONTAINMENT lorsque vous spécifiez les informations d'application de l'attribut contenant l'enfant. Pour plus d'informations, voir Attributs représentant un objet métier enfant de type cardinalité simple.
Un objet encapsuleur est un objet métier de niveau supérieur qui ne correspond à aucune table de base de données ni à aucune vue. L'objet encapsuleur est dénoté par la propriété WRAPPER de l'objet métier de niveau supérieur dont la valeur est true. L'objet encapsuleur est un parent fictif utilisé en tant que conteneur pour les enfants non associés. Lors du traitement d'un objet encapsuleur, le connecteur ignore l'objet métier de niveau supérieur et traite uniquement les enfants. L'objet encapsuleur peut contenir les entités de cardinalité N et/ou N-1.
Une entité de cardinalité N doit au minimum avoir un attribut unique signalé en tant que clé primaire et au minimum un attribut signalé en tant que clé étrangère. Cette clé étrangère sera ensuite ajoutée en tant que clé primaire à l'objet encapsuleur. La clé étrangère de l'entité fera référence à la clé primaire de l'objet encapsuleur tout juste ajoutée.
Dans le cas d'une entité de cardinalité N-1, la clé primaire doit être signalée à la fois en tant que clé primaire et clé étrangère, référençant la clé primaire dans l'encapsuleur, identique à la clé primaire de l'entité N-1.