Los 10 errores más comunes en el modelado de datos

La modelización de datos es el proceso mediante el cual representamos objetos o entidades del sistema de información y las conexiones entre ellos. Estas entidades pueden ser personas, productos u otros elementos relacionados con su negocio. Independientemente del tipo de entidad, modelarlas correctamente resulta en una configuración de base de datos potente para una rápida recuperación de información, un almacenamiento eficiente y más.

Dado las ventajas que ofrece la modelización de datos para obtener información detallada de la base de datos, es importante aprender a hacerlo de manera efectiva en su organización. En esta guía, señalaré algunos errores clave a evitar al modelar sus datos.

No considerar los modelos de datos de calidad como un activo

Como señala la consultora de Microsoft Power BI, Melissa Coates, a veces optimizamos nuestros modelos de datos para un caso de uso particular, como analizar datos de ventas, y esto se vuelve más complicado cuando los analistas necesitan analizar más de una cosa.

Por ejemplo, puede resultar difícil para los analistas analizar la intersección de las ventas y las llamadas de soporte si los modelos se han optimizado solo para los datos de ventas. Esto sin mencionar el tiempo adicional, los recursos y los posibles costos adicionales que podrían requerirse para crear modelos adicionales cuando un solo modelo habría sido suficiente.

Para evitar esta ineficiencia de modelo, tómese el tiempo necesario para garantizar que su modelo de datos ofrezca una aplicabilidad más amplia y tenga sentido en el largo plazo desde el punto de vista financiero.

Vale la pena invertir en minería de datos

No considerar el uso de la aplicación de los datos

Una de las cosas más difíciles de la modelización de datos es encontrar el equilibrio correcto entre los intereses en competencia, como:

• Las necesidades de datos de la aplicación(es)
• Metas de rendimiento
• Cómo se recuperarán los datos

Es fácil consumirse tanto con la estructura de los datos que se dedica poco tiempo a analizar cómo una aplicación usará los datos y encontrar el equilibrio adecuado entre el interrogatorio, la actualización y el procesamiento de los datos.

Otra forma de expresar este error es la falta de empatía por aquellos que usarán el modelo de datos. Un buen modelo de datos tiene en cuenta a todos los usuarios y casos de uso de una aplicación y se construye en consecuencia.

El esquema sin esquema no significa sin modelo de datos

Las bases de datos NoSQL (documentales, clave-valor, de columnas anchas, etc.) se han convertido en un componente crítico de la arquitectura de datos empresariales, debido a la flexibilidad que ofrecen para los datos no estructurados. Aunque a veces se piensa erróneamente que las bases de datos NoSQL son "sin esquema", es más preciso pensar en ellas como habilitadoras de esquemas flexibles. Y aunque algunos confunden los esquemas de datos con los modelos de datos, ambos cumplen funciones diferentes.

Un esquema de datos instruye al motor de base de datos sobre cómo se organiza la información en la base de datos, mientras que un modelo de datos es más conceptual y describe los datos y las relaciones entre ellos. Independientemente de esta confusión sobre cómo el esquema flexible puede afectar la modelización de datos, al igual que con una base de datos relacional, los desarrolladores deben modelar los datos en las bases de datos NoSQL. Sin embargo, dependiendo del tipo de base de datos NoSQL, ese modelo de datos será simple (clave-valor) o más sofisticado (documental).

No controlar los datos semiestructurados

La mayoría de los datos hoy en día son no estructurados o semiestructurados, pero eso no significa que su modelo de datos deba seguir esos mismos formatos. Aunque puede resultar conveniente no pensar en cómo estructurar los datos al momento de ingresarlos, esto casi siempre resultará en problemas. No se puede evitar el uso de datos semiestructurados, pero la forma de lidiar con ellos es aplicar rigor en el modelo de datos en lugar de adoptar un enfoque pasivo durante la recuperación de datos.

Fase de análisis: Entendiendo lo que el cliente quiere

No planificar la evolución del modelo de datos

Considerando el trabajo que puede implicar elaborar un modelo de datos, puede resultar tentador asumir que el trabajo está terminado una vez que se ha construido el modelo de datos. Sin embargo, eso no es así, según Anna Geller de Prefect: "Crear activos de datos es un proceso continuo," porque "a medida que sus necesidades analíticas cambian con el tiempo, el esquema también tendrá que ajustarse".

Una forma de facilitar la evolución del modelo de datos es "dividir y desacoplar las transformaciones de datos [para] hacer que todo el proceso sea más fácil de construir, depurar y mantener a largo plazo", continúa Geller.

Vincular rígidamente la interfaz de usuario con los campos y valores de los datos

Como destaca el socio de Tailwind Labs, Steve Schoger: "No temas 'pensar fuera de la base de datos'". Explica que no es necesario vincular directamente la interfaz de usuario con cada campo y valor de datos. Este error tiende a surgir al centrarse únicamente en el modelo de datos en lugar de la arquitectura de información subyacente. El problema también implica que es probable que presente los datos de una manera más intuitiva para el público de la aplicación que realizar un mapeo uno a uno del modelo de datos subyacente.

Niveles de granularidad incorrectos o diferentes

En el análisis, la granularidad se refiere al nivel de detalle que podemos observar. En un negocio de SaaS, por ejemplo, es posible que deseemos ver el nivel de consumo de nuestro servicio por día, por hora o por minuto. Tener la cantidad correcta de granularidad en un modelo de datos es importante, ya que si es demasiado granular, puede terminar con toda clase de datos innecesarios, lo que dificulta el descifrado y clasificación de todos ellos.

Pero si tiene demasiada poca granularidad, es posible que no tenga suficientes detalles para analizar detalles o tendencias importantes. Ahora, agregue la posibilidad de que su nivel de granularidad se enfoque en los números diarios, pero el negocio quiere diferenciar entre el consumo en horas pico y horas valle. En ese punto, estaría lidiando con una granularidad mixta y confundiría a los usuarios. Determinar los casos de uso exactos de los datos para los usuarios internos y externos es un primer paso importante para decidir cuánto detalle granular necesita su modelo.

Patrones de nomenclatura inconsistentes o inexistentes

En lugar de inventar una convención de nomenclatura única, es mejor seguir enfoques estándar con los modelos de datos. Si, por ejemplo, las tablas carecen de una lógica coherente en cómo se nombran, el modelo de datos se vuelve muy difícil de seguir. Puede parecer ingenioso inventar convenciones de nomenclatura oscuros que relativamente pocas personas comprendan de inmediato, pero esto inevitablemente conducirá a la confusión más adelante, especialmente si se incorporan nuevas personas para trabajar con estos modelos.

Los 12 errores más comunes al trabajar con el objeto Recordset en Access

No separar el concepto de claves de índices

En una base de datos, las claves e índices cumplen funciones diferentes. Como explicó Bert Scalzo, "Las claves aplican reglas empresariales, es un concepto lógico. Los índices aceleran el acceso a la base de datos, es un concepto puramente físico".

Debido a que muchos confunden los dos, terminan sin implementar claves candidatas y, por lo tanto, limitan los índices; en el proceso, también disminuyen el rendimiento. Scalzo continuó con este consejo: "Implemente el menor número de índices [que] pueda admitir eficazmente todas las claves".

Comenzar demasiado tarde en la modelización de datos

Si el modelo de datos es el plano que describe los datos de una aplicación y cómo interactúan esos datos, no tiene sentido comenzar a construir la aplicación antes de que un modelador de datos haya delimitado completamente el modelo de datos. Sin embargo, esto es precisamente lo que muchos desarrolladores hacen.

Comprender la forma y estructura de los datos es esencial para el rendimiento de la aplicación y, en última instancia, la experiencia del usuario. Esto debería ser la primera consideración y nos lleva de vuelta al error número uno: no considerar los modelos de datos de calidad como un activo. No planificar el modelo de datos es esencialmente planificar el fracaso (y planificar mucho trabajo de refactorización más adelante para corregir los errores).

Divulgación: Trabajo para MongoDB, pero las opiniones expresadas aquí son mías.

Las mejores herramientas de inteligencia empresarial para tomar decisiones basadas en datos

En Newsmatic nos especializamos en tecnología de vanguardia, contamos con los artículos mas novedosos sobre Big Data, allí encontraras muchos artículos similares a Los 10 errores más comunes en el modelado de datos , tenemos lo ultimo en tecnología 2023.