Collahuasi CEDW DocBuenasP

Collahuasi Enterprise
Datawarehouse
CEDW - Buenas Prácticas
Documento de Buenas Prácticas ODI
Versión: 1.0
Documento de Buenas Prácticas ODI : CEDW - Buenas Prácticas
Registro de Cambios en el Documento
Documento de Buenas Prácticas ODI

C.I. CEDW-BP-ODI
Versió Fecha Autor de los Comentarios
n Cambios
1.0 26-08-2013 Elizabeth Funes Documento Original
Collahuasi Enterprise Datawarehouse 2 de 24

Ámbito del Documento
Proyecto Collahuasi Enterprise Datawarehouse

CEDW - Buenas Prácticas
Empresa Inys Consulting
Cliente CMDIC
Jefe de Proyecto Rodolfo Muñoz
Fase Desarrollo
Responsable Rodolfo Muñoz
Audiencia del Documento
Nombre Empresa Cargo

Noé Aravena CMDIC Analista Sénior de Reportabilidad
Patricio Plaza CMDIC Analista Sénior de Reportabilidad
Elizabeth Funes INYS Consultor INYS

Rodrigo Flores INYS Consultor INYS
Jorge Medida INYS Jefe de Proyecto INYS
Rodolfo Muñoz INYS Jefe de Proyecto INYS

1. Tabla de Contenidos
1. Tabla de Contenidos............................................................................................................4
2. Propósito del documento.....................................................................................................5
3. Alcance...............................................................................................................................5
4. Audiencia............................................................................................................................5
5. ¿Qué es Integración de Datos?............................................................................................5
6. ¿Qué es el Oracle Data Integrator (ODI)?.............................................................................5
7. ¿Quién Necesita ODI?..........................................................................................................6
8. Arquitectura De Oracle Data Integrator................................................................................6
9. Interfaces Gráficas..............................................................................................................7
10. Repositorio.........................................................................................................................8
11. Scheduler Agent..................................................................................................................9
12. ODI y un Proyecto de Data Warehouse...............................................................................10
12.1. Organización de los Equipos........................................................................................10
12.2. Programación y Funcionamiento Escenarios (Scheduler)...............................................11
12.3. Definición de la Topología...........................................................................................11
12.4. Servidores de Datos...................................................................................................12
13. Algunas Definiciones de Esquemas de Trabajo para el Área de Staging.................................14
14. Definición del Dataserver...................................................................................................14
15. Esquemas Físicos..............................................................................................................17
16. Contextos.........................................................................................................................18
17. Esquemas Lógicos.............................................................................................................19
18. Agentes Físicos y Lógicos...................................................................................................20
19. Definición de Modelos........................................................................................................20
20. Contenido del Modelo........................................................................................................21
21. Contenidos de Proyectos ODI.............................................................................................22
22. Diferentes Tipos de Módulos de Conocimiento.....................................................................23
23. Consideraciones en ODI.....................................................................................................23
1.

2. Propósito del documento
El objetivo de este documento es presentar buenas prácticas y estandarizar la

nomenclatura de nombres utilizada en el diseño y mantenimiento de bases de datos del CEDW.
Por mejores prácticas se entiende un conjunto coherente de acciones que han rendido buen o
incluso excelente servicio en un determinado contexto y que se espera que, en contextos
similares, rindan similares resultados.
3. Alcance
Este documento aplica al desarrollo y aplicaciones de integración de ODI, para el CEDW.
Lo definido en este documento debiera ser el ideal a considerar, para el buen desarrollo
de aplicaciones de integración de sus datos y lograr finalmente un Data Warehousing que
responda con las expectativas del negocio, de la empresa y la toma de decisiones.
4. Audiencia
Este documento se encuentra dirigido a programadores, analistas, jefes de proyecto y
especialistas técnicos del departamento de Reporting Corporativo, que tengan entre sus tareas
realizar el diseño de las aplicaciones, ejecución de los procesos y carga de la metadata.
5. ¿Qué es Integración de Datos?

La integración de datos la podemos definir como el proceso de combinar datos que
residen en diferentes fuentes y permitirle al usuario final tener una vista unificada de todos sus
datos. La habilidad de transformar datos interdepartamentales de fuentes heterogéneas en un
plan de acción que se convertido en un reto y en una ventaja competitiva para compañías que
requieran la integración de datos.
La integración de datos es un elemento fundamental y crítico en la variedad de

tecnologías incluyendo Data Warehouse, aplicaciones de inteligencia de negocio, arquitecturas
orientada a servicio, aplicaciones MDM y arquitecturas data-centric.
Oracle conociendo la necesidad de la integración de datos para muchas empresas y

distintos tipos de industria, tiene una solución innovadora conocida como Oracle Data
Integrator.
6. ¿Qué es el Oracle Data Integrator (ODI)?

Oracle Data Integrator es una plataforma de integración completa que cubre los
requisitos de integración de datos. Maneja alto volumen, provee lotes de alto desempeño a
procesos dirigidos a eventos, a servicios de integración basados en una arquitectura orientada
a servicios y con la capacidad de procesar eventos en tiempo real.
Oracle Data Integrator maneja múltiples necesidades empresariales referentes a la

integración de datos:
• Data Warehousing e Inteligencia de Negocios tiene la capacidad de manejar grandes

volúmenes de datos con un desempeño óptimo para cargar Data Warehouse y Data
Mart. Maneja cargas incrementales, integridad de datos, reglas de negocio y
consistencia
• Arquitectura Orientada a Servicios. Provee la funcionalidad de invocar servicios
externos para propósitos de integración e implementar servicios de integración y
transformación integrados a una arquitectura orientada a servicios.
• Master Data Management – es una combinación de aplicaciones y tecnologías que
consolidan, limpian, mejora los datos maestros de la empresa y los sincroniza con
aplicaciones, procesos de negocio y herramientas analíticas como Oracle BIEE+.
• Migración – Provee cargas masivas eficientemente de datos históricos, incluyendo
transformaciones complejas de sistemas legados a sistemas nuevos.
7. ¿Quién Necesita ODI?

Toda empresa que necesite de sus datos para la toma de decisiones y la consolidación de
estos datos de diferentes fuentes de información más que una oportunidad o un reto debería
ser una acción a tomar.
8. Arquitectura De Oracle Data Integrator

El repositorio es el componente central dentro de la arquitectura de ODI. En éste se
almacena información de la configuración de la infraestructura de TI, la metadata de todas las
aplicaciones, proyectos, escenarios y registros de ejecución. Muchas instancias del repositorio
pueden coexistir en la infraestructura TI. La arquitectura del repositorio fue diseñado para
permitir varios ambientes separados de metadatos y escenarios (por ejemplo: desarrollo,
pruebas, mantención y entornos de producción). En la figura a continuación, se representan
dos repositorios: uno para Desarrollo y el otro para Producción. El repositorio también actúa
como un sistema de control de versiones donde los objetos se guardan y se les asigna un
número de versión. El repositorio de ODI se puede instalar en una base de datos relacional
OLTP.
Los administradores, desarrolladores y operadores utilizan interfaces gráficas de ODI

(GUI) para acceder a los repositorios. Estas GUIs ayudan en la administración de la
infraestructura (Seguridad y Topología), la ingeniería reversa de la metadata y proyectos de

desarrollo (Diseñador), la programación y los escenarios de operación y registros de ejecución

(Operador).
Ejemplo de Repositorio
9. Interfaces Gráficas
Las Interfaces gráficas de ODI son interfaces basadas en Java. Se pueden instalar en
cualquier plataforma que soporte una Máquina Virtual Java 1.4 (Windows, Linux, HP-UX,
Solaris, pSeries, etc.)
Las GUI de ODI se componen de 4 módulos:

• Topology Manager, interfaz gráfica de usuario que maneja los datos que describen la
arquitectura física y lógica de la infraestructura. Se utiliza para registrar servidores,
esquemas y representa el repositorio principal de ODI. Este módulo generalmente es
utilizado por los administradores.
• Security Manager, interfaz gráfica que permite al usuario administrar privilegios en
ODI. Se da acceso a los objetos a los distintos usuarios o perfiles. Este módulo es
utilizado generalmente por el Administrador de Seguridad.
• Designer, interfaz gráfica donde se define la Metada y la transformación de datos /
normas de calidad que generarán los escenarios de producción. Los Proyectos de
desarrollo se gestiona a partir de ese GUI. Es el módulo principal para desarrolladores
y los administradores de metadatos.

• Operator, interfaz gráfica para la gestión y seguimiento de Oracle Data Integrator en

producción. Está dedicado a los operadores y muestra los registros de la ejecución con
el número de errores potenciales, el número de filas procesadas, estadísticas de
ejecución, etc. Los desarrolladores también lo podrán utilizar para efectos de
depuración.
10. Repositorio
Los Repositorios de ODI generalmente se componen de un Master Repository,
principal y varios Work Repository. Los objetos desarrollados o configurados en ODI a
través de las GUI, se almacenan en lo Work Repository.
Por lo general, existe sólo un repositorio principal, el cual almacena la siguiente

información:
• Información de seguridad, incluidos los usuarios, perfiles y derechos sobre la
plataforma de ODI
• Información de topología incluidas las tecnologías, las definiciones de servidor,
esquemas, contextos, lenguajes, etc
• Versionamiento y almacenamiento de objetos.
La información contenida en el repositorio principal es mantenida por el Administrador de

Topología del módulo Security Manager.
El Repositorio de trabajo o Work Repository, contiene el desarrollo de las aplicaciones de

los distintos proyectos. Varios repositorios de trabajo pueden coexistir en la misma instalación
ODI (por ejemplo, para tener separados ambientes o para que coincida con un ciclo de vida de
versiones en particular). A Work Repository almacena la siguiente información:
• Modelos, incluida la definición de esquemas, estructuras almacenes de datos y

metadatos, campos y definiciones de columnas, restricciones de calidad de datos,
referencias cruzadas de datos linaje etc.
• Proyectos, incluyendo las reglas de negocio, paquetes, procedimientos, las carpetas,
los conocimientos Módulos o KM, variables, etc.
• Ejecución de Escenario, incluyendo escenarios de programación, información y
registros.
Cuando el Work Repository contiene sólo la información de ejecución (comúnmente

usado en producción), entonces se llama un Execution Repository.
La figura a continuación da una visión general de un repositorio (simplificado), muestra

la arquitectura de Desarrollo, Testing o Q&A y Producción están en Repositorios de trabajo
independientes.

Cuando el equipo de Desarrollo finaliza una versión del proyecto, este es exportado en
una única versión al Master Repository. El equipo de Test importa esta versión para pruebas a
un Work Repository, lo cual le permite al equipo de desarrollo continuar con el trabajo en una
nueva versión. Cuando las pruebas de validación realizadas por el equipo de Test son exitosas,
el equipo de Producción importa los ejecutables de esta versión, más bien llamados
escenarios, al repositorio final Execution Repository.
Se recomienda instalar estos repositorios en una base de datos distinta OLTP

de las aplicaciones fuente o de destino.
11. Scheduler Agent

El Scheduler Agent organiza la ejecución de escenarios desarrollados. Puede ser instalado
en cualquier plataforma que soporte una Máquina Virtual Java 1.4 (Windows, Linux, HP-UX,
Solaris, pSeries, iSeries, zSeries, etc.).
Sistemas de programación externos también pueden llamar al agente para que ejecute los
escenarios desarrollados.
Gracias a la arquitectura E-LT de Oracle Data Integrator, el Scheduler Agent rara vez
realiza transformaciones. Por lo general, simplemente recupera el código desde el Execution

Repository, y pide que los servidores de bases de datos o sistemas operativos lo ejecuten.
Después de la ejecución, el agente actualiza los registros en el repositorio, reportando
mensajes de error y las estadísticas de ejecución del proceso.
12. ODI y un Proyecto de Data Warehouse

El objetivo principal de almacenar datos es consolidar y entregar indicadores exactos a
los usuarios de negocios para ayudar en la toma de decisiones en su día a día del negocio. Un
proyecto típico se compone de varias etapas e hitos. Algunos de los estos son:
• Definición de las necesidades del negocio (indicadores clave)

• Identificación de fuentes de datos preocupación principal, indicadores, que
especifican las reglas de negocio; para transformar la información de origen en los
indicadores clave
• Modelado de la estructura de datos del destino donde se almacenarán los indicadores
clave
• Rellenar los indicadores mediante la aplicación de reglas de negocio
• Medición de la precisión global de los datos mediante la creación de datos de normas
de calidad
• Desarrollo de Informes sobre los indicadores clave
• Uso de los indicadores clave y metadatos disponibles para los usuarios de negocio a
través de herramientas adhoc de consulta o informes predefinidos
• Medición de la satisfacción de los usuarios de negocio y agregar / modificar los
indicadores clave
12.1.Organización de los Equipos

Como ODI se basa en un repositorio centralizado, diferentes tipos de usuarios puede ser
necesario para acceder a él. La lista a continuación describe la lista de usuarios comúnmente
definidos en ODI.
Perfil Descripción Módulo de ODI usado

Developer Los desarrolladores están a cargo de implementar para  Topology (read only
el negocio normas en relación con las especificaciones access)
descritas por los analistas de negocios. Su trabajo  Designer:
proporcionará los escenarios o ejecutables que serán • Limited access
instalador finalmente en producción. to Models
Los desarrolladores deben tener tanto conocimiento • Full access to
técnico y el conocimiento del negocio. Projects
 Operator
 Metadata Navigator
Metadata Los administradores de metadatos son los encargados  Topology (limited
Administrator de la fuente, reverse engineering y aplicaciones de access)
destino. Ellos garantizan la coherencia global de  Designer:
metadatos en el repositorio ODI. Tienen un excelente • Full access to
conocimiento de la estructura de las fuentes y Models

destinos, y han participado en el modelamiento de • Restore access

datos e indicadores clave. En conjunto con los to Projects
analistas de negocio, enriquecen los metadatos  Metadata Navigator
mediante la adición de comentarios, descripciones e
incluso reglas de integridad (tales como restricciones).
Los administradores de metadatos son responsables de
la gestión de versiones.
Database Los Database Administrators están encargados de la  Topology (full access)
Administrator definición de la infraestructura técnica de la Base de  Designer (full access)
Datos, que soportará ODI. Ellos crean los perfiles de  Operator (full access)
Base de Datos, que tendrán acceso a ODI. Crean  Metadata Navigator
esquemas separador y BD para almacenar las áreas de
Staging. . Todo esto lo realizan a través del Topology
Manager
Security El administrador de seguridad es el encargado de  Security (full access)
Administrator definir la política de seguridad para el repositorio de  Designer (read access)
ODI. Crea los usuarios ODI y les otorga los permisos y  Topology (read access)
accesos a los modelos, proyectos y contextos.  Metadata Navigator
Operator El Operador, estará a cargo de la importación de las  Operator
versiones y prueba de los escenarios, en el ambiente  Metadata Navigator
de Producción. Se encargará del agendamiento de
dichos escenarios, de la ejecución y reiniciar sesiones
fallidas cuando se necesite.
En estricto rigor los roles en una empresa no son tan definidos ni exclusivos, como se
muestran en el cuadro anterior.
12.2.Programación y Funcionamiento Escenarios (Scheduler)

Programación y operación de escenarios se realiza por lo general en repositorio de
Testing y en el Repositorio de Producción. El Operador ODI proporciona una interfaz gráfica
para realizar estas tareas. Cualquier escenario puede ser programado por el Agente de ODI.
Cuando un escenario se está ejecutando en producción, el agente generará registros de

ejecución en un Repositorio de Trabajo ODI. Estos registros pueden ser controlados a través
del Operator o a través de cualquier navegador web.
12.3.Definición de la Topología
La topología describe la arquitectura física y lógica del Sistema. Se le da una forma muy
flexible a la gestión de los diferentes servidores, entornos y agentes. Toda la información de la
topología se almacena en ODI en el Master Repository y por lo tanto es centralizado para una
administración optimizada. Todos los objetos manipulados dentro de los Repositorios de trabajo
se refieren a la topología. Es por eso que es el punto de partida más importante en la definición
y la planificación de su arquitectura.
Los proyectos típicos tendrán ambientes separados para el Desarrollo, Prueba y

Producción. Algunos proyectos incluso tendrán varias pruebas o producción duplicación de
ambientes. Por ejemplo, es posible tener varios contextos de producción de filiales que
ejecutan sus propios sistemas de producción (Production New York, Producción Boston, etc). Es

evidente que hay una diferencia entre la vista lógica dell sistema de información y su
implementación física como se describe en la figura a continuación.
La vista lógica describe esquemas lógicos que representan los esquemas físicos de las
aplicaciones existentes, independientemente de su implementación física. Estos esquemas
lógicos son entonces vinculados a los recursos físicos a través de contextos.
Los diseñadores siempre se refieren a la vista lógico definido en la topología. Todo el

desarrollo hecho por lo tanto, se vuelve independiente de la ubicación física de los recursos que
Dirección. En tiempo de ejecución, la información lógica se asigna a los recursos físicos, dados
los contextos apropiados. El mismo escenario se puede ejecutar en diferentes servidores físicos
y aplicaciones con sólo especificar diferentes contextos. Este trae una arquitectura muy flexible
donde los desarrolladores no tienen que preocuparse por la subyacente a la ejecución física de
los servidores de los que dependen.
12.4.Servidores de Datos
Los Servidores de datos describen las conexiones a los servidores de aplicaciones reales
físicos y bases de datos. Ellos se pueden representar, por ejemplo:
• Sistema de Teradata
• Instancia Oracle

• Base de datos IBM DB2

• IBM DB2 iSeries Instancia
• Instancia de Microsoft SQL Server
• Servidor Sybase ASE
• Enrutador Websphere MQ
• Sistema de archivos
• Archivo XML
• Microsoft Excel
ODI utiliza controladores JDBC para conectarse a las fuentes de datos siguientes:
• Bases de datos relacionales, tales como servidores Teradata, Oracle, IBM DB2,
Microsoft SQL Server, Sybase, Informix, MySQL, PostgreSQL, etc
• Bases de datos de escritorio como Microsoft Access, Hypersonic SQL, Dbase, FoxPro,
Microsoft Excel, etc
• Los archivos binarios ASCII o cuando se utiliza el controlador JDBC DE ODI para
archivos. Este requiere que el archivo sea cargado por un Agente ODI. Este controlador
no se utiliza cuando el agente llama a cargadores de bases de datos nativas como
FastLoad, multicarga, SQL * Loader, BCP, etc
• Los archivos XML, utilizando ODI JDBC Driver para XML. Cualquier estructura de
archivos XML es convertido por este controlador en una estructura de base de datos
relacional (ya sea en la memoria o persistentemente en cualquier otra base de datos)
• Directorios LDAP, utilizando ODI abierto Conector para LDAP.
• Las bases de datos no relacionales, tales como IMS, ADABASE, DATACOM, VSAM, etc,
mediante el uso de adaptadores de otras marcas (iWay, Attunity, Software Hit son
ejemplos de proveedores de soluciones)
Definición de cuentas de usuario o inicios de sesión de ODI para acceder a los servidores
de datos.
En tiempo de ejecución, el agente ODI necesitará un nombre de usuario y contraseña

para conectarse a los servidores de datos. Una buena práctica consiste en crear una conexión
dedicada en cada servidor de datos que se debe accederá en el ODI. El uso del inicio de una
sesión para cada servidor trae beneficios como privilegios de administración puede ser
centralizada por la base de datos administrador. Por lo general, todos los servidores de datos
tienen varios esquemas (o bases de datos o catálogos o directorios o bibliotecas) en virtud del
cual los almacenes de datos (tablas, vistas, archivos, colas, etc.) se almacenan. Se recomienda
que el agente ODI utilice una única conexión para cada servidor de datos.
ODI almacena versiones encriptada de las contraseñas de todos los servidores de datos
en el Master Repository. Es muy importante asegurar el acceso a la base de datos que aloja el
Repositorio principal de ODI.

13. Algunas Definiciones de Esquemas de Trabajo

para el Área de Staging
Los Módulos de Conocimiento de ODI KM, a menudo usan objetos temporales para
organizar los datos temporales, con el fin de optimizar el trabajo. Estos objetos temporales se
almacenan siempre en un esquema concreto o directorio llamado el esquema de trabajo (o
área de preparación).
En los servidores de datos de destino, se debe crear un esquema dedicado a esta área.
Con el fin de una mejor administración de esta área y evitar la contaminación a los esquemas
fuentes o de destino. Aquí se almacenará:
• Tablas temporales y vistas creadas durante la fase de carga si la fuente de datos no
están en el mismo servidor que el objetivo (C $ tabla)
• Tablas temporales creadas durante la fase de integración en determinados Módulos de
Conocimiento Integración (I $ tabla)
• Tablas de errores permanentes creadas durante la fase de control de calidad de los
datos usada por el KM de Check (E $ tabla)
14. Definición del Dataserver

Al convertir una interfaz al código, ODI utiliza definiciones de datos de los servidores para
determinar las fases de carga. Tener 2 servidores de datos definidos que apunta a una solo
servidor de datos físico puede causar fases de carga adicionales que no son necesarios. Por lo
tanto se recomiendan definir un servidor de datos único por servidor físico,
independientemente del número de esquemas físicos que se necesiten ser accesados en este
servidor. Por ejemplo, se considera un sistema único de Teradata, sólo un servidor de datos
debe ser definido en el Administrador de Topología.
Para definir el servidor de datos, puede seguir estos pasos:
1. Del administrador de base de datos o de aplicación crear un login (nombre de usuario de

inicio de sesión y contraseña) para este servidor de datos.
2. Crear un esquema de trabajo para almacenar objetos temporales y asignar por default el
login previamente creado. Ajustar el tamaño de dicho esquema en relación al tamaño de
las tablas temporales que serán creadas. Por ejemplo, Un servidor de destino el tamaño de
su esquema debería ser al menos dos veces el tamaño de las transacciones simultáneas
que se ejecutan en paralelo.
3. Asegúrese de que puede conectarse correctamente al servidor de datos de cualquier ODI
cliente o agente, utilizando las herramientas de cliente.
4. Copie el JDBC o JMS o las bibliotecas de Java necesarios para conectarse a la servidor de
datos en el directorio "drivers" de la instalación de ODI. (ver ODI ayuda en línea para más
detalles)
5. Pruebe la conexión con un cliente JDBC puro como Squirrel-sql (suministrado e instalado
por defecto con ODI)
6. En el Administrador de Topología, cree un nuevo servidor de datos de la siguiente manera:
• Nombre de usuario y contraseña: Utilice la información de inicio de sesión para
el inicio de sesión específico que ha creado para la ODI.

Definir el controlador JDBC o JNDI (consulte la documentación del controlador)

•
Defina la URL (utilizar nombres de host en lugar de direcciones IP siempre que
•
sea posible)
• Pruebe su conexión a nivel local y de todos los agentes que se ha definido
7. El nombre que le asigne al servidor de datos es muy importante.

Ejemplo de creación de DataServer Oracle:

Ejemplo de creación de DataServer Microsoft Sqlserver :
15. Esquemas Físicos

El Esquema físico indica la ubicación física del almacén de datos (tablas, archivos, colas,
etc) dentro de un servidor de datos. Al acceder a un servidor de datos JDBC. Todos los
esquemas físicos que necesitan ser accesados tienen que estar registrados en el servidor de
datos correspondiente. Esquemas físicos se utilizan para nombres de los objetos de prefijo
cuando se genera código (nombres completos).
Al crear un esquema físico, es necesario especificar un esquema temporal o área de

trabajo permanente, en el cual se almacenarán los objetos temporales necesarios en tiempo de
ejecución. Se debe seleccionar el esquema temporal o de trabajo permanente, previamente
definido en el servidor de datos. Algunos objetos que ODI, puede crear en el área temporal o
de trabajo:
• Carga de tablas temporales creadas por los Módulos de Conocimiento de carga -LKM
(generalmente precedido por C $)
• Tablas de Integración temporales creados por los módulos de integración de
conocimientos - IKM (por lo general prefijado por I $)
• Tablas de errores permanente al utilizar datos de los módulos de conocimiento de
calidad – CKM (por lo general prefijado por E $)

16. Contextos
Los contextos se utilizan para agrupar los recursos físicos que pertenecen al mismo
entorno. Una vez creado en topología, se debe evitar el borrado o la modificación del código de
un contexto, ya que puede ser referenciado en uno o más repositorios de trabajo. Un proyecto
típico tendrá muy pocos contextos (menos de 10). Estos pueden ser, por ejemplo:
Es importante tener el mismo número de servidores de datos y esquemas definidos

dentro de cada contexto. Por ejemplo, se tiene 2 servidores de destino de producción y sólo un
servidor de destino para desarrollo, probablemente debería dividir la definición del servidor de
destino por el desarrollo en 2 servidores de datos en la arquitectura física definición tal como
se muestra en la figura a continuación:

A partir de este ejemplo, podemos ver que el servidor SRV_DEV tiene que ser definido en
dos ocasiones en la arquitectura física para que coincida con el entorno físico real en producción.
Por lo tanto los servidores de datos definidos SRV_DEV_CRM y SRV_DEV_SFA ambos referencian al
mismo servidor de datos SRV_DEV. De esta manera, el servidor de datos SRV_DEV se maneja
como 2 servidores independientes en la generación de código en el contexto del Desarrollo. Así
este código será válido cuando se ejecute en los servidores de producción.
17. Esquemas Lógicos

Un esquema lógico es un alias que permite a un único nombre que se dará a todo el
esquema físico que contienen las mismas estructuras del almacén de datos. El objetivo del
esquema lógico es para garantizar la portabilidad de los procedimientos y modelos de
diferentes esquemas físicos en tiempo de ejecución. Un esquema lógico puede tener uno o más
implementaciones físicas en esquemas físicos separados, sino que deben basarse en los
servidores de datos de la misma la tecnología. Un esquema lógico siempre está directamente
vinculado a una tecnología. Para ser útil, un esquema lógico debe ser declarado en un
contexto. Declarar un esquema lógico en un contexto consiste en indicar qué esquema físico
corresponde al alias -esquema lógico - para este contexto.
En tiempo de ejecución, el agente utilizará la siguiente fórmula para determinar el recurso
físico:
Nombre lógico del esquema + Contexto = 1 esquema físico (y 1 Physical Data Server
también)

18. Agentes Físicos y Lógicos

Un agente físico es un servicio ODI Java que se ejecuta en un host como un oyente en un
TCP / IP. Puede ejecutar los escenarios cuando se invoca desde una de las Módulos de interfaz
gráfica de usuario ODI o programar estas ejecuciones cuando se inicia como un programador.
Un agente físico debe tener un nombre único en Administrador de Topología. Se hace

referencia a la dirección IP o el nombre de su huésped y el TCP puerto en el que está
escuchando.
Un agente físico puede ejecutar varias sesiones en paralelo (multi-threaded). Para fines
de optimización, se recomienda que ajuste el número máximo de sesiones simultáneas que se
permite para ejecutar. Cuando este número máximo es alcanzado, cualquier nueva sesión
entrante se pondrá en cola por el agente y ejecutado más tarde cuando otras sesiones han
terminado.
Los agentes físicos son parte de la arquitectura física. Por lo tanto, se puede optar por
tener diferentes agentes de acuerdo con su entorno y contextos. Para ello, definir un agente
lógico y vincularlo a varios agentes físicos de acuerdo con el contexto. Al iniciar una sesión,
basta con indicar que el agente lógico y el contexto y ODI se traducirán a la dirección física del
agente.
19. Definición de Modelos

Uno de los temas clave de su proyecto de almacenamiento de datos es entender y
localizar los almacenes de datos (estructuras de datos) es necesario para la construcción de
indicadores clave de negocio de los usuarios. Estos almacenes de datos, que se encuentra en
un esquema lógico, se componen generalmente de campos (o columnas), unidos entre sí a
través de reglas de integridad referencial y seguida por reglas de singularidad y otras relaciones
de campo y limitaciones.
Modelos ODI representan los modelos de datos de su sistema de información. Se refieren

a un conjunto de almacenes de datos en un esquema lógico. Todas las asignaciones y
transformaciones consulten almacenes de datos los campos y las limitaciones modelos de
datos.
ODI no distingue entre los modelos de origen y destino. Los modelos se guardan en el
Repositorio de trabajo y son la base para la creación de reglas de negocio. Ellos centralizan los
metadatos del núcleo de sus sistemas.
Almacenes de datos en un modelo pueden ser organizados en sub-modelos y además se

pueden agrupar en carpetas.
Un almacén de datos generalmente es:

• Tabla almacenada en una base de datos relacional
• Archivo ASCII o EBCDIC (delimitado o ancho fijo)
• Nodo desde un archivo XML
• una API que devuelve datos en la forma de un conjunto de registros

Esta abstracción permite ODI para conectar teóricamente a cualquier fuente de datos.
Modelos referencia a una base de datos relacional se pueden rellenar automáticamente de
las tablas y vistas de definición del RDBMS a través de la API JDBC. Para otros modelos,
deberán definir los metadatos de forma manual o escribir una reverseengineering específica KM
que pueble el repositorio de trabajo ODI desde una metadatos provista.
20. Contenido del Modelo

Los modelos pueden contener los siguientes objetos:
• Sub-módulo: Sub-modelos son carpetas dentro de un modelo que se puede utilizar
para organizar sus almacenes de datos.
• Datastores: Un almacén de datos representa un conjunto de registros con formato de
una lógica esquema de un servidor de datos
• Columns: Las columnas representan los atributos o campos pertenecientes a un
almacén de datos.Se definen típicamente con un nombre de columna única, una breve
descripción, una posición, un tipo de datos, la longitud y la escala, un indicador
obligatorio (no nula), y otros datos de comprobación de atributos.
• Constraints: Las constraints definen reglas de negocio de datos adicionales de calidad
que aplicar en el nivel de datos para el almacén de datos. Al obtener los metadatos de
un RDBMS, algunas de las restricciones definidas en el esquema físicas son importado.
Se puede agregar sus propias limitaciones en el almacén de datos para los datos fines
de control de calidad sin alterar los esquemas de bases de datos. La los siguientes tipos
de restricciones puede ser ingeniería inversa (inverso) en ODI.
• Primary Key: Una clave principal se define la lista de columnas que sirven
para identificar de forma única un registro en un almacén de datos. se
recomienda que los se define una clave primaria para cada almacén de datos
del modelo. Las columnas que participan en la clave principal deben ser
definidos como obligatoria.
• Unique Key (Keys Alternativa): Una clave única define una lista alternativa de
columnas que se pueden identificar de forma exclusiva un registro. Las
columnas que pertenecen a una clave única pueden contener valores
nulos.Definición de claves únicas puede ayudar a hacer cumplir la singularidad
de registros de acuerdo a diferentes criterios que la clave principal (por
ejemplo, controlando que el (nombre-cliente + phone_number) son únicos en
la tabla cliente identificado por la customer_id)
• Índices: un índice define un conjunto de columnas indexadas en la base de
datos. Los índices se definen a título sólo informativo.
• References (Foreing Key): Una referencia definen una relación entre 2
almacenes de datos para exigir la integridad referencial. ¿Cuándo claves
externas no se aplican en el esquema físico, es recomienda definir de forma
manual para el modelo y han ODI realizar el control de calidad de los datos
durante la integración. ODITambién se ha introducido un tipo de referencia
compleja que le permite definir una relación entre 2 almacenes de datos que
deben coincidir con un complejo Expresión SQL en lugar de la igualdad entre
clave externa campos y campos de referencia de clave principal. Este tipo de
referencia es muy útil cuando se trata de los modelos no en tercera forma

normal donde los valores de columna pueden tener varios significados. Un

ejemplo de utilizando una referencia compleja podría ser: "verificar que los 3
primeros caracteres en el campo de la dirección de la tabla de clientes que
coincida con el clave de código de país del país de tabla "
• Conditions: Una condición define una expresión que un registro deben
coincidir para ser considerado válido. Una condición puede ser implementada
en la base de datos como una restricción de comprobación.
• Filters: Un filtro define una expresión de filtrado predeterminada utilizada al
el almacén de datos es una fuente de una interfaz ODI. Cuando el almacén de
datos es arrastrado y soltado en la interfaz, la condición de filtro se convierte
en un filtro en la interfaz.
21. Contenidos de Proyectos ODI

Los Proyectos almacenan objetos que se desarrollan para poblar el repositorio de datos.
Proyectos se pueden organizar en carpetas y contener los siguientes tipos de objetos:
• Carpetas: Las carpetas se utilizan para organizar los objetos desarrollados dentro de
un proyecto. Tenga cuidado al hacer referencia a los objetos a través de las carpetas,
ya que puede conducir a importar temas / exportación. Por ejemplo, trate de evitar la
referencia a las interfaces de otra carpeta dentro de un paquete de su carpeta actual
tanto como sea posible. Dentro de las carpetas tenemos:
o Interfaces: Los principales objetos donde el diseño de su transformación
como reglas de negocio. Interfaces asignan varios almacenes de datos
heterogéneos a una fuente almacén de datos de destino.
o Procedimientos: Compuesto por un conjunto de pasos que le permiten
ejecutar su propia código específico. Este código puede ser SQL de base de
datos específica (por ejemplo, PL / SQL o Transact SQL), los comandos del
sistema operativo, Java, Jython, o ODI comandos integrados (API ODI). Pasos
dentro de un procedimiento pueden mezclar llamadas a cualquiera de estos
idiomas programáticas. Un mecanismo de control de transacción es También
disponible para los comandos de base de datos específica.
o Packages: Los paquetes se utilizan para implementar un flujo de trabajo
técnico integrado de varios pasos unidos entre sí. Ellos definen la secuencia de
ejecución de puestos de trabajo que va a liberar en la producción.
• Módulos de Conocimiento, KM: La piedra angular para las interfaces de
construcción para rellenar objetivo almacenes de datos de fuentes heterogéneas
• Variables: Las variables definidas en un proyecto pueden ser utilizados en cualquier
lugar dentro de la alcance de ese proyecto. Ellos se pueden actualizar o consultar en
tiempo de ejecución. Paquetes puede evaluar o cambiar su valor actual para
implementar estructuras de control. Las variables se pueden fijar como persistente que
se mantiene en tiempo de ejecución múltiple sesiones.
• Secuencias: Secuencias son objetos que pueden ser utilizados por el agente como un
ODI contrarrestar. Se pueden utilizar, por ejemplo, para asignar una calculada
automáticamente número de serie a un campo de un almacén de datos. Sin embargo,
como los valores de secuencias son gestionados por el agente, usando los obliga una

carga de trabajo a procesar fila por fila en lugar de a granel, lo que puede dar lugar a
problemas de rendimiento. Por lo tanto, tenga cuidado al considerar el uso de
secuencias. Cuando las bases de datos tienen instalaciones para la asignación de un
contador automático para una columna (por ejemplo, secuencias o las columnas de
identidad), ODI recomienda el uso de estos mecanismos, como lo harán siempre ser
más eficiente que Secuencias ODI'Ss.
• Funciones de usuario: El uso de las funciones de usuario se recomienda cuando el
mismo patrón de transformación tiene que ser asignado a diferentes almacenes de
datos en diferentes interfaces.
Nota:
Proyectos en la terminología ODI no necesariamente coinciden con la definición de empresa de un
proyecto. Se puede tener varios proyectos definidos en ODI, todos ellos pertenecientes al mismo
Proyecto "Almacenamiento de datos", por ejemplo, se puede tener un proyecto por áreas de
negocio en lugar de un gran proyecto que contiene todo. Incluso se recomienda dividir su
desarrollo en varios proyectos pequeños que contengan menos de 300 objetos. De esta forma
mejorará la eficiencia de sus operaciones de control de versiones de importación / exportación.
22. Diferentes Tipos de Módulos de Conocimiento

• RKM (Reverse Knowledge Modules), se utilizan para realizar una ingeniería inversa
personalizada de los modelos de datos para una tecnología específica.
• LKM (Loading Knowledge Modules), se utilizan para extraer datos de la base de datos
fuente mesas y otros sistemas (archivos, middleware, centrales, etc.)
• JKM (Journalizing Knowledge Modules), se utilizan para crear un diario de las
modificaciones de datos (insertar, actualizar y eliminar) las bases de datos de origen
para realizar un seguimiento de los cambios.
• IKM (Integration Knowledge Modules), se utilizan para integrar datos (carga) para las
tablas de destino.
• CKM (Check Knowledge Modules), se utilizan para comprobar que las restricciones
sobre las fuentes y los destinos no sean violados.
• SKM (Service Knowledge Modules), se utilizan para generar el código necesario para la
creación de los datos servicios.
23. Consideraciones en ODI

• Identificar la tabla destino
• Identificar las tablas fuentes
• Identificar tablas de Referencia (Lookup)
• Seleccionar e importar los módulos de conocimiento para la extracción
• Verificar los pareos de campos (mapping)
• Pareos Automáticos
• Columnas no nulas

• Añadir columnas adicionales

• Probar regularmente la extracción
• En las transformaciones
• Identificar, verificar y validar las condiciones
• Verificar y validar campos y funciones para convertir formatos de fecha
• Verificar tamaños de columnas para no truncar los datos extraídos o que de
algún tipo de error
• Verificar los tipos de datos(Datatype)
• Verificar las secuencias
Oracle Data Integrator provee una plataforma de integración con capacidad de alto
desempeño y productividad el cual provee un alto grado de flexibilidad y modularidad. El Oracle
Data Integrator cumple con todas aquellas necesidades asociadas a la integración de datos
incluyendo data Warehouse e inteligencia de negocios, integración de procesos, migraciones y
todas aquellas iniciativas donde se requieran los datos correctos, en el lugar correcto en el
momento correcto

Collahuasi CEDW DocBuenasP

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Collahuasi CEDW DocBuenasP

Cargado por

Copyright:

Formatos disponibles

Collahuasi Enterprise

Registro de Cambios en el Documento

Documento de Buenas Prácticas ODI

Collahuasi Enterprise Datawarehouse 2 de 24

Ámbito del Documento

Proyecto Collahuasi Enterprise Datawarehouse

Audiencia del Documento

Nombre Empresa Cargo

Elizabeth Funes INYS Consultor INYS

Collahuasi Enterprise Datawarehouse 3 de 24

Collahuasi Enterprise Datawarehouse 4 de 24

2. Propósito del documento

El objetivo de este documento es presentar buenas prácticas y estandarizar la

5. ¿Qué es Integración de Datos?

La integración de datos es un elemento fundamental y crítico en la variedad de

Oracle conociendo la necesidad de la integración de datos para muchas empresas y

6. ¿Qué es el Oracle Data Integrator (ODI)?

Collahuasi Enterprise Datawarehouse 5 de 24

Oracle Data Integrator maneja múltiples necesidades empresariales referentes a la

• Data Warehousing e Inteligencia de Negocios tiene la capacidad de manejar grandes

7. ¿Quién Necesita ODI?

8. Arquitectura De Oracle Data Integrator

Los administradores, desarrolladores y operadores utilizan interfaces gráficas de ODI

Collahuasi Enterprise Datawarehouse 6 de 24

desarrollo (Diseñador), la programación y los escenarios de operación y registros de ejecución

Las GUI de ODI se componen de 4 módulos:

Collahuasi Enterprise Datawarehouse 7 de 24

• Operator, interfaz gráfica para la gestión y seguimiento de Oracle Data Integrator en

Por lo general, existe sólo un repositorio principal, el cual almacena la siguiente

La información contenida en el repositorio principal es mantenida por el Administrador de

El Repositorio de trabajo o Work Repository, contiene el desarrollo de las aplicaciones de

• Modelos, incluida la definición de esquemas, estructuras almacenes de datos y

Cuando el Work Repository contiene sólo la información de ejecución (comúnmente

La figura a continuación da una visión general de un repositorio (simplificado), muestra

Collahuasi Enterprise Datawarehouse 8 de 24

Se recomienda instalar estos repositorios en una base de datos distinta OLTP

11. Scheduler Agent

Collahuasi Enterprise Datawarehouse 9 de 24

12. ODI y un Proyecto de Data Warehouse

• Definición de las necesidades del negocio (indicadores clave)

12.1.Organización de los Equipos

Perfil Descripción Módulo de ODI usado

Collahuasi Enterprise Datawarehouse 10 de 24

destinos, y han participado en el modelamiento de • Restore access

12.2.Programación y Funcionamiento Escenarios (Scheduler)

Cuando un escenario se está ejecutando en producción, el agente generará registros de

Los proyectos típicos tendrán ambientes separados para el Desarrollo, Prueba y

Collahuasi Enterprise Datawarehouse 11 de 24

Los diseñadores siempre se refieren a la vista lógico definido en la topología. Todo el

Collahuasi Enterprise Datawarehouse 12 de 24

• Base de datos IBM DB2

En tiempo de ejecución, el agente ODI necesitará un nombre de usuario y contraseña

Collahuasi Enterprise Datawarehouse 13 de 24

13. Algunas Definiciones de Esquemas de Trabajo

14. Definición del Dataserver

Para definir el servidor de datos, puede seguir estos pasos:

1. Del administrador de base de datos o de aplicación crear un login (nombre de usuario de

Collahuasi Enterprise Datawarehouse 14 de 24

Definir el controlador JDBC o JNDI (consulte la documentación del controlador)

Collahuasi Enterprise Datawarehouse 15 de 24

Ejemplo de creación de DataServer Oracle:

Collahuasi Enterprise Datawarehouse 16 de 24

Ejemplo de creación de DataServer Microsoft Sqlserver :