Category Archives: Artículo

Artículo: Buenas prácticas en diseño de Bodegas de datos

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

 

Advertisements

Leave a comment

Filed under Alberto Rivera, Artículo, SQL Server 2014

Artículo: Mapas de Colombia en Power View

clip_image007

Uno de los escenarios más interesantes en Power View es la visualización geográfica. Esta visualización se realiza utilizando la tecnología de Bing Maps.

En este artículo, Andreí Garzón nos explica cómo construir mapas de Colombia en Power View.

VER ARTÍCULO AQUÍ

Leave a comment

Filed under Andreí Garzón, Artículo, SharePoint Server 2013, SQL Server 2014

Conociendo el nuevo modelo de Implementación (Project Deployment Model) de SQL Server Integration Services

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

Leave a comment

Filed under Alberto Rivera, Artículo, SQL Server 2012, SQL Server 2014

Artículo: CheckPoints en SQL Server Integration Services

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

Leave a comment

Filed under Alberto Rivera, Artículo, SQL Server 2014

Tableros de control con Power View

Hola a todos.

Nuestro amigo Andrei Garzón nos comparte este artículo donde se presenta la forma de crear tableros de control en SharePoint utilizando Power View

Leave a comment

Filed under Andreí Garzón, Artículo, SharePoint Server 2013, SQL Server 2012

Crear y poblar una dimensión de Fechas en SQL Server 2012

En un sistema de Bodegas de Datos, una de las tablas más importantes y que siempre se encuentra presente es la dimensión Fecha, ya que con esta, estamos en la capacidad de medir en el tiempo, la historia de nuestro sistema para poder realizar análisis sobre los datos.

A continuación, aprenderemos a crear y poblar una bodega de datos en SQL Server 2012.

 

Nuestro amigo, Alberto Rivera, nos comparte el siguiente artículo: Aquí

Leave a comment

Filed under Alberto Rivera, Artículo, SQL Server 2012

ARTÍCULO: DATA TAPS (DERIVACIONES DE DATOS) EN SSIS 2012

Nuestro amigo Andreí, nos comparte el siguiente artículo: Una de las nuevas capacidades de SSIS en SQL Server 2012 es la posibilidad de visualizar los datos que pasan por los flujos de datos cuando estamos en producción. 

image

Aprende con este artículo, la manera en la que los Data taps, nos ayudan a conseguir este objetivo:

Para ver el artículo CLIC AQUÍ

Leave a comment

Filed under Andreí Garzón, Artículo, SQL Server 2012