SQL Server, ideas y experiencias

Truco para diseñar una dimensión tiempo de un Data Warehouse

por Jose Mariano Alvarez 18. noviembre 2010

CalendarioLa dimensión de tiempo existe habitualmente en cada data warehouse y la granularidad más usada es el día. Generalmente tiene muchos atributos pero solo algunos de estos atributos como por ejemplo el nombre del mes y el año pueden ser obtenidos fácilmente usando una expresión SQL aplicada a la fecha. Si la dimensión tiene atributos para dar soporte a múltiples lenguajes resulta a veces complicado construirla con el lenguaje SQL. Otros atributos no se pueden obtener mediante SQL ya que no hay mecanismos predecibles y dependen de decisiones humanas.

Otra característica de la dimensión tiempo es que suele tener muchos atributos como por ejemplo marcas de días feriados o no laborables, atributos de períodos fiscales o de temporadas, atributos relacionados a la fecha como el número de semana, la marca de último día del mes, y otros atributos muy útiles usados especialmente para la navegación y que deben estar integrados en la dimensión fecha mediante atributos dimensionales.

La gran ventaja de esta dimensión es que está completamente definida y especificada desde el inicio del proyecto del data warehouse. Pero la desventaja es que no tiene una fuente de datos convencional sino que se suele generar mediante algún mecanismo como una planilla o tabla cargada manualmente o mediante algún proceso.

La clave de la dimensión fecha

Todas las dimensiones fecha necesitan un atributo que representa a la fecha y un atributo para relacionar con la tabla de hechos. Debe haber al menos un registro que permita representar situaciones especiales como una fecha no aplicable o no informada o que no ha ocurrido aún y además es posible que desee distinguir varias de estas condiciones inusuales.

En estos casos en que se deben representar hechos relacionados a estas “fechas especiales”, las referencias foreign key en la tabla de hechos deben permitir referenciar a estos registros con “fechas inusuales” en la tabla de la dimensión fecha. Recordemos que el valor de estos atributos en los campos de la tabla de hechos no puede ser nulo, ya que debe estar relacionado con la tabla de la dimensión tiempo.

La clave principal de la dimensión fecha ideal debería ser una clave subrogada sin representación semántica, como por ejemplo un numero entero (que no representa una fecha), pero muchos diseñadores no pueden resistir la tentación de hacer que la clave sea legible como por ejemplo 20101116 significando el 16 de noviembre de 2010. Sin embargo, como con todas las claves inteligentes, los pocos registros especiales en la dimensión fecha harán que el diseñador utilice trucos para representarlas. Por ejemplo, la clave inteligente para una fecha “no aplicable” tendría que ser un valor sin sentido como por ejemplo 99999999, y esto trae aparejado que las aplicaciones que tratan de interpretar la fecha directamente para obtener información (como por ejemplo el mes) sin usar los atributos de la dimensión tengan inconvenientes porque no es una fecha válida.

Conclusión

En definitiva utilizar un tipo de dato fecha para el atributo clave de la dimensión fecha no es una buena elección y conviene que el valor este subrogado utilizando una clave entera que está oculto al usuario dentro de la meta data. El atributo representativo de la fecha debe ser un atributo que acepte representaciones especiales y no solamente representación de fechas válidas.

Referencia:

[PDF] Kimball Design Tip #51: Latest Thinking On Time Dimension Tables
http://www.rkimball.com/html/designtipsPDF/KimballDT51LatestThinking.pdf

Tags: ,

Ideas y nociones | Artículos

SQL Server Service Broker - Mensajería asincrónica desde la base de datos

por Jose Mariano Alvarez 28. julio 2009

El SQL Service Service Broker incluye la infraestructura necesaria para la programación asincrónica y se puede utilizar para la creación de aplicaciones distribuidas a través de múltiples bases de datos. Hace ya un tiempo que vengo hablando con algunos colegas respecto de los beneficios que nos ofrece el Service Bróker sobre todo cuando se necesita realizar el procesamiento de forma asincrónica o se necesita distribuir el procesamiento entre varios equipos.

Entre los beneficios que nos ofrece el Service bróker tenemos:

  • La integración de bases de datos.
  • Ordenación y coordinación de mensajes.
  • El acoplamiento flexible de las aplicaciones.
  • El bloqueo de mensajes relacionados.
  • La activación automática.

Para ver el detalle de estos conceptos pueden visitar:

Ventajas de Service Broker

Algunos ejemplos de uso del Service bróker pueden ser:

  • Desencadenadores asincrónicos
  • Procesamiento confiable de consultas
  • Recopilación confiable de datos
  • Procesamiento distribuido en el servidor para aplicaciones cliente
  • Consolidación de datos para aplicaciones cliente
  • Procesamiento por lotes a gran escala

 

Para ver el detalle de estos conceptos pueden visitar:

Usos habituales de Service Broker

 

Motivación

Ayer mismo estuvimos hablando de las posibilidades de usarlo en una reunión de trabajo con un grupo de arquitectos y desarrolladores. Luego me puse a buscar algo de información al respecto para respaldar mis afirmaciones y encontré este caso de éxito.

Les resumo parte de lo que pueden ver en el documento (en inglés) que pueden encontrar en el siguiente Link:

MySpace Uses SQL Server Service Broker to Protect Integrity of 1 Petabyte of Data

 

Resumen del caso de éxito en el uso del Service Broker

MySpace decidió que la mejor manera de manejar el constante crecimiento de sus bases de datos relacionales, que actualmente suman más de 1 petabyte, era escalar horizontal mente y dividir la información a través de múltiples instancias de SQL Server. Para ayudar a garantizar la integridad de los datos mientras se mantiene picos de demanda de servicio de hasta 4,4 millones de usuarios simultáneos, se necesitaba una solución eficiente de mensajería asincrónica entre sus 440 instancias de SQL Server y más de 1000 bases de datos.

MySpace creó una solución para que actúa como punto de coordinación para la entrega de mensajes a través de sus bases de datos distribuidas. La solución trabaja en un modelo de broadcast en la que el despachador de servicios asegura que un cambio originario de una base de datos se entrega al grupo de bases de datos destino relevante para la transaccion mediante la utilización del Service Broker, lo que ha permitido a MySpace realizar la gestión de claves foráneas a través de sus 440 servidores de bases de datos, la activación y desactivación de cuentas de sus millones de usuarios.

MySpace también utiliza Service Broker administrativa para distribuir los nuevos procedimientos almacenados y otras actualizaciones en todos los 440 servidores de bases de datos a través del despachador que crearon.

Tags:

Ideas y nociones

Powered by SQL Total Consulting


View Jose Mariano Alvarez's profile on LinkedIn

 Add to Technorati Favorites 

Calendar

<<  mayo 2017  >>
lumamijuvido
24252627282930
1234567
891011121314
15161718192021
22232425262728
2930311234

View posts in large calendar

Locations of visitors to this page

Widget Twitter not found.

Root element is missing.X


Valid XHTML 1.0 Transitional

Valid CSS!