En la mayoría de los casos, el conector supone que cada objeto comercial individual está representado por una sola tabla o vista de base de datos, y que cada atributo simple (es decir, un atributo que representa un valor individual, tal como String, Integer o Date) contenido en el objeto está representado por una columna de esa tabla o vista. Por tanto, los atributos contenidos en el mismo objeto comercial individual no se pueden guardar en tablas de base de datos diferentes. Sin embargo, pueden darse las situaciones siguientes:
Los objetos comerciales de WebSphere Business Integration Adapter pueden ser planos o jerárquicos. Todos los atributos de un objeto comercial plano son simples y representan un valor individual. El término objeto comercial jerárquico hace referencia a un objeto comercial completo, incluidos todos los objetos comerciales hijo que el objeto contiene a cualquier nivel. El término objeto comercial individual hace referencia a un sólo objeto comercial, con independencia de los objetos comerciales hijo que pueda contener o en los que esté contenido. El término objeto comercial de nivel superior hace referencia al objeto comercial individual situado en lo más alto de la jerarquía y que no tiene ningún objeto comercial padre.
Un objeto comercial jerárquico tiene atributos que representan un objeto comercial hijo, una matriz de objetos comerciales hijo o una combinación de ambos. A su vez, cada objeto comercial hijo puede contener un objeto comercial hijo o una matriz de objetos comerciales, y así sucesivamente. Existe una relación de cardinalidad simple cuando un atributo de un objeto comercial padre representa un objeto comercial hijo individual. En este caso, el atributo es del mismo tipo que el objeto comercial hijo.
Existe una relación de cardinalidad múltiple cuando un atributo de un objeto comercial padre representa una matriz de objetos comerciales hijo. En este caso, el atributo es una matriz del mismo tipo que los objetos comerciales hijo.
El conector es compatible con los tipos siguientes de relaciones entre objetos comerciales:
En cada tipo de cardinalidad, la relación entre los objetos comerciales padre e hijo está descrita por la información específica de la aplicación del atributo de clave correspondiente al objeto comercial donde está contenida la relación. Para obtener más información sobre esta información específica de la aplicación, consulte FK=[nombre_objeto_cf.]nombre_atributo_cf.
Normalmente, un objeto comercial que contiene un objeto comercial hijo de cardinalidad simple tiene como mínimo dos atributos que representan la relación. El tipo de uno de los atributos es el mismo que el tipo del hijo. El otro atributo es un atributo simple que contiene la clave primaria del hijo como clave foránea del padre. El padre tiene tantos atributos de clave foránea como el hijo tiene atributos de clave primaria.
Debido a que las claves foráneas que establecen la relación están almacenadas en el padre, cada padre solamente puede contener un sólo hijo de cardinalidad simple de un tipo dado.
La Figura 2 muestra una relación típica de cardinalidad simple. En el ejemplo, fk1 es el atributo simple donde reside la clave primaria del hijo e hijo[1] es el atributo que representa al objeto comercial hijo.
Normalmente, cada objeto comercial padre es el propietario de los datos del objeto comercial hijo contenido en el objeto padre. Por ejemplo, si cada objeto comercial Cliente contiene un objeto comercial individual denominado Dirección, cuando se crea un nuevo cliente, se añade una nueva fila tanto a la tabla de clientes como a la tabla de direcciones. La nueva dirección es exclusiva del nuevo cliente. Del mismo modo, cuando se suprime un cliente de la tabla de clientes, también se elimina la dirección del cliente en la tabla de direcciones.
Sin embargo, existen situaciones en las que varios objetos comerciales jerárquicos contienen los mismos datos, los cuales no pertenecen a ninguno de los objetos comerciales. Por ejemplo, suponga que el objeto comercial Dirección tiene el atributo EstadoProvincia[1] que representa la tabla de búsqueda EstadoProvincia con cardinalidad simple . Debido a que la tabla de búsqueda raramente se actualiza y su mantenimiento se realiza con independencia de los datos de la dirección, la creación o modificación de los datos de la dirección no afecta a los datos de la tabla de búsqueda. El conector encuentra un nombre de estado o provincia existente o bien no logra encontrarlo. No añade ni modifica valores en la tabla de búsqueda.
Cuando varios objetos comerciales contienen el mismo objeto comercial hijo de cardinalidad simple, el atributo de clave foránea de cada objeto comercial padre debe especificar la relación como NO_OWNERSHIP (sin propietario). Cuando un intermediario de integración envía al conector un objeto comercial jerárquico con una petición Crear, Suprimir o Actualizar, el conector pasa por alto los hijos de cardinalidad simple contenidos sin propietario. Para estos objetos comerciales el conector sólo realiza acciones de recuperación. Si el conector no lograr recuperar un objeto comercial de cardinalidad simple de esa clase, devuelve un error y detiene el proceso.
Para obtener información sobre cómo especificar la relación sin propietario, consulte Atributos que representan un objeto comercial hijo de cardinalidad simple. Para obtener más información sobre la especificación de relaciones de clave foránea, consulte Especificación de la clave foránea de un atributo.
Además de facilitar el uso de tablas de búsqueda estáticas, la inclusión sin propietario proporciona otra capacidad: la sincronización de datos normalizados y desnormalizados.
Especificar una relación como NO_OWNERSHIP le permite crear o modificar datos cuando sincroniza desde una aplicación normalizada a otra desnormalizada. Por ejemplo, suponga que su aplicación normalizada de origen almacena datos en dos tablas, A y B. Suponga también que su aplicación desnormalizada de destino almacena todos los datos en una tabla individual de forma que cada entidad A almacena datos de B de forma redundante.
En este ejemplo, para sincronizar un cambio en los datos de la tabla B desde la aplicación de origen a la aplicación de destino, debe activar un suceso de la tabla A cada vez que cambien los datos de la tabla B. Además, debido a que los datos de la tabla B se almacenan de forma redundante en la tabla A, debe enviar un objeto comercial para cada fila de la tabla A que contenga los datos cambiados de la tabla B.
Cuando sincroniza datos desde una aplicación desnormalizada de origen a una aplicación normalizada de destino, el conector no crea, suprime ni actualiza datos contenidos sin propietario en la aplicación normalizada.
Cuando sincroniza datos a una aplicación normalizada, el conector pasa por alto todos los objetos hijo de cardinalidad simple contenidos sin propietario. Para poder crear, eliminar o modificar tales datos hijo, el usuario debe procesar los datos manualmente.
Normalmente, un objeto comercial que contenga una matriz de objetos comerciales hijo tiene un sólo atributo para representar la relación. El atributo es una matriz del mismo tipo que los objetos comerciales hijo. Para que un objeto padre contenga más de un objeto hijo, las claves foráneas que establecen la relación se almacenan en cada hijo.
Por tanto, cada hijo tiene como mínimo un atributo simple que contiene la clave primaria del padre como clave foránea. El hijo tiene tantos atributos de clave foránea como atributos de clave primaria tiene el padre.
Debido a que las claves foráneas que establecen la relación se almacenan en el hijo, cada padre puede tener de cero a varios hijos.
La Figura 3 muestra una relación de cardinalidad múltiple. En el ejemplo, IDpadre es el atributo simple donde reside la clave primaria del padre y hijo[n] es el atributo que representa la matriz de objetos comerciales hijo.
Algunas aplicaciones almacenan una entidad hija individual de forma que la relación se almacena en el hijo en lugar de hacerlo en el padre. Es decir, el hijo contiene una clave foránea cuyo valor es idéntico al valor almacenado en la clave primaria del padre.
La Figura 4 muestra este tipo especial de relación de cardinalidad simple.
Las aplicaciones utilizan este tipo de relación de cardinalidad simple cuando los datos del hijo no existen con independencia del padre respectivo y sólo se puede acceder a ellos a través del padre. Tales datos del hijo no son nunca propiedad de más de un padre, y necesitan que el padre y su valor de clave primaria existan para poder crear el hijo y su valor de clave foránea.
Para tener en cuenta las aplicaciones de esta clase, el conector también puede trabajar con objetos comerciales jerárquicos que contienen un hijo con cardinalidad simple, pero que almacenan la relación en el hijo en lugar de hacerlo en el padre.
Para especificar que un objeto comercial padre contiene un hijo de cardinalidad simple de esta forma especial, cuando especifique la información específica de la aplicación del atributo donde está contenido el hijo, no incluya el parámetro CONTAINMENT. Para obtener más información, consulte Atributos que representan un objeto comercial hijo de cardinalidad simple.
El objeto envoltorio es un objeto comercial de nivel superior que no corresponde a ninguna tabla ni vista de base de datos. El objeto envoltorio se denota mediante la propiedad de objeto comercial de nivel superior WRAPPER, que tiene el valor true. El objeto envoltorio es un padre ficticio que se utiliza como contenedor para hijos que no guardan relación entre sí. Al procesar el objeto envoltorio, el conector pasa por alto el objeto comercial de nivel superior y sólo procesa los hijos. El objeto envoltorio puede contener entidades de cardinalidad N o de cardinalidad N-1 o ambas cosas.
Una entidad de cardinalidad N debe tener como mínimo un atributo exclusivo designado como clave primaria y al menos un atributo designado como clave foránea. Esta clave foránea se añadirá luego como clave primaria al objeto envoltorio. La clave foránea de la entidad hará referencia a la clave primaria del objeto envoltorio que se acaba de añadir.
En el caso de una entidad de cardinalidad N-1, la clave primaria debe estar designada como clave primaria y clave foránea, y hacer referencia a la clave primaria del envoltorio, que es la misma que la clave primaria contenida en la entidad N-1.