Normalización - script

From Ibbddunq

Revision as of 21:01, 8 May 2009

Enganche con el Navathe 5ta edición

Este tema está cubierto por los caps 10 y 11. Este curso incluye específicamente el material en:

• 10.1
• 10.2.1 y 10.2.2
• 10.3
• 10.4
• 11.1, excepto la parte de definiciones formales y algoritmos
• intro a 11.3, 11.3.1, 11.3.3

Motivación

En el curso vimos una forma de llegar al esquema de una BD relacional: arrancar por un MER y traducirlo. Hay otras formas, p.ej. armar una bolsa con todos los atributos que quiero y después ir separándolos en tablas.

P.ej. te dicen ... (o bien artista y trailer, o bien funcion / formaParte / acto).

¿Es correcta esta base? Si les preguntan por qué no, ¿qué dirían, cómo lo justificarían? A partir de estos atributos, ¿cómo armarían un esquema de BD que tenga la misma info y que esté bien?

Hoy vamos a hablar de

• criterios de calidad de esquemas de BD, que se suman a las anomalías y restricciones de integridad que vimos al estudiar MR.
• cómo transformar un esquema en otro que sí cumpla con las restricciones de calidad adicionales.

O sea, estas restricciones también las vamos a garantizar sin necesidad de programa.

Si armamos primero el MER y después lo traducimos a MR con las reglas que vimos, la BD que resulta cumple las restricciones que vamos a ver; o sea, una buena manera de armar un esquema de MR, es armarlo en MER y después pasarlo; o hacerlo directamente en MR, pero pensar en "cómo sería el MER de esta parte" ante dudas.

Un poco para verificar que una traducción MER -> MR quedó OK, y bastante porque hay mucha gente en el mundo que no sabe MER, vamos a estudiar estos criterios de calidad y las formas de ir mejorando el esquema de una BD.

Criterio de calidad fundamental - semántica

Cuando arman un esquema de BD, para cada tabla que les quedó deberían ser capaces de responder en forma sencilla a alguna de estas dos preguntas

• ¿qué representa cada fila?
• ¿qué quiere decir que la tabla incluya una fila con ciertos valores?

Ver ejemplos del circo.

Anomalías y pautas informales

Anomalías de actualización (págs 340 a 343)

(trabajar con el ejemplo de tabla funcion + formaParte

• de inserción: no sabés qué insertar (función sin actos asignados) y/o tenés que meter algunos valores iguales que otra fila, (2do acto de una función).
• de eliminación: había programado un solo acto para una función, me arrepiento, borro la fila correspondiente.
• de modificación: si cambio un dato de una función (ponele que aumento la entrada), lo tengo que cambiar en todos los formaParte para la misma función.

2. pautas, que vienen a atacar los mismos problemas

• no mezclar atributos de distintas entidades en la misma tabla.
• que no quede info repetida excepto FKs.
• los enganches deben ser FK-PK, ponele que enganchás funcion y formaParte por la ciudad. Ver qué pasaría al joinear en ese caso -> tablas espurias.

Dependencias funcionales

Definición:

  X -> Y si t1(X) = t2(X) => t1(Y) = t2(Y)

A partir de este concepto podemos definir

• superclave de una tabla
• clave de una tabla

Las 6 reglitas - pág 350.

Formas normales

Qué son: restricciones de calidad que ayudan a que no se puedan producir anomalías. O sea, si un esquema de BD cumple con la restricción xFN (veremos x de 1 a 4), cuanto más alto el x, más hay que ingeniarse para que que haya anomalías.

Hay varias formas de definirlas, más o menos equivalentes. Nosotros nos quedamos con lo que sigue porque creemos que es la forma en que se entienden mejor.

1FN: sin repeticiones.

2FN: 1FN + sin dependencias parciales.

3FN: 2FN + sin dependencias transitivas.

Cómo trabajar un esquema para ir subiendo la FN

• parcial, ponele clave A+B y A determina C. Se crea una nueva tabla A+C, se saca C de la tabla original, A es una FK a la nueva tabla. Ejemplo:

 <funcion,acto,gradoPel>

• transitiva, ponele A determina B y B determina C. Se van B y C a otra tabla, se tacha C de la tabla original, B es una FK a C. Ejemplo:

 <funcion,ciudad,provincia>

Estas reglas no cubren todos los casos, ver p.e