Los discos duros y el desempeño del servidor

20 11 2007

¿los discos?¿alguna vez sea ha preocupado por esto?

Imagine que va al estadio. El estadio está al lado de una importante avenida por lo que no es problema llegar a el. El estacionamiento es inmenso por lo que no hay problema al estacionarse. Ahora imagine que solo hay 2 salidas en el estacionamiento, Pregunta: ¿Qué sucede al terminar el partido cuando todos quieren salir de ahí?

Por más grande que sea el estacionamiento, por mejores que sean las avenidas, si solo hay 2 salidas todo se atascara al salir. La desesperación cunde, los autos no avanzan y todo está a vuelta de rueda. Por más rápido que los autos puedan conducirse, a muchos kilómetros por hora, por la puerta no pueden salir más autos de los que caben por ahí.

Bueno, pues lo mismo pasa con los discos duros que almacenan la información en un data warehouse. Cada disco tiene cierta capacidad y velocidad para leer los datos. Los discos tienen cierta capacidad de trasmisión de esos datos a la tarjeta controladora de los discos y la tarjeta controladora de los discos a su vez solo pueden pasar al servidor cierta cantidad de datos por segundo al servidor (eso es el ancho de banda).

Uno no puede pedirle que trabajen más rápido o envíen los datos más rápido de lo que pueden hacerlo.

Si diseñamos mal nuestro data warehouse y sobrepasamos esas capacidades, entonces el servidor se se atora, los procesadores se van al 100%, las luces de los discos se encienden y los usuarios se quejan de que todo está lento y no sirve para nada.

Alguna vez se han preguntado si el problema de desempeño está en los discos duros ¿el I/O de datos?

Mucha gente no. Se quejan de que su servidor es lento y se compran otro más grande pero los problemas siguen. Le echan la culpa a la base de datos y cambian de marca. Le echan la culpa a la herramienta y buscan otra. Cambian Windows por Unix. Y cuando tienen un mega servidor, una base de datos carísima y licencias de cuanta herramienta hay disponible en el mercado; todo sigue igual de lento. Entonces, proclaman maldiciones a los 4 vientos y determinan que data warehousing es una basura, que es una falacia, que no sirve para nada, que han tirado miles de dólares a la basura.

Si usted tiene problemas de desempeño con el servidor, antes de pasar por todo esto pregúntese si el almacenamiento está bien diseñado, si la información está bien distribuida en los díscos, si no está sobrepasando los límites de transmisión de datos.

Este problema es mucho más común si tiene SQLServer de Microsoft ya que aunque es una base de datos que se auto-administra de manera admirable uno olvida a veces que con esos gigantescos volúmenes de datos necesita ayuda. En Oracle u otras bases de datos ocurre menos debido a que por la administración que se hace de ella (la base de datos) se le obliga a uno a administrar mejor el almacenamiento. SQLServer tiene muchas de las cosas que Oracle tiene, están ahí, escondidas, solo tiene que investigarlas. Un buen DBA debería detectar estos problemas rápidamente y solucionarlos.

Regresemos al problema del estacionamiento, si ponemos 10 salidas en vez de 2 entonces todo se aligera ¿no? Piense también en que no basta poner 10 salidas, hay que distribuir los autos en el estacionamiento para que al terminar el partido todos tomen una salida diferente. Si tenemos 10 salidas y todos intentan salir por una el problema sigue.

Lo mismo pasará pasar en el servidor.

Si ponemos 10 discos duros, el servidor puede escribir o leer 5 gigas de datos más rápido en 10 discos que en uno solo. Pero hay que diseñar la base de datos para que esté distribuida en esos 10 discos de tal forma que al leer lo haga de varios discos a la ves. En SQLServer para eso existen los filegroups que serían los equivalentes de los table spaces de Oracle. También existen las tablas particionadas para que pueda distribuir el contenido de una tabla en varios archivos y estos a su vez en varios discos.

Tenga presente el ejemplo de los autos, repítalo una y otra vez. Si el estacionamiento tiene 10 salidas en vez de dos, uno puede salir más rápido de ahí pero las salidas tienen que estar bien distribuidas y los autos haberse estacionado a lo largo del estacionamiento para que al terminar el partido cada uno de ellos tenga una salida cerca. De esta forma cuando usted piense en datos recuerde distribuir los datos en los diferentes discos duros para que las lecturas puedan distribuirse.

Un amigo compartió conmigo un documento como ejemplo de como pueden ser las cosas. Un disco para los catálogos, discos para la tabla de hechos, discos para la base de datos temporal, etc. Es un ejemplo más que claro de como se logran esos volúmenes gigantescos con determinado hardware.

Por cierto, se supone que los arreglos de discos hacen todo esto en automático pero me duele el hígado cada vez que me lo mencionan. Lo mismo me ocurre cuando me mencionan la palabra SAN. Asegurese de el arreglo o la SAN estén configurados correctamente.

Importante: todo esto no lo exime de usar índices. Tampoco significa que lo óptimo es llenar de discos el servidor. Debe de hacer un análisis para detectar si existen problemas de contención de datos.

Technorati tags: ,
About these ads

Comentarios : 2 Comentarios »
Etiquetas: , ,
Categorías : Data Warehouse, Performance

La Tabla de Tiempo en Oracle

9 11 2007

Finalmente tuve la oportunidad de hacer el equivalente en Oracle de la tabla de tiempo. Asume que hay autoconversion de caracteres a numeros, si no es así en la base de datos que están usando habría que añadirle el TO_NUMBER antes de cada TO_CHAR para las columnas numéricas.

/*
Tabla de Tiempo en Oracle
Adrián Ceballos
HaciendoCubos.com
*/
CREATE TABLE Tiempo (
       TiempoID         int NOT NULL,
       Fecha            date NOT NULL,
       Año              int NOT NULL,
       MesID            int NOT NULL,
       Mes              varchar2(10) NOT NULL,
       Cuarto           int NOT NULL,
       Semana           int NOT NULL,
       NumDiaSemana     int NOT NULL,
       DiaSemana        varchar2(15) NOT NULL
);
ALTER TABLE Tiempo
       ADD PRIMARY KEY (TiempoID);

Y el llenado de la tabla. Hay que jugar con el TO_CHAR para cambiar el día de la semana. En Bochgoch pueden encontrar una excelente referencia de los formatos usados en el TO_CHAR.

declare
FechaFin date;
Fecha date;
begin

Fecha    := to_date('2000-01-01','yyyy-MM-dd');
FechaFin := to_date('2010-12-31','yyyy-MM-dd');

WHILE Fecha < FechaFin LOOP

     DBMS_OUTPUT.PUT_LINE('Mes: ' || TO_CHAR(Fecha,'YYYYMMDD') );

     INSERT INTO Tiempo
     SELECT
     TO_CHAR(Fecha,'YYYYMMDD') AS TIEMPO_ID,
     Fecha,
     TO_CHAR(Fecha,'YYYY') AS YEAR,
     TO_CHAR(Fecha,'YYYYMM') AS MES_ID,
     TO_CHAR(Fecha,'MON-YY') AS MES,
     TO_CHAR(Fecha,'YYYYQ') AS TRIMESTRE,
     TO_CHAR(Fecha, 'YYYYIW') AS SEMANA,
     TO_CHAR(Fecha,'D'),
     TO_CHAR(Fecha,'DY') AS DIA_SEMANA
     FROM DUAL;
     SELECT Fecha+1 into Fecha from dual;

end loop;

end;

 

Technorati tags: ,


Comentarios : 4 Comentarios »
Etiquetas: ,
Categorías : Data Warehouse, Diseño, Oracle

Agregados

25 10 2007

sumas

En una empresa con 10,000 empleados si el Director de la empresa desea saber a cuanto asciende la nómina en su empresa ¿Cómo es más rápido obtener ese total?

  1. A cada uno de los 10000 empleados les pregunta cuanto gana, cuantas prestaciones tiene y toma nota. Cuando haya tomado nota de cada uno de ellos calcula el total.
  2. Levanta el teléfono, marca la extensión del departamento de recursos humanos y nómina y les pregunta que cuál es el total de la nómina, que seguramente ya lo tienen a la mano y siempre actualizado.

Obviamente es mucho más rápido el segundo método.

Este es el concepto de agregados (aggregates por su nombre en inglés) o agregaciones. En vez de recorrer el detalle me voy sobre un total yá calculado.

En los data warehouses y cubos este es un concepto importantísimo. Para que su herramienta de BI no tenga que hacer los cálculos de los totales a nivel registros se usan agregados.

Todas las herramientas y motores OLAP manejan o usan el concepto de agregados. Analysis Services (7, 2000, y 2005), Oracle 8 o mayor, Redbrick, DB2, SAP BW, Teradata, HP NeoViews, Artus, Pentaho, Cognos…y ahora sí que etc. Ciertamente Oracle y HP NeoViews les llaman vistas materializadas o materialized views pero el concepto es el mismo.

El administrador es el que define que agregados desea calcular y cuando se deben de recalcular. Lo normal es que se recalculen en la carga del cubo o datawarehose. Los usuarios de la información no se enteran si existen agregados, ellos lanzan la consulta sobre el cubo o la estrella principal y el motor de cubos o base de datos detecta que para resolver la consulta puede usar un agregado, toma la información de ahí y se la regresa al usuario.

Tome en cuenta que los agregados toman tiempo y espacio. Así que tampoco llene su servidor con todos los agregados posibles. Cree solo aquellos que ocupa y créelos en base a elementos que reduzcan el # de registros a recorrer. Por ejemplo, si tiene 100 tiendas, cree un agregado o total por tienda ya que serán 100 registros por día o por mes. Si tiene 17 millones 244 mil facturas NO cree un agregado a nivel factura ya que se está haciendo harakiri.

Todas los motores olap y herramientas tienen query advisors que monitorean los querys y le sugieren que agregados crear además de índices. Solo tiene que activar esos servicios. Por ejemplo en Microsoft Analysis Services puede usar la “optimización basada en uso”.

En otras palabras, si el tiempo de respuesta de sus consultas es lentísimo y desesperante, el foquito del disco duro siempre está encendido o el procesador está al 100% durante las búsquedas, no sea sádico, use agregados.Nerd

Technorati tags: ,

Comentarios : 3 Comentarios »
Etiquetas: , , ,
Categorías : Data Warehouse, Performance

¿Estrella o Copo de Nieve?

22 10 2007

Plato

Cada vez que comenzamos un proyecto nuevo siempre es lo mismo ¿Estrellas o copos de nieve?¿que es mejor? Es una decisión dificil de tomar.

A mi me gusta trabajar más con estrellas. El tiempo de respuesta del servidor es más rápido debido a que se involucran menos tablas en los querys. Sin embargo tienen la desventaja que hay que programar más. Los programas que se encargarán de estar manteniendo los catálogos (o puntas de la estrella) al día son más complejos.

La ventaja que yó le veo a los copos de nieve es que la información se puede pasar casi siempre tal cual viene. O sea que en un 2×3 podemos tener lista la parte del modelo referente a los catálogos.

Respecto al trabajo que se requiere para llenar la tabla de hechos no hay diferencia entre un modelo y el otro.

No son verdades absolutas. En un modelo estrella, cuando el catálogo que representa una dimensión que tiene demasiados registros, involucrar esta tabla no es tán eficiente. No se requiere ser un genio para darse cuenta que si tengo una estrella donde se usa la dimensión cliente con 500,000 registros y si el sexo de nuestro cliente es una columna más de la tabla de clientes, entonces hacer un query que nos dé las compras por el sexo del cliente (¿quién compra más, las mujeres o los hombres?) hará que la base de datos recorra 500,000 registros del catálogo para sacar los valores diferentes de sexo. Esto hará que el servidor trabaje más; aquí el modelo copo de nieve sería más eficiente.

Si usted tiene Redbrick, entonces no se preocupe, puede hacer todo como una estrella perfecta y crearle agregados a los catálogos. Sí, Redbrick recorre las tablas de la estrella y coloca en una tabla de agregados los valores diferentes de las dimensiones (sexo) dentro de la grán dimension (clientes). Si no estoy mal, lo mismo debe suceder con Oracle.

Lo siento, no he tenido la oportunidad de verificar si otras marcas de base de datos tienen esta capacidad.

Si usted tiene el tiempo suficiente para hacer todo como debe de ser digamos que la regla sería: 

Si los valores de las dimensiones son pocos (los catálogos) use el modelo estrella. Para dimensiones gigantescas use el modelo copo de nieve.

¿qué es gigantesco y qué no lo es? La experiencia y el hardware de su servidor lo dirán.

Como vé, en muchos proyectos no se pueden tener estrellas ó copos de nieve. A veces lo que se requieren son híbridos, mitad y mitad.


Comentarios : 6 Comentarios »
Etiquetas: , , , , , , , ,
Categorías : Data Warehouse, Diseño

La Dimensión Minutos

16 10 2007

Muchas veces se requiere analizar la información en base al tiempo. Por ejemplo, desglosar las ventas por hora, por minuto o si ocurrieron en la mañana, tarde o noche. En otras palabras, requerimos una dimensión de tiempo, pero nó la de tiempo normal sinó una en base al minuto del día en el que transcurrieron las cosas.


CREATE TABLE Minutos (
MinutoID int NOT NULL,
Minuto varchar(50) null,
HoraID int NOT NULL,
Hora varchar(50) NULL,
ParteDelDiaID int NOT NULL,
ParteDelDia varchar(50) NULL,
PRIMARY KEY (MinutoID)
)

El anterior código es el create table para nuestra dimensión Minutos. La llave es el MinutoID, para esta llave yo siempre uso el minuto del día a partir de las cero horas. Así por ejemplo para las 5:30 uso 5*60+30=330 como llave.

Minutos

Un select sobre la tabla Minutos nos daría el anterior resultado. Minuto y Hora son varchar para dejar ahí la descripción de los minutos y hora. Como por ejemplo: “12:58″ y “12:00″; “00:34″ ó “01:00″.

Esto se requiere para el order by, sobre todo cuando se quiere una gráfica hora por hora.

El código para llenar la tabla minutos es el siguiente:


Declare @Fecha datetime

set @Fecha = '2007-01-01 00:00:00'
while @fecha < = '2007-01-01 23:59:00'
begin
insert into minutos
select
datepart( hh, @fecha)*60+datepart(mi, @fecha) as MinutoID,
left(convert( varchar, @fecha, 108),5) as Minutos,
datepart( hh, @fecha) as HoraID,
left(convert( varchar, @fecha, 108),3)+'00' as Hora,
case
when datepart( hh, @fecha) between 0 and 12 then 1
when datepart( hh, @fecha) between 13 and 19 then 2
else 3
end as ParteDelDiaID,
case
when datepart( hh, @fecha) between 0 and 6 then 'Madrugada'
when datepart( hh, @fecha) between 6 and 11 then 'MaÃ�±ana'
when datepart( hh, @fecha) between 12 and 19 then 'Tarde'
else 'Noche'
end as ParteDelDia

set @Fecha=dateadd( mi, 1, @fecha)

end

La tabla únicamente guarda los 1440 minutos del día, nó mas.

Con esta tabla como parte de la estrella ahora sería posible hacer querys como estos:


select hora, sum( NumeroTransacciones)
from dbo.FactProcessesPerspective a
join Tiempo b on a.tiempoid = b.tiempoid
join Minutos c on a.MinutoID = c.MinutoID
where
b.Mes = '2007-01'
group by hora

o en vez de hora usar el campo ParteDelDia y así tendría cual fué el número de transacciones en la mañana, tarde o noche. Por cierto, esta tabla es algo indispensable para un cubo de delicuencia.

Technorati tags: ,


Comentarios : 4 Comentarios »

Categorías : Data Warehouse, Diseño

Uso de índices en un data warehouse

28 08 2007

mapa

Varias veces me ha pasado que al visitar un data warehouse me encuentro con que en las tablas hay cero índices. Tengo muy presente unos cubos que se tardaban 2 días en procesarse.

El uso de índices es uno de las cosas que más afecta el performance o desempeño. Debería ser obligado que todo data warehouse tenga los apropiados.

Para los que se preguntan ¿que es un índice? Una sencilla respuesta sería hacer una comparación. Para encontrar donde está ubicado un cliente que tengo que visitar tengo 2 opciones: buscar la dirección en un mapa o lanzarme a ciegas. Si me lanzo a ciegas tengo que recorrer calle por calle, preguntar e ir contando número por numero hasta dar con la dirección. Los 2 sabemos que éste último método es pésimo.

De 10 veces solo una vez encontré la dirección a la primera y eso que tuve mucha suerte.

Los índices son los mismo. Son un mapa de la información. Si no hay mapa entonces la base de datos recorre uno por uno los registros para dar con ellos. Un síntoma de que ocurre esto es que al pararse enfrente del servidor las lucecitas están prendidas y no se detienen.

Aparte de que el % de uso del procesador es elevado.

Si usted es de esos usuarios avanzados sabrá que se puede monitorear la cantidad de accesos a disco y que el resultado dice que están arriba de lo normal.

Algunas recomendaciones para usted y su data warehouse respecto a los índices:

  • indexar las primary keys de las tablas. Si, a veces hay primary keys y no hay índices. Sobre todo en los motores de bases de datos viejitos que no tenían tanta integridad.
  • Evitar usar campos llaves que no sean numéricos. Prefiera los campos enteros para las llaves. Eso hará que los índices se eficienten mucho y respondan de manera más rápida. Además esto le permitirá definir índices de tipo bitmap que funcionan hiper-eficientemente por no decir “hechos la @#&%!”. Conozco una base de dato que cada índice mide el 25% de lo que mide la tabla. Con 2 o 3 índices ya nos acabamos el disco duro. Todo por que las llaves son varchar.
  • Indexar aquellas columnas por las que hará búsquedas frecuentemente.
  • Si tiene tiempo, paciencia y recursos pruebe lo que dice el manual de almacenar los índices en un archivo o disco diferente al de datos. Se sorprenderá al ver los tiempos de respuesta. Si todavía tiene paciencia entonces pruebe todo el concepto (datos, temporales, base de datos de sistema, indices y logs). Si tiene una base de datos gigantesta, los tiempos de respuesta están lentos y aún no ha probado esto…no entiendo como ha sobrevivido.
  • Lea los manuales y trate de entender los diferentes tipos de índices que su base de datos tiene, las desventajas y ventajas que tiene cada uno de ellos. El costo y los beneficios que le puede traer.
  • Si tiene Oracle el uso del paralelismo le puede traer muchos beneficios, investigue.
  • En algunas bases de datos los índices también se pueden particionar. Esto aplica para data warehouses gigantescos.
  • Un data warehouse está diseñado para consultas así que es perfectamente válido que esté sobre-indexado, pero no exagere.
  • Monitoree las consultas que se lanzan sobre la base de datos y verifique que usen índices. Si no usan índices investigue por qué. A lo mejor simple y sencillamente no tiene.
  • Pregunte qué están haciendo en otras empresas respecto a este tema y no tenga temor de contratar alguien que le apoye con este tema.

¿Ahora entiende por qué aquellos cubos que mencioné se tardaban 2 días en procesarse? Había cero índices.

Technorati tags: , ,

Comentarios : 3 Comentarios »

Categorías : Data Warehouse, Mejores prácticas, Performance

¿qué es un data warehouse?

23 08 2007

almacen

Para aquellos que les haya tocado la época en donde todas las consultas se resolvían con reportes o queries se acordarán de los problemas más comunes de aquellos tiempos.

  • Cientos de tablas de donde sacar la información ¿cuál era la buena?
  • El reporte solo se podía ejecutar por las noches o los fines de semana
  • 20 sistemas diferentes en diferentes lenguajes y diferentes bases de datos
  • la información estaba en 20 servidores distintos
  • varias versiones de la verdad
  • mil problemas más

Ahora cuando recuerdo las petición “necesito un reporte consolidado de las operaciones de la empresa” puedo entender mi stress.

Debo corregir el texto. Esos problemas no forman parte del pasado. Como consultor de BI me los encuentro cada día en cada una de las empresas que visito.

Alguien sugirió para resolver todos esos problemas relacionados con la consulta y análisis de información crear una base de datos que contuviera toda la información histórica de la compañía. De esta forma si necesitaba un dato, ese dato estaría ahí. En un solo lugar. En un solo sistema. En una sola marca de base de datos. En un solo lenguaje de consulta y con una sola verdad.

Regresando a la pregunta ¿qué es un data warehouse o bodega de información? Pues es eso, una base de datos o bodega e información que almacena los datos históricos de los diferentes sistemas en un solo lugar. Y sirve, están diseñado y está hecho para ser consultado y para analizar información. Todo esto de una manera fácil.

—¿base de datos histórica?¿ Entonces si levanto un respaldo de mi sistema en otro servidor es un data warehouse?

No se emocione Nerd. Si usted levanta el respaldo de los 5 años anteriores del sistema de facturación en otro servidor eso NO es un datawarehouse.

Así como en las bodegas tradicionales se utilizan tarimas de varios niveles, carritos y grúas para acomodar grandes cantidades de artículos, en un data warehouse las tablas que almacenan información se diseñan de una manera especial pensando en que almacenarán cantidades gigantescas de información.

Esas maneras especiales o modelos son el copo de nieve y estrella. Cada uno tiene sus ventajas y desventajas.

He visto data warehouses diseñados como si fueran el sistema de facturación o el de producción. Desde mi punto de vista son inservibles todos ellos. Hay un excelente documento llamado Drawing the line between Dimensional Modeling and ER Modeling Techiques by Ralph Kimball que pinta la línea perfectamente.

¿y los cubos? Eso es punto y aparte. No són la misma cosa, se complementan y a menudo se traslapan. He estado en empresas con data warehouses explotados con SQL y Excel, sin cubos. Lo platicamos después.

Otro punto que debe de considerar es que la información que contiene por lo general debe estar trasformada y limpia ( usted no tiene una columna total_documentos; en el DWH tiene métricas que se llaman Ventas, Ventas en dólares, Devoluciones, mermas, etc.).

Todavía hay más cosas como los agregados, pero creo que con todo lo anterior queda un poco más claro qué es un data warehouse.

Technorati tags:

Comentarios : 23 Comentarios »
Etiquetas: , , , , , , , ,
Categorías : Data Warehouse

Algunas recomendaciones para la tabla de hechos

26 07 2007

Cuando hagas tu tabla de hechos sigue estas recomendaciones.

  • No usar llaves compuestas. Trata de no usar llaves compuestas, esto es, utiliza un solo campo para hacer join con las otras tablas. Esto hará que la base de datos trabaje menos. Es un poco complejo de programar pero ayudará bastante en el performance de la base de datos. ¿ Y no funciona si uso llaves compuestas? Si, si funciona pero se nota una diferencia en los tiempos de respuesta. Esto se nota más si la tabla de hechos será gigantesca.
  • Define la Primary Key en la tabla de hechos. Si en el CREATE TABLE establecemos quién es la primary key, la base de datos creará un índice con la combinación de estos campos lo que hará más rápidas las búsquedas….Si, si me he topado con DWH que no tienen índices y que al procesar los cubos se tardaban 2 días. Si su tabla de hechos no tiene índices, pongale uno, el más apropiado de entrada es aquel que incluye a todos los campos que forman la llave de la tabla….Lo mismo aplica para las tablas de dimensiones o catálogos.
  • Utilice los tipos de datos apropiados. En el diagrama puede ver como el campo unit sales usa un tipo de dato DOUBLE PRECISION; esto estaría bien si nos dedicaramos a la venta de garbanzos :D  y quisiéramos llevar la cuenta del # de garbanzos vendidos (no sé, pero un kilo de garbanzos ha de traer cientos de ellos ) ¡Es para almacenar números gigantescos!. Si lo que vendemos es maquinaria a lo mejor con un Decimal(10,2) estaría bien. Tenemos que acoplarnos al número que almacenará la columna. Espacio de más hará que la base de datos crezca más y se requiera más espacio, y a más espacio más trabajo y más servidor y más memoria y más…
  • Tenga cuidado con el tipo de dato entero. Una vez haciendo un cubo de recursos humanos teníamos 2 indicadores: # de Personas y #Personal Requerido. Como no se puede tener 1/2 persona ni requerir 1/2 persona los dos los definí de tipo entero. La bronca vino al hacer las consultas. Resulta que en las bases de datos, al dividir un entero entre otro entero el resultado es un entero, o sea ( 768/1000 ) = 1. Luego teníamos a cada rato que anteponerle CONVERT u otra instrucción por que el resultado o era 1 o 0. Recuerdo que esto aplica para SQLServer y Redbrick, no recuerdo en este momento si pasa lo mismo en Oracle.
  • Las tablas de hechos pueden tener campos de apoyo. Si, no siempre se tienen únicamente los hechos y dimensiones. Se pueden tener campos como Fecha de entrega, de compra, etc.
  • No guarde campos que se pueden calcular. Si por ejemplo tiene un indicador que es el precio promedio = ventas $/ Ventas Unidades; no haga el calculo y lo guarde en la tabla de hechos por que al consultar los datos deberá usar una formula de agregación como SUM, AVG, MAX, MIN y si lo analiza, la distorsión del indicador será bastante grande al promediar un precio promedio en millones de registros o pocos de ellos.
  • Use nombres amigables. No hay razón para no utilizar el nombre VENTAS UNIDADES para una columna en la tabla de hechos. Luego no tiene uno NPI de lo que hay en cada columna.

Recuerde, los datawarehouses se diseñan pensando en ser de fácil consulta. Son para analizar información.

Technorati tags: ,

Comentarios : 10 Comentarios »

Categorías : Data Warehouse, Mejores prácticas

La tabla de hechos

24 07 2007

TablaHechos

Cuando estamos construyendo nuestro Data Warehouse tenemos que diseñar la tabla central que es la que guardará los hechos. A diferencia de un sistema transaccional donde en una tabla tenemos el total de la factura, en otra el total de la orden de compra, en otro el tipo de cambio (y así sucesivamente) en un Data Warehouse (DWH) los hechos (las cosas que sucedieron) están en una única tabla.

Para aclarar la palabra hechos: ¿qué sucedió en mi compañia? Pues vendí, compré, vendí en unidades, tuve un # de empleados. Entonces en la tabla de hechos se guardan las ventas, las ventas en unidades, las compras, etc..

Todo lo que sean indicadores.

Tampoco se trata de hacer una tabla gigantesca que tenga lo de recursos humanos + lo de ventas + lo de produccion + lo de telemarketing + ¡todo!

No hay que exagerar…Time out

Normalmente las cosas que están en la tabla de hechos tienen afinidad entre sí. De esta forma tendremos una tabla de Hechos de Ventas, una de inventario, una de Recursos Humanos, una de produccion, etc.

No todas las herramientas de explotación de Data Warehouse permiten hacer reportes o informes tomando información de 2 o más tablas de hechos; es por esto que a veces en un DWH se suelen encontrar cosas extrañas como las ventas y el # de empleados en la misma tabla de hechos ( para hacer el calculo de Ventas/#Personas). El problema de esto es que el DWH vuelve caótico: cada vez que necesite hacer un calculo entre 2 tablas de hechos hago un nueva table de hechos que junte las 2 y entonces me lleno de tablas de hechos o cubos ( si trabaja con cubos Rolap a esto se le llama cubitis).

Mejor encuentre una herramienta que permita tomar información de multiples tablas de hechos. Artus soporta crear indicadores calculados con columnas de 2 o más tablas de hechos. No solo eso, si no que también permite mezclar en el tablero de control información de diferentes proveedores de cubos: SAP, Analysis Services, Rolap ( Oracle, Sybase, DB2, Redbrick ).

Technorati tags: ,


Comentarios : 22 Comentarios »

Categorías : Data Warehouse, Diseño

Llenando la tabla de tiempo

18 07 2007

Recurro muy seguido a este script de SQL para llenar mi tabla de tiempo. Casi siempre lo hago y lo vuelvo a hacer una vez al mes. Todavía no comprendo como no demonios lo guardo en alguna parte…bueno, esperemos que al publicarlo lo tenga en un solo lado.


/*
Llena la tabla de tiempo
Haciendo cubos: Adrian Ceballos

Solo para asegurarnos que esto corre
en cualquier servidor independientemente
del idioma ademas de especificar en que
idioma saldran los nombres de los dias de la semana
*/
SET LANGUAGE spanish

/*Ponemos que el primer dia de la semana
1 es Lunes. Para el Domingo usar 7*/

SET DATEFIRST 1

declare @fi datetime, @ff datetime

set @fi = '2004-01-01'
Set @ff = '2004-31-12'

while @fi &lt; = @ff
begin
insert into Tiempo (TimeID, Fecha, Anio, MesID, Mes,
Cuarto, Semana, NumDiaSemana, DiaSemana)
select year(@fi)*10000+month(@fi)*100+day(@fi) as TimeId,
@fi as Fecha,
year(@fi) as Anio,
year(@fi)*100+month(@fi) as MesID,
case when Month(@fi)  &lt; 10
then datename(year,@fi)+'-0'+convert(varchar,month(@fi))
else datename(year,@fi)+'-'+convert(varchar,month(@fi))
end as Mes,
year(@fi)*10+datepart(q,@fi) as Cuarto,
datename(year,@fi)+datename(ww,@fi) as Semana,
datepart( dw, @fi) as NumDiaSemana,
datename( dw, @fi) as DiaSemana
set @fi = @fi + 1
end

Solo hay que darle copy-paste y ¡voilá!…No olviden sustituir los valores fechas para el rango que quieren se genere en la tabla de tiempo. El detalle de las columnas aquí.

El concepto es el mismo para cualquier marca de base de datos pero habrá que traducir el script. El script para crear y llenar la tabla de tiempo puede bajar aquí.

Technorati tags: ,


Comentarios : 15 Comentarios »

Categorías : Data Warehouse, Diseño, Estrellas

« Entradas anteriores


Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 29 seguidores