NORMALIZACION II
La cuarta forma normal (4NF) es una forma normal usada en la normalización de bases de datos. La 4NF se asegura de que las dependencias multivaluadas independientes estén correcta y eficientemente representadas en un diseño de base de datos. La 4NF es el siguiente nivel de normalización después de la forma normal de Boyce-Codd (BCNF).
Una tabla está en 4NF si y solo si esta en Tercera forma normal o en BCNF (Cualquiera de ambas) y no posee dependencias multivaluadas no triviales. La definición de la 4NF confía en la noción de una dependencia multivaluada. Una tabla con una dependencia multivaluada es una donde la existencia de dos o más relaciones independientes muchos a muchos causa redundancia; y es esta redundancia la que es suprimida por la cuarta forma norma
La quinta forma normal (5FN), también conocida como forma normal de proyección-unión (PJ/NF), es un nivel de normalización de bases de datos designado para reducir redundancia en las bases de datos relacionales que guardan hechos multi-valores aislando semánticamente relaciones múltiples relacionadas. Una tabla se dice que está en 5NF si y sólo si está en 4NF y cada dependencia de unión (join) en ella es implicada por las claves candidatas.
El psiquiatra puede ofrecer tratamiento reembolsable a los pacientes que sufren de la condición dada y que son asegurados por el asegurador dado. En ausencia de cualquier regla que restrinja las combinaciones válidas posibles de psiquiatra, asegurador, y condición, la tabla de tres atributos Psiquiatra-para-Asegurador-para-Condición es necesaria para modelar la situación correctamente.
Sin embargo, suponga que la regla siguiente se aplica:
Cuando un psiquiatra es autorizado a ofrecer el tratamiento reembolsable a los pacientes asegurados por el asegurador P, y el psiquiatra puede tratar la condición C, entonces - en caso que el asegurador P cubra la condición C - debe ser cierto que el psiquiatra puede ofrecer el tratamiento reembolsable a los pacientes que sufren de la condición C y están asegurados por el asegurador P.
Con estas restricciones es posible dividir la relación en tres partes.
Note como esta disposición ayuda a quitar redundancia. Suponga que el Dr. James se convierte en un proveedor de tratamientos para FriendlyCare. En la disposición anterior tendríamos que agregar dos nuevas entradas puesto que el Dr. James puede tratar dos condiciones cubiertas por FriendlyCare: ansiedad y depresión. Con la nueva disposición necesitamos agregar una sola entrada (en la tabla Psiquiatra-para-Asegurador).
. Aplicación del alumno
1 INTRODUCCIÓN
En esta actividad, los alumnos/as aprenderán a utilizar una base de datos
(Microsoft Access) para estudiar las características de los árboles más
frecuentes en parques y jardines.
Los estudiantes deberán rellenar unas fichas de campo sobre los árboles que
estudien en una salida de campo. Después consultarán diversas guías de
árboles y páginas web para verificar las observaciones y completar los datos.
Utilizarán como herramienta principal una base de datos para introducir las
características recogidas y un procesador de textos para diseñar las fichas de
observación de árboles. Opcionalmente se ofrece la posibilidad de realizar una
serie de diapositivas con un programa de presentaciones.
La posibilidad de consultar una base de datos, analizar y seleccionar la
información y tratar en grupo estos trabajos, representa una alternativa al
simple conocimiento memorístico, pues favorece la capacidad de organización
del saber y propicia un cambio curricular a nivel organizativo y metodológico.
La formación debe encaminarse al desarrollo de las capacidades, y entre estas
capacidades, a adquirir destrezas para el acceso y utilización de la información.
2 OBJETIVOS
· Identificar los árboles más frecuentes en parques y jardines.
· Crear e interrogar a una base de datos para encontrar relaciones y
Aspectos comunes.
· Comprender que los ordenadores son útiles en tareas que requieren
Grandes cantidades de información.
martes, 8 de noviembre de 2011
viernes, 4 de noviembre de 2011
SEMANA 13 - NORMALIZACIÓN I
NORMALIZACIÓN I
Qué es la normalización
Normalización es un conjunto de reglas que sirven para ayudar a los diseñadores a desarrollar un esquema que minimice los problemas de lógica. Cada regla está basada en la que le antecede. 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 trataba de manipular los datos. Por ejemplo, vea la base de datos MiTienda. Si almacena todos los datos en la tabla Clientes, ésta podría verse como se muestra a continuación:
Clientes
ID_Cliente Nombre
Apellidos
Nombre_Producto1 Costo_Producto1
Imagen_Producto1 Nombre_Producto2 Costo_Producto2
Imagen_Producto2 Fecha_Pedido
Cantidad_Pedido
Nombre_Cia_Envios
La tabla se ha descrito de manera abreviada pero aun así representa la idea general.
¿Cómo podría añadir un nuevo cliente en su tabla Clientes? Debería añadir un producto y un pedido también. ¿Qué tal si quisiera emitir un informe de todos los productos que vende? No podría separar fácilmente los productos de los clientes con una simple instrucción SQL. Lo bello de las bases de datos relacionales, si están bien diseñadas, es que puede hacer esto fácilmente.
La nomlalización también hace las cosas fáciles de entender. Los seres humanos tenemos la tendencia de simplificar las cosas al máximo. Lo hacemos con casi todo desde los animales hasta con los automóviles. Vemos una imagen de gran tamaño y la hacemos menos compleja agrupando cosas similares juntas. Las guías que la nomlalización provee crean el marco de referencia para simplificar la estructura. En su base de datos de muestra es fácil detectar que usted tiene tres diferentes grupos: clientes, productos y pedidos. Si sigue las guías de la nomlalización, podría crear las tablas basándose en estos grupos.
El proceso de nomlalización tiene un nombre y una serie de reglas para cada fase. Esto puede parecer un poco confuso al principio, pero poco a poco irá entendiendo el proceso, así como las razones para hacerlo de esta manera. A la mayoría de la gente le encantan las hojas de cálculo por la forma en la que manejan sus datos. El tiempo que le lleve reconfigurar su esquema para ajustarlo al proceso de nomlalización, siempre será bien Iinvertido. Al fin y al cabo, esto le tomará menos tiempo que el que tendría que invertir , para cortar y pegar sus columnas de datos para generar el infomle que quiere su jefe.
Otra ventaja de la nomlalización de su base de datos es el consumo de espacio. Una base de datos nomlalizada puede ocupar menos espacio en disco que una no nomlalizada. Hay menos repetición de datos, lo que tiene como consecuencia un mucho menor uso de espacio en disco.
Grados de normalización
Existen básicamente tres niveles de normalización: Primera Fomla Normal (1NF), Segunda Fomla Normal (2NF) y Tercera Fomla Normal (3NF). Cada una de estas formas tiene sus propias reglas. Cuando una base de datos se conforma a un nivel, se considera nomlalizada a esa forma de nomlalización. Por ejemplo, supongamos que su
base de datos cumple con todas las reglas del segundo nivel de nomlalización. Se considera que está en la Segunda Fomla Normal. No siempre es una buena idea tener una base de datos conformada en el nivel más alto de normalización. Puede llevar aun nivel de complejidad que pudiera ser evitado si estuviera en un nivel más bajo de normalización.
Primera Forma Normal
La regla de la Primera Forma Normal establece que las columnas repetidas deben eliminarse y colocarse en tablas separadas. Ésta es una regla muy fácil de seguir. Observe el esquema de la tabla Clientes de la base de datos.
.
Clientes
ID Cliente
Nombre
Apellidos
Nombre_Producto1
Costo_Producto1
Imagen_Producto1
Nombre_Producto2
Costo_Producto2
Imagen_Producto2
Fecha_Pedido
Cantidad_Pedido
Nombre Cia Envios
--
La tabla tiene varias columnas repetidas. Éstas se refieren principalmente a los productos. De acuerdo con la regla, debe eliminar las columnas repetidas y crearles su propia tabla.
Eliminación de datos repetidos en una base de datos
Clientes Pedidos
ID_Clientes Nombre_Productos
Nombre Costo_Producto
Apellidos Imagen_Producto
Direccion
Numero_Pedido
Fecha_Pedido
Cantidad_Pedido
Clave_Cia_Envios
Nombre_Ci_ Envios
--
Ahora tiene dos tablas. Pero todavía hay un problema. No hay forma de relacionar los datos de la tabla original con los de la nueva tabla. Para hacerlo, debe añadir un campo clave a la segunda tabla de forma que se establezca la relación. Añada a la tabla Productos una clave primaria que se llame ID_Producto y añada una clave a la tabla Clientes que la relacione con la tabla Productos. El campo ID_Producto es el candidato ideal.
Primera Forma Normal
Clientes Pedidos
ID_Productos ID_Productos
ID_Clientes Nombre_Productos
Nombre Costo_Producto
Apellidos Imagen_Producto
Direccion
Numero_Pedido
Fecha_Pedido
Cantidad_Pedido
Clave_Cia_Envios
--
Así, se ha establecido una relación uno a varios. Ésta representa lo que la base de datos estará haciendo en la vida real. El cliente tendrá muchos productos que podrá comprar,
sin importar cuántos otros clientes quieran comprarlos también. Además, el cliente necesitará haber pedido un producto para ser un cliente. Usted ya no está obligado a añadir
un cliente cada vez que añade un nuevo producto a su inventario.
Poner la base de datos en la Primera Forma Normal resuelve el problema de los encabezados de columna múltiples. Muy a menudo, los diseñadores de bases de datos inexpertos harán algo similar a la tabla no normalizada. Una y otra vez, crearán columnas que representen los mismos datos. En una empresa de servicios de electricidad, había una base de datos para el control de refacciones de una planta nuclear. La tabla de su base de datos, la cual contenía los números de parte de las refacciones, tenía una columna repetida más de treinta veces. Cada vez que una nueva parte se tenía que dar de alta, se creaba una nueva columna para almacenar la información. Obviamente, el diseño de la base de datos era bastante pobre y, por lo mismo, resultaba una pesadilla para sus programadores/administradores.
La normalización ayuda a clarificar la base de datos ya organizarla en partes más pequeñas y más fáciles de entender. En lugar de tener que entender una tabla gigantesca y monolítica que tiene muchos diferentes aspectos, usted sólo tiene que entender objetos pequeños y más tangibles, así como las relaciones que guardan con otros objetos también pequeños. No es necesario mencionar que un mejor entendimiento del funcionamiento de su base de datos conducirá aun mejor aprovechamiento de sus activos.
Segunda Forma Normal
La regla de la Segunda Forma Normal establece que todas las dependencias parciales se deben eliminar y separar dentro de sus propias tablas. Una depen dencia parcial es un término que describe a aquellos datos que no dependen de la clave de la tabla para identificarlos. En la base de datos de muestra, la información de pedidos está en cada uno de los registros. Sería mucho más simple utilizar únicamente el número del pedido. El resto de la información podría residir en su propia tabla. Una vez que haya organizado la información de pedidos.
Eliminación de las dependencias parciales -Segunda Forma Normal
Clientes Pedidos Productos
ID_Productos ID_Productos ID_Producto
ID_Clientes Nombre_Productos Fecha_Compra
Nombre Cantidad_Pedido Costos_Productos
Apellidos Imagen_Producto
Direccion
Numero_Pedido
Nombre_Cia_Envios
De nuevo, al organizar el esquema de esta forma puede reflejar el mundo real en su base de datos. Tendría que hacer algunos cambios en sus reglas del negocio para que esto fuera aplicable, pero para ilustrar la normalización, así está bien.
Una de las mayores desventajas de la normalización es el tiempo que lleva hacerlo. La mayoría de la gente está demasiado ocupada, y emplear tiempo para asegurarse de que sus datos están normalizados cuando todo funciona más o menos bien, parece ser un desperdicio de tiempo. Pero no es así. Usted tendrá que emplear más tiempo arreglando una base de datos no normalizada que el que emplearía en una normalizada.
Al haber alcanzado la Segunda Forma Normal, usted puede disfrutar de algunas de las ventajas de las bases de datos relacionales. Por ejemplo, puede añadir nuevas columnas a la tabla Clientes sin afectar a las tablas Productos y Pedidos. Lo mismo aplica para las otras tablas. Alcanzar este nivel de normalización permite que los datos se acomoden de una manera natural dentro de los límites esperados.
Una vez que ha alcanzado el nivel de la Segunda Forma Normal, se han controlado la mayoría de los problemas de lógica. Puede insertar un registro sin un exceso de datos en la mayoría de las tablas. Observando un poco más de cerca la tabla Clientes, vemos la columna Nombre_Cia_Envios. Ésta no es dependiente del cliente. El siguiente nivel de normalización explicará cómo solucionar esto.
Tercera Forma Normal
La regla de la Tercera Forma Normal señala que hay que eliminar y separar cualquier dato que no sea clave. El valor de esta columna debe depender de la clave. Todos los valores deben identificarse únicamente por la clave. En la base de datos de muestra, la tabla Clientes contiene la columna Nombre_Cia_Envios, la cual no se identifica únicamente por la clave. Podría separar estos datos de la tabla y ponerlos en una tabla aparte.
Eliminación de los datos que no son claves para la Tercera Forma Normal
Clientes Productos PedidoMaestro PedidoDetallado Cias_Envios
ID_cliente ID_Producto ID_Pedido ID_PedidoDetallado ID_Cia_Envios
ID_Producto Nombre_Producto Fecha_Pedido ID_Pedido Nombre_Cia_Envios.
Numero_Pedido Costos_Productos Cantidad_Pedidos Fecha_Pedido
ID_Cia_Envios Foto_Producto Cantidad_Pedido
Nombre
Apellidos
Direccion
Ahora todas sus tablas están en la Tercera Forma Normal. Esto le da más flexibilidad y previene errores de lógica cuando inserta o borra registros. Cada columna en la tabla está identificada de manera única por la clave, y no hay datos repetidos. Esto provee un esquema limpio y elegante, que es fácil de trabajar y expandir.
Qué tan lejos debe llevar la normalización
La siguiente decisión es ¿qué tan lejos debe llevar la normalización? La normalización es una ciencia subjetiva. Determinar las necesidades de simplificación depende de usted. Si su base de datos va a proveer información aun solo usuario para un propósito simple y existen pocas posibilidades de expansión, normalizar sus datos hasta la 3FN sea quizá algo extremoso. Las reglas de normalización existen como guías para crear tablas que sean fáciles de manejar, así como flexibles y eficientes.
A veces puede ocurrir que normalizar sus datos hasta el nivel más alto no tenga sentido. Por ejemplo, suponga que añade una columna extra para la dirección en su base de datos. Es muy normal tener dos líneas para la dirección. El esquema de la tabla podría verse como se muestra a continuación:
ID_Cliente
Nombre
Apellidos
Direccion1
Direccion2
De acuerdo con las reglas, si aplica la Primera Forma Normal, la columna de dirección debería sacarse de esta tabla y reemplazarse con la clave de una nueva tabla. El resultado de este esquema se muestra a continuación:
ID_Ciente ID_Direccion
Nombre ID_Cliente
Apellidos Direccion
La base de datos ahora cumple con la Primera Forma Normal. Los clientes pueden tener más de una dirección. El problema aquí es que usted ha complicado demasiado una idea simple, por tratar de seguir las reglas de normalización. En el ejemplo mostrado, la segunda dirección es totalmente opcional. Está ahí sólo para colectar información que pudiera utilizarse como información de contacto. No hay necesidad de partir la tabla en dos y forzar las reglas de la normalización. En esta instancia, el exceso de normalización frustra el propósito para el que se utilizan los datos. Añade, de manera innecesaria, un nivel más de complejidad. Una buena forma de determinar si está llevando demasiado lejos su normalización, es ver el número de tablas que tiene. Un número grande de tablas pudiera indicar que está normalizando demasiado. Observe su esquema.
¿Está dividiendo tablas sólo para seguir las reglas o estas divisiones son en verdad prácticas? Éstas son el tipo de cosas que usted, el diseñador de la base de datos, necesita decidir. La experiencia y el sentido común lo pueden auxiliar para tomar la decisión correcta. La normalización no es una ciencia exacta. Es subjetiva.
Existen seis niveles más de normalización que no se han discutido aquí. Ellos son Forma Normal Boyce-Codd, Cuarta Forma Normal (4NF), Quinta Forma Normal (5NF) o
Forma Normal de Proyección-Unión, Forma Normal de Proyección-Unión Fuerte, Forma Normal de Proyección-Unión Extra Fuerte y Forma Normal de Clave de Dominio. Estas formas de normalización pueden llevar las cosas más allá de lo que necesita. Éstas existen para hacer una base de datos realmente relacional. Tienen que ver principalmente con dependencias múltiples y claves relacionales.
En resumen
La normalización es una técnica que se utiliza para crear relaciones lógicas apropiadas entre tablas de una base de datos.
Ayuda a prevenir errores lógicos en la manipulación de datos. La normalización facilita también agregar nuevas columnas sin romper el esquema actual ni las relaciones.
Normalización es un conjunto de reglas que sirven para ayudar a los diseñadores a desarrollar un esquema que minimice los problemas de lógica. Cada regla está basada en la que le antecede. 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 trataba de manipular los datos. Por ejemplo, vea la base de datos MiTienda. Si almacena todos los datos en la tabla Clientes, ésta podría verse como se muestra a continuación:
Clientes
ID_Cliente Nombre
Apellidos
Nombre_Producto1 Costo_Producto1
Imagen_Producto1 Nombre_Producto2 Costo_Producto2
Imagen_Producto2 Fecha_Pedido
Cantidad_Pedido
Nombre_Cia_Envios
La tabla se ha descrito de manera abreviada pero aun así representa la idea general.
¿Cómo podría añadir un nuevo cliente en su tabla Clientes? Debería añadir un producto y un pedido también. ¿Qué tal si quisiera emitir un informe de todos los productos que vende? No podría separar fácilmente los productos de los clientes con una simple instrucción SQL. Lo bello de las bases de datos relacionales, si están bien diseñadas, es que puede hacer esto fácilmente.
La nomlalización también hace las cosas fáciles de entender. Los seres humanos tenemos la tendencia de simplificar las cosas al máximo. Lo hacemos con casi todo desde los animales hasta con los automóviles. Vemos una imagen de gran tamaño y la hacemos menos compleja agrupando cosas similares juntas. Las guías que la nomlalización provee crean el marco de referencia para simplificar la estructura. En su base de datos de muestra es fácil detectar que usted tiene tres diferentes grupos: clientes, productos y pedidos. Si sigue las guías de la nomlalización, podría crear las tablas basándose en estos grupos.
El proceso de nomlalización tiene un nombre y una serie de reglas para cada fase. Esto puede parecer un poco confuso al principio, pero poco a poco irá entendiendo el proceso, así como las razones para hacerlo de esta manera. A la mayoría de la gente le encantan las hojas de cálculo por la forma en la que manejan sus datos. El tiempo que le lleve reconfigurar su esquema para ajustarlo al proceso de nomlalización, siempre será bien Iinvertido. Al fin y al cabo, esto le tomará menos tiempo que el que tendría que invertir , para cortar y pegar sus columnas de datos para generar el infomle que quiere su jefe.
Otra ventaja de la nomlalización de su base de datos es el consumo de espacio. Una base de datos nomlalizada puede ocupar menos espacio en disco que una no nomlalizada. Hay menos repetición de datos, lo que tiene como consecuencia un mucho menor uso de espacio en disco.
Grados de normalización
Existen básicamente tres niveles de normalización: Primera Fomla Normal (1NF), Segunda Fomla Normal (2NF) y Tercera Fomla Normal (3NF). Cada una de estas formas tiene sus propias reglas. Cuando una base de datos se conforma a un nivel, se considera nomlalizada a esa forma de nomlalización. Por ejemplo, supongamos que su
base de datos cumple con todas las reglas del segundo nivel de nomlalización. Se considera que está en la Segunda Fomla Normal. No siempre es una buena idea tener una base de datos conformada en el nivel más alto de normalización. Puede llevar aun nivel de complejidad que pudiera ser evitado si estuviera en un nivel más bajo de normalización.
Primera Forma Normal
La regla de la Primera Forma Normal establece que las columnas repetidas deben eliminarse y colocarse en tablas separadas. Ésta es una regla muy fácil de seguir. Observe el esquema de la tabla Clientes de la base de datos.
.
Clientes
ID Cliente
Nombre
Apellidos
Nombre_Producto1
Costo_Producto1
Imagen_Producto1
Nombre_Producto2
Costo_Producto2
Imagen_Producto2
Fecha_Pedido
Cantidad_Pedido
Nombre Cia Envios
--
La tabla tiene varias columnas repetidas. Éstas se refieren principalmente a los productos. De acuerdo con la regla, debe eliminar las columnas repetidas y crearles su propia tabla.
Eliminación de datos repetidos en una base de datos
Clientes Pedidos
ID_Clientes Nombre_Productos
Nombre Costo_Producto
Apellidos Imagen_Producto
Direccion
Numero_Pedido
Fecha_Pedido
Cantidad_Pedido
Clave_Cia_Envios
Nombre_Ci_ Envios
--
Ahora tiene dos tablas. Pero todavía hay un problema. No hay forma de relacionar los datos de la tabla original con los de la nueva tabla. Para hacerlo, debe añadir un campo clave a la segunda tabla de forma que se establezca la relación. Añada a la tabla Productos una clave primaria que se llame ID_Producto y añada una clave a la tabla Clientes que la relacione con la tabla Productos. El campo ID_Producto es el candidato ideal.
Primera Forma Normal
Clientes Pedidos
ID_Productos ID_Productos
ID_Clientes Nombre_Productos
Nombre Costo_Producto
Apellidos Imagen_Producto
Direccion
Numero_Pedido
Fecha_Pedido
Cantidad_Pedido
Clave_Cia_Envios
--
Así, se ha establecido una relación uno a varios. Ésta representa lo que la base de datos estará haciendo en la vida real. El cliente tendrá muchos productos que podrá comprar,
sin importar cuántos otros clientes quieran comprarlos también. Además, el cliente necesitará haber pedido un producto para ser un cliente. Usted ya no está obligado a añadir
un cliente cada vez que añade un nuevo producto a su inventario.
Poner la base de datos en la Primera Forma Normal resuelve el problema de los encabezados de columna múltiples. Muy a menudo, los diseñadores de bases de datos inexpertos harán algo similar a la tabla no normalizada. Una y otra vez, crearán columnas que representen los mismos datos. En una empresa de servicios de electricidad, había una base de datos para el control de refacciones de una planta nuclear. La tabla de su base de datos, la cual contenía los números de parte de las refacciones, tenía una columna repetida más de treinta veces. Cada vez que una nueva parte se tenía que dar de alta, se creaba una nueva columna para almacenar la información. Obviamente, el diseño de la base de datos era bastante pobre y, por lo mismo, resultaba una pesadilla para sus programadores/administradores.
La normalización ayuda a clarificar la base de datos ya organizarla en partes más pequeñas y más fáciles de entender. En lugar de tener que entender una tabla gigantesca y monolítica que tiene muchos diferentes aspectos, usted sólo tiene que entender objetos pequeños y más tangibles, así como las relaciones que guardan con otros objetos también pequeños. No es necesario mencionar que un mejor entendimiento del funcionamiento de su base de datos conducirá aun mejor aprovechamiento de sus activos.
Segunda Forma Normal
La regla de la Segunda Forma Normal establece que todas las dependencias parciales se deben eliminar y separar dentro de sus propias tablas. Una depen dencia parcial es un término que describe a aquellos datos que no dependen de la clave de la tabla para identificarlos. En la base de datos de muestra, la información de pedidos está en cada uno de los registros. Sería mucho más simple utilizar únicamente el número del pedido. El resto de la información podría residir en su propia tabla. Una vez que haya organizado la información de pedidos.
Eliminación de las dependencias parciales -Segunda Forma Normal
Clientes Pedidos Productos
ID_Productos ID_Productos ID_Producto
ID_Clientes Nombre_Productos Fecha_Compra
Nombre Cantidad_Pedido Costos_Productos
Apellidos Imagen_Producto
Direccion
Numero_Pedido
Nombre_Cia_Envios
De nuevo, al organizar el esquema de esta forma puede reflejar el mundo real en su base de datos. Tendría que hacer algunos cambios en sus reglas del negocio para que esto fuera aplicable, pero para ilustrar la normalización, así está bien.
Una de las mayores desventajas de la normalización es el tiempo que lleva hacerlo. La mayoría de la gente está demasiado ocupada, y emplear tiempo para asegurarse de que sus datos están normalizados cuando todo funciona más o menos bien, parece ser un desperdicio de tiempo. Pero no es así. Usted tendrá que emplear más tiempo arreglando una base de datos no normalizada que el que emplearía en una normalizada.
Al haber alcanzado la Segunda Forma Normal, usted puede disfrutar de algunas de las ventajas de las bases de datos relacionales. Por ejemplo, puede añadir nuevas columnas a la tabla Clientes sin afectar a las tablas Productos y Pedidos. Lo mismo aplica para las otras tablas. Alcanzar este nivel de normalización permite que los datos se acomoden de una manera natural dentro de los límites esperados.
Una vez que ha alcanzado el nivel de la Segunda Forma Normal, se han controlado la mayoría de los problemas de lógica. Puede insertar un registro sin un exceso de datos en la mayoría de las tablas. Observando un poco más de cerca la tabla Clientes, vemos la columna Nombre_Cia_Envios. Ésta no es dependiente del cliente. El siguiente nivel de normalización explicará cómo solucionar esto.
Tercera Forma Normal
La regla de la Tercera Forma Normal señala que hay que eliminar y separar cualquier dato que no sea clave. El valor de esta columna debe depender de la clave. Todos los valores deben identificarse únicamente por la clave. En la base de datos de muestra, la tabla Clientes contiene la columna Nombre_Cia_Envios, la cual no se identifica únicamente por la clave. Podría separar estos datos de la tabla y ponerlos en una tabla aparte.
Eliminación de los datos que no son claves para la Tercera Forma Normal
Clientes Productos PedidoMaestro PedidoDetallado Cias_Envios
ID_cliente ID_Producto ID_Pedido ID_PedidoDetallado ID_Cia_Envios
ID_Producto Nombre_Producto Fecha_Pedido ID_Pedido Nombre_Cia_Envios.
Numero_Pedido Costos_Productos Cantidad_Pedidos Fecha_Pedido
ID_Cia_Envios Foto_Producto Cantidad_Pedido
Nombre
Apellidos
Direccion
Ahora todas sus tablas están en la Tercera Forma Normal. Esto le da más flexibilidad y previene errores de lógica cuando inserta o borra registros. Cada columna en la tabla está identificada de manera única por la clave, y no hay datos repetidos. Esto provee un esquema limpio y elegante, que es fácil de trabajar y expandir.
Qué tan lejos debe llevar la normalización
La siguiente decisión es ¿qué tan lejos debe llevar la normalización? La normalización es una ciencia subjetiva. Determinar las necesidades de simplificación depende de usted. Si su base de datos va a proveer información aun solo usuario para un propósito simple y existen pocas posibilidades de expansión, normalizar sus datos hasta la 3FN sea quizá algo extremoso. Las reglas de normalización existen como guías para crear tablas que sean fáciles de manejar, así como flexibles y eficientes.
A veces puede ocurrir que normalizar sus datos hasta el nivel más alto no tenga sentido. Por ejemplo, suponga que añade una columna extra para la dirección en su base de datos. Es muy normal tener dos líneas para la dirección. El esquema de la tabla podría verse como se muestra a continuación:
ID_Cliente
Nombre
Apellidos
Direccion1
Direccion2
De acuerdo con las reglas, si aplica la Primera Forma Normal, la columna de dirección debería sacarse de esta tabla y reemplazarse con la clave de una nueva tabla. El resultado de este esquema se muestra a continuación:
ID_Ciente ID_Direccion
Nombre ID_Cliente
Apellidos Direccion
La base de datos ahora cumple con la Primera Forma Normal. Los clientes pueden tener más de una dirección. El problema aquí es que usted ha complicado demasiado una idea simple, por tratar de seguir las reglas de normalización. En el ejemplo mostrado, la segunda dirección es totalmente opcional. Está ahí sólo para colectar información que pudiera utilizarse como información de contacto. No hay necesidad de partir la tabla en dos y forzar las reglas de la normalización. En esta instancia, el exceso de normalización frustra el propósito para el que se utilizan los datos. Añade, de manera innecesaria, un nivel más de complejidad. Una buena forma de determinar si está llevando demasiado lejos su normalización, es ver el número de tablas que tiene. Un número grande de tablas pudiera indicar que está normalizando demasiado. Observe su esquema.
¿Está dividiendo tablas sólo para seguir las reglas o estas divisiones son en verdad prácticas? Éstas son el tipo de cosas que usted, el diseñador de la base de datos, necesita decidir. La experiencia y el sentido común lo pueden auxiliar para tomar la decisión correcta. La normalización no es una ciencia exacta. Es subjetiva.
Existen seis niveles más de normalización que no se han discutido aquí. Ellos son Forma Normal Boyce-Codd, Cuarta Forma Normal (4NF), Quinta Forma Normal (5NF) o
Forma Normal de Proyección-Unión, Forma Normal de Proyección-Unión Fuerte, Forma Normal de Proyección-Unión Extra Fuerte y Forma Normal de Clave de Dominio. Estas formas de normalización pueden llevar las cosas más allá de lo que necesita. Éstas existen para hacer una base de datos realmente relacional. Tienen que ver principalmente con dependencias múltiples y claves relacionales.
En resumen
La normalización es una técnica que se utiliza para crear relaciones lógicas apropiadas entre tablas de una base de datos.
Ayuda a prevenir errores lógicos en la manipulación de datos. La normalización facilita también agregar nuevas columnas sin romper el esquema actual ni las relaciones.
sábado, 29 de octubre de 2011
SEMANA 12 - TEORÍA DE NORMALIZACIÓN
TEORÍA DE NORMALIZACIÓN
Terminología relacional equivalente
Trabajo (Código, Nombre, Posición, Salario), donde Código es la Clave Primaria.
- Relación = tabla o archivo
- Registro = registro, fila , renglón o tupla
- Atributo = columna o campo
- Clave = llave o código de identificación
- Clave Candidata = superclave mínima
- Clave Primaria = clave candidata elegida
- Clave Ajena (o foránea) = clave externa o clave foránea
- Clave Alternativa = clave secundaria
- Dependencia Multivaluada = dependencia multivalor
- RDBMS = Del inglés Relational Data Base Manager System que significa, Sistema Gestor de Bases de Datos Relacionales.
- 1FN = Significa, Primera Forma Normal o 1NF del inglés First Normal Form.
Todo atributo en una tabla tiene un dominio, el cual representa el conjunto de valores que el mismo puede tomar. Una instancia de una tabla puede verse entonces como un subconjunto del producto cartesiano entre los dominios de los atributos. Sin embargo, suele haber algunas diferencias con la analogía matemática, ya que algunos RDBMS permiten filas duplicadas, entre otras cosas. Finalmente, una tupla puede razonarse matemáticamente como un elemento del producto cartesiano entre los dominio.
Dependencia
Una dependencia funcional es una conexión entre uno o más atributos. Por ejemplo si se conoce el valor de FechaDeNacimiento podemos conocer el valor de Edad.Las dependencias funcionales del sistema se escriben utilizando una flecha, de la siguiente manera:
FechaDeNacimiento
Aquí a FechaDeNacimiento se le conoce como un determinante. Se puede leer de dos formas FechaDeNacimiento determina a Edad o Edad es funcionalmente dependiente de FechaDeNacimiento. De la normalización (lógica) a la implementación (física o real) puede ser sugerible tener éstas dependencias funcionales para lograr la eficiencia en las tablas.
Propiedades de la Dependencia funcional
Existen 3 axiomas de Armstrong:Dependencia funcional Reflexiva
Si "x" está incluido en "x" entonces xDependencia funcional Aumentativa
DNI
DNI,dirección
Si con el DNI se determina el nombre de una persona, entonces con el DNI más la dirección también se determina el nombre y su dirección.
Dependencia funcional transitiva.
Sean X, Y, Z tres atributos (o grupos de atributos) de la misma entidad. Si Y depende funcionalmente de X y Z de Y, pero X no depende funcionalmente de Y, se dice entonces que Z depende transitivamente de X. Simbólicamente sería:X
FechaDeNacimiento
Edad
FechaDeNacimiento
Entonces tenemos que FechaDeNacimiento determina a Edad y la Edad determina a Conducir, indirectamente podemos saber a través de FechaDeNacimiento a Conducir (En muchos países, una persona necesita ser mayor de cierta edad para poder conducir un automóvil, por eso se utiliza este ejemplo).
Propiedades deducidas
Unión
Pseudo-transitiva
Descomposición
Claves
Una clave primaria es aquella columna (o conjunto de columnas) que identifica únicamente a una fila. La clave primaria es un identificador que va a ser siempre único para cada fila. Se acostumbra a poner la clave primaria como la primera columna de la tabla pero es más una conveniencia que una obligación. Muchas veces la clave primaria es numérica auto-incrementada, es decir, generada mediante una secuencia numérica incrementada automáticamente cada vez que se inserta una fila.En una tabla puede que tengamos más de una columna que puede ser clave primaria por sí misma. En ese caso se puede escoger una para ser la clave primaria y las demás claves serán claves candidatas.
Una clave ajena (foreign key o clave foránea) es aquella columna que existiendo como dependiente en una tabla, es a su vez clave primaria en otra tabla.
Una clave alternativa es aquella clave candidata que no ha sido seleccionada como clave primaria, pero que también puede identificar de forma única a una fila dentro de una tabla. Ejemplo: Si en una tabla clientes definimos el número de documento (id_cliente) como clave primaria, el número de seguro social de ese cliente podría ser una clave alternativa. En este caso no se usó como clave primaria porque es posible que no se conozca ese dato en todos los clientes.
Una clave compuesta es una clave que está compuesta por más de una columna.
La visualización de todas las posibles claves candidatas en una tabla ayudan a su optimización. Por ejemplo, en una tabla PERSONA podemos identificar como claves su DNI, o el conjunto de su nombre, apellidos, fecha de nacimiento y dirección. Podemos usar cualquiera de las dos opciones o incluso todas a la vez como clave primaria, pero es mejor en la mayoría de sistemas la elección del menor número de columnas como clave primaria.
· Diccionario de Datos
. 1FN, 2FN,3FN
La Primera Forma Normal Esta primera Forma Normal, nos lleva a no repetir datos en nuestras tablas. Los famosos maestro – detalle, deben aplicarse a la estructura de la tabla.Si nuestra tabla de ventas repite una y otra vez (por cada venta) , el nombre, el domicilio y otros datos del Cliente, es que no hemos aplicado esta Normalizaciòn.Si tenemos una tabla clientes, en la tabla ventas, solo deberia figurar el codigo del cliente, para que el resto de los datos se puedan referenciar automaticamente sin problemas y sin duplicar información.Lo mismo ocurriria en una tabla de detalle de ventas, si por cada item vendido colocamos el detalle del producto, con su descripción , medidas, etc…Tendriamos un desaprovechamiento de espacio y recursos muy grande. Para ello, tendremos nuestra tabla maestra de Productos y con solo grabar el código de dicho producto en nuestra tabla de ventas, será suficiente.
La Segunda Forma Normal (Si o si debe estar previamente aplicada la Primera Forma Normal) La Segunda Forma Normal nos habla de que cada columna de la tabla debe depender de la clave.Esto significa que todo un registro debe depender únicamente de la clave principal, si tuvieramos alguna columna que se repite a lo largo de todos los registros, dichos datos deberian atomizarse en una nueva tabla.Veamos un ejemplo
La Tercera Forma Normal En realidad si nos guiamos en el ejemplo de esta nota, ya no quedaria normalización por aplicar y podriamos decir que nuestro ejemplo cumple con las 3 formas normales, ya que la 3ra Forma Normal nos habla de que :
- Ninguna Columna puede depender de una columna que no tenga una clave
- No puede haber datos derivados
En el 2do ejemplo hemos descubierto campos que dependian de la clave principal (VentaID) y que podrian incluirse en una tabla maestra.Pero supongamos un ejemplo donde ciertas columnas no dependen de la clave principal y si dependen de una columna de nuestra tabla.
ConclusiónFinalmente si tomamos en cuenta que una tabla de detalle de venta (item x item) puede contener un volumen de millones de registros, al haberle aplicado las 3 formas normales nos estaremos ahorrando varios Gigabytes de tamaño en dicha tabla y por supuesto mejorado notablemente la performance.
Formas Normales
Las formas normales son aplicadas a las tablas de una base de datos. Decir que una base de datos está en la forma normal N es decir que todas sus tablas están en la forma normal N.
Diagrama de inclusión de todas las formas normales.
En general, las primeras tres formas normales son suficientes para cubrir las necesidades de la mayoría de las bases de datos. El creador de estas 3 primeras formas normales (o reglas) fue Edgar F. Codd.[1]Primera Forma Normal (1FN)
Artículo principal: Primera forma normal
Una tabla está en Primera Forma Normal si:- Todos los atributos son atómicos. Un atributo es atómico si los elementos del dominio son indivisibles, mínimos.
- La tabla contiene una llave primaria única.
- La llave primaria no contiene atributos nulos.
- No debe existir variación en el número de columnas.
- Los Campos no llave deben identificarse por la llave (Dependencia Funcional)
- Debe Existir una independencia del orden tanto de las filas como de las columnas, es decir, si los datos cambian de orden no deben cambiar sus significados
Esta forma normal elimina los valores repetidos dentro de una BD
Segunda Forma Normal (2FN)
Artículo principal: Segunda forma normal
Dependencia Funcional. Una relación está en 2FN si está en 1FN y si los atributos que no forman parte de ninguna clave dependen de forma completa de la clave principal. Es decir que no existen dependencias parciales. (Todos los atributos que no son clave principal deben depender únicamente de la clave principal).En otras palabras podríamos decir que la segunda forma normal está basada en el concepto de dependencia completamente funcional. Una dependencia funcional
Por ejemplo {DNI, ID_PROYECTO}
Tercera Forma Normal (3FN)
Artículo principal: Tercera forma normal
La tabla se encuentra en 3FN si es 2FN y si no existe ninguna dependencia funcional transitiva entre los atributos que no son clave.Un ejemplo de este concepto sería que, una dependencia funcional X->Y en un esquema de relación R es una dependencia transitiva si hay un conjunto de atributos Z que no es un subconjunto de alguna clave de R, donde se mantiene X->Z y Z->Y.
Por ejemplo, la dependencia SSN->DMGRSSN es una dependencia transitiva en EMP_DEPT de la siguiente figura. Decimos que la dependencia de DMGRSSN el atributo clave SSN es transitiva vía DNUMBER porque las dependencias SSN→DNUMBER y DNUMBER→DMGRSSN son mantenidas, y DNUMBER no es un subconjunto de la clave de EMP_DEPT. Intuitivamente, podemos ver que la dependencia de DMGRSSN sobre DNUMBER es indeseable en EMP_DEPT dado que DNUMBER no es una clave de EMP_DEPT.
Formalmente, un esquema de relacion R está en 3 Forma Normal Elmasri-Navathe,[2] si para toda dependencia funcional
- X es superllave o clave.
- A es atributo primo de R; esto es, si es miembro de alguna clave en R.
sábado, 22 de octubre de 2011
SEMANA 11- MODELO DE DATOS
MODELO DE DATOS
Un diagrama o modelo entidad-relación (a veces denominado por sus siglas, E-R "Entity relationship", o, "DER" Diagrama de Entidad Relación) es una herramienta para el modelado de datos de un sistema de información. Estos modelos expresan entidades relevantes para un sistema de información así como sus interrelaciones y propiedades.
Modelado Entidad-Relación
El Modelo Entidad-Relación.
- Se elabora el diagrama (o diagramas) entidad-relación.
- Se completa el modelo con listas de atributos y una descripción de otras restricciones que no se pueden reflejar en el diagrama.
Dado lo rudimentario de esta técnica se necesita cierto entrenamiento y experiencia para lograr buenos modelos de datos.
El modelado de datos no acaba con el uso de esta técnica. Son necesarias otras técnicas para lograr un modelo directamente implementable en una base de datos. Brevemente:
- Transformación de relaciones múltiples en binarias.
- Normalización de una base de datos de relaciones (algunas relaciones pueden transformarse en atributos y viceversa).
Definicion de modelo de datos
``Un modelo de datos es un sistema formal y abstracto que permite describir los datos de acuerdo con reglas y convenios predefinidos. Es formal pues los objetos del sistema se manipulan siguiendo reglas perfectamente definidas y utilizando exclusivamente los operadores definidos en el sistema, independientemente de lo que estos objetos y operadores puedan significar. ‘‘ ``Un modelo de datos es una combinación de tres componentes:
- una colección de estructuras de datos (los bloques constructores de cualquier base de datos que conforman el modelo);
- una colección de operadores o reglas de inferencia, los cuales pueden ser aplicados a cualquier instancia de los tipos de datos listados en (1) , para consultar o derivar datos de cualquier parte de estas estructuras en cualquier combinación deseada;
- una colección de reglas generales de integridad, las cuales explícita o implícitamente definen un conjunto de estados consistentes --estas reglas algunas veces son expresadas como reglas de insertar-actualizar-borrar. ‘‘
- i) como una herramienta para especificar los tipos de datos y la organización de los mismos que son permisibles en una base de datos específica;
- ii) como una base para el desarrollo de una metodología general de diseño para las bases de datos;
- iii) como una base para el desarrollo de familias de lenguajes de alto nivel para manipulación de consultas ( querys ) y datos;
- iv) como el elemento clave en el diseño de la arquitectura de un manejador de bases de datos.
“El modelo de datos es el proceso que implica crear una representación que tienen los usuarios de los datos Si el modelo de datos representa en forma incorrecta la visión que poseen los usuarios de los datos, encontrarán las aplicaciones difíciles de usar, incompletas y por supuesto en el desarrollo de las bases de datos y sus aplicaciones..”
“Un modelo de datos es una serie de conceptos que puede utilizarse para describir un conjunto de datos y las operaciones para manipularlos.
Hay dos tipos de modelos de datos: los modelos conceptuales y los modelos lógicos.
- Los modelos conceptuales se utilizan para representar la realidad a un alto nivel de abstracción. Mediante los modelos conceptuales se puede construir una descripción de la realidad fácil de entender.
- En los modelos lógicos , las descripciones de los datos tienen una correspondencia sencilla con la estructura física de la base de datos.
Un esquema es un conjunto de representaciones lingüísticas o gráficas que describen la estructura de los datos de interés.
Los modelos conceptuales deben ser buenas herramientas para representar la realidad, por lo que deben poseer las siguientes cualidades:
- Expresividad : deben tener suficientes conceptos para expresar perfectamente la realidad.
- Simplicidad : deben ser simples para que los esquemas sean fáciles de entender.
- Minimalidad : cada concepto debe tener un significado distinto.
- Formalidad : todos los conceptos deben tener una interpretación única, precisa y bien definida.
Resumen:
Un modelo de datos es una serie de conceptos que puede utilizarse para describir un conjunto de datos y las operaciones para manipularlos.Más explícitamente:
Un modelo de datos es la combinación de una colección de estructuras de datos, operadores o reglas de inferencia y de reglas de integridad, las cuales definen un conjunto de estados consistentes. El cual puede ser usado como una herramienta para especificar los tipos de datos y la organización de los mismos. Además para la manipulación de consultas y datos, así mismo es el elemento clave en el diseño de la arquitectura de un manejador de BD.
El primer modelo de datos fue el relacional en 1969, mucho antes incluso que los modelos jerárquicos y de red.
. Técnica de Aplicaciones
El problema de las bases de datos es cómo buscar en ellas; no porque sea especialmente dificultoso sino porque – a pesar de los intentos efectuados – no hay un único lenguaje o modelo de interrogación.
Por eso, es importante tomarse un tiempo cada vez que nos enfrentemos a una base de datos, y consultar la ayuda que casi todas incorporan.
No obstante, hay una serie de rasgos que suelen ser comunes (aunque su utilización pueda ser diferente):
— Toda consulta se traduce en una especie de ecuación, que es la que interroga al sistema. Muchas veces oiremos hablar de ella como ecuación de búsqueda.
— Puede buscarse por un único campo (sólo en un tipo de datos del registro: materias, títulos,...), por varios a la vez o por todos (o al menos, por los más significativos).
Normalmente, los términos están normalizados (se establece que un nombre de autor o una materia, por ej., aparezca siempre de la misma forma).
— Se utiliza la lógica booleana para buscar por varios términos a la vez. Cuando veamos el término búsqueda avanzada, generalmente hace referencia a la utilización de tal lógica.
Los elementos básicos de la misma (llamados operadores booleanos) son los siguientes:
Y : representa una intersección (en Matemáticas “Ç”) y reduce los resultados
Significa que los términos buscados deben encontrase todos a la vez en los registros que recuperemos. Acota, por tanto, los resultados: sirve para reducir su número.
Algunas otras formas en que aparece son: AND, + , .AND., ...
Ej.: "economics and spain " recupera sólo los registros donde aparezcan a la vez los dos términos
O : representa una unión (en Matemáticas “È”). Amplía los resultados.
Su uso provoca que en los resultados aparezca uno cualquiera de los términos buscados en solitario, cualquier combinación de ellos (si son más de dos) y todos ellos a la vez.
Generalmente, obtenemos demasiados resultados, produciéndose ruido documental (información que no responde a lo que nos interesa en una búsqueda).
Otras formas de representación: OR, / , .OR., ...
Ej.: "economics or social" recupera los registros que contengan alguno de los términos o los dos a la vez.
NOT : representa la negación: excluye (en Matemáticas “Ë”)
Todo término que siga al operador será considerado como no pertinente y eliminará del resultado los registros que lo contengan
Se representa también como: NOT, — , .NOT., ...
Existen otros operadores booleanos, que son combinación de los anteriores. Pondremos como ejemplo el “O exclusivo” (NOR): funciona exactamente como el O; pero invalida los registros en que aparezcan todos los términos implicados a la vez: sólo serán válidos los que contengan un único término (uno, u otro, u...)
Ej.: "Economics not spain" recupera sólo los registros que incluyan economics pero no spain.
— Truncamientos: Consiste en indicar una serie de caracteres que queremos que aparezcan en nuestra consulta; pero sin que escribamos la palabra completa.
Se utilizan una serie de símbolos, llamados comodín, que pueden suplir a cualquier número de caracteres o a uno sólo: los más utilizados son * y s
Los truncamientos pueden situarse a la izquierda, a la derecha o en ambos lados. Los más frecuentes son los de la derecha.
Sirven para recuperar palabras que pertenecen a la misma familia. En rigor, sería como buscar varios términos utilizando el O booleano.
Ej. Econom*
Si * equivale a cualquier nº de caracteres, obtendremos Economía, econometría, económico (si no se tienen en cuenta las tildes), economicos, econometrices, economia ,...
Sería como haber utilizado en la búsqueda todos esos términos conectados con O.
Todos estos son elementos que encontraremos en cualquier base de datos (en cierto modo, están también en la base de cualquier catálogo).
Suscribirse a:
Entradas (Atom)