Sincronización

.

Unidad 5 Tarea 1

Valores nulos

Los valores NULL se utilizan en bases de datos relacionales cuando el valor de una columna se desconoce o falta. Un NULL no es ni una cadena vacía (en los tipos de datos de caracteres o de fecha y hora) ni un valor cero (en los tipos de datos numéricos).

Es necesario analizar la forma en la que las operaciones del álgebra relacional manejan los valores nulos (y las complicaciones que surgen).

Las operaciones y comparaciones con valores nulos se deberían evitar siempre que sea posible.

Valor nulo: Valor desconocido o no existente

Reunión

Las reuniones se pueden expresar como un producto cartesiano seguido de una selección.

La definición de la forma en la cual la selección trata los nulos también define la forma en que la operación reunión trata los nulos.

En una reunión natural, si dos tuplas tienen valor nulo en el atributo común, las tuplas no casan.

Proyección Generalizada

Los nulos en las expresiones de los atributos en la proyección generalizada se tratan como en cualquier expresión.

Las tuplas duplicadas que contienen valores nulos se tratan como en la operación proyección.

Πnombre-cliente, límite - saldo-crédito (información-crédito)

Πnombre-cliente, (límite – saldo-crédito) as crédito-disponible (información-crédito)

Funciones de Agregación

Cuando hay nulos en atributos agregados, la operación borra los valores nulos del resultado antes de aplicar la agregación.

El tratamiento de los valores nulos aquí es diferente al realizado en las operaciones aritméticas <- aplicarlo como en las operaciones aritméticas significaría que un único valor desconocido en un gran grupo podría hacer que el resultado agregado sobre el grupo fuese nulo, y se perdería una gran cantidad de información útil.

Gsum(sueldo) (trabajo-por-horas)

Gcount-distinct(nombre-sucursal) (trabajo-por-horas)

Reunión Externa

Las operaciones de reunión externa se comportan como las operaciones de reunión, excepto sobre las tuplas que no aparecen en el resultado.

empleado (nombre-empleado, calle, ciudad)

trabajo-a-tiempo-completo (nombre-empleado, nombre-sucursal, sueldo)

empleado (  )trabajo-a-tiempo-completo

Unidad 4 tarea 2.

Integridad de los datos

La exigencia de integridad de los datos garantiza la calidad de los datos de la base de datos.

 La integridad de datos pertenece a una de las siguientes categorías:

Integridad de entidad

La integridad de entidad define una fila como entidad única para una tabla determinada. La integridad de entidad exige la integridad de las columnas de los identificadores o la clave principal de una tabla, mediante índices y restricciones UNIQUE, o restricciones PRIMARY KEY.

Ejemplo

Tenemos la siguiente relación:

DESPACHOS
edificio	número	superficie
Marina	120	10
Marina	122	15
Marina	230	20
Diagonal	120	10

En esta relación, puesto que la clave primaria está formada por edificio y número, no hay ningún despacho que tenga un valor nulo para edificio, ni tampoco para número.

Otras relaciones bien podrían tener una clave primaria en la cual se permiten nulos. Como por ejemplo vamos a suponer  que se permiten nulos para el atributo P.COLOR en la base de datos proveedores y partes, y consideremos la relación resultante de la consulta “obtener todos los colores de las partes”.

Integridad de dominio

La integridad de dominio viene dada por la validez de las entradas para una columna determinada. Puede exigir la integridad de dominio para restringir el tipo mediante tipos de datos, el formato mediante reglas y restricciones CHECK, o el intervalo de valores posibles mediante restricciones FOREIGN KEY, restricciones CHECK, definiciones DEFAULT, definiciones NOT NULL y reglas.

Ejemplo:

Si en la relación EMPLEADOS(DNI, nombre, apellido, edademp) hemos declarado que dominio(DNI) es el dominio predefinido de los enteros, entonces no podremos insertar, por ejemplo, ningún empleado que tenga por DNI el valor “Luis”, que no es un entero.

Otro ejemplo seria que en la relación EMPLEADOS(DNI, nombre, apellido, edademp) hemos declarado que dominio(edademp) es el dominio definido por el usuario edad. Supongamos también que el dominio edad se ha definido como el conjunto de los enteros que están entre 16 y 65. En este caso, por ejemplo, no será posible insertar un empleado con un valor de 90 para edademp.

Como segundo ejemplo una empresa dedicada a la venta de bebidas; podríamos identificar a las bebidas:

-Todas las bebidasen un solo grupo.

-Todas las bebidas de la misma marca en un grupo.

-Agrupar las bebidas en función de si contienen alcohol o no

-El sabor de la bebida

-Cadas bebida de modo individual

Integridad referencial

En el contexto de las bases de datos, la integridad referencial es una propiedad deseable en las mismas. Gracias a la integridad referencial se garantiza que una entidad (fila o registro) siempre se relaciona con otras entidades válidas, es decir, que existen en la base de datos. Implica que en todo momento dichos datos sean correctos, sin repeticiones innecesarias, datos perdidos y relaciones mal resueltas

 Por ejemplo, en una base de datos académica, exista un profesor en un departamento inexistente, o un curso impartido por un profesor inexistente.

Otro  ejemplo seria , con las tablas Ventas y Títulos en la base de datos Pubs, la integridad referencial está basada sobre las relaciones entre la clave ajena (tit_ID) en la tabla ventas y la clave primaria (tit_ID) en la tabla Titulos, como se muestra en la Figura.

Otro ejemplo se puede representar en el siguiente cuadro:

Integridad definida por el usuario

La integridad definida por el usuario permite definir reglas de empresa específicas que no pertenecen a ninguna otra categoría de integridad. Todas las categorías de integridad admiten la integridad definida por el usuario. Esto incluye todas las restricciones de nivel de columna y nivel de tabla en CREATE TABLE, procedimientos almacenados y desencadenadores.

Un ejemplo podría ser  ser que no podamos matricular alumnos en un centro educativo de secundaria, menores de 12 años. El principio, para el modelo datos seria indiferente que en nuestros sistemas tuvieron alumnos matriculados menores de 12 años, pero no para los encargados de gestionar el centro educativo, para los que seria inaceptable que alumnos menores de esa edad estuvieron causando estudios en el centro.

Otro ejemplo similar sería que nuestra base de datos no aceptara a ciertos usuarios en una biblioteca, por ejemplo usuarios con adeudo graves en la biblioteca no podrían ser acreedores a un préstamo. 

Tarea 4

DESCOMPOSICION

Como ya hemos visto se sugiere que se deben descomponer los esquemas de relación que tienen muchos atributos en varios esquemas con menos atributos. Una descomposición poco cuidadosa, no obstante, puede llevar a otra modalidad de mal diseño.

Una descomposición que no es una descomposición con pérdida es una descomposición de reunión sin pérdida. 

El concepto de reunión sin pérdida resulta fundamental para gran parte del diseño de bases de datos relacionales.

Para tener una descomposición de reunión sin pérdida hay que imponer restricciones en el conjunto de las relaciones posibles.

 Se dice que una relación es legal si satisface todas las reglas, o restricciones, que se hayan impuesto en la base de datos.

Esta información es para conocer  el  problema de la especificación de restricciones para las bases de datos y del modo de obtener descomposiciones de reunión sin pérdida que eviten los inconvenientes.

PROPIEDADES DESEABLES DE LA DESCOMPOSICIÓN

Se puede utilizar un conjunto dado de dependencias funcionales

para diseñar una base de datos relacional en la que no se halle presente la mayor parte de las propiedades no deseables, Cuando se diseñan estos sistemas puede hacerse necesaria la descomposición de una relación en varias relaciones de menor tamaño.

En este apartado se describen las propiedades deseables de las descomposiciones de los esquemas relacionales.

En apartados posteriores se describen maneras concretas de descomponer un esquema relacional para obtener las propiedades deseadas.

Descomposición de reunión sin pérdida

Al descomponer una relación en varias relaciones de menor tamaño, resulta fundamental que la descomposición sea una descomposición sin pérdida.

Hay que presentar un criterio para determinar si una descomposición es una descomposición con pérdida.

Se puede utilizar el cierre de los atributos para comprobar de manera eficiente la existencia de superclaves.

En el caso general de la descomposición simultánea de una relación en varias partes, la búsqueda de la descomposición de reunión sin pérdida resulta más complicada.

Aunque la prueba de la descomposición binaria es, evidentemente, una condición suficiente para la reunión sin pérdida, sólo constituye una condición necesaria

si todas las restricciones son dependencias funcionales.

Conservación de las dependencias

Otro objetivo en el diseño de las bases de datos relacionales:

la conservación de las dependencias. Cuando se lleva a cabo una actualización de la base de datos el sistema debe poder comprobar que la actualización no crea ninguna relación ilegal, es decir, una relación que no satisface todas las dependencias funcionales dadas.

Si hay que comprobar de manera eficiente las actualizaciones, se deben diseñar unos esquemas de bases de datos relacionales que permitan la validación de las actualizaciones sin que haga falta calcular las reuniones.

Para decidir si hay que calcular las reuniones para   comprobar una actualización hace falta determinar las dependencias funcionales que hay que comprobar verificando cada relación una a una.  Dado que todas las dependencias funcionales de una restricción únicamente implican atributos de un esquema de relación, es posible el cumplimiento de la condición por una dependencia verificando sólo una relación.

Repetición de la información

La descomposición separa los datos  en relaciones diferentes, con lo que elimina esta redundancia. La falta de redundancia de la descomposición es algo deseable. El grado hasta el que se puede conseguir esta falta de redundancia viene representado por varias formas normales.

REUNION NATURAL

R	placa	marca
	MBO34L	Ford
	LDA75K	Toyota
	ADA89A	Fiat
	LBF78G	Toyota
	XSA67D	Ford

Q	Marca	Color
	Ford	Verde
	Toyota	Blanco
	Fiat	Gris
	Ford	rojo

T	Placa	Marca	Color
	MBO34L	Ford	verde
	MBO34L	Ford	rojo
	LDA75K	Toyota	blanco
	ADA89A	Fiat	Gris
	LBF78G	Toyota	blanco
	XSA67D	Ford	Verde
	XSA67D	Ford	rojo

Descomposición

Es el reemplazo de una relación R (A1, A2,…, An) por una colección de relaciones R’1, R’2,…,R’n obtenidas de las proyecciones de R y tal que la relación resultado de las reuniones R’1, R’2… R’n tiene el mismo esquema que R. R1 =  placa, modelo, color (Carro) R2 =  modelo, marca (Carro) R    Q ≠ Carro pero R1 *R2 = Carro

Descomposición sin pérdida

• Es la descomposición de una relación R en R’1, R’2,…,R’p tal que para toda extensión de R se tiene que: R = R’1 R’2… R’p

• El problema de la concepción de bases de datos relacionales se reduce a la descomposición sin pérdida de las relaciones universales con todos sus atributos en subrelaciones que no contengan anomalías

CUARTA FORMA FORMAL

La cuarta forma normal (4NF) es una forma normal usada en la normalización de bases de datos. La 4NF se asegura de que las dependencias multivaluadas independientes estén correcta y eficientemente representadas en un diseño de base de datos

Una tabla está en 4NF si y solo si esta en Tercera forma normal y no posee dependencias multivaluadas no triviales. La definición de la 4NF confía en la noción de una dependencia multivaluada. Una tabla con una dependencia multivaluada es una donde la existencia de dos o más relaciones independientes muchos a muchos causa redundancia; y es esta redundancia la que es suprimida por la cuarta forma normal.

Para entender mejor aún esto consideremos la tabla llamada estudiante que contiene los siguientes atributos: Clave, Especialidad, Curso tal y como se demuestra en la siguiente figura:

Clave	Especialidad	Curso
S01	Sistemas	Natación
S01	Bioquímica	Danza
S01	Sistemas	Natación
B01	Bioquímica	Guitarra
C03	Civil	Natación

          *existe dependencia de valores múltiples

Las dependencias de valores múltiples se definen de la siguiente manera: Clave ->->Especialidad y Clave->->Curso; Esto se lee "Clave multidetermina a Especialidad, y clave multidetermina a Curso"

Para eliminar la redundancia de los datos, se deben eliminar las dependencias de valores múltiples. Esto se logra construyendo dos tablas, donde cada una almacena datos para solamente uno de los atributos de valores múltiples.

Para nuestro ejemplo, las tablas correspondientes son:

Tabla Especialidad

Clave	Especialidad
S01	Sistemas
B01	Bioquímica
C03	Civil

Tabla Curso

Clave	Curso
S01	Natación
S01	Danza
B01	Guitarra
C03	Natación

OTRAS FORMAS FORMALES

Existen otras dos formas normales, la llamada quinta forma normal (5FN) que posee un dudoso valor práctico ya que conduce a una gran división de tablas y la forma normal dominio / clave (FNDLL) de la que no existe método alguno para su implantación.

Como ya se ha visto, las dependencias multivaloradas ayudan a comprender y a abordar algunas formas de repetición de la información que no pueden comprenderse en términos de las dependencias funcionales. Hay tipos de restricciones denominadas dependencias de reunión que generalizan las dependencias multivaloradas y llevan a otra forma normal denominada forma normal de reunión por proyección (FNRP) (la FNRP se denomina en algunos libros quinta forma normal). Hay una clase de restricciones todavía más generales, que lleva a una forma normal denominada forma normal de dominios y claves (FNDC).

Un problema práctico del empleo de estas restricciones generalizadas es que no sólo es difícil razonar con ellas, sino que tampoco hay un conjunto de reglas de inferencias seguras y completas para razonar sobre las restricciones. Por tanto, la FNRP y la forma normal de dominios y claves se utilizan muy raramente.