- :-)Sm!le...: PREGUNTAS QUE HACEN PARTE DEL PROCESO BD

ANTEPROYECTO


Uploaded on authorSTREAM by jasonarj

viernes, 23 de febrero de 2007

PREGUNTAS QUE HACEN PARTE DEL PROCESO BD

ARQUITECTURA DE LOS SISTEMAS DE BASES DE DATOS

Hay tres características importantes inherentes a los sistemas de bases de datos: la separación entre los programas de aplicación y los datos, el manejo de múltiples vistas por parte de los usuarios y el uso de un catálogo para almacenar el esquema de la base de datos.
En 1975, el comité ANSI-SPARC (American National Standard Institute - Standards Planning and Requirements Committee) propuso una arquitectura de tres niveles para los sistemas de bases de datos, que resulta muy útil a la hora de conseguir estas tres características. El objetivo de la arquitectura de tres niveles es el de separar los programas de aplicación de la base de datos física. En esta arquitectura, el esquema de una base de datos se define en tres

Niveles de Abstracción Distintos:

En el nivel interno se describe la estructura física de la base de datos mediante un esquema interno. Este esquema se especifica mediante un modelo físico y describe todos los detalles para el almacenamiento de la base de datos, así como los métodos de acceso.
En el nivel conceptual se describe la estructura de toda la base de datos para una comunidad de usuarios (todos los de una empresa u organización), mediante un esquema conceptual. Este esquema oculta los detalles de las estructuras de almacenamiento y se concentra en describir entidades, atributos, relaciones, operaciones de los usuarios y restricciones. En este nivel se puede utilizar un modelo conceptual o un modelo lógico para especificar el esquema.
En el nivel externo se describen varios esquemas externos o vistas de usuario. Cada esquema externo describe la parte de la base de datos que interesa a un grupo de usuarios determinado y oculta a ese grupo el resto de la base de datos. En este nivel se puede utilizar un modelo conceptual o un modelo lógico para especificar los esquemas.
La mayoría de los SGBD no distinguen del todo los tres niveles. Algunos incluyen detalles del nivel físico en el esquema conceptual. En casi todos los SGBD que se manejan vistas de usuario, los esquemas externos se especifican con el mismo modelo de datos que describe la información a nivel conceptual, aunque en algunos se pueden utilizar diferentes modelos de datos en los niveles conceptual y externo.

Hay que destacar que los tres esquemas no son más que descripciones de los mismos datos pero con distintos niveles de abstracción. Los únicos datos que existen realmente están a nivel físico, almacenados en un dispositivo como puede ser un disco. En un SGBD basado en la arquitectura de tres niveles, cada grupo de usuarios hace referencia exclusivamente a su propio esquema externo. Por lo tanto, el SGBD debe transformar cualquier petición expresada en términos de un esquema externo a una petición expresada en términos del esquema conceptual, y luego, a una petición en el esquema interno, que se procesará sobre la base de datos almacenada. Si la petición es de una obtención (consulta) de datos, será preciso modificar el formato de la información extraída de la base de datos almacenada, para que coincida con la vista externa del usuario. El proceso de transformar peticiones y resultados de un nivel a otro se denomina correspondencia o transformación. Estas correspondencias pueden requerir bastante tiempo, por lo que algunos SGBD no cuentan con vistas externas.

La arquitectura de tres niveles es útil para explicar el concepto de independencia de datos que podemos definir como la capacidad para modificar el esquema en un nivel del sistema sin tener que modificar el esquema del nivel inmediato superior. Se pueden definir dos tipos de

INDEPENDENCIA DE DATOS:
La independencia lógica es la capacidad de modificar el esquema conceptual sin tener que alterar los esquemas externos ni los programas de aplicación. Se puede modificar el esquema conceptual para ampliar la base de datos o para reducirla. Si, por ejemplo, se reduce la base de datos eliminando una entidad, los esquemas externos que no se refieran a ella no deberán verse afectados. La independencia física es la capacidad de modificar el esquema interno sin tener que alterar el esquema conceptual (o los externos). Por ejemplo, puede ser necesario reorganizar ciertos ficheros físicos con el fin de mejorar el rendimiento de las operaciones de consulta o de actualización de datos. Dado que la independencia física se refiere sólo a la separación entre las aplicaciones y las estructuras físicas de almacenamiento, es más fácil de conseguir que la independencia lógica.

En los SGBD que tienen la arquitectura de varios niveles es necesario ampliar el catálogo o diccionario, de modo que incluya información sobre cómo establecer la correspondencia entre las peticiones de los usuarios y los datos, entre los diversos niveles. El SGBD utiliza una serie de procedimientos adicionales para realizar estas correspondencias haciendo referencia a la información de correspondencia que se encuentra en el catálogo. La independencia de datos se consigue porque al modificarse el esquema en algún nivel, el esquema del nivel inmediato superior permanece sin cambios, sólo se modifica la correspondencia entre los dos niveles. No es preciso modificar los programas de aplicación que hacen referencia al esquema del nivel superior.

Por lo tanto, la arquitectura de tres niveles puede facilitar la obtención de la verdadera independencia de datos, tanto física como lógica. Sin embargo, los dos niveles de correspondencia implican un gasto extra durante la ejecución de una consulta o de un programa, lo cual reduce la eficiencia del SGBD. Es por esto que muy pocos SGBD han implementado esta arquitectura completa.

BASES DE DATOS DISTRIBUIDAS- FRAGMENTACIÓN

Un fragmento es una porción lógica de relaciones globales. Los fragmentos están físicamente localizados en uno o más sitios de la red.
Un fragmento está definido por una expresión del álgebra relacional que toma relaciones globales como operandos y produce un fragmento.Condiciones para definir fragmentos:
Completitud (Completness)
Reconstrucción (Reconstruction)
Disyunción (Disjoitness)
Bases De Datos Distribuidas-Criterios

COMPLETITUD: Si una relación R esta descompuesta en fragmentos R1, R2, ...Rn, cada elemento que puede encontrarse en R también se encuentra en 1 o más Ri’s, 1<= i <= n (No hay pérdida de información)Reconstrucción: Si una relación R está descompuesta en fragmentos R1, R2, ...Rn, debe ser posible definir un operador relacional Ñ tal que R = Ñ Ri " Ri Î FR(Preservación de dependencias)

DISYUNCION: Si una relación R está horizontalmente descompuesta en fragmentos R1, R2, ...Rn, y un elemento di está incluido en un fragmento Rj, entonces di no existe en ningún otro fragmento Rk .

Fragmentación Horizontal No Tiene Mismo Conjunto De Tuplas Si la relación R está verticalmente descompuesta esta regla excluye los atributos que forman la llave primaria (i.e., atributos de la llave primaria aparecen en todos los fragmentos)

FRAGMENTACIÓN HORIZONTAL (HF)
Parte tuplas de una relación global en subconjuntosDefinidos por una operación de selección, llamada calificación, sobre una relación global.

EJEMPLO
Considere la relación global equipos de béisbol EQUIPO(NomEquipo, Liga, Localidad, Entrenador)Esta relación global puede ser fragmentada horizontalmente basándose en el valor del atributo Liga:EQUIPO A = s liga=americana EQUIPOEQUIPO N =s liga=nacional EQUIPO
BASES DE DATOS DISTRIBUIDAS FRAGMENTACIÓN HORIZONTAL DERIVADA (Dhf):Fragmentación que se deriva de la fragmentación horizontal de otra relaciónEjemplo: Considere la relación global de jugadores de béisbolJUGADOR(RFC, NombreJ, NombreE, Posición, Contrato, Salario)Esta fragmentación global puede también ser fragmentada horizontalmente basada en la liga en la cual el jugador participa. La liga sin embargo no es un atributo de jugador.Jugador A= JUGADOR SJ NombreE = NomEquipo EQUIPO A Jugador N= JUGADOR SJ NombreE = NomEquipo EQUIPO N

BASES DE DATOS DISTRIBUIDAS FRAGMENTACIÓN VERTICAL (VF):

Fragmenta una relación global a través de la proyección de atributos.Ejemplo: Considere la relación global de jugadores de béisbolJUGADOR(RFC, NombreJ, NombreE, Posición, Contrato, Salario)Esta relación pude ser fragmentada verticalmente de la siguiente forma:

Jugador1= p RFC, NombreJ, NombreE, Posición JUGADORJugador2= p RFC, Contrato, Salario JUGADOR

La operación de reconstrucción es:JUGADOR = Jugador1 join Jugador2Note que esta fragmentación no puede ser disjunta dado que la llave de la relación global debe aparecer en los fragmentos para efectos de reconstrucción.

BASES DE DATOS DISTRIBUIDAS FRAGMENTACIÓN MIXTA:


Generada a través de la aplicación recursiva de operadores del álgebra relacional en los fragmentos.Ejemplo: Considere (una vez mas!!) la relación global de jugadores de béisbolJUGADOR(RFC, NombreJ, NombreE, Posición, Contrato, Salario)Después de la fragmentación vertical en
Jugador1= p RFC, NombreJ, NombreE, Posición JUGADORJugador2= p RFC, Contrato, Salario JUGADORJugador1 puede tener una fragmentación horizontal derivada basada en la liga en la que juega el jugadorJugador1.A= Jugador1 SJ EQUIPOA SJ= SemiJoinJugador1.N= Jugador1 SJ EQUIPON

ALOJAMIENTO DE FRAGMENTOS
Objetivo: Minimizar el número de accesos remotos que son realizados por las aplicaciones distribuidas

NO REDUNDANTE: Un fragmento es alojado en exactamente un sitio. Técnica de "best fit" usando alguna métrica, alojar el fragmento en el sitio que tiene la mejor métrica.

REDUNDANTE: Opción más compleja debido a la replicación de fragmentos y a la selección de los sitios para accesar los fragmentos."All benefical Sites": Alojar el fragmento a cada sitio donde el el beneficio de alojar una copia a ese sitio es más alto que su costo"Additional Replication" : empezar con "best fit" y agregar una replicación hasta que no ya nos benéfico asignar fragmentos

TRANSACCIONES (MOTOR DE LA BASE DE DATOS)
Una transacción es una secuencia de operaciones realizadas como una sola unidad lógica de trabajo. Una unidad lógica de trabajo debe exhibir cuatro propiedades, conocidas como propiedades de atomicidad, coherencia, aislamiento y durabilidad (ACID), para ser calificada como transacción.

ATOMICIDAD: Una transacción debe ser una unidad atómica de trabajo, tanto si se realizan todas sus modificaciones en los datos, como si no se realiza ninguna de ellas.COHERENCIA: Cuando finaliza, una transacción debe dejar todos los datos en un estado coherente. En una base de datos relacional, se deben aplicar todas las reglas a las modificaciones de la transacción para mantener la integridad de todos los datos. Todas las estructuras internas de datos, como índices de árbol b o listas doblemente vinculadas, deben estar correctas al final de la transacción.

AISLAMIENTO: Las modificaciones realizadas por transacciones simultáneas se deben aislar de las modificaciones llevadas a cabo por otras transacciones simultáneas. Una transacción reconoce los datos en el estado en que estaban antes de que otra transacción simultánea los modificara o después de que la segunda transacción haya concluido, pero no reconoce un estado intermedio. Esto se conoce como seriabilidad, ya que deriva en la capacidad de volver a cargar los datos iniciales y reproducir una serie de transacciones para finalizar con los datos en el mismo estado en que estaban después de realizar las transacciones originales.

DURABILIDAD: Una vez concluida una transacción, sus efectos son permanentes en el sistema. Las modificaciones persisten aún en el caso de producirse un error del sistema. SERIALIDAD: Toda transacción en una base de datos debe tener un orden, debe ser continuo para evitar errores una transacción debe seguir después de otra culminada y realizada.Los programadores de SQL son los responsables de iniciar y finalizar las transacciones en puntos que exijan la coherencia lógica de los datos. El programador debe definir la secuencia de modificaciones de datos que los dejan en un estado coherente en relación con las reglas corporativas de la organización. El programador incluye estas instrucciones de modificación en una sola transacción de forma que SQL Server 2005 Database Engine (Motor de base de datos de SQL Server 2005) puede exigir la integridad física de la misma.
Es responsabilidad de un sistema de base de datos corporativo, como una instancia de Database Engine (Motor de base de datos), proporcionar los mecanismos que aseguren la integridad física de cada transacción. Database Engine (Motor de base de datos) proporciona:Servicios de bloqueo que preservan el aislamiento de la transacción.
Servicios de registro que aseguran la durabilidad de la transacción. Aunque se produzca un error en el hardware del servidor, el sistema operativo o la instancia de Database Engine (Motor de base de datos), la instancia utiliza registros de transacciones, al reiniciar, para revertir automáticamente las transacciones incompletas al punto en que se produjo el error del sistema.Características de administración de transacciones que exigen la atomicidad y coherencia de la transacción. Una vez iniciada una transacción, debe concluirse correctamente; en caso contrario, la instancia de Database Engine (Motor de base de datos) deshará todas las modificaciones de datos realizadas desde que se inició la transacción.

CONTROL DE CONCURRENCIA EN BD DISTRIBUIDAS.

(candados)lock candados de lectura y candados de escritura
El problema de concurrencia en las bases de datos distribuidas se presenta porque pueden existir múltiples copias de un item de datos almacenadas en diferentes nodos, y se debe garantizar que las copias son idénticas; igualmente debe asegurarse que la lectura de una de estas copias es consistente –su integridad-.Se asume que las transacciones son de ejecución en dos fases y que existe seriabilidad y atomicidad local para las transacciones; sin embargo, los RLOCKS y WLOCKS deberán asegurar seriabilidad en el ambiente distribuido (una violación a la seriabilidad podría presentarse si existen dos transacciones teniendo un RLOCK una, y un WLOCK la otra, al mismo tiempo sobre el mismo item de datos).Una de las estratégias de control consiste en asociar un bloqueo con cada copia del item de datos, y en otorgar o negar los bloqueos a cada transacción que requiera un RLOCK o WLOCK desde cada sitio de la copia. Debido a que el DBMS distribuido deberá ver los bloqueos sobre los items de datos en una forma global y no sobre las copias, se ha definido una regla para convertir los bloqueos sobre las copias en bloqueos sobre los items de datos, así:
Una transacción tiene un RLOCK sobre un item A, cuando ella tiene otorgado un RLOCK sobre cualquiera de las copias de A.
Una transacción tiene un WLOCK sobre un item A, cuando ella tiene otorgado un WLOCK sobre todas las copias de A.

Las reglas para otorgar o negar bloqueos son las mismas que para bases de datos centralizadas; se puede otorgar un RLOCK si ninguna otra transacción tiene un WLOCK en la copia, y se puede otorgar un WLOCK si ninguna otra transacción tiene un RLOCK o WLOCK. El efecto de esto es que dos (2) transacciones no pueden obtener un bloqueo de escritura y de lectura sobre el mismo item en el mismo momento. Este método garantiza que si el número de nodos n=1, entonces el sistema se comporta como si fuera el único sitio existente -DB centralizada-.Si uno o más sitios niegan un requerimiento de bloqueo, entonces el bloque sobre el item es negado. Para evitar abrazos mortales, las transacciones deben informar los desbloqueos a cada uno de los sitios que otorgaron un bloqueo, en caso contrario dos transacciones podrían estar indefinidamente esperando por la liberación de un item que la otra tiene bloqueado.

No hay comentarios:

MODELO DE CASCADA

MODELO DE CASCADA

MODELO EN ESPIRAL

MODELO EN ESPIRAL

MODELO LINEAL

MODELO LINEAL

MODELO INCREMENTAL

MODELO INCREMENTAL

MODELO PROTOTIPADO

MODELO PROTOTIPADO

CICLOS DE VIDA DE SOFTWARE

CICLOS DE VIDA DE SOFTWARE

DIRECTORIO NOVASOFT