Collahuasi CEDW DocBuenasPracticasODI

Collahuasi Enterprise
Datawarehouse
CEDW - Buenas Prcticas
Documento de Buenas Prcticas ODI
Versin: 1.0
Documento de Buenas Prcticas ODI : CEDW - Buenas Prcticas
Registro de Cambios en el Documento
Documento de Buenas Practicas Base de Datos

C.I. CEDW-BP-ODI
Versin Fecha Autor de los Comentarios
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 Practicas
Empresa Inys Consulting
Cliente CMDIC
Jefe de Proyecto Rodolfo Muoz
Fase Desarrollo
Responsable Rodolfo Muoz
Audiencia del Documento
Nombre Empresa Cargo

No Aravena CMDIC Analista Snior de Reportabilidad
Patricio Plaza CMDIC Analista Snior de Reportabilidad
Elizabeth Funes INYS Consultor INYS

Rodrigo Flores INYS Consultor INYS
Jorge Medida INYS Jefe de Proyecto INYS
Rodolfo Muoz INYS Jefe de Proyecto INYS

1. Tabla de Contenidos
1. Tabla de Contenidos ........................................................................................................... 4

2. Propsito del documento..................................................................................................... 5
3. Alcance .............................................................................................................................. 5
4. Audiencia ........................................................................................................................... 5
5. Qu es Integracin de Datos? ............................................................................................ 5
6. Qu es el Oracle Data Integrator (ODI)? ............................................................................ 5
7. Quin Necesita ODI? ......................................................................................................... 6
8. Arquitectura De Oracle Data Integrator ................................................................................ 6
9. Interfaces Grficas ............................................................................................................. 7
10. Repositorio ......................................................................................................................... 8
11. Scheduler Agent ................................................................................................................. 9
12. ODI y un Proyecto de Data Warehouse .............................................................................. 10
12.1. Organizacin de los Equipos ....................................................................................... 10
12.2. Programacin y Funcionamiento Escenarios (Scheduler) .............................................. 11
12.3. Definicin de la Topologa .......................................................................................... 11
12.4. Servidores de Datos................................................................................................... 12
13. Algunas Definiciones de Esquemas de Trabajo para el rea de Staging ................................ 14
14. Definicin del Dataserver .................................................................................................. 14
15. Esquemas Fsicos.............................................................................................................. 17
16. Contextos ........................................................................................................................ 18
17. Esquemas Lgicos ............................................................................................................ 19
18. Agentes Fsicos y Lgicos .................................................................................................. 20
19. Definicin de Modelos ....................................................................................................... 20
20. Contenido del Modelo ....................................................................................................... 21
21. Contenidos de Proyectos ODI ............................................................................................ 22
22. Diferentes Tipos de Mdulos de Conocimiento .................................................................... 23
23. Consideraciones en ODI .................................................................................................... 23

2. Propsito del documento
El objetivo de este documento es presentar buenas prcticas y estandarizar la

nomenclatura de nombres utilizada en el diseo y mantenimiento de bases de datos del CEDW.
Por mejores prcticas 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 integracin de ODI, para el CEDW.
Lo definido en este documento debiera ser el ideal a considerar, para el buen desarrollo
de aplicaciones de integracin 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 tcnicos del departamento de Reporting Corporativo, que tengan entre sus tareas
realizar el diseo de las aplicaciones, ejecucin de los procesos y carga de la metadata.
5. Qu es Integracin de Datos?
La integracin 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 heterogneas en un
plan de accin que se convertido en un reto y en una ventaja competitiva para compaas que
requieran la integracin de datos.
La integracin de datos es un elemento fundamental y crtico en la variedad de

tecnologas incluyendo Data Warehouse, aplicaciones de inteligencia de negocio, arquitecturas
orientada a servicio, aplicaciones MDM y arquitecturas data-centric.
Oracle conociendo la necesidad de la integracin de datos para muchas empresas y

distintos tipos de industria, tiene una solucin innovadora conocida como Oracle Data
Integrator.
6. Qu es el Oracle Data Integrator (ODI)?

Oracle Data Integrator es una plataforma de integracin completa que cubre los
requisitos de integracin de datos. Maneja alto volumen, provee lotes de alto desempeo a
procesos dirigidos a eventos, a servicios de integracin basados en una arquitectura orientada
a servicios y con la capacidad de procesar eventos en tiempo real.
Oracle Data Integrator maneja mltiples necesidades empresariales referentes a la

integracin de datos:
Data Warehousing e Inteligencia de Negocios tiene la capacidad de manejar grandes

volmenes de datos con un desempeo 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 propsitos de integracin e implementar servicios de integracin y
transformacin integrados a una arquitectura orientada a servicios.
Master Data Management es una combinacin de aplicaciones y tecnologas que
consolidan, limpian, mejora los datos maestros de la empresa y los sincroniza con
aplicaciones, procesos de negocio y herramientas analticas como Oracle BIEE+.
Migracin Provee cargas masivas eficientemente de datos histricos, incluyendo
transformaciones complejas de sistemas legados a sistemas nuevos.
7. Quin Necesita ODI?

Toda empresa que necesite de sus datos para la toma de decisiones y la consolidacin de
estos datos de diferentes fuentes de informacin ms que una oportunidad o un reto debera
ser una accin a tomar.
8. Arquitectura De Oracle Data Integrator

El repositorio es el componente central dentro de la arquitectura de ODI. En ste se
almacena informacin de la configuracin de la infraestructura de TI, la metadata de todas las
aplicaciones, proyectos, escenarios y registros de ejecucin. Muchas instancias del repositorio
pueden coexistir en la infraestructura TI. La arquitectura del repositorio fue diseado para
permitir varios ambientes separados de metadatos y escenarios (por ejemplo: desarrollo,
pruebas, mantencin y entornos de produccin). En la figura a continuacin, se representan
dos repositorios: uno para Desarrollo y el otro para Produccin. El repositorio tambin acta
como un sistema de control de versiones donde los objetos se guardan y se les asigna un
nmero de versin. El repositorio de ODI se puede instalar en una base de datos relacional
OLTP.
Los administradores, desarrolladores y operadores utilizan interfaces grficas de ODI

(GUI) para acceder a los repositorios. Estas GUIs ayudan en la administracin de la
infraestructura (Seguridad y Topologa), la ingeniera reversa de la metadata y proyectos de
desarrollo (Diseador), la programacin y los escenarios de operacin y registros de ejecucin
(Operador).

Ejemplo de Repositorio
9. Interfaces Grficas
Las Interfaces grficas de ODI son interfaces basadas en Java. Se pueden instalar en
cualquier plataforma que soporte una Mquina Virtual Java 1.4 (Windows, Linux, HP-UX,
Solaris, pSeries, etc.)
Las GUI de ODI se componen de 4 mdulos:

Topology Manager, interfaz grfica de usuario que maneja los datos que describen la
arquitectura fsica y lgica de la infraestructura. Se utiliza para registrar servidores,
esquemas y representa el repositorio principal de ODI. Este mdulo generalmente es
utilizado por los administradores.
Security Manager, interfaz grfica que permite al usuario administrar privilegios en
ODI. Se da acceso a los objetos a los distintos usuarios o perfiles. Este mdulo es
utilizado generalmente por el Administrador de Seguridad.
Designer, interfaz grfica donde se define la Metada y la transformacin de datos /
normas de calidad que generarn los escenarios de produccin. Los Proyectos de
desarrollo se gestiona a partir de ese GUI. Es el mdulo principal para desarrolladores
y los administradores de metadatos.
Operator, interfaz grfica para la gestin y seguimiento de Oracle Data Integrator en
produccin. Est dedicado a los operadores y muestra los registros de la ejecucin con
el nmero de errores potenciales, el nmero de filas procesadas, estadsticas de

ejecucin, etc. Los desarrolladores tambin lo podrn utilizar para efectos de

depuracin.
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
travs de las GUI, se almacenan en lo Work Repository.
Por lo general, existe slo un repositorio principal, el cual almacena la siguiente

informacin:
Informacin de seguridad, incluidos los usuarios, perfiles y derechos sobre la
plataforma de ODI
Informacin de topologa incluidas las tecnologas, las definiciones de servidor,
esquemas, contextos, lenguajes, etc
Versionamiento y almacenamiento de objetos.
La informacin contenida en el repositorio principal es mantenida por el Administrador de

Topologa del mdulo 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 instalacin
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 informacin:
Modelos, incluida la definicin 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 Mdulos o KM, variables, etc.
Ejecucin de Escenario, incluyendo escenarios de programacin, informacin y
registros.
Cuando el Work Repository contiene slo la informacin de ejecucin (comnmente

usado en produccin), entonces se llama un Execution Repository.
La figura a continuacin da una visin general de un repositorio (simplificado), muestra

la arquitectura de Desarrollo, Testing o Q&A y Produccin estn en Repositorios de trabajo
independientes.

Cuando el equipo de Desarrollo finaliza una versin del proyecto, este es exportado en
una nica versin al Master Repository. El equipo de Test importa esta versin para pruebas a
un Work Repository, lo cual le permite al equipo de desarrollo continuar con el trabajo en una
nueva versin. Cuando las pruebas de validacin realizadas por el equipo de Test son exitosas,
el equipo de Produccin importa los ejecutables de esta versin, ms 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 ejecucin de escenarios desarrollados. Puede ser instalado
en cualquier plataforma que soporte una Mquina Virtual Java 1.4 (Windows, Linux, HP-UX,
Solaris, pSeries, iSeries, zSeries, etc.).
Sistemas de programacin externos tambin 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 cdigo desde el Execution

Repository, y pide que los servidores de bases de datos o sistemas operativos lo ejecuten.
Despus de la ejecucin, el agente actualiza los registros en el repositorio, reportando
mensajes de error y las estadsticas de ejecucin 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 da a da del negocio. Un
proyecto tpico se compone de varias etapas e hitos. Algunos de los estos son:
Definicin de las necesidades del negocio (indicadores clave)

Identificacin de fuentes de datos preocupacin principal, indicadores, que
especifican las reglas de negocio; para transformar la informacin de origen en los
indicadores clave
Modelado de la estructura de datos del destino donde se almacenarn los indicadores
clave
Rellenar los indicadores mediante la aplicacin de reglas de negocio
Medicin de la precisin global de los datos mediante la creacin 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
travs de herramientas adhoc de consulta o informes predefinidos
Medicin de la satisfaccin de los usuarios de negocio y agregar / modificar los
indicadores clave
12.1. Organizacin 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 continuacin describe la lista de usuarios comnmente
definidos en ODI.
Perfil Descripcin Mdulo de ODI usado

Developer Los desarrolladores estn a cargo de implementar para Topology (read only
el negocio normas en relacin con las especificaciones access)
descritas por los analistas de negocios. Su trabajo Designer:
proporcionar los escenarios o ejecutables que sern Limited access
instalador finalmente en produccin. to Models
Los desarrolladores deben tener tanto conocimiento Full access to
tcnico 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 adicin de comentarios, descripciones e
incluso reglas de integridad (tales como restricciones).
Los administradores de metadatos son responsables de
la gestin de versiones.
Database Los Database Administrators estn encargados de la Topology (full access)
Administrator definicin de la infraestructura tcnica de la Base de Designer (full access)
Datos, que soportar ODI. Ellos crean los perfiles de Operator (full access)
Base de Datos, que tendrn acceso a ODI. Crean Metadata Navigator
esquemas separador y BD para almacenar las reas de
Staging. . Todo esto lo realizan a travs del Topology
Manager
Security El administrador de seguridad es el encargado de Security (full access)
Administrator definir la poltica 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 importacin de las Operator
versiones y prueba de los escenarios, en el ambiente Metadata Navigator
de Produccin. Se encargar del agendamiento de
dichos escenarios, de la ejecucin 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. Programacin y Funcionamiento Escenarios (Scheduler)

Programacin y operacin de escenarios se realiza por lo general en repositorio de
Testing y en el Repositorio de Produccin. El Operador ODI proporciona una interfaz grfica
para realizar estas tareas. Cualquier escenario puede ser programado por el Agente de ODI.
Cuando un escenario se est ejecutando en produccin, el agente generar registros de

ejecucin en un Repositorio de Trabajo ODI. Estos registros pueden ser controlados a travs
del Operator o a travs de cualquier navegador web.
12.3. Definicin de la Topologa

La topologa describe la arquitectura fsica y lgica del Sistema. Se le da una forma muy
flexible a la gestin de los diferentes servidores, entornos y agentes. Toda la informacin de la
topologa se almacena en ODI en el Master Repository y por lo tanto es centralizado para una
administracin optimizada. Todos los objetos manipulados dentro de los Repositorios de trabajo
se refieren a la topologa. Es por eso que es el punto de partida ms importante en la definicin
y la planificacin de su arquitectura.
Los proyectos tpicos tendrn ambientes separados para el Desarrollo, Prueba y

Produccin. Algunos proyectos incluso tendrn varias pruebas o produccin duplicacin de
ambientes. Por ejemplo, es posible tener varios contextos de produccin de filiales que
ejecutan sus propios sistemas de produccin (Production New York, Produccin Boston, etc). Es
evidente que hay una diferencia entre la vista lgica dell sistema de informacin y su
implementacin fsica como se describe en la figura a continuacin.

La vista lgica describe esquemas lgicos que representan los esquemas fsicos de las
aplicaciones existentes, independientemente de su implementacin fsica. Estos esquemas
lgicos son entonces vinculados a los recursos fsicos a travs de contextos.
Los diseadores siempre se refieren a la vista lgico definido en la topologa. Todo el

desarrollo hecho por lo tanto, se vuelve independiente de la ubicacin fsica de los recursos que
Direccin. En tiempo de ejecucin, la informacin lgica se asigna a los recursos fsicos, dados
los contextos apropiados. El mismo escenario se puede ejecutar en diferentes servidores fsicos
y aplicaciones con slo especificar diferentes contextos. Este trae una arquitectura muy flexible
donde los desarrolladores no tienen que preocuparse por la subyacente a la ejecucin fsica 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
fsicos 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)
Definicin de cuentas de usuario o inicios de sesin de ODI para acceder a los servidores
de datos.
En tiempo de ejecucin, el agente ODI necesitar un nombre de usuario y contrasea

para conectarse a los servidores de datos. Una buena prctica consiste en crear una conexin
dedicada en cada servidor de datos que se debe acceder en el ODI. El uso del inicio de una
sesin para cada servidor trae beneficios como privilegios de administracin 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 catlogos 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 conexin para cada servidor de datos.
ODI almacena versiones encriptada de las contraseas 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 Mdulos 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 preparacin).
En los servidores de datos de destino, se debe crear un esquema dedicado a esta rea.
Con el fin de una mejor administracin de esta rea y evitar la contaminacin 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
estn en el mismo servidor que el objetivo (C $ tabla)
Tablas temporales creadas durante la fase de integracin en determinados Mdulos de
Conocimiento Integracin (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. Definicin del Dataserver

Al convertir una interfaz al cdigo, 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 fsico puede causar fases de carga adicionales que no son necesarios. Por lo
tanto se recomiendan definir un servidor de datos nico por servidor fsico,
independientemente del nmero de esquemas fsicos que se necesiten ser accesados en este
servidor. Por ejemplo, se considera un sistema nico de Teradata, slo un servidor de datos
debe ser definido en el Administrador de Topologa.
Para definir el servidor de datos, puede seguir estos pasos:
1. Del administrador de base de datos o de aplicacin crear un login (nombre de usuario de

inicio de sesin y contrasea) 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 tamao de dicho esquema en relacin al tamao de
las tablas temporales que sern creadas. Por ejemplo, Un servidor de destino el tamao de
su esquema debera ser al menos dos veces el tamao de las transacciones simultneas
que se ejecutan en paralelo.
3. Asegrese 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 instalacin de ODI. (ver ODI ayuda en lnea para ms
detalles)
5. Pruebe la conexin con un cliente JDBC puro como Squirrel-sql (suministrado e instalado
por defecto con ODI)
6. En el Administrador de Topologa, cree un nuevo servidor de datos de la siguiente manera:
Nombre de usuario y contrasea: Utilice la informacin de inicio de sesin para
el inicio de sesin especfico que ha creado para la ODI.

Definir el controlador JDBC o JNDI (consulte la documentacin del controlador)

Defina la URL (utilizar nombres de host en lugar de direcciones IP siempre que

sea posible)
Pruebe su conexin 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 creacin de DataServer Oracle:

Ejemplo de creacin de DataServer Microsoft Sqlserver :
15. Esquemas Fsicos

El Esquema fsico indica la ubicacin fsica del almacn de datos (tablas, archivos, colas,
etc) dentro de un servidor de datos. Al acceder a un servidor de datos JDBC. Todos los
esquemas fsicos que necesitan ser accesados tienen que estar registrados en el servidor de
datos correspondiente. Esquemas fsicos se utilizan para nombres de los objetos de prefijo
cuando se genera cdigo (nombres completos).
Al crear un esquema fsico, es necesario especificar un esquema temporal o rea de

trabajo permanente, en el cual se almacenarn los objetos temporales necesarios en tiempo de
ejecucin. 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 Mdulos de Conocimiento de carga -LKM
(generalmente precedido por C $)
Tablas de Integracin temporales creados por los mdulos de integracin de
conocimientos - IKM (por lo general prefijado por I $)
Tablas de errores permanente al utilizar datos de los mdulos de conocimiento de
calidad CKM (por lo general prefijado por E $)

16. Contextos
Los contextos se utilizan para agrupar los recursos fsicos que pertenecen al mismo
entorno. Una vez creado en topologa, se debe evitar el borrado o la modificacin del cdigo de
un contexto, ya que puede ser referenciado en uno o ms repositorios de trabajo. Un proyecto
tpico tendr muy pocos contextos (menos de 10). Estos pueden ser, por ejemplo:
Es importante tener el mismo nmero de servidores de datos y esquemas definidos

dentro de cada contexto. Por ejemplo, se tiene 2 servidores de destino de produccin y slo un
servidor de destino para desarrollo, probablemente debera dividir la definicin del servidor de
destino por el desarrollo en 2 servidores de datos en la arquitectura fsica definicin tal como
se muestra en la figura a continuacin:

A partir de este ejemplo, podemos ver que el servidor SRV_DEV tiene que ser definido en
dos ocasiones en la arquitectura fsica para que coincida con el entorno fsico real en produccin.
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 generacin de cdigo en el contexto del Desarrollo. As
este cdigo ser vlido cuando se ejecute en los servidores de produccin.
17. Esquemas Lgicos

Un esquema lgico es un alias que permite a un nico nombre que se dar a todo el
esquema fsico que contienen las mismas estructuras del almacn de datos. El objetivo del
esquema lgico es para garantizar la portabilidad de los procedimientos y modelos de
diferentes esquemas fsicos en tiempo de ejecucin. Un esquema lgico puede tener uno o ms
implementaciones fsicas en esquemas fsicos separados, sino que deben basarse en los
servidores de datos de la misma la tecnologa. Un esquema lgico siempre est directamente
vinculado a una tecnologa. Para ser til, un esquema lgico debe ser declarado en un
contexto. Declarar un esquema lgico en un contexto consiste en indicar qu esquema fsico
corresponde al alias -esquema lgico - para este contexto.
En tiempo de ejecucin, el agente utilizar la siguiente frmula para determinar el recurso
fsico:
Nombre lgico del esquema + Contexto = 1 esquema fsico (y 1 Physical Data Server
tambin)

18. Agentes Fsicos y Lgicos

Un agente fsico 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 Mdulos de interfaz
grfica de usuario ODI o programar estas ejecuciones cuando se inicia como un programador.
Un agente fsico debe tener un nombre nico en Administrador de Topologa. Se hace

referencia a la direccin IP o el nombre de su husped y el TCP puerto en el que est
escuchando.
Un agente fsico puede ejecutar varias sesiones en paralelo (multi-threaded). Para fines
de optimizacin, se recomienda que ajuste el nmero mximo de sesiones simultneas que se
permite para ejecutar. Cuando este nmero mximo es alcanzado, cualquier nueva sesin
entrante se pondr en cola por el agente y ejecutado ms tarde cuando otras sesiones han
terminado.
Los agentes fsicos son parte de la arquitectura fsica. Por lo tanto, se puede optar por
tener diferentes agentes de acuerdo con su entorno y contextos. Para ello, definir un agente
lgico y vincularlo a varios agentes fsicos de acuerdo con el contexto. Al iniciar una sesin,
basta con indicar que el agente lgico y el contexto y ODI se traducirn a la direccin fsica del
agente.
19. Definicin 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 construccin de
indicadores clave de negocio de los usuarios. Estos almacenes de datos, que se encuentra en
un esquema lgico, se componen generalmente de campos (o columnas), unidos entre s a
travs 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 informacin. Se refieren

a un conjunto de almacenes de datos en un esquema lgico. 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 creacin de reglas de negocio. Ellos centralizan los
metadatos del ncleo de sus sistemas.
Almacenes de datos en un modelo pueden ser organizados en sub-modelos y adems se

pueden agrupar en carpetas.
Un almacn 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 abstraccin permite ODI para conectar tericamente a cualquier fuente de datos.
Modelos referencia a una base de datos relacional se pueden rellenar automticamente de
las tablas y vistas de definicin del RDBMS a travs de la API JDBC. Para otros modelos,
debern definir los metadatos de forma manual o escribir una reverseengineering especfica KM
que pueble el repositorio de trabajo ODI desde una metadatos provista.
20. Contenido del Modelo

Los modelos pueden contener los siguientes objetos:
Sub-mdulo: Sub-modelos son carpetas dentro de un modelo que se puede utilizar
para organizar sus almacenes de datos.
Datastores: Un almacn de datos representa un conjunto de registros con formato de
una lgica esquema de un servidor de datos
Columns: Las columnas representan los atributos o campos pertenecientes a un
almacn de datos.Se definen tpicamente con un nombre de columna nica, una breve
descripcin, una posicin, un tipo de datos, la longitud y la escala, un indicador
obligatorio (no nula), y otros datos de comprobacin de atributos.
Constraints: Las constraints definen reglas de negocio de datos adicionales de calidad
que aplicar en el nivel de datos para el almacn de datos. Al obtener los metadatos de
un RDBMS, algunas de las restricciones definidas en el esquema fsicas son importado.
Se puede agregar sus propias limitaciones en el almacn 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 ingeniera 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 almacn de datos. se
recomienda que los se define una clave primaria para cada almacn 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.Definicin 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 ttulo slo informativo.
References (Foreing Key): Una referencia definen una relacin entre 2
almacenes de datos para exigir la integridad referencial. Cundo claves
externas no se aplican en el esquema fsico, es recomienda definir de forma
manual para el modelo y han ODI realizar el control de calidad de los datos
durante la integracin. ODITambin se ha introducido un tipo de referencia
compleja que le permite definir una relacin entre 2 almacenes de datos que
deben coincidir con un complejo Expresin 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 podra ser: "verificar que los 3
primeros caracteres en el campo de la direccin de la tabla de clientes que
coincida con el clave de cdigo de pas del pas de tabla "
Conditions: Una condicin define una expresin que un registro deben
coincidir para ser considerado vlido. Una condicin puede ser implementada
en la base de datos como una restriccin de comprobacin.
Filters: Un filtro define una expresin de filtrado predeterminada utilizada al
el almacn de datos es una fuente de una interfaz ODI. Cuando el almacn de
datos es arrastrado y soltado en la interfaz, la condicin 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 travs de las carpetas,
ya que puede conducir a importar temas / exportacin. 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 diseo de su transformacin
como reglas de negocio. Interfaces asignan varios almacenes de datos
heterogneos a una fuente almacn de datos de destino.
o Procedimientos: Compuesto por un conjunto de pasos que le permiten
ejecutar su propia cdigo especfico. Este cdigo puede ser SQL de base de
datos especfica (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 programticas. Un mecanismo de control de transaccin es Tambin
disponible para los comandos de base de datos especfica.
o Packages: Los paquetes se utilizan para implementar un flujo de trabajo
tcnico integrado de varios pasos unidos entre s. Ellos definen la secuencia de
ejecucin de puestos de trabajo que va a liberar en la produccin.
Mdulos de Conocimiento, KM: La piedra angular para las interfaces de
construccin para rellenar objetivo almacenes de datos de fuentes heterogneas
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 ejecucin. 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 ejecucin mltiple 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
automticamente nmero de serie a un campo de un almacn 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 asignacin de un
contador automtico para una columna (por ejemplo, secuencias o las columnas de
identidad), ODI recomienda el uso de estos mecanismos, como lo harn siempre ser
ms eficiente que Secuencias ODI'Ss.
Funciones de usuario: El uso de las funciones de usuario se recomienda cuando el
mismo patrn de transformacin tiene que ser asignado a diferentes almacenes de
datos en diferentes interfaces.
Nota:
Proyectos en la terminologa ODI no necesariamente coinciden con la definicin 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 pequeos que contengan menos de 300 objetos. De esta forma
mejorar la eficiencia de sus operaciones de control de versiones de importacin / exportacin.
22. Diferentes Tipos de Mdulos de Conocimiento

RKM (Reverse Knowledge Modules), se utilizan para realizar una ingeniera inversa
personalizada de los modelos de datos para una tecnologa especfica.
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 cdigo necesario para la
creacin 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 mdulos de conocimiento para la extraccin
Verificar los pareos de campos (mapping)
Pareos Automticos
Columnas no nulas
Aadir columnas adicionales

Probar regularmente la extraccin

En las transformaciones
Identificar, verificar y validar las condiciones
Verificar y validar campos y funciones para convertir formatos de fecha
Verificar tamaos de columnas para no truncar los datos extrados o que de
algn tipo de error
Verificar los tipos de datos(Datatype)
Verificar las secuencias
Oracle Data Integrator provee una plataforma de integracin con capacidad de alto
desempeo y productividad el cual provee un alto grado de flexibilidad y modularidad. El Oracle
Data Integrator cumple con todas aquellas necesidades asociadas a la integracin de datos
incluyendo data Warehouse e inteligencia de negocios, integracin de procesos, migraciones y
todas aquellas iniciativas donde se requieran los datos correctos, en el lugar correcto en el
momento correcto

Collahuasi CEDW DocBuenasPracticasODI

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Collahuasi CEDW DocBuenasPracticasODI

Загружено:

Авторское право:

Доступные форматы

Collahuasi Enterprise

Registro de Cambios en el Documento

Documento de Buenas Practicas Base de Datos

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

1. Tabla de Contenidos ........................................................................................................... 4

Collahuasi Enterprise Datawarehouse 4 de 24

2. Propsito del documento

El objetivo de este documento es presentar buenas prcticas y estandarizar la

La integracin de datos es un elemento fundamental y crtico en la variedad de

Oracle conociendo la necesidad de la integracin de datos para muchas empresas y

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

Collahuasi Enterprise Datawarehouse 5 de 24

Oracle Data Integrator maneja mltiples necesidades empresariales referentes a la

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

7. Quin Necesita ODI?

8. Arquitectura De Oracle Data Integrator

Los administradores, desarrolladores y operadores utilizan interfaces grficas de ODI

Collahuasi Enterprise Datawarehouse 6 de 24

Las GUI de ODI se componen de 4 mdulos:

Collahuasi Enterprise Datawarehouse 7 de 24

ejecucin, etc. Los desarrolladores tambin lo podrn utilizar para efectos de

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

La informacin 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 definicin de esquemas, estructuras almacenes de datos y

Cuando el Work Repository contiene slo la informacin de ejecucin (comnmente

La figura a continuacin da una visin 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

Definicin de las necesidades del negocio (indicadores clave)

12.1. Organizacin de los Equipos

Perfil Descripcin Mdulo de ODI usado

Collahuasi Enterprise Datawarehouse 10 de 24

datos e indicadores clave. En conjunto con los to Projects

12.2. Programacin y Funcionamiento Escenarios (Scheduler)

Cuando un escenario se est ejecutando en produccin, el agente generar registros de

12.3. Definicin de la Topologa

Los proyectos tpicos tendrn ambientes separados para el Desarrollo, Prueba y

Collahuasi Enterprise Datawarehouse 11 de 24

Los diseadores siempre se refieren a la vista lgico definido en la topologa. Todo el

12.4. Servidores de Datos

Collahuasi Enterprise Datawarehouse 12 de 24

Instancia de Microsoft SQL Server

En tiempo de ejecucin, el agente ODI necesitar un nombre de usuario y contrasea

Collahuasi Enterprise Datawarehouse 13 de 24

13. Algunas Definiciones de Esquemas de Trabajo

14. Definicin del Dataserver

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

1. Del administrador de base de datos o de aplicacin crear un login (nombre de usuario de

Collahuasi Enterprise Datawarehouse 14 de 24

Definir el controlador JDBC o JNDI (consulte la documentacin del controlador)

Collahuasi Enterprise Datawarehouse 15 de 24

Ejemplo de creacin de DataServer Oracle:

Collahuasi Enterprise Datawarehouse 16 de 24