Bases de Datos

Cada tabla normalizada representa una entidad o clase de negocios. Por lo tanto, un diagrama de clases se puede convertir en una lista de tablas normalizadas. Asímismo, es posible dibujar una lista de tablas normalizadas como un diagrama de clases. Técnicamente, las entidades en un diagrama de clases no tienen que estar en la 3NF (o posterior). Algunos diseñadores utilizan un diagrama de clases como resumen, o imagen general de los negocios, y dejan fuera algunos detalles normalizados. En esta situación, tendrán que convertirse las clases a una lista de tablas normalizadas.

Relaciones uno-a-muchos

La regla más importante al convertir diagrama de clases a tablas normalizadas es que las relaciones se manejan al colocar una columna común en cada una de las tablas relacionadas. Esta columna suele ser una llave en una de las tablas y este proceso es fácil de apreciar con las relaciones uno-a-muchos.

Para convertir una relación uno-a-muchos  debe agregarse la llave primaria del lado uno a la tabla del lado muchos. Esa llave agregada a la tabla del lado muchos no formará parte de su llave primaria, sino que será una columna común.

Relaciones muchos-a-muchos

Los diagrama de clases resumidos suelen contener relaciones muchos-a-muchos. Sin embargo, en una base de datos relacional, las relaciones muchos a muchos deben dividirse en dos relaciones uno-a-muchos para llegar a la BCNF.

Cada una de las dos entidades iniciales (con una relación muchos-a-muchos) se convierte en una tabla. El paso siguiente es crear una tabla nueva, que contiene las llaver primarias de las otras dos tablas. Esta tabla representa la relación muchos-a-muchos. Debe verificarse que las tres tablas estén en la 3NF, donde cada columna que no es una llave depende de la llave completa y sólo de la llave.

Asociaciones enarias

Las asociaciones enarias se representan con un diamante. Esta asociación con un diamante también se vuelve una clase. En cierto sentido, una asociación enaria es un grupo de varias asociaciones binarias. La nueva clase de asociación contiene la llave primaria de cada una de las otras clases. Siempre y cuando las asociaciones binarias sean uno-a-muchos, cada columna en la nueva clase de asociación será parte de la llave primaria. Si por alguna razó una asociación binaria es uno-a-uno, la columna correspondiente no sería una llave.

Generalización o tipos secundarios

Al convertir este tipo de diseño a una base de datos relacional, existen 2 métodos básicos.

1. Si los tipos secundarios son similares, puede ignorar las clases secundarias y comprimirlas en la clase principal, la cual contendría todas las propiedades de cada una de las clases secundarias.
2. En casi todos los casos, un mejor método es crear tablas separadas para cada clase secundaria. Cada tabla contendrá la llave primaria de la clase principal (superclase o clase padre). Además deberán agregarse atributos específicos a cada uno de los tipos secundarios.

Asociaciones reflexivas

En ocasiones, una entidad puede vincularse consigo misma. Para hacer la conversión, se crea una tabla con los atributos de esta entidad como columnas, y agregar como otra columna el nombre dado al vínculo en la asociación reflexiva.

En el diseño de informes y tablas deben considerarse las reglas de negocios necesarias a imponer para asegurar la presición y la integridad de los datos. Se consultan las definiciones de las tablas y se agregan las restricciones y un mensaje. Otras restricciones serían que en un formulario se ofrezca una lista de opciones predefinidas para que de ellos solamente se elija la opción. Otra restricción es la integridad referencial que se aplica teniendo en una tabla una llave foránea y sólo podemos introducir ese valor si el valor correspondiente ya existe en la tabla que la origina. Todo esto sirve para introducir valores correctos en la base de datos.

Al preparar la teoría de las bases de datos relacionales, F.F. Codd propuso primero las tres reglas de la normalización. Al examinar las situaciones del mundo real, él y otros diseñadores comprendieron que podrían ocurrir problemas adicionales en algunas situaciones, por lo que se crearon «formas normales» adicionales. Por suerte, estas situaciones no suelen surgir en la práctica.

Las tablas deben estar en la 3NF.

Forma normal de Boyce-Codd

Deben analizarse las columnas; si varias de ellas presentan una dependencia oculta entre sí (siendo que si de la tabla se eliminan filas y por ello se pueden perder datos importantes) debe agregarse una nueva tabla para hacer explícita la dependencia entre esas columnas. Como buena práctica y por cuestiones de flexibilidad se recomienda dejar la tabla original y agregar la nueva.

Cuarta forma normal

El problema se presenta cuando hay relaciones binarias pero el modelador intenta mostrarlas como una relación combinada. Si se detecta que hay una dependencia oculta entre columnas, se debe dividir la tabla en varias tablas (las necesarias) para mostrar cada una de las dependencias haciéndolas explícitas.

Forma normal dominio-llave

En 1981, Fagin describió un enfoque diferente para las tablas normalizadas cuando propuso la forma normal dominio-llave (DKNF), la cual describe la meta final al diseñar una base de datos. Si una tabla está en la DKNF, también debe estar en la 4NF, 3NF y todas las demás formas normales. La dificultad es que no hay un método definido para hacer que una tabla esté en la DKNF. De hecho, es posible que algunas tablas nunca puedan convertirse a la DKNF.

La meta de la DKNF es hacer que cada tabla represente un tema y que para todas las reglas de negocios se exprese en términos de restricciones de dominios y relaciones de llaves. Es decir, todas las reglas de negocios se describen de manera explícita por medio de las reglas de las tablas. Las restricciones de dominios son sencillas; representan las limitaciones que se aplican a los datos en una columna.

Todas las otras reglas de negocios deben expresarse en términos de relaciones con las llaves. En particular, no puede haber relaciones ocultas.

Para definir un grupo de tablas en la DKNF, primero hay que trabajar en las reglas de la 3NF. Después, confirmar que se tiene una lista completa de las reglas de negocios. A continuación, asegurarnos que las reglas de negocios están expresadas en términos de restricciones de dominios y relaciones de las llaves. Revisar las llaves primarias para confirmar que sean únicas; y que se han capturado todas las relaciones muchos a muchos. Comprobar que no haya reglas ocultas ni dependencias. Establecer relaciones con llaves foráneas para imponer las reglas de existencia y para hacer coincidir los datos en las otras tablas.

La meta al diseñar la base de datos es desarrollar un modelo de la organización, y la DKNF aclara esta meta al afirmar que el mejor diseño de una base de datos es el que declara de manera explícita todas las reglas de negocios como reglas de la base de datos.

Para estar en la tercera forma normal, una tabla ya debe estar en la 2NF, y cada columna que no es una llave sólo debe depender de la llave. Si una columna depende de las columnas que no son parte de la llave, deben dividirse esas columnas en una tabla nueva.

Definición de la segunda forma normal

Una tabla está en la segunda forma normal (2NF) si cada columna que no es una llave depende de la llave completa (no sólo de una parte de ella). Este problema surge sólo para llaves compuestas. La solución es dividir las partes que sólo dependen de una parte de la llave, sin olvidar incluir esa parte de la llave en la tabla nueva.

Dependencia

Este análisis de la 2NF (y de la 3NF) emplea el término depende. Es decir, el atributo Y depende de X si y sólo si cada valor de X determina con exactitud un valor de Y. El problema para la normalización es determinar las relaciones de los datos del negocio en la vida real. La dependencia es un problema de las suposiciones y las operaciones de negocios.

Cuando una tabla no tiene grupos repetidos, se dice que está en la primera forma normal (1NF). Es decir, para cada celda en una tabla sólo puede haber un valor.

Grupos repetidos

Todos los grupos repetidos en una tabla deben dividirse en tablas nuevas. La tabla nueva debe incluir una copia de la llave de la tabla original. La tabla que contiene el grupo repetido debe tener una llave concatenada para volver a combinar los datos en las consultas.

Grupos repetidos anidados

Los grupos se anidan cuando se repiten dentro de otro grupo. Deben dividirse todos los grupos en pasos. Cada tabla contendrá la llave original.

Llaves compuestas

En una tabla puede ser que se utilice más de una columna para su llave primaria, a esa llave se le denomina llave compuesta. Es necesario llaves compuestas cuando la tabla contiene una relación uno a muchos o muchos a muchos con otra tabla.

Para normalizar los datos de manera correcta y guardarlos lo más eficiente posible, deben identificarse las llaves adecuadamente. La llave que se elija depende de las relaciones de negocios, la terminología de la organización, las relaciones uno-a-muchos y muchos-a-muchos dentro de la compañia.

Llaves sustitutas

Puede ser difícil asegurar que cualquier dato del mundo real genere siempre una llave única. Por lo tanto, a menudo se pedirá al sistema de la base de datos que genere sus propios valores de llave. Estas llaves sustitutas se utilizan sólo dentro de la base de datos y suelen estar ocultas, de modo que los usuarios ni siquiera saben que existen. Son muy útiles cuando no existe certeza con las llaves de negocios. Si se basa en las llaves de negocios, es importante confiar en que siempre serán uniformes y nunca se duplicarán.

Notación

Un diagrama de clases detallado puede describir cada tabla e incluir todas las propiedades dentro de cada clase y las columnas marcadas como llaves. La ventaja de emplear diagramas de clases es que resaltan las asociaciones entre las clases. La desventaja es que pueden hacerse muy grandes, dificultándose incluir toda la información en una página, también se cruzan muchas líneas de asociación complicando la lectura del diagrama.

A esto puede usarse una notación más breve, que consiste en una lista simple  de las tablas. Las llaves primarias se subrayan y suelen mostrarse primero. Esta notación es fácil de escribir y muestra varias tablas en un espacio compacto, pero es difícil mostrar las relaciones entre las tablas.

Una base de datos es un conjunto de tablas. Las bases de datos sin una herramienta muy útil, pero lo serán sólo si se diseñan de manera correcta, es decir, que las tablas estén hechas correctamente, y para esto deben tomarse en cuenta una serie de reglas, las Reglas de Normalización de los datos.

La normalización de los datos se refiere a dividir dichos datos en varias tablas que se conectarán entre sí basadas en los datos que contengan. Deben crearse las tablas específicas para el negocio, por lo que primero debe comprenderse el negocio y sus tablas deben coincidir con las reglas de negocios; ésta es la mitad del trabajo de la normalización.

Las relaciones de negocios o la correspondencia de cardinalidad (uno-a-uno, uno-a-varios, varios-a-uno, varios-a-varios) son la base de la normalización de los datos. Estas relaciones y reglas de negocios varían para cada empresa.

Al diseñar con cuidado las tablas para la base de datos se consiguen varias ventajas:

• Ahorrar espacio
• Minizar la duplicación
• Proteger los datos para asegurar que sean uniformes
• Proporcionar transacciones más rápidas al enviar menos datos