Relacion circular Ayuda!

[#1]

Hola como va? Tengo el siguiente problema con una relacion circular que no puedo solucionar. . A ver si por favor alguien con mas idea me puede ayudar  y hacer que las tablas se conecten TODAS entre si (o las que tengan relacion digamos). Es un ejemplo base de stock, articulos, etc.

Muchas gracias!

http://bitshare.com/files/xvjox8s0/EJ.qvw.html

[#2]

Hola,

De manera rápida podrías concatenar las tablas de Ordenes y Facturas para formar una sola tabla de hechos y eliminar la relación cíclica, sin embargo esto no resolverá del todo las relaciones y por ahí tendrás al menos una llave sintética dado que ARTICULO_ID está tanto en la tabla de ARTICULO como en la de STOCK. Resolver esto dependerá de la forma en que se relacionen tus tablas, es decir, si alguna de ellas puede prescindir de este campo, o se debe realizar algún otro tipo de operación. También habrá que considerar que en la tabla de hechos probablemente debas unificar los campos de fecha en uno solo para crear un calendario maestro, así como agregar una bandera para distinguir los registros de Ordenes de las facturas, esto último es completamente opcional pero lo considero una buena práctica que te facilitará la revisión de datos.

Adjunto un screenshot de cómo se vería el modelo de datos al crear una tabla de hechos concatenada como la que propongo.

Saludos.

[#3]

Gracias por contestar antes que nada.

Como haces para que la tabla creada no sea temporal y aparezca en el visor de tablas? Porque estoy concatenando  a partir de las resident que luego borro pero no me aparece nada..

Y en ese caso de tener la tabla hecho vos decis que los ID de cliente y vendedor no van a traer problema por más que se repitan? Porque los Order_ID y Factura_ID tambien pueden ser iguales.. no tendria duplicados o registros "exactamente iguales"? O me estoy mareando.

Y lo del FLAG como se haría por ejemplo?

Y una pregunta más teórica... vos como pensas que estaría bien? Dejar todo en una tabla o tener separados los orders de las facturaciones? En ese caso que alternativa tendria?

Saludos y gracias! Soy nuevo en esto

[#4]

Hola,

Realicé una carga binaria para modificar el modelo a partir de tu qvw. Posteriormente utilicé le siguiente código:

HECHOS:
LOAD *, 1 AS DUMMY
Resident ORDERS;
Concatenate
LOAD *
Resident FACTURAS;
DROP TABLE ORDERS;
DROP TABLE FACTURAS;

Lo que permite que la tabla de hechos se mantenga en el modelo de datos es la adición del campo DUMMY. EL punto aquí es que cuando QlikView detecta que dos tablas son exactamente iguales, como sucede cuando se ejecuta esto:

HECHOS:
LOAD *, 1 AS DUMMY
Resident ORDERS;

QliKView concatena el resultado del RESIDENT a la tabla de ORDERS que ya existía, por lo que si no agregaras al menos un campo que haga a las tablas diferentes, como lo hace el campo DUMMY, en realidad no se creará la tabla de HECHOS y cuando utilices el DROP TABLE ORDERS, se borrará el contenido de la tabla original como el del RESIDENT.

Respecto a si es problemático que se repitan valores en los campos CLIENTE_ID y VENDEDOR_ID, se debe notar que los valores si se van a repetir dentro del campo, sin embargo por la forma en que QlikView estructura la información no deberías tener problemas al respecto. Es precisamente la forma en que QlikView funciona que permite realizar este tipo de concatenación que en otros casos o tecnologías no sería recomendable. De hecho, cuando tengas este tipo de casos donde tienes múltiples tablas de hechos que comparten más de un campo, la solución más fácil y práctica en la mayoría de los casos consiste en concatenar las tablas y unificar los campos iguales con nombres iguales, de manera que la información de estos campos se concentre en un misma columna y no tener por ejemplo un campo llamado CLIENTE_ID_1 y CLIENTE_ID_2. Esto último sólo es recomendable si los campos contienen el mismo tipo de información, o lo que es lo mismo, si podrían funcionar como campos llave que unifiquen las tablas.

Por lo que describo antes, tendrías que considerar cuidadosamente si es factible realizar este mismo procedimiento para los campos ORDEN_ID y FACTURA_ID, pues el unificarlas en un mismo campo, que  por ejemplo se llamase DOCUMENT ID, sólo será recomendable si contienen el mismo tipo de dato siempre, mientras que si sólo en ocasiones pueden tener valores iguales o referirse a la misma información, es más recomendable mantenerlos en campo separados.

Respecto a cómo realizar el campo FLAG, puedes utilizar el campo DUMMY que describo antes como un ejemplo de lo mismo. Este campo sólo serviría para identificar los distintos tipos de registros que contiene la tabla de hechos. Es más... ahí te va un ejemplo:

HECHOS:
LOAD *, 1 AS FLAG
Resident ORDERS;
Concatenate
LOAD *, 2 AS FLAG
Resident FACTURAS;

De esta manera, puedes utilizar el campo flag para filtar el tipo de información que quieres utilizar, ya sea con un listbox o con set analysis.

Por último, la decisión de mantener unificadas o no las tablas de ORDENES Y FACTURAS, depende de muchas variantes. La mayoría de la veces lo que termina definiendo este tipo de operaciones es la existencia de llaves sintéticas o relaciones cícilicas. Sin embargo también depende la forma en que se relaciona tu fuente de datos y del tipo de análisis que desees habilitar en la aplicación. En última instancia cabe recordar que QlikView muestra un mejor rendimiento cuando se crea un modelo tipo estrella conformado por una sola tabla de hechos y un nivel de dimensiones a su alrededor.

Espero que esto aclare un poco tus dudas, porque va a ser un poco difícil ahondar más en este tipo de temas de modelado de datos por este medio.  Si trabajas en México te podemos apoyar con capacitación al respecto. Mi correo de contacto es carlos.reyes@evolcon.com

Saludos.

[#5]

Antes que nada, muchas gracias por contestar, muy útil lo que comentaste.

Solo tengo una duda. Agregue los articulos a las facturas. Si uno todo a una misma tabla y elijo 1 articulo, me trae los orders y las facturas. Ahora, si las quiero dejar separadas y solo dejar en la mestra un "articulo" y pocos campos mas, pero mantener las otras 2 tablas; igual deberia seguir funcionando lo del articulo no? Porque relaciona las 2. Bueno, eso no me lo està haciendo.. O estoy concatenando mal¿? O es un join lo que se hace?

Juntarlas en 1 sola no le veo mucho sentido a este problema porque no tienen mucho que ver los orders con las facturas.

La idea es entonces dejar en "hechos" solo lo necesario para que luego eligiendo o un cliente o un articulo, me salgan los orders y las facturas, manteniendo las 2 tablas. Alguna ayuda?

Saludos y gracias

[#6]

No entendí muy bien lo que estás haciendo o intentando hacer. Será más fácil orientarte sobre el tipo de modelo de datos que te conviene más si detallas específicamente qué analsis quieres realizar o lograr. Pues como comentaba antes, el modelo de datos depende mucho de qué análisis quieras realizar y casi nunca existe una solución única a un problema.

Saludos

[#7]

Si, me explique mal creo.

Tengo Articulos tanto en Facturas como en Orders ahora.

En vez de concatenar TODO en HECHOS y dropear las otras 2 (Funciona! pero quiero hacerlo de otra manera), quiero que en HECHOS solo me queden los Articulos si o si(y algunas claves mas? vendedor? cliente? facturaid? orderid?) y que luego a traves de ese articulo me relacione a la tabla facturas (con sus id, etc) y a la tabla orders (con sus id, etc) que NO las dropeo y las dejo con todos sus datos. La idea es que luego seleccionando un articulo o un cliente, tenga todos los orders y facturas.

Ahora me explique?

Estoy haciendo

HECHOS:

REPLACE LOAD FactD, Fact_Article as Articulo_ID, Stock_ID, Cliente_ID, Vendedor_ID, 1 AS FLAG

Resident Facturas;

Concatenate

REPLACE LOAD OrderID, Order_Article as Articulo_ID, Cliente_ID, Vendedor_ID,

Resident Orders;

NO ME CARGA ninguna factura en la de HECHOS creo, porque la cantidad de registros de maestra es IGUAL a la de orders.¡Que estoy haciendo mal¿ Los articulos no se me relacionan con facturas. Si con orders.

(supone que los campos estan bien de nombre)

Abrazo y gracias

[#8]

En primer lugar creo que estás utilizando la sentencia REPLACE erróneamente. Esa sentencia sólo se debe utilizar cuando quieres realizar recargas parciales, lo cual no creo que sea tu caso. Si intentas el mismo código borrando REPLACE deberías obtener el resultado que buscas.

MAESTRA:

LOAD FactD, Fact_Article as Articulo_ID, Stock_ID, Cliente_ID, Vendedor_ID, 1 AS FLAG

Resident Facturas;

Concatenate

LOAD OrderID, Order_Article as Articulo_ID, Cliente_ID, Vendedor_ID, 2 AS FLAG

Resident Orders;

Por otro lado, me parece que lo que buscas es crear una LINK TABLE para ligar tanto ORDERS como FACTURAS. Sin embargo esto es un recurso que sólo se recomienda en casos contados y cuando ningún otro método logra el resultado deseado. En tu caso me parece que la tabla concatenada provee un método mucho más práctico y eficiente. En cualquier caso, si creas o no la LINK TABLE, debes resolver la forma en que la tabla de STOCK se liga con las demás tablas, pues contiene dos campos llave que generarán otra relación cícilca con una LINK TABLE y una llave sintética con la tabla CONCATENADA.

[#9]

Gracias y perdón por la insistencia jaja

Cierto lo del replace, me había quedado colgado

Si, supongo que loque quiero es una link table, porque concatenar tantos campos de orders y facturas en 1 sola no le veo sentido (son muchos, acà lo acotè)

El problema que estoy viendo es en el concatenate. SOLO me queda la cantidad de registros en la tabla hechos = a la cantidad de registros de la tabla que ponga 2da en esa instruccion

No me esta concatenando a la maestra todos los otros articulos (y registros) de la tabla que pongo 1ro.

Estoy usando algo mal ahi en el concatenate me parece, mas alla que luego queden relaciones circulares, llaves sintèticas, etc. Me explico?

Tabla Fact             TablaHechos         TablaOrders

Fact_id                   Articulo_ID            Order_id

Campo1                  Cliente_ID            Campo4

Campo2                                             Campo5

Campo3                                             Campo6

Cliente_ID?                                         Cliente_ID?

Articulo_ID?                                        Articulo_ID?

...                                                            ...

Eso es lo que quiero. Que seleccionando un articulo o un cliente, me de las facturas y las orders. Lo que pongo con ? es lo que no se si irìa. Los articulos deberian quedar en las 3 tablas creo yo, ese es mi linkeo.

En fin, igual gracias por todo lo que me dijiste, lo voy a usar a ver si puedo arreglarlo

Abrazo y gracias

[#10 · Accepted solution]

En el caso de que originalmente tengas el campo ARTICULO en ambas tablas : ORDERS y FACTURAS, y si quieres realizar una LINK TABLE, tendrías que hacer esto:

MAESTRA:

LOAD Fact_Article as Articulo_ID, Cliente_ID, 1 AS FLAG, Fact_Article & ' ' &Cliente_ID as KEY

Resident Facturas;

Concatenate

LOAD Order_Article as Articulo_ID, Cliente_ID, 2 AS FLAG, Order_Article & ' ' &Cliente_ID as KEY

Resident Orders;

Con el código anterior tendrás 4 campos en tabla MAESTRA:

Articulo_ID,

Cliente_ID,

FLAG,

KEY

Y Deberás crear el mismo campo llamado KEY en las tablas de ORDERS Y FACTURAS para que estas se liguen a la tabla MAESTRA por este campo. Además también deberás asegurarte que no existan campos denominados Articulo_ID y Cliente_ID en las tablas de ORDES y FACTURAS para evitar la aparición de relaciones cíclicas o llaves sintéticas.  La relación debería quedar así:

Tabla Fact             TablaHechos         TablaOrders

Fact_id                  KEY                     Order_id

KEY                      Articulo_ID            KEY

Campo1                 Cliente_ID             Campo4

Campo2                 FLAG                   Campo5

Campo3                                             Campo6

Saludos.