En esta sesión, aprenderemos a garantizar un proceso de carga incremental óptimo, en una solución de Bodegas de Datos, con SQL Server Integration Services.

Las bodegas de datos permiten que las organizaciones tomen mejores decisiones con sus datos históricos. A diferencia de un sistema transaccional, las bodegas de datos ofrecen un escenario desnormalizado que garantiza poder consultar de manera más efectiva grandes volúmenes de información.

A continuación, explicaremos algunos conceptos importantes en el diseño de una solución de bodegas de datos, y las mejores prácticas a tener en cuenta cuando se está creando una.

DIMENSIONES

Las dimensiones son el fundamento de un modelo dimensional, ya que describen los objetos a nivel de negocio que se desean analizar (Cliente, Sucursal, Vendedor, Tienda, etc). Las dimensiones son los sutantivos de un sistema de Inteligencia de Negocios, permitiendo describir los eventos medibles de la organización.

image

LLAVES DE NEGOCIO Y SUSTITUTA

La llave de Negocio hace referencia al campo dentro de la dimensión que funciona como clave de acceso, e identificador único del atributo dentro del sistema transaccional. Esta llave es la que se utiliza en los procesos de cargue incremental, para relacionar un hecho con el respectivo atributo de la dimensión.

La llave sustituta, generalmente es un campo autonumérico, que cumple la función de clave principal de la dimensión, y que sirve para establecer la relación de integridad referencial con la tabla de hechos.

image

DIMENSIÓN TIEMPO

Una de las dimensiones obligatorias en cualquier sistema de Bodegas de datos, es la de Tiempo. Dado que la información histórica de la organización es medible a través del tiempo, se hace importante la creación y el cargue de la misma. En este artículo, aprenderán a crear una dimensión Tiempo. AQUÍ

TABLAS DE HECHOS

Cada tabla de Hechos contiene las medidas asociadas con un proceso específico de negocio (ventas por internet, ventas por sucursal, Inventario, Manufactura, etc). Un registro en una tabla de hechos es una medida, y un evento medible puede siempre producir un registro en la tabla de Hechos.

image

Las tablas de hechos por lo general, se componen de columnas con información numérica. Parte de los datos corresponden a los datos medibles del proceso de negocio respectivo. Los otros, corresponden a las llaves sustitutas de las dimensiones con las cuales el proceso se relaciona, mediante integridad referencial.

image

GRANULARIDAD

El nivel de detalle contenido en las tablas de hechos se conoce como granularidad. Es recomendado construir tablas de hechos con el mínimo nivel de detalle que sea posible del sistema transaccional original, el cual generalmente se conoce como el nivel atómico.

MODELO ESTRELLA

Este modelo consiste en contar don dimensiones relacionadas directamente con una tabla de hechos, garantizando relaciones uno-muchos (1:M). Se recomienda fuertemente construir bodegas de datos en SQL Server bajo este modelo, ya que garantiza un mayor rendimiento en el funcionamiento de una solución de Inteligencia de Negocios.

image

MODELO COPO DE NIEVE

En términos simples, un modelo Copo de Nieve se asemeja al Modelo Estrella, salvo que en este, las dimensiones se pueden relacionar con otras tablas de Dimensión. Es decir, aplica cuando se tienen dimensiones que se han re-normalizado.

image

Dado que son dimensiones normalizadas, se recomienda fuertemente sobre SQL Server evitar al máximo el uso de este tipo de modelo.

DIMENSIONES CONFORMADAS

Las dimensiones Conformadas son dimensiones que son compartidas a través de múltiples procesos de Negocio. De esta manera, se evita la duplicidad de la información en la bodega de datos.

 

DIMENSIONES DEGENERADAS

Los identificadores de transacciones a menudo terminan como dimensiones degeneradas, sin necesidad de unirse a una dimensión existente. Por ejemplo, el id de una orden generalmente no se agrega a una dimensión, sino que por el contrario se convierte en un atributo más de una tabla de hechos. Esto es lo que se conoce como dimensión degenerada.

image

 

Hola a todos.

Quiero iniciar esta serie de videos titulada “El poder de los Powers”. El primero de ellos será Power Map; en donde navegaremos esta poderosa herramienta con un análisis de ventass por ciudades y organizaciones en Colombia.

Enjoy!!!

 

El Poder de los Powers–Power Map

SQL Saturday es un evento de entrenamiento para profesionales en SQL Server y también para aquellos que quieren aprender sobre SQL Server. Este evento se desarrollará el 27 de Septiembre de 2014 en la Universidad EAFIT, Carrera 49 N° 7 Sur – 50, Medellín, Colombia. La admisión al evento es gratuita.

Así, quiero compartirles que estaré impartiendo la charla Inteligencia de Negocios Geoespacial. Más adelante estaré compartiendo las memorias de las mismas.

Los esperamos: Inscripciones Aquí

A partir de SQL Server 2012, SSIS permite dos modelos de implementación, el modelo de implementación de paquetes (existente en versiones anteriores), y el modelo de implementación de proyectos.

La nueva opción de implementación de proyectos permite implementar los proyectos como una unidad integral en el servidor de Integration Services, sin necesidad de hacer implementaciones particulares a nivel de paquetes.

Estas son algunas características de un modelo de implementación de Proyectos:

  • El proyecto sería la unidad de Implementación
  • Los parámetros son utilizados para asignar valores a las propiedades del paquete.
  • La extensión de implementación de un proyecto es .ispac.
  • Estos proyectos se implementan en el catálogo SSISDB en una instancia de SQL Server.
  • Requiere integración con el CLR.

 

CREAR EL CATÁLOGO SSISDB

El primer paso es crear el catálogo SSIDB en la instancia de SQL Server (2012 o 2014).

  • En SQL Server Management Studio, conectado a un motor relacional (2012 o 2014), clic derecho en Integration Services Catalogs y Create Catalog.

image

  • Asegúrese de seleccionar la integration con el CLR, y coloque una llave para el cifrado del catálogo. Clic en OK.

image

  • Nuevamente en SSMS, expanda Integration Services Catalogs, clic derecho sobre el catálogo SSISDB y clic en New Folder (En esta carpeta colocaremos un proyecto).

image

  • Coloque un nombre y descripción a la carpeta y clic en OK

image

  • Si desplegamos la carpeta que acabamos de crear, encontraremos 2 carpetas anidadas, Projects y Enviroments. En la primera, se publicarán los diferentes proyectos que se necesiten en esta carpeta (dichos proyectos tendrán sus respectivos paquetes). En la segunda, se crearán los diferentes entornos de ejecución de los paquetes (por ejemplo, entornos de desarrollo, pruebas y producción).

image

 

CÓMO IMPLEMENTAR PROYECTOS

  • Una vez creado el catálogo, pasamos a la etapa de implementar proyectos. Para ello, utilizamos cualquier proyecto que tengamos creado sobre SQL Server Data Tools.

image

  • En Solution Explorer, clic derecho sobre el  Proyecto y clic en Deploy

image

  • En Introduction, Clic en Next.
  • En Select Source, seleccione Project Deployment file, y verifique que la ruta seleccionada es la del archivo con extensión .ispac. Clic en Next

image

  • En Select Destination, escriba la instancia de SQL Server donde fue creado el catálogo. En Path, seleccione la carpeta creada en pasos anteriores. Clic en Next.

image

  • Clic en Deploy.

image

  • Enhorabuena!!! Acaba de implementar su primer proyecto bajo el modelo Project Deployment Model.

image

  • Vaya nuevamente al catálogo de SSISDB, y verifique que el proyecto y los paquetes se hayan creado de manera exitosa.

image

Hola a todos.

Nuestra comunidad hermana ShareCol, tiene el agrado invitarlos a este gran evento, el SharePoint Saturday, que se organizará en Bogotá el día 24 de mayo de 2014, en los auditorios de Cafám Floresta.

Tengo el honor de ser uno de los oradores de este evento, con la charla Inteligencia de Negocios Autoservicio, cómo mejorar su toma de decisiones.

Les comparto algunos banners de este evento y el video promocional.

Info e inscripciones: http://tinyurl.com/ll6zz9v

Comunidad ShareCol en Facebook: http://tinyurl.com/p9bckvm

banner

agenda

SharePoint Saturday

Contamos con un paquete de SQL Server Integration Services, el cual tiene diferentes tareas a ejecutar, como en la siguiente imagen.

image

Durante la ejecución, falla una de las tareas:

image

Supongamos que el problema se detecta y se soluciona. La pregunta a hacernos es, “al volver a ejecutar el paquete, desde donde debería comenzar?” Si la respuesta es “desde la tarea donde se produjo el fallo”, es ahí donde necesitamos del uso de los CheckPoints.

Un punto de comprobación, o CheckPoint, garantiza que un paquete se reinicie desde el punto de fallo de la ejecución de un paquete, y no desde el inicio. El uso de puntos de comprobación garantiza las siguientes ventajas:

  1. Evita repetir procesos de carga y descarga de archivos grandes.
  2. Evita repetir cargas de grandes cantidades de datos.
  3. Evita repetir la agregación de valores previamente ingresados.

 

CÓMO FUNCIONA UN PUNTO DE COMPROBACIÓN

Durante la ejecución de un paquete, si se llegase a presentar un error, el punto de comprobación se encarga de guardar en un archivo de configuración, información tal como el contenedor o tarea que provocó el fallo y del estado de todos los contenedores, valores de parámetros y variables que existan en ese momento y el identificador único del paquete. De esta manera, en la siguiente ejecución, el paquete usará la información de dicho archivo. Si el paquete se ejecuta de manera correcta, dicho archivo se borrará.

CÓMO CONFIGURAR UN PAQUETE PARA QUE SE REINICIE

Es importante configurar 3 propiedades a nivel del paquete:

  • CheckPointFileName: Especifica el nombre del archivo del CheckPoint
  • CheckPointUsage: Especifica si se utilizarán CheckPoints
  • SaveCheckPoints: Especifica si se guardarán CheckPoints. Esta propiedad debe estar en True para poder reiniciar el paquete en un punto de fallo.

Por último, para cada uno de los contenedores en donde deseemos establecer puntos de comprobación, establecemos la propiedad FailPackageOnFailure en True.

La propiedad CheckPointUsage, permite seleccionar los siguientes valores:

  • Never: Indica que nunca usará el archivo de configuración. Por ende, siempre se ejecutará desde el inicio.
  • Always: Indica que siempre se utilizará el archivo de configuración para la ejecución del paquete. Si el archivo no existe, la ejecución genera error.
  • IfExists: Especifica que usará el archivo solo en caso de existir. En caso de no estar, el paquete se ejecutará desde el inicio.

 

Y AHORA…. A PROBARLO!!!

  • Establecemos las propiedades a nivel del  paquete

image

  • Cambiamos la propiedad FailPackageOnFailure a True, en la tarea que falla

image

  • Ejecutamos el paquete para provocar el fallo.

image

  • Solucionamos el error, volvemos a ejecutar el paquete y…. Magia!!!!

image

  • Volvamos a ejecutar el paquete… Este debe comenzar desde el inicio, ya que el archivo se borra tras la ejecución exitosa.

image