Diseño del esquema de una base de datos: por qué tus clientes no pueden consultar tus datos (y cómo solucionarlo)

Si estás desarrollando una plataforma SaaS o un producto de datos, es importante tener en cuenta qué herramientas de BI utilizan ya tus clientes. Quieren conectar Tableau, Power BI, Logi Symphony o su propio conjunto de herramientas de análisis directamente a tus datos. Quieren acceso a SQL y poder consultar tu plataforma del mismo modo que consultan todo lo demás.

Sin embargo, las expectativas no se ajustan del todo a la realidad cuando empiezan a llegar las solicitudes. Se trata de un problema habitual entre los ISV, que reciben una media de entre 6 y 20 solicitudes de análisis al mes, según un estudio realizado por insightsoftware y Hanover Research. Casi la mitad (45 %) de las organizaciones destina entre el 40 % y el 59 % de su presupuesto de desarrollo de software a la creación y el mantenimiento de sistemas de análisis.

A pesar de que la plataforma funciona exactamente según lo previsto, es posible que los clientes se encuentren en un callejón sin salida. No saben qué tablas deben unir. Los nombres de los campos no se corresponden con lo que esperan. Las relaciones que existen lógicamente en sus datos no aparecen en ningún lugar donde su herramienta pueda detectarlas. Las consultas que deberían ser sencillas no arrojan ningún resultado útil o ni siquiera se ejecutan. La plataforma funciona exactamente según lo previsto. Los clientes siguen sin saber qué hacer.

Este es uno de los puntos de fricción más habituales para los proveedores de SaaS y de plataformas de datos, y casi nunca se resuelve cambiando la base de datos. A continuación, analizamos por qué a tus clientes les cuesta realizar consultas en los datos y cómo solucionarlo.

Por qué los esquemas internos no están diseñados para el análisis de datos

Un esquema diseñado para una aplicación operativa y otro diseñado para el acceso analítico resuelven problemas distintos. Los esquemas operativos están optimizados para el rendimiento de escritura, la consistencia transaccional y la lógica de la aplicación, con tablas estructuradas en función de cómo la aplicación lee y escribe los datos, en lugar de cómo los concibe un analista.

Esto suele traducirse en estructuras muy normalizadas, en las que un concepto que el cliente considera una única entidad se distribuye entre varias tablas. Los nombres de los campos, que tenían sentido para los ingenieros que desarrollaron el sistema, pueden no resultar intuitivos para el usuario, mientras que las relaciones clave que existen en el código de la aplicación no se declaran en la base de datos, por lo que las herramientas de BI no pueden detectarlas.

El problema radica en el propio diseño: se espera obtener un resultado al crear un esquema para un fin concreto y, a continuación, pedirle que sirva para otro completamente distinto.

En qué se equivocan la mayoría de las orientaciones

Si a tus clientes les cuesta entender tu esquema, el instinto suele indicarnos que lo tratemos como un problema de diseño del esquema.

Aunque medidas como añadir una mejor documentación, cambiar el nombre de campos que pueden dar lugar a confusiones y crear vistas adicionales tienen sentido si se parte de cero, en el caso de una plataforma de producción que ya cuenta con clientes, podrían causar más problemas de los que resuelven. Por ejemplo:

• Cambiar el nombre de los campos provoca que las integraciones existentes dejen de funcionar.

• La reestructuración de tablas requiere migraciones coordinadas.

• Añadir un esquema paralelo compatible con el análisis implica mantener dos modelos de datos al mismo tiempo, con toda la carga de trabajo que conlleva su sincronización.

En el fondo, este enfoque no aborda el meollo del problema.

La exposición del esquema es una decisión relacionada con el producto

La brecha entre tu modelo de datos interno y lo que tus clientes pueden consultar es, en esencia, un problema de conectividad.

Cuando un cliente conecta su herramienta de BI a tu plataforma, es necesario que haya una conversión entre tu esquema interno y la interfaz que espera su herramienta. Esa capa de conversión determina qué nombres de tablas ve el usuario, qué relaciones puede detectar su herramienta, qué tipos de datos se devuelven y si una consulta sencilla de «arrastrar y soltar» en Tableau genera un resultado o un error.

La mayoría de los proveedores de datos no tienen en cuenta explícitamente esa capa de traducción. La conexión funciona, lo que da la impresión de que el trabajo está hecho. Pero que algo funcione y que se pueda consultar son cosas distintas, y la brecha entre ambas es precisamente donde surgen las incidencias de soporte técnico.

Considerar la exposición de esquemas como una decisión deliberada de producto implica plantearse preguntas diferentes, como por ejemplo:

• ¿Qué deben poder hacer los clientes con estos datos?

• ¿Qué información debe mostrar su herramienta de BI para que esas tareas resulten sencillas?

• ¿Cómo se deben simplificar las estructuras complejas o anidadas del modelo interno para convertirlas en tablas relacionales con las que puedan trabajar los analistas?

• ¿Qué relaciones deben hacerse evidentes de forma explícita a través de los metadatos, aunque la aplicación las imponga en el código?

Para responder a estas preguntas, es necesario crear una capa de traducción que se sitúe entre tus datos y las herramientas de tus clientes.

Cómo lo resuelven los conductores

Un controlador diseñado específicamente para tu plataforma puede encargarse de esa conversión. Un controlador puede consultar tu modelo de datos interno, asignarlo a la estructura relacional que esperan tus clientes, mostrar las relaciones y los metadatos del esquema que sus herramientas pueden detectar automáticamente, y devolver los resultados a través de una interfaz SQL estándar mediante ODBC o JDBC.

Desde el punto de vista del cliente, la conexión con su herramienta de BI funciona igual que con cualquier base de datos bien estructurada, sin dejar de ser fácil de usar, mientras que la complejidad subyacente de tu modelo interno le resulta invisible.

Desde tu punto de vista, el esquema interno no cambia.

Esta es la arquitectura para la que está diseñado el SDK de Simba de insightsoftware. El SDK proporciona la infraestructura de análisis de consultas, asignación de esquemas y detección de metadatos que requiere el desarrollo de controladores personalizados. Se encarga de los aspectos técnicos de traducir el SQL a consultas que tu almacén de datos pueda ejecutar, de asignar tus estructuras internas a tablas relacionales y de extraer la información de esquemas que las herramientas de BI necesitan para funcionar correctamente.

El resultado es que tu equipo de ingeniería se centra en la integración de las fuentes de datos, en lugar de en la infraestructura de controladores. La capa de traducción entre tu plataforma y las herramientas de tus clientes se crea una sola vez, se mantiene a medida que tu plataforma evoluciona y ofrece un acceso SQL coherente en todas las herramientas de BI que utilizan tus clientes.

En última instancia, los clientes que no pueden sacar partido a sus datos no siguen siéndolo. Pero al crear una capa de traducción de forma deliberada, en lugar de dejarla para más adelante, puedes desarrollar una plataforma que funcione para las personas que dependen de ella. El SDK de Simba proporciona a los equipos de plataformas la infraestructura necesaria para hacerlo sin tener que crear desde cero un proceso de ingeniería de controladores, ya que incluye mapeo de esquemas, descubrimiento de metadatos, análisis sintáctico de SQL y salida ODBC y JDBC basada en estándares. Tu equipo conecta el SDK a tu almacén de datos y configura la presentación del esquema que necesitan tus clientes.

¿Estás listo para saber más? Mira cómo creamos un controlador ODBC en 30 minutos: demostración en directo del SDK de Simba.