• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Normalizacion_Rozic
 

Normalizacion_Rozic

on

  • 957 views

 

Statistics

Views

Total Views
957
Views on SlideShare
903
Embed Views
54

Actions

Likes
0
Downloads
45
Comments
0

5 Embeds 54

http://formaciononlinesena.blogspot.com 37
http://ee-bd.blogspot.com 12
http://www.ee-bd.blogspot.com 2
http://formaciononlinesena.blogspot.com.ar 2
http://formaciononlinesena.blogspot.mx 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Normalizacion_Rozic Normalizacion_Rozic Presentation Transcript

    •  
    •  
    • TÉRMINO DE NORMALIZACIÓN
      • La normalización es un término que deriva de la metodología que se utiliza para evitar la redundancia de datos y el fácil acceso y actualización de estos. Dicha metodología fue enunciada por Codd.
      • Esta consistía en definir un conjunto de normas a las que las llamó formas normales. Cada forma normal fue numerada (esto en realidad es una verdad a medias, ya que existe una forma normal que no posee número y se llama forma normal de Boyce - Codd) desde la 1° hasta la 5°, llamándose 1 ° forma normal, 2° forma normal, y así hasta la 5° forma normal.
      • Lo importante de esta metodología es que para que una relación esté en 2° FN (a partir de este momento abreviaremos forma normal como FN) debe anteriormente estar en 1 ° FN, para estar en 3° FN debe estar antes en 2° FN y por transitividad y lo que dijimos antes, debe también estar en 1 ° FN.
      • Así, lo que se garantiza es que para que una relación esté en una determinada forma normal antes debe estar en todas las formas normales que la preceden.
      • La l 0 FN solicita que se cumplan dos condiciones sobre la relación (entidad o tabla):
      • Debe existir una clave primaria .
      • Todos los dominios simples contienen únicamente valores atómicos.
      • Sobre la existencia de clave primaria a esta altura no hace falta realizar ninguna explicación. Y sobre la 2° condición que dice que "todos los dominios simples contienen únicamente valores atómicos" en criollo o castellano coloquial quiere decir "los atributos de la relación no pueden contener grupos repetitivos o multivalorados".
    • Aclaremos un poco: si miramos nuestra relación veremos que para una venta realizada en una determinada fecha con un número de factura para un mismo cliente, por cada producto que compre el cliente, sucederá algo como lo que se ve en la Tabla 1. NroFactura Codigo-Producto Descripcion-Pdcto Precio-Unitario-Pdcto Canlidad_Vendida_Pdcto Codigo_Cliente Nombre_Cliente Fecha_de_Venta 3 2 Martillo 20.4 15 878 JuanPérez 02/03/04 3 5 Clavo 0.8 3110 878 JuanPérez 02103/04 3 9 Clavo 120 2 878 JuanPerez 02/03/04 3 15 Destornillador 7.5 8 878 JuanPérez 02/03/04
      • Si usted presta atención observará que los atributos NroFactura, Codigo_Cliente, Nom­bre_Cliente, Fecha_de_ Venta se repiten cn la tabla por cada aparición diferente de CòdigoProducto, Cantidad_ Vendida_Prod., Precio_Unitario_Prod. y Descripción_Prod. En realidad estos últimos atributos (los referentes al producto) no están cumpliendo con la segunda condición definida para que una relación se encuentre en lo FN y por ello los atributos correspondientes a la venta y al cliente se repiten en cada tupla, esto es lo que llamamos redundancia de datos.
    • CÓMO LOGRAR QUE UNA RELACIÓN QUEDE EN 1° FN
      • Eliminar de la relación original el o los atributos que no posean únicamente valores atómicos (o sea los que son grupos repetitivos).
      • Seleccionar la clave primaria de la relación original.
      • Crear una nueva relación que posea los atributos que son grupos repetitivos y fueron eliminados de la relación original.
      • El atributo que es clave primaria en la relación original será parte o formará parte de la clave primaria de la nueva relación.
      • Dar un nombre a la nueva relación y definir su clave primaria.
    • EJEMPLO
      • Eliminaremos de nuestra relación venta los siguientes atributos: Codigo_PIOduc­to, Cantidad_ Vendida_PIod, Precio_Unitario_Prod Y Descripción_Prod.
      • Seleccionaremos como clave primaria de la relación venta el atributo NroFactura.
      • Definiremos una nueva relación con los siguientes atributos: Codigo_PIOducto, Cantidad_Vendida_Prod, recio_Unitario_prod Y Descripción_PIod
      • Agregaremos a la nueva entidad el atributo NroFactura que formará parte de la clave primaria de la nueva entidad.
      • Definiremos la relación con el nombre DETALLE_VENTA y tomaremos como cla­ve primaria de la relación a los atributos NroFactura y Código_Producto.
      • Como consecuencia de lo anterior nos queda un modelo relacional como el que se muestra a continuación en la Figura 2.
      Figura 2. Las dos entidades ya en 1° EN con sus atributos claves subrayados. Venta CP NroFactura Codigo_Cliente Nombre_Cliente Fecha_de_Venta detalle_venta CP CP NroFactura Codigo_Producto Descripcion_pdcto Precio_Unitario_pdcto Cantidad_Vendida_Pdcto
    • VENTA DETALLE VENTA Tabla 2. Dos entidades ya en 1° FN con sus respectivos valores derivados de las tuplas originales. NroFactura Codigo_Cliente Nombre_Cliente Fecha_de_Venta 3 878 Juan Pérez 02/03/04 NroFactura Codigo_Producto Descripcion_Pdcto Precio_Unitario_Pdcto Cantidad_Vendida_Pdcto. 3 2 Martillo 20,4 15 3 5 Clavo 0,8 300 3 9 Taladro 120 2 3 15 Destornillador 17.5 8
      • Para que una relación se encuentre en 2° FN debe satisfacer las siguientes condiciones:
      • Debe estar en lº FN.
      • Todos los atributos no clave dependen funcionalmente de la clave primaria.
      • En nuestro ejemplo en cuestión la relación VENTA que estaba en·1° FN también se encuentra en 2° FN, pero la relación DETALLE_VENTA que se encuentra en 1 ° FN no se encuentra en 2 0 FN. Observe que el atributo Descripción_Prod depende funcionalmente del atributo Codigo_Producto que forma parte de la clave primaria de dicha relación, pero no depende funcionalmente del atributo NroFactura que también es uno de los atributos que forman parte de la clave primaria de la relación.
      • En cambio los atributos Cantidad_ Vendida_Prod y Precio_Unitario_Prod dependen funcionalmente de ambos atributos, que forman la clave primaria. Veremos ahora cómo lugramos que nuestra relación DETALLE_VENTA quede en 2° FN.
    • COMO LOGRAR QUE UNA RELACIÓN QUEDE EN 2º FN
      • Eliminar de la relación original el o los atributos que no dependan funcionalmente por completo de la clave primaria.
      • Crear una nueva relación que posea como atributos el o los atributos eliminados de la relación original.
      • Agregar a dicha relación el atributo de la clave primaria de la relación original del cual dependían funcionalmente los atributos no claves de la relación original.
      • El atributo del punto anterior será tomado como clave primaria de la nueva relación.
      • Darle un nombre a la nueva relación.
    • EJEMPLO
      • Sacaremos de la relación DETALLE_VENTA el atributo Descripción_Prod.
      • Crearemos una nueva relación que contenga el atributo Descripción_Prod.
      • Agregaremos a dicha relación el atributo Código_Producto.
      • Definiremos el atributo Código_Producto como clave primaria de dicha relación.
      • Llamaremos a dicha relación PRODUCTOS.
    • Con lo cual nos queda un modelo relacional como el que muestra la Figura 3 en 2° FN.   Figura 3. Nuestro modelo relacional con las tres relaciones en 2° FN. Venta CP NroFactura Codigo_Cliente Nombre_Cliente Fecha_de_Venta detalle_venta CP CP NroFactura Codigo_Producto Precio_Unitario_pdcto Cantidad_Vendida_Pdcto Producto CP Codigo_Producto Descripción_Pcdto
    • VENTA DETALLE_VENTA PRODUCTO Tabla 3. Las tres entidades ya en 2° FN con sus respectivos valores derivados de las tuplas originales. NroFactura Codigo_Cliente Nombre_Cliente Fecha_de_Venta 3 878 Juan Pérez 02/03/04 NroFactura Codigo_Producto Precio_Unitario_pdcto Cantidad_Vendida_Pdcto 3 2 20,4 15 3 5 0,8 300 3 9 120 2 3 15 7,5 8 Codigo_Producto Descripción_Pdcto 2 Martillo 5 Clavo 9 Taladro 15 Destornillador
      • Para que una relación se encuentre en 3° FN debe cumplir las siguiemes condiciones:
      • Debe estar en 2 0 FN .
      • Si todos los atributos no claves dependen de manera no transitiva de la clave primaria.
      • En nuestro ejemplo, las relaciones DETALLE_VENTA y PRODUCTOS satisfacen ambas condiciones, pero no sucede lo mismo con nuestra relación VENTA, ya que los atributos Nombre_Cliente y Domicilio_Cliente dependen funcionalmenre del atributo Codigo_Cliente que no es un atributo clave y no dependen funcionalmente del atributo NroFactura que es la clave primaria. Así que veremos cómo nuestra relación VENTA puede quedar en 3 0 FN.
    • COMO LOGRAR QUE UNA RELACIÓN QUEDE EN 3º FN
      • Eliminar de la relación original los atributos no claves que dependen de manera no transitiva de la clave primaria.
      Venta CP NroFactura Codigo_Cliente Nombre_Cliente Fecha_de_Venta detalle_venta CP CP NroFactura Codigo_Producto Precio_Unitario_pdcto Cantidad_Vendida_Pdcto Producto CP Codigo_Producto Descripción_Pcdto Cliente CP Codigo_Cliente Nombre_Cliente
      • Crear una nueva relación que contenga como atributos el o los atributos eliminados de la relación original.
      • Copiar el atributo no clave de la relación original del cual dependian transitivamente los atributos no claves eliminados de dicha relación.
      • Definir el atributo del punto anterior como clave primaria de la nueva relación.
      • Darle un nombre a la nueva relación.
    • EJEMPLO
      • Eliminaremos de la relación VENTA los atributos denominados Nombre_Cliente y Domicilio_Cliente.
      • Crearemos a continuación una relación nueva con los atributos Nombre_Cliente y Domicilio_Cliente.
      • Copiaremos el atributo Codigo_Cliente a esta nueva relación.
      • Definiremos al atributo Codigo_Cliente como clave primaria de esta relación.
      • Daremos el nombre CLIENTES a la nueva relación.
      • Con lo cual nos queda un modelo relacional como el que muestra la Tabla 4 en 3° FN.
    • VENTA DETALLE_VENTA PRODUCTO CLIENTE Tabla 4. Nuestro modelo relacional con cuatro tablas. todas ellas en 3' FN. NroFactura Codigo_Cliente Nombre_Cliente Fecha_de_Venta 3 878 Juan Pérez 02/03/04 NroFactura Codigo_Producto Precio_Unitario_pdcto Cantidad_Vendida_Pdcto 3 2 20,4 15 3 5 0,8 300 3 9 120 2 3 15 7,5 8 Codigo_Producto Descripción_Pdcto 2 Martillo 5 Clavo 9 Taladro 15 Destornillador Codigo_Cliente Nombre_CLiente 878 Juan Pérez
    • FORMA NORMAL DE BOYCE CODD
      • Muchas veces la 3º FN no satisface totalmente los criterios de normalización en los casos que nuestra relación posee más de una clave candidata.
      • En nuestro ejemplo eso no sucedía con ninguna de nuestras relaciones, o esas claves candidatas son claves compuestas y además existe la posibilidad que entre esas claves candidatas compartan algún atributo en común .
      • Para solucionar esta falencia que presentaba la 3° FN se definió con posterioridad la Forma Normal de Boyce/Codd.
      • Dicha forma normal se enuncia de la siguiente manera:
      • Una relación se encuentra en la forma normal de Boyce Codd sí y solo sí un determinante es una clave candidata. Pero no profundizaremos más en este tema pues él está fuera de los alcances de este libro.
      • La 4º FN se aplica para dependencias multivaluadas. Una relación se encuentra en 4º FN si cumple las siguientes condiciones:
      • Se encuentra en la forma normal de Boyce Codd. y
      • Todas las dependencias multivaluadas de dicha relación son por defecto dependencias funcionales.
      • Una relación se encuentra en 5° FN si se satisface que toda dependencia de reunión es consecuencia de las claves candidatas de la relación.
      • Una relación satisface la dependencia de reunión sí y solo sí dicha relación es igual a la reunión de sus proyecciones, donde cada proyección es un subconjunto del conjunto de arributos de la relación. Muchas veces cuando se descompone la relación en dos proyecciones de esta sucede el efecto no deseado de pérdida de formacion pero se puede evitar si dicha relación se descompone en más de dos proyecciones. Al suceder esto lo que garantiza la 5° FN es que con la reunión de una determinada manera de dichas proyecciones se puede reconstruir la relación y evitar la pérdida de información de ella.
    • INTEGRIDAD DEL MODELO DE DATOS
      • En este momento es bueno hacer algunos comentarios o complementar ciertos conceptos ya explicados en capítulos anteriores antes de seguir adelante.
      • Por ejemplo, en todas nuestras diferentes definiciones de clave primaria que dimos a los largo del libro aplicando los diferentes conceptos aprendidos, siempre hablamos que eran atributos únicos o que el resto de los atributos no clave dependían funcionalmente de ella, pero hay algo que no mencionamos: que las claves primarias no pueden contener el valor nulo o null como valor válido. Ya que una clave primaria no puede ser indefinida. Con lo cual la primera condición de integridad que debe cumplir un modelo relacional es que la clave primaria no puede contener valores nulos.
      • Está claro por qué no puede aceptar valores nulos una clave primaria, pero por si queda algún tipo de duda se lo paso a explicar. Una clave primaria, como dijimos antes es el atributo o conjunto de atributos que nos permite identificar unívocamente a cada tupla de la relación y como contrapartida, el valor nulo en un atributo indica la indefinición o desconocimiento de su valor, por ende poco podría servir como clave primaria un atributo o conjunto de arributos con valor desconocido.
      • Esto además está relacionado con el concepto de que el modelo relacional, como ya dijimos anteriormente es una simulación o representación del mundo real, por ende es muy poco probable que en el mundo real existan elementos indefinidos o no identificables sin ambiguedad.
      • Ahora existe otro concepto subyacente al de clave primaria, del cual no hemos hablado todavía y es el de clave foránea o clave externa o clave ajena (en realidad son todas formas diferentes de llamar lo mismo) el cual implica lo siguiente: una clave externa es un atributo o conjuntos de atributos de una relación P cuyos valores deben coincidir con el valor o los valores de los arributos que componen la clave primaria de alguna relación K.
      • Una aclaración que cae de maduro y por deducción a esta altura de nuestros conocimientos, es que los valores de la clave foránea y los valores de la clave primaria asociada con esa clave foránea pertenecen al mismo dominio. Es más, si ambas claves son compuestas, el dominio de cada atributo que compone ambas claves es el mismo. Para entender el concepto de clave foránea daremos un ejemplo que aclarará la situación.
      • Retornemos el modelo relacional de la Figura 4. Si nos fijamos en él con atención, el atributo Codigo_Cliente de la relación VENTA es una clave foránea de la clave primaria Codigo_Cliente de la relación CLIENTE.
      • Ahora expondremos la 2° condición de integridad del modelo relacional que es la condición de integridad referencial.
      • La condición de integridad referencial lo que pide es que no existan en el modelo relacional valores para las claves foráneas sin coincidencia con los valores de las cla ves primarias asociadas a ella.
      • Veamos con un ejemplo qué es lo que nos está pidiendo la 2° condición.
      • Volvamos a nuestro ejemplo de la Figura 3 con nuestras relaciones VENTA y CLIENTE. El modelo no podría tener registrada una venta para un cliente inexistente, ya que eso no cumpliría la condición de integridad referencial y fíjese que lógico que es esto. En la vida real solo es válido realizar una venta a un cliente existente y no tendría sentido generar una venta a un cliente inexistente a no ser que se deseara realizar una estafa o maniobra fraudulenta y no es la idea permitir que esto suceda.
    • Figura 4. Modelo relacional normalizado y con la integridad referencial definida. Venta CP NroFactura Codigo_Cliente Nombre_Cliente Fecha_de_Venta detalle_venta CP CP NroFactura Codigo_Producto Precio_Unitario_pdcto Cantidad_Vendida_Pdcto Producto CP Codigo_Producto Descripción_Pcdto Cliente CP Codigo_Cliente Nombre_Cliente
      • Veremos ahora el diagrama de nuestro modelo de ventas con las restricciones de integridad referencial aplicadas. La suma de la flecha indica una cardinalidad de 1 y la línea continua donde termina la flecha indica muchos (quiero aclarar que esta es una de las tantas formas de indicar la cardinalidad, aunque no es la única, igualmente lo único que cambia es su representación gráfica, pero el concepto es el mismo).
      • Quiere decir que esto se leería o diría de la siguiente manera visto de la relación CLIENTE "Un cliente tiene muchas ventas" o dicho de otra manera visto desde la relación VENTA "Muchas ventas son de un clienre".
      • Lo mismo se podría hacer con VENTA y DETALLE_VENTA, parados en VENTA diríamos "Una venta posee muchos detalles de venta" y parados en DETALLE_VENTA diríamos "Muchos detalles de venta pertenecen a una venta" y lo mismo entre PRODUCTO Y DETALLE_VENTA; parados en PRODUCTO diríamos "Un producto puede existir en muchos detalles de venta" y parados en DETALLE_VENTA diríamos "Muchos detalles de venta contienen un producto."