Sei sulla pagina 1di 24

REPBLICA BOLIVARIANA DE VENEZUELA. MINISTERIO DEL PODER POPULAR PARA LA DEFENSA.

UNIVERSIDAD NACIONAL EXPERIMENTAL POLITCNICA DE LAS FUERZAS ARMADAS. ESTADO ANZOTEGUI, NCLEO: SAN TOM.

Docente: Ing. Jos Hernndez. 5to Semestre, Seccin D02.

Bachilleres: Azuaje, Luis. Correa, David. Gil, Romina. Gmez, Jos. Valdez, Gabriel.

C.I: 20.741.463 C.I: 24.846.914 C.I: 19.984.570 C.I: 21.175.519 C.I: 20.741.646

04 de Julio, 2012

INTRODUCCIN

Una base de datos (cuya abreviatura es BD) es una entidad en la cual se pueden almacenar datos de manera estructurada, con la menor redundancia posible. Diferentes programas y diferentes usuarios deben poder utilizar estos datos. Por lo tanto, el concepto de base de datos generalmente est relacionado con el de red ya que se debe poder compartir esta informacin. De all el trmino base. "Sistema de informacin" es el trmino general utilizado para la estructura global que incluye todos los mecanismos para compartir datos que se han instalado.

Rpidamente surgi la necesidad de contar con un sistema de administracin para controlar tanto los datos como los usuarios. La administracin de bases de datos se realiza con un sistema llamado DBMS.

RECUPERACIN

La recuperacin es la tarea que se lleva a cabo cuando es necesario volver al estado de la aplicacin al momento del ltimo respaldo. A partir de los datos de la ultima copia realizada, se hace una copia en sentido inverso, recuperando la aplicacin.

Todas las transacciones ocurridas despus del ltimo respaldo se han perdido. Los movimientos ocurridos entre el momento al ltimo respaldo y el momento en que se detecta la necesidad de la recuperacin deben ser reconstruidos a mano.

La recuperacin es una tarea eventual. Solo se hace si se han perdido datos, en magnitud tal que justifique utilizar el respaldo. Puede hacerse en forma parcial, por ejemplo, un solo archivo o completo.

ACCIONES A TOMAR PARA HACER LA RECUPERACIN

En funcin del tipo de fallo pueden establecerse polticas de recuperacin que se plasman en procedimientos de recuperacin manuales o automticos.

Recuperacin de fallos del medio. Cuando el medio externo ve alterado su estado normal de funcionamiento y en ese medio reside la base de datos fsica (BDF) es necesario restablecer el estado del mismo a un estado consistente anterior que haya sido copiado (back up) a un medio redundante (cintas, cartuchos, discos redundantes, etc.

El procedimiento de recuperacin debe, por tanto, contemplar: a) Realizacin de copias de seguridad peridicas (Back Up).

Pueden utilizarse soportes offline (cintas, cartuchos, etc.) o bien online (discos redundantes). Las copias pueden ser totales (la base de datos entera) o bien incrementales (cambios realizados a la BDF desde la ltima copia de seguridad).

Es especialmente relevante la verificacin del estado de la copia de seguridad para asegurar que el soporte redundante ser vlido en caso de necesidad.

b) Custodia de copias de seguridad Es importante la designacin de los lugares (sitios fsicos) de custodia de las copias de seguridad y el nmero de copias de seguridad a mantener teniendo en cuenta:

Desastres (incendios, inundaciones, etc.) naturales o intencionados que puedan producirse. Salvaguarda en armarios ignfugos y estancos. Custodia en sitios alternativos y distantes del centro de proceso de datos.

c) Recuperacin del medio El medio (discos de almacenamiento de la BDF) se restablecer a un estado consistente anterior lo ms cercano al desastre mediante una recuperacin en frio (Cold Recovery) que consistir en:

Restablecer en el medio una copia o copias de seguridad anteriores (teniendo en cuenta la disposicin de copias totales y/o incrementales). Arranque del sistema, incluyendo el arranque del SGBD.

Recuperacin de fallos de transacciones y del sistema Bajo la hiptesis de medio externo estable, lo que significa que la BDF y los diarios de transacciones son accesibles por el software (SGBD) pueden establecerse procedimientos automticos de recuperacin o recuperacin en caliente (Warm Recovery) que consistirn en: Reconocer el estado consistente ms reciente y/o cercano al instante del fallo. Deshacer las transacciones que no han podido alcanzar el punto de COMMIT antes del fallo.

Rehacer las transacciones que ganaron el punto de COMMIT. Reanudar el proceso normal de gestin de transacciones.

TRANSACCIONES

Una transaccin es un conjunto de operaciones de una aplicacin de Bases de Datos que se efectan como una nica operacin lgica.El gestor de transacciones es la parte del gestor de base de datos que se asegura de mantener la atomicidad, durabilidad y aislamiento (ACID) de las transacciones. Si no hay ningn error, al acabar la transaccin esta se da por definitiva. Si se produce un error durante la transaccin, el sistema debe restaurar la base de datos al estado en que estaba justo antes de que empezara la transaccin. Este proceso se denomina recuperacin de fallos.

COMMIT, ROLLBACK.

Una sentencia COMMIT en SQL finaliza una transaccin de base de datos dentro de un sistema gestor de base de datos relacional (RDBMS) y pone visibles todos los cambios a otros usuarios. El formato general es emitir una sentencia BEGIN WORK, una o ms sentencias SQL, y entonces la sentencia COMMIT.

Su sintaxis es:

COMMIT { TRAN | TRANSACTION } [ transaction_name | @tran_name_variable ] ] [;] Donde: transaction_name Motor de base de datos de SQL Server lo omite. transaction_name especifica un nombre de transaccin asignado a una instruccin BEGIN TRANSACTION anterior.

transaction_name debe cumplir con las reglas para identificadores, pero no puede superar los 32 caracteres. transaction_name se puede usar como una ayuda de legibilidad, ya que

indica a los programadores a qu instruccin BEGIN TRANSACTION anidada est asociada la instruccin COMMIT TRANSACTION.

@tran_name_variable Se trata del nombre de una variable definida por el usuario que contiene un nombre de transaccin vlido. La variable debe declararse con un tipo de datos char, varchar, nchar o nvarchar. Si se pasan ms de 32 caracteres a la variable, solo se usarn 32 caracteres; el resto de los caracteres se truncarn.

En SQL, ROLLBACK es un comando que causa que todos los cambios de datos desde la ltima sentencia BEGIN WORK, o START TRANSACTION sean descartados por el sistema de gestin de base de datos relacional (RDBMS), para que el estado de los datos sea "rolled back"(devuelto) a la forma en que estaba antes de que aquellos cambios tuvieran lugar.

Su sintaxis es: ROLLBACK { TRAN | TRANSACTION } [ transaction_name | @tran_name_variable | savepoint_name | @savepoint_variable ] [;]

Donde: transaction_name Es el nombre asignado a la transaccin en BEGIN TRANSACTION. transaction_name debe ajustarse a las reglas para los identificadores, pero solo se usan los 32 primeros caracteres del nombre de la transaccin. Cuando se anidan transacciones,transaction_name debe ser el nombre de la instruccin BEGIN TRANSACTION ms externa.

@ tran_name_variable

Es el nombre de una variable definida por el usuario que contiene un nombre de transaccin vlido. La variable se debe declarar con un tipo de datos char, varchar, nchar o nvarchar.

savepoint_name Es savepoint_name de una instruccin SAVE TRANSACTION. savepoint_name debe ajustarse a las reglas para los identificadores. Utilice savepoint_name cuando una operacin de reversin condicional solo deba afectar a parte de la transaccin.

@ savepoint_variable Es el nombre de una variable definida por el usuario que contiene un nombre de punto de retorno vlido. La variable debe declararse con un tipo de datos char, varchar, nchar o nvarchar.

RECUPERACIN DE DATOS

Esto significa que, si ocurre algn error en los datos, hay un bug de programa de hardware, el DBA (Administrador de base de datos) puede traer de vuelta la base de datos al tiempo y estado en que se encontraba en estado consistente antes de que el dao se causara. El DBA debe definir y poner en practica un plan de recuperacin adecuado que incluya, por ejemplo una descarga o "vaciado" peridico de la base de datos en un medio de almacenamiento de respaldo, y procedimientos para cargar otra vez la base de datos a partir de vaciado ms reciente cuando sea necesario. Las actividades de recuperacin incluyen el hacer respaldos de la base de datos y almacenar esos respaldos de manera que se minimice el riesgo de dao prdida de los mismos, tales como hacer diversas copias en medios de almacenamiento removibles y almacenarlos fuera del rea en antelacin a un desastre anticipado. La recuperacin es una de las tareas ms importantes de los DBA's.

PROCEDIMIENTO PARA LA RECUPERACIN DE DATOS.

Fase 1: Evaluacin La fase de evaluacin examina la necesidad empresarial respecto a las copias de seguridad y restauracin y hace el inventario de los procesos de copia de seguridad y recuperacin actualmente disponibles. Las actividades de copia de seguridad garantizan que los datos se almacenan adecuadamente y quedan disponibles para la restauracin y recuperacin segn los requisitos empresariales. Cualquier diseo de soluciones de copia de seguridad y recuperacin debe considerar los requisitos empresariales y el entorno de operaciones de la organizacin.

Fase 2: Identificacin El objetivo de la fase de identificacin de la solucin de copia de seguridad y recuperacin es identificar los repositorios de datos de destino y establecer las prioridades del carcter crtico de los datos. Los datos crticos son los datos necesarios para mantener el negocio en funcionamiento y cumplir las leyes o normas aplicables. Las soluciones de este tipo deben ser predecibles, confiables y tener capacidad para cumplir con la normativa y procesar los datos en el menor tiempo posible.

Entre los desafos a los que se enfrentar al administrar datos se encuentran:


Administrar el crecimiento en los volmenes de datos. Administrar la infraestructura de almacenamiento para mejorar la calidad del

servicio (QoS) definida en los contratos de nivel de servicio (SLA) reduciendo al mismo tiempo la complejidad y controlando los costos.

Integrar las aplicaciones con los requisitos de almacenamiento y administracin de

los datos.

Operar con breves o inexistentes ventanas de copia de seguridad de datos. Admitir sistemas de TI existentes que no pueden ejecutar las ltimas tecnologas. Administrar islas tecnolgicas que tienen una administracin descentralizada.

Analizar el valor de los datos para poder aplicar las estrategias ms adecuadas a

cada tipo de datos.

Aunque las actividades de copia de seguridad y restauracin de todos los datos de la organizacin son importantes, este tema trata las directivas y los procedimientos de copia de seguridad y restauracin que deben implementarse para los servicios crticos con el fin de pasar del nivel bsico al nivel estandarizado.

Fase 3: Evaluacin y planeacin En la fase de evaluacin y planeacin, debe tener en cuenta varios aspectos acerca de los datos para determinar la solucin adecuada de copia de seguridad y recuperacin para su organizacin Estos requisitos pueden incluir:

Cantidad de datos que se va a almacenar. Previsiones de crecimiento de datos. Rendimiento de los procesos de copia de seguridad y restauracin. Necesidades de copia de seguridad y restauracin de la base de datos. Requisitos de copia de seguridad del correo electrnico. Tablas para copias de seguridad y restauraciones. Requisitos del archivado de datos (almacenamiento externo). Identificacin de restricciones. Seleccin y adquisicin de componentes de infraestructura de almacenamiento. Plan de administracin y supervisin de almacenamiento. Estrategia de prueba y copia de seguridad.

Plan de copia de seguridad Debe considerar los siguientes factores a la hora de desarrollar un plan de copia de seguridad y recuperacin para servidores crticos:

Modo de copia de seguridad Tipo de copia de seguridad

Topologa de copia de seguridad Plan de servicio

Modos de copia de seguridad El modo de copia de seguridad determina cmo se efectuar la copia de seguridad en relacin con los datos que se van a almacenar. Son dos las formas en que se pueden realizar copias de seguridad:

Copias de seguridad en lnea: se realizan mientras los usuarios tienen acceso a los

datos.

Copias de seguridad sin conexin: se realizan de los datos a los que los usuarios ya

no tienen acceso.

Tipos de copias de seguridad Se pueden usar varios tipos de copia de seguridad, tanto en lnea como sin conexin. El requisito de tiempo de recuperacin, el perodo de copia de seguridad y el contrato de nivel de servicio determinan el mtodo o la combinacin de mtodos que resultan idneos para cada entorno.

Copia de seguridad completa: captura todos los archivos de todos los discos. Copia de seguridad incremental: captura los archivos agregados o modificados

desde la ltima copia de seguridad incremental.

Copia de seguridad diferencial: captura los archivos agregados o modificados

desde la ltima copia de seguridad completa.

Topologa de copia de seguridad Originalmente, el nico tipo de tecnologa de almacenamiento con copia de seguridad consista en discos duros conectados directamente a adaptadores de almacenamiento en servidores. Hoy en da, este tipo de almacenamiento se conoce como almacenamiento de conexin directa o DAS. El panorama de copia de seguridad y recuperacin ha cambiado considerablemente con el desarrollo de tecnologas, como la red de rea de

almacenamiento (SAN, Storage Area Network) y el almacenamiento de conexin den red (NAS, Network Attached Storage). En concreto, los entornos SAN ofrecen la oportunidad destacable de optimizar y simplificar estos procesos.

Copia de seguridad y recuperacin en servidor local (DAS). Cada servidor est

conectado a su propio dispositivo de copia de seguridad.

Copia de seguridad y recuperacin en LAN (NAS). Se trata de una arquitectura de

varios niveles en la que algunos servidores de copia de seguridad inician los trabajos y recopilan metadatos acerca de los datos de copia de seguridad (tambin conocidos como datos de control), mientras otros servidores (designados como servidores de medios) llevan a cabo el trabajo real de administracin de los datos de copia de seguridad.

Copia de seguridad y recuperacin en SAN. En esta topologa, tiene la posibilidad

de trasladar la operacin de copia de seguridad real del host de produccin a un sistema host secundario.

Plan de servicio Al disear el servicio de copia de seguridad y recuperacin debe considerar muchos factores. Algunos de los factores a tener en cuenta son:

Prioridades de copia de seguridad y recuperacin rpidas, objetivo de tiempo de

recuperacin (RTO, Recovery Time Objective).


La frecuencia con la que cambian los datos. Restricciones de tiempo sobre la operacin de copia de seguridad. Medios de almacenamiento. Requisitos de retencin de datos. Actualidad de los datos recuperados, objetivo de punto de recuperacin

(RPO, Recovery Point Objective).

Plan de recuperacin Sin un plan de recuperacin, hasta el mejor plan de copia de seguridad puede resultar ineficaz. Las siguientes son algunas de las prcticas que componen un buen plan de recuperacin de datos.

Comprobar las copias de seguridad La comprobacin de las copias de seguridad es un paso fundamental en la recuperacin ante desastres. No podr recuperar datos a no ser que disponga de una copia de seguridad vlida.

Hacer copia de seguridad de los archivos de registro existentes antes de llevar a cabo una restauracin Una buena proteccin es hacer copia de seguridad de los archivos de registro existentes antes de restaurar un servidor. Si los datos se pierden o por error se restaura un conjunto de copias de seguridad ms antiguo, el registro ayuda a recuperar la informacin.

Realizar simulacros de incendios peridicos Un simulacro mide la capacidad de recuperacin ante un desastre y certifica los planes de recuperacin ante desastres. Cree un entorno de prueba e intente una recuperacin completa de los datos. Asegrese de usar los datos de copia de seguridad de produccin y de registrar cunto se tarda en recuperar los datos. Ello incluye la recuperacin de los datos del almacenamiento externo.

Crear un kit de desastres Planee por adelantado creando un kit de desastres que incluya una hoja de configuracin del sistema operativo, una hoja de configuracin de la particin del disco duro, una matriz redundante de configuracin de discos independientes (RAID), una hoja de configuracin de hardware y as sucesivamente. Este material es bastante fcil de compilar y puede reducir a un mnimo el tiempo de recuperacin, mucho del cual puede estar dedicado a intentar localizar informacin o discos necesarios para configurar el sistema de recuperacin.

Fase 4: Implementacin Cuando disponga de los componentes de infraestructura de almacenamiento adecuados y se haya definido el plan de servicio de copia de seguridad y recuperacin, su organizacin podr instalar la solucin de almacenamiento y las herramientas de administracin y supervisin asociadas en el entorno de TI.

REGLAS DE INTEGRIDAD

Una base de datos contiene unos datos que, en cada momento, deben reflejar la realidad o, ms concretamente, la situacin de una porcin del mundo real. En el caso de las bases de datos relacionales, esto significa que la extensin de las relaciones (es decir, las tuplas que contienen las relaciones) deben tener valores que reflejen la realidad correctamente. Suele ser bastante frecuente que determinadas configuraciones de valores para las tuplas

de las relaciones no tengan sentido, porque no representan ninguna situacin posible del mundo real.

Un sueldo negativo En la relacin de esquema EMPLEADOS(DNI, nombre, apellido, sueldo), una tupla que tiene un valor de 1.000 para el sueldo probablemente no tiene sentido, porque los sueldos no pueden ser negativos.

Denominamos integridad la propiedad de los datos de corresponder a representaciones plausibles del mundo real. Como es evidente, para que los datos sean ntegros, es preciso que cumplan varias condiciones. El hecho de que los sueldos no puedan ser negativos es una condicin que se debera cumplir en la relacin EMPLEADOS.

En general, las condiciones que garantizan la integridad de los datos pueden ser de dos tipos: 1) Las restricciones de integridad de usuario son condiciones especficas de una base de datos concreta; es decir, son las que se deben cumplir en una base de datos particular con unos usuarios concretos, pero que no son necesariamente relevantes en otra base de datos.

Restriccin de integridad de usuario en EMPLEADOS ste sera el caso de la condicin anterior, segn la cual los sueldos no podan ser negativos. Observad que esta condicin era necesaria en la base de datos concreta de este ejemplo porque apareca el atributo sueldo, al que se quera dar un significado; sin embargo, podra no ser necesaria en otra base de datos diferente donde, por ejemplo, no hubiese sueldos.

2) Las reglas de integridad de modelo, en cambio, son condiciones ms generales, propias de un modelo de datos, y se deben cumplir en toda base de datos que siga dicho modelo.

Ejemplo de regla de integridad del modelo de datos relacional En el caso del modelo de datos relacional, habr una regla de integridad para garantizar que los valores de una clave primaria de una relacin no se repitan en tuplas diferentes de la relacin. Toda base de datos relacional debe cumplir esta regla que, por lo tanto, es una regla de integridad del modelo.

Los SGBD deben proporcionar la forma de definir las restricciones de integridad de usuario de una base de datos; una vez definidas, deben velar por su cumplimiento.

A continuacin estudiaremos con detalle las reglas de integridad del modelo relacional, reglas que todo SGBD relacional debe obligar a cumplir. La regla de integridad de unicidad de la clave primaria establece que si el conjunto de atributos CP es la clave primaria de una relacin R, entonces la extensin de R no puede tener en ningn momento dos tuplas con la misma combinacin de valores para los atributos de CP.

Un SGBD relacional deber garantizar el cumplimiento de esta regla de integridad en todas las inserciones, as como en todas las modificaciones que afecten a atributos que pertenecen a la clave primaria de la relacin. La regla de integridad de entidad de la clave primaria establece que si el conjunto de atributos CP es la clave primaria de una relacin R, la extensin de R no puede tener ninguna tupla con algn valor nulo para alguno de los atributos de CP.

Un SGBD relacional tendr que garantizar el cumplimiento de esta regla de integridad en todas las inserciones y, tambin, en todas las modificaciones que afecten a atributos que pertenecen a la clave primaria de la relacin.

La regla de integridad referencial establece que si el conjunto de atributos CF es una clave fornea de una relacin R que referencia una relacin S (no necesariamente diferente de R), que tiene por clave primaria CP, entonces, para toda tupla t de la extensin de R, los valores para el conjunto de atributos CF de t son valores nulos, o bien valores que coinciden con los valores para CP de alguna tupla s de S.

En el caso de que una tupla t de la extensin de R tenga valores para CF que coincidan con los valores para CP de una tupla s de S, decimos que t es una tupla que referencia s y que s es una tupla que tiene una clave primaria referenciada por t.

Un SGBD relacional tendr que hacer cumplir esta regla de integridad. Deber efectuar comprobaciones cuando se produzcan las siguientes operaciones:

a) Inserciones en una relacin que tenga una clave fornea. b) Modificaciones que afecten a atributos que pertenecen a la clave fornea de una relacin. c) Borrados en relaciones referenciadas por otras relaciones. d) Modificaciones que afecten a atributos que pertenecen a la clave primaria de una relacin referenciada por otra relacin La regla de integridad de dominio est relacionada, como su nombre indica, con la nocin de dominio. Esta regla establece dos condiciones.

La primera condicin consiste en que un valor no nulo de un atributo Ai debe pertenecer al dominio del atributo Ai; es decir, debe pertenecer a dominio(Ai). Esta condicin implica que todos los valores no nulos que contiene la base de datos para un determinado atributo deben ser del dominio declarado para dicho atributo.

La segunda condicin de la regla de integridad de dominio es ms compleja, especialmente en el caso de dominios definidos por el usuario; los SGBD actuales no la soportan para estos ltimos dominios. Por estos motivos slo la presentaremos superficialmente.

Esta segunda condicin sirve para establecer que los operadores que pueden aplicarse sobre los valores dependen de los dominios de estosvalores; es decir, un operador determinado slo se puede aplicar sobre valores que tengan dominios que le sean adecuados.

DEFINICIN DE INTEGRIDAD EN LENGUAJES DE DEFINICIN DE DATOS.

SEGURIDAD Un lenguaje de definicin de datos (Data Definition Language, DDL por sus siglas en ingls) es un lenguaje proporcionado por el sistema de gestin de base de datos que permite a los usuarios de la misma llevar a cabo las tareas de definicin de las estructuras que almacenarn los datos as como de los procedimientos o funciones que permitan consultarlos.

La integridad de datos se refiere a los valores reales que se almacenan y se utilizan en las estructuras de datos de la aplicacin. La aplicacin debe ejercer un control deliberado sobre todos los procesos que utilicen los datos para garantizar la correccin permanente de la informacin.

Es posible garantizar la integridad de los datos mediante la implementacin escrupulosa de varios conceptos clave, como los que se incluyen a continuacin: Normalizar datos. Definir reglas de empresa. Proporcionar integridad referencial. Validar los datos.

EJEMPLOS

DE

INSTRUCCIONES

DE

AUTORIZACIN

LENGUAJES

DE

MANIPULACIN DE DATOS

Lenguaje de manejo de datos Una vez creados los esquemas de la base de datos, los usuarios necesitan un lenguaje que les permita manipular los datos de la base de datos: realizar consultas, inserciones, eliminaciones y modificaciones. Este lenguaje es el que se denomina lenguaje de manejo de datos (LMD).

Hay dos tipos de LMD: los procedurales y los no procedurales. Con un LMD procedural el usuario (normalmente ser un programador) especifica qu datos se necesitan y cmo hay que obtenerlos. Esto quiere decir que el usuario debe especificar todas las operaciones de acceso a datos llamando a los procedimientos necesarios para obtener la informacin requerida. Estos lenguajes acceden a un registro, lo procesan y basndose en los resultados obtenidos, acceden a otro registro, que tambin deben procesar. As se va accediendo a registros y se van procesando hasta que se obtienen los datos deseados. Las sentencias de un LMD procedural deben estar embebidas en un lenguaje de alto nivel, ya que se necesitan sus estructuras (bucles, condicionales, etc.) para obtener y procesar cada registro individual. A este lenguaje se le denomina lenguaje anfitrin. Las bases de datos jerrquicas y de red utilizan LMD procedurales.

Un LMD no procedural se puede utilizar de manera independiente para especificar operaciones complejas sobre la base de datos de forma concisa. En muchos SGBD se pueden introducir interactivamente instrucciones del LMD desde un terminal o bien embeberlas en un lenguaje de programacin de alto nivel. Los LMD no procedurales permiten especificar los datos a obtener en una consulta o los datos que se deben actualizar, mediante una sola y sencilla sentencia. El usuario o programador especifica qu datos quiere obtener sin decir cmo se debe acceder a ellos. El SGBD traduce las sentencias del LMD en uno o varios procedimientos que manipulan los conjuntos de registros necesarios. Esto libera al usuario de tener que conocer cul es la estructura fsica de los datos y qu algoritmos se deben utilizar para acceder a ellos. A los LMD no procedurales tambin se les denomina declarativos. Las bases de datos relacionales utilizan LMD no procedurales,

como SQL (Structured Query Language) o QBE (Query-By-Example). Los lenguajes no procedurales son ms fciles de aprender y de usar que los procedurales, y el usuario debe realizar menos trabajo, siendo el SGBD quien hace la mayor parte.

La parte de los LMD no procedurales que realiza la obtencin de datos es lo que se denomina un lenguaje de consultas. En general, las rdenes tanto de obtencin como de actualizacin de datos de un LMD no procedural se pueden utilizar interactivamente, por lo que al conjunto completo de sentencias del LMD se le denomina lenguaje de consultas, aunque es tcnicamente incorrecto.

CONCURRENCIA

En computacin, la concurrencia es la propiedad de los sistemas que permiten que mltiples procesos sean ejecutados al mismo tiempo, y que potencialmente puedan interactuar entre s.

Los procesos concurrentes pueden ser ejecutados realmente de forma simultnea, slo cuando cada uno es ejecutado en diferentes procesadores. En cambio, la concurrencia es simulada si slo existe un procesador encargado de ejecutar los procesos concurrentes, simulando la concurrencia, ocupndose de forma alternada en uno y otro proceso a pequesimos intervalos de tiempo. De esta manera simula que se estn ejecutando a la vez.

Debido a que los procesos concurrentes en un sistema pueden interactuar entre otros tambin en ejecucin, el nmero de caminos de ejecucin puede ser extremadamente grande, resultando en un comportamiento sumamente complejo. Las dificultades asociadas a la concurrencia han sido pensadas para el desarrollo de lenguajes de programacin y conceptos que permitan hacer la concurrencia ms manejable.

PROBLEMAS DE INTERFERENCIA

Como los procesos que se ejecutan en un sistema paralelo acceden con frecuencia a recursos compartidos, pueden sufrir un cierto retardo como consecuencia de la interferencia de cada nuevo proceso en la competencia con los procesos existentes por el acceso a los recursos ms comunes, como el bus del sistema, los discos compartidos o incluso los bloqueos. Este fenmeno afecta tanto a la ganancia de velocidad como a la ampliabilidad.

Cuando un usuario o ms de uno estn actualizando los datos, se pueden producir problemas de interferencia que tengan como consecuencia la obtencin de datos errneos y la perdida integral de la base de datos.

LOCKS EXCLUSIVOS

Los locks exclusivos o bloqueos exclusivos (X) evitan que transacciones simultneas tengan acceso a un recurso. Al utilizar un bloqueo exclusivo (X), el resto de las transacciones no pueden modificar los datos; las operaciones de lectura slo se pueden realizar si se utiliza la sugerencia NOLOCK o el nivel de aislamiento de lectura no confirmada. Las instrucciones para modificar datos, como INSERT, UPDATE y DELETE combinan las operaciones de modificacin con las de lectura. En primer lugar, la instruccin lleva a cabo operaciones de lectura para adquirir los datos antes de proceder a ejecutar las operaciones de modificacin necesarias. Por tanto, las instrucciones de modificacin de datos suelen solicitar bloqueos compartidos y exclusivos. Por ejemplo, una instruccin UPDATE puede modificar las filas de una tabla a partir de una combinacin con otra tabla. En este caso, la instruccin UPDATE solicita bloqueos compartidos para las filas ledas en la tabla de combinacin, adems de bloqueos exclusivos para las filas actualizadas.

DEADLOCKS

Un deadlock o punto muerto es una condicin que ocurre cuando dos transacciones esperan a que una u otra desbloquee los datos. Los deadlocks ocurren cuando dos transacciones, T1 y T2 existen en el siguiente modo: Si T1 no ha desbloqueado el elemento de datos (Y), T2 no puede iniciarse; si T2 no ha desbloqueado el elemento de datos (X), T1 no puede continuar. Por consiguiente, T1 y T2 esperan indefinidamente, cada una espera que la otra desbloquee el elemento de datos requerido. Una condicin comn no deseable es descripta como deadlock, que es cuando dos procesos estn en un estado de ejecucin, y requieren intercambiar recursos entre s para continuar. Ambos procesos estn esperando por la liberacin del recurso requerido, que nunca ser realizada; como no hay ningn resultado, tomar un camino que llevar a un estado de deadlock.

LOCKS COMPARTIDOS, ACTUALIZACIN DE LOCKS.

Locks compartidos Los bloqueos compartidos (S) permiten que varias transacciones simultneas lean (SELECT) un recurso en situaciones de control de simultaneidad pesimista. Para obtener ms informacin, vea Tipos de control de simultaneidad. Ninguna otra transaccin podr modificar los datos mientras el bloqueo compartido (S) exista en el recurso. Los bloqueos compartidos (S) en un recurso se liberan tan pronto como finaliza la operacin de lectura, a menos que se haya establecido el nivel de aislamiento de la transaccin como REPEATABLE READ o ms alto, o bien se utilice una sugerencia de bloqueo para mantener los bloqueos compartidos (S) durante la transaccin.

Locks actualizacin Los bloqueos de actualizacin (U) evitan una forma comn de interbloqueo. En una transaccin de lectura repetible, la transaccin lee los datos, adquiere un bloqueo compartido (S) en el recurso (pgina o fila) y, a continuacin, modifica los datos, lo que

requiere una conversin del bloqueo en un bloqueo exclusivo (X). Si dos transacciones adquieren bloqueos compartidos en un recurso y, a continuacin, intentan actualizar los datos simultneamente, una de ellas intenta convertir el bloqueo en un bloqueo exclusivo (X). La conversin de bloqueo compartido en exclusivo debe esperar, ya que el bloqueo exclusivo de una transaccin no es compatible con el bloqueo compartido de la otra. Por tanto, se produce una espera de bloqueos. La segunda transaccin intenta adquirir un bloqueo exclusivo (X) para realizar su actualizacin. Debido a que ambas transacciones intentan convertir los bloqueos en exclusivos (X) y cada una espera a que la otra libere su bloqueo de modo compartido, se produce un interbloqueo.

Para evitar este posible problema de interbloqueo, se utilizan los bloqueos de actualizacin (U). Dos transacciones no pueden obtener simultneamente un bloqueo de actualizacin (U) para un recurso. Si una transaccin modifica un recurso, el bloqueo de actualizacin (U) se convierte en un bloqueo exclusivo (X).

CONCLUSIONES

El sistema manejador de bases de datos es la porcin ms importante del software de un sistema de base de datos. Un DBMS es una coleccin de numerosas rutinas de software interrelacionadas, cada una de las cuales es responsable de alguna tarea especfica.

Las funciones principales de un DBMS son: Crear y organizar la Base de datos, establecer y mantener las trayectorias de acceso a la base de datos de tal forma que los datos puedan ser accesados rpidamente, manejar los datos de acuerdo a las peticiones de los usuarios, registrar el uso de las bases de datos, Interaccin con el manejador de archivos, esto a travs de las sentencias en DML al comando del sistema de archivos. As el Manejador de base de datos es el responsable del verdadero almacenamiento de los datos.

En s, un sistema manejador de base de datos es el corazn de la base de datos ya que se encarga del control total de los posibles aspectos que la puedan afectar.

BIBLIOGRAFA

Avda, Reina. (2007, 1 de Noviembre) Diseo de bases de datos [PDF en lnea]. Recuperacin de bases de datos. Consultado el da 30 de Junio de 2012 de la World Wide Web: http://www.lsi.us.es/docencia/get.php?id=5412

Tener, Simn. Pequeo, Nelson (2007) Respaldo y Recuperacin de Datos [PDF en lnea]. . Consultado el da 30 de Junio de 2012 de la World Wide Web:

http://www.ccee.edu.uy/ensenian/catcomp/material/respyrec.pdf

J. Galindo Gmez (2009) Administracin de Bases de Datos (Ingeniera Tcnica en Informtica de Gestin).[PDF en lnea] Consultado el da 30 de Junio de 2012 de la World Wide Web: http://www.lcc.uma.es/~bds/adminbd/apuntes/ABD1_Intro.pdf

Potrebbero piacerti anche