#21 Protocolos REDO/UNDO y el protocolo 2PC de confiabilidad distribuida

Protocolos REDO/UNDO.
El registro de la base de datos contiene información que es utilizada por el proceso de recuperación para restablecer la base de datos a un estado consistente. Esta información puede incluir entre otras cosas:
el identificador de la transacción,
el tipo de operación realizada,
los datos accesados por la transacción para realizar la acción,
el valor anterior del dato (imagen anterior), y
el valor nuevo del dato (imagen nueva).
Considere el escenario mostrado en la Figura de abajo. El DBMS inicia la ejecución en el tiempo 0 y en el tiempo t se presenta una falla del sistema. Durante el periodo [0, t] ocurren dos transacciones, T1 y T2. T1 ha sido concluida (ha realizado su commit) pero T2 no pudo ser concluida.
La propiedad de durabilidad requiere que los efectos de T1 sean reflejados en la base de datos estable. De forma similar, la propiedad de atomicidad requiere que la base de datos estable no contenga alguno de los efectos de T2.

Ejemplo de una falla del sistema.
A pesar que T1 haya sido terminada, puede suceder que el buffer correspondiente a la página de la base de datos modificada no haya sido escrito a la base de datos estable. Así, para este caso la recuperación tiene que volver a realizar los cambios hechos por T1. A esta operación se le conoce como REDO y se presenta en la Figura de abajo.
La operación de REDO utiliza la información del registro de la base de datos y realiza de nuevo las acciones que pudieron haber sido realizadas antes de la falla. La operación REDO genera una nueva imagen.


Operación REDO.
Por otra parte, es posible que el administrador del buffer haya realizado la escritura en la base de datos estable de algunas de las páginas de la base de datos volátil correspondientes a la transacción T2.
Así, la información de recuperación debe incluir datos suficientes para permitir deshacer ciertas actualizaciones en el nuevo estado de la base de datos y regrasarla al estado anterior. A esta operación se le conoce como UNDO y se muestra en la Figura de abajo. La operación UNDO restablece un dato a su imagen anterior utilizando la información del registro de la base de datos.



Operación UNDO.
De forma similar a la base de datos volátil, el registro de la base de datos se mantiene en memoria principal (llamada los buffers de registro) y se escribe al almacenamiento estable (llamadoregistro estable). Las páginas de registro se pueden escribir en el registro estable de dos formas: síncrona o asíncrona. En forma síncrona, también llamada un registro forzado, la adición de cada dato en el registro requiere que la página del registro correspondiente se mueva al almacenamiento estable. De manera asíncrona, las páginas del registro se mueven en forma periódica o cuando los buffers se llenan.

Protocolo 2PC de confiabilidad distribuida.
El protocolo 2PC básico un agente (un agente-DTM en el modelo) con un rol especial. Este es llamado el coordinador; todos los demás agentes que deben hacer commit a la vez son llamados participantes.
El coordinador es responsable de tomar la decisión de llevar a cabo un commit o abort finalmente. Cada participante corresponde a una subtransacción la cual ha realizado alguna acción de escritura en su base de datos local.
Se puede asumir que cada participante está en un sitio diferente. Aun si un participante y el coordinador se encuentran en el mismo sitio, se sigue el protocolo como si estuvieran en distintos sitios.
La idea básica del 2PC es determinar una decisión única para todos los participantes con respecto a hacer commit o abort en todas las subtransacciones locales.
El protocolo consiste en dos fases:

• La primera fase tiene como objetivo alcanzar una decisión común,
• La meta de la segunda fase es implementar esta decisión.

El protocolo procede como sigue:
Fase uno:
• El coordinador escribe “prepare” en la bitácora y envía un mensaje donde pregunta a todos los participantes si preparan el commit (PREPARE).
• Cada participante escribe “ready” (y registra las subtransacciones) en su propia bitácora si está listo o “abort” de lo contrario.
• Cada participante responde con un mensaje READY o ABORT al coordinador.
• El coordinador decide el commit o abort en la transacción como un resultado de las respuestas que ha recibido de los participantes. Si todos respondieron READY, decide hacer un commit. Si alguno ha respondido ABORT o no ha respondido en un intervalo de tiempo determinado se aborta la transacción.
Fase dos:
• El coordinador registra la decisión tomada en almacenamiento estable; es decir, escribe “global_commit” o “global_abort” en la bitácora.
• El coordinador envía mensaje de COMMIT o ABORT según sea el caso para su ejecución.
• Todos los participantes escriben un commit o abort en la bitácora basados en el mensaje recibido del coordinador (desde este momento el procedimiento de recuperación es capaz de asegurar que el efecto de la subtransacción no será perdido).
Finalmente:

• Todos los participantes envían un mensaje de acuse de recibo (ACK) al coordinador, y ejecutan las acciones requeridas para terminar (commit) o abortar (abort) la subtransacción.
• Cuando el coordinador ha recibido un mensaje ACK de todos los participantes, escribe un nuevo tipo de registro en la bitácora, llamado un registro “completo”.

#20 Conceptos básicos de confiabilidad

#19 Disciplinas del Interbloqueo

#18 Algoritmos de control de concurrencia

Basados en Bloqueos
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), también llamados compartidos, o de escritura (wl), también llamados exclusivos. Como se aprecia en la tabla siguiente, los candados de lectura presentan conflictos con los candados de escritura, dado que las operaciones de lectura y escritura son incompatibles.

En sistemas basados en candados, el despachador es un administrador de candados (LM). 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, 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 candados verifica si el elemento de datos que se quiere accesar ya ha sido bloqueado por un candado. Si candado solicitado es incompatible con el candado con que el dato está bloqueado, entonces, la transacción solicitante es retrasada. 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. El administrador de transacciones es informado luego sobre el resultado de la operación. La terminación de una transacción libera todos los candados y se puede iniciar otra transacción que estaba esperando el acceso al mismo dato.


Basados en estampas de tiempo
A diferencia de los algoritmos basados en candados, los algoritmos basados en estampas de tiempo no pretenden mantener la seriabilidad por exclusión mutua. En lugar de eso, ellos seleccionan un orden de serialización a priori y ejecutan las transacciones de acuerdo a ellas. Para establecer este ordenamiento, el administrador de transacciones le asigna a cada transacción Ti una estampa de tiempo única ts (Ti ) cuando ésta inicia. Una estampa de tiempo es un identificador simple que sirve para identificar cada transacción de manera única. Otra propiedad de las estampas de tiempo es la monoticidad , esto es, dos estampas de tiempo generadas por el mismo administrador de transacciones deben ser monotonicamente crecientes. Así, las estampas de tiempo son valores derivados de un dominio totalmente ordenado.
Existen varias formas en que las estampas de tiempo se pueden asignar. Un método es usar un contador global monotonicamente creciente. Sin embargo, el mantenimiento de contadores globales es un problema en sistemas distribuidos. Por lo tanto, es preferible que cada nodo asigne de manera autónoma las estampas de tiempos basándose en un contador local. Para obtener la unicidad, cada nodo le agrega al contador su propio identificador. Así, la estampa de tiempo es un par de la forma


<contador local ,identificador de nodo >


Note que el identificador de nodo se agrega en la posición menos significativa, de manera que, éste sirve solo en el caso en que dos nodos diferentes le asignen el mismo contador local a dos transacciones diferentes. El administrador de transacciones asigna también una estampa de tiempo a todas las operaciones solicitadas por una transacción. Más aún, a cada elemento de datos x se le asigna una estampa de tiempo de escritura, wts (x ), y una estampa de tiempo de lectura ,rts (x ); sus valores indican la estampa de tiempo más grande para cualquier lectura y escritura de x , respectivamente.












Pruebas de validación optimistas

#17 Niveles de aislamineto, COMMIT y ROLLBACK

https://onedrive.live.com/?cid=2B362BDAC7D792D5&id=2B362BDAC7D792D5%21644
Niveles de aislamiento

#17 Los mecanismos de control de transacciones para una BDD

Una transacción de una sola instancia de Motor de base de datos que abarque dos o más bases de datos es, de hecho, una transacción distribuida. La instancia administra la transacción distribuida internamente; para el usuario funciona como una transacción local.

En la aplicación, una transacción distribuida se administra de forma muy parecida a una transacción local. Al final de la transacción, la aplicación pide que se confirme o se revierta la transacción. El administrador de transacciones debe administrar una confirmación distribuida de forma diferente para reducir al mínimo el riesgo de que, si se produce un error en la red, algunos administradores de recursos realicen confirmaciones mientras los demás revierten la transacción. Esto se consigue mediante la administración del proceso de confirmación en dos fases (la fase de preparación y la fase de confirmación), que se conoce como confirmación en dos fases (2PC).

Fase de preparación
Cuando el administrador de transacciones recibe una solicitud de confirmación, envía un comando de preparación a todos los administradores de recursos implicados en la transacción. Cada administrador de recursos hace lo necesario para que la transacción sea duradera y todos los búferes que contienen imágenes del registro de la transacción se pasan a disco. A medida que cada administrador de recursos completa la fase de preparación, notifica si la preparación ha tenido éxito o no al administrador de transacciones.

Fase de confirmación
Si el administrador de transacciones recibe la notificación de que todas las preparaciones son correctas por parte de todos los administradores de recursos, envía comandos de confirmación a cada administrador de recursos. A continuación, los administradores de recursos pueden completar la confirmación. Si todos los administradores de recursos indican que la confirmación ha sido correcta, el administrador de transacciones envía una notificación de éxito a la aplicación. Si algún administrador de recursos informó de un error al realizar la preparación, el administrador de transacciones envía un comando para revertir la transacción a cada administrador de recursos e indica a la aplicación que se ha producido un error de confirmación.

Requiere:
Existe un agente raíz que inicia toda la transacción, así que cuando el usuario requiere la ejecución de una aplicación distribuida el agente raíz es iniciado; el sitio del agente raíz es llamado el sitio origen de la transacción.
El agente raíz tiene la responsabilidad de asegurar BEGIN-TRANSACTION, COMMIT O ROLLBACK de toda la transacción distribuida.

Recuperación de transacciones distribuidas

• Para realizar la recuperación de transacción distribuidas se asume que cada sitio tiene su propio manejador de transacción local (LTM).
• Cada agente utiliza de manera local las primitivas asociadas a sus transacciones. Podemos llamar a los agentes subtransacciones, lo cual origina distinguir las primitivas BEGIN-TRANSACTION, COMMIT Y ROLLBACK asociado a la transacción distribuida de la primitivas locales utilizada por
• cada agente en LTM; para poder distinguir una de las otras, a las ultimas les llamaremos:
• LOCAL-BEGIN, LOCAL-COMMIT Y LOCALROLLBACK.
• Para propósito del manejador de transacciones distribuidas (DTM), requieren que los LTM se conformen de la siguiente manera:

1. Asegurar la atomicidad de su transacción.
2. Grabar en bitácora por ordenes de la transacción distribuida.

Para asegurar que todas las acciones de una transacción distribuida son ejecutadas o no ejecutadas dos condiciones son necesarias:

• En cada sitio todas las acciones son ejecutadas o ninguna es ejecutada.
• Todos los sitios deberán tomar la misma decisión respecto al COMMIT o ROLLBACK de la transición global.

Estados de una transacción

• Activa: Durante su ejecución Ficheros y bases de datos
• Parcialmente comprometida: Después de ejecutar su última instrucción.
• Fallida: Imposible de continuar su ejecución normal.
• Abortada: Transacción retrocedida y base de datos restaurada al estado anterior a su
ejecución. Se puede reiniciar o cancelar.

Diagrama de estados de una transacción:

Actividad #16 Investigar estrategias de procesamiento de consulta distribuida y optimización de consultas distribuidas.

Las consultas distribuidas tienen acceso a datos de varios orígenes de datos heterogéneos.Estos orígenes de datos pueden estar almacenado en el mismo equipo o en equipos diferentes.

El procesamiento de consultas tiene varas etapas a seguir para resolver una consulta SQL. Las características del modelo relacional permiten que cada motor de BD elija su propia representación: Consulta Distribuida

Es preciso tener en cuenta otros factores como son:

• El costo de transmisión de datos en la red.
• Repetición y fragmentación.
• Procesamiento de intersección simple

OBJETIVOS DEL PROCESAMIENTO DE CONSULTAS
Los objetivos del procesamiento de consultas son transformar una consulta escrita en un lenguaje de alto nivel, normalmente SQL, en una estrategia de ejecución correcta y eficiente expresada en un lenguaje de bajo nivel, por ejemplo, el álgebra relacional, y ejecutar dicha estrategia para extraer los datos solicitados.

FASES DEL PROCESAMIENTO DE CONSULTAS

El procesamiento de consultas puede dividirse en cuatro fases principales:

• Descomposición.
• Optimización.
• Generación de código.
• Ejecución.

METODOLOGIA DE PROCESAMIENTO DE CONSULTAS DISTRIBUIDAS

Primeramente se debe de contar con heterogenidad de los datos, para que puedan ser usados para formular consultas. Tenemos los sigueintes ejemplos:

BD CENTRALIZADA

BD DISTRUIBUIDA

Asi como tambien necesitamos contar con:

-Localizacion de los datos para generar reglas heuristicas
-Descomposicion de consultas en paralelo en cada nodo
-Reducir la cantidad de datos a transferir en la red

  

ESTRATEGIAS DE PROCESAMIENTO DE CONSULTAS DE BASES DE DATOS DISTRIBUIDAS

Contamos con la estategia de Reformulacion de consultas, que nos sirve para encontrar q la informacion que nos va a proveer sea solo la que se le pidio por la fuente

Tambien se cuenta con la estrategia de descomposicion de las fuentes, q consiste en que segun las fuentes q pidan cierto tipo de datos sean las atentidas con mayor velocidad.

OPTIMIZACION DE CONSULTAS DISTRIBUIDAS

Para poder optimizar una consulta necesitamos tener claras las propiedades del algebra relacional para asegurar la reformulacion de la consulta, al optimizar una consulta obtenemos los siguientes beneficios:

• Minimizar costos
• Reducir espacios de comunicaciones
• Seguridad en envios de informacion

CONSULTA NO OPTIMIZADA

MEJORAR EL RENDIMIENTO DE QUERIES EN SQL SERVER

Uso de sintaxis UNION
Debemos tener en cuenta que por defecto un UNION equivale a realizar un SELECT DISTINCT sobre el resultado final de una query. En otras palabras, UNION toma los resultados de dos recordsets, los combina y realiza un SELECT DISTINCT de cara a eliminar las filas duplicadas. Este proceso ocurre incluso si no hay registros duplicados en el recordset final. Si sabemos que hay registros duplicados, y esto representa un problema para la aplicación, entonces haremos uso de UNION para eliminar estas filas duplicadas.

Por otro lado si sabemos que nunca habrá duplicado de filas o si las hay pero no representa un problema para la aplicación entonces deberemos usar UNION ALL en lugar de UNION. La ventaja de UNION ALL es que no realiza el SELECT DISTINCT, lo cual evita uns gran cantidad de trabajo y recursos al servidor SQL.


Mejorar rendimiento de UNION
Otro caso bastante común es el que se explica en el siguiente ejemplo, imaginemos que queremos realizar una query para mezclar dos conjuntos de datos:

SELECT column_name1, column_name2
FROM table_name1
WHERE column_name1 = some_value
UNION
SELECT column_name1, column_name2
FROM table_name1
WHERE column_name2 = some_value

La misma query puede ser reescrita como se explica a continuación para mejorar el rendimiento de la misma:

SELECT DISTINCT column_name1, column_name2
FROM table_name1
WHERE column_name1 = some_value OR column_name2 = some_value

Y puede mejorarse aún más si sabemos que la mezcla de estos dos grupos de datos a paesar de contener duplicados no afectan al funcionamiento de la aplicación eliminando el DISTINCT.


Evaluar el uso de DISTINCT
Un aspecto relativo al rendimiento es la evaluación del uso de la sentencia DISTINCT. Muchos desarrolladores aplican esta sentencia por defecto aunque no se necesite, Sólo debe usarse si sabemos que la query puede devolver duplicados, y además esto puede provocar un mal funcionamiento de la aplicación que hace uso de los datos.

La sentencia DISTINCT genera una gran cantidad de trabajo extra a SQL Server debido a que consume muchos recursos que son necesarios para otras queries que sean lanzadas dentro de la base de datos. Sólo se debe usar si es necesario.


Devolver los datos que se necesitan
Un aspecto que siempre se menciona en todos los libros de SQL es que debemos devolver nada más que los datos que se necesitan, y esto sobre todo referido a las columnas de datos. Debemos evitar el uso de SELECT * ya que esto además de devolver más datos de los que seguramente necesitemos, impide el uso de índices, añadiendo mayor degradación al rendimiento del sistema.


Uso de operadores en el WHERE
Otro aspecto importante de cara a mejorar el rendimiento de las queries, es tener en consideración que operadores dentro de la clausula WHERE tienen mejor rendimiento, a continuación se detalla una lista ordenada de mejor a peor rendimiento:

• =
• >, >=, <, <=
• LIKE
• <>

Además de esto, existen otros criterios que son también importantes a la hora de elaborar la condición de cualquier Query. Estas consideraciones son relativas a que ciertos operadores pueden prestarse a tener mejor rendimiento según se usen, a continuación detallamos estos casos, ordenados de mayor a peor rendimiento:

• Un literal único en lugar de varios usado al lado de un operador
• Un nombre de columna o de parámetro al lado de un operador
• Una expresión multi-operando al lado de un operador
• Un número único exacto al lado de un operador
• Un número único no exacto al lado de un operador (date, time)
• Datos de caracteres, Null

En el caso de haber varias expresiones dentro del WHERE, no se agiliza el rendimiento por ordenarlos, excepto en algunos casos.


Forzado de INDICES
Es posible que podamos encontrarnos TABLE SCAN en las queries que lanzemos, a pesar de existir INDICES que mejorarían el rendimiento. En estos casos la mejor opción para forzar el uso de un INDICE es realizar los siguiente, como muestra el ejemplo:

SELECT * FROM tblTaskProcesses WHERE nextprocess = 1 AND processid IN (8,32,45)

Esto tarda 3 segundos y al siguiente QUERY tarda menos de un segundo:

SELECT * FROM tblTaskProcesses (INDEX = IX_ProcessID) WHERE nextprocess = 1 AND processid IN (8,32,45)


Concatenación ANDs
Si existe una cláusula WHERE que incluye expresiones conectadas por dos o más operadores AND, SQL Server evaluará desde la izquierda hacia la derecha en el orden que hayan sido escritas. Esto asume que no se hayan usado paréntesis para cambiar el orden de la ejecución. Por esta razón se debe considerar lo siguiente cuando usemos el operador AND:

• Localizaremos la expresión menos probable de suceder y la pondremos en primer lugar de la expresión AND. De este modo si una expresión AND es falsa la cláusula finalizará inmediatamente ahorrando tiempo
• Si ambas partes de una expresión AND son iguales o tienen igual peso, y son falsas, pondremos la menos compleja primero. De este modo si es falsa la expresión se realizará menos trabajo para evaluar la expresión.

http://es.slideshare.net/JosMendoza1/estrategias-de-procesamiento-de-consultas-distribuidas

http://es.slideshare.net/rapaluzji/procesamiento-de-consultas-528026?related=1
http://blogs.msdn.com/b/apinedo/archive/2007/01/24/mejorar-el-rendimiento-de-queries-en-sql-server.aspx

Optimizacion de consultas

Optimizacion de consultas

Es el proceso de selección del plan de evalucion de las consultas mas eficientes dentre las muchas estrategias generalmente disponibles para el procesamiento de una consulta dada, especialmente si la consulta es compleja.

Importancia

Crear un plan de evaluacion de consultas que minimice el costo de la evaluacion de consultas a traves de la optimizacion de la misma.

Rendimiento de una BD

• Costo
• Tamaño
• Velocidad
• Potencia

Transferencias equivalentes

Principio de optimización 

Se basa en la eleccion de los planes de evaluación.
Un plan de evaluacion es la estrategia a seguir para la implementacion deuna consulta.

Tipos de Optimizacion 
Basado en Costo:

• Minimizacion de costos operativos

Optimizacion Heuristica:

• Basada en la experiencia
• Tomando en cuenta las equivalencias

Actividad #15 Presentación

Estrategias de procesamiento de consultas distribuidas
https://onedrive.live.com/?cid=2B362BDAC7D792D5&id=2B362BDAC7D792D5%21644

Actividad #14 Esquema de Fragmentacion y Distribucion

https://onedrive.live.com/?cid=2B362BDAC7D792D5&id=2B362BDAC7D792D5!644

Ejercicios

Resumen Documento 2

Se considera una BDD (base de datos distribuida) a “una colección lógicamente
interrelacionada de datos compartidos (junto con una descripción de estos datos)
fisicamente distribuidas por una red informática”, [CONOLLY  2005].


Se considera un SGBDD (sistema gestor de  base de datos distribuido) a un “sistema
software que permite gestionar la base de datos distribuida y hace que dicha distribución
sea transparente para los usuarios”, [CONOLLY 2005].


Se habla de replicación, que consiste en mantener réplicas de fragmentos  en varios nodos, según una política de replicación que va desde una replicación mínima (un fragmento replicado en otro nodo)
a una replicación total (todos los fragmentos son replicados).



El factor más importante que diferencia a  unos SGBDD de otros es la transparencia.
Esto supone que no se requiere soporte para la manipulación de datos (transparente para
el usuario) pero si se requieren operaciones de definición de datos (FRAGMENT,
REPLICATE).


Desde el punto de vista académico los dos tipos de software conocidos son:
•  Microsoft Access, con un SGBD muy sencillo porque da soporte a una base de
datos de oficina muy poco sofisticada. No proporciona funcionalidad de BDD,
pero se pueden implementar módulos que simulen la fragmentación, replicación
y consultas distribuidas. Sin embargo, no se garantiza la fiabilidad del SGBDD
desarrollado.
•  MySQL, no proporciona actualmente soporte alguno para los BDD verdaderos.
•  Oracle9i, (KOCH, G., 2003); no ofrece utilidades para fragmentar, replicar y
realizar consultas optimizadas, pero se  la ha elegido como plataforma para
desarrollar la transparencia debido a sus prestaciones como SGBD.

 El catálogo en una base de datos
centralizada proporciona la información relativa a las relaciones, vistas e índices se
almacena en un CATALOGO o DICCIONARIO DE DATOS.


En una base de datos distribuida el catálogo se usa también para hacer un seguimiento de los datos distribuidos en varios sitios. Ese seguimiento debe tener en cuenta cómo han sido fragmentadas y replicadas
las relaciones.

Resumen Documento 1

Conceptos de BDD

• Sistema de computación distribuido: elementos de procesamiento que cooperan en la ejecución de tareas,
interconectados por una red de ordenadores.

• BD distribuida (BDD): son varias BD interrelacionadas  lógicamente y situadas en diferentes nodos de una red de ordenadores.
• SGBD distribuido: el que gestiona BD distribuidas de forma transparente para el usuario (éste ve las BD como si fueran una sola BD centralizada)


 Otras funciones de las BDD:
– Seguir la pista a los datos: fragmentación, réplica
– Procesar consultas distribuidas
– Gestionar transacciones distribuidas
– Gestionar datos replicados: qué copia usar, mantener la consistencia
– Recuperar BDD: de fallos de ordenadores individuales
– Seguridad: privilegios, autorizaciones de acceso
– Gestionar el catálogo distribuido: contiene los metadatos. Debe ser global para toda la BDD o local para cada sitio.

Diseño de la BD "Empresa"

Estado de la BD "Empresa"

Diseño de BDD: fragmentación

• Directorio (catálogo) global: contiene la información de fragmentación. Lo utiliza el SBDD.

• Fragmentar: decidir dónde situar las partes de la BDD

– Se puede plantear top-down (como aquí) o bottom-up

• Idea simple: situar cada tabla en un ordenador distinto

• Fragmentación horizontal:

– Ejemplo: un ordenador por departamento. Cada departamento quiere tener su información en su ordenador. (BD Empresa)

– Supone dividir las tuplas de cada tabla en 3 trozos.

Cada trozo en el ordenador de su departamento.

– Así, EMPLEADO se divide en: σND=1, σND=4 y σND=5

– La tabla original se reconstruye con UNIÓN de los 3 trozos.

– Es posible generar fragmentos que compartan tuplas (no disjuntos)

• Fragmentación horizontal derivada: la partición de la tabla primaria DEPARTAMENTO se aplica a tablas secundarias, como EMPLEADO, que la referencian mediante una clave extranjera (ND)

• Fragmentación vertical:

– De EMPLEADO en información personal y laboral:

• πNOMBRE, INIC, APELLIDO, FECHA_NCTO, DIRECCIÓN, SEXO

• πNSS, SALARIO, NSS_SUPERV, ND

– Esta división no es apropiada porque no se puede reconstruir la tabla original: es necesario añadir NSS a la primera división (clave primaria)

– Para reconstruir la tabla original se usa REUNIÓN EXTERNA COMPLETA (o UNIÓN EXTERNA). Con REUNIÓN simple, las tuplas de una relación que no se reúnen con ninguna tupla de la otra tabla no aparecen en el resultado.

– Podemos generar fragmentos que compartan otros atributos además de la clave (no disjuntos)

• Toda fragmentación debería ser completa:

– Horizontal: todas las tuplas están en algún fragmento

– Vertical: todo atributo está en algún fragmento

• Fragmentación mixta: cuando se aplica fragmentación vertical y horizontal sobre la misma tabla

• Esquema de fragmentación es un conjunto de fragmentos que:

– Fragmentación completa: todos los atributos y tuplas están en algún fragmento

– Permite reconstruir la BD original.

– Interesante (no necesario) que los fragmentos sean disjuntos

Diseño de BDD: replicación y asignación
• La replicación mejora la disponibilidad de los datos
• Caso extremo: tener una réplica de la BD completa en cada sitio (ordenador):
– Ventajas: mejora el rendimiento local y global además de la disponibilidad (con un sitio activo se
accede a toda la BD)
– Inconvenientes: actualizaciones más costosas (se deben realizar en todas las réplicas para mantener la coherencia). El control de concurrencia y recuperación es también más costoso.
• El otro extremo es no tener ninguna replicación (salvo las claves primarias en fragmentos verticales).
• Entre ambos extremos: replicación parcial. Hay muchasposibilidades.
• Esquema de replicación: describe qué se replica
• Asignación: dónde se sitúan los fragmentos y réplicas
– La elección del lugar y el grado de replicación depende de los objetivos de rendimiento y
disponibilidad. También del tipo de transacciones y su frecuencia.
– Encontrar una solución óptima o incluso una buena es un problema complejo

BDD y cliente-servidor:
arquitectura de 2 niveles
• Los SGBD totalmente distribuidos (transparentes) aun no son viables comercialmente
• En su lugar se han creado sistemas basados en cliente-servidor
• La forma habitual de dividir la funcionalidad del SGBD entre cliente y servidor ha sido la arquitectura de 2 niveles:
– Servidor (o servidor SQL): donde se sitúa el SGBD. Una BDD se situaría en varios servidores.
– Clientes:
• Envían consultas/actualizaciones a servidores
• Tienen interfaces SQL, de usuario y funciones de
interfaz del lenguaje de programación
• Consultan en el diccionario de datos la información sobre la distribución de la BD entre los servidores.
Tienen módulos que descomponen consultas globales en varias locales a cada servidor
• Interacción cliente-servidor (arquitectura de 2 niveles):
– El cliente analiza la consulta del usuario. La descompone en varias subconsultas y envía cada una a un servidor. (También puede hacerlo el usuario a mano)
– Cada servidor ejecuta su subconsulta y devuelve el resultado al cliente
– El cliente combina los resultados recibidos y muestra al usuario el resultado de su consulta.
• En este enfoque al servidor se le llama máquina back-end (o subyacente) y al cliente máquina
front-end (de la parte visible).
• Al servidor también se le llama servidor de transacciones y procesador de BD y al cliente procesador de aplicaciones

BDD y cliente-servidor:
arquitectura de 3 niveles
• Actualmente es más común utilizar una arquitectura en 3 niveles, sobre todo para aplicaciones web.
• Las 3 capas son:
– Cliente (Presentación):
• Es la interfaz (interfaces web, formularios, …)
• Suelen usar navegadores web y lenguajes como HTML, JavaScript, PERL, …
• Gestiona las entradas, salidas y la navegación con páginas web estáticas o, cuando accede a BD, con
páginas dinámicas (ASP, JSP, …)
– Servidor de aplicaciones (SA) (lógica de negocio):
• Incluye, por ejemplo, consultas basadas en datos introducidos por el usuario, o resultados de consultas a los que da formato y envía para su presentación
• Puede incluir otro tipo de funcionalidad como comprobaciones de seguridad o de la identidad
• Puede acceder a varias BD conectándose mediante ODBC, JDBC u otras técnicas
– Servidor de BD (SBD):
• Procesa consultas y actualizaciones solicitadas por la capa de aplicación
• Puede devolver los resultados en formato XML
• La división de funcionalidad entre las 3 capas puede variar.
• El servidor de aplicaciones (SA) también:
– Tiene acceso a diccionarios de datos para consultar
cómo se distribuyen las BDD entre los servidores de BD
(SBD)
– Puede incluir módulos para descomponer una consulta
en varias subconsultas locales a cada SBD
• La interacción entre SA y SBD puede ser así:
– El SA construye una consulta utilizando datos tomados
por el cliente. Descompone la consulta en varias
subconsultas, cada una de ellas local a un SBD, y las
envía a sus correspondientes SBD.
– Cada SBD procesa sus consultas y envía los resultados al
SA que las solicitó. Cada vez es más frecuente utilizar el
formato XML para devolver los resultados.
– El SA combina los resultados para obtener el resultado
de la consulta original. Dota al resultado de un formato,
como HTML y lo envía al cliente para su presentación.
• El SA es responsable de (en arquitectura de 2 niveles lo es el
cliente):
– Generar un plan de ejecución distribuido y supervisar su
ejecución.
– Garantizar la consistencia de las réplicas de datos.
– Asegurar la atomicidad de las transacciones globales
(que no se puedan ejecutar “a medias”, o sea que bien se ejecuta
toda la transacción o no se ejecuta nada)

Actividad #13 Sistemas gestores de bases de datos distribuidas existentes

Microsoft SQL Server es una plataforma de base de datos que se utiliza en el procesamiento de transacciones en línea a gran escala, el almacenamiento de datos y las aplicaciones de comercio electrónico; es también una plataforma de Business Intelligence para soluciones de integración, análisis y creación de informes de datos.

CARACTERÍSTICAS

·         Soporte de transacciones.
·         Escalabilidad, estabilidad y seguridad.
·         Soporta procedimientos almacenados.
·         Incluye también un potente entorno gráfico de administración, que permite el uso de comandos DDL y       DML gráficamente.
·         Permite trabajar en modo cliente-servidor, donde la información y datos se alojan en el servidor y los terminales o clientes de la red sólo acceden a la información.
·         Además permite administrar información de otros servidores de datos.

•          Es un sistema de gestión de bases de datos objeto-relacional.
•          Código fuente disponible libremente.
•          PostgreSQL utiliza un modelo cliente/servidor
•          Usa multiprocesos en ves de multihilos.
•          Postgres intenta ser un sistena de bases de datos de mayor nivel que MySQL, a la altura de Oracle, Sysbase o Interbase.

CARACTERISTICAS
·         Es una base de datos ACID
·         Integridad referencial
·         Implementación del estándar SQL92/SQL99.
·         Implementa el uso de rollback's, subconsultas y transacciones.
·         Se pueden realizar varias operaciones al mismo tiempo sobre la misma tabla.
·         Licencia BSD
·         Soporta un subconjunto de SQL92 MAYOR que el que soporta MySQL. Ademas, tiene ciertas caracteristicas orientadas a objetos.
·         Gestión de usuarios y passwords, manteniendo un muy buen nivel de seguridad en los datos.

 MySQL es un sistema de gestión de base de datos relacional.

Capaz de almacenar una enorme cantidad de datos de gran variedad.

Mysql utiliza el lenguaje de consulta estructurado (SQL).

Incluye un motor de almacenamiento InnoDb y ACID.

Además dispone de store procedures, triggers, vistas.

Mysql es GPL (General Public Licence) no tiene costo, en lo que gana la empresa es en el soporte y entrenamiento.

Al ser una empresa que maneja sus códigos con el tipo de licencia GPL reduce los costos de desarrollo, administración.

CARACTERISTICAS

• Múltiples motores de almacenamiento (MyISAM, Merge, InnoDB, BDB, Memory/heap, MySQL Cluster, Federated, Archive, CSV, Blackhole y Example en 5.x), permitiendo al usuario escoger la que sea más adecuada para cada tabla de la base de datos.
• Uso de multihilos mediante hilos del kernel.
• Usa tablas en disco b-tree para búsquedas rápidas con compresión de índice
• Tablas hash en memoria temporales
• El código MySQL se prueba con Purify (un detector de memoria perdida comercial) así como con Valgrind, una herramienta GPL
• Completo soporte para operadores y funciones en cláusulas select y where.
• Completo soporte para cláusulas group by y order by, soporte de funciones de agrupación
• Soporta gran cantidad de datos. MySQL Server tiene bases de datos de hasta 50 millones de registros.

Es un manejador de base de datos relacional que hace uso de los recursos del sistema informático en todas las arquitecturas de hardware

Es el mayor y mas usado Sistema Manejador de Base de Dato Relacional (RDBMS) en el mundo. La Corporación Oracle ofrece este RDBMS como un producto incorporado a la línea de producción. Además incluye cuatro generaciones de desarrollo de aplicación, herramientas de reportes y utilitarios.

Oracle corre en computadoras personales (PC), microcomputadoras, mainframes y computadoras con procesamiento paralelo masivo

CARACTERISTICAS

• Oracle es un sistema de gestión de base de datos relacional (o RDBMS por el acrónimo en ingles de Relational Data Base Management System,), desarrollado por Oracle Corporation.
• Soporte de transacciones
• Estabilidad
• Escalabilidad
• Soporte multiplataforma.
• Permite el uso de particiones para la mejora de la eficiencia, de replicación e incluso ciertas versiones admiten la administración de bases de datos distribuidas.

http://es.slideshare.net/jonathan_agila/los-gestores-de-base-de-datos?related=1

Actividad #12 Fragmentación

https://prezi.com/smnoksyzucsg/fragmentacion/

Actividad #11 Cuestionario

¿Qué es una transacción? Una transacción es una unidad de la ejecución de un programa que accede y posiblemente actualiza varios elementos de datos. 

¿Qué significa ACID?  y defina cada una de las palabras que forman las siglas el acrónimo se obtiene de la primera letra de cada una de las cuatro propiedades en inglés (Atomicity, Consistency, Isolation y Durability, respectivamente).

• Atomicidad. O todas las operaciones de la transacción se realizan adecuadamente en la base de

datos o ninguna de ellas.

• Consistencia. La ejecución aislada de la transacción (es decir, sin otra transacción que se ejecute

concurrentemente) conserva la consistencia de la base de datos.

• Aislamiento. Aunque se ejecuten varias transacciones concurrentemente, el sistema garantiza que

para cada par de transacciones Ti y Tj, se cumple que para los efectos de Ti, o bien Tj ha terminado

su ejecución antes de que comience Ti , o bien que Tj ha comenzado su ejecución después de que Ti

termine. De este modo, cada transacción ignora al resto de las transacciones que se ejecuten concurrentemente

en el sistema.

• Durabilidad. Tras la finalización con éxito de una

transacción, los cambios realizados en la base de

datos permanecen, incluso si hay fallos en el sistema.

¿Qué significa Tx?
Transmisor o Transmisión

¿Para que nos sirve el Rollback?

defina Integridad de datos

defina concurrencia

Defina Grado de consistencia

Mencione aspectos relacionados al procesamiento de transacciones

defina los estados de una transacción:
Activa (Active):el estado inicial; la transacción permanece en este estado durante su ejecución.
Parcialmente comprometida (Uncommited):después de ejecutarse la última instrucción.
Fallida (Failed):tras descubrir que no puede continuar la ejecución normal.
Abortada (Rolled Back):después de haber retrocedido la transacción y restablecido la base de datos a su estado anterior al comienzo de la transacción.
Comprometida (Commited):tras completarse con éxito.

Actividad #10 Niveles de transparencia

La transparencia se define como la separación de la semántica de alto nivel de un sistema de los aspectos de bajo nivel relacionados a la implementación del mismo. Un nivel de transparencia adecuado permite ocultar los detalles de implementación a las capas de alto nivel de un sistema y a otros usuarios.

La independencia de datos se puede dar en dos aspectos: lógica y física.

.1 Independencia lógica de datos. Se refiere a la inmunidad de las aplicaciones de usuario a los cambios en la estructura lógica de la base de datos. Esto permite que un cambio en la definición de un esquema no debe afectar a las aplicaciones de usuario. Por ejemplo, el agregar un nuevo atributo a una relación, la creación de una nueva relación, el reordenamiento lógico de algunos atributos.

.2 Independencia física de datos. Se refiere al ocultamiento de los detalles sobre las estructuras de almacenamiento a las aplicaciones de usuario. La descripción física de datos puede cambiar sin afectar a las aplicaciones de usuario. Por ejemplo, los datos pueden ser movidos de un disco a otro, o la organización de los datos puede cambiar.

La transparencia sobre replicación de datos se refiere a que si existen réplicas de objetos de la base de datos, su existencia debe ser controlada por el sistema no por el usuario. Se debe tener en cuenta que cuando el usuario se encarga de manejar las réplicas en un sistema, el trabajo de éste es mínimo por lo que se puede obtener una eficiencia mayor. Sin embargo, el usuario puede olvidarse de mantener la consistencia de las réplicas teniendo así datos diferentes.

La transparencia a nivel de fragmentación de datos permite que cuando los objetos de la bases de datos están fragmentados, el sistema tiene que manejar la conversión de consultas de usuario definidas sobre relaciones globales a consultas definidas sobre fragmentos. Así también, será necesario mezclar las respuestas a consultas fragmentadas para obtener una sola respuesta a una consulta global. El acceso a una base de datos distribuida debe hacerse en forma transparente. 

Transparencia de la ubicación. Puede darse el caso de que el usuario conozca cómo se encuentran fragmentadas las tablas, pero no conoce y no es necesario que sepa la ubicación de etas.

Fragmentación

Es una relación que corresponde a una tabla, consiste en dividirla en fragmentos menores, cada fragmento se guarda en  sitio diferente, tiene como objetivo buscar alternativas para dividir una de las tablas o instancias en otras más pequeñas

Existen tres tipos de fragmentación:

1. Fragmentación horizontal: Se realiza sobre las tuplas de la relación, es decir que cada fragmento será un subconjunto de las tuplas de la relación. 

2. Fragmentación vertical: consiste en dividir la relación en un conjunto de relaciones más pequeñas tal que algunas de las aplicaciones de usuario sólo hagan uso de un fragmento. Sobre este marco, una fragmentación óptima es aquella que produce un esquema de división que minimiza el tiempo de ejecución de las aplicaciones que emplean esos fragmentos.

3. Fragmentación mixta: La fragmentación mixta puede llevarse a cabo de tres formas diferentes: desarrollando primero la fragmentación vertical y, posteriormente, aplicando la  fragmentación  horizontal sobre los fragmentos verticales (denominada partición VH), o aplicando primero una división horizontal para luego, sobre los fragmentos generados, desarrollar una fragmentación vertical (llamada partición HV), o bien, de forma directa considerando la semántica de las transacciones.

Presentacion

https://onedrive.live.com/?cid=2B362BDAC7D792D5&id=2B362BDAC7D792D5!644

Actividad #8 Bases de datos vs. Sistemas de archivos

Antes de la llegada de los sistemas de gestión de bases de datos (SGBD), las organizaciones normalmente han almacenado la información usando estos sistemas, pero mantener la información en estos sistemas de archivos tiene una serie de inconvenientes importantes:

• Redundancia e inconsistencia de datos. Existen datos que pueden repetirse en diferentes lugares o archivos, esto provoca que, teniendo esa duplicidad de datos, el almacenamiento y el costo (en recursos del sistema) de acceso sean más altos. Inconsistencia de datos se presentará porque las copias de los mismos datos en diferentes archivos pueden no coincidir, pues si en un archivo se hicieron cambios de los datos, en los otros archivos donde estaban los mismos datos no son modificados automáticamente.
• Dificultad en el acceso a los datos. Cuando se requiere de ciertos datos diferentes de archivos diferentes, la obtención, consulta y modificación de los datos no puede hacerse dirtectamente de forma práctica y eficiente. Tendrían que desarrollarse sistemas de recupración de datos para realizar esa operación específica, o desarrollar un sistema de recuperación de datos para uso general y ajustarlo de acuerdo a las necesidades.
• Aislamiento de datos. Debido a que los datos están dispersos en varios archivos, y los archivos pueden estar en diferentes formatos, es difícil escribir nuevos programas de aplicación para recuperar los datos apropiados.
• Problemas de integridad. Los valores de los datos almacenadosen la BD deben satisfacer ciertas restricciones de consistencia. Los desarrolladores hacen cumplir estas restricciones en el sistema añadiendo código apropiado en las diversas aplicaciones. Sin embargo, cuando se añaden nuevas restricciones es difícil cambiar los programas para hacer que se cumplan. Esto se complica cuando las restricciones implican diferentes elementos de datos de diferentes archivos.
• Problemas de atomicidad. En muchas aplicaciones es crucial asegurar que, cuando ocurra un fallo y sea detectado, se restauren los datos a un estado de consistencia que existía antes del fallo. Es difícil asegurar esta propiedad en un sistema de archivos tradicional.
• Anomalías en el acceso concurrente. en estos sistemas un entorno en el que permita a múltiples usuarios actualizar los datos de un mismo archivo simultáneamiente puede dar lugar a datos inconsistentes o un estado incorrecto.
• Problemas de seguridad. No todos los usuarios de un sistema de bases de datos deberían poder acceder a todos los datos. En estos sistemas es difícil garantizar tales restricciones de seguridad.

Algunas ventajas de las bases de datos frente a los sistemas de archivos

A) Independencia de los datos respecto a los tratamientos y viceversa: La mutua independencia de datos y tratamientos lleva a que un cambio de los programas no implican tener que cambiar el diseño lógico y/o físico de la base de datos.

B) Coherencia de los resultados: Debido a que la información de la base de datos se recoge y almacena una sola vez. En todos los programas se utilizan los mismos datos, por lo que los resultados de todos ellos son coherentes y perfectamente comparables.

C) Mejor disponibilidad de los datos para el conjunto, de los usuarios: Cuando se aplica la metodología de bases de datos, cada usuario ya no es propietario de los datos, puesto que éstos se comparten entre el conjunto de aplicaciones, existiendo una mejor disponibilidad de los datos para todos los que tienen necesidad de ellos, siempre que estén autorizados para su acceso.

D) Mayor eficiencia en la recogida, validación entrada de los datos al sistema: Al no existir apenas redundancias, los datos se recogen y validan una sola vez, aumentando así el rendimiento de todo el proceso previo al almacenamiento. 

E) Reducción del espacio de almacenamiento: La desaparición (o disminución) de las redundancias, así como la aplicación de técnicas de compactación, lleva en los sistemas de bases de datos a una menor ocupación de almacenamiento secundario -disco magnético-. 

Fuentes de consulta:

https://uvfdatabases.wordpress.com/2009/02/02/sistemas-de-bases-de-datos-vs-sistemas-de-archivos/

file:///C:/Users/alumno/Downloads/ventajasydesventajasdelasbasesdedatosfrentealosarchivos-110208185627-phpapp01.pdf