q3.

2 Normalizacin
3.1.2.1 Dependencias Funcionales

Segn [Elmasri y Navathe] Una dependencia funcional es una restriccin entre dos conjuntos de atributos de la base de datos. Una dependencia funcional, denotada por X ?Y, entre dos conjuntos de atributos X y Y que son subconjuntos de R especifica una restriccin sobre las posibles tuplas que podran formar un ejemplar de relacin r de R. La restriccin dice que, para cualquier dos tuplas ti y t2 de r tales que t1 [X] = t2 [X], debemos tener tambin t1 [Y] = t2 [Y]. Esto significa que los valores del componente Y de una tupla de r dependen de los valores del componente X, o estn determinados por ellos; o bien, que los valores del componente X de una tupla determinan de manera nica (o funcionalmente) los valores del componente Y. Tambin decimos que hay una dependencia funcional de X a Y o que Y depende funcionalmente de X. Abreviaremos la dependencia funcional con DF. El conjunto de atributos X se denomina miembro izquierdo de la DF , y Y es el miembro derecho. As pues, X determina funcionalmente a Y en un esquema de relacin R si y slo si, siempre que dos tuplas r(R) coincidan en su valor X, necesariamente deben coincidir en su valor Y. Observe que: Si una restriccin de R dice que no puede haber ms de una tupla con un valor X dado en cualquier ejemplar de relacin r(R) esto es, X es una clave candidata de R - esto implica que X->Y para cualquier subconjunto de atributos Y de R. Si X->Y en R, esto no nos dice si Y-> X en R o no.

Las dependencias funcionales son propiedades del significado o la semntica de los atributos. Aprovechamos nuestra comprensin de la semntica de los atributos de Resto es, qu relacin hay entre ellos- para especificar las dependencias funcionales que deben cumplirse en todos los estados de relacin (extensiones) r de R. Siempre que la

semntica de dos conjuntos de atributos e R indique que debe cumplirse una dependencia funcional.

Segn [Korth y Silberschatz] Puede utilizarse un conjunto dado de dependencias funcionales al disear una base de datos relacional en la que no ocurra la mayora de las propiedades no deseables. En el diseo de tales sistemas puede llegar a ser necesario descomponer una relacin en varias ms pequeas. Usando Dependencias Funcionales, podemos definir varias formas normales que representan diseos <<buenos>> de bases de datos.

Segn [ David M. Kroenke] Una dependencia funcional es una relacin entre uno o ms atributos. Suponga que si se da el valor de un atributo se puede obtener (o buscar) el valor de otro. Si se conoce el valor de NmeroDeCuentaDeCliente, Esto es es cierto, se puede se hallar el valor de que de EstadoDeCuentaDeCliente. EstadotDeCuentaDeCliente NmeroDeCuentaDeCliente. puede decir

funcionalmente

dependiente

En trminos ms generales, el atributo Y es dependiente del atributo X si el valor de X determina el valor de Y. O, puesto de otro modo, si se conoce el valor de X, se puede obtener el valor de Y. Las ecuaciones pueden representar dependencias funcionales. Si se sabe el precio de un artculo y la cantidad de artculos comprados, se puede calcular el precio total de esos artculos como sigue: PrecioTotal = PrecioDelArtculo X Cantidad En este caso se podra decir que PrecioTotal es dependiente del PrecioDelArticulo y Cantidad.

A diferencia de una ecuacin, tales dependencias funcionales no pueden trabajarse usando aritmtica; en vez de ello se listan en una base de datos. La expresin de las dependencias funcionales es una de las razones para tener una base de datos Las dependencias Funcionales se escriben usando la siguiente notacin:

La primera expresin se lee como SID determina funcionalmente Especialidad, SID determina Especialidad o Especialidad es dependiente de SID. Los atributos al lado izquierdo de la flecha se llaman determinantes .

Ejemplo de Dependencia Funcional: Consideremos el esquema de la relacin EMP_PROY; a partir de la semntica de los atributos, sabemos que deben cumplirse las siguientes dependencias funcionales:

Estas dependencias funcionales especifican que: 1. Una combinacin de valores de NSS y NMEROP determina de manera nica el nmero de horas que el empleado trabaja en el proyecto cada semana (HORAS). 2. El valor del nmero de seguro social de un empleado (NSS) determinan de manera nica el nombre de ese empleado (NOMBREE).

3. El valor del nmero de un proyecto (NMEROP) determina de manera nica el nombre del proyecto (NOMBREPR) y su lugar (LUGARP). Alternativamente, podemos decir que NOMBREE est determinado funcionalmente por (o depende funcionalmente de) NSS, o dado un valor de NSS, conocemos el valor de NOMBREE, y as sucesivamente. La figura 3.9 tambin presenta una notacin diagramtico para indicar las

dependencias funcionales: cada DF se muestra como una lnea horizontal. Los atributos del miembro izquierdo de la DF se conectan mediante lneas verticales a la lnea horizontal que representa la DF. Los atributos del miembro derecho de la DF se conectan a la lnea horizontal mediante flechas que apuntan a los atributos.

Introduccin a la normalizacin
En el proceso de normalizacin, segn la propuesta original de Codd (1972), se somete un esquema de relacin a una serie de pruebas para certificar si pertenece o no a una cierta forma norma. En un principio, Codd propuso tres formas normales, a las cuales llam primera, segunda y tercera formas normales. Posteriormente, bice y Codd propusieron una definicin ms estricta de 3FN, a la que se conoce como forma normal de bice-Codd. Todas estas formas normales se basan en las dependencias funcionales entre los atributos de una relacin. Ms adelante se propusieron una cuarta forma normal (4FN) y una quinta (5FN), con fundamento en los conceptos de dependencias multivaluadas y dependencias de reunin, respectivamente.

Qu es normalizacin?
La normalizacin de datos puede considerarse como un proceso durante el cual los esquemas de relacin insatisfactorios de descomponen repartiendo sus atributos entre esquemas de relaciones ms pequeos que poseen propiedades deseables . Las formas normales proveen a los diseadores de bases de datos lo siguiente: Un marco formal para analizar los esquemas de relacin con base en sus claves y en las dependencias funcionales entre sus atributos.

Una serie de pruebas que pueden efectuarse sobre esquemas de relacin individuales de modo que la base de datos relacional pueda normalizarse hasta el grado deseado. Cuando una prueba falla, la relacin que provoca el fallo debe descomponerse en relaciones que individualmente satisfagan las pruebas de normalizacin.

Un punto que merece la pena destacar es que los diseadores de bases de datos no tienen que normalizar hasta la forma normal ms alta posible. Las relaciones pueden dejarse en formas normales inferiores por razones de rendimiento.

Primeras formas normales. Primera forma normal (1 FN).

La primera forma normal se defini para prohibir los atributos multivaluados, los atributos compuestos y sus combinaciones. Una relacin esta en 1FN si y solo si todos sus dominios simples subyacentes contienen solo valores atmicos (o indivisibles). Consideremos el esquema de relacin DEPARTAMENTO cuya clave primaria es NMEROD, y supongamos que la extendemos al incluir el atributo LUGARESD. Suponemos que cada departamento puede tener varios lugares. En la figura 3.10 se muestra el ejemplo de extensin. Es evidente que no est en 1FN porque LUGARESD no es un atributo atmico, como puede verse en la primera tupla. Hay dos formas de considerar el atributo LUGARESD: El dominio de LUGARESD contiene valores atmicos, pero algunas tuplas pueden tener un conjunto de esos valores El dominio de LUFARESD contiene conjuntos de valores y por tanto no es atmico. En este caso, NSS->LUGARESD, porque cada conjunto se considera un miembro individual del dominio del atributo.

Una manera de normalizar a 1FN es tener una tupla en la relacin DEPARTAMENTO original por cada ubicacin de un departamento, como se muestra en la figura 3.11. En este caso, la clave primaria se convierte en la combinacin {NMEROD, LUGARESD} pero hay redundancia en las tuplas.

La idea es eliminar el atributo LUGARESD que viola la 1FN y colocarlo en una relacin aparte LUGARES_DEPTOS junto con la clave primaria NEROD de DEPARTAMENTO. La calve primaria de esta relacin es la combinacin {NMEROD, LUGARD}, como se aprecia en la figura 3.12. Hay una tupla distinta el LUGARES_DEPTOS por cada ubicacin de un departamento. El atributo LUGARESD se quita de la relacin DEPARTAMENTO de la figura 3.10, descomponiendo la relacin que no es 1FN en las dos relaciones 1FN DEPARTAMENTO Y LUGARES_DEPTOS.

La segunda solucin es mejor porque no padece el problema de redundancia. La primera forma normal tambin prohbe los atributos compuestos que por s mismos son multivaluados.

Segunda Forma normal (2FN)

Un esquema de relacin esta en segunda forma normal 2FN si y solo si esta en 1 FN y todos los atributos no clave dependen funcionalmente de manera completa de la clave primaria.

La relacin EMP_PROY esta en 1FN pero no en 2FN. El atributo no clave NOMBREE viola 2FN debido a que no depende de manera completa de la clave primaria en la dependencia funcional 2 (df2), y lo mismo sucede con los atributos no clave NOMBREPR Y LUGARP debido a la df3.Las dependencias funcionales df2 y df3 hacen que NOMBRE, NOMBREPR Y LUGARP dependan parcialmente de la clave primaria {NSS, NMEROP} de la relacin EMP_PROY, violndose as la 2FN.

Si un esquema de relacin no est en 2FN, se le puede normalizar a varias relaciones 2FN en las que los atributos no clave estn asociados slo a la parte de la clave primaria de la que dependen funcionalmente de manera completa. As, las

dependencias funcionales df1, df2 y df3 de la figura 3.13(a) originan la descomposicin de EMP_PROY en los tres esquemas de relacin EP1, EP2 y EP3 que ilustra la figura 3.13(b), cada uno de los cuales est en 2FN.

Tercera Forma Normal 3FN y FNBC (Forma Normal Boyce-Codd ) Tercera Forma Normal (3FN)
La tercera forma normal de basa en el concepto de dependencia transitiva. De acuerdo con la definicin original de Codd, un esquema de relacin R esta en 3FN si y solo si esta en 2FN y todos los atributos no clave dependen de manera no transitiva de la clave primaria. La transitividad se da cuando un atributo no clave depende funcionalmente de un atributo que a su vez depende de la clave primaria.

Figura 3.14. El proceso de Normalizacin. (a) El esquema de relacin EMP_DEPTO. (b) Normalizacin de EMP_DEPTO a relaciones 3FN. La dependencia NSS->NSSGTED es transitiva a travs de NMEROD de la relacin EMP_DEPTO en la figura 3.14(a), porque se cumplen las dos dependencias NSS>NMEROD y NMEROD->NSSGTED y NMEROD no es un subconjunto de la clave de EMP_DEPTO. Podemos ver que en EMP_DEPTO no es deseable la dependencia de NSSGTED con respecto a NMEROD porque NMEROD no es una clave primaria de EMP_DEPTO. El esquema de relacin EMP_DEPTO de la figura 3.14 (a) est en 2FN, pues no existen dependencias parciales de una calve. Sin embargo, no est en 3FN debido a que NSSGTED (y tambin NOMBRED) dependen transitivamente de NSS a travs de NMEROD. Podemos normalizar EMP_DEPTO descomponindolo en los dos esquemas de relacin 3FN ED1 y ED2 que aparecen en la figura 3.14 (b). Vemos, que ED1 y ED2 representan

hechos independientes acerca de las entidades empleados y departamentos. Una operacin de REUNION NATURAL aplicada a ED1 y ED2 recuperar la relacin original EMP_DEPTO sin generar tuplas repetidas.

FNBC (Forma Normal Boyce-Codd

Un esquema de relacin est en FNBC si, y solo si todo determinante es una clave candidata.

Definiciones generales de la segunda y tercera formas normales Segn las definiciones de segunda y tercera forma normal expuestas en la seccin 3.2.2.2 y 3.2.2.3, los pasos para la normalizacin a relaciones, empero, no tienen en cuenta otras claves candidatas de una relacin, si existen. A Continuacin presentaremos las definiciones ms generales de 2FN y 3FN que tienen en cuenta todas las claves candidatas de una relacin. Cabe sealar que esto no afecta la definicin de 1FN, ya que es independiente de las claves y de las dependencias funcionales.

Definicin General de Segunda forma normal (2FN) Un esquema de relacin esta en segunda forma normal(2FN) si y solo si esta en 1 FN y todos los atributos no clave dependen funcionalmente de manera completa de la clave primaria. Consideremos el esquema de relacin LOTES que aparece en la figura 3.15(a) y que describe terrenos a la venta en diversos municipios de un estado. Supongamos que hay dos claves candidatas: ID_PROPIEDAD y {NOMBRE_MUNIC, NM_LOTE}; es decir, los NM_LOTE son nicos slo dentro de cada municipio, pero los identificadores de propiedad (ID_PROPIEDAD) son nicos para todo el estado, sin importar el municipio. Con base en las dos claves candidatas ID_PROPIEDAD y {NOMBRE_MUNIC,

NM_LOTE}, sabemos que las dependencias funcionales df1 y df2 s se cumplen. Escogemos ID_PROPIEDAD como clave primaria, y por ello esta subrayada y la clave candidata {NOMBRE_MUNIC, NM_LOTE} esta sombreada.

La dependencia df3 dice que la tasa fiscal es fija para un municipio dado. Y df4 indica que el precio de un lote lo determina su rea sin importar en que municipio se encuentre. El esquema de relacin LOTES viola la definicin general de 2FN porque TASA_FISCAL depende parcialmente de la clave candidata {NOMBRE_MUNIC, NM_LOTE} debido a df3. Para normalizar LOTES a 2FN, la descomponemos en las dos relaciones LOTES1 y LOTES2 que se muestran en la figura 3.15 (b). Construimos LOTES1 eliminando de LOTES el atributo TASA_FISCAL que viola 2FN y colocando junto con NOMBRE_MUNIC en otra relacin LOTES2. Tanto LOTES1 como LOTES2 estn en 2FN.

Definicin General de tercera forma normal (3FN) Un esquema de relacin R est en 3FN si, siempre que una dependencia funcional X ?A se cumple en R, o bien: 1. X es una clave candidata de R, o 2. A es un atributo clave de R De acuerdo con esta definicin, LOTES2 (Fig. 3.15 (b)) est en 3FN. Sin embargo, df4 de LOTES1 viola 3FN porque rea no es una clave candidata de LOTES1 y PRECIO no es un atributo clave. Para normalizar LOTES1 a 3FN, la descomponemos en los esquemas de relacin LOTES1A y LOTES1B, como en la figura 3.15(c). Construimos LOTES1A eliminando de LOTES1 el atributo PRECIO que viola 3FN y colocndolo junto con REA (el miembro

izquierdo de df4 que causa la dependencia transitiva) en otra relacin LOTES1B. Tanto LOTES1A como LOTES1B estn en 3FN.

Normalizacin Adicional Dependencia Multivaluada y 4F

Las dependencias multivaluadas son una consecuencia de la primera forma normal, que prohbe que un atributo de una tupla tenga un conjunto de valores. Si tenemos dos o ms atributos multivaluados independientes en el mismo esquema de relacin, nos enfrentamos al problema de tener que repetir todos los valores de uno de los atributos con cada valor del otro atributo para que las tuplas de la relacin sigan siendo consistentes.

Ejemplo: Consideremos la relacin EMPLEADOS que se muestra en la figura 3.16 (a). Una tupla de esta relacin representa el hecho de que un empleado cuyo nombre es NOMBREE trabaja en el proyecto cuyo nombre es NOMBREPR y tiene un dependiente cuyo nombre es NOMBRED.

Un empleado puede trabajar en varios proyectos y tener varios dependientes, y los proyectos y dependientes de un empleado no estn relacionados directamente entre s. Para que las tuplas de la relacin sean consistentes, debemos tener una tupla por cada una de las posibles combinaciones de dependiente y proyecto de un empleado como se muestra en la figura 3.16 (b). Esta restriccin se especifica como una dependencia multivaluada sobre la relacin EMP.

Figura 3.16. Ventajas de la 4FN. (a) La relacin empleados con dos Dependencias multivaluadas: NOMBREE ?NOMBREPR y NOMBREE?NOMBRED. (b) Descomposicin de EMPLEADOS en dos relaciones: EMP-PROY y EMP-DEP, que estn en 4FN.

Dependencia de Juntura y 5FN

Una descomposicin posee la propiedad de reunin sin prdidas. Sin embargo, en algunos casos puede ser que no exista una descomposicin con reunin sin prdidas que d dos esquemas de relacin, pero s que produzca ms de dos esquemas de relacin. Estos casos se manejan con la dependencia de reunin y la quinta forma normal. Es importante sealar que estos se presentan muy rara vez y que es difcil detectarlos en la practica. Una dependencia de reunin (DR) , denotada por DR(R1, R2, , Rn), especificada sobre el esquema de relacin R, especifica una restriccin sobre los ejemplares r de R. La restriccin establece que todo ejemplar permitido r de R debe tener una descomposicin con reunin sin prdidas para dar R1, R2, , R; Una dependencia multivaluada es un caso especial de una DR donde n = 2. Una dependencia de reunin DR (R1, R2, , Rn), especificada sobre el esquema de relacin R, es una DR trivial si uno de los esquemas de relacin Ri en DR (R1, R2, ,Rn) es igual a R. Se dice que tal dependencia es trivial porque posee la propiedad de reunin sin prdidas para cualquier ejemplar de relacin r de R y, por tanto, no especifica ninguna restriccin sobre R. Ahora podemos especificar la Quinta Forma Normal , que tambin se denomina forma normal de proyeccin-reunin .

Quinta Forma Normal (5FN)

Un esquema R est en quinta forma normal (5FN) o forma normal de proyeccinreunin (FNPR) respecto a un conjunto F de dependencias funcionales, multivaluadas y de reunin si, para cada dependencia de reunin no trivial DR (R1, R2, , Rn) en F+ (esto es, implicada por F), toda Ri es una superclave de R.

3.3 Integridad de bases de datos

3.3.1 Concepto

Segn [Korth y Silberschatz ] La integridad Proporciona un medio de asegurar que los cambios que se hacen en la base de datos por usuarios autorizados no resultan en una prdida de consistencia de los datos.

Segn [ David M. Kroenke] Un conjunto de datos tiene integridad si son consistentes, si se ensamblan entre s. Con frecuencia, en los sistemas de procesamiento de archivos se aprecia una pobre integridad de los datos.

Resumen
Concepto : La integridad Proporciona un medio de asegurar que los cambios que se hacen en la base de datos por usuarios autorizados no resultan en una prdida de consistencia de los datos.

3.3.2 Restricciones Bsicas

Segn [Korth y Silberschatz] Restricciones de dominio Los lmites de dominios son la forma ms elemental de restricciones de integridad. Son fciles de probar por el sistema siempre que se introduce un nuevo dato en la base de datos. Es posible que varios atributos tengan el mismo dominio. Por ejemplo, los atributos nombre-cliente y nombre empleado podran tener el mismo dominio, el conjunto de todos los nombres de personas. Sin embargo los dominios de saldo y nombre-sucursal, por supuesto, deben ser distintos. En el nivel de implementacin, los nombres de cliente y los nombres de sucursal son cadenas de caracteres. Podemos ver que una definicin adecuada de restricciones de dominio no slo nos permite probar valores

insertados en la base de datos sino que tambin nos permite probar consultas para asegurar que la comparacin que se hace tiene sentido.

Restriccin de Valores Nulos Para determinado atributos, los valores nulos pueden ser inapropiados. Considrese una tupla en la relacin cliente la que nombre-cliente es un valor vaci. Una tupla de este tipo da una calle y una ciudad para un cliente annimo y, por tanto, no contiene informacin til. En casos como ste, deseamos prohibir los valores nulos, restringiendo el dominio de ciudad-cliente para que excluya los valores nulos. El SQL estndar permite que la declaracin del dominio de un atributo incluya la especificacin not null . Esto prohbe la insercin de un valor nulo para este atributo. Cualquier modificacin de la base de datos que causara que se insertase un valor nulo en un dominio not null genera un diagnstico de error. Hay muchas situaciones en las que la prohibicin de valores nulos es deseable. Un caso particular en el que es esencial prohibir los valores nulos es en la clave primaria de un esquema de relacin.

Restriccin de asercin Una Tcnica ms formal para representar restricciones explcitas es con un lenguaje de especificacin de restricciones , que suele basarse en alguna variacin del clculo relacional. Este enfoque declarativo establece una separacin clara entre la base de restricciones (en la que las restricciones se almacenan en una forma codificada apropiada) y el subsistema de control de integridad del SGBD (que tiene acceso a la base de restricciones para aplicar estas ltimas correctamente a las transacciones afectadas). Cuando se usa esta tcnica, las restricciones suelen llamarse aserciones . Se ha sugerido el uso de esta estrategia con SGBD relacinales. El subsistema de control de integridad compila las aserciones, que entonces se almacenan en el catalogo del SGBD, donde el subsistema de control de integridad puede consultarlas e imponerlas automticamente. Esta estrategia es muy atractiva desde el punto de vista de los usuarios y programadores por su flexibilidad.

Segn [Elmasri / Navathe ] Las restricciones de integridad protegen la base de datos contra daos accidentales. Una base de datos almacena informacin sobre alguna parte del mundo real, a la que denominamos o universo de discurso . Ciertas reglas, las restricciones de integridad, gobiernan el minimundo. Cuando diseamos un esquema para una aplicacin de base de datos particular, una actividad importante consiste en identificar las restricciones de integridad que se deben cumplir en la base de datos.

Restricciones de dominio Las restricciones de dominio especifican que el valor de cada atributo A debe ser un valor atmico del dominio dom(A) para ese atributo. Los tipos de datos asociados a los dominios por lo general incluyen los tipos de datos numricos estndar de los nmeros enteros (como entero- corto, entero, entero-largo) y reales (flotante y flotante de doble precisin). Tambin disponemos de caracteres, cadenas de longitud fija y cadenas de longitud variable, as como tipos de datos de fecha, hora, marca de tiempo y dinero. Otros dominios posibles se pueden describir mediante un intervalo de valores de un tipo de datos o como un tipo de datos enumerado en el que se listan explcitamente todos los valores posibles.

Restricciones de clave Todos los elementos de un conjunto son distintos; por tanto, todas las tuplas de una relacin deben ser distintas. Esto significa que no puede haber dos tuplas que tengan la misma combinacin de valores para todos sus atributos. La restriccin de clave es una de las restricciones estndar que con frecuencia aparecen en las aplicaciones de bases de datos. Estas restricciones se manejan de formas ligeramente distintas en los diversos modelos de datos. En el modelo E-R, una clave es un atributo de un tipo de entidades que debe tener un valor nico para cada entidad que pertenezca a dicho tipo en cualquier momento especfico. As el valor del atributo clave puede servir para identificar de manera nica cada entidad. Los atributos claves deben ser monovaluados, pero pueden ser simples o compuestos.

Un tipo de entidades normal puede tener una o ms claves; un tipo de entidades dbil no tiene clave, pero casi siempre tiene una clave parcial cuyos valores identifican de manera nica las entidades dbiles que estn relacionadas a la misma entidad propietario a travs de un vnculo identificador. Suponga que denotamos un subconjunto as de atributos con SC; entonces, para cualesquiera dos tuplas distintas t1 y t2 en un ejemplar de relacin r de R, tenemos la siguiente restriccin:

Todo conjunto de atributos SC de este tipo es una superclave del esquema de relacin R. Toda relacin tiene por lo menos una superclave: el conjunto de todos sus atributos. Sin embargo una superclave puede tener atributos redundantes, as que un concepto ms til es el de clave, que carece de redundancia.

En general, un esquema de relacin pude tener ms de una clave. En tal caso, cada una de ellas se denominan clave candidata. Por ejemplo en una relacin COCHE tiene dos claves candidatas: NumMatrcula y NumSerieMotor. Es comn designar a una de las claves candidata como clave primaria de la relacin. sta es la clave candidata cuyos valores sirven para identificar las tuplas en la relacin.

Restriccin de Valores Nulos

Si muchos de los tributos no se aplican a todas las tuplas de la relacin, se acabar con un gran nmero de nulos en esas tuplas. Esto puede originar un considerable desperdicio en el nivel de almacenamiento y posiblemente dificultar el entendimiento del significado de los atributote y la especificacin de operaciones de Reunin con en el nivel lgico. Otro problema con los nulos es cmo manejarlos cuando se aplican funciones agregadas como COUNT o SUM. Adems, los nulos pueden tener mltiples interpretaciones, como los siguientes: El atributo no se aplica a esta tupla Se desconoce el valor del atributo para esta tupla.

El valor se conoce pero est ausente; esto es, todava no se ha registrado.

Tener la misma representacin para todos los nulos puede hacer que se confundan los diferentes significados que podran tener. Por tanto, hasta donde sea posible, evite incluir en una relacin base atributos cuyos valores puedan ser nulos. Si no es posible evitar los nulos, asegrese de que se apliquen slo en casos excepcionales.

Resumen
Las restricciones de integridad protegen la base de datos contra daos accidentales. Una base de datos almacena informacin sobre alguna parte del mundo real, a la que denominamos o universo de discurso . Ciertas reglas, las restricciones de integridad, gobiernan el minimundo. Cuando diseamos un esquema para una aplicacin de base de datos particular, una actividad importante consiste en identificar las restricciones de integridad que se deben cumplir en la base de datos. Restricciones de dominio Las restricciones de dominio especifican que el valor de cada atributo A debe ser un valor atmico del dominio dom(A) para ese atributo. Los tipos de datos asociados a los dominios por lo general incluyen los tipos de datos numricos estndar de los nmeros enteros (como entero- corto, entero, entero-largo) y reales (flotante y flotante de doble precisin). Tambin disponemos de caracteres, cadenas de longitud fija y cadenas de longitud variable, as como tipos de datos de fecha, hora, marca de tiempo y dinero. Otros dominios posibles se pueden describir mediante un intervalo de valores de un tipo de datos o como un tipo de datos enumerado en el que se listan explcitamente todos los valores posibles.

Restriccin de Valores Nulos Para determinado atributos, los valores nulos pueden ser inapropiados. Considrese una tupla en la relacin cliente la que nombre-cliente es un valor vaci. Una tupla de este tipo da una calle y una ciudad para un cliente annimo y, por tanto, no contiene informacin til. En casos como ste, deseamos prohibir los valores nulos, restringiendo el dominio de ciudad-cliente para que excluya los valores nulos.

El SQL estndar permite que la declaracin del dominio de un atributo incluya la especificacin not null . Esto prohbe la insercin de un valor nulo para este atributo. Cualquier modificacin de la base de datos que causara que se insertase un valor nulo en un dominio not null genera un diagnstico de error. Hay muchas situaciones en las que la prohibicin de valores nulos es deseable. Un caso particular en el que es esencial prohibir los valores nulos es en la clave primaria de un esquema de relacin

Restriccin de clave Es una de las restricciones estndar que con frecuencia aparecen en las aplicaciones de bases de datos. Estas restricciones se manejan de formas ligeramente distintas en los diversos modelos de datos. En el modelo E-R, una clave es un atributo de un tipo de entidades que debe tener un valor nico para cada entidad que pertenezca a dicho tipo en cualquier momento especfico. As el valor del atributo clave puede servir para identificar de manera nica cada entidad. Los atributos claves deben ser monovaluados, pero pueden ser simples o compuestos. Un tipo de entidades normal puede tener una o ms claves; un tipo de entidades dbil no tiene clave, pero casi siempre tiene una clave parcial cuyos valores identifican de manera nica las entidades dbiles que estn relacionadas a la misma entidad propietario a travs de un vnculo identificador. En general, un esquema de relacin pude tener ms de una clave. En tal caso, cada una de ellas se denominan clave candidata. Por ejemplo en una relacin COCHE tiene dos claves candidatas: NumMatrcula y NumSerieMotor. Es comn designar a una de las claves candidata como clave primaria de la relacin. sta es la clave candidata cuyos valores sirven para identificar las tuplas en la relacin.

Restriccin de asercin Una Tcnica ms formal para representar restricciones explcitas es con un lenguaje de especificacin de restricciones , que suele basarse en alguna variacin del clculo relacional. Este enfoque declarativo establece una separacin clara entre la base de restricciones (en la que las restricciones se almacenan en una forma codificada apropiada) y el subsistema de control de integridad del SGBD (que tiene

acceso a la base de restricciones para aplicar estas ltimas correctamente a las transacciones afectadas). Cuando se usa esta tcnica, las restricciones suelen llamarse aserciones . Se ha sugerido el uso de esta estrategia con SGBD relacinales. El subsistema de control de integridad compila las aserciones, que entonces se almacenan en el catalogo del SGBD, donde el subsistema de control de integridad puede consultarlas e imponerlas automticamente. Esta estrategia es muy atractiva desde el punto de vista de los usuarios y programadores por su flexibilidad.

Integridad de Entidades
Segn [Korth y Silberschatz] Una fuente de restricciones de integridad son los conjuntos de entidades dbiles. El esquema de relaciones para un conjunto de entidades dbil debe incluir la clave esquema de relaciones de entidades de la cual depende. As, pues, el esquema de relaciones para cada conjunto de entidades dbil incluye una clave exterior que conduce a una restriccin de integridad referencial.

Segn [Elmasri / Navathe ] La restriccin de integridad de entidades establece que ningn valor de clave primaria puede ser nulo. Esto porque el valor de la clave primaria sirve para identificar las tuplas individuales en una relacin; el que la clave primaria tenga valores nulos implica que no podemos identificar algunas tuplas. Por ejemplo, si dos o ms tuplas tuvieran nulo en su clave primaria, tal vez no podramos distinguirlas

Resumen
La restriccin de integridad de entidades establece que ningn valor de clave primaria puede ser nulo. Esto porque el valor de la clave primaria sirve para identificar las tuplas individuales en una relacin; el que la clave primaria tenga valores nulos implica que no podemos identificar algunas tuplas. Por ejemplo, si dos o ms tuplas tuvieran nulo en su clave primaria, tal vez no podramos distinguirlas.

Integridad Referencial
Segn [Korth y Silberschatz] A menudo queremos asegurar que un valor que aparece en una relacin para un conjunto de atributos dado tambin aparece para un cierto conjunto de atributos en otra relacin. Esto se llama integridad referencial. Las restricciones de integridad referencial se representan frecuentemente. Si

obtenemos el esquema de base de datos relacional construyendo tablas desde diagramas E-R, entonces todas las relaciones que surgen de un conjunto de relaciones tienen restricciones de integridad referencial. Un conjunto de relaciones n-ario R, referente a los conjunto de entidades E1, E2, , En. Ki representa la clave primaria de Ei. Los atributos del esquema de relaciones para el conjunto de relaciones R incluyen K1 K2 Kn. Cada Ki del esquema de R es una clave exterior que conduce a una restriccin de integridad referencial Segn [Elmasri / Navathe] La restriccin de integridad referencial se especifica entre dos relaciones y sirve para mantener la consistencia entre tuplas de las dos relaciones. En trminos informales, la restriccin de integridad referencial establece que una tupla en una relacin que haga referencia a otra relacin deber referirse a una tupla existente en esa relacin. Por ejemplo, en la fig. 3.17 el atributo ND de EMPLEADO da el nmero del departamento para el cual trabaja cada empleado; por tanto, su valor en cada tupla de EMPLEADO deber coincidir con el valor de NMEROD en alguna tupla de la relacin DEPARTAMENTO.

Resumen
A menudo queremos asegurar que un valor que aparece en una relacin para un conjunto de atributos dado tambin aparece para un cierto conjunto de atributos en otra relacin. Esto se llama integridad referencial En trminos informales, la restriccin de integridad referencial establece que una tupla en una relacin que haga referencia a otra relacin deber referirse a una tupla existente en esa relacin. Por ejemplo, en la fig. 3.17 el atributo ND de EMPLEADO da el nmero del departamento para el cual trabaja cada empleado; por tanto, su valor en cada tupla de EMPLEADO deber coincidir con el valor de NMEROD en alguna tupla de la relacin DEPARTAMENTO.

Reglas de Relacin

Segn [Elmasri / Navathe] Orden de las tuplas en una relacin : una relacin se define como un conjunto de tuplas matemticamente, los elementos de un conjunto no estn ordenados; por tanto, las tuplas de una relacin no tienen orden especfico. El ordenamiento de las tuplas no forma parte de la definicin de una relacin, porque la relacin intenta representar los hechos en un nivel lgico abstracto. Orden de los valores dentro de una tupla, y definicin alternativa de relacin : Una tupla es una lista ordenada de n valores, as que el orden de los valores de una tupla y por tanto de los atributos en la definicin de un esquema de relacin es importante. No obstante, en un nivel lgico, el orden de los atributos y de sus valores en realidad no es importante en tanto se mantengas la correspondencia entre atributos y valores. Valores en las Tuplas: Cada valor en una tupla es un valor atmico; esto es, no es divisible en componentes en lo que respecta al modelo relacional. Por ello no se permiten valores compuestos ni multivaluados.

Reglas de base de datos

Segn [Elmasri / Navathe] Una base de datos representa algn aspecto del mundo real, en ocasiones llamado minimundo o universo de discurso . Las modificaciones del minimundo se reflejan en la base de datos. Una base de datos es un conjunto de datos lgicamente coherente, con cierto significado inherente. Una coleccin aleatoria de datos no puede considerarse propiamente una base de datos. Toda base de datos se disea, construye y prueba con datos para un propsito especfico. Esta dirigida a un grupo de usuarios y tiene ciertas aplicaciones preconcebidas que interesan a dichos usuarios.

En otras palabras, una base de datos tiene una fuente de la cual se derivan los datos, cierto grado de interaccin con los acontecimientos del mundo real y un pblico que est activamente interesado en el contenido de la base de datos.

Reglas de negocios

Segn [Elmasri / Navathe] Una base de datos almacena informacin sobre alguna parte del mundo real, a la que denominamos minimundo o universo de discurso . Ciertas reglas, las restricciones de integridad, gobiernan el minimundo, y suelen recibir el nombre de reglas de negocios . Cuando diseamos un esquema para una aplicacin de base de datos particular, una actividad importante consiste en identificar las restricciones de integridad que se deben cumplir en la base de datos.

Segn [ David M. Kroenke] El ltimo elemento de un esquema de base de datos son las reglas de negocios. Son restricciones en las actividades de negocios que necesitan reflejarse en la base de datos y en sus aplicaciones. Los siguientes son ejemplos de reglas de negocios para Highline Collage: 1. Para pedir prestado cualquier equipo, un capitn debe tener un nmero de telfono local. 2. Ningn capitn puede tener prestadas a la vez ms de siete pelotas de soccer. 3. Los capitanes deben regresar todo el equipo dentro de los cinco das posteriores al final de cada semestre. 4. Ningn capitn puede pedir prestado ms equipo si tiene algn material vencido.

Las reglas de negocios son una parte importante del esquema porque especifican las limitaciones sobre los valores de datos permitidos que deben cumplirse, sin importar la forma en la que los cambios en los datos llegan al motor DBMS. Sin tomar en cuenta si

una solicitud no vlida de un cambio de datos viene del usuario de una forma, de una solicitud de consulta/actualizacin o de un programa de aplicacin, el DBMS lo debe rechazar. Los actuales productos DBMS slo ofrecen un cumplimiento limitado de las reglas de negocios, de modo que la mayor parte de las reglas deben cumplirse mediante programas de aplicacin y procedimientos llevados a cabo por el usuario. La situacin est cambiando y se estn desarrollando productos DBMS para cumplir las reglas de negocios.

Resumen
Las reglas de negocios son restricciones en las actividades de negocios que necesitan reflejarse en la base de datos y en sus aplicaciones. Los siguientes son ejemplos de reglas de negocios para Highline Collage:

1. Para pedir prestado cualquier equipo, un capitn debe tener un nmero de telfono local. 2. Ningn capitn puede tener prestadas a la vez ms de siete pelotas de soccer. 3. Los capitanes deben regresar todo el equipo dentro de los cinco das posteriores al final de cada semestre. 4. Ningn capitn puede pedir prestado ms equipo si tiene algn material vencido.

Las reglas de negocios son una parte importante del esquema porque especifican las limitaciones sobre los valores de datos permitidos que deben cumplirse, sin importar la forma en la que los cambios en los datos llegan al motor DBMS. Sin tomar en cuenta si una solicitud no vlida de un cambio de datos viene del usuario de una forma, de una solicitud de consulta/actualizacin o de un programa de aplicacin, el DBMS lo debe rechazar.

3.4 Seguridad de bases de datos

Seguridad de bases de datos Concepto de seguridad

Segn [Korth y Silberschatz]

La informacin almacenada en la base de datos debe estar protegida contra accesos no autorizados, destruccin o alteracin con fines indebidos y la introduccin accidental de inconsistencia.

Segn [Elmasri / Navathe] La tcnica empleada apara proteger la base de datos contra personas que no estn autorizadas para tener acceso a una parte de la base de datos o a toda. Es la proteccin contra el acceso mal intencionado.

Resumen
La tcnica empleada apara proteger la base de datos contra personas que no estn autorizadas para tener acceso a una parte de la base de datos o a toda. La informacin almacenada en la base de datos debe estar protegida contra accesos no autorizados, destruccin o alteracin con fines indebidos y la introduccin accidental de inconsistencia

Autentificacin y autorizacin
Segn [Korth y Silberschatz] Un usuario puede tener varias formas de autorizacin sobre partes de la base de datos. Entre ellas se encuentran las siguientes: Autorizacin de lectura , que permite leer, pero no modificar, la base de datos. Autorizacin de insercin , que permite insertar datos nuevos, pero no modificar los ya existentes. Autorizacin de actualizacin , que permite modificar la informacin, pero no permite la eliminacin de datos. Autorizacin de borrado , que permite la eliminacin de datos.

Un usuario puede tener asignados todos, ninguno o una combinacin de los tipos de autorizacin anteriores. Adems de las formas de autorizacin de acceso de datos antes mencionadas, es posible autorizar al usuario para que modifique es esquema de la base de datos.

Autorizacin de ndice , que permite la creacin y eliminacin de ndices. Autorizacin de recursos , que permite la creacin de relaciones nuevas. Autorizacin de alteracin , que permite agregar o eliminar atributos de una relacin. Autorizacin de eliminacin , que permite eliminar relaciones.

Las autorizaciones de eliminacin y borrado difieren en cuanto a que la autorizacin de borrado slo permite la eliminacin de tuplas. Si un usuario elimina todas las tuplas de una relacin, sta quedar vaca, pero seguir existiendo. Si se elimina la relacin dejar de existir.

Segn [Elmasri / Navathe] Por lo regular, un SGBD cuenta con un subsistema de seguridad y autorizacin de la base de datos que se encarga de garantizar la seguridad de porciones de la base de datos contra el acceso no autorizado. Actualmente se acostumbra hablar de dos tipos de mecanismos de seguridad en las bases de datos: Los mecanismos de seguridad discrecionales se usan para otorgar privilegios a los usuarios, incluida la capacidad de tener acceso a archivos, registros o campos de datos especficos en un determinado modo ( como modo de lectura, de escritura o de actualizacin) Los mecanismos de seguridad obligatorios sirven para imponer seguridad de mltiples niveles clasificando los datos y los usuarios en varias clases (o niveles) de seguridad e implementando despus la poltica de seguridad apropiada de la organizacin. Por ejemplo, una poltica comn consiste en permitir a los usuarios de un cierto nivel de clasificacin ver slo los elementos de informacin clasificados en el mismo nivel que el usuario (o en un nivel inferior).

Otro problema de seguridad comn a todos los sistemas de computo es el de evitar que personas no autorizadas tengan acceso al sistema mismo, ya sea para obtener informacin o para efectuar cambios mal intencionados en una porcin de la base de

datos. El mecanismo de seguridad de un SGBD debe incluir formas de restringir el acceso al sistema como un todo. Esta funcin de denomina control de acceso y se pone en practica creando cuentas de usuarios y contraseas para que el SGBD controle el proceso de entrada al sistema. Otra tcnica de seguridad es el cifrado de datos , que sirve para proteger datos confidenciales que se transmiten por satlite o por algn otro tipo de red de comunicaciones. As mismo, el cifrado puede proveer proteccin adicional a secciones confidenciales de una base de datos. Los datos se codifican mediante algn algoritmo de codificacin.

Resumen
Un usuario puede tener varias formas de autorizacin sobre partes de la base de datos. Entre ellas se encuentran las siguientes: Autorizacin de lectura , que permite leer, pero no modificar, la base de datos. Autorizacin de insercin , que permite insertar datos nuevos, pero no modificar los ya existentes. Autorizacin de actualizacin , que permite modificar la informacin, pero no permite la eliminacin de datos. Autorizacin de borrado , que permite la eliminacin de datos.

Un usuario puede tener asignados todos, ninguno o una combinacin de los tipos de autorizacin anteriores. Adems de las formas de autorizacin de acceso de datos antes mencionadas, es posible autorizar al usuario para que modifique es esquema de la base de datos. Autorizacin de ndice , que permite la creacin y eliminacin de ndices. Autorizacin de recursos , que permite la creacin de relaciones nuevas. Autorizacin de alteracin , que permite agregar o eliminar atributos de una relacin. Autorizacin de eliminacin , que permite eliminar relaciones.

Las autorizaciones de eliminacin y borrado difieren en cuanto a que la autorizacin de borrado slo permite la eliminacin de tuplas. Si un usuario elimina todas las tuplas de

una relacin, sta quedar vaca, pero seguir existiendo. Si se elimina la relacin dejar de existir.

Rol y privilegios de usuarios

Segn [Elmasri / Navathe] Entre las obligaciones del DBZ est otorgar privilegios a los usuarios que necesitan usar el sistema y clasificar los usuarios y los datos d acuerdo con la poltica de la organizacin. El DBA tiene una cuenta privilegiada en el SGBD, a veces denominada cuenta del sistema, que confiere capacidades extraordinarias no disponibles para las cuentas y usuarios ordinarios de la base de datos. Las rdenes privilegiadas del DBA incluyen rdenes para otorgar o revocar privilegios a cuentas individuales, usuarios o grupos de usuarios, y para efectuar los siguientes tipos de acciones: 1. Creacin de cuentas : Esta accin crea una nueva cuenta y contrasea para un usuario o grupo e usuarios, a fin de que puedan tener acceso al SGBD. 2. Concesin de privilegios : Esta accin permite al DBA otorgar ciertos privilegios a ciertas cuentas. 3. Revocacin de privilegios : Esta accin permite al DBA revocar (cancelar) ciertos privilegios que se haban concedido previamente a ciertas cuentas. 4. Asignacin de niveles de seguridad : esta accin consistente en asignar cuentas de usuario al nivel apropiado de clasificacin de seguridad. El DBA es responsable de la seguridad global del sistema de base de datos. La accin 1 de la lista sirve para controlar el acceso el SGBD en general, en tanto que las acciones 2 y 3 se usan para controlar las autorizaciones discrecionales, y con la accin 4 se controla la autorizacin obligatoria.

Vistas y Seguridad
Segn [Korth y Silberschatz]

El concepto de vistas, es una forma de proporcionar al usuario un modelo personalizado de la base de datos. Una vista puede ocultar datos que el usuario no tiene necesidad de ver. Esta posibilidad sirve tanto para simplificar la utilizacin del sistema como para fomentar la seguridad. El uso del sistema es ms sencillo porque el usuario puede restringir su atencin a los datos que le interesan. La seguridad se logra si se cuenta con un mecanismo que limite a los usuarios a su vista o vistas personales. Lo normal es que las bases de datos relacionales cuenten con dos niveles de seguridad: Relacin. Puede permitirse o impedirse que el usuario tenga acceso directo a una relacin. Vista . Puede permitirse o impedirse que el usuario tenga acceso a la informacin que aparece en una vista. Aunque es posible impedir que un usuario tenga acceso directo a una relacin, puede permitrsele acceso a una parte de esa relacin por medio de una vista. De tal manera, es posible utilizar una combinacin de seguridad al nivel relacional y al nivel de vistas para limitar el acceso del usuario exclusivamente a los datos que necesita.

Segn [Elmasri / Navathe] Por si mismas, las vistas constituyen un importante mecanismo de autorizacin discrecional, Por ejemplo, si el propietario A de una relacin R desea que otra cuenta B pueda leer nicamente ciertos campos de R, A puede crear una vista V de R que incluya slo esos atributos, y despus otorgar a B el privilegio SELECT para V. Lo mismo se aplica cuando se desea limitar a B a la lectura de slo ciertas tuplas de R; se puede crear una vista V1 definindola por medio de una consulta que seleccione slo las tuplas de R que A desea poner al alcance de B.

Resumen
Una vista puede ocultar datos que el usuario no tiene necesidad de ver. Esta posibilidad sirve tanto para simplificar la utilizacin del sistema como para fomentar la seguridad. El uso del sistema es ms sencillo porque el usuario puede restringir su atencin a los datos que le interesan. La seguridad se logra si se cuenta con un mecanismo que limite a los usuarios a su vista o vistas personales. Lo normal es que las bases de datos relacionales cuenten con dos niveles de seguridad:

Relacin. Puede permitirse o impedirse que el usuario tenga acceso directo a una relacin. Vista . Puede permitirse o impedirse que el usuario tenga acceso a la informacin que aparece en una vista.

Aunque es posible impedir que un usuario tenga acceso directo a una relacin, puede permitrsele acceso a una parte de esa relacin por medio de una vista. De tal manera, es posible utilizar una combinacin de seguridad al nivel relacional y al nivel de vistas para limitar el acceso del usuario exclusivamente a los datos que necesita.

3.5 Recuperacin de bases de datos

3.5.1 Transacciones 3.5.5.1 Definicin de transaccin
Segn [Korth y Silberschatz] Una transaccin es una unidad de programa cuya ejecucin conserva la consistencia de una base de datos. Segn [Elmasri / Navathe] Una transaccin es la ejecucin de un programa que incluye operaciones de acceso a la base de datos.

Resumen
Una transaccin es la ejecucin de un programa que incluye operaciones de acceso a la base de datos, cuya ejecucin conserva la consistencia de una base de datos

Propiedades de atomicidad, consistencia, aislamiento y durabilidad (ACIS)

Segn [Elmasri / Navathe]

Las transacciones atmicas deben poseer varias propiedades. stas se conocen como propiedades ACID y deben ser impuestas por los mtodos de control de concurrencia y de recuperacin del SGBD. Las propiedades ACID son: 1. Atomicidad: Una transaccin es una unidad atmica de procesamiento; o bien se realiza por completo o no se realiza en absoluto. 2. Conservacin de la consistencia: Una ejecucin correcta de la transaccin debe llevar a la base de datos de un estado consistente a otro. 3. Aislamiento: Una transaccin no debe dejar que otras transacciones puedan ver sus actualizaciones antes de que sea confirmada; esta propiedad, cuando se hace cumplir estrictamente, resuelve el problema de la actualizacin temporal y hace innecesarias las reversiones en cascada de las transacciones. 4. Durabilidad o permanencia: Unas ves que una transaccin ha modificado la base de datos y las modificaciones se han confirmado, stas nunca deben perderse por un fallo subsecuente.

3.5.1.3 Estados de las transacciones

Segn [Korth y Silberschatz] El coordinador de transacciones se encarga de coordinar todas las transacciones que se inicien en esa localidad. Para cada una de estas transacciones, el coordinador debe: Iniciar la ejecucin de la transaccin. Dividir la transaccin en varias subtransacciones, las cuales ha de distribuir en las localidades apropiadas para su ejecucin. Coordinar la terminacin de la transaccin, ya sea que quede ejecutada o abortada en todas las localidades.

Protocolo de compromisos
Para garantizar la atomicidad, es preciso que todas las localidades en las que se haya ejecutado la transaccin T coincidan en el resultado final de la ejecucin. T debe

quedar ejecutada o abortada en todas las localidades. Para garantizar esta propiedad, el coordinador de transacciones encargado de T debe ejecutar un protocolo de compromiso. Compromiso de dos-fases Sea T una transaccin que se inicio en la localidad Li, y sea Ci, el coordinador de transacciones de esa localidad. El protocolo de compromiso Cuando T termina de ejecutarse, es decir, cuando todas las localidades en las que se ejecuto T informan a Ci que T lleg a su trmino, Ci inicia el protocolo de compromiso de dos-fases. Fase1 . Ci aade el registro < preparar T> a la bitcora y la graba en memoria estable. Una vez hecho esto enva un mensaje de preparar T a todas las localidades en las que se ejecut T. Al recibir el mensaje, el gestor de transacciones de cada una de esas localidades determina si esta dispuesto a ejecutar la parte de t que le correspondi. Si no est dispuesto, ste aade un registro < no T> la bitcora y a continuacin enviar un mensaje abortar T a Ci. Si la respuesta es afirmativa agregar un registro < T lista > a la bitcora y grabar todos los registros de bitcora que corresponden a T en memoria estable. Una vez hecho esto, responder a Ci con el mensaje T lista .

Fase2 . Una vez que todas las localidades hayan respondido al mensaje preparar T enviado a Ci, o despus de un intervalo de tiempo, previamente especificado, Ci puede determinar si la transaccin T puede ejecutarse o abortarse. Si Ci recibi el mensaje T lista de todas las localidades que participan, la transaccin T puede ejecutarse. En caso contrario, la transaccin T debe abortarse. Segn haya sido el veredicto, se agregar un registro < ejecutar T> o < abortar T> a la bitcora y se grabar en memoria estable. En este punto, el destino de la transaccin se habr sellado. A continuacin, el coordinador enviar un mensaje < ejecutar T> o < abortar T> a todas las localidades participantes. Al recibir este mensaje, cada una de las localidades lo registra en la bitcora.

Segn [Elmasri / Navathe] Para fines de recuperacin, el sistema necesita mantenerse al tanto de cundo la transaccin se inicia, termina y se confirma o aborta. As pues, el gestor de recuperacin se mantiene al tanto de las siguientes operaciones: INICIO_DE_TRANSACCIN : sta marca el principio de la ejecucin de la

transaccin. LEER o ESCRIBIR : stas especifican operaciones de lectura o escritura de

elementos de la base de datos que se efectan como parte de una transaccin. FIN_DE_TRANSACCIN : sta especifica que las operaciones de LEER y ESCRIBIR de la transaccin han terminado y marca el lmite de la ejecucin de la transaccin. Sin embargo, en este punto puede ser necesario verificar si los cambios introducidos por la transaccin se pueden aplicar permanentemente a la base de datos (confirmar) o si la transaccin debe abortarse porque viola el control de concurrencia o por alguna otra razn. CONFIRMAR _ TRANSACCIN: sta seala que la transaccin termin con xito y que cualesquier cambios (actualizaciones) ejecutadas por ella se pueden confirmar sin peligro en la base de datos y que no se cancelarn. REVERTIR (o ABORTAR) : sta indica que la transaccin termin sin xito y que cualesquier cambios o efectos que pueda haber aplicado a la base de datos se deben cancelar.

Adems de las anteriores, algunas tcnicas de recuperacin requieren operaciones adicionales como las siguientes: DESHACER: Similar a revertir, pero se aplica a una sola operacin y no a una transaccin completa. REHACER: sta especifica que ciertas operaciones de transaccin de deben repetir (rehacer) para asegurar que todas las operaciones de una transaccin confirmada se hayan aplicado con xito a la base de datos.

La figura 3.18 muestra el diagrama de transicin de estados que describe el paso de una transaccin por sus estados de ejecucin. Una transaccin entra en un estado activo inmediatamente despus de que inicia su ejecucin, y ah puede emitir operaciones LEER y ESCRIBIR. Cuando la transaccin termina, para al estado parcialmente confirmado. En este punto, algunas tcnicas de control de concurrencia requieren que se efecten ciertas verificaciones para garantizar que la transaccin no interfiera otras transacciones en ejecucin. Una vez realizadas con xito las verificaciones, se dice que la transaccin ha llegado a su punto a su punto de confirmacin y pasa al estado confirmado. Una vez que una transaccin esta en el estado confirmado, ha concluido con xito su ejecucin.

Sin embargo, una transaccin puede pasar al estado fallido si una de las verificaciones falla o si la transaccin se aborta mientras est en el estado activo. El estado terminado corresponde al abandono del sistema por parte de la transaccin. Las transacciones fallidas o abortadas pueden reiniciarse posteriormente, ya sea en forma automtica o despus de reintroducirse como transacciones nuevas.

Resumen
Para fines de recuperacin, el sistema necesita mantenerse al tanto de cundo la transaccin se inicia, termina y se confirma o aborta. As pues, el gestor de recuperacin se mantiene al tanto de las siguientes operaciones:

INICIO_DE_TRANSACCIN : sta marca el principio de la ejecucin de la

transaccin. LEER o ESCRIBIR : stas especifican operaciones de lectura o escritura de

elementos de la base de datos que se efectan como parte de una transaccin. FIN_DE_TRANSACCIN : sta especifica que las operaciones de LEER y ESCRIBIR de la transaccin han terminado y marca el lmite de la ejecucin de la transaccin. Sin embargo, en este punto puede ser necesario verificar si los cambios introducidos por la transaccin se pueden aplicar permanentemente a la base de datos (confirmar) o si la transaccin debe abortarse porque viola el control de concurrencia o por alguna otra razn. CONFIRMAR _ TRANSACCIN: sta seala que la transaccin termin con xito y que cualesquier cambios (actualizaciones) ejecutadas por ella se pueden confirmar sin peligro en la base de datos y que no se cancelarn. REVERTIR (o ABORTAR) : sta indica que la transaccin termin sin xito y que cualesquier cambios o efectos que pueda haber aplicado a la base de datos se deben cancelar. Adems de las anteriores, algunas tcnicas de recuperacin requieren operaciones adicionales como las siguientes: DESHACER: Similar a revertir, pero se aplica a una sola operacin y no a una transaccin completa. REHACER: sta especifica que ciertas operaciones de transaccin de deben repetir (rehacer) para asegurar que todas las operaciones de una transaccin confirmada se hayan aplicado con xito a la base de datos.

3.5.2 Bitcora
Segn [Elmasri/Navathe] Para poderse recuperar los fallos de transacciones, el sistema mantiene una bitcora (a veces llamada diario ) que sigue la pista a todas las operaciones de transacciones que afecta los valores de elementos de la base de datos. La bitcora se mantiene en disco, de modo que no la afecta ningn tipo de fallo, ms que los de disco o lo catastrficos. Adems, la bitcora se respalda peridicamente en cinta para protegerse contra fallos catastrficos.

3.5.2.1 Tipos de bitcora

Segn [Elmasri/Navathe] A continuacin mencionaremos los tipos de entradas que se escriben en la bitcora y la accin que realiza cada una de ellas- T se refiere a un identificador de transaccin nico que el sistema genera automticamente y que sirve para identificar cada transaccin: 1. [inicio_de_transaccin, T]: Asienta que se ha iniciado la ejecucin de la transaccin T.

2. [escribir_elemento,T,X,

Valor_anterior,nuevo_valor]:

Asienta

que

la

transaccin T cambi el valor del elemento de base de datos X de valor_anterior a nuevo_valor. 3. [leer_elemento,T,X]: Asienta que la transaccin T ley el valor del elemento de base de datos X. 4. [confirmar,T]: Asienta que la transaccin T termin con xito y establece que su efecto se puede confirmar (asentar permanentemente) en la base de datos. 5. [abortar,T]: Asienta que se abort la transaccin T. Los protocolos de recuperacin que evitan las reversiones en cascada no requieren que las operaciones LEER se asienten en la bitcora del sistema, pero otros protocolos s necesitan estas entradas para la recuperacin. En el primer casi, el costo extra de asentar las operaciones en la bitcora se reduce, porque en ella se registran menos operaciones, slo las de ESCRIBIR. Adems, los protocolos estrictos requieren entradas ESCRIBIR ms simples que no incluyen nuevo _ valor. Si el sistema se cae, podemos recuperar la base de datos a un estado consistente examinando la bitcora y usando una de las tcnicas de recuperacin. Dado que la bitcora contiene un regusto de cada operacin ESCRIBIR que altera el valor de algn elemento de la base de datos, es posible deshacer (cancelar) el efecto de estas operaciones ESCRIBIR de una transaccin T rastreando hacia atrs en la bitcora y restableciendo todos los elementos alterados con una operacin ESCRIBIR T a su valor _ anterior. Tambin podemos rehacer el efecto de las operaciones ESCRIBIR de una transaccin t rastreando hacia delante en la bitcora y cambiando todos los elementos modificados por una operacin ESCRIBIR de T a su nuevo _ valor. Una transaccin T llega a su punto de confirmacin cuando todas sus operaciones que tienen acceso a la base de datos se han ejecutado con xito y el efecto de todas estas operaciones se ha asentado en la bitcora.

3.5.2.2 Contenido de la bitcora

Segn [David M. Kroenke] La bitcora contiene un registro de las modificaciones de los datos en orden cronolgico. Las transacciones se escriben en la bitcora, antes de su aplicacin a la base de datos. Si el sistema se cae antes de que la transaccin haya sido registrada y

el momento en que se aplica, en el peor de los casos, existe un registro de una transaccin no aplicada. Si las transacciones fueron aplicadas antes de su inclusin en la bitcora, seria posible modificar la base de datos, pero no tener registro del cambio.

3.5.2.3 Respaldo
Segn [Elmasri / Navathe] Las utileras de respaldo crean una copia de seguridad de la base de datos, casi siempre vertiendo toda la base de datos en cinta. La copia de seguridad puede servir para restaurar la base de datos en caso de un fallo catastrfico.

3.6 Diccionario de bases de datos

3.6.1 Concepto
Segn [David M. Kroenke] Un diccionario de datos es una herramienta de importancia para el administrador de la base de datos, es un catalogo accesible para el usuario de datos relacionados. Con la base de datos.

Segn [Elmasri/Navathe] Con el termino de diccionario de datos suele designarse una utilera de software ms general que un catalogo. Los sistemas de diccionario de datos sirven para mantener informacin relativa al hardware y software, la documentacin y los usuarios del sistema, as como otra informacin pertinente para la administracin del sistema.

Resumen

Los sistemas de diccionario de datos sirven para mantener informacin relativa al hardware y software, la documentacin y los usuarios del sistema, as como otra informacin pertinente para la administracin del sistema. Es un catalogo accesible para el usuario de datos relacionados Con la base de datos.

3.6.2 Contenido y funcin

Segn [Korth y Silberschatz] El diccionario de datos almacena informacin acerca de la estructura de la base de datos, y la informacin de autorizacin, y datos acerca de las relaciones. Tipos de informacin que el sistema debe almacenar estn: Los nombres de las relaciones.

Los nombres de los atributos de cada relacin.

Los dominios de los

atributos. Los nombres de las vistas definidas en la base de datos y la definicin de esas vistas. Las restricciones de integridad de cada relacin (por ejemplo, las restricciones e clave). Adems de esto, muchos sistemas conservan los datos siguientes de los usuarios del sistema: Nombres de los usuarios autorizados.

Informacin contable acerca de los usuarios. En los sistemas que utilizan estructuras altamente sofisticadas para almacenar relaciones, pueden conservarse datos estadsticos y descriptivos acerca de las relaciones: Nmero de tuplas en cada relacin.

Mtodo de almacenamiento utilizado para cada relacin (por ejemplo, agrupado o sin agrupar).

3.6.3 Tipos
Segn [Elmasri/Navathe]

Diccionario de datos Activo: Es un diccionario cuyas entradas son modificadas en forma automtica por el software, siempre que ocurran modificaciones en la escritura de la base de datos. Diccionario de datos Pasivo : necesitan ser actualizados en forma separada, para hacer modificaciones en la base de datos, de lo contrario no reflejarn con exactitud el estado de la base de datos. Los diccionarios de datos Activos cuestan ms, pero aseguran se actualicen; no estn disponibles con todos los productos DBMS. Los diccionarios de datos pasivos son menos costosos que los activos, pero se requiere de mayor esfuerzo para mantenerlos actualizados. Cualquiera de ellos es una gran ayuda al DBA para registrar y rastrear nombres, formatos, relaciones y referencias cruzadas de los datos.

10.3.3. Casos prcticos Ejercicios:

Dadas las siguientes relaciones analcelas cuidadosamente, declare su clave, las dependencias funcionales y normalcela en caso de ser necesario.

Al normalizar la relacin indique hasta que forma normal lleg y cuales son las claves principales y ajenas de las relaciones resultantes.

10.3.4. Banco de reactivos

1. Explicar qu significa?: Repeticin de la informacin Incapacidad para representar informacin Prdida de informacin

Explicar por qu cualquiera de estas propiedades puede indicar que un diseo de una base de datos relacional es malo. 1. Qu es una dependencia funcional? 2. Qu es normalizacin? 3. Qu es transitividad? 4. Cul es el concepto de integridad? 5. Cules son las restricciones bsicas y explquelas? 6. A que se refiere el trmino de integridad de entidades? 7. Qu es la integridad referencial? 8. Explique cuales son las reglas de relacin? 9. Cules son las reglas de negocios? 10. Cul es el concepto de seguridad? 11. A que se refiere la autentificacin y autorizacin? 12. Menciona los tipos de privilegios a usuarios? 13. Qu es una vista? 14. Las bases de datos relacionales cuenten con dos niveles de seguridad, cules son? 15. Cul es la definicin de transaccin? 16. Cules son las propiedades de las transacciones? 17. Menciones los estados de las transacciones? 18. Qu es y que contiene la bitcora? 19. Qu es el diccionario de datos? 20. Cules son los tipos de diccionario de datos? 21. Qu es una dependencia multivaluada? 22. Defina la cuarta forma normal Por qu es til?