viernes, 16 de noviembre de 2012

Datos



Jueves 15 Setiembre 2012

Alumno: Javier Eduardo Huamaní Portocarrero
Curso: Base de datos
Ciclo: 2012-2
Profesor: Luis Serna Jherry

Bases de Datos Distribuidas: soluciones homogéneas y heterogéneas, integradas, federadas o multibase

SISTEMAS DISTRIBUIDOS

En un sistema distribuido de bases de datos se almacena la base de datos en varias computadoras. Varios
medios de comunicación, como las redes de alta velocidad o las líneas telefónicas, son los que pueden poner
en contacto las distintas computadoras de un sistema distribuido. No comparten ni memoria ni discos. Las
computadoras de un sistema distribuido pueden variar en tamaño y función pudiendo abarcar desde las estaciones de trabajo a los grandes sistemas.

Dependiendo del contexto en el que se mencionen existen diferentes nombres para referirse a las computadoras que forman parte de un sistema distribuido, tales como sitios o nodos. Para enfatizar la distribución física de estos sistemas se usa principalmente el término sitio. 

Las principales diferencias entre las bases de datos paralelas sin compartimientos y las bases de datos distribuidas son que las bases de datos distribuidas normalmente se encuentran en varios lugares geográficos
distintos, se administran de forma separada y poseen una interconexión más lenta. Otra gran diferencia es que en un sistema distribuido se dan dos tipos de transacciones, las locales y las globales. Una transacción local es aquella que accede a los datos del único sitio en el cual se inició la transacción. Por otra parte, una transacción global es aquella que, o bien accede a los datos situados en un sitio diferente de aquel en el que se inició la transacción, o bien accede a datos de varios sitios distintos.



Hay varias razones para construir sistemas distribuidos de bases de datos, incluyendo el compartimiento
de los datos, la autonomía y la disponibilidad.

• Datos compartidos. La principal ventaja de construir un sistema distribuido de bases de datos es poder disponer de un entorno donde los usuarios puedan acceder desde una única ubicación a los datos que residen en otras ubicaciones. Por ejemplo, en un sistema de banca distribuida, donde cada sucursal almacena datos relacionados con dicha sucursal, es posible que un usuario de una de las sucursales acceda a los datos de otra sucursal. Sin esta capacidad, un usuario que quisiera transferir fondos de una sucursal a otra tendría que recurrir a algún mecanismo externo que pudiera enlazar los sistemas existentes.

• Autonomía. La principal ventaja de compartir datos por medio de distribución de datos es que cada ubicación es capaz de mantener un grado de control sobre los datos que se almacenan localmente. En un sistema centralizado, el administrador de bases de datos de la ubicación central controla la base de datos. En un sistema distribuido, existe un administrador de bases de datos global responsable de todo el sistema. Una parte de estas responsabilidades se delegan al administrador de bases de datos local de cada sitio. Dependiendo del diseño del sistema distribuido de bases de datos, cada administrador puede tener un grado diferente de autonomía local. La posibilidad de autonomía local es a menudo una de las grandes ventajas
de las bases de datos distribuidas.

• Disponibilidad. Si un sitio de un sistema distribuido falla, los sitios restantes pueden seguir trabajando. En particular, si los elementos de datos están replicados en varios sitios, una transacción que necesite un elemento de datos en particular puede encontrarlo en varios sitios. De este modo, el fallo de un sitio no implica necesariamente la caída del sistema. El sistema puede detectar el fallo de un sitio, y pueden ser necesarias acciones apropiadas para recuperarse del fallo. El sistema no debe seguir utilizando los servicios del sitio que falló. Finalmente, cuando el sitio que falló se recupera o se repara, debe haber mecanismos disponibles para integrarlo sin problemas de nuevo en el sistema.



Soluciones Homogéneas.-
En los sistemas de bases de datos distribuidas homogéneas, todos los sitios emplean el mismo software de gestión de bases de datos,  y conocen los demás sitios de tal forma que puedan cooperar en el procesamiento de las solicitudes de los usuarios.

Soluciones Heterogéneas.-
En las bases de datos distribuidas heterogéneas puede que los diferentes sitios utilicen esquemas y software de gestión de sistemas de bases de datos diferentes. Puede que algunos sitios no tengan información de la existencia del resto y que solo proporcionen facilidades limitadas para la cooperación en el procesamiento de las transacciones de los usuarios.

Soluciones Integradas.-
Son aquellas que prefieren las pequeñas o medianas empresas debido a que tienen un costo menor y es de fácil manejo.

Soluciones Federadas.-
Permite que administrar entidades interdependientes entre compañías. De esta forma, los usuarios de EShop´s podrán acceder a varias áreas de la base de datos con sus datos de ingreso al sistema.





Arquitectura Cliente/Servidor


Como las computadoras personales son ahora más rápidas, más potentes y más baratas, los sistemas se han ido distanciando de la arquitectura centralizada. Los terminales conectados a un sistema central han sido suplantados por computadoras personales. De igual forma, la interfaz de usuario, que solía estar gestionada directamente por el sistema central, está pasando a ser gestionada, cada vez más, por las computadoras personales. Como consecuencia, los sistemas centralizados actúan hoy como sistemas servidores que satisfacen las peticiones generadas por los sistemas clientes. En la siguiente figura se representa la estructura general de un sistema cliente-servidor.

La funcionalidad de una base de datos se puede dividir a grandes rasgos en dos partes: la parte visible al usuario y el sistema subyacente. El sistema subyacente gestiona el acceso a las estructuras, la evaluación y optimización de consultas, el control de concurrencia y la recuperación. 

La parte visible al usuario de un sistema de base de datos está formado por herramientas como formularios,
diseñadores de informes y facilidades gráficas de interfaz de usuario. La interfaz entre la parte visible al usuario y el sistema subyacente puede ser SQL o una aplicación. Las normas como ODBC y JDBC, se desarrollaron para hacer de interfaz entre clientes y servidores. Cualquier cliente que utilice interfaces ODBC o JDBC puede conectarse a cualquier servidor que proporcione esta interfaz. En las primeras generaciones de sistemas de bases de datos, la carencia de tales normas hacía que fuera necesario que la interfaz visible y el sistema subyacente fueran proporcionados por el mismo distribuidor de software. Con el aumento de las interfaces estándares, a menudo diferentes distribuidores proporcionan la interfaz visible al usuario y el  servidor del sistema subyacente. 

Las herramientas de desarrollo de aplicaciones se utilizan para construir interfaces de usuario; proporcionan
herramientas gráficas que se pueden utilizar para construir interfaces sin programar. Algunas de las  herramientas de desarrollo de aplicaciones más famosas son PowerBuilder, Magic y Borland Delphi; Visual Basic también se utiliza bastante en el desarrollo de aplicaciones.




Arquitectura Centralizada.

ARQUITECTURAS CENTRALIZADAS

Los sistemas de bases de datos centralizados son aquellos que se ejecutan en un único sistema informático sin interaccionar con ninguna otra computadora. Tales sistemas comprenden el rango desde los sistemas de bases de datos monousuario ejecutándose en computadoras personales hasta los sistemas de bases de datos de alto rendimiento ejecutándose en grandes sistemas. Por otro lado, los sistemas cliente-servidor tienen su funcionalidad dividida entre el sistema servidor y múltiples sistemas clientes.


Una computadora moderna de propósito general consiste en una o unas pocas unidades centrales de procesamiento y un número determinado de controladores para los dispositivos que se encuentran conectados a través de un bus común, el cual proporciona acceso a la memoria compartida. Las UCP (unidades centrales de procesamiento) poseen memorias caché locales donde se almacenan copias de ciertas partes de la memoria para acelerar el acceso a los datos. Cada controlador de dispositivo se encarga de un tipo específico de dispositivos (por ejemplo, una unidad de disco, una tarjeta de sonido o un monitor). Las UCP y los controladores de dispositivos pueden ejecutarse concurrentemente compitiendo así por el acceso a la memoria. La memoria caché reduce la disputa por el acceso a la memoria, ya que la UCP necesita acceder a la memoria compartida un número de veces menor. Se distinguen dos formas de utilizar las computadoras: como sistemas monousuario o multiusuario.

En la primera categoría están las computadoras personales y las estaciones de trabajo. Un sistema monousuario típico es una unidad de sobremesa utilizada por una única persona que dispone de una sola UCP, de uno o dos discos fijos y que trabaja con un sistema operativo que sólo permite un único usuario. Por el contrario, un sistema multiusuario típico tiene más discos y más memoria, puede disponer de varias UCP y trabaja con un sistema operativo multiusuario. Se encarga de dar servicio a un gran número de usuarios que están conectados al sistema a través de terminales. Normalmente, los sistemas de bases de datos diseñados para funcionar sobre sistemas monousuario no suelen proporcionar muchas de las facilidades que ofrecen los sistemas multiusuario. En particular no tienen control de concurrencia, que no es necesario cuando solamente un usuario puede generar modificaciones. Las facilidades de recuperación en estos sistemas o no existen o son primitivas; por ejemplo, realizar una copia de seguridad de la base de datos antes de cualquier modificación.

La mayoría de estos sistemas no admiten SQL y proporcionan un lenguaje de consulta muy simple que,
en algunos casos, es una variante de QBE. En cambio, los sistemas de bases de datos diseñados para sistemas multiusuario soportan todas las características de las transacciones que se han estudiado antes.



Recuperación de la BD.


Una computadora, al igual que cualquier otro dispositivo eléctrico o mecánico, está sujeta a fallos. Éstos se producen por diferentes motivos como: fallos de disco, cortes de corriente, errores en el software, un incendio en la habitación de la computadora o incluso sabotaje. En cada uno de estos casos puede perderse información. Por tanto, el sistema de bases de datos debe realizar con anticipación acciones que garanticen que las propiedades de atomicidad y durabilidad de las transacciones, se preservan a pesar de tales fallos. Una parte integral de un sistema de bases de datos es un esquema de recuperación, el cual es responsable de la restauración de la base de datos al estado consistente previo al fallo. El esquema de recuperación también debe proporcionar alta disponibilidad; esto es, debe minimizar el tiempo durante el que la base de datos no se puede usar después de un fallo.


CLASIFICACIÓN DE LOS FALLOS


En un sistema pueden producirse varios tipos de fallos, cada uno de los cuales requiere un tratamiento diferente. El tipo de fallo más fácil de tratar es el que no conduce a una pérdida de información en el sistema. Los fallos más difíciles de tratar son aquellos que provocan una pérdida de información. En este capítulo  consideraremos sólo los siguientes tipos de fallos:

• Fallo en la transacción. Hay dos tipos de errores que pueden hacer que una transacción falle:

    — Error lógico. La transacción no puede continuar con su ejecución normal a causa de alguna condición interna, como una entrada incorrecta, datos no encontrados, desbordamiento o exceso del límite de recursos. 
    — Error del sistema. El sistema se encuentra en un estado no deseado (por ejemplo, de interbloqueo)
como consecuencia del cual una transacción no puede continuar con su ejecución normal. La transacción, sin embargo, se puede volver a ejecutar más tarde.

• Caída del sistema. Un mal funcionamiento del hardware o un error en el software de la base de datos o del sistema operativo causa la pérdida del contenido de la memoria volátil y aborta el procesamiento de una transacción. El contenido de la memoria no volátil permanece intacto y no se corrompe. La suposición de que los errores de hardware o software fuercen una parada del sistema, pero no corrompan el contenido de la memoria no volátil, se conoce como supuesto de fallo-parada. Los sistemas bien diseñados tienen numerosas comprobaciones internas, al nivel de hardware y de software, que abortan el sistema cuando  existe un error. De aquí que el supuesto de fallo-parada sea razonable.

• Fallo de disco. Un bloque del disco pierde su contenido como resultado de bien una colisión de la cabeza lectora, bien un fallo durante una operación de transferencia de datos. Las copias de los datos que se encuentran en otros discos o en archivos de seguridad en medios de almacenamiento secundarios, como cintas, se utilizan para recuperarse del fallo.


ESTRUCTURA DEL ALMACENAMIENTO


Los diferentes elementos que componen una base de datos pueden ser almacenados y accedidos con diferentes medios de almacenamiento. Para entender cómo se pueden garantizar las propiedades de atomicidad y durabilidad de una transacción, se deben comprender mejor estos medios de almacenamiento y sus métodos de acceso.


Los medios de almacenamiento se pueden distinguir según su velocidad relativa, capacidad, y resistencia a fallos, y se pueden clasificar como almacenamiento volátil o no volátil y estable.


Almacenamiento volátil. La información que reside en almacenamiento volátil no suele sobrevivir a las caídas del sistema. La memoria principal y la memoria caché son ejemplos de este almacenamiento. El acceso al almacenamiento volátil es muy rápido, tanto por la propia velocidad de acceso a la memoria, como porque es posible acceder directamente a cualquier elemento de datos.


• Almacenamiento no volátil. La información que reside en almacenamiento no volátil sobrevive a las caídas del sistema. Los discos y las cintas magnéticas son ejemplos de este almacenamiento. Los discos se utilizan para almacenamiento en conexión, mientras que las cintas se usan para almacenamiento permanente. Ambos, sin embargo, pueden fallar (por ejemplo, colisión de la cabeza lectora), lo que puede conducir a una pérdida de información.


• Almacenamiento estable. La información que reside en almacenamiento estable nunca se pierde (bueno, nunca diga nunca jamás, porque teóricamente el nunca no puede garantizarse; por ejemplo, es posible, aunque extremadamente improbable, que un agujero negro se trague a la Tierra y ¡destruya para siempre todos los datos!). A pesar de que el almacenamiento estable es teóricamente imposible de conseguir, puede obtenerse una buena aproximación usando técnicas que hagan que la pérdida de información sea una posibilidad muy remota.


RECUPERACIÓN Y ATOMICIDAD


Considérese de nuevo el sistema bancario simplificado y una transacción Ti que transfiere 50€ desde la cuenta A a la cuenta B, siendo los saldos iniciales de A y de B de 1.000€ y 2.000€ respectivamente. Supóngase que el sistema cae durante la ejecución de Ti después de haberse ejecutado salida(BA), pero antes de la ejecución de salida(BB), donde BA y BB denotan los bloques de memoria intermedia en los que residen A y B. Al perderse el contenido de la memoria no se sabe la suerte de la transacción; así, podríamos invocar uno de los dos procedimientos posibles de recuperación.

• Volver a ejecutar Ti. Este procedimiento hará que el saldo de A se quede en 900 € en vez de en 950 €. De este modo el sistema entra en un estado inconsistente.

• No volver a ejecutar Ti. El estado actual del sistema otorga los valores de 950 € y 2.000 € para A y B respectivamente. Por tanto, el sistema entra en un estado inconsistente.


En cualquier caso se deja a la base de datos en un estado inconsistente y, por lo tanto, este esquema simple de recuperación de datos no funciona. El motivo de este mal funcionamiento es que se ha modificado la base de datos sin tener la seguridad de que la transacción se comprometa realmente.


RECUPERACIÓN BASADA EN EL REGISTRO HISTÓRICO


La estructura más ampliamente utilizada para guardar las modificaciones de una base de datos es el registro histórico. El registro histórico es una secuencia de registros que mantiene un registro de todas las actividades de actualización de la base de datos. Existen varios tipos
de registros del registro histórico. Un registro de actualización del registro histórico describe una única escritura en la base de datos y tiene los siguientes campos:

• El identificador de la transacción es un identificador único de la transacción que realiza la operación escribir.

• El identificador del elemento de datos es un identificador único del elemento de datos que se escribe. Normalmente suele coincidir con la ubicación del elemento de datos en el disco. 

• El valor anterior es el valor que tenía el elemento de datos antes de la escritura. 

• El valor nuevo es el valor que tendrá el elemento de datos después de la escritura.



PAGINACIÓN EN LA SOMBRA


La paginación en la sombra es una técnica de recuperación alternativa a las basadas en registro histórico. Bajo ciertas circunstancias la paginación en la sombra puede requerir menos accesos al disco que los métodos basados en registro histórico que se presentaron anteriormente. No obstante, como se verá, existen algunos inconvenientes en el enfoque de la paginación en la sombra. Por ejemplo, es difícil extender la paginación en la sombra para permitir que varias transacciones puedan ejecutarse concurrentemente.


Igual que antes, la base de datos se divide en un número determinado de bloques de longitud fija a los que se denominará páginas. Debido a que se va a utilizar un esquema de paginación para la gestión de la memoria, se ha tomado prestado de los sistemas operativos el término página. Supóngase que hay n páginas numeradas desde 1 hasta n (en la práctica, n puede ser del orden de cientos de miles). No es necesario almacenar en disco estas páginas en un orden determinado (como se vio en el Capítulo 11 hay muchas razones por las que esto es así). Sin embargo, dado un cierto i, debe existir una manera de localizar la página i-ésima de la base de datos.


TRANSACCIONES CONCURRENTES Y RECUPERACIÓN


Hasta ahora se ha tratado la recuperación en un entorno en el que se ejecutaba una sola transacción en cada instante. Ahora se verá cómo modificar y extender el esquema de recuperación basado en registro histórico para permitir la ejecución concurrente de varias transacciones.

El sistema sigue teniendo una única memoria intermedia de disco y un único registro histórico
independientemente del número de transacciones concurrentes. Todas las transacciones comparten los bloques de la memoria intermedia. Se permiten actualizaciones inmediatas y que un bloque de la memoria intermedia tenga elementos de datos que hayan sido modificados por una o más transacciones.


TÉCNICAS AVANZADAS DE RECUPERACIÓN


Se han desarrollado técnicas avanzadas de recuperación para soportar técnicas de bloqueo de alta concurrencia, como las utilizadas para el control de concurrencia con árboles B+. Estas técnicas se basan en el registro deshacer lógico y siguen el principio de repetir la historia. En la recuperación de un fallo del sistema se realiza una fase rehacer utilizando el registro histórico seguida de una fase deshacer sobre el registro histórico para retroceder las transacciones incompletas.


SISTEMAS REMOTOS DE COPIAS DE SEGURIDAD


Los sistemas remotos de copia de seguridad proporcionan un alto nivel de disponibilidad, permitiendo que continúe el procesamiento de transacciones incluso si se destruye el sitio primario por fuego, inundación o terremoto.














Seguridad de la BD.


Los datos guardados en la base de datos deben estar protegidos contra los accesos no autorizados, de la destrucción o alteración malintencionadas además de la introducción accidental de inconsistencias que evitan las restricciones de integridad. A continuación, se examina el modo en que se pueden utilizar mal los datos o hacerlos inconsistentes de manera intencionada. Se presentan luego mecanismos para protegerse de dichas incidencias.


Violaciones de la seguridad


Entre las formas de acceso malintencionado se encuentran:
• La lectura no autorizada de los datos (robo de información)
• La modificación no autorizada de los datos
• La destrucción no autorizada de los datos

La seguridad de las bases de datos se refiere a la protección frente a accesos malintencionados. No es posible la protección absoluta de la base de datos contra el uso malintencionado, pero se puede elevar lo suficiente el coste para quien lo comete como para disuadir la mayor parte, si no la totalidad, de los intentos de tener acceso a la base de datos sin la autorización adecuada.

Para proteger la base de datos hay que adoptar medidas de seguridad en varios niveles:

• Sistema de bases de datos. Puede que algunos usuarios del sistema de bases de datos sólo estén autorizados a tener acceso a una parte limitada de la base de datos. Puede que otros usuarios estén autorizados a formular consultas pero tengan prohibido modificar los datos. Es responsabilidad del sistema de bases de datos asegurarse de que no se violen estas restricciones de autorización.

• Sistema operativo. Independientemente de lo seguro que pueda ser el sistema de bases de datos,
la debilidad de la seguridad del sistema operativo puede servir como medio para el acceso no autorizado
a la base de datos.

• Red. Dado que casi todos los sistemas de bases de datos permiten el acceso remoto mediante terminales
o redes, la seguridad en el nivel del software de la red es tan importante como la seguridad física, tanto en Internet como en las redes privadas de las empresas.


• Físico. Los sitios que contienen los sistemas informáticos deben estar protegidos físicamente contra
la entrada de intrusos.

• Humano. Los usuarios deben ser autorizados cuidadosamente para reducir la posibilidad de que alguno de ellos dé acceso a intrusos a cambio de sobornos u otros favores.


Debe conservarse la seguridad en todos estos niveles si hay que asegurar la seguridad de la base de datos.
La debilidad de los niveles bajos de seguridad (físico o humano) permite burlar las medidas de seguridad estrictas de niveles superiores (base de datos).



Autorizaciones


Los usuarios pueden tener varios tipos de autorización para diferentes partes de la base de datos. Entre ellas
están las siguientes:

• La autorización de lectura permite la lectura de los datos, pero no su modificación.
• La autorización de inserción permite la inserción de datos nuevos, pero no la modificación de los existentes.
• La autorización de actualización permite la modificación de los datos, pero no su borrado.
• La autorización de borrado permite el borrado de los datos.

Los usuarios pueden recibir todos los tipos de autorización, ninguno de ellos o una combinación determinada
de los mismos. Además de estas formas de autorización para el acceso a los datos, los usuarios pueden recibir autorización para modificar el esquema de la base de datos:

• La autorización de índices permite la creación y borrado de índices.
• La autorización de recursos permite la creación de relaciones nuevas.
• La autorización de alteración permite el añadido o el borrado de atributos de las relaciones.
• La autorización de eliminación permite el borrado de relaciones.

Las autorizaciones de eliminación y de borrado se diferencian en que la autorización de borrado sólo permite el borrado de tuplas. Si un usuario borra todas las tuplas de una relación, la relación sigue existiendo, pero está vacía. Si se elimina una relación, deja de existir. La capacidad de crear  nuevas relaciones queda regulada mediante la autorización de recursos. El usuario con la autorización de recursos que crea una relación nueva recibe automáticamente todos los privilegios sobre la misma.



Concesión de privilegios

El usuario al que se le ha concedido alguna forma de autorización puede ser autorizado a transmitir esa autorización a otros usuarios. Sin embargo, hay que tener cuidado con el modo en que se puede transmitir la autorización entre los usuarios para asegurar que la misma pueda retirarse en el futuro.



Otros


Otros dos mecanismos importantes para la protección de acceso no autorizado, que también debemos tener en cuenta son:

La criptografía: Consiste en cifrar los datos para hacerlos ilegibles mediante algoritmos altamente sofisticados de tal manera que sólo los usuarios autorizados puedan decifrarlos. Para encriptar o cifrar los datos, se necesita de un algoritmo de encriptamiento y otro para el desencriptamiento.

El control de la inferencia: Consiste en impedir que un usuario pueda deducir información, sin tener autorización, a partir de los datos a los que sí tiene acceso.







Integridad y Concurrencia


INTEGRIDAD


Integridad de las Bases de Datos, la integridad en una base de datos es la corrección y exactitud de la información contenida. Además de conservar la seguridad en un sistema de bases de datos que permite el acceso a múltiples usuarios en tiempos paralelos.


Restricciones de Integridad:

Las restricciones de integridad proporcionan un medio de asegurar que las modificaciones hechas a la base de datos por los usuarios autorizados no provoquen la pérdida de la consistencia de los datos. Por tanto, las restricciones de integridad protegen a la base de datos contra los daños accidentales.

Estas restricciones eran de los tipos siguientes:

• Declaración de claves – la estipulación de que ciertos atributos pueden formar una clave
para un conjunto de entidades determinado.

• Forma de la relación – de varios a varios, de uno a varios, de uno a uno.

En general, la restricción de integridad puede ser un predicado arbitrario referente a la base de datos. Sin embargo, los predicados arbitrarios pueden resultar complicados de verificar. En consecuencia, lo habitual es limitarse a restricciones de integridad que puedan verificarse con una sobrecarga mínima. Existe otra forma de restricción de integridad, denominada «dependencia funcional», que se usa principalmente en el proceso del diseño de esquemas.


Restricciones de Dominio:



Las restricciones de los dominios especifican el conjunto de valores que se pueden asociar con un atributo.
Estas restricciones también pueden impedir el uso de valores nulos para atributos concretos.


Restricciones de Integridad Referencial:

Las restricciones de integridad referencial aseguran que un valor que aparece en una relación para un conjunto de atributos dado aparezca también para un conjunto de atributos concreto en otra relación.





Las restricciones de dominio y las de integridad referencial son relativamente sencillas de verificar. El uso
de restricciones más complejas puede provocar una sobrecarga considerable. Se han visto dos maneras de
expresar restricciones más generales. Los asertos son expresiones declarativas que manifiestan predicados
que deben ser siempre verdaderos.

Aserto:


Un aserto es un predicado que expresa una condición que se desea que la base de datos satisfaga siempre. Las restricciones de dominio y las de integridad referencial son formas especiales de los asertos. Se ha prestado una atención especial a estos tipos de asertos porque se pueden verificar con facilidad y se aplican a una gran variedad de aplicaciones de bases de datos. Sin embargo, hay muchas restricciones que no se pueden expresar utilizando únicamente estas formas especiales. Ejemplos de estas restricciones pueden ser

       • La suma de todos los importes de los préstamos de cada sucursal debe ser menor que la suma de          todos los saldos de las cuentas de esa sucursal. 
       • Cada préstamo tiene al menos un cliente que tiene una cuenta con un saldo mínimo de 1.000 €.

Triggers:

Los triggers, que son instrucciones que el sistema ejecuta automáticamente como efecto colateral de una modificación de la base de datos. Los disparadores se usan para asegurar algunos tipos de integridad.
Además de la protección contra la introducción accidental de inconsistencia, puede ser necesario
proteger los datos almacenados en la base de datos frente a accesos no autorizados y destrucción
o alteración malintencionada. 




CONCURRENCIA

La mayoría de los sistemas de gestión de base de datos son de múltiples usuarios. Es decir, permiten cualquier numero T accesando a la misma BD al mismo tiempo. En estos sistemas, se necesita algún mecanismo de control de concurrencia como, por ejemplo, el mecanismo de bloqueo o cierre, que es uno de los mas empleados en la practica.

Hay distintos casos en que puede haber problemas, es decir, en los que una T correctamente definida puede, no obstante, producir un resultado incorrecto debido a la interferencia de otra T (en el caso de que no haya un mecanismo de control adecuado)

Ejemplos: 

  1. Actualizacion perdida:


Transacción A         Tiempo        Transacción B
___________                               ___________
Recuperar R                 t1              ___________
___________                               ___________
___________              t2              Recuperar R
___________                               ___________
Actualizar  R                 t3              ___________
___________                               ___________
___________              t4              Actualizar  R

A recupera el articulo R en el tiempo t1 y B, el mismo articulo en el tiempo t2.
A actualiza R en t3 y B actualiza el mismo articulo en t4, de acuerdo al valor encontrado en t1.
Entonces, la actualizacion hecha por A se pierde en el tiempo t4, pues B sobreescribe articulos sin haberla considerado.


    2.  Cierre o bloqueo:

La idea básica de cierre es simple: cuando una T necesita que algún objeto(tipicamente un articulo)

 no cambie de forma impredecible mientras que ella lo esta tratando, T adquiere un cierre sobre tal objeto. El efecto es que otras T quedan fuera que no se les permita accesar el articulo, y por tanto, se previene que este sea cambiado por esas T


   3.  Abrazo Fatal:

Version generalizada del abrazo fatal:


Transacción A         Tiempo        Transacción B
___________                               ___________
solicita X/R1                 t1              ___________
___________                               ___________
___________              t2              solicita X/R2
___________                               ___________
solicita X/R2                 t3              ___________
espera                                           ___________
espera                          t4              solicita X/R1
espera                                           espera

El abrazo fatal es una situación en la que dos o mas T están simultáneamente en un estado de espera, cada una esperando que una de las otras libere un recurso que ella necesita para proseguir.

Si un lazo fatal ocurre, el sistema debe detectarlo y romperlo. Esto ultimo se realiza seleccionando unas de las T involucradas en el abrazo fatal como victima y deshaciendo lo realizado por ella, y por tanto, liberando sus cierres, lo que permite a otra T proseguir. Muchos sistemas reinician automáticamente dicha T, asumiendo que las condiciones causantes del abrazo falta no ocurrirán.
No obstante es preferible evitar la ocurrencia de un abrazo fatal que recuperarse de el. Lo mas usual para evitarlo es no permitir a una transaccion solicitar un recurso.



Administración de Objetos y Recursos.


Administración de Objetos



• Las aplicaciones de bases de datos de la generación actual no encajan a menudo en el conjunto de suposiciones hecho para el tipo de aplicaciones más antiguas de procesamiento de datos. Se ha desarrollado
el modelo de datos orientado a objetos para trabajar con varios de estos nuevos tipos de aplicaciones.

• El modelo de datos orientado a objetos es una adaptación para los sistemas de bases de datos del paradigma de la programación orientada a objetos. Se basa en el concepto de encapsular los datos en un objeto y el código que opera sobre ellos.

• De manera parecida, los objetos estructurados se agrupan en clases. El conjunto de las clases se estructura
en subclases y superclases basadas en una extensión del concepto ES del modelo entidad-relación.

• El valor de un elemento de datos de un objeto puede ser un objeto, haciendo posible representar los continentes de objetos, lo que da lugar a objetos compuestos.



• Hay dos enfoques para la creación de bases de datos orientadas a objetos: se pueden añadir los conceptos de la programación orientada a objetos a los lenguajes de bases de datos existentes o extender los lenguajes orientados a objetos existentes para que trabajen con las bases de datos añadiendo conceptos
como la persistencia y las colecciones. Las bases de datos relacionales extendidas adoptan el primer enfoque. Los lenguajes de programación persistentes adoptan el segundo.




Propiedades de las Bases de Datos orientadas a objetos:


Identidad del objeto. Los objetos tienen identidades únicas que son independientes de sus valores de atributo.

Constructores de tipos. Las estructuras de los objetos complejos se pueden construir aplicando recursivamente un conjunto de constructores básicos (tupla, conjunto, lista y bolsa).

Encapsulamiento de operaciones. Tanto la estructura del objeto como las operaciones que pueden
aplicarse a los objetos están incluidas en las definiciones de clase del objeto.

Compatibilidad con el lenguaje de programación. Los objetos persistentes y transitorios se manipulan sin problemas. Los objetos se hacen persistentes adjuntándolos a una colección persistente o denominándolos explícitamente.

Jerarquía de tipos y herencia. Los tipos de objetos pueden especificarse utilizando una jerarquía de tipos, que permite heredar los atributos y los métodos de los tipos definidos anteriormente. En algunos modelos se permite la herencia múltiple.

Extensiones. Todos los objetos persistentes de un tipo particular se pueden almacenar en una extensión. Las extensiones correspondientes a una jerarquía de tipos tienen implementadas restricciones de conjunto/subconjunto.

Soporte de objetos complejos. Los objetos complejos estructurados y no estructurados se pueden almacenar y manipular.

Polimorfismo y sobrecarga del operador. Los nombres de los métodos y las operaciones se pueden sobrecargar para que puedan aplicarse a diferentes tipos de objetos con implementaciones distintas.


Administración de Recursos


Es una actividad administrativa que aplica tecnologías de sistemas de información (como administración de base de datos, almacenes de datos y otras herramientas de administración de datos) a la tarea de administrar los recursos de datos de una organización, con el fin de satisfacer las necesidades de información de sus participantes de negocio.


Elementos lógicos de datos:


a) Archivo
Un grupo de registros relacionados es un archivo de datos, o tabla. Así, un archivo de empleados contendría los registros de los empleados de una empresa.

b) Base de datos
Una base de datos es una colección integrada de elementos de datos relacionados de manera lógica. La base de datos consolida los registros almacenados de antemano en archivos separados dentro de un grupo común de elementos de datos, el cual proporciona información para muchas aplicaciones.

c) Campo
Un campo consiste en una agrupación de caracteres relacionados. Por ejemplo, la agrupación de los caracteres alfabéticos del nombre de una persona que puede formar un campo de nombre.

d) Carácter
El elemento más básico de los datos lógicos es el carácter, que consiste en un símbolo único alfabético, numérico o de otro tipo.

e) Registro
Los campos relacionados de información se agrupan para formar un registro. Por eso, un registro representa una colección de atributos que describen una entidad.

viernes, 31 de agosto de 2012

Datos de presentación


Viernes 31 Agosto 2012


Alumno: Javier Eduardo Huamaní Portocarrero
Curso: Base de datos
Ciclo: 2012-2
Profesor: Luis Serna Jherry

Normalización desde la 1FN hasta la 4FN.







Cuarta Forma Normal (4FN). Fallas que presenta la 4FN.


La cuarta forma normal (4FN) es una forma normal usada en la normalización de bases de datos. La 4FN se asegura de que las dependencias multivaluadas independientes estén correcta y eficientemente representadas en un diseño de base de datos. La 4FN es el siguiente nivel de normalización después de la forma normal de Boyce-Codd (BCNF).
Una tabla está en 4FN si y solo si esta en Tercera forma normal o en BCNF (Cualquiera de ambas) y no posee dependencias multivaluadas no triviales. La definición de la 4FN confía en la noción de una dependencia multivaluada. Una tabla con una dependencia multivaluada es una donde la existencia de dos o más relaciones independientes muchos a muchos causa redundancia; y es esta redundancia la que es suprimida por la cuarta forma normal.

Fallas
Las Fallas que presenta la Cuarta Forma Normal (4FN) es que no reduce completamente la redundancia en la base de datos relacionales que guardan hechos multivalores. También que cada dependencia de unión no implica necesariamente las claves candidatas, quiere decir, que no siguen los criterios de clave.



Considerando la tabla anterior, cada fila indica que una tienda dado puede entregar una variedad dada de chocolates a un área dada. Note que debido a que la tabla tiene una clave única y ningún atributo no-clave, no viola ninguna forma normal hasta el BCNF. Pero debido a que las variedades de chocolate que una tienda ofrece son independientes de las áreas a las cuales la tienda envía, hay redundancia en la tabla: por ejemplo, nos dicen tres veces que A1 Chocolate ofrece la Corteza rellena, y si A1 Chocolate comienza a producir chocolates de Corteza de vainilla-chocolate entonces necesitaremos agregar múltiples registros, uno para cada una de las Áreas de envío de A1 Chocolate. En términos formales, esto se describe como que Variedad de chocolate está teniendo una dependencia multivalor en la tienda.

Para satisfacer la 4NF, debemos poner los hechos sobre las variedades de chocolates ofrecidas en una tabla diferente de los hechos sobre áreas de envío:



 En contraste, si las variedades de chocolate ofrecidas por una tienda a veces variaran de un área de envío a otra, la tabla original de las tres columnas satisfaría la 4FN.


Ejemplo1

   
Ejemplo2

Ejemplo3

  
Ejemplo4







Tercera Forma Normal (3FN). Fallas que presenta la 3FN


Una relación R esta en 3FN si esta en 2FN y si, y solo si, los atributos no llaves son independientes de cualquier otro atributo no llave primaria.Esto es lo mismo que decir que se deben eliminar las dependencias transitivas de atributos no llaves respecto a la llave primaria, estando ya la relación en 2FN.

Consiste en eliminar la dependencia transitiva que queda en una segunda forma normal, en pocas palabras una relación esta en tercera forma normal si está en segunda forma normal y no existen dependencias transitivas entre los atributos, nos referimos a dependencias transitivas cuando existe más de una forma de llegar a referencias a un atributo de una relación.



Fallas en la 3FN
Las fallas de la 3FN se dan por la posible existencia de un mismo atributo con muchos valores.






Otro ejemplo:  la relación tiene dos claves sobrepuestas (Nivel,Cargo) y (Nivel,Nombre), pero como el determinante de Cargo es Nombre pero este atributo Nombre no es una clave candidata.


 Ejemplo1

 Ejemplo2

Ejemplo3

 Ejemplo4





Segunda Forma Normal (2FN). Fallas que presenta la 2FN.


Una relación R se dice que esta en 2FN si esta en 1FN y si, y solo si, los atributos no llaves (ni primarias ni candidatas) de R, si los hubiese, son funcional y completamente dependientes de la llave primaria de R.
Entonces este segundo paso se aplica solo a relaciones con llaves compuestas, pues no es posible que en una relación cuya llave primaria sea simple (compuesta por un solo atributo) haya atributos que dependan de parte de la llame primaria. Una relación que este en 1FN y que tenga una llave primaria simple, esta en 2FN.

Problemas con la 2FN
Los defectos de almacenamiento de una relación 2FN son causados por la dependencia transitiva (DT) de atributos no-clave con la clave primaria.

Este es un ejemplo donde se muestra fallas en la 2FN, las cuales son acusadas por la DT de atributos dato no clave con la PK




Ejemplo 1
Tenemos los siguientes datos:


Pasamos estos datos a 1FN, enfocándonos en el atributo emails



 Ahora separamos las tablas para cumplir el DFC



 Ejemplo 2

 Ejemplo 3


 Ejemplo 4











Diferencia entre datos Normalizados en 1FN y el universo de datos no normalizados


En primer lugar, empezaremos definiendo a la normalización y su primera forma. La Normalización es la expresión formal del modo de realizar un buen diseño. Provee los medios necesarios para describir la estructura lógica de los datos en un sistema de información.  Las principales ventajas de la Normalización son: evitar anomalías, mejorar la independencia de los datos permitiendo realizar extensiones de la BD, afectando muy poco, o nada, a los programas de aplicación existentes que accesan la base de datos.

La Normalización involucra varias fases que se realizan en orden. La realización de la 2da fase supone que se ha concluido la 1ra y así sucesivamente. Las relaciones en la 1FN son un conjunto del universo de todas las relaciones posibles. Las relaciones 2FN son un subconjunto de las que están en 1FN y así sucesivamente, como se muestra en la figura.





Para que los datos cumplan con la 1FN deben cumplir los siguientes requisitos:



·         Una relación R se encuentra en 1FN si y solo sí por cada renglón columna contiene valores atómicos, es decir un atributo es atomico si los elementos del dominio son indivisibles, mínimos.
·         Las celdas de las tablas poseen valores simples y no se permiten grupos ni arreglos repetidos como valores, es decir, contienen un solo valor por cada celda.
·         Todos los ingresos en cualquier columna (atributo) deben ser del mismo tipo.
·         Cada columna debe tener un nombre único, el orden de las columnas en la tabla no es importante.
·         Dos filas o renglones de una misma tabla no deben ser idénticas, aunque el orden de las filas no es importante.



Teniendo en cuenta esto, la diferencia entre los datos normalizados en la 1FN y los datos del universo no normalizado  es que estos están atomizados, cada atributo no se repite, de esta forma no existen errores lógicos. Así mismo, los datos normalizados siguen normas que hacen el acceso a los datos de forma ordenada y sin errores. Los  datos no normalizados están organizados de una manera en la cual algunos atributos pueden mostrar mas de un dato en un campo o pueden estar algunos duplicados mostrando atributos repetidos, además de no estar agrupados por claves que identifiquen lo que representa la una tabla.

Ejemplo 1:

          Un error en datos no normalizados es por ejemplo en una tabla Persona que tiene como campos:                 
          DNI, Nombre, Direccion, telefono , en el atributo telefono se agregue 2 numeros de telefonos.




La 1FN evita los datos duplicados y nos cerciora que los valores de cualquier columna son del mismo tipo. La siguiente imagen muestra la tabla anterior llevada a la 1FN





Ejemplo 2
En este caso de la biblioteca, la PK es el CodLibro, quién determina a los demás atributos de la tabla.




Ejemplo 3
En este caso la PK es Código de Película  C_Pelicula




Ejemplo 4
En esta Tabla, la PK es el Nro_GI (número de guía) quién determina a los demás atributos de la tabla.