unidad 2 Base de datos para la toma de decisiones

Unidad 2 Base de datos para la toma de decisiones
2.1 Almacenes de Datos (Data Warehouse)


Un Almacén de Datos (o Data Warehouse) es una gran colección de datos que recoge información de múltiples sistemas fuentes u operacionales dispersos, y cuya actividad se centra en la “Toma de Decisiones”.
Una vez reunidos los datos de los sistemas fuentes se guardan durante mucho tiempo, lo que permite el acceso a datos históricos; asílos Almacenes de Datos proporcionan al usuario una interfaz consolidada única para los datos, lo que hace más fácil escribir las consultas para la Toma de Decisiones.



2.1.1 Características


Organizado en torno a temas.La información se clasifica en base a los aspectos que son de interés para la empresa.

Integrado.Es el aspecto más importante. La integración de datos consiste en convenciones de nombres, codificaciones consistentes, medida uniforme de variables, etc.

Dependiente del tiempo.Esta dependencia aparece de tres formas:
–La información representa los datos sobre un horizonte largo de tiempo.
–Cada estructura clave contiene (implícita o explícitamente) un elemento de tiempo (día, semana, mes, etc.).

–La información, una vez registrada correctamente, no puede ser actualizada.

No volátil.El Almacén de Datos sólo permite cargar nuevos datos y acceder a los ya almacenados, pero no permite ni borrar ni modificar losdatos.











2.1.2 Arquitectura





Arquitectura de un DW –Repositorio de Datos


􀂃El repositorio de datos operacionales es la fuente donde se encuentran los datos primitivos, actuales e integrados, por lo tanto es el encargado de suministrar datos al sistema, estos datos operacionales pueden ser:
􀂾Mayoritariamente precedentes de sistemas mainframe.
􀂾Datos de estaciones de trabajo o servidores privados.
􀂾Sistemas externos como las bases de datos comerciales, de proveedores o clientes, o incluso de Internet.
􀂾Datos departamentales almacenados en Sistemas Propietario.

Arquitectura de un DW –Gestor de Carga


􀂃También conocido comoSistema ETL (Extraction, Transformation, Load), es el encargado de realizar las funciones de extracciónde las fuentes de datos (transaccionales o externas), transformación(limpieza, consolidación principalmente) y la cargadel Almacén de Datos, también hace el refresco del almacén (operación periódica que propaga los cambios de las fuentes externas al almacén de datos).

Arquitectura de un DW –Gestor del Almacén de Datos


􀂃Realiza las operaciones relacionadas con la gestión de los datos dentro del Almacén utilizando herramientas específicas que realizan operaciones como la transformación de datos para la incorporación de éstos en las tablas del Almacén de Datos, la creación de índices y vistas de las tablas base, creación de copias de seguridad y archivado de datos, además del análisis de los datos para garantizar la coherencia de los mismos.


Arquitectura de un DW –Tipos de Datos (1)


􀂃Datos Detallados. Son los que se obtienen directamente del procesado de los datos, no se encuentran almacenados en línea, sino que se puede acceder a ellos con un nivel más bajo de detalle. Se almacenan en disco ocupando mucho espacio, sin embargo asíse facilita el acceso.




2.1.3 Diseño


1.-Origen (Source): Define los orígenes de datos del Almacén de Datos, como los sistemas de Procesamiento de Transacciones en Línea (On-LineTransactionProcessing, OLTP), las fuentes de datos externas (datos sindicados, datos censales), etc.

2.-Integración (Integration): Define el mapeo entre los orígenes de datos y el propio Almacén de Datos.

3.-Almacén de Datos (Data Warehouse):Define la estructura del Almacén de Datos.

4.-Adaptación (Customization): Define el mapeo entre el Almacén de Datos y las estructuras empleadas por el cliente.

5.-Cliente (Client): Define las estructuras concretas que son empleadas por los clientes para acceder al Almacén de Datos, como Data Martso aplicaciones OLAP.

Niveles por Etapa del Diseño del Almacén de Datos

Cada etapa se analiza desde tres niveles o perspectivas que se crean en el siguiente orden:

􀂃Conceptual:Define el Almacén de Datos desde un punto de vista conceptual, es decir, desde el mayor nivel de abstracción y contiene únicamente los objetos y relaciones más importantes.


􀂃Lógico:Abarca aspectos lógicos del diseño del Almacén de Datos, como la definición de las tablas y claves, la definición de los procesos ETL, etc.


􀂃Físico:Define los aspectos físicos del Almacén de Datos, como el almacenamiento de las estructuras lógicas en diferentes discos o la configuración de los servidores de bases de datos que mantienen el almacén de datos.










2.2 Minería de datos (Data Mining)
La minería de datos (DM, Data Mining) consiste en la extracción no trivial de información que reside de manera implícita en los datos. Dicha información era previamente desconocida y podrá resultar útil para algún proceso. En otras palabras, la minería de datos prepara, sondea y explora los datos para sacar la información oculta en ellos.
Bajo el nombre de minería de datos se engloba todo un conjunto de técnicas encaminadas a la extracción de conocimiento procesable, implícito en las bases de datos. Está fuertemente ligado con la supervisión de procesos industriales ya que resulta muy útil para aprovechar los datos almacenados en las bases de datos.
Las bases de la minería de datos se encuentran en la inteligencia artificial y en el análisis estadístico. Mediante los modelos extraídos utilizando técnicas de minería de datos se aborda la solución a problemas de predicción, clasificación y segmentación.


2.2.1 Antecedentes
La minería de datos, entendida como la búsqueda de patrones dentro de grandes bases de datos utilizando para ello métodos estadísticos y de aprendizaje basado en computadora, está empezando a extenderse en nuestro país. Empresas en el sector de telecomunicaciones, financiero y de autoservicio están en el proceso de adquirir alguna solución tecnológica en este campo, por lo que surge una demanda por recursos humanos con conocimientos en minería de datos.
Además, al enfrentar un ambiente más competitivo las empresas requieren de tecnologías que les permitan pronosticar, dentro de un marco probabilística, el comportamiento de sus clientes y prospectos a fin de desarrollar estrategias de atracción o retención.



Aunque desde un punto de vista académico el término data mining es una
etapa dentro de un proceso mayor llamado extracción de conocimiento en bases de datos, (mencionado en el capitulo anterior) en el entorno comercial, así como en este trabajo, ambos términos se usan de manera indistinta. Lo que en verdad hace el data mining es reunir las ventajas de varias áreas como la Estadística, la Inteligencia Artificial, la Computación Gráfica, las Bases de Datos y el Procesamiento Masivo, principalmente usando como materia prima
las bases de datos. Una definición tradicional es la siguiente: Un proceso no
trivial de identificación válida, novedosa, potencialmente útil y entendible de
patrones comprensibles que se encuentran ocultos en los datos (Fayyad y otros,
1996). Desde el punto de vista empresarial , lo definimos como: La integración
de un conjunto de áreas que tienen como propósito la identificación de un
conocimiento obtenido a partir de las bases de datos que aporten un sesgo
hacia la toma de decisión (Molina y otros, 2001).

La idea de data mining no es nueva. Ya desde los años sesenta los estadísticos manejaban términos como data fishing, data mining o data archaeology con la idea de encontrar correlaciones sin una hipótesis previa en bases de datos con ruido. A principios de los años ochenta, Rakesh Agrawal, Gio Wiederhold, Robert Blum y Gregory Piatetsky-Shapiro, entre otros, empezaron a consolidar los términos de data mining y KDD.[3] A finales de los años ochenta sólo existían un par de empresas dedicadas a esta tecnología; en 2002 existen más de 100 empresas en el mundo que ofrecen alrededor de 300 soluciones.
Las listas de discusión sobre este tema las forman investigadores de más de ochenta países. Esta tecnología ha sido un buen punto de encuentro entre personas pertenecientes al ámbito académico y al de los negocios.
El data mining es una tecnología compuesta por etapas que integra varias áreas y que no se debe confundir con un gran software. Durante el desarrollo de un proyecto de este tipo se usan diferentes aplicaciones software en cada
etapa que pueden ser estadísticas, de visualización de datos o de inteligencia artificial, principalmente. Actualmente existen aplicaciones o herramientas comerciales de data mining muy poderosas que contienen un sinfín de utilerías
que facilitan el desarrollo de un proyecto. Sin embargo, casi siempre acaban complementándose con otra herramienta.

La data mining es la etapa de descubrimiento en el proceso de KDD: Paso
consistente en el uso de algoritmos concretos que generan una enumeración
de patrones a partir de los datos preprocesados (Fayyad et al., 1996)Aunque
se suelen usar indistintamente los términos KDD y Minería de Datos.




Los Fundamentos del Data Mining
Las técnicas de Data Mining son el resultado de un largo proceso de investigación
y desarrollo de productos. Esta evolución comenzó cuando los datos
de negocios fueron almacenados por primera vez en computadoras, y continuó
con mejoras en el acceso a los datos, y más recientemente con tecnologías generadas
para permitir a los usuarios navegar a través de los datos en tiempo
real. Data Mining toma este proceso de evolución más allá del acceso y navegación
retrospectiva de los datos, hacia la entrega de información prospectiva
y proactiva. Data Mining está listo para su aplicación en la comunidad de negocios
porque está soportado por tres tecnologías que ya están suficientemente
maduras:
• Recolección masiva de datos.
• Potentes computadoras con multiprocesadores.
• Algoritmos de Data Mining.

2.2.2 Fases de proyectos de minería de datos
Un proyecto de minería de datos tiene varias fases necesarias que son, esencialmente:
• Comprensión del negocio y del problema que se quiere resolver.
• Determinación, obtención y limpieza de los datos necesarios.
• Creación de modelos matemáticos.
• Validación, comunicación, etc. de los resultados obtenidos.
• Integración, si procede, de los resultados en un sistema transaccional o similar.
La relación entre todas estas fases sólo es lineal sobre el papel. En realidad, es mucho más compleja y esconde toda una jerarquía de subfases. A través de la experiencia acumulada en proyectos de minería de datos se han ido desarrollando metodologías que permiten gestionar esta complejidad de una manera más o menos uniforme. Ejemplo de ella es CRISP-DM, se cree que SEMMA es una metodología SAS declara en su página que ésta NO es una metodología

2.2.3 Filtrado de datos


El formato de los datos contenidos en la fuente de datos nunca es el idóneo y la mayoría de las veces no es posible utilizar ningún algoritmo de minería. Mediante el preprocesado, se filtran los datos (se eliminan valores incorrectos, no válidos, desconocidos... ), se obtienen muestras de los mismos (mayor velocidad de respuesta del proceso), o se reduce el número de valores posibles (mediante redondeo, clustering,...).











2.2.4 Selección de Variables
Aún después de haber sido preprocesados, se sigue teniendo una cantidad ingente de datos. La selección de características reduce el tamaño de los datos, eligiendo las variables más influyentes en el problema, sin apenas sacrificar la calidad del modelo de conocimiento obtenido del proceso de minería. Los métodos para la selección de características son dos: - Los basados en la elección de los mejores atributos del problema - Los que buscan variables independientes mediante tests de sensibilidad, algoritmos de distancia o heurísticos.
También existen dos tipos de algoritmos de Selección de Características, wrapper o de envoltura y filter o de filtro. Los primeros utilizan un algoritmo de aprendizaje, mientras que los segundos lo hacen de medidas estadísticas o funciones heurísticas.

2.2.5 Extracción de Conocimiento
Mediante una técnica se obtiene un modelo de conocimiento, que representa patrones de comportamiento observados en los valores de las variables del problema o relaciones de asociación entre dichas variables. También pueden usarse varias técnicas a la vez para generar distintos modelos

2.2.6 Interpretación y Evaluación
Finalmente se procede a su validación, comprobando que las conclusiones son válidas y satisfactorias. En el caso de haber obtenido varios modelos mediante el uso de distintas técnicas, se deben comparar los modelos en busca de aquel que se ajuste mejor al problema. Si ninguno de los modelos alcanza los resultados esperados, se alterará alguno de los procesos anteriores en busca de nuevos modelos.





2.3Minería Web
La minería de datos es la tecnología que nos permite descubrir información oculta en los datos de cualquier sistema. En este sentido, cualquier servidor web registra un volumen de datos nada despreciable, anotando todas las peticiones que se le hacen desde el exterior. La minería de uso de la Web tiene por objeto extraer información y conocimiento útil de estos ficheros históricos de logs.
El proceso general de minería de uso de la Web parte del establecimiento de los
objetivos del gestor o propietario del servidor de información, pasando por fases de filtrado y limpieza de datos, así como transformación y agregación de datos. En este punto del proceso se utilizan diferentes técnicas para analizar y descubrir patrones de comportamiento interesantes en los clientes o usuarios. La información obtenida será de gran utilidad para mejorar el rendimiento de los servidores web, tanto desde el punto de vista técnico como de negocio.

Este documento ofrece una perspectiva general de todo este proceso. Los lectores que no tengan un conocimiento previo de lo que es la minería de datos, encontrarán una introducción en la sección 2, que incluye la descripción de algunas aplicaciones en Internet.
La sección 3 presenta el proceso que se debe seguir en todo proyecto de minería de uso de la Web. Las aplicaciones y tecnologías utilizadas en este proceso se muestran en la sección 4.

unidad 1 bases de datos distribuidas

UNIDAD I BASES DE DATOS DISTRIBUIDAS
1.1ARQUITECTURA
1.1.1AUTONOMÍA
Como muchos usuarios de sistemas de bases de datos no están familiarizados con computadoras, los desarrolladores esconden la complejidad a los usuarios a través de varios niveles de abstracción para simplificar la interacción de los usuarios con el sistema. Existen diferentes niveles de abstracción para simplificar la interacción de los usuarios con el sistema:
El nivel interno: Tiene un esquema interno, que describe la estructura física de almacenamiento de la base de datos. El esquema interno emplea un modelo físico de los datos y describe todos los detalles para su almacenamiento, así como los caminos de acceso para la base de datos.
El nivel conceptual: Tiene un esquema conceptual, que describe la estructura de toda la base de datos para una comunidad de usuarios. El esquema conceptual oculta los detalles de las estructuras físicas de almacenamiento y se concentra en describir entidades, tipos de datos, vínculos, operaciones de los usuarios y restricciones. En este nivel podemos usar un modelo de datos de alto nivel o uno de implementación.
>El nivel externo o de vistas: Incluye varios esquemas externos o vistas de usuario. Cada esquema externo describe la parte de la base de datos que interesa a un grupo de usuarios determinado, y oculta a ese grupo el resto de la base de datos. En este nivel podemos usar un modelo de datos de alto nivel o uno de implementación.

1.1.2HETEROGENEIDAD
La heterogeneidad es importante en un sistema distribuido. Aún más si se permite que los recursos migren entre distintos nodos.
En principio, el modelo de DAMN no impone ninguna de las soluciones conocidas para resolver los problemas presentados por entornos heterogéneos. No obstante, Off propone una solución poco común: La eliminación de representaciones independientes de arquitectura.
Es cierto que las representaciones neutrales, de red o independientes de arquitectura son esenciales para interconectar nodos heterogéneos en la red, pero sólo si:
• existe un gran número de arquitecturas que no pueden predecirse con antelación y/o
• los distintos sistemas ocultan su representación interna de la información.
Ninguno de estos dos puntos es cierto en los sistemas objeto de estudio. Consiguientemente, Off exporta o congela los objetos de un modo dependiente de arquitectura. Dado que junto con la firma del objeto se suministra un identificador de arquitectura, nada impide al usuario traducir la representación de una arquitectura a otra.
Nada, ¡salvo la integridad de la firma!
Un portal similar al de autenticación, el de traducción, permite a un núcleo de Off la obtención de una versión congelada válida la arquitectura local. Cuando un usuario intenta descongelar un objeto etiquetado como i586PC en un nodo con arquitectura PA-RISC, Off confía a una aplicación de usuario (en la que se confía) la traducción de dicho objeto congelado.
Dado que el núcleo ha comprobado ya la integridad de la imagen congelada, la traducción puede hacerse de forma segura en área de usuario.
1.1.3DISTRIBUCIÓN Y ESQUEMA GLOBAL
El nivel conceptual describe la estructura lógica global de la base de datos mediante un modelo abstracto de datos comprensible por el SGBD. Se definen la descripción de atributos, de entidades, las conexiones y las restricciones de integridad asociadas a la semántica (significado). Podemos decir que describe que datos son almacenados realmente en la base de datos y las relaciones que existen entre los mismos, describe la base de datos completa en términos de su estructura de diseño. El nivel conceptual de abstracción lo usan los administradores de bases de datos, quienes deben decidir qué información se va a guardar en la base de datos.
El esquema conceptual representa la visión organizacional de la base de datos que se obtiene al integrar los requerimientos de todos los usuarios en una empresa; y es totalmente independiente de las estructuras físicas de almacenamiento y de la representación final de los datos que los usuarios manejan. La implantación de este esquema es responsabilidad del DBA.

1.2DISEÑO DE BASES DE DATOS DISTRIBUIDAS
1.2.1Diseño top-Down: fragmentación.
El enfoque de arriba hacia abajo (top-down). Este enfoque es más apropiado para aplicaciones nuevas y para sistemas homogéneos. Consiste en partir desde el análisis de requerimientos para definir el diseño conceptual y las vistas de usuario. A partir de ellas se define un esquema conceptual global y los esquemas externos necesarios. Se prosigue con el diseño de la fragmentación de la base de datos, y de aquí se continúa con la localización de los fragmentos en los sitios, creando las imágenes físicas. Esta aproximación se completa ejecutando, en cada sitio, "el diseño físico" de los datos, que se localizan en éste. En la Figura 3.1 se presenta un diagrama con la estructura general del enfoque top-down.










1.2.2Diseño bottom-up : integración de bases de datos.
El diseño de abajo hacia arriba (bottom-up). Se utiliza particularmente a partir de bases de datos existentes, generando con esto bases de datos distribuidas. En forma resumida, el diseño bottom-up de una base de datos distribuida requiere de la selección de un modelo de bases de datos común para describir el esquema global de la base de datos. Esto se debe es posible que se utilicen diferentes SMBD. Después se hace la traducción de cada esquema local en el modelo de datos común y finalmente se hace la integración del esquema local en un esquema global común.
1.3 ARQUITECTURAS CLIENTE/SERVIDOR PARA SGBD
Los servidores de bases de datos son Sistemas de Gestión de Bases de Datos o SGBD (en inglés DBMS = DataBase Management System), aplicaciones cuyo objetivo no es solo almacenar y recuperar datos, sino también facilitar la manipulación de éstos de la forma más eficiente y segura.
Un servidor de datos debe elaborar la información que va a devolver al cliente a partir de los datos recuperados del sistema de archivos usando para ellos diferentes estructuras físicas, así como asegurar su integridad verificando restricciones y utilizando transacciones.
Aunque en un principio surgieron SGBD de distintos tipos, según la estructura con la que se almacenaba la información, los más extendidos y conocidos son los Sistemas Administradores de Bases de Datos Relacionales SGBDR (en inglés RDBMS = Relational Data Base Management System) llamados así porque los datos se estructuran con ciertas relaciones entre ellos (Modelo Relacional), simplificando la recuperación y el tratamiento y evitando la repetición innecesaria de información. Algunos ejemplos de SGBDR son los ya mencionados SQL Server, Oracle, MySQL, Firebird, etc.
1.3.1FILOSOFÍA CLIENTE/SERVIDOR
Cliente-servidor de dos capas.- Descrito brevemente en el punto anterior. El modelo de dos capas se encuentra ligado fuertemente a la implantación de una computadora operando como el CLIENTE y otra como SERVIDOR conteniendo la base de datos de la empresa.
Cliente-Servidor de n capas.- Partiendo del modelo cliente/servidor han surgido otros conocidos genéricamente como n-tier, siendo el más habitual el three-tier o de tres capas.
El concepto de n capas ha cambiado con el tiempo, puede referirse tanto al hardware como a software.

Cliente-Servidor de tres capas.- Desde el punto de vista de software, la arquitectura cliente servidor de tres capas esta dada por tres elementos básicos: capa de presentación, capa lógica (de negocio), y capa de datos. Los clientes no se comunican directamente con el servidor de datos, sino que entre ellos se interpone un nuevo servidor: el de aplicaciones (capa lógica,capa de negocio o lógica del negocio).


En este modelo los clientes no tienen acceso directo a los datos, trabajo que queda en manos de los componentes que se ejecutan en el servidor de aplicaciones.Dichos componentes, además, alojan la lógica de proceso de la información, lo que normalmente se conoce como lógica del negocio (capa de negocio),tarea que en el modelo cliente/servidor recaía en la aplicación del cliente. De esta forma, el cliente queda relegado a una simple interfaz de usuario, ya sea nativa en un ordenador, un documento en un navegador web o desde un dispositivo móvil.
La ventaja principal es que resulta más fácil llegar a clientes heterogéneos y dispersos, interconectados no en redes de la propia empresa si no a través de internet.




1.3.2SOCKETS
Socket designa un concepto abstracto por el cual dos programas (posiblemente situados en computadoras distintas) pueden intercambiar cualquier flujo de datos, generalmente de manera fiable y ordenada.
Un socket queda definido por una dirección IP, un protocolo de transporte y un número de puerto.

Para que dos programas puedan comunicarse entre sí es necesario que se cumplan ciertos requisitos:
• Que un programa sea capaz de localizar al otro.
• Que ambos programas sean capaces de intercambiarse cualquier secuencia de octetos, es decir, datos relevantes a su finalidad.
Para ello son necesarios los tres recursos que originan el concepto de socket:
• Un protocolo de comunicaciones, que permite el intercambio de octetos.
• Una dirección del Protocolo de Red (Dirección IP, si se utiliza el Protocolo TCP/IP), que identifica una computadora.
• Un número de puerto, que identifica a un programa dentro de una computadora.
Los sockets permiten implementar una arquitectura cliente-servidor. La comunicación ha de ser iniciada por uno de los programas que se denomina programa cliente. El segundo programa espera a que otro inicie la comunicación, por este motivo se denomina programa servidor.
Un socket es un fichero existente en la máquina cliente y en la máquina servidora, que sirve en última instancia para que el programa servidor y el cliente lean y escriban la información. Esta información será la transmitida por las diferentes capas de red.
Propiedades inherentes a los sockets
Las propiedades de un socket dependen de las características del protocolo en el que se implementan. El protocolo más utilizado es TCP, aunque también es posible utilizar UDP o IPX. Gracias al protocolo TCP, los sockets tienen las siguientes propiedades:
• Orientado a conexión.
• Se garantiza la transmisión de todos los octetos sin errores ni omisiones.
• Se garantiza que todo octeto llegará a su destino en el mismo orden en que se ha transmitido.
Estas propiedades son muy importantes para garantizar la corrección de los programas que tratan la información.
El protocolo UDP es un protocolo no orientado a la conexión. Sólo se garantiza que si un mensaje llega, llegue bien. En ningún caso se garantiza que llegue o que lleguen todos los mensajes en el mismo orden que se mandaron.
1.3.3RPC
El RPC (del inglés Remote Procedure Call, Llamada a Procedimiento Remoto) es un protocolo que permite a un programa de ordenador ejecutar código en otra máquina remota sin tener que preocuparse por las comunicaciones entre ambos. El protocolo es un gran avance sobre los sockets usados hasta el momento. De esta manera el programador no tenía que estar pendiente de las comunicaciones, estando éstas encapsuladas dentro de las RPC.
Las RPC son muy utilizadas dentro del paradigma cliente-servidor. Siendo el cliente el que inicia el proceso solicitando al servidor que ejecute cierto procedimiento o función y enviando éste de vuelta el resultado de dicha operación al cliente.
Hay distintos tipos de RPC, muchos de ellos estandarizados como pueden ser el RPC de Sun denominado ONC RPC (RFC 1057), el RPC de OSF denominado DCE/RPC y el Modelo de Objetos de Componentes Distribuidos de Microsoft DCOM, aunque ninguno de estos es compatible entre sí. La mayoría de ellos utilizan un lenguaje de descripción de interfaz (IDL) que define los métodos exportados por el servidor.
Hoy en día se está utilizando el XML como lenguaje para definir el IDL y el HTTP como protocolo de red, dando lugar a lo que se conoce como servicios web. Ejemplos de éstos pueden ser SOAP o XML-RPC.
ONC RPC, abreviación del inglés Open Network Computing Remote Procedure Call, es un protocolo de llamada a procedimiento remoto (RPC) desarrollado por el grupo ONC de Sun Microsystems como parte del proyecto de su sistema de archivos de Red NFS, algunas veces se lo denomina Sun ONC o Sun RPC. Trabaja sobre los protocolos TCP y UDP. La codificación de datos se realiza utilizando el protocolo XDR (presentación de datos).
Desarrollo de aplicaciones: compiladores de protocolo
El desarrollo de aplicaciones para ONC RPC consisten en desarrollar programas cliente/servidor, donde los datos deben codificarse según el protocolo XDR.
Las aplicaciones se realizan en forma sistemática mediante compiladores de protocolo como el programa rpcgen, que fue el programa original desarrollado por Sun que generaba casi todo el código en lenguaje C necesario para crear los programas servidor y cliente. Existen compiladores de este protocolo que generan código en java, denominados jrpcgen.
1.3.4CORBA
En computación, CORBA (Common Object Request Broker Architecture — arquitectura común de intermediarios en peticiones a objetos), es un estándar que establece una plataforma de desarrollo de sistemas distribuidos facilitando la invocación de métodos remotos bajo un paradigma orientado a objetos.
CORBA fue definido y está controlado por el Object Management Group (OMG) que define las APIs, el protocolo de comunicaciones y los mecanismos necesarios para permitir la interoperabilidad entre diferentes aplicaciones escritas en diferentes lenguajes y ejecutadas en diferentes plataformas, lo que es fundamental en computación distribuida.
En un sentido general, CORBA "envuelve" el código escrito en otro lenguaje, en un paquete que contiene información adicional sobre las capacidades del código que contiene y sobre cómo llamar a sus métodos. Los objetos que resultan, pueden entonces ser invocados desde otro programa (u objeto CORBA) desde la red. En este sentido CORBA se puede considerar como un formato de documentación legible por la máquina, similar a un archivo de cabeceras, pero con más información.
CORBA utiliza un lenguaje de definición de interfaces (IDL) para especificar las interfaces con los servicios que los objetos ofrecerán. CORBA puede especificar a partir de este IDL, la interfaz a un lenguaje determinado, describiendo cómo los tipos de dato CORBA deben ser utilizados en las implementaciones del cliente y del servidor. Implementaciones estándar existen para Ada, C, C++, Smalltalk, Java, Python, Perl y Tcl.
Al compilar una interfaz en IDL se genera código para el cliente y el servidor (el implementador del objeto). El código del cliente sirve para poder realizar las llamadas a métodos remotos. Es el conocido como stub, el cual incluye un proxy (representante) del objeto remoto en el lado del cliente. El código generado para el servidor consiste en unos skeletons (esqueletos) que el desarrollador tiene que rellenar para implementar los métodos del objeto.
CORBA es más que una especificación multiplataforma, también define servicios habitualmente necesarios como seguridad y transacciones. Y así este no es un sistema operativo en si, en realidad es un middleware.

1.4 OPTIMIZACIÓN DE PREGUNTAS Y TRANSACCIONES
En nuestras aplicaciones podemos optimizar los procesos forzando que éstos se ejecuten en tercer plano, es decir, en el servidor. Veámoslo con un ejemplo.
A continuación presentamos un proceso sin optimizar:

El origen del proceso es una lista de la tabla CLIENTES y en él se pregunta si queremos o no actualizar los clientes. En caso afirmativo se recorre la lista y se modifica el campo FECHA ALTA.
El proceso se ejecuta en primer plano, es decir, en nuestra máquina. Además,como incluye la función recorrer lista lectura / escritura, escribe en disco.
Esto implica que sólo realice una transacción al recorrer el bucle (si no escribiera en disco realizaría tantas transacciones como registros encontrara, ralentizándose mucho más el proceso).
Podemos optimizar este proceso partiéndolo en dos: uno que incluya el bucle y que se ejecute en tercer plano y otro encargado de lanzar el anterior y que se ejecute en primer plano. Veámoslo:
El proceso que se va a ejecutar en el servidor es el siguiente:

El proceso anterior tiene como origen una lista de la tabla CLIENTES y lo hemos identificado como UPDATE-CLIENTES-OPT-3P.
El proceso encargado de lanzar el anterior es:

Este proceso se ejecuta en primer plano, y en él incluimos la función Ejecutar proceso en la que seleccionamos el proceso UPDATE-CLIENTESOPT-3P, indicando que éste debe lanzarse en modo servidor.
Al montar el proceso de este segundo modo (optimizado) la actualización de la lista se realiza mucho más rápido (diez veces más de media), ya que es el servidor quien la realiza, evitando que haya tráfico de información a través de la red.
Al montar una estructura como la anterior hemos de tener en cuenta que en un proceso en tercer plano no podemos lanzar preguntas, presentar formularios, rejillas… sólo podemos usar la función de procesos Mensaje, que se suele usar para depurar. Sus contenidos se presentarán en la barra de mensajes del servidor de aplicaciones.
Forzar una única transacción
Supongamos un proceso para actualizar las ventas en una lista de clientes y que necesita confirmación por parte del usuario. Éste se compondrá de dos procesos:
Uno lanzador, en primer plano y con origen una lista de la tabla CLIENTES. En él incluiremos la parte que interactúa con el usuario.

PROCESO LANZADOR
Otro en tercer plano (ACTUALIZAR-VENTAS-CLIENTES-3P en el proceso anterior) con origen ficha de la tabla CLIENTES, en el que cargamos el histórico de ventas de cada cliente, lo recorremos y realizamos la modificación necesaria en cada registro.