Ejemplo de metadatos virtuales

Cuando se almacena la información de forma externa y se accede a ella de modo virtual, es posible obtener una vista completa de su cliente al tiempo que mitiga las inquietudes relacionadas a la duplicación de datos en el Data Hub.

El modelo Data Hub

Tiene un modelo existente que contiene dos tipos de entidades, Customer y CustomerMaster, con una relación del tipo HasMasterRecord.

La imagen que aparece a continuación muestra un modelo que se elaboró a partir de estos metadatos. Observe que George y Martha Washington poseen entidades Customer independientes pero que comparten la misma entidad CustomerMaster ya que la ID maestro representa un hogar y no una persona.

Las tablas externas

Deseamos vincular a los clientes con su historial de compra, que crearemos a través de tres tablas externas: una para los clientes, una para las compras y una para los productos.

Para la tabla Clientes, utilizaremos la misma información que utilizamos para completar las entidades Customer:

La tabla Compras contiene los números de solicitud, las ID de los productos y las fechas de compra, así como indica si la compra se realizó en línea o no. Esta tabla vincula los datos con la ID del cliente, que también se utilizó en la tabla Clientes.

La tabla Productos contiene los nombres de los productos, los números de modelo y las descripciones. Esta tabla vincula los datos con la ID del producto, que también se utilizó en la tabla Compras.

La tabla Compras servirá como tabla de unión que establece las conexiones entre los registros de las tablas Clientes y Productos. La imagen que aparece a continuación representa las relaciones existentes entre los distintos campos de las tres tablas externas.

Vinculación de datos físicos y virtuales

Para crear relaciones entre las entidades en el modelo de Data Hub y los registros en las tablas externas, las entidades del Data Hub deben contar con propiedades que hagan referencia a los datos externos. Para generar un vínculo entre el modelo de Data Hub y los registros en la tabla Clientes, es necesario que exista una propiedad en l tabla externa que contenga los mismos valores que se almacenaron en el campo CustomerID de las entidades. En la imagen que aparece a continuación, puede observar que Martha Washington posee una función denominada CustRef, que contiene los mismos valores que el campo CustomerID en la tabla Clientes.

Para establecer un vínculo entre la entidad Customer y la tabla externa, primero es necesario crear una entidad virtual para la tabla Clientes. Las instrucciones para llevar esto a cabo comienzan en el paso 5 del tema anterior, "Uso de metadatos virtuales en los modelos". La imagen que aparece a continuación muestra la pantalla completa para el nuevo tipo de entidad. Observe que "CustomerID" se encuentra seleccionado como Clave principal, que es la propiedad utilizada para generar un vínculo entre las entidades virtuales y físicas.

Una vez que se agrega la entidad virtual, debemos agregar una relación que vincule tal entidad con la entidad física que ya existe en el modelo. Las instrucciones para llevar esto a cabo comienzan en el paso 14 del tema anterior. La imagen que aparece a continuación muestra la pantalla completa para el nuevo tipo de relación. Observe que la ID de entidad de origen hace referencia a la propiedad CustRef y la ID de entidad de destino hace referencia a la propiedad CustomerID. Este es el vínculo que relaciona la entidad virtual con la entidad física ya que ambas propiedades incluyen la lD del cliente.

Asimismo, en este ejemplo, la relación entre los clientes es una relación uno a uno, lo que significa que para cada entidad física debería existir, como máximo, una entidad virtual y, al mismo tiempo, para cada entidad virtual, debería existir, como máximo, una entidad física. Para las relaciones uno a uno, como también las para las relaciones uno a varios, no es necesario contar con una Tabla de unión real; por lo tanto, seleccionamos la tabla Clientes, que es la misma tabla que se utilizó para definir la entidad virtual.

Ahora, los metadatos del modelo incluyen un vínculo a los datos virtuales. Observe la estrella de color azul que se encuentra junto a la entidad ERP_Customer. Esta estrella indica que se trata de una entidad virtual.

Relaciones varios a varios

Ahora que hemos vinculado el cliente virtual al cliente físico, necesitamos vincular las compras con los productos. El enfoque óptimo consiste en crear una entidad virtual para los productos y crear una relación virtual del tipo varios a varios entre los Clientes físicos y los Productos virtuales, utilizando la tabla Compras como una tabla de unión. En primer lugar, necesitamos crear una entidad virtual para la tabla Productos que utilice ProductID como la Clave principal.

A continuación, se agregará una relación nueva que utiliza la tabla Compras como una tabla de unión para lograr una relación del tipo varios a varios. Las entidades Customer se vinculan con las entidades Product en función de la información de la tabla Compras. Observe que la propiedad CustomerID se utiliza como la ID del vínculo para las entidades Customer y que la propiedad ProductID se utiliza como la ID del vínculo para las entidades Product. La tabla Compras contiene ambas propiedades, lo que permite relacionar la información de Customer a Product.

La ID de entidad de origen (CustRef) es la propiedad de la entidad Customer que se cruzará con la columna ID del vínculo de origen (CustomerID) en la tabla Compras. La ID del vínculo de destino (ProductID) es la columna de la tabla Compras que se cruzará con la propiedad ID de entidad de destino (también ProductID) de la entidad Products. En el siguiente diagrama, se muestra cómo se utiliza cada campo para vincular la entidad Customer con Product.

Configuración avanzada

Una alternativa al enfoque que se muestra aquí consiste en utilizar la tabla Compras para crear una relación del tipo varios a varios entre el cliente virtual y las entidades de producto virtual. Esta alternativa implica un salto virtual adicional e innecesario del cliente físico al cliente virtual. El Data Hub es mucho más eficaz para atravesar las relaciones que las fuentes de datos SQL ya que se desarrolló a partir de una base de datos gráfica; por lo tanto, el salto adicional debe evitarse si es posible.

Una segunda alternativa consiste en crear entidades virtuales para la tabla Compras, además de aquellas para la tabla Productos. Este enfoque requeriría relaciones del tipo uno a varios entre las entidades de clientes físicos y las entidades de compras virtuales, como también relaciones del tipo uno a varios entre las compras virtuales y los productos virtuales. Este procedimiento no es eficaz ya que crea saltos virtuales innecesarios para llegar de cliente físico a producto virtual. Representar una compra como una entidad no genere ningún beneficio ya que la relación puede contener todos los campos Purchases como propiedades. El único motivo para crear una entidad para Purchases es si conecta más de dos tipos de entidades, por ejemplo, si hubiera en la tabla una clave externa correspondiente a un tercero que vincule las compras con una tienda.