Habla de normalizacion bases de datos

2. DependenciaFuncional Por ejemplo, sea la siguiente relacion: Vehiculo(serie, nombre, motor, carroceria, peso, eficiencia). Aqui, serie es la clave. Por ende, hay solo un [modelo de] motor por serie, solo una [forma de] carroceriapor serie, solo un peso por serie y solo una eficiencia [energetica] por serie: nombre = nombre( serie), motor = motor(serie), asi, como sigue. O sea, serie nombre, motor, carrocera, peso, eficiencia (la relación es función de su clave; solo hay una tupla por clave). Sea un relación Película(título, año, estudio, presidente, fono_presidente). Digamos que ”título” es la clave de la relación (determina todo). Sin embargo, notemos que el presidente de un estudio se puede determinar conociendo el estudio y el año (idealmente). estudio, año presidente. Además, es claro que presidente fono_presidente. La relación ”Película” fue mal modelada desde un principio. En un modelo entidad-relacion, ”Película”, ”Estudio” y ”Presidente” deberían ser entidades distintas, luego relaciones distintas en el modelo relacional.

3. Normalización la normalización son una serie de reglas que sirven para ayudar a los diseñadores de bases de datos a desarrollar un esquema que minimice los problemas de lógica a proteger los datos, lo cual permite hacer que la base de datos sea más flexible al eliminar la redundancia y las dependencias incoherentes. ¿Qué es una "dependencia incoherente"? Aunque es intuitivo para un usuario mirar en la tabla Clientes para buscar la dirección de un cliente en particular, puede no tener sentido mirar allí el salario del empleado que llama a ese cliente. El salario del empleado está relacionado con el empleado, o depende de él, y por lo tanto se debería pasar a la tabla Empleados. Las dependencias incoherentes pueden dificultar el acceso porque la ruta para encontrar los datos puede no estar o estar interrumpida. Las guías que la normalización provee crean el marco de referencia para simplificar una estructura de datos compleja. Se toma un esquema relacional y se le aplica un conjunto de técnicas para producir un nuevo esquema que representa la misma información pero contiene menos redundancias y evita posibles anomalías en las inserciones, actualizaciones y borrados. tablas relacionales se pueden definir diferentes restricciones La integridad de entidad: Cada entidad representada por una tupla o fila tiene que ser diferente de las demás en su relación(Claves primarias). La integridad referencial: La clave foránea solo debe contener valores que o bien sean nulos, o bien existan en la relación referenciada por la clave foránea. http://es.wikipedia.org/wiki/Normalizaci%C3%B3n_de_bases_de_datos

4. Normalización Esquema relacional EMPLEADOS(idnumero, nombre, puesto, salario, emails) con idnumerocomo clave primaria.

5. Primera forma normal (1FN) Una tabla está en 1FN si sus atributos contienen valores atómicos. En el ejemplo, podemos ver que el atributo emails puede contener más de un valor, por lo que viola 1FN. http://es.wikipedia.org/wiki/Primera_forma_normal tenemos dos opciones. Solución 1: duplicar los registros con valores repetidos En general, esta solución pasa por sustituir R por una nueva relación modicada R', en la cual: El atributo M que violaba 1FN se elimina. Se incluye un nuevo atributo M' que solo puede contener valores simples, de modo que si R'[M'] es uno de los valores que teníamos en R[M], entonces R'[K] = R[K]. En otras palabras, para una tupla con n valores duplicados en M, en la nueva relación habrá n tuplas, que sólo varían en que cada una de ellas guarda uno de los valores que había en M. La clave primaria de R' es (K, M'), dado que podrá haber valores de K repetidos, para los valores multivaluados en M.

7. tenemos dos opciones.

8. Solución 1: duplicar los registros con valores repetidos

9. Sustituir R por una nueva relación modicada R', en la cual:

10. El atributo M que violaba 1FN se elimina. Se incluye un nuevo atributo M' que solo puede contener valores simples, de modo que si R'[M'] es uno de los valores que teníamos en R[M], entonces R'[K] = R[K].

11. La clave primaria de R' es (K, M'), dado que podrá haber valores de K repetidos, para los valores multivaluados en M.la nueva tabla EMPLEADOS'(a) clave primaria(PK) (idnumero, email):

13. sustituir R por una nueva relación modificada R' que no contiene el atributo M.

14. Crear una nueva relación N(K, M'), es decir, una relación con una clave foránea K referenciando R', junto al atributo M', que es la variante mono-valuada del atributo M.

15. La nueva relación N tiene como clave (K, M').la nueva tabla EMPLEADOS‘(b) la nueva tabla EMAILS clave primaria(PK) (idnumero, email):

16. Segunda forma normal (2FN) Está en 1FN. Todos sus atributos que no son de la clave principal tienen dependencia funcional completa respecto de todas las claves existentes en el esquema. En otras palabras, para determinar cada atributo no clave se necesita la clave primaria completa, no vale con una subclave. La 2FN se aplica a las relaciones que tienen claves primarias compuestas por dos o más atributos. Si una relación está en 1FN y su clave primaria es simple (tiene un solo atributo), entonces también está en 2FN. En general, tendremos que observar los atributos no clave que dependan de parte de la clave. http://es.wikipedia.org/wiki/Segunda_forma_normal Para solucionar este problema, tenemos que hacer lo siguiente para los grupos de atributos con dependencia incompleta M: Eliminar de R el atributo M. Crear una nueva relación N con el atributo M y la parte de la clave primaria K de la que depende, que llamaremos K'. La clave primaria de la nueva relación será K'.

18. Por tanto, la tabla EMPLEADOS'(b) está en 1FN

19. La tabla EMAILS no tiene atributos no clave, por lo que el esquema está en 2FN. tabla EMPLEADOS‘(b) tabla EMAILS clave primaria(PK) (idnumero, email):

21. Las dependencias funcionales que tenemos son las siguientes:

22. Idnumero->nombre, salario, email

23. puesto->salario

24. Como la clave es (idnumero, email), las dependencias de nombre, salario y email son incompletas, por lo que la relación no está en 2FN. tabla EMPLEADOS'(a) clave primaria(PK) (idnumero, email)

26. Eliminar de Empleados(a) el atributo EMAILS como resultado queda la relación EMPLEADOS’(d) .

27. Crear una nueva relación EMAILS con el atributo emails y la parte de la clave primaria de empleados (idnumero) de la que depende, que llamaremos K'.

28. La clave primaria de la nueva relación será PK'. tabla EMPLEADOS’(d) tabla EMAILS clave primaria(PK’) (idnumero, email):

29. Tercera forma normal (3FN) Está en 2FN. Ningún atributo no-primario de la tabla es dependiente transitivamente de una clave candidata o primaria La 2FN se aplica a las relaciones que tienen claves primarias compuestas por dos o más atributos. Si una relación está en 1FN y su clave primaria es simple (tiene un solo atributo), entonces también está en 2FN. En general, tendremos que observar los atributos no clave que dependan de parte de la clave. http://es.wikipedia.org/wiki/Tercera_forma_normal Para solucionar este problema, tenemos que hacer lo siguiente para los grupos de atributos con dependencia incompleta M: Determinar los atributos que son dependientes de un atributo que no es clave. Sustituir R por una nueva relación modicada R', en la cual: El o los atributos M que son dependientes se eliminan. Crear una nueva relación N con los atributos M que son dependientes y la clave primaria K de la que depende, que llamaremos K'.

32. Eliminar de ordenes(a) los atributos NOM_CLIENTE y ESTADO como resultado queda la relación ORDENES’(d) .

33. Crear una nueva relación CLIENTES con el atributo ID_CLIENTE como clave primaria, y los atributos NOM_CLIENTES y ESTADO que son atributos dependientes de ID_CLIENTETabla Ordenes ’(d) Tabla Clientes(d)

34. NORMALIZACIÓN Los datos redundantes desperdician el espacio de disco y crean problemas de mantenimiento, por esto es de gran utilidad hacer normalización en la base de datos. La normalización no es una ciencia exacta, más bien subjetiva. “Cumplir la tercera forma normal, aunque en teoría es deseable, no siempre es práctico. Si tiene una tabla Clientes y desea eliminar todas las dependencias posibles entre los campos, debe crear tablas independientes para las ciudades, códigos postales, representantes de venta, clases de clientes y cualquier otro factor que pueda estar duplicado en varios registros. En teoría, la normalización merece el trabajo que supone. Sin embargo, muchas tablas pequeñas pueden degradar el rendimiento o superar la capacidad de memoria o de archivos abiertos. Puede ser más factible aplicar la tercera forma normal sólo a los datos que cambian con frecuencia. Si quedan algunos campos dependientes, diseñe la aplicación para que pida al usuario que compruebe todos los campos relacionados cuando cambie alguno.”