viernes, 23 de septiembre de 2011

Modelización de datos en Excel (2)


Durante este tutorial vamos a trabajar sobre un ejemplo supuesto muy sencillo:

Un Director Financiero quiere construir una aplicación en Excel para tener un control de las nóminas que se van generarndo mes a mes de los empleados (producción, comerciales, administrativos y gerencia) y sus remuneraciones (fijas, horas extra y comisiones), así como de los pagos realizados a los trabajadores.

¿Cómo se modelizan los datos en Excel?

Como se decía en el artículo precedente a este (Modelización de datos en Excel), para modelizar y montar una estructura de datos adecuada, es necesario organizar los datos agrupándolos, según unos criterios determinados, mediante tablas de dos tipos:

1) Tablas de hechos (fact tables)

En estas tablas deben ir los datos que representen los hechos principales a medir y a vigilar mediante indicadores. Suelen ser los datos que se multiplican en mayor cantidad a medida que pasa el tiempo, luego también suele ser imprescindible que en una tabla de hechos exista como mínimo un campo de fecha y otro que represente el hecho en sívalorado en euros. En otras palabras (y simplificando para entenderlo mejor), los datos de las tablas de hechos suelen expresar: ¿cúando ha ocurrido un hecho? y ¿qué valor tiene el hecho?.

En nuestro ejemplo de aplicación para el control de nóminas, el hecho principal es que cada mes se generan una serie de nóminas en la empresa. Las nóminas podrán ser de un trabajador u otro, pagarse mediante una cuenta de tesorería u otra, pero cada mes se generan nóminas... y así... indefinidamente. Es una tabla que multiplicará sus registros muy rápidamente y cada registro (cada hecho) es una nómina que está asociada a una fecha de generación (el último día de cada mes). En definitiva, la Tabla de Hechos será la tabla de nóminas generadas con los siguientes campos, por ejemplo:


Fecha Nómina: La fecha de devengo de la nómina. Normalmente el último día del mes.
Devengos: Suma de las cantidades principales que componen la nómina (salario base, antigüedad, etc.)
Horas: Horas extras a incluir en la nómina.
Incentivos: Comisiones y similares por productividad o ventas.
S.Social: Deducción de la Seguridad Social que va a cargo del trabajador
IRPF: Deducción del IRPF que corresponde al trabajador por su nómina.


Podemos observar que, los datos que de momento se han incluido en la tabla de hechos son los que cumplen las siguientes condiciones:

  • Todos los meses varían. Es decir, la fecha, el importe devengando, el IRPF, etc... siempre varían en cada nómina. Podría hacerse una lista muy larga de fechas e importes, sólo limitada por la duración de la vida de la empresa.
  • Las cantidades (devengos, horas, comisiones e IRPF) y la fecha de cada nómina son lo que queremos cuantificar y son los datos protagonistas.

2) Tablas de dimensión (dimensión tables)

Cada una de las tablas de dimensión debe contener los valores que definen a los hechos diciendo quién los ha realizado y qué características tienen.


Por ejemplo, el dato: Comisión = 105,56 € en 31/01/2011 no tiene utilidad "per se", sino que necesita de otros datos complementarios (dimensiones) que expliquen quién ha recibido la comisión y por qué entidad financiera se pagará. Las dimensiones son aquellos conceptos por los que después se consultará en los informes: es frecuente que un Director Financiero quiera consultar las comisiones por cada comercial, las nóminas por cada área o departamento, etc.


En otras palabras (y simplificando para entenderlo mejor), las tablas de dimensión suelen decir ¿qué tipo de hecho ha ocurrido? ¿quién hay detrás del hecho?

Claves primarias (primary keys)

Las tablas de dimensión necesitan que uno de los campos sea una clave primaria o primary key para que cada registro quede identificado inequívocamente. Esto significa que en ese campo NO PUEDE HABER DUPLICADOS. En el mundo del Business Intelligence, las claves primarias suelen ser números enteros que se generan mediante autonumeración (por norma y aunque haya campos en cuyos registros no haya duplicados), pero en Microsoft Excel y dado que no es una aplicación diseñada como base de datos relacional, debemos flexibilizar algunas normas y esta es una de ellas: si en una tabla de dimensión hay un campo que contiene datos para los que no va a haber duplicados, lo aprovecharemos como clave primaria, pero si no lo hay, agregaremos uno "ad hoc" cuyo contenido sea preferentemente significativo, no demasiado largo y por supuesto, sin duplicados. Veremos esto a continuación y sobre la práctica de ejemplo.

Para nuestro ejemplo y de momento, construiremos 2 tablas de dimensión:

1) La tabla de trabajadores será una de las dimensiones que defina quién está detrás de cada nómina y los datos íntimamente relacionados con cada trabajador (fecha de nacimiento, situación laboral, etc.)


ID Nombre trabajador: Apellidos y Nombre del trabajador, que será la clave primaria (ID), puesto que es imposible que nos veamos obligados a poner un mismo nombre a 2 trabajadores de una misma empresa. Es decir, no habrá duplicados.
Fecha nacimiento: Fecha de nacimiento del trabajador.
Situación: Alta, Baja o Enfermedad.
Ultima fecha: Última fecha de cambio de situación.

2) La tabla de cuentas de tesoreria


ID Tesorería: Código de la cuenta de tesorería. Este campo se ha creado "ad hoc" porque es ciertamente posible que una empresa pueda tener dos cuentas de tesorería en una misma entidad financiera, o bien que maneje varias cuentas de efectivo de caja (como es el caso del ejemplo). Por lo tanto, el nombre de la tesorería (que es el siguiente que explicamos) no nos sirve como clave primaria.
Nombre tesorería: Nombre de la entidad financiera o de la cuenta de efectivo.
Cuenta: Nº de cuenta de tesorería.

En el siguiente post, nos adentramos algo más en otras teorías del Business Intelligence para conocer las principales formas (esquemas o diagramas) que hay de relacionar las tablas que hemos creado. Concretamente veremos el Esquema en Estrella y el Esquema en Copo de Nieve. Previamente se estudiarán las claves que debe contener una tabla de hechos (claves externas).

Artículos relacionados:

Modelización de datos en Excel
Modelización de datos en Excel (3)
Modelización de datos en Excel (4)
Modelización de datos en Excel (5)


  José Manuel Pomares Medrano


No hay comentarios:

Publicar un comentario en la entrada