DEJA TUS COMENTARIOS

................................................AQUÍ.......................................................

febrero 24, 2007

GUIA 1

GUIA 1


1. TRANSACCIONES


CONCEPTO DE TRANSACCIONES


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.


PROPIEDADES DE TRANSACCION


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.
Serialidad: Es la propiedad que garantiza que un plan de ejecución concurrente es equivalente al secuencial es decir 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.

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 terminada la transacción, los cambios realizados en la base de datos deben quedar almacenados en la base y evitar su pérdida. Para cumplir con las propiedades, se implementaros en el sistema de base de datos las BITÁCORAS y las listas de commit y rollback. Cada que se ejecuta la transacción, almacena en la bitácora el identificador de la transacción, los datos a procesar, tanto en sus valores iniciales, como los valores resultado del proceso y la finalización de la transacción. Si en algún momento, el sistema se cae, revisa la bitácora y carga cada transacción y cada operación en una lista llamada LISTA DE ROLLBACK. Va leyendo la bitácora y pasando los valores a dicha lista. Sí, encuentra el registro de terminación de transacción, pasa todos los registros leidos de dicha transacción a la LISTA DE COMMIT. Luego de terminar de revisar la bitácora, toma la Lista de commit y procesa las transacciones incluidas allí para modificar los datos y alterar la base de datos. Revisa la lista de Rollback y deja los valores en su estado inicial, para que sean reenviadas las transacciones que está en esta lista, ya que se rechazan.

3. BITÁCORAS


Un blog, también conocido como weblog o cuaderno de bitácora (listado de sucesos), es un sitio web periódicamente actualizado que recopila cronológicamente textos o artículos de uno o varios autores, apareciendo primero el más reciente, donde el autor conserva siempre la libertad de dejar publicado lo que crea pertinente. Habitualmente, en cada artículo, los lectores pueden escribir sus comentarios y el autor darles respuesta, de forma que es posible establecer un diálogo. El uso o temática de cada weblog es particular, los hay de tipo personal, periodístico, empresarial o corporativo, tecnológico, educativo (edublogs), etc.


4. 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.


5. PROTOCOLO DE DOS FASES

Este protocolo permite al sistema saber que tipo de acción realizar ante el desarrollo de una transacción. El protocolo tiene, como su nombre lo indica, dos fases.
En la primera fase, conocida como fase Ready, el sistema permite a la transacción comenzar a ejecutarse; quedando a la espera de la respuesta de si pudo terminar o no las diferentes actividades que se involucran en la transacción. Si la respuesta de la transacción es "Termine", el protocolo sabe que el resultado hay que almacenarlo por lo que da COMMIT. Sí el resultado es "No pude terminar", el protocolo hace ROLLBACK a la transacción.
Existe además formas externas para asegurar la disponibilidad de los datos. Estas estrategias son, los procesos de backup y el manejo de discos especiales que permitan la recuperación de los datos (ej. Sistemas raid 5)

6. REGISTRO Y RECUPERACIÓN DE BD

El registro de transacciones es una secuencia de registros que guarda los cambios producidos en la base de datos desde el punto en el que ésta se creó hasta el momento actual. Cada operación registrada crea a su vez un registro de dicha operación. Estos registros generados por la transacción se graban en el disco cuando ésta se confirma. Por el contrario, las páginas de datos modificadas por la transacción no se graban inmediatamente en el disco, sino que se retienen en la caché del búfer de SQL Server y se guardan posteriormente. Este retraso en la escritura de los datos en el disco permite maximizar la eficacia de los accesos múltiples a las páginas de datos y evita las interrupciones en las exploraciones. Forzar el registro en el disco garantiza que no se pierda ningún trabajo confirmado en caso de un error grave en el servidor.

Con la recuperación se asegura que la base de datos es coherente desde el punto de vista transaccional como paso previo a su presentación en línea. Se dice que una base de datos es coherente de forma transaccional cuando presenta todo el trabajo confirmado y ha deshecho el no confirmado. El registro siempre define la vista correcta de la base de datos. En resumen, la recuperación es el proceso de hacer que los datos sean coherentes con el registro de las transacciones en un momento dado.
La recuperación se lleva a cabo de forma automática cuando se inicia SQL Server, cuando se tiene acceso a una base de datos o como paso final en la restauración de una base de datos desde la copia de seguridad. El primero de los casos, cuando la recuperación se realiza cuando se inicia SQL Server, se denomina recuperación de reinicio ("restartstartup recovery"). La recuperación desde las copias de seguridad se debe normalmente a un error del disco. Este tipo de recuperación se denomina recuperación de medios ("media recovery").
La recuperación de reinicio es automática y siempre recupera al momento dado más reciente. En el caso de la recuperación desde copias de seguridad, el administrador de la base de datos puede elegir la recuperación a un momento anterior.
La recuperación de reinicio tiene lugar de forma automática cada vez que se inicia una instancia de SQL Server y consiste en deshacer cualquier transacción que haya quedado incompleta la última vez que se cerró la instancia. En el caso de la recuperación desde copias de seguridad, el administrador de la base de datos puede elegir la recuperación a un momento anterior. Esto está sujeto a limitaciones.


LA RECUPERACIÓN CONSTA DE DOS FASES

  1. Se rehacen todos los cambios hasta que se encuentra el momento dado de destino en el registro de transacciones.
  2. Se deshace todo el trabajo realizado por las transacciones que estaban activas en el momento en el que se detuvo la acción de rehacer.
    SQL Server utiliza puntos de control para acelerar la recuperación de reinicio.


El backup



dump o copia de respaldo de una base de datos puede hacerse a través de phpMyAdmin, del Admin del foro, de mySQL, etc... pero sea cual fuere el medio que se utilice, hay que configurar parámetros.
Para facilitar la cosa y evitar -en una tarea repetitiva como es un backup- tener que configurar parámetros cada vez, he creado este par de scripts complementarios que son el colmo de la simplificación: Dump y Download la Base de Datos - Restore la Base de Datos que, con un simple click son capaces de hacer lo que su propio nombre indica.
Su preparación es sencilla: 1.- Configurar en ambos scripts las cuatro variables: $db_server = "la dirección de base de datos: mysql.webcindario.com o localhost o..."; $db_name = "el nombre de la base de datos"; $db_username = "el usuario"; $db_password = "el password"; 2.- Crear en el server una carpeta con privilegios de escritura. 3.- Subir a esa carpeta ambos scripts. Su Funcionamiento Es Simple: Dump y Download la Base de Datos:

  • Cada vez que se lanza el script, se borra la estructura de la base de datos y se restituye el contenido del dump que, con nombre igual al de la base de datos y extensión '.gz' o '.sql' según tenga el server o no, capacidad de compresión, respectivamente, está en la misma carpeta que el script.
  • Cada vez que se lanza el script, se crea el Dump de la Base de Datos completa. - El Dump se crea comprimido si el servidor tiene capacidad para ello. - El Dump se crea con el nombre de la base de datos y extensión '.gz' o '.sql' según tenga el server o no, capacidad de compresión, respectivamente.
  • El Dump creado se salva en la misma carpeta en que está el script.
  • El Dump puede descargarse del server al ordenador desde la misma ventana del navegador.
  • Cuando se lanza el script, no se obtiene el resultado en la ventana del navegador hasta que el dump finaliza. Eso significa que con una gran base de datos sin comprimir de 1000 Mb (1 Gb), por ejemplo, el resultado tardará en aparecer tres minutos aprox., dependiendo de la velocidad del server. - Cuando se lanza el script, no cerrar ni hacer nada con esa ventana del navegador, hasta que el script concluya y muestre el resultado.

febrero 23, 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 ABSTRACCION 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 subconjuntos
Definidos 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 EQUIPO
EQUIPO 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ón
Ejemplo: Considere la relación global de jugadores de béisbol
JUGADOR(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éisbol
JUGADOR(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 JUGADOR
Jugador2= p RFC, Contrato, Salario JUGADOR


La operación de reconstrucción es:
JUGADOR = Jugador1 join Jugador2
Note 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éisbol
JUGADOR(RFC, NombreJ, NombreE, Posición, Contrato, Salario)
Después de la fragmentación vertical en


Jugador1= p RFC, NombreJ, NombreE, Posición JUGADOR
Jugador2= p RFC, Contrato, Salario JUGADOR
Jugador1 puede tener una fragmentación horizontal derivada basada en la liga en la que juega el jugador
Jugador1.A= Jugador1 SJ EQUIPOA SJ= SemiJoin
Jugador1.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.


MACRO ALGORITMO DEL PROTOCOLO DE DOS FASES



Registro Y Recuperación De BD:

El registro de transacciones es una secuencia de registros que guarda los cambios producidos en la base de datos desde el punto en el que ésta se creó hasta el momento actual. Cada operación registrada crea a su vez un registro de dicha operación. Estos registros generados por la transacción se graban en el disco cuando ésta se confirma. Por el contrario, las páginas de datos modificadas por la transacción no se graban inmediatamente en el disco, sino que se retienen en la caché del búfer de SQL Server y se guardan posteriormente. Este retraso en la escritura de los datos en el disco permite maximizar la eficacia de los accesos múltiples a las páginas de datos y evita las interrupciones en las exploraciones. Forzar el registro en el disco garantiza que no se pierda ningún trabajo confirmado en caso de un error grave en el servidor.

Con la recuperación se asegura que la base de datos es coherente desde el punto de vista transaccional como paso previo a su presentación en línea. Se dice que una base de datos es coherente de forma transaccional cuando presenta todo el trabajo confirmado y ha deshecho el no confirmado. El registro siempre define la vista correcta de la base de datos. En resumen, la recuperación es el proceso de hacer que los datos sean coherentes con el registro de las transacciones en un momento dado.

La recuperación se lleva a cabo de forma automática cuando se inicia SQL Server, cuando se tiene acceso a una base de datos o como paso final en la restauración de una base de datos desde la copia de seguridad. El primero de los casos, cuando la recuperación se realiza cuando se inicia SQL Server, se denomina recuperación de reinicio ("restartstartup recovery"). La recuperación desde las copias de seguridad se debe normalmente a un error del disco. Este tipo de recuperación se denomina recuperación de medios ("media recovery").

La recuperación de reinicio es automática y siempre recupera al momento dado más reciente. En el caso de la recuperación desde copias de seguridad, el administrador de la base de datos puede elegir la recuperación a un momento anterior.

La recuperación de reinicio tiene lugar de forma automática cada vez que se inicia una instancia de SQL Server y consiste en deshacer cualquier transacción que haya quedado incompleta la última vez que se cerró la instancia. En el caso de la recuperación desde copias de seguridad, el administrador de la base de datos puede elegir la recuperación a un momento anterior. Esto está sujeto a limitaciones.
La recuperación consta de dos fases:
  1. Se rehacen todos los cambios hasta que se encuentra el momento dado de destino en el registro de transacciones.
  2. Se deshace todo el trabajo realizado por las transacciones que estaban activas en el momento en el que se detuvo la acción de rehacer. SQL Server utiliza puntos de control para acelerar la recuperación de reinicio.


El backup


dump o copia de respaldo de una base de datos puede hacerse a través de phpMyAdmin, del Admin del foro, de mySQL, etc... pero sea cual fuere el medio que se utilice, hay que configurar parámetros.
Para facilitar la cosa y evitar -en una tarea repetitiva como es un backup- tener que configurar parámetros cada vez, he creado este par de scripts complementarios que son el colmo de la simplificación: Dump y Download la Base de Datos - Restore la Base de Datos que, con un simple click son capaces de hacer lo que su propio nombre indica.
Su preparación es sencilla: 1.- Configurar en ambos scripts las cuatro variables: $db_server = "la dirección de base de datos: mysql.webcindario.com o localhost o..."; $db_name = "el nombre de la base de datos"; $db_username = "el usuario"; $db_password = "el password"; 2.- Crear en el server una carpeta con privilegios de escritura. 3.- Subir a esa carpeta ambos scripts. Su Funcionamiento Es Simple: 1.- Dump y Download la Base de Datos:

  • Cada vez que se lanza el script, se borra la estructura de la base de datos y se restituye el contenido del dump que, con nombre igual al de la base de datos y extensión '.gz' o '.sql' según tenga el server o no, capacidad de compresión, respectivamente, está en la misma carpeta que el script.
  • Cada vez que se lanza el script, se crea el Dump de la Base de Datos completa. - El Dump se crea comprimido si el servidor tiene capacidad para ello. - El Dump se crea con el nombre de la base de datos y extensión '.gz' o '.sql' según tenga el server o no, capacidad de compresión, respectivamente. - El Dump creado se salva en la misma carpeta en que está el script.
  • El Dump puede descargarse del server al ordenador desde la misma ventana del navegador.
  • Cuando se lanza el script, no se obtiene el resultado en la ventana del navegador hasta que el dump finaliza. Eso significa que con una gran base de datos sin comprimir de 1000 Mb (1 Gb), por ejemplo, el resultado tardará en aparecer tres minutos aprox., dependiendo de la velocidad del server. - Cuando se lanza el script, no cerrar ni hacer nada con esa ventana del navegador, hasta que el script concluya y muestre el resultado.
    RAID (Redundant array of independent disks)

ARREGLO REDUNDANTE DE DISCOS INDEPENDIENTES



Un RAID o un array de discos se utiliza para proteger las bases de datos de posibles fallas, en estos arreglos se clasifican los discos de acuerdo a un ordenamiento lógico y físico de prioridad tanto para acceso como para respaldo.


Niveles De RAIDLa elección de los diferentes niveles de RAID va a depender de las necesidades del usuario en lo que respecta a factores como seguridad, velocidad, capacidad, coste, etc. Cada nivel de RAID ofrece una combinación específica de tolerancia a fallos (redundancia), rendimiento y coste, diseñadas para satisfacer las diferentes necesidades de almacenamiento. La mayoría de los niveles RAID pueden satisfacer de manera efectiva sólo uno o dos de estos criterios. No hay un nivel de RAID mejor que otro; cada uno es apropiado para determinadas aplicaciones y entornos informáticos. De hecho, resulta frecuente el uso de varios niveles RAID para distintas aplicaciones del mismo servidor. Oficialmente existen siete niveles diferentes de RAID (0-6), definidos y aprobados por el el RAID Advisory Board (RAB). Luego existen las posibles combinaciones de estos niveles (10, 50, ...). Los niveles RAID 0, 1, 0+1 y 5 son los más populares.


RAID 0: Disk Striping "La más alta transferencia, pero sin tolerancia a fallos".
También conocido como "separación ó fraccionamiento/ Striping". Los datos se desglosan en pequeños segmentos y se distribuyen entre varias unidades. Este nivel de "array" o matriz no ofrece tolerancia al fallo. Al no existir redundancia, RAID 0 no ofrece ninguna protección de los datos. El fallo de cualquier disco de la matriz tendría como resultado la pérdida de los datos y sería necesario restaurarlos desde una copia de seguridad. Por lo tanto, RAID 0 no se ajusta realmente al acrónimo RAID. Consiste en una serie de unidades de disco conectadas en paralelo que permiten una transferencia simultánea de datos a todos ellos, con lo que se obtiene una gran velocidad en las operaciones de lectura y escritura. La velocidad de transferencia de datos aumenta en relación al número de discos que forman el conjunto. Esto representa una gran ventaja en operaciones secuenciales con ficheros de gran tamaño. Por lo tanto, este array es aconsejable en aplicaciones de tratamiento de imágenes, audio, video o CAD/CAM, es decir, es una buena solución para cualquier aplicación que necesite un almacenamiento a gran velocidad pero que no requiera tolerancia a fallos. Se necesita un mínimo de dos unidades de disco para implementar una solución RAID 0.

RAID 1: Mirroring "Redundancia. Más rápido que un disco y más seguro"
También llamado "Mirroring" o "Duplicación" (Creación de discos en espejo). Se basa en la utilización de discos adicionales sobre los que se realiza una copia en todo momento de los datos que se están modificando. RAID 1 ofrece una excelente disponibilidad de los datos mediante la redundancia total de los mismos. Para ello, se duplican todos los datos de una unidad o matriz en otra. De esta manera se asegura la integridad de los datos y la tolerancia al fallo, pues en caso de avería, la controladora sigue trabajando con los discos no dañados sin detener el sistema. Los datos se pueden leer desde la unidad o matriz duplicada sin que se produzcan interrupciones. RAID 1 es una alternativa costosa para los grandes sistemas, ya que las unidades se deben añadir en pares para aumentar la capacidad de almacenamiento. Sin embargo, RAID 1 es una buena solución para las aplicaciones que requieren redundancia cuando hay sólo dos unidades disponibles. Los servidores de archivos pequeños son un buen ejemplo. Se necesita un mínimo de dos unidades para implementar una solución RAID 1.



RAID 0+1/ RAID 0/1 ó RAID 10: "Ambos mundos"
Combinación de los arrays anteriores que proporciona velocidad y tolerancia al fallo simultáneamente. El nivel de RAID 0+1 fracciona los datos para mejorar el rendimiento, pero también utiliza un conjunto de discos duplicados para conseguir redundancia de datos. Al ser una variedad de RAID híbrida, RAID 0+1 combina las ventajas de rendimiento de RAID 0 con la redundancia que aporta RAID 1. Sin embargo, la principal desventaja es que requiere un mínimo de cuatro unidades y sólo dos de ellas se utilizan para el almacenamiento de datos. Las unidades se deben añadir en pares cuando se aumenta la capacidad, lo que multiplica por dos los costes de almacenamiento. El RAID 0+1 tiene un rendimiento similar al RAID 0 y puede tolerar el fallo de varias unidades de disco. Una configuración RAID 0+1 utiliza un número par de discos (4, 6, 8) creando dos bloques. Cada bloque es una copia exacta del otro, de ahí RAID 1, y dentro de cada bloque la escritura de datos se realiza en modo de bloques alternos, el sistema RAID 0. RAID 0+1 es una excelente solución para cualquier uso que requiera gran rendimiento y tolerancia a fallos, pero no una gran capacidad. Se utiliza normalmente en entornos como servidores de aplicaciones, que permiten a los usuarios acceder a una aplicación en el servidor y almacenar datos en sus discos duros locales, o como los servidores web, que permiten a los usuarios entrar en el sistema para localizar y consultar información. Este nivel de RAID es el más rápido, el más seguro, pero por contra el más costoso de implementar.

RAID 2: "Acceso paralelo con discos especializados. Redundancia a través del código
Hamming"
El RAID nivel 2 adapta la técnica comúnmente usada para detectar y corregir errores en memorias de estado sólido. En un RAID de nivel 2, el código ECC (Error Correction Code) se intercala a través de varios discos a nivel de bit. El método empleado es el Hamming. Puesto que el código Hamming se usa tanto para detección como para corrección de errores (Error Detection and Correction), RAID 2 no hace uso completo de las amplias capacidades de detección de errores contenidas en los discos. Las propiedades del código Hamming también restringen las configuraciones posibles de matrices para RAID 2, particularmente el cálculo de paridad de los discos. Por lo tanto, RAID 2 no ha sido apenas implementado en productos comerciales, lo que también es debido a que requiere características especiales en los discos y no usa discos estándares.Debido a que es esencialmente una tecnología de acceso paralelo, RAID 2 está más indicado para aplicaciones que requieran una alta tasa de transferencia y menos conveniente para aquellas otras que requieran una alta tasa de demanda I/O.

RAID 3: "Acceso síncrono con un disco dedicado a paridad"
Dedica un único disco al almacenamiento de información de paridad. La información de ECC (Error Checking and Correction) se usa para detectar errores. La recuperación de datos se consigue calculando el O exclusivo (XOR) de la información registrada en los otros discos. La operación I/O accede a todos los discos al mismo tiempo, por lo cual el RAID 3 es mejor para sistemas de un sólo usuario con aplicaciones que contengan grandes registros.
RAID 3 ofrece altas tasas de transferencia, alta fiabilidad y alta disponibilidad, a un coste intrínsicamente inferior que un Mirroring (RAID 1). Sin embargo, su rendimiento de transacción es pobre porque todos los discos del conjunto operan al unísono.
Se necesita un mínimo de tres unidades para implementar una solución RAID 3.

RAID 4: "Acceso Independiente con un disco dedicado a paridad."
Basa su tolerancia al fallo en la utilización de un disco dedicado a guardar la información de paridad calculada a partir de los datos guardados en los otros discos. En caso de avería de cualquiera de las unidades de disco, la información se puede reconstruir en tiempo real mediante la realización de una operación lógica de O exclusivo. Debido a su organización interna, este RAID es especialmente indicado para el almacenamiento de ficheros de gran tamaño, lo cual lo hace ideal para aplicaciones gráficas donde se requiera, además, fiabilidad de los datos. Se necesita un mínimo de tres unidades para implementar una solución RAID 4. La ventaja con el RAID 3 está en que se puede acceder a los discos de forma individual.

RAID 5: "Acceso independiente con paridad distribuida."
Este array ofrece tolerancia al fallo, pero además, optimiza la capacidad del sistema permitiendo una utilización de hasta el 80% de la capacidad del conjunto de discos. Esto lo consigue mediante el cálculo de información de paridad y su almacenamiento alternativo por bloques en todos los discos del conjunto. La información del usuario se graba por bloques y de forma alternativa en todos ellos. De esta manera, si cualquiera de las unidades de disco falla, se puede recuperar la información en tiempo real, sobre la marcha, mediante una simple operación de lógica de O exclusivo, sin que el servidor deje de funcionar.
Así pues, para evitar el problema de cuello de botella que plantea el RAID 4 con el disco de comprobación, el RAID 5 no asigna un disco específico a esta misión sino que asigna un bloque alternativo de cada disco a esta misión de escritura. Al distribuir la función de comprobación entre todos los discos, se disminuye el cuello de botella y con una cantidad suficiente de discos puede llegar a eliminarse completamente, proporcionando una velocidad equivalente a un RAID 0.RAID 5 es el nivel de RAID más eficaz y el de uso preferente para las aplicaciones de servidor básicas para la empresa. Comparado con otros niveles RAID con tolerancia a fallos, RAID 5 ofrece la mejor relación rendimiento-coste en un entorno con varias unidades. Gracias a la combinación del fraccionamiento de datos y la paridad como método para recuperar los datos en caso de fallo, constituye una solución ideal para los entornos de servidores en los que gran parte del E/S es aleatoria, la protección y disponibilidad de los datos es fundamental y el coste es un factor importante. Este nivel de array es especialmente indicado para trabajar con sistemas operativos multiusuarios.
Se necesita un mínimo de tres unidades para implementar una solución RAID 5.
Los niveles 4 y 5 de RAID pueden utilizarse si se disponen de tres o más unidades de disco en la configuración, aunque su resultado óptimo de capacidad se obtiene con siete o más unidades. RAID 5 es la solución más económica por megabyte, que ofrece la mejor relación de precio, rendimiento y disponibilidad para la mayoría de los servidores.

RAID 6: "Acceso independiente con doble paridad"
Similar al RAID 5, pero incluye un segundo esquema de paridad distribuido por los distintos discos y por tanto ofrece tolerancia extremadamente alta a los fallos y a las caídas de disco, ofreciendo dos niveles de redundancia. Hay pocos ejemplos comerciales en la actualidad, ya que su coste de implementación es mayor al de otros niveles RAID, ya que las controladoras requeridas que soporten esta doble paridad son más complejas y caras que las de otros niveles RAID. Así pues, comercialmente no se implementa.


ABRAZO MORTAL


Un abrazo mortal se le conoce como la espera de que una transacción A se ejecute para poder terminar una transacción B pero a su vez la transacción A esta esperando que termine la transacción B para poder terminar la transacción A. de esta manera nunca termina ninguna de las dos transacciones y nunca habría un commit en un abrazo mortal.
Para esto se pueden establecer los seguros o Candados y no permitir casos como estos, se asegura la transacción A y hasta que no termine, no se ejecuta la transacción B, esto se conoce con el nombre de Serialidad que una transacción debe ejecutarse detrás de otra.

febrero 19, 2007

TALLER EVALUATIVO DE MODELAMIENTO DE DATOS Y DISEÑO DE BASE DE DATOS PRE-REQUISITO PARA EL CURSO DE BD DISTRIBUIDAS.

CONCEPTOS

1. Fases Del Desarrollo De Base De Datos:
Fases:
  • Diseño Conceptual
  • Diseño lógico
  • Diseño Fisico

DISEÑO CONCEPTUAL

Parte de los requerimientos y su resultado es el esquema conceptual de la base de datos. Un esquema conceptual es una descripción de alto nivel de la estructura de la base de datos, independiente del software de manejador de bases de datos que se llegue a utilizar.


Los diagramas de datos más ampliamente usados para del diseño conceptual de base de datos son los diagramas entidad-relación (ER), UML (Unified Modeling Language) o OMT (object modeling tecniques) (RIGAUX; SCHOLL y VOISARD, 2002)

DISEÑO LÓGICO:

Parte del esquema conceptual y da como resultado un esquema lógico. Un esquema lógico es una descripción de la estructura de una base de datos que puede procesar el software de SGBD.

DISEÑO FÍSICO

Parte del esquema lógico y da como resultado un esquema físico. Un esquema físico es una descripción de la implantación de la base de datos en la memoria secundaria; describe las estructuras de almacenamiento y los métodos usados para tener un acceso efectivo a los datos, por lo anterior el esquema físico se adapta al SGBD específico.


2. Actividades y finalidad en el modelamiento conceptual de datos, diseño de bases de datos,

CONSTRUCCION DE BD

MODELAMIENTO CONCEPTUAL DE DATOS


Los modelos de datos son usados para describir la realidad. Los diseñadores usan lo modelos de datos para construir esquemas que son representaciones de la realidad. La calidad de de los esquemas resultantes dependerá, no solo del modelo elegido sino también del habilidad del analista.
Un modelo de datos es una serie de conceptos que se utiliza para describir un conjunto de datos y operaciones para manipular los mismos. Cuando un modelo de datos describe un conjunto de conceptos de una realidad se llama modelo conceptual.
El bloque de construcción común a todos los modelos conceptuales de datos es una pequeña colección de mecanismos de abstracción: clasificación (agrupación de una clase de objetos son características comunes), agregación (una nueva clase formada por la reunión de varios objetos) y la generalización o especialización (una relación de subconjuntos entre los elementos de dos o mas clases).
La abstracción es un proceso mental que se aplica al seleccionar algunas características y propiedades de un conjunto de objetos y excluir otras no pertinentes.
En el modelamiento conceptual, se identifican las propiedades estructurales (sobre los objetos, atributos y relaciones) y dinámicas (operaciones sobre los objetos) además de ciertas restricciones de integridad, de un dominio de aplicación con iras a su transformación en un modelo de más bajo nivel.
Los modelos conceptuales deben ser buenas herramientas para representar la realidad; por esta razón debe poseer, entre otras las siguientes características: Expresividad, Simplicidad, Minimalidad y Formalidad.


DIAGRAMA ENTIDAD-RELACIÓN (E-R)

Es una herramienta para el modelado de datos de un sistema de información. Estos diagramas expresan entidades relevantes para un sistema de información, sus inter-relaciones y propiedades.

El diagrama entidad-relación se basa en "una percepción del mundo real que consiste en una colección de objetos básicos llamados entidades y relaciones entre estos objetos"El diagrama entidad-relación es el modelo más ampliamente usado para el diseño conceptual de bases de datos y fue introducido por Peter Chen en 1976.

Elementos BásicosLos elementos básicos son entidades, interrelaciones, atributos y cardinalidad.

ENTIDADES


Una entidad es cualquier "objeto" discreto sobre el que se tiene información. Se representa mediante un rectángulo o "caja" etiquetada en su interior mediante un nombre. Ejemplos de entidades habituales en los sistemas de información son: factura, persona, albarán, empleado, etc.


Cada ejemplar de una entidad se denomina instancia. Por ejemplo, Francisco y Luisa pueden ser dos instancias distintas de la entidad "persona". Las instancias no se representan en el diagrama. No obstante, se pueden documentar aparte porque son útiles para inicializar la base de datos resultante. Por ejemplo, los departamentos existentes de una empresa pueden ser relevantes como datos iniciales de la entidad "departamento"..


ATRIBUTOS

Representan las propiedades básicas de las entidades. Se representan por elipses.(Batini, Ceri y Navathe, 1994).


El Diagrama E-R, muestra además propiedades de opcionalidad y cardinalidad.Opcionalidad u obligatoriedad. Una entidad puede tener o no relaciones de pertenencia u ocurrencia con relación a otra entidad.Cardinalidad. Indica el grado de relación de entre las entidades, que puede ser: Uno a Uno, Uno a muchos, o muchos a muchos.

Los atributos son propiedades relevantes propias de una entidad y sólo una. Se representan mediante un círculo o elipse etiquetado mediante un nombre en su interior. Cuando un atributo es identificativo de la entidad se suele subrayar dicha etiqueta.
Por motivos de legibilidad, los atributos no suelen representarse en un diagrama entidad-relación, sino que se describen textualmente en otros documentos adjuntos.
Los atributos describen información útil sobre las entidades. En particular, los atributos identificativos son aquellos que permiten diferenciar a una instancia de la entidad de otra distinta. Por ejemplo, el atributo identificativo que distingue a un empleado de otro es su número de la Seguridad Social.

Ejemplos de atributos de la entidad "persona":
· Documento Nacional de Identidad (identificativo).
· Nombre.
· Apellidos.
· Dirección.
· Código postal.


RELACION

Una relación describe cierta interdependencia (de cualquier tipo) entre una o más entidades. Se representa mediante un rombo etiquetado en su interior mediante un verbo. Además, dicho rombo debe unirse mediante líneas con las entidades que relaciona (es decir, los rectángulos).Una relación no tiene sentido sin las entidades que relaciona. Algunos ejemplos son:· una persona (entidad) trabaja (relación) para un departamento (entidad).

Tambiebn es una asociación entre varias entidades. Se representan por rombos Relacion Uno a uno, Uno a muchos y muchos a uno.

Cardinales De Las Relaciones

  • Las relaciones, en principio binarias, pueden involucrar a un número distinto de instancias de cada entidad. Así, son posibles tres tipos de cardinalidades:
    Relaciones de uno a uno: una instancia de la entidad A se relaciona con una y solamente una de la entidad B.
  • Relaciones de uno a muchos: cada instancia de la entidad A se relaciona con varias instancias de la entidad B.
  • Relaciones de muchos a muchos: cualquier instancia de la entidad A se relaciona con cualquier instancia de la entidad B.
    El tipo de cardinalidad se representa mediante una etiqueta en el exterior de la relación, respectivamente: "1:1", "1:N" y "N:M". Otra forma de expresar la cardinalidad es situando un símbolo cerca de la línea que conecta una entidad con una relación: "0" si la entidad no está obligada a participar en la relación.
  • "1" si la entidad está obligada a participar en la relación y, además, cada instancia solamente participa una vez.
  • "N" , "M", ó "*" si la entidad no está obligada a participar en la relación y cada instancia puede participar cualquier número de veces.

Ejemplos de relaciones que expresan cardinalidad:

  • Una factura (entidad) se emite (relación) a una persona (entidad) y sólo una, pero una persona puede tener varias facturas emitidas a su nombre. Es una relación 1:N.
    Un cliente (entidad) puede comprar (relación) varios artículos (entidad) y un artículo puede ser comprado por varios clientes distintos. Es una relación N:M.

UID


El parámetro UID indica el login para acceder al servidor SQL Server. Este ejemplo utiliza el login sa, sin embargo, es comveniente utilizar otro login, por cuestiones de seguridad.

SOLUCION EJERCICIO II. SOLUCION EJERCICIO III.