GuilleSQL :: Microsoft SQL Server, SSIS, y más !! Votar en los Premios Bitacoras.com a Portal GuilleSQL

Definición de un Modelo de Versionado

Volver a: [Trabajar con tablas versionadas (Fecha Desde y Fecha Hasta) en SQL Server, Slowly Changing Dimension (SCD) Tipo 2]


Este capítulo define un Modelo de Versionado que utilizaremos a lo largo de todo el Artículo, y que facilita el conocimiento y comprensión del funcionamiento de las tablas versionadas (tablas que almacenan históricos de cambios), en particular, de cómo se rellenan sus campos Fecha Desde y Fecha Hasta, tanto para es desarrollo de sistemas operacionales, como para una correcta extracción, transformación y carga de datos (ETL) en entornos de Data Warehouse (DW) y Business Intelligence (BI). También se aprovecha para indicar las diferencias comunes entre Modelos de Versionado diferentes, se hace hincapié en la dependencia que se tiene cara al desarrollo de consultas SQL sobre tablas versionadas, se comentan alternativas de diseño, etc.

A continuación se define un Modelo de Versionado, es decir, un conjunto de reglas que se debe seguir para la implementación del mismo, desde el punto de vista de Ingeniería de Software (Análisis, Diseño y Desarrollo de Software), con el objetivo de poder gestionar tablas que almacenan históricos de cambios. El Modelo de Versionado que a continuación se explica, es el Modelo de Versionado que tomaremos como ejemplo para el desarrollo del resto del Artículo.

El conjunto de criterios o reglas aquí expuesto no es el único posible, es decir, del mismo modo que podemos decidir utilizar estas reglas, es posible utilizar un conjunto de reglas diferentes, incluso en ocasiones, suelen seguirse diferentes reglas de versionado en diferentes tablas (esto siempre dependerá de cómo realicemos nuestro Análisis y Diseño, así como de los requisitos que tengamos impuestos). Evidentemente, siempre será preferible definir un único Modelo de Versionado que sea implementado sobre todas las tablas con versiones de nuestra base de datos. Es decir, dado que en función del Modelo de Versionado que utilicemos deberemos realizar las consultas SQL de nuestras tablas, utilizar diferentes Modelos de Versionado en diferentes tablas puede causar confusión a los desarrolladores que generen erratas en nuestro software (o en nuestro Data Warehouse - DW - , si nuestro cometido es sólo la explotación de dichos datos con fines analíticos - OLAP y Business Intelligence).

Sin más, a continuación se detallan las Reglas de nuestro Modelo de Versionado:

  • Cada fila de una tabla versionada tiene un campo Fecha Desde y un campo Fecha Hasta, ambos obligatorios (NOT NULL), ya que siempre tienen que estar rellenos para poder conocer el periodo de validez de dicha versión. Los campos Fecha Desde y Fecha Hasta almacenarán sólo la Fecha, es decir, no almacenarán información horaria.
  • Fechas especiales: se definirá un valor correspondiente a la menor fecha posible (-infinito) y otro correspondiente a la mayor fecha posible (+infinito). La definición de estos valores, debe ser consecuente con los tipos de datos en que se vayan a utilizar, es decir, que esté en rango. Por ejemplo, los valores 01/01/0001 y 31/12/9999 no se pueden utilizar en SQL Server 2005 o versiones anteriores (tampoco en MySQL), pero por el contrario, si es posible utilizarlos en SQL Server 2008 (y en otros motores como ORACLE, DB2 e Informix).
  • Una versión es válida desde su Fecha Desde (incluida) hasta su Fecha Hasta (excluida) definiendo un intervalo cerrado por la izquierda y abierto por la derecha. Este detalle es especialmente importante, ya que otros Modelos de Versionado podrían tomar como inclusive la Fecha Hasta (es decir, formar un intervalo cerrado por la izquierda y cerrado por la derecha), de tal modo, que en función de cómo se rellene la Fecha Desde y la Fecha Hasta, deberemos construir una cláusula WHERE u otra en nuestras consultas SQL (SELECT, UPDATE, etc.) para conseguir el resultado deseado.
  • Para cada valor de negocio (ej: para cada cliente), todas las versiones definirán un conjunto de intervalos continuo. Otro detalle importante, ya que en otro Modelo de Versionado se podrían permitir intervalos discontinuos, es decir, para el Cliente A tener una versión del 01/01/2004 a 01/01/2005 y otra del 01/01/2006 al 31/12/9999 (por poner un ejemplo), existiendo un hueco entre el 01/01/2005 al 01/01/2006. En nuestro caso, esto no será posible.
  • Aunque la mayoría de los cambios pueden generar nueva versión, pueden existir cambios que no generen nueva versión, porque no tenga sentido. Por ejemplo, en una tabla de gestión de usuario el cambio de la dirección de correo de un usuario podría generar una nueva versión, y sin embargo el cambio de la Fecha de último logon podría no generar nueva versión si se considera que no tiene relevancia el estudio de sus cambios a lo largo del tiempo (o si se pudiera obtener dicho dato de otra tabla). Esta es una cuestión funcional que debe analizarse en cada caso por separado (y documentarse, claro ;-)
  • Al dar el alta de una nueva entidad en una tabla versionada, se creará una fila con Fecha Desde informada (habitualmente a la Fecha del sistema) y Fecha Hasta establecida a +infinito (ej: 31/12/9999).
    Puede ser interesante crear la fila con Fecha Desde a una Fecha anterior a la Fecha del sistema, con el objetivo de conseguir un efecto retroactivo. Del mismo modo, puede ser interesante crear la fila con Fecha Desde posterior a la Fecha del sistema, por ejemplo porque estemos dando de alta unos valores de forma anticipada, los cuales tendrán sentido en un momento posterior en el tiempo.
    En cualquier caso, como se comenta más adelante en este Artículo, en ocasiones resulta de utilidad utilizar campos de Fechas adicionales como los campos Fecha Alta y Fecha Baja.
  • Al modificar una entidad en una tabla versionada, se modificará la Fecha Hasta de la última versión existente (ej: de +infinito – 31/12/9999 – a la Fecha del sistema) y se creará una nueva fila, con Fecha Desde a la Fecha del sistema, y Fecha Hasta establecida a +infinito (ej: 31/12/9999).
  • La realización de múltiples cambios en el mismo día que impliquen generar nueva versión generará múltiples filas (múltiples versiones). Por lo tanto, si realizamos varios cambios en el mismo día, se obtendrán los siguientes resultados.

    • La primera versión con Fecha Desde igual al Fecha Hasta de la última versión existente y Fecha Hasta al día del cambio, es decir, se tratará de una versión cerrada (Fecha Hasta diferente de +infinito) con Fecha Desde < Fecha Hasta (ojo, estrictamente menor… nada de menor o igual… estrictamente menor).
      Si no existen versiones anteriores, entonces se establecerá Fecha Desde también al día del cambio, es decir, se tratará de una versión cerrada donde los campos Fecha Desde y Fecha Hasta tendrán el mismo valor.
    • Las versiones intermedias con Fecha Desde y Fecha Hasta al día del cambio, es decir, se tratará de una versión cerrada donde Fecha Desde y Fecha Hasta almacenarán el mismo valor.
    • La última versión con Fecha Desde al día del cambio, y Fecha Hasta a +infinito (ej: 31/12/9999), por lo tanto, se tratará de una versión abierta.

    Teniendo en cuenta los criterios antes comentados, en especial, que una versión es válida desde su Fecha Desde (incluida) hasta su Fecha Hasta (excluida), y que no se almacenará información horaria en estos campos, ocurre que todas la versiones con Fecha Desde igual a Fecha Hasta quedarán descartadas, es decir, estas versiones quedarán deshabilitadas de forma implícita. Esto es más que evidentemente, pues realmente serán válidas en un periodo de tiempo de duración cero (conjunto vacio, osea, nones).

    Este comportamiento, es el que he decidido tomar como criterio. Es importante tener en cuenta que existen desarrollos en mercado que mantienen éste comportamiento, mientras otros prefieren alternativas como no generar múltiples versiones para cambios en el mismo día. Es decir, al hacer un cambio genero una nueva versión que estará abierta (Fecha Hasta a +infinito), de tal modo, que sucesivos cambios en el mismo día, no generarán nuevas versiones, sino que por el contrario actualizarán esta versión. También existen desarrollos en mercado, que utilizan un criterio u otro en función de que tabla se trate (pa gustos hay versiones... digo colores ;-).

    En cualquier caso, lo importante es tener claro qué criterio se está utilizando en cada tabla, ya que en función de cómo se gestione esta problemática, varía la forma de desarrollar las consultas SQL de base de datos (ej: comprobar solapamiento de versiones) o de gestionar la propia tabla (ej: generación de índices únicos).

    El motivo por el que prefiero generar múltiples versiones para cambios en el mismo día, es porque me permite almacenar un histórico de cambios. De este modo, nunca se pierde información.

Con todo esto, habremos definido un conjunto de reglas suficiente para la definición de nuestro Modelo de Versionado.

Resulta de gran importancia, haber entendido correctamente todas las reglas anteriores antes de continuar con la lectura de éste Artículo (si no ha sido así, mi recomendación es realizar una nueva lectura de éste capítulo antes de continuar, vale la pena...). Es decir, dado que dichas reglas definen cómo se van a almacenar los datos en nuestras tablas, si no tenemos un conocimiento claro del contenido de nuestras tablas ¿Cómo vamos a ser capaces de consultarlas correctamente?

Cabe destacar, que en el Modelo de Versionado aquí propuesto se utiliza una única tabla para almacenar la información actual (versiones abiertas) y la información histórica (versiones cerradas). Bueno, esto es una forma de hacerlo, igual que en otros Modelos de Versionado que utilicen una única tabla para versiones actuales e históricas, se podría definir una política diferente para rellenar los campos Fecha Desde y Fecha Hasta. Pero dónde quiero llegar es a otro punto, es decir, existen Modelos de Versionado que utilizan una tabla con la información actual, y otra tabla con la información histórica, incluso en ocasiones se implementan Triggers (disparadores) sobre las tablas actuales, para que al modificar o insertar datos sobre las mismas, se rellene de forma automática las tablas históricas, generándose así los datos históricos. Una diferencia destacable de utilizar dos tablas (es decir, una tabla con las versiones actuales, y otra tabla con las versiones históricas), es que resulta más fácil crear claves únicas sobre la tabla actual, pudiendo utilizar (salvo excepciones) la Clave de Negocio (Business Key o BK) como campo único (eso sí, en la tabla con datos históricos, volveríamos a las andadas ;-)

También es interesante resaltar el detalle de que en el Modelo de Versionado aquí descrito se utilizan dos Fechas (Fecha Desde y Fecha Hasta), ya que en otros Modelos de Versionados se utilizan una única fecha (la Fecha Desde), de forma que la Fecha Hasta se podría inferir de la Fecha Desde de la siguiente versión. Personalmente me parece mucho más cómodo utilizar dos fechas (Fecha Desde y Fecha Hasta), pudiendo así simplificar las consultas SQL sobre las tablas versionadas.

Comprendido todo esto, vamos al siguiente paso...

Volver a: [Trabajar con tablas versionadas (Fecha Desde y Fecha Hasta) en SQL Server, Slowly Changing Dimension (SCD) Tipo 2]




Miembros de
Miembros de GITCA (Global IT Community Association)

Menu de Usuario
  Iniciar Sesión
  Registrarse
  Restablecer Contraseña
  Ventajas de Registrarse

Acerca de
  Contigo desde Oct 2007
  623 usuarios registrados
  86146 pageloads/mes
  Ranking Alexa 498160



Archivo

Junio de 2012 (1)
Mayo de 2012 (2)
Abril de 2012 (7)
Marzo de 2012 (16)
Febrero de 2012 (9)
Enero de 2012 (5)
Diciembre de 2011 (10)
Noviembre de 2011 (10)
Octubre de 2011 (4)
Septiembre de 2011 (5)
Agosto de 2011 (2)
Julio de 2011 (2)
Junio de 2011 (4)
Mayo de 2011 (2)
Abril de 2011 (6)
Marzo de 2011 (4)
Febrero de 2011 (10)
Enero de 2011 (5)
Diciembre de 2010 (6)
Noviembre de 2010 (4)
Octubre de 2010 (8)
Septiembre de 2010 (4)
Agosto de 2010 (1)
Julio de 2010 (3)
Mayo de 2010 (5)
Abril de 2010 (6)
Marzo de 2010 (8)
Febrero de 2010 (3)
Enero de 2010 (1)
Diciembre de 2009 (9)
Noviembre de 2009 (14)
Octubre de 2009 (2)
Septiembre de 2009 (8)
Agosto de 2009 (2)
Julio de 2009 (10)
Junio de 2009 (9)
Mayo de 2009 (10)
Abril de 2009 (9)
Marzo de 2009 (3)
Febrero de 2009 (2)
Enero de 2009 (3)
Noviembre de 2008 (2)
Octubre de 2008 (2)
Septiembre de 2008 (2)
Agosto de 2008 (5)
Julio de 2008 (5)
Junio de 2008 (1)
Mayo de 2008 (3)
Abril de 2008 (2)
Marzo de 2008 (2)
Febrero de 2008 (2)
Enero de 2008 (5)
Noviembre de 2007 (2)
Octubre de 2007 (2)






Copyright © 2007 GuilleSQL, todos los derechos reservados.