You are on page 1of 137

INSTITUO TECNOLÓGICO DE CULIACÁN Ingeniería en Sistemas Computacionales

Temas Selectos de Bases de Datos Semestre: Ago-Dic de 2013
Dr. Clemente García Gerardo

Introducción Bases de Datos
¿Qué es una Base de Datos?
• Es una colección de datos organizada de tal forma que puede consultarse y actualizarse, de manera eficiente y ordenada
• Es un conjunto de registros de información ordenados de acuerdo a un diseño. • Es un modelo que representa al sistema, a través de sus diferentes características y componentes, debidamente simbolizadas por los datos adecuados .

Introducción Bases de Datos
Representación gráfica de una base de datos
Base de Datos Vista de las bases de datos en un servidor, usando la herramienta SQL Server Enterprise Manager

Definición de tablas (DataBase MetaData)

Tablas
registra toda la información del sistema de SQL Server registra la existencia del resto de bases de datos, incluida la ubicación de los archivos de base de datos Registra todas las cuentas de inicio de sesión y todas las opciones de configuración del sistema registra la información de inicialización de SQL Server, y siempre mantiene disponible una copia de seguridad reciente de master

Introducción Bases de Datos Contenido de una base de datos Contiene una fila por cada objeto creado en una base de datos. .

Introducción Bases de Datos Consulta a la tabla SysObjects Base de Datos Llave Primaria Tabla de usuario Procedimiento Almacenado .

Estos modelos se pueden agrupar en dos categorías: • Conceptuales • Modelos conceptuales: • Ejecución Se enfoca en la naturaleza lógica de la representación de datos.Modelos de BD ¿Qué es un modelo de base de datos? Es un conjunto de ideas lógicas utilizadas para representar la estructura de datos y las relaciones entre ellos dentro de la base de datos. Este modelo está comprometido con lo que está representado en la base de datos y NO en cómo está representado. .

1) 1:1 Mujer (0.1) Matrimonio Ejemplo de modelo conceptual E-R Fecha . Orientado a Objetos Hombre (0.Modelos de BD Ejemplos de modelos conceptuales: 1. Entidad-Relación (E-R) 2.

Modelos de BD. Entidad-Relación .

Modelos de BD. Entidad-Relación .

EJECUCIÓN • Modelos de ejecución se enfoca en el cómo los datos están representados en la base de datos o en como se ejecutan las estructuras de datos para representar lo que está modelado Los modelos de bases de datos que se incluyen son: • Bases de datos jerárquicos • Bases de datos de red • Bases de datos relacionales • Bases de datos orientadas a objetos .Modelos de BD.

hasta 50 años después del presente milenio.Modelos de BD Evolución La siguiente gráfica muestra el proceso evolutivo de las técnicas de modelado de base de datos en el periodo de finales de los años 40s. 2000 1990 1980 1970 1960 1950 Pre-1950 Sist. Archivos Jerárquico Red Relacional Objectos Obj-relacional .

Modelos de BD. Cualquier búsqueda de datos a través de los archivos planos tiene que ser programada explícitamente. y la base de datos está almacenada en archivos "planos" en un sistema de archivos. implica que no se aplica ninguna técnica para modelar. La ventaja de varios modelos de base de datos es que ellos proporcionan algunos programas de ese tipo. . SISTEMA DE ARCHIVOS Sistema de archivos Usar un modelado de la base de datos de sistema de archivos.

Compañía Departamento Gerente Empleado Proyecto Tareas La desventaja de este modelo. departamento. gerente y finalmente el empleado. no se puede buscar por un empleado sin primero encontrar la compañía. es que cualquier acceso a los datos tiene que generarse en el nodo raíz.Modelos de BD. En el modelo que se ilustra en la gráfica. Relaciones 1:1 o 1:n . Las tablas en este modelo toman una relación de padre-hijo. SISTEMA JERÁRQUICO Modelo de Bases de Datos jerárquicos Este modelo es como una estructura de árbol invertida.

Compañía Tipo Empleado Departamento Gerente Proyecto Tareas Relación de muchos a muchos Empleado Asignación .Modelos de BD. En este modelo se permite a la tabla hijo tener mas de un padre. SISTEMA DE RED Modelo de Bases de Datos de Red Este modelo. es esencialmente un refinamiento del modelo jerárquico. logrando de esta manera crear una estructura de tablas como una red.

cuya estructura principal es la relación. RELACIONAL Modelo de Base de Datos Relacional En el modelo relacional se representa el mundo real mediante tablas relacionadas entre sí por columnas comunes. .Modelos de BD. Las bases de datos que pertenecen a esta categoría se basan en el modelo relacional. es decir una tabla bidimensional compuesta por filas y columnas.

RELACIONAL .Modelos de BD.

Modelos de BD. RELACIONAL .

RELACIONAL El modelo de base datos relacional y una imagen de los datos .Modelos de BD.

SU HISTORIA .Modelo Relacional.

Almacenar gran volumen de datos 4. Permite hacer consultas a la bases de datos (Lenguaje de Interrogación DML-) 3.Sistema manejador de Base de Datos ¿Qué es un sistema manejador de bases de datos? • Por sus siglas en inglés DBMS. Controla el acceso a los datos . es un sistema de gestión de bases de datos. Manejar la creación de bases de datos (Lenguaje de Definición de Datos – DDL-). • Es un conjunto de programas que se encargan de: 1. 2.

Usuario SOLICITUD DATOS RESPUESTA DBMS LECTURA Base de datos local 1. Valida. Por ejemplo. .DBMS CENTRALIZADO La siguiente figura ilustra cómo un DBMS centralizado maneja las interacciones entre el usuario final y la base de datos. El DBMS recibe la solicitud de una aplicación (o de un usuario) 2. la solicitud podría requerir datos de una sola tabla o acceso a varias tablas. analiza y descompone la solicitud La solicitud podría incluir operaciones aritméticas y/o lógicas. seleccionar a todos los clientes con saldo>1000.

la seguridad y la integridad 7. Determina la ruta de los componentes de los datos lógicos a los físicos solicitados 4. . Descompone la solicitud en varias operaciones de I/O de disco 5.DBMS CENTRALIZADO 3. localiza. 8. lee y valida los datos 6. Garantiza la consistencia. si las hay especificadas por la solicitud. Presenta los datos seleccionados en el formato requerido Todas estas actividades son transparentes para el usuario. Busca. Valida los datos de conformidad con las condiciones.

ubicada en CLN DBMS Base de Datos Esta computadora es conocida como servidor de base de datos. Computadora 1. ubicada en MZT Computadora 3.Procesamiento Distribuido Permite compartir el procesamiento lógico de la base de datos entre dos o más sitios físicamente independientes conectados mediante una red. Red de comunicación Computadora 2. . ubicada en GVE La figura muestra que un sistema de procesamiento distribuido reparte las tareas de procesamiento de la base de datos en tres sitos conectados a través de una red.

• En un sistema de Base de Datos Distribuida. • 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. pero que están (los datos) dispersos en los diferentes sitios de una red computacional. Los sitios están conectados a través de una red de computadoras. .Bases de Datos Distribuidas • Es una colección de datos que pertenecen lógicamente a un mismo sistema. • Es una base de datos lógicamente relacionada almacenada en dos o más sitios físicamente independientes. una base de datos se compone de varias partes conocidas como fragmentos de la base de datos. éstos se localizan en diferentes sitios.

ubicada en GVE La base de datos de la figura anterior esta dividida en tres fragmentos (A. ubicada en MZT DBMS Fragmento C Sitio 3. Es una aplicación que maneja un Base de Datos Distribuida como si esta estuviera almacenada en una misma computadora.Bases de Datos Distribuidas Sitio 1. . Las computadoras (1.B y C).2 y 3) están conectadas por medio de un sistema de red. ubicada en CLN DBMS Fragmento A 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. localizados en diferentes sitios. un usuario en cualquier sitio puede accesar los datos en cualquier parte de la red exactamente como si los datos estuvieran almacenados en su propio sitio. DDBMS DBMS Fragmento B Red de comunicación SBDD Sitio 2.

ubicada en MZT BD Lógica DBMS Fragmento B DBMS Fragmento C Sitio 3. ubicada en GVE .Bases de Datos Distribuidas Sitio 1. ubicada en CLN DBMS Fragmento A Esta BD estará definida en uno de los sitios o una computadora exclusiva para ello Red de comunicación Sitio 2.

la cual requiere acceder datos en diferentes sitios. Administrador de la BD DBA Local DBMS Fragmento A DBA GLOBAL Red de comunicación BD Lógica DBA Local DBMS Fragmento B DBMS Fragmento C DBA Local . Cada sitio participa en la ejecución de al menos una aplicación global.Bases de Datos Distribuidas Cada sitio en la red es autónomo en sus capacidades de procesamiento y es capaz de realizar operaciones locales.

. • Los costos de operación se reducen. • La comunicación entre nodos se mejora. • Son amigables al usuario. • Nuevos nodos se pueden agregar fácil y rápidamente.BDD. • La probabilidad de que una falla en un solo nodo afecte al sistema es baja y • Existe una autonomía e independencia entre los nodos. VENTAJAS •En primer lugar los datos son localizados en lugar más cercano. • El procesamiento es rápido debido a que varios nodos intervienen en el procesamiento de una carga de trabajo. por tanto. el acceso es más rápido.

la necesidad de desarrollar una aplicación global (que incluya a toda la organización). se resuelva fácilmente con bases de datos distribuidas. .BDD. el enfoque de bases de datos distribuidas permite un crecimiento suave. y por un crecimiento futuro. VENTAJAS Las razones por las que compañías y negocios migran hacia bases de datos distribuidas incluyen razones organizacionales y económicas. entonces. El enfoque distribuido de las bases de datos se adapta más naturalmente a la estructura de las organizaciones. Además. para obtener una interconexión confiable y flexible con las bases de datos existente. Si una organización crece por medio de la creación de unidades o departamentos nuevos.

BDD. las bases de datos distribuidas pueden presentar cierto grado de tolerancia a fallas haciendo que el funcionamiento del sistema no dependa de un solo lugar como en el caso de las bases de datos centralizadas. haciendo que los usuarios tengan control local de los datos con los que interactúan. . VENTAJAS Los datos se pueden colocar físicamente en el lugar donde se accesan más frecuentemente. Mediante la replicación de información. Esto resulta en una autonomía local de datos permitiendo a los usuarios aplicar políticas locales respecto del tipo de accesos a sus datos.

el control de concurrencia y los mecanismos de recuperación son mucho más complejos que en un sistema centralizado . Dado que éstos residen en muchos nodos diferentes y se pueden consultar por nodos diversos de la red. la probabilidad de violaciones de seguridad es creciente si no se toman las precauciones debidas.BDD. La integridad se refiere a la consistencia. validez y exactitud de la información. Dado que los datos pueden estar replicados. DESVENTAJAS La principal desventaja se refiere al control y manejo de los datos. La habilidad para asegurar la integridad de la información en presencia de fallas no predecibles tanto de componentes de hardware como de software es compleja.

El sistema no se ve afectado por fallas de nodos y sistema continúa operando en el caso de una falla de nodo o de una expansión de la red. Cada sitio local puede actuar como un DBMS independiente. 2. reglas que la describen Las siguientes reglas describen una base de datos totalmente distribuida y. Ningún sitio en la red depende de un sitio central o de cualquier otro sitio y los sitios tienen las mismas capacidades. el control de concurrencia. centralizado y cada sitio es responsable de la seguridad. Independencia de fallas. Independencia del sitio local. 3. la reglas sí constituyen un útil objetivo de base de datos distribuida 1. el respaldo y la recuperación. Independencia del sitio central. autónomo.BDD. aunque ningún DDBMS actual se adapta. .

La fragmentación es transparente para el usuario y no necesita conocer el nombre de los fragmentos. La optimización de las consultas es realizada transparentemente por el usuario. 6.BDD. El usuario ve sólo una base de datos lógica. reglas que la describen 4. 5. El DDBMS maneja todos los fragmentos transparentemente hacia el usuario 7. Transparencia de ubicación. El usuario no necesita saber la ubicación de los datos para recuperarlos. Procesamiento de consulta distribuida. El usuario ve sólo una base de datos lógica. Transparencia de replicación. Una consulta distribuida puede ser ejecutada en varios sitios. El DDBMS selecciona de una forma transparente el fragmento que va a accesar. Transparencia de fragmentación. .

BDD. Independencia del hardware. . 11. El sistema debe funcionar en cualquier plataforma de hardware. 12. El sistema debe funcionar con cualquier plataforma de red. 9. reglas que la describen 8. El sistema debe funcionar con cualquier plataforma de software de sistema operativo. Procesamiento de transacciones distribuidas. Independencia del sistema operativo. Independencia de la red. 10. Independencia de la base de datos. Una transacción puede actualizar datos en varios sitios diferentes y se ejecutan en varios sitios diferentes de procesamiento de datos. El sistema debe soporta cualquier producto de base de datos provisto por cualquier proveedor.

características para ser considerado distribuido Un Sistema Manejador de Base de Batos Distribuidos (DDBMS) controla el almacenamiento y procesamiento de datos lógicamente relacionados a través de computadoras interconectadas. . Transformación Para determinar qué componentes de solicitud de datos se distribuyen y cuáles son locales. Interface de aplicación Para interactuar con el usuario final o con programas de aplicación y con otros DBMS dentro de la BDD 2.DBMS. Características de un DBMS para ser considerado distribuido 1. en las cuales. 3. Validación Para analizar las solicitudes de datos. las funciones de datos como de procesamiento se distribuyen en varios sitios.

DBMS. 8. características para ser considerado distribuido 4. Formateo Para preparar los datos para su presentación al usuario final o un programa de aplicación. Mapeo Para determinar la ubicación de los segmentos locales y remotos 6. . Seguridad Para proporcionar privacidad tanto en bases de datos locales como remotas. Optimización de consultas Para encontrar la mejor estrategia de acceso. ¿cuáles fragmentos deben ser accesados para consulta y cómo. Interface de E/S Para leer o escribir datos de medios de almacenamiento locales permanentes 7. si las hay. se deben sincronizar las actualizaciones de los datos? 5.

Respaldo y recuperación Para garantizar la disponibilidad y recuperabilidad de la base de datos en caso de una falla. lo mismo que transacciones a través de segmentos múltiples distribuidos. Esta actividad incluye la sincronización de transacciones locales y remotas. 10. .DBMS. Administración de la base de datos Para el administrador de la base de datos 11. Manejo de transacciones Para garantizar que los datos pasen de un estado consistente a otro. Control de concurrencia Para manejar el acceso simultáneo a los datos y garantizar su consistencia a través de los fragmentos en DDBMS 12. características para ser considerado distribuido 9.

Para que la interacción entre el TP y DP se requiere de protocolos utilizado por el DDBMS . Al DP también se le conoce como administrador de datos (DM). COMPONENTES • Estaciones de trabajo (sitios o nodos) que formen el sistema de red. • El procesador de transacciones (TP) es un componente de software encontrado en cada computadora que solicita datos. • Medios de comunicación que transporten los datos de una estación a otra. Es deseable que las funciones de las bases de datos distribuidas puedan realizarse en diferentes plataformas. • Componentes de hardware y software residentes en la estación de trabajo. El DDBMS debe de ser independiente del hardware del sistema de computadoras. El procesador recibe y procesa las solicitudes de datos de la aplicación. El DDBMS debe de ser independiente de los medios de comunicación. Al TP también se le conoce como procesador de aplicaciones (AP) o administrador de transacciones (TM) •El procesador de datos (DP) es el componente de software en cada computadora que guarda y recupera datos localizados en el sitio.DDBMS. Los componentes de red permiten el intercambio.

DDBMS. COMPONENTES TP TP TP DP DP Red de comunicación TP DP TP TP DP Cada procesador de transacciones puede accesar datos en cualquier procesador de datos y cada procesador de datos maneja todas las solicitudes de datos locales de cualquier procesador de transacciones .

Datos en un solo sitio Proceso en un solo sitio DBMS anfitrión (maimframe.Niveles de distribución: DATOS Y PROCESOS Los DBMS se clasifican en base a cómo la distribución de los procesos y datos son soportados. minicomputadora o PC) Servidor de archivos DBMS Cliente-Servidor (DBMS LAN) Datos en sitios múltiples No aplicable Proceso en múltiples sitios DDBMS Cliente-Servidor (Totalmente distribuido) .

con soporte para múltiples procesadores de datos y de transacciones en diversos sitios. Según el nivel de soporte de diferentes tipos DBMS centralizados. los DDBMS se clasifican como: • Homogéneos Integran un solo tipo de DBMS centralizado a través de un red • Heterogéneos. Integran diferentes tipos de DBMS centralizados a través de un red Un DDBMS totalmente heterogéneo soportará diferentes DBMS que incluso pueden soportar diferentes modelos de datos que funcionan en diferentes sistemas de computos como mainframes. minicomputadoras y PC.Procesamiento y datos en sitios múltiples (MPMD) El escenario MPMD describe un sistema de administración de base de datos totalmente distribuida. .

Escenario de BDD heterogénea
Plataforma DBMS Sistema Operativo Protocolo de comunicaciones de red APPC LU 6.2 DECnet

IBM 3090 DEC/VAX

DB2 VAX rdb

MVS MVS

IBM AS/400 Computadora RISC
Pentium CPU

SQL/400 Informix
Oracle

OS/400 Unix
Windows 2000

3270 TCP/IP
NetBios

DDBMS COMERCIAL (INGRES/STAR)
Ingres / Star Es un manejador de datos distribuidos, lo que le da a Ingres / Star la capacidad de un sistema manejador de bases de datos distribuidas relacional, el cual incluye acceso, almacenamiento y proceso distribuido. Ingres / Star permite incluir múltiples hardware y sistemas operativos (mainframe, computadoras de escritorio), así como múltiples DBMS.

Ingres / Star permite combinar un número de bases de datos separadas, para crear una vista sencilla de los datos, los cuales son accedidos como si fuera una base de datos local. Si se instalan los productos Net y Enterprise Access junto con Star, se consigue acceso transparente, simultáneo a través de nodos múltiples, plataformas de hardware, y configuraciones del software por medio de protocolos de comunicación múltiples de la red.

DDBMS INGRES/STAR (productos que debe instalar)
Productos que se deben instalar El tipo y la localización de la BD que se desea acceder determina que productos de Ingres deben instalarse.

• Para acceso de datos locales

Ingres DBMS Instalar Ingres
Base de Datos Ingres

Ingres por sí mismo trabaja con una base de datos a la vez en su propia computadora. Por lo tanto, para tener acceso a una sola base de datos en una sola computadora, solo instale Ingres en su computadora local.

.DDBMS INGRES/STAR (productos que debe instalar) • Acceso de datos remotos DBMS Instalar Net Base de Datos Red de comunicación DBMS Instalar Net Base de Datos DBMS Instalar Net Base de Datos Cuando la computadora es parte de una red. Por lo tanto para acceder la BD de una computadora remota. Net permite acceder una base de datos sencilla desde otra computadora. debes instalar Net en ambas computadoras.

DDBMS INGRES/STAR (productos que debe instalar) • Para acceso de datos heterogéneos Los productor Enterprise Access permiten accesar datos en bases de datos diferentes a Ingres. Si la BD no Ingres se encuentra en una computadora remota debe instalar Net. por lo tanto para accesar BD distintas a Ingres. se debe instalar el Enterprise Acces adecuado para la BD deseada. Ingres / Star: Herramientas y aplicaciones SQL Ingres Star Local DBMS Local DBMS Enterprise Access BD Local BD Local BD Local .

Ingres /Star. z/OS) . BD Heterogéneas Las aplicación Ingres sobre el sistema operativo VMS son ligadas con el DBMS remoto (que se ejecuta en unix y con protocolo TCP/IP) a través de Ingres Net. Ingres/Star: herramientas y aplicaciones Ingres Net DBMS Local (Ingres) Las aplicaciones Ingres sobre el sistema operativo VMS son ligadas con el DB2 remoto (que se ejecuta en MVS y con protocolo SNA LUO) a través del Ingres Net y Enterprise Acess Protocolo TPC/IP Protocolo SNA LU0 Ingres Net DBMS Remoto (Ingres) Ingres Net BD Ingres Sistema Operativo VMS Enterprise Acces para DB2 BD Ingres Unix DB2 Manejador BD DB2 Sistema Operativo IBM-MVS (OS/390.

Ingres /Star. esta se logra usando las utilerías netutil o ingnet. debe utilizar netutil o ingnet para definir cada uno de los nodos remotos que contienen una base de datos que se desea accesar. Definiendo BD remotas Usted o el administrador del sistema Ingres. Definir un nodo remoto le da un Vnodo nombre (virtual) Los usuarios Star deben ser autorizados sobre los nodos locales y remotos en los cuales ellos desean accesar información. Crear un BDD createdb bdempresa /star Se creo la BD con un coordinador por default iibdempresa createdb bdempresa /star empresa Se creo la BD con un coordinador empresa .

amount) as link from john. dándole el nombre usa_sales y redefiniendo sus columnas como customer.sales with node = reno. inv_no y amount. inv_no. database = west_usa. .Ingres /Star. register table usa_sales (customer. Definiendo BD remotas La siguientes instrucciones registra la tabla “sales” de la BD West_USA sobre el nodo reno.

abortada. La cual permite que una BDD sea tratada como una sola BD lógica. centralizado.DDBMS. El DDBMS de transformar las solicitudes desempeño por usoes enresponsable una red o por diferencia de plataforma. que los datos pueden estar replicados en varios sitios y no necesita saber la ubicación los datos características de de transparencia del DDBMS tienen Las características de transparencia del DDBMS son: • • • • • De distribución La cual permite que el sistema continúe operando en De transacción De falla el caso de una falla de nodo. . de red y jerárquico) conforme a un esquema común. para el usuario. de datos del es esquema global en esquema del DBMS local. están Esta transparencia garantiza complejidades de sitios unadeBDD escondidas o son que la transacción será o completada en su totalidad o transparentes. De desempeño La cual permite que la integración varios DBMS locales el sistemade funciones como si fuera diferentes un DBMS De heterogeneidad (relacional. El sistema no sufrirá ninguna degradación de global. El usuario noDE necesita saber: que los CARACTERÍSTICAS TRANSPARENCIA datos están en particiones. todas en varios la red. Las la propiedad común de permitir que el usuario sienta que La cual permite una transacción datos las es el único que estaque utilizando la actualice BD.

pero no especifica su ubicación. Se reconocen tres niveles de transparencia de distribución: 1. Transparencia de distribución El nivel de transparencia soportado por el DDBMS varía de sistema a sistema.DDBMS. Esto permite acceder los datos sin especificar los nombres y ubicación de los fragmentos. La transparencia de ubicación local Existe cuando el usuario o programador debe especificar el nombre de los fragmentos de la BD y la ubicación de los fragmentos. La transparencia de ubicación Existe cuando el usuario o programador debe especificar el nombre de los fragmentos de la BD. 2. . 3. La transparencia de fragmentación El usuario o programador no necesita saber que una BD está en particiones.

LM Red . Transparencia de distribución Suponga que la tabla empleado tiene el esquema que se muestra en la siguiente figura: E_Nombre E_FechaNaci E_Direccion E_Depto E_Salario Distribución de los datos Gve CLN Un usuario desea realizar una consulta SQL.DDBMS. donde muestre todos los empleados con fecha de nacimiento anterior a 1-Enero-1990.

Transparencia de distribución La BDD soporta transparencia de fragmentación La consulta se ajusta al formato de consulta de base de datos local. Select * from Emp_1 where E_fechanaci <‟01-01-1990‟ Union Select * from Emp_2 where E_fechanaci <‟01-01-1990‟ Union Select * from Emp_3 where E_fechanaci <‟01-01-1990‟ .DDBMS. Select * from Empleado where E_fechanaci <‟01-01-1990‟ La BDD soporta transparencia de ubicación En la consulta deben especificarse los nombre de los fragmentos. mas no su ubicación. ya que no se especifican ubicaciones o nombres de los fragmentos.

DDBMS. NODE es para propósito de ilustración y no forma parte de la sintaxis de SQL. Transparencia de distribución La BDD soporta transparencia de ubicación local En la consulta debe especificarse el nombre y ubicación del fragmento Select * from Emp_1 NODE GVE where E_fechanaci <‟01-01-1990‟ Union Select * from Emp_2 NODE LM where E_fechanaci <‟01-01-1990‟ Union Select * from Emp_3 NODE CLN where E_fechanaci <‟01-01-1990‟ NODE indica la ubicación del fragmento de la base de datos. .

.DDBMS. por sus siglas en inglés) o un catálogo de datos distribuidos (DDC. es el esquema de BD común utilizado por TP locales. El DDC contiene la descripción de toda la base tal como la ve su administrador. por sus siglas en inglés). para transformar las consultas de usuarios en subconsultas (solicitudes remotas) que serán procesadas por diferentes procesadores de datos. La descripción de la base de datos. El DDC es en si mismo distribuido y está replicado en los nodos de la red. Transparencia de distribución La transparencia de distribución es soportada por un diccionario de datos distribuido (DDD. conocida como esquema global distribuido.

si ambas consultas producen el mismo resultado. . esto es. típicamente en cálculo relacional. a una consulta equivalente en una especificación de bajo nivel.El problema de procesamiento de consultas La función principal de un procesador de consultas relacionales es transformar una consulta en una especificación de alto nivel. La transformación debe ser correcta y eficiente. La consulta de bajo nivel implementa de hecho la estrategia de ejecución para la consulta. Es correcta si la consulta de bajo nivel tiene la misma semántica que la consulta original. típicamente alguna variación del álgebra relacional.

Sin embargo. la dificultad más importante es seleccionar la estrategia de ejecución que minimiza el consumo de recursos.El problema de procesamiento de consultas El mapeo bien definido que se conoce entre el cálculo relacional y el álgebra relacional hace que la correctitud de la transformación sea fácil de verificar. Una consulta en el cálculo relacional puede tener muchas transformaciones correctas y equivalentes en el álgebra relacional. . Ya que cada estrategia de ejecución equivalente puede conducir a consumos de recursos de cómputo muy diferentes. producir una estrategia de ejecución eficiente es mucho más complicado.

El problema de procesamiento de consultas Considere los siguientes esquemas Ingenieros E ENo ENom Titulo Ingenieros asignados a cada proyecto (G) ENo JNo Responsble Jornada Se desea realizar la siguiente consulta. ¿Encuentre todos los nombres de empleados que administran un proyecto? .

el álgebra relacional no es suficiente para expresar la ejecución de estrategias. Sin embargo.Eno and responsable=“administrador” Dos consultas equivalentes en el álgebra relacional. las estrategias de ejecución de consultas pueden ser bien expresadas como una extensión del álgebra relacional. G where E.El problema de procesamiento de consultas La expresión de la consulta en SQL se puede ver como: Select Enom from E. en sistemas distribuidos. consume mucho menos recursos que la primera. .ENo=G. y por lo tanto es mejor. En un contexto centralizado.ENo = G.Eno (E  G)) Y ∏Enom (E  E. que son transformaciones correctas de la consulta SQL son: ∏Enom (Responsable=“Administrador”  E.ENo (Responsable=“Administrador” (G)) La segunda estrategia que evita calcular el producto cartesiano de E y G.

.El problema de procesamiento de consultas La consulta distribuida debe ser complementada con operaciones para el intercambio de datos entre diferentes nodos. el procesador de consultas distribuidas debe seleccionar también los mejores sitios para procesar datos y posiblemente la forma en que ellos tienen que ser transformados. Además de elegir el orden de las operaciones del álgebra relacional.

Nodo 1 E1 = Eno<=“E3” E) Nodo 3 G1 = Eno<=“E3” G) Nodo 2 E2 = Eno>“E3” E) Nodo 4 G2 = Eno>“E3” G) El resultado se desea en el Nodo5 .ENo (Responsable=“Administrador” (G)) Suponga que las relaciones E y G están fragmentadas. horizontalmente (tuplas completas) como se muestra a continuación.El problema de procesamiento de consultas Considere la siguiente consulta en un ambiente distribuido ∏Enom (E  E.

• La estrategia B centraliza todos los datos en el nodo resultante antes de procesar la consulta.ENo (Responsable=“Administrador” (G)) • La estrategia A explota el hecho de que las relaciones E y G están fragmentadas de la misma manera y ejecuta la operación de selección y junta en paralelo. .El problema de procesamiento de consultas Se presentan dos diferentes estrategias de ejecución distribuidas para la consulta: ∏Enom (E  E.

El problema de procesamiento de consultas Nodo 5 Resultado= E1‟ υ E2„ Nodo 1 Nodo 2 E1‟= E1 ENo G1„ Nodo 3 Nodo 4 E2‟= E2 ENo G2„ G1‟=  Responsable=“Administrador” G1 G2‟=  Responsable=“Administrador” G2 Estrategía A Nodo 5 Resultado= (E1 υ E2) ENo Responsable=“Administrador” (G1 υ G2) ¿Cómo saber cuál de las estrategias consume menos recursos? Nodo 1 Nodo 2 Nodo 3 Nodo 4 Modelo de costos Estrategía B .

de manera que. 3. existen 20 administradores en la relación G. La transferencia de una tupla (tuptrans) tiene un costo de 10 unidades. 5. se usará un modelo de costo simple: 1. las relaciones G y E están agrupadas localmente en los atributos Responsable y ENo. los datos están uniformemente distribuidos entre los nodos 6. respectivamente.El problema de procesamiento de consultas Para evaluar el consumo de recursos. Suponga que las relación E tiene 400 tuplas y la relación G 1000 tuplas 4. hay un acceso directo a los tuplas de G y E. . Suponga que el costo de acceso a una tupla (tuplacc) es 1 unidad 2.

Transferir G‟ a los nodos de E. requiere 20*tuplatrans= 20*10 = 200 3. Transferir E‟ al nodo resultante requiere 20 * tuplatrans = 20 * 10 = 200 Total de unidades=820 . Producir E‟. Producir G‟ seleccionando G. requiere 20 * tuplaacc = 20 * 1 = 20 unidades 2. requiere (20*20) * tuplaacc = 400 4. concatenando G‟ y E.El problema de procesamiento de consultas El costo de la estrategia A se puede calcular como sigue: 1.

requiere 400 * tuplatrans = 400 * 10 = 4. Transferir E al nodo 5.El problema de procesamiento de consultas El costo de la estrategia B se puede calcular como sigue: 1. Calcular G‟ seleccionando G.000 2.000 3.000 . requiere 1000 * tuplatrans = 1000 * 10 = 10. 1000 * Tuplaacceso = 1000*1=1000 4.Transferir G al nodo 5. Juntar E y G‟. requiere 400*20*tuplacceso= 400*20*1=8000 Costo total=23.

000 tuplas c/tupla 100 bytes Tamaño de la relación 10000*100=106 15 Bytes 15 Bytes 9 Bytes Nodo 2. tabla Empleado Nombre Apellido COD Dir Sexo Sueldo FechaNac Depto 10.Ejemplo de consulta distribuida Nodo 1. tabla Departamento Nombre NDepto Responsable Edificio 10 Bytes 4 Bytes 9 Bytes 4 Bytes 100 tuplas c/tupla 35 bytes Tamaño de la relación 100*35=3500 .

000 bytes. obtener el nombre del empleado y el nombre del departamento al que pertenece” . Cada tupla resultante será de una longitud de 40 bytes.000 tuplas.Ejemplo de consulta distribuida “Por La consulta se lanza desde el nodo 3 (nodo respuesta) que no tiene datos implicados en la consulta. El tamaño del resultado será por tanto de 400. Q1(1): ΠNombre.NombreDPto(EMPLEADO*DEPARTAMENTO) cada empleado. El resultado de esta consulta constará de 10.Apellido. Existen tres alternativas para resolver la consulta.

500 = 1. tanto la relación Empleado.003.000.Ejemplo de consulta distribuida Primera alternativa: Transferir. . En éste caso se transfieren: 1. como la relación Departamento al nodo respuesta (nodo 3) y realizar allí mismo la operación de join.000 + 3.500 bytes.

Ejemplo de consulta distribuida Segunda alternativa: Transferir la relación Empleado al nodo 2.000 + 400.000 (resultado) = 1. Esto implicaría transferir: 1.400. ejecutar el join en este nodo y enviar el resultado al nodo 3.000 bytes .000.

Ejemplo de consulta distribuida Tercera alternativa: Transferir la relación Departamento al nodo 1.000 (byte de la proyección) = 403. los bytes transferidos serán: 3.500 + 400.500 bytes. ejecutar el join en este nodo y enviar el resultado al nodo 3. . En este caso.

000 bytes. obtener departamento y el de su director” el nombre del Q2: ΠNombreDPto.003.Nombre. Se transfieren en este caso:3.Ejemplo de consulta distribuida “Para cada departamento.004.500 bytes.000 = 7. Opción 3: transferimos la relación Departamento al nodo 1 y enviamos el resultado del joinal nodo 3. Opción 2:transferimos la relación Empleado al nodo 2 y enviamos el resultado del join al nodo 3.000.500 + 4.Apellido(Departamento * Empleado) La consulta se lanza desde el nodo 3. Opción 1: transferimos las relaciones Departamento y Empleado al nodo 3.000 = 1.000.500 bytes. Se transfieren:3.000 = 1.000 + 4. .500 + 1.000 bytes). Se transfieren:1. El resultado de esta consulta constará de 100 tuplas(4.

Opción 2: transferir la relación Departamento al nodo 1.000 bytes.Ejemplo de consulta distribuida NUEVO SUPUESTO: las consultas anteriores se lanzan desde el nodo 2.000 de resultado = 403.500 bytes.000. realizar el join y presentar el resultado al usuario del nodo 2. La segunda opción es más optima .500 de Departamento y 400.000 de resultado = 7. Para la consulta Q2: 3. En este caso se transfieren: para la consulta Q1: 3. realizar el join y enviar el resultado al nodo 2. De ésta manera se transferirán el mismo número de bytes para la consulta Q1 y la Q2: 1.500 de Departamento y 4. Opción 1: transferir la relación Empleado al nodo 2.500 bytes.

Se envían las columnas implicadas en el resultado al nodo inicial y se vuelve a realizar el join con R. allí se realiza el join con la otra relación S. . 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. 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.Ejemplo de consulta distribuida Proceso distribuido de consultas utilizando semijoin Reducción de el número de tuplas antes de ser transferidas a otro nodo.

Paso 1. Consulta Q1: proyección en Departamento sobre atributos que van a intervenir en la operación de join y transferencia al nodo 1. Consulta Q2: F2: ΠResponsable(Departamento) Tamaño resultante:9 bytes del atributo Responsable por 100 tuplasde Departamento = 900 bytes transferidos. F1: ΠNDpto(Departamento) Tamaño resultante:4 bytes del atributo NDpto por 100 tuplas de Departamento = 400 bytes transferidos. .Ejemplo de consulta distribuida Semijoin de las consultas Q1 y Q2.

Total bytes transferidos para Q1= 340. Tamaño:( R2: ΠResponsable. Consulta Q1:realización del join de las tuplas transferidas en el paso anterior. Nombre.Ejemplo de consulta distribuida Semijoin de las consultas Q1 y Q2:Paso 2.000+400 (F1)=340.000 bytes transferidos. Apellido (F2* Empleado) 9 + 15 + 15) * 100= 3900 bytes transferidos.000=340.Apellido(F1 * Empleado) + 15) * 10. Se transfieren sólo los atributos necesarios para realizar el join final: Consulta Q2: Tamaño:(4 + 15 R1: ΠDpto.400 Total bytes transferidos para Q2= 3900+900 (F2)=4. Transferencia del resultado del join de nuevo al nodo 1.800 .Nombre.

Las primeras tres se realizan en un nodo central usando información global. en una secuencia optimizada de operaciones locales. optimización global de consultas y optimización local de consultas. Las cuatro capas principales son: descomposición de consultas. cada una de ellas actuando en una base de datos local. La cuarta capa se realiza en cada nodo local. localización de datos. • • • • .Arquitectura del procesamiento de consultas Cuatro capas principales están involucradas en canalizar una consulta a una base de datos distribuida.

Arquitectura en capas del procesamiento de consultas Consultas sobre relaciones Descomposición de consultas Consultas sobre el álgebra Nodo Central Localización de datos Consultas sobre fragmentos Optimización global Optimización de consultas sobre fragmentos Nodo local Optimización local Consultas locales optimizadas Esquema Locales Estadísticas sobre fragmentación Esquema fragmentado Esquema Global .

Arquitectura en capas del procesamiento de consultas
Descomposición de consultas La primera capa descompone una consulta en el cálculo relacional en una consulta en el álgebra relacional que opera sobre relaciones globales. Consiste de cuatro partes: 1. Normalización. Involucra la manipulación de los cuantificadores de la consulta y de los calificadores (Por ejemplo, se verifica el tipo de los operandos cuando se hace la calificación) de la misma mediante la aplicación de la prioridad de los operadores lógicos. Existen dos tipos de formas normales:

• Conjuntiva: es una conjunción de disyunciones
(P11  P12  ..  P1N)  (P21  P22  ..  P2N)  …  (PM1  PM2  ..  PMN) • Disyuntiva: es una disyunción de conjunciones (P11  P12  ..  P1N)  (P21  P22  ..  P2N)  …  (PM1  PM2  ..  PMN)

Arquitectura en capas del procesamiento de consultas
En cualquier forma normal, la expresión está libre de cuantificadores, existencial o universal, por lo que solo se consideran predicados simples.
la forma normal conjuntiva es más práctica puesto que incluye más operadores AND ( ) que operadores OR ( ). Típicamente, los operadores OR se transforman en uniones de conjuntos y los operadores AND se transforman en operadores de junta o selección.

Encuentre los nombres de los empleados que han trabajado en el proyecto J1 y con una duración de 12 o 24 meses
La consulta expresada en SQL es: SELECT ENAME FROM E, G WHERE E.ENO = G.ENO AND G.JNO = "J1" AND Duracion = 12 OR Duracion = 24

Arquitectura en capas del procesamiento de consultas
La consulta en forma normal conjuntiva es: E.ENO = G.ENO  G.JNO = "J1"  (DUR = 12  DUR = 24)

La consulta en forma normal disyuntiva es: (E.ENO = G.ENO  G.JNO = "J1"  DUR = 12)  (E.ENO = G.ENO  G.JNO = "J1"  DUR = 24)

2. Análisis. Se detecta y rechazan consultas semánticamente incorrectas. 3. Simplificación. Elimina predicados redundantes.
4. Reestructuración. Mediante reglas de transformación una consulta en el cálculo relacional se transforma a una en el álgebra relacional. Se sabe que puede existir más de una transformación. Por tanto, el enfoque seguido usualmente es empezar con una consulta algebraica y aplicar transformaciones para mejorarla.

Arquitectura en capas del procesamiento de consultas
Localización de datos La entrada a esta capa (segunda capa) es una consulta algebraica definida sobre relaciones distribuidas. El objetivo de esta capa es localizar los datos de la consulta usando la información sobre la distribución de datos. Esta capa determina cuales fragmentos están involucrados en la consulta y transforma la consulta distribuida en una consulta sobre fragmentos.

Arquitectura en capas del procesamiento de consultas
Optimización Global de Consultas (tercer capa) Dada una consulta algebraica sobre fragmentos, el objetivo de esta capa es hallar una estrategia de ejecución para la consulta cercana a la óptima. La estrategia de ejecución para una consulta distribuida puede ser descrita con los operadores del álgebra relacional y con primitivas de comunicación para transferir datos entre nodos.

La salida de la capa de optimización global es una consulta algebraica optimizada con operación de comunicación incluidas sobre los fragmentos.

es optimizada usando el esquema local del nodo.Arquitectura en capas del procesamiento de consultas Optimización Local de Consultas (cuarta capa) El trabajo de la última capa se efectúa en todos los nodos con fragmentos involucrados en la consulta. Hasta este momento. Cada subconsulta que se ejecuta en un nodo. . La optimización local utiliza los algoritmos de sistemas centralizados. se eligen los algoritmos para realizar las operaciones relacionales. llamada consulta local.

Transparencia de transacción Una transacción es una colección de acciones que hacen transformaciones consistentes de los estados de un sistema preservando la consistencia del sistema. está formada por una o más solicitudes (sentencias SQL) a la base de datos. • La transparencia de transacción es una propiedad del DDBMS que garantiza que las transacciones de base de datos mantendrán la integridad y consistencia de la BDD. . inserciones. La diferencia entre una transacción no distribuida y una distribuida. y supresiones de información.DDBMS. es que la segunda puede actualizar y solicitar datos de varios sitios remotos en una red. Los cambios de estado ocurren debido a actualizaciones. Una base de datos está en un estado consistente si obedece todas las restricciones de integridad definidas sobre ella. o una transacción remota. La transparencia de transacción garantiza que la transacción será completada sólo si todos los sitios implicados completan su parte • • • Sea una transacción distribuida.

67. porque cada solicitud puede hacer referencia un sitio La transacción hace referencia a dos sitios remotos (2y 3) diferente.‟15-03-2008‟.98) Commit work El DBMS no maneja solicitudSitio 2 DP distribuida Cada solicitud puede accesar sólo un sitio remoto a la vez Red Producto Cliente . por ejemplo: La primer solicitud es procesada por el DP del sitio 2 La solicitud update e insert es procesada por el DP en el sitio 3 Begin work Select * from producto where CvePro in (25.DDBMS. Aunque cada solicitud puede hacer referencia sólo a un sitio de procesamiento de datos remoto.89) Update Cliente Set Saldo=Saldo + 235 where CveCli=758 Sitio 1 TP Sitio 3 DP Factura Insert into factura values(100. La transacción como un todo puede hacer referencia a varios sitios de procesamiento de datos. Transparencia de transacción Una transacción distribuida permite que una transacción haga referencia a varios sitios de procesamiento de datos diferentes.1500.

67. ya que la tabla de productos esta en dos sitios diferente. ¿la transacción anterior podrá realizarse? No puede realizarse. .89) Update Cliente Set Saldo=Saldo + 235 where CveCli=758 Insert into factura values(100. el manejador debe permitir solicitudes distribuidas.‟15-03-2008‟.98) Commit work Sitio 2 Red Factura Prod_2 Cliente considerando la característica que una solicitud sólo puede accesar un sitio remoto. Para poder realizar la transacción.DDBMS. Transparencia de transacción Ahora suponga que la tabla de productos esta fragmentada sobre los sitios 2 y 3 Sitio 1 TP Sitio 3 DP DP Prod_1 Begin work Select * from producto where CvePro in (25.1500.

factura where FolioFactura=1000 and ProductoFactura=CvePro Update Cliente Set Saldo=Saldo + 235 where CveCli=758 Insert into factura values(100.DDBMS.‟15-03-2008‟.98) Commit work Sitio 2 Red DP Prod_1 Factura Prod_2 Cliente La capacidad de ejecutar solicitudes distribuidas proporciona capacidades de procesamiento de BD totalmente distribuidas. permite hacer referencia a datos de varios sitios de datos remotos. Transparencia de transacción Solicitud distribuida. porque se puede dividir una tabla en varios fragmentos y hacer referencia a uno o mas de esos fragmentos solamente con una solicitud(transparencia de fragmentación) . Como cada solicitud puede accesar datos de mas de un DP. una transacción de mantenimiento puede accesar varios sitios. Sitio 1 TP Sitio 3 DP Begin work Select * from producto.1500.

. . begin tran t2 . . . end . . Transparencia de transacción Estructuras de transacciones Transacciones planas Es una secuencia de instrucciones encerrada entre las palabras begin end Begin tran t1 . end Transacciones anidadas En las transacciones anidadas las operaciones de una transacción pueden ser así mismo transacciones Begin tran t1 . .DDBMS. . end .

DDBMS. Cuando la transacción es abortada. A esta operación también se le conoce como rollback. . Transparencia de transacción Condiciones de terminación de una transacción : Una transacción siempre termina. Si una transacción termina de manera exitosa se dice que la transacción hace un commit. Si la transacción se detiene sin terminar su tarea. aún en la presencia de fallas. se dice que la transacción aborta. su ejecución es detenida y todas sus acciones ejecutadas hasta el momento son deshechas (undone) regresando a la base de datos al estado antes de su ejecución.

Para evitar este tipo de problemas debe hacerse uso de un protocolo commit de dos fases. Un escenario de este tipo provoca una BD inconsistente.Control de concurrencia en BDD El control de concurrencia es importante en el ambiente de BDD. Sitio 3 Sitio 2 . con sus inevitables problemas de integridad. pero el sitio 2 no logro terminar exitosamente la transacción. ya que es mucho más probable que las operaciones en sitios múltiples y procesos múltiples creen inconsistencia en los datos y así como transacciones que hayan sido detenidas sin llegar a su finalización de forma exitosa. Sitio 1 begin Write(x) Rollbackt Begin Write(x) DP Commit end Fact begin Write(x) end Red DP DP Prod Commit end Ctes En los sitios 1 y 3 la transacción de mantenimiento fue completada exitosamente.

El resultado del protocolo cubre: • Fallas en la red • Fallas en Nodos .¿Qué es el protocolo commit de 2 fases? El protocolo commit de dos fases (2PC) es un algoritmo distribuido que permite a todos los nodos de un sistema distribuido ponerse de acuerdo para hacer commit a una transacción.

El protocolo commit de dos fases garantiza que. Debe emitirse un commit final hasta que todos los sitios hayan completado su parte de la transacción. todos los cambios completados en los otros sitios que participan en la transacción serán deshechos para mantener el estado consistente de la BDD. se escriba antes que el fragmento de la BD se actualice en realidad. Cada DP mantiene su propio registro de transacción.Control de concurrencia en BDD Las BDD hacen posible que una transacción accese datos en varios sitios. El protocolo commit de dos fases requiere de dos protocolos: • DO-UNDO-REDO • Escritura anticipada . El protocolo commit de dos fases requiere que cada ingreso de registro del DP. si una parte de la operación de la transacción no puede completarse .

Control de concurrencia en BDD El protocolo DO-UNDO-REDO es utilizado por el procesador de datos para terminar y/o abortar las transacciones con la ayuda de los ingresos de registro de transacciones del sistema (cada acción genera un registro log). Estado inicial DO Estado final Log •UNDO revoca una operación. Log Estado final UNDO Estado inicial . mediante los ingresos registrados (escritos) por la parte “DO” de la secuencia. Este protocolo define tres tipos de operaciones: • DO realiza la operación y registra los valores “antes” y “después” en el registro de transacciones.

Control de concurrencia en BDD REDO rehace una operación. . mediante los ingresos registrados por la parte “DO” de la secuencia. Log Estado inicial REDO Estado final El protocolo de escritura anticipada hace que el ingreso registrado se escriba en un almacenamiento permanente antes que la operación en si ocurra.

.Control de concurrencia en BDD El protocolo commit de dos fases define las operaciones entre dos tipos de nodos: • • El coordinador y. Los subordinados reciben el mensaje. El coordinador envía un mensaje de PREPARED TO COMMIT a todos los subordinados. 3. Uno o mas subordinados Fases del protocolo commit Fase 1: preparación 1. 2. escriben el registro de transacciones mediante el protocolo de escritura anticipada y envían un mensaje de confirmación YES/PREPARED TO COMMIT O NO/NOT PREPARED al coordinador El coordinador se asegura de que todos los nodos estén listos para “completar” o “abortar” la acción.

Si uno o más subordinados no cumplen. 2. con lo cual obliga a deshacer todos los cambios. El coordinador envía un mensaje commit a todos los subordinados y espera las respuestas. el coordinador envía un mensaje abort.Control de concurrencia en BDD Fase 2: el commit final 1. luego actualiza la BD mediante el protocolo “DO”. . 3. Cada subordinado recibe un mensaje commit. Los subordinados contestan con un mensaje commited o no commited al coordinador.

una después de otra. esto puede afectar grandemente el desempeño de un DDBMS dado que el nivel de concurrencia se reduce al mínimo. Si las transacciones son internamente consistentes. Sin embargo. .Control de concurrencia distribuido El control de concurrencia trata con los problemas de aislamiento y consistencia del procesamiento de transacciones. El control de concurrencia distribuido de un DDBMS asegura que la consistencia de la base de datos se mantiene en un ambiente distribuido multiusuario. Por lo tanto. es probablemente el parámetro más importante en sistemas distribuidos. los mecanismos de control de concurrencia buscan encontrar un balance entre el mantenimiento de la consistencia de la base de datos y el mantenimiento de un alto nivel de concurrencia. el número de transacciones activas. El nivel de concurrencia. La manera más simple de lograr este objetivo es ejecutar cada transacción sola.

se pueden presentar dos anomalías: En primer lugar.Control de concurrencia en BDD Acceso concurrente a una región crítica Transacciones A B C Si no se hace un adecuado control de concurrencia. se pueden perder actualizaciones provocando que los efectos de algunas transacciones no se reflejen en la base de datos. En segundo término. . pueden presentarse recuperaciones de información inconsistentes.

Control de concurrencia en BDD El criterio de clasificación más común de los algoritmos de control de concurrencia es el tipo de primitiva de sincronización. . Aquellos algoritmos que están basados en acceso mutuamente exclusivo a datos compartidos (candados). Aquellos algoritmos que intentar ordenar la ejecución de las transacciones de acuerdo a un conjunto de reglas (protocolos) . 2. Esto resulta en dos clases: 1.

Como se aprecia en la tabla siguiente.Control de concurrencia en BDD Algoritmos basados en candados En los algoritmos basados en candados. las transacciones indican sus intenciones solicitando candados al despachador (llamado el administrador de candados). Los candados son de lectura (rl). dado que las operaciones de lectura y escritura son incompatibles. también llamados compartidos. o de escritura (wl). también llamados exclusivos. los candados de lectura presentan conflictos con los candados de escritura. rl rl wl si no wl no no .

. Si candado solicitado es incompatible con el candado con que el dato está bloqueado. El administrador de candados verifica si el elemento de datos que se quiere accesar ya ha sido bloqueado por un candado.Control de concurrencia en BDD En sistemas basados en candados. el despachador es un administrador de candados (LM). entonces. la transacción solicitante es retrasada. El administrador de transacciones le pasa al administrador de candados la operación sobre la base de datos (lectura o escritura) e información asociada. De otra forma. el candado se define sobre el dato en el modo deseado y la operación a la base de datos es transferida al procesador de datos. como por ejemplo el elemento de datos que es accesado y el identificador de la transacción que está enviando la operación a la base de datos. El administrador de transacciones es informado luego sobre el resultado de la operación.

2. El enfoque de abajo hacia arriba (bottom-up) . 1. DISEÑO Enfoques al problema de diseño de bases de datos distribuidas: Existen dos estrategias generales para abordar el problema de diseño de bases de datos distribuidas. El enfoque de arriba hacia abajo (top-down).BDD.

creando las imágenes físicas. 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. en cada sitio. Se prosigue con el diseño de la fragmentación de la base de datos. A partir de ellas se define un esquema conceptual global y los esquemas externos necesarios. que se localizan en éste. y de aquí se continúa con la localización de los fragmentos en los sitios.BDD. . Esta aproximación se completa ejecutando. DISEÑO 1. "el diseño físico" de los datos. El enfoque de arriba hacia abajo (top-down).

. . . Lo c al Data ba se Sitio n . . . . . . . . . . . . . . . .Bases de Datos DistribuidasArquitecturas • Integración lógica por medio de diseño top-down (DistDB) Global Schema Fragmentation Schema Allocation Schema Local Mapping Schema . . . . Local Mapping Schema DataBase Manager System DataBase Manager System Lo c al Data ba se Sitio 1 . .

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.Bases de Datos DistribuidasArquitecturas 2. Se utiliza particularmente a partir de bases de datos existentes. generando con esto bases de datos distribuidas. 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. . El diseño de abajo hacia arriba (bottom-up). Esto se debe a que es posible que se utilicen diferentes SMBD.

. . Itermediate Schema Translator Local Conceptual Schema Local Conceptual Schema Lo cal Database Sitio 1 . . . . . . . . . . . . . . . . . .Bases de Datos DistribuidasArquitecturas •Integración lógica por medio de bottom-up (Multidatabase) Global Schema Schema Integration Itermediate Schema Translator . . . . Lo cal Database Sitio n .

• -Fragmentation Schema: Traducción entre relaciones globales y fragmentos. Consiste de una definición de relaciones globales. • -Local Maping Schema: Traduce los fragmentos locales a los objetos que son manejados por el SMBD local .• -Global Schema: Define todos los datos que están incluidos en la bd distribuida tal como si la bd no fuera distribuida. (Una relación global puede consistir de varios fragmentos pero un fragmento está asociado con sólo una relación global) • -Allocation Schema: Define el sitio (o sitios) en el cual un fragmento está localizado.

por ejemplo. Por ejemplo. el uso completo de relaciones no favorece las cuestiones de eficiencia sobre todo aquellas relacionadas con el procesamiento de consultas. La otra posibilidad es usar fragmentos de relaciones (sub-relaciones) lo que favorece la ejecución concurrente de varias transacciones que accesan porciones diferentes de una relación. Sin embargo. Aunado a esto. Sin embargo. las vistas de usuario que no se pueden definir sobre un solo fragmento necesitarán un procesamiento adicional a fin de localizar todos los fragmentos de una vista. el manejo de llaves únicas requiere considerar todos los fragmentos en los que se distribuyen todos los registros de la relación . ¿cuál es la unidad razonable de distribución? Se puede considerar que una relación completa es lo adecuado ya que las vistas de usuario son subconjuntos de las relaciones. el control semántico de datos es mucho más complejo ya que.El problema de fragmentación El problema de la fragmentación se refiere al particionamiento de la información para distribuir cada parte a los diferentes sitios de la red. el uso de sub-relaciones también presenta inconvenientes.

y cada uno de los fragmentos tiene tuplas únicas (con los mismos atributos). Horizontal Es la división de una relación en subconjuntos (fragmentos) de tuplas.El problema de fragmentación El objetivo de la fragmentación es encontrar un nivel de particionamiento adecuado en el rango que va desde tuplas o atributos hasta relaciones completas. Cada segmento puede guardarse en cualquier sitio en una red de computadoras. . desde donde es accesada por el TP para procesar las solicitudes de los usuarios. tabla) en dos o mas segmentos o fragmentos. La información de la fragmentación se guarda en el catálogo de datos distribuidos (DDC). Cada fragmento se guarda en un nodo diferente. La fragmentación permite dividir un objeto (BD usuario. Tipos de fragmentación: 1.

Cada subconjunto (fragmento) se guarda en un nodo diferente y cada fragmento tiene columnas únicas. .El problema de fragmentación 2. Una tabla puede dividirse en varios subconjuntos horizontales (filas) y cada una tiene un subconjunto de los atributos. con la excepción de los atributos que forman la llave primaria 3. Vertical Es la división de una relación en subconjuntos de atributos. Mezclada o Mixta Es la combinación de las estrategias horizontal y vertical.

Si la relación R se descompone en los fragmentos R1. Condición de Reconstrucción.. R2.. entonces debe existir algún operador relacional  . Al realizar la fragmentación de una relación se deben satisfacer las siguientes condiciones para garantizar la correctitud de la misma: • Condición de completitud... y el dato di está en Rj. entonces.. no debe estar en ningún otro fragmento Rk (k j). Rn. La descomposición de una relación R en los fragmentos R1... R2. ... . Rn.El problema de fragmentación Correctitud de una fragmentación. R2. . . Rn es completa si y solamente si cada elemento de datos en R se encuentra en algún de los Ri. R =1<=i<=n Ri Condición de Fragmentos Disjuntos. Si la relación R se descompone en los fragmentos R1. tal que.

.El problema de fragmentación Para ilustrar las estrategias de fragmentación considere el esquema y la información de la tabla Clientes que se muestra en las siguientes figuras.

BDD fragmentación Fragmentación Horizontal Suponga que la gerencia general de la compañía requiere información de sus clientes de los tres estados. Los fragmentos que se requieren se definen a continuación. 12 11. VER. DF) solamente requieren datos con respecto a los clientes locales. pero las ubicaciones de las compañías en cada estado (PUE. Nom_fragm CUST_H1 CUST_H2 CUST_H3 Ubicación Puebla DF Veracruz Condición Estado = Pue Estado = DF Estado = Ver Nom_Nodo PUE DF VER Num_Cus 10. 14 15 Num_Reg 2 3 1 . 13.

BDD fragmentación Nombre del Fragmento = CUST_H1 Cus_Num 10 12 Cus_Nom López Aranda Dir 14 ote 11 norte Estado Pue Pue Limite 350000 400000 Balance 27000 35000 Adeudo 12450 34000 Nombre del Fragmento = CUST_H2 Cus_Num 11 13 14 Cus_Nom Gómez Méndez Merino Dir Perisur Revolución Zaragoza Estado DF DF DF Limite 600000 600000 120000 Balance 12000 58900 5500 Adeudo 0 10900 0 Nombre del Fragmento = CUST_H3 Cus_Num 15 Cus_Nom Reyes Dir Sur 10 Estado Ver Limite 200000 Balance 3500 Adeudo 500 .

Balance. La fragmentación se define como se ilustra a continuación. Límite. Suponga que la compañía está dividida en dos departamentos. Adeudo .BDD fragmentación Fragmentación vertical También puede dividirse la relación cliente en fragmentos verticales compuestos de un conjunto de atributos. Cada departamento está ubicado en un edificio distinto y cada uno tiene interés solamente en unos cuantos de los atributos de la tabla cliente. Nom_fragm CUST_V1 Ubicación Servicios Nom_Nodo SVC Nom_Atributo Cus_Num. el de servicio y el de colecciones. Dir. Estado CUST_V2 Colección COL Cus_Num. Cus_Nom.

BDD fragmentación Cus_Num 10 Cus_Nom López Dir 14 ote Estado Pue Nombre del Fragmento CUST_V1 11 12 13 14 Gómez Aranda Méndez Merino Reyes Perisur 11 norte Revolución Zaragoza Sur 10 DF Pue DF DF Ver Cus_Num 10 11 12 13 Limite 350000 600000 400000 600000 Balance 27000 12000 35000 58900 Adeudo 12450 0 34000 10900 15 Nombre del Fragmento CUST_V2 14 15 120000 200000 5500 3500 0 500 .

12 11. 12 10. Adeudo Cus_Num. Estado Cus_Num. Límite. Balance. Dir. Dir. 13. 14 15 15 Criterio_Ver Cus_Num. Balance. los datos deben ser fragmentados verticalmente para acomodar los diferentes departamentos (servicio y colección) Nom_fragm CUST_M1 CUST_M2 CUST_M3 CUST_M4 CUST_M5 CUST_M6 Ubicación PueServ PueCol DFServ DFCol VerServ VerCol Criterio_Hor Estado = Pue Estado = Pue Estado = DF Estado = DF Estado = Ver Estado = Ver Nom_Nodo PUE-S PUE-C DF-S DF-C VER-S VER-C Num_Cus 10. Límite. dentro de las ubicaciones. Adeudo . Cus_Nom.BDD fragmentación Fragmentación Mixta La estructura de la compañía requiere que los datos Cliente se fragmenten horizontalmente para acomodar las diferentes ubicaciones de la compañía. Cus_Nom. Balance. Cus_Nom. Adeudo Cus_Num. 13. 14 11. Dir. Estado Cus_Num. Límite. Estado Cus_Num.

BDD fragmentación Cus_Num Cus_Nom López Aranda Dir 14 ote 11 norte Estado Pue Pue Nombre del Fragmento = CUST_M1 10 12 Cus_Num Cus_Nom Gómez Méndez Merino Dir Perisur Revolución Zaragoza Estado DF DF DF Nombre del Fragmento = CUST_M3 11 13 14 Nombre del Fragmento = CUST_M5 Cus_Num 15 Cus_Nom Reyes Dir Sur 10 Estado Ver .

BDD fragmentación Cus_Num Limite 350000 400000 Balance 27000 35000 Adeudo 12450 34000 Nombre del Fragmento = CUST_M2 10 12 Cus_Num Limite 600000 600000 120000 Balance 12000 58900 5500 Adeudo 0 10900 0 Nombre del Fragmento = CUST_M4 11 13 14 Nombre del Fragmento = CUST_M6 Cus_Num 15 Limite 200000 Balance 3500 Adeudo 500 .

BDD CASO PRÁCTICO La Universidad Carlos III tiene en la actualidad tres campos distribuidos en las siguientes poblaciones de la comunidad de Madrid: Getafe. para manejar de forma autónoma información sobre las titulaciones ofertadas. En este departamento también se desea guardar información de los profesores (nombre. El departamento de gestión de nómina y contratación de profesores se mantendrá en Getafe. En cada uno de los campus se requiere crear un departamento para la gestión de las distintas titulaciones impartidas en ese campus. . actualmente centralizada en Gatefe. e-mail y número de despacho) que imparten clases en cada uno de los campus. además de manejar los datos acerca de los cursos de los que consta cada uno de ellos y los grupos que forman parte de estos cursos. Leganés y Colmenarejo. Esta ampliación ha repercutido en los sistemas informáticos de esta Universidad llevándose a cabo el tendido de una red para unir los tres campus y ahora se maneja la posibilidad de diseñar una base de datos distribuida.

BDD CASO PRÁCTICO Titulación CodTitulacion Nombre Creditos Nota_Minima Campus Curso CodTit Curso Max_Alumnos Clasificacion Categoria NoHorasMaximo Salario Grupo CodGrupo CodTit Curso Asignatura CodAsignatura NombreAsignatura CodTit CodCurso HorasSemana Turno Profesor CodProfesor Nombre Direccion Categoria Telefono E-Mail Despacho Impartir CodAsignatura CodProfesor NumeroHoras Esquema relacional BD centralizada para la gestión de la Universidad .

Colmenarejo} . Leganés. Colmenarejo} Grupoi= Grupo CodTitulacion. Leganés. donde i ={Getafe. por lo que tenemos que realizar una fragmentación horizontal en las relaciones Curso y Grupo. Curso Cursoi. Titulacioni=campus=i Titulacion.BDD CASO PRÁCTICO Esquena de fragmentación Como se quiere que en cada campus se maneje la información de las titulaciones que allí se imparten tendremos que aplicar una fragmentación horizontal en la relación Titulación. donde i ={Getafe. Cursoi= Curso CodTitulacionTitulacioni. Colmenarejo} Para tener la información completa sobre las titulaciones de cada campus necesitamos saber qué cursos se imparten y los grupos formados por cada curso. donde i ={Getafe. Leganés.

donde i ={Getafe. Impartiri= Impartir Codasignatura Asignaturai. . primero realizamos una fragmentación vertical para quedarnos con la información que nos interesa. Colmenarejo} Para saber los profesores que dan clases en los distintos campus realizamos otra fragmentación derivada con los fragmentos de las asignaturas. CursoCursoi. Leganés. Colmenarejo} Recuarde: el departamento de gestión de nóminas y contratación de profesorado se mantendrá en Getafe.BDD CASO PRÁCTICO Asignamos las asignaturas impartidas en las distintas titulaciones a los campus correspondientes realizando una fragmentación horizontal derivada con los fragmentos del Cursoi. donde i ={Getafe. Asignaturai= Asignatura CodTitulacion. Como sólo necesitamos algunos datos acerca de los profesores que imparten asignaturas en las titulaciones de cada campus. Leganés.

Nombre.BDD CASO PRÁCTICO Inf_Profesor: ∏CodProfesor.Nombre. donde i ={Getafe. Colmenarejo} . Despacho(Profesor) Nomina_Profesor: ∏CodProfesor. Leganés.Direccion. Telefono. Categoria(Profesor) Para luego realizar una fragmentación horizontal derivada y de esta forma obtener fragmentos con los atributos de los profesores necesarios en cada uno de los campus.E-Mail. Inf_Profi= Inf_Profesor CodProfesorImpartiri.

por lo que se puede duplicar en todas los nodos .BDD CASO PRÁCTICO Esquema de asignación Tabla/ Nodo Titulacion Curso Grupo Getafe Titulacion_Getafe Curso_Getafe Grupo_Getafe Asignatura_Getafe Impartir_Getafe Nomina_Profesor Clasificacion Inf_Profesor_Getafe Colmenarejo TitulacIon_Colmanerejo Curso_Colmanerejo Grupo_Colmanerejo Asignatura_Colmanerejo Leganés Tutulacion_Leganés Curso_Leganés Grupo_Leganés Asignatura_Leganés Impartir_Leganés Asignatura Impartir Profesor Clasificacion Inf_Profesor Impartir_Colmanerejo Clasificacion Inf_Profesor_Colmanerejo Clasificacion Inf_Profesor_Leganés La tabla clasificación tendrá pocas actualizaciones.

Condición indicará que condiciones hemos utilizado en los operadores de algebra relacional para generar el fragmento y replicado que tomará S o N. Tabla Titulacion Curso Profesor Inf_Profesor Profesor Fragmento Titulacion_Getafe Curso_Getafe Inf_Profesor Inf_ProfesoGetafe Nomina_Profesor Getafe Getafe Sede Getafe Getafe Tipo H HD V HD V Condicion Campus=“Getafe” CodTitulacion=Titulacion_Get afe. . Nombre del fragmento.CodigoTitulacion Replicado No No No No No Atributos selecciono CodProfesor=cvePro fesor Atributos selecciono Para los demás fragmentos. HD horizontal derivada). Sede. Tipo (H orizontal V ertical. la información guardada en el diccionario global sería análoga.BDD CASO PRÁCTICO Contenido del diccionario La información sobre los fragmentos se guardará en una relación que contiene los siguientes campos: Nombre de la tabla base.

esto quiere decir que cuando hay una actualización de la base de datos se realiza en todos los sitios donde hay réplicas. – Los datos replicados se someten a la regla de consistencia mutua. finalmente estas copias reducen los costos de comunicación y de consulta totales. además de mejorar la disponibilidad de los datos y el tiempo respuesta.BDD Replicación – Se refiere al almacenamiento de copias de datos en sitios múltiples. también exige más complejidad de procesamiento del DDBMS cada copia de datos debe ser mantenida por el sistema. . puede ser para satisfacer requerimientos de información. – Aunque se tiene beneficios. la cual requiere que todas las copias de fragmentos de datos sean idénticas.

.BDD Replicación • De esta forma. 2. El procesador de transacciones envía una solicitud de datos a cada procesador de datos para su ejecución. El procesador de datos recibe y ejecuta cada solicitud y envía los datos de vuelta al procesador de transacciones 3. El procesador de transacciones arma las respuestas del procesador de datos. una operación READ (lectura) selecciona la copia más cercana para satisfacer la transacción. • Una operación WRITE (escritura) requiere que todas las copias se seleccionen y actualicen. 1.

Se tiene un buen manejo – Base de datos no replicada.BDD Replicación • Existen tres escenarios de replicación: – Base de datos totalmente replicada. guarda múltiples copias de algunos fragmentos de la base de datos en múltiples sitios. – Base de datos parcialmente replicada. No es práctica debido la cantidad de carga impuesta al sistema. guarda varias copias de cada fragmento de la base de datos en varios sitios. guarda cada fragmento de base de datos en un solo sitio. .

¿Qué es confiabilidad? •Se refiere a la precisión con la que una aplicación proporciona. .DDBMS Confiabilidad Un sistema de manejo de bases de datos confiable es aquel que puede continuar procesando las solicitudes de usuario aún cuando el sistema sobre el que opera no es confiable. aún cuando los componentes de un sistema distribuido fallen. un DDMBS confiable debe seguir ejecutando las solicitudes de usuario sin violar la consistencia de la base de datos. •También se puede interpretar como la probabilidad de que un sistema no haya experimentado ninguna falla dentro de un periodo de tiempo dado La confiabilidad se utiliza típicamente como un criterio para describir sistemas que no pueden ser reparados o donde la operación continua del sistema es crítica. • La confiabilidad se puede ver como una medida con la cual un sistema conforma su comportamiento a alguna especificación. En otras palabras. sin errores. los servicios que se establecieron en las especificaciones originales.

En este tipo de fallas se asume que el contenido de la memoria principal se pierde. los tipos de fallas que pueden ocurrir en un SMBD distribuido son: 1. Típicamente. se hace diferencia entre las fallas parciales y fallas totales del nodo. Fallas del sistema. Una falla total se presenta en todos los nodos del sistema distribuido. Así. Experimentalmente. Fallas de transacciones Las fallas en transacciones se pueden deber a un error debido a datos de entrada incorrectos así como a la detección de un interbloqueo. 2. se ha determinado que el 3% de las transacciones abortan de manera anormal. pero el contenido del almacenamiento secundario es seguro. Una falla parcial se presenta solo en algunos nodos del sistema. En un sistema distribuido se pueden presentar fallas en el procesador.DDBMS Confiabilidad Diseñar un sistema confiable que se pueda recuperar de fallas requiere identificar los tipos de fallas con las cuales el sistema tiene que tratar. La forma usual de enfrentar las fallas en transacciones es abortarlas. . la memoria principal o la fuente de energía de un nodo.

o del disco mismo. 4. Fallas del medio de almacenamiento Se refieren a las fallas que se pueden presentar en los dispositivos de almacenamiento secundario que almacenan las bases de datos. Esas fallas se pueden presentar por errores del sistema operativo. por errores del controlador del disco. Fallas de comunicación Las fallas de comunicación en un sistema distribuido son frecuentes. . Estas se pueden manifestar como pérdida de mensajes lo que lleva en un caso extremo a dividir la red en varias subredes separadas.DDBMS Confiabilidad 3.

el coordinador envía mensajes global-commit o globalabort de manera repetida a todos los nodos que no han respondido y espera por su reconocimiento. El coordinador está esperando por las decisiones locales de los participantes. escribe un comando abort en el registro de la base de datos y envía un mensaje global-abort a todos los participantes. etc. Sin embargo. él puede decidir abortar globalmente la transacción. Timeout en los estados COMMIT o ABORT. El coordinador no puede de manera unilateral realizar un commit.DDBMS Confiabilidad Fallas de nodos En una red puede haber muchas fallas de comunicación debido a colisiones. comunicación intermitente por interferencia. En este caso el coordinador no esta seguro que los procedimientos de commit o abort se han terminado en todos los nodos participantes. sobrecarga de trabajo. . La única forma de suponer que existe una falla de nodo es cuando después de un cierto periodo de tiempo (timeout) no se obtiene respuesta del mismo Timeouts del coordinador Timeout en el estado WAIT. En este caso. Así.

Así permanecerá bloqueado hasta que pueda conocer de alguien. esto se puede manejar de dos formas. 2. Si el mensaje prepare llega en un tiempo posterior al participante. No se puede de manera unilateral ni hacer un commit ni hacer un abort. El coordinador pudo haber fallado en el estado INITIAL por lo que el participante puede abortar de manera unilateral la transacción. En este estado el participante está esperando por un mensaje prepare. Puede responder con un vote-abort o simplemente ignorar el mensaje y dejar que ocurra el timeout en el lado del coordinador. Timeout en el estado INITIAL. Timeout en el estado READY. En este estado el participante ha votado por realizar un commit pero desconoce la decisión global del coordinador. . cual fue la decisión final sobre la transacción.DDBMS Confiabilidad Timeout de los participantes 1. el coordinador u otro participante.

DDBMS Confiabilidad Diagrama de transición .

haciendo uso de fragmentación vertical. Consultas Nom. SMBDD Propio 1.tabla distribuida :_______ Fragmento ----------Base Datos -----------Criterio ----------Atributos ---------------------- Transacciones Insert into Empleados values() Update From Empleados set vig=„a‟ where zona=„1‟ . Transacciones 3.Proyecto de BDD: elaborar un software que no permita simular el funcionamiento de un SMBDD. Fragmentos 2.