Curso de Introducción a SQL Server 2005

Podemos concluir el proceso de normalización cuando analizando nuestras tablas comprobamos que somos capaces de realizar una actualización sin tener que cambiar más de un dato para cada actualización.

Mencionar que el proceso de normalización ha ido evolucionando, los investigadores de bases de datos han incluido dos formas normales a las tres que hemos explicado, la forma normal D y E.

Estas dos últimas formas pertenecen a la normalización avanzada, y no son aplicables a la mayoría de las bases de datos, ya que es muy difícil alcanzar un nivel de complejidad tan alto como para tener que aplicarlas. Incluso se aconseja a los diseñadores que revisen sus estructuras cuando es necesario aplicar las formas normales D y E, ya que posiblemente si son necesarias es porque el desarrollador a cometido errores en su diseño.

Con el proceso de normalización hemos conseguido evitar al máximo la redundancia de datos, permitiendo realizar modificaciones de un modo cómodo. Para ello hemos indicado que desglosamos nuestra base de datos en tantas tablas como sea necesario.

De todas las reglas que hemos visto hay una que está por encima de todas, la lógica y la experiencia del administrador. Estas reglas no son obligatorias, son aconsejables en muchos casos y son de gran ayuda.

La lógica del programador puede indicarle que siguiendo la normalización de su base de datos, ha conseguido desglosar su estructura en tantas tablas con sus consiguientes relaciones. Esto puede provocar que la búsqueda de un registro tenga que llevarse a cabo a través de varias tablas y relaciones, con un rendimiento que deja mucho que desear.

Para solucionar esto, el desarrollador lleva a cabo el proceso de desnormalización, que tendrá consecuencias de redundancia de datos, pero que posiblemente sean necesario para la mejora del rendimiento.

Para conseguir alcanzar el término medio entre el proceso de normalización y desnormalización, el mejor medio es la experiencia. Se expone la base de datos a explotación como prueba piloto y se analiza la actividad que se realiza sobre ella, estudiando si los resultados se adaptan a las necesidades y cumplen con el rendimiento esperado, sino es así, gracias a estos estudios podremos ver que debemos modificar para mejorar nuestro diseño. SQL Server 2005 tiene la herramienta SQL Server Profiler que nos ayuda a realizar este tipo de análisis.

El servidor SQL Server ofrece un grupo de herramientas que ayudan en el proceso de normalización. Gracias a estas herramientas podremos gestionar nuestras tablas de modo que los datos se añadan con la lógica deseada y que las modificaciones cumplan los requisitos deseados.

Con estas herramientas podremos indicar a nuestro servidor como debe administrar la normalización, y nos ahorraremos muchas líneas de código en aplicaciones para que se encarguen de ella.  Esto supone una gran ventaja frente a otras bases de datos.

Vamos a explicar brevemente las herramientas que tendremos ocasión de ver como utilizarlas en próximos capítulos. Estas herramientas son:

• Identidad
• Restricciones
• Integridad en relaciones
• Disparadores

Podemos tener una columna configurada como columna identidad, esta columna identidad es la manera más sencilla de garantizar la integridad de identidad.

La columna de identidad es una columna para la cual el propio servidor de base de datos se encarga de asignarle valores automáticamente. Por defecto, el primer valor es uno, y los siguientes registros van aumentando este valor de unidad en unidad. Aunque estos valores, son por defecto, veremos como se pueden modificar.

Una columna identidad es el mejor modo de añadir claves suplentes, como explicamos en el anterior capítulo, cuando una tabla no puede dar de modo natural una clave principal, será tarea nuestra añadir columnas que formen esa clave principal, pues el modo más eficaz es añadir columnas identidad.

Con este tipo de claves suplentes mejoramos considerablemente la relación entre tablas por columnas numéricas, bastante más eficaces que las claves principales formadas por textos.

Mediante las restricciones ponemos limitaciones a los datos que se van a introducir en la base de datos. Determinamos que datos son válidos para insertar en la columna de una tabla.

Tenemos las restricciones UNIQUE, DEFAULT y CHECK que fuerzan la integridad de identidad, dominio y la marcada por usuario. Y por otro lado contamos con las restricciones PRIMARY KEY y FOREIGN KEY para garantizar la integridad referencial en las relaciones.

Esta restricción obliga a que todos los valores de una determinada columna no estén repetidos en otros registros. Si tenemos varias restricciones UNIQUE en una misma tabla, todas deben ser cumplidas a la vez para cada registro.

Con la restricción UNIQUE aseguramos la integridad de identidad de la tabla, ya que cumplimos con la norma de que cada registro es diferente al resto. Si aplicamos claves principales a una tabla, automáticamente se asigna esta restricción a esa columna.

No debes pensar que una columna identidad que se incrementa ella sólo automáticamente, es otro modo de tener una restricción UNIQUE, ya que se pueden dar casos en que tengamos valores duplicados, a no se que marquemos esa columna como clave suplente o principal. Puedes llegar a esta conclusión errónea si has trabajado con ACCESS, pero en SQL Server no es así.

Como su propio nombre indica, esta restricción introduce un valor por defecto en una columna cuando no se índica ningún valor para insertar. Con esta restricción aseguramos la integridad de dominio, ya que aseguramos valores válidos para nuevos registros que se inserten.

Esta restricción evalúa por medio de expresiones los valores que se insertan en una columna. Esta expresión, una vez que se evalúa devuelve un resultado, en función de si el dato es válido (Verdadero) o no (Falso), por lo tanto devuelve un valor booleano que indica si el dato tendrá permiso para ser ingresado o no.

Como puedes ver, nos ayuda a asegurar la integridad de dominio, y si vamos un poco más allá, también nos ayuda a asegurar la estabilidad  de relaciones en configuraciones mucho más avanzadas.

Este tipo de integridad, denominada integridad referencial declarativa (DRI - Declarative Referential Integrity),  es el proceso por el cual SQL Server fuerza de manera automática las relaciones entre tablas. Antes de aparecer este tipo de integridad para servidores SQL Server, era necesario desarrollar códigos para aplicaciones denominadas desencadenadores para cada tabla, y estos se encargaban de ejecutar una serie de acciones que asegurasen esta integridad, y siempre bajo la supervisión del administrador.

A este tipo de integridad llegamos ahora de manera automática, de un modo muy sencillo y con un rendimiento considerable, de modo que el administrador puede dedicarse a otras tareas. Para conseguir esta integridad tenemos dos tipos de restricciones: PRIMARY KEY y FOREIGN KEY.

La clave principal (PRIMARY KEY) nos permite asegurar la integridad de entidad (puesto que es única en cada registro) y por otro lado nos garantiza la estabilidad de las relaciones con otras tablas.

La restricción FOREIGN KEY, se conoce como la clave externa o foránea que ya hemos explicado. Y como ya sabes es la pareja de la restricción PRIMARY KEY, y juntas cumplen con la integridad referencial.

Una clave externa es una copia de la clave principal de la tabla principal, se inserta en la tabla que se pretende enlazar y con esto creamos la relación entre un par de tablas. Las claves externas pueden ser varias en una misma tabla, mientras que las principales deben ser únicas.

Para que esta relación que comentamos se cumpla, la clave principal que enlaza con la externa debe cumplir obligatoriamente que las dos columnas sean del mismo tipo.

Esta tipo de integridad que surgió con la versión 2000 de SQL Server, permite una serie de operaciones, que sólo pueden llevarse a cabo de este modo y no de otro.

Expliquemos porque a este tipo de integridad referencial se le añade el concepto de cascada. Imagina que tenemos una tabla que almacena las facturas emitidas para los clientes. Esta tabla entre sus campos contiene el campo codigo_cliente, que es la clave externa que se relaciona con la clave principal de la tabla clientes. Por lo tanto la tabla clientes tendrá un campo codigo_cliente que se relaciona con la tabla Facturas. Puedes verlo algo más claro en el siguiente gráfico:

Como ves, tenemos una relación uno a varios. Mientras en la tabla Clientes el campo codigo_cliente será único en cada registro, en la tabla Facturas, este mismo campo puede aparecer varias veces en diferentes registros, ya que emitimos varias facturas para el mismo cliente.

Esta relación representa una integridad referencial estricta, la cual no nos permite modificar el valor del código de cliente en la tabla clientes ya que de algún modo dejaría "huérfanos" a aquellos registros que anteriormente estaban relacionados al código de cliente que tratamos de modificar. Otra limitación que tenemos con esta integridad es que no nos permiten eliminar un cliente que tenga facturas emitidas en la tabla Facturas, por lo tanto no podemos eliminar un registro que tenga otros registros referenciados mediante estas relaciones.

Precisamente para solucionar estos problemas que hemos planteado tenemos la integridad referencial en cascada. Podemos añadir una serie de acciones que permita solventar estas complicaciones.

Podemos incluir actualizaciones en cascada, de modo que cuando modifiquemos el valor de una clave principal en la tabla principal, se modifiquen del mismo modo los valores de las claves externas en el resto de tablas enlazadas a la principal. En nuestro caso, al modificar el valor del campo codigo_cliente de un determinado cliente, este nuevo valor se cambiará para todos los registros referenciados en la tabla Facturas.

Igualmente podemos incluir eliminaciones en cascada, de tal forma que si eliminamos un registro de la tabla principal, se eliminen también los registros enlazados en la tabla subordinada. En nuestro caso, podríamos eliminar un cliente, y automáticamente se eliminarían todos sus registros de facturas.

Debes tener mucho cuidado a la hora de utilizar este tipo de relaciones en cascada, ya que si activamos por ejemplo la eliminación en cascada, corremos peligro de que un usuario no sea consciente de que perderá todos los registros vinculados a esa tabla.

Una clave principal, por norma general no cambiará su valor, por lo tanto no tiene sentido activar en esos casos tampoco la actualización en cascada.

Los desencadenadores representan aplicaciones que desarrollamos en lenguaje T-SQL y que se ejecutan, o mejor dicho, se "disparan" cuando sucede algún tipo de evento en una tabla. Los desencadenadores se llaman también disparadores o triggers.

En función del tipo de evento, tenemos los siguientes grupos de desencadenadores:

• Desencadenadores de inserción. Estos desencadenadores se ejecutan cuando se añade un registro o varios.
• Desencadenadores de actualización. Se ejecutan cuando se ha actualizado uno o varios registros.
• Desencadenadores de eliminación.

Con estos desencadenadores aseguramos la lógica de negocio y definimos la integridad de usuario. Antiguamente (versiones anteriores a SQL Server 2000), la integridad referencial en cascada tenía que implementarse mediante desencadenadores que permitiesen la actualización y eliminación en cascada.