UNIDAD II

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, es decir, en el análisis de la información- en vez de en su captura. 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 los datos.

Base de Datos Operacional Almacén de Datos

Datos operacionales Datos del negocio para Información
Orientado a aplicación Orientado al sujeto
Actual Actual + Histórico
Detallada Detallada + Resumida
Cambia continuamente Estable

2.1.2 ARQUITECTURA

La estructura básica de la arquitectura Data Warehouse incluye:

1. Datos operacionales. Origen de datos para el componente de almacenamiento físico del Almacén de Datos.

2. Extracción de datos. Selección sistemática de datos operacionales usados para formar parte del Almacén de Datos.

3. Transformación de datos. Procesos para sumarizar y realizar cambios en los datos operacionales.

4. Carga de datos. Inserción de datos en el Almacén.

5. Almacén. Almacenamiento físico de datos de al arquitectura Data Warehouse.

6.Herramienta de acceso. Herramientas que proveen acceso a los datos.

2.1.3 DISEÑO

Estructura lógica del Almacén de Datos

La estructura lógica de un Almacén de Datos está compuesta por los siguientes niveles:

Metadatos. Describen la estructura de los datos contenidos en el almacén.
Están en una dimensión distinta al resto de niveles.

Datos detallados actuales. Obtenidos directamente del procesado de los datos.
Forman el nivel más bajo de detalle.
Ocupan mucho espacio.
Se almacenan en disco, para facilitar el acceso.

Datos detallados históricos. Igual que los anteriores, pero con datos correspondientes al pasado.
Se suelen almacenar en un medio externo, ya que su acceso es poco frecuente.

Datos ligeramente resumidos. Primer nivel de agregación de los datos detallados actuales.
Corresponden a consultas habituales.
Se almacenan en disco.

Datos muy resumidos. Son el nivel más alto de agregación.
Corresponden a consultas que se realizan muy a menudo y que se deben obtener muy rápidamente.
Suelen estar separados del Almacén de datos, formando Supermercados de Datos (Data Marts).

Data Warehousing es el proceso que facilita la creación y explotación de un Almacén de Datos.

Los Sistemas de Data Warehousing incluyen funcionalidades como:

Integración de bases de datos heterogéneas (relacionales, documentales, geográficas, archivos, etc.)

Ejecución de consultas complejas no predefinidas visualizando el resultado en forma gráfica y en diferentes niveles de agrupamiento y totalización de datos.

Agrupamiento y desagrupamiento de datos en forma interactiva.

Análisis del problema en términos de dimensiones.

Control de calidad de datos.

Estructura física del Almacén de Datos

La estructura física puede presentar cualquiera de las siguientes configuraciones:

Arquitectura centralizada. Todo el Almacén de datos se encuentra en un único servidor.

Arquitectura distribuida. Los datos del Almacén se reparten entre varios servidores. Asignando cada servidor a uno o varios temas lógicos.

Arquitectura distribuida por niveles. Refleja la estructura lógica del Almacén, asignando los servidores en función del nivel de agregación de los datos que contienen. Un servidor está dedicado para los datos de detalle, otro para los resumidos y otro para los muy resumidos.

Cuando los datos muy resumidos se duplican en varios servidores para agilizar el acceso se habla de Supermercados de datos (Data Marts).

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óny segmentación.

El datamining (minería de datos), es el conjunto de técnicas y tecnologías que permiten explorar grandes bases de datos, de manera automática o semiautomática, con el objetivo de encontrar patrones repetitivos, tendencias o reglas que expliquen el comportamiento de los datos en un determinado contexto.
Básicamente, el datamining surge para intentar ayudar a comprender el contenido de un repositorio de datos. Con este fin, hace uso de prácticas estadísticas y, en algunos casos, de algoritmos de búsqueda próximos a la Inteligencia Artificial y a las redes neuronales.
De forma general, los datos son la materia prima bruta. En el momento que el usuario les atribuye algún significado especial pasan a convertirse en información. Cuando los especialistas elaboran o encuentran un modelo, haciendo que la interpretación que surge entre la información y ese modelo represente un valor agregado, entonces nos referimos al conocimiento. Vea más diferencias entre datos, información y conocimiento.

Aunque en datamining cada caso concreto puede ser radicalmente distinto al anterior, el proceso común a todos ellos se suele componer de cuatro etapas principales:
Determinación de los objetivos. Trata de la delimitación de los objetivos que el cliente desea bajo la orientación del especialista en data mining.
Preprocesamiento de los datos. Se refiere a la selección, la limpieza, el enriquecimiento, la reducción y la transformación de las bases de datos. Esta etapa consume generalmente alrededor del setenta por ciento del tiempo total de un proyecto de data mining.
Determinación del modelo. Se comienza realizando unos análisis estadísticos de los datos, y después se lleva a cabo una visualización gráfica de los mismos para tener una primera aproximación. Según los objetivos planteados y la tarea que debe llevarse a cabo, pueden utilizarse algoritmos desarrollados en diferentes áreas de la Inteligencia Artificial.
Análisis de los resultados. Verifica si los resultados obtenidos son coherentes y los coteja con los obtenidos por los análisis estadísticos y de visualización gráfica. El cliente determina si son novedosos y si le aportan un nuevo conocimiento que le permita considerar sus decisiones.

2.2.1 ANTECEDENTES

Tradicionalmente, las técnicas de minería de datos se aplicaban sobre información contenida en almacenes de datos. No obstante, actualmente está cobrando una importancia cada vez mayor la minería de datos desestructurados como es la información contenida en ficheros de texto (text mining), en Internet (web mining), etc. Además, hoy en día han surgido otras necesidades de tipo operativo, como la integración de los resultados obtenidos en los sistemas de información en línea, con la exigencia, por tanto, de que los procesos funcionen prácticamente en tiempo real, por ejemplo, la alerta temprana frente a alarmas en una cadena de montaje, la detección instantánea del fraude en operaciones bancarias, un sistema de recomendación de productos en una tienda en línea, etc.

Como verdaderos pioneros en España, en DAEDALUS llevamos investigando y trabajando en este campo desde sus orígenes, habiendo desarrollado un gran número de proyectos en numerosos sectores de aplicación, incluyendo seguros, banca y finanzas, telecomunicaciones, energía, medios de comunicación, distribución, marketing, industria, educación, consultoría, etc. En general, la minería de datos se emplea para mejorar el rendimiento de procesos de negocio o industriales en los que se manejan grandes volúmenes de información estructurada y almacenada en bases de datos.

Una aplicación especial de la minería de datos es la minería web (o minería de uso de la web, web mining) que consiste en extraer información y conocimiento útil específicamente de la actividad de un sitio web: análisis de tráfico (visitas y visitantes), contenidos más accedidos, procedencia, tipo de usuarios, navegadores y sistemas operativos, reglas de asociación entre páginas (tasa de conversión).

2.2.2 FASES DE PROYECTOS DE MINERÍA DE DATOS

Los pasos a seguir para la realización de un proyecto de minería de datos son siempre los mismos, independientemente de la técnica específica de extracción de conocimiento usada.

El proceso de minería de datos se compone de las siguientes fases:

Selección y preprocesado de datos

El formato de los datos contenidos en la fuente de datos (base de datos, Data Warehouse…) nunca es el idóneo y la mayoría de las veces no es posible ni siquiera utilizar ningún algoritmo de minería sobre los datos “en bruto”.

Mediante el preprocesado se filtran los datos (de forma que se eliminan valores incorrectos, no válidos, desconocidos… según las necesidades y el algoritmo que va a usarse), se obtienen muestras de los mismos (en busca de una mayor velocidad de respuesta del proceso), o se reduce el número de valores posibles (mediante redondeo, clustering…).

Los métodos para la selección de características son básicamente dos:

1. Aquellos basados en la elección de los mejores atributos del problema
2. Aquellos que buscan variables independientes mediante tests de sensibilidad, algoritmos de distancia o heurísticos

Dentro de un proyecto de Data Mining podemos diferenciar las siguientes fases:
1. Identificación y definición del objetivo de negocio a resolver. Muy importante. La minería de datos no es un fin en si mismo, sin objetivos de negocio no hay proyecto.
2. Identificación de las fuentes de datos para soportar la resolución de los objetivos y análisis preliminar de la calidad de los datos. Si no tenemos unos datos con la calidad requerida y el formato necesario, nuestro proyecto será un fracaso. Creo que muchas veces se subestima este punto…
3. Preparación y acondicionamiento de los datos. Una fase crucial, que ocupa un tanto por ciento importante del tiempo del proyecto. Con preparación y acondicionamiento estamos hablando de las estructuras que alimentaran la construcción del modelo. Por ejemplo, si queremos hacer una segmentación de clientes, para ello necesito preparar los datos en formato tabla de clientes, donde cada registro es un cliente con los atributos de modelización en columnas.
4. Modelización de datos. Aplicando las técnicas de minería de datos, obtenemos el mejor modelo predictivo posible para nuestros objetivos.
5. Análisis de resultados. Una vez obtenido el modelo, se debe proceder a su validación comprobando que las conclusiones que arroja son válidas y suficientemente 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, debe alterarse alguno de los pasos anteriores para generar nuevos modelos.
6. Conclusiones. ¿Se han cumplido las expectativas y los objetivos?
7. Puesta en producción. No nos podemos quedar con unos simples informes de consultoría o una serie de recomendaciones. Si cogemos los modelos generados y los ponemos en producción de forma efectiva estaremos aprovechando el principal beneficio del Data Mining.

2.2.3 FILTRADO DE DATOS

El formato de los datos contenidos en la fuente de datos (base de datos, Data Warehouse…) nunca es el idóneo, y la mayoría de las veces no es posible ni siquiera utilizar ningún algoritmo de minería sobre los datos en bruto.

Se recurre a la operación de filtración cuando se desean eliminar muchos informes, de tal modo que aparezcan sólo aquellos que nos interesan. Para aplicar un filtro podemos recurrir a dos métodos:

Filtro por selección: es el método más sencillo para realizar filtraciones, pero antes de usarlo se debe localizar en la tabla un ejemplo del valor que debe encontrarse en los informes filtrados.

Filtro para formulario: es un método más potente respecto del anterior en cuanto que permite la inserción de expresiones lógicas para localizar informes.

2.2.4 SELECCIÓN DE VARIABLES

Aún después de haber sido preprocesados, en la mayoría de los casos se tiene 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 básicamente dos:
1. Aquellos basados en la elección de los mejores atributos del problema
2. Y aquellos que buscan variables independientes mediante tests de sensibilidad, algoritmos de distancia o heurísticos

2.2.5 EXTRACCIÓN DE CONOCIMIENTO

Mediante una técnica de minería de datos, 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, aunque generalmente cada técnica obliga a un preprocesado diferente de los datos.

2.2.6 INTERPRETACIÓN Y EVALUACIÓN

Una vez obtenido el modelo, se debe proceder a su validación, comprobando que las conclusiones que arroja son válidas y suficientemente 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, debe alterarse alguno de los pasos anteriores para generar nuevos modelos.

Si desea obtener una descripción más detallada, puede consultar la documentación de CRISP-DM (CRoss Industry Standard Process for Data Mining), que es un estándar industrial, utilizado por más de 160 empresas e instituciones de todo el mundo, que surge en respuesta a la falta de estandarización y propone un modelo de proceso general para proyectos de minería de datos:
Neutral respecto a industria y herramientas
Aplicable en cualquier sector de negocio

2.3 MINERÍA WEB

La minería web (o minería de uso de la web) es una aplicación especial de la minería de datos que consiste en extraer información y conocimiento útil específicamente de la actividad de un sitio web: análisis de tráfico (visitas y visitantes), contenidos más accedidos, procedencia, tipo de usuarios, navegadores y sistemas operativos, reglas de asociación entre páginas (tasa de conversión), etc.

El análisis de esta información, a partir del tráfico de un sitio web registrado de una manera adecuada, es fundamental, por una parte, para entender el comportamiento y los hábitos de los clientes/usuarios del sitio y, por otra, porque ayudan a mejorar su diseño.

El problema es que obtener una información fiable y precisa sobre el comportamiento real de los usuarios de un sitio web es una labor complicada por varios motivos: las particularidades de Internet (cachés intermedias, direcciones IP dinámicas, deslocalización geográfica, etc.), la heterogeneidad de las visitas (usuarios con diferentes expectativas, robots, navegadores, buscadores, etc.) o la complejidad de la información recibida (concepto de sesión, visitantes detrás de servidores proxy, nombres de máquinas y dominios, protocolos, etc.)

1.1.1Autonomía

Presentan las diferentes dimensiones (factores) que se deben considerar para la implementación de un sistema manejador de base de datos. Las dimensiones son tres:
Distribución. Determina si las componentes del sistema están localizadas en la misma computadora o no.
Heterogeneidad. La heterogeneidad se puede presentar a varios niveles: hardware, sistema de comunicaciones, sistema operativo o SMBD. Para el caso de SMBD heterogéneos ésta se puede presentar debido al modelo de datos, al lenguaje de consultas o a los algoritmos para manejo de transacciones.
Autonomía. La autonomía se puede presentar a diferentes niveles:
Autonomía de diseño. La habilidad de un componente del SMBD para decidir cuestiones relacionadas a su propio diseño.
Autonomía de comunicación. La habilidad de un componente del SMBD para decidir como y cuando comunicarse con otros SMBD.
Autonomía de ejecución. La habilidad de un componente del SMBD para ejecutar operaciones locales de la manera que él quiera

1.1.2Heterogeneidad
Un sistema es heterogéneo cuando existen en él componentes que se ejecutan en diversos sistemas operativos, de diferentes fuentes, etc.
Debido a las necesidades que surgen en las grandes compañías, diferentes BD se han ido desarrollando e implementando para estar a la altura de las demandas de los usuarios, éstas BD pueden ser diseñadas independientemente de la organización.
Como resultado, la Heterogeneidad de las BD es inevitable cuando diferentes tipos de BD coexisten en una organización que trata de compartir datos entre éstas. Por lo que muchos investigadores han enfocado sus esfuerzos en la exploración de un esquema global que trate de resolver los problemas de la Heterogeneidad, la definición de Protocolos Interoperables y la integración de las BD.
La interoperabilidad entre diferentes sistemas de información ha sido uno de los aspectos más críticos en la operación cotidiana de muchas organizaciones. La necesidad de interoperabilidad surge a raíz de los cambios organizacionales que sufren las empresas modernas, alianzas estratégicas, compartimiento de información, y absorción de pequeñas y medianas industrias por grandes corporativos son sólo algunos de los panoramas que provocan esta situación.

1.1.3Distribución y esquema global
Una de las decisiones más importantes que el diseñador de bases de datos distribuidas debe tomar es el posicionamiento de la data en el sistema y el esquema bajo el cuál lo desea hacer. Para esto existen cuatro alternativas principales: centralizada, replicada, fragmentada, e híbrida. La forma centralizada es muy similar al modelo de Cliente/Servidor en el sentido que la BDD está centralizada en un lugar y los usuarios están distribuidos. Este modelo solo brinda la ventaja de tener el procesamiento distribuido ya que en sentido de disponibilidad y fiabilidad de los datos no se gana nada.

1.2Diseño de bases de datos distribuidas

BASE DE DATOS DISTRIBUIDAS
Una base de datos distribuida (BDD) es un conjunto de múltiples bases de datos lógicamente relacionadas las cuales se encuentran distribuidas entre diferentes sitios interconectados por una red de comunicaciones, los cuales tienen la capacidad de procesamiento autónomo lo cual indica que puede realizar operaciones locales o distribuidas. Un sistema de Bases de Datos Distribuida (SBDD) es un sistema en el cual múltiples sitios de bases de datos están ligados por un sistema de comunicaciones de tal forma que, un usuario en cualquier sitio puede acceder los datos en cualquier parte de la red exactamente como si los datos estuvieran siendo accedidos de forma local.
En un sistema distribuido de bases de datos se almacenan en varias computadoras. Los principales factores que distinguen un SBDD de un sistema centralizado son los siguientes:
Hay múltiples computadores, llamados sitios o nodos.
Estos sitios deben de estar comunicados por medio de algún tipo de red de comunicaciones para transmitir datos y órdenes entre los sitios.
Por lo que el hardware que compone una base de datos distribuida se reduce a servidores y la red.
También consta con una serie de software:

Sistema de Administración de Base de Datos Distribuida (DDBMS)
Este sistema está formado por las transacciones y los administradores de la base de datos distribuidos.
Administrador de transacciones distribuidas (DTM)
Este es un programa que recibe las solicitudes de procesamiento de los programas de consulta o transacciones y las traduce en acciones para los administradores de la base de datos.
Administrador de la base de datos (DBM)
Es un programa que procesa cierta porción de la base de datos distribuida. Se encarga de recuperar y actualizar datos del usuario y generales de acuerdo con los comandos recibidos de los DTM.
Nodo
Un nodo es una computadora que ejecuta un DTM o un DBM o ambos. Un nodo de transacción ejecuta un DTM y un nodo de base de datos ejecuta un DBM.
Ventajas y Desventajas
Ventajas
• Refleja una estructura organizacional – los fragmentos de la base de datos se ubican en los departamentos a los que tienen relación.
• Autonomía local – un departamento puede controlar los datos que le pertenecen.
• Disponibilidad – un fallo en una parte del sistema solo afectará a un fragmento, en lugar de a toda la base de datos.
• Rendimiento – los datos generalmente se ubican cerca del sitio con mayor demanda, también los sistemas trabajan en paralelo, lo cual permite balancear la carga en los servidores.
• Economía – es más barato crear una red de muchas computadoras pequeñas, que tener una sola computadora muy poderosa.
• Modularidad – se pueden modificar, agregar o quitar sistemas de la base de datos distribuida sin afectar a los demás sistemas (módulos).
Desventajas
• Complejidad – Se debe asegurar que la base de datos sea transparente, se debe lidiar con varios sistemas diferentes que pueden presentar dificultades únicas. El diseño de la base de datos se tiene que trabajar tomando en cuenta su naturaleza distribuida, por lo cual no podemos pensar en hacer joins que afecten varios sistemas.
• Economía – la complejidad y la infraestructura necesaria implica que se necesitará una mayor mano de obra.
• Seguridad – se debe trabajar en la seguridad de la infraestructura así como cada uno de los sistemas.
• Integridad – Se vuelve difícil mantener la integridad, aplicar las reglas de integridad a través de la red puede ser muy caro en términos de transmisión de datos.
• Falta de experiencia – las bases de datos distribuidas son un campo relativamente nuevo y poco común por lo cual no existe mucho personal con experiencia o conocimientos adecuados.
• Carencia de estándares – aún no existen herramientas o metodologías que ayuden a los usuarios a convertir un DBMS centralizado en un DBMS distribuido.
• Diseño de la base de datos se vuelve más complejo – además de las dificultades que generalmente se encuentran al diseñar una base de datos, el diseño de una base de datos distribuida debe considerar la fragmentación, replicación y ubicación de los fragmentos en sitios específicos.
1.2.1 Diseño top-down : fragmentación.

DISEÑO TOP-DOWN; FRAGMENTACION

Existen dos estrategias generales para abordar el problema de diseño de bases de datos distribuidas:
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.

Figura 3.1. El enfoque top-down para el diseño de bases de datos distribuidas.

1.2.2 Diseñ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.
El diseño de una base de datos distribuida, cualquiera sea el enfoque que se siga, debe responder satisfactoriamente las siguientes preguntas:
• Por qué hacer una fragmentación de datos?
• Cómo realizar la fragmentación?
• Qué tanto se debe fragmentar?
• Cómo probar la validez de una fragmentación?
• Cómo realizar el asignamiento de fragmentos?
• Cómo considerar los requerimientos de la información?

Figura 3.2. El problema de fragmentación de relaciones

1.3 Arquitecturas Cliente/Servidor para SGBD

Durante años, las bases de datos se han utilizado en sistemas que se ajustaban a una arquitectura conocida como cliente/servidor. En ella los datos residen en un ordenador que actúa como servidor, ejecutando el software que denominábamos antes servidor de datos (SGBD). Los usuarios, desde ordenadores remotos, se sirven de un software cliente para comunicarse con el servidor de datos. Ese software cliente es especifico para cada servidor de datos existen.

Supongamos que esta utilizando SQL Server como Servidor de datos, estando instalado dicho software en una maquina que reside en un centro de proceso de datos. Desde su ordenador, ubicado en otra planta del mismo edificio, se comunicaría con ese servidor mediante el software cliente de Sql Server que, lógicamente, debería estar instalado en su maquina. Dicho software cliente no serviría para comunicar con un servidor Oracle, etc. por poner un caso, teniendo que disponer del software cliente que corresponda en cada caso.

1.3.1Filosofía Cliente/Servidor

En el sentido más estricto, el término cliente/servidor describe un sistema en el que una máquina cliente solicita a una segunda máquina llamada servidor que ejecute una tarea específica. El cliente suele ser una computadora personal común conectada a una LAN, y el servidor es, por lo general, una máquina anfitriona, como un servidor de archivos PC, un servidor de archivos de UNIX o una macrocomputadora o computadora de rango medio. El programa cliente cumple dos funciones distintas: por un lado gestiona la comunicación con el servidor, solicita un servicio y recibe los datos enviados por aquél. Por otro, maneja la interfaz con el usuario: presenta los datos en el formato adecuado y brinda las herramientas y comandos necesarios para que el usuario pueda utilizar las prestaciones del servidor de forma sencilla.
El programa servidor en cambio, básicamente sólo tiene que encargarse de transmitir la información de forma eficiente. No tiene que atender al usuario. De esta forma un mismo servidor puede atender a varios clientes al mismo tiempo. Algunas de las principales LAN cliente/servidor con servidores especializados que pueden realizar trabajos para clientes incluyen a Windows NT, NetWare de Novell, VINES de Banyan y LAN Server de IBM entre otros. Todos estos sistemas operativos de red pueden operar y procesar solicitudes de aplicaciones que se ejecutan en clientes, mediante el procesamiento de las solicitudes mismas.

1.3.2Sockets

Un socket es un mecanismo de comunicación entre dos o más procesos, gracias al cual es posible enviar o recibir información. A efectos de programación un socket funciona como un descriptor de ficheros de bajo nivel; comandos como read() y write() funcionan con sockets de la misma forma que lo hacen con ficheros y tuberías.
El conjunto de servicios que ofrece un socket fue diseñado para facilitar una conexión entre procesos, tanto si se ejecutan en una sola máquina, como si lo hacen en red. Los procesos se intercambian información transmitiendo datos a través de mensajes que circulan entre un socket en un proceso y otro socket en otro proceso. Para la comunicación entre máquinas se suelen utilizar los protocolos TCP/IP, logrando así la independencia del hardware y de la arquitectura de red mediante la cual se establece el enlace; siendo esto posible gracias a la estructura en forma de capas que posee una red de ordenadores (véase ). Los sockets son conexiones que pertenecen a la capa de transporte de la estructura OSI. Una aplicación con sockets debe especificar los puertos de protocolo local y remoto y la dirección IP remota que utilizará, si usará TCP o UDP, y si iniciará transferencia o esperará por una conexión (es decir, si funcionará como servidor o cliente).
Tipos de sockets
El mecanismo de sockets está diseñado de forma genérica; un socket por sí mismo no contiene información suficiente para describir la comunicación entre procesos. Los sockets operan dentro de dominios de comunicación, que determinan el formato de direcciones a utilizar y el protocolo de comunicación. Además el dominio difine si los dos porcesos que se comunican se encuentran en el mismo sistema o en sistemas diferentes y cómo pueden ser direccionados. De esta forma un socket puede clasificarse según su dominio y según el tipo de conexión que realice.
En función del tipo de conexión se dispone de varios tipos de socket, que describen la forma en la que se transfiere información a través de ese socket: sockets stream, sockets datagrama y sockets raw.
Los sockets stream son un servicio orientado a conexión donde los datos se transfieren sin encuadrarlos en registros o bloques. Para establecer una comunicación utilizando el protocolo TCP.
Los sockets datagrama son un servicio de transporte si conexión que utilizan el protocolo de transporte UDP. Cada vez que se envían datagramas es necesario enviar el descriptor del socket local y la dirección del socket que deve recibir el datagrama. Por tanto, hay que enviar datos adicionales cada vez que se realice una comunicación. Los datos se envían y reciben en paquetes cuya entrega no está garantizada.
Con respecto a la clasificación en función del dominio, bajo Unix existen dos dominios: uno para comunicaciones internas al sistem (dominio UNIX) y el otro para comunicaciones entre sistemas (dominio Internet). El dominio UNIX (AF_UNIX) permite una comunicación intrasistema entre procesos que corren en el mismo microprocesador. Se permiten tanto los sockets stream como los datagrama; no se permiten los sockets de tipo raw. El dominio Internet (AF_INET) soporta los protocolos estándar de Internet TCP y UDP y se utiliza para comunicar procesos que corren en distintos microprocesadores. Permite sockets stream, datagrama y raw.

1.3.3 RPC
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.

1.3.4 CORBA
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.
CORBA es una tecnología que oculta la programación a bajo nivel de aplicaciones distribuidas, de tal forma que el programador no se tiene que ocupar de tratar con sockets, flujos de datos, paquetes, sesiones etc. CORBA oculta todos estos detalles de bajo nivel. No obstante CORBA también brinda al programador una tecnología orientada objetos, las funciones y los datos se agrupan en objetos, estos objetos pueden estar en diferentes máquinas, pero el programador accederá a ellos a través de funciones normales dentro de su programa.
Veamos un ejemplo:
Esta función ejecutaría el método setMode sobre el objeto object, para el programador esta llamada es como una operación local, no hay más complejidad.
los métodos y datos corba se agrupan formando lo que se denominan interfaces, los interfaces pueden ser interpretados como objetos que agrupan datos y métodos para acceder a estos. todos estos interfaces se definen usado un lenguaje idl (interface definition language), que es precisamente esto, un lenguaje para la definición de interfaces. este lenguaje es estándar y lo soportan todas las implementaciones corba.
es algo más que una abstracción que oculta la complejidad de red, -> todas las llamas para el programador son iguales -> se definen objetos y métodos -> los objetos son remotos -> no porque corba oculte cosas debemos dejar de pensar en la eficiencia de red hay una multitud de sistemas con un propósito muy similar a corba circulando por el mundo, los más usados son: el rpc (remote procedure call) de sun microsystems y dcom (distributed que los desarrolladores de gnome han adoptado es individuales corba -> muy importante especificación, omg.

1.4 Optimización de preguntas y transacciones

El propósito es seleccionar el mejor camino de acceso para una consulta local.

Se estudia el coste de las comunicaciones.
Objetivo: la reducción de la cantidad de datos transferidos.
Optimización mediante operación de semijoin.

Proceso distribuido de consultas utilizando semijoin??Reducción del número de tuplasantes de ser transferidas a otro nodo. ??Se envía la columna con la que se va a realizar el join de una relación R al nodo donde se encuentra la otra relación, allí se realiza el join con la otra relación S??Se envían las columnas implicadas en el resultado al nodo inicial y se vuelve a realizar el join con R.??Sólo se transfieren las columnas de R que intervienen en la realización del join en una dirección y el subconjunto de columnas de S resultantes en la otra.