7. DISEÑO DE LA SOLUCIÓN

7. DISEÑO DE LA SOLUCIÓN

Una vez hecha la toma de requerimientos y teniendo identificada toda la información necesaria para el cliente y acceso a los lugares donde se encontraba, pasamos a la fase de definición y diseño de los data marts en Litebi.

En esta fase el departamento de sistemas definió el espacio de solución para CECAV dentro de la base de datos de Litebi, creando en primer lugar un usuario administrador que pudiera desarrollar la solución sobre el espacio asignado.

Cuando se define un espacio de solución, se define automáticamente la estructura del data warehouse para el cliente, que es común a todas las soluciones y se asigna un espacio de almacenamiento base, pudiéndose cambiar más adelante si el espacio de almacenamiento no es suficiente. Cabe destacar que Litebi utiliza una tecnología R- OLAP para su herramienta de análisis.

A continuación se presenta el diseño y la definición de los cubos OLAP que representan los data marts en los que se divide el data warehouse de esta solución.

Yaestudio

7.1 Objetivos y beneficios

Como se ha presentado a lo largo del documento, el principal objetivo a cumplir en la arquitectura de la solución era que el CECAV dispusiera de toda la información relativa a cualquier tipo de análisis sobre las muestras de diversos tipos de aves integrada en una misma aplicación y que fuera accesible desde cualquier lugar. Esta información se utilizaría para realizar informes de manera más rápida y sencilla que con las aplicaciones que utilizaban anteriormente; y sobre todo, como objetivo principal a cumplir, la generación de mapas sanitarios de diversas enfermedades codificados por colores, algo muy importante para el centro y que resultaba demasiado costoso.

La inexistencia de un sistema que proporcionara todas estas ventajas fue el factor principal que impulsó el desarrollo de esta solución. Todos estos beneficios tendrían que tenerse en cuenta a la hora de diseñar la solución, ya que eran los principales objetivos a cumplir. Estos objetivos ya fueron marcados y expuestos brevemente en el apartado 5 donde se explicaban las condiciones del proyecto, pero fue necesario detallarlos a la hora de establecer un diseño que los satisficiera:

  • Estandarización: Al utilizarse diferentes sistemas de análisis, la presentación de informes dependía del formato de exportación de cada uno, presentando gran heterogeneidad en el tratamiento de la información. Esto dificultaba claramente el desarrollo de aplicaciones estándar para todos los departamentos de análisis de enfermedades, ya que cada uno trataba los análisis de maneras diferentes. Con la existencia de un data warehouse integrado y una sola aplicación de inteligencia de negocio para todos los departamentos se pretendía homogeneizar estos conceptos de negocio, sustituyéndolos por los definidos en el data warehouse. Las ventajas de esta estandarización son muchas: un informe desarrollado sobre una enfermedad es válido para toda la organización; los diferentes departamentos ven facilitada su comunicación entre sí al usar todos los mismos informes y conceptos de negocio; se facilita el acceso de la información a niveles más elevados dentro de la jerarquía empresarial con necesidad de mayor nivel de consolidación. La estandarización es de una importancia enorme para conseguir el objetivo: Inteligencia.
  • Capacidad de análisis: La herramienta de Inteligencia de negocio Litebi posibilita múltiples métodos de análisis de información: Cubos con tecnología OLAP, Drill- Trough, Slice and Dice, y desarrollo de informes simples en un tiempo muy escaso. Todo esto sin necesidad de conocimientos informáticos por parte del usuario. La existencia de estas posibilidades fue muy útil para los usuarios operativos que tienen que tratar con información de cada día al momento y tienen necesidad de analizarla en profundidad para la toma de decisiones operativas. Estas herramientas de análisis también resultaban útiles para el caso en que una persona en un puesto más elevado dentro de la empresa quisiese “investigar” un suceso concreto más detalladamente. [1] formatos además de tenerlo accesible desde el navegador (PDF, Excel,…etc.). Existe la posibilidad de planificar la ejecución de un informe de manera periódica y de ser enviados por mail a un usuario especificado. En definitiva la aplicación cuenta con la posibilidad de generar unos informes potentes y dinámicos que bien podían sustituir la gran mayoría de los informes usados hasta el momento en cada una de las aplicaciones. Lo que se pretendía era la generación de informes estandarizados que fuesen usados desde todos los departamentos.
  • Centralización: Uno de los aspectos atractivos de la tecnología es que está totalmente basada en web. Existe un portal desde el que se realizan todos los accesos a la información, donde se encuentran los informes y cubos desde donde se puede consultar la información en el momento. Esto permite guardar todos los desarrollos de la empresa en un mismo lugar, abaratando costes de mantenimiento y de desarrollo.Devonn 

La conclusión que se obtuvo a través de este análisis en detalle de los objetivos es que era fácil satisfacer estos objetivos gracias a las características de Litebi, donde el más importante y que menos dependía de la plataforma para el apartado de diseño era el de la estandarización, ya que habría que adaptar los tres sistemas a un formato estándar que los agrupara.

7.2 Primer diseño

Una vez realizados todos los pasos de creación del espacio de solución por parte del departamento de sistemas, ya se disponía de un espacio de almacenamiento donde volcar los datos necesarios de la solución. Cuando identificamos la información necesaria y los orígenes de datos, se trabajó en el desarrollo de una capa de metadatos capaz de albergar las estructuras (cubos y dimensiones) que albergaran y permitieran el análisis de la información integrada.

En la fase de diseño las tareas a realizar eran:

  • Estructurar la información necesaria en un modelo estrella compuesto de tablas de hechos y tablas de dimensiones que marcarán la pauta para definir los cubos y las dimensiones.
  • A partir de los modelos en estrella, crear tantos cubos como modelos haya, crear dimensiones compartidas si existe al menos una dimensión repetida en dos modelos y el resto de dimensiones no comunes definirlas como embebidas.

A través de esta reglas básicas se inició la fase de diseño de los data marts de la solución, partiendo sobretodo de que los objetivos a cumplir más importantes en cuanto al almacenamiento de los datos eran los de integración y estandarización. Con esta idea se propuso como primera alternativa el siguiente diseño de modelo en estrella.

Como se observa este diseño contaba con un único cubo OLAP (ya que solamente existe un esquema de modelo en estrella) el cual debería contener datos provenientes de cualquier origen (las 3 aplicaciones mencionadas). Al cubo se le llamo “Resultados” y estaba formado por los siguientes indicadores y dimensiones:

  • Indicadores o métricas: Número de registros, Títer (Número de anticuerpos en la muestra), Resultado.
  • Dimensiones: Fecha oficial, Fecha toma, Fecha entrada, Fecha inicio análisis, Fecha fin análisis (Todas estas se sacan a partir de una dimensión compartida Tiempo, ya que todas hacen referencias a fechas y la dimensión Tiempo contendrá una serie de fechas tomadas desde una fecha inicial hasta una fecha final, por tanto sólo habría que establecer una asociación), Determinación (dimensión embebida) y Registro (o Muestra, también dimensión compartida).
  • Cabe destacar que a partir de una dimensión compartida es posible extraer
    dimensiones nuevas o separadas a partir de sus diferentes jerarquías (Ver Anexo
    1). Por ejemplo, como vemos la dimensión Registro está formada por una serie de
    niveles, y podría darse el caso que yo quisiera filtrar por tipo de ave y también por
    origen, y como en este caso, existir los dos niveles en diferentes jerarquías (a la hora del análisis solo es posible seleccionar una jerarquía de una dimensión y cambiarla por otra, pero nunca dos a la vez), por tanto, a la hora de explorar si no las tratamos como dimensiones separadas no seremos capaces de hacer este filtrado y se descartarían posibilidades infinitas de análisis. Así que, la dimensión Registro se separó en otras dimensiones lo que afectaba beneficiosamente a nivel de creación de informes, pero no afectaba de manera perjudicial a nivel de diseño.

7. DISEÑO DE LA SOLUCIÓN

Se eligió como primera alternativa este diseño, no por ello el mejor, pero a primera vista conseguía satisfacer los objetivos principales de integración (un cubo albergaba todos los datos de cualquier análisis existente en el centro) y estandarización (los datos provenientes de diferentes fuentes tendrían el mismo formato).

Finalmente este diseño preliminar se desechó una vez nos pusimos a alimentar de datos las estructuras diseñadas (ya se sabe que cualquier proceso que conlleve una serie de fases siempre nos hace retroceder sobre nuestros errores). El caso era que al realizarse diferentes tipos de análisis en cada uno de los orígenes de datos, los resultados a medir eran diferentes factores en cada caso y esto era imposible de representar únicamente con un indicador “Resultado”. Por otra parte, la dimensión “Determinación” que originalmente se alimentaba del origen de datos 1, no contenía algunas enfermedades presentes en los otros dos sistemas y resultaba bastante complicado unir las enfermedades de los tres lugares sin alterar de arriba abajo la solución.

7.3 Diseño definitivo

Tras detectar los diferentes errores expuestos anteriormente, se planteó la idea de definir un cubo por cada uno de los orígenes de datos y uno global (que se alimentaría de los resultados de las placas analizadas en el origen de datos 1, donde en este proceso, se analizaban una serie de enfermedades determinadas pero no sobre unas muestras o registros determinados sino sobre todos los registros que llegaban al centro, ver punto 6.2.1).

Por tanto el diseño definitivo de la solución quedó de la siguiente manera:

  • Cubo Resultados Origen 1
  • Cubo Resultados Origen 2
  • Cubo Resultados Origen 3
  • Cubo Resultados Origen 1 Global
  • Además de los cubos se diseñaron las dimensiones compartidas: Tiempo, Determinación y Reg (explicadas en el diseño de los cubos que las utilizan).

De esta manera se seguían conservando los criterios de integración y estandarización, ya que los datos se presentarían en el mismo formato en todos los cubos y seguíamos teniendo presentes todos los datos referentes a los análisis en una misma aplicación. Tras una breve comunicación con el cliente, éste nos resolvió la única desventaja que creíamos que se daba en este diseño: Nunca se comparan enfermedades entre sí. Por tanto esta solución se adaptaba a las necesidades del cliente ya que podrían analizar datos de los análisis pero esta vez además distinguidos por las características que cada una de las aplicaciones ofrecía, como por ejemplo los resultados característicos de cada tipo de análisis. Con esto se consiguió una solución más acorde y más personalizada con cada uno de los sistemas. El diseño de cada uno de los data marts se expondrá con detalle a continuación (si se desea conocer al detalle la creación de los data marts y cada uno de sus elementos, ver Anexo 1).

7.3.1 Resultados Origen 1

A partir de los informes y datos obtenidos de la base de datos de la primera aplicación, se confeccionó la siguiente estructura de esquema en estrella para elaborar posteriormente este cubo.

7. DISEÑO DE LA SOLUCIÓN

A partir de aquí este cubo contaría con los siguientes elementos:

  • Indicadores: Títer y Número de muestras de la placa.
  • Dimensión Número Columna (Embebida): Al tratarse de unas placas con una serie de muestras nos interesa ver resultados por columna de la placa.
  • Dimensión Número Fila (Embebida): Mismo caso que el anterior pero para las filas.
  • Dimensión Orden Determinación (Embebida): Número de enfermedades que se analizan para una muestra.
  • Dimensión Visible (Embebida): Propiedad Visible del resultado con valor S o N (Sí o No).
  • Dimensión Determinación (Compartida): Todas las enfermedades divididas en jerarquías por subunidad, producto, método o simplemente la propia enfermedad como nivel base de la jerarquía. Para este caso es compartida ya que se utilizará en el cubo de Origen 1 y Origen 1 global que comparten el mismo origen de datos.
  • Dimensión Fecha Entrada (Compartida): Se alimenta de la dimensión compartida tiempo que se encuentra jerarquizada por curso, por mes, por semestre y por trimestre siendo el último nivel de todas las jerarquías el día. Esta fecha hace referencia a cuando la muestra se recibe en el centro.
  • Dimensión Fecha Oficial (Compartida): Mismo caso que el anterior pero esta fecha se refiere a la fecha que oficialmente la muestra se da de alta.
  • Dimensión Fecha Toma (Compartida): Fecha de toma de la muestra, sigue la forma de las anteriores fechas.
  • Dimensión Fecha Ini Análisis (Compartida): Fecha de inicio del análisis. También se alimenta de la dimensión compartida Tiempo.
  • Dimensión Fecha Fin Análisis (Compartida): Fecha de fin del análisis. Asociada a la dimensión compartida Tiempo.
  • Dimensión Reg (Compartida): Dimensión más importante de toda la solución. Posee todos los datos asociados a una muestra o registro en concreto, los cuales son válidos para cualquier software aunque estén únicamente presentes en la base de datos del origen de datos 1. Como se había comentado en el diseño anterior esta muestra estaba jerarquizada de diversas maneras a partir de sus características. Estas jerarquías se separaron como dimensiones para poder utilizarlas en filas y en columnas durante la generación de informes (este caso es algo curioso, únicamente ocurre en las soluciones más complejas de BI). Los registros de muestras se pueden clasificar por provincia, municipio, origen, subdepartamento, producto, cliente, código postal, población, operación, profesional o por tipo de ave.
  • Dimensión Tiempo Resultado (Compartida): Fecha de obtención del resultado del análisis.

Todos estos puntos de vista fueron necesarios para la perfecta realización de los informes que se necesitaban. Para saber los pasos exactos para definir las dimensiones compartidas y los cubos ver Anexo 1.

7. DISEÑO DE LA SOLUCIÓN

7.3.2 Resultados Origen 2

Para el caso de la segunda aplicación el esquema en estrella que se diseñó fue el siguiente:

7. DISEÑO DE LA SOLUCIÓN

Y el cubo se compuso de los siguientes indicadores y dimensiones:

  • Indicadores: Densidad óptica, Grupo de Título, Log2, Número Muestras (en este caso cada registro también está formado por x muestras), S/P,S/N, Títer. Cabe destacar que estos indicadores en este caso no tendrán valor siempre, ya que existen enfermedades que miden el Títer y otras que miden la DO.
  • Dimensión Determinación (embebida): Enfermedades como en el caso anterior, con la salvedad de que las enfermedades presentes aquí son característica propia de este sistema.
  • Dimensión Resultado (embebida): Resultado del análisis de la muestra con valores Positivo, Negativo o Sus (No válido).
  • Dimensión Reg, Fecha Oficial, Fecha Toma, Fecha Entrada, Fecha Ini Análisis, Fecha Fin Análisis (compartidas): Las mismas dimensiones compartidas (menos Determinación) que en el caso anterior, pero aplicadas al caso del origen de datos 2.

7. DISEÑO DE LA SOLUCIÓN

7.3.3 Resultados Origen 3

De la misma manera que para el caso anterior, el diseño del cubo OLAP de la tercera aplicación se basó en el esquema en estrella que se muestra a continuación:

7. DISEÑO DE LA SOLUCIÓN

Este cubo se compuso de:

  • Indicadores: Densidad óptica, MediaN, MediaP, Número de Muestras (cada registro con x muestras), Resul1 y Resul2 (Columnas con resultados para cada una de las muestras)
  • Dimensión Determinación (embebida): Para este caso la dimensión de las enfermedades analizadas es embebida, como en el caso anterior, ya que las enfermedades analizadas en este sistema sólo se relacionan con esta aplicación y no están presentes en otras.
  • Dimensión Interpretación (embebida): Interpretación de la muestra con valores D,P y N.
  • Dimensión Rango Ini (embebida): Rango de inicio desde donde se realiza el análisis.
  • Dimensión Rango Fin (embebida): Rango de fin hasta donde se realiza el análisis.
  • Dimensión X (embebida): Fila de la muestra en la placa.
  • Dimensión Y (embebida): Columna de la muestra en la placa.
  • Dimensiones compartidas comunes al software del origen de datos 2.

Como se observa aquí, este tipo de análisis depende de unas características diferentes al del anterior software.

7. DISEÑO DE LA SOLUCIÓN

7.3.4 Resultados Origen 1 Global

En este cubo se muestran datos de pruebas específicas realizadas sobre todas las muestras que llegan al centro, de ahí su nombre “global”. Este cubo se basa sobre el siguiente diseño de esquema en estrella:

7. DISEÑO DE LA SOLUCIÓN

El cubo se compone de los siguientes elementos:

  • Indicadores: Número de registros, Positivos (cuantas muestras tienen resultado positivo), Totales, Valor Numérico.
  • Dimensión Orden Determinación (embebida): Número de enfermedades analizadas sobre una muestra.
  • Resultado textual: Un resultado en forma de texto que se añade cuando se realiza el análisis. Estos datos son de la forma: <10, 1’0E1…etc. son unos resultados bastante curiosos pero que son de utilidad para el centro.
  • Además se tienen las mismas dimensiones compartidas que para el caso de Origen 1.

7. DISEÑO DE LA SOLUCIÓN

Publicaciones Similares