O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Normalizacion

83 visualizações

Publicada em

Diseño de base de datos relacional, dando a conocer las características y propiedades con las que debe contar el diseño relacional para lograr una personificación apropiada con la realidad además de cuáles son los inconvenientes que se pueden presentar al realizar un mal diseño

Publicada em: Educação
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Normalizacion

  1. 1. NORMALIZACIÒN Técnica para diseñar la estructura lógica de los datos de un sistema de información en el modelo relacional, desarrollada por E. F. Codd en 1972.
  2. 2. Al tener las tablas ya relacionadas se deben de aplicar reglas de normalización de todas las tablas. • Las bases de datos relacionales se normalizan para: • Evitar la redundancia de datos. • Evitar problemas de actualización de los datos en las tablas. • Proteger la integridad de los datos.
  3. 3. Siempre que se diseña un sistema no solo una base de datos, si no también cualquier tipo de solución informática, se ha de medir la calidad de la misma, y sino cumple determinados criterios de calidad, hay que realizar, de forma iterativa, sucesivos refinamiento en el diseño., para alcanzar la calidad deseada. Uno de los parámetros que mide la calidad de una base de datos es la forma normal en la que se encuentra su diseño. Esta forma normal puede alcanzarse cumpliendo ciertas restricciones que imponen cada forma normal al conjunto de atributos de un diseño. El proceso de obligar a los atributos de un diseño cumplir ciertas formas normales se llama NORMALIZACIÒN.
  4. 4. Refinamiento de un diseño de base de datos
  5. 5. CONCEPTUALIZACIÒN La normalización es el proceso mediante el cual se transforman datos complejos a un conjunto de estructuras de datos más pequeñas, que además de ser más simples y más estables, son más fáciles de mantener. También se puede entender la normalización como 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. La normalización se adoptó porque el viejo estilo de poner todos los datos en un solo lugar, como un archivo o una tabla de la base de datos, era ineficiente y conducía a errores de lógica cuando se trataban de manipular los datos El proceso de normalización tiene un nombre y una serie de reglas para cada fase. Esto puede parecer un poco confuso al principio, pero poco a poco se va entendiendo el proceso, así como las razones para hacerlo de esta manera. En el modelo relacional es frecuente llamar tabla a una relación, aunque para que una tabla sea considerada como una relación tiene que cumplir con algunas restricciones: •Cada columna debe tener su nombre único. •No puede haber dos filas iguales. No se permiten los duplicados. •Todos los datos en una columna deben ser del mismo tipo.
  6. 6. Dependencia funcional Relación entre atributos de una misma tabla. Si x e y son atributos de la relación R, se dice que y es funcionalmente dependiente de x (se denota por x → y) si cada valor de x tiene asociado un solo valor de y (x e y pueden constar de uno o varios atributos). A x se le denomina determinante, ya que x determina el valor de y. Se dice que el atributo y es completamente dependiente de x si depende funcionalmente de x y no depende de ningún subconjunto de x. La dependencia funcional es una noción semántica. Si hay o no dependencias funcionales entre atributos no lo determina una serie abstracta de reglas, sino, más bien, los modelos mentales del usuario y las reglas de negocio de la organización o empresa para la que se desarrolla el sistema de información. Cada dependencia funcional es una restricción y representa una relación de uno a muchos (o de uno a uno).
  7. 7. Dependencia funcional En el proceso de normalización se debe ir comprobando que cada tabla cumple una serie de reglas que se basan en la clave primaria y las dependencias funcionales. Cada regla que se cumple aumenta el grado de normalización. Si una regla no se cumple, la tabla se debe descomponer en varias tablas que sí la cumplan. La normalización se lleva a cabo en una serie pasos. Cada paso corresponde a una forma normal que tiene unas propiedades. Conforme se va avanzando en la normalización, las tablas tienen un formato más estricto (más fuerte) y, por lo tanto, son menos vulnerables a las anomalías de actualización. El modelo relacional sólo requiere un conjunto de tablas en primera forma normal (en caso contrario no se pueden implementar). Las restantes formas normales son opcionales. Sin embargo, para evitar las anomalías de actualización, es recomendable llegar al menos a la tercera forma normal.
  8. 8. (Y no depende de X) Ejemplo 1 PRODUCTOS (CódigoProducto, Nombre, Fabricante, País) CódigoProducto Fabricante Fabricante → País CódigoProducto - → País, es decir, CódigoProducto depende transitivamente de País Ejemplo 2: PRODUCTOS (CódigoProducto, Nombre, Fabricante, País) CódigoProducto Nombre Nombre → CódigoProducto CódigoProducto - → Nombre
  9. 9. FORMAS NORMALES •Primera forma normal •Segunda forma normal •Tercera forma normal •Forma normal de Boyce/Codd •Otras formas norlames Primera Forma Normal 1FN •Una tabla está en primera forma normal (1FN) si, y sólo si, todos los dominios de sus atributos contienen valores atómicos, es decir, no hay grupos repetitivos. Un grupo repetitivo es un atributo que puede tener múltiples valores para cada fila de la relación.
  10. 10. Si se tiene la relación Alumnos con los siguientes campos: codigo_alum, nombre_alum y asignaturas_alum, de los cuales el campo asignaturas_alum, almacena las asignaturas en las que recibe clases cada alumno. Se observa en la relación Alumnos, los registros dos y tres tienen dominios que contienen varios valores por tanto la relación no se encuentra en primera forma normal. Para convertir esta relación en la primera forma normal se crea una nueva relación Asignatura, en donde cada asignatura responderá a una clave principal. Ejemplo
  11. 11. FORMAS NORMALES •Primera forma normal •Segunda forma normal •Tercera forma normal •Forma normal de Boyce/Codd •Otras formas normales Segunda Forma Normal 2FN •Una tabla está en segunda forma normal (2FN) si, y sólo si, está en 1FN y, además, cada atributo que no forma parte de la clave primaria es completamente dependiente de la clave primaria. •La 2FN se aplica a las tablas que tienen claves primarias compuestas por dos o más atributos. Si una tabla está en 1FN y su clave primaria es simple (tiene un solo atributo), entonces también está en 2FN. •Las tablas que no están en 2FN pueden sufrir anomalías cuando se realizan actualizaciones sobre ellas.
  12. 12. Ejemplo la relación Pedidos ya se encuentra en su segunda forma normal inicialmente por el hecho de estar en primera forma normal y contar como clave principal con un único atributo Mientras que en lo que respecta a la relación denominada Linea_pedidos, para que logre estar en su segunda forma normal se deberá verificar que todos sus atributos que no son considerados clave, como lo son la descrip_art, cantidad_art y pvp_art, respondan completamente a la clave principal, por lo tanto, lo siguiente quiere decir que deben tener totalmente una dependencia funcional con relación al par de atributos (codigo_ped, codigo_art): (codigo_ped, codigo_art) ⇒ Descrip_art (codigo_ped, codigo_art) ⇒ cantidad_art (codigo_ped, codigo_art) ⇒ pvp_art
  13. 13. Ejemplo Primera dependencia funcional total: No es verdadera ya que la descripción del artículo responde únicamente al código del mismo y no al código del pedido que lo solicita, por ende, es considerada como verdadera la dependencia parcial entre codigo_art → descrip_art. Por este motivo se puede asegurar que la relación Linea_pedidos no se encuentra en su segunda forma normal. Segunda dependencia funcional total: Es considerada como verdadera ya que la cantidad que es solicitada de un artículo por un pedido no está determinada únicamente por el pedido con el que se está tratando o el artículo que es requerido, sino por los dos. Es decir que se tendría lo siguiente codigo_ped → cantidad_art, puesto que en un pedido sería posible solicitar varias y distintas cantidades de artículos el que se está tratando o el artículo que es requerido, sino por los dos. Es decir que se tendría lo siguiente codigo_ped → cantidad_art, puesto que en un pedido sería posible solicitar varias y distintas cantidades de artículos. Tercera dependencia funcional total: Es considerada verdadera cuando los valores correspondientes a los artículos no son siempre los mismos para los pedidos. Es común que el valor de cada artículo sea el mismo para todos y cada uno de los clientes, es por esto que se comprueba la dependencia funcional codigo_art → pvp_art, motivo por el cual tampoco se cumple que aquel atributo que no es clave pvp_art vaya totalmente a depender de la clave, lo cual indicaría otra razón para que la relación no se encuentre en su segunda forma normal. Otra manera de observar cuando una relación se encuentra en su segunda forma normal es examinando su diagrama de dependencias funcionales.
  14. 14. FORMAS NORMALES •Primera forma normal •Segunda forma normal •Tercera forma normal •Forma normal de Boyce/Codd •Otras formas normales Tercera Forma Normal 3FN •Una tabla está en tercera forma normal (3FN) si, y sólo si, está en 2FN y, además, cada atributo que no forma parte de la clave primaria no depende transitivamente de la clave primaria. La dependencia x −→ z es transitiva si existen las dependencias x −→ y, y −→ z, siendo x, y, z atributos o conjuntos de atributos de una misma tabla. •La tercera forma normal se fundamenta del concepto de dependencia transitiva, por lo tanto, se dice que una relación está en tercera forma normal solo si sus atributos dependen únicamente a la clave principal mas no de otros atributos. •Para renunciar a las dependencias transitivas se debe descartar de la relación que no se encuentra en tercera forma normal el atributo que genera la dependencia transitiva y se crea una relación que contenga los atributos transitivos conjuntamente con el atributo del que requiere es decir mediante el cual conserva su transitividad. PRODUCTOS (CódigoProducto, Nombre, Fabricante, País). CódigoProducto → Fabricante Fabricante → País CódigoProducto - -/→País País depende transitivamente de CódigoProducto, por tanto, no está en tercera forma normal.
  15. 15. FORMAS NORMALES •Primera forma normal •Segunda forma normal •Tercera forma normal •Forma normal de Boyce/Codd •Otras formas normales Forma normal de Boyce/Codd • Una tabla está en la forma normal de Boyce–Codd (BCFN) si, y sólo si, todo determinante es una clave candidata. • La 2FN y la 3FN eliminan las dependencias parciales y las dependencias transitivas de la clave primaria. Pero este tipo de dependencias todavía pueden existir sobre otras claves candidatas, si éstas existen. La BCFN es más fuerte que la 3FN, por lo tanto, toda tabla en BCFN está en 3FN. • La violación de la BCFN es poco frecuente ya que se da bajo ciertas condiciones que raramente se presentan. • Se debe comprobar si una tabla viola la BCFN si tiene dos o más claves candidatas compuestas que tienen al menos un atributo en común. NOTAS (DNIAlumno, DNIProfesor,NombreProfesor, Nota) DNIProfesor → NombreProfesor NombreProfesor → DNIProfesor DNIProfesor,DNIAlumno → Nota En este caso, la tabla está en 3FN porque no hay dependencias funcionales transitivas, y sin embargo no está en FNBC porque NombreProfesor y DNI Profesor son implicantes, y no son claves candidatas. Para obtener la tabla en FNBC habría que quitar de la tabla los atributos DNIProfesor y NombreProfesor.
  16. 16. FORMAS NORMALES •Primera forma normal •Segunda forma normal •Tercera forma normal •Forma normal de Boyce/Codd •Otras formas normales Otras formas normales • Existen más formas normales (FN4, FN5, FNDK, FN6...) • Las formas normales 4 y 5, se ocupan de las dependencias entre atributos multivaluados, la Forma Normal Dominio Clave (FNDK) trata las restricciones y los dominios de los atributos, y finalmente la FN6 trata ciertas consideraciones con las bases de datos temporales.
  17. 17. Referentes • López, I, Castellano, M. y Ospino, J. (2013). Bases de datos. Desarrollo de aplicaciones multiplataforma y web DAM y DAW. Elfaomega, México. • Marqués, M. (2009). Bases de datos. [Material online]. Departamento de Ingeniería y Ciencia de la Computación, UNIVERSITAT JAUME I DE CASTELLÓ. España. • Zea, M., Honores, J. y Rivas, W. (2015). Fundamentos de base de datos. Ediciones utmach, Ecuador.

×