Tratamiento de valores nulos

Valores nulos

A menudo hay varias formas de tratar los valores nulos y, como resultado, las siguientes definiciones pueden ser a veces arbitrarias. Las operaciones y las comparaciones con valores nulos se deberían evitar siempre que sea posible. Dado que el valor especial nulo indica «valor desconocido o no existente», cualquier operación aritmética (como +, –, * y /) que incluya valores nulos debe devolver un valor nulo. De manera similar, cualquier comparación (como <, <=, >, >= y ≠) que incluya un valor nulo se evalúa al valor especial desconocido; no se puede decir si el resultado de la comparación es cierto o falso, así que se dice que el resultado es el nuevo valor lógico desconocido. Las comparaciones que incluyan nulos pueden aparecer dentro de expresiones booleanas que incluyan las operaciones y (conjunción), o (disyunción) y no (negación). Se debe definir la forma en que estas operaciones tratan el valor lógico desconocido.
•y: (cierto y desconocido) = desconocido; (falso y desconocido) = falso; (desconocido y desconocido)= desconocido.
•o: (cierto o desconocido) = cierto; (falso o desconocido)= desconocido; (desconocido o desconocido)= desconocido.
• no: (no desconocido) = desconocido.
select: la operación selección evalúa el predicado P en σP(E) sobre cada tupla de E. Si el predicado devuelve el valor cierto, se añade t al resultado. En caso contrario, si el predicado devuelve desconocido o falso, t no se añade al resultado.

Reunión

Producto cartesiano seguido de una selección. Por tanto, la definición de la forma en que 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 r se puede observar de la definición anterior que si dos tuplas, tr ∈r y ts ∈ s, tienen un valor nulo en un atributo común, entonces las tuplas no casan.

Ejemplo:
R = (A, B, C, D)
S = (E, B, D)
• Esquema de relación = (A, B, C, D, E)
• r x s se define como:
∏r.A, r.B, r.C, r.D, s.E(σr.B = s.B ∧r.D = s.D(r x s))

Proyección

Trata los nulos como cualquier otro valor al eliminar duplicados. Así, si dos tuplas del resultado de la proyección son exactamente iguales, y ambos tienen nulos en los mismos campos, se tratan como duplicados. La decisión es un tanto arbitraria porque sin saber cuál es el valor real no se sabe si los dos valores nulos son duplicados o no.

Unión, intersección, diferencia: tratan los valores nulos al igual que la operación proyección; tratan las tuplas que tienen los mismos valores en todos los campos como duplicados incluso si algunos de los campos tienen valores nulos en ambas tuplas. El comportamiento es un tanto arbitrario, especialmente en el caso de la intersección y la diferencia, dado que no se sabe si los valores reales (si existen) representados por los nulos son los mismos.

Proyección generalizada

Se describió la manera en que se tratan los nulos en las expresiones al principio del Apartado 3.3.4. Las tuplas duplicadas que contienen valores nulos se tratan como en la operación proyección. Cuando hay nulos en los atributos agregados, la operación borra los valores nulos del resultado antes de aplicar la agregación. Si el multiconjunto resultante está vacío, el resultado agregado es nulo. Obsérvese que el tratamiento de los valores nulos aquí es diferente que en las expresiones aritméticas ordinarias; se podría haber definido el resultado de una operación de agregación como nulo si incluso sólo uno de los valores agregados es nulo. Sin embargo, esto 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.

Ejemplo: 

Dada la relación info-credito(nombre-cliente, limite, saldocredito), encontrar cuanto puede gastar cada persona: 

∏nombre-cliente, limite – saldo-credito (info-credito)

Funciones de agregación

Las funciones de agregación toman como argumentos un conjunto de valores y devuelven un valor simple como resultado.
avg: valor medio
min: valor mínimo
max: valor máximo
sum: suma de valores
count: número de valores

Ejemplo:

Reunión externa

Las operaciones de reunión externa se comportan como las operaciones reunión, excepto sobre las tuplas que no aparecen en el resultado. Estas tuplas se pueden añadir al resultado (dependiendo de si la operación es , o ) añadiendo nulos.

Ejemplo:

 

Modelo Relacional con la 1ra Forma Normal

Posterior al modelo entidad-relación diseñamos el siguiente modelo relacional de nuestra base de datos aplicándole la 1ra forma normal:

Diagrama Entidad-Relación

El siguiente es nuestro diagrama entidad-relación obtenido del análisis de nuestro enunciado para la creación de una base de datos:

Integridad de datos

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 1

Un ejemplo a partir del sistema de base de datos que desarrollamos paralelamente en este blog es el de nuestros productos, ya que estos en ves de tenerlos como productos en general los dividimos en tipo de productos que son regalos mercería y papelería, y a su ves a cada producto en especifico se le asigna una clave primaria única.

Ejemplo 2

Como ejemplo una empresa dedicada a la venta de bebidas, podríamos identificar las bebidas de un modo general, a un modo más individual: todas las bebidas en un sólo grupo. Todas las bebidas de la misma marca en un grupo. Agrupar las bebidas en función de si son alcohólicas o no. Cada bebida de modo individual. Un hecho sobre una determinada bebida, como puede ser el sabor de un refresco.

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 1

En nuestra base de datos por ejemplo el atributo fecha_venta dividido en año mes y día solo aceptara entradas de datos de tipo entero de 4, 2 y 2 caracteres respectivamente; en caso de año solo aceptara entradas de números enteros de 4 caracteres entre 2012 (año en que entrara en función la BD) hasta el valor igual o menor del año en curso de la entrada, mes solo  aceptara entradas de números enteros de 2 caracteres entre 01 y 12, y en función de los datos anteriores día aceptara entradas de números enteros de 2 caracteres entre 01 y 28,29,30 ó 31 según sea el caso.

Ejemplo 2

Como ejemplo supongamos el sistema de base de datos de una Universidad, en el atributo calificación de la entidad alumno los valores permitidos deberán estar restringidos en un dominio que acepte únicamente entradas de tipo entero menores o iguales a 100 y mayores o iguales a 70, en caso de que la calificación sea menor a 70 la entrada deberá ser 0.

Integridad referencial.

La integridad referencial protege las relaciones definidas entre las tablas cuando se crean o se eliminan filas. La integridad referencial se basa en las relaciones entre claves externas y claves principales o entre claves externas y claves exclusivas, mediante restricciones FOREIGN KEY y CHECK. La integridad referencial garantiza que los valores de clave sean coherentes en las distintas tablas. Para conseguir esa coherencia, es preciso que no haya referencias a valores inexistentes y que, si cambia el valor de una clave, todas las referencias a ella se cambien en consecuencia en toda la base de datos.

Ejemplo 1.

Sea una base de datos relacional:

· CIUDAD (C#, NOMBRE, HABITANTES)

· CARRETERA (A#, DESCRIPCION, CATEGORIA)

· RUTA (C#1, C#2, A#)

· ENLACE (C#1, C#2, C#3)

Donde C#1 y C#2 son códigos de ciudad ¿Se podría poner como restricción de integridad referencial entre la relación CIUDAD y la relación RUTA para C1# DELETE CASCADE y para C2# DELETE RESTRICT? ¿Y entre la relación CIUDAD y la relación ENLACE? ¿En ambos casos sería relevante la restricción de integridad referencial entre la relación CARRETERA y las relaciones RUTA y ENLACE?

La estructura referencial que representaría la DB relacional propuesta se representa de la siguiente manera:

Se puede observar que existen dos caminos desde la relación CIUDAD a la relación RUTA, consecuentemente por ambos las opciones de integridad deber ser iguales.

Para el caso de CIUDAD y ENLACE, el razonamiento sería idéntico.

Las restricciones de integridad referencial entre la relación CARRETERA y las relaciones RUTA y ENLACE no influyen en el carácter correcto o incorrecto de la estructura referencial

Ejemplo 2.

Sea una base de datos relacional:

· PROFESOR (P#, NOMBRE, A#)

· ASIGNATURA (A#, TITULO, D#)

· DEPARTAMENTO (D#, NOMBRE, CURSO)

· ESTUDIA (E#, A#, P#)

Se requiere contestar de una manera justificada lo siguiente:

a) ¿Qué tipo de estructura referencial tenemos?

b) ¿se podría poner como restricción de integridad referencial entre la relación ESTUDIA y la relación ASIGNATURA: DELETE CASCADE, sabiendo que entre la relación ESTUDIA y la relación PROFESOR la restricción establecida es DELETE RESTRICT?

c) ¿Y so entre la relación ESTUDIA y la relación PROFESOR la restricción es DELETE CASCADE, siendo la restricción referencial entre PROFESOR y ASIGNATURA DELETE SET NULL?

d) ¿En ambos casos sería relevante la restricción de integridad referencial entre la relación ESTUDIANTE y la relación ESTUDIA?

La estructura referencial que representaría la DB relacional propuesta se representa de la siguiente manera: 

a) No existen ciclos: por lo tanto la estructura referencial es lineal

b) Hay dos caminos desde la relación ASIGNATURA a la relación ESTUDIA, consecuentemente por ambos las opciones de integridad deben ser iguales

c) Si se borra una asignatura se borrarían directamente todas las tuplas de la relación ESTUDIA cuyo valor de código de asignatura coincida con el valor borrado. Por el otro camino el código de asignatura en la relación PROFESOR se pondría a valor NULL, no borrándose tupla alguna, y así no se propaga ningún borrado a la relación ESTUDIA.

d) La restricción de integridad referencial entre la relación ESTUDIANTE y la relación ESTUDIA no influye en el carácter correcto o incorrecto de la estructura referencial.

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.

Tipos de restricciones de integridad

•  Datos Requeridos: establece que una columna tenga un valor no NULL. Se define efectuando la declaración de una columna es NOT NULL cuando la tabla que contiene las columnas se crea por primera vez, como parte de la sentencia CREATE TABLE.
• Chequeo de Validez: cuando se crea una tabla cada columna tiene un tipo de datos y el DBMS asegura que solamente los datos del tipo especificado sean ingresados en la tabla.
•  Integridad de entidad: establece que la clave primaria de una tabla debe tener un valor único para cada fila de la tabla; si no, la base de datos perderá su integridad. Se especifica en la sentencia CREATE TABLE. El DBMS comprueba automáticamente la unicidad del valor de la clave primaria con cada sentencia INSERT Y UPDATE. Un intento de insertar o actualizar una fila con un valor de la clave primaria ya existente fallará.
•  Integridad referencial: asegura la integridad entre las llaves foráneas y primarias (relaciones padre/hijo). Existen cuatro actualizaciones de la base de datos que pueden corromper la integridad referencial:
•  La inserción de una fila hijo se produce cuando no coincide la llave foránea con la llave primaria del padre.
•  La actualización en la llave foránea de la fila hijo, donde se produce una actualización en la clave ajena de la fila hijo con una sentencia UPDATE y la misma no coincide con ninguna llave primaria.
•  La supresión de una fila padre, con la que, si una fila padre -que tiene uno o más hijos- se suprime, las filas hijos quedarán huérfanas.
• La actualización de la llave primaria de una fila padre, donde si en una fila padre, que tiene uno o más hijos se actualiza su llave primaria, las filas hijos quedarán huérfanas.

Tarea IV: Algoritmos de descomposición & Formas normales superiores.

7.4 descomposición

Dentro del diseño de bases de datos relacionales, puntualmente en la aplicación de la primera forma normal, podemos encontrar anomalías en el diseño, tales como la redundancia de datos, por lo que se debe replantar el diseño haciendo algunas modificaciones que eliminen dichas redundancias.

Partiendo de este echo, debemos modificar nuestro esquema de relación en el que tenemos redundancias descomponiéndolo en sub-esquemas con menor cantidad de atributos; esta descomposición debe ser cuidadosa, debido a que una mala descomposición nos lleva a otra modalidad de mal diseño.

Tras descomponer el esquema principal en sub-esquemas debemos tener en cuenta que entre estos debe haber solo un atributo en común mediante el cual relacionaremos nuestros esquemas, sin embargo debemos ser cuidadosos con este atributo ya que a su vez este debe ser la única forma en que se puedan generar las relaciones entre sub-esquemas, es decir, que cumpla con la dependencia funcional.

De ser así decimos que tenemos una descomposición de reunión sin pérdida caso contrario si no se cumple decimos que tenemos una descomposición de reunión con pérdida lo que significa un mal diseño de base de datos.

Para ejemplificar lo anterior, partamos del siguiente esquema de una compañía de telefonía:

nombre_tienda	ciudad_tienda	capital	nombre_cliente	num_contrato	mensualidad
Galerías	Pachuca	250000	Vargas	tel-01	1000
Gran patio	Pachuca	150000	Escamilla	tel-13	560
Satélite	DF	300000	Muñoz	tel-31	320
Centro Histórico	DF	350000	Pérez	tel-22	560
Tulancingo Centro	Tulancingo	100000	Juárez	tel-14	1500
Galerías	Pachuca	250000	Escamilla	tel-99	540
Satélite	DF	300000	Muñoz	tel-29	2000
Centro Histórico	DF	350000	Cortes	tel-95	1700
Satélite	DF	300000	Gutiérrez	tel-43	360
Tulancingo Centro	Tulancingo	100000	Cerón	tel-70	850

Esquema renta_equipos

A partir de aquí pudiésemos descomponerlo en los siguientes esquemas:

nombre_tienda	ciudad_tienda	capital	nombre_cliente
Galerías	Pachuca	250000	Vargas
Gran patio	Pachuca	150000	Escamilla
Satélite	DF	300000	Muñoz
Centro Histórico	DF	350000	Pérez
Tulancingo Centro	Tulancingo	100000	Juárez
Galerías	Pachuca	250000	Escamilla
Satélite	DF	300000	Muñoz
Centro Histórico	DF	350000	Cortes
Satélite	DF	300000	Gutiérrez
Tulancingo Centro	Tulancingo	100000	Cerón

Tienda-cliente

nombre_cliente	num_contrato	mensualidad
Vargas	tel-01	1000
Escamilla	tel-13	560
Muñoz	tel-31	320
Pérez	tel-22	560
Juárez	tel-14	1500
Escamilla	tel-99	540
Muñoz	tel-29	2000
Cortes	tel-95	1700
Gutiérrez	tel-43	360
Cerón	tel-70	850

Cliente-renta

De esta descomposición podemos observar que para el caso de que un cliente tenga contratos en más de una tienda, las tuplas no permiten determinar que préstamo es de qué sucursal provocando una perdida de información que nos lleva a una descomposición de reunión con pérdida.

Sin embargo podemos descomponer nuestro esquema en los siguientes sub-esquemas:

nombre_tienda	ciudad_tienda	capital
Galerías	Pachuca	250000
Gran patio	Pachuca	150000
Satélite	DF	300000
Centro Histórico	DF	350000
Tulancingo Centro	Tulancingo	100000

Esquema-tienda

nombre_tienda	nombre_cliente	num_contrato	mensualidad
Galerías	Vargas	tel-01	1000
Gran patio	Escamilla	tel-13	560
Satélite	Muñoz	tel-31	320
Centro Histórico	Pérez	tel-22	560
Tulancingo Centro	Juárez	tel-14	1500
Galerías	Escamilla	tel-99	540
Satélite	Muñoz	tel-29	2000
Centro Histórico	Cortes	tel-95	1700
Satélite	Gutiérrez	tel-43	360
Tulancingo Centro	Cerón	tel-70	850

Esquema-contrato

De aquí observamos que se tiene en común el atributo nombre_tienda y este atributo si cumple la dependencia funcional:

Nombre_tienda→capital, ciudad_tienda

Asi pues podemos decir que tenemos una descomposición de reunión sin pérdida.

7.5 propiedades deseables de la descomposición

Existen algunas ocasiones en las que es necesario descomponer relaciones en otras relaciones de menor tamaño con el fin de obtener ciertas propiedades que son necesarias y que con una relación concreta no se distinguían a la perfección.

7.5.1 descomposición de reunión sin pérdida 

Dado un esquema de relación R y sea F un conjunto de dependencias funcionales del esquema de relación R, R1, R2 se forma así una descomposición en R, se dice que una descomposición es una descomposición de reunión sin pérdida si al menos una dependencia de R se encuentra en F⁺, es decir, si las dependencias funcionales R1 o R2 forman una superclave ya sea de R1 o R2, la descomposición de R es una descomposición de reunión sin pérdida.

Para ejemplificar la descomposición de reunión sin perdida veamos el ejemplo siguiente:

Esquema-tienda=( nombre_tienda, ciudad_tienda, capital)

Esquema-contrato=(nombre_tienda, nombre_cliente, num_contrato, mensualidad)

Como se puede observar nombre_tienda→ ciudad_tienda, capital, esto nos implica que:

nombre_tienda→ nombre_tienda ciudad_tienda, capital

Podemos ver que Esquema-tienda⋂Esquema-contrato={nombre_tienda}, demostrando así que la descomposición inicial es una descomposición sin perdida.

7.5.2 conservación de las dependencias

Se dan algunos casos en los que se necesita actualizar la base de datos y con ello se requiere verificar que todas las relaciones continúen realizando su tarea y que no se realizaron relaciones que no satisfacen las necesidades del sistema.Para poder comprobar de manera eficiente las actualizaciones proporcionadas se necesitan elaborar esquemas de BD que permitan la validación de las actualizaciones sin necesidad de calcular los productos que reconstruyen las relaciones.

Para verificar si es necesario calcular las reuniones para comprobar una actualización se deben determinar las dependencias funcionales que hay que comprobar verificando cada relación una a una.

Partiendo de que F es un conjunto de dependencias funcionales del esquema R y R1, R2,...,Rn una descomposición de R, es posible comprobar el cumplimiento de la condición por una dependencia verificando sólo una relación.

Otra forma de ver que la descomposición conserva las dependencias es verificar si se puede comprobar cada miembro del conjunto de dependencias funcionales F para cada una de las relaciones de la descomposición, pero esto no siempre es así ya que hay casos en los que alguna dependencia de F no se puede comprobar con ninguna relación de la descomposición y por lo tanto se tendría que aplicar una prueba general.

Para que nos quede mas claro este término veamos el ejemplo siguiente:

nombre_tienda→ ciudad_tienda, capital utilizando el esquema-tienda=(nombre_tienda, ciudad_tienda, capital)

Como podemos ver cada miembro de de F pertenece a una descomposición de R demostrando así la conservación de dependencias.

7.5.3 Repetición de la información

Se dan algunos casos en los que es necesario introducir la misma información más de una vez todo esto con el fin de satisfacer las tuplas requeridas, pero una vez realizada la descomposición de relaciones se puede observar que los datos se separan eliminando así las redundancias que se presenten.

7.8 Cuarta Forma Normal

Aunque ya se tengan normalizados los esquemas de relación en la (3FN), pueden tener el problema de la redundancia de datos y ya no es suficiente solo tener dependencias funcionales, para tratar este problema se requiere implementar una nueva forma de restricción que se denomina dependencia multivalorada. Esta dependencia no impide la existencia de tulpas con el mismo valor, exigen que estén presentes en la relación. Se puede utilizar para especificar restricciones del conjunto de relaciones; sólo habrá que preocuparse de las relaciones que satisfagan un conjunto dado de dependencias funcionales y multivaloradas. Este tipo de normalización es igual que el FNBC pero en lugar de dependencias funcionales se encuentran las multivaloradas. En pocas palabras la 4FN consiste en descomponer una relación con dependencias funcionales a un esquema donde contenga dependencias multivaloradas  y a abordar algunas formas de repetición de la información que no pueden comprenderse en términos de las dependencias funcionales. Ejemplo:

Esquema-BC = (número-préstamo, nombre-cliente,

                                                                       calle-cliente, ciudad-cliente)

se emplea el algoritmo de descomposición con dependencias multivaloradas

Esquema-prestatario = (nombre-cliente,

                                          número-préstamo)

Esquema-cliente = (nombre-cliente, calle-cliente,

           ciudad-cliente).

7.9 Otras Formas Normales

Este tipo de normalización de utiliza mas raramente ya que no hay reglas o normas para razonar las restricciones a aplicar, es generalizar las dependencias multivaloradas con lo cual llevan a una forma normal de reunión por proyección.