III. In-depth analysis of selected cases 64
4. Concluding reflections on the case studies 86
En esta etapa de implementación del ODS se da inicio al proyecto. Se debe reunir un grupo de personas encargadas de la puesta en marcha del proyecto, se deben identificar un conjunto de personas que colaboren en la implementación. Entre estas personas se debe disponer de un Patrocinador del Proyecto, un Líder del proyecto por parte de IT, un líder usuario ( que represente las necesidades de los usuarios), un conjunto de ingenieros y analistas del negocio que trabajen en el diseño del ODS a implementar.
Todo este grupo de personas se convertirán en un equipo de trabajo que se encargaran de realizar el lanzamiento del proyecto, liderarlo y ponerlo en marcha.
La etapa de Diseño se divide a su vez en una serie de pasos que deberán realizarse.
Requerimientos Funcionales
• Definición del Modelo de Datos • Requerim ientos de Usuarios • G rafos de Flujos de Datos
• P lataformas de Software y Hardware • E specificación de Metadatos y O DS • P eriodicidad de Transm isión de Datos • Definición de Metadatos
• Definición de la Base de Datos que s o po rta e l O D S
• Definición de la Interfase
• Pruebas de Cargue • Documentación de Pruebas • Aseguram iento de puntos de chequeo • Puesta en m archa
• Reprocesos
• Desarrollo de Metadatos • Desarrollo de Bases de Datos
q ue so p o rta n e l O D S
• Generación de program as ETL • Creación de Interfase
DIS EÑ O
DE SAR RO L L O AP RO BAC IO N
MISC-03-1-9
Determinar el Enfoque del ODS. Se establece una reunión inicial entre el Patrocinador, el líder de IT, el líder usuario donde se firma el compromiso para comenzar a trabajar en la etapa de análisis de requerimientos y diseño del sistema:
El soporte en esta etapa es un documento de Requerimiento Funcional (Anexo 1), para este primer paso se definen los siguientes ítems:
Objetivo : Se establece el Objetivo general del proyecto
Alcance : aquí se definen los limites que se abarcarán en el desarrollo del ODS
Necesidades : se plantean los puntos que hacen necesario el desarrollo del sistema propuesto.
Áreas usuarias y Representante: se definen las áreas usuarias implicadas, por cada una de ellas se define un representante.
Glosario de Términos: se definen los conceptos propios referentes al proyecto, con el fin de hablar en las reuniones siguientes en un solo lenguaje común.
Se establecen reuniones periódicas ( no más de cinco) donde un grupo de analistas del negocio ( cada uno de los representantes de las áreas usuarias) y un grupo de ingenieros elaboran conjuntamente los Requerimientos Funcionales. Estas reuniones dependen de la disponibilidad de los usuarios, es importante que exista el compromiso por parte de todos los implicados en el desarrollo. Para ello es necesario reservar unas horas en el calendario de cada uno para que estén presentes. Es importante que las reuniones sean continuas y con las mismas personas en cada sesión. Se sugiere esto porque si las reuniones son muy distantes en tiempo es posible que se pierda la idea inicial del proyecto. Así mismo deben estar las mismas personas porque al haber un reemplazo de un usuario por otro, generalmente lo que ocurre es un choque de ideas entre lo que pide originalmente el primero y lo que podría solicitar el segundo.
En este paso se complementa el documento inicial con la siguiente información:
Modelo Actual: se dibuja gráficamente lo que se dispone actualmente. Situación actual: se describe en palabras el inconveniente actual. Modelo Propuesto: se dibuja gráficamente que es lo que se requiere.
MISC-03-1-9
Situación Propuesta: se describe en palabras los beneficios que conllevaría el desarrollo de un ODS.
Definición de las Consultas o Reportes. Dentro del documento se define un ítem correspondiente a consultas. En este ítem correspondiente a Consultas se llena cada uno de los reportes solicitados. En este paso se coloca la información correspondiente a
Periodicidad Æ Se explica con que periodicidad se ejecuta el reporte que puede ser a solicitud, diario, semanal, o mensual.
Día de ejecución Æ Se indica que día calendario debe ser entregada la información o el día de la semana. Por ejemplo: lunes, martes o el día 5 de cada mes.
Lista de Campos Æ Es un listado de los campos o columnas con su descripción, esta información hace parte de los metadatos.
Campos de Agrupamiento Æ campos por los cuales se puede agrupar la información del reporte
Campos Sumables Æ campos sobre los cuales se realiza alguna operación de computo como Sumas, Formulas.
Tipo de presentación Æ Como se presentará este archivo a los usuarios, en que formato. Por ejemplo puede ser archivo plano *.txt, *.lst, o un *xls (MS Excel)
Parámetros de ejecución Æ se indican los parámetros de ejecución necesarios para ejecutar el reporte. Entre estos parámetros están los rangos de fechas, con su formato establecido.
Ejemplo del reporte Æ Se describe como es la extracción de la información y como se visualizaría este.
Es decir los reportes son definidos de esta manera permitiendo que las personas de IT identifiquen posteriormente con estas consultas las dimensiones de las cuales se requiere mayor numero de información.
Modelo de Datos de las Fuentes
Se recolecta la información de las fuentes desde las cuales se extrae la información, es decir se busca el modelo de datos parcial de lo que se desea integrar en el ODS. Este es un buen punto de referencia para establecer el Modelo de Datos del ODS. Se requiere de las fuentes la siguiente información:
MISC-03-1-9
Modelo de las Entidades Originales Æ se considera las entidades que se tendrán en cuenta para representarlas en el ODS.
Listado y Descripción de las Entidades Æ se describe por cada una de las entidades las características que presentan. Por cada una de las entidades se lista los campos.
Notas Generales Æ Se anexa información concerniente a las características generales del sistema que se representa.
Esta información es recopilada en un formato de Modelo de Datos de las Fuentes (Anexo 2)
Escogencia del Tipo de ODS
Las clases de ODS se explicaron anteriormente en el punto 6.1.2. Y se realiza un breve resumen aquí:
Tipo I – Actualización sincrónica.
Tipo II – Se realiza una actualización cada 3 o 4 horas.
Tipo II – Se actualiza la información cada 24 horas aproximadamente.
Tipo IV – la información se carga de un DW y generalmente no es programable su actualización.
Teniendo en cuenta estos tipos de ODS, la propuesta metodológica plantea una serie de pasos y Grafos de cargue y actualización de información que se ajustan mas a los tipos II y III. Sin embargo es posible extenderla de cierta manera a los otros tipos si se definen la forma de capturar las modificaciones.
Diseño del Modelo de Datos del ODS
Teniendo en cuenta las consultas que se deben disponer en el ODS se debe crear un Modelo de Datos que cumpla con ellas. La escogencia del modelo es muy flexible en este punto, la metodología no pretende proponer un sistema propio de modelamiento, se pueden utilizar los métodos de modelamiento tanto Relacional como Dimensional. La
MISC-03-1-9
diferencia entre la utilización de uno u otro es determinada por el tipo de información que se desea reflejar en el ODS.
Las tablas, campos, periodicidad, datos sumables determinara que modelo de datos será mas apropiado a aplicar entre ellos están los siguientes: Relacional, Dimensional o Híbridos.
Relacional : Si la información que se requiere tiene una precondición de integridad referencial debe utilizarse este tipo de modelo.
Dimensional : Si lo que se requiere es un sistema con información agrupada y muchos datos resumidos. Este tipo modelo es el adecuado.
Si requiere una información híbrida pues es posible instalar en el ODS un modelo de datos relacional intercalado con algún conjunto de tablas que agrupen los datos.
Se debe tener en cuenta que en un ODS los datos están detallados, en un DW los datos son una mezcla de resumidos y detallados.
Este modelo de datos debe ser documentado en un formato de Diseño de Modelo de Datos (Anexo 3). Dentro de este formato se colocara la siguiente información:
Lista de Entidades del ODS Æ se enumera las entidades participantes en el modelo de datos
Un diseño de modelo de datos Æ representa gráficamente el modelo a implementar
Descripción del modelo Æ se coloca una breve descripción escrita del modelo a implementar.
Por cada una de las entidades implicadas en el modelo se coloca la información necesaria:
MISC-03-1-9 Descripción de la entidad Æ se describe las características de esta entidad y su
importancia dentro del modelo de datos.
Fuente de Origen Æ Se indica cual es la Base de Datos origen, indicando que sistema representa.
Nombre de la Entidad fuente Æ se explica cual es la entidad o entidades originales de las cuales esta compuesta esta entidad destino.
Proceso de Transformación Æ se indica si la entidad sufrió algún proceso de transformación.
Periodicidad de cargue Æ se debe definir por cada una de las entidades cada cuanto tiempo se cargará la información.
Lista de campos Æpor cada uno de los campos se debe describir su información y al lado de cada uno el tipo.
Llave Primaria Æ se define la llave primaria de la entidad en referencia.
Se debe tener especial cuidado que el Modelo de Datos propuesto sea elaborado cumpliendo los requerimientos y sobre todo las consultas o reportes solicitados. Para ello se debe evaluar el Modelo de Datos con cada uno de los reportes solicitados, una forma de hacer esta evaluación es haciendo una validación de completitud de entidades y completitud de campos.
Completitud de Entidades
El procedimiento permita cruzar las entidades del Modelo contra las consultas o Reportes solicitados en el requerimiento funcional, esto permitirá evaluar la consistencia del Modelo de Datos Propuesto.
Entidades Consultas
Entidad 1 Entidad 2 Entidad 3 Entidad m Completitud de Entidades ( Completa o Incompleta) Consulta 1 X X Completa Consulta 2 X X X Completa ... ...
Consulta n X X Completa o Incompleta
MISC-03-1-9
Un valor completo indica que en el modelo de datos están todas las entidades necesarias en la consulta. Un valor incompleto indica que en el modelo de datos no están todas las entidades requeridas.
El valor de completitud permitirá saber si la consulta i requerida en el modelo esta satisfecha completamente.
El porcentaje de Completitud permitirá definir si el modelo cumple con todas las consultas que los usuarios requieren
Completitud del Modelo ODS = (completas) / n * 100 N : Al número de consulta requeridas.
Completitud de Campos
Dependiendo del análisis realizado en el punto anterior se organizan de mayor a menor las entidades con sus respectivos campos, determinando por cada uno de ellos los que son requeridos y lo que no lo son.
Entidad Campos Consulta 1 Consulta 2 ... Consulta n Entidad 1 Campo 1 X X Entidad 1 Campo 2 X X Entidad 1 Campo n X X Entidad 2 Entidad 2 X X Entidad 2 Campo 1 X X Entidad 2 Campo 2 X X ... Entidad m Campo n X X
Tabla No. 4. Completitud de Campos.
Para el cargue inicial es indispensable identificar aquellos que son prioritarios para implementarlos en el ODS, aquellos campos que tiene importancia baja deben ser
MISC-03-1-9
negociados con los usuarios para identificar si se deben cargar inmediatamente o si pueden ser cargados posteriormente en una segunda etapa del ODS.
• Al escoger el sistema de almacenamiento de los metadatos es recomendable que esta se encuentre en el mismo sitio donde esta el ODS, con el fin de facilitar su acceso.
Definición de equivalencias entre el esquema global y cada esquema local
• En las multibases de datos los conflictos se deben manejar en tiempo de ejecución, es decir que al momento de realizar la consulta esta se divide en subconsultas en las cuales se debe analizar los tipos de conflictos, transformaciones y fragmentaciones. Por el contrario en una ODS toda esta tarea se realiza al momento de cargar la información al ODS. Es decir es manejado con los programas ETL.
Existen distintos tipos de conflictos, entre los cuales se destacan los siguientes:
Problemas de Fragmentación Horizontal: Cuando una estructura de tabla es dividida lógicamente en dos o más bases de datos. La fragmentación particiona una tabla en diferentes tuplas (filas o registros)Cada fragmento tiene un subconjunto de las tuplas de la tabla. Este tipo de problemas se soluciona con una operación de unión entre los distintos fragmentos.
Problemas de Fragmentación Vertical: Cuando una tabla R esta dividida en dos o más componentes donde cada una de ellas contiene atributos de las tablas y una llave primaria de la tabla R. Este inconveniente se soluciona con una operación de reunión entre los elementos fragmentados.
MISC-03-1-9
Problemas de Tipos de Atributos Distintos: Cuando un atributo en una base de datos tiene una representación distinta en otra tabla. Se maneja con conversiones en el ámbito de columnas. Se deben establecer equivalencias en el ámbito de columnas.
Problemas de Nombramiento: Cuando un mismo atributo posee dos nombres distintos en dos tablas. Se maneja con equivalencia y transformaciones simples referentes a columnas.
Todas estas equivalencias se pueden manejar de dos maneras por medio de codificación en los programas ETL o usando tablas de equivalencias que indicarán las relaciones de conflictos entre distintas bases de datos.
Paso Directo de las Fuentes al ODS
Cuando las tablas de las Bases de datos locales tienen una representación directa en el ODS debe reflejarse esta equivalencia en un documento de Definición de Transformaciones (Anexo4) Si ocurre algún tipo de transformación referente columnas escribirse a cual se refiere. Las Transformaciones en columnas se refieren generalmente a conversiones entre un campo de la fuente y un campo de la tabla destino.
Esquema Local – BD 1
Esquema Global - ODS
Transformación de columnas
(Copiar, Substring, Formateo de fechas, etc)
Tabla 1 Tabla 1
Tabla 1 – Campo 1 Tabla 1 – Campo 1 Copiar Tabla 1 – Campo 2 Tabla 1 – Campo 2 Substring
Tabla 1 – Campo 3 Tabla 1 – Campo 3 Formateo de Fechas
Tabla 2 Tabla 2
Tabla 2 – Campo 1 Tabla 2 – Campo 1 Copiar Tabla 2 – Campo 2 Tabla 2 – Campo 2 Substring
Esquema Local – BD 2
Esquema Global - ODS
Transformación de columnas
(Copiar, Substring, Formateo de fechas, etc)
Tabla 1 Tabla 1
Tabla 1 – Campo 1 Tabla 1 – Campo 1 Copiar Tabla 1 – Campo 2 Tabla 1 – Campo 2 Substring
Tabla 1 – Campo 3 Tabla 1 – Campo 3 Formateo de Fechas
MISC-03-1-9
Así mismo si en el proceso de cargue de la información al ODS es necesario cargar inicialmente las tablas de las fuentes a tablas temporales del ODS, estas deben también ser documentadas aquí.
Esquema Local – BD 1
Esquema Local – ODS Transformación
(Copiar, Substring, Formateo de fechas, etc)
Tabla 1 Tabla Temporal 1
Tabla 1 – Campo 1 Tabla Temp 1 – Campo 1 Copiar Tabla 1 – Campo 2 Tabla Temp 1 – Campo 2 Substring
Tabla 1 – Campo 3 Tabla Temp 1 – Campo 3 Formateo de Fechas
Tabla No. 6. Paso Directo de Fuentes a tablas temporales del ODS
Transformaciones entre Entidades
Cuando la información de las fuentes originales no puede ser cargada en el ODS directamente, sino que surge como un proceso de integración entre dos o más tablas, debe documentarse esta información en un documento de Definición de Transformaciones (Anexo 4), que permita identificar claramente las operaciones que se realizan entre las tablas del ODS, para establecer una visión integrada de la información.
Objetos Tablas Iniciales del ODS Tabla Destino del ODS
Operación ( Unión, Intersección, Extracción, etc.)
Tablas Tabla 1 Tabla 2 Tabla 3 Intersección ( Tabla 1 y Tabla 2) Campos
Relacionados
Campo 1 Campo 1 Donde Tabla1.Campo1 =
Tabla2.Campo1
... ... ... ... ...
Tabla No. 7. Transformaciones entre Entidades
Definición de Captura de Modificaciones
Las modificaciones deben ser fácilmente identificables en los sistemas en línea. Las Modificaciones en las BD´s de los sistemas en línea pueden ser identificadas mediante log generados en la Base de datos, así como modificaciones en las tablas registradas en tablas de auditoria o por medio de consultas directas a las tablas de hechos validando mediante fechas de cambios estas transformaciones. Dependiendo de esta clase de
MISC-03-1-9
identificación de modificaciones se podrá realizar el paso de la información de las BD fuentes hacia el ODS. Se pueden acceder a estos cambios de tres maneras:
Consultando directamente la información en las BD´s Transaccionales por medio de conexión establecida entre el ODS y estas BD´s. Esto es poco probable que esto sea permitido debido al impacto generado sobre estos sistemas debido a su alta transacionalidad.
Las otras dos maneras consisten en generar tablas temporales dentro de las BD`s transaccionales que contengan los cambios hechos en las tablas originales. La otra posibilidad y la que menos impacto tiene sobre los sistemas es crear archivos planos que poseen los registros que han cambiado.
Periodicidad
Los ODS están clasificados según su periodicidad de paso de información de los sistemas operacionales hacia el ODS. En esta etapa se define esta periodicidad.
• Determinar la periodicidad del paso de la información de las fuentes orígenes hasta el destino. Esto se hace con una conciliación entre las partes usuarias y los administradores de las Bases de Operacionales, ya que puede que el usuario requiera la información con cierta periodicidad, pero este grupo de expertos indiquen que no es posible extraer la información a ese ritmo.
• Se debe tener en cuenta que a medida que se desee que el tiempo de transmisión entre la fuente origen y destino sea más pequeño se aumentará la complejidad de tal tarea, puesto que cuando se desea transferir casi en línea se gasta mucho en procesamiento de máquina y el impacto en los sistemas operacionales es grande. Por lo tanto esto casi nunca se debería hacer a menos que su beneficio sea muy alto comparado con el costo que representa.
• Así como existe un tiempo de paso de los sistemas en Línea hacia el sistema ODS, también debe existir un tiempo de borrado de esta información. Antes de que la información sea borrada es buena practica realizar una transferencia de estos datos hacia un Datamart o hacia un DW corporativo, por supuesto haciendo
MISC-03-1-9
previamente una depuración y transformación de información si es necesaria. Este paso de un sistema ODS hacia otro repositorio se podría realizar en Línea o mediante el almacenamiento de la información en archivos planos que posteriormente serán cargados al Datamart o DW.
Revisar si las necesidades del proyecto requieren de la utilización de una Herramienta ETL o si es suficiente con programas hechos a la medida. Aquí es importante destacar el costo de las dos propuestas.
La Variable periodicidad deber ser de público conocimiento y debe ser de tipo Hora.
Variables de Tiempo
El tiempo determina el orden a cargar. Las tablas maestras se cargan inicialmente para evitar inconvenientes con las tablas de modificaciones, debido a la integridad referencial que pueda existir entre ellas. Dependiendo del tiempo se establece una identificación de la información a cargar, si es a partir de una tabla origen al momento de extraer la información se pueden crear vistas con una nomenclatura que indique que la tabla fue generada a cierto momento del día. Si el origen es un archivo plano debe indicarse por nomenclatura estos archivos.
Usando vistas temporales se pueden identificar mediante una nomenclatura como NOMBRETABLA_DDMMYYYYHH24MISS
donde
NOMBRETABLA = Nombre de la tabla en la Base de Datos DDMMYYYYHH24MISS = Hora de generación de la información por ejemplo SERVICIOS_01022003120000
Utilizando archivos planos se pueden identificar mediante una nomenclatura como NOMBRETABLA_DDMMYYYYHH24MISS.EXT
Donde
MISC-03-1-9
DDMMYYYYHH24MISS = Hora de generación de la información
EXT = Extensión que indique que es un archivo plano, esta extensión puede ser LIS, TXT, CSV, etc.
Un ejemplo de un archivo de estos es SERVICIOS_01022003120000.lis
Si la obtención de la información es a partir de un archivo plano es necesario definir un delimitador de columnas para la información, este delimitador puede ser “|” ó “,” ó “;”.