Open Business Intelligence

La red del Business Intelligence

Hola amigos tengo el siguiente problema resulta que quiero obtener datos estadísticos, con respecto por ejemplo a tardanza en etapas de reparación de un vehículo en una semana. y he decidido sumergirme en el mundo del DHW y cree estas tablas para poder diseñar el hw

etapas
-IDEtapa
-Descripcion

alertas
-IDAlera
-Descripcion

companias
-IDCia
-Descripcion

con esta tengo problemas, no se como llenar los datos para poder realizar las busquedas, por ejemplo, un año determinado, desde el martes 1 de noviembre hasta el 27 de noviembre y ese tipo de busquedas

tiempo
-IDTiempo


hechos
-IDEtapa
-IDAlera
-IDCia
-IDTiempo
-Otros campos

Este HW va hacer montado en PostgreSQL y pretendo llenarlo con el SPOON de Pentaho

Saludos...Desde Chile

Visitas: 334

Responde a esto

Respuestas a esta discusión

Hola,

si el nivel de granularidad es a nivel de día, es decir, si el nivel más bajo al que se van a analizar los datos es el nivel de día, la tabla de tiempo debería ser así:

DIM_TIEMPO

ID_TIEMPO

AÑO

MES

DIA

Esta dimensión la deberás rellenar mediante una etl, insertando tantos registros como días estén comprendidos en el periodo de análisis. Por ejemplo, si los datos históricos van desde el año 2009 al año actual, en la tabla de tiempo deberás introducir 3*365 registros, uno por día. Dentro de los ejemplos que incorpora PDI hay una transformación de ejemplo sobre como completar una dimensión de tiempo genérica, que aunque incluye muchos campos que no necesitarás, puede servirte como base.

Un saludo.

y con el Dim_Tiempo los datos deberian ser, de esta manera?

id_tiempo INTEGER,

año         DATE

MES       INTEGER

DIA        INTEGER

o de esta otra manera?

id_tiempo CHARACTER (10)

año         INTEGER

MES       CHARACTER (3)

DIA        INTEGER

Cual de las 2 es la mejor manera?

las otras estan de esta manera

CREATE TABLE ALERTAS (
IDALERTA INTEGER NOT NULL,
COLORES VARCHAR(50) NOT NULL,
CONSTRAINT PK_ALERTAS PRIMARY KEY (IDALERTA)
);

CREATE TABLE CIAS (
IDCIA INTEGER NOT NULL,
CIA VARCHAR(25) NOT NULL,
CONSTRAINT PK_CIAS PRIMARY KEY (IDCIA)
);


CREATE TABLE TALLERES (
IDTALLER INTEGER NOT NULL,
ALIAS VARCHAR(50) NOT NULL,
LOCAL VARCHAR(60) NOT NULL,
CONSTRAINT PK_TALLERES PRIMARY KEY (IDTALLER)
);

CREATE TABLE PAIS (
IDPAIS INTEGER NOT NULL,
DESCRIPCION VARCHAR(25) NOT NULL,
CONSTRAINT PAIS_PK PRIMARY KEY (IDPAIS)
);

CREATE TABLE FAC_TABLE (
IDALERTA INTEGER NOT NULL,
--IDTIEMPO INTEGER NOT NULL,
IDPAIS INTEGER NOT NULL,
IDTALLER INTEGER NOT NULL,
IDCIA INTEGER NOT NULL

datos...

);

la otra consulta, es bueno que el WH quede en la misma BD en el mismo Esquema ; en la misma BD en otro Esquema ; o simplemente en otra BD ??

Ala primera pregunta, yo realmente lo haría así:

id_tiempo INTEGER,

año         VARCHAR(4)

MES       VARCHAR(2)

MES_NUMEROINTEGER

MES_NOMBRE VARCHAR(25)

DIA       VARCHAR(2)

DIA_NUMERO INTEGER

DIA_NOMBRE VARCHAR(15)

El id-tiempo es importante que sea un numérico porque será el campo que enlace con la tabla de hechos, y las consultas serán más ligeras a la hora de hacer los cruces.

Te propongo poner mes, mes_numero y mes_nombre porque, a la hora de mostrar los datos es posible que necesites mostrar el mes como 01, 02 y también mostrar los nombres. Así, esta info ya la tienes en la tabla y no es necesario estar haciendo transformaciones extra.

A la segunda pregunta, todo depende del volumen de datos qeu contenga el datawarehouse y de la concurrencia de usuarios. Si el volumen de datos es elevado y la concurrencia de usuarios consultando la aplicación es grande, yo recomiendo posicionar el dw en una máquina independiente, separada del sistema operacional. Como mínimo aconsejo poner la base de datos en una máquina distinta a donde se encuentre la aplicación que va a acceder a los datos.

Pero si sólo es un sistema de desarrollo o un sistema de poca importancia, puede estar todo junto sin problemas.

Un saludo

Responder a debate

RSS

Distintivo

Cargando…

© 2024   Creado por Emilio.   Tecnología de

Emblemas  |  Reportar un problema  |  Términos de servicio