Principales Arquitecturas en Datawarehousing: Inmon versus Kimball (Parte I)

Slowly Changing Dimensions

Bajo el nombre Slowly Changing Dimension nos vamos a encontrar la necesidad de cómo gestionar  el efecto que el Tiempo tiene sobre nuestro Datawarehouse.

En ocasiones, podemos encontrar interesante (y necesario) recoger todos los cambios a los que se ve sometido una Dimension de nuestro modelo.

Este problema, planteado por Kimball, tiene distintos tipos de soluciones, dependiendo de los requerimientos funcionales.

Veamos ahora las distintas soluciones que tenemos al problema de cómo gestionar el efecto del Tiempo en una Dimensión.

Tipologia de las Slowly Changing Dimensions

Para facilitar la comprensión de lo aquí expuesto, vamos a utilizar un ejemplo basado en una tabla de Dimensión simple, formada por una clave subrogada, la clave natural del Cliente y el tipo de Cliente.

Tipo 0

Representa una concepción radical lejana a la realidad. Las dimensiones nunca cambian.

Bajo este supuesto, tendríamos que un Cliente es siempre el mismo cliente, y tendríamos un solo registro de ese cliente, invariable a lo largo del Tiempo.

Pej., el Cliente 55 de nuestra Dimension “CLIENTES” es un cliente de Proveedor de Internet (ISP) que tiene contratado un ADSL con velocidad “1Mb”

Tipo 0. No se considera ningún tipo de cambio

Y suponemos que, como es tipo 0, ese Tipo de Cliente (“1Mb”) nunca va a cambiar.

Tipo 1

Se introducen los nuevos cambios sobre-escribiendo los anteriores valores.

Tenemos igualmente que cada registro representa un Cliente, y lo que hacemos es actualizar siempre ese registro con los cambios que se vayan produciendo a lo largo del Tiempo.

En nuestro Ejemplo teníamos al Cliente 55 que tenía contratada una velocidad ADSL de “1Mb” en el momento t₀

Tipo 1. Punto de partida

Con el paso del tiempo (momento t₁) nos encontramos que decide contratar una velocidad de descarga mayo (“3MB”) con lo que directamente actualizamos el registro

Tipo 1. Actualización del registro

Por lo tanto, el Tipo 1 es la forma más simple de tratar con los cambios de los atributos en las tablas de Dimensión. Es fácil de implementar, pero no se mantiene ninguna “historia” de los valores anteriores de la Dimensión. Si un usuario de Negocio quisiera introducir en su análisis un estudio de cómo evolucionan los clientes en función de los precios de velocidad del ADSL ofertados, vemos que no sería posible.

Tipo 2

Esta solución se basan en un nuevo concepto: “El versionado de la Historia”.

Hasta ahora, cada registro de una tabla dimensional representaba un Objeto. Así en la tabla “Clientes” tendríamos tantos registros como Clientes tiene el Negocio. Pero el “Versionado” obliga a cambiar este planteamiento, introduciendo el concepto de que cada registro son “Versiones de un objeto”. Así, un mismo Cliente puede dar lugar a distintas registros, y todos los registros relacionados con el mismo cliente no son sino Versiones de ese Cliente con respecto al tiempo, es decir, el Cliente 1 puede tener un registro válido en el tiempo t₁ y un registro distinto en el tiempo t₂, así sucesivamente hasta t_n.

Partiendo de la situación inicial (Cliente “55” con velocidad ADSL “1Mb”), a la hora de introducir el cambio a velocidad ADSL “3Mb”, lo hacemos insertando un nuevo registro con la misma Clave Natural (“55”) pero una nueva Clave Subrogada (“2”), y el nuevo atributo. La tabla tendría entonces 2 versiones del mismo cliente, una insertada en el momento  t₀ y otra en el momento t₁:

Tipo 2 Versionado de la Historia

Esas claves primarias subrogadas están siempre correctamente asociadas con los registros temporales de la tabla de Hechos. Cuando crucemos esta dimensión con una tabla de Hechos, un registro cruzaría con los Hechos anteriores a t₁ mientras que el otro, con los Hechos posteriores a t₁.

El nuevo registro en la tabla de Dimensiones automáticamente particiona históricamente la tabla de Hechos, por lo que el Tipo 2 es un técnica sencilla y poderosa de solucionar el registro de los cambios a los que se enfrenta un DWH a lo largo del tiempo.

También se puede incluir una columna que distinga la versión del Cliente actual (“1”) de las no-vigentes (“0”), por lo que tendríamos:

Tipo 2. Versionado de la Historia con columna para "Version"

Tipo 3

En este caso, disponemos de columnas en las que almacenar los cambios que suceden.

En nuestro ejemplo anterior, basta con incluir una nueva columna “Tipo Cliente Predecesor” que almacene el valor a actualizar:

Tipo 3. Columna con valor Histórico

Aunque el tipo 2 permitía particionar la Historia, no podemos recrear los Hechos de forma que el cambio nunca haya ocurrido. Pero con el Tipo 3 estamos limitados únicamente a almacenar la información pasada tantas veces como columnas para ello hayamos dispuesto.

Tipo 6 (3+2+1)

El Tipo 6 es un tipo híbrido, ya que combina elementos de los 3 anteriores tipos (donde “6” representa la suma de los 3 tipos anteriores “3+2+1”).

Se basa en insertar un nuevo registro para capturar el cambio (“versionado”) como en el Tipo 2 y añadir una nueva columna para registrar el valor actual, como en el tipo 3.

En nuestro ejemplo esto se materializaría de la siguiente forma. Tendríamos la situación de partida en t₀:

Tipo 6. Situación Inicial

donde el Tipo Cliente actual e histórico serían el mismo.

Ante el cambio en la velocidad ADSL contratada a 3Mb, actualizamos la columna de Tipo de Cliente actual con el nuevo valor e insertamos un nuevo registro (con una nueva clave subrogada) con el Tipo de Cliente actual y Tipo Cliente Predecesor de “3Mb”:

Tipo 6. Resultado de la tabla tras primera modificación

Que el “Tipo Cliente” actual y “Tipo Cliente Predecesor” tengan el mismo valor cuando el registro se inserta, es consecuencia de la necesidad de poder reconstruir la Historia, ya que la columna “Tipo Cliente” siempre va a almacenar el valor actual y “Tipo Cliente Predesor” los distintos valores que va tomando la versión del “Cliente”. Para ver esto más claro, supongamos que en el momento t₂, nuestro Cliente “55” decide contratar una velocidad mayor “6Mb”, con lo que nuestra tabla tendría que reflejar ese cambio. Actualizaríamos los dos registros (“versiones”) anteriores e insertaríamos un nuevo registro (con una nueva clave subrogada):

Tipo 6. Resultado de la tabla tras la segunda modificación

Como vemos, se actualizan los dos registros anteriores en el valor “Tipo Cliente” actual y se inserta un nuevo registro de la forma “Tipo Cliente” = “Tipo Cliente Predecesor”. De esta forma, podemos en todo momento poder recuperar la información histórica en relación al Cliente “55”, cumpliendo con el requerimiento del cliente.

Estos son los tipos principales con los que Kimbal solucionó el problema por él planteado de cómo recoger los cambios en el tiempo en los que se ven envueltos los elementos que forman un Datawarehouse.

Modelo en Estrella

El Modelo en Estrella es un tipo de Modelo Dimensional, y por lo tanto, tiene como elementos una tabla de Hechos y tablas de Dimensiones. Lo que caracteriza al Modelo en Estrella, y lo diferencia de otros modelos dimensionales como el Modelo de Copo-de-Nieve, es cómo se lleva a cabo la relación entre las tablas de Dimensiones, más en concreto, como se construye la relación entre los distintos niveles dentro de una Dimensión. En el Modelo en Estrella, cada dimensión utiliza únicamente una tabla, en el Modelo en Copo-de-Nieve, una dimensión es representada en varias tablas.

La tabla de Hechos es una tabla que contiene dos tipos de campos: por un lado, las Medidas, que no son más que los datos que vamos a analizar. En un datawarehouse (DW) de ventas, pues serían las ventas. En un DW financiero, serían elementos del Balance (Activo a Corto Plazo, Pasivo Circulante, Acreedores, etc.). En nuestro DW para análisis bursátil, serían los conceptos de Precio de Apertura, Precio de Cierre, etc. El otro tipo de campos incluídos en la tabla de Hechos son las claves que apuntan a los registros de las tablas de dimensiones, y que permiten relacionar los datos con los niveles de las dimensiones. Los valores que forman conjunto de claves forma la Clave Primaria de la tabla de Hechos.

Pongamos un ejemplo de Modelo en Estrella. Un DW de ventas de una distribuidora de productos electrónicos. Tendríamos un modelo dimensional en Estrella como éste:

Ejemplo de Esquema en Estrella

Como vemos, tenemos una tabla de Hechos, cuya clave primaria es id_producto, id_tienda, id_tiempo, y tres dimensiones: dim_producto, dim_tienda, dim_tiempo, es decir, para una tienda, un día del año y un producto solo puede haber un valor para las medidas PRECIO y UNIDADES:

Diseño de la Tabla "HECHOS"

Si ejecutamos una instruccion SQL contra esta tabla » Hechos» de la forma

SELECT * FROM HECHOS;

obtendríamos

Resultado de una query SELECT en la tabla HECHOS

Veamos ahora las tablas de dimensiones. Cada una de las tres dimensiones de nuestro análisis («Producto», «Tienda», «Tiempo») son representadas en nuestro Modelo en Estrella en una única tabla. Esta es la característica diferencial con respecto a los Modelos en Copo-de-Nieve.

Entrando en detalle, veamos una dimensión, en concreto la dimensión»Producto»:

Diseño de la tabla de "DIM_PRODUCTO"

y si ejecutamos una consulta SQL contra ella

SELECT * FROM DIM_PRODUCTO;

obtendríamos datos como estos (como el SELECT no filtra la tabla, y ésta tiene más registros, solo mostramos un extracto de los mismos):

Resultado de una query SELECT en la tabla "DIM_PRODUCTO"

Como observamos, en esta tabla hay campos que tienen el mismo valor una y otra vez, por ejemplo, el campo fabricante es «BLUSENS» (que es una marca española de Tecnología).

Si nos desplazamos unos registros más hacia abajo en esa tabla, tendríamos en este campo»Fabricante» otros valores como «TOSHIBA», «PHILIPS», etc., es decir, todos los fabricantes que están en el católogo de la empresa distribuidora. Lo que llama la atención es que hay valores que se repiten una y otra vez en la tabla (no solo en el campo «Fabricante», también en los campos «Categoría» y «Subcategoría»).

Esto contradice las reglas de Normalización de Codd. Si nos ponemos en el caso de que una empresa compra a otra (como ha ocurrido con la compra por parte de HP a Palm) tendríamos que modificar esta tabla DIM_PRODUCTO tantas veces como productos de ese fabricante tengamos en la tabla de dimensión «Producto», de manera que ahora el fabricante de cualquier producto «Palm» sería a partir de ese momento «HP_Palm». Si tenemos un amplio catálogo de productos de «Palm», tendríamos que actualizar uno por uno cada registro de la tabla de dimensión «Producto», de manera que se generarían transacciones para actualizar esos registros de la tabla «Producto». Esto podría evitarse mediante un proceso de «Normalización de Tablas»: para evitar que cada cambio en un atributo genere transacciones, lo que hacemos es que en la tabla de Producto, en lugar de poner el nombre del Fabricante, utilicemos el ID de otra tabla «Fabricante» (con solo 2 columnas, «ID» y «Nombre_Fabricante»). En la tabla «Fabricante» tendríamos un registro  con valores:

(ID=»25″, Nombre_Fabricante=»Palm»)

y en la tabla «Producto» únicamente almacenemos la ID del registro en la tabla «Fabricante» (es decir ID=»25″), de manera que, si se modifica el nombre del fabricante, y ahora «Palm» se llama «HP_Palm» en la tabla «Fabricante»

(ID=»25″, Nombre_Fabricante=»HP_Palm»)

, solo haya que cambiarlo una vez en la tabla «Fabricante», porque la ID del registro en la tabla «Producto» no se modifica (sigue siendo ID=»25″).

Con ello, normalizamos la dimensión «Producto» y sus valores estarían incluídos en varias tablas («Producto», «Fabricante»). Lo mismo para cada uno de los campos en los que se almacenan valores duplicados una y otra vez.

Ahora, nuestra base de datos está normalizada (tendríamos 2 tablas para la dimensión «Producto», una tabla «PRODUCTO» y otra tabla «FABRICANTE»), y estaríamos de acuerdo con las Reglas de Codd, pero ya no tendríamos un Modelo en Estrella.Porque el Modelo en Estrella es un modelo «Desnormalizado», es decir, que no tiene en cuenta las bondades del proceso Normalizador de Codd, ya que éste busca mejorar el rendimiento de una base de datos operacional, donde se utilizan toda una variedad de instrucciones SQL (INSERT, UPDATE, DELETE). Una característica del DW es que es «No-Volátil», por lo que sus datos no suelen ser actualizados o borrados. Una vez que se inserta una venta en la tabla «Hechos», no se modifica. De ahí que ya no necesitemos normalizar las tablas: mayoritariamente, el tipo de instrucciones SQL que los usuarios ejecutan contra un DW son del tipo SELECT  porque queremos acceder a la información (los usuarios no modifican los datos, solo los leen en sus informes y análisis). Por eso, no es necesario normalizar las tablas, ya que buscamos mejorar el rendimiento de instrucciones SELECT, y los Gestores de las bases de datos, suelen penalizar los JOIN utilizados para recuperar la información mediante SELECT entre las distintas tablas que forman la dimensión (es decir, en el modelo normalizado, donde la dimensión «Producto» consta de dos tablas, «PRODUCTO» y «FABRICANTE», si el usuario del DW quiere mostrar el nombre del fabricante, que es más descriptivo que su ID, como en la tabla «PRODUCTO» solo guardamos los ID del fabricante, estamos obligados a introducir un Join entre ambas tablas «PRODUCTO» y «FABRICANTE», y en el resultado del SELECT obtendremos el valor Fabricante=»Palm».

Este caso de dimensiones en varias tablas, es el Modelo en Copo-de-Nieve que veremos más adelante.

Por lo tanto, un modelo Dimensional en Estrella, es un modelo en el cuál todas las dimensiones que utilicemos en nuestro análisis están almacenadas en una única tabla.

Modelo Dimensional

Dentro de la disciplina de Modelado de Datos, encontramos el «Modelo Dimensional». Sus elementos principales son:

1. Hechos,
2. Dimensiones

Los Hechos serían aquéllos datos que nos proporcionan una información cuantitativa sobre las carácterísticas del Negocio que queremos analizar. En nuestro caso, los Hechos serán los datos de la acción («Precio Apertura», «Precio Cierre», «Máximo Diario», «Mínimo Diario», «Volumen»).

Su finalidad es proporcionar información necesaria para la gestión, facilitando el conocimiento del Negocio o Proceso a modelar, y fundamentar, entre otras, la toma de decisiones, facilitar los procesos de marketing (ofertas y promociones), fidelizar clientes, valorar el desempeño de los trabajadores, etc.

Por otra parte, las Dimensiones buscan determinar un contexto para el análisis de los Hechos. Se trata de grupos homogéneos de elementos, en muchas ocasiones, jerarquizados. Su papel es promocionar la información contenida en los Hechos. En nuestro caso, tenemos dos dimensiones: «Tiempo» y «Sociedades».

Las Dimensiones pueden estar jerarquizadas o no. En nuestro caso, todos los elementos de la dimensión Tiempo son jerarquizables, y se pueden representar en un esquema en árbol. El primer término es «Año», siendo sus descendientes «Trimestres», que a su vez tienen como descendientes a los «Meses», éstos a las «Semanas», etc. En este contexto, definimos al «Elemento Padre» como el elemento superior en la jerarquía dado un elemento  («Año es el Elemento Padre de «Trimestres») y como «Elemento Hijo» a los elementos inferiores en la jerarquía dado un elemento («Meses es el Elemento Hijo de Semanas»).

Pero los elementos de la dimensión «Sociedad» no son jerarquizables, ya que su nexo de unión es su condición de valores incluídos en el IBEX-35, y todos estarían al mismo nivel. Si en el futuro, decidieramos aumentar el número de sociedades a analizar, más allá del IBEX-35, e incluyésemos todos los valores sujetos a negociación en el Mercado de Madrid, o incluso en Mercados internacionales (por ejemplo, el NASDAQ-100, que es un índice de incluye los 100 principales valores del sector TIC a cotización en el Mercado de New York), si ya tendríamos elementos-Padre y elementos-Hijo (siendo los elementos-Padre «IBEX-35», «NASDAQ-100», etc. y los elementos-Hijo las sociedades cuyas acciones están incluídas en el cálculo del índice «Telefonica», «Repsol YPF», etc), aunque mantendrían su condición de «No-agregables» (ya que, a priori, no tiene sentido sumar todos los precios de cierre de valores distintos).

La relación entre los Hechos y las Dimensiones tiene en cuenta la «Granularidad». Definimos la «Granularidad» como el menor grado de detalle de nuestro análisis. En nuestro caso, sería dia-sociedad. Otra forma de definirlo es cómo el menor nivel al que existe relación entre los Dimensiones y el conjunto de Hechos. Por lo tanto, los Hechos son explicables a partir de datos en un entorno día-sociedad. A partir de aquí, podemos realizar «Roll Up», que no es más que ir agregando los valores en función de los elementos-Padre, y así sucesivamente hasta llegar al Elemento superior de la jerarquía. En nuestro caso, si hacemos «Roll Up» sucesivamente desde el menor grado, tendríamos un análisis semana-sociedad, mes-sociedad, trimestre-sociedad, año-sociedad. El proceson inverso, basado en desagregar en función de los elementos-Hijo, se conoce como «Drill Down», y busca permitir al analista de la información, una forma de ver más detalle los datos.

Cuando lo que hacemos es limitar o ampliar los miembros de una Dimensión (pej, queremos ver los datos de los Hechos solo para el primer trimestre de 2010), estamos haciendo un «Slice» (del inglés, «cortar en lonchas»), . El proceso de acotar aún más el conjunto de información contenida por un «Slice» se conoce como «Dice» (del inglés, «cortar en dados»).

Las dos  enfoques con los que su utiliza el Modelo Dimensional son:

1. Modelo en Estrella
2. Modelo en Copo-de-Nieve

Clase Java para Descargar el Fichero .csv de Yahoo Finanzas

El fichero de datos se obtendrá con la dirección de Yahoo Finanzas:

http://es.old.finance.yahoo.com/d/quotes.csv?s=@%5EIBEX&f=sl1d1t1ophgv&e=.csv

Lo primero que intentamos fué descargarla directamente mediante una llamada a «Mozilla Firefox» pasandole la URL como parámetro:

firefox -url http://es.old.finance.yahoo.com/d/quotes.csv?s=@%5EIBEX&f=sl1d1t1ophgv&e=.csv

Pero tenía el inconveniente de que nos solicitaba mediante una pantalla que abriesemos o guardasemos el fichero:

Ventana de Firefox solicitando como debe manejar el fichero

lo cuál, no me parece la mejor opción. Es un workaround, pero no me parece una pieza de código digno del proyecto.

Por lo tanto se ha codificado una clase en Java que realice este trabajo. Con ello conseguimos que nos descargue el fichero, junto con la creación de un fichero de log que nos facilite saber como ha ido la descarga para un día concreto. Teniendo en cuenta nuestro interés en que sea un proceso automatizado, el hecho de tener un log y saber si se ha descargado o no un día concreto el fichero, nos facilita mucho las cosas a la hora de resolver problemas futuros.

La clase en Java la hemos llamado «DescargarFicheroYahoo» y a través de la URL que le pasamos, construye un objeto URL, entre cuyos métodos tiene openStream(), y este flujo se le pasa a un Buffer para escribirlo en un fichero. También escribe un fichero log con cada ejecución. Tanto el nombre del fichero de datos como el log contienen en su nombre la fecha del día que se generaron (a modo de timestamp). Para escribir el log, hemos creado un método en nuestra clase que nos va indicando la fecha y hora en el que se van ejecutando los procesos de escritura en el fichero de datos.

La clase está configurada para que por defecto utilice como carpeta de destino del fichero .csv y del fichero log:

/home/proxecto/ProjectSourceFiles/

/home/proxecto/ProjectSourceFiles/LogDescarga/

ya que el entorno es Linux, pero acepta como argumentos cualquier ruta (también rutas en Windows), para hacerla más flexible.

Un tercer argumento es la URL. Por defecto es la de Yahoo Finanzas, pero podemos utilizar cualquier otra URL (podemos cambiar en el futuro la URL de Yahoo Finanzas si fuese necesario).

Una vez creada la clase, lo se ha exportado a un fichero .jar para poder conseguir portabilidad («run anywhere!») y para poder lanzarlo cómodamente tanto en Linux como en Windows, con un fichero .sh (en Linux) o .bat (en Windows). La forma de ejecutar un archivo .jar es:

java -jar Files.jar

y ya después se incluyen los parámetros (ruta fichero de datos, ruta fichero de log, distinta URL), de forma que se puede utilizar en un entorno Windows. Veamos el caso en Windows. Vamos a utilizar el directorio:

C:\ProyectoPentahoDw\SrcFiles

para guardar los ficheros, y en una carpeta dentro de él («LogFiles») para almacenar los ficheros de log. Ubicamos el fichero .jar en la carpeta:

C:\ProyectoPentahoDw

para que quede de esta forma:

Fichero .jar, fichero .bat y carpeta para almacenar los ficheros

Un fichero .bat es un fichero con comandos pero sin necesidad de escribirlos en la consola. Con ellos se consiguen realizar tareas de automatización. Para realizarlo, basta crear un nuevo documento de texto plano (es decir, con el bloc de notas, no con Word) por ejemplo pulsando en la carpeta destino el botón derecho de ratón y escogiendo «Nuevo» > «Documento de texto»:

Creando un fichero .bat

El nuevo fichero generado, se le da nombre y se le cambia la extensión, de .txt a .bat

El .bat contiene la orden para lanzar el .jar, pasando como parámetros las rutas para los ficheros de datos y log. Como vamos a seguir utilizando la misma URL, no es necesario pasarle un tercer parámetro al fichero .jar. El contenido del fichero .bat es:

Codigo del fichero .bat

Cada vez que abrimos este fichero (para editarlo y modificar los comandos, boton-derecho y escoger Editar, si pinchamos dos veces sobre el archivo se ejecuta) se ejecuta las órdenes contenidas en el mismo, en nuestro caso el fichero .jar con sus parámetros, lo que descargará el fichero de datos y nos creará el fichero de log. Hemos incluido un comando «pause» para que la consola de Windows no se cierre automáticamente. Esto solo es necesario a la hora de desarrollar el .bat, para ir viendo el retorno del comando. Una vez que vayamos a automatizar el proceso de descarga, se lanzará el .bat sin este comando «pause» (sólo irá el comando «java -jar Files.jar…»).

Los ficheros aparecen con la fecha en la que se generaron. De esta manera podemos almacenar ficheros hasta que vayan ser ejecutados (ya que cada día tiene un nombre distinto):

Ficheros .csv descargados con la clase de Java

Y además, en la carpeta «LogFile» vamos almacenando los ficheros de log:

Ficheros .log generados por nuestra clase

El contenido de los ficheros de datos, como hemos dicho, es un fichero .csv:

Contenido del fichero de datos .csv

siendo el contenido del fichero .log:

Contenido del fichero .log generado por nuestra clase de Java

Con ello hemos conseguido obtener nuestra fuente de datos y ya estamos listo para el siguiente paso: trabajar con la ETL y mover los datos a nuestra base de datos.

Actualizacion (2008-08-20)

Me he dado cuenta que la URL de Yahoo no funciona bien para el código del IBEX35, y en lugar de 35 valores, devuelve 32 valores. Por lo tanto, estoy reescribiendo la clase de Java para no utilizar Yahoo y buscar la información en alguna página web, y tratarla mediante expresiones regulares para volcarla en un fichero de texto plano, que se cargará en el data warehouse.

Actualizacion (2011-02-23): Descargar Fichero

El software para descargar automáticamente se puede descargar de aqui.

Dentro se incluye un archivo Leeme.txt que se recomienda leer, ya que incluye las instrucciones de instalación y uso del mismo.

Asimismo, os invito a dejar un comentario sobre vuestras impresiones y/o recomendaciones de mejora.

Modelado E-R

El Modelo E-R (Entidad-Relación) es un modelo de datos propuesto por Peter Chen en 1976 que busca definir los principales elementos del proceso a modelar como «Entidades» para pasar posteriormente a definir las «Relaciones» entre ellas. Una vez definidas las relaciones, obtendríamos un modelo Relacional, al que optimizaríamos sus relaciones mediante la Normalización.

Un proceso básico de Modelado E-R seguiría los siguientes pasos:

Proceso de Modelado E-R

Las finalidad de los Modelos E-R está en servir como soporte a los procesos operacionales, de ahí el enfásis en la Normalización. La normalización obtiene un modelo de datos cuyo enfásis recae en la manipulacíón de los datos ( insercción, actualización y borrado de datos).

En nuestro caso, al utilizar un modelo dimensional enfocado al análisis y toma de decisiones, donde una característica de los datos es su «no-volatilidad», y donde necesitamos optimizar la consulta de grandes volúmenes de datos, podemos utlilizar un modelo denormalizado.

Como ejemplo, vamos a realizar un Modelo E-R básico que se encuentra una empresa en su proceso de venta.

1. Identificar las Entidades: cliente, pedido, producto, vendedor. En este apartado es necesario conocer bien el Negocio, por lo que habría que mantener reuniones con la gente del Negocio para poder comprender su proceso de venta.
   

   Entidades Modelo E-R

2. Identificar los principales atributos: para «Cliente», sería nombre, apellidos, etc. Para «Pedido», identificador de pedido, estado, fecha de pedido, fecha de envío, etc. Para «Producto», tendríamos un identificador del producto, su nombre, tipo de producto, etc. Para «Vendedor», su identificador, su nombre, sus apellidos, etc.
3. Identificar las relaciones: tendríamos que «Cliente», «Vendedor» y «Producto» se relacionan a través de «Pedidos»
4. Cardinalidad: Aquí hay que volver a recoger información sobre el Negocio, ya que son ellos los que definen como son los clientes, que pueden y no pueden hacer, cuántos vendedores puede haber en un pedido, etc. Tras ello, concluimos que un cliente puede tener varios pedidos y un vendedor puede tener varios pedidos, pero un pedido solo puede tener un cliente y un vendedor. A la vez, un producto puede tener varios pedidos, y un pedido puede tener varios productos.
5. Normalizar el modelo: que no es más que utilizar un conjunto de reglas matemáticas con las que evitar las redundancias. Para la mayoría de casos, nos bastaría con cumplir las 3 primeras normas. Por lo tanto, si en nuestra Entidad «Cliente» hemos incluído como atributo «Dirección», al normalizar la tabla, debemos quitar las columnas relacionadas con «Dirección» a una tabla aparte. Por lo tanto, al normalizar nos hemos dado cuenta de que hay atributos que no dependen exactamente de la clave. Habría que realizar lo mismo con todas las relaciones, entidades y atributos, y alcanzaríamos un modelo normalizado. Asimismo, la relación N:N entre el pedido y los productos, se trasladaría a otra tabla («detalle») cuya clave sean dos claves foráneas, una hacia «pedido» y otra hacia «productos».
   

   Modelo Relacional (Normalizado)

6. Identificar los tipos de datos e índices: hay que prestar atención al rango de valores que serán incluídos así como identificar correctamente el tipo de dato que nos facilite la manipulación de la información. Un ejemplo lo tendríamos con los códigos postales. En España, el código postal es un número de cinco cifras. Podemos identificarlo como un «número entero» pero esto nos podría traer problemas en el futuro, ya que hay códigos postales que comienzan por cero («08080» es de Barcelona), y si lo tratamos como número, al almacenarlo es muy probable que se pierda el cero inicial. Por eso, sería más útil identificarlo como «texto», ya que no es necesario realizar operaciones algebráicas sobre él. Para los índices, es necesario identificar por qué columnas realizamos las búsquedas en las tabla, ya que la finalidad del índice es facilitar las mismas.
7. Optimizar el Modelo: tener en cuenta el crecimiento futuro de la tabla, la rapídez de ejecución de las consultas en la tabla, particionamientos, seguridad, etc.

Tenemos un modelo relacional que funcionará correctamente y facilitará el mantenimiento de la información de ventas de la empresa.

Modelado de datos

El Modelado de Datos (MD) es una disciplina de la Gestión de la Información encargada de la construcción de modelos de datos, que son representaciones abstractas de los datos.

Dentro del MD, encontramos 3 niveles:

1. Nivel Conceptual o de Negocio, donde se busca abstraer la forma en que el Negocio entiende la información. Es el punto de partida del modelo. Un ejemplo sería el modelo E-R (Entidad-Relación)
2. Nivel Lógico, que está orientado a las operaciones. El Modelo Relacional es un ejemplo de modelo de datos en nivel lógico.
3. Nivel Físico, representa el último nivel y en el intervienen los elementos relacionados ya con la base de datos, como pueden ser índices, tablas, etc.

En lo que respecta al objetivo, el MD busca ayudarnos con las capacidades que buscamos en los datos (comprender, documentar, comunicar, analizar, generalizar, clarificar, estandarizar, especificar e implementar).

El proceso de MD está basado en 3 elementos:

Proceso de Modelado de Datos

1. Recoger los requerimientos que debe satisfacer nuestro modelo, fundamentados en el Negocio o Proceso a modelar,
2. Planificar el proyecto, que incluiría analizar todas las fuentes de datos a considerar, posibles migraciones de los mismos, procesos de calidad de datos, etc.
3. Diseñar y construir la base de datos, último paso, con los entregables desarrollados en las 2 primeras fases (análisis, diseños).

que cubriría las fases de análisis, diseño e implementación de la base de datos.

Existen varias clases de Modelos de Datos  (jerárquico, relacional, etc.) entre los que destacan los dos más usados: el modelo E-R (y su extensión Modelo Relacional) y el modelo Dimensional.

El modelo Relacional tiene como finalidad servir de soporte a datos operacionales. Es el principal modelo de datos para aplicaciones que tienen como finalidad servir a los procesos y actividades del Negocio. Un ejemplo de base de datos relacional estaría en una base de datos donde dar soporte a los usuarios de Facebook. O gestionar el catálogo de una biblioteca. Los ejemplos son variados. Su entorno es el que las transacciones con la base de datos están caracterizadas por ser comunes tanto los INSERT, UPDATE y DELETE sobre los registros almacenados. Con el fin de optimizar la gestión de dichas transacciones, tienen que satisfacer una serie de condiciones, recogidas en un proceso conocido como «Normalización de bases de datos«, propuesto por Codd. También se busca garantizar la inexistencia de registros duplicados, mediante la utilización de claves. Si bien durante mucho tiempo se ha defendido que las transacciones sobre las que operan las bases de datos relacionales cumplieran las características ACID, hoy en día, con la aparición de fenómenos como Facebook o Twitter, sus problemas de escalabilidad han cambiado las reglas de juego, y sustituyendo ACID con conceptos como NoSQL.

El Modelo Dimensional tiene como finalidad servir de soporte a la toma de decisiones. Aquí ya no se buscan optimizar las transacciones de tipo INSERT, UPDATE ó DELETE. Debido a ello, la Normalización pierde sentido. Se busca optimizar las consultas (transacciones SELECT) de grandes volúmenes de información, por lo que se llevan a cabo procesos como el particionamiento de tablas o la ausencia de Foreign Keys.

Por lo tanto, el Modelo Relacional se utiliza en un entorno operacional mientras que el Modelo Dimensional se utiliza en un entorno de dar soporte a la toma de decisiones.

Modelo de datos dimensional: Dimensión Tiempo

Ralph Kimball nos indica que a la hora de diseñar un Data Warehouse (DW) seguimos una serie de pasos:

1. Proceso a Modelar (hecho: valores bursátiles del IBEX-35)
2. Granularidad (hecho: sociedad x día)
3. Diseño de Dimensiones (pendiente)
4. Diseño de Tabla de Hechos (pendientet).

Los dos primeros pasos ya los tendríamos, por lo que seguimos con el diseño de las dimensiones.

Cuando definimos el modelo de datos lógico, o de negocio, hicimos hincapié en que iba a tener 2 dimensiones, tiempo y sociedad, que son las que necesitamos en nuestro análisis.

La dimensión tiempo es común en el diseño de sistemas informacionales. Normalmente se busca un diseño con el punto de vista de los análisis a realizar. En nuestro caso, nos interesa analizar el valor de las acciones día a día, agrupados por semanas, meses, trimestres, años…y de ahí podemos establecer el diseño de la Dimensión tiempo, que será:

Dimensión Tiempo

Vamos a explicarla campo por campo.

1. CLAVE_TIEMPO: es un número entero que hará las veces de clave subrogada en la tabla de hechos. Es un número secuencial que se autoincrementa.
2. FECHA: con formato date es una fecha. En nuestro caso, especificaremos la hora pero no es necesario en principio en el análisis.
3. DIA_DE_SEMANA: es una cadena de texto que incluye los valores «Lunes», «Martes», etc
4. DIA_DE_MES: número entero que pertenece al rango ( 1, 31)
5. DIA_TOTAL: el número de día dentro del total de días delaño.
6. SEMANA_AÑO: número entero que representa la semana dentro del año.
7. MES: entero para indicar el mes (1, 12)
8. MES_TOTAL: entero para indicar el número de mes dentro del total de meses en el DW.
9. TRIMESTRE: número entero del rango (1, 4)
10. ESTACIÓN: cadena de caracteres, con valores «Primavera», «Verano», «Otoño» e «Invierno».

Con esto hemos definido los valores que vamos a encontrar en la dimensión Tiempo. Solo tendríamos que ejecutar un script dimension_tiempo.sql con el código SQL:

para tener nuestra tabla de dimension a punto.

El siguiente paso sería llenarla con los valores de dimensión.

Ficheros .csv (comma separated values)

Los ficheros con formato .csv (comma separated values) son utilizados para el intercambio y la conversión de datos entre programas, bases de datos, etc. Los distintos valores van entrecomillados y separados comúnmente por comas/punto y comas  (otros valores que pueden actuar como separadores son el tabulador, numero fijo de espacios, etc.).

Aunque no existe una especificación única para este formato, las características comunes son:

1. Cada registro está situado en una línea, delimitada por un retorno de carro y un salto de línea (CRLF).
2. El último registro del fichero podría no tener este retorno de carro/salto de línea.
3. Las dobles comillas son utilizadas para encerrar los valores dentro de un campo. Se utilizan cuando existan valores que deben ser considerados parte del campo, como pueden ser espacios, puntos y coma o comas como signos ortográficos, retornos de carro dentro del campo, etc. Son descartadas a la hora de leer el valor.
4. Puede existir una primera línea que actúe como cabecera que indique qué es cada columna, con el mismo formato que las líneas de registros, y el mismo número de campos. Al igual que las dobles comillas.
5. Cada línea debe contener el mismo número de campos. Los espacios son considerados como parte de un campo. Los campos para los que no existan valores, tienen que estar incluídos.

Un ejemplo de fichero en formato .csv sería un fichero de texto con estos valores (el carácter CRLF no es visible en muchos programas):

«abc», «123», «ABC» CRLF

«def», «456» «DEF» CRLF

«ghi», «789», «GHI»

Pueden ser generados por una gran cantidad de programas, como editores de hojas de cálculo (Calc, Excel), programas de edición de texto (UltraEdit, Notepad), ficheros de exportación de bases de datos, etc.

Su codificación no es únicamente ASCII, pudiendo emplear mayores conjuntos de caracteres como UTF-8, etc.

URL de Yahoo Finanzas (explicación)

Para construir la URL con la que solicitar el fichero de datos a Yahoo Finanzas, tenemos que, a partir de la URL de Yahoo Finanzas,

http://es.old.finance.yahoo.com

añadir una serie de parámetros, cuyo esquema sería:

http://es.old.finance.yahoo.com/d/quotes.csv?s= + [simbolo sociedad] + &f= +[parámetros columnas]

Pongámos un ejemplo. Imaginemos que queremos solicitar los datos de Telefonica. Vamos a la página de Telefonica para conocer su simbolo:

Informacion bursátil sobre el valor "Telefonica" en Yahoo Finanzas

En este caso sería «TEF.MC». Bien, pues ya tenemos la primera parte de la URL:

http://es.old.finance.yahoo.com/d/quotes.csv?s=TEF.MC

Vayamos ahora con los valores a solicitar. Como dijimos aquí, queremos que el fichero incluya los datos de «Simbolo», «Último Precio», «Tiempo», «Fecha», «Precio Apertura», «Precio Cierre», «Máximo Diario», «Mínimo Diario», «Volumen», que teniendo en cuenta los valores mostrados en esta tabla,

Parametros URL Yahoo Finanzas

Parametros URL Yahoo (Cont.)

serían «sl1d1t1c1ohgv». Con ello tenemos la segunda parte de la URL:

http://es.old.finance.yahoo.com/d/quotes.csv?s=TEF.MC&f=sl1d1t1c1ohgv

Quedaría únicamente añadir el formato del fichero (fichero .csv) y ya tendríamos la URL:

http://es.old.finance.yahoo.com/d/quotes.csv?s=TEF.MC&f=sl1d1t1c1ohgv&e=.csv

Que si introducimos en un navegador, obtendremos el siguiente resultado:

Que es un fichero .csv con las columnas arriba indicadas.

Fácil, ¿no?

Pues esto es lo que vamos a utilizar como fuente automática de datos.