. NORMALIZACIÓN IV
CASO PRACTICO
domingo, 20 de noviembre de 2011
viernes, 18 de noviembre de 2011
SEMANA 15 - NORMALIZACIÓN III
NORMALIZACIÓN III
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.
VentaID | ItemID | ProductoID | Cantidad | Descripcion | Medida | Proveedor |
1 | 1 | 3455 | 12 | Impresora HP LJ8000 | 122cm | 1 |
1 | 2 | 2455 | 34 | Scanner HP A3555 | 33cm | 1 |
2 | 1 | 5444 | 21 | Mouse HP Wireless | - | 1 |
Esto es muy normal encontrar en bases mal normalizadas.Vemos que los campos DESCRIPCION , MEDIDA y PROVEEDOR no dependen de VENTAID y es por ello que no deberian estar dentro de la tabla de detalle de ventas, ya que dependen de PRODUCTOID.Aqui no se trata ya de eliminar grupos repedidos de datos (1ra Forma Normal) sino que ante la inclusion de una clave perteneciente a otra tabla, cualquier campo que sea subordinado de dicha clave debe estar en otra tabla y no en nuestra tabla detalle.
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.
. Aplicaciones
Si las tablas no son definidas apropiadamente, podemos tener muchos dolores de cabeza al momento de ejecutar consultas a la base de datos para tratar de obtener algún tipo de información.
No importa si nuestra base de datos tiene sólo 20 registros, o algunos cuantos miles, es importante asegurarnos que nuestra base de datos está correctamente diseñada para que tenga eficiencia y que se pueda seguir utilizando por largo del tiempo.
En este artículo, se mencionarán algunos principios básicos del diseño de base de datos y se tratarán algunas reglas que se deben seguir cuando se crean bases de datos.
Dependiendo de los requerimientos de la base de datos, el diseño puede ser algo complejo, pero con algunas reglas simples que tengamos en la cabeza será mucho más fácil crear una base de datos perfecta para nuestro siguiente proyecto.
Son muchas las consideraciones a tomar en cuenta al momento de hacer el diseño de la base de datos, quizá las más fuertes sean:
- La velocidad de acceso,
- El tamaño de la información,
- El tipo de la información,
- Facilidad de acceso a la información,
- Facilidad para extraer la información requerida,
- El comportamiento del manejador de bases de datos con cada tipo de información.
No obstante que pueden desarrollarse sistemas de procesamiento de archivo e incluso manejadores de bases de datos basándose en la experiencia del equipo de desarrollo de software logrando resultados altamente aceptables, siempre es recomendable la utilización de determinados estándares de diseño que garantizan el nivel de eficiencia mas alto en lo que se refiere a almacenamiento y recuperación de la información.
De igual manera se obtiene modelos que optimizan el aprovechamiento secundario y la sencillez y flexibilidad en las consultas que pueden proporcionarse al usuario.
Entre las metas más importantes que se persiguen al diseñar un modelo de bases de datos, se encuentran las siguientes que pueden observarse en esta figura- Almacenar Solo La Información Necesaria.
A menudo pensamos en todo lo que quisiéramos que estuviera almacenado en una base de datos y diseñamos la base de datos para guardar dichos datos. Debemos de ser realistas acerca de nuestras necesidades y decidir qué información es realmente necesaria.
Frecuentemente podemos generar algunos datos sobre la marcha sin tener que almacenarlos en una tabla de una base de datos. En estos casos también tiene sentido hacer esto desde el punto de vista del desarrollo de la aplicación.
1.2. Normalizar la Estructura de las Tablas.
Si nunca antes hemos oído hablar de la "normalización de datos", no debemos temer. Mientras que la normalización puede parecer un tema complicado, nos podemos beneficiar ampliamente al entender los conceptos más elementales de la normalización.
Una de las formas más fáciles de entender esto es pensar en nuestras tablas como hojas de cálculo. Por ejemplo, si quisiéramos seguir la pista de nuestra colección de CD’s en una hoja de cálculo, podríamos diseñar algo parecido a lo que se muestra en la siguiente tabla.
+------------+-------------+--------------+ .. +--------------+
| Álbum | track1 | track2 | | track10 |
+------------+-------------+--------------+ .. +--------------+
Esto parece razonable. Sin embargo el problema es que el número de pistas que tiene un CD varía bastante. Esto significa que con este método tendríamos que tener una hoja de cálculo realmente grande para albergar todos los datos, que en los peores casos podrían ser de hasta 20 pistas. Esto en definitiva no es nada bueno.
Uno de los objetivos de una estructura de tabla normalizada es minimizar el número de "celdas vacías". El darnos cuenta de que cada lista de CD’s tiene un conjunto fijo de campos (título, artista, año, género) y un conjunto variable de atributos (el número de pistas) nos da una idea de cómo dividir los datos en múltiples tablas que luego podamos relacionar entre sí.
Mucha gente no esta familiarizada con el concepto "relacional", de manera sencilla esto significa, que grupos parecidos de información son almacenados en distintas tablas que luego pueden ser "juntadas" (relacionadas) basándose en los datos que tengan en común.
Es necesario que al realizar la estructura de una base de datos, esta sea flexible. La flexibilidad está en el hecho que podemos agregar datos al sistema posteriormente sin tener que rescribir lo que ya tenemos. Por ejemplo, si quisiéramos agregar la información de los artistas de cada álbum, lo único que tenemos que hacer es crear una tabla artista que esté relacionada a la tabla álbum de la misma manera que la tabla pista. Por lo tanto, no tendremos que modificar la estructura de nuestras tablas actuales, simplemente agregar la que hace falta.
La eficiencia se refiere al hecho de que no tenemos duplicación de datos, y tampoco tenemos grandes cantidades de "celdas vacías".
El objetivo principal del diseño de bases de datos es generar tablas que modelan los registros en los que guardaremos nuestra información.
Es importante que esta información se almacene sin redundancia para que se pueda tener una recuperación rápida y eficiente de los datos.
A través de la normalización tratamos de evitar ciertos defectos que nos conduzcan a un mal diseño y que lleven a un procesamiento menos eficaz de los datos.
Podríamos decir que estos son los principales objetivos de la normalización:
- Controlar la redundancia de la información.
- Evitar pérdidas de información.
- Capacidad para representar toda la información.
- Mantener la consistencia de los datos
martes, 8 de noviembre de 2011
SEMANA 14 - NORMALIZACIÓN II
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.
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.
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.
Suscribirse a:
Entradas (Atom)