Conceptos básicos de un modelo de datos

A veces no disponemos de todos los datos en una sola tabla, como hemos visto en las clases anteriores, sino que tenemos que combinar información de diferentes tablas. Por ejemplo, en la Tabla 1 tengo la información de las reservas de nuestros trenes. Tenemos el número de tren, la clase, el Origen-Destino, y el código de reserva (PNR). Sin embargo, no tenemos la información del punto de venta donde se realizó la reserva dado que este dato se suele recibir a parte y no está en nuestras bases de datos. En la Tabla 2 tenemos el código de reserva y el nombre del punto de venta. Para relacionar la información, por ejemplo, ver en qué punto de venta se han reservado los pax de un tren, tenemos dos opciones:

• Combinar las dos tablas con SQL o Power Query y cargar en nuestro fichero Excel una sola tabla con todo;
• Descargar las dos tablas y crear un modelo de datos “en vivo” en Power Pivot (Teoría Avanzado);

Veremos cómo hacerlo en la práctica más adelante, pero de momento necesitamos entender bien algunos conceptos de bases de datos.

COMBINAR Y ANEXAR CONSULTAS

El segundo caso es cuando queremos juntar tablas, pero con información diferente. En el ejemplo anterior hablábamos de una tabla con los datos de una reserva (Tabla 1) y en la otra tabla, los puntos de venta de estas reservas (Tabla 2). En este caso queremos ampliar la información de cada fila para que incluya el punto de venta, mientras que cuando anexamos queremos añadir más información a las columnas. A la hora de combinar unas tablas hay unas cuestiones importantes a tener en cuenta:

• Siempre cruzamos sólo dos tablas a la vez, y si queremos combinar una tercera, deberemos hacer un segundo cruce sucesivo.
• El orden también es importante, es decir que debemos tener claro cuál es la Tabla 1 y la Tabla 2.
• Normalmente la primera tabla es las “más importante” y la segunda es de donde queremos sacar información adicional.
• Para cruzar las tablas hay que definir uno o más campos en común. Cuando definimos más de un campo en el cruce, la combinación de campos tiene que coincidir para que se combinen las filas.

A continuación, explicaré los principales tipos de cruces que podemos hacer. Para la siguiente explicación, por simplicidad, vamos a suponer que hay una relación de “1:1”, es decir que cada fila de una tabla corresponde a una fila de la otra tabla.

Inner join (combinación interna): sólo los datos en común de las dos tablas. Este es el tipo de combinación más común y la que vas a necesitar normalmente.

Outer join (combinación externa): total de datos de las dos tablas, las columnas que no tiene información en la otra tabla tendrán un valor “nulo”, o vacío.

Left join (combinación externa izquierda): todos los datos de la primera tabla, solo los datos en común de la segunda tabla.

Right join (combinación externa derecha): todos los datos de la segunda tabla, solo los datos en común de la primera tabla.

Anti left-join (combinación anti izquierda): solo los datos de la primera tabla que no son en común con los datos de la segunda tabla. Existe también la combinación anti derecha que viene a ser lo mismo, pero con las tablas al revés.

Retomando nuestro ejemplo anterior de reservas y puntos de venta, ¿qué tipo de cruce debemos utilizar?

Si la información fuera perfecta, es decir en caso de recibir todos los datos de puntos de venta para poder cruzarlo, un “inner join” sería lo apropiado. Sin embargo, no siempre se reciben todos los códigos de reserva (PNR) de los puntos de venta para cruzarlos con nuestros datos de venta, así que, si optamos por un “inner join”, algunas de las ventas en nuestra tabla principal desaparecerían si no tienen su correspondiente en la segunda tabla. En este caso, es mejor usar un “left join”. Cuando no recibimos la información del canal de venta de alguna reserva, los campos combinados estarán “nulos” y nos podremos dar cuenta de que no tenemos el dato, sin perder ninguna reserva a la hora de hacer un total.

Hasta ahora hemos hablado de una relación 1:1 (llamada cardinalidad), cada PNR en la tabla de reservas corresponde a un PNR en la tabla de puntos de venta. ¿Pero qué pasaría si tuviéramos dos PNR en una de las tablas? Es significa que el número de filas se multiplica. Hacer el cálculo es simple, los PNR de la Tabla 1 multiplicados los PNR de la Tabla 2: 1×2 o 2×1 = 2. Tendríamos dos filas.

Ahora bien, en nuestro ejemplo concreto, si tenemos los 2 PNR en la primera tabla todo saldría correctamente dado que cada fila representa una reserva (o parte de una reserva que se ha dividido en dos por alguna razón), tiene que seguir habiendo dos filas con sus pasajeros e ingresos. A estas dos filas vamos a añadir el dado del punto de venta que será asociado a un solo PNR.

Sin embargo, si tenemos una fila en la tabla de reservas, y dos en la tabla de puntos de venta, esto es un problema. Esto significa que tenemos una sola reserva, pero en la tabla de puntos de venta esta misma reserva corresponde a dos puntos de venta. A parte de que lógicamente no tendría sentido, pero en la práctica lo que supone es que se dupliquen las filas de nuestra Tabla 1, duplicando las reservas.

Si tuviéramos, dos filas en una tabla con mismo PNR y dos filas en la otra tabla con el mismo PNR, tendríamos un total de filas en la tabla combinada de 2×2 = 4. Con estos ejemplos acabamos de ver relaciones que no son “1:1”, sino relaciones que son “N:1”, “1:N” y “N:N”. Por el momento es importante entender cómo se duplican las filas en estos casos, para saber cuál será el resultado del cruce. Si el cruce no produce los resultados esperados deberemos modificar una de las dos tablas, por ejemplo, eliminando algunos campos, agregando los datos, o filtrándolos.

CREAR UN MODELO DE DATOS

La segunda manera de combinar diferentes tablas es a través de un modelo de datos. Un modelo de datos es un conjunto de tablas relacionadas entre sí a través de unos campos específicos (llamados claves) y unas cardinalidades específicas (lo que vimos de 1:1, N:1 etc.). Además, podemos establecer jerarquías entre campos, por ejemplo, las jerarquías de fecha (año, mes, fecha). A diferencia de la manera explicada anteriormente, en este caso no se genera una tabla única con todos los datos, sino que las tablas se mantienen separadas, pero a la hora de utilizar los dato, por ejemplo, en una tabla dinámica, el resultado tendrá en cuenta el cruce entre ellas.

La tabla de hechos contiene básicamente las métricas que queremos analizar (número de reservas, pasajeros, ingresos, visitas a la página web etc.), mientras que las tablas de dimensiones contienen la información de “cómo queremos analizar los datos” o, dicho de otra manera, los atributos asociados a la información en la tabla de hechos.

Cada tabla contiene una clave primaria que identifica cada entidad (fila) de manera única, y tendrá una o más “claves foráneas” (Foreign Key) que son los campos de relación con las otras tablas. Las relaciones entre tablas se realizan entre una clave foránea (en la tabla principal) y una clave primaria de la tabla secundaria. Por ello, estos tipos de modelos suelen tener relaciones 1:1 o 1:N. En la imagen vemos una tabla de hechos relacionada con varias tablas de dimensiones, que a su vez pueden estar relacionadas con otras tablas de dimensiones.

La cardinalidad entre las tablas suele ser de 1:1 o 1:N donde la tabla de hechos es el “N”. En nuestro ejemplo de reservas de trenes, las tablas de dimensiones que incluiríamos pueden ser:

• Fechas: fecha de viaje, mes de viaje, año de viaje etc..
• Origen-Destino: información sobre cada origen-destino como la distancia, que tipo es, si es internacional o nacional etc.
• …

El hecho de separar esta información en tablas de dimensiones permite reducir la redundancia y el volumen de datos. Imagina todos los campos relacionados con la fecha (año, mes, día del año, día de la semana, cuatrimestre etc.). Si tenemos una tabla de dimensiones de fechas esta información se repite sólo para cada fecha, mientras que, si todos estos campos se repiten en la tabla de hechos, como hay fechas duplicadas, esta información se repetiría varias veces.

A veces, podemos tener más tablas de hechos, por ejemplo, cuando las métricas que queremos analizar proceden de tablas diferentes. Imaginemos el ejemplo donde queremos relacionar los datos de nuestras reservas del tren con datos de la competencia. En este caso tendremos dos (o más) tablas de hechos que se relacionarán entre si a través de tablas de dimensiones comunes. No es aconsejable juntar directamente dos tablas de hechos por dos razones:

• Deben tener una columna común con una cardinalidad de 1:1 (de lo contrario, si fuera 1:N o N:1 estaríamos duplicando los valores de una de las dos tablas).
• Si tienen dimensiones comunes, unir las dos podría crear problemas de ambigüedad, es decir que el modelo no sabe bien qué hacer si filtras algo en una tabla dado que hay una relación “circular” con otras tablas.

En nuestro ejemplo anterior (tren y competidores) relacionaríamos las dos tablas a través de tablas de dimensiones por ejemplo una tabla de fechas y una tabla de Origen-Destino. Si quisiéramos relacionar estas tablas directamente Power Pivot no lo permitiría porque no permite las relaciones de muchos a muchos (N:N), y tendremos que utilizar una especie de tabla puente, o varias tablas de dimensiones que relacionan las dos. Si usas Microsoft Power BI, sin embargo, verás que se permite este tipo de cardinalidad, pero hay que tener cuidado a la hora de usarlo porque puede confundir al usuario final y puede haber diferencias si la columna de relación no tiene los mismos elementos en las dos tablas. De todas formas, para crear un modelo de datos bien estructurado, por lo general se desaconseja crear relaciones N:N, a menos que no sea indispensable.

Otro concepto importante es la dirección de la relación entre tablas, o dirección de filtro cruzado. Esto determina la propagación de los filtros, es decir si la relación va de la tabla de fechas a la tabla de ventas, entonces al filtrar una fecha en la tabla dinámica, se filtrarán las ventas correspondientes. Sin embargo, si filtráramos algo en la tabla de ventas, este filtro no aplicaría a la tabla de fechas. Power Pivot sólo permite una dirección única desde la tabla de dimensiones (1) hacia la tabla de hechos (N). En caso de tener una cardinalidad de 1:1 podemos elegir el sentido de la dirección. En Power BI, además de elegir una relación N:N, es posible establecer que el filtro se propague en ambas direcciones, sin embargo hay que tener cuidado y entender bien las implicaciones que esto supone.

Además de las relaciones, dentro de cada tabla puedes establecer una jerarquía, por ejemplo: Año, Cuatrimestre, Mes, Fecha. Las jerarquías son útiles a la hora de analizar los datos, dado que permiten explorar en profundidad los datos por jerarquía. Por ejemplo, en las tablas dinámicas podemos dar al botón “+” y “-“ para expandir o reducir el detalle de la fecha.

En conclusión, hemos vistos dos maneras de cruzar datos, crear una tabla única con SQL o Power Query, o crear un modelo de datos en Power Pivot. Pero ¿Cuál de las dos formas es mejor?

Depende del uso que le vayas a dar y de la cantidad de datos. Si hablamos de pocos datos, no hay realmente diferencia y las dos opciones son válidas, depende de cómo te sientas más cómodo. Si tenemos muchos datos (millones de filas y muchas tablas que cruzar) ya depende del uso que le des. Como regla general, si quieres priorizar la rapidez de actualización y limitar la redundancia de datos, opta por un modelo de datos en Power Pivot. Si quieres priorizar la rapidez de las tablas dinámicas, tener muchos cruces (en particular cuando una tabla de dimensiones se relaciona con otras tablas de dimensiones) no ayuda.