CLAVES SUBROGADAS

Las Claves Subrogadas (Surrogate Keys) es un concepto muy utilizado en el diseo de bases de datos, especialmente en entornos de Data Warehouse (DW) y Business Intelligence (BI). Las Clave Subrogadas suelen utilizarse especialmente en tablas de dimensin versionadas o histricas, conocidas como Slowly Changing Dimension (SCD) de tipo 2, es decir, tablas de dimensin que almacenan tanto los datos actuales (versin actual) como los datos histricos (versiones antiguas). El concepto de Clave Subrogada no es nico de SQL Server, es decir, las Claves Subrogadas son un concepto general que puede aplicarse a cualquier motor de base de datos (ORACLE, IBM DB2, IBM Informix, MySQL, etc). Sin embargo, antes de poder continuar estudiando el concepto de Clave Subrogada, es importante introducir el concepto de Clave de Negocio y de Tablas Versionadas o Histricas (Slowly Changing Dimension de tipo 2 - SCD Type 2). CLAVE DE NEGOCIO
( B U SI N E S S K E Y )

La mayora de las tablas de base de datos con que trabajamos, utilizan un campo como clave de acceso, el cual identificar de forma inequvoca a un elemento de negocio, y que en muchos casos tiene significado por s mismo. Pongamos algunos ejemplos: y y y y Si estuviramos hablando de una tabla que almacena Plizas, la Clave de Negocio podra ser el Nmero de Pliza (un valor nico para cada Pliza, que tiene significado por s mismo). Si estuviramos hablando de una tabla que almacena vehculos, la Clave de Negocio podra ser la matrcula (o quizs el nmero de bastidor). Si estuviramos hablando de una tabla que almacena productos comerciales, la Clave de Negocio podra ser el cdigo EAN-13. Si estuviramos hablando de una tabla de facturas, la Clave de Negocio podra ser la composicin del Ao de Factura y el Nmero de Factura.

En un principio, podramos pensar que la Clave de Negocio contiene un valor nico para cada fila de la base de datos, sin embargo, el hecho de trabajar con Tablas Versionadas o Histricas (Slowly Changing Dimension de Tipo 2) impide que sea as. TABLA VERSIONADA O HISTRICA
( SC D- 2 SL O W L Y CH A N G IN G D IM E N S IO N DE TI PO 2 )

Habitualmente nos encontraremos con tablas de base de datos, para las cuales es posible que se produzcan modificaciones sobre sus datos a lo largo del tiempo, y adems es necesario poder realizar un seguimiento de sus cambios a lo largo del tiempo. En entornos de Data Warehouse (DW) y Business Intelligence (BI), este tipo de tablas suelen tratarse de tablas de Dimensin, a las cuales se las denomina Tablas Slowly Changing Dimensions (SCD) o Tablas SCD. En las bases de datos operacionales (OLTP), este tipo de tablas (tablas versionadas) pueden modelarse de diferentes formas (ej: utilizar dos tablas, una para las versiones actuales y otra para las versiones histricas), aunque existen sistemas de gestin que modelan las tablas versionadas del mismo modo que se hace en un Data Warehouse. Existen diferentes tipos de tablas Slowly Changing Dimension (SCD), en funcin de cmo se gestionen los cambios sobre los datos de dichas tablas. Principalmente, se pueden identificar los siguientes tipos de tablas Slowly Changing Dimensions (SCD):

SCD Tipo 1. Los cambios sobre los datos de la tabla, son implementados con sentencias UPDATE, de tal modo, que no se puede realizar un seguimiento de cambios, aunque si resulta posible que dichos cambios se produzcan. En entornos de Data Warehouse en condiciones, las tablas SCD slo se implementan en aquellos casos que el seguimiento de cambios no es relevante y/o no es frecuente, pues en caso contrario se suele utilizar tablas SCD de Tipo 2 (es lo suyo). SCD Tipo 2 (Tablas Versionadas). Los cambios sobre los datos de la tabla, son implementados con sentencias INSERT, es decir, manteniendo mltiples filas en la tabla para cada Clave de Negocio, de las cuales slo una ser la fila actual. En este caso, si es posible realizar un seguimiento de cambios ilimitado, pues podremos insertar ilimitadas filas (salvo que nos quedemos sin espacio en disco, claro ;-). En la prctica, es bastante habitual encontrarse con tablas SCD de Tipo 2. SCD Tipo 3. Los cambios sobre los datos de la tabla, son implementados agregando nuevos campos a la tabla, de tal modo que para un campo que pueda cambiar, se pueda utilizar un campo para el valor actual y otro campo para el valor anterior. En este caso, no se utilizan mltiples filas, aunque por el contrario se utilizarn mltiples campos. En consecuencia, es posible realizar un seguimiento limitado de los cambios, y dicho lmite ser impuesto por el nmero de campos utilizados para el seguimiento de cambios. En la prctica, es poco habitual encontrarse con tablas SCD de Tipo 3.

Volviendo al ejemplo de las Plizas, para una empresa de seguros resultar vital poder realizar un seguimiento de una Pliza a lo largo de toda su historia, incluyendo todos los cambios sufridos a lo largo del tiempo sobre todas sus caractersticas (Tomador, Riesgos, Garantas contratadas, Capital Asegurado, etc.). Pero Cmo podemos conseguirlo? Existen diferentes alternativas para implementar esta funcionalidad en el OLTP, como por ejemplo, siempre que se realiza un cambio sobre la tabla, en vez de realizar un UPDATE (en cuyo caso perderamos la informacin original), se podra hacer un INSERT con la informacin ms actual (esto es algo ms complicado, pero quiero explicarlo as por fines didcticos), almacenando en cada fila (es decir, en cada versin) el periodo de tiempo para el cul es vlida la informacin de dicha fila de la base de datos (por ejemplo, incluyendo dos campos Fecha Desde y Fecha Hasta en la tabla). Evidentemente, estamos hablando de una tabla de Slowly Changing Dimension (SCD) de Tipo 2. En consecuencia, ya no podremos definir la Clave de Negocio como un campo nico, ya que pueden existir mltiples filas (es decir, mltiples versiones, tanto la actual como una o varias versiones histricas) con el mismo valor de la Clave de Negocio (Business Key). Claro est que no todas las tablas son susceptibles de convertirse a Tablas Versionadas (tablas SCD de Tipo 2), pero an as, esta es una prctica muy habitual en entornos de aplicaciones empresariales y en entornos de Data Warehouse (DW) y Business Intelligence (BI). CLAVE SUBROGADA
( SU R R O G A T E K E Y )

Una Clave Subrogada es un campo numrico de una tabla cuyo nico requisito es almacenar un valor numrico nico para cada fila de la tabla, actuando como una clave sustituta, de forma totalmente independiente a los datos de negocio, que habitualmente no tiene significado por s misma. En consecuencia, es posible crear una Clave Subrogada en cualquier tabla (se trate de una Tabla Versionada o no), aunque habitualmente resultan especialmente tiles al trabajar con Tablas Versionadas SCD de Tipo 2. Algunos consultores de Business Intelligence (BI) recomiendan que en los Data Warehouse absolutamente todas las tablas tengan Claves Subrogadas, y en consecuencia la unin entre todas las tablas del Data Warehouse se realice siempre utilizando las Claves Subrogadas (es decir, autonumricos o IDENTITYs). Yo personalmente no estoy totalmente de acuerdo con dicha afirmacin (al menos con tal rigurosidad), ya que las Claves de Negocio ser necesario mantenerlas en muchos casos (para incluirla en Reports o acciones de Drillthrough por requisitos de los Usuarios, para facilitar comprobaciones de datos entre el Data Warehouse y las fuentes origen de datos, etc.) y adems la

utilizacin de autonumricos (IDENTITYs) en SQL Server en algunos casos resulta un poco ms laborioso de lo deseable. Por ello, bajo mi opinin resulta de gran inters analizar cada caso por separado y tomar la decisin ms ventajosa. Por ejemplo, con tablas versionadas puede evaluarse la posibilidad de utilizar Claves Subrogadas o quizs utilizar claves compuestas o concatenaciones de varios campos. Por el contrario, con tablas sin versionado (ej: tablas SCD de Tipo 1) puede plantearse la utilizacin de la Clave de Negocio (Business Key) exclusivamente. Un ejemplo de utilizacin de Claves Subrogadas sobre tablas no versionadas, es el caso de la denormalizacin. Es decir, si tenemos una tabla en la cual almacenamos una descripcin que se repite para muchas filas, es posible crear una nueva tabla que almacene los diferentes valores para dicha descripcin asociados a un valor numrico nico, y en la tabla inicial sustituir dicha descripcin por el valor numrico asociado. Con esto habremos obtenido un menor tamao de almacenamiento, y una indexacin ms ptima (es preferible indexar datos numricos que datos texto de gran longitud). Un ejemplo de utilizacin de Claves Subrogadas sobre tablas versionadas de un Data Warehouse (DW), es el caso de tener una Tabla de Dimensin Versionada (es decir, una tabla Slowly Changing Dimension de Tipo 2) como pueda ser nuestro ejemplo de Plizas, en la cual almacenamos el Capital Asegurado de la Pliza, la Provincia del Tomador, y otros datos asociados a la Pliza que pueden cambiar con el tiempo, y que en cada cambio generarn una nueva fila (es decir, una nueva versin) en la tabla de Plizas. De este modo, podemos tener una o varias tablas de hechos, como podra ser el ejemplo de Siniestros de las Plizas o de Pagos de las Primas, pudiendo ahora asociar las tablas de hechos con las Dimensiones (en particular, con la Dimensin Pliza) a travs de la Clave Subrogada. Esto nos permitir poder asociar a cada Siniestro y/o a cada Prima (los ejemplos tomados), la versin correspondiente de la Pliza a la fecha correspondiente (ej: fecha de siniestro o fecha de prima). Cara al diseo y construccin de nuestro modelo multidimensional (OLAP), como sera el caso del diseo y construccin de un Cubo de Analysis Services (SSAS), en la Dimensin Pliza mantendremos oculto el atributo correspondiente a la Clave Subrogada, construyendo las Jerarquas deseada para dicha Dimensin Pliza empleando los atributos deseados (ej: N Pliza, Provincia del Tomador, etc.). CREAR UNA CLAVE SUBROGADA El caso habitual y natural de creacin de una Clave Subrogada es la utilizacin de campos autonumricos, como es el caso de los campo IDENTITY de SQL Server (este tipo de campos, si que cumple el requisito de no tener significado por s mismos jeje ;-). La teora dice que una Clave Subrogada est formada por un nico campo numrico, es decir, se debe evitar la creacin de claves compuestas. Adems, las Claves Subrogadas deben ser independientes de los datos de negocio (algo que tambin cumplen los datos autonumricos). De hecho, algunos consultores de BI recomiendan que las Claves Subrogadas no se creen como un nico campo fruto de concatenaciones de mltiples claves de negocio. Una vez ms llevo la contraria (desde mi ignorancia), pues en ocasiones los campos autonumricos pueden ofrecer grandes ventajas, pero en el caso de un Data Warehouse con complicados procesos de carga que pueden sufrir complejos cambios de diseo con bastante periodicidad, basar las uniones de todas las tablas en campos autonumricos implica un mayor coste de mantenimiento, y plantearse la eliminacin de las Claves de Negocio en el Data Warehouse podra considerarse incluso una aberracin (insisto, bajo mi opinin). Por ello, como siempre, mi recomendacin ser estudiar cada caso por separado, dotando de autonumricos cuando nos resulte ventajoso, y utilizando otras alternativas (concatenaciones de campos o claves compuestas) cuando su utilizacin nos resulte de inters.

TRABAJAR CON TABLAS DE VERSIONES DE DATOS.

A continuacin se describe con suficiente detalle, el funcionamiento de las tablas versionadas, es decir, aquellas tablas que utilizan campos Fecha Desde y Fecha Hasta para conseguir almacenar las diferentes versiones (histrico) de los datos a lo largo del tiempo. Este tipo de tablas, son conocidas en los entornos de Data Warehouse (DW) y Business Intelligence (BI), como Slowly Changing Dimensions (SCD) de tipo 2. El problema de trabajar con versiones de datos, tiene dos principales alcances: y Por un lado, el Anlisis, Diseo y Desarrollo de Software de Gestin, debido a que sta es una prctica muy habitual en aplicaciones de ste tipo (ERPs, CRMs, etc.), por la necesidad de almacenar y gestionar en bases de datos relacionales la informacin y su evolucin a lo largo del tiempo. Aunque no toda la informacin es susceptible de ser versionada, gran parte de la informacin almacenada en las aplicaciones de gestin sufre cambios de estado a lo largo del tiempo, que pueden resultar de necesario seguimiento (y en consecuencia, son etiquetados con campos Fecha Desde y Fecha Hasta para conocer el periodo de validez del dato). En caso contrario, estaramos perdiendo informacin. Por otro lado, la Consulta, Extraccin y Transformacin de tablas versionadas en entornos de Business Intelligence (BI) y Data Warehousing (DW), por la sencilla razn, de que si nuestros sistemas transaccionales almacenan los datos versionados, evidentemente nuestros sistemas analticos debern consumir (consultar, extraer o cargar, y transformar) los datos versionados (etiquetados con Fecha Desde y Fecha Hasta) para un fcil interpretacin por parte de sus usuarios (Directivos y Mandos Intermedios). En consecuencia, nuestros procesos de extraccin, transformacin y carga de datos (ETL) realizarn intensivas transformaciones sobre tablas versionadas, y nuestros sistemas analticos (OLAP y Reporting) consumirn intensivamente este tipo de tablas. A lo largo de los diferentes captulos, se utilizar el ejemplo bancario de las Cuentas Corrientes y los Titulares (se presentar con ms detalle ms adelante), con el fin de que al utilizar un mismo ejemplo para los distintos aspectos tratados, se facilite la comprensin de estos contenidos (al menos, lo he hecho con esta intencin).
DEFINICIN DE UN MODELO DE VER SIONADO.

Este captulo define un Modelo de Versionado que utilizaremos a lo largo de todo el artculo, y que facilita el conocimiento y comprensin del funcionamiento de las tablas versionadas (tablas que almacenan histricos de cambios), en particular, de cmo se rellenan sus campos Fecha Desde y Fecha Hasta, tanto para el desarrollo de sistemas operacionales, como para una correcta extraccin, transformacin y carga de datos (ETL) en entornos de Data Warehouse (DW) y Business Intelligence (BI). Tambin 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 diseo, etc.
EL VER SIONADO ( F E C H A D E S D E Y F E C H A H A ST A ) Y O T R A S F E C H A S R E L A C I O N A DA S (FECHA ALTA, FECHA BAJA, FECHA C R E A C I N O T I M E S T A M P , E T C .)

A continuacin se describen otros campos de tipo Fecha tambin relacionados con el Versionado (Fecha Desde y Fecha Hasta) que muy habitualmente nos encontraremos en tablas versionadas: Fecha Hora de Creacin (Timestamp), Fecha Hora de Actualizacin,

Fecha Alta y Fecha Baja, son quizs los campos de tipo Fecha que ms habitualmente nos podremos encontrar en tablas versionadas. Su conocimiento y comprensin son vitales, debido a que pueden afectar al desarrollo de consultas SQL sobre tablas versionadas, en funcin de cul sea el dato que deseemos obtener, y qu campos posea la tabla versionada.
R A N GO S D E F E C H A S V L I D O S Y T I P O S D E DAT OS DE FECHA Y/O HOR A

Al trabajar con tablas versionadas (Fecha Desde y Fecha Hasta) y con distintos motores de base de datos, resulta especialmente importante conocer las caractersticas de los tipos de dato Fecha que disponemos: Almacenan slo Fecha o Fecha y Hora? Qu Fechas mnima y mxima permite almacenar cada tipo de dato? Con qu precisin se almacena la informacin horaria? Qu calendario se utiliza: Calendario Juliano o Calendario Gregoriano? Qu precisin y rangos de Fecha y Hora soportan SQL Server, Access, My SQL, ORACLE, o DB2 en sus tipos de datos de Fecha y/o Hora?
EL GRFICO DE LNEA DE T IEMPO (T IME LINE) , EL SU DO KU DE LA S FECHA S

sobre tablas versionadas (con Fecha Desde y Fecha Hasta) debido al potencial riesgo de duplicidad de valores (violacin de claves) si utilizamos slo la Clave de Negocio (Business Key). Las Claves Primarias o Indices Unicos permiten garantizar la integridad de los datos en lo referente a la unicidad de filas, facilitan tareas como comprobar versiones solapadas, etc. En entornos de Business Intelligence (BI) y Data Warehouse (DW) facilitan la creacin de Claves Subrogadas en tablas de Dimensiones de Cubos OLAP, etc. Puede interesarnos un valor autonumrico o secuencial? Puede interesarnos un campo Fecha Hora de Creacin o Timestamp?
C M O C O N S U LT A R L A V E R S I N V L I D A A UNA FECHA

Este captulo describe el Grfico de Lnea de Tiempo, una herramienta de gran utilidad para facilitar la construccin de Consultas SQL sobre tablas versionadas, pudiendo comprobar los distintos casos que pueden producirse para as validar la fiabilidad de nuestro algoritmo (es decir, de nuestra consulta SQL, especialmente las clusulas WHERE y JOIN). Resulta especialmente til, cuando necesitamos denormalizar dos tablas versionadas (ambas con sus campos Fecha Desde y Fecha Hasta, caso habitual en entornos de Business Intelligence - BI - y Data Warehouse - DW) y en consultas SQL similares.
CMO DEFINIR UNA CLAVE UNICA O INDICE U NICO SOBR E U NA T ABLA CON VER SIONADO (FECHA DESDE Y FECHA HASTA)

Este captulo describe cmo realizar una consulta SQL sobre una tabla versionada (con Fecha Desde y Fecha Hasta) para obtener la versin vlida a un Fecha, algo muy habitual al trabajar con tablas versionadas (ej: obtener la versin vlida de un Titular a fecha de Movimiento; obtener la versin vlida de un Cliente a Fecha de Factura), tanto en entornos transaccionales (OLTP) como en entornos de Business Intelligence (BI) y Data Warehouse (DW) especialmente para Reporting. Se incluyen ejemplos de consultas SQL (en Transact-SQL), se explica la lgica de estas consultas SQL, se considera el caso de tablas versionadas que incluyan los campos Fecha Alta y Fecha Baja, etc.
C O M O D E N O R M A L I Z A R D O S T A B LA S V E R S I O N A DA S ( C O N F E C H A D E S DE Y FECHA HASTA)

Este captulo examina las diferentes alternativas posibles cara a la necesidad de definir de Claves Primarias o ndices nicos

Este captulo detalla un mtodo o algoritmo para denormalizar dos tablas versionadas (con Fecha Desde y Fecha Hasta), por supuesto, sin utilizar cursores. Esta tcnica resulta de gran utilidad en entornos de Business Intelligence (BI) y Data Warehouse (DW), tanto para Reporting como para construir tablas de Dimensin en entornos OLAP. Se explica tambin, como para denormalizar varias tablas versionadas es posible aplicar este mtodo o algoritmo varias veces consecutivas. Se incluyen consultas SQL de ejemplo, se detalla qu campos son estrictamente necesarios, y

otras alternativas de diseo cara a la implementacin de este mtodo o algoritmo en entornos de produccin de base de datos (a poder ser, con SQL Server, of course ;-).
C O M O C O M P R O B A R L A E X I ST E N C I A D E V E R S I O N E S S O L A P A DA S E N T A B L A S V E R S I O N A DA S S C D T I P O 2 ( C O N F E C H A D E S D E Y F E C H A H A ST A )

Este captulo explica una de las tareas de comprobacin que suele resultar necesaria al trabajar con tablas versionadas: comprobar la existencia de versiones solapadas en una Tabla Versionada SCD Tipo 2 (con Fecha Desde y Fecha Hasta). Esta comprobacin resulta especialmente til en entornos de Data Warehouse (DW) y Business Intelligence (BI), como medio para garantizar los datos resultantes de los procesos de carga y transformacin de datos (ETL), que en ocasiones realizan intensivas transformaciones sobre las tablas versionadas (Slowly Changing Dimensions) de origen. Este captulo explica cmo realizar esta comprobacin con consultas SQL (es decir, utilizando Transact-SQL), con el ejemplo bancario de las Cuentas Corrientes y los Titulares utilizado anteriormente.

DEFINICIN DE UN MODELO DE VERSIONADO

A continuacin se define un Modelo de Versionado, es decir, un conjunto de reglas que se debe seguir para la implementacin del mismo, desde el punto de vista de Ingeniera de Software (Anlisis, Diseo y Desarrollo de Software), con el objetivo de poder gestionar tablas que almacenan histricos de cambios. El Modelo de Versionado que a continuacin se explica, es el Modelo de Versionado que tomaremos como ejemplo para el desarrollo del resto del Artculo. 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 cmo realicemos nuestro Anlisis y Diseo, 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 funcin del Modelo de Versionado que utilicemos deberemos realizar las consultas SQL de nuestras tablas, utilizar diferentes Modelos de Versionado en diferentes tablas puede causar confusin a los desarrolladores que generen erratas en nuestro software (o en nuestro Data Warehouse - DW - , si nuestro cometido es slo la explotacin de dichos datos con fines analticos - OLAP y Business Intelligence). Sin ms, a continuacin 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 versin. Los campos Fecha Desde y Fecha Hasta almacenarn slo la Fecha, es decir, no almacenarn informacin horaria.

Fechas especiales: se definir un valor correspondiente a la menor fecha posible (infinito) y otro correspondiente a la mayor fecha posible (+infinito). La definicin 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 versin es vlida 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 podran 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 funcin de cmo se rellene la Fecha Desde y la Fecha Hasta, deberemos construir una clusula 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 definirn un conjunto de intervalos continuo. Otro detalle importante, ya que en otro Modelo de Versionado se podran permitir intervalos discontinuos, es decir, para el Cliente A tener una versin 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 mayora de los cambios pueden generar nueva versin, pueden existir cambios que no generen nueva versin, porque no tenga sentido. Por ejemplo, en una tabla de gestin de usuario el cambio de la direccin de correo de un usuario podra generar una nueva versin, y sin embargo el cambio de la Fecha de ltimo logon podra no generar nueva versin 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 cuestin 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 tendrn sentido en un momento posterior en el tiempo. En cualquier caso, como se comenta ms adelante en este Artculo, 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 versin 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 realizacin de mltiples cambios en el mismo da que impliquen generar nueva versin generar mltiples filas (mltiples versiones). Por lo tanto, si realizamos varios cambios en el mismo da, se obtendrn los siguientes resultados. La primera versin con Fecha Desde igual al Fecha Hasta de la ltima versin existente y Fecha Hasta al da del cambio, es decir, se tratar de una versin 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 tambin al da del cambio, es decir, se tratar de una versin cerrada donde los campos Fecha Desde y Fecha Hasta tendrn el mismo valor.

Las versiones intermedias con Fecha Desde y Fecha Hasta al da del cambio, es decir, se tratar de una versin cerrada donde Fecha Desde y Fecha Hasta almacenarn el mismo valor. La ltima versin con Fecha Desde al da del cambio, y Fecha Hasta a +infinito (ej: 31/12/9999), por lo tanto, se tratar de una versin abierta.

Teniendo en cuenta los criterios antes comentados, en especial, que una versin es vlida desde su Fecha Desde (incluida) hasta su Fecha Hasta (excluida), y que no se almacenar informacin horaria en estos campos, ocurre que todas la versiones con Fecha Desde igual a Fecha Hasta quedarn descartadas, es decir, estas versiones quedarn deshabilitadas de forma implcita. Esto es ms que evidentemente, pues realmente sern vlidas en un periodo de tiempo de duracin 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 mltiples versiones para cambios en el mismo da. Es decir, al hacer un cambio genero una nueva versin que estar abierta (Fecha Hasta a +infinito), de tal modo, que sucesivos cambios en el mismo da, no generarn nuevas versiones, sino que por el contrario actualizarn esta versin. Tambin existen desarrollos en mercado, que utilizan un criterio u otro en funcin 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 funcin de cmo se gestione esta problemtica, vara la forma de desarrollar las consultas SQL de base de datos (ej: comprobar solapamiento de versiones) o de gestionar la propia tabla (ej: generacin de ndices nicos).

El motivo por el que prefiero generar mltiples versiones para cambios en el mismo da, es porque me permite almacenar un histrico de cambios. De este modo, nunca se pierde informacin. Con todo esto, habremos definido un conjunto de reglas suficiente para la definicin de nuestro Modelo de Versionado.

Tambin 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 podra inferir de la Fecha Desde de la siguiente versin. Personalmente me parece mucho ms cmodo utilizar dos fechas (Fecha Desde y Fecha Hasta), pudiendo as simplificar las consultas SQL sobre las tablas versionadas

Resulta de gran importancia, haber entendido correctamente todas las reglas anteriores antes de continuar con la lectura de ste Artculo (si no ha sido as, mi recomendacin es realizar una nueva lectura de ste captulo antes de continuar, vale la pena...). Es decir, dado que dichas reglas definen cmo se van a almacenar los datos en nuestras tablas, si no tenemos un conocimiento claro del contenido de nuestras tablas Cmo 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 informacin actual (versiones abiertas) y la informacin histrica (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 histricas, se podra definir una poltica diferente para rellenar los campos Fecha Desde y Fecha Hasta. Pero dnde quiero llegar es a otro punto, es decir, existen Modelos de Versionado que utilizan una tabla con la informacin actual, y otra tabla con la informacin histrica, 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 automtica las tablas histricas, generndose as los datos histricos. Una diferencia destacable de utilizar dos tablas (es decir, una tabla con las versiones actuales, y otra tabla con las versiones histricas), es que resulta ms fcil 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 histricos, volveramos a las andadas ;-)

Este captulo explica las dudas frecuentes al trabajar con fechas en SQL Server: tipos de datos de fecha en SQL Server y sus rangos de valores, realizacin de consultas sobre fechas y utilizacin de funciones de fecha habituales (utilizar BETWEEN, DATEPART, DATEDIFF, etc), realizacin de castings (cambiar datos de un tipo a otro, ej: VARCHAR a DATETIME) con CAST y CONVERT, cmo obtener la fecha actual en SQL Server (GETDATE y GETUTCDATE), utilizacin de la opcin de configuracin SET LANGUAGE, cmo obtener la fecha sin la hora, Calendario Juliano o Calendario Gregoriano?, etc. El primer factor de xito es la eleccin del tipo de dato correcto para representar las fechas, que hasta SQL Server 2005, slo podemos elegir entre datetime (01/01/1763 a 31/12/9999, con precisin de unos 3,3 milisegundos) y smalldatetime (01/01/1900 a 06/06/2079, con precisin de 1 minuto). Ambos almacenan Fecha y Hora, ya que en SQL Server 2005 (y en versiones anteriores) son los nicos tipos de datos disponibles para Fecha Hora, y no existen otros tipos que almacenen slo la Fecha o slo la Hora. Esto cambia en SQL Server 2008, como describo (muy por encima) en Ya est disponible SQL Server 2008 para descargar desde MSDN !! Un error tpico, es intentar cargar fechas de un origen de datos externo que contiene valores fuera de rango del que puede almacenar SQL Server. A modo de ejemplo, a continuacin se muestran el rango de fechas vlido en algunos motores de base de datos habituales: y Microsoft Access 2003 tiene un nico tipo de dato Fecha Hora de 8 bytes que admite fechas desde el 01/01/0100 al 31/12/9999. Eso si... Microsoft Access no es un motor de base de datos del todo... IBM DB2 tambin admite Fechas desde el 01/01/0001 hasta el 31/12/9999. IBM Informix tambin admite Fechas desde el 01/01/0001 hasta el 31/12/9999. MySQL admite Fechas desde el 01/01/1000 hasta el 31/12/9999. ORACLE admite fechas desde el 01/01/4713 AC hasta el 31/12/9999. El estandard ANSI SQL define Fechas desde el 01/01/0001 hasta el 31/12/9999.

Otro error tpico, es insertar fechas en una tabla y luego hacer consultas sobre las filas insertadas utilizando el operador de igualdad sobre campos de fecha. Claro, como se almacena fecha y hora, si en nuestras consultas slo especificamos la fecha, para la hora se tomar el valor 00:00:00.000, luego o realmente almacenamos las fechas en SQL Server truncando el valor de hora-minutosegundo-milisegundo, o tendremos que modificar nuestras consultas para obtener el resultado deseado. Este error es muy comn, y suele causar bastante confusin hasta que se comprende este funcionamiento. Puede ser de ayuda utilizar el operador BETWEEN en la clusula WHERE (ojo con BETWEEN, ya que incluir todas las filas entre las fechas indicadas, incluyendo dichas fechas, es decir, inclusives), o bien almacenar la fecha sin la hora (truncando la hora a la 00:00:00.000), o quizs truncar la fecha (quitando la informacin horaria) como se explica ms adelante en este mismo artculo, etc. Un detalle muy importante es saber cmo indicar las fechas a SQL Server, es decir, en qu formato debemos escribir las fechas en nuestras consultas. Esto, por defecto, depende de la configuracin de idioma (o lenguaje) que tiene el Inicio de Sesin de SQL Server con el que estamos conectados a la Instancia. Vale la pena recordar que cada Inicio de Ssin tiene su configuracin de lenguaje, y que cuando se crea un Inicio de Sesin, si no se especifica explcitamente la configuracin deseada de lenguaje, se asignar la configuracin por defecto establecida en la Instancia. Esta configuracin la podemos cambiar dentro de un bloque de cdigo Transact-SQL, utilizando la sentencia SET LANGUAGE. Sin embargo, quizs la mejor solucin sea utilizar el formato ANSI de fechas (YYYYMMDD HH:mm:ss), y as no tener dependencias con la configuracin de idioma o lenguaje.
DECLARE @Fecha AS DATETIME DECLARE @FechaHora AS DATETIME SET @Fecha = '20080101' SELECT @Fecha SET @FechaHora = '20080101 15:30:00.000' SELECT @FechaHora

y y y y y

Otro tema importante es cmo obtener la fecha hora del sistema en SQL Server. Para ello, podemos utilizar la funcin GETDATE(), o bien GETUTCDATE() si deseamos la fecha hora en UTC. Existen otras funciones de fecha hora vitales para trabajar con fechas en SQL Server, como son DATEPART para obtener una determinada parte de una fecha hora (el mes, el da, la semana del ao, etc.), DATEDIFF para saber la diferencia entre dos fechas (se puede especificar la unidad deseada, es decir, podemos querer la diferencia de minutos, o la diferencia de horas...) y DATEADD para conocer el resultado de agregar a una fecha hora un intervalo determinado (un nmero concreto de minutos, o de horas, o de das, etc.). Es importante recordar que algunas de estas funciones, devuelven valores numricos, y en consecuencia nos puede interesar realizar una casting (utilizando las funciones CAST o

CONVERT) a un dato alfanumrico (ej: un casting a VARCHAR) para poder realizar concatenaciones, etc. Existen ms funciones. Tanto el resto de funciones existentes, como el detalle de lo que hemos contado, est muy bien descrito en la ayuda de SQL Server, el decir, los Libros en Pantalla (BOL - Books On Line). Una tarea muy habitual al trabajar con Fechas en SQL Server, es obtener la Fecha sin la hora, es decir, truncar la informacin horaria obteniendo slo la parte de la fecha. En consecuencia, para la parte de la hora, se utilizar medianoche (es decir las 00:00:00.000). Existen varias formas de conseguir la Fecha sin la hora en SQL Server. Quizs la mejor manera, se hacer un casting de fecha a FLOAT, truncar la parte decimal (es decir, la informacin horaria), y hacer una casting del resultado a Fecha DATETIME o SMALLDATETIME.

-- Obtener la diferencia en das (un valor entero), desde la fecha 0 y la fecha deseada, -- y seguidamente aadir a la fecha 0 el nmero de das calculado previamente -- (pero sin informacin horaria). -- Obtener la diferencia en das (es decir, un valor entero), -- desde la fecha 0 y la fecha deseada, -- y seguidamente convertir dicho valor numrico a un valor Fecha Hora. -- Como en las fechas, la parte decimal es la correspondiente a la informacin horaria, -- conseguimos truncar la informacin horaria y conservar slo la Fecha. SELECT CAST(DATEDIFF(DAY, 0, GETDATE()) AS DATETIME) -- Convertir un valor Fecha Hora, a una cadena de texto, -- con la opcin de estilo 112 (ISO) SELECT CAST(CONVERT(VARCHAR(20), GETDATE(), 112) AS DATETIME) -- Convertir un valor Fecha Hora en un valor numrico en coma flotante -- (recordar, que las fechas internamente son nmeros cuya parte decimal -- es la informacin horaria), seguidamente truncar el valor numrico obtenido, -- es decir, eliminar la informacin horaria), para finalmente -- volver a convertirlo a Fecha Hora (pero con la informacin horaria sesgada). SELECT CAST(FLOOR(CAST(GETDATE() AS FLOAT)) AS DATETIME)

Otro punto a tener en cuenta es la presentacin de las fechas. Como hablamos, depende de la configuracin de lenguaje del inicio de sesin actual, la cual si no nos satisface, podemos cambiar (SET LANGUAGE) o utilizar funciones de fecha y hora. Sin embargo, como esto en ocasiones resulta algo engorroso, puede ser til utilizar la funcin CONVERT especificando un formato de estilo (consultar los Libros en

Pantalla para ms informacin), como en el siguiente ejemplo:

SELECT CONVERT(VARCHAR, GETDATE(), 103).

En cualquier caso, recordar que en muchas ocasiones el trabajo de presentacin es realizado por las aplicaciones cliente (Web o Win) o por las herramientas de Reporting

utilizadas (Crystal Reports, Reporting Services, Actuate, etc.).

CALENDAR IO JU LIANO O CALENDAR IO GR EGOR IANO?

El Calendario Juliano fu implantado en el ao 46 antes de Cristo, hasta que posteriormente fu sustituido por el Calendario Gregoriano (ojo, en cada pas se impuso el Calendario Gregoriano en un momento del tiempo distinto, es decir, no se cambi de calendario en todos los pases el mismo da...). Y esto que nos importa? pues principalmente, que el clculo de los aos bisiestos es diferente, en funcin de que nos ajustemos al Calendario Juliano o al Calendario Gregoriano. Por ello, puede resultar til saber cmo se gestionan los aos bisiestos en nuestra base de datos verd? Por ejemplo: SQL Server utiliza el Calendario Gregoriano. DB2 utiliza el Calendario Gregoriano. ORACLE utiliza el Calendario Gregoriano para las fechas posteriores al ao 1582, pero utiliza el Calendario Juliano para las fecha anteriores. En consecuencia, podemos encontrar situaciones peculiares. Por ejemplo, el da 29/02/1300 es una fecha vlida en ORACLE, mientras que en DB2 resulta una fecha invlida, al tratar el ao 1300 como no bisiesto.

http://www.guillesql.es/Articulos/Versionado _Fecha_Desde_Fecha_Hasta_Versiones_Consulta s_SQL.aspx