Volúmen II

MEJORES PRÁCTICAS SQL

MODELADO DE DATOS
Ebook

datalytics.bi datalytics.mejorcondatos Datalytics Datalytics

datalytics.com
 Mejores prácticas SQL 02

ÍNDICE
Introducción - ¿Qué es el modelado de datos? 03

Conceptos básicos I: OLTP vs. OLAP 04

Conceptos básicos II: Tablas de hechos y dimensiones 06

Modelo estrella y modelo copo de nieve 08

¿Cómo construir un data warehouse? 10

Dimensiones lentamente cambiantes 13

Técnicas más avanzadas I: Dimensiones degeneradas 16

Técnicas más avanzadas II: Dimensiones basura (o Junk Dimensions) 17

Técnicas más avanzadas III: Tablas de hechos sin hechos (o Factless) 18

Errores frecuentes I: Distinta granularidad 19

Errores frecuentes II: Múltiples monedas 20

Errores frecuentes III: Marcas para misceláneos 21

Conclusiones 22
 Mejores prácticas SQL 03

Introducción
¿Qué es el modelado de datos?
En este ebook les traemos las Mejores Prácticas en modelado de datos que usamos en Datalytics. El
tema genera mucho interés en la comunidad de datos porque no es algo que esté del todo estandarizado y,
en general, no se enseña en las universidades/cursos.

A continuación, van a encontrar conceptos teóricos que les van a ayudar mucho, pero es importante que
sepan que el modelado de datos es algo que se aprende haciendo. Por lo tanto, luego de leer este conteni-
do, esperamos que pongan manos a la obra.

Vamos a empezar con un poco de filosofía.

Modelar datos es tomar una realidad y representarla a partir de un criterio. El mismo concepto se
puede modelar de distintas formas y en esa interpretación se juega nuestra subjetividad.

Este proceso implica conciliar muchas diferencias. (Sirve para los datos, sirve para la vida. )

El modelado no tiene que ver con la tecnología, sino con la lógica. Si nuestro modelo lógico tiene
sentido, el físico también lo tendrá. Sí, por el contrario, el modelo lógico carece de criterio, el físico no
va a servir para nada.

Trabajamos con datos para lograr que las personas tomen decisiones a partir de ellos.

Los conceptos que vamos a ver son sencillos de entender, sin embargo, se aplican a problemas que
pueden ser muy complejos.

Construir una única versión de la realidad es la problemática más difícil que nos va a tocar enfrentar.
Por eso, lo principal es entender cuál es el objetivo de lo que estamos modelando.

Lo primero que tenemos que preguntarnos es: ¿cómo vamos a usar los datos? (¿para almacenarlos?
¿para analizarlos? ¿para extraerlos? Etc. Etc.) Una vez respondida esta pregunta podemos comenzar.
 Mejores prácticas SQL 04

Conceptos básicos I
OLTP vs. OLAP
Los sistemas transaccionales (OLTP) son para ALMACENAR los datos y los analíticos (OLAP) son para
ANALIZARLOS.

OLTP

La prioridad es poder insertar rápido los registros. Por ejemplo, los datos que recibe la caja registrado-
ra de un supermercado, ya que cualquier demora en este proceso generaría largas filas (y mucho mal
humor ).

Estos modelos almacenan rápido, por eso están orientados a la normalización y evitan que se
dupliquen los datos. En ellos las operaciones más comunes son de INSERT, UPDATE y DELETE, por
eso se necesitan tablas que sigan los estándares de normalización para que la ejecución sea correc-
ta.

Las consultas son a nivel registro y determinan quién hizo qué. (Ejemplo: ¿Esta transacción ocurrió?
¿es válida o es falsa?)

Los sistemas más comunes que necesiten una operación de los datos rápida en cuanto a registro,
actualización y borrado son TRANSACCIONALES y están modelados de esta manera. Por ejemplo:
los sistemas ERP, los CRM, los cajeros automáticos, etc.

OLAP

Está orientado a la LECTURA de los datos, la idea es obtenerlos de manera rápida para después poder
hacer algo con ellos (uso frecuente de sentencia SELECT ).

No importa de dónde vengan los datos, lo importante es nuestro objetivo, ¿PARA QUÉ los modela-
mos?, por eso está orientado a temas. Recuerden que no se modela por sistema origen, en un
modelo OLAP pueden integrar diferentes fuentes para tener una visión general de, por ejemplo, el
cliente.

La estructura está desnormalizada (sí, algo que en muchas carreras de tecnología se considera una
aberración , pero es lo que hay que hacer para que la lectura sea rápida ).

Lo que importa es registrar cómo varían los datos a lo largo del tiempo. Por ejemplo: cómo fue el
consumo de luz en determinado mes.

¡No vale hacer DELETE! La info no se modifica ni se elimina ya que, si lo hacemos, vamos a cambiar la
realidad que modelamos. Las modificaciones no son gratis en OLAP, mucha atención a eso.
 Mejores prácticas SQL 05

OLTP vs. OLAP

Online Transaction Processing Online Analytical Processing

Integración &

consolidación

OLTP OLAP

ORIENTADO A: ORIENTADO A:
. Más transacciones . Grandes volúmenes de datos
. Almacenamiento rápido . Operaciones de lectura principalmente
. Normalización . Desnormalización
. Consultas a nivel registro . Consultas de agregación
. ¿Quién hizo qué? . ¿Cuántas personas hicieron qué en
este período de tiempo?
 Mejores prácticas SQL 06

Conceptos básicos II
Tablas de hechos y dimensiones
En este apartado vamos a ver qué es el MODELADO DIMENSIONAL, cómo se compone y por qué es tan
importante.

Es un tipo de sistema OLAP que busca responder consultas en las que lo que importa es analizar algo
(¿cómo se distribuyen las ventas?, ¿por qué bajaron?, ¿por qué subieron?, etc.)

Sirve para analizar los datos a escala en volumen. Recuerden que la única forma de escalar es con
orden y con un buen modelo de datos que permita hacer las cosas más fáciles.

Tiene que ser rápido y fácil de interpretar (para complicar las cosas ya habrá tiempo ). Recuerden
que la performance es un factor fundamental.

Si hacen un buen modelo lógico, el físico va a ser bueno. En cambio, si el modelo lógico es malo,
no habrá forma de rescatarlo , salvo con más hardware, algo que hace que las cosas no escalen
lo suficiente.

El modelo dimensional tiene dos partes:

HECHOS

Son las cosas que pasaron que nos interesa modelar (ventas, stock, reclamos, etc.)

Están compuestos por medidas, son numéricos.

Todo lo que sucede se almacena en la tabla de hechos.

Responden a la pregunta: ¿qué es lo que estoy midiendo?

DIMENSIONES

Son las características de los hechos (quién, qué, cuándo, dónde, cómo, por qué).

Tienen atributos (nombre, apellido, número de documento, teléfono, dirección, etc.)

A veces, tienen jerarquías que pueden ser, por ejemplo, de tiempo (día, mes año), de familia de
productos (tipo, marca, modelo), de segmentación de clientes, etc.

Responden a la pregunta: ¿cómo mido las cosas?

Entonces, en el modelado dimensional recuerden: orden ante todo y un buen diseño.

 Mejores prácticas SQL 07

Modelo dimensional
hechos y dimensiones

FECHA PRODUCTO

IdFecha Tabla de hechos/Fact Table IdProducto

Anio DescripcionProducto
Semestre TamanioProducto
Tabla de dimensiones

Tabla de dimensiones
Mes TipoPaquete
Dia Categoria
Descripcion ID FECHA
IndicadorFestivo
ID PRODUCTO
ID SUCURSAL
ID PROMOCION
SUCURSAL PROMOCIÓN
IdPromocion
DescripcionPromocion
IdSucursal Descuento
NombreSucursal CantVentas FechaInicio
GerenteSucursal ValorVentas FechaFin
CiudadSucursal
TotalM2
 Mejores prácticas SQL 08

Modelo estrella y modelo copo de nieve

El modelo a elegir dependerá de cómo usen los datos y de las herramientas con las que los exploten. Un
consejo: empiecen siempre con un modelo estrella y después, si es necesario, evolucionen hacia un
modelo copo de nieve que les permita explotar mejor ciertas dimensiones.

MODELO ESTRELLA (STAR)

Es el más sencillo, los hechos van en el centro y las dimensiones alrededor. 

TODOS los niveles de la dimensión están contenidos en la tabla de dimensiones. 

Introduce redundancia de datos. Desnormalización de la información. 

Simplifica las consultas y la indexación. 

Usen las claves técnicas (o subrogadas) porque los joins mejoran el rendimiento . No usen los ID
de negocios.  

Tengan en cuenta que no todo es una dimensión, piensen bien cuáles deben ser funcionales a las
necesidades del modelo.

FECHA SUCURSAL

Tabla de dimensión Tabla de dimensión

VENTAS
Tabla de hechos

PRODUCTO PROMOCIÓN
Tabla de dimensión Tabla de dimensión
 Mejores prácticas SQL 09

Modelo estrella y modelo copo de nieve

MODELO COPO DE NIEVE (SNOWFLAKE)

Es más complejo.

Todos los niveles de la dimensión pueden estar en tablas separadas.

Normaliza las dimensiones, evitando la redundancia de datos.

Simplifica la reutilización de algunas dimensiones para las agregaciones. 

La pregunta del millón al momento de modelar bajo este esquema: “¿hasta qué nivel tiene sentido
seguir normalizando las dimensiones?” Dependerá del criterio de quien diseñe, pero…

TIP: Si tienen dimensiones muy pesadas (ejemplo con muchos productos) lo mejor va a ser
explotarlas para alivianarlas. Es decir, llevarlas a un esquema de copo de nieve (productos/fami-
lia/proveedores, etc.) Esto no significa que todas las dimensiones tienen que estar explotadas, sino
que van a explotar solo aquellas que tengan sentido para lo que hagan. Esto dependerá de la forma
de consumo, por ejemplo, si la herramienta de reportería soporta Copo de nieve.

Para cerrar, como ya les dijimos: el principal desafío a la hora de modelar es construir una ÚNICA
versión de la realidad y esto no tiene nada que ver con la tecnología (¡ojalá así fuera!) 

En el modelado es dónde realmente tenemos que entender CUÁL es el OBJETIVO DE LO QUE ANALIZA-
MOS, sólo así el producto que hagamos será útil.

Categoria Marca
Zona Region
Color PRODUCTO SUCURSAL
Barrio Municipio
Tamanio

VENTAS
Tabla de hechos

Anio Mes

Semana DIA PROMOCION Tipo_promocion

Semana_fiscal

Mes_fiscal

Anio_fiscal
 Mejores prácticas SQL 10

¿Cómo construir un data warehouse?

Si trabajan en un entorno de data lake o Lakehouse, esto aplica igual. Hoy tenemos la posibilidad de cons-
truir usando de base muchas tecnologías e inclusive arquitecturas, sin embargo, siempre habrá una capa
de datos consolidados (llámese data warehouse, capa de negocio, capa de oro o como más les guste). Por
eso el concepto de modelado dimensional (aka “data warehouse”) está más presente que nunca .

Para explicarlo simple: hacer un data warehouse es construir una única versión de la realidad. Para eso hay
que consolidar las dimensiones de los modelos y —lo más difícil— conciliar las diferencias de criterio entre
las áreas o las personas.

Si los datos son el activo más importante de una organización, tenerlos limpios e integrados entre sí será
clave para poder utilizarlos cuando los necesiten.

Veamos los conceptos clave en orden:

DATA MART
Es un modelo de datos que representa un objeto de estudio en particular. Es decir, es la visión desde
el punto de vista de los datos de una problemática de negocios en particular. Puede ser desde algo
ambicioso como las ventas, el stock, las finanzas hasta cosas más puntuales como las campañas
comerciales, un proyecto en particular, etc.

En su versión más simple, no será más que una tabla de hechos con sus dimensiones.

Del data mart al data warehouse

Proveedor Ordenes de compra Centro distribución

Tabla de dimensiones Tabla de hechos Tabla de dimensiones

Fecha Producto
Tabla de dimensiones Tabla de dimensiones

Stock Ventas Sucursal Promocion

Tabla de hechos Tabla de hechos Tabla de dimensiones

Sucursal
Tabla de dimensiones

Transporte Despachos
Tabla de dimensiones Tabla de hechos
 Mejores prácticas SQL 11

Dimensiones consolidadas (o conformadas)

A medida que construyan distintos Data Marts, con seguridad, surgirán distintas perspectivas para los
mismos conceptos: que la definición de cliente para el área de marketing es una distinta a la que
utiliza el área de operaciones, etc.

Será clave en el proceso de modelando, ir consolidando las dimensiones a medida que van modelan-
do nuevas problemáticas de negocio.

Llevemos esto a la práctica: supongamos que tenemos un Data Mart comercial con una tabla de
hechos y diferentes dimensiones (fecha, producto, sucursal, promociones, etc.) Si estuviéramos
modelando el Data Mart de operaciones y en particular construyendo la tabla de hechos que almace-
nará los movimientos de stock, con seguridad habrá algunas dimensiones del Data Mart de ventas
que sí nos importarán y otras que no.

Sería un error de diseño –muy feo– NO reutilizar las dimensiones que ya tenemos. Si ya creamos las
dimensiones de fecha, producto, sucursal, etc. para analizar las ventas, al momento de analizar stock
NO hay que crear nuevas dimensiones: ¿qué debo modificar o extender de las dimensiones existentes
para poder dar soporte al nuevo análisis?

El desafío será: consolidar todo eso en el mismo modelo y conciliar las diferencias entre áreas: ¿qué
es un producto para comercial? ¿y para operaciones?

Recuerden: Hay que modelar la realidad conciliando las diferencias, eso es lo más complejo .

FECHA

Dimensión Fact INVENTARIO

PRODUCTO ID FECHA
ID PRODUCTO
ID SUCURSAL
Dimensión

SUCURSAL
Fact VENTAS
Dimensión
ID FECHA
ID PRODUCTO
PROMO ID SUCURSAL
ID PROMO
Dimensión

Tablas de hechos independientes para representar cada

proceso de negocio / objeto de análisis.
 Mejores prácticas SQL 12

Bus Matrix
Es mucho más sencillo de lo que parece, es una forma de graficar la consolidación de las dimensio-
nes. Se grafica cruzando los Data Marts con sus dimensiones como muestra el gráfico de abajo.

Lo arman a medida que modelan y sirve justamente para identificar aquellas dimensiones que tienen
que reutilizar, conciliando las diferencias si las hubiera. En caso que no lo hagan, el Bus Matrix se va a
encargar de mostrarlo de forma muy evidente: por ejemplo, mostrando la dimensión cliente_marke-
ting y la dimensión cliente_operaciones.

Ordenes de compra

Inventario

Ventas de almacen

Fecha Producto Sucursal Promocion Centro_Distribucion Transporte

 Mejores prácticas SQL 13

Dimensiones lentamente cambiantes

En inglés se conocen como SCD (Slowly Changing Dimensions). Se trata de un clásico que muchas veces se
menciona, pocas se entiende y rara vez se piensa, por eso vamos a echar un poco de luz sobre el tema.

Tengamos en cuenta que siempre vamos a tener que gestionar la historia de las dimensiones. Los atributos
cambian —las personas se mudan, los nombres de los productos se modernizan, los precios cambian— y no
podemos pretender que las dimensiones se mantengan estáticas.

Recuerden que cuando modelamos, no podemos cambiar los hechos porque eso sería modificar el pasado. Por
lo tanto, tenemos que evolucionar la historia de las dimensiones, es decir, los ATRIBUTOS de los hechos. 

Para eso aparecen las dimensiones lentamente cambiantes que son formas de modelar el manejo de la historia.

Hay tres tipos de dimensiones bien diferentes y *SPOILER ALERT* pensar que todas se manejan igual es un
error grave. Veamos en qué consiste cada una:

TIPO 1

Son las más fáciles (¡ojalá todas fueran de este tipo!)

Son las indicadas en caso que NO nos importe la historia de lo que vayamos a analizar. Por ejemplo,
un error de tipeo o una falta de ortografía en un nombre o apellido.

Se actualizan haciendo un UPSERT: insertamos los nuevos registros y modificamos los que haya que
cambiar. 

ID CLIENTE NOMBRE APELLIDO SEGMENTO

1 Pavio Sanfilipo Alto Consumo

ID CLIENTE NOMBRE APELLIDO SEGMENTO

1 Pablo Sanfilipo Alto Consumo

La nueva información sobrescribe la vieja información.

No se guarda histórico. La información de los estados anteriores no es guardada.

Se utiliza cuando no es necesario mantener un histórico, es decir,

cuando no se necesita la traza de los cambios.
 Mejores prácticas SQL 14

Dimensiones lentamente cambiantes

TIPO 2

Nos importan todos los cambios en la historia del dato. La nueva información se agrega a la vieja que
se mantiene. 

Atención en este punto: de los atributos cuya historia vamos a mantener, por cada modificación se
agrega un nuevo registro, es decir, que vamos a hacer operaciones de INSERT generando una nueva
clave subrogada con fechas de inicio y fin para identificar a qué período corresponde el dato.

Se usan cuando necesitamos reconstruir la traza de los cambios de estado de la información. Por
ejemplo, la evolución del tipo de cambio de una moneda.

Son más complejas para mantener porque en ellas tenemos todas las versiones de los datos, es
decir, más de un registro.

En general tratamos de evitarlas y caer en las tipo 1 y eso está mal . A modo de consuelo, tengan
en cuenta que en la mayoría de los casos el análisis se ve afectado sólo por ALGUNOS de los atribu-
tos de la dimensión, no siempre son todos. 

Por lo tanto, solo vamos a tener que gestionar como tipo 2 a ALGUNAS de las dimensiones, no a todas. 

ID CAMBIO COD_MONEDA TIPO DE CAMBIO INICIO FIN

412312 USD $75,23 16/7/2020 17/7/2020
412313 USD $75,30 17/7/2020 20/7/2020
412314 USD $75,53 20/7/2020 21/7/2020
412315 USD $75,61 21/7/2020 22/7/2020
412316 USD $75,66 22/7/2020 -

ID CAMBIO COD_MONEDA TIPO DE CAMBIO INICIO FIN

412312 USD $75,23 16/7/2020 17/7/2020
412313 USD $75,30 17/7/2020 20/7/2020
412314 USD $75,53 20/7/2020 21/7/2020
412315 USD $75,61 21/7/2020 22/7/2020
412316 USD $75,66 22/7/2020 23/7/2020
412317 USD $75,74 23/7/2020 -
 Mejores prácticas SQL 15

Dimensiones lentamente cambiantes

TIPO 2

La nueva información se agrega a la vieja.

La información vieja es mantenida y efectivamente versionada.

Se utiliza cuando se necesita recontruir la traza de los cambios de estado de la información.

Son más complejas de mantener dado que, a diferencia que en Tipo 1 y Tipo 3, en las dimensiones
tenemos todas las versiones de los datos (más de un registro).

TIPO 3

Aplican cuando no nos interesa toda la vida del dato, sino solo UNA PARTE de los cambios que se
dieron en la historia. Por ejemplo, una persona pasó del segmento de consumo medio al alto. 

La información nueva se guarda junto a la anterior. Para modelar agregamos tantas columnas como
versiones queramos de los datos o ponemos una columna con el dato actual y al lado otra con el
anterior.

Solo insertamos o actualizamos registros. No tenemos que complejizar los JOINS ni hacer UPSERTS
raros (como en las tipo 2).

ID CLIENTE NOMBRE APELLIDO SEGMENTO_ACTUAL SEGMENTO_ANTERIOR

1 Pablo Sanfilipo Medio Consumo -

ID CLIENTE NOMBRE APELLIDO SEGMENTO_ACTUAL SEGMENTO_ANTERIOR

1 Pablo Sanfilipo Alto Consumo Medio Consumo

La nueva información es guardada junto con la vieja.

La vieja información es guardada parcialmente.

La traza de los datos es almacenada de forma acotada.

Columnas adicionales son creadas para reflejar los cambios que son acontecidos.

Permite la visualización de los hechos tanto para el estado actual como para los estados pasados.
 Mejores prácticas SQL 16

Técnicas más avanzadas I

Dimensiones degeneradas
Son dimensiones que se crean dentro de la tabla de hechos.

Se usan cuando hay varios atributos y sólo interesa uno. Entonces, en vez de construir y sacar la
dimensión a otra tabla, lo que se hace es degenerarla en la tabla de hechos.

Por ejemplo: cuando tenemos una fact transaccional y necesitamos utilizar el número de ticket. 

Cuando aparecieron los sistemas distribuidos la tendencia era a degenerar prácticamente todo ya
que era muy costoso hacer los joins. Sin embargo, a medida que las cosas evolucionaron ya no se
hace así y hoy solo lo hacemos cuando tiene sentido. 

Tengan en cuenta que si degeneran demasiado una dimensión, en caso de tener que reprocesar algo,
van a tener que hacer un UPDATE letal sobre la tabla de hechos y eso no es nada bueno. Presten
atención. 

Moraleja: de fábrica nos chipearon para NORMALIZAR, porque era TERRIBLE duplicar los datos, sin
embargo a veces hay que pensar las cosas desde otra perspectiva . 

FactFactura
DimProducto
DimTiempo IdFechaDespacho
IdFechaPedido IdProducto
IdFecha IdProducto ProductoDesc
FechaDesc IdCliente
Dia IdCentroDistribucion
Mes NroFactura DimCliente
Anio

Cantidad IdCliente
Importe Nombre
Apellido
Descuento Direccion
ImporteNeto Ciudad
ImporteBruto Estado

DimCentroDistribucion

IdCentroDistribucion
Nombre
Ciudad
Estado
Tipo
Region
 Mejores prácticas SQL 17

Técnicas más avanzadas II

Dimensiones basura (o Junk Dimensions)
Es simplemente recortar una dimensión. 

Las pueden usar para hacer análisis muy particulares o cuando tengan dimensiones con muchos
atributos y las quieran acotar ya que no necesitan tanto detalle. 

Se trata de combinar distintos atributos —idealmente de cosas que se analicen de forma conjunta— y
de unificarlos en una misma dimensión. 

Se llaman basura porque no representan una característica de los datos (como cliente, sucursal,
región) sino un conjunto agrupado de los mismos.

Cliente DimCliente

IdCliente IdCliente
NombreCliente NombreCliente
FechaNacim FechaNacimiento
... ...
Edad Edad
Ingreso
FlagPropietario
FlagContactado
DimBasura

NivelEdad
RangoGeneracional
NivelIngreso
FlagPropietario
FlagContactado
 Mejores prácticas SQL 18

Técnicas más avanzadas III

Tablas de hechos sin hechos (O Factless)
No incluyen ninguna columna de medida, solo contienen claves de dimensión.

Podrían almacenar observaciones definidas por claves de dimensión. Por ejemplo, en una fecha y
hora determinadas, un cliente concreto ha iniciado sesión en el sitio web. 

Pueden definir una medida para contar las filas de la tabla de hechos sin hechos a fin de realizar un
análisis de cuántos clientes han iniciado sesión y cuándo lo han hecho.
 Mejores prácticas SQL 19

Errores frecuentes I
Distinta granularidad
Supongamos que modelan una necesidad y tienen la tabla de hechos con cierto grano (por ejemplo:
ventas diarias y apertura por producto y sucursal). 

Este nivel sería suficiente en caso de tener que alimentar cosas con un nivel de grano mayor, por
ejemplo las ventas por mes, por año, etc.

Cuando tienen mucha información en la tabla de hechos, será necesario construir tablas agregadas.

En este punto hay que empezar a pensar en un concepto muy importante: el LINAJE DE DATOS que
es cuando el grano fino alimenta al más grande. 

Las tablas agregadas muchas veces se derivan de la tabla de hechos que ya tenían (las ventas por
mes de las ventas por día).

Pero, ¿qué pasa si las cosas se dan vuelta? Tienen la tabla con el grano más alto (mes por ejemplo) y
necesitan el más fino (día).

En este caso no quedará otra que modelar y reprocesar para construir una tabla con un nivel de grano
menor.

Y en este punto hay que tener mucho cuidado porque, si no se hace de forma correcta, pueden surgir
muchos problemas.

Para que todo se mantenga bajo un esquema de gobierno y de coherencia, cuando construyan la
tabla con el grano más fino, tienen que modificar la lógica de la tabla anterior que ya estaba funcio-
nando para que se derive de la nueva. 

En la práctica: la lógica vieja pasa a ser la base de la lógica nueva y el proceso de carga de la tabla
vieja pasa a ser de nuevo un GROUP BY. Así es como se respeta el linaje.
 Mejores prácticas SQL 20

Errores frecuentes II
Múltiples monedas
En estos casos tienen que pensar qué nivel de complejidad quieren manejar. Como siempre en la vida, habrá dos
caminos:

El fácil: la solución es poner la misma métrica ya calculada y pegar al lado los valores en la tabla de
hechos con los distintos atributos (en pesos, en dólares, etc.) Así evitarán tener que ir a una dimen-
sión tipo 2 porque el tipo de cambio ya es un hecho.

El difícil: En otros casos pueden ir directo a una dimensión tipo 2 y versionar todo lo que necesiten y
fin de la historia.
 Mejores prácticas SQL 21

Errores frecuentes III

Marcas para misceláneos
Está asociado a las dimensiones basura.

Los sistemas transaccionales generalmente producen misceláneos, flags de baja cardinalidad y

texto.

Atributos que no suelen pertenecer a otras dimensiones y que no parecen organizarse de manera
coherente para conformar una dimensión.

Para evitar poblar la tabla de hechos con este tipo de atributos, una opción es generar una nueva
dimensión que los agrupe.

Los atributos pueden construirse con todas las combinaciones posibles/producto cartesiano, o tan
solo con las combinaciones detectadas.

La dimensión puede contar además de los flags Si/No, Activo/Inactivo, 0/1, True/False, etc., la
descripción asociada a los mismos.
 Mejores prácticas SQL 22

Conclusiones
Para terminar, les dejamos algunas conclusiones que deben tener muy presentes cada vez que se sienten a
modelar.

El modelo lógico siempre le gana a la performance: No nos cansaremos de repetir esto, si se

equivocan en el modelo lógico no habrá prácticamente forma de salvarlo . El hardware podrá
ayudar temporalmente, sí. Pero en última instancia, ¡nada escala! (Créannos que es así ).

Modelo lógico bien mantenido = gobierno = productividad: Lo importante es dar forma a un modelo
que garantice la integridad de los conceptos que modelan. Si logran una única representación de la
realidad, los equipos nuevos no van a tener que reinventar la rueda, simplemente tendrán que tomar
los atributos que ya están y extenderlos.

Modelamos de atrás para adelante: Partimos de la necesidad de datos, para entenderla es super
importante hablar con las personas, conocer qué necesitan y modelar a partir de eso. Los perfiles de
Business Analytics Translators (BATs) son claves en este sentido. Se trata de traducir problemáticas
de negocio en soluciones basadas en datos a través del proceso de modelado. Para esto, en el mejor
de los casos, podrán partir de reportes y en el peor, tendrán que hacer desde cero todas las preguntas
e interpretarlas.

El modelo tiene que ser coherente: Ante la duda pregunten SIEMPRE. No caigan en el facilismo de
considerar que todo es una dimensión porque no van a terminar nunca de modelar y, a la larga,
siempre va a faltar algo.

Prestar atención al linaje de datos: Si quieren tener gobierno, tienen que respetar el linaje, que
implica (casi siempre) ir de mayor a menor detalle. Esos procesos hay que respetarlos ya que es la
forma más fácil de garantizar la coherencia de los cálculos.

Recuerden que esto se trata de partir del dato más crudo hasta el dato más cocido pasando por todas las instan-
cias. Si respetan esto, su vida será más feliz. Y sabemos por qué lo decimos.
 ¿Quiénes somos?

Datalytics es una compañía especializada en DATA & IA que acompaña a las empresas en la
modernización de sus productos y servicios a partir del uso de los datos. Nuestros equipos tienen
más de 15 años de experiencia ayudando a los sectores líderes a tomar decisiones más
informadas, a mejorar sus operaciones y a crear nuevos modelos de negocio.

Si te interesa que contratar nuestros servicios, puedes contactarnos aquí.

Si te interesa formar parte de nuestro equipo, estas son nuestras las posiciones abiertas.

datalytics.bi datalytics.mejorcondatos Datalytics Datalytics