Tips de Diseño de DWH- La Granularidad – Parte 1

 

 

Por nuestra Blogger SmartB: Rut Almoguera

Querido lector que te inicias en el diseño de DWHs, si crees que la granularidad es un término elegante para referirse a la cantidad de granos de arena que hay en una hermosa playa del Caribe… Entonces este post es para ti.
Cuando escuchamos la palabra granularidad normalmente lo asociamos a granos de arena, sin embargo en el caso del diseño de un DWH, este concepto se refiere a dos cosas.  Una es al nivel de detalle de la data que guardamos en una tabla de una dimensión, y otra al nivel de detalle que con el que registramos los hechos en una tabla Fact.
En este post hablaremos de la granularidad en las dimensiones.
La granularidad como instintivamente pensamos está asociada al grano, pero al grano de las dimensiones de un DWH. El grano de las dimensiones es el nivel de detalle a la que llegamos en la data que guardamos en la dimensión. Para entender mejor este concepto, usemos de ejemplo la dimensión Región.
Imaginemos por un momento que tenemos un DWH en donde registramos las ventas de unos almacenes que tienen presencia a nivel mundial.  En este DWH se requiere que se registren las regiones en donde se realizaron las ventas para poder analizar cómo fueron las ventas en cada una de ellas y tal vez analizar donde aplicar campañas estratégicas con ofertas por Región.
 
 
Supongamos que nuestra región de venta se registra en el transaccional a nivel de Municipio, es decir cada tienda que realiza una venta deja registrado en el sistema el Municipio de la misma.  En este caso en el sistema transaccional conocemos el detalle de las ventas con el Continente, el País, el Estado, la Ciudad y el Municipio, con lo cual tendríamos una jerarquía que llega hasta el detalle del Municipio:
 
Con esta jerarquía en la dimensión Región, tendríamos que la granularidad de dicha dimensión es hasta el nivel de Municipio.
Con gran frecuencia la granularidad de las dimensiones en el DWH es la que encontramos en el sistema transaccional, pero a veces ese nivel de detalle es excesivo para el DWH, y entonces debemos decidir cambiarlo por algo más resumido, para que sea útil para los análisis que se desean realizar.  Imaginemos por ejemplo que el detalle que deseamos conocer en el DWH es solo hasta el nivel de la Región.  En este caso la jerarquía que estaríamos usando dentro de nuestro DWH para la dimensión Región sería diferente al nivel de detalle que tenemos en el transaccional.  En este caso la jerarquía para dicha dimensión sería la siguiente:
 
Con esto la dimensión Región llegaría solo hasta la granularidad de Región y no del Municipio.
Mientras más detalle tiene una dimensión en el DWH más fino es el grano y diríamos que tiene una granularidad más fina, y mientras menos detalle, el grano es más grueso, y por lo tanto la granularidad es más gruesa.
Con frecuencia se recomienda que el grano de las dimensiones en el DWH sea el mismo que tenemos en el transaccional, pero sucede que en ocasiones demasiado detalle implica tablas Facts más grandes, y con eso puede causar que se degrade el tiempo de respuesta del DWH.  Además de esto, los DWHs guardan data histórica de varios años, lo que puede causar que el nivel de detalle se convierta en un problema para el mantenimiento de los mismos, pues tendríamos que decidir entre tener más detalle del transaccional en cada hecho guardado en la tabla Fact vs tener menos años de historia en el DWH.
Por esto al momento de diseñar las dimensiones y decidir el grano de las mismas debemos sopesar que es más importante para nuestro análisis: si el hecho de tener mayor detalle por hecho en la Fact y que se degrade el performance de respuesta del DWH con un nivel de detalle que a lo mejor no es requerido en los análisis de la empresa y que puede estar afectando el tamaño de la BD del DWH, o tener menor detalle que causaría que tuviésemos menos historia dentro del DWH.  Por esto es necesario que antes de diseñar estudiemos detenidamente los requerimientos de los usuarios, y veamos los Reportes y Dashboards que se desean que el DWH ayude a realizar, pues el DWH no está hecho para sustituir los reportes ya existentes en el sistema transaccional sino para complementarlo y responder a las preguntas de alto nivel que se hacen los directivos de la empresa con respecto al desempeño de la misma.
Así que querido lector, la próxima vez que estés diseñando un DWH es importante no solo decidir las dimensiones que participaran del mismo, sino también hay que prestar atención a la granularidad de las mismas, pues esto contribuirá con el éxito de nuestro diseño, adaptándose mejor a los análisis que se harán de los datos y también al mantenimiento de la BD que lo contiene.
En un próximo post hablaremos sobre la granularidad de las tablas Fact.

Tips de diseño de DWH: La Omnisciente Dimensión Time – Parte 1

Por Rut Almoguera Poggi



Si estas iniciándote en el diseño de DWH hay una dimensión que deberías conocer pues te va a acompañar en todos los diseños que realices: La dimensión Time.
Voy a comenzar este post con una afirmación que  a lo mejor te va a asombrar: La dimensión Time es una dimensión usada en TODOS los Data Warehouses.
La primera pregunta que se suele hacerse alguien que esta iniciándose en el diseño de DWH es ¿Por qué es necesario utilizar una dimensión Time, si se puede registrar la fecha como un hecho o medición más de la Fact?.
La respuesta a esa pregunta la encontramos, al igual que las respuestas a todas las decisiones de diseño en un solo sitio: “Los requerimientos del Cliente”.  Revisando cuales son los requerimientos de nuestro cliente, cuales son las preguntas que el DWH necesita responder podremos determinar si necesitamos o no una dimensión Time.
La experiencia nos dice que los análisis que los clientes quieren hacer suelen ser cosas como: ver cuando sucedió un evento específico, o hacer comparaciones entre periodos de tiempo diferentes, por ejemplo en un DWH en donde se guarden las ventas, podríamos querer comparar las ventas del mes actual con las del mes anterior, o con este mismo mes pero el año anterior. O podría querer ver el comportamiento de las ventas en fechas especiales, como por ejemplo el último día del año o los días cercanos a las quincenas o al cobro de las utilidades.
Además con frecuencia los Clientes requieren de Cubos n-dimensionales que totalicen la data a través de las jerarquías de las dimensiones para poder tener respuestas a todos sus interrogantes,  siguiendo con nuestro ejemplo del DWH de ventas, podría querer ver las ventas diarias, pero también poder consultar las ventas del semestre actual o del año o del mes, por lo tanto con declarar la fecha simplemente como un atributo de la tabla Fact no nos basta, es necesario crear una dimensión.
Dicha dimensión Time, en ocasiones tiene una gran complejidad, conteniendo una gran cantidad de información, como por ejemplo los días feriados, el total de días hábiles del mes, el número de la semana del año a la que pertenece una fecha en específico, cual es el periodo fiscal especifico de nuestra empresa, tener un atributo que  indique si un día es o no el ultimo día del mes, etc.  Como podemos ver, estas no son cosas simples de determinar a simple vista o con cálculos sencillos y nos pueden ser muy útiles para hacer cálculos requeridos por el Cliente.
Dado que ya determinamos que la dimensión Time es imprescindible y que ella debe ser una tabla física dentro de nuestro DWH, nos enfrentamos a un segundo problema: ¿De dónde sacamos la data? Todas las demás dimensiones en un Data Warehouse tienen un origen de datos, bien sea una tabla, un archivo plano, etc.  Sin embargo, la dimensión Time, es una dimensión especial, pues de esta dimensión NUNCA se tiene una fuente.  Esto se debe a que los sistemas transaccionales no necesitan por lo general tener una tabla con la data de las fechas, pues en los sistemas OLTP no se realizan análisis de los datos, solo se registran los mismos, y es en el DWH en donde se realizaran los análisis de los comportamientos del negocio asociados a los periodos de tiempo.
 Dada esta limitación, de no contar con una fuente de datos para la construcción de la dimensión Time,  la misma debe ser llenada haciendo uso de un Store Procedure de BD,  una hoja de Excel con la cual podamos precargar un rango grande de fechas o algún otro programa que desarrollemos para tal fin.
Hoy en día, muchas herramientas de ETL te permiten crear una dimensión Time sin tener ninguna fuente de donde sacar los valores, pero en general es más recomendable que dicha dimensión la construyamos nosotros mismos, pues de esta manera podemos colocarle las particularidades necesarias para el diseño especifico que estemos realizando, como por ejemplo los periodos fiscales, o la cantidad de días hábiles acumulados al mes en una fecha específica.  Obviamente la complejidad o simplicidad de nuestra dimensión Time dependerá en gran medida de la granularidad que vaya a tener dicha dimensión y de los requerimientos de nuestro Cliente.

En la siguiente entrada de este post hablaremos un poco sobre cuáles son las recomendaciones a seguir cuando vamos a crear nuestra dimensión Time.

Instalación de BigInsights 3.0.0.2 Pre-requisitos / Tips PARTE III

Por Yosely Quintero

 Siguiendo con la secuencia de pasos de la parte II de este documento de pre-requisitos y tips a seguir para la instalación exitosa de BigInsights, se procede a configurar el archivo 90-nproc.conf.
Ø  Ahora vamos a configurar Red de Trabajo
Edite el archivo /etc/hosts para incluir la IP, el FDQN del servidor. Si solo tiene el localhost se debe agregar otra línea que apunte a la IP del localhost pero que tenga un  nombre de dominio diferente al locahost para que bigInsights lo reconozca como un nodo valido.
En este caso se agregó la segunda línea, este será el nodo sobre el cual se realizara la instalación.
       vi /etc/hosts
          
Ø  Edite el archivo /etc/resolv.conf y modifique el dominio que usara para su nodo. En este caso como el nodo era el de la segunda línea de /etc/hosts, en este archivo este es el dominio que se debe colocar en search localdomain.
      vi /etc/resolv.conf
 
           Para finalizar esta configuración de red, ejecute el siguiente comando:
    service network restart
Ø  Se debe configurar passwordless SSH para el usuario root y biadmin. Siga los siguientes pasos:
su root
ssh-keygen -t rsa ( se deja en blanco para que se genere de forma automática).
Cuando solicite la clave déjela en blanco.
Para esta instalación se debe colocar el  dominio que se agregó en /etc/hosts (bda.iicbang.ibm.com )
ssh-copy-id -i ~/.ssh/id_rsa.pub root@bda.iicbang.ibm.com
Repita esta configuración para el usuario biadmin.
Finalmente asegúrese que  puede conectarse de forma exitosa al servidor remoto sin clave con el siguiente comando:
ssh root@bda.iicbang.ibm.com
exit
Ø  Ejecute los siguientes comandos para deshabilitar el firewall
service iptables save
service iptables stop
chkconfig iptables off
 
Ø  A continuation  desactive  IPV-6:
echo “install ipv6 /bin/true” >> /etc/modprobe.d/disable-ipv6.conf
Ø  Edite el archivo /etc/sysconfig/network, para que se vea como se muestra en la siguiente imagen
vi /etc/sysconfig/network
Ø  A continuacion edite el archivo /etc/sysconfig/network-scripts/ifcfg-eth0 ( Asumiendo que usa eth0 para su red).Toda esta información la obtiene desde el ifconcig(HWADDR)
               vi /etc/sysconfig/network-scripts/ifcfg-eth0
         
Ø  Edite el archivo  /etc/sysctl.conf y agregue al final los valores que se muestran en la imagen
  vi /etc/sysctl.conf
Ø  Finalmente reinicie la maquina
reboot
Ø  Ahora vamos a verificar  que la IPV6 este desactivada (no se debe listar en la salida del ifconfig)
Ifconfig
Ø  Procedemos a sincronizar el reloj, usando Network Time Protocol (NTP):Editar el archivo /etc/ntp.conf y modificar las líneas en rojo
vi /etc/ntp.conf

Ø  Para modificar el  servicio NTPD con el tiempo del servidor espercificado antes en el paso anterior, para esto ejecute el siguiente comando. chkconfig –add ntpd
Ø  Inicie el servicio NTPD:
service ntpd start
Ø  Verificar que el reloj este sincronizado con el tiempo del servidor:
ntpstat
Una vez completadas las configuraciones previas a la instalación, se puede continuar con la fase de validación para iniciar la instalación. (Documento Instalación BigInsights V3.0.0.2) 

Slowly Changing Dimensions – Tipos 3. 4 y 6.

Rut Almoguera Poggi

                                              


En el post anterior hablamos de los SCD 0,1 y 2, en esto post veremos algunos otros que en varios casos son más complicados de implementar.
 
Además de los SCD 0, 1 y 2 que vimos en el post anterior, que son las más comunes y fáciles de implementar, existen otras alternativas interesantes sobre cómo se puede manejar el cambio en las dimensiones cuando se desea registrar en el DWH dichos cambios.  En esta ocasión nos encargaremos de definir los tipos 3, 4 y 6, los cuales guardan los cambios de las dimensiones, pero cada uno lo hace de una manera diferente. 
 
Tipo 3(SCD3): En este caso, se desea guardar la historia de los cambios, pero a diferencia del tipo 2, se guarda solamente un número finito y predeterminado de cambios, y no se agrega un registro nuevo en la tabla, sino que se tienen campos extra en la misma fila para guardar los valores anteriores.
 
Usualmente se implementa el tipo 3 si tenemos la necesidad de guardar unos pocos cambios, como por ejemplo, las direcciones de residencia de una persona, en donde podríamos tener tres campos dentro de la tabla para guardar los últimos tres sitios en donde la persona ha vivido.  En este caso, si la persona se vuelve a mudar, la dirección más antigua se pierde y se guardan solamente las tres últimas.
 
Sin embargo, es importante advertir que este método sube la complejidad del desarrollo del ETL, pero tiene la ventaja de no aumentar el tamaño de la tabla de la dimensión, pues en ocasiones ciertas tablas de dimensiones pueden ser demasiado grandes, como suelen ser,  por ejemplo, las tablas de clientes en un banco internacional, y si se desea guardar la historia de los cambios de algún atributo de la dimensión, se prefiere la complejidad antes que incrementar el tamaño de la tabla, pues esto podría degradar el performance de consulta al DWH.
 
Para ilustrar esto, , si tenemos la dimensión producto, y queremos guardar el histórico de 2 cambios de  precio, la tabla que tendríamos para dicha dimensión seria como se muestra a continuación:
 
SK_Producto
Codigo_Producto
Descripcion
Precio_actual
Precio_anterior
1
SANDDAMLUJ0012
Sandalia de Dama de Fiesta
20.000,00
2
ZAPCABACUER0018
Zapato Caballero Cuero Cerrados
35.000,00
3
ZAPDAMTAC0039
Zapato Dama Tacón Corrido
25.000,00
15.000,00
 
En dicha tabla podemos notar que el producto ZAPDAMTAC0039 tiene un precio actual de 25.000,00 y que anteriormente su precio era de 15.000,00.  Si ese mismo producto cambiara ahora su precio a 30.000,00, la tabla se mostraría como sigue:
 
SK_Producto
Codigo_Producto
Descripcion
Precio_actual
Precio_anterior
1
SANDDAMLUJ0012
Sandalia de Dama de Fiesta
20.000,00
2
ZAPCABACUER0018
Zapato Caballero Cuero Cerrados
35.000,00
3
ZAPDAMTAC0039
Zapato Dama Tacón Corrido
30.000,00
25.000,00
 
Nótese como en este caso, ya no tenemos manera de saber que dicho producto en algún momento tuvo un precio de 15.000,00, pero seguimos viendo los últimos dos cambios de precio sin agregar ninguna fila estra a la tabla.
 
Tipo 4 (SCD 4):  En este tipo, se guarda en la tabla original el último valor, pero se tiene una mini tabla de dimensión que guarda la historia de los cambios.  Y en este caso, la tabla Fact guarda referencia a las dos dimensiones, es decir a la que tiene el valor actual y a la que tiene la historia de los cambios.
 
En la dimensión que contiene el último valor se encuentran todos los campos de la dimensión, pero en la que tiene el histórico de cambios solo están el SK de ese registro, la clave natural y el campo que cambio, con otros dos campos de fecha que indican el inicio y el fin de la vigencia de dicho valor.  Con esto, se preserva la historia de cambios y no se afecta el performance de consulta, sin embargo sube la complejidad de los queries cuando se desea consultar la historia de los cambios de dicho campo.  Esto se suele usar cuando se tiene un campo que es extremadamente volátil y que sufre cambios con una frecuencia alta.
 
Siguiendo con nuestro ejemplo de la tabla de productos, en donde el producto ZAPDAMTAC0039, ha tenido tres precios distintos, que son 15.000, 25.000 y finalmente 30.000, tendríamos dos tablas, una con los productos con su precio actual:
SK_Producto
Codigo_Producto
Descripcion
Precio
1
SANDDAMLUJ0012
Sandalia de Dama de Fiesta
20.000,00
2
ZAPCABACUER0018
Zapato Caballero Cuero Cerrados
35.000,00
5
ZAPDAMTAC0039
Zapato Dama Tacón Corrido
30.000,00
Y otra tabla con el histórico de los cambios:
SK_Producto
Codigo_Producto
Precio
Fecha_Inicio_Vigencia
Fecha_Fin_Vigencia
3
ZAPDAMTAC0039
15.000,00
2015-08-02
2015-08-17
4
ZAPDAMTAC0039
25.000,00
2015-08-17
2015-09-20
Nótese como en la tabla del histórico de cambios solo están los campos pertinentes al cambio de precios, y los otros campos de la dimensión, como la descripción del producto no se encuentran en dicha tabla de históricos de precios.
Tipo 6 (SCD 6): Este tipo es una combinación del tipo 1 el tipo 2.  Se implementa igual que el tipo 2, agregando una fila nueva por cada cambio en el campo al que se le desea guardar el histórico de cambios, pero además de esto, se tiene una columna extra en donde se guarda cual es el valor actual.
 
Siguiendo con nuestro ejemplo de la dimensión producto, en donde el productoZAPDAMTAC0039  ha tenido tres precios que son 15.000, 25.000 y 30.000, tendríamos la tabla de productos como sigue:
 
                                                                                 
SK_Producto
Codigo_Producto
Descripcion
Precio
Fecha_Inicio_Vigencia
Fecha_Fin_Vigencia
Precio_actual
1
SANDDAMLUJ0012
Sandalia de Dama de Fiesta
20.000,00
2015-08-02
20.000,00
2
ZAPCABACUER0018
Zapato Caballero Cuero Cerrados
35.000,00
2015-08-02
35.000,00
3
ZAPDAMTAC0039
Zapato Dama Tacón Corrido
15.000,00
2015-08-02
2015-08-17
30.000,00
4
ZAPDAMTAC0039
Zapato Dama Tacón Corrido
25.000,00
2015-08-17
2015-09-20
30.000,00
5
ZAPDAMTAC0039
Zapato Dama Tacón Corrido
30.000,00
2015-09-20
30.000,00
Como podemos observar en nuestro ejemplo, todas las filas del producto ZAPDAMTAC0039, tienen un campo que indica cual es el valor vigente para el precio, que en este caso es 30.000,00.
 
Como podemos ver existen muchas propuestas para manejar el cambio en las dimensiones, cual elijamos implementar, dependerá del caso particular que estemos modelando.

Errores en el proceso de instalación de BigInsights V3.0.0.2


Por Yosely Quintero

En este documento comparto los errores presentados al momento de instalar BigInsights V3.0.0.2, y las soluciones a los mismos, como lo he dicho en documentos anteriores la  clave de una instalación exitosa es cumplir con todos los pre-requisitos y configurar el ambiente donde se realizará la misma de forma correcta, para así evitar inconvenientes que no permitan avanzar hasta finalizar el proceso.
A continuación, la lista de errores que se me presentaron al momento de instalar esta herramienta:
  1. En el bloque de PASSWORDLESS SSH/SUDO
       Error:

          Verify passwordless SSH works for account root  [FAILED]
               
Solución
Se debe configurar de forma correcta la clave con el comando ssh-keygen -t rsa, con el usuario root, así que asegúrese de estar conectado con este usuario en la consola, antes de ejecutar el comando.
  1. En la configuración del archivo sudoers:
        Error:    
   
         Verify requiretty unset and NOPASSWD set in /etc/sudoers [FAILED]
              
               Solución
 En el archivo /etc/sudoers asegúrese de haber comentado la línea de default requirettyy haber agregado la línea con el usuario root que indique que no solicite contraseña como sigue:
root ALL=(ALL) NOPASSWD:ALL
  1. En el bloque CLUSTER ENVIRONMENT CHECKS
Error:
Correct ulimits in /etc/security/limits.conf  [FAILED]
       Solución:
       El archivo debe tener los siguientes limites definidos para los usuarios biadmin y root,   edite el archivo y compare.
*               soft    nofile  65535
*               hard    nofile  65535
*               soft    nproc   65535
*         hard    nproc   65535
root    soft    nproc   65536
root    hard    nproc   65536
# End of file
root    hard    nofile  65536
root    soft    nofile  65536
biadmin hard    nofile  65536
  1. Problemas de sincronización del tiempo
Error:

                 Verify connectivity to time server [FAILED]
Solución: se agregó la línea server 127.0.0.1 # local clock, esto es en el archivo /etc/ntp.conf.
      
  1. Problemas con el registro del host name
Error:
Verify all host names are RFC-1035 valid [FAILED]
Solución:
 Debe asegurarse que el archivo /etc/resolv.conf se vea como la siguiente imagen, es decir que este apuntando al nodo que creamos para la instalación. (search localdomain iicbang.ibm.com).
Vi /etc/resolv.conf
6
 
  1. Verifique que este deshabilitado el SELINUX
        Error:
        Linux not in enforcing mode  [FAILED]
Security-Enhanced Linux (SELinux) : es un módulo de seguridad para el kernel Linux que proporciona el mecanismo para soportar políticas de seguridad para el control de acceso. En este caso de la instalación se debe deshabilitar para que permita instalar el software.
             Solución:
ü  Se ejecuta el comando status, para verificar el estatus que tiene SELINUX.
ü  Si el estatus es enforced, edite el archivo vi  /etc/selinux/config  y coloque en la línea SELINUX=disabled.
ü  Verifique que el cambio se actualizo con el siguiente comando getenforce, y la salida debería ser Disabled.
  1. Al  restaurar la máquina virtual, cambia automáticamente la tarjeta de red y no reconoce la tarjeta configurada para la instalación:
Error:
              Bringing Up Interface Eth0:  Error: No Suitable Device Found: No Device Found for  Connection ‘System Eth0′
             Solución: Vea el siguiente link para solventar el problema y subir los servicios sin  ningún tipo de problemas.
          http://www.uptimemadeeasy.com/vmware/fixing-eth0-mac-address-vmware-clone-restore/

Áreas involucradas en la construcción de un Data Warehouse (DWH)

Por Édgar Barrios 

La construcción de un Data Warehouse siempre es una tarea exigente, por esta razón es muy importante tener bien definido el diseño que se utilizará para la implementación. En este artículo vamos a hablar un poco de cuáles son las áreas (Bases de Datos) que siempre se deben tomar en cuenta al momento de construir un DWH.


·         Fuentes de datos: son todos aquellos repositorios de datos donde se encuentra almacenada la información que maneja la empresa sobre sus operaciones. Puede ser de diversos tipos, por ejemplo, archivos planos, bases de datos, etc.
·         Área de Staging: es una base de datos que debe ser creada con la finalidad de ser un área de aterrizaje de datos sobre la cual se importa toda la información extraída de los orígenes de datos y se llevan a cabo las tareas de transformación de la data. En esta área se debería crear una réplica del modelo de Base de Datos existente en los orígenes de datos, consiguiendo con esto independizar el proceso de transformación y carga de datos, de los sistemas operacionales de la empresa. De igual modo también se deberían crear las tablas definidas como tablas de dimensión, las cuales serán alimentadas por la réplica de las fuentes de datos implementada en esta área.
·         Área de Data Warehouse: Es el área en la cual se carga toda la información en el Data Warehouse diseñado. Aquí deben existir las tablas de dimensión y las tablas facts que fueron definidas. El proceso consiste en comenzar cargando la información en las dimensiones y luego cargar la tabla fact. La fuente de datos para esta área debería ser el área de Staging.
Tener clara la función que cumple cada una de estas áreas es un buen comienzo para poder llevar a cabo la implementación de un DWH de manera exitosa. En futuros artículos hablaremos de forma más detallada acerca de cada una de ellas, donde se profundizará el tema con el apoyo de ejemplos prácticos.

Subrrogates Keys

 Por Rut Almoguera Poggi
¿Te estás iniciando en el desarrollo de ETLs?
¿Quieres saber que es un Surrogate Key y cuáles son las ventajas de su uso?
Si contestaste que SI a estas  preguntas, este post es para ti.
Al inicio, cuando estamos aprendiendo a desarrollar un DataWarehouse, nos enfrentamos con algunos conceptos que nos resultan confusos.  Uno de los que generan más dificultad es el de “Surrogate Key”.
Un “Surrogate Key” o “Clave Surrogada” es una clave que sustituye a la original en las dimensiones de un DataWarehouse.  Es un identificador único que se asigna a cada registro de una tabla de dimensión, y que sería el nuevo “Primary Key” de la tabla de la dimensión. Esta clave, generalmente, no tiene ningún sentido específico de negocio y son siempre de tipo numérico. Preferiblemente un entero auto incremental.
 

 

Veamos un ejemplo para ver claramente como sería un “Surrogate Key” en una dimensión.  Imaginemos que en nuestro sistema fuente tenemos una tabla PRODUCTO, cuyo “Primary Key” es el campo “Codigo_Producto” y con las siguientes filas:
 
Nuestra dimensión de Productos, DIM_PRODUCTO, además de los campos de la tabla PRODUCTO, tendría un campo llamado SK_PRODUCTO, el cual es la “Surrogate Key” y “Primary Key” de la dimensión, la cual quedaría de la siguiente manera:

 

  
El concepto es sencillo, sin embargo podrían surgir las siguientes preguntas:
 ¿Por qué hay que sustituir la clave original de las dimensiones? ¿Acaso la clave que tienen las dimensiones en los diferentes sistemas fuentes NO son suficientemente buenas? ¿Acaso no eran “Primary Keys” en las tablas de donde se están extrayendo y con eso sería suficiente para ser la clave de la dimensión?  La respuesta a estas preguntas es NO.
Algunas de las razones por las que es mejor sustituir la clave del negocio de una dimensión por una “Clave Surrogada” o “Surrogate Key” son las siguientes:
Fuentes heterogéneas: el DWH suele alimentarse de diferentes fuentes, cada una de ellas puede tener sus propias claves, con su propia semántica, inclusive pueden repetirse en diferentes orígenes una misma clave pero que tienen significados diferentes. 
Cambios en las aplicaciones origen: puede ocurrir que cambie la lógica operacional de alguna clave y que el formato ya no sea el mismo en el sistema origen.
Rendimiento: en la base de datos ocupa menos espacio un entero que una cadena. Identificar una ciudad con cinco bytes, o una persona con nueve bytes es un desperdicio considerable de espacio. Además, no solo debe preocuparnos el espacio que ocupa, sino también el tiempo que se invierte en leerlo. Recordemos que las claves subrogadas las llevaremos a las tablas Facts, por lo que cada código es susceptible de repetirse cientos de millones de veces. Por lo tanto, conviene optimizarlo al máximo. Lo mejor es crear entonces claves subrogadas para las dimensiones del Data Mart. 
También se usa para permitir la aplicación del concepto de Slowly Changing Dimension, el cual será explicado en la siguiente entrega.

 

Instalación de BigInsights 3.0.0.2 Pre-requisitos / Tips PARTE II

Por Yosely Quintero
Actividades de Pre-instalación
Ø  Apuntar al repositorio de nuestro ambiente: Se debe tener montado en /media el repositorio, en caso de necesitar instalar algún paquete. Esto se hace desde la imagen de la máquina virtual(o CD de Instalación del sistema operativo, en caso que no sea maquina virtual tu ambiente). En este caso el ambiente es una maquina Virtual donde corre Red hat 6.5.
mount -oloop Nombre_Imagen_maquina_virtual_DVD1.iso /media
    Editamos el archivo de configuración de repostorio
     vi /etc/yum.repos.d/server.repo
     Agregamos las siguientes lineas, y se debe ver como sigue:
       
             

Terminamos de importar el repositorio con los siguientes comandos:
rpm –import /media/*GPG*
yum clean all
Como buena práctica  copiamos  tanto el instalador como la imagen de la máquina  virtual en una carpeta que debemos crear en la raíz. Puede ser /data

Ø  Verificar que estén instalados los siguientes paquetes en nuestro ambiente:
rpm -qa | grep expect
rpm -qa | grep numactl
rpm -qa | grep ksh
Expect: contiene un programa que permite diálogos programados con otros programas interactivos.
Numactl: Se encarga de brindar apoyo a las políticas de acceso a memoria no uniforme (NUMA). Apoya en ejecutar otros programas con una política NUMA específico.
Ksh: es un shell de Unix desarrollado por AT & T Bell Laboratories, que es compatible hacia atrás con el shell Bourne (Bash) e incluye muchas características de la shell C. Necesario para ejecutar tareas en segundo plano.
Si falta alguno de estos paquetes se debe proceder a instalar de la siguiente manera:
yum install expect
yum install numactl
yum install ksh
       
Ø  Seguidamente asegúrese que tiene espacio suficiente en las siguientes rutas, con el siguiente comando: df –h
/ 10GB
/tmp 5GB
/opt 15GB
/var 5GB
/Home 5GB
Ø  En caso de no tener en su máquina un usuario biadmin se recomienda que cree uno, así como también  un grupo de la siguiente manera:
Agregar Grupo:
groupadd biadmin
Agregar el usuario a un grupo:
useradd -g biadmin biadmin
Cambiar la clave al usuario biadmin:
  passwd biadmin
Ø  Se debe agregar el usuario biadmin al grupo de sudoers, para que pueda ejecutar la instalación.Edite el archivo /etc/sudoers con el siguiente comando:
vi  /etc/sudoers
Proceda a comentar la línea Defaults requirety

En el mismo archivo agregue el usuario biadmin como se muestra en la imagen:

Ø  Se edita el archivo /etc/security/limits.d/90-nproc.confy agregue las siguientes líneas. Se debe ver como la siguiente imagen:

       vi /etc/security/limits.d/90-nproc.conf

Ø  Luego edite el archivo /etc/security/limits.conf y agregue las siguientes líneas:

       vi /etc/security/limits.conf

Este proceso continua en la parte III.

Instalación de BigInsights 3.0.0.2 Pre-requisitos / Tips PARTE I

 Por Yosely Quintero
En una entrega de 3 partes, explicaré los Pre-requisitos que se deben cumplir antes de iniciar la instalación de BigInsightsV3.0.0.2, debido a que estos pasos previos son los mas importante del todo proceso de instalación, cumpliendo uno a uno los pasos y tips que compartiré a lo largo de este documento podrá obtener una exitosa instalación de este producto.
Es importante destacar que el ambiente donde realizó las demostraciones que verá a lo largo de este documento es sobre el siguiente ambiente: Maquina virtual con Sistema Operativo: Red Hat Enterprise Linux Server (RHEL) Server 6.5
Pre-requisitos/Tips
Al momento de instalar esta herramienta, es indispensable tener presente las consideraciones, en cuanto a arquitectura, es decir tener definido sobre cuántos nodos se realizará la instalación, y cumplir con los pasos detallados a continuación:
v Arquitectura
Es importante antes de iniciar la instalación definir el tipo de arquitectura sobre la cual se realizara la misma, debido a que el proceso de instalación difiere dependiendo de esto. En este proceso de instalación se hará sobre single node, pero existen otros tipos, como se puede observar en el siguiente link:
v Sotware y Hardware
a.       Software: Solo es compatible con el sistema operativo Linux y se recomiendan las siguientes distribuciones:





b.      Hardware: Se establece un mínimo de memoria, y disco duro libre como se muestra en la siguiente imagen: